IRC channel logs

2026-06-08.log

back to list of logs

<mwette>Why this? (vhash? (alist->vhash ())) => #f
<probie>There's an interesting comment in vhash-cons https://paste.sr.ht/~probie/b10506c92cca69c08eed311a8bebb6d57aa1464f
<probie>It returns false, because an empty "vhash" is just an empty vlist, and vhash? returns false on those
<mwette>probie: thanks - I may push an issue on this
<old>mwette: I don't think we can fix that until a breaking release
<old>some code might assume the empty list to not be vhash
<mwette>old: got it. ill use vlist? for now
<optimal>old: remember that little web microframework i was talking about, i put it on codeberg https://codeberg.org/jgg/guile-selectron
<old>mwette: well feel free to open an issue so we can discuss about that on codeberg
<old>optimal: yes thank you I'm looking at it :-)
<old>happy to see you used blue. did it went well ?
<optimal>blue is fantastic
<optimal>quite possibly the best build system i've ever used, very low boiler plate but still great customizability
<optimal>i haven't used the more advanced functionality but just for saving me the trouble of having to touch autotools you deserve an award
<old>thanks :-) we are not even in alpha stage yet
<old>this is just pre-alpha
<optimal>can't wait to see what's to come, i believe blue will be to build systems what Guix is to packaging and systems
<optimal> and there's quite a lot in blue that should be upstreamed to Guile, like the fantastic backtraces
<old>yes indeed :-)
<old>I want to add the backtrace at some point yes
<old>maybe adding a little more pretty compiler error/warning outputs also
<optimal>yes, i'd also love to have the little logging library included in Guile, i could have really used it for my webframework
<optimal>i might be stuck with the silly logger in Guile-Lib for now
<optimal>frankly there's a lot of stuff both in Guix and in Blue that should be upstreamed
<old>there's one (not in core)
<old>in guile-lib
<old>ah just read that from you
<old>sorry
<old>I should read the full message before replying :-)
<optimal>:P
<old>in BLUE we use a custom logger that has nested regions
<old>you can see it: blue --log-level=trace build
<old>you should see a lots of things
<old>it's the closest I could think of for structured logging
<optimal>this is incredible holy shit
<optimal>we found it, Guile 4
<old>haha
<old>It's also "smart"
<old>try it with: blue --log-level=trace --fresh-store configure
<old>you should see the configuration progress be indented under the corresponding longing blocks
<old>if there are ones
<old>anyway, it's very much verbose, but god it is easy to fix a bug report when you have that
<old>s/longing/logging
<optimal>i don't know what's better, the logs or the code producing it
<optimal>i think if you replaced the string formatting with SRFI-166, you'd have the perfect logging framework
<optimal>ever
<old>optimal: I wish for that yes
<old>especially for the coloring
<old>I have a bunch of: (format #f (colorize "foo" (color bold))) in the code
<old>really ugly
<old>monadic format would certainly help
<old>however srfi-166 is quite large
<old>and BLUE is self-contained. So I would need to slice some part of it and embedding it in BLUE. Assuming I can do that license wise
<JohnCowan>Essentially all SRFIs are MIT
<old>so I would need to make BLUE dual-license
<old>BLUE is LGPL
<old>at least the SRFI portion would be
<JohnCowan>You can incorporate MIT code into LGPL without problem
<old>okay
<probie>Do you actually need all of srfi-166 (unless you want to expose the pretty logging to users of BLUE)?
<tusharhero>Hello, I am trying to use raylib from Guile using the instructions here: (info "(guile) Foreign Function Interface"). But it is not able to find raylib if I only specify "libraylib", I have to find the path and put that in. I have guix shell'ed both raylib and guile. How can I make Guile know where to find libraylib.so?
<old>probie: nah just a sub-set
<mwette>tusharhero: load-foreign-library accepts a search path (list of dir's IIRC). Or you can use LD_LIBRARY_PATH env var, I believe.