!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

724 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/ | More Nix: #community:nixos.org | More Haskell: #haskell-space:matrix.org144 Servers

Load older messages


SenderMessageTime
10 Feb 2025
@ashinnv:matrix.orgMr Mayhem changed their display name from Mississippi_metalhead_mailman_magnolia_mayhem to Mississippi_metalhead_mailman_maybe_magnolia_mayhem.21:48:24
@dmjio:matrix.org@dmjio:matrix.org

alexfmpe sterni I'm open to moving to the new JS backend, but last I checked there were some outstanding regressions in closure compilation that significantly affect payload size (maybe I'm out of date now?), and some new runtime errors that users were reporting (despite the fact that it builds). The original GHCJS (that miso caches) has a working GHCJSi, TH support, payloads amenable closure compilation, and the fewest runtime errors.

It seems the community has moved on to using an experimental build tool (flakes), a new compiler (which has introduced seemingly significant regressions for JS code output) and a new haskell package infra (haskell.nix), and has chosen to replace GHCJSi w/ the package jsaddle-warp and nixops is on life support.

Was considering the WASM backend as default instead because they support GHCi and TH now, but getting a proper nix derivation for it (it forks llvm to add a custom allocator -- maybe we should consider zig cc ?) to work with crossPkgs seems like a non-starter (according nix experts) and from my own experiments manually applying the ghc wasm patches to llvm in nixpkgs.

So the situation is less than ideal imo. In summary if the regressions can be addressed for the js closure compilation that would make me feel a little more comfortable, but I'd like to keep ghcjs around until feature parity is reached w/ the new JS backend.

21:54:57
@emilazy:matrix.orgemilydo you plan to update to Nixpkgs 25.05?22:00:47
@dmjio:matrix.org@dmjio:matrix.orgI would like to, ideally we could have a working build with the latest nixpkgs.22:04:58
@maralorn:maralorn.demaralorn dmjio: What exactly do you mean with "regressions in closure compilation"? 22:05:09
@maralorn:maralorn.demaralorn dmjio: Which libraries are you using? 22:05:52
@alexfmpe:matrix.orgalexfmpe9.10 payload sizes I think?22:05:51
@alexfmpe:matrix.orgalexfmpebut that build doesn't need to be 8.10 ghcjs right?22:08:37
@maralorn:maralorn.demaralornBy the way throwing flakes, the new js backend, haskell.nix, nixops and jsaddle-warp together sounds a bit like FUD to me. I get the sentiment, but no one is forcing you to use haskell.nix or flakes and this is all orthogonal to deployment. If you say, that you are currently using ghcjs in nixpkgs and that there are specific things missing for you to switch to the new backend, that is a very valuable data point.22:10:38
@dmjio:matrix.org@dmjio:matrix.org

