| 3 Nov 2025 |
 sterni | they search for the library and headers for no other reason than to fail with a “helpful” error message | 14:21:18 |
| sterni | this build may fail with Setup.hs and succeed if you delete it | 14:21:47 |
|  Collin Arnett changed their profile picture. | 15:23:55 |
 Daniel Firth | Doing a few benchmarks of GHC here. https://www.youtube.com/watch?v=kt2hM2uz8Hs | 21:13:09 |
 keypusher | Say I have 2 flakes A and B that basically are just haskell packages. B depends on A. If I use nix, it's quite the roundtrip to update A and utilize those changes in B. Someone hinted it's possible to circumvent nix and easily get changes to A while in a nix develop shell for B. Makes sense? | 21:45:30 |
 Alex | In reply to @keypusher:matrix.org
Say I have 2 flakes A and B that basically are just haskell packages. B depends on A. If I use nix, it's quite the roundtrip to update A and utilize those changes in B. Someone hinted it's possible to circumvent nix and easily get changes to A while in a nix develop shell for B. Makes sense? It's not entirely clear what you're asking or of what relevance Haskell or Nixpkgs are, but how about overriding flake B to use a different version of flake A? | 21:47:41 |
| keypusher | I'm getting at the timeconsuming roundtrip of getting a change in A availalbe in the "nix developer shell" of B. Atm I need to 1) make changes to A. 2) exit B's dev shell. 3) start B's dev shell that includes an implicit build of the A flake. 4) issue cabal build in B's devshell. | 21:52:09 |
| Alex | In reply to @keypusher:matrix.org
I'm getting at the timeconsuming roundtrip of getting a change in A availalbe in the "nix developer shell" of B. Atm I need to 1) make changes to A. 2) exit B's dev shell. 3) start B's dev shell that includes an implicit build of the A flake. 4) issue cabal build in B's devshell. You could exclude A from the devshell build by adding it to the packages list in haskellPackages.shellFor.
This naturally assumes that A's source is visible to B's Cabal project. | 21:55:51 |
| keypusher | A right. Yeah it could be different target (forgot the actual term). Like nix flake develop .#includeAInBuildOfB so to speak? | 21:59:58 |
| Alex | If you still want to keep the "A from devshell" version, then yes you could make this "fast" devshell a different one. | 22:01:20 |
| 4 Nov 2025 |
|  ncfavier changed their profile picture. | 23:55:13 |
| 5 Nov 2025 |
 tks_123 | I have a "nix develop" environment working fine for "cabal build". It links successfully to a custom static C library I have in the flake.nix | 07:35:24 |
| tks_123 | When running "cabal repl", why does it complain the dynamic library .so isn't found? This library is only static | 07:35:44 |
| tks_123 | * When running "cabal repl", why does it complain the dynamic library .so isn't found? The library is only static. (It's specified in extra-libraries in .cabal btw.) | 07:36:10 |
|  Supermuskox left the room. | 09:10:40 |
| Supermuskox joined the room. | 09:37:13 |
| sterni | what version of GHC? | 10:06:54 |
| sterni | I think for 9.4 this works, but in general it is not to be expected. You need to coax the rts linker into loading a shared archive which it doesn't necessarily like because it's tricky. dlopen of course only works for shared objects which is the normal way | 10:08:33 |
| sterni | (Haskell static archives/object files is not a problem, but arbitrary ones) | 10:08:56 |
 chreekat | Ghc/Cabal is confusing af on this point. I'm spectating right now as people in #GHC:matrix.org try to figure out some forms of static linking | 10:56:00 |
| sterni | i mean this is not that great a mystery, only dynamic libs are designed so that they can be dynamically loaded at run time (instead of link time) | 12:05:15 |
| sterni | so you would not in general expect your repl to br able to do this | 12:05:34 |
| chreekat | Well it's obvious now that you've said it 😄 | 12:15:35 |
| keypusher | Redacted or Malformed Event | 14:12:49 |
| 6 Nov 2025 |
|  @denbrahe:matrix.org left the room. | 15:24:22 |
| 7 Nov 2025 |
 MangoIV | has anybody here thought about enabling -finfo-table-map in nixpkgs? | 15:29:15 |
 maralorn | Yes | 16:20:44 |
| maralorn | me | 16:20:45 |
| maralorn | I discussed this with ben. The problem is, that it increases binary size significantly. So we probably can’t enable it by default. And its also not possible to strip it in binaries which don’t want it. | 16:21:59 |
| maralorn | So the best available option would be to replace our profiling builds with an info-table-map build. | 16:22:30 |
