IRC channel logs

<rlb>nvm regarding srfi html -> texinfo, just did it by hand again, though this was easier than srfi-207 since a lot of procedure entries just forward to the existing string fn docs.

<rlb>I did replace our xsubstring docs with the fancier srfi-152 version

<rlb>Rarely, but every now and then (maybe 1/50+ or more make check runs) I see a segfault (I think in future.test). Anyone else?

<ieure>mwette, Sorry, had to drop to take care of stuff. Yes, pkg needs to eval in the caller's environment, but the macro also needs to see the symbol itself.

<ieure>mwette, Thank you for the code, but I don't think it solves my problem. The `define-emacs-native-variant' I wrote already works for the a single package case, what doesn't work is `define-emacs-native-variants', which I want to take a list of symbols and define one package for each.

<ieure>I do not really understand `define-syntax', which seems *much* more complicated than `defmacro', and whose main benefit (hygeine) is not one I desire.

<mwette>ieure: did you try wrapping the list in a `begin' form?

<ieure>mwette, Yes, two attempts at this were in the pastes I sent.

<mwette>Got it.

<ieure>mwette, My attempts to debug have been thwarted by the output looking nothing like the input at all. ex if I change `(begin ...)to '`(begin ...), it expands to a tree-il record. Is that how I should be doing this?

<ieure>Here's my current attempt, this is using a technique I've found valuable in CL-style languages, where the actual body of the transformation is in a regular function, and the macro just wraps it: https://paste.debian.net/hidden/bacc664b

<ieure>So `d-e-v*' "works," in that it takes the input and produces the output I want to eval.

<ieure>ex. (define-emacs-native-variants '(emacs-9lc-mode emacs-tl1-mode)) ;; -> (begin (define-emacs-native-variant emacs-9lc-mode) (define-emacs-native-variant emacs-tl1-mode))

<ieure>Sorry, all wrong there.

<mwette>You can turn the tree-il back to scheme: https://www.gnu.org/software/guile/manual/html_node/Macro-Expansion.html

<ieure>(d-e-v* '(emacs-9lc-mode emacs-tl1-mode)) -> ;; (begin (define-emacs-native-variant emacs-9lc-mode) (define-emacs-native-variant emacs-tl1-mode))

<ieure>But if I then use the macro wrapping that, I get: Syntax error: unknown location: quote: bad syntax in form quote

<ieure>Okay, I figured it out.

<ieure>I think.

<ieure>Yes! Okay, cool.

<ieure>This does what I want: https://paste.debian.net/hidden/9d5d68a1

<ieure>I can now: (define %emacs-pkgs '(emacs-org emacs-magit)) and (define-emacs-native-variants %emacs-pkgs)

<ieure>And I get emacs-org/native and emacs-magit/native.

<mwette>Nice.

<ieure>Okay, amazing, this did not solve the initial problem I found which motivated me to figure this out.

<ieure>Here's the full (WIP) module code: https://paste.debian.net/hidden/3924a596 (this is this stuff with some fixes: https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/packages/emacs-xyz.scm)

<ieure>When I load the emacs-xyz.scm file in Emacs and hit C-c C-k, I get: "error: %standard-emacs-package-symbols: unbound variable"

<ieure>But if I eval the forms in the file one at a time, I do not get the error.

<ieure>I'm guessing I need `eval-when' to fix this? The macros are getting expanded in an environment which doesn't have the symbols previously defined in the file?

<ieure>I tried moving the symbols to another module, but I get the same behavior.

<mwette>I think that's because the entire file is macro-expanded first, then compiled; not a top-level form at a time

<mwette>ACTION afk

<spk121>rlb: On the systems I test on, fluids.text, ftw.test, and foreign.test each cause problems. But future.test seems solid.

<rlb>Hmm, OK, thanks it might be fluids --- I'll try to check more carefully next time wrt the parallel output.

<rlb>And yes, I've thought I might try to fix ftw.test at some point, at least fix the fact that it'll fail if you have a file modified, but not saved in emacs in the tree.

