IRC channel logs

<aggi>ok.

<aggi>currently MES-replacement does need pre-compiled binaries (tcc_cc/stack_c) still, too pnut does; both of which is appropriate for faster testing

<aggi>i'll checkout tcc_bootstrap_alt/ and tcc_simple/ from cosinusoidally next

<aggi>if tcc-0.9.2 was required this will limit the who approach to ARCH=x86, which is appropriate for my use-case here, and leaving all other ARCH to cross-compilation setup

<aggi>GNU mes may not introduce a limitation to any ARCH i think, which is a relevant criteria, but i'll postpone this one for a moment

<aggi>with regards to various tcc-versions involved, i've noticed some peculiarities many years ago already

<aggi>to compile linux-tcc/tccboot, initially tccboot used tcc-0.9.21, that was known to suffice, and this version did not have any dependency for an external libc i think

<aggi>i need a day or two off, without coffee

<LaurentH>aggi: catching up on the messages from the last few days, but pnut-exe can bootstrap from M2-Planet and produces the exact same tcc-0.9.26 checksums as Mes, so it should be relatively easy to swap Mes for pnut-exe for a faster development cycle, no need for precompiled binaries

<LaurentH>I really should finish https://github.com/fosslinux/live-bootstrap/pull/554

<aggi>hi LaurentH, didn't pnut-exe need a shell-interpreter?

<aggi>the one available is kaem at that stage

<LaurentH>Yes and no, if you're bootstrapping pnut-exe from pnut-sh, yes, but I recently ported pnut-exe to M2-Planet to allow bootstrapping from stage0: https://github.com/udem-dlteam/pnut/pull/208

<aggi>ok. that's very interesting then.

<aggi>in total that is 3 options for a stage0-bootstrap: GNU mes, tcc_bootstrap_alt, pnut

<aggi>and a 4th option to re-confirm bit-identical output together with dependency tracking with T-diagrams: MES-replacement

<mwette>ACTION released nyacc-3.04.0 for the mes folks

<ekaitz>mwette: <3

<stikonas>aleksi: were you able to test nyacc 3.04.0?

<stikonas>(with mes?)

<stikonas>I've now got unhandled exception: unbound-variable: (syntax->datum)

<stikonas>not sure if that's the same issue you saw with missing tokens that you mentioned on the bug

<stikonas>ekaitz, janneke: do you understand this error?

<ekaitz>we do yes

<ekaitz>but not the context

<ekaitz>that's afaik a macro expander error that is not able to convert a syntax object to a symbol or a number or something like that (a datum)

<stikonas>oh, I wonder if that needs psyntax.pp :( which would be a circular loop

<janneke>syntax->datum is a syntax-case primitive, mes does not support syntax-case (yet)

<janneke>but we don't know where it's coming from

<janneke>there is the prospect of integrating popsyntax, but that hasn't been done and promises to be very slow

<janneke>i've also got no idea what the requirements to the core are in order to support popsyntax

<stikonas>oh well, maybe we'll have to wait then

<stikonas>I guess it comes from module/nyacc/lalr.scm

<stikonas>yeah, backtrace shows grammar-symbol

<stikonas>so it is that file

<stikonas>ok, I guess I'll need to apply parts of the patch by tsample; https://github.com/Googulator/nyacc/commit/c301626b5883378f07be68819d88cd4c4897876c

<janneke>looking at that patch, it might even be worth trying adding: (define syntax->danum identity) somewhere

<stikonas>janneke: ok, I've just patched it out, same complexity as defining identity

<stikonas>it's running now

<janneke>stikonas: nice

<stikonas>anyway, what we have is now much more maintainable (if that run that I started succeeds)

<stikonas>tsample's patch was much more invasive

<stikonas>so thanks again to mwette

<janneke>yeah, hear hear

<mwette>reading the logs; ugh, I have to check reserved?

<stikonas>mwette: I've sorted out mach.gen run, it now created a few files .gram*.txt

<stikonas>thoufh I guess I need to copy them somewhere?

<stikonas>mescc now complains unhandled exception: error: (("include-from-path: not found: " "nyacc/lang/c99/mach.d/cpp-act.scm"))

<mwette>reserved? fix, maybe: https://paste.debian.net/hidden/0c1eeaaa

<stikonas>mwette: no, I think my issue was that mes didn't have syntax->datum

<mwette>Those belone under c99/mach.d/ like they were a while ago. But now they are not part of the distribution but created in the build process.

<stikonas>not reserved

<mwette>lemme chekc

<stikonas>ok, that's fine, I need to look at Makefiles

<stikonas>anyway, I"ve worked around that syntax->datum issue in mes by patching it out

<stikonas>it's a one-liner patch, not a big issue

<mwette>Yes, but for mes, reserved? is used in a define macro, let me fix better

<mwette>hang on ...

<mwette>this one: https://paste.debian.net/hidden/092228fc

<mwette>I could update in a 3.04.1, but let's deal with the other issues.

<mwette>the production of gram.txt files in mach.gen is not needed; I use that to debug parsing errors (where it reports the state where the parsing error occurs)

<stikonas>ok, thanks. I think I understand now. Earlier I've somehow got confused that now it's gram instead of cpp-act.scm and friends

<ekaitz>stikonas:

<ekaitz>checking whether the C compiler works... configure: error: in `/tmp/guix-build-gcc-muslboot-4.6.4.drv-0/gcc-4.6.4/riscv64-unknown-linux-musl/libstdc++-v3':

<ekaitz>configure: error: cannot run C compiled programs.

<ekaitz>If you meant to cross compile, use `--host'.

<ekaitz>does this ring a bell?

<stikonas>--host is your current system

<stikonas>for cross-commpile you need --target

<stikonas>I thnk

<stikonas>well, you might need to specify both

<ekaitz>this is the riscv bootstrapp

<mwette>In my experience (doing x-compilng), "cannot run C compiled programs" means the cross-c linker could not find a crt0.o

<ekaitz>yeah... or maybe that the compiler is dead

<mwette>haha, that too

<ekaitz>idk why it's trying to build libstdc++ if it only has --enabled-languages=c

<stikonas>which GCC?

<stikonas>oh 4.6.4

<ekaitz>gcc-muslboot-4.6.4

<ekaitz>:)

