| 26 Dec 2025 |
 emily | 9.10.3 looks there to me https://github.com/NixOS/nixpkgs/blob/nixos-25.11/pkgs/top-level/haskell-packages.nix | 16:12:02 |
 Magnus | I don't see it at https://search.nixos.org/packages?channel=25.11&query=ghc910 | 16:16:51 |
| emily | it's just being deduplicated with haskell.compiler.ghc910 pretty sure. search is weird. | 16:18:03 |
| emily | the minor version attributes aren't very supported AIUI | 16:18:10 |
| emily | er, the patch version ones that is | 16:18:14 |
| emily | you should say ghc910 rather than ghc9103 | 16:18:22 |
| Magnus | It's just than when doing overrides it's really nice to specify the exact version. Especially when we've in the past have been using several different minor versions in different projects that all share a common overlay. | 16:20:38 |
| Magnus | Very strange... I seem to have gotten a broken hash or something, because a 2nd nix flake update updated the hash again... and now 9.10.3 is there. I guess it was a blip. Very strange. | 16:23:18 |
| Magnus | * Very strange... I seem to have gotten a broken hash or something, because a 2nd nix flake update updated the hash again... and now 9.10.3 is there. I guess it was a blip. 🤷♂️ | 16:24:42 |
 Jack | Hi everyone. Thanks for all the work you do. Is there a nice way to force GHC to use the llvm backend in a similar way to pkgs.pkgsLLVM? I've noticed that if you dig in in the repl at `nixpkgs#haskell.compliler.ghc914.llvmPackages' it has what looks like a set "-fllvm"-satisfying dependencies. | 19:12:09 |
| Jack | In short, I'm trying to override and use "-fllvm" for all my dependencies but I can't find a better way than:
monad-par.extraBuildFlags = ["--ghc-options=-fllvm"];
monad-par.extraPkgconfigDepends = [
pkgs.llvmPackages_20.clang
pkgs.llvmPackages_20.libllvm
]
;
for all of them
| 19:13:35 |
| 27 Dec 2025 |
|  das-g changed their display name from das-g to das-g (DECT 7881). | 13:21:37 |
 sterni | Jack: you can use forceLlvmCodegenBackend from the package set you are working with. It should also be possible to apply this globally by overriding mkDerivation | 17:53:25 |
| Jack | fantastic! | 17:53:44 |
| sterni | https://github.com/NixOS/nixpkgs/blob/3aebc5e7ae7ca5e3aac2fc33b2d7f5d6e601cfa6/pkgs/development/haskell-modules/make-package-set.nix#L732-L752 | 17:54:19 |
| Jack | thank you very much. I'm doing compression and llvm made a huge performance difference, so now I'm very curious of extending it to dependencies will also affect it. | 17:55:00 |
 maralorn | Is it even possible to link object files from different llvm and native backend? | 18:00:01 |
| sterni | yes | 18:00:41 |
|  Nyte changed their display name from realnyte to Nyte. | 21:22:08 |
| 28 Dec 2025 |
|  Lenny. changed their display name from Lenny. to Lenny. ☎️5665. | 14:25:15 |
| 29 Dec 2025 |
 MangoIV | I'm going nutz - I do doJailbreak hsuper.integer-logarithms as usual and it's build-type Simple and it fails with missing or private dependencies ghc-bignum <bla> installed <blup>
Is that something that happens only with ghc-bignum? Or does somebody know what's going on there?
| 10:44:45 |
 Alex | In reply to @mangoiv.:matrix.org
I'm going nutz - I do doJailbreak hsuper.integer-logarithms as usual and it's build-type Simple and it fails with missing or private dependencies ghc-bignum <bla> installed <blup>
Is that something that happens only with ghc-bignum? Or does somebody know what's going on there?
Most likely it's because it's a conditional dependency. IIRC jailbreak does not work with those, so you'll need to patch the Cabal description with more primitive methods or find another way around the issue instead. | 12:51:44 |
| MangoIV | right; i guess calling it again with callCabal2nix would have also worked with the right ghc version - I decided to just patch it upstream ^^ | 12:53:31 |
| 30 Dec 2025 |
| sterni | Wolfgang Walther: so what is actually the state of __structuredAttrs itself? How widely supported is it nowadays and how many issues remain with it? I remember that in the past there were always various problems or bugs with certain Nix versions. | 12:30:18 |
| sterni | I think writing code that simultaneously supports __structuredAttrs true and false is somewhat nonsensical especially when code is written in a way that it has an extra API to work around regular argument splitting limitations. | 12:31:10 |
| sterni | If __structuredAttrs is truly the way to go and there are no potentially showstopping issues, I'd rather redesign the GHC expression and generic builder in a breaking way and always use structured attrs. | 12:32:09 |
| sterni | it'd help mkDerivation, actually, in some ways. | 12:32:21 |
| sterni | I must say that I personally find __structuredAttrs a bit icky since it's not exactly simple nor has clean separation of concerns, but oh well… | 12:33:43 |
 Wolfgang Walther | From the interpreter side, all (known) issues with structuredAttrs should be solved since we bumped min version for Nixpkgs - we are not concerned anymore with any Nix versions that had problems there. structuredAttrs is certainly the way to go in the future, it's just a matter of time (and effort) to get the migration done.
The reason to support both with/without structuredAttrs is purely the transition period while not every expression supports them. This is mostly relevant for generic builders / setup hooks and such, which might not be able to tell in advance whether their downstream consumers will be using structuredAttrs or not.
The GHC expressions can certainly all be rewritten to consistently use structuredAttrs, no problem with that. Forcing the haskell generic builder to always use structuredAttrs would have an impact of out-of-tree users using that builder. If we're OK with a breaking change in that way, then yes, the best way is to consistently use structuredAttrs here, too. | 12:37:55 |
| maralorn | Is there some ressource about what structuredAttrs does and what it solves? | 12:53:28 |
