IRC channel logs

<rlb>wingo: brilliant, and will do, as soon as I get a minute (presume "days" if not sooner (possibly tonight)).

<rlb>I can test locally "faster" in a debvm, if I still have it -- testing via the debian buildds will be more work. Though maybe I'll just use a porterbox after that...

<rlb>wingo: ERROR: format.test: ~f fixed-point: ~2f - arguments: ((out-of-range "string-ref" "Argument 2 out of range: ~S" (18446744073709551615) (18446744073709551615)))

<rlb>That's what I see now on an i386 host. fwiw, if you have access to an x86 debian system, I can give you a trivial debvm-create command that'll build a suitable test vm.

<rlb>(and then debvm-run will of course run it)

<rlb>(also happy to run further tests if you have anything you'd like to try)

<sneek>mwette: Greetings :D

<mwette>sneek: botsnack

<sneek>:)

<amano>How long does it take to build guile 3?

<wingo>rlb: weird! fwiw i can test reasonably ok with guix (guix shell -D -f guix.scm --system=i686-linux --pure)

<wingo>yes i get that same error

<wingo>good

<wingo>oh good i get it on 64-bit as well

<wingo>apologies, i didn't run the full test suite after!

<amano>20 minutes to compile guile 3 on my machine. It's somewhat heavy....

<amano>I certainly don't want to compile guile on low-resource machines.

<wingo>amano: yeah. if you build from a tarball, that includes bootstrapped .go files which makes it faster

<amano>13 ~ 14 milliseconds to start up guile 3. Not bad. Janet startup takes 7 ~ 8 milliseconds.

<amano>Python takes 20 milliseconds.

<amano>wingo: Do you mean it can take less than 20 minutes on my system?

<wingo>amano: i mean that if you build from a tarball instead of a git checkout, it should take less than 20 minutes, yes

<amano>And, my gentoo guile package already builds from a tarball from gnu.

<wingo>interesting.

<amano>My CPU is AMD FX 8300 which is neither fast nor slow.

<amano>My gentoo guile package enables deprecated features, jit, networking, native language support, regex, and threads.

<amano>I guess FX 8300 is already outdated and slow. https://www.cpubenchmark.net/compare/1825vs5178/AMD-FX-8300-Eight-Core-vs-Intel-N200 says FX 8300 consumes 95 watts and is slightly faster than Inten N200 which consumes 6 watts.

<amano>On Intel N200, compiling guile 3 will take 20 minutes?

<wingo>i could not tell you :)

<amano>Time to earn more money and buy a new computer.

<daviid>amano: fwwi, i do not thing compiling guile, from a source cone, that would take 20min, would justify to buy another computer, ver

<amano>On my machine, building janet takes less than 40 seconds. Janet is very light.

<amano>Is it the case that my computer is slow?

<amano>Perhaps, I should build it again.

<amano>Guile build process isn't taking full advantage of all CPU cores.

<amano>Now, it is using CPU cores 100%.

<ArneBab>wingo: nice! (re 32bit fixed)

<amano>Compiling guile 3 again with AMD FX 8300 CPU took 19 minutes.

<amano>It's basically the same...

<amano>I guess my CPU is just slow.

<daviid>amano: 19min is perfectly ok

<amano>I wanted something like 2 minutes.

<amano>I heard scheme is minimal?

<amano>Compiliing rakudo takes 7 minutes 12 seconds. Rakudo isn't small.

<amano>I mean compiling rakudo, moarvm, and nqp takes 7 minutes and 12 seconds.

<daviid>amano: we do not care

<amano>I guess guile isn't so small.

<amano>Does guile have good libraries for GUI and TUI?

<wingo>rlb: fixed

<dpk>amano: if you want a ‘small’ Scheme implementation which isn’t so slow to compile, maybe try Chibi Scheme

<dpk>although i have no idea why compilation time for the implementation itself is really that big of a deal to anyone who isn’t hacking the implementation themselves

<lloda>FAIL: bit-operations.test: bit-extract: documented?

<lloda>bit-extract does have doc tho (?)

<amano>dpk: After compilation, guile scheme is okay for scripts that require fast startup time.

<amano>It starts up faster than python and raku and ruby.

<wingo>lloda: yeah. in a clean build somehow guile-procedures.txt isn't generated by the time that test runs

<lloda>i c

<amano>Is guile designed to handle non-code resource files in load paths?

<amano>Things like images.

<dpk>‘handle’ in what way?

<dpk>you are asking very strange questions

<amano>I want to get the path to resource files that come with guile libraries and guile applications.

<amano>Can the paths be found during compilation and put into compiled guile modules?

<amano>Or, are the paths found only during runtime?

<amano>Or, are resources inserted into compiled guile modules?

<amano>dpk: ^^

<amano>All I can find for resource handling is search-path, %search-load-path, and search-in-load-path.

<amano>Those are runtime resource finders.

<amano>Not compile-time resource path finders.

<amano>I mean %search-load-path would be the only function that seems to make sense.

<amano>Is %search-load-path the way to find the path to non-code resource files in guile modules?

<freakingpenguin>I notice in Geiser Guile that the function geiser-guile-debug-menu does nothing in *Geiser Debug*. Is there some setup that needs to be done to use the debugging capabilities?

<freakingpenguin>Ah, there's a #geiser channel. Apologies.

<haugh>ArneBab, nice work on getting 234 across the finish line. I'm a fan of the multi-value/quasi-boolean error handling. Was that you? It's very composable, though I imagine a Guile implementation would try to take advantage of our exceptions.

<cpli>does `png-image-data` in guile-png return the rgba pixel values of an image?

<ArneBab>haugh: that was me, though it wasn’t my first version (this went through many iterations: the last step was adding a single value and an always-multiple-value version, because Chez cannot treat multi-value as single-value)

<ArneBab>haugh: the first version used exceptions with additional information, but people didn’t like that

<ArneBab>haugh: and thank you ☺

<ArneBab>haugh: my main reason for wanting the multi-value version is that a graph algorithm will often already have information about the error when it hits an error, so I can avoid some re-calculation.

<rlb>wingo: great - I'll test again, likely tonight, and if everything passes here, I'll probably shift to undoing the debian unstable downgrade.

<rlb>lloda: that rings a bell, I thought maybe I'd fixed that in main.

<rlb>(...or is that patch still pending for review? I'll look later.)

<rlb>i.e. there were some ordering problems with full "make -j 11 check" from a clean tree that I tried to address recently.

<rlb>(but only in main)

<rlb>Oh, no, both looks like my patch(es) are still pending, and Andy may also have done something. I'll try rebasing and investigate later.

<rlb>lloda: was that the relevant context? i.e. parallel (or maybe not even) "make check" from a clean tree?

<lloda>rlb: dirty build tree from a couple commits before, make clean + make check

<lloda>not parallel

<rlb>OK, thanks. Will have to see what the rebase says about my patch vs the current arrangement.

<cpli>what environment variable changes would allow me to load my guix installed guile modules?

<cpli>why is compiling image.scm failing with "no code for module (scheme documentation)"?

<cpli>i'm kinda desperate now, i can't figure out why (scheme documentation) is even imported..

<cpli>or what it is

<cpli>guile-lib was necessary

<haugh>arnebab, I hate navigating the SRFI archive! Do you happen to remember approximately when the scuffle over exceptions went down?

<haugh>I didn't know extraneous values was unspecified behavior. That explains a LOT.

<haugh>Oh I found the thread, nevermind.

<cpli>haugh: post link to thread owo

<haugh>cpli of course how rude of me https://srfi-email.schemers.org/srfi-234/msg/20488660/

IRC channel logs

2024-09-26.log