| 21 Feb 2025 |
 John Ericson | angerman: I hope that the matthew thing will mean that we can serialize and deserialize core too | 02:31:40 |
| John Ericson | option of saving and loading after pipeline stages | 02:31:52 |
| John Ericson | this will be really good for finding bugs in GHC | 02:31:59 |
 alexfmpe | well, I don't really need an answer for applying to nixpkgs today, more like knowing towards what is worth contributing over a long term | 02:42:50 |
| alexfmpe | short term I'll just use haskell.nix or reflex-platform | 02:43:14 |
| alexfmpe | * well, I don't really need an answer for applying to nixpkgs today, more like knowing what is worth contributing towards over the long term | 02:43:35 |
 angerman | Well, having proper serialization for each intermediate step would be beneficial. | 03:04:22 |
 Alex | Several days and >2kLoC of patching later
$ nix-build -A haskell.packages.microhs-0_11_7_1.binary --no-out-link -j1
/nix/store/xrb8cx4mcq209z06p4v4cjb0nfnjhlzx-binary-0.8.9.2
And I'm not even sure that the package actually works properly. 🙃 | 22:49:06 |
 Janus | In reply to @alex:tunstall.xyz
Several days and >2kLoC of patching later
$ nix-build -A haskell.packages.microhs-0_11_7_1.binary --no-out-link -j1
/nix/store/xrb8cx4mcq209z06p4v4cjb0nfnjhlzx-binary-0.8.9.2
And I'm not even sure that the package actually works properly. 🙃 so now you can build arbitrary haskellPackages with microCabal? | 23:50:34 |
| 22 Feb 2025 |
| Alex | Yes, but most don't build because of core dependencies failing (like mtl, which I'm currently trying to fix). | 00:15:20 |
| Alex | I might just try to skip Hadrian altogether and try building ghc-bin with custom build scripts.
Fixing all of Hadrian's dependencies is much tougher than building GHC's dependencies. | 00:17:49 |
 emily | you're saying Nixpkgs gets to maintain yet another GHC build system? :) | 00:26:29 |
| Alex | Unfortunately, that may be the sanest way of booting GHC from source. | 00:30:16 |
| emily | it would be cool if we beat Guix to the punch for a from-source GHC bootstrap (not sure if they've already incorporated MicroHs) | 00:30:46 |
| Alex | Solution: upstream it to GHC :D | 00:30:46 |
| Janus | In reply to @alex:tunstall.xyz
Unfortunately, that may be the sanest way of booting GHC from source. but doesn't GHC have DataKinds and Type families? how could microhs compile that? | 03:38:05 |
| Janus | I mean the source itself uses those extensions | 03:38:42 |
| emily | I assumed it would go via old GHC. | 03:50:31 |
| emily | btw, it's not clear to me how MicroHs really achieves "source bootstrapping" | 03:52:33 |
| emily | it seems like you're still basically running a binary blob of combinators derived from Haskell source? | 03:52:43 |
| Janus | you can compile it with hugs | 03:52:49 |
| emily | it's just that there's a simple C runtime to run that binary blob | 03:52:52 |
| Janus | you don't have to use the shipped c | 03:52:57 |
 Tristan Ross | I've spent a bit of time working on redoing my GHC LLVM bump PR. One thing I have ran into is it looks like the bootstrap GHC for 8.10 would need to be compiled with the LLVM bump flag to not use LLVM versions < 14. The hope is to move everything to at least LLVM 15 since that'll be sitting in nixpkgs for the next few releases and give us time. Hopefully this MicroHs stuff makes the PR more workable. | 03:53:04 |
| emily | ah, right. | 03:53:26 |
| emily | I saw that being said here but forgot :) | 03:53:26 |
| Janus | In reply to @emilazy:matrix.org
I assumed it would go via old GHC. I would think so to, but it Alex didn't mention that , so it sounds like that's not the plan | 03:54:47 |
| emily | it doesn't seem out of the question for augustss to just go and implement every relevant GHC extension :) | 03:58:42 |
| Janus | the fact that e.g. recordDotSyntax is always on and can't be turned off means that lots of code isn't compatible | 04:37:06 |
| Janus | I've just removed NonDecresingSyntax use from happy to make it compatible | 04:37:25 |
