Newest at the top
| 2025-02-12 22:19:04 +0100 | <merijn> | euouae: yeah .local is just a bunch of overrides merged into cabal.project |
| 2025-02-12 22:19:03 +0100 | <EvanR> | justsomeguy, what fmap does depends on the particular instance of Functor, it may not be obvious in isolation which one you're dealing with. In this case "function" Functor |
| 2025-02-12 22:19:02 +0100 | <tomsmeding> | merijn: and it should say that with --PROG-option(s)? |
| 2025-02-12 22:18:42 +0100 | <tomsmeding> | the same goes for cabal.project.freeze, actually |
| 2025-02-12 22:18:39 +0100 | <merijn> | tomsmeding: tbh it should probably just mentioned the tossed flags are the set of flags not affecting build artifacts, most notably warnings |
| 2025-02-12 22:18:29 +0100 | <euouae> | right okay |
| 2025-02-12 22:18:25 +0100 | <tomsmeding> | _conventionally_, it's your local configuration that you don't push |
| 2025-02-12 22:18:15 +0100 | <tomsmeding> | euouae: cabal.project.local is just the same thing as cabal.project, but with a different name |
| 2025-02-12 22:18:12 +0100 | <euouae> | It's not project versus dependencies -- it's programmer versus upstream |
| 2025-02-12 22:17:58 +0100 | <euouae> | tomsmeding: the .local is a different thing isn't it? I'm going by what I know from CMake |
| 2025-02-12 22:17:52 +0100 | <tomsmeding> | https://tomsmeding.com/vang/Qk3nO7/.psub.kWMobRelu5 |
| 2025-02-12 22:17:50 +0100 | <tomsmeding> | the only thing I changed is change "no longer" to "not", and change the "you should use" instruction to "--repl-options bypasses this tossing" :p |
| 2025-02-12 22:17:41 +0100 | <merijn> | xD |
| 2025-02-12 22:17:39 +0100 | <merijn> | tomsmeding: I think I closed that already |
| 2025-02-12 22:17:12 +0100 | <tomsmeding> | merijn: the thing I edited in my diff? |
| 2025-02-12 22:17:09 +0100 | <euouae> | justsomeguy: look up the Functor instances of Maybe and (->) |
| 2025-02-12 22:16:51 +0100 | <merijn> | tomsmeding: But not very well |
| 2025-02-12 22:16:46 +0100 | <tomsmeding> | justsomeguy: that outer fmap is (.), so it's `(fmap sum . Just) [1,2,3]` |
| 2025-02-12 22:16:45 +0100 | <merijn> | tomsmeding: It is mentioned here: https://cabal.readthedocs.io/en/stable/cabal-commands.html#cmdoption-repl-options |
| 2025-02-12 22:16:14 +0100 | <tomsmeding> | that solution is cabal.project.local, probably |
| 2025-02-12 22:16:13 +0100 | <justsomeguy> | How does fmap (fmap sum) Just [1,2,3] turn into fmap sum (Just [1,2,3])? What happens to the inner fmap? |
| 2025-02-12 22:15:59 +0100 | <merijn> | Is it very pretty? No, but I didn't (and still don't :p) know a better solution beyond "redesign the way every --PROG-opts work to correctly scope it to project or transitively) |
| 2025-02-12 22:15:57 +0100 | <tomsmeding> | merijn: is that tossing documented somewhere |
| 2025-02-12 22:15:51 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-12 22:15:20 +0100 | ljdarj1 | ljdarj |
| 2025-02-12 22:15:20 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-02-12 22:15:16 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 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 +0100 | justsomeguy | (~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 +0100 | wootehfoot | (~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 +0100 | ljdarj1 | (~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 +0100 | hattckory | (~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" |