IRC channel logs
2023-05-15.log
back to list of logs
<emilytrau[m]><ericson2314> "what branch/repo should I target..." <- nixpkgs targets the mes-0.24 branch 👍 <ericson2314>emilytrau: saw that. Yeah I guess my question was more does stuff from non-mes branches still get incorporated <ericson2314>since that this feature isn't about bootstrapping/mes per-se <ericson2314>another thing is that tcc seem, like gcc and clang, confused on whether -B should point to something with a lib/ subdir <janus>I like how he even explains how LML itself was bootstrapped <ericson2314>oh I guess -B is only supposed to have lib subdir for PE <janus>It's interesting to me because everyone who is trying bootstrapping nowadays seems to be trying real hard to avoid LML <stikonas>janneke: thanks again, I think lists do work <stikonas>I just tried it for a few minutes and managed it to print the first bit correctly <stikonas>you probably saved me a fair amount of time <janus>Bootstrapping to me always sounds like you're making a compiler. But strictly speaking, you'd only need to interpret HBC, right? <janus>I am not saying it is the most viable option, I just thought it was interesting that we have a claim that this is what was *actually* done <janus>It is good news for me working on the ghc-0.96 sources, because I had gotten the impression that the HBC specific code was a bit more extensive <janus>So I have been using that as a reference, which is good, because that is the code that was actually working, according to Augustsson <janus>So even though we don't have an LML interpreter, it still is a valuable tidbit for anybody looking at the ghc-0.96 sources <stikonas[m]>E.g. mes is interpreter too that is useful in bootstrapping tcc <ericson2314>it is good for GHC to abstract its own IO better anyways <ericson2314>emilytrau: one cannot go from m2 straight to tinycc, no? <janus>ericson2314: So you're saying, first patch GHC master to abstract out it's own I/O? And then use that new GHC to compile the oldest possible GHC to Core? And then run that with the new interpreter? <ericson2314>janus: it is not the past of least resistance for bootstrapping probably, but it brings a bunch of benefits <ericson2314>IMO there is an interesting distinction between "history reply" and non-"history reply" bootstrapping <janus>Right ok. It's an interesting proposal because I think many are discouraged when they hear that they have to use gcc-2.96 and such... <ericson2314>for garbage fires like C++, history reply is the only way <ericson2314>but for a "nice" language, it really ought to be possible to do better <ericson2314>and if one cannot do better, well then you should loose your "nice language" status <janus>ericson2314: It also has the advantage that you get to know the current GHC codebase, which is a more marketable skill than knowing the 0.96 codebase :P <janus>So it's interesting that you say it is not the path of least resistence, because it kinda seems to me that it might be, when you consider the big picture of somebody deciding to spend X amount of days working on this <ericson2314>there is some....cultural friction about what constitutes good software engineering <ericson2314>I will be at Zurihac in a few weeks, hope to keep the discussion going then <janus>Sadly I can't come this year... But I like your proposal. Did you ever talk to Joachim Breitner about it? <janus>I suppose in a way Breitner's proposal might align with what you're proposing, since he'd also have to use only the simplest of IO if Hugs' runtime system is to be compatible? <stikonas[m]>We added some features recently (e.g. structs on stack) <ericson2314>It sort of seems there is a little scheme vs unix rivalry in the bootstrap :) <ericson2314>janus: I've been involved with a "split-base" thing, to try do separate implementation agnostic vs specific stuff in the standard library <ericson2314>maybe a s-expression C would be a good intermediate step :) <stikonas[m]>One could also port mescc from scheme to M2 but it's non trivial work with little benefit <stikonas[m]>mes might be slow to build itself, but GCC 12 is slower <oriansj>ericson2314: well the problem with M2-Planet is that it supports enough of the C lambda core to do anything one needs to do but it lacks enough of the extra C features that people generally choose to use to do more advanced things. And there is a minor hobby project of mine which is effectively S-expression M2-planet but it doesn't bring much benefit as I doubt one would tweak mescc to run in that subset. <muurkha>I don't think rekado's writeup mentioned LML or HBC? <muurkha>"Lazy ML" sounds plausible; is that a thing that exists? <muurkha>I'm guessing the LML version of GHC doesn't survive? <probie>LML wasn't used to build GHC, it was used to build HBC (and HBC was used to build GHC) <muurkha>oh, thanks for the correction. does HBC survive? <probie>I think so. I've just been playing around trying to get it build. I think it might actually be buildable (and I've got a version of ghc which thinks it can be compiled by hbc) <probie>I think it includes an lml compiler written in C under src/syntax <probie>it might actually be possible to bootstrap GHC via getting hbc to build and then working your way up through a dozen or so versions of GHC <probie>nevermind, it does actually depend on an installed lmlc <probie>that said, it looks like you could bootstrap ghc via hbc if one wrote an lml compiler in C (or another bootstrappable language) <[exa]>probie: the possibility is wildly theoretical given the insane amount of spacetime ghc actually needs for compiling and the complexity of build tools all around <[exa]>there's some push even in hs community to provide a better bootstrap for ghc than "the last blob from the chain of blobs" but it's going slowly <muurkha>Augustsson's paper seems clear enough about LML, especially with all of SPJ's later fine work elaborating on the G-machine model <[exa]>imo if the purpose of haskell here is to provide a strong tool for compiling stuff, I'd go for just reimplementing LML because it's going to do the same job for like 1% of the price <probie>As a user of GHC, I'd like a path to build it that doesn't require trusting some binary that someone generated 20 years ago <janneke>"<ericson2314> emilytrau: saw that. Yeah I guess my question was more does stuff from non-mes branches still get incorporated" <janneke>it would be nice if the bootstrappable patches could be ported to a newer tcc, there have been several attempts the past years but they did not lead to a runnable tcc yet <theruran>Irvise_: I just read your messages above about targeting an old GCC/GNAT would be problematic because it would require so many compiles in the path; and maybe it would be easier to write a separate compiler that targets a current GNAT or the GCC 4.7 (?) that is targeted by mescc <theruran>as an aside, I am interested in writing a formally-verified Kernel LISP using Vale/FStar then translating the assembly into the stage0-posix path. probably no time for that tho! ;((( <theruran>because having LISP pre-C in the bootstrap path is very appealing to me, and could be used to write an Ada compiler <stikonas>wouldn't it be simpler to keep these as separate goals? I would expect that it isbe simpler to write ada compiler by using far more powerful tools (C/C++, Guile, etc) rather than be limitted to stage0-posix stuff <theruran>yeah, well Kernel would need some things like pattern matching, a parser combinator library, and some binary file manipulation probably for the linker (gnatlink). and while those could be translated from Scheme it probably wouldn't be the most straightforward thing <theruran>Irvise_ and I talked about it before. getting GNAT to compile and building an full Ada compiler seemed like separate goals. and using an existing small Scheme, and writing one to be pre-C in the bootstrap path also seemed like separate goals <Irvise_>theruran: yes, you understood it correctly :) <Irvise_>I think jumping directly to GCC 4.7 is the best we can do. <Irvise_>Regarding jumping the C dependency: that is why I wanted to take a look a look at using Mes instead of TR7. <theruran>🤔 so jumping to 4.7 doesn't seem like a big scope change from GNAT 3.1 or whatever <theruran>I was thinking we don't even need to write a type checker if we're just bootstrapping GNAT, right? <theruran>because like, the goal is not to verify the GNAT implementation of the Ada spec. it's just to get a bit-for-bit executable. right? <theruran>Irvise_: well Mes is written in C but at least it is a C subset. I'll have to give it a good run on the latest version, because last I was told it is missing some things.. debugger? useful error messages? maybe it's not a big deal anyway <muurkha>I think you need a type checker to compile Ada; for one thing, it has generics <muurkha>for another, it has value types. in fact, it's mostly value types <muurkha>to put an object of a user-defined value type in .bss or a stack frame you need to know what size it is, which depends on its type <muurkha>also, I think the different records have their fields in different namespaces, as in C except before about 01978 <muurkha>in C "x->head" might compile to different offsets from where x points depending on the static type of x <muurkha>but maybe you can do all of that "interpretively"; Ada being stricter than C might mean Ada programs don't care about things like what gets copied when you memcpy a struct <muurkha>then the value-type semantics just comes down to [possibly unnecessarily] cloning objects in the heap to prevent aliasing <Irvise_>Indeed. Luckily for us, the GNAT compiler does not tend to use some of the more advance features, so a reduced Ada subset may actually work. But of course, we are still in the very early stages of work. <Irvise_>I still have not ordered my copies of books to properly learn Scheme. <theruran>Irvise_: lol. see if you can do SICP with Mes :P <Irvise_>That would actually be a nice challenge >:D <Irvise_>theruran: however, before I start with the bootstrap, which, once again, is going to take me a long while to begin with; I want to at least get an Ada compiler into Guix. <Irvise_>There are people waiting for it to get Coreboot/Libreboot graphics support. <Irvise_>And a binary is still allowed for non-bootstrapped languages so... <theruran>Irvise_: sounds good. we both know that getting the supporting tools built together is a major PITA and having a Guix-reproducible build recipe would help a lot <Irvise_>And we do have a plan to get it bootstrapped. I hope the Guix people will allow a temporary fix to get some Ada packages and Ada support into Guix (GHDL also comes to mind). <theruran>I am also annoyed by AdaCore's packaging discipline w.r.t. gnatprove. there are no tags in the spark2014 repo and I *guess* we are meant to just point at fsf branch HEAD (wtf) <Irvise_>I will focus on that from now on. Though, just like always, it is going to be a slow process... Maybe it is not that difficult and we can have an initial binary seed in a couple of moths... <theruran>muurkha: those are some great points. I don't think I'll be able to approach an answer on that without getting knee-deep into it. <muurkha>yeah, I'm pretty ignorant about Ada, so I might have fundamental things wrong <Irvise_>I would use the ones used in Alire... <Irvise_>I know, it is a very poor practice and a bad practice w.r.t AdaCore, but that is what we have... <Irvise_>Also, they are a bit behind GCC releases. So the official support for GCC 13 from GNATProve is not there yet... <Irvise_>(I would use the same tags as in Alire) <theruran>Irvise_: I cannot use the gnatprove from Alire on a musl-libc system. cool huh?! <sam_>I think it changed in gcc 11 or 12 <sam_>i.e. there's no more gnat-gpl releases as of >= 11 <theruran>well at least you can point to the GCC version of the GNAT FSF in Alire. but gnatprove in Alire does not point to any version, tag, or commit hash of the AdaCore/spark2014 repo. so it's not clear what version it is, and if intermediate commits on HEAD are actually stable enough for packaging