| 7 Sep 2025 |
 emily | e.g. it messes up easy bootstrap of new architectures | 21:31:46 |
| emily | since now you have to backport codegen to every version | 21:31:59 |
 Alex | Definitely trying to keep the chain as short as possible, but there is always unregisterised GHC if absolutely necessary. | 21:32:34 |
| emily | yeah | 21:32:58 |
| emily | have you talked with Lennart about this? | 21:33:14 |
| emily | it would certainly be cool to see | 21:33:19 |
| emily | did you have to patch it for Hugs support? | 21:33:28 |
| emily | 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 |
 maralorn | What are my old and tired eyes seeing?
┃ > Encountered missing or private dependencies:
┃ > cabal-add >=0.1 && <0.2 (installed: 0.2)
Look at the installed. I have been wishing for that feature for years and have been procrastinating to implement it basically the same time.
| 21:36:26 |
| maralorn | This is amazing. | 21:37:05 |
| Alex | In reply to @emilazy:matrix.org
did you have to patch it for Hugs support? Nope, 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 |
| Alex | In reply to @emilazy:matrix.org
have you talked with Lennart about this? I 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 |
| emily | well AIUI the upstream build system either compiles the C blob or uses GHC right? | 21:43:23 |
| emily | so adding a path to bootstrap via Hugs would be a good step | 21:43:36 |
| emily | and yeah, having to keep Hugs working is part of the burden here... | 21:44:03 |
| emily | as C codebases unmaintained for 20 years are no fun to keep going | 21:44:20 |
| Alex | In reply to @emilazy:matrix.org
well AIUI the upstream build system either compiles the C blob or uses GHC right? Not 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 |
| emily | ah. but that's a separate branch of MicroHs? | 21:46:21 |
| emily | 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 |
| Alex | 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 |
| emily | I do worry a bit about the part where he says the resulting binaries are 10x slower than GHC. | 21:55:36 |
| emily | it's not exactly fast to bootstrap GHC to begin with | 21:55:49 |
| emily | but I guess targeted optimization work could be applied | 21:56:08 |
| 8 Sep 2025 |
|  romildo joined the room. | 21:04:44 |
| romildo | 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:
$ nix-shell -p python313Packages.jupyter-client '(ihaskell.override { packages = (ps: with ps; [ random ]); })'
$ ihaskell install
$ jupyter kernelspec list
Available kernels:
python3 /nix/store/452p7spwcycp694vd791hw2c2a2kl5c5-ihaskell-with-packages/lib/python3.13/site-packages/ipykernel/resources
haskell /home/romildo/.local/share/jupyter/kernels/haskell
$ jupyter console --kernel haskell
Jupyter console 6.6.3
IHaskell 0.11.0.0 GHC 9.8.4
In [1]: import System.Random
...:
<interactive>:1:1: error: [GHC-87110]
Could not find module ‘System.Random’.
Use -v to see a list of the files searched for.
In [2]:
Can anyone help me with this?
| 21:16:33 |
| romildo | * 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:
$ nix-shell -p python313Packages.jupyter-client '(ihaskell.override { packages = (ps: with ps; [ random ]); })'
$ ihaskell install
$ jupyter kernelspec list
Available kernels:
python3 /nix/store/452p7spwcycp694vd791hw2c2a2kl5c5-ihaskell-with-packages/lib/python3.13/site-packages/ipykernel/resources
haskell /home/romildo/.local/share/jupyter/kernels/haskell
$ jupyter console --kernel haskell
Jupyter console 6.6.3
IHaskell 0.11.0.0 GHC 9.8.4
In [1]: import System.Random
...:
<interactive>:1:1: error: [GHC-87110]
Could not find module ‘System.Random’.
Use -v to see a list of the files searched for.
In [2]:
Can anyone help me with this?
| 21:16:47 |
| 9 Sep 2025 |
| maralorn | Isn't random a core package? | 06:46:21 |
|  @julm:matrix.org joined the room. | 11:06:06 |
| @julm:matrix.org left the room. | 11:06:49 |
 bglgwyng | 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 |
