IRC channel logs

<mwette>Ah. OK. So doc strips off leading space. Thanks, rlb.

<mwette>debugging (gensym) is unpleasant w/ #{ g123}#, so switched to (gensym "x") for now

<sneek>wb dsmith :D

<dsmith>sneek, botsnack!

<rlb>v3.0.11 passed make check just fine on the riscv64 porterbox in a sid chroot, so "it's probably not upstream" at least.

<rlb>Oh, I misunderstood the problem. It's not guile itself that's having trouble, it's debian's shepard and guile-fibers, I think: https://qa.debian.org/excuses.php?package=guile-3.0

<ArneBab>rlb: since (afaik) shepherd uses fibers, this points to fibers.

<rlb>yeah, fibers' tests themselves segfault all over the place on debian riscv64 when the package build runs them.

<rlb>I'll see about a test with --enable-jit=no.

<dsmith>rlb, Was just about to ask what would make riscv special about fibers? But jit. Yeah

<rlb>iirc we added jit for riscv64 in 11, so plausible candidate I suppose.

<rlb>I'm hoping that a ./configure --enable-jit=no in an already built tree will "work" (well enough) so I don't have to wait another N hours :)

<rlb>about to find out

<dsmith>Yeah, that can be tedious

<rlb>Guile itself is fine with the jit enabled, so I assume some nontrivial subset of it is fine.

<rlb>i.e. guile (of course) builds and passes all its own tests (or there'd be no package in the first place)

<rlb>Hmm, perhaps double-check; is there an easy to to detect when the jit is enabled for the current guile...

<rlb>guess if nothing else I can set GUILE_JIT_LOG and see if anything happens :)

<rlb>that works

<rlb>...taking more than a half hour just to *re*-run ./configure (i.e. with caching); wonder how qemu on my fastest machine would compare (assuming the riscv64 support's good enough).

<ArneBab>rlb: maybe there’s a problem in epoll.c or one of the other C files?

<ArneBab>do they actually support riscv64?

<rlb>I don't know that fibers has changed at all, currently believe that it's just 3.0.10 -> 3.0.11 (where I also enabled the JIT on riscv64) that's the likely culprit.

<rlb>And as far as I know debian may be the first place fibers has been tried on riscv64?

<rlb>Guessing maybe it exercises something JIT related that the guile test suite doesn't.

<rlb>(fibers does)

<rlb>Anyone know offhand if there's a preferred way to get fibers to run against a specific guile? If not, I'll just use a PATH/LD_LIBRARY_PATH/... wrapper.

<johnwcowan>when I was first mrssing with Guile I bulit it frim source. 10 hiurs later....

<ArneBab>rlb: you may be able to use ./configure GUILE=path/to/guile/meta/guile -- same for GUILD

<rlb>Oh, I just forgot for a minute --- can first just try meta/uninstalled-guile-env

<dsmith>For playing around with risc-v, I wonder if this is performant enough: https://pine64.com/product/star64-model-a-4gb-single-board-computer/

<rlb>no idea -- all I know atm is that some of the debian buildds can build guile in 2h, and some take 7+, so there's a lot of variance.

<rlb>there's also the framework compatible one: https://frame.work/de/en/products/deep-computing-risc-v-mainboard

<rlb>debian lists some others too: https://wiki.debian.org/RISC-V

<ArneBab>rlb: 2h vs. 7h sounds like more than the effect of the jit (that provides roughly factor 2-3 speedup)

<ArneBab>though it may be more effective with compilation (2-3x is from the r7rs benchmarks ⇒ https://www.draketo.de/software/guile-fast#benchmarking-guile-r7rs )

<rlb>I think for debian it's likely just substantial differences between the riscv64 buildds: https://buildd.debian.org/status/logs.php?pkg=guile-3.0&arch=riscv64

<rlb>i.e. the times have been all over the place for "years"

<rlb>Though hmm, I guess all the post 3.0.7 times are "high"...

<rlb>interesting

<rlb>but also maybe all the faster ones were "rv-mullvad-*"

<rlb>(which don't appear anymore)

<rlb>anyway, not important

IRC channel logs

2026-01-30.log