IRC channel logs
2025-12-14.log
back to list of logs
<old>I will post the patch on codeberg <old>it worked with older guile because the reader was not read-syntax <old>now the default reader for Scheme is read-syntax, which return a syntax object. So we need to check for identifier? also instead of just symbol? like old reader did <old>oh I need to learn how to make PR now <old>ArneBab: I would like to add tests for the fix <old>but I don't find any tests for meta command of the RPEL <old>REPL. Maybe you have an idea? <rlb>...imagine you figured it out, but typically, just create a fork of guile in your account, then create a branch with the fix there, and from that branch, I think there'll be a "pr" button (not logged in atm to check). <rlb>Looks like debian release archs for 3.0.11 are all good now -- thought it was going to be a lot longer for riscv64 because gcc and llvm builds were running, and gcc for example appears to take 5+ days atm. Must have enough buildds to bypass them. <rlb>dsmith: I noticed gcc was building for riscv64 while guile was waiting, and looks like that typically takes 5+ days right now. <ArneBab>old: I don’t know whether we have tests for those commands. To maybe find them: break the then run make check? <ArneBab>rlb: did the problems for GNU Cash with 3.0.11 already get fixed by now? <ArneBab>old: there’s currently a difference between the output of ,d + and ,d const: for + we get - Scheme Procedure: + [x [y . rest]] ... , for ,d const we get only the description. Does that come from different snarfing of the documentation? <ArneBab>(so no problem of your code, but of documentation?) <ArneBab>old: that’s a really neat fix by the way (⇒ putting in .guile) <ArneBab>It feels we should now document a lot more. ,d let # ,d define #f … <old>I can't compile guile entirely hm <old>so I can't run the tests <old>make[3]: *** No rule to make target 'guile-tools.1', needed by 'all-am'. Stop. <ArneBab>just found that when srfi tests fail, make check does not fail. <old>ArneBab: you ge the same behavior with ,d string-append <old>these are defined in C and the documentation that is generated has the header Scheme Procedure: I think <old>for Scheme procedure you have do to it yourself .. <mwette>ArneBab: I saw email but my client lost it. Anyhow, nyacc was set up from start to be able to imple <mwette>implement parsers in other lang's. I created a parser engine in python and simple lex. In grammar one uses `($$/ref 'ref-token code ...)' for actions and then use array of python functions to implement actions. <mwette>The parse-engine in python is 40 lines of code. <dsmith>old, rlb recently added some man pages. Sounds like some auto* tools magic needed <janus>'unknown location: unexpected syntax in form ()' <janus>how do you debug stuff like this? just manually binary search <janus>i don't know why the location is unknown, since if happens before execution, it should be even closer to the shape that the source has in my editor <janus>would make more sense if the location were unknown after syntax expansion (or whatever the right terminology is?) <janus>oooh i know, it is because of the missing tick <janus>should have been an empty list '() <rlb>old: hmm, yeah, I likely broke that --- doc/guile-tools.1 should just be a symlink to doc guild.1, but since guild.1 is autogenerated, it's a dangling symlink until the first build. That worked fine here, even via a distcheck, but I wondered if it was still perhaps "too clever". <rlb>Does a reconfigure (or just touching configure.ac and re-running make) fix it? <rlb>(The guild manpage has both NAMEs.) <rlb>Since my impression (and vage recollection) was that guile-tools was effectively just an older name for guild. <rlb>ArneBab: I believe mwette figured out the gnucash issue --- it's the srfi-64 overhaul, though it wasn't entirely clear whether our implementation was "wrong", or still within the spec. In any case, there's an easy workaround. <ArneBab>old: re make: did you make clean and autoreconf -i ; ./configure? -- my command for a full rebuild is guix shell -D guile gperf sed guile -- bash -c 'make clean; ./configure CFLAGS="-g -O2 -march=native -Werror=array-bounds -flto -ffat-lto-objects"; make -j6; make check' <ArneBab>rlb: so is there something still broken? Or is 3.0.11 ok as is? <rlb>However, looks like that information never made it out of #guile... I'll fix that. <rlb>No, for now, they'll need to make a small change. <ArneBab>Do they know already? (is there a patch or PR?) <rlb>And we'll also probably want to make a change for .12, but if I'm remembering the fix right, their code is probably "questionable" to begin with, i.e. I think the case was effectively (test-group "name") i.e. a test-group form with no body at all. <rlb>ArneBab: there's nothing yet, other than the irc discussion from a week or so ago. <rlb>I believe the plan was for someone to ping the srfi-62 author about it first, and of course we should reply to the list --- I'll do both. <rlb>(I may have been the likely "someone" in the first place :) ) <rlb>Oh, hmm, looks like mwette claimed to have sent a mail, but didn't specify whether to guile-devel, or gnucash, or... <old>ArneBab: I just want to avoid doing the bootstrap again if possible .. <old>(I build out of tree) <old>janus: typically, this kind of syntax error is badly reported when interpreted with psyntax <old>I have made a custom reader that remember the last read expression along its location and whenever I got a syntax-error, I report that location <old>idk why psyntax kind of lost the syntax locations somehow <rlb>Hmm, www.gnu.org isn't responding for me at least... <old>ArneBab: don't you need to pass --enable-mini-gmp? <old>I always get that last autoconf error about gmp <identity>rlb: might be on your end, it works just fine on my end <rlb>old: did I break doc/ for you? <old>rlb: idk. did a distclean and retrying here <old>but since I build out-of-tree, that's kind of weird <old>I often just need to delete build diretory and configure it again <rlb>by out of tree, do you mean vpath? <old>mkdir build && cd build && ../configure && make <old>I never build in top of the source-tree <rlb>OK, right, that's a "vpath build" iirc. <old>I call that OOT build :-), I guess VPATH is makefile things that allow supporting OOT <rlb>Oh, right, I just meant wrt the auto* terminology. <rlb>(what I was familiar with) <old>good lord I have to do the stage0 again <old>How can I speed this up <rlb>Depends on the circumstance -- if you're just jumping around commits (and not across a backward incompatible change), you should just be able to rebuild incrementally. <rlb>(I typically use multiple git worktrees and just keep them built.) <rlb>git-worktree(1) I mean <rlb>But that won't help for the first build of each, of course. <old>but there is no way for me to pull the bootstrap from somewhere? <identity>old: i think you can get stage0 files from release tarballs or something <rlb>I assume you could put "suitable" .go files in place if you're sure and then "touch" the corresponding .scm files. <rlb>i.e. git will always set the mtime to "now" when it changes a file. <rlb>And really, for a fairly fast machine, you may only need two or three of them. <rlb>i.e. I think eval.go, maybe psyntax.go, and...? <rlb>I believe eval.go is the primary bottleneck. <old>ya the problem seems that the stage is not highly parallelized <old>once these two are bootstrapped, I got full cores power <rlb>It's intentionally not. <rlb>i.e. it's even slower if it's not :) <old>I did get some perf gain by changing the bootstrap evaluatior in C <old>but we are talking a 3 seconds diff on a 2 minutes run <rlb>You just have to get through eval.go, and whatever else is intentionally restricted there, os that they can make everything else faster iirc. <rlb>i.e. you'll find a commit where those were serialized because they make the build faster by going first. <old>And I suppose that other than eval.go and psyntax.go, there other modules can not be compiled using the evaluator in C because of the C stack somehow ? <old>in that the evaluator in C is kind of restricted with respect to what it can evaluate <rlb>Oh, no, wait, they can be? i.e. it used to be fully parallel, and that's observably slower. <rlb>because I believe, with say make -j10, you start trying to compile 10 things with the *really* slow evaluator. <rlb>instead, now, we just compile eval first and then use that for everything else. <old>Ah I guess that the Scheme evaluator is always used <old>except for evaluating itself first <old>thus the C evaluator <rlb>it's just that uncompiled eval is **slow**, I think. <rlb>So compile it first, and then "release the hounds". <old>Yeah because you have to evaluate the evaluator. kind of like nested VM <rlb>I also toyed with some additional ordering myself, e.g. does it help to move srfi-1 ahead of other things, etc., but didn't find anything obviously worth it for the time I spent. <rlb>(Yeah, looks like gnu.org (or something) is just not happy with my connection (currently via 5g, which I've heard can be treated unusually both because it may be "assumed phone", and because the carriers may use cgnat (giant nat across many devices, I think)) --- works fine from another machine for me too.) <old>rlb: wrt gnu.org, I often have very bad response when using my phone <old>For example, when looking at Guile doc online using my phone (yeah I do that often) <rlb>(Guessing perhaps a lot of other bad behavior behind that cgnat address.) <old>Idk if it's because I have a VPN on my phone or wathever <rlb>Oh, well a vpn should avoid the cgnat; I assume you'd be evaluated based on your VPN exit addr. <rlb>(if that's even the issue, and it's not just more pedestrian routing differences) <old>Is it normal that geiser does not load my .guile in HOME ? <old>I know there is a .guile-geiser file that I could also used but seems redundant <old>ah: geiser-guile-load-init-file <old>ehh I still get make[3]: *** No rule to make target 'guile-tools.1', needed by 'all-am'. Stop. <old>removing guile-tools.1 from: 29 dist_man1_MANS = $(guile_generated_mans) <ArneBab>old: this is how I build, so I guess I don’t have to pass --enable-mini-gmp … <old>well I don't see any test failure when I add a throw to the describe meta command <old>so I guess, it's simply not tested <rlb>old: I'll plan to try a vpath build later, though I thought make distcheck already did... <rlb>Though I suppose it'd be less "clever" to create guile-tools.1 via a target, so might just do that instead. <old>ACTION really wished srfi-64 accept an optional [count] for test-group <rlb>old: were you using -jN when you hit the guile-tools.1 issue? <rlb>I reproduced it here once in a "normal" tree, but now I can't...