IRC channel logs
2025-03-29.log
back to list of logs
<lilyp>old maybe you want to use a variable? <lilyp>modules and variables are first class citizens in guile <old>lilyp: variable don't evaluate to the value in them. you need to do variable-ref <lilyp>true, but if you're making a module, you can reference it like any other variable <lilyp>the only other thing you could use are thunks with setters <old>basically I have a <computation> record, kind of like delay/force <lilyp>but those require an explicit function call <old>but valid under the dynamic extent of a run-with-states <old>a computation is simply a thunk that get memoize under a dynamic extent of states <old>But I want to avoid having to do: (run-computation x) <old>It's like you have (delay expr ...) and I would like to avoid having to do (force promise) <old>and just do: promise <old>anyway, I don't think this is possible without the help of Guile in C in the VM or something like that <lilyp>hmm, would be an interesting idea to implement lazy variables <lilyp>yeah, they'd be a solution to the problem at hand <spk121>I've been evaluating a couple of different sets of 64-bit patches for Guile on Windows. Basic 64-bit Windows problem: longs are 4 bytes, pointers are 8 bytes, Guile expects pointers fit in longs, blah blah <spk121>There's really just two strategies over different projects' patchsets: (1) use intptr_for long, uintptr for unsigned long, or (2) make a typedef for a long_t ulong_t. Neither of those would change the ABI on GNU/Linux. <spk121>Lilypond has been carrying patches for a couple of years for their Lilypond on Windows build. <spk121>I'd like to find a consensus, but, historically, this isn't an important issue to most Guilers / Guixers. <rlb>spk121: ideally, I might like to see what wingo's opinion is, in case any of it relates to the prospective compiler and/or gc stuff he's been working on. <rlb>Also, if it helps, if we get closer to a candidate, I can probably double-check it on some archs if I have access to any that you (y'all) don't via the debian porterboxes, etc. <rlb>In the end, I might only care if one or the other is better one way or another from a "better type for the long term public api" perspective (as long as neither breaks any existing, relevant platforms/ABIs). <spk121>rlb: Would be great to check a patchset on debian's boxen when its ready <spk121>I feel like the best strategy would be to just have a mostly uniform GNU/Linux-like ABI for 64-bit platforms for the libguile <rlb>ok, just shout -- not sure if I'd want to run that through the actual buildds via experimental, but I could certainly spot check it on powerpc, (32-bit big-endian), s380x, riscv (though that one's a bit painful atm time-wise) etc. <rlb>Yeah, I'm just perhaps a touch (too?) paranoid (cautious?) about C wrt typing and what's "specified", etc. <rlb>Either might be just fine. <spk121>wingo: how annoying would it be for you if I replaced all the 'long' and 'unsigned long' in libguile with 'long_t' and 'ulong_t' to I could make 64-bit windows work. Or a couple of years ago we and janneke discussed making longs into intptr_t <rlb>spk121: any idea if we have any regular testing of abi backward compat? e.g. testing "existing, compiled, client code" (even if just ours) against the current build's .so or something. (Be nice to have.) <spk121>rlb: for elf, it should be easy enough to run abi-compliance-checker. Tho I've never done it for libguile. For COFF (Win32) it is kind of a non-issue since it needs to work first <rlb>hmm, TIL abi-compliance-checker -- might take a look if I get time. Thanks. <rlb>(be really nice to just always know we haven't made a mistake)