IRC channel logs

<aggi>another idea, concerning absent dependency-tracking with script-generator (which is rather good as is)

<aggi>the base-system components (from live-bootstrap and the tiny-bootstrap fork) are kept minimal

<aggi>and then an additional package-set such as steps-extra/ can be added with a separate extra-manifest file

<aggi>and such extra-manifest can be generated with some manifest-generator, that understands a simple DEPENDS declaration for those steps-extra/

<aggi>then the manifest-generator parses all steps-extra/ and arranges those in-order to satisfy dependencies

<aggi>by this, regular live-bootstrap establishes the base-system, and atop this steps-extra/ can be ported

<aggi>similar to *BSD who separate their base from ports tree

<aggi>an alternative to this, again keeping live-bootstrap as a base-system profile, and bootstrap gentoo-portage as seamless as possible

<aggi>since i already did fully fork a portage tree for tinycc/c-toolchain support

<aggi>but gentoo/portage/python open a giant can of worms, i rather take the pain to re-write entire packaging of 500ebuilds

<aggi>and i do like the the live-bootstrap script-configurator, in combination with the steps-extra/ approach with some simple dependency tracking added for these

<aggi>mainly because, the manifest-generator probably can be implemented with POSIX shell instead of python

<aggi>and this could keep the whole script-configurator steps/ untouched, except for some DEPENDS=<> variable added to steps-extra/

<aggi>thinking about this, because i do miss a few pieces in live-bootstrap (dev-vcs/git, app-cdr/cdrtools and a few other among those 500builds ported to tinycc)

<aggi>and by keeping the tiny-bootstrap steps-tiny/ separated from steps-extra, the former are compiled in ~10minutes yielding a development host

<aggi>and all else, with however much compile-time this takes, remains flexible and optional alltogether

<aggi>furthermore i tend to think live-bootstrap is sufficient to abandon cross-compilation scenarios and all the pain this caused

<aggi>because with the help from qemu-binfmt a chroot-bootstrap can be done native without cross-compilation, or truly native on bare-metal (which is unpractical sometimes)

<aggi>the disadvantage with this, QEMU portability restricts development hosts to >=linux-2.6 and full GNU toolchain systems mainly

<aggi>i don't expect a steps-tiny/qemu-0.14 anytime soon driven by tinycc atop a linux-tcc 2.4 syscall abi

<aggi>but there's worse issues to worry about, and live-bootstrap does cover the whole dependency chain up until linux5/g++ etc

<aggi>so, i'll just live that decision to live-bootstrap to hack a steps/qemu

<aggi>*leave

<aggi>with tiny-bootstrap fork i'll probably wrap steps/python into a CONFIG_PYTHON which defaults to False for myself, and test this only once

<aggi>ideally i may too keep Perl/autotools wrapped inside a CONFIG_PERL option, and keep this dependency out of steps-tiny/ by default

<aggi>then, a CONFIG_EXTRA which implies CONFIG_PERL due to autotools which most of steps-extra/ with dependency tracking probably need

<aggi>i think i can handle re-writing 500ebuilds for script-configurator style steps-extra/

<aggi>good thing is, steps-tiny/ are finished almost, so this can be released and discussed among tinycc-devel, for nightly builds and regression testing

<aggi>it's too rather small and simple, and less effort to port this to ARCH other than x86_32 if anyone wished to do so (i won't)

<aggi>because riscv64 and aarch32/64 etc. introduce a gigantic dependency graph

<aggi>out of curiosity, since it's fiwix relied upon with live-bootstrap: had there been any ideas and efforts how to handle this for riscv64 and aarch?

<aggi>and, if there was no bare-metal bootstrap option and qemu/chroot done, is it the idea then to _always_ hack the entire dependency chain up until >gcc-10/llvm?

<aggi>because, even when one day tinycc completed riscv64 for example, i do not see any kernel which could be compiled with tcc-riscv64

<aggi>which adds up to the whole madness surrounding QEMU portability

<aggi>and i don't think there is any plans to backport riscv64 to linux2/fiwix, nor backporting riscv64 to any suitable QEMU version for this

<aggi>and since this is the status of it, i'm not sure where live-bootstrap was heading with riscv64, because a cross-compilation setup seems unavoidable for this anyway

<aggi>which is, ok, doing so, but what's been the plan for live-bootstrap if that was blocked at that many fronts for any other ARCH than x86_32?

<aggi>because, live-bootstrap is mostly stable for x86_32 and all else is handled by cross-compilation if i'm not mistaken

<aggi>of cause, riscv64 can be bootstrapped already, up until M2-Planet and some LISP-machine type of thing available

<aggi>which is good, but is there any other plans?

<aggi>and, imo, the key to solving some of these issues with riscv64/aarch32/64 etc.

<aggi>that is c-toolchain support with TinyCC (or any other like simple-cc, pnut, plus assembler/linker) to compile a kernel at least with it

<aggi>instead of plans for abandoning tinycc from live-bootstrap

<aggi>of cause, if you can handle the transition from M2 towards GNU gcc and/or llvm with GNU mes-cc/scheme/lisp for riscv64, that's good

<aggi>which reminds me of the M2->tinycc/musl transition again, which i think related problems aren't caused by tinycc itself only

<aggi>even when tinycc was dropped in favor of GNU mes-cc

<aggi>and so far the M2->pnut|mes-cc->tinycc/musl for x86_32 is the ONLY fully confirmed one, and it's a challenging hackjob still

<aggi>(seen when rebasing for tcc-head, which by coincidence is the one which riscv64 was hacked for mostly)

<aggi>in this regard riscv64 is a remarkable industry specimen, given the amount of $$$ that's dumped into it (by Nvidia)

