***Hagfish_ is now known as Hagfish
<Hagfish>don't worry, i'm not excited about the idea of you having to redo the work of coreutils, but it is exciting to have that dependency effectively removed for the purposes of bootstrapping <fossy>well, done the envar stuff for kaem <fossy>only took ~2 1/2 hours, nice <fossy>mes build system is slightly annoying and needs envars.. don't want a shell dependency.. so added envar support to kaem <fossy>then i can try and port the scripts to kaem <fossy>hopefully soon i'll put in conditional execution, then that's all with kaem <fossy>since im on holidays at the moment i have time to do these things lol <Hagfish>a couple of hours ago i used the "feedback" option on youtube to complain about something (without needing an account), and now it's been fixed <Hagfish>it might just be that i've found a workaround (the issue is hard to reproduce and i'm not sure how solid the fix is yet) <fossy>Google has unlimited manpower <Hagfish>the bug was a recent regression, so it's something they could have easily reverted <Hagfish>(it's to do with the menu on the left hand side of the screen) <oriansj>Hagfish: we will not be needing coreutils in M2-Planet <oriansj>instead we have the gash work to solve that problem <oriansj>we need only get mes-m2 in a state where it can run gash <oriansj>fossy: although your mescc-tools-seed work looks mostly correct and good to merge, the pieces that depend upon sh and coreutils are not something I would have on the master branch <fossy>that's what i'm refractoring out <oriansj>but if you wish to track that on a seperate branch; that I could get behind <oriansj>thus when gash is working on mes-m2; we can merge it in and be done <fossy>oriansj: please do note that there is the mes seed there at the moment <fossy>which you won't want on master I am guessing <oriansj>The only seeds, I am accepting are the hex0s and kaem-optional-seed <fossy>hence why it needs to wait for mes-m2 <oriansj>also mes-seed will be replaced by mes-m2 when it is done (as it will be replacing mes.c entirely) <oriansj>also, I have a way for us to add proper getenv and setenv <oriansj>we simply copy envp after we create it <oriansj>an implicit global we can encode; thus allowing perfect behavior and interface match with getenv and setenv <oriansj>for example in test/common_x86/libc-core.M1 at line 31 we do LOAD_IMMEDIATE_ebx &GLOBAL__envp and then STORE_INTEGER <Hagfish>what is needed for mes-m2 to run gash? <oriansj>well first I need to get modules working in mes-m2 and from there is just adding scheme features until it works <oriansj>although if there were proper tests for guile primitives that I probably need to added support for, would be handy if anyone wanted to contribute those... <oriansj>(basically tests for the primitives that guile and mes.c share; but focusing on ensuring compatibility with guile) <oriansj>Or primitives if one feels the desire (lots of examples to build from) <fossy>no need for me to write any coreutils <fossy>lol since it's like all cp and m <oriansj>and it can copy 10ish GB/s (limited by hardware) <oriansj>not bad for 13 instructions per 1MB (just needs to change a couple constants to get that up to 4GB per 13 instructions) <oriansj>but I wanted to keep it's memory requirements lowish (1MB buffers are quite large for 16bit machines) <fossy>oriansj: uh. i gave you a non-working patch for kaem :S <fossy>just realised, that when you set a variable any subsequent commands will not work <fossy>but execve seems to return -17?! <fossy>it has something to do with the modification of execve <fossy>it was because envp seems to be immutable <oriansj>fossy: I do have to warn you free doesn't actually do anything in M2-Planet ***ng0_ is now known as ng0
<fossy>ill leave it there for GCC purposes <oriansj>fossy: well honestly it is unlikely to be an issue unless a kaem script does 1M+ of those sorts of actions <oriansj>but I just wanted you to be aware (incase you do something insane) <oriansj>in the most bass ackwards way possible <oriansj>now to get mes-m2's boot-0.scm to behave like guile in regards to passed arguments <oriansj>good, what fun are you working on today? <rekado>unfortunately, I forgot who claimed to have found a shorter Java bootstrap. I would very much like to see it integrated in Guix. <rekado>I worked on a simpler bootstrap chain before and I’d be happy to consider my work obsolete. <janneke>hello rekado, any idea where that was claimed? i guess you grepped the channel logs... <rekado>stikonas: some time ago you mentioned that you had been able to build up to the openjdk in a shorter bootstrap chain than the one implemented in Guix. I would be very interested in bringing it to Guix. <stikonas>rekado: was travelling for a few days with my relatives <stikonas>rekado: yes, I was able to build openjdk:7 directly, skipping openjdk:6 <stikonas>I have some gentoo ebuilds for inspiration, but I did not yet port it to Guix