IRC channel logs

2022-02-04.log

back to list of logs

<rekado_>janus: thanks for the confirmation
<rekado_>sadly, there’s more wrong
<rekado_>I’ve been patching file after file, but hugs also doesn’t like tuple definitions
<rekado_>I’m starting with “:load PrelAddr” and fix whatever is reported as broken
<rekado_>now on the seventh file… but it is all about tuples
<janus>what are you changing them into then?
<rekado_>the tuple stuff? No idea.
<rekado_>it’s definitions like this: data (,,,,) a b c d e = (,,,,) a b c d e deriving (Eq, Ord)
<rekado_>hugs says “(unexpected comma)”
<rekado_>I feel like this is a dead end
<rekado_>I need way too much of the standard lib to run the compiler, and hugs can’t read most of it
<rekado_>the only reason why I went with GHC 4.08.2 is that it’s the last GHC with a modified hugs that I can build without having built the compiler first
<rekado_>the next release is GHC 5, which comes with ghci.
<rekado_>I’ll look at the GHC 5 code next to see if there’s any way to split up the build
<rekado_>I don’t see how I can get STGhugs from GHC 4 to interpret the GHC 4 standard library or the compiler tools.
<rekado_>though … maybe it could interpret GHC 3
<rekado_>nope, GHC 3.02 also has the same PrelTup.hs which would lead to “unexpected comma”, and it uses # just as often as GHC 4.
<janus>but at least tuples should be transformable into a different syntax. it's a simple but tedious process
<janus>if it is parsable using ghc-exactprint it might even be automatable...
<stikonas>oh, my build of hugs is probably broken for similar reason that rekado_ inially had. I also have no support for shared libraries...
<stikonas>maybe I'll give up for now... since rekado_ seems to be quite a bit ahead
<janus>did you guys already try with NHC as mentioned in that blog post? because that is probably how it was historically bootstrapped
<stikonas>no, I haven't tried...
***ChanServ sets mode: +o rekado
<rekado>janus: I was going to go back to nhc98, but it doesn’t officially support more than Haskell 98 and GHC has always been non-standard.
<rekado>in my blog post I didn’t get far because I used a more recent toolchain
<rekado>early publications mention HBC, but there are no official releases available any more (I found a copy of a random CVS version on Github) and it has no license.
<stikonas[m]>HBC also needs LML compiler, so that's not worth pursuing even if license was GPL2 (which it ought to be because it uses GMP but without it being explicit we can't really tell)
<rekado>nhc98 might be nice to have, but I don’t see a path from there to GHC. It might be able to compile a few files on the way there, but the GHC standard library and compiler makes heavy use of non-standard Haskell code.
<rekado>GHC 0.29 comes with generated hc files meant for bootstrapping.
<rekado>there’s a chance that GHC 0.29 can be built with NHC, but GHC 0.29 is a dead end. There are no public source archives for GHC 2, and you need at least GHC 2 to build GHC 3.
<janus>ooh that is very useful information. i had not considered that an intermediate ghc release would be lost
<janus>rekado: did you already try asking GHC oldtimers like SPJ if they have a copy of GHC 2?
<rekado>I haven’t asked, but I’d prefer to not need GHC 2
<rekado>GHC 3 sources mention nhc once, so there’s hope that it can be built with NHC
<janus>i created an issue just for posterity: https://gitlab.haskell.org/ghc/homepage/-/issues/8
<rekado>I’m still holding out hope that I can make STGhugs from GHC4 understand GHC4 sources.
<muurkha>it's strange that it doesn't
<rekado>it’s not obvious how to accomplish this; GlaExts is the module that provides support for GHC extensions.
<rekado>but I guess I don’t want to use it because it depends on the standard lib and thus would require heavy patching before I could load it.
<rekado>STGhugs is linked with GHC4 internals, so it should be able to work with at least part of the GHC4 sources
<rekado>maybe I missed something in the build
<rekado>I probably won’t be able to hack on this in the next few days, so my next step is to clean up my patches a little and publish this somewhere
<rekado>a usable STGhugs from GHC4 might be useful to others
<rekado>STGhugs has a mode called “combined” mode. Naturally, it fails to star, but I think that’s what we want.
<rekado>it loads a different prelude and all that; it’s nowhere defined what exactly it means, but it is referred to as “the combined Hugs-GHC system” elsewhere
<rekado>unfortunately, this seems to require *compiled* Haskell code. Strace shows it’s looking for all of Prelude.{u_o,u_hi,hs,lhs}, but it only finds the last one and then barfs “Can't find object for module "Prelude"”.
<stikonas>well, pushing something out will let others to review/try some ideas...
<Hagfish>nice to see some recent friendly collaboration on fixing this 5 year old reproducibility issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864082
<bauen1>Hagfish: amazing that that is still not fixed, i remember running across it when trying to make my debian-cd builds fully reproducible
<Hagfish>i hope it's the last issue standing in the way of that, and similar things
<Hagfish>and i hope that the new patch makes its way into the next stable release