IRC channel logs
2023-04-21.log
back to list of logs
<roconnor>is mes-0.24.2/lib/linux/x86-mes-gcc/crtn.c supposed to be emtpy(ish)? <stikonas[m]>I think because GCC / C library would provide their own C runtime <roconnor>tcc want's to load them ... I'm having some trouble with that right now, but I'm sure I've done something stupid <stikonas[m]>Those should be just plain command in early bootstrap <roconnor>yeah. But I'm trasncribing them into Nix expressions as I go, and fiddling with the directory structures as I go. <roconnor>I'm not sure what is going on here. It builds libtcc1.o from mes, then immedately clobbers the result by building libtcc1.o from tcc. <muurkha>roconnor: tell me about bootstrap paths for Haskell <muurkha>it would be fantastic if Nix could be reproducibly built from a tiny binary seed <roconnor>tiny seed, plus a posix kernel, plus the nix-daemon. <muurkha>I don't think I realized he had written this <muurkha>Fiwix seems to be making progress on the "plus a posix kernel" problem <muurkha>how hard would it be to write a Haskell interpreter that could run GHC if it didn't have to be efficient or collect garbage? <roconnor>I don't know. Maybe you take Hugs and try to extend it. <muurkha>I mean you can easily get a box with 64 gigs of RAM now, and compiling GHC with GHC might generate less garbage than that <muurkha>is there a tiny kernel of Haskell that you can translate the rest of Haskell into, maybe with code written in the kernel language? <muurkha>I have this vague memory of such a thing existing <roconnor>yes. F_omega is what Haskell is compiled to. <roconnor>it's a standard type theory with first class polymorphism. <muurkha>a type theory? is that all you need to specify what the code does? <muurkha>IIRC you were the person who first introduced me to the Curry-Howard isomorphism <roconnor>these type systems don't make sound logics because they support non-termination. <rekado>AwesomeAdam54321: none of the GHC versions run on Hugs <rekado>and I did modify the GHC modules (because Hugs doesn’t support mutually recursive modules) <AwesomeAdam54321>rekado: oh ok, from your blog post I thought you used nhc98 to compile GHC <rekado>I tried running nhc98 on Hugs because GHC on Hugs required even more changes and wouldn’t work <rekado>in Guix I’ve ended up adding GHC 4.08 with some generated C files <rekado>I don’t recall the differences, but early GHCs claimed to be buildable with nhc <rekado>now I don’t think that was ever more than aspirational <AwesomeAdam54321>I feel like bootstrapping GHC is so close, the only thing needed is to use gcc-toolchain@2 instead of gcc-toolchain@4 to compile nhc <rekado>we have nhc98 1.22 in Guix (not bootstrapped from Haskell) and it could not build any of the GHCs I tried. <rekado>so I don’t think nhc is the way forward. <rekado>early GHCs also mentioned HBC, but that’s another compiler written in Haskell and it’s not under a free license last time I checked. <AwesomeAdam54321>Either way, a Haskell compiler needs to bend towards GHC's dialect of Haskell, or heavily modify GHC to use standard Haskell instead <rekado>the biggest problem I found is that GHC depends heavily on internal types that are defined in the RTS. You can’t use Hugs or any other compiler to provide these implementations. <rekado>and to build the RTS you need GHC <AwesomeAdam54321>I haven't made much progress yet though, I want to see if the oldest version can be converted to Guile Scheme <roconnor>Should I make PR? I don't really know what I'm doing. <river>roconnor: if you have the energy to do that i think people would be very grateful <stikonas[m]>roconnor: if you can, make PR. There is more than one instance of this clobbering though <roconnor>The line where I run live-bootstrap before opening a PR. :) <roconnor>I might be able to give it a try. The chroot build command doesn't seem so bad. <roconnor>getopt build steps ought to be copied or moved to tcc-0.9.27; currently it isn't recompiled with 0.9.27. <janus>rekado: HBC is not written in Haskell, it is written in Lazy ML. Which I don't know of a compiler for. <janus>So far, it doesn't seem super hard to port GHC 0.29 to NHC, it's just tedious because modules are mutually recursive in their imports. But often times, the actual name module A needs from B could be gotten more directly from module C. So it might not be as mutually recursive as it seems <janus>The build system is building files in an arbitrary manner because they ship hi files for everything, so they never had this problem of having to regenerate hi files <roconnor>so you would modify GHC 0.29 to remove the recursive imports? <janus>Some of that, which is nice, because then you can have NHC generate a new fresh .hi file. But if I know where the name is supposed to come from, I am often tempted to just write the hi file by hand. <stikonas[m]>roconnor: we could rebuild them, though perhaps if getopt built with old tcc worked, we thought it's not worth rebuilding it... <roconnor>I should check to see if the results are identical ... <janus>rekado: but I haven't looked at the RTS of GHC 0.29. Have you looked at it, or were your comments specific to GHC 4? <roconnor>that's why I think moving the steps to 0.9.27 rather than copying it might make more sense. <avih>aggi: did bellard reply? <roconnor>the way it currently works is that getopt is built with mes-tcc, then it is ignored for a while, and then rebuilt with tcc-0.9.26, and that is it (at least as far as I've gone so far). <aggi>avih: i havent received an email nor any other feedback <aggi>no problem, currently i am too tired anyway <aggi>and he mentioned on his website, he stopped working on tcc almost 20 years ago already <aggi>meanwhile i made some progress with tccboot <aggi>and i had to do spring-cleaning, before i can focus on some heavy-task several weeks non-stop, without drowning in dirt and chaos <aggi>i'll notify in this channel, as soon as the issues with tccboot and linux-2.4/tcc are resolved <avih>aggi: hmm.. i was sure he'd reply.. a bit weird TBH... but glad you made progress