<aggi>and there is no complete bootstrap for that thing known (by myself), nor any future prospect i guess to see any in the next few years

<aggi>makes me wonder how the money-makers behind this got away with it, advertizing this with 4trillion cash at stock exchange

<aggi>and that's not the whole picture of it, given hardware-development and firmware-issues weren't focused on yet

<lanodan>Oh discovered a fork of chibicc with some enhancements: https://github.com/fuhsnn/slimcc

<matrix_bridge><cosinusoidally> lanodan: there's also https://github.com/fuhsnn/widcc by the same author, which is a more conservative fork of chibicc. These are all x86_64 only and rely on binutils though. The ci suite is also interesting as fuhsnn actually builds multiple real world codebases and then runs their test suites.

<matrix_bridge><cosinusoidally> The codebase looks far easier to understand than tcc so adding other backends/eliminating the binutils dependency should be doable.

<matrix_bridge><cosinusoidally> and it can build tcc and gcc.

<luke-jr>I don't suppose anyone has an Erlang bootstrap?

<matrix_bridge><Andrius Štikonas> luke-jr: no, i don't think so

<matrix_bridge><Andrius Štikonas> At least i don't remember it mentioned here

<aggi>apropos binutils: i've salvaged some older elfutils-0.127 version that passed compilation with tcc

<aggi>as a quick hack this spares the hazzle to hack another AR (not arch-specific) and OBJDUMP,NM (arch-specific i think)

<aggi>this elfutils version did not need NPTL nor C11 _thread extension - which could be relevant for some use-cases

<aggi>the combination of AS=YASM|AS86, elfutils, and any CC=tcc|chibbic|.. could be easier to handle for an integration with live-bootstrap, offering a somewhat complete toolchain

<aggi>with ARCH=x86_64 there's a few other aspects which keep me distanced: UEFI, ACPI, no known FPGA SoC deployment for 64bit free/open hardware systems

<aggi>in this regard, x86_32 (plus 16bit real-mode boot) remains a must have and x86_84 a nice-to-have

<aggi>git-pushed: https://codeberg.org/aggi/tiny-bootstrap/src/branch/master/steps-tiny/tcc-head

<aggi>^ this one is "self-hosting" at pass2.sh already confirmed up until a working steps-tiny/busybox-1.2.2.1

<aggi>tiny-stage0-x86_32.sh shows which TINYCC_PATCHES were applied for this onto tcc-head

<mwette>ekaitz: b

<ekaitz>hi

<ekaitz>b?

<mwette>ekaitz: did you try coding syntax-rule s using the "Macros That Work" algorithm? I'm looking at that. Trying to figure how to deal with calling macros.

<mwette>(looking just for fun, to try to understand what they did)

<ekaitz>could you link me to that algorithm?

<ekaitz>i never tried, I've written the Mes define-macro based macro expander

<mwette>I think this will work: https://www.researchgate.net/publication/220997237_Macros_That_Work

<mwette>I thought someone was working on re-writing the MES syntax-rules.

<ekaitz>we should, maybe

<ekaitz>specially for introduced symbols, those are not handled properly

<ekaitz>and I need to do something about it

<ekaitz>at the moment our coude is taken from scheme48's alternative implementation folder, and it's missing that

<mwette>My reading is there are two stages of replacement. When you convert syntax-rules you replace all bound variables with gensym-based ones; and on each macro call you then replace the formal pattern variables with gensym-based ones.

<ekaitz>that reminds me an older algorithm that for each expansion adds some timestamp to symbols

<mwette>I'm trying to figure out if symbols which are macro names should be left alone, and, if so, how to determine that's what they are.

<ekaitz>but I think the paper i'm talking about is from 86

<ekaitz>and it was slow

<mwette>This paper claims O(n) time vs O(n^2) time for older alg's.

<ekaitz>yeah, O(n^2) it's probably the one I was referring to

<ekaitz>also i don't understand reduction notation

<ekaitz>i ordered a book so I could learn, but every single time I learn something I have to work on other things and I forget

<mwette>Haha, I feel your pain. I didn't grasp all of the notation, but think I have the general idea.

<mwette>Basically, the items above the bar sufficient conditions to "prove" below the bar.

<ekaitz>it should be that they become the ones below after one expansion

<ekaitz>but also all the things with the ¬ and all

<ekaitz>i don't understand

<mwette>that is "not"; the expansion is explained in the text. e: |- E -> E' means in environment e E gets expanded to E'

<mwette>What book did you order? I have Huth and Ryan, "Logic in Computer Science".

<ekaitz>types and programming languages i think its the name

<mwette>(FYI, My education is in control systems. Picked up CS via reading.)

<ekaitz>i'm a telecom engineer really

<ekaitz>nothing from my university studies touch computer science

<mwette>I found it, by Pierce I guess.

<ekaitz>they do touch some computer stuff, but not in the CS way

<ekaitz>yes Pierce

<mwette>hope you enjoy !

<ekaitz>you mean my work? every day

<mwette>the book; but the work too

<ekaitz>ah the book I have since summer or so but I didn't read yet

<ekaitz>this happens a lot

<aggi>there's one disadvantage with yasm (required for linux-tcc kernel): pre-generated files ...

<aggi>imo, the config.h from autoreconf/configure is not critical

<aggi>but there is some x86ins*.c opcode tables generated with some python script

<aggi>it's several options, all of them with some disadvantages: binutils and the huge dependency-graph, as86 which introduces and relies upon ASM intel syntax (confirmed for linux-tcc kernel non-SMP only), and yasm

<aggi>i consider yasm the least concerning regardless of pre-generated files involved (these can be reviewed)

IRC channel logs

2026-03-18.log