IRC channel logs

2025-06-21.log

back to list of logs

<lanodan>Yeah, quite makes me hope it won't be needed for something like live-bootstrap
<stikonas>well, it's not needed for bootstrapping gcc
<stikonas>in principle it could be added as optional branch, but it's a lot of work to add it (need to buid a lot of different versions of clang...)
<oriansj>honestly, every language feels like it is trying to make itself unbootstrappable.
<agg1>noticed a peculiarity last week: bash.static compiled with tinycc segfaults and or mis-behaves
<agg1>tested bash-3.x 4.x 5.x, either segfault or mis-behaviour when bash.static handles brace-expansion
<agg1>i got a complete tinycc compiled system up and running, too salvaged a python.static with it, to retain gentoo/portage tooling
<agg1>and then, got hit by surprise, it's not trivial to compile a bash.static without gcc or llvm/clang involved
<agg1>fun one, bashism inside portage/eclasses prevents me from swapping bash with oksh
<agg1>i've activated a tiny test-site documenting a few things of interest to bootstrappable.org, and you're cited rather often:
<agg1> http://tinyfront.mooo.com/docs.html
<Mikaku>agg1: not sure if your segfaults are related to this but just in case don't forget to add '--without-bash-malloc' when you run ./configure during Bash build
<stikonas>oriansj: indeed. I just had a thought. Given current zig "bootstapping" strategy where they commit web assembly blob into the repo, eventually they'll also have issues with git repo size...
<ekaitz>stikonas: yup the repo is already huge
<ekaitz>stikonas: I talked with andrew kelley about it not that long ago, and I started with an idea of his: writing a zig interpreter for the simplest case that could compile to that webassembly file
<ekaitz>i even started writing it but that uncovered some issues in the guile standard library and fixed those instead
<ekaitz>and then got overwhelmed by a lot of work and I couldn't continue
<stikonas>well, yeah, there is always more work than any of us could do
<ekaitz>andrew wanted to write that interpreter in Lua, and I started in Guile instead
<ekaitz>from Zig they are not going to do it, but they support efforts to try make it happen
<stikonas>well, probably still a lot of work, there is no way around having to write 2nd implementation of the language
<stikonas>if you don't want very long bootstrap chain
<ekaitz>yeah, but they had that in C++ before. I think one written in Guile/Lua/... would be way easier to make
<ekaitz>specially if it's done for the simplest case
<ekaitz>it doesn't even have to be fast
<ekaitz>(maybe in Mes?)
<stikonas>yeah, even slow interpreter is probably faster than 50 or so steps (that are not too fast either)
<ekaitz>exactly