Newest at the top
| 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" |
| 2025-02-12 22:11:21 +0100 | hattckory | (~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 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca) |
| 2025-02-12 22:09:31 +0100 | hattckory | (~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 |