IRC channel logs
2026-06-09.log
back to list of logs
<alganet>wow, the vapeserver project sounds awesome <alganet>I do however, prefer hardware that could in theory standalone. The dystopian scenario explains the conditions well: If I have exactly two vapes after the apocalypse, can I bootstrap one using the other? <alganet>What comes in mind for me is ESP32. Cheap, lots of boards with 2 USB-C, reasonably powerful enough that this idea seems plausible (a "seed ESP32" that setups bootstrap on another) <efraim>thanks, not sure how tab completion missed you the first time <Googulator>but I haven't been able to finish the cross-compilation step <efraim>I assume the copyright line on line 30 is the one you'd like added for yourself? <efraim>just getting the 32-bit part working is better than we have now <Googulator>the problem is that it has a dependency on gcc 4.9, which is AFAIK still broken <efraim>I was able to switch it to gcc-4.8 and 4.8 to also build gcc-2.95 and that got things building again <efraim>ACTION has to run to drive the kids around <fossy>hmm, FransFaase left. Definitely, we would love to have the tcc-0.9.26 -> tcc-0.9.27 64 bit support in live-bootstrap... <matrix_bridge><Andrius Štikonas> fossy: at this stage might be worth waiting for new mes <matrix_bridge><Andrius Štikonas> And directly build tcc mob or whatever it is targeting <mwette>ACTION has handed off nyacc-for-mes to janneke : no syntax-rules and cut 80% from parse time over 3.04. <aggi>the tcc mob/HEAD sitution seems non-trivial, because it's mob/HEAD where most riscv/aarch64 development continued <aggi>and i don't know which and how many riscv/aarch64 pieces could be or should be back-ported to the 0.9.26 fork <aggi>or if the 0.9.26 -> 0.9.27/HEAD transition could remain as-is; with x86_32 it's a non-urgent issue <aggi>or, if tcc was dropped completely in favor as mes-cc, which was proposed before <aggi>i got no plans (nor any funding) to roll along with any other ARCH than x86_32 for the c-toolchain profile anyway <aggi>and i have no intent whatsoever to interfere with any decision, nor scaring away any competent contributor like Frans (hope he'll be back) <roconnor>Googulator: Why can't guix build ghc with an older glibc? <roconnor>Switching to Oleg's bracket abstraction only reduced my B's from 19738 to 13220 <roconnor>I guess there is a price I'm paying for using lambda to implement let. Ben Lynn has, more or less, let built into his VM, but my VM is simpler and only allows combinators. <roconnor>Anyhow, eventually I will compile directly to a graph and this will all go away. <siraben>wow, claude fable 5 is finally doing the mini OCaml task completely and correctly <siraben>but nothing is over until tcc compiles and self-hosts! <siraben>needs some more rounds of cleanup but the path A → B has been shown, and on the ZINC VM as well <aggi>siraben> but nothing is over until tcc compiles and self-hosts! <aggi>sorry, to jump at it again <aggi>tcc or any sufficiently complete c-toolchain (simple-cc, kefir, cproc/qbe, none of which are sufficiently complete for kernel+libc+userland) <aggi>one live-bootstrap argument was, any such intermediate compiler merely should suffice to bootstrap gcc/llvm/clang <aggi>while i uphold an alternative to gcc should be sufficient for kernel/libc/userland, almost all free software that's written in C still <aggi>and it's not been too easy to track all this free software against an alternative c-toolchain <aggi>furthermore it's moot to discuss if there was any other bootstraps for haskell, scheme, etc. because most relevant software is written in C <siraben>aggi: I'm just interested in the stage from m2-planet to tcc <siraben>i.e. the space that is filled by MESCC right now <siraben>so the point of blynn-bootstrap is to replace mescc with hcc, a bootstrapped mini C compiler in Haskell <aggi>ok, sorry if there's a misunderstanding on my side, i'm certainly not competent to participate in compiler design discussions <siraben>however, even though end-to-end timing is the same as MESCC it's not very efficient with memory usage, and ML might be a better fit because it can use mutable records and have better string representations than linked list of characters <aggi>what i had in mind, it's the twisted situation, anything which can compile tcc, already is a candidate to replace tcc itself <siraben>Depends. tcc handles a lot of stuff actually, like linking, asm etc. <siraben>I think asking someone to implement all of those is a big ask. <siraben>I'd rather development be split across communities than us having to maintain something like tcc <aggi>currently it's the pnut-cc thing mainly, which is written in C, can be spawn from M2, and can compile tcc <siraben>with pnut-cc don't you still need a posix shell? <aggi>which, at bare minimum already showcases, a half-way decent C-compiler can be spawn from M2 <aggi>siraben: nope, there is pnut-sh and pnut-cc, the former emits shell script, the latter emits ELF (if i'm not crazily mistaken) <aggi>the current disadvantage of pnut-cc: it's x86_32 exclusive <aggi>that's the reason why the whole mes-cc support for other ARCH is discussed, with or without tcc-0.9.26 involved and the complicated situation with it <aggi>otherwise, of cause, there's legitimate concerns to bootstrap haskell, scheme, rust etc. but that's unrelated to the C-compiler issue <aggi>however, one argument from live-bootstrap was/is, a c-compiler shouldn't be written in the language it's compiling for <aggi>but this is a non-issue when pnut-cc is spawn from M2, because the chicken-and-egg problem is solved by spawning a C-compiler from M2/macro-assembly <aggi>hence it is not necessary to re-entangle scheme/haskell/shell-script into the bootstrapping path <aggi>it's merely a nice-to-have for what's known as "diverse double compilation" to re-confirm trust then <aggi>just in case you wouldn't sufficiently trust M2, and the few GNU mes-libc pieces involved <siraben>aggi: Yeah, I'm not currently interested in bootstrapping haskell, scheme rust etc as you said once you have tcc you can get to the other langauges, and in the case of rust there's mrustc already <siraben>The Haskell part I'm doing only exists to express a readable, checkable C compiler that can also be developed with GHC (for nice stuff like linting, more readable type errors, profiling, etc.) <siraben>just moving things in the direction of: less code to trust, less time needed to get to the first self-hosting tcc