IRC channel logs

2026-03-08.log

back to list of logs

<stikonas>ekaitz: with your patch :unhandled exception: unbound-variable: (define-private)
<mwette>right! not a big deal (C brain at work)
<ekaitz>that's different!
<stikonas>yes... though why do i see it now...
<stikonas>it's in mes/module/mes/guile-module.mes
<stikonas>probably something for another day, getting late
<ekaitz>it's missing a macro that defines define-private
<ekaitz>literally as `define` should be fine
<ekaitz>you can see that now because the code explodes later I guess
<ekaitz>stikonas: we have this in mes:
<ekaitz>;; Mes: FIXME: This causes a segmentation fault.
<ekaitz>;;(define define-private define)
<stikonas>hmm yes
<ekaitz>it's probably because it should be something like (define-macro (define-private . x) (cons define x))
<ekaitz>added a fix for that too
<stikonas>thanks!
<ekaitz>-;; Mes: FIXME: This causes a segmentation fault.
<stikonas>well, I see your email to bug-mes
<ekaitz>-;;(define define-private define)
<ekaitz>+(defmacro define-private args
<ekaitz>+ (cons 'define args))
<ekaitz>i probably should run tests on this one
<ekaitz>ACTION is a cowboy 
<ekaitz>ACTION will send patch anyway
<ekaitz>stikonas: if you could run it, that would be helpful
<stikonas>yeah, let me try
<ekaitz>it is a lot of fun that it wasn't fixed before...
<ekaitz>sometimes you find these gems...
<stikonas>ok, kicked it off, though probably need 15 min
<stikonas>to go past nyacc rebuild stage
<ekaitz>okay great,
<ekaitz>no hurries
<stikonas>ekaitz: probably the next error now: https://paste.debian.net/hidden/747137e1
<ekaitz>i'm not sure where that's happening...
<stikonas>I think same filel
<ekaitz>but all these mes issues... weird
<stikonas>probably due to nyacc 3.04
<stikonas>I guess nobody tried mes with it
<stikonas>but yes, a bit strange
<ekaitz>aaaah that explains things
<ekaitz>export is for exporting things in modules
<stikonas>anyway, probably enough patching for today
<ekaitz>maybe nyacc is exporting in the wrong place
<ekaitz>idk
<stikonas>we found some bugs and you already fixed a few
<ekaitz>yeah, we did some fixing!
<mwette>w/o guix, mes was a mystery to build for me; and my only guix install is on aarch64, which didn't work for aht
<mwette>So, have to rely on you folks to flush it out.
<mwette>and I don't think I have any odd exports
<stikonas>yeah, mes is a bit tricky to build, though there are various ways...
<mwette>there is a module called 'export' which could be a problem, but I guess you don't use that; it's not needed
<ekaitz>mwette: that can be... idk
<mwette>there is also use of #:re-export
<mwette>but that's been there a while
<ekaitz>i think that is ok
<ekaitz>i'm not a master of the module system, I just had to suffer it a lot haha
<ekaitz>let me clone nyacc and take a look
<ekaitz>maybe the exports' level is not calculated properly in mes
<mwette>c99/munge.scm,parser.scm
<ekaitz>well, it's probably too late for this
<ekaitz>i'll try to debug this a little bit tomorrow or so
<mwette>sleep well
<ekaitz>thank you, you too (if timezone helps!)
<aggi>no problem, but i do see neither the pnut nor the tcc_bootstrap_alt variants were re-integrated into main live-bootstrap
<janneke>snuik: later tell ekaitz: oops, yeah that's an funny (and honest) bug
<snuik>Will do.
<janneke>snuik: botsnack
<snuik>ty!
<aleksi>stikonas: Yes, I was able to use nyacc 3.04.0 with Mes. I had to patch out some of the things discussed here.
<aleksi>That is, (syntax->datum grammar-symbol) because grammar-symbol, and I also fixed the string-every issue
<aleksi>And in c99/cpp.scm, I had to replace define-public with define. But I don't remember why exactly, this was a leftover from debugging I did with 3.03
<aleksi>I think the biggest blocker for building upstream tinycc on i386 will be support for long long, hmm
<mwette>the only define-public in cpp.scm is for lookup-def which is localonly, I'll make that public.
<mwette>relevant diffs for 3.04.1 so far: https://paste.debian.net/hidden/e0f81e7a
<ekaitz>it would be great if stikonas could run his setup with it
<snuik>Welcome back ekaitz you have 1 message
<snuik>ekaitz, janneke says: oops, yeah that's an funny (and honest) bug
<matrix_bridge><Andrius Štikonas> ekaitz, mwette: I can try later perhaps, travelling today
<matrix_bridge><Andrius Štikonas> But diff looks reasonable
<mwette>kk: I may just make a 3.04.1 release which Yuo can try later
<matrix_bridge><Andrius Štikonas> Sure
<aggi>ok. with the review i've arrived at script-generator/configurator executing, with approriate steps/manifest steps/env and bootstrap.cfg
<aggi>steps/checksum-transcriber-1.0/pass1.kaem is launched; M2-Mesoplant is missing M2LIBC_PATH="./M2libc" although that's set correctly in both /steps/env and bootstrap.cfg
<aggi>moment... the separation of bootstrap.cfg and env is a little confusing
<aggi>then i've noticed steps/mes bundles some include/linux headers which i am not sure yet if these match the linux-2.4/fiwix/linux4 ones
<aggi>but ok. one step at a time
<aggi>aha, script-configurator is a little pedantic over bootstrap.cfg
<aggi>didn't help: when using /usr/bin/kaem (mescc-tools/Kaem/kaem.c) ENV is NOT passed along from steps/0.sh into steps/checksum-transcriber-1.0/pass1.kaem
<aggi>sigh, found it, my mistake "./M2libc" != "/M2libc"
<aggi>kaem-0 however does not support ENV
<aggi>good so far, and i tend to enjoy the configurator a bit as a general-purpose build/packaging system
<aggi>now it's regular build-system maintenance almost to re-iterate over each individual step and distfile pulled into
<aggi>verbose debug log output from kaem and configurator are helpful too
<aggi>interestingly, although the checksums from mescc-tools-extra mis-matched, so far the few ones inside steps/ do match
<aggi>the mes include/linux/syscall.h headers seems not problematic either, it's aligned to fiwix and won't clash with musl nor linux-2.4 i think
<aggi>and i see, a pnut-compiled tcc-0.9.26 does need mes/libc.a, although steps/mes from LaurentH seems to exclude it's compilation, have to see