| 30 Oct 2025 |
 alexfmpe | $ grep "callPackage" hackage-packages.nix | wc -l
18654
$ grep "broken = true" hackage-packages.nix | wc -l
7267
a few others won't eval because of platform but that still looks like around 10k that will at least attempt to build
| 23:12:01 |
| 31 Oct 2025 |
 Alex | In reply to @alexfmpe:matrix.org
another option is building whatever deps your planned project has, plus a few dependency heavy hitters It's much lighter if you only fetch all transitively required sources.
Though naturally, that means you need to build whatever you want to use. | 01:56:46 |
| 2 Nov 2025 |
|  ➡️@amadaluzia:unredacted.org changed their display name from amadaluzia to ➡️@amadaluzia:unredacted.org. | 22:49:04 |
| 3 Nov 2025 |
 sterni | incredible https://github.com/Tritlo/duckdb-haskell/blob/main/duckdb-ffi/Setup.hs | 11:09:28 |
 maralorn | What exactly? That this is not just using pkg-config? | 11:52:58 |
 teo (they/he) | At least it's not hard coding paths in the .cabal file | 11:56:03 |
| 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 |