<stikonas>hmm, that should still be fine, that one is still written in C

<stikonas>with later ones I guess 3-stage build first builds C++ compiler

<stikonas>hmm

<stikonas>perhaps something with guix prefixes makes it not find some files as mwette suggested

<ekaitz>yeah... hmmm

<ekaitz>it's hard to find what is actually failing

<ekaitz>the config.log doesn't say much

<stikonas>well, try to run the last failing command manually

<stikonas>and see from there...

<stikonas>strace it perhaps

<stikonas>see what files it is trying to open

<ekaitz>i don't find where the actual command is lol

<ekaitz>okay yeah it's trying to run a.out

<ekaitz>but i don't find it anywhere

<mwette>this is the modules/Makefile snippet you should see: https://paste.debian.net/hidden/dc08e012

<stikonas>yeah, I've got it working now I think

<stikonas>I've split it into 3 separate scripts...

<mwette>makes sense

<mwette>much of cpp.scm is totally rework, so I would not be surprised to see cpp errors

<mwette>though all my tests are passing and nyacc parsed all of glib, gobject, gdk, gtk

<mwette>(headers)

<ekaitz>damn dude i have no idea of where are these configure scripts building the thingies

<stikonas>for gcc? they are in subdirectorie

<stikonas>since gcc is a collection of subprojects

<ekaitz>i literally run `find -name a.out` and it's not anywhere

<ekaitz>hehe

<stikonas>a.out might be temporary file

<ekaitz>yeah

<stikonas>I wouldn't be surprised if you can't find it

<ekaitz>ACTION hates when they are not left

<stikonas>ok, I think generation of mach.d suceeded but mescc now fails with unhandled exception: not-a-pair: ("EOF in list") which I think is the issue aleksi mentioned in that bug

<stikonas>in sting-every in mes/module/srfi/srfi-13.mes

<ekaitz>is that a mes bug or a nyacc?

<ekaitz>if it's mes' i can fix

<stikonas>ekaitz: mes probably

<stikonas>see last comments in https://github.com/mwette/nyacc/issues/59

<ekaitz>okay yeah

<ekaitz>let me see what string-every is supposed to do

<ekaitz>yes, there's missing path there

<ekaitz>stikonas: can you try to patch mes really fast?

<ekaitz>just to make sure you don't get that error

<ekaitz>in that function there's a #t

<ekaitz>that i don't think that should be there

<stikonas>sure, let me check

<ekaitz>in the end of the line of the `or` there's a `#t`

<ekaitz>hehe we should ask janneke about it

<ekaitz>it's a very funny bug

<ekaitz>janneke: 44133033a0ecc6fefdc1945776c5343c3263204c

<ekaitz>i'll send the patch anywa

<mwette>look at nyacc/lang/util.scm: string-every is defined for mes

<ekaitz>mwette: (or something #t something-else)

<ekaitz>mwette: imagine what happens

<mwette>but not used; never mind

<mwette>string-only only seems to be used in nyacc/util.scm

<mwette>as `(string-every #\space str)'

<ekaitz>stikonas: with that change at least something should change

<stikonas>yeah, I'm testing it now

<ekaitz>stikonas: i missed working with you

<ekaitz>:)

<stikonas>if that doesn't work, I'll try nyacc implementation

<stikonas>yeah, I know...

<mwette>If you look at the code nyacc/lang/util.scm maybe that is correlated

<stikonas>though it was very busy time too

<ekaitz>yeah, it was

<mwette>it looks somewhat similar

<mwette>for mes, the string-length should be pulled out of the loop

<ekaitz>yeah, that's true, too

<ekaitz>well, now I'm thinking ... string-length should be just a simple check

<ekaitz>it is a builtin... that would have a little bit of overhead

IRC channel logs

2026-03-07.log