<rlb>I assume it's mad about the emacs "marker files" there.

<spk121>the GC test in fluids is nonsensical. On Cygwin, where GC is exceptionally slow, it never passes.

<JohnCowan>spk121: what makes gc slow on Cygwin (but not on native Windows?)

<dsmith>JohnCowan, Hah! Was going to ask the same question

<JohnCowan>in years and years of using Cygwin, theonly serious perf problems were wirh process creation, whuch is dog slow on Windows

<JohnCowan>and tge moral of thar Y was, don't run Guile's ./configure! When I tried, it took 6-8 *hours*.

<old>JohnCowan: it can't be right. 8 hours for configure?

<jcowan>And compiling.

<jcowan>This was many years ago, but it was much slower than building any other Scheme from scratch.

<dsmith>When I would rebuild guile and bobot++ for the bot, it would take all weekend. (Beaglebone Black)

<dsmith>!version

<dsmith>sneek, version

<sneek>Sneeky bot running on Guile version 3.0.3 using bobot++ release.2.3.1-6-a463-dirty

<dsmith>An old Guile. Cause it takes so long

<old>better off with cross-compiling at this point

<jcowan>I'm off Windows, probably for good now. I used Cygwin because I was using $EMPLOYER-owned equipment

<jcowan>(shhh)

<old>really wish guile exposed system page size

<jcowan>66 lines, isn't it?

<rlb>I've thought I might like us to eventually have a well organized set of broader info, all of which we know when building. Haven't thought about how it should look, though (map, module(s), ...). I think we do have some of that already.

<rlb>I've thought of that in the context of (similar to python), just being able to rely on guile for "autoconf-style" info about the platform. i.e. python often has much of what simple projects might want, and python's fairly ubiquitous.

<rlb>(dunno, not well thought through...)

<rlb>old: imagine you know, but there's a sysconf for that sysconf(_SC_PAGESIZE)

<rlb>...and also if you have it getconf(1).

<old>we should not rely on build time for system page size tho

<old>it's better to poll the OS at runtime

<old>yes sysconf but we don't even provide the binding

<rlb>Then perhaps we add sysconf, or is it static too (don't recall)?

<old>yes sysconf would be ideal I guess

<rlb>yeah, and the key there is the values for the args, which ffi won't get you...

<old>there are other way to poll on Linux using /proc but not as portable as sysconf

<old>right

<old>but thse are constants per OS, so really one can write this quickly using ffi

<rlb>sure, though I don't find copy/pasting the integer values all that satisfying :)

<rlb>Prefer to capture them at build time if we get serious about it, of course.

<rlb>old: so, I just ended up with another "backward incompatible" barrier in the series, and this time it was because I moved a function to a different module. Quick fix is to rm stage2/.../specific.go that's causing the trouble (not one of the two involved in the move).

<rlb>Only mentioning it as another example of the domain.

<rlb>I also (temporarily in the series) after moving it, only provide it via @@ from the new location, but I'm not sure that's relevant --- seemed more like the stale.go had embedded the previous location or something.

<rlb>(error was undefined variable for the moved function, without great info about why/where)

<rlb>(Figured out the .go via educated guessing and trial/error.)

<old>probably inlined in stage 2

<old>until we have proper build system support, moving public bindings around can break stage 2 modules in suprising ways

<old>we should probably have some helper command for dealing with this

<old>like forcing to rebuild stage 2 (takes only a few seconds) to ensure fresh modules

<rlb>ACTION uses find "stage2 -name '*.go' -delete" someimes

<rlb>Anyway, I'm adding a note for now to the commit message.

<rlb>(My "pushing back some of the tests" to the start of the series paid off again --- exposed another minor bug in one of the reverse-list->string patches when I re-ran make check on the series.)

<rlb>I'm not sure how much of that I'll do, but for now...

<rlb>Also some of those patches, we could just add to main if we liked and have the expanded tests there now.

<dsmith>rlb, You just got me thinking. Are there any tests to ensure or expose ABI compatibility between releases?

<rlb>Nothing automated, but I think we should (and I have, after Ludovic told me about it) test before a release with abigail's abi differ.

<dsmith>Interesting. Got a link?

<rlb>Right, was just looking ;) In debian: https://packages.debian.org/abigail-tools

