2025/05/23

Newest at the top

2025-05-23 10:57:06 +0200pabs3(~pabs3@user/pabs3) pabs3
2025-05-23 10:56:15 +0200pabs3(~pabs3@user/pabs3) (Read error: Connection reset by peer)
2025-05-23 10:54:12 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-23 10:53:51 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-23 10:53:34 +0200tomsmeding. o O ( cabal install --lib --package-env=some-dir )
2025-05-23 10:53:14 +0200 <dminuoso> And tear it down afterwards?
2025-05-23 10:53:06 +0200 <dminuoso> sclv: So I guess one solution would be to actually install it into some temporary place?
2025-05-23 10:52:33 +0200 <tomsmeding> it makes sense from an architectural perspective, but as a user, I mean, the first thing you ever do is essentially `cabal run` https://cabal.readthedocs.io/en/stable/getting-started.html
2025-05-23 10:51:58 +0200wootehfoot(~wootehfoo@user/wootehfoot) wootehfoot
2025-05-23 10:51:52 +0200 <sclv> the issue with run is the binary isn't "installed" anywhere, so the datafiles don't get placed in a location the binary knows to look em up in
2025-05-23 10:51:17 +0200 <sclv> eg give the binary a flag to let it read files from a specified directory
2025-05-23 10:51:14 +0200 <tomsmeding> sclv: thanks for confirming my shakey memory about this :p
2025-05-23 10:50:53 +0200 <sclv> cabal run is about the only circumstance where datafiles don't just immediately work, and it is something that should be fixed. however, its pretty straightforward to hack around that
2025-05-23 10:50:50 +0200 <tomsmeding> I'm not against
2025-05-23 10:50:26 +0200 <dminuoso> Im just suggesting, it would be nice to embed binary data via .cabal rather than TH
2025-05-23 10:50:20 +0200 <tomsmeding> oh I see
2025-05-23 10:50:10 +0200 <dminuoso> Well the programming language for build customization is Setup.hs?
2025-05-23 10:49:56 +0200 <haskellbridge> <sm> I'm sure justine tunney (cosmopolitan c etc) has solutions!
2025-05-23 10:49:47 +0200 <tomsmeding> dminuoso: are you advocating for embedding a little programming language in cabal files so that we can move the customisation there?
2025-05-23 10:49:41 +0200 <dminuoso> Fun.
2025-05-23 10:49:39 +0200 <dminuoso> Or maybe you could generate CPP macros in your Setup.hs which are substitude in the middle of a TH splice
2025-05-23 10:49:08 +0200 <dminuoso> Are you going to propagate cabal flags via CPP to influence TH?
2025-05-23 10:49:02 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-23 10:49:00 +0200 <dminuoso> What if the content needs to be customizable?
2025-05-23 10:49:00 +0200 <tomsmeding> there's a philosophical niceness about having data in a separate file on disk from your executable code
2025-05-23 10:48:49 +0200 <dminuoso> Because with file-embed you're tying a build system into the parsing stage of your compiler...
2025-05-23 10:48:44 +0200tomsmedingdoesn't care very much about that difference
2025-05-23 10:48:36 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-23 10:48:28 +0200fp(~Thunderbi@2001:708:20:1406::1370) (Ping timeout: 272 seconds)
2025-05-23 10:48:25 +0200 <dminuoso> I would much prefer text sections in my resulting object files embedded by cabal, rather than as the result of a TH splice.
2025-05-23 10:47:50 +0200 <tomsmeding> but my point is: data files are something rather basic, and if they prohibit standard things that I expect to do with cabal packages, then it's data files that are broken, not `cabal run`
2025-05-23 10:47:00 +0200 <tomsmeding> Accelerate builds some C++ stuff in certain build modes and does so via Setup.hs, but it's fragile
2025-05-23 10:46:40 +0200 <tomsmeding> significant non-haskell dependencies that require build steps _might_ also get a pass to need a custom build system
2025-05-23 10:46:17 +0200 <dminuoso> No it's still bad for me.
2025-05-23 10:46:09 +0200 <dminuoso> It's still headaches, but honestly there just are no sane build systems in this world.
2025-05-23 10:46:04 +0200 <tomsmeding> good for you :)
2025-05-23 10:45:51 +0200 <dminuoso> See, Im building via haskell.nix to get deterministic behavior *and* all the custom nonsense without meddling with Setup.hs :)
2025-05-23 10:45:43 +0200 <tomsmeding> if you get a package from hackage, its data files probably work fine
2025-05-23 10:45:28 +0200 <dminuoso> Oh.
2025-05-23 10:45:24 +0200 <tomsmeding> dminuoso: I'm talking about everything _but_ hackage lol
2025-05-23 10:45:09 +0200 <dminuoso> Besides, the fragility of data-files by itself is perhaps a good indicator why relying on hackage is not the best of ideas.
2025-05-23 10:44:56 +0200 <tomsmeding> I'm not saying that every haskell codebase everywhere must run with `cabal run`, just that the _vast majority_ has not enough claim to specialness to not do so
2025-05-23 10:44:34 +0200 <tomsmeding> (i.e. staged build is sufficient justification for being special :p)
2025-05-23 10:43:52 +0200 <tomsmeding> okay staged ghc build gets a pass too
2025-05-23 10:43:43 +0200 <tomsmeding> dminuoso: ah right, I forgot about the staged build
2025-05-23 10:43:41 +0200 <dminuoso> While yes, you probably could rebuild it all in Setup.hs with enough energy..
2025-05-23 10:43:29 +0200 <tomsmeding> if you need something that's so complex that even a custom Setup.hs can't handle it, simplify your build process, or justify why you're special
2025-05-23 10:43:26 +0200 <dminuoso> It's simply not trivial.
2025-05-23 10:43:20 +0200 <dminuoso> I dont think age is relevant at all. GHC has a complicated staged build process.
2025-05-23 10:42:56 +0200 <tomsmeding> GHC is a special case that gets allowed its build system madness because it's old and predates cabal