| 21 Feb 2025 |
 angerman | Cross splicing will work most of the time though. | 02:03:48 |
| angerman | It is bound to fail if you build system is 64 bit and target is 32bit and you end up embedding Word sizes and similar. For the JS backend though, I don’t think we use qemu at all. It’s basically still the th runner approach with node. | 02:05:33 |
| angerman | I will note that for android, we have a fairly big PR, that tries to fix a lot of issues. | 02:08:16 |
| angerman | https://github.com/input-output-hk/haskell.nix/pull/1874 | 02:09:00 |
| angerman | One neat thing with the iserv appraoch is that it lays the groundwork of remote debugging. So having that work is important (to me). | 02:09:36 |
| angerman | alexfmpe: good job on the windows cross stuff! Just don't expect to get 8.10 to work if you ever try. And haskell.nix has patches to keep MSVCRT alive (for now). | 02:11:36 |
 alexfmpe | oh yeah windows was more of a "wonder what state that thing is in" adventure | 02:17:34 |
| alexfmpe | yeah this creeps me out a bit in the abscence of pure template haskell | 02:20:25 |
| alexfmpe | * yeah this creeps me out a bit in the absence of pure template haskell | 02:20:31 |
| angerman | TH has unrestricted IO. It should be burned in fire. But it is what it is... ab absolute abomination and very few who understand how bad it is. | 02:21:13 |
 John Ericson | I agree in theory but we haven't gotten bit yet IIRC | 02:30:30 |
| 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 |