<rlb>Has a hompage link if you click on one of those.

<rlb>"homepage"

<rlb> https://sourceware.org/libabigail/

<dsmith>Yep. Thanks.

<rlb>I forget the command I used, but hopefully I wrote it down, and if I didn't, we should probably also add the process to doc/release.org...

<rlb>"if I didn't already"

<rlb>Of course that won't find everything, but it sounds like a lot better than nothing :)

<dsmith>Indeed

<dsmith>Elm has tooling that does automatic semantic version bumps

<rlb>While working on some utf8 related changes to get-string* I noticed our rnrs condition wrappers, and I think we should change them to preserve/provide errno somehow (as an extension if needed), maybe always, but at least in the "fallback" cases where it doesn't map to a specific rnrs condition, i.e. here (at least) we shouldn't just drop the value: https://codeberg.org/guile/guile/src/branch/main/module/rnrs/io/ports.scm#L231-L232

<rlb>So you can "do something" if you need to, even if rnrs doesn't include it in its portable conditions.

<rlb>s/it/the case/

<jcowan>The Abigail idea that the exit status is a bitvector is interesting (and new to me)

<dsmith>rlb, Since .go files are elf, can abidiff work with them? I mean, can it detect changes there?

<rlb>EIDEA :)

<rlb>old: I tried moving the xsubstring/string-xcopy! tests I just added back to main, and assuming I did that right, and got the tests right (derived from 152's tests), it just shows that those functions are broken on main...

<rlb>And I'm not sure I'm up for fixing them there right now, either, depending on what's wrong --- took some doing to get them right for utf8...

<rlb>(we'll see)

<rlb>(I'll at least try to double-check to make sure I believe I got the tests right.

<rlb>yeah, upstream srfi 152 test (from chibi-tests.scm) say

<rlb>(test "string-replicate" "defdefd"

<rlb> (string-replicate "abcdefg" 0 7 3 6))

<rlb>and string-replicate *is* srfi-13 xsubstring

<rlb>but in main we have

<rlb>scheme@(guile-user)> (xsubstring "abcdefg" 0 7 3 6)

<rlb>$1 = "abcabca"

<rlb>I'm not surprised --- string-replicate is not *that* hard, but it's not trivial, and even more so from C.

<rlb>(...and we have no tests)

<rlb>I ended up with one case where I couldn't figure out what was going on, and it was interplay between C modulus and my size_t where I needed an ssize_t :)

<jcowan>rlb: Huh, why is that being done in C?

<rlb>All of srfi-13 is C atm.

<rlb>And can't easily be changed.

<rlb>because bootstrapping/ordering/etc.

<rlb>I originally wanted srfi-13 to become hybrid when working on UTF-8, but didn't find any plausible way to do that for now...

<rlb>(For utf8, it perhaps makes a bit more sense given the ability to work with the bytes "in bulk".)

<rlb>but there were other tedious srfi-13 bits that I certainly would have attempted handling in scheme for the transition (leave C more for the heavy lifting).

<rlb>(had I figured out a way that wasn't too "out of scope")

<rlb>jcowan: as a bonus, we were able to uncomment that

<rlb>(test "string-replicate" "abcabca"

<rlb> (string-replicate "abc"

<rlb> 30000000000000000000000000000000

<rlb> 30000000000000000000000000000007))

<rlb>works just fine in the utf-8 branch now :)

<rlb>But of course from C that was a touch more complex as compared to "just works" had it been in scheme.

<jcowan>ACTION chuckles

<rlb>(It wasn't *that* hard, and I was in a mood.)

<rlb>only takes that path if it needs to -- typically just uses (s)size_t.

<rlb>nvm, backporting the tests and fixes to main wasn't that bad --- moving it the start of the series for consideration for main.

IRC channel logs

2026-04-27.log