| 14 Jul 2025 |
 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 |
| ncfavier | amazing, thank you so much! | 11:33:49 |
| alexfmpe | Wonder if we should add the ghc issue as an eval warning heh | 13:03:47 |
| ncfavier | maybe we could just add that to the default cabal flags if stdenv.hostPlatform.isGhcjs or something | 13:55:13 |
| alexfmpe | if it's morally a "ghc backport" I agree | 14:44:10 |
| alexfmpe | otherwise it can get weird if upstream is injecting ld-options and what not for you | 14:44:32 |
| alexfmpe | silently | 14:44:37 |
| maralorn | The major problem with ld-options is that they override preconfigured ld-options. | 15:23:30 |
| maralorn | Which is no problem for the js backend because it currently has none. | 15:23:46 |
| maralorn | But in general they are mainly meant for ghc devs for debugging purposes and bgamari dislikes the fact that they are exposed via cabal options. | 15:24:41 |
| 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))
| 16:06:43 |
| 16 Jul 2025 |
| ncfavier | Is this the blessed way to write an overlay that adds a package foo to all Haskell package sets, without undoing previous overlays? If so, should we add it to the manual?
final: prev: {
haskell = prev.haskell // {
packageOverrides = final.lib.composeExtensions prev.haskell.packageOverrides
(hfinal: hprev: {
foo = ...;
});
};
}
| 15:13:51 |
| ncfavier | * Is this the blessed way to write an overlay that adds a package foo to all Haskell package sets, without undoing previous overlays? If so, should we add it to the manual? If not, what is?
final: prev: {
haskell = prev.haskell // {
packageOverrides = final.lib.composeExtensions prev.haskell.packageOverrides
(hfinal: hprev: {
foo = ...;
});
};
}
| 15:15:17 |
