2024/09/22

Newest at the top

2024-09-23 00:21:02 +0200 <sm> that sounds good, and/or a ghc bug asking for the script to be updated for latest ghc
2024-09-23 00:18:13 +0200 <gwern> anyway so I guess I should file a ubuntu bug for the ghc package asking for the existing ghc.bash to be installed appropriately?
2024-09-23 00:17:46 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-23 00:15:33 +0200joeyadams(~joeyadams@syn-184-054-105-097.res.spectrum.com) (Quit: Leaving)
2024-09-22 23:53:37 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-09-22 23:50:41 +0200uli-fem(~uli-fem@user/uli-fem) (Ping timeout: 248 seconds)
2024-09-22 23:48:20 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-22 23:38:24 +0200athan(~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!)
2024-09-22 23:37:29 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-09-22 23:32:33 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-22 23:24:46 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-09-22 23:21:44 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds)
2024-09-22 23:16:47 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-22 23:08:00 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-09-22 23:03:07 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-22 23:01:24 +0200 <haskellbridge> <sm> it also gets more complicated if you want your tool to run external exes as subcommands, as recent cabal does
2024-09-22 23:00:18 +0200 <haskellbridge> <sm> I think that kind of position sensitivity in clis is uncommon because it requires custom logic (or more flexibility than exists in the vast majority of parsing libs)
2024-09-22 22:57:08 +0200 <tomsmeding> `cabal run foo xyz` does run `foo xyz`
2024-09-22 22:57:01 +0200 <tomsmeding> it's not what cabal does, for better or for worse
2024-09-22 22:56:29 +0200 <gwern> (ie. 'cabal run --option foo' obviously means that '--option' is for 'cabal run' and not for 'foo', and so 'cabal run --option1 foo --option2' is not ambiguous and doesn't need any guarding)
2024-09-22 22:55:57 +0200 <haskellbridge> <sm> gwern: that's a possible convention, but would be surprising to some people. Robust command line processing is quite hard
2024-09-22 22:55:42 +0200 <gwern> a wrapper like that doesn't usually *need* the ' -- ' guard
2024-09-22 22:55:40 +0200 <tomsmeding> it also takes them after the executable name -- not sure why
2024-09-22 22:55:17 +0200 <gwern> just sounds odd. I would expect cabal run to only take its options if they came before 'foo', or before 'run' even
2024-09-22 22:54:52 +0200 <tomsmeding> I mean, even if that did work, that wouldn't make fish's completion any more functional :p
2024-09-22 22:54:25 +0200 <gwern> `cabal run foo --abc` doesn't automatically turn that into running `foo --abc`?
2024-09-22 22:54:23 +0200 <haskellbridge> <sm> when I want to run anything in the context of a project's package environment, I'm doing stack exec -- ... or cabal exec -- ...
2024-09-22 22:54:17 +0200 <tomsmeding> `cabal run` takes an executable name (to build and run) and, after `--`, arguments to said executable
2024-09-22 22:53:53 +0200 <tomsmeding> gwern: just to pass arguments to the program I'm `cabal run`ing
2024-09-22 22:53:41 +0200 <gwern> what unsafe arguments do you need ' -- ' for?
2024-09-22 22:53:15 +0200 <haskellbridge> <sm> -- is important
2024-09-22 22:53:00 +0200 <haskellbridge> <sm> oh that's annoying
2024-09-22 22:52:49 +0200 <tomsmeding> (fish's cabal completion script doesn't understand '--' meaning that I get negative utility when passing arguments to 'cabal run something -- ...', and I hate it, but not quite enough to go and fix it)
2024-09-22 22:52:34 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds)
2024-09-22 22:52:07 +0200 <tomsmeding> (in the cases where the completion script is overly restrictive)
2024-09-22 22:51:52 +0200 <tomsmeding> I always find it incredibly annoying if some completion script decides for me that it will only complete certain kinds of things for me, meaning that I don't even get a list reminding me of the full thing to type -- I actually have to bail out, `ls`, and type if over
2024-09-22 22:51:48 +0200 <haskellbridge> <sm> completion scripts can be smart about such things
2024-09-22 22:51:10 +0200 <tomsmeding> mind that some options to ghc(i) do take non-.hs files, such as ghci -ghci-script
2024-09-22 22:49:56 +0200 <haskellbridge> <sm> sounds like a good addition to ghc.bash
2024-09-22 22:49:50 +0200 <haskellbridge> <sm> s/and especially ghc contributors//
2024-09-22 22:49:38 +0200 <tomsmeding> and if they are, it's for small examples where dumb tab completion is more than sufficient
2024-09-22 22:49:37 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-09-22 22:49:12 +0200 <haskellbridge> <sm> I think a lot of haskellers and especially ghc contributors are not often running "ghc" directly
2024-09-22 22:48:39 +0200 <gwern> (gwern.net has gotten kinda complicated in terms of tooling and libraries)
2024-09-22 22:48:22 +0200 <gwern> and the more hs files you have, the worse it gets since it's multiplicative: a .o and .hi for every .hs, or worse, in my case because I have a bunch of php, python, and bash scripts which also get picked up by the tab-completion...
2024-09-22 22:47:32 +0200 <haskellbridge> <sm> yes I see, you have to type all of "foo"
2024-09-22 22:47:20 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-22 22:47:10 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-09-22 22:46:27 +0200 <gwern> then you have to cycle through the wrong ones
2024-09-22 22:45:52 +0200 <haskellbridge> <sm> and excluding wrong file extensions is another use I hadn't thought of. I would tend to just type "ghc foo" omitting the extension