Haskell in Nixpkgs/NixOS | 702 Members | |
| For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | 140 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Sep 2025 | ||
| Definitely trying to keep the chain as short as possible, but there is always unregisterised GHC if absolutely necessary. | 21:32:34 | |
| yeah | 21:32:58 | |
| have you talked with Lennart about this? | 21:33:14 | |
| it would certainly be cool to see | 21:33:19 | |
| did you have to patch it for Hugs support? | 21:33:28 | |
| if you could get bootstrap via Hugs upstreamed to MicroHs and ensure that Hugs builds okay with modern C compilers, then I wonder what it would take to Hugs -> MicroHs + MicroCabal added as an option for the Nixpkgs Haskell package set. (where presumably very little would work, but it would at least be tantalizing incentive to working on closing the gap between that and GHC) | 21:36:12 | |
| What are my old and tired eyes seeing?
Look at the | 21:36:26 | |
| This is amazing. | 21:37:05 | |
In reply to @emilazy:matrix.orgNope, this is already something Lennart has sorted out. Though I did, amusingly, have to patch Hugs because it was broken in the Nixpkgs commit I started from (someone else wrote that patch, so no effort on my part). | 21:38:44 | |
In reply to @emilazy:matrix.orgI don't think so, but I will try and upstream whatever improvements/fixes I make along the way. (And I expect there to be a lot.) | 21:39:19 | |
| well AIUI the upstream build system either compiles the C blob or uses GHC right? | 21:43:23 | |
| so adding a path to bootstrap via Hugs would be a good step | 21:43:36 | |
| and yeah, having to keep Hugs working is part of the burden here... | 21:44:03 | |
| as C codebases unmaintained for 20 years are no fun to keep going | 21:44:20 | |
In reply to @emilazy:matrix.orgNot necessarily: https://github.com/augustss/MicroHs?tab=readme-ov-file#bootstrapping-with-hugs (I also delete the C blobs to be extra sure I don't accidentally use them.) | 21:45:29 | |
| ah. but that's a separate branch of MicroHs? | 21:46:21 | |
| seems like it'd be ideal for it to be merged with the main one but I guess worst case it's just another hop | 21:46:43 | |
| Yes, it's another hop, but the MicroHs build is under 5min anyway, so I'm not concerned. It's a good idea to build a stage 2 mhs anyway. | 21:53:37 | |
| I do worry a bit about the part where he says the resulting binaries are 10x slower than GHC. | 21:55:36 | |
| it's not exactly fast to bootstrap GHC to begin with | 21:55:49 | |
| but I guess targeted optimization work could be applied | 21:56:08 | |
| 8 Sep 2025 | ||
| 21:04:44 | ||
| I want to install IHaskell with access to the System.Random package, as Jupyter kernel (on NixOS unstable). I have tried the following, without success:
Can anyone help me with this? | 21:16:33 | |
| * I want to install IHaskell with access to the System.Random package, as a Jupyter kernel (on NixOS unstable). I have tried the following, without success:
Can anyone help me with this? | 21:16:47 | |
| 9 Sep 2025 | ||
| Isn't random a core package? | 06:46:21 | |
| 11:06:06 | ||
| 11:06:49 | ||
Is ${pkgs.cabal-install}/bin/cabal wrapped to use the specific ghc binary? I just read the script and I don't think so. However, I have considered it working as expected, using package db configured in pkgs.haskellPackages.ghc, each time I run cabal build things in the shell. | 14:52:33 | |
hmm... does it just use ghc in PATH? And it has been ok since I always put pkgs.ghc together with pkgs.cabal-install in the shell? | 14:55:19 | |
| It uses the PATH, pretty sure. | 15:35:10 | |