2025/02/12

Newest at the top

2025-02-12 22:15:04 +0100 <merijn> (instead of globally transitive)
2025-02-12 22:14:55 +0100 <merijn> euouae: Hence --repl-options bypass the flag tossing "for this project ONLY"
2025-02-12 22:14:46 +0100justsomeguy(~justsomeg@user/justsomeguy) justsomeguy
2025-02-12 22:14:38 +0100 <merijn> euouae: Then I quickly hit your problem "whoops, now I can't use warnings via cabal repl"
2025-02-12 22:14:23 +0100 <merijn> euouae: So the compromise was: any *commandline* ghc-option that does *not* affect the resulting binary gets tossed (so no rebuilding the transitive dependencies)
2025-02-12 22:14:01 +0100 <euouae> right, I'm following
2025-02-12 22:13:47 +0100 <merijn> euouae: It has one, but not on the commandline
2025-02-12 22:13:47 +0100 <tomsmeding> not on the command line; the `ghc-options` field in the .cabal file works fine
2025-02-12 22:13:36 +0100 <merijn> euouae: Dependencies are tagged with a hash of their version, source *and flags*
2025-02-12 22:13:34 +0100 <euouae> that's /bad/ lol :P
2025-02-12 22:13:29 +0100 <euouae> okay right, you're saying cabal had no way to separate project from dep flags
2025-02-12 22:13:23 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2025-02-12 22:13:12 +0100 <merijn> euouae: Its not, cabal is
2025-02-12 22:13:06 +0100 <merijn> euouae: So, the solution was: "Strip out any flags that do not affec the resulting binary from ghc options"
2025-02-12 22:13:06 +0100 <tomsmeding> you can fiddle with them in the cabal file, which does work
2025-02-12 22:13:03 +0100 <euouae> well, ghc shouldn't be a build system? why is ghc aware of dependencies?
2025-02-12 22:12:58 +0100ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-02-12 22:12:48 +0100 <euouae> exactly, that's an issue
2025-02-12 22:12:37 +0100 <euouae> yup I see
2025-02-12 22:12:35 +0100 <merijn> euouae: This was making me fiddling with my warning flags REALLY fucking slow :p
2025-02-12 22:12:12 +0100 <merijn> euouae: Which means: adding/removing a flag via --ghc-options will trigger a recompile of your entire transitive dependency graph (well, unless you already compiled that specific set of flags before)
2025-02-12 22:11:41 +0100hattckory(~hattckory@70.31.30.224)
2025-02-12 22:11:32 +0100 <merijn> euouae: The current interpretation of --ghc-options is "transtively applied to all dependencies"
2025-02-12 22:11:21 +0100hattckory(~hattckory@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca) (Remote host closed the connection)
2025-02-12 22:10:53 +0100 <merijn> euouae: If you want the dirty complicated version: There is (or at least at the time of implementation) no way to distinguish between "ghc flags that apply to all transitive dependency of this code" and "ghc flags that apply to thise project *speficially"
2025-02-12 22:10:22 +0100 <tomsmeding> "to control ghci without influencing the build", rather
2025-02-12 22:09:51 +0100 <euouae> merijn: ah sigh.. it's a messy thing. maybe (NB. use --repl-options on ghc instead)
2025-02-12 22:09:47 +0100 <merijn> And only for a deterministic set of flags
2025-02-12 22:09:47 +0100 <tomsmeding> merijn: the original was not clearer in that direction :)
2025-02-12 22:09:45 +0100hattckory(~hattckory@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca)
2025-02-12 22:09:31 +0100hattckory(~hattckory@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca) (Remote host closed the connection)
2025-02-12 22:09:23 +0100 <merijn> euouae: It is *specifically and only* ghc that is affected
2025-02-12 22:09:15 +0100 <tomsmeding> euouae: it's useful for all situations _except_ passing an option to the repl
2025-02-12 22:09:07 +0100 <merijn> I mean that formulation is a bit confusing in the sense of "why would it not reliably pass flags?" it sounds like it implies non-determinism
2025-02-12 22:08:57 +0100 <euouae> if --PROG-options is not reliable, you might as well deprecate it
2025-02-12 22:08:44 +0100 <euouae> it might be nice to mention --repl-options in the docs for --PROG-options?
2025-02-12 22:08:27 +0100misterfish(~misterfis@84.53.85.146) misterfish
2025-02-12 22:07:48 +0100 <tomsmeding> s/game/came/
2025-02-12 22:07:40 +0100 <tomsmeding> (the idea being to turn this from a historical remark of why the flag game to be, to a description of what you can do with it)
2025-02-12 22:07:00 +0100 <tomsmeding> (this is the user guide on --repl-options)
2025-02-12 22:06:44 +0100 <tomsmeding> merijn: what do you think about this reformulation? https://tomsmeding.com/vang/Qk3nO7
2025-02-12 22:06:18 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-02-12 22:05:18 +0100zungi(~tory@user/andrewchawk) andrewchawk
2025-02-12 22:02:14 +0100 <merijn> I'm trying to reverse my logic, but it's split across 2 PRs, annoyingly
2025-02-12 22:02:08 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 272 seconds)
2025-02-12 21:59:33 +0100 <tomsmeding> it certainly seems to act as if there's no reparsing going on in between, but perhaps that just means that it's properly escaped beforehand
2025-02-12 21:59:04 +0100 <tomsmeding> merijn: if I use --ghc-option instead of --ghc-options, the space remains intact
2025-02-12 21:58:33 +0100 <tomsmeding> mauke: not if there's escaping/quoting in between
2025-02-12 21:58:25 +0100 <merijn> tomsmeding: If you quote it further, presumably
2025-02-12 21:58:08 +0100 <tomsmeding> can I not pass an option to GHC that contains a space?