IRC channel logs
2026-05-04.log
back to list of logs
<rlb>Looking at (system vm assembler) link-data, I'm wondering if we might want to add a read-only? argument (unless it's OK to decide based on the name), so that I can write inline strings for the read-only section (instead of current "string that points to stringbuf" combination). <rlb>(That of course also assumes that we'll never want read-only strings to share content via a stringbuf.) <rlb>(If that's not the case, then we'd have to have some way to distinguish, perhaps based on size at least --- for smaller strings, say <= 20-30 chars, the sharing actually wastes space.) <rlb>old: finally got it --- all tests pass with support for inline strings, and all symbols at least should be based on inline strings (assembly included). Just need to clean up. For now (and perhaps forever), it'll be optional, at the end of the utf8 series. <rlb>I'll probably also see where else we could use them by default (e.g. smaller read-only, non-shared substrings), but broader use for say string literals, may require additional accommodations (e.g. link-data above). <old>so where was the culprited read-only bit set? <rlb>that one was just "rlb can't bitflip"; the harder one was trying to figure out why the (module-filename ...) strings were wrong, but only during tests or standalone scripts. <rlb>That was because assembler link-data was using 0 for a non-shared string's "start" into it stringbuf, which is just wrong. <rlb>But that's also what we're doing in main. <rlb>which is why I was confused for longer than I should have been --- assumed that was right. <rlb>I think, but have not confirmed, that the reason it works in main (where it might or might not be wrong), is that we're not faithfully carrying through the original string instance, with it's original stringbuffer, i.e. sharing's being reset along the way, so that there, hard-coding start 0 is fine. <rlb>Whereas in the "inline strings" work, I made changes that cause it to carry through the structure (the original string instances) without adulteration, which is feasible because we no longer need the synthetic <stringbuf> records. <rlb>i.e. a basis string is a valid scheme object now (previously those compile-time <stringbuf> placeholders were needed because stringbufs weren't top-level scheme objects. <rlb>Now we can just let the (basis) string carry-through. <rlb>(i.e. it can represent itself --- if any of that makes sense without more context ;) ) <rlb>(which then of course must be true in main, right now, one way or another) <rlb>It *should* be (%stringbuf-start string) rather than 0, except that we only have that function in the utf8 branch :) <mooseball>i am having issues with filter being defined in sxpath and srfi1, what's the right way to avoid this? what i have is (define-module (template) #:use-module ((sxml xpath) #:select (sxpath)) #:use-module (srfi srfi-1), but i still end up with the xpath version of filter ruling my repl <mooseball>ah hm, no it seems it works like that. maybe i had also manually loded sxpath in the repl <yarl>mooseball: You can use #:prefix too <mwette>there is also #:hide now #use-module ((sxml xpath) #:hide (filter)) ; you can use `node-self' instead of `filter' <mooseball>mwette: ah, thanks hide is good to know, filter out rather than include <mooseball>somehow i got into a frankenstein situation where geiser doc commands would point to the version of filter that wasn't loaded, urgh <mwette>I've dealt with `filter' for years. #:hide is an undocumented recent addition. <mooseball>mwette: btw, do you know of any examples/user docs for sxpath? i struggled to learn about it via the manual, as i don't know xpath other than in guile. <mooseball>(manual on sxpath has no examples, is v hard to follow, compared to other sections which i mostly find v clear.) <mwette>mooseball: I've been working on a doc on and off for a bit but keep pushing it to back burner. Lemme check ... <mwette>I typically use the explicit procedures over `sxpath'