IRC channel logs
2026-05-01.log
back to list of logs
<apteryx>when would you use a fluid vs a parameter in Guile? The former has fluid-set!, which seems useful when wanting to change its globally known state? <lilyp>fluids are low-level parameters; you typically want the latter, but for old/low level code, fluids exist <apteryx>something as simple as a boolean option switch in autoconf is code right. tells a lot. <apteryx>TIL; --disable-something=yes and --enable-something=yes register the same enableval <apteryx>not technically supported to use an argument with --disable, so that explains some of it: (info "(autoconf) Package Options") <ArneBab_>ekaitz: merged it. Thank you for the ping! (that was really easy to review ☺) <ekaitz>next I have to read all the PEG improvements :) <ekaitz>looks like codeberg CI is back up <regtur>ekaitz: When you are curious as to how PEG might deal with partially valid input, please have a look at the documentation of the fall-back enhancement and then the patch :) <ekaitz>regtur: sure! i also have zig-spec somewhere so I can test against that <ekaitz>rlb: arch-test only returns i386 and amd64 <ekaitz>now it's the debian wiki what's down <ekaitz>things are getting better anyway, I added the license comment on the top and woodpecker still takes it <ekaitz>and now I have something that I can use for testing <ArneBab_>ekaitz: can you get the debian wiki via archive.org? <ekaitz>i'm so frustrated i didn't even think about it <ArneBab_>I can imagine … (the web seems pretty brittle these days) <ekaitz>sudo apt install libc6:arm64 says the package doesn't exist <apteryx>is it possible to parse with guile-json some map like object where the key is anything and the value a string? <janneke>"the" (an?) emacs json parser seems pretty forgiving, iirc <mwette>apteryx: to set parameter a to 1, use (a 1) <apteryx>lilyp: thanks (re fluids vs parameters) <apteryx>which is an loosely defined object (keys are not known in advance; they represent user-provided labels) <spk121>Trying to build Guile in OpenBSD. Had to disable JIT since in OpenBSD you can't have a mmap be PROT_WRITE and PROT_EXEC at the same time. <spk121>You can have a writeable mmap, but, when you want to use it for exec, you need to mark it read-only first. <spk121>Also, OpenBSD's makeinfo throws an error for our texi for SRFI-207 not having proper sectioning, like an 'Up' field. <spk121>Tho, if I recall corectly, 'Up' nodes have been optional for a very long time. <ArneBab_>spk121: does it also throw errors for others? I don’t see structural differences between @node SRFI-197 and @node SRFI-207 -- except for one more colon in 197 <spk121>It says this ' /home/runner/work/guile-build/guile-build/guile/doc/ref//srfi-modules.texi:7857: `SRFI-207 Acknowledgements' has no Up field (perhaps incorrect sectioning?).' <apteryx>re my guile-ssh problem; I think it's not an issue. If I don't map an object to a type, it'll be parsed the usual way, as a malleable alist. <ArneBab_>spk121: that’s the last subsubsection of 207 <spk121>I haven't really investigated, I'm just looking at CI output <ArneBab_>ah -- it starts with "unreferenced field", so the issue may be that SRFI-207 has no menu. <apteryx>another trick for guile-ssh: if you don't care parsing a field, you can simply omit it from the json-type you define <mwette>While on this topic, the guile module (texinfo) is out of date I'm looking to update, but not completely. Notably missing are single-char, non-alpha commands like `@*'. <mwette>The other issue is how to handle flags (via set, clear, ifset, ifclear). <spk121>Is Guile's (texinfo) worth saving, I wonder? The GNU Texinfo project is alive and well. <mwette>I want to convert .texi to .md and pandoc output is sad looking, so I started to look at (texinfo) as a way to do it myself. <mwette>I thought it might be easy to extend, but processing flags adds state. <apteryx>I now realize all these fields I could have done without ^^' <jcowan>apteryx: The answer to your JSON question is no. JSON, following JavaScript, supports only keys that are strings. <jcowan>Of course you could ad hoc stringify anything else, but it's problematic. <apteryx>my original (perceived) problem was how to use the structured guile-json types to parse something partially unstructured <apteryx>the answer was to not define a structured type for the unstructured object; guile-json parses it as a plain alist then <apteryx>(the keys were all strings, just arbitrary strings) <apteryx>it's getting late here; have fun, guilers! <jcowan>(Also, control characters are forbidden in JSON strings, except for line terminators. <ArneBab_>spk121: (texinfo) may not be up to date, but we don’t know whether it’s used, so we can’t remove it and updating it is the way which improves the code we ship. <jcowan>I am making that very point to the incipient JSONSCHEMA WG, whose charter says "the working group may remove features <jcowan>and mechanisms it is (a) confident are not in use and (b) are likely not to be used in <jcowan>How do we determine what satisfies point (b), a crystal ball? <jcowan>There have been five WDs already, and whereas the latest JSON RFC is only 16 pages, the WD for JSON Schema is 98 pages. <jcowan>A vicious example of the second-system effect. <samplet>lechner: psyntax is a macro expander (providing syntax-case). When the article talks about eager expansion, that’s psyntax. <samplet>(An interesting read as usual from the wingolog.) <jcowan>My favorite wingolet is the one that talks about which Scheme to use for what. <rlb>ekaitz: did you still need help wrt the multiarch bits? Offhand, I wouldn't have expected you to need to install libc:ARCH directly... <rlb>(And the wiki's responding here now, though very slowly.) <rlb>But if it can't see packages, that's probably because either the /etc/apt/sources* don't include that arch, or they do, but "apt update" or "apt-get update" hasn't been run since they were added. <rlb>oh, right, just the latter. <rlb>i.e. make sure you run apt-update after adding the arch via --add-architecture <rlb>"apt update" or "apt-get update" I meant. <ekaitz>rlb: the arch-test continues to report that <ekaitz>basically it doesn't include the added architecture <rlb>and it does show up in dpkg --print-foreign-architectures? <rlb>oh, right arch-test is broader, I'm guessing, dependent on binfmt-misc, etc. being set up right, or similar. <ekaitz>rlb: calling with qemu-{arch} works <ekaitz>maybe we have to use that instead <rlb>The qemu user emulation should work, if it's a regular debian system, but I don't know whether or not container/etc. might affect things. <rlb>I assume you installed qemu-user-binfmt and qemu-user? <ekaitz>it looks like for binfmt_misc it requires some kernel module <ekaitz>so the containers may not have that when the host doesn't <rlb>Right, I assume they wouldn't. <ekaitz>wait a second, maybe a few packages have changed <ekaitz>I do this: - apt-get install -y make binfmt-support qemu-user <rlb>There's also that sysctl vm.mmap_min_addr=0 --- but I have no idea what a failure related to that would look like. <rlb>(at least I assume so, from there, and I do have it installed on my main machine...) <rlb>I believe that's what handles the automagic execution redirection... <rlb>Does binfmt_misc show up in "lsmod | grep ..."? <rlb>(I agree that I think that's probably relevant, but I'm not certain.) <ekaitz>i don't know if I should add that or just change the makefile to use the qemu-* binaries directly <ekaitz>probably the second option is simpler, i reduce the amount of packages to install and everything is happier <rlb>Oh, if you mean add binfmt_misc --- you probably can't, i.e. has to be enabled on the host as you said, I'd assume. <rlb>(if you're just in a container) <rlb>I'm assuming that qemu-user-binfmt hooks in to that... <ekaitz>i'll just call `qemu-whatever &test` and leave <ekaitz>ACTION triggered the CI like hundreds of times today (: <ekaitz>okay added an extra input to the makefile that says which qemu-binary to use just in case <ekaitz>i need to do some engineering in the tests <ekaitz>because that makefile... is going to make things difficult <ekaitz>made them all pass, but i did some tricks <rlb>That doesn't seem too bad --- and could always abstract it a bit more if it mattered, i.e. "${LIGHTENING_TEST_ENV:-env}" there or something, perhaps eventually useful for someone for other reasons. <rlb>And I suppose drop the double quotes if you *want* to allow more arbitrary injection. <ekaitz>i'll rewrite a little bit and try to use qemu in every case or select the arch in the CI just to make sure <rlb>Then anyone could "LIGHTENING_TEST_ENV=foo-env make check" if they needed something special... <ekaitz>but idk i want to make it easy for people to run tests locally too <ekaitz>without having to worry much about things <rlb>Oh, I see, you want to autodetect quemu and dtrt. <ekaitz>yeah.. we already know the platform in the test target <rlb>Could also right that up in the makefile via "judicious" (...) use of $(shell ...) and .SHELLSTATUS <rlb>Not saying you *should* do that :) <rlb>Also to do it sanely probably requires gnu make, and "new enough". <ekaitz>ACTION wonders if he is good at anything <rlb>I'm less likely to be adventurous there without .SHELLSTATUS --- it's doable, but much uglier (to get it right). <rlb>Anyway --- can probably do something fairly simple that's just fine, and maybe preferable to fancy :) <ekaitz>i'm also interested on not using -native at all <rlb>But if you want to detect a command from the makefile, "command -v CMD" is portable, and the exit status lets you know. <rlb>i.e. cmd := $(shell command -v something) and then check .SHELLSTATUS via ifeq ... etc., though perhaps also enough in that case to check for the empty string... <ArneBab_>jcowan: "likely not to be used" is a hard question, yes. thank you for asking that! <ArneBab_>jcowan: and regarding point (a): chrome and firefox said "almost no one is using theora, we can remove it". The result was that a lot of pages I use got broken, and most of them still are. Because going through a lot of pages with actual content and updating them actually takes work. And much more work than they are saving by not maintaining theora. My point: they thought it weren’t in use and they broke a lot, including the hardware <ArneBab_>token of a brasilian bank. The idea that you can find out what people use is usually wrong. <ekaitz>rlb: maybe you can help me with this <ekaitz>that i made so I can put qemu-blablablah in VIRT <ekaitz>but I want to be able to `guix shell -s $system -- ./program` <ekaitz>do you have any magic trick for me? <rlb>"what" doesn't work there? (I'm also not familiar with guix shell). <ekaitz>putting `guix shell blablablah --` in VIRT <ekaitz>it doesn't just concatenate and have fun <rlb>You mean that it's treating the expansion as a single "word"? What's the error? <rlb>I'd guess the issue is at another level, but I can take a look if it's pushed somewhere, or you want to paste the relevant bits. <rlb>I'd also suggest maybe some lightening-specific prefix on the var; it looks like lightening already uses/reserves jit in C, perhaps JIT_TEST_ENV or something, but maybe I'm just overly inclined to avoid potential collisions... <rlb>What's the right way to compile libguile (at least) without optimization? "make CFLAGS='-g -O0'" doesn't work because looks like we don't still include some required args. <rlb>Perhaps a reconfigure will do it, if a bigger sledgehammer than I wanted... <rlb>I think the problem is that (if we meant to), we didn't treat a make-time CFLAGS as an addition to whatever else is always required, instead of clobbers at least some of them. <mwette>just checked: pretty sure `make CFLAGS+=-O0' works <rlb>I believe I tried that and it didn't work -- failed in filesys.c on undeclared O_BINARY, but I can test again later; maybe I did it wrong. For now I just reconfigured. <mwette>Is there a way to check if the binary is O0 ? also, I had to add -std=gnu11 <rlb>I wouldn't worry too much about it, this is also on the utf8 branch which has a lot of changes, so that could be involved. <mwette>+= does not work; I checked w/ a simple Makefile <mwette>I think automake sets up some persistent "CFLAGS". <ekaitz>i'm too excited, may impulsively rebase and merge <rlb>Hmm, not sure. I'd have to think about that more later. Selfishly, I'd have it just use qemu when it's available by default, i.e. doesn't matter how you have it available, rather than default to guix. <rlb>i.e. more "delivery agnostic" <ekaitz>there were calls to guix environment for the compiler <rlb>In any case, if I get a chance, I'll think about it a bit more later, but don't let me hold you up :) <ekaitz>also it's interesting because guix shell doesn't work for arm haha <rlb>If I do poke at it later I'll shout. <ekaitz>yeah, great, I'll leave it there for a few days <rlb>right now I'm trying to diagnose sefault compiling psyntax after I messed with the string layouts again :) <ekaitz>it wouldn't hurt anyway, it's not critical and doesn't affect the code <rlb>(hence the gdb questions) <rlb>or rather -O0 questions <rlb>something's building a (wrong) string that's not strings.[hc]... <ekaitz>ACTION runs away before getting interested by what rlb is doing <rlb>(it's probably me, via a mistake in the related assembler changes...)