IRC channel logs
2025-12-18.log
back to list of logs
<old>rlb: did you made your changes for guile 3.0.11 for Debian? <rlb>...m68k is just timing out (currently suspect it's some change that's not allowing the multi day build we need), but sh4 looks "new" (some more significant crash, now that I look at the log). <rlb>"Unhandled trap: 0x180" (and then registers)? <old>I was wondering if you had moved guild binary to guile package instead of guile-devel <rlb>Oh, no --- I poked at that a bit, but no conclusions. I need to think through the implications a good bit more I suspect. <rlb>i.e. guild is a wrapper for a bunch of subcommands --- what do we promise about which files they require? <rlb>(wrt what's currently in guile-3.0-dev --- i.e. can any of them crash if those files are missing, and/or are we unlikely to change that?) <rlb>basically debian introduces a "novel" split that guile itself doesn't have upstream... <rlb>Assuming we want to address the original issue, in the limiting case I suspect I could just move nearly all the files from guile-3.0-dev to guile-3.0-libs, such that guile-3.0-dev is really just there for the "external" dependencies i.e. for compiling against libguile, but that could make people unhappy wrt the size of guile-3.0-libs, so... <rlb>"limiting case" meaning if we weren't sure exactly what all the guild subcommands (and guile-snarf, and guile-config?) might need from dev. <rlb>(now or in the future) <rlb>Other ways we could split the packages too, of course. <old>well in the first instance, the problem was that pulling guild pull a lots of other things and that somehow slow down my CI quite a bit <old>I don't get why this problem does not exist on say ArchLinux <old>they have a single package that pull everything <old>yet it's order of magnitude slower than Debian <rlb>maybe just different "apt update/get" costs? <old>so maybe this could be address instead. I am not really not familiar with how Debian packages are made and what are the implications here <rlb>(or their equivalent) <rlb>Basically I think the question is "what files do any of the guile subcommands depend on"? <old>only Guile modules and the shared libs runtime I suppose <rlb>If we think we know the answer with some confidence, then sure, should be able to rearrange the split to avoid needing "tons of useless C packages". <rlb>And note, definitely not saying no, just cautious. <rlb>It could also be (if guild is opportunistic about subcommands), that some subcommands would belong in -dev and some in -libs. <rlb>i.e. say some subcommand depended on having the headers available to compile C or something... <rlb>certainly guile-config (not guild) depends on the .pc file. <old>To my knowledge, Guild is really just a command dispatcher that lookup scripts in a pre-defined directory. So it a sens, it can be packaged where the `guile` binary itself is packaged <rlb>so could be that guild moves but guile-config doesn't or... <rlb>Right, fwiw, my *guess* is that guild can move, and perhaps guile-config should stay, and not yet sure about snarf... <old>guile-config make sens to keep it with devel <rlb>If snarf is purely "textual" manipulation, i.e. doesn't care about any actual headers, then it could probably move too. <old>you need it for development anyway (I think m4 macros use it) <rlb>Sure, though I'm also fine moving "more" to guile-3.0-libs or guile-3.0 (or a similar new package if that's better) if it's not excessive, so, for example, might be fine to have guile-config in -libs or guile-3.0 along with the .pc file *if* a dep on pkg-config was also small enough to be acceptable. <rlb>But by default would probably leave guile-config in -dev. <old>Ya I would do the minimal change here that risk not breaking workflow <old>If you end up not changing it that's okay also. I could just create a pre-made image in Dockerhub with guile installed <rlb>it'd very likely be safe either way -- since guile-3.0-dev depends on both -libs and guile-3.0, the move would be "transparent" to everyone. <old>that's what I think also <rlb>Really, my only question is "do we intend for guild to work just fine without 'everything'" where everything mostly means the headers, libguile.a, and the typical C dev deps (libgc-dev, etc.). Perhaps? <rlb>(and where "work just fine" can also include splitting the subcommands across guile-3.0-libs (or guile-3.0) and guile-3.0-dev) <rlb>vaguely doubt we do right now <rlb>old: also y'all were fairly certain (say via live observation, or timestamps, or something) that guile-3.0-dev was the specific issue rather than just say "debian vs arch" in some more general way? <rlb>If not, testing two dummy debian jobs, one that installs guile-3.0 vs one that installs guile-3.0-dev might reinforce --- assuming there's not too much variance in your CI across hosts/runs. <old>rlb: well Debian and Ubuntu had the same problem. <old>they both build in 7 minutes <old>vs Arch and Fedora in 1 minute <old>but I could not tell which packages caused the issue <old>I suspected it was guile-3.0-dev <rlb>OK, well if it's easy somehow, say via temp branch, or temp "project", or..., might be worth trying the two trivial jobs (just installing either guile-3.0 or guile-3.0-dev) --- just in case that might turn out not to actually be the culprit, and avoid some work/packaging-churn. <rlb>Though I'll still think about it --- might be preferable to have guild in guile-3.0 anyway, all else equal. <rlb>(If you do try the test jobs, probably also worth running them a few times each, just to hopefully average any per-job/host variances.) <dsmith>This talk of snarfing has reminded me of something. Doc snarfing. Currently the commands to extract and format docstrings from C are not installed. <dsmith>Also, there is no way to add extra files to search for docs besides guile-procedures.txt <dsmith>I know writing C extensions is not preferred, but it is still useful. <dsmith>Pretty sure the doc snarfing stuff has been stable for many many years now. <ArneBab>wrapping two communicating async fibers into a sync fiber fixed socket synchronization problems I had and scaled up dryads wake, so that the tiny VPS can now serve 250 simultaneous players: https://dryads-wake.1w6.org/ <rlb>dsmith: which commands? guile-snarf is, (at least in guile-3.0-dev deb). <dsmith># We can re-enable install for some of these if/when they are documented <dsmith># and people feel like maintaining them. For now, this is not the case. <dsmith>noinst_SCRIPTS = guile-snarf-docs <dsmith>The script calls the C prog, which parses the output of gcc with flags to expand macros a certain way. The results are all then cat'ed together. <dsmith>But it's been a while since I looked at it. Might have missed some steps in there.