<fossy>OriansJ: looking at the test structure of mescc tools again <fossy>what is the point of check.sh <fossy>shouldn't people just be running make test <fossy>and do you have a problem with kaem not using hello.sh? Because essentially all of them would have the same hello.sh <OriansJ>fossy: check.sh was a legacy hold over that I haven't gotten to purge yet. <OriansJ>fossy: it is fine if they don't have hello.sh but the tests need to be numbered. <OriansJ>as it would be odd to use bash to run a script to test kaem. <fossy>siraben: vm run compiles stuff to ION assembly, right? <fossy>which isn't a problem for trusting trust because it's haskell -> ION assembly and haskell is readable. right? <fossy>but it is a problem for singularity and co because its... just raw ion assembly which is unreadable <siraben>> The backquote is a prefix binary operator denoting application. For example, we represent the program BS(BB) with: ``BS`BB; <xentrac>not sure I'd be able to spot an intentional backdoor in a program written in the form ``BS`BB <fossy>but arent we reimplemnting the asm thing in scheme or c <siraben>If someone could hide a compiler backdoor in that, props to them lol <siraben>The only way to produce characters to output is through combinators like #, so #a represents the character a <siraben>you could obfuscate it by adding characters together, presumably. but it would blow up the size <siraben>I agree with trusting trust, and we should make it as readable as possible. So, I could rewrite the earlier stages in Scheme at a later point <fossy>didn't OriansJ want to do that before we continued <siraben>Skip the first few stages and go to binary written in lisp <siraben>Few caveats: requires a lazy (call by name) lisp to evaluate <siraben>identifies like @a may or may not be parsed by mes-m2 <V>baby don't byte me no more <siraben>fossy: it's one of the stages of blynn compiler <siraben>his website should have a description <siraben>fossy: probably because it's in vm.c <fossy>make it work under mes-m2 or make mes-m2 work with it, then what <fossy>no i know what binary does but how do we slot it into this <siraben>so let's go from mes-m2 → binary → rest of haskell → scheme <fossy>looks like we are getting somewhere :DDD <siraben>so my effort to rewrite binary in lisp was not in vain <siraben>specifically we need an interpreter for lazy lisp in mes-m2 to run binary.lisp <fossy>could binary.lisp not need lazy lisp <siraben>actually, that'd be would probably be the easiest approach <fossy>siraben: which lisp did you use to test this <fossy>i am having trouble getting it to run under guile <siraben>i adapted the previous stage to accept lisp syntax <siraben>so it will not work under guile without rewriting everything <fossy>so, how do we run binary.lisp under mes-m2 ***pgreco_ is now known as pgreco
<OriansJ>siraben: guile supports lazy evaluation; so I am curious what exactly we need to get the lisp version of binary working in a general way <siraben>OriansJ: the laziness would have to be pervasive, see `binary.lisp` <OriansJ>and there is no way to write it in a non-lazy lisp? <OriansJ>look, guile is good enough to run MesCC and guix and gash and do the full bootstrap. Requiring more than guile doesn't exactly help the bootstrap. <OriansJ>as mes-m2 is just a small subset of guile's primitives <OriansJ>So what alternate solutions could we explore? <OriansJ>for example could we rewrite one of the earlier stages in lisp (something that guile can run) and use that to remove the blobs? <OriansJ>then say rewrite binary in the haskell subset that it would provide? <OriansJ>There are an infinite number of possible solutions. What feels like the least work and frustration for us? <rain1>mes-m2 → binary → rest of haskell → scheme are these interpreters or compilers <siraben>rain1: mes-m2 → binary is done via interpreter <siraben>i'll rewrite binary.lisp completely to make it work on a non-lazy lisp <rain1>so you wont have everthing fall over due to interpreter tower slowdown, thats good <OriansJ>siraben: if that is what you think is best; I look forward to your results <OriansJ>rain1: right now the build time for everything (if we use GCC) is 204.82 seconds <OriansJ>assuming things are 10 times slower because of M2-Planet (and its slower binaries); 2048.2 seconds time to the haskell <rain1>that is a brilliant build time! <OriansJ>rain1: could be better but we are still at the early stages of exploring this option and checking our assumptions might find us even better solutions. <rain1>I would like to know which thing are able to execute tinycc? <rain1>i think it is mescc and gios asmc, are those both true, anything else? <OriansJ>rain1: well that would be posix kernels that actually execute tinycc but if you mean compile that would be MesCC in our current understanding of the bootstrapping path <OriansJ>there was also the plan to rewrite TCC in the M2-Planet subset and call it M3-Star <OriansJ>but I wanted to break the linker and assembler out of TCC and provide a binutils compatible set that MesCC could use to help its porting to new architectures <OriansJ>just need to write the function that dumps the generated ELF file onto disk <OriansJ>(Then do the port to AMD64, armv7l and AArch64) <OriansJ>Then I would do the assembler which generates standard relocatable ELF files; thus allowing us to use standard linkers with it too <OriansJ>we will be limited to dealing with binaries greater than 2GB but that shouldn't be an issue <OriansJ>correction: limited to working with binaries that are less than 2GB in size