IRC channel logs

2024-06-30.log

back to list of logs

<rlb>guile-3.0 3.0.10-1 uploaded to debian unstable.
<mwette>woo hoo, cool
<mwette>So, within module, if there is a top-level form (define foo #f) and later (set! foo 1) is that module still (for all practical purposes) declarative?
<mwette>^ assuming foo is never set! again
<rlb>wingo, civodul: do we test on i386 (i686) anywhere (aside from debian) you know of? Asking because compilation ust crashed there (I'll delve later): https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=i386&ver=3.0.10-1&stamp=1719703034&raw=0
<mwette>rlb: Guix System is released in binary for for i686, if that answers
<mwette>s/for for/form for/
<rlb>mwette: certainly a useful data point -- thanks.
<rlb>Looks like there's also a SEEK_DATA related failure in ports.test on ppc64el: https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=ppc64el&ver=3.0.10-1&stamp=1719704143&raw=0
<rlb>Wonder if that might be because the filesystem on the buildd is unusual in a way that code hasn't seen yet...
<rlb>wingo: yeah, we have three architectures (so far) failing for 3.0.10 in jenkis-lookup3-hashword2 "u64...", and I think they might all be 32-bit (suspicious, but not sure it's relevant): https://buildd.debian.org/status/package.php?p=guile%2d3%2e0
<rlb>wingo: debian does still carry one 32-bit (big-endian) specific patch fwiw: https://salsa.debian.org/rlb/deb-guile/-/commit/d9b26d69ee6cf695ca67bb8d23f31d1eb8d39796
<rlb>If no one beats me to it, I'll may look in to that hashing issue tomorrow if I have time.
<sneek>Yey! dsmith is back!
<dsmith>sneek, botsnack
<sneek>:)
<sevan>been poking at the autotools infra of guile. This commit introduced a few modules from gnulib which seem to not be used in the autoconf infra. Specifically the gettext related parts but others too. https://git.savannah.gnu.org/cgit/guile.git/patch/?id=edfca3b7e5931b5b5a83112e2a9813b068be99c2
<sevan>will submit a patch when I'm done.
<Arsen>they are indirectly used probably
<Arsen>don't forget to check that
<sevan>Arsen: I'm using 'gnulib-tool --add-import' which re-applies what's in m4/gnulib-cache.m4
<sevan>delete the contents of lib & m4 directories, restore m4/gnulib-cache.m4 and run 'gnulib-tool --add-import', the gettext files are not handled. They're also missing from the 3.0.10 release
<rlb>If anyone working from an existing clone sees a failure in bit-operations.text, that's due to a dangling ./guile-procedures.txt file. Just rm it.
<rlb>wingo: wonder if we might want to add that to clean-local for now.
<ArneBab>elb: hg.sr.ht still provides Mercurial hosting.
<ArneBab>rlb: also https://foss.heptapod.net/ and https://savannah.gnu.org/
<ArneBab>rlb: sorry, that was for elb
<rlb>:)
<rlb>Hopefully fixed some issues with 3.0.10 (specifically building/testing from existing or clean clone). If anyone familiar with automake has time to take a look, that'd be much appreciated (top two commits here): https://codeberg.org/rlb/guile/commits/branch/proposed
<rlb>Without the top one, make check will fail in a clean tree, for example, but wanted to make sure the fixes are appropriate.
<rlb>also, wingo civodul ^
<rlb>mwette: has guix built 3.0.10 for i686 successfully yet?
<rlb>ACTION just realized he'd assumed
<mwette> rlb: no idea
<rlb>OK, thanks -- guessing it's going to break too
<mwette>me too
<rlb>I'm looking in to it now. Offhand, feel like a 32-bit, possibly signed/unsigned issue with the hashing or logand changes since 3.0.10, but that's just a medium wild guess as yet.
<rlb>"feels like"
<rlb>I *can* reproduce it easily on a debian i386 porterbox -- currently moving to a local debvm so it'll be easier to investigate.
<rlb>wingo civodul: do we test all the "relevant" architectures before a release somewhere? If not, maybe for the next release, I should consider trying to upload to debian experimental as the relaese approaches, which should vet things fairly well.
<rlb>(i.e. run it through the debian buildds via experimental)
<rlb>Found/fixed one 32-bit problem (I introduced) in test-hashing.c.
<rlb>wingo: the "real" crash (compiling reify-primitives.go) is in jenkins-lookup3-hashword2, and I can see that if I mess with the final "b" let binding to print the value and then return it, the crash is avoided. The crash is a range error (not sure from where yet).
<rlb>All we see is:
<rlb> In language/cps/guile-vm.scm:
<rlb> 111:31 2 (target-symbol-hash _)
<rlb> 45:18 1 (jenkins-lookup3-hashword2 "u64-imm-<")
<rlb> In ice-9/boot-9.scm:
<rlb> 1676:22 0 (raise-exception _ #:continuable? _)
<rlb>
<rlb> ice-9/boot-9.scm:1676:22: In procedure raise-exception:
<rlb> Value out of range 0 to< 18446744073709551615: -505802029
<rlb>ACTION needs to set this aside for now -- 3.0.10 will be blocked wrt debian unstable until I can get it sorted.
<ArneBab>Did you see my message about benchmarking guille 3.0.10 vs. 3.0.9 and 3.0.8? ⇒ about 3% faster in geometric mean.
<rlb>I haven't. And I forget, were you one of the people who also tried the proposed utf8 conversion (iirc that helped too)?
<ArneBab>I didn’t try, no
<ArneBab>I now documented my benchmarking method pretty briefly (as a code-block you can just throw into bash in a Guix system): https://www.draketo.de/software/shell-tricks#benchmarking-guile-versions
<rlb>Oh, now I see the mail. Wonder about having an in-tree (or not) utility script that can (easily) compare two commits. Say some test/compare-perf HASH HASH that would run "some tests" and maybe even optional produce some simple graphs. i.e. make it easy to do at least some evaluation of the impact of a change.
<ArneBab>Feel free to steal my code ☺
<ArneBab>you may need to ask ecraven about their parts (I just clone r7rs …).
<ArneBab>But you may want to tune the tests to take less time. Currently they run quite long, because they must run long enough for sensible statistics on every scheme — including ones which happen to be perfect for the given test.
<ArneBab>Also we’ll need to run these multiple times to actually have sane statistics (at least a robust standard deviation would be nice)
<ArneBab>that’s why I just started a new run. Maybe I should tune these to run each version 10x so I can improve the benchmarking to actually provide uncertainty bounds.
<mwette>rlb: I ran my ffi-helper tool with your utf-8 branch and it reduced runtime 20%, which is huge.
<mwette>rlb: any plan to sync your utf-8 branch on codeberg to 3.0.10?
<mwette>Rather, I mean the other way: merge 3.0.10 into your utf-8 branch.
<rlb>mwette: it's pretty close atm, but yeah, I was planning to rebase it when I got side-tracked by these build failures.
<rlb>(i.e. wanted to get 3.0.10 into debian first)
<mwette>got it -- thanks
<rlb>By pretty-close, I mean I rebased recently.
<rlb>And thanks for the reminder wrt perf :)
<rlb>...but now I'm a little nervous there too wrt 32-bit. i.e. did I make any mistakes without knowing it.
<rlb>I'll want to try testing that in the i386 debvm once the rest is sorted.
<rlb>At the moment, it *looks* like main make check has been broken wrt i386 for a long time.
<rlb>(if nothing else, because of my oversight when I added test-hashing)
<rlb>s/i386/32-bit/
<rlb>I suspect