<Hagfish>"ZZ (drunk octopus) a rust inspired transpiler and symbolic verifier to bare metal C" <Hagfish>that seems extremely clever, although i don't know enough about C to know whether it is actually useful ***ChanServ sets mode: +o rekado
***duncanm_ is now known as duncanm
<oriansj>dddddd: well that haskell compiler looks promising; provided they keep up the work they might end up solving the ghc problem for us <oriansj>I however am insanely tired of the only x lines of code argument about bootstrapping. 500 lines of C, lisp and FORTH are in no way compariable in terms of bootstrapping difficulty <oriansj>just purge the line comments from M2-Planet and it is a single line program. :rolleyes: <oriansj>also it appears to depend upon gforth, clang and docker <oriansj>now if I was being extra ironic, demonstrate the trusting trust attack by making a version of M2-Planet that only has zero lines of code in its bootstrap. <oriansj>Now if he wrote seed-forth in assembly, or M1 (hell I'd even given credit if it was in M2-Planet) I would celebrate his success; however bootstrapping from a program that is bigger than 50MB means your bootstrap binaries is larger than guix's. <oriansj>Further assuming that 2KB is staticly linked and no other libraries are depended upon. (x86/cc_x86 is 14,446bytes and was written in 24hours) he should be able to reduce his bootstrap to just NASM or M1 in less than a day; then it might be worth incorporating. <oriansj>NOPE, super dynamically linking; depends upon glibc and multiple prebuild libraries. <oriansj>look stage0's forth is 4,372bytes and 1506 lines long and supports most of seed-forth; with minimal effort it can be made into a seed-forth and will be trivial to port to other architectures (just translate the functions one by one). Let us assume it is done and he has it; what useful bootstrapping thing will we have? <oriansj>at least with mes.c (~500lines of "simple C") janneke wrote MesCC and did something useful in terms of real bootstrapping. <oriansj>atleast jones FORTH had the fucking balls to be written in assembly (macro'd to all hell assembly but assembly none the less); which if you didn't know is what stage0's FORTH is (jones FORTH translated into M0) <oriansj>hell I even give lisp the win for actually bootstrapping GCC. <oriansj>instead of being smug and talking about how minimal their shit was; lisp programmers (janneke to be precise) actually got their shit together and did the freaking work to deliver a non-trivial result. <oriansj>if that FORTH could build mes.c or tcc or anyting of value in bootstrapping; it would be really freaking useful; but no, it depends upon a bootstrap bigger than freaking guix and it doesn't deliver anything beyound a FORTH less useful than GFORTH (which it freaking depends upon) <oriansj>sorry dddddd for ranting for so long but I am just so freaking tired of language fetishism. I no longer care about language, I care about what they can do of value. Assembly the results are obviously useful. C the results are obviously useful. Scheme (thanks to guix, guile and MesCC) the results are obviously useful (just don't try to write it in anything lower than C; you'll lose 9months of your life like I did). FORTH: ummm I'm cool I <oriansj>swear trust me (thanks for wasting 4months of my life) <oriansj>Hagfish: to your question; it has potential but until anyone does anything of value in it, assume it is another experiment in programming language that end up not being worth the effort (Rust is barely beginning to show they might be past that phase) <oriansj>dddddd: and thank you for the fix, I appreciate it <janneke>i like getting things to work, although that's often just a first step <oriansj>speaking of which janneke what is the plan to reduce guix and finally close the gap? <dddddd>Sorry for firing those bad feelings, oriansj. A good informed rant is good, also serves as escape valve (instead of burning you from the inside). I guess docker is just an option but you're right about the need of a HOSTFORTH, I missed that. I was hoping that their preforth were more low-level. Anyway, implementation details aside, I guess the identification of a minimal subset (and how to grow it) is their contribution. Eventualy one can <dddddd>The recording from janneke's talk is still not available, but many other are. It happens, the one you want more, the later it comes :P <janneke>oriansj: you have seen my ugly prototype of mes-m2 merger/rewrite into mes hack, just before mes-m2 made radical changes to boot-0, tests and slow_lisp <janneke>the first poc will off course use that <janneke>meanwhile i will start looking at how to merge your work since the past ~4months <civodul>and there's the wip-bootstrap branch ("full Scheme") that's also pretty exciting! <janneke>civodul: sure, that's my current focus; oriansj was asking about my fsb plans <janneke>civodul: i'm currently looking why my new, rebased wip-bootstrap needs two ugly, long 'setenv stanzas re-inserted that you managed to remove on core-updates <NieDzejkob>So, what's the story with ML bootstrap? Is anybody working on a bootstrappable ML compiler? <rain1>we looked into ocaml and cakeml a bit <rain1>there was some really good progress on ocaml <rain1>the SMLs seem like they would be a lot harder to deal with to me <rain1>they tend to be self hosted without much thought of building in terms of a small core <janneke>civodul: on wip-bootstrap that i intend to rebase+rewrite after you update core-updates, shall i change all the 'bootstrap: ' prefix in commit messages to 'gnu: commencement: '? you were using that and i liked it better <civodul>janneke: sure, i think that's what i've been using in the past <civodul>"gnu:" is for (gnu packages), and then, i either write "PACKAGE: " or "CATEGORY: " <janneke>civodul: good; the reviewers must have been quite lenient towards me in the past ;-) <civodul>janneke: getting commit logs right is considered less important than getting bootstrapping right, i guess :-) <oriansj>dddddd, I made a recording of janneke's talk and I could possibly share if you wanted <civodul>speaking of which, do you know why there's no video for your talk, janneke ? <oriansj>janneke: well, I must admit that my merger of our two branches of mes-m2 being a slow process is entirely my fault of ambition. I want mes-m2 to solve the guix and guile bootstrap problems. <oriansj>I was hoping that once slow-utils finishes; mescc could just leverage a statically compiled guile and guix could be reduced to a single binary bootstrap. <oriansj>after which the mes-m2 work will slowly grow until it becomes a drop in solution and we will be done <oriansj>but now that mescc-tools has been fuzzed to hell and segment faults have been largely eliminated (12 hour fuzzing runs turning up nothing); M2-Planet finally on AArch64 (because dddddd is awesome) and now all of the architectures now have atleast 1 cc_* written (making future porting work easier). There are no excuses left for me not to focus on mes-m2 becoming a full scheme capable of running gash, guile bootstrap, guix and MesCC tools <oriansj>Please criticise everything about that plan you think could be better. <fossy>oriansj: for the most part I agree, mes-m2 should be the focus right now. Its pretty much the missing part and the other parts are mostly complete. IMO the dev plan for mes-m2 should go 1. Make mescc run 2. Make gash run 3. Make guix run/guile bootstrap. Either is ok, because guile bootstrap will essentially allow guix to use guile. But if one is easier than the other I would do that first. <fossy>In terms of the full scheme bootstrap in this <fossy>I do not think it is too far fetched to only have the single guile binary. Mes may be needed since I found it impossible to get guile to run mescc. <fossy>however my what I am now calling gcc-seed (fork of mescc tools seed) that works up to GCC 9 toolchain, is using guile and mes. Once mes m2 can run mescc and gash, we will have a complete bootstrap. <fossy>Actually, not even gash, if I can get kaem into a reasonable state.... Leads me to another question, how far should I develop kaem? <fossy>Do we want to not need gash and be able to just use kaem up to make? <oriansj>so you are thinking having janneke make using MesCC on Guile easier is a good priority? <fossy>IMO, thats probably a waste of time <fossy>oriansj: not in the long term. For the full scheme bootstrap yes, but the work will quickly become obosolete when mes m2 is done <oriansj>well not entirely as waste as being more scheme agnostic and friendly would help MesCC in the long term <fossy>I havent been here for long and I guess where to go from here is directly related to what our goal is <fossy>If our goal is to have a full bootstrap then getting mes-m2 to run mescc and gash should be the priority <fossy>If our goal is to make guix into a full bootstrap then getting from mes m2 to guix is likely the priority <fossy>oriansj: <fossy> IMO, thats probably a waste of time was RE: <fossy> Do we want to not need gash and be able to just use kaem up to make? <oriansj>well it is possible to get kaem able to make make. Which reduce our dependence on the success of guix in the bootstrap <oriansj>but it would have to be done by someone who thinks it would be a fun project. *fossy is the person who thinks it'd be a fun project <fossy>however a /more/ fun project for me is removing guix from the bootstrap <fossy>but i want to be able to bootstrap my comptuers without guix <fossy>i don't want to remove scheme.. just guix <fossy>which is waht gcc-seed is trying to do <janneke>fossy: no offence taken; guix was never meant to be a dependency of the full source bootstrap <fossy>rain1: its my project i'm doing, extending mescc-tools-seed to bootstrap gcc <janneke>oriansj: please don't feel bad about anything; for 0.19 i merged a lot of your work (snarfing, cyclic include, mes_open, etc) <fossy>and i need to clean it up a /lot/ <fossy>because TinyCC is a very poorly coded piece of software <rain1>fossy: cool I will check it out. have you see gio's ASMC OS? <fossy>the hacks i had to do to get TinyCC non-prefixed and work "everywhere" <janneke>oriansj: it will take some time before i get to the previous pre-slow_lisp merger: first the scheme-only bootstrap <janneke>oriansj: arm work has just re-started <fossy>the idea is that gcc-seed would ideally be build from an initramfs <fossy>oh, also AMD64 is b0rked on gcc-seed <dddddd>Oh, I also missed your repo, fossy. I see the goal of getting to gcc as the more broadly applicable one. <janneke>fossy: guix just was the first distribution to declare minimalistic bootstrap seeds to be an important goal <Hagfish>gcc-seed sounds great, and anything that can be gained from asmc will only make it better <oriansj>indeed, we all can help each other achieve our successes <xentrac>fossy: that's interesting; what aspects of TinyCC are coded very poorly? <oriansj>xentrac: ever try to build tcc without make? <oriansj>or perhaps as a single shell command? <oriansj>note this even occurs if you use gcc or clang ***deesix_ is now known as deesix
<oriansj>what happens until you stumble into the magic ordering? oh yeah it refuses to freaking build <oriansj>(Hence why I want MesCC to grow until it can build gcc directly) <xentrac>are you saying you think its build system is poorly thought out? <oriansj>I'm saying the coding skill level involved has dropped over th years <xentrac>that seems almost tautological in this case <xentrac>but what are the indicators you see of that? <oriansj>no C compiler should demand as many C features as it provides <oriansj>janneke had to literally change implementation details to fix that in TCC <oriansj>otherwise janneke would have implemented all the feature to build GCC directly <oriansj>which you know is probably a good idea at this point as it will significantly reduce the bootstrap chain <oriansj>not a huge rush at this point as guix allows the hiding of insane levels of complexity <oriansj>as fossy has been discovering by converting the guix steps to shell (and one of the reasons why kaem improvements are key to guix free init bootstrap) <oriansj>fossy: looking at your reduced kaem, I think I have a way to make it even smaller <fossy>make sure you are looking at minimal-debug branch not minimal <fossy>Minimal has some very weird errors <oriansj>drop the need for -f; just assume anything passed is a filename <oriansj>also skip the error message and just exit(EXIT_FAILURE) as we have it as default verbose <oriansj>we can also move everything from execute_commands into main to save a function call and then replace the outer while with a goto which will also be smaller <oriansj>although I would include the kaem-optional-seed build steps and source in mescc-tools-seed (even if the steps are commented out) so that if anyone asks about the 5KB blob, we can say uncomment this and you'll build it yourself. <oriansj>also AMD64 can leverage the same binary as it can run x86 binaries too <oriansj>but it looks like you already did that that last one