IRC channel logs
2019-11-16.log
back to list of logs
<oriansj>xentrac: no problem; just remember hardware is always faster than software but flaws can't be fixed and everything added has to be supported forever. (Including that little stupid dance bootloaders need to do to get to protected mode) <fosslinux>hey. i'm having an issue with cc_x86 on stage0. the rom sha matches. <fosslinux>Invalid state reached after: 11 instructions <fosslinux>16386: Writeout bytes Address_2 is outside of World <fosslinux>this /seems/ to be a problem with my bin/vm binary, but i'm not completely sure <oriansj>fosslinux: actually not silly but a useful attempt to help us identify and solve a potential problem. Thank you <janneke>yeah, i agree; when you (finally) see what went wrong it is often very easy to correct; that hardly changes how easy the puzzle was to solve without that awareness <janneke>i am having this boot-9 module system integration puzzle, maybe that talking to #bootstrappable works <janneke>mes is using `handle's to store variable values, a pair of a symbol and any value: (key . value); e.g. (foo . "bar") <janneke>for local variables and closured variables, these are stored in an alist, globals are stored in a hash table <janneke>now, guile (i am looking at 1.8, but also current versions) has an extra indirection, called #<variable> <janneke>so, guile stores variables like this: (foo . #<variable "bar">) <janneke>actually, it prints like (foo . #<variable value: "bar">) <janneke>the boot-9 module system expects such variables, module-variable, variable-ref, module-add etc. <janneke>that all works now in mes, but it seems problematic for integrating it in eval-apply <janneke>eval-apply wants to do: symbol -> value <janneke>adding a simple extra indirection for variable does seem to work <janneke>'foo -> (foo . "bar") => handle->cdr <oriansj>So like how Slow_lisp handles variables <janneke>'foo-boot9 -> (foo-boot9 . #<variable "bar") => handle->cdr -> #<variable "bar"> -> var->value *boom* (somewhere deep in eval/apply) <oriansj>why don't we do something simpler and smarter for modules <janneke>i cannot see why an extra dereference of a #<variable> would not work; afaiu a #<variable> never directly holds another #<variable.... <oriansj>wouldn't an alist forest be a simpler way to handle modules? <janneke>yes...i'm pretty ambivalaent -- using guile-1.8 code gives pretty good guile compatibility! <oriansj>well that is one option we never really took seriously <oriansj>I mean; converting guile-1.8 to M2-Planet is something entirely technically possible <janneke>i would like to not rewrite boot-9 right now, just use it if possible and rewrite later (oh ... my usual pitfall?) <oriansj>janneke: what if we attacked this from an alternate route? <janneke>but i also don't want to add this #<variable> indirection everywhere and spend one extra cell for each variable <oriansj>Let us ignore guile's internals for a second and think in terms of scheme functionality and behavior that actually what we care about. <janneke>yeah, well... things like variable?, variable-bound?, module-variable, module-define! are public guile functions; so having them could be a feature. otoh, we could always decide on adding them later and start small <janneke>or not add them and rewrite nyacc or guix code if it needs such details <oriansj>well that is the thing, when I see variable? I think walk the current alist and return #t if found and #f if not but nothing that would require any of those implementation details <oriansj>when I see module-define! I simply imagine a pointer to an alist assigned to a variable name <oriansj>if I have good primitive tests; I can make mes-m2 do anything you want janneke <oriansj>for example I made mes-m2 vectors internally lists without it being visable to programs that leverage that functionality <oriansj>and I can do that for anything else if I have good tests <oriansj>remember at the core; alternate but compatible where guile doesn't abuse the spec <oriansj>we at this moment have 2 paths ahead of us: 1) take our working mes-m2 and expand it slowly with more and more working tests or 2) make guile-1.8 buildable by M2-Planet and hopefully not break it while doing so <oriansj>personally I find the task of making guile-1.8 buildable by M2-Planet a bit of a task (akin to just making TCC directly buildable by M2-Planet) and thus propose the following plan: MesCC expands to be able to build guile-1.8 and GCC 4.7 directly; during which time I expand mes-m2 to the support all of the functions required to run MesCC directly. <Hagfish>i wish i could picture how the shell/kernel fits into this <oriansj>Hagfish: well the shell is going to run on mes-m2/guile and the kernel becomes a simple spec with a handful of required syscalls <oriansj>As janneke strips out all binaries except guile from the guix bootstrap; I'll be making mes-m2 a drop in replacement for guile <oriansj>Once that work is done; I can simply write a trivial bootloader and Posix in M2-Planet, use cc_x86 to build it and the trusted kernel problem is gone too <oriansj>Then I do Knight in FPGA and then TTL to finish off all bios/firmware/microcode risks <oriansj>Then I have no idea what I am going to do then <oriansj>janneke: there is a new branch on mes-m2 that holds the current state of my crazy idea (a merging of mes-m2 and slow_lisp [Not fully complete yet but showing potential]) <oriansj>with it we gain a trivial to add macro capability (I literally left a simple TODO); single S-Expression Stepping and soon a more efficient form of Tail-recursive evaluation <oriansj>also, it halves Mes-m2's memory requirements; supports both (define foo (lambda (a b) ..)) and (define (foo a b) ...) function types <oriansj>and the REPL does exactly what one expects <fosslinux><oriansj> fosslinux: actually not silly but a useful attempt to help us identify and solve a potential problem. Thank you <fosslinux>is mes-m2 currently working at a stage where it can run mesc <oriansj>fosslinux: honestly no, I broke Mes.c when converting it to M2-Planet form <stikonas>fosslinux: no, I don't think it can't run mes-m2 <stikonas>it can run some simple scheme tests only <oriansj>hence why good scheme tests are needed (That are compatible with both guile and mes.c); So that fixing what is broken can be done methodically <fosslinux>i guess if I want to contribute I should learn a bit of scheme <oriansj>fosslinux: if you learn scheme one feature at a time and create a test that leverages that one feature; it'll be double useful for us <janneke>oriansj: oh, that's interesting! that could work <janneke>fosslinux: mes's wip-m2 branch will run mescc; oriansj is doing something much more experimental and fun :-) <oriansj>Which has lots of work needed from scheme programmers of naive to professional levels of skill <oriansj>(More naive than professional right now) <oriansj>With lots of bits to gain experience on and level up <fosslinux>oriansj: so are the test0* the scheme tests? <oriansj>fosslinux: all tests in mes-m2 are scheme tests; I just don't have the functionality required for the later tests to enable them yet <oriansj>the last of which is running MesCC to compile C code (ultimately itself and then TCC) <oriansj>fosslinux: it is a part of mes.c that I am cleaning up but essentially boot-01.scm is just a set of scheme functionality loaded by default <janneke>fosslinux: the scheme tests and mescc tests that i wrote for mes.c are pretty ad-hoc; oriansj is rewriting everything much more vigorously in mes-m2 <oriansj>essentially with the goal of making mes-m2 the ultimate educational scheme