| 25 Apr 2025 |
 Teo (he/him) | haskell.nix has pretty bad performance in my experience | 13:57:36 |
 toonn | I use it on a Core2Duo from a decade ago. | 13:58:05 |
| toonn | It's heavier than the Nixpkgs infra though, that's certainly true. But that's because it does so much more. | 13:58:46 |
 thirdofmay18081814goya | hm I see ty for comments | 15:06:24 |
| thirdofmay18081814goya | guess it can't hurt to try both (except for the time expense lol) | 15:06:37 |
 maralorn | The two main advantages I see in haskell.nix are clean derivations for cross-plattform and non-default flags and the possibility to consume a cabal/stack generated build plan. Both of those features I would really want upstreamed into cabal2nix. imo, however if you can get your builds to build without them it is probably not worth the overhead. You are depending on nixpkgs anyway. | 15:16:12 |
| maralorn | My impression is that haskell.nix is a good fit for larger projects/companies where reliably targeting many plattforms is a requirement, it is unrealistic for every team member to be well-versed in the manual dependency resolution dance of nixpkgs, caching is a non-issue because they need their own cache anyway and upstreaming is not a priority. | 15:20:20 |
| maralorn | * My impression is that haskell.nix is a better fit for larger projects/companies where reliably targeting many plattforms is a requirement, it is unrealistic for every team member to be well-versed in the manual dependency resolution dance of nixpkgs, caching is a non-issue because they need their own cache anyway and upstreaming is not a priority. | 15:20:51 |
| maralorn | But I have not actually used haskell.nix a lot. | 15:21:25 |
| toonn | The Nixpkgs infra makes it hard to pick versions of deps. That applies for small projects more than large projects, IMO. | 15:25:28 |
| thirdofmay18081814goya | hm I see | 15:39:30 |
| thirdofmay18081814goya | lots to read and test out heheh, tyvm for comments | 15:39:42 |
|  Find me at aleksana:qaq.li joined the room. | 15:39:50 |
 shapr | We used haskell.nix when I worked at SimSpace. We had one employee who spent all their time on the nix toolchain things. It was worth it! | 15:41:10 |
| shapr | For my own use, stock nixpkgs is fine 99% of the time. | 15:41:25 |
| 26 Apr 2025 |
| Find me at aleksana:qaq.li | I'm trying to build our haskell ecosystem part in Nixpkgs on loongarch64. loongarch64 support of haskell is only available after ghc>=9.12 and llvm>=18. Currently our default is ghc 9.6 and llvm 15. | 03:54:06 |
| Find me at aleksana:qaq.li | There are two issues here, the less significant issue is that I need to change the default ghc version to 9.12, but I don't know how compatible our stackage is with this version. | 03:55:29 |
| Find me at aleksana:qaq.li | The bigger issue is that I can't rely on 9.10 to compile 9.12, like we do now, so I should package a binary distribution of 9.12, but upstream does not publish binary distribution built for loongarch64. | 03:56:56 |
| Find me at aleksana:qaq.li | Oh, there's hadrian bootstrap source, but upstream only publishes 9.8 and 9.10 | 04:01:30 |
| Find me at aleksana:qaq.li | Wait, seems like the support is older than I got, I just have to get a set of patches | 04:10:25 |
| Find me at aleksana:qaq.li | In reply to @aleksana:mozilla.org
Oh, there's hadrian bootstrap source, but upstream only publishes 9.8 and 9.10 It's not ghc with hc files generated 😣 | 04:38:25 |
 Alex | In reply to @aleksana:mozilla.org
The bigger issue is that I can't rely on 9.10 to compile 9.12, like we do now, so I should package a binary distribution of 9.12, but upstream does not publish binary distribution built for loongarch64. You can cross-compile 9.4 using the LLVM backend and use that to natively compile newer versions. | 09:10:30 |
| Find me at aleksana:qaq.li | In reply to @alex:tunstall.xyz
You can cross-compile 9.4 using the LLVM backend and use that to natively compile newer versions. There's no loongarch64 support in ghc94 at all | 09:15:18 |
| Find me at aleksana:qaq.li | I'm trying to cross compile ghc 9.8.4 with no luck | 09:15:37 |
| Alex | It doesn't matter. You can use unregisterised mode. | 09:15:40 |
| Alex | AFAIK cross is completely broken with Hadrian.
If you can get it to work, I'd love to know how. | 09:16:05 |
| Find me at aleksana:qaq.li | In reply to @alex:tunstall.xyz
AFAIK cross is completely broken with Hadrian.
If you can get it to work, I'd love to know how. I don't write haskell at all tbh | 09:16:27 |
| Find me at aleksana:qaq.li | In reply to @alex:tunstall.xyz
It doesn't matter. You can use unregisterised mode. Do we have nix code for unregisterised mode already? | 09:17:14 |
| Alex | Unregisterised GHC relies entirely on the C compiler and needs no knowledge of the target architecture. | 09:17:16 |
| Alex | Yes, you can set it explicitly, but GHC will do so automatically if it doesn't recognise the architecture anyway. | 09:17:49 |
