IRC channel logs
2025-12-02.log
back to list of logs
<mwette>rlb: Does 3.0.11 have update to not fail with mem-test on debian? <rlb>I'll probably work on the debs soon, so should have an updated patch list. <mwette>rlb: thanks. I'll see what happens. I'm on ubuntu. <rlb>I don't know how quickly they pick up debian changes, but I'll probably have the new version in debian "this week". <mwette>OK. I have the old one. It's a simple patch, IIRC. <mwette>The old one should work by hand. <mwette>rlb: on ubuntu 24.10 I get this: PASS: test-out-of-memory <rlb>OK, thanks -- though the failure's intermittent, and maybe arch-sensitive. <rlb>My impression from Ludovic or Andy(?) was that it's known to be flaky. <rlb>So maybe we should mark it as such "officially"... <mwette>Maybe something changed (on guile or ubuntu). Previously, for me, it always failed. <dsmith>mwette, So you remember which specific test was failing? <dsmith>Oh I see now. The individual tests there are not labled at all. <mwette>Right. I'm going to try to build 3.0.10 now, on my 25.10 ubuntu, and see what happens. <rlb>mwette: oh, well, that'd be great if we somehow made it go away. <old>I hear some echoes the other day that the bootstrap Guile was slow. <mwette>To compile 3.0.9 and 3.0.10 I'm using CFLAGS=-std=gnu11 argument to configure, or make dies pretty quick. <old>Could someone explain how this bootstrap process work? What are prebuilt, stage0, stage1? <rlb>mwette: recommend std=gnu17 since that what we had in recent gcc until 14. <rlb>until we fix gcc 15+ <rlb>gcc 15 switched the default from gnu17 <rlb>And yeah, a full bootstrap takes 20-30 min on a fastish host, and *much* longer on slower architectures (sometimes days). <rlb>(though that's for very slow archs :) ) <mwette>passes 3.0.9 and 3.0.10 pass. I'm guessing something in OS changed. <rlb>I'd imagine it might also be load related, etc. <rlb>i.e. maybe different depending on ram, perf, and/or concurrency. <mwette>rlb: sounds plausable; nothing I can chase down right now <rlb>At some point I've thought about removing the XFAIL for one debian upload, see what that reveals too. <rlb>(across the buildds) <ArneBab>old: AFAIK bootstrap first builds from sources, then rebuilds everything with the built code, and finally builds one more time to get rid of remainders of the old code. <ArneBab>old: it is sensibly fast when using the bootstrap binaries, but you can build without those. Then stage0 uses a much slower interpreter as long as the Interpreter in Scheme has not been built, so the bootstrap takes much, much longer. <janneke>ISTM that the savannah mirror is broken? <listentolist>Is it possible to undefine a variable? I unbound it but it still shadows a variable with the same name in another module. <ekaitz>listentolist: i don't think you can do that, but you can always (define whatever (@@ (original module) whatever)) <chrislck>hmm guix users... if I switch from guile to guile-next as a daily driver, am I expecting any surprises <chrislck>is there a package for guilers who like to live dangerously? <identity>chrislck: you can define guile@main if you so choose <old>ArneBab: what is the bootstrap binary? <old>it is someting you can install on the system to speed-up buildin gGuile? <old>I'm asking because I'm looking into the bootstrap code to see if I could speed it up <dariqq>maybe a bit of a weird question but is string-length the same as the bytevector-length of the utf8 bytevector? <dthompson>because a utf-8 character may span several bytes <dariqq>so when I am working with a binary format that wants the length of the message i should only rely on the bytevector-length <identity>dariqq: really, it depends on what «the length of the message» means <dariqq>identity: from a parsing/reading perspective the number of bytes makes more sense to me and the number of utf-8 characters should be irrelevant as long as it is valid utf-8. But the description of the format is a bit vague on this <rlb>janneke: hmm, unless I misunderstood, I don't think savannah is intended to be a mirror now. <rlb>i.e. it's just codeberg. <rlb>old: wrt the bootstrap files, see prebuilt/ <rlb>make clean doesn't clean them (and the dist archives include them), and if you have them, as mentioned, the build's much faster. <canterel>hi, I'm a little fuzzy on how to cleanup threads. Say, for example, I want to run a webserver in a separate thread. If I use (srfi srfi-18) threads, is there a way to kill the server when the thread terminates? The guile web server responds to SIGINT, and using (kill (getpid) SIGINT) works on the main thread, but how do I apply that to a separate thread? <rlb>old, wait, they're not in there <rlb>Oh, right, I think you only have stage0 normally, but I believe there are 4 "flavors" for a full set. <rlb>Also, I believe much/most of the time for a build from a clean tree is spent in stage0 on a few (couple?) of files, i.e. eval and psyntax. <rlb>And they bottleneck things (intentionally I think) wrt concurrency, so once they're built, if you have a lot of cores and -jN, it'll go much faster. <rlb>That's all if you want it to be driven by signals (say sigint). In general, things like condition-variables, select, etc. may also be used to coordinate, and of course if the web server already has some happy path (typical approach) with respect to shutting down, perhaps favor that. <rlb>(And I'm guessing others here have more recent, related guile experience...) <ekaitz>rlb: congrats for the release and thanks for all the work <rlb>yw, and thanks to you too for the help. <old>rlb: right I read the blog-post from wingo <old>I thought that the C interpreter was bottleneck, but apparently it is only used to compile eval.scm <old>yet it takes roughtl 2.15 m on my machine for this <old>I manage to make it down to 2.9 m by using goto labels meh <rlb>Yep, it takes a while. <rlb>janneke: while I have no opinion as yet about peek-error, in general, I'm inclined to think we should start raising the bar with respect to additions to the default module. I feel like in most cases, new bindings should go in some/any module other than (guile). <rlb>(Could be peek-error (were we to decided we wanted it) would have to go there to be useful, don't know offhand, but just wanted to mention the concern.) <ekaitz>janneke: in the new release the PEG improvements are included, so you might benefit from them <janneke>rlb: yeah, i'd agree and am very open to suggestions <ekaitz>janneke: let me know if anything fails in that front <janneke>ACTION sees no reason at all to have it in the default module <janneke>rutger rebased our peg patches already <ekaitz>i still had those to review but I never did... too many things to do <janneke>ekaitz: no need to do so, regtur made quites some improvements and will submit a pull request some time soon (TM) <janneke>ACTION hopes "someone" will suggest a nice shining new util model to put pke (and pk?) in :) <regtur>the pretty versions of pk and pke <ekaitz>the debugging in PEG is still pretty hard to do <regtur>ekaitz: that's what my patches address <regtur>I have added tracing of the backtracking <ekaitz>regtur: i remember the tracing, but I don't know how useful that is really <rlb>I think I'd also prefer guile to nearly always put its own (new) bindings underneath guile or ice-9, i.e. leaving the rest of the module "namespace" free. <regtur>Short circuiting of the backtracking + error collection <ekaitz>regtur: we don't have a good way for error reporting in PEG i believe, do we? <rlb>perhaps plus or minus some explicit exceptions like rnrs, etc. <rlb>i.e. all guile-specific stuff goes underneath (guile ...) or (ice-9 ...). <regtur>nope, we don't, that is what I address using expect parsing <regtur>where you annotate non terminals that you expect to be there <regtur>if the input does not match, an exception short circuits the back tracking and allows you to catch the error <regtur>on top of that I built fall-back parsing, which builds on the expect exception <regtur>and recovers parsing, adding the missing (expected) results to the parse tree <ekaitz>regtur: that is very cool actually. So you can re-synchronize the parsing to any position from there right? <rlb>old: one issue I ran in to when working on the utf8 changes was that I'd wanted to move some srfi-13 (or 14?) functions to scheme, but apparently we can't currently easily have a hybrid scheme/C module there -- I forget the details, but I believe Andy(?) was aware when I mentioned it. <rlb>I don't recall whether that was somehow related to some part of bootstrapping, but I think it might have been more a "how/where those modules are intertwined with the startup process". <regtur>ekaitz: PEG takes care of re-synchronization, which you can influence through the grammar declaration. <rlb>Were it easy, it'd be nice to fix that somehow -- avoid needing as much (careful) C code in some places where it shouldn't matter. <rlb>(Since the string handling is a good place to end up with overflow/overrun related entertainment.) <regtur>also the grammar dictates how the parsing may continue <canterel>rlb: yeah I was looking at the node in the guile manual for further insight, it's where I got the (kill (getpid) SIGINT) bit from. Naively, it looks like I can just do that and terminate the thread separately, and the web server stops running. For my use case, that's enough, but I confused myself with the language in the thread docs about exceptions. I thought I could install an exception handler that would run when the thread was <canterel>terminated, but that's apparently not how it works <rlb>In general, if you can, (and speaking across more than just guile), it's often better to avoid using signals for this kind of thing. But maybe fine here since in guile it's perhaps "more ok" because guile attempts to paper over the (very significant) mess that is *nix threads and signals. <rlb>i.e. often better if you can to have threads have some other way to detect when it's time to exit, when they're in a known state, etc. <rlb>And if the library you're using has some typical way, probably favor that. <rlb>If you have to do it by hand, another typical way is to have a pipe that the thread selects along with whatever other sockets it's listening to, and when it's time to quit, send a #\q or whtever on that pipe. <rlb>thread wakes up, notices the #\q on the "time to die" pipe, and exits its main loop, or similar... <rlb>(wakes up from the select) <rlb>cf condition-variables, and many other constructs across platforms... <rlb>Reminds me -- I'd wondered about abstracting guile's thread pool a bit, so you can create more than one, but haven't ever gotten back to look in to it. <canterel>the only reason I reached for signals in the first place is that the built-in guile webserver runs under a signal handler waiting for SIGINTs specifically. <canterel>but thanks for the context, all this stuff is pretty new to me, and as I'm finding out, complicated indeed. <canterel>really all I'm doing here is running the web server inside the REPL while developing, and I opted to run it in a thread because without one, the server blocks the REPL thread and makes Emacs unresponsive <rlb>Hmm, does the web server have any other way to ask it to exit? <rlb>If so, I'd use that so that you don't have to think about process signal delivery wrt multiple threads, setc. <rlb>dpk: I was looking at noncharacters again after a good while, and I imagine it's obvious, but could you remind me why it wants/needs the u+fffe leading escape -- i.e. as compared to just having the xy pair for each relevant byte? <canterel>it seems a rather minimal implementation, but I'm not exactly writing performance-critical apps <rlb>OK, well I forget the default semantics, but if you know the server thread, and sending a kill to it only delivers to that thread, then you should be fine there. <rlb>I thought you were also trying to shut down other threads of your own too, a the same time. <canterel>nope, just the server thread, so I think it's fine. I'll move away from this method when I put up the site, there's definitely no need for a separate thread there when the app is running remotely <rlb>Well, then I definitely misunderstood, and you shouldn't need to worry about the broader complexity I described, for this. <old>canterel: what about closing the server socket? <old>that ought to fail accept(2) <canterel>rlb: forgive my convoluted explanation then lol <canterel>old: I suppose I could, but is that supported from within guile? I don't think the (web server) API exposes any functionality related to the underlying socket <old>ahh you are using the core web-server <old>nah I don't think so <old>the loop is hidden AFIAK <dpk>rlb: hmm, that’s a good question! i should ask jcowan <dpk>congrats on the 3.0.11 release btw :-) <dpk>rlb: at a guess, it means you can detect when a filename (or other OS string) was valid Unicode but just happened to contain one of the noncharacters used to represent invalid Unicode, without knowledge of the character encoding used by the OS <rlb>Hmm, not sure I follow completely yet, but unless u+fffe is somehow "more special" than u+ffdo-ufdef then maybe you still have ambiguity wrt u+fffe... <rlb>It'd be nice to save the space if it doesn't buy us "enough", but as mentioned, suspect I'm missing something. <rlb>Anyway, thanks for checking. <rlb>Oh, wait, maybe I see. <dpk>a noncharacter error handling string containing U+FDD0 through U+FDEF can’t really be interpreted without knowledge of the original encoding it came from <rlb>To I think repeat what you said, it's maybe intended so that you can detect whether the encoder had a problem with the bytes, *or* the path just happened to contain those unicode chars. i.e. we're not (as I'd vaguely guessed) just assuming that since those noncharacters are only intended for 'internal use", nothing else should ever present them, and/or we can just assert that that's not distinguisable. <rlb>ooops -- "whether the decoder ha a problem" <dpk>if it only contains U+FFFE plus a quoted one of those characters, you know that the original string was actually validly encoded, and you can actually losslessly convert to what would have been the string if it had been decoded using normal Unicode rules <dpk>yes, exactly; you might want to not mess about with some noncharacters in an OS string that have been given over to some ‘internal use’ by some particular application protocol or something <rlb>Right, if you see "U+FFFE xy", then you know that to get the right encoding on the round trip, you should just re-encode normally, but if you just see xy, then you need to "blindly" output the byte built from x and y, I *think*... <ArneBab>old: the bootstrap binaries are *.go files shipped in release tarballs <ArneBab>rlb: it seems we broke GNU Cash compilation … (emails by Greg Troxel to guile-devel) <dpk>rlb: right. i’ll ask jcowan anyway, he might have other reasons <ArneBab>I think I may have seen something with compilation … could dependency resolution in guild have changed? <rlb>ArneBab: I saw that, but don't know anything offhand -- an offhand guess was some change causing a macro to expand to (lambda ()) when it didn't before, i.e. with a missing body. <rlb>One of those tedious errors with no context information... <rlb>Only info so far is that it's us calling someone's exception handler --- from the else in raise-exception, and so perhaps that's what has the bad form. <rlb>At least I assumed that "handler" is a "catch" thunk --- didn't look closely. <ArneBab>rlb: would you be able to do a followup release quickly if/when/once we finde a fix? <rlb>Certainly more quickly than 11, I'd assume. <rlb>And it'll be "we", I'm sure ;) <daviid>sneek later tell tohoyn I'll try to look at why your GClosure args seems wrong, but as I told you , I currently have (quite) limited free time - your last paste still uses a main that does not check nor sets the -d --debugg paramemter .. please update and re-paste, tx