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>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 <mwette>rlb: Guix System is released in binary for for i686, if that answers <rlb>mwette: certainly a useful data point -- thanks. <rlb>Wonder if that might be because the filesystem on the buildd is unusual in a way that code hasn't seen yet... <rlb>If no one beats me to it, I'll may look in to that hashing issue tomorrow if I have time. <sevan>will submit a patch when I'm done. <Arsen>they are indirectly used probably <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. <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 <rlb>OK, thanks -- guessing it's going to break 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>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> 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> 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)? <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>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) <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)