<siraben>OriansJ: I think you can remove the wasm and site-generation stuff <siraben>`cobble` is Ben Lynn's own website generator <OriansJ>siraben: true and to properly start fuzzing the vm, I'll need to make changes with how it handles input <OriansJ>So it is going to be a rather major changes to get it into bootstrapping shape; which will probably not be liked upstream. <OriansJ>But fortunately because you got them to license it under the GPLv3; that isn't going to be an issue for us. <OriansJ>But there remains alot of work to strip out everything implicit in the bootstrap and make it all explicit and obvious. <OriansJ>and I am starting to think he never heard of >> in bash <OriansJ>well why do (cat rts.c && ./vm run effectively.hs < lonely.hs) > lonely.c; when cp rts.c lonely.c && ./vm run effectively.hs < lonely.hs >> lonely.c is more clear <xentrac>it seems like a matter of subjective preference to me <OriansJ>xentrac: fair but I also tend to work with a far more minimal shell (kaem) <siraben>OriansJ: I noticed you used >| which I hadn't seen before <siraben>Didn't know it was another operator altogether! <OriansJ>siraben: noclobber is just standard for my ~/.bashrc because I make mistakes <OriansJ>So if I do thing > $foo and I got what $foo is wrong; it doesn't damage anything I might care about <OriansJ>but if I am writing to thing > foo and I know that I am going to overwrite something; just toss on the | <siraben>OriansJ: expect a *lot* of segfaults during fuzzing. One thing I'm tempted to do is port the assembler to Haskell for the earlier stages. <OriansJ>siraben: I can fix alot of segfaults pretty quickly with require <OriansJ>think of it like M2-Planet's version of assert but it operates at runtime <OriansJ>require(bool, message_string_when_error); <OriansJ>so if foo != TYPE_H => require( foo != TYPE_H, "foo was type_h\n"); <siraben>One thing I'd like to understand is the garbage collector `evac`, that's the only part I didn't read in detail <OriansJ>siraben: well we are going to get deep into its guts and tear it to pieces squeezing out all the understanding that can be found in it. <siraben>Let me know if you have any questions regarding how/why the VM works. <OriansJ>siraben: how VMs work is usually just a state machine, which I just need to map out. <OriansJ>The why for primitives I might need to have a greater understanding of Haskell and I am sure that you can help with that. <nimaje>(asserts are also at runtime, but normally defined to nothing in a release build) <siraben>Ah, I also need to adjust the generated C code in the later stages to make it M2-Planet compatible. <OriansJ>siraben: that definitely looks like it might take a while <siraben>Yeah. I'll need to understand what subset of C I can use <siraben>Looks like the C code generation starts from the guardedly.hs compiler <siraben>How would you translate `static unsigned root[] = {1,2,3,4,5};`? <OriansJ>well first I'd make it unsigned* root; do a root=calloc(5, sizeof(unsigned)); and then do root[0]=1; root[1]=2; etc but depending on how common that is we could implement that feature in M2-Planet <siraben>That's the code generation, should be somewhat readable if you look at the strings. <siraben>I could make it a sequence of array assignments, if needed. <siraben>I wouldn't want to complicate the C source, it really wouldn't be a lot of work to generate the list of assignments. <OriansJ>siraben: performance is not a priority for bootstrapping, just a nice to have <OriansJ>keep things as simple as possible and later if it matters we can make it faster. <xentrac>stacking layers of interpreters on top of each other suffers progressive slowdown, not layers of compilers <xentrac>making compilers slow usually requires making them sophisticated <siraben>Depending on what the later stages look like, it could mean removing the intermediate C language altogether, going from Hex → ASM → blynn-compiler → mes <xentrac>(although maybe if someone writes a bootstrapping compiler in prolog they'll create a counterexample) <OriansJ>siraben: I would be surprised if it was easier to write a Haskell compiler in Assembly than to write a C compiler in assembly (cc_x86 only took 20 hours total) <siraben>OriansJ: It would involve porting vm.c to assembly <xentrac>btw, not relevant to what we're doing here, but do you know about the B and C combinators? <xentrac>*blush* well uh I haven't actually looked... <OriansJ>siraben: problem that we don't have a bootstrapped EVM virtual machine to run said code <siraben>OriansJ: haha of course, but I'm only using the basic opcodes of the EVM <OriansJ>we have M1 macro assembly and bare metal to work with here (until I get M3 done) <siraben>Of course for entirely different reasons than Haskell, Lisp, C, etc. lol <OriansJ>hmmm vm; does not like being moved to bin/vm ***ericonr- is now known as ericonr
<fossy>OriansJ: is VM.c complete in m2 planet now? <fossy>This weekend we will see some further kaem improvements ***nckx is now known as jorts
***jorts is now known as nckx