| 21 Feb 2025 |
John Ericson | and then that is kind of a tie breaker event | 01:58:58 |
John Ericson | that makes it better than the external interpreter | 01:59:08 |
angerman | Template Haskell is an absolute train wreck. The qemu approach is the one that is the most conservative. Cross splicing under TH conditions is potentially dangerous across architectures. It also assumes you have a build native equivalent for all host libraries. | 02:03:24 |
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 |