| 18 Mar 2026 |
 alexfmpe | haskellPackages in particular is 'wrong' in that it generates one derivation per package, not per component | 05:50:54 |
| alexfmpe | So we have to manually break cycles for a bunch of test packages with dontCheck | 05:51:15 |
| alexfmpe | Search for 'cycle' or so in configuration-common.nix for examples | 05:51:40 |
| alexfmpe | `nix-build --show-trace` can help find specific cycles since it shows the call stack | 05:52:47 |
| alexfmpe | In reply to @alex:tunstall.xyz
Right, so haskellPackages.ghc is the same as buildPackages.ghc? I think so, though it seems completely backwards to me | 05:53:21 |
| alexfmpe | I'd expect haskellPackages.foo to always have the same host platform | 05:53:46 |
| alexfmpe | * I'd expect pkgsCross.foo.haskellPackages.bar to always have 'foo' as same host platform for all 'bar' | 05:54:28 |
| alexfmpe | But bar=ghc acts special | 05:54:53 |
| alexfmpe | In reply to @alexfmpe:matrix.org
haskellPackages in particular is 'wrong' in that it generates one derivation per package, not per component Or rather, cabal2nix is wrong, and haskellPackages is based on throwing cabal2nix at hackage | 05:55:40 |
 Alex | I believe this is due to how ghc is threaded through haskellPackages. So that mkDerivation can find it, it is bound to ghc, but this only works well for native.
It also has weird consequences when you try using other compilers, where you can e.g. end up with haskellPackages.ghc being MicroHs. | 06:08:19 |
 woobilicious | Ahh thanks for the feedback, I don't think manual intervention is practical here, the more I think about it, the more it might be easier to just build dirivation per package, with no "real" dependencies, and then de-duplicate strings some way to prevent infinite loops. | 07:45:37 |
|  cookies joined the room. | 11:01:33 |
 linj | Just found a new nix interpreter implemented from scratch in Haskell https://github.com/Novavero-AI/nova-nix. Any comments? | 11:05:00 |
 chreekat | Big if true | 11:20:30 |
| alexfmpe | Author has been announcing it in couple rooms | 11:29:16 |
| alexfmpe | Seems like AI slop | 11:29:25 |
| alexfmpe | > Hand-rolled recursive descent parser for the full Nix expression language. 13 precedence levels, 18 AST constructors, | 11:29:30 |
| alexfmpe | "Now with 30% more precedence levels. Buy 3, take 4" | 11:30:37 |
| alexfmpe | * "Now with 30% more precedence levels. Buy 3, get 4" | 11:31:20 |
 magic_rb | It is AI slop | 11:32:48 |
| magic_rb | Its fully slop-coded, top to bottom | 11:33:02 |
| woobilicious | Nothing screams "Haskell" coding like using a probalitistic LLM... | 11:33:04 |
| magic_rb | Indeed, i have interest in reviewing or using slop-coded code in my free time. The code produced is always subtly wrong and weirdly organized, I've better things to do with my life | 11:34:57 |
| magic_rb | * | 11:35:09 |
 Morj | Nothing screams "Haskell" coding like using a probalitistic LLM...
If it compiles it works, right | 12:00:07 |
| Morj | I remember in chat they were going to use it to distribute their games for windows. If it works for that, that would be cool if horrifying | 12:09:11 |
| Morj | * I remember in chat they were going to use the new nix impl to distribute their games for windows. If it works for that, that would be cool if horrifying | 12:09:20 |
 MangoIV | sternimaralorn I would like to invite you to a discussion on coordination of downstream release testing https://gitlab.haskell.org/ghc/ghc/-/issues/27061
I hear that you already had this discussion last ZuriHac with teo (they/he) since the main effort for downstream testing is currently head.hackage but I think we could all benefit for a more coordinated effort across distributors and the GHC maintainers.
Thanks in advance.
| 12:48:25 |
| magic_rb | Lets give vibe-coded "programs" root access, what can go wrong | 12:52:04 |
 eveeifyeve | Everything can go wrong. | 13:18:29 |