maralorn: three things particular

  1. Linking (JS file concatenation) can cause OOMs (still) in CI servers - I think this has always been a problem though.
  2. The optimizer that typically runs was disabled (I'm not sure if they fixed that upstream, but modifications to it caused them to rethink)
  3. Closure compiler support stopped working and payload size got much larger
  4. Newer versions of nix don't work with miso's default version of nixpkgs ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64
22:12:00
@dmjio:matrix.org@dmjio:matrix.org *

maralorn: three 4 things particular

  1. Linking (JS file concatenation) can cause OOMs (still) in CI servers - I think this has always been a problem though.
  2. The optimizer that typically runs was disabled (I'm not sure if they fixed that upstream, but modifications to it caused them to rethink)
  3. Closure compiler support stopped working and payload size got much larger
  4. Newer versions of nix don't work with miso's default version of nixpkgs ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64
22:12:13
@dmjio:matrix.org@dmjio:matrix.org *

maralorn: three 4 things particular

  1. Linking (JS file concatenation) can cause OOMs (still) in CI servers - I think this has always been a problem though.
  2. The optimizer that typically runs was disabled (I'm not sure if they fixed that upstream, but modifications to it caused them to rethink)
  3. Closure compiler support stopped working and payload size got much larger
  4. Newer versions of nix don't work with miso's default version of nixpkgs on Darwin. ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64
22:12:38
@dmjio:matrix.org@dmjio:matrix.orghttps://github.com/ghcjs/ghcjs/issues/821#issuecomment-112938836622:13:14
@alexfmpe:matrix.orgalexfmpe
  1. This is the thing that got disabled in 8.10 I believe. I seem to recall in #ghc-js-backend:matrix.org them telling me that thing in particular was still disabled, but a ton of other optimizations had been done that probably maked up for it
    One of the reasons I was getting miso-examples building in nixpkgs was to peek at the resulting sizes but I'm a bit confused on whether I have the right output due to some "undefined" errors when running.
    FWIW, here's what I got so far on my branch (no closure compiler AFAICT)
> l $(NIXPKGS_ALLOW_BROKEN=1 nix-build -A pkgsCross.ghcjs.haskell.packages.ghc912.miso-examples)/bin
total 110M
dr-xr-xr-x 1 root root  160 jan  1  1970 .
dr-xr-xr-x 1 root root   16 jan  1  1970 ..
-r-xr-xr-x 2 root root 9.3M jan  1  1970 canvas2d
-r-xr-xr-x 2 root root 9.6M jan  1  1970 compose-update
-r-xr-xr-x 2 root root 9.7M jan  1  1970 file-reader
-r-xr-xr-x 2 root root 9.7M jan  1  1970 mario
-r-xr-xr-x 2 root root 9.2M jan  1  1970 mathml
-r-xr-xr-x 2 root root  12M jan  1  1970 router
-r-xr-xr-x 2 root root  11M jan  1  1970 svg
-r-xr-xr-x 2 root root 9.4M jan  1  1970 threejs
-r-xr-xr-x 2 root root  11M jan  1  1970 todo-mvc
-r-xr-xr-x 2 root root  11M jan  1  1970 websocket
-r-xr-xr-x 2 root root  11M jan  1  1970 xhr
22:15:31
@maralorn:maralorn.demaralornkk. I know 1, I don’t know how problematic that is. 2. is not completely solved but the new backend is better than ghcjs 8.10 afaict. 3. I thought that closure compiler works with the new backend (see: https://blog.haskell.org/case-study-foreign-integration-js-browser/).22:15:33
@alexfmpe:matrix.orgalexfmpeso that's ~10MB pre closure compiler and pre-compression22:16:15
@alexfmpe:matrix.orgalexfmpewhich doesn't sound too big given I've reached 100MB on 8.10 at that stage hhe22:16:41
@alexfmpe:matrix.orgalexfmpe* which doesn't sound too big given I've reached 100MB on 8.10 at that stage heh22:16:45
@maralorn:maralorn.demaralornBut if 2. is really a problem for you, does that mean you are still on ghcjs 8.6? If yes, then you are currently not on a working nixpkgs and us dropping 8.10 wouldn’t make a difference, would it?22:16:56
@maralorn:maralorn.demaralorn* But if 2. is really a problem for you, does that mean you are still on ghcjs 8.6? If yes, then you are currently not on an up-to-date nixpkgs and us dropping 8.10 wouldn’t make a difference, would it?22:17:26
@dmjio:matrix.org@dmjio:matrix.orgWell yes and no, if you don't keep in lockstep with the community eventually everything bitrots to the point where it can't be built. That's why nix has been great so far, but the critical mass of the community is converging around tooling that introduces imo significant regression22:17:57
@maralorn:maralorn.demaralornI would understand that. We are on 8.6 at work exactly for this reason. That is why we don’t care about dropping 8.10 its useless to use anyway.22:18:06
@dmjio:matrix.org@dmjio:matrix.org I'm personally not, but other people I know who use miso at work do use 8.10 22:18:29
@dmjio:matrix.org@dmjio:matrix.orgOk then we're in the same boat22:18:48
@alexfmpe:matrix.orgalexfmpeIsn't miso's nixpkgs pin ~2 years old? The same goes for reflex-platform which is why we had been assuming everyone would jump from old nixpkgs with 8.x ghcjs to new nixpkgs with 9.12+22:19:21
@alexfmpe:matrix.orgalexfmpethe question is whether anyone needs a new nixpkgs with a 8.x ghcjs22:19:38
@maralorn:maralorn.demaralornAnyway we can’t do anything about flakes. And we in this channel generally don’t want to switch to haskell.nix. The bitrotting of ghcjs is sad, but that’s why it is awesome that there is the new backend.22:20:04
@maralorn:maralorn.demaralorn* I would understand that. We are on 8.6 at work exactly for this reason. That is why we don’t care about dropping 8.10 its useless to us anyway.22:20:13
@dmjio:matrix.org@dmjio:matrix.org6 years old22:21:07
@rosscomputerguy:matrix.orgTristan Ross
In reply to @dmjio:matrix.org
6 years old
That's a little scary
22:21:20

Show newer messages


Back to Room ListRoom Version: 6