| 1 Mar 2026 |
|  Allan Dinakaran joined the room. | 16:37:08 |
|  @magpi:matrix.org left the room. | 21:29:45 |
|  Philip W joined the room. | 22:41:32 |
| 2 Mar 2026 |
|  iclanzan joined the room. | 01:25:33 |
| iclanzan | I’ve been happily using Haskell for a couple of years through Nix like so:
(pkgs.haskell.packages.ghc910.override {overrides = ...;}).ghcWithPackages(p: [...])
However recently one of my haskell apps started crashing with an exception from time to time. I am hunting for a way to have a call-stack printed for these exceptions. Since I don’t control third party libraries I cannot add HasCallstack to them to be able to debug that way so I have been trying to compile with -prof for the last couple of days with no success.
Does anyone have a working example of how to get this working?
| 14:19:07 |
 alexfmpe | I thought nixpkgs built everything with and without profiling by default? | 19:24:59 |
| alexfmpe | I see .o and .p_o in logs all the time | 19:25:12 |
|  GlowupFeathers joined the room. | 20:38:25 |
 Alex | In reply to @iclanzan:matrix.org
I’ve been happily using Haskell for a couple of years through Nix like so:
(pkgs.haskell.packages.ghc910.override {overrides = ...;}).ghcWithPackages(p: [...])
However recently one of my haskell apps started crashing with an exception from time to time. I am hunting for a way to have a call-stack printed for these exceptions. Since I don’t control third party libraries I cannot add HasCallstack to them to be able to debug that way so I have been trying to compile with -prof for the last couple of days with no success.
Does anyone have a working example of how to get this working?
If you really need to, you can override dependencies to tune them to your liking.
But profiling builds are available by default, so if that's all you're after then you only need to tweak the build for the final executable.
What exactly have you tried and how has it failed? The usual Cabal flag should just work. | 20:46:31 |
| iclanzan | I am not using Cabal in my project. Trying to compile with ghc -prof gives an error about ghc not supporting profiling because it was compiled with -dynamic. I tried overriding mkDerivation to add enableLibraryProfiling = true and enableExecutableProfiling = true which caused the tests (check phase) to fail for a lot of libraries so then I added doCheck = false to skip tests. That worked to compile libraries but did not help with ghc. Same error ensued.
Then I tried overriding pkgs.haskell.packages.ghc910.compiler by adding enableProfiledLibs = true to no effect. I then added enableSharedLibraries = false and enableSharedExecutables = false and that cause ghc to fail to compile complaining about missing dynamic object files.
| 21:04:48 |
| Alex | Works fine for me.
alex@alex-pc3 ~> nix-shell -p ghc --run fish
alex@alex-pc3 nix-shell:/t/nix-shell-1930075-2124826253> ghc -prof Hello.hs
[1 of 2] Compiling Main ( Hello.hs, Hello.o )
[2 of 2] Linking Hello
alex@alex-pc3 nix-shell:/t/nix-shell-1930075-2124826253> ./Hello -RTS -p
Hello, world!
alex@alex-pc3 nix-shell:/t/nix-shell-1930075-2124826253> cat Hello.prof
Mon Mar 2 21:25 2026 Time and Allocation Profiling Report (Final)
Hello +RTS -p -s -RTS
total time = 0.00 secs (0 ticks @ 1000 us, 1 processor)
total alloc = 49,280 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc
MAIN MAIN <built-in> 0.0 22.7
CAF GHC.Internal.IO.Handle.FD <entire-module> 0.0 70.5
CAF GHC.Internal.IO.Encoding <entire-module> 0.0 5.0
CAF GHC.Internal.Conc.Signal <entire-module> 0.0 1.3
individual inherited
COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc
MAIN MAIN <built-in> 138 0 0.0 22.7 0.0 100.0
CAF GHC.Internal.Conc.Signal <entire-module> 262 0 0.0 1.3 0.0 1.3
CAF GHC.Internal.IO.Encoding <entire-module> 208 0 0.0 5.0 0.0 5.0
CAF GHC.Internal.IO.Encoding.Iconv <entire-module> 206 0 0.0 0.4 0.0 0.4
CAF GHC.Internal.IO.Handle.FD <entire-module> 197 0 0.0 70.5 0.0 70.5
CAF Main <entire-module> 145 0 0.0 0.1 0.0 0.1
| 21:26:47 |
| Alex | For reproducibility, I should also mention this:
alex@alex-pc3 ~> nixos-version
25.11.2793.89dbf01df72e (Xantusia)
| 21:28:03 |
| Alex | * Works fine for me.
alex@alex-pc3 ~> nix-shell -p ghc --run fish
alex@alex-pc3 nix-shell:/t/nix-shell-1930075-2124826253> ghc -prof Hello.hs
[1 of 2] Compiling Main ( Hello.hs, Hello.o )
[2 of 2] Linking Hello
alex@alex-pc3 nix-shell:/t/nix-shell-1930075-2124826253> ./Hello +RTS -p
Hello, world!
alex@alex-pc3 nix-shell:/t/nix-shell-1930075-2124826253> cat Hello.prof
Mon Mar 2 21:25 2026 Time and Allocation Profiling Report (Final)
Hello +RTS -p -RTS
total time = 0.00 secs (0 ticks @ 1000 us, 1 processor)
total alloc = 49,280 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc
MAIN MAIN <built-in> 0.0 22.7
CAF GHC.Internal.IO.Handle.FD <entire-module> 0.0 70.5
CAF GHC.Internal.IO.Encoding <entire-module> 0.0 5.0
CAF GHC.Internal.Conc.Signal <entire-module> 0.0 1.3
individual inherited
COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc
MAIN MAIN <built-in> 138 0 0.0 22.7 0.0 100.0
CAF GHC.Internal.Conc.Signal <entire-module> 262 0 0.0 1.3 0.0 1.3
CAF GHC.Internal.IO.Encoding <entire-module> 208 0 0.0 5.0 0.0 5.0
CAF GHC.Internal.IO.Encoding.Iconv <entire-module> 206 0 0.0 0.4 0.0 0.4
CAF GHC.Internal.IO.Handle.FD <entire-module> 197 0 0.0 70.5 0.0 70.5
CAF Main <entire-module> 145 0 0.0 0.1 0.0 0.1
| 21:29:28 |
| 3 Mar 2026 |
| iclanzan | I figured it out. I am using TemplateHaskell and for that to work with -prof I needed to add -fexternal-interpreter. GHC’s error message indicated that as a possible solution but I didn’t explore it. 🤦 | 01:34:03 |
| 4 Mar 2026 |
 sterni | in this case updating should help recent versions of nixpkgs build cabal2nix against Cabal 3.14 | 21:21:58 |
