***Server sets mode: +cnt
<oriansj>fossy: looks like sys_pipe is just the ticket you want; it would really help if you had a test (like how getcwd syscall returned something different than expected) <oriansj>markjenkinsznc: well the reason for the aproach I took with mes-m2 is the result of 9months of work; resulting in still a very fragile and hard to debug program. Unwinding mes.c's C macros was a major project for me and increased mes.c's size by a factor of 4. <oriansj>Lisps at their core are like a crystal; extremely useful and robust of aligned carefully or fragile as hell. Fixing a broken lisp where only 1 or 2 things is wrong is an easy task; fixing it when major fundamental pieces have to change: can't be done. <oriansj>see mes.c made such heavy use of C macros; that I literally had to take 2months of my life to get gcc to be able to build mes.c (a bad first sign) <oriansj>Second mes.c made very heavy uses of arrays that leveraged a C property that M2-Planet; clearing out all of the features that M2-Planet didn't support took 9months and the end result was a lisp that would segfault if you looked at it funny. (not my proudest moment) <oriansj>I realized: why am I trying to make a lisp like a lisp programmer in C? I previously wrote a lisp that contained everything in the original lisp paper (Slow_lisp which I wrote in assembly in stage2: lisp.s) and have been porting features from mes.c to mes-m2 (as fast as I can figure out proper tests). Now I am far closer to the goal of bootstrapping MesCC (literally just some missing functionality) from M2-Planet than I ever was. <oriansj>I am up insanely early today (it is 4am here) <fossy>nice to see you've found here :) <oriansj>well janneke missed the stage0 hardware work entirely <joostvb>there's always room for improvement :) <oriansj>I guess rushed was the pacing; probably because of the setup issues <Harzilein>the website contains no mention of objc, is that the actual state of things, or is just nobody working on it _specifically_? <oriansj>Harzilein: well gcc-objc does cover it as far as I am aware <oriansj>and as long as gcc can be bootstrapped, it should be a non-issue <oriansj>I am thinking of breaking the bootstrap seeds to its own repo broken up by triplet <oriansj>hmmm I have an idea to make cc_* easier to understand <oriansj>I'll be pulling the binaries out of mescc-tools-seed shortly <oriansj>and I am preparing for a new release of mescc-tools-seed to incorporate AArch64 support <oriansj>it is 579lines of hex0 (corresponding to 1038bytes total); and 17,284bytes of binaries <oriansj>and I am removing the need for gcc to build hex.c to build the stage0 bootstrap binaries. <oriansj>and pulling the floppy images out of stage0 as they are each 1.44MB in size and are not going to be of any future value <oriansj>(I'll move the root one into bootstrap-seeds) <janneke>oriansj: sorry, i wanted to keep it very short and very simple <janneke>i didn't tell anything about all the work i did in guix, or all the work of porting mes c lib to the hurd <oriansj>janneke: now that would have been fun to see <janneke>oriansj: yeah, figured it would be better to leave out as much technical stuff as possbile <janneke>this might be going to be big -- as you have been saying all along ;-)