IRC channel logs
2019-09-28.log
back to list of logs
<OriansJ>Now for the tough question of the day. Should I submit a proposal for a LibrePlanet 2020 talk about the stage0 work? <OriansJ>This of course is the question that I present here because ultimately the talk would be for us. <jackhill>I wonder how hard it would be to get additional ones to bootstrap from the ones that are <xentrac>there is a missing t in that page title <xentrac>I am confused about what the page says about Lisps though <xentrac>why would you need lazy evaluation for macros? I think someone was unclear on the concept of Lisp macros when they wrote that entry <xentrac>at some point Ur-Scheme stopped building successfully with Guile; I should fix that <xentrac>OriansJ: I don't know anything about LibrePlanet but I think giving talks about stage0 is an excellent idea <rain2>jackhill: it may be quite difficult do you have a specific scheme you want to try? <rain2>a big part of the trouble would be implementation specific quirks of the language that are used to implement the language <rain2>one would have to simulate those in the host scheme <rain2>and this can be a very long and difficult process with something large like a whole compiler <rain2>I think that it's easier when bootstrapping off a smaller simpler compiler was designed in from the start <OriansJ>jackhill: well much of the data comes from people here and I guess there has not been an exhustive search for lisps/schemes yet <OriansJ>xentrac: I am to blame for the lisp macros part and to be honest it was written after I wrote a lisp interpreter in assembly and was trying to figure out how to shoe-horn macros into slow_lisp (Improvements to the wiki are always welcome ^_^) <OriansJ>xentrac: Libreplanet is a very FSF heavy event and I found they tended more towards talks about politics than technical work. In fact they did reject my last 2 proposals outright and my 3rd they accepted but turned around and said that my talk got pulled from the schedule to make room for another talk they wanted more. :shrug: <OriansJ>speaking of which I guess it is time for me to admit I need some help. Specifically with mes-m2 [https://github.com/oriansj/mes-m2] I need someone familiar with guile to add some scheme tests for all of the scheme primitives which succeed on guile but will catch me if I break that primitive. <janneke>OriansJ: what exactly are you looking for, beyond what you have now in test/? <OriansJ>janneke: one test per scheme primitive; so that I can change the implementation of primitives individually <OriansJ>and make sure each primitive behaves exactly like guile <OriansJ>thus when I am done; mes-m2 will be a drop in for guile for the guix bootstrap <janneke>yes, my tests are pretty ad-hoc, and followed the evolution of my learning to write a scheme... <OriansJ>well that is the next major step for guix anyway; reduce the bootstrap binary down to only a gcc statically compiled mes-m2 with the scheme source files for slow-utils and MesCC <janneke>yes, sure -- but i like your approach <OriansJ>Which means someone needs to import all of the scheme replacements for core-utils into slow-utils (including gash) *janneke needs to go afk in 5min -- will be back later "tonight" <OriansJ>I have to hammer mes-m2 until it is 100% deterministic across all platforms and possibly behave better under low memory conditions <OriansJ>I also have to rewrite several mescc-tools into scheme to remove those binaries from the next generation guix bootstrap <OriansJ>and then once that is done I can finish getting mes-m2 into a form buildable by M2-Planet (which ends the bootstrap problem forever) <OriansJ>Then I have to go back and do the hex0->cc_armv7l for armv7l and hex0->cc_aarch64 ports. <OriansJ>Then I have to do a posix from M2-Planet v1.x to eliminate Linux from our trusting trust domain. <OriansJ>Then I have to do FPGA work for knight to eliminate the hardware from the bootstrap scope down to a single FPGA+RAM. <OriansJ>Then I have to implement that design in TTL and then I'll finally be done. <OriansJ>Then I was planning on getting an 686-pae FPGA design for those wanting to reduce their hardware trust down to FPGA+RAM <OriansJ>Then if someone hasn't done it already, create a libresilicon design for the above; thus providing libre-hardware for those who wish to use x86 or knight and not have to worry about malicious hardware. <OriansJ>also I still need to find people to audit the work, find typos and force me to clarify anything that I have done that does not seem immediately obvious to them. <jackhill>rain2, OriansJ: thanks. I'm most interested in Chez and Racket. <jackhill>which does look like it would be very non-trivial to do. <jackhill>but I was hopeing that bootstrapping via different implementation would be more attractive to scheme authors, than maintaining a bootstrap via a different language that your community isn't excited about/experienced with using. <OriansJ>jackhill: well, we will have a universal bootstrap scheme with mes-m2 <OriansJ>then provided your scheme can be bootstrapped from scheme (such as from guile) then we can keep that bootstrap problem small <OriansJ>basically for bootstrap chains that wish not to do alot of heavy lift, assume guile, gcc and the full Gnu toolset <OriansJ>jackhill: scheme has a problem; all of the good scheme implementations are quite complex (because otherwise they would be slow) and all of the simple scheme implementations lack functionality required to used for real scheme programs that do important work. So janneke built mes.c which honestly is an amazing result given that it right out of the gates was able to run a C compiler good enough to self-host itself. That is why I am <OriansJ>hammering on mes-m2. Because there is nothing else out there good enough that we have found to replace it and honestly because I really don't want to put in the 2 years of work required to skip the work janneke has done by making M2-Planet v2.x build tcc directly. <OriansJ>The work remaining on mes-m2 is at this point about removing guile from the guix bootstrap by extending mes-m2 to the point guix can be run off it directly (atleast enough for it to do the guile build) and for me to get it into a form M2-Planet v1.x/v2.x can handle <jackhill>OriansJ: cool! You and janneke (and everyone else) are doing amazing work, thanks! Bootstrapping other schemes with guile and gcc sounds reasonable, even if it is a log of work :) <OriansJ>jackhill: well we encourage everyone here to make any amazing thing they think is missing ^_^ because honestly we are all better when we help each other. <OriansJ>hopefully you are working on something fun this week jackhill <OriansJ>for example if anyone wanted to pick up the minimal posix in M2-Planet work that would be amazing (you can do most of the development with gcc and do the conversion at the end) or if someone wanted to do FPGA work to ensure those pieces are in place sooner. [Lots of room for people to work on the pieces they think will be fun or needed] <jackhill>OriansJ: this week, I'm learning lots of stuff about languages and compilers, so that is very fun <OriansJ>jackhill: that is great if you have questions we love to help ^_^ <OriansJ>janneke: I've uploaded the blood-elf in scheme prototype (play with it and see if works as a drop in replacement for the binary version for MesCC) Assuming nothing is wrong with it; I'll get started on M1-macro in scheme and then you can remove mescc-tools from the mes-m2 bootstrap base (unless you are using kaem and in which case; I'll do that one next) <rain2>I don't know how to bootstrap chez, it seems very difficult because it depends on binary blob boot files <rain2>racket was almost bootstrappable - I think the core of the compiler was basically all written in C and there was only a couple generated files - but that's all changing with the move to chez <jackhill>rain2: thanks for the pointer. Inteed C Racket seems easier than Chez Racket. Would be nice to teach Guile how to build the Chez boot files.