IRC channel logs

2022-11-18.log

back to list of logs

<flatwhatson>guile-next might be on 3.0.7, but it's useful in combination with package transforms, eg. guix shell guile-next --with-branch=guile-next=main
<old>why is guile-next on 3.0.7 btw? Should it not be 3.0.9?
<dirtcastle>is guile fast?
<old>define fast
<spk121>dirtcastle: no, but it isn't slow either
<spk121>ACTION has an idea for FOSDEM minimalistic, but, wonders if it is too ridiculous
<flatwhatson>hi, we've got an interesting performance bug with popen (and potential fix): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59321
<ArneBab>spk121: do you want to share your idea?
<ArneBab>dirtcastle: depending on the task, guile can be a good deal faster than Python (i.e. math with huge numbers) or slower (string manipulation from files which is Python is directly handed off to C-code). Guile is among the faster Schemes, but performance of Schemes varies strongly by task. See https://ecraven.github.io/r7rs-benchmarks/
<ArneBab>To give an idea to gauge those numbers in comparison to other programming languages: In the middle 50% of tests (inter-quartile-range, IQR) Racket is on average 5-10x slower than C while Python is 20-200x slower than C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html
<spk121>ArneBab: the idea is to basically build a (ultra-portable) shell, scripting language, and coreutils using only what's in the official C standard library. Unlike GNU libc, the C standard's library is very very minimal
<flatwhatson>won't you need POSIX (or equivalent)? so at least some super minimal libc to interact with the kernel?
<flatwhatson>and then when you start porting across different kernels, you start go grow a new libc...
<spk121>flatwhatson: Well, to put it another way. Standard libc's only hooks to the OS are fopen etc, getenv/setenv and system(). The idea would be to explore what work can still be done that is all you've got to interact with the OS.
<flatwhatson>ok, that makes more sense :)
<flatwhatson>if you go with C11, you would even have threads, mutexes, condvars, and atomics!
<ArneBab>spk121: You could also see whether you can retarget Gash to run on MES: https://savannah.nongnu.org/projects/gash/ https://www.gnu.org/software/mes/
<ArneBab>That would give you a shell with a minimal source bootstrapping path.
<janneke>ArneBab: samplet and I will be working on that, the coming year
<ArneBab>nice!
<dsmith-work>Happy Friday, Guilers!!
<dsmith-work>Are there any C11 compilers/libs that actually implement the threads stuff?
<spk121_>dsmith-work: new gnu libc has ISO C threads
<spk121>musl libc: no. Cygwin's newlib: no. Microsoft's UCRT: no. Gnulib has an ISO C thread wrapper for posix threads and Win32 threads
<old>Pthread rule
<dsmith-work>spk121: Interesting, I thought they all just used posix threads.
<dsmith-work>Prob just a wrapper over pthreads..
<haugh>Is there any consensus on JSON? I've found guile-json and guile-sjson, and I've seen some references in mailing lists to (ice-9 json). Anything else I should be aware of?
<yosik>SRFI 180? https://srfi.schemers.org/srfi-180/
<dthompson>haugh: I wrote the (ice-9 json) patch but it was never accepted. guile-json is the thing to use. I think it should eventually become part of guile.
<dthompson>at the time I didn't want to use vectors for representing json arrays because it's not as convenient for serialization, but as time has passed I can see that it wasn't the right call.
<dthompson>so yeah just use guile-json :)
<old>I concur
<haugh>Okay, the timeline makes more sense now, thanks. I noticed that guile-json doesn't export a fold procedure like the SXML-esque approaches. Is there anywhere I can read more about that or about authoritative discussion about choosing an "official" module?
<haugh>Thanks for your work :)
<dthompson>I don't know of anything. it's just become clear that guile-json is the preferred choice. even guix uses it!
<haugh>All the cool kids, you say?
<dthompson>exactly
<dsmith-work>Wasn't there something about how best to map json objects? Hashes? Alists?
<dthompson>could be! I haven't looked at that stuff in a long time
<darth-cheney>hey all, geiser/guile/emacs question:
<darth-cheney>sometimes I switch to scheme to run some commands that return alists, which I then would like to use in elisp. Is there some way to easily get the output of a procedure in the repl to get printed into a non-repl buffer?
<darth-cheney>(think here of JSON responses to api requests etc)
<darth-cheney>Or, as an alternative, is there some emacs-lisp way to execute some scheme, and get the result as a string
<ArneBab>I just did a comparison of the R7RS benchmarks for Guile 2.2 and Guile 3.0.7+(branch next). Geometric mean of the slowdown compared against the faster: Guile 2.2: 1.975 — Guile 3-next: 1.056 — read1 and string are factor 1.5 slower, sum1 and pi are factor 2 slower, ctak is factor 1.0.8 slower, all others are faster in 3-next by up to factor 6.3 (tak).
<ArneBab>TLDR: Guile 3 is 2x as fast as Guile 2.
<old>ArneBab: What if you set GUILE_JIT_THRESHOLD=-1 ?
<ArneBab>old: that will take a while to test :-) which version? 3?
<old>Yes
<old>I wonder what is the speed factor associated with the JIT
<old>Did guile-2 had a JIT?
<dsmith-work>old: According to NEWS file the jit was added 2.2 -> 3.0
<ArneBab>ah, damn, I had an old version
<ArneBab>⇒ master → main
<ArneBab>run it again
<ArneBab>git checkout main; make clean; timeout 300 make ; nice make -j4
<ArneBab>… intersperse ./autogen.sh …
<dsmith-work>ArneBab: I sometime do a "git clean -dxf" in there too
<old>Got the same suprise last day when I say that all that time I was looking at code from 2021 on master ..
<old>s/say/saw