<oriansj>janneke: I think I can make mes-m2's display behave exactly like guile's so we don't need to use core:display anymore <oriansj>in fact I can do that for all of the core:primitives because I am just passing a single argument to the builtins <oriansj>now that mes-m2's primitives are now entirely isolated and independent <oriansj>and by doing this one little change; now mes-m2 tests can be directly run on guile and compared such that we can ensure the behavior matches exactly at all times <oriansj>Ironically mes-m2 will be supporting both 0xDF and #xDF <oriansj>also I think quotient is more accurate than / for what we actually have in mes-m2 <oriansj>and modulo actually appears to be remainder <oriansj>I probably should fix that and add a proper modulo <oriansj>patches are up on the slow_lisp branch <oriansj>only test002 fails on guile and that is because display-error requires a frame instead of just a string <janneke>oriansj: ah, those are pretty cleanups! <janneke>in mes, guile needs a compatibility layer to run the tests <janneke>it's great to have that eradicated, very good! <janneke>oriansj: meanwhile, it seems that i have booted the guile module system <janneke>"seems": only a simple hello world test runs <janneke>now to see if it can replace boot-0.scm and be used to replace `mes-use-module' <janneke>oriansj: i have added a reproducible `dist' target to mescc-tools-seed, mescc-tools, m2-planet; patches up on my gitlabs <janneke>for the guix full source bootstrap we need [reproducible] tarballs and cannot rely on auto-generated gitlab/github/savannah or git commits <oriansj>janneke: this of course means you'll have to strip out all non-guile bits from mes-m2 (as no compatibility layer will be needed) <janneke>oriansj: i was just looking at my tests...what a mess <janneke>i added at least 3 compatibilty layers guile->mes mes->guile and a much smaller, test-specific mes-0 one <janneke>well, it takes time to create something simple and beautiful... :-) *janneke pushes a first experimental `wip-full-source-bootstrap' to guix <janneke>the mes is from my mes-m2 merge branch: wip-m2, which i branched off the scheme-only bootstrap work <janneke>so i either need to cleanup and finish that scheme-only work, or see to remove it and rebase on top of wip-m2 again <janneke>dannym is going to have some serious git fun when he resumes his work on arm :-) <janneke>so i'll be looking at some serious cleanup/release work; but at least our rope ladder is starting to solidify <oriansj>janneke: well the first goal is get guix down to just Mes.c; my mes-m2 work can always come later <civodul>impressive work once again, gentlefolks! <oriansj>civodul: looking foward to a sub 1MB bootstrap binary? <oriansj>because mes.c compiled via gcc --static doesn't depend upon glibc and is under 1MB <janneke>oriansj: eh...that's very close to what guix currently has <janneke>the reduceed binary seed bootstrap starts with a mescc-compiled mes.c <janneke>`wip-full-source-bootstrap' starts with the 357 byte hex0-seed <janneke>civodul: yeah, it's amazing how things are coming together. did you see samplet's bash bootstrap news? <amz3>joined the channel on the first /join #bootstrappable ***stikonas_ is now known as stikonas
<stikonas>congratulations on your progress! I'm just starrting to catch up with todays news <vagrantc>janneke: it would be interesting to see if we can use it to do cross-distro bootstrapping of a bit-for-bit identtical tcc or something <vagrantc>gotta head out, but figured i'd drop the news :) <janneke>stikonas: yes, these work for me; of course these are the first working versions, we need testers and ... apparently fixes :-/ <stikonas>well, I probably need to get all tarballs... At the moment I used my old M2-Planet binaries <stikonas>or possibly I'm missing some env variables or something like that... <janneke>in any case, i would like to help you to get it to work or get a good bug report! <stikonas>janneke: I started looking at it a bit later, but then I was not sure what WIP means... <stikonas>so wanted to confirm with you before trying to run something that wasn't supposed to work <janneke>work in progress -- so yeah, it could mean anything <janneke>it's always good to ask; we (or i at least) publish quite some broken stuff sometimes :) <janneke>stikonas: note that oriansj has scripted a real nice gitmodules thing <stikonas>yeah, I was using his git submodules too, but then I was getting confused which repo should I use, his mes-m2 or some branch in your repo <janneke>we don't want to use that in guix for bootstrap, rather use tarballs; so that's a bit of a hassle to setup by hand; also guix will control the environment for you. luckily (well, it's really oriansj's engineering rather than luck), kaem will shield us from most of the environment <stikonas>anyway, I should look a bit more at commencment.scm <stikonas>janneke: do you use mes build with gcc? if I understand that script correctly? <stikonas>(i.e. that script refers to /bin/mes, not /bin/mes-m2) <stikonas>I still don't understand what I did incorrectly on the first try <janneke>m2-planet is being bootstrapped by m2-planet-boot0 + mescc-tools, + mescc-tools-seed; that then builds mes <stikonas>but with your exact tarballs it seems to work <janneke>yes, the patches are all hot, from today <stikonas>but doesn't matter, must have been my mistake <janneke>ah yes; i have utterlyl ignored amd64/x86_64 for now <stikonas>well, it's not urgent... guix bootstrap is x86 anyway <janneke>yes, i think i feel a bit bad about it because all the work that others have put into it already <oriansj>janneke: well we can always incorporate the ports to alternate architectures later as we firm up our multiple roots of bootstrap <janneke>oriansj: the ports are important, i added amd64 to mes because it was the one other architecture i had; it helped dannym a lot to get started with arm. i didn't finish it, 64bit mescc has some bugs that i need to look into <stikonas>oh, I think my original mistake was incorrect GUILE_LOAD_PATH... After I added extra '../', it started working <oriansj>also kaem's --nightmare-mode eliminates the environment entirely; <janneke>that's a cool flag; blood-elf needs that one too <oriansj>blood-elf doesn't even read the environment <oriansj>heck you need to pass it --64 for it to realize you need to do 64bit output <janneke>oriansj: just kidding while appreciating your choice of names <oriansj>but I was tempted to add --kill-all-the-dwarfs as a flag for blood-elf; which results in it returning an empty footer <oriansj>we also need to concern ourselves with alternate distro's bootstrap of guix as well; my perspective is let kaem build everything up to a self-hosting mes-m2 (built from MesCC) and then run guix on that to do the rest <oriansj>and the current goal of mes-m2 (be able to run MesCC and Guix) <janneke>the first thing i want to create is a way in debian to describe a package build without build-essential <oriansj>janneke: well that is the thing; mescc-tools-seed is too trivial for the debian build system <oriansj>it is too trivial for virtually all build systems <oriansj>no worring about flags or environments <oriansj>a seperate script and folder for each architecture <oriansj>no inputs and only 1 possible output; no tests beyound a basic checksum required <oriansj>but how to get it as a debian package? <janneke>what bothers me is that gcc will be in the package's dependency graph, that needs to go <oriansj>janneke: that is something for the Debian developers to sort out <janneke>exactly, that's what i intend to have them sort out <oriansj>janneke: why don't we shame them into doing it by doing it first in guix? <oriansj>Nothing changes behavior like headlines around the world <fosslinux>what would be great is having bootstrappable integrated into gentoo <janneke>fosslinux: is gentoo built from a well-defined set of bootstrap binaries? <Hagfish>how trollish would it be to make the Debian build process of mes-m2 go on to compile and package gcc, then include the hash of that package in a README file? <janneke>fosslinux: i would support any distribution that wants to bootstrap; i merely said debian because that's the only thing i have used/supported besides guix since long ago <stikonas>fosslinux: unfortunately some parts of gentoo might be relatively unfriendly for bootstrapping <stikonas>on gentoo it's quite hard to avoid binaries... Even if you use masked gcj-jdk, it still uses ecj binaries <stikonas>fosslinux: although, I would be interested too in getting gentoo to bootstrap better... <stikonas>fosslinux: well, can always start with overlay on gentoo <stikonas>I guess bootstrapping rust is another hard thing on gentoo <civodul>janneke: i missed samplet's bash bootstrap news, where was it? <janneke>he got bash5 built without any earlier bash <janneke>that is very good news for our scheme-only bootstrap; it still has quite some ugly workarounds here and there <oriansj>Hagfish: it would be a better troll to make a guix package for building the debian build-essential package thus forcing debian to run guix to build debian <oriansj>honestly, it wouldn't be a crazy project to add dpkg files to guix pack <oriansj>and then we would be able to produce 100% reproducible Debian package repo before the entire Debian team could <oriansj>then with a handful of tweaks the ability to make rpm packages and we take over the entire packaging world <oriansj>if we do things right; all software in 20 years will depend upon the work we do here. <Hagfish>that would still be downplaying the importance of this work, but it's a good start at least :P <Hagfish>to "all software" i would add "all software engineers"