Newest at the top
| 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 |
| 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 +0100 | misterfish | (~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 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-02-12 22:05:18 +0100 | zungi | (~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 +0100 | alfiee | (~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? |
| 2025-02-12 21:58:06 +0100 | <merijn> | it's complicated |
| 2025-02-12 21:58:03 +0100 | <mauke> | <merijn> euouae: it's a shell process call <-- directly contradicts <merijn> euouae: There is not space splitting |
| 2025-02-12 21:58:03 +0100 | <merijn> | well, a bit |
| 2025-02-12 21:57:59 +0100 | <merijn> | tomsmeding: I mean, not really |
| 2025-02-12 21:57:55 +0100 | <tomsmeding> | why was it designed that way |
| 2025-02-12 21:57:49 +0100 | <tomsmeding> | that's dumb |
| 2025-02-12 21:57:42 +0100 | <tomsmeding> | ah |
| 2025-02-12 21:57:35 +0100 | <merijn> | tomsmeding: Of course not, it's not called as program, it just calls the same logic with a string argument :p |
| 2025-02-12 21:57:34 +0100 | <tomsmeding> | also not if I `cabal clean` first |
| 2025-02-12 21:57:11 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-12 21:57:07 +0100 | <tomsmeding> | I don't see a setup invocation at all |
| 2025-02-12 21:56:53 +0100 | <tomsmeding> | the first call containing "notify-send" is a call to ghc that gets passed "$(notify-send" and "kaas)" as two separate arguments |
| 2025-02-12 21:56:53 +0100 | <merijn> | tomsmeding: Might be just getting reparsed at the Setup step and using execve then |
| 2025-02-12 21:56:30 +0100 | <merijn> | (similar to the two line one cabal init generates) |
| 2025-02-12 21:56:27 +0100 | <tomsmeding> | I just ran `cabal build --ghc-options='$(notify-send kaas)'` in a simple cabal project under a tracer that shows all execve calls |
| 2025-02-12 21:56:15 +0100 | <merijn> | They (implicitly) usethe default Setup.hs |
| 2025-02-12 21:55:57 +0100 | <tomsmeding> | s/projects/packages/ |
| 2025-02-12 21:55:56 +0100 | <merijn> | yes |
| 2025-02-12 21:55:52 +0100 | <tomsmeding> | is this also true in build-type: Simple projects? |
| 2025-02-12 21:54:57 +0100 | <merijn> | in that Setup step |
| 2025-02-12 21:54:49 +0100 | <merijn> | all arguments definitely get turned into one string and then reparsed, though |
| 2025-02-12 21:54:00 +0100 | <euouae> | I'm not trying to criticize eitehr |
| 2025-02-12 21:53:57 +0100 | <merijn> | the problem is that cabal-install just calls Cabal's Setup.hs |
| 2025-02-12 21:53:22 +0100 | <tomsmeding> | but as I said, at least there appears to be some escaping going on if so |
| 2025-02-12 21:53:20 +0100 | <merijn> | oh, no that's not new |
| 2025-02-12 21:53:09 +0100 | <tomsmeding> | if cabal does indeed pass these things to the shell, I blame the reviewers who accepted that PR |