IRC channel logs
2025-09-24.log
back to list of logs
<ArneBab>dsmith: for naming and logic I decided to only write about syntax-rules, because syntax-case is much harder to understand and 99% of the tasks are possible with syntax-rules already. <euouae>just looking at your comment on codeberg repsnding to me <euouae>did you modify lib/Makefile.am or was that gnulib-tool? <dpk>all the files except libguile/posix.c are generated and/or managed by gnulib-tool <dpk>it says so in comments at the top of those files <euouae>did you have to run a gnulib-tool command? <dpk>yes, gnulib-tool --add-import <dpk>to add posix_spawn_file_actions_destroy <dpk>i’m guessing these changes are because there was some slight difference in how Ludo ran gnulib-tool last time he updated the tree vs how i ran it to just add this one module <euouae>so `gnulib-tool --add-import posix_spawn_file_actions_destroy` in root project dir? <dpk>i think, notwithstanding the fact the comments tell you not to do this, i might just manually remove the change you flagged as potentially problematic (plus some similar weird path changes in comments), make sure it still builds that way, and then push again <dpk>euouae: hmm, i might have run it from the gnulib directory and used another flag to tell it where to find the project directory. that might be the issue <dpk>yeah, it seems to autoconf, configure, and make okay with changing that path back to what it originally was. i guess whatever it is, it might re-appear next time the whole Gnulib tree is updated, in which case probably nobody will notice <euouae>can you document in the changelog what your use of gnulib-tool was? <dpk>why? that doesn’t seem to be standard practice for updating the gnulib files <dpk>again, everything in lib/ is managed by gnulib-tool. i didn’t introduce that practice <dpk>go and look at the Git history in that directory <euouae>you manually edited the gnulib files right? <dpk>just now, yes. but i only changed one non-comment line <dpk>(the one you flagged) <euouae>it would be useful to document this for the review <euouae>both what your invocation of gnulib-tool was (for reproduction) and what line you edited <euouae>it might come up that someone knows how to use gnulib-tool without requiring the manual intervention <dpk>that person is probably Ludo, who has thus far maintained the lib/ directory apparently <dpk>again, i don’t think this is relevant to anyone <dpk>probably there was some minor difference in the setup i used to add posix_spawn_file_actions_destroy vs the setup Ludo used to update to v0.1-5703-g356a414e8c in January 2023 <dpk>we’re going round in circles here. you already asked that <euouae>The specific command you ran is what I'm curious of <dpk>i don’t know which shell history that would be in … <dpk>it could have been lost because i do my Guile development in a Nix shell <dpk>./gnulib-tool --dir=.. --m4-base=m4 --add-import posix_spawn_file_actions_destroy <euouae>hmm I think it's --dir=.. that caused it then <euouae>using the gnulib-tool on debian oldstable I can't even get it to work properly <dpk>gnulib is a stinking heap of computational coprolites <dpk>admittedly, coprolites don’t tend to stink nor form heaps <euouae>on my system it's a nice 8k sh script <dpk>okay, confirmed that the build fully works with the manual changes <dpk>as mentioned yesterday, the ‘portability’ problem that Gnulib solves in the case of posix_spawn is that some OSes released two decades ago didn’t support it yet. i would put decent money on there being numerous other reasons why Guile does not build and run on Solaris 9 or FreeBSD 6 <identity>‘nice’, ‘8 thousand lines’ and ‘sh script’ should not meet in one sentence <dpk>(and the real portability problem, discussed here recently, is the _np file actions especially addclosefrom, which Gnulib can’t sensibly patch and thus rightly doesn’t even attempt to patch) <euouae>dpk: IMHO it's a form of premature optimization to attempt to target all possible platforms that ever exist, you end up with 50 components all half-targeting different combinations and everything falls apart once you move away from linux/windows/mac/bsd <euouae>Why can't _np be sensibly patched? I don't know what it does <dpk>i have no idea whether you’re agreeing with me or disagreeing <dpk>posix_spawn_file_actions_addclosefrom_np requires actual support from the kernel or libc implementation of posix_spawn. there’s no way to fake it in userland <euouae>How did you catch that memory bug? <dpk>by reading the source code <euouae>Aha! Spurious reading or targeted? <euouae>oh, spurious is the wrong word, I meant something else <euouae>as in, were you just reading random parts or for a reason? <dpk>ACTION notes that the portability problem she notes in the C file there is explicitly not one that’s fixed by Gnulib, although it fairly easily could be (albeit it would be most easy to fix it in the less helpful way) <dpk>‘Portability problems not fixed by Gnulib: When you call select with a timeout, some implementations modify the timeout parameter so that upon return from the function, it contains the amount of time not slept. Other implementations leave the timeout parameter unmodified.’ — https://www.gnu.org/software/gnulib/manual/html_node/select.html <euouae>ah yeah I've read that comment before <dpk>it’s a wonder anything works at all, frankly <dpk>just wait until you hear my rant about POSIX’s underspecification of close(2) <dpk>(also not something Gnulib could safely fix) <euouae>A POSIX compliant system with no further features is probably useless <euouae>At least from my bit of reading of POSIX, e.g. the system utilities have very few options <euouae>I have never used mutation analysis before :( I don't know what meze does <euouae>ah -- modify the source code a little, and try the test suite again, hoping you catch a bug. Okay fair enough! That is a cool project. It doesn't work with Guile does it? <dpk>no, only on Chez: it uses Chez-specific features such as Chez’s own API for tracking source locations (so it can tell you exactly where the thing is that it changed that caused a mutation to survive), and also the FFI to spawn the process that runs the test suite <dpk>it would be reasonably easy and fun to create a Guile version though, and you probably wouldn’t even need to write the process-spawning part in C on Guile since it has a native Scheme interface to process spawning etc :-) <euouae>Yeah! I might eventually dig into unit testing more <euouae>Another idea was property testing and random testing like QuickCheck/Hedgehog <dpk>there are sooooo many Scheme libraries for that … however, i don’t like any of them and also plan to create my own at some point :D <euouae>fair enough, maybe one day. I'm focused on making a tiny text editor for now <euouae>ah so the extensible pattern matcher is your SRFI? I didn't realize <euouae>I know someone linked me to it at some point here. I see you're also using it in your meze code <euouae>well that's all from me today, I have to go <ArneBab>sneek later tell civodul: to do some pressure testing of fibers, I created a tool I’ve wanted to write for a long time: distsort sorts files or arbitrary strings by editing distance and uses fibers to parallelize the work: https://hg.sr.ht/~arnebab/distsort/browse/distsort.w?rev=463e9a930cb4#L95 -- this only yields factor 2 speedup, I think due to garbage collector problems, but it’s the simplest use: fan out and recombine in a block. <jlicht>ArneBab: for not having really looked into it, wisp seems surprisingly clean <wehlutyk>kestrelwx, dthompson, thanks for the other day <wehlutyk>I'm now trying to combine chickadee with something that I would say needs guile-fibers <wehlutyk>would anybody have inspiration for that? <wehlutyk>I saw it's mentioned in chickadee as a TODO / open question <dthompson>wehlutyk: the issue with fibers + chickadee is that fibers has its own event loop but really we need something that integrates with chickadee's <wehlutyk>is it otherwise possible to combine chickadee (or use parts) with another existing event loop? <dthompson>if the necessary hooks are available to do the cooperation, yeah <dthompson>I've made goblins and chickadee cooperate in the past, for example <wehlutyk>so the next step is to start reading goblins right? :) <wehlutyk>or would you have a commit or two that would focus on that? <dthompson>I wouldn't put anything in chickdee explicitly for this <dthompson>for fibers integration, we need to be able to schedule fibers in a chickadee agenda <wehlutyk>I mean for what you did having chickadee and goblins cooperate <dthompson>because in a game it's important to schedule things based on ticks of the game loop rather than real time <dthompson>oh I have some commits somewhere for the chickadee+goblins stuff <dthompson>in goblins, a vat is an event loop where actors live. the chickadee vat implements a message queue loop that suspends to a chickadee agenda. <wehlutyk>I have to study/digest all that -- thanks for the reference <dsmith-work>rlb: Just tried HEAD on Debian 11. Getting a failure with make -j$(nproc) The out-of-memory test <dsmith-work>make check (and with -j$(nproc) both fail the test-out-of-memory <dsmith-work>rlb, Did you need to disable that test for the deb package? <rlb>(...and the parent dir has all the current patches -- for now debian has more than usual because of the patches pulled from main to fix 32-bit) <rlb>dpk: don't know how/if it applies to your pr, but doc/release.org mentions some bits, for a full upgrade, about making the version clear. (Also, we should add instructions to that section eventually, or a well maintained build-aux command or something...) <rlb>Yeah, you can see in the patches dir view that ~8-20 are for the 32-bit support -- why I'll also be happy to have a 3.0.11 release. <rlb>Also had to mark that inter-protocol attack test as unresolved, so I guess it's not just me :) <dsmith>rlb, And git HEAD on Deb 13 passes make check no failures <rlb>I also tested it the other day (clearly) on s390x and i386 forky (or was that trixie) -- though I'll probably test again once we're closer. <dsmith>So... Something between 11 and 13 makes the memory test not fail? <rlb>Oh, I'm not sure, but I think that may be another test that's just unpredictable. <rlb>i.e. maybe if you ran it in a loop, it'd fail eventually, or under some other different circumstances (arch, etc.). <rlb>That is, maybe we've "fixed" it, but I would guess not, offhand. <rlb>I believe that in the debian patch message I was alluding to the fact that we "know" its flaky. <rlb>i.e. maybe Ludovic just told me -- rings a vague bell <dsmith>So I was thinking about dpk's leak. Is there a standard way we check that mem is leaking? Looking a /proc or ps output? Looking at gc? <rlb>or maybe it's in that guile bug <rlb>other than *grind or whatever, I suppose if you can easily do so, could make a simple loop and watch the RSS -- or put a ulimit on it and wait for a crash :) <ArneBab>rlb: what’s still missing for 3.0.11? <rlb>A bit of bandwidth from Ludovic if nothing else, though now I think that memory leak fix might be worth considering. I haven't looked at it myself much yet, but I think at least dsmith and euouae may be. <rlb>I'll also need to finish up the NEWS entries (e.g. still have some from you that are pending locally). <rlb>(so don't worry about adjusting your pr) <rlb>(or Andy, wrt bandwidth) <rlb>But overall, I think main should be in pretty good shape. <dpk>rlb: is the SRFI 207 notation supposed to be supported in a build from HEAD? i tried it at the REPL and it didn’t work (it went to a continuation line as if an expression were unfinished) <rlb>Did you enable it via (print-enable 'bytestrings) and (read-enable 'bytestrings)? <rlb>It's off by default for now. <rlb>If I didn't mention that in the NEWS, I should -- I'll double-check. <dpk>reading the manual would probably put me at an advantage :D <rlb>No worries -- happy to help. <dpk>okay, yes, then it works :D <rlb>From my work on some of the string conversion functions (i.e. debugging), I think it'd be quite nice if guile eventually defaulted to that output, at least for some things, like failed encoding/decoding error messages, etc. <dpk>note SRFI 207 forbids writing in bytestring form as a default for interoperability reasons <rlb>Because it'd be a lot easier to see what's going on immediately with one of those, than with #vu8(INT INT INT ...) <dpk>you can, of course, ignore that :D <rlb>Sure, but even if I had to opt in, that'd be nice, and not sure, but I wonder if some error *messages* might be acceptable. <rlb>i.e. embedded in error message strings. <rlb>Perhaps not something that's as critical wrt backward-compat readability. <rlb>(read ...)ability :) <dpk>my vague plan was to specify a higher-order procedure for writer customization. so you would do something like (make-writer 'bytestrings 'datum-labels) and it would return a version of the write procedure which can safely write circular structures with datum labels and which always prints bytevectors in the string notation <rlb>dpk: given dsmith's impression, I might poke at your pr a bit too (though I'm much rustier wrt spawn atm), and consider merging it (maybe in the next day or two) -- think it's about ready? And think it might be worth putting the gnulib version in the commit message (somewhere, presumably not exactly as described in release.org) if you haven't? <dpk>never got around to that, though <dpk>yes, it’s entirely ready to merge <dpk>it’s a four line fix to deallocate before returning <dpk>(plus a bunch of wanking around with gnulib) <dpk>i checked out the same Gnulib revision as mentioned in the commit message of literally every other file in lib/, but i could do that if you think it’s important <rlb>Yeah, I think Andy had some inclinations about how he might want to integrate bytestrings too. So for now just having the existing opt-in mechanisms seemed pretty low risk, if not entirely flexible. <dpk>(two of the four lines are curly brackets) <rlb>Oh, so you matched our current version. <dpk>yes, i assumed there would possibly be un-fun version conflicts if posix_spawn_file_actions_init and posix_spawn_file_actions_destroy came from different versions :P <rlb>Right -- I guess it might be nice to mention that in the message (i.e. same version as existing lib), but now that I'm thinking it through, that's probably what one (I) should have assumed by default. <dsmith>rlb, All exit paths in do_spawn are covered to free structures allocated there <rlb>Also, I had read the "don't turn this on by default", and figured read-enable/print-enable were the most likely answer for us atm. <rlb>(particularly for a Z release, of course) <dpk>yes, certainly in the context of how Guile’s reader customization currently works <dpk>/writer customization <rlb>I took that a touch further in lokke, making it possible to create a reader with the customizations embedded if you like. <dsmith>rlb, Something else to consider for the next release is update the README with savannah -> codeberg urls and such <dsmith>Anyone know the man page(s) or url that documents the fields in /proc/self/stat ? <dsmith>rlb, Yeo, That's what I'm looking for,