| 16 Jul 2024 |
 alexfmpe | first bump nixpkgs then bump ghc | 13:21:21 |
 maralorn | No, the reason is that we have no policy for dropping old ghc versions other than "when peti feels like it". And since peti is gone for a few years now, we don’t. 😄 | 13:21:38 |
 doyougnu | In reply to @alexfmpe:matrix.org
AFAICT everyone uses reflex-platform or haskell.nix or miso this is my understanding as well. Also speaking as one of the people that merged the JS backend, we really want people to migrate off of ghcjs to the JS backend (which is 9.6 and up). | 13:39:57 |
| doyougnu | In reply to @maralorn:maralorn.de
No, the reason is that we have no policy for dropping old ghc versions other than "when peti feels like it". And since peti is gone for a few years now, we don’t. 😄 ah why did they leave? | 13:40:25 |
| maralorn | In reply to @doyougnu:matrix.org
ah why did they leave? They became a climate activist. (Which is one of the fucking best reasons I can think of. 😄 ) | 13:42:19 |
| doyougnu | oh thats awesome! Its a nice pivot from the software developer -> woodworking pipeline :p | 13:43:10 |
| alexfmpe | In reply to @doyougnu:matrix.org
this is my understanding as well. Also speaking as one of the people that merged the JS backend, we really want people to migrate off of ghcjs to the JS backend (which is 9.6 and up). need at least 9.8 for the jsaddle-verse to work no? | 13:45:53 |
| alexfmpe | but realistically, noone's going to prod until .js files are close to ghcjs 8.6 | 13:46:25 |
| alexfmpe | > nix-build -A pkgsCross.ghcjs.haskell.packages.ghc910.hello
/nix/store/slg75cqwgfl1wrmpxqszz11msa8vchh7-hello-1.0.0.2
> ls -alh result/bin/*
-r-xr-xr-x 1 root wheel 5.2M Jan 1 1970 result/bin/hello
| 13:46:59 |
| doyougnu | In reply to @alexfmpe:matrix.org
need at least 9.8 for the jsaddle-verse to work no? I'm honestly not sure, I haven't spent any time with the jsaddle-verse yet. But I agree with the .js files | 13:47:27 |
| doyougnu | yea the binary sizes are very bad right now. But there is a group of GHC devs working on fixing that. I believe they've gotten it down to something like 1.5MB on the GHC CI using the closure compiler | 13:48:18 |
| doyougnu | most of it is an uncompressed unicode table | 13:48:29 |
| alexfmpe | maybe recent jsaddle-verse works with 9.6 but when those releases happened 9.8 was already out and I mixed them | 13:49:40 |
| alexfmpe | yeah I peek at the "hello world" issue now and then | 13:50:03 |
| maralorn | In reply to @doyougnu:matrix.org
yea the binary sizes are very bad right now. But there is a group of GHC devs working on fixing that. I believe they've gotten it down to something like 1.5MB on the GHC CI using the closure compiler Google closure compiler does not work for us at work. ☹️ | 13:51:27 |
| alexfmpe | mostly out of curiosity, not that relevant until 9.12 is out | 13:50:58 |
| maralorn | In reply to @doyougnu:matrix.org
this is my understanding as well. Also speaking as one of the people that merged the JS backend, we really want people to migrate off of ghcjs to the JS backend (which is 9.6 and up). We really would love to switch at work. But we are kinda stuck on reflex-platform, which is not moving. I will hopefully have time to look into it soon, though. | 13:54:25 |
| alexfmpe | In reply to @maralorn:maralorn.de
Google closure compiler does not work for us at work. ☹️ huh that's weird | 14:03:34 |
| alexfmpe | it's supposed to come with obelisk out of the box, used it in a bunch of projects | 14:03:50 |
| alexfmpe | hell, back when there was a bug with -dedupe that made builds for a specific project take like an hour on the closure compiler step | 14:04:24 |
| alexfmpe | because we disabled -dedupe and the input to closure was that much bigger | 14:04:37 |
| alexfmpe | heh, # reflex-frp is leaking | 14:05:01 |
 Florian | I have a haskell libarary in my nixos configuration repo. I called cabal2nix to generate an nix file for this libary. Shouldn't that nix file suffice to build the libary. Why do I still need the cabal file? Can I somehow not have the dependency description duplicated in the cabal and nix file. I know about callCabal2nix, but i want to avoid IFD. | 14:17:59 |
 Alex | cabal2nix doesn't extract all the information needed for the build (e.g. module lists), its main purpose is to autopopulate dependencies.
The Cabal file is still needed by GHC/Cabal to perform the build. | 14:20:10 |
| Alex |
Can I somehow not have the dependency description duplicated in the cabal and nix file.
Besides using IFD or generating the Cabal file from Nix, I don't see a way to avoid duplication.
Nix needs the dependency list to provide dependencies.
GHC needs the dependency list to unhide the packages. | 14:22:22 |
| maralorn | In reply to @alexfmpe:matrix.org
huh that's weird Well, at least in the aggressive mode it doesn’t work because we use quite a few js deps and they don’t have the interface definitions that the closure compiler needs. | 14:26:14 |
| maralorn | In reply to @qe7ftcyrpg:matrix.org
I have a haskell libarary in my nixos configuration repo. I called cabal2nix to generate an nix file for this libary. Shouldn't that nix file suffice to build the libary. Why do I still need the cabal file? Can I somehow not have the dependency description duplicated in the cabal and nix file. I know about callCabal2nix, but i want to avoid IFD. I see your point, but I also see no way around it. I like to use a pre-commit hook to keep the nix file up-to-date, that makes it relatively seamless and it’s clear which file is authoritative. | 14:28:12 |
| alexfmpe | huh that's interesting | 15:23:18 |
| alexfmpe | I was kind of resigned to live with IFD slowdown on CI etc | 15:23:33 |
| alexfmpe | because of the duplication alternative | 15:23:43 |
