IRC channel logs
2025-12-01.log
back to list of logs
<lechner>Hi, how may I programmatically 'define' variables, please? As in (apply define 'hello 1) ? <mwette>look at the module reflection section in the manual <lechner>Hi, module-add! creates great bindings. How may I export them, please? <mwette>(module-define! (current-module) 'abc 123) (export abc) <mwette>Sorry. That prob won't work for you. Not sure. <lechner>mwette / i am hoping to do so programmatically <lechner>mwette / the undocumented module-export! from (ice-9 boot) will do it, like this (module-export! (resolve-module '(elf runtime)) '(%page-size) #:replace? #f) <lechner>mwette / as always, thank you for your help and company---as well as the formidable Nyacc and CDATA modules <lechner>Hi, when exporting data that varies between architectures, such as from the ELF auxiliary vector, should I instantiate missing data with #f or not define the variables? I never learned how to use defined? properly and find it inconvenient. Thanks! <rlb>dsmith: caught us ;) Sill have to update the website and online manual, which I should be able to do tomorrow, and then we can announce it. <tohoyn>daviid: BTW, could you look at lines 132-152 of the server? Is there any cleaner way to get the interface out of the introspection data? <tohoyn>daviid: In order to test the code launch the server in a terminal window and then the client in another terminal window. The client should print some output and you can close both programs after that. <tohoyn>daviid: use the following command to build the c client: gcc c-client1.c -o c-client1 $(pkg-config --cflags --libs gio-2.0 glib-2.0) <rlb>ArneBab: civodul already tagged 3.0.11 --- and I thought that had been deferred. <efraim>oh, I'll test build 3.0.11 on some of my architectures to make sure they build correctly <dsmith>So. In the past there have been several instances of a release x.y.z and very soon after a x.z.z+1. What about doing a -rc release for people to test before the final release? <rlb>Could, though I think we've done a good bit of testing --- something we could discuss for future releases, though hopefully the bar should now be lower for our next Zs, as long as we keep main in shape. In any case, too late now; tag's made and archives are already available. <rlb>I'm just working on the website and doc changes (first time I've handled that, so having to set things up -- haunt question not unrelated :) ). <identity>rlb: iirc {gu,n}ix uses a slightly diffferent base32 called nix-base32 <rlb>OK, thanks --- fwiw I was just wanting to use it as a "second opinion" when vetting haunt 0.3.0 --- and for that purpose, a portable encoding would be nice. i.e. checking that I have the same tree guix has been using as another bit of info. <identity>if you have guix, you can hash using ‹guix hash› <rlb>I don't atm, but not a big deal, that wasn't the only vetting, just "nice to have". <rlb>Just never used haunt before, and it's not in debian, and I'm not using guix, and I'm using it for something "important" :) so I thought I'd poke at things a bit before I run them --- often try to for new things, with possibly wildly varying degrees of diligence... <dthompson>I'm honestly a little surprised that it's still not in debian. the project is a decade old and used by a decent number of websites. <dthompson>minimal dependencies, too. nearly everything is optional aside from guile, of course. <rlb>...and being able to know that I have the same tree guix is already using is "supporting evidence" :) <rlb>But I just scanned the code --- probably would have done that anyway, since it's feasible. <dthompson>guix is using the official release tarballs with no modifications afaik <rlb>right, I'd just wanted to cross check their hash against mine after my download (rather have "their" git hash, but they're not working from git). <rlb>hmm, it looks like building the guile website does require guix, or at least requires (guix licenses)... <rlb>No idea if I can install that independently. <rlb>Also requires (guix utils) <rlb>oh, and several other things <identity>rlb: you probably can install it standalone (+ some other guix modules, i guess), it is pretty much just (define-record-type <license>) and some instantiations of it <identity>you would need to pull in, like, 6 guix modules if i had to guess <ArneBab>rlb: arg, I missed the tagging … sorry. apteryx fixed the backwards compatibility breakage. Since you already tagged, does that mean that the merged PR will go into 3.0.12 instead? <dsmith>apteryx, Without thinking about it too much, would it have been possible to detect the arity in the load hook and call it with the extra arg? <dsmith>Would need to rework all the hook stuff for optional args <ArneBab>dsmith: apteryx experimented, but the arity info wasn’t reliable. <old>** The SRFI-64 module for test suites has been rewritten <old>does this mean I can properly use test-error now <old>** The psyntax implementation has been improved <old>is there more details on this? <old>AFAIK, psyntax was not properly forwarding source-location on bad syntax <rlb>old: at least in the source tree, you can also now create srfi-64 based test-suite/tests/*.sr64 tests and they'll be picked up. <rlb>i.e. as an alternative to the traditional test-lib tests. <old>rlb: it's the first time I saw you make the release if I am not mistaken <old>(release announcement) <dsmith>rlb, Yey! Congrats on the release <rlb>thx, and thanks to everyone for all the help (including civodul, who I had to badger for help any number of times).