| 5 Mar 2026 |
|  @kintrix:matrix.org left the room. | 17:13:04 |
| 6 Mar 2026 |
|  nki ⚡️⚡️ changed their display name from nki ⚡️ to nki ⚡️⚡️. | 18:41:12 |
| 8 Mar 2026 |
|  Jack (he/him) changed their display name from Jack to Jack (he/him). | 07:37:36 |
 ncfavier | I have a strange situation where building a Haskell package on aarch64-darwin results in more references than expected (as reported by nix-store -q --references), and most of them are not actually present in the output (at least grep -ra doesn't find them). Does this ring a bell for anyone? To reproduce, clone https://github.com/the1lab/1lab and run nix-build -A shakefile. | 15:48:14 |
| Alex | I recall hearing of a much alike issue before.
Have you looked at the output of nix why-depends --all --precise? | 15:52:37 |
| ncfavier | Thanks, that helped me figure out that the references are through symbolic links, which grep doesn't follow by default. | 16:01:40 |
| 9 Mar 2026 |
| sterni | I finally discovered what breaks HLS on 9.12.3 and its a bug that has been present in Cabal 3.14 all along, but was masked by a bug that has been fixed in Cabal 3.14.2.0 lol https://github.com/haskell/cabal/issues/11598 | 15:03:54 |
| sterni |
- https://github.com/fourmolu/fourmolu/pull/518
- https://github.com/Bodigrim/cabal-add/pull/10
| 15:22:44 |
| sterni | IMO a bad change, though, since it doesn't make sense that build-tool-depends are available at test suite run time. Cabal should have rather added a different mechanism (that has been needed since forever) for this. | 15:23:50 |
 chreekat | You typoed the name of the executable on the report to cabal-add :P (you wrote fourmolu) | 16:11:15 |
| alexfmpe | Oh yay more build-tool-depends annoyances | 18:13:04 |
| alexfmpe | https://github.com/well-typed/haskell-debugger/pull/203 | 18:13:07 |
| alexfmpe | Which quickly got reverted because cabal somehow failed to build cabal | 18:15:21 |
| alexfmpe | https://github.com/well-typed/haskell-debugger/issues/206 | 18:16:06 |
| alexfmpe | * Oh yay more build-tool-depends annoyances. I recently ran into | 18:16:34 |
