| 31 Mar 2025 |
 a12l | Is it possible my /tmp (tmpfs) that gets filled? For I've > 75GB left on my SSD, and I hope more than that isn't necessary?
| 11:38:24 |
 maralorn | I guess so. | 11:39:21 |
| a12l | Guess I'll have to move my /tmp to my regular fs. I'll come back later today with the results :) | 11:44:00 |
| maralorn | That’s annoying. | 11:45:18 |
 emily | you can set the Nix build-dir setting | 14:26:54 |
 sellout | Thanks – you’ve reminded me why my code is the way it is. I currently use cabal-doctest, but sol suggested I change it to use the more “official” way to run it. And getting rid of 75 loc per package seemed like a good reason to. But a major reason I use cabal-doctest is so my doctests are run in the Nixpkgs derivations, which I have much less control over than the derivations in my repo. I think the only reasonable way to avoid it would be if cabal2nix itself accepted some way to run doctest explicitly. At least all that boilerplate is generated code – I generally don’t have to think about it. | 15:09:37 |
|  Alyssa Ross joined the room. | 16:02:58 |
| Alyssa Ross | @sternenseemann:systemli.org what would be my route to getting GHC on aarch64 musl in Nixpkgs, ideally relatively soon? They have binaries for 6.8 but nothing older, and my previous strategy of just avoiding anything with a pandoc input is getting more and more difficult. | 16:04:42 |
| a12l | I've
(pkgs.haskell-language-server.override {
supportedGhcVersions = [ "96" "92" ];
})
in environment.systemPackages. But when I run haskell-language-server-wrapper in a Haskell project I get this
# haskell-language-server-wrapper
No 'hie.yaml' found. Try to discover the project type!
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 2.9.0.0 x86_64 ghc-9.6.6
Current directory: /root/Forges/Exercism/haskell/acronym
Operating system: linux
Arguments: []
Cradle directory: /root/Forges/Exercism/haskell/acronym
Cradle type: Stack
Tool versions found on the $PATH
cabal: 3.12.1.0
stack: 3.1.1
ghc: 9.6.6
Consulting the cradle to get project GHC version...
2025-03-31T19:38:26.654350Z | Debug | stack --stack-yaml /root/Forges/Exercism/haskell/acronym/stack.yaml setup --silent
2025-03-31T19:38:28.478946Z | Debug | stack --stack-yaml /root/Forges/Exercism/haskell/acronym/stack.yaml exec ghc -- --numeric-version
Project GHC version: 9.2.7
haskell-language-server exe candidates: ["haskell-language-server-9.2.7","haskell-language-server"]
Failed to find a HLS version for GHC 9.2.7
Executable names we failed to find: haskell-language-server-9.2.7,haskell-language-server
| 19:55:35 |
| a12l | Doesn't seem that HLS for 9.2 is available in my $PATH? | 19:55:51 |
| maralorn | Can you do an ls on the output of the derivation? | 20:51:10 |
 Alex | In reply to @a12l:matrix.org
Doesn't seem that HLS for 9.2 is available in my $PATH? nix-repl> haskell.compiler.ghc92.version
"9.2.8"
This is probably why. You need "927" in the supportedGhcVersions. | 21:29:12 |
| a12l | maralorn, Alex It seems that haskell-language-server-9.2.8 is in my $PATH when I try to autocomplete in the terminal. | 21:58:21 |
| a12l | May be that. But why do I need to specify 927? Why doesn't 928 show up when I run haskell-language-server-wrapper when 966 shows up? | 21:59:56 |
| Alex | In reply to @qyliss:fairydust.space
@sternenseemann:systemli.org what would be my route to getting GHC on aarch64 musl in Nixpkgs, ideally relatively soon? They have binaries for 6.8 but nothing older, and my previous strategy of just avoiding anything with a pandoc input is getting more and more difficult. Have you tried getting it through pkgsMusl?
IIRC pkgsMusl is cross-compiled from the glibc bootstrap, but that should work even for GHC nowadays. | 22:00:52 |
| Alex | In reply to @a12l:matrix.org
May be that. But why do I need to specify 927? Why doesn't 928 show up when I run haskell-language-server-wrapper when 966 shows up? Because 92 means "the latest available revision of 9.2" and that happens to be 9.2.8, not 9.2.7.
For 96, 9.6.6 is the latest revision in Nixpkgs so that's what you get. | 22:02:24 |
| a12l | I understand why you get 9.2.8 when you specify 92, but why does 9.6.6 show up when running haskell-language-server-wrapper and not 9.2.8? In that project 9.2.8 is more correct that 9.6.6 | 22:05:22 |
| Alex | I don't think it's chosen to use either version?
HLS needs the exact same version as the compiler, so the wrapper gave up altogether when it failed to find a HLS for 9.2.7. | 22:06:51 |
| Alex | * I don't think it has chosen to use either version?
HLS needs the exact same version as the compiler, so the wrapper gave up altogether when it failed to find a HLS for 9.2.7. | 22:06:58 |
| 1 Apr 2025 |
|  _low_ joined the room. | 00:19:59 |
| _low_ | Hey, I'm using NixOS & Cabal & GHC 9.12.1. I want to utilize hmatrix-gls (0.19.0.1). But cabal new-build all --preference="Cabal >= 3.14.1.1" --keep-going --enable-debug-info=3 inside of nix develop --impure --expr 'with import <nixpkgs> {}; mkShell rec { buildInputs = [pkg-config zlib blas lapack gsl]; LD_LIBRARY_PATH = lib.makeLibraryPath buildInputs;}' leads to <no location info>: error: …/libgsl.so: undefined symbol: cblas_ctrmv. Any idea? Thx in advance! | 00:52:19 |
| _low_ | Among other things, I've tried to (1) utilize openblas instead of blas and to (2) link dynamically by shared: True↵executable-dynamic: True. | 00:52:56 |
| _low_ set a profile picture. | 00:57:46 |
| _low_ changed their profile picture. | 01:03:16 |
| _low_ changed their display name from lowtex to low. | 01:03:44 |
| Alyssa Ross | In reply to @alex:tunstall.xyz
Have you tried getting it through pkgsMusl?
IIRC pkgsMusl is cross-compiled from the glibc bootstrap, but that should work even for GHC nowadays. That's what I'm doing. It is not cross compiled. | 07:09:44 |
| a12l | Alex: It works now! Thanks for the help! | 07:26:50 |
| Alyssa Ross | It natively bootstraps from a GHC-provided binary, but for 9.2.4 (current bootstrap) compiler, that's only available for x86_64: nixpkgs/ | 08:30:30 |
| Alyssa Ross | * | 08:30:39 |
 @Las:matrix.org | What's the "canonical" way of applying an overlay to all haskell packages? Can't seem to find it in the manual, and I think what I did back in the day was do it manually for the specific haskell packages I was using. | 18:36:19 |
