<OriansJ>emorrp1: well we have bootstrapped a FORTH, a Bash compatible shell, a Cross platform C compiler and a minimal scheme (without complex macros) from that 250byte seed; how many more languages do you need us to bootstrap? And how will they actually help us reach our goals? (Other languages previously mentioned to us include Ada, Oberon, Javascript and smalltalk with no one willing do work on them.) <OriansJ>Remember at the end of the day if someone is willing to do the work required; every language will be accepted here but we will reject claims that anything is magically the perfect only way to do bootstrapping. <roptat>emorrp1, for Kotlin, I think it's possible to bootstrap a very old version of it, but it has some difficult dependencies (even more difficult to package because they're old) <roptat>but I have no idea whether this version is going to be able to build anything newer than itself <roptat>I think the real difficulty I have is that there's a 3GB repository that's a dependency of that old kotlin, but they depend on an unspecified version of it... (or maybe a fork? no idea...), so right now my kotlin package fails with 3 errors <ericonr>OriansJ: wouldn't a JavaScript bootstrap basically consist of a C++ toolchain? <roptat>anyway, time to go to bed for me :) <OriansJ>ericonr: well someone found a way to bootstrap JavaScript from C (but only a newer version of GCC 7+ if I remember correctly) <OriansJ>So it isn't exactly a viable route for bootstrapping of GCC. <vagrantc>finally tracked down the exact patch i needed to fix mescc-tools on debian: e633669dfdf16f503a7d740b9058e343536533b4 Fix ELF headers to be more well behaved <vagrantc>and 37f3ce4278770f42da06d9dddab9d0f8148998e2 Inherrit CFLAGS in kaem makefile, although I already effectively had that in debian/patches <OriansJ>well yeah, the kaem regression was a major change (just so that I could get mescc-tools-seed working quickly after being off for months) <vagrantc>i still don't understand what exactly changed in debian's toolchain that triggered the build failures; it was working perfectly fine with the exact same source code not too long ago <vagrantc>then again... these things happen with updating toolchains :) <xentrac>which is one reason this project is important! <vagrantc>speaking of updating toolchains ... the changes fixing building mes with gcc-10 appear to not generate the very-well-verified hashes of mes-mescc <vagrantc>but i think janneke said that would be expected <vagrantc>i should probably also pull in 0d25095a2518ca463c58864d8b36d591961784f5 ensure get-machine is available for all tests <vagrantc>i think machines with many processors might trigger that issue <fossy>OriansJ: link for js bootstraps? <siraben>OriansJ: the test suite you have in mes-m2, if they all pass then bootstrapping to Guile would work? <siraben>I'm wondering what requirements are needed to bootstrap Guile, i.e. R5RS + extras? <OriansJ>siraben: if all the tests pass, then mes-m2 will be able to run MesCC and we can bootstrap GCC from our 250byte bootstrap binary <siraben>OriansJ: Amazing. Which tests are failing at the moment? <OriansJ>as the last test (the biggest number) is the running of MesCC to compile a C program. <OriansJ>and if you notice the README.md; packaged with mes-m2 is a known good working version of MesCC and once we are done we can simply replace guile in the example command with mes-m2 and be compiling <OriansJ>all pieces try to converge on common standards (if possible) and operate in a drop-in replacement fashion. Thus allowing multiple independent implementations to share as much work as possible; while reducing the cognative load for understanding what each piece does and how they all fit together. <OriansJ>M1 and hex2 are the only specialized languages in the entire bootstrap; everything else is just a subset of a common standard like C, scheme, or bourne/bash shell ***LHLaurini2 is now known as LHLaurini
<fossy>I am thankful for Mr. Bellard <fossy>He has made some useful code for us over the years, particularly for intermediate stuff <vagrantc>once i get mescc-tools building on Debian GNU/kFreeBSD ... i'll start working on mes ... and then see if we can't produce a bit-by-bit identical mes-mescc :) <nimaje>(didn't they drop Debian GNU/kFreeBSD? maybe I remember that wrong) <vagrantc>it was never officially released, it's been moved into debian-ports, where all the new or ancient ports live <vagrantc>provides some interesting porting challenges <vagrantc>notably, need to teach get_machine to ... do the right thing... whatever that is <vagrantc>ok, hacked my way around the issue with mescc-tools on debian kfreebsd ... but of course, mes doesn't support the platform at all :) <vagrantc>why did i think i could have any chance of getting this to work when i couldn't even figure how to to cross-compile i386 mes on amd64? <vagrantc>my hack to get mescc-tools to build was to output kfreebsd-amd64 instead of amd64, which probably caused it to skip most/all the tests <nimaje>well, if you load the linux emu the tests should run, not sure if Debian GNU/kFreeBSD has the linux emu <vagrantc>i think it's possible to enable it, but no way to ensure it's enabled <vagrantc>it did actually run some tests ... and apparently some failed, but it seemed to not actually fail the build :/ <vagrantc>the conception of architecture names is hard to get portably <vagrantc>of course, my whole idea here was to propose building on an unusual environment to increase diversity for DDC (diverse double compiling) <vagrantc>but... probably an excercise for another day.