<oriansj>janneke: check out the latest commit on the slow_lisp branch <oriansj>janneke: how important is #; to MesCC? <fosslinux>speaking of void linux, this makes me very happy <janneke>fosslinux: "Newly, it is bootstrapped with openjdk7-bootstrap, so it does not need to download binaries." <janneke>do you know how openjdk7-bootstrap is created? <janneke>oriansj: that's just wicked -- i like it! <janneke>oriansj: #; is very convenient. you won't see it much in guile because paredit does not support it? matt wette is a fan of it and uses it in nyacc. why not support all comment styles? otoh, like with most things: any feature can be dropped and if it's really important, it will come back ;) <janneke>ah, and you moved quasiquote to C; great <fosslinux>> This is a new toolchain used to bootstrap OpenJDK 8. It is itself bootstrapped using gcj-6 (#16415), which lets us compile the whole chain from source without fetching foreign binaries. <fosslinux>i'm wondering; is there a reason guix dosent do it this way? it seems to be a far more straightforward path to use gcj-6 from gcc <oriansj>fosslinux: that is always an option; if the process can be vetted to not include binaries <oriansj>janneke: I'll be adding (define (newline) (display #\newline)) to test101 and soon it'll run directly on mes-m2 <stikonas>fosslinux: doesn't void linux suffer from the same problem as gentoo ecj binary is still there? <stikonas>guix has quite a bit longer bootstrap path to solve that <stikonas>so I don't think you can easily shorten openjdk bootstrap path... <stikonas>ghc is still using binaries on guix, am I right? <oriansj>I honestly don't know anyone working on it right now <oriansj>janneke: would the minor restriction of #; that there is no space after the ; before the thing being commented out a reasonable compromise? <oriansj>Then I can write a simpler solution to the #; problem in the reader (basically as far as the tokenizer is concerned, that block never happened <oriansj>much like the #|, #! and ; comments are dealt with now <oriansj>aka #;foo and #;( foo .....)) is fine but #; foo is not and #; (foo ..) is not <oriansj>days like this make me wish C had a proper loop command so I don't have to do while(TRUE) <janneke>oriansj: i think the compromise is reasonable...i do wonder why it's hard to read one sexp and then drop it <oriansj>janneke: because the read and tokenization are entirely seperate <oriansj>read just knowns chars and returns a single string; tokenization only gets a single string and converts it into an S-expression <oriansj>ironically the dumb_lisp approach is only 2,184 lines of C code (thus far); while mes.c was 5,407 lines of C code; so by shoving more into C our lisp is smaller? <oriansj>but I must say janneke your error handling is far nicer than dumb_lisp's <janneke>oriansj: i resurrected stack traces while i was getting stuck trying to debug the guile module booting; that's really awesome :-) <janneke>made me almost want to add real source-properties with source locations... <oriansj>actually that is something rather simple to add to the dumb_lisp reader <oriansj>(literally just add a line counter and a hook in tokenize) ***zigzag is now known as zig
<oriansj>hmm Ironically test101 gives alternate results <fosslinux>oriansj: oh, I see now the ecj jar included on the gcc6 package <oriansj>fosslinux: we love great news, simpler solutions and the rest but we also have to be careful to make sure no binaries slip in "accidentially" <fosslinux>i thought later, well guix has been doing this for a long time... im pretty sure that there's going to be a good reason that they haven't done it this way <oriansj>well sometimes it is because we are so buried in our work we miss beautiful things done around us (like 2 different bash alternatives in scheme) <oriansj>janneke: checkout the latest slow_lisp commit (test101 is working again, no extras required) <fosslinux>if i was to attempt to bootstrap eg rust, is it best to start packaging stuff for a distribution at the bottom of the chain (mrustc) or the top (increasingly older versions of rust)? <oriansj>fosslinux: depends on your style; working from newest to oldest provides immediate results. working from bottom up means you know what you have to work with at every step of the journey <oriansj>now that guix has a chain for bootstrapping rust; you gain the advantage of knowing the solution when working from newest to oldest and get double benefits <oriansj>results know and predictable success as you walk back in the chain <oriansj>Me, I like knowing what I have to work with going forward; it keeps things simple <oriansj>for example; I know if MesCC v1.0 can build NASM, then I know MesCC v2.0 can leverage NASM to simplify the binary generation process and benefit from all the work being done by the NASM team. <oriansj>or like janneke learned when he switched from writing direct binaries to M1 macro output instead; that I could catch problems and make his job easier going forward. <oriansj>janneke: hopefully you don't mind that the slow_lisp has let as a primitive (that behaves just like let*) <oriansj>and is there any macro functionality you require beyound define-macro ? <stikonas>fosslinux: regarding mrust, I thought new versions of mrust can bootstrap newer rust <stikonas>i.e. you don't need ot start with 1.17 or so <oriansj>(currently my list of features required to be added to slow_lisp is: define-module use-modules load and define-record-type) <janneke>oriansj: it was on my wish list to have letrec as a primitive <janneke>that's what guile used to do until 2.0 i think, now it has letrec* <janneke>but i'm exploring the path of booting psyntax some time, recent guile versions need at least one of those <janneke>having let is already a great start! <oriansj>janneke: well that is the thing, once I have some good tests, reasoning about implementation is rather straight forward <oriansj>If I need to add letrec and letrec* to get us there; write the tests and I'll get it done <oriansj>Slowly but surely, the more eyes spotting my flaws the better <fosslinux>stikonas: yeah, still have to start with 1.29 <fosslinux>rustc bootstrap tested and validated (1.19.0 validated once, 1.29.0 is repeatable) <xentrac>letrec* was sort of implicit in Scheme's semantics for nested defines already <xentrac>I feel like most of the time you could just use letrec* instead of letrec, let, or let* <xentrac>probably always with a little bit of beta-renaming to prevent name collisions <xentrac>but beta-renaming is beyond the power of syntax-rules