IRC channel logs

<TheTaoOfSu>I'm trying to use a library from Akku, (srfi 106), and I'm running into problems when I try to import it because it can't find any code for (srfi srfi-106), which is notably *not* (srfi 106). Is Guile attempting some sort of automatic conversion I can prevent somehow?

<TheTaoOfSu>I have another library from Akku, (chibi url), that seems to be working just fine since I saw lines about compiling something for that before it errored on (srfi 106)

<TheTaoOfSu>This is on Guix System, so I dunno if that may be interfering with anything, but it doesn't seem likely

<old>TheTaoOfSu: there's ongoing issues/PRs fixing this IIRC

<TheTaoOfSu>old: so this is a bug with Guile that I'm just going to have to work around for a little while?

<TheTaoOfSu>*Is* there a known workaround?

<old>but indeed, Guile does some kind of auto-write of (srfi 106) to (srfi srfi-106)

<old>hm

<old>well you can't do: (use-modules (srfi 106))

<old>and (resolve-module '(srfi 106)) failed because it expect a symbol (srfi-106) in the cdr

<old>same for (library (srfi 106))

<TheTaoOfSu>I'm trying to (import (srfi 106)), and that doesn't work

<old>but (import (srfi 106)) works but you need to make a symlink: srfi/srfi-106.scm -> srfi/106.scm

<TheTaoOfSu>lol of course, I should have thought of that

<old>I will try to find a way to fix this

<old>tho, I don't really get why Guile is doing that in the first place

<old>and I am not very familiar with all of the rnrs conventions

<old>please feel free to participate in the discussion on Codeberg

<TheTaoOfSu>God, Akku takes SO long to solve dependencies, it's kinda ridiculous. There aren't that many packages in the whole repo

<TheTaoOfSu>...why can it not find (chibi uri) now... I removed Akku to try Snow, but that doesn't support Guile, and now it's getting caught up on trying to import (chibi uri) before it even gets to (srfi 106) despite the fact that it was working fine before

<ArneBab>ieure: to be fair, datetime is hard. Mantatory xkcd ☺: https://xkcd.com/2867/

<TheTaoOfSu>What might make loading a library fail to find a corresponding file? (import (chibi uri)) successfully pulls uri.sld, but when that tries to (include "uri.scm"), that's failing

<TheTaoOfSu>...I have to run guile from .akku/lib so it can find the file. But then it compiles

<TheTaoOfSu>Okay, with that resolved, I can test old's idea and confirm that a simple symlink will resolve it for now

<old>TheTaoOfSu: include is broken. I fixed this on the main branch

<old>you can replace it with `include-from-path`

<old>and ensure that the directoy contains the file is in the load path

<TheTaoOfSu>old: someone in #scheme pointed out your work. Unfortunately, not live on Guix yet, but I did find I can work around it until then by just building from .akku/lib for now

<TheTaoOfSu>My thanks for fixing that because it's annoying and wasted a bunch of my time trying to figure out what was going wrong

<JohnCowan> hŵ

<JohnCowan>Akku supports both r6 and r7 systems, the simplest difference being that r6 systems don't support integers in library names and r7 systems do. Therefore r7 systems use (srfi 1), whereas most r6 systems use (srfi :1) by convention. Guile however uses (srfi srfi-1) instead.

<civodul>quizz: if you call ‘primitive-fork’ and then ‘exec’ in the child, is there a possibility for the child to receive SIGPWR after exec?

<civodul>(SIGPWR is used by libgc)

<graywolf>IIUC there is effectively a ban on adding new exported symbols into the (guile) module. If that is so, where should I put new time symbols (tm: and friends) I want to add?

<rlb>graywolf: not sure --- and perhaps a ban, but at least a fairly high bar, I think. What are the bindings?

<old>civodul: I would say if there is a bug in libgc yes

<old>but libgc has phtread_atfork hook

<old>also: • The dispositions of any signals that are being caught are reset to the default (signal(7)).

<old>that is for execve

<old>so really, I don't see how that's possible other than a bug in libgc

<graywolf>rlb: I realize two fundamental procedures are missing, one to convert broken time to unix time while respecting tm:gmtoff, and one to return same time point in a different timezone.

<graywolf>realized* ; working names tm:unix and time-in-timezone

<graywolf>I guess I could stuff them into (ice-9 time)?

<civodul>graywolf: maybe srfi-19 is a better fit?

<graywolf>We could make (srfi srfi-19 gnu), but it feels wrong to make procedures working on (guile)'s localtime in srfi-19 namespace..

<rlb>If they don't cross the bar for (guile), then I suppose (ice-9 time) might be plausible. Or srfi-19 gnu, but I might be more comfortable with the latter if what you need could be handled as natural (gnu) extensions there, and we wanted to nudge people that way.

<rlb>I don't understand the situation/background well enough atm to have any strong or well-founded opinion.

<rlb>I could also see deciding to duplicate most/all of the contents of (guile) in some other modules, so that someday we could provide a more minimal opt-in "core" module, and then you'd get everything else you want, selectively, from those other modules. In that world, we might need a new "time" module (or broader posix module, or...), and perhaps not (ice-9 time) if we didn't want that module to suddenly start exporting a lot of new

<rlb>bindings. Dunno.

IRC channel logs

2026-09-05.log