freenode/#lisp - IRC Chatlog
Search
23:17:12
jcowan
Well, I suppose you can't force people to understand things, even if they have known all about them since age eight.
23:26:51
jmercouris
I have found an example of using the sbcl unix domain sockets: https://gist.github.com/205c1de56cb66de167c30271666c6975
3:02:20
dandruff
I've heard people say that macros wouldn't be possible with a static type system, but it looks like it might be possible with linear/unique types: https://github.com/fare/moll
3:12:33
sigjuice
what are the unusual looking filenames in quicklisp/dists/quicklisp/software/eazy-project-20180131-git/skeleton about?
3:16:02
sigjuice
I also stumbled across this thing on my computer a few months ago. ~/Library/Caches/$(CFBundleIdentifier)
4:38:42
Xach
As little as I like timezone discussion, I feel a little isolated from my lisp friends due to being in a bad timezone for the next 10 days.
5:14:45
smokeink
how difficult would it be to make a system/algorithm in SBCL that can store in a hashtable all the symbols which are called during a 'testing session' (a session in which the app is run and all the implemented functions are called with the purpose of tesing all the app's functionalities), and then destroy all the symbols which were never called - thus reducing the image for deployment ? there must be a way to do that, and it should
5:57:06
White_Flame
smokeink: there are tools called tree shakers that are supposed to cull unused portions of code. I've not used them, but you can search for the term
5:58:33
smokeink
White_Flame: good idea. https://gist.github.com/burtonsamograd/f08f561264ff94391300
6:00:58
White_Flame
"destroys the package system and does a gc before saving the lisp image" I guess that's one way to do it :)
6:06:38
beach
smokeink: Have you done a back-of-envelope calculation that justifies decreasing the image size?
6:06:38
smokeink
"Wouldn't it be a better approach to start with a tiny kernel and only load what is needed, instead of loading everything and then trying to get rid of everything?"
6:07:28
beach
smokeink: Common Lisp doesn't work that way. Once EVAL or COMPILE is needed, you must have the entire compiler in the image.
6:10:01
jackdaniel
you can load it on demand. default compile may be lazy, like (defun compile (&rest args) (declare (notinline compile)) (without-package-locks (load-cmp-module)) (apply compile args))
6:11:11
beach
jackdaniel: That sounds like a good idea. On systems that don't have demand paging. Otherwise, the compiler would naturally migrate to disk anyway.
6:12:00
jackdaniel
sure, my point is that there is nothing preventing implementer from separating small runtime core from the rest
6:13:08
beach
Sure, but what's the point? Having a small executable, and then a larger file with the compiler in it.
6:13:45
jackdaniel
I can imagine deployment scenario when I'm anxious about providing compiler / evaluator in runtime
6:14:34
jackdaniel
like it's not very common to have lisp library as a shared object, but it is useful in some projects
6:15:40
beach
ACTION again fails to get his point across, so he will be quiet. And he should learn not to try in the future either, so as to prevent additional frustration.
6:17:06
White_Flame
but even to smokeink's last statement, if you lazily load in stuff during development, then you still need to remove the lazy loader mechanism when you bake your image for deployment
6:35:00
p_l
beach: My favourite case for decreasing image sizes are downloading things over internet. And my back-of-the-envelope calculation was based on realities of mobile internet
6:40:44
p_l
beach: simple - very, very lousy network connection, and wanting to get a program over it.
6:41:12
p_l
that said, these days I also often deal with systems that have much lower memory not because of hw, but because of bin-packing services
6:43:42
p_l
beach: btw, fun idea that just came to me regarding a modularly-designed implementation - network demand-pagein of code
6:44:35
p_l
the scenario is one where the end users do not know nor care if the application is on disk already
6:58:32
pjb
smokeink: notice that if you call MAPCAR, and never call CAR, and then you delete CAR, it could fail, because nothing prevents an implementation to use (funcall 'car x) instead of (car x) inside MAPCAR. (or something similar).
6:59:49
beach
smokeink: And if you haven't called all your generic functions with all possible combinations of classes, then the compiler might be invoked in the middle of your application execution.
7:00:35
beach
smokeink: I am still waiting for that back-of-envelope calculation that lead you to think that you must decrease the image size.
7:03:46
smokeink
beach: here's a calculation that illustrates your point https://groups.google.com/forum/#!topic/comp.lang.lisp/49f1RMAjBm8 right after "In practice it'll be a lot of work to implement a solid tree shaker. " ... But that doesn't mean we can't or shouldn't discuss about such hacks :) I am interested to learn more about the technicalities of tree shaking
7:05:05
pjb
smokeink: for example, the delete all packages algo. You may notice problems on some implementations, or that it work well in some others…
7:08:13
beach
smokeink: It is even more complicated that that, because a lot of people assume that the amount of RAM consumed will be the size of the image, but that is true only if your system does not use demand paging. So in many cases, the cost is only for the disk.
7:09:22
beach
smokeink: For example, if the compiler is needed while your application warms up the generic-function caches, eventually, it will probably migrate to disk, leaving you with a much smaller RAM footprint than the image.
7:18:31
smokeink
Actually it'd be just great if (asdf:operate 'asdf:monolithic-compile-bundle-op :my-system) would create a loadable .fasl - then I could just distribute my app as a .fasl and all 'd be cool. The problem is that the generated .fasl is never loadable, I think asdf 'assembles' together the individual .fasls in the wrong order, or I don't know...
7:19:21
Shinmera
ASDF can't assemble fasls, all it can do is assemble a single lisp file for everything and turn that into a fasl.
7:25:48
Shinmera
also: distributing fasls is a bad idea because fasls are typically constrained to an exact version and platform combination of your implementation.
7:27:20
Shinmera
if you want to distribute your app you should either distribute binaries, or sources.
10:16:52
Shinmera
My radiance applications are unfortunately all severely lacking in documentation, sorry about that :(