Sender | Message | Time |
---|---|---|
7 Sep 2025 | ||
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 | |
not currently; judging by the master table, https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history, it was on and off untill GHC 8.4.4 when it was dropped and never picked up since. This sounds funny of course. | 16:37:18 | |
* not currently; judging by the master table, https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history, it was on and off untill GHC 8.4.3 when it was dropped and never picked up since. This sounds funny of course. | 16:38:10 | |
Artem: Seems a bit … random. 🤪 | 18:04:21 | |
22:16:18 | ||
22:17:57 | ||
10 Sep 2025 | ||
Heya Will yall repost the maintainer summary thingy on the Haskell-updates PR? I think that would be nice, to have an update every now and then without having to sift through the jobset | 12:50:58 | |
We sometimes do. But are you aware of https://github.com/cdepillabout/nix-haskell-updates-status ? | 13:15:41 | |
No that’s perfect. Thanks. | 13:16:13 | |
maybe this link is worth adding to the (ever growing) list of links in the Matrix room description?.. | 13:26:33 | |
Why does haskell98 show up under "Top 50 broken packages, sorted by number of reverse dependencies", but can't be found in any of the sections above it? | 13:41:55 | |
i was asking the same question myself. Worth noting that many of those "top 50" are completely dead packages. So this list isn't very useful I think. It'd be great to implement the "dead" category besides the "broken" category, as discussed on the meeting (https://github.com/NixOS/nixpkgs/pull/429810#issuecomment-3224849043 called "removed" there) | 13:46:02 | |
there's an open PR for that | 13:54:47 |