IRC channel logs
2023-07-16.log
back to list of logs
<oriansj>Irvise_: If they proposed using the Debian binary (which is much smaller and a single blob) and had the following plan, it'll probably be accepted. They will using the oldest (and smallest) possible Debian Ada binary, create a bootstrap chain to the newest Ada binaries and frameworks [thus giving as minimal fixed target as possible going forward] <sam_>Irvise_: thanks for sharing <sam_>this is a huge pain for us in gentoo still (for D as well) <Irvise_>sam_: Lucretia, from the #ada channel has been working on the Ada overlay recently, trying to improve the situation, so at least you are not alone :) <Irvise_>oriansj: I expect Guix will prefer the smaller binary, I just don't know how well will it play with the system GCC... That is why I proposed Alire's. But Guix did not pick the tough path for no reason X) <markjenkinswpg>Hi folks. It's been awhile since I said hello. Haven't been reading the chat logs either so out of the loop. <markjenkinswpg>Good news, I haven't been entirely distracted by other things (though true at times). Some of my bootstrapping work has continued quietly in pre-release form <markjenkinswpg>Wrote my byte code interpreter in M2-Planet C and wrote my bytecode compiler in a very minimal scheme variant <markjenkinswpg>But, being easily distractable I decided to pause and first move up the stack to see if I could write something more high level in this Lox subset, demonstrating it's worth finishing the job of bootstrapping <markjenkinswpg>So I decided to "slay the Dragon" (book reference) and started writing a parser generator that could replace the heritage yacc that folks were using to bootstrap bash, but which had licensing issues <markjenkinswpg>I got as far as being able to generate a LR0 automaton, but the limitations of the language started to catch up with me, the classic challenge of bootstrapping <markjenkinswpg>So more recently I've added another layer to the rabbit hole, writing a prototype in Java to force some type safety on me. I'm avoiding features like polymorphism and only using data structure that are like the stack of pairs I was working with in "sublox1" or which I've otherwise already implemented from that in sublox1 <markjenkinswpg>From the java prototype I think I will be able to do a disciplined 1-to-1 re-write to my sublox1 code <stikonas[m]>markjenkinswpg: in case you haven't been following logs, we actually have a problem even earlier <markjenkinswpg>It could easily be another year before I could bootstrap bash's yacc in this manner <stikonas[m]>Still, if you find it fun to work on yacc, you can still continue <markjenkinswpg>interesting stikonas, in both respects I'm trying to work in parallel away from scheme, I use a primitive version of it very early on and my goal is to get away from scheme in the bootstrap path as soon as possible and this may invite other developers <markjenkinswpg>though I appreciate a lot of great work has been done in scheme, more then I could ever hope to catch up on <markjenkinswpg>I'm playing a long game here. Would be very interesting if efforts could eventually converge by me trying to bootstrap that Nyacc problem my own way or to even write a different scheme implementation that's bytecode based with a compiler to bytecode that's not written in C or scheme, but instead in a more high level imperative language <markjenkinswpg>generally low performance (language interpreter vs bytecode interpreter) is okay in bootstrapping, but at a certain point there could be value in ensuring folks writing bootstrappable stuff can have performance not only through guile while they're doing initial work, but also when they're testing the bootstrap path <markjenkinswpg>Another imperative program that I think would be interesting to put through a re-write to lox and also use my parser generator (yacc) along the way would be pcc <markjenkinswpg>Though, even if I can write stuff in this toy language Lox, who knows if anyone else will want to work in it even if I can write/re-write some useful high level programs like yacc/pcc. Possibly folks will need to improve the reference implemention to provide better debug feedback and better interactivity <oriansj>Irvise_: not playing well with the system GCC isn't an issue with guix (as we could just package a version of gcc which does play well with that version of Ada) <oriansj>markjenkinswpg: glad to hear that you are having some fun; exploring the potential solution space ^_^ <markjenkinswpg>Reading that Nyacc related report (306), I see the parser table there is to be re-generated from scheme code. Would be pretty bizarre for me to re-generate that parser table through another path, as ultimately Nyacc makes a lot more sense if everything is done through scheme <markjenkinswpg>But reading back a little bit and just from my own imagination, mes sounds like a challenging scheme interpreter to maintain and extend <stikonas>yeah, that one is perhaps best done in mes <stikonas>I think it's just that fewer people know scheme than C <stikonas>in some sense a lot of our tools get hard to extend at some point <stikonas>e.g. it's not easy to add much more support to M2-Planet... <markjenkinswpg>ah yes, another imperative program I want to attempt a re-write of in a higher level imperitive lang <stikonas>it has quite good support for C99 but the way tcc itself is written is very ugly <markjenkinswpg>I think part of how bootstrapping has to succeed over the long run is to rely more on tools building higher level tools vs trying to maintain a lot at a lower level. tcc sounds like another good example to get away from <stikonas>(one letter variable names, poorly commented, etc...) <oriansj>well int i as an index is fine; poorly commented on the other hand is hard to excuse... <markjenkinswpg>I personally want to work with as little assembler, M2-Planet C, Scheme, and C that I can get away with <stikonas>oriansj: int i as an index is indeed fine as it is a well known convention, but when all other variables are like this, it's hard to read <markjenkinswpg>To my list of "avoids" I should add "forth". I'm fascinated by the theoretical bootstrappability of my power macs, OCPC-XO and other people's Sparc machines, but if I ever go there I'll be looking to leap out of Forth asap too <oriansj>markjenkinswpg: completely fair; parser generators and the like really can save a good deal of manual effort <markjenkinswpg>My thinking is just that parser generators are nice when somebody has already done the hard work of constructing the right grammer, precedence indications and actions. Bash an pcc come to mind first. <markjenkinswpg>Not sure how much I actually want to use parser generators as a tool beyond that, though I'm going to attempt as a dogfooding exercise to put together a grammer for my loxsubset + a few extra features <markjenkinswpg>I would actually add yacc grammers and specifically parser generators only accepting LALR(1) to the list of tools I want to bootstrap away from :). Am kind of facinated by Python using something else, "PEG" or something <markjenkinswpg>anyway, I'm going to go back to my research cave. (not an academic by trade FYI). Will try to check back and read more, maybe drop some github gist links as pre-releases, and hopefully switch this parser gen project to public mode within a few months <[exa]>PEGs ain't bad, just sometimes very cringely slow <[exa]>yeah the landscape is complex <[exa]>I'm not sure if someone solved it but the last time I looked at the theory it was still unknown whether PEGs are strictly stronger or weaker than usual context-free grammars <[exa]>PEGs can do e.g. {a^nb^nc^n|n is natural} but the trick doesn't generally apply to context-sensitive grammars <[exa]>and general contextfree grammars (Earley/CYK/etc) can explore the whole possible parse tree but no one showed yet if that would be a problem for PEGs <[exa]>s/grammars/grammar parsers/ s/parse tree/parsetree space/ <stikonas>doras: do you know why python checksums differ? <stikonas>i.e. would it not break qemu bootstrap where you are not changing available devices? <doras>Yes. No impact on binaries as far as I could tell. <stikonas>ok, but test -c "/dev/ptmx" would run in qemu mode <doras>I ran all possible bootstrap modes other than bare-metal, I think.