IRC channel logs

2021-09-27.log

back to list of logs

<oriansj>stikonas: merged
<stikonas[m]>Thanks
<janneke>NieDzejkob: if the commit message does not live up to the standard, the review failed or was absent. writing good commit messages is not something most people learn in school and are of little use for the author.
<janneke>it often helps if you have to explain your commit that you realise some thngs can be done better, but the main advantage of a good commit message is to the reader/reviewer
*janneke remembers the cvs->(arch/darcs/xxx)->git transfer all too well, and is interested to see what useful information will remain from changelog-free projects after the next vcs transition
<stikonas[m]>I suspect that when next VCS transition happens, new VCS tools will keep equivalent of git log --stat and similar commands.
<fossy>apart from not seeing git going away any time soon, i think any to be replacement will have some kind of migration from git, probably retaining close to all history
<stikonas>yeah, I wouldn't be surprised if after 20 years everybody is still using git
<Irvise>IMO, fossil is better for projects that need more control and an all-in-one solution.
<Irvise>Also hello! I came here reommended by theruran. I am toying with the idea of an Ada compiler in Scheme. Ada, sadly, has no bootstrapping path :)
<stikonas>I wonder how complicated initial Ada compiler has to be to bootstrap proper Ada compiler
<Hagfish>that's one of the great unsolved mysteries of software engineering which this project will celebrate the answer to, if someone finds it :)
<Irvise>Well... I suppose it will depend on what GNAT (gcc-ada) compiler version we target... It is not using very new constructs, but Ada 1983 was already massive for its time (hence why it really never took off).
<Irvise>There is also HAC, an Ada compiler written in Ada. But its goal is to be smaller and simpler, with the aim of being used for scripts. See: https://github.com/zertovitch/hac
<stikonas>yeah, if HAC can't build GNAT, then it's not too useful
<Irvise>I thought of maybe creating a small initial compiler that can compile HAC and then use it to jump into GNAT... we will see.
<stikonas>well, that's basically how C is bootstrapped here
<Irvise>It is still growing, we will see where it gets.
<Irvise>Yup.
<stikonas>simple C compiler is surprisingly small (about 5000 lines of assembly code)
<stikonas>and then we had to use a few more intermediate compilers to reach GCC
<Irvise>Btw, one question. I know that Guile was being used as the initial seed for the Guix/GNU project. However, I know that smaller seeds are being developed, and that TCC will be used as the "first big" compiler that is built from source.
<Irvise>So, my question is: what Scheme implementation would you recommend us to use? I thought about Chicken Scheme since it can be built with TCC.
<Irvise>stikonas: small C compiler == https://github.com/rui314/chibicc?
<stikonas>probably doesn't matter which want you want to use. Guile is bootsrapped, so whether you use guile or something simpler, it doesn't matter for bootsrappability
<stikonas>we don't need ADA for anything critical
<stikonas>so targeting tcc does not gain you much
<stikonas>Irvise: well, this one is not multiplatform
<stikonas>M2-Planet is full cross-platform compiler
<stikonas>and bootstrappable from hex
<stikonas>Irvise: https://github.com/oriansj/M2-Planet/
<stikonas>M2-planet actually supports fewer features than that chibicc
<stikonas>but enough to build quite a bit of software: basic system tools (cp, chmod, etc), untar, ungz and mes scheme interpreter
<stikonas>Irvise: oh and most importantly, M2-Planet supports inline assembly
<stikonas>you can't do much without inline assembly
<Irvise>I could try to see if it can compile Chicken 5 (probably not, since that is not a simple piece of software).
<stikonas>I would just say pick a language that's more comfortable to yo
<stikonas>to you
<Irvise>I would like to use the most capable Scheme that is closer to the root/seed. And one that has a linking exception similar to GCC's (I think libguile is LGPL...).
<stikonas>I wonder why chibicc does not support inline assembly. It's literally the easiest C feature to implement. You just print the same thing you read
<Irvise>Issue with Ada is that it is part of GCC, it is a language that is used in safety critical systems (and a bootstrapping compiler would be nice to have for reproducibility reasons) and the only open VHDL compiler, GHDL, is written in Ada...
<stikonas>actually, not the whole GCC bootstrap path is rediscributable. Some binaries have conflicting licenses
<stikonas>Irvise: well, Guile can be bootstrapped from seed in maybe 2h from hex0...
<stikonas>tcc is probably 15 minutes
<stikonas>(most of the time is spend in mes scheme interpreter)
<stikonas>scheme is slow...
<Irvise>I am proposing the usage of Scheme since I have heard that is one of the most competent language for compiler creation and that it is being used in the bootstrapping project. AFAIK, you only use assembly, C and Scheme.
<Irvise>Yes... The Scheme interpreter is either simple or fast, not both...
<stikonas>yes, I don't know that much scheme but yes, it's mostly assembly C and scheme...
<stikonas>although, scheme in live-bootstrap is only used to build 1 single binary (tcc), so I guess mostly C
<stikonas>although, if gash is eventually usable with gnu mes, that would help with making whole bootstrap output redistributable
<Irvise>Okay, thank you for the explanation :)
<stikonas>because now live-bootstrap combines GPL and CDDL software
<Irvise>Redistributable because of the license? Binary output?
<stikonas>binary output
<stikonas>in order to build bash, we had to build some simple parser generator (before bison is bootstrapped), so we had to use heirloom yacc (which is CDDL)
<Irvise>That is also one of my fears. I am not against GPL, but I would like to create a compiler that is not copy-left licensed.
<civodul>Irvise: janneke started work on GNU Mes specifically for bootstrapping purposes: to have a small Scheme
<stikonas>and CDDL is incompatible with mes libc license (GPL)
<civodul>that's what Guix uses
<stikonas>but once gash runs on mes, that should help us to avoid linking mes libc and yacc...
<stikonas>well, Guilx uses Guile...
<stikonas>I don't think it can run on mes yet
<stikonas>maybe in the future...
<Irvise>But doen't gash run on Guile? So the path would be ... -> Guile -> Gash -> world?
<stikonas>Irvise: gash runs on guile but not on Mes
<stikonas>guile is build much much later
<Irvise>civodul: I thought that GNU Mes' goal was to be a simple C <-> Scheme compiler. That is all good, but maybe a bit too little for an Ada compiler?
<stikonas>that's why I said use what is more convenient for you
<stikonas>Guile might be better
<stikonas>you'll have more features
<Irvise>That is the proposal of theruran :) I thought about Chicken since it is also very capable, can be compiled with TCC and is BSD licensed :)
<Irvise>But then again... Chicken needs GNUMake, so we are back at square one...
<stikonas>Irvise: GNU make is easy to build
<stikonas>at least old make
<stikonas>here https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst make is step number 10
<civodul>Irvise: Mes includes MesCC, a simple C compiler written in Scheme
<Irvise>Old make? BSDMake?
<stikonas>Irvise: GNU make
<stikonas>3.80
<stikonas>that's from 2002
<Irvise>Thank you for that link, it lays down pretty much what I want to know :)
<stikonas>(this is full-no pregen files bootstrap)
<stikonas>there is a simpler one if you look at Guix graph which uses some pregen files
<Irvise>Mmmm... I could try building Chicken with GNU Make 3.80 and TCC... (or Mes).
<stikonas> https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
<Irvise>stikonas: the bootstrap path I was aware was the Guix one. That is why I thought that Guile was being used as a binary seed. I could not patch together the differences between M2, Mess and the Guix path... So you are both doing the same way, but Guix jumps ahead with a binary seed?
<stikonas>yes
<stikonas>live-bootstrap starts from hex0 and uses kaem-optional-seed (while thing is about 1 KB) to script to bootstrap
<stikonas>Guile master starts with GNU mes as compiler seed and uses Guile to drive the whole process (also uses Guile for some stuff as gash before bash is available)
<Irvise>Okay, I have it a bit more clear. I need to become more familiar with the live-bootstrap documentation.
<stikonas>there is Guix branch that starts with hex0 but of course still uses Guile to drive the whole process
<stikonas>Irvise: that parts.rst file describes most of the things
<Irvise>Thank you for all the explanation stikonas and civodul I will keep on reading :)
<civodul>yw :-)
<stikonas>oriansj: so I've just started debugging M0
<stikonas>and it happens when brk syscall does not allocate anything
<stikonas>I don't know why that happens...
<stikonas>but I can see (in gdb) brk (new_value) returning old_value
<stikonas>and then list becomes messed up (NEXT points to brk boundary and hence is illegal read)
<stikonas>it might be qemu bug
<stikonas>or rather qemu-riscv bug
<stikonas>so qemu translates brk calls to mmap
<stikonas> https://paste.debian.net/1213454/
<stikonas>so I guess if qemu can't allocate memory in the desired place it just tells brk that failed go get memory...
<stikonas>hmm
<stikonas>maybe this is triggered on riscv64 because binaries are quite a bit bigger
<stikonas>so hitting 2 MB page limit
<stikonas>ok, it's not 2 MB page limit but qemu limitation
<stikonas>I've talked to qemu folks
<stikonas>they only guarantee 16 MB of memory for brk arena in qemu and expect a "real" malloc to use mmap
<stikonas>so wouldn't crash on real HW...
<stikonas>but for development purposes it's a bit annoying
<stikonas> https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L2314
<Hagfish>wow, that's so good to get it confirmed by the qemu devs themselves (and somewhat reassuring that real HW would be fine)
<Hagfish>the idea comes to mind that the simplest solution would be to use a custom version of qemu, but i don't know whether that is a good idea or not
<stikonas>well, it's my guess that real HW would be fine
<stikonas>well, I can test it by using qemu-system rather than qemu-user...
<stikonas>(i.e. run full distro inside qemu)
<stikonas>it might be possible to split M1 files into smaller units...
<stikonas>hmm, that is also somewhat tricky because cc_riscv64 does not always put the whole instructions into a single line
<Irvise>I have read the parts.rst document. Holly molly.
<Hagfish>Irvise: it's a masterpiece, isn't it?
<Irvise>I am very impressed.
<Irvise>Very much indeed. I can just imagine the testing, trial and error, reproducibility nightmares...
<Hagfish>obviously it's the result of a lot of great work, and probably lots of experimentation that isn't recorded there
<Hagfish>exactly
<Irvise>Though I am very much intreaged whether Chicken scheme could be built after step 10, 12, or 13... Maybe 22...
<Hagfish>it's like the first time someone created a map of the world. it gives a whole new way to see and thinking about the software ecosystem
<Irvise>Is there a way in which I can run the script up to step 13 and try to build a program?
<Hagfish>huh, i don't know, but that sounds like a reasonable feature
<Hagfish>i mean, you could just hack the script, right?
<Irvise>Hagfish: I am taking a look into sysa/run.sh... It seems pretty clean... I could hack it..
<Irvise>I suppose that https://github.com/fosslinux/live-bootstrap/blob/7b8219214c65a60e55acab1b8ea53f7ab5170be9/sysa/run.sh#L59 is step 22. So adding my own stuff just right after may work.
<xentrac>Chicken is somewhat demanding of the C runtime; you need a working longjmp
<xentrac>otherwise, though, it's a much more portable way to write a fastish Scheme than the alternatives
<xentrac>however, I suspect Chicken's macro system is not compiled from source
<xentrac>getting Guile to bootstrap was a real bear
<xentrac>ugh, I didn't realize heirloom-yacc was CDDL. thanks for mentioning that, stikonas
<stikonas>well, if we can somehow run bash scripts before (e.g. gash) that wouldn't be the problem at all
<xentrac>yeah
<stikonas>i.e. then build gash->musl->yacc->bash rather than yacc->bash->musl
<stikonas>Irvise: you can edit kaem script files to interupt the build
<Irvise>xentrac: you are correct. Chicken, as it ships from the tarballs comes with some pregenerated code. If you clone from git, it is required that you already have chicken installed to generate the files...
<xentrac>right, Guile has a similar cycle
<xentrac>which took a lot of work to break
<Irvise>stikonas: I am taking a look into it right now :) I think I have found steps 11, 12...
<stikonas>oh, if chicken ships with pregenerated files
<stikonas>then you don't get much advantage over guile
<Irvise>xentrac: thanks for mentioning that dependency... I now realise that is will not be as easy peasy as I thought...
<stikonas>well, guile also ships with pregen files
<stikonas>hence we build it quite late
<stikonas>oh yes, guile xentrac just mentioned it
<stikonas>Irvise: and we couldn't even do everything
<stikonas>gcc ships with autogen pregenerated files
<Irvise>Aw... If Chicken could bootstrap that soon, it would be really cool.
<xentrac>heavy reliance on macros is kind of a disadvantage of Scheme
<stikonas>we didn't manage to solve that yet
<stikonas>but kinf of workaround it
<xentrac>there are some other disadvantages for compilers: no pattern-matching and no static type checking
<xentrac>(of Scheme)
<stikonas>for gcc and binutils we had to avoid using top-level configure/Makefile.in file because of that autogen dependency and manually ran many configure scripts in subdirectories
<Irvise>Yup. A bit of research is going on right now on typed scheme...
<Irvise>I have read those adventures...
<Irvise>I will ask #chicken about their pregenerated files... Lets see what they are exactly.
<xentrac>I actually kind of prefer OCaml over Scheme for writing interpretery things
<xentrac>but of course it also lacks a bootstrapping path
<stikonas>maybe chicken scheme can be bootstrapped with guile...
<Irvise>stikonas: most likely it can. I am asking #chicken to see how are those pregenerated files generated and if there is an alternative path.
<xentrac>yes, almost surely
<xentrac>a language like Smalltalk which did its conditionals and looping constructs with lightweight lambda syntax instead of Scheme's macro approach would be more amenable to bootstrapping
<xentrac>I mean the Scheme standard doesn't *require* you to implement loops, conditionals, and even sequencing in terms of macros. it just carefully lays out the considerations you would need to take into account in order to do so and provides macro implementations of those constructs in case you want to use tem
<xentrac>*them
<xentrac>it's sort of unfortunate that we've chosen the term "bootstrapping" for what is conventionally called "not bootstrapping"
<qyliss>xentrac: I don't know anything about OCaml, but I recently saw a PR claiming to bootstrap it in Nixpkgs from https://github.com/Ekdohibs/camlboot
<xentrac>oh, that's wonderful!
<xentrac>MIT license
<qyliss> https://github.com/NixOS/nixpkgs/pull/138519
<Irvise>I am going to sleep now. I spoke with the Chicken people. The generated files are anything but trivial, they would have to be autogenerated in one way or another...
<oriansj>Irvise: I remember previously discussing Ada being bootstrappable and we do have notes on it in our wiki: https://bootstrapping.miraheze.org/wiki/Boostrapping_Specific_Languages#Ada_and_SPARK
<fossy>Irvise: if you want to build chicken scheme as early as possible, it is just a matter of writing a kaem or bash script and inserting it into the middle of the appropriate live-bootstrap script (if you wish to use live-bootstrap)
<oriansj>So there is likely already a path without having to program in anything other than guix scripts
<fossy>i'm a little confused, though, why are you wanting chicken scheme?
<stikonas>fossy: was just looking at parts.rst, there is a reference error
<fossy>oh, where
<stikonas>see part 21
<fossy>oh yes
<stikonas>I guess just reword
<stikonas>with tcc-musl from the previous step
<stikonas>or something like that
<fossy>yeps
<stikonas>oriansj: any thoughts on what to do with M0 issue?
<stikonas>I think we understand the crash much better now
<fossy>also, it appears guile is not fully reproducible, one in about 5-6 times i get a different result, so i am investigating that now
<stikonas>oh, I see
<stikonas>I did build it a few times
<stikonas>but maybe not enough to observe this
<stikonas>or maybe my environment is less prone to that issue
<xentrac>fossy: Chicken is a lot more efficient than Guile and has an easier time calling C extensions
<stikonas>well, for now live-bootstrap has built guile for guix purposes
<xentrac>I don't think it has anything in the language semantics that makes it a better fit for writing compilers, which is what Irvise wants to do
<stikonas>live-bootstrap itself doesn't use guile at all
<oriansj>but guix does
<xentrac>I think Scheme is a better language than C or probably Python for writing compilers in, but not as good as, in one direction, JS, and in another direction, anything in the ML family
<xentrac>but it might be mostly a matter of taste. the other day I went back and looked at some things I'd written earlier to rebut "No Silver Bullet"
<xentrac>because I was sure that Python was an improvement of more than an order of magnitude over that fusty old Ada that Brooks was touting in 01987
<stikonas>and probably experience using some language means more than advantage gained by certain constructs of the language
<xentrac>but when I looked at how long it actually took me to write some things in Python, I realized that it wouldn't have taken me an order of magnitude longer to write them even in C, and I'd expect Ada to be a little better than C (if I knew Ada well)
<xentrac> https://news.ycombinator.com/item?id=28660097 was my account
<xentrac>so writing things in Python might be 2 or 5 times faster than writing them in C but not 10 times faster
<xentrac>I do think writing things in C is about 10 times faster than writing them in assembly