9 Jul 2025 |
sellout | I know the Cachix incantation removes the .drv s before pushing, but I had added those back in. | 16:49:42 |
sellout | Thanks for the response βΒ it at least gives me more to explore. | 16:51:15 |
11 Jul 2025 |
| Jose Storopoli joined the room. | 17:50:21 |
12 Jul 2025 |
Patrick Steele | Late response, but NixOS on WSL2. | 02:17:45 |
13 Jul 2025 |
Pierre Thierry | I want HLS for GHC 9.6.6 to match what a Stack project is using, so I tried a shell.nix file with:
pkgs.mkShell {packages = [pkgs.haskell.packages.ghc966.ghcWithPackages (p: [p.haskell-language-server])];}
But the test suite of zlib fails on check compress large chunk: Test suite tests: FAIL
| 18:11:02 |
Pierre Thierry | I'm not sure how to debug/fix that⦠| 18:11:10 |
Pierre Thierry | (is there a better way to get the HLS for GHC 9.6.6?) | 18:30:36 |
maralorn | @kephaspierre:matrix.org We need more context for that error message. Is it while building the nix shell failing the zlib derivation? There are different ways but at this point I don't see how they would fix the problem. | 22:18:59 |
alexfmpe | yay, gi-foo packages got fixed with LTS bump | 22:50:54 |
alexfmpe | I was utterly on the dark about that | 22:51:20 |
14 Jul 2025 |
Pierre Thierry | In reply to @maralorn:maralorn.de @kephaspierre:matrix.org We need more context for that error message. Is it while building the nix shell failing the zlib derivation? There are different ways but at this point I don't see how they would fix the problem. Yes, the nix-shell is built just fine with ghc963 but fails with ghc966 . | 00:09:44 |
sterni | alexfmpe: https://github.com/haskell-gi/haskell-gi/issues/472#issuecomment-3041892857 | 08:22:23 |
sterni | π¨π¨π¨π¨π¨π¨π¨π¨π¨π¨π¨π¨ https://www.stackage.org/lts-24 | 20:59:47 |
alexfmpe | seems my packages work there
which is good because I'm about to disappear into a black hole for 3 weeks | 23:36:31 |
15 Jul 2025 |
sterni | I have a good feeling about this LTS version (clueless) | 09:20:07 |
sterni | maralorn: have you played around with nix-eval-jobs before? | 09:21:30 |
sterni | Did we intentionally remove this job? https://hydra.nixos.org/eval/1816888#tabs-removed can't remember anything | 09:30:49 |
maralorn | Yeah, the fact that it arrived so fast is probably a good sign. | 09:31:40 |
maralorn | Not really, I think. Why? | 09:32:10 |
sterni | we need to use it now because hydra-eval-jobs got killed | 09:32:36 |
maralorn | Huh, I see. | 09:32:51 |
sterni | it has a different streaming output I think which needs changes | 09:35:29 |
sterni | I figured out the flags needed to get it to behave like hydra-eval-jobs mostly now | 09:35:43 |
sterni | but I haven't seen it finish on my machine yet and I don't quite know what's going on | 09:35:58 |
sterni | I think it has some built in resource limits | 09:36:05 |
sterni | I have a draft pr with it | 09:36:18 |
ncfavier | has anyone seen this error before with the GHC JS backend?
Aborted('HEAP8' was not exported. add it to EXPORTED_RUNTIME_METHODS (see the Emscripten FAQ))
(nix run github:ncfavier/glam/ghcjs-backend#glam-js to reproduce; say yes at the prompts to avoid building GHC)
| 11:10:59 |
maralorn | ncfavier: Yes! That is a known issue. | 11:24:12 |
maralorn | I have upstreamed a fix in ghc, which is not yet released and funnily I donβt think the fix works anyway. π However there is a known to be working workaround:
Put this in the executable part of your .cabal file.
-- Workaround for a runtime error ("HEAP8 not found"). Only necessary until
-- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14362 is resolved.
ld-options: -sEXPORTED_RUNTIME_METHODS=HEAP8,HEAPU8
| 11:26:25 |
maralorn | One of the causes here is that the emscripten version used in ghc CI is older than in nixpkgs. | 11:28:35 |