IRC channel logs

<jab>so apparently spacemacs has a weird bug, which makes geiser mode not work at the moment.

<jab>It's really annoying doing guile programming without geiser.

<humm>jedb: environment variable or command line option

<jedb>humm: there are no environment variables I can find, and the only place a command line option would work is when invoking guild directly, which then has the problem of being unable to load in other files in the same way you would pass -l to guile

<humm>jedb: (guile) 4.2.2 Environment Variables

<humm>invoking guild directly? wdym? it’s guile that’s autocompiling, not just guild

<humm>and guile has a command line option to disable autocompilation

<jedb> https://www.gnu.org/software/guile/manual/html_node/Environment-Variables.html there are no environment variables that affect optimisation level

<jedb>and yes it's guile that's autocompiling, but if you rely on that then how do you control the optimisation level?

<humm>I apologize, I utterly misread the question

<rlb>jedb: I'm not sure I follow the details, but if you can make the adjustments you need on the guild command line, then perhaps you could create a wrapper guild that shadows the real one in your PATH?

<old>anything that guaranteed ordering traversal of hash-table ?

<rlb>old: for regular hash-tables? I think the ordering of say hash-for-each is explicitly unspecified.

<rlb>Also unspecified what happens if you modify the table during traversals.

<johnwcowan>but srfi 250 should rjn fine on Guile

<johnwcowan>old: ™^

<old>johnwcowan: oh that's fresh

<old>rlb: but given an insertion of item in H, the the ordering should be the same if I do the exact same thing again no?

<johnwcowan>yes, updates to existing associatons don't change the ordering

<jab>I feel like we should have a lisp systems language. Do ya'll think that there should be a systems lisp language? And if it existed, could it be better than zig / rust ?

<rlb>old: unless that's specified, I'd assume it's not, i.e. might change in some release?

<rlb>jab: there have been related efforts, e.g. https://prescheme.org/

<humm>has anyone heard of the prescheme person this last year?

<jab>does prescheme work on 64 bits yet ?

<rlb>Hmm, I don't think there's been a lot of public activity with respect to the restoration for a while. I just meant it as a potential example of the kind of thing you suggested.

<rlb>(precedent)

<mwette>I am making progress on guile-freezer which is a prototype script to bind a main program with libguile and all needed .go's into a single binary. If you have use-case for such a script, please let me know here: https://github.com/mwette/guile-freezer/issues/6

<mwette>ArneBab: for the above i have a small, 3 line patch for libguile/init.c

<mwette>i lied, it's a little more: https://paste.centos.org/view/4292c879

<old>humm: the person who's working on pre-scheme has been offline for a 1 year now. Nobody was able to reach him

<humm>sad

<ArneBab>mwette: that would be pretty useful for games.

<ArneBab>mwette: I got guix pack --format=appimage working for a chickadee game, but it’s 500 MiB, because it includes all of LLVM, GCC, MESA, and two Python implementations.

<ArneBab>An appimage works kind of like a generalized binary that also includes data. But the binary is much too big for small games.

<ArneBab>mwette: Also a compiled Guile is 55 MiB of go files. Getting that down to the 5 MiB or so of *go files I actually use would be really useful.

<mwette>My script only pulls in modules that are referenced. For a trivial script that only uses (ice-9 format) I ended up pulling in about 20 modules. That part is about 3.5 meg of .go files, though libguile is about 25 meg.

<ArneBab>mwette: 500 MiB bandwidth cost about 5 cent on AWS (other solutions have similar cost), so for a demo or free software (anything that does not cost at least a few dollars to get to a download), that makes a big difference.

<mwette>here is a list of modules pulled in: https://paste.centos.org/view/1b814ed5

<rlb>mwette: 25mb for the .so?

<rlb>(I imagine don't mean libguile*.so --- here mine'

<rlb>s 1.3mb)

<rlb>"I imagine you don't mean"

<ArneBab>what does MATNG- mean?

<mwette>the .a is 24 Meg. The .so is 61 meg.

<rlb>So not a normal libguile.so?

<ArneBab>does that include the glibc or so?

<rlb>i.e. vs -rw-r--r-- 1 root root 1.3M Dec 12 21:20 /usr/lib/x86_64-linux-gnu/libguile-3.0.so.1.7.1

<mwette>In the translation I hash the directory part of the module path.

<ArneBab>mwette: that’s nice

<mwette>rlb: Currently I'm just dynamically linking. I assume static link is possible, but I had issue with it before.

<rlb>Right, but I'm wondering (if this is what you're saying) why your libguile.so is 25mb where a "normal" one is 1.3.

<mwette>here's the C code: https://paste.centos.org/view/28e6f58a

<mwette>rlb: I misread. The .so is 6.1 MB. on my system

<rlb>oh, ok -- and perhaps unstripped?

<mwette>but the .a is 24 MB. Why is that, you think?

<ArneBab>does it maybe include *.go files?

<rlb>not sure, I have -rw-r--r-- 1 root root 2.7M Dec 12 21:20 /usr/lib/x86_64-linux-gnu/libguile-3.0.a

<rlb>but check "file LIB" and see if it's unstrippe.

<rlb>"unstripped"

<rlb>(well, for the .so, not sure about the .a)

<ArneBab>I also see 1,3M, stripped.

<mwette>on my ubuntu system, /usr/lib/x86_64-.../libguile..a is 2.8 MB. That's probably stripped. Can you strip a .a?

<mwette>My original's numbers from libguile.a build by me from source.

<mwette>If I strip that 24 MB .a I get 10.9 MB. Sorry for the misleads.

<rlb>Interesting that it's still 3+x (if you mean the .a) larger than the .a here.

<ArneBab>maybe the optimization level is different?

<mwette>OK. So, the libguile size can be ~ 3 MB. The rest (i.e., the .go files) is independent of that, I think.

<mwette>I wonder if it is possible to strip the debug info out of the .go files.

<ArneBab>according to https://www.gnu.org/software/guile/manual/html_node/Object-File-Format.html that’s default debug info, so it should be possible, but I don’t know whether it’s implemented.

IRC channel logs

2026-02-14.log