IRC channel logs
2026-03-16.log
back to list of logs
<stikonas>I guess that would perform even worse in mes? <ekaitz>on who is calling that object->string <mwette>lalr is definitely overalling atomize-terminal <ekaitz>i mean, mes is slow, but if nyacc does its best and mescc too, we could relief some of the pressure we put in the interpreter <mwette>object->string called by ugly-print, to generate the tables; main use it to make sure lines don't go over 80 chars. <mwette>That's just for generating the tables. It would have to go "on the list". I've over-nyacc'ed the last couple months. <stikonas>that's fine. Take care of yourself in the first place <mwette>I was using `statprof' in guile. <mwette>Ah. All the above numbers are bogus. I was for just printing the tables. I need to regenerate also. <stikonas>ok, that explains why it spent most of the time in ugly-print then <mwette>Now on my laptop, using guile, a little odd: 1.00=>3.6s 3.04=>7.0s <mwette>To make comparible timing tests, I'd need to be more careful, I think. That's all for now. <safinaskar>janneke: Hi, Janneke and others. somebody created commercial open source Linux distro https://stagex.tools/ , which heavily relies on Mes and other work from bootstrappable community. the project is open source. but it offers commercial support, as you can see on their site <safinaskar>janneke: so, i think that you and, possibly, other members of bootstrappable community should contact stagex authors and ask for fair share of money <janneke>safinaskar: thanks for the headsup...but it doesn't work that way, especially not with free software :) <janneke>safinaskar: also, having a company doesn't imply you're making loads of money <janneke>we can only hope they do one day, and decide to give back to the community <mwette>For nyacc-1.00.2 what did you use for lalr's syntax-case? In 3.00.X that was changed to syntax-rules. <matrix_bridge><Andrius Štikonas> No, we used that custom patch which replaced it with syntax-rules <matrix_bridge><Andrius Štikonas> Well, i think more lalr rules explains slowdown... <matrix_bridge><Andrius Štikonas> Like you said it is nonlinear in thr number of rules <aggi>can't precisely distuingish GNU mes from scheme/LISP, some pieces are written in C, others are written in scheme <aggi>seems it is mes-cc in particular which relies upon scheme/LISP, and is hit by a performance penalty hence <aggi>haven't used LISP/scheme myself ever, was only reading some LISP/scheme interpreters claim near native performance <aggi>so, it's not necessarily a scheme-issue either, why mes-cc is much slower than pnut-exe <ekaitz>aggi: what do you mean by distinguish Mes from Scheme? <ekaitz>LISP is a family of languages, being Scheme one language of that family. Mes is one implementation of a language of that family <aggi>ekaitz: i mean the system-integration i'm working on here does need GNU mes, but it's NOT hit by any performancy penalty because pnut-exe is used instead of mes-cc <aggi>i see, the build: tcc-head here does need ${DISTFILES}/${MES_PKG}.tar.gz for it's libc <aggi>but those pieces are written in C to my knowledge <ekaitz>GNU Mes has 3 parts: a C compiler written in Scheme, a Scheme interpreter written in C and a C standard library (written in C ofc) <aggi>too tcc-0.9.26 for pnut-exe needs MES_PKG, but does not need any scheme-interpreter anywhere either <ekaitz>because that is using the Mes C standard library <matrix_bridge><Andrius Štikonas> I guess C standard library can also be written in non C language <ekaitz>stikonas: you could, but had to provide all the headers and all anyway <ekaitz>and support the calling convention <aggi>so far, the mes-libc did work quiet well, except for the first test-run with busybox-1.2.2.1 <aggi>which is a non-trivial issue, because this too involved linux-tcc kernel (to replace fiwix which i'm not willing to try yet), depending on the desired features with it (networking, filesystem) <aggi>but i think it's feasible to link busybox-1.2.2.1 against mes/libc.a (not sure yet if it's worth the effort because live-bootstrap got the musl-libc integration implemented) <ekaitz>hey aggi we are not that bad as programmers after all <aggi>proceeding with tcc-head/pass2.sh "We have to compile using tcc-0.9.26 as tcc-0.9.27 is not self-hosting when built with mes" <aggi>this shows up with pass3.sh again <aggi>weird, tcc-head/pass2.sh passed compile-time, and i've used tcc-head instead of tcc-0.9.26 there <aggi>don't know yet why tcc linked against mes/libc.a was/is considered non-self-hosting <aggi>it's a little complicated to re-confirm, because pass3.sh is affected too, in parallel to the mes/libc.a transition towards musl/libc.a <aggi>at least, i'm running this inside chroot atop linux-2.4 syscall ABI already, and it seems to not cause any trouble, not yet <aggi>i've already backported musl-1.1.24 onto linux-2.4 long time ago, so this could rule out most/all potential problems <aggi>of cause there is a few differences between fiwix and linux-2.4 <aggi>and, i'm testing with pnut-exe here, which at least could provide a baseline (if that works as intended) for the default mes-cc chain too <aggi>stikonas: do you recall what the issue was/is with tcc-0.9.27/mes-libc that it was not considered self-hosting? <aggi>i've not hit any compile-time, but do fear and would want to rule-out mis-compiled binaries and/or run-time issues later <stikonas>pass3.sh in live-bootstrap says # We first have to recompile using tcc-0.9.26 as tcc-0.9.27 is not self-hosting, but when linked with musl it is. <aggi>yes, pass2.sh too says so; ok, then there could be some good news, i hope, because the pnut-exe -> tcc-0.9.26 -> tcc-head -> tcc-head did yield a self-hosting compiler here with pass2.sh already <stikonas>when ekaitz and I were bootstrapping tcc[mob] on riscv64, we didn't see this issue <aggi>i'm testing this atop a linux-tcc 2.4 kernel abi (inside chroot), not fiwix-native <stikonas>I doubt that kernel would make a difference <aggi>good then, i'll just proceed with the musl-libc passes next, then busybox etc. etc. <aggi>and i think i will re-organize steps/tcc (such as steps-tiny/tcc-head-mes steps-tiny/tcc-head-musl) <aggi>steps/musl-1.1.24 isn't trivial, since i've extensively patched this for linux-2.4 ABI inside TinyCC/OS, diff/rebasing again...