<oriansj>gio: that is fine ( I was hoping for some detailed status notes about your asmc and nbs, like I added for mes and stage0 in bootstrappable.org to allow anyone to know where you are, what is done and what is being worked on <oriansj>fossy: if you want tools that work the same everywhere, you have to make life harder for yourself and add arbitrary restrictions (like main in C or -e in scheme) <fossy>my segfault is actually my f'ed up system afaict <oriansj>line 170 is probably the most lispy one in the entire file <oriansj>(just copy hexit and flatten into guile to see how it is supposed to work) <oriansj>hint: (map hexit (string->list "fuck it")) <oriansj>dddddd: yeah the bots going crazy are entirely my fault for just copying gio's talk materials without review; basically all because of package-lock.json had to pull that entirely otherwise I'd be getting generated crap forever <oriansj>and a minor feature enhancement for M1 (give correct line numbers following strings with \n in them) <oriansj>I am going to finish up M1.scm tomorrow and hopefully purge NOP from mescc-tools-seed <fossy>a mescc compiled mes is much smaller then a tcc or GCC compiled mes <fossy>lol ill just use this as the bootstrap ***Server sets mode: +cnt
<janneke>fossy: gcc-compiled is using -g, probably (debug info) <fossy>well good news, mes build (from mes) works <fossy>and it is reproducible between systems, did the verifying hashes jazz <fossy>but tcc is reproducibly segfaulting in the same way <fossy>there's something wrong with the build process for tcc, but not with the mes its building tcc with because I tried building mes again with that mes and it worked <oriansj>fossy: good to hear that you are making solid progress <civodul>janneke: hey, what are your plans regarding a post/press release for the "DDC" work? <janneke>civodul: i am counting on having delegated that to vagrantc <janneke>did he copy you on his mail to david wheeler? <janneke>i haven't seen vagrantc in a while, a season's thing i'm sure <civodul>janneke: ah, i don't think i've seen that message, but it's great that vagrantc is taking care of it! <janneke>civodul: to make the ddc part of it more interesting, i verified that we get the same mes binary hash when guile+mescc build mes <oriansj>well it is offical, mes-m2 finally has its first garbage collection bug <oriansj>well that is the hard part about garbage collection bugs in interpreters, it is usually something you didn't think about that gets you <oriansj>it occurred when I added a 1 line change to module/mes/boot-0.scm <oriansj>speaking of which janneke you'll be happy to see the new mes_eval.c (that comes with the latest commit) <janneke>sure, i'll have a look later -- thanks! <oriansj>janneke: after I got mes-m2 tail call form *janneke needs to make some calls <oriansj>which means I can cheat off of mes.c's implementation a bit <pder>oriansj: I fixed a few things that broke in mescc-tools-seed since the latest changes in M2-Planet. I sent you a pull request on github <fossy>hey oriansj, where is kaem developed at the moment? i see it in mescc-tools and it's own kaem repository <oriansj>fossy: primarily it is done in mescc-tools (I'll probably pull the seperate kaem repo to avoid confusion) <oriansj>it is probably one of the most neglected tools of the set (save for exec_enable which is probably just going to be pulled entirely) <fossy>i would like to add environment variable support to it and conditional execution <fossy>for environment variable support i was just thinking as-per-normal VAR=xyz <fossy>(ie a line saying VAR=xyz to declare the variable) <fossy>conditional execution i was thinking if command == return_code <oriansj>fossy: might as well make the syntax compatible <fossy>because the = functionality seems to be provided by test on a full-fledged system <fossy>i wonder what the shell in and of itself does <oriansj>well the hard part will be adding the setenv primitive to M2-Planet <oriansj>but take your time and I am sure you'll do great <fossy>oriansj: hm, now that I look at the stuff relating to envp in kaem, i can't really tell why M2-Planet needs to be altered? it already passes envp to execve, can't it just eval the VAR=42 string and set that in envp, and then shouldn't it pass VAR to the subprocess (through execve)? <fossy>cool. so then what would be the purpose of setenv? can't find a getenv anywhere in M2-Planet <oriansj>M2-Planet doesn't read/write the environment; if you however are writing the functionality of setenv to match that of the classic C version (might as well put it in M2-Planet) <fossy>ok. to start off with i'll just do envars in kaem and if i feel tempted i'll write setenv/getenv for M2-Planet <fossy>i don't get how you implement setenv without having the user pass through envp <fossy>on another note, please take a look at https://github.com/fosslinux/mescc-tools-seed. Phase 14 is fully working (compiling mes from mes-seed) however it currently has an external dependency on sh and coreutils :( because i need envar support in kaem (so I'll do that before moving on) and i might make some kind of coreutils implementation in M2-Planet to remove those dependencies <Hagfish>obviously, work on these things in whatever order makes the most sense and suits you best <Hagfish>"without referencing any eternal programs" <fossy>Hagfish: i don't plan to implement /all/ of coreuitls <fossy>just for the moment cp, rm, mv, pwd and basename <fossy>because those are the only ones needed