 | Haskell in Nixpkgs/NixOS | 722 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.org | 144 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Feb 2025 | ||
 emily | if you just personally don't want those versions to be removed, then ok | 17:07:17 |
| emily | but while it's still unclear if there will be any point to me as a Darwin/LLVM person to put in the effort I'm not going to allocate my limited time to it | 17:07:46 |
| emily | if a survey is what's required I'll wait for the survey. I already sorted things out with other users of old compilers like the CUDA team and I am convinced that GHC is the only substantive blocker | 17:08:37 |
| emily | riscv64 is tier nothing, it can wait for build system bugs to be fixed (assuming we can't just patch or work around them) | 17:09:13 |
| emily | avoiding an unsupported platform placing maintenance burdens on one of our major ones is part of the reason we have a vague notion of support tiers in the first place | 17:09:51 |
| emily | if static is a blocker then that can be discussed but then why was this not raised the previous 10 times this was talked about? | 17:10:44 |
 maralorn | sterni: If you want the details: reflex-plattform currently still pins older nixpkgs, no one is planing on bumping that pin while using ghcjs. Obsidian systems has already switched to using haskell.nix and the new ghc js backend is expected to be usable with that whole setup very soon. | 17:10:51 |
| maralorn | And I actively asked the people involved whether they’d be affected by us dropping ghcjs and they all said no. | 17:12:28 |
| emily | saying that there's no need for a survey because the internal users are what matter, and then saying that actually we'd need to survey external users when I say that the internal users seem tractable and I'm happy to help, and then bringing up new concerns about RISC-V and static when I say I'll wait for the survey, just makes it seem like you want to stall indefinitely | 17:16:28 |
| emily | if old GHCs are actually required and that's just a fact of life then sure, I can deal with that, although it would be nice if the GHC maintainers took over responsibility for quickly backporting fixes to old LLVMs that they are consequently the only substantive users of | 17:17:35 |
| emily | but I haven't seen any evidence that more than one person wants to keep them, and plenty of evidence that nobody else really cares, but the reasons pile keeps growing every time it's brought up all the same | 17:18:09 |
| emily | I'm happy to put in effort to solve any technical obstacles, or wait for a survey or whatever else, but I'm not convinced that technical obstacles are what's blocking here | 17:18:52 |
 mjm joined the room. | 17:19:48 | |
| emily | GHC is in the critical path for building a working Nixpkgs. the bootstrap pulls in an unsupported LLVM that doesn't build with modern compilers without patching and keeps requiring manual work to backport fixes. it has broken during recent staging cycles and it has fallen on Darwin maintainers to fix it because we cannot just ignore it. if there are substantive technical blockers to fixing this, then I want to work to address them. if there is a meaningful external userbase that relies on using those unsupported compilers with a supported Nixpkgs then I want to hear from them and discuss what the long-term options are. but it is a major burnout factor to have to repeatedly take responsibility for maintaining a codebase that we would rather be outside our purview because it very indirectly blocks the world and one maintainer can't decide what the reason it has to stay is | 17:33:32 |
| emily | if a survey will settle the issue then I'll wait for a survey. but the reason there are still internal users is that it seems like a bad use of my time and energy when I get the feeling there'd be another reason even if static and RISC-V were solved and the survey got 1000 responses all saying they don't care about it | 17:34:41 |
| emily | so instead I spend my time shepherding LLVM 12 fixes because I have no choice other than giving up on Darwin maintenance | 17:35:59 |
| emily | for the benefit of what may well be zero users who want to use old ghcjs on a fresh Nixpkgs release that is still over 3 months away | 17:36:36 |
| maralorn | sterni: I am currently not super motivated to do that survey. But what do you think about dusting of my deprecation proposal: https://md.darmstadt.ccc.de/FZwe_M9GQwWVnYfO0U4qJA (Would need a few updates.) The idea is still to announce it loud and wide and then people can complain, which I don’t expect them to do. The goal here is to give ourselves the permission to remove 8.10-9.2 if we can manage it. Of course we wouldn’t do it if we can’t manage building stuff like elm or bootstraping relevant configurations, but that’s orthogonal. No deprecation policy can force us to break our builds. This is just to unblock contributors like emily so that we are clear about internal and external requirements and expectations. | 18:05:09 |
 Tristan Ross | In reply to @emilazy:matrix.orgYeah, this is why I'm being kinda strict with removing LLVM 12. Less of a burden. And with the Darwin, really seems much more of a reason to remove it. We've basically got everything else except GHC off LLVM 12 so GHC is the last thing standing. It's the last release pre monorepo, doesn't get any patches. | 19:19:13 |
 alexfmpe | In reply to @maralorn:maralorn.deAlso use it, also on said call and I'm with maralorn on this. Kill it with fire, brimstone and extreme prejudice. Miso and reflex-dom now build with pkgsCross.ghcjs.haskell.packages.ghc912 on haskell-updates or open PRs to it | 21:08:16 |
| alexfmpe | Obsidian isn't even fussing over nixpkgs haskell, they adopted haskell.nix | 21:09:55 |
| alexfmpe | Miso does use nixpkgs haskell but they're also on a 2 years old and in the process of jumping directly to modern nixpkgs | 21:12:28 |
| alexfmpe | Er, modern nixpkgs for 9.12 ghc | 21:13:08 |
 Mr Mayhem changed their display name from magnolia_mayhem to Mississippi_metalhead_mailman_magnolia_mayhem. | 21:47:39 | |
| Mr Mayhem changed their display name from Mississippi_metalhead_mailman_magnolia_mayhem to Mississippi_metalhead_mailman_maybe_magnolia_mayhem. | 21:48:24 | |
 @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 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 | 21:54:57 |
| emily | do you plan to update to Nixpkgs 25.05? | 22:00:47 |
| @dmjio:matrix.org | I would like to, ideally we could have a working build with the latest nixpkgs. | 22:04:58 |
| maralorn | dmjio: What exactly do you mean with "regressions in closure compilation"? | 22:05:09 |
| maralorn | dmjio: Which libraries are you using? | 22:05:52 |