| 18 Mar 2026 |
 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 |
| magic_rb | mhm and yet a bsc student shouldnt be given push access to the mainline linux tree | 13:28:51 |
 sterni (he/him) | In reply to @woobilicious:matrix.org
I have a questions about the general architecture of haskellPackages, does hackage have dep cycles? and how do you deal with them when generating the package list? I'm working on a little project that generates a package list from a foreign source, but it has cycles, and I'm kinda clueless on how to break cycles up without just removing all dependencies It has cycles but only via test dependencies. We work around this by strategically disabling tests to break such cycles | 15:52:02 |
|  NudelErde 🏳️⚧️ [she/her] joined the room. | 19:39:06 |
| 19 Mar 2026 |
 alexfmpe | somehow cabal test regression-tests in my x86_64-linux is twice as fast than in my aarch64-darwin even though the later is noticeable faster for everything else | 01:28:25 |
| alexfmpe | * somehow cabal test regression-tests in my x86_64-linux is almost twice as fast than in my aarch64-darwin even though the later is noticeable faster for everything else | 01:28:41 |
| alexfmpe | * somehow cabal2nix's suite cabal test regression-tests in my x86_64-linux is almost twice as fast than in my aarch64-darwin even though the later is noticeable faster for everything else | 01:29:49 |
| sterni (he/him) | it does a lot of I/O and exec (I think?) so maybe that's just better on linux | 11:41:01 |
 Alex | Maybe cross-compiling GHC with Hadrian is possible, but there's no up-to-date documentation for how to do it?
https://www.reddit.com/r/haskell/comments/1irfu72/comment/mdlb6td/ | 18:53:53 |
| Alex | I was looking at the build graph for RISC-V GHC and wondering why clang is a dependency (rather than just llvm).
LLVMAS should be a "specific LLVM compatible assembler" which needs to understand assembly produced by LLVM. The easiest way to be sure is to use clang from the same version as llc and opt. Note that the naming chosen by GHC is misleading, clang can be used as an assembler, llvm-as converts IR into machine code.
This comment in the Nixpkgs source code doesn't clearly explain why LLVMAS is set to clang and not llvm-as.
The upstream documentation is no better.
Specifically GHC needs to be able to call the opt and llc tools.
Does anyone here know why the build uses clang? | 19:21:44 |
| Alex | I'm seeing a lot of "unknown operand" errors coming from clang during a stage 1 build.
I'll try llvm-as instead. | 20:17:24 |
| sterni (he/him) | LLVMAS should be clang as was my understanding | 20:25:47 |
| sterni (he/him) | configure.ac literally checks for clang | 20:26:08 |
| sterni (he/him) | GHC cross may work again it was horribly broken last I checked | 20:26:38 |
| sterni (he/him) | there are aspects of it that are still broken and I couldn't get my first patch for that merged iirc | 20:27:56 |
| sterni (he/him) | Alex: https://gitlab.haskell.org/ghc/ghc/-/blob/f8817879f94e4ea3e603808fd6370b8365818911/configure.ac#L556 | 20:28:00 |
| Alex | Well, I just got to stage2 in the build with llvm-as and, sure enough, it doesn't work:
llvm-as: Unknown command line argument '-iquotelibraries/ghc-prim/GHC'. Try: '/nix/store/8cn6305g0gsrczz3ga298k0zilfzgs7r-llvm-20.1.8/bin/llvm-as --help'
llvm-as: Did you mean '--help-list-hidden'?
[...]
| 20:28:45 |
| sterni (he/him) | ah it was lol https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13932 | 20:29:01 |
| Alex | Anyway, back on clang, I'm getting many errors in the assembly that GHC generates, e.g.
/build/ghc44067_0/ghc_7.s:11:7: error:
error: unknown operand
subq $40, %rsp
^
|
11 | subq $40, %rsp
| ^
I can upload a full log, but I doubt it's very insightful.
It seems that instead of targeting LLVM assembly, it's generating something else? | 20:33:06 |
 Teo (he/him) | https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15231 should make a big difference. Sven is currently splitting off bits from this large branch and getting them merged | 20:33:07 |
| sterni (he/him) | Alex: do clang/LLVMAS version and LLVM version match? | 20:38:42 |
| Alex | I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:
- I set the target stage to 3 (instead of 1).
- I removed the
--host configure flag because the script still complains about "build != host"
I'm not very familiar with x86 assembly, but it does look like x86 assembly. Even though GHC is being explicitly given -fllvm. | 20:41:12 |
| Alex | * I would assume so, because I've undone the changes I made to LLVMAS.
I think this is just happening because:
- I set the target stage to 3 (instead of 1 or 2).
- I removed the
--host configure flag because the script still complains about "build != host"
I'm not very familiar with x86 assembly, but it does look like x86 assembly. Even though GHC is being explicitly given -fllvm. | 20:41:32 |
