freenode/#lisp - IRC Chatlog
Search
20:18:33
aeth
VincentVega: You can write a macro which replaces each _ with a new gensym, saves those gensyms into a list, and then adds an implicit (declare (ignore ,@gensym-list)) at the start.
20:20:18
aeth
It might be useful for certain advanced macros that might do actions on otherwise-ignored things, where it could instead do (declare (ignorable ,@gensym-list)) instead.
20:20:55
aeth
(i.e. it's not used in the user code, and it may or may not trigger the macro processing that uses it in the macro's code)
20:30:00
VincentVega
aeth: I see what you mean. I don't have macro code needing that yet, but i will keep this possibilityin mind!
20:41:21
phoe
okay, tomorrow at 18:00 CET is the official premiere of this Common Lisp video. https://www.47deg.com/academy/2021-01-05-immutable-conversations-common-lisp/
21:03:00
ralt
Just putting this here, sorry if it's a bit spammy, but I think it's relevant. https://twitter.com/Crell/status/1346198039409647616
21:04:43
ralt
I don't want to be more spammy than necessary, that's a fyi, if the people lurk around in #lisp they'll see it
22:37:08
ralt
tests are still running, found this error when trying to boot sly in the meantime https://pastebin.com/0Nzw92yB
22:41:00
ralt
but I guess lisp doesn't really have the concept of "exported for a subset of other packages"
22:41:41
ralt
that would be something I'd use quite often, given that I use package-inferred systems
22:59:02
Krystof
the two tests that fail are things that might invoke compilers or linkers -- maybe they need adjusting for musl somehow?
23:10:44
fe[nl]ix
ralt: it seems that the feature test tools-for-build/os-provides-dlopen-test.c fails somehow
23:22:26
etimmons
ralt: I helped get the musl support merged back in 2.0.5. and have been using it successfully since
23:23:22
etimmons
But I haven't run the full test suite on musl in a while (currently doing that). Wouldn't surprise me if it's a bug in the test
23:23:48
ralt
I'm playing with it to generate a static binary, a bit unsuccessfully so far, but linkers are finicky beasts :)
23:24:10
etimmons
Coincidentally I also have a set of patches to make static executables with musl. I sent some early versions to sbcl-devel a while back, but they didn't get traction
23:25:01
etimmons
I was literally in the middle of doing a little writeup on how to actually make a static executable when I paged over here and saw the discussion
23:26:55
etimmons
There are really two ways to do it. There's supposedly a way to do it with the static shrinkwrapping recipe in the SBCL repo, but that does some low level assembly stuff and currently only works on amd64.
23:27:49
etimmons
I have also yet to get a good explanation from Doug Katzman on how to get rid of the requirement on libdl with that route (but it seems he/Google has a way)
23:29:07
etimmons
The second route is with my patches. They should work on any arch, but require two compilations of your code: one with a dynamic SBCL to record the needed foreign symbols, and then one with a static SBCL to dump the final executable
23:33:47
etimmons
Yes, I'm aware of that. I had some nasty recipes in the past that used that as a starting point.
23:34:53
etimmons
The issue is SBCL's linkage table. It records all the C addresses of the foreign symbols and uses dlopen/dlsym at runtime to populate it.
23:35:34
etimmons
I'm sure you could get the symbols needed for SBCL's runtime from sbcl.o, but that won't tell you what user code needs (if it uses CFFI)
23:38:03
etimmons
The shrinkwrapping recipe rewrites a core so that the system's dynamic linker populates the linkage table for SBCL at runtime. My set of patches instead generates a C file that needs to be compiled into the core. That's how I get away with doing this knowing ~zero assembly
23:39:57
ralt
phoe: what's "multi images"? https://mobile.twitter.com/peterseibel/status/1346226308506796034
23:42:27
etimmons
ralt: shameless self plug; if you're into Docker I maintain a set of Docker images for SBCL, including Alpine based ones. They used to be at daewok/sbcl, but I'm working with the CLF to move them to a more community owned space for longevity.
23:42:52
no-defun-allowed
Netfarm is for mostly-untrusted replicated object storage, and you do not want to use it for distributed computation. You want something more like lfarm for computing.
23:43:40
no-defun-allowed
Hey, same, the GitLab CI stuff aeth and I use uses daewok/lisp or something like that.
23:43:51
scymtym
phoe: interesting news indeed. i don't have a working twitter account, but i would suggest hyperlinking and syntax highlighting as in this example: https://techfak.de/~jmoringe/pcl-highlighting-example/12-they-called-it-lisp-for-a-reason-list-processing.html
23:46:25
no-defun-allowed
ralt: I seriously don't give a fuck, and I hope you don't act on that desire.
23:47:31
ralt
etimmons: anyway, I'm going away now, please look at your PMs, I sent you my email because I'll disconnect from irc, I really want static binaries :P
23:48:16
ralt
no-defun-allowed: by mainframe, I mean a "lisp process" that never dies, no matter what the underlying hardware does
1:24:30
fiddlerwoaroof
You have to build sbcl like this: https://github.com/fiddlerwoaroof/sbcl-workspace/blob/master/setup/build
1:25:17
fiddlerwoaroof
And then this will do the rest: https://github.com/fiddlerwoaroof/daydreamer/blob/master/build.lisp
1:26:00
fiddlerwoaroof
The only problem is that certain libraries insist on causing problems here: I go out of my way to avoid depending on osicat because of this
1:26:42
fiddlerwoaroof
Or, patch it something like this: https://gitlab.com/fiddlerwoaroof/osicat/-/commit/b56f924c5dafa92e6da1f2a91a6b7f133cbd69fa
3:54:50
fiddlerwoaroof
It sounds like a defconstant is being evaluated/compiled twice with values that aren't EQL
3:56:15
charles`
Yes it says constant NAME is being redefined from "string" to "string". I know it happens when I try to reevaluate the defconstant, but It sometimes happens after I restart the image
3:59:10
fiddlerwoaroof
It sounds like your startup sequence is evaluating a defconstant twice, but you aren't really providing enough context