IRC channel logs
2026-04-29.log
back to list of logs
<apteryx>old: I see; thanks for the explanations. In this case, perhaps our documentation of 'spawn' could be extended to mention that the ports used for its arguments must be file-backed ports? <dsmith>apteryx, That is a *very* good idea <old>apteryx: The proper thing would also be to throw an exception that is more detailed <ekaitz>civodul: you wanna hear something funny? <ekaitz>civodul: the lightening pipeline was not triggered because woodpecker cannot read the files when they start with a comment <ekaitz>since 5 months ago the CI has been broken because I added a license header to it <cow_2001>which tokenizer and/or parser would you choose out of all the guilish tokarser? <cow_2001>there's (ice-9 peg), the lalr thing, outside libraries nyacc and stis <ekaitz>cow_2001: depends on what you want to do <cow_2001>i'm reading a book, right? it's about writing a compiler <cow_2001>and i'm trying to translate its javascript ohm library stuff into (ice-9 peg) <cow_2001>you set up an "identifier" rule for things that are "[_a-zA-Z][_a-zA-Z0-9]*", but there's also a rule for things that are like "let x = 1;" and i don't know how to tell it not to read "let" as an identifier <ekaitz>so if matches "let" first, it won't try to match an identifier <cow_2001>an alternative to telling the peg system not to read "let" as identifier is to have another step scanning for non-LetStatement use of the reserved keyword "let" <cow_2001>ah, but the thing is that the rule above it is: <ekaitz>cow do you want to see a huge PEG example of a working language? <ekaitz>(the syntax of zig is quite heavy) <ekaitz>cow_2001: I think I made ice-9 peg compatible with it, yes <cow_2001>ekaitz: do you think there's worth in a bytes based PEG, in addition to the string based PEG? <ekaitz>hmmm what do you mean by bytes based PEG vs string based? <cow_2001>i casually complain about stuff with some guy on irc and it's the author of the library. what a world <cow_2001>match-pattern takes a PEG rule and a string <cow_2001>why not a similar match-pattern that takes a rule and a u8vector? <ekaitz>(i'm not the author, i just added a few things) <ekaitz>in that line i think rlb is working on making strings use utf8 <ekaitz>which would make them become a bytevector-u8 i think inside <ekaitz>hmmm there are better tools for reading binary aren't there? <ekaitz>did you get the keyword example? <ekaitz>cow_2001: also you should read the original PEG paper, it's very easy to read and in the first pages explains how it works <ekaitz>basically it tries to match a rule, if it fails it backtracks <ekaitz>you can do that, with a "not" rule <ekaitz>and I think you can also make it work with the order of the rules carefully chosen, but don't take my word on that <ekaitz>wikipedia has a very good explanation too <cow_2001>ekaitz: printed. the bastard printer was told to print it on both sides but it spitefully printed it only on one side, and gave me the last page as an error, so i had to reprint the last page... even though it's probably just the parting words and a bunch of references, but i didn't get there yet <jcowan>I'm going to have to parse PL/I with a PEG grammar, because there are no reserved words and no LET keyword. <jcowan>up till now I think all PL/I parsers have been ad hoc <jcowan>Every statement except an assignment begins with a keyword, but those keywords are also legitimate identifiers <jcowan>"IF then = else THEN else = then ELSE else = if;" is legitimate (it's case insensitive) <spk121>Heya. If any committer has spare attention, PR 174 (a macro left-shift overflow) is good to go, and in PR 141 (updating gnulib) I've addressed all the comments received so far. <ekaitz>civodul: looks like the CI is actually doing something now but it fails because it doesn't detect the binfmt-support package? <ekaitz>is here any debian(-like) user that help me with this? <ekaitz>the same pipeline description that worked 5 months ago doesn't work today <ekaitz>> /bin/sh: 3: ./test-aarch64-absr_d: Exec format error <ekaitz>i'd say it's not able to find that binfmt-support... <ekaitz>(the context is lightening's CI) <spk121>ekaitz: perhaps 'file ./test-aarch-absr_d' would provide some info <ekaitz>spk121: i don't have access to the pipeline machine <ekaitz>i would need to replicate the setup... <ekaitz>the very same pipeline worked a few months ago <mwette>I see four packages in search for Term::Readline: libterm-readline-{gnu,perl,ttytter,zoid}-perl <mwette>maybe one of will work. The gnu one is based on gnu libreadline <mwette>But can't find the pipeline code. Can you ref it? <ekaitz>this looks like some weird debian issue but i don't know what it is <ekaitz>i can try to restart an old successfull pipeline <ekaitz>oh re-launching old ones also fail! <ekaitz>it has to be on the CI machine side <rlb>ekaitz: happy to try to help. <ekaitz>rlb: if you could find a way to fix the ci script or at least replicate the issue, that would be great <rlb>If you haven't seen it. <rlb>Also looks like qemu-user-static has maybe moved to qemu-user. <rlb>Oh, and is this debian, or debian-ish (e.g. ubuntu)? <rlb>Oh, I guess likely debian proper from the .woodpecker.yml. <mwette>ekaitz: I will try via docker on aarch64 box w/ debian:latest container <rlb>ekaitz: might also be worth running that arch-test and/or hello just to make sure they work. <rlb>If I can't test locally, I typically just create a temp branch/pr and use it to test via push, and "git commit --amend --reset-author --no-edit" if I need to force a re-run without changing anything ;) <rlb>(also, of course comment out all the other nodes) <rlb>Is "stable" there trixie, I assume? <rlb>My offhand guess is that binfmt-misc support is messed up there somehow... <ekaitz>mwette: but the compilation process is successful <mwette>no -- I can't compile a "hello, world" program <mwette>but apt says binutils-aarch64-linux-gnu is installed <mwette>`find /usr/lib -name as` blank; but /usr/bin/aarch64-linux-gnu-as is there <rlb>ekaitz: do you have a way forward, or should I start trying to set things up to test here too? <ekaitz>rlb: please try, because I'm very bad at configuring things and I'm 100% going to screw it up and then think the issue is somewhere else <ekaitz>ACTION is aware of his limitations <ekaitz>ACTION is also working on 10 things at the same time, and that doesn't help <rlb>Heh, OK, I'll see what I can figure out in a bit. Though I'm no expert on the mult-arch / cross-compilation side. <rlb>As an aside (and no one should waste much time on this if it isn't obvious) I was toying with changing one of the string tag bits (not critical, but might be slightly desirable if we pursue inline, immutable strings), and I thought I found all the relevant changes (assembler too), but it ends up crashing like this: https://paste.debian.net/hidden/9134fe95 <rlb>I'll probably just (and should) let it go in a bit --- guessing we have some code that's building the string without using the functions it should, and so doesn't set the inverted flag now. <rlb>(aside from the assembler and SCM_IMMUTABLE_STRING --- fixed those) <ekaitz>rlb: did you change the content of the docs? <rlb>but I do have to make clean <rlb>because the string type changes (to have inverted meaning for that flag bit) <rlb>I think, but don't know, that the error's likely just s symptom. i.e. I think it's just encountering a "bad" string. But maybe it's something simpler and I just need more (or less) coffee. <rlb>Mostly just wondered if that error rang any bells. <rlb>ekaitz: I suppose the issue could also be some codeberg-side runner change. <ekaitz>yes, it could be, but I'd like to make sure this is not just a debian error <ekaitz>or a container error or something <mwette>rlb: Do you know if there's a debian package that would make symlink from /usr/bin/as to /usr/bin/as-aarch64-linux-gnu? <ekaitz>i want to avoid reporting to them because that will take time <rlb>mwette: that's almost certainly managed by update-alternatives(1) <rlb>unless gcc does something custom <mwette>well, on my aarch64 ubuntu system (24.04) /usr/bin/{as,ld} are symlinks to aarch64-linux-gnu-{as,ld}, respectively <rlb>looks like it's handled by binutils <rlb>I suspect you shouldn't need to do that... <mwette>ekaitz: maybe `- if [ ! -f /usr/bin/as ]; then ln -s aarch64-linux-gnu-as /usr/bin/as ; fi' and same for ld <mwette>(if that works in a pipeline file) <ekaitz>the only difference i find, mwette is the pipeline log actually build things, the build step doesn't really fail <mwette>Is it possible the error came from the first attempt to compile and you just got a indirect error message? <rlb>I didn't need to do anything about as in a debian trixie debvm (debvm is *handy* if you're on a debian system). <rlb>and ekaitz - following the woodpecker file, works just fine for aarch64 here in that vm. <rlb>i.e. the test build and run <rlb>So I'd guess some runner change, or something. <ekaitz>rlb: does it run the tests? and they pass? <rlb>after building the vm <rlb>ekaitz: did that arch-test and/or hello work for you in CI? <ekaitz>we could add another step that does that <rlb>Or just stick it at the top of the node's instructions for a test run on a branch/pr? <rlb>(and perhaps comment out the other nodes to save some trees ;) ) <rlb>"apt install hello:arm64 && hello" also works in the vm <mwette>ekaitz, rlb: if I `apt install binutils' I get the symlinks <rlb>And did you see: "If the hello command doesn't work, try sudo hello instead. If that works, you may need to set the vm.mmap_min_addr=0 sysctl option before programs will run as a non-root user." <rlb>Might try printing that setting too --- maybe they changed that or something. <rlb>Though if you're actually root, should be fine? <rlb>(and you must be, or at least root-ish ;) ) <ekaitz>i'll make a new temporary branch for these tests and commit a lot of garbage to codeberg hehe <rlb>temp branches are *fine* :) <rlb>Just get gc-ed eventually anyway, if you delete them when you're finished. <rlb>But yeah, I'd likely test those bits next, since if they don't work, nothing will. <ekaitz>i'll paste this in the issue I opened just to make sure that I don't forget this <mwette>the pipeline must be running as root (inside the container) since you can run apt <rlb>right (plus or minus variants like fakeroot, etc.) <mwette>It's odd that gcc has the aarch64-* prefix but does not look for aarch64-*-as. I wonder if the package was generated with a valid `as' round. <rlb>You installed gcc:arm64 and not the native gcc? <rlb>(if you're doing multiarch) <rlb>(wondering if that might explain what you see, though not sure I'm following, entirely) <mwette>I installed gcc-aarch64-linux-gnu according to the pipeline cmds <rlb>right, but that just gives you the aarch64 suite, gcc is likely still the native gcc. <mwette>I was wondering if it is necessary. Maybe "gcc" instead of "gcc-arch64-linux-gnu" would do, but that's call for ekaitz. <rlb>i.e. you'll have all the /usr/bin/gcc-ARCH tools, but the default symlinks will still be native. <rlb>And yeah, in my vm, /usr/bin/as is still the x86_64 as, because the native gcc package is installed. <rlb>But the build uses the aarch64 variants. <rlb>(I assume, since it works.) <mwette>But it seems that the build for gcc with the prefix should look for similar prefixes for the binutils programs. Could there be an error in the cross-gcc builds? <rlb>I'm not sure I understand what your problem was, but the woodpecker.yml "make -C tests ..." works just fine in a current trixie vm here. <rlb>set up according to the woodpecker.yml's commands. <rlb>(with current lightening main) <mwette>The ci did not run in a docker running debian:latest on aarch64 machine. Maybe it's something with the docker. Maybe ekaitz can conver his pipeline to use the trixie vm. <mwette>Is installing "gcc" over "gcc-aarch64-linux-gnu" a possibility? <rlb>gcc is a metapackage that just "adds" --- I doubt it has any overlap with gcc-arch64. <rlb>i.e. I suspect it's mostly just the arch-based symlinks. <rlb>See dpkg --listfiles gcc. <rlb>And I assume if you install gcc, you get the native links, if you install gcc:ARCH you get those arch symlinks, etc. <rlb>But was as even a problem in the CI log? <rlb>Looked like a multiarch exec support (binfmt-misc) issue offhand to me. <ekaitz>no, it was just a binary format issue <mwette>ekaitz: Is this running on qemu? <ekaitz>it's the codeberg woodpecker, idk what it is <ekaitz>ofc I just tried something and the CI is down now...