Newest at the top
| 2025-05-04 21:52:04 +0200 | <haskellbridge> | <sm> well a runghc shebang script could pass ghc opts to runghc |
| 2025-05-04 21:51:43 +0200 | <haskellbridge> | <sm> but if you want people to write scripts using your lib easily.. then no |
| 2025-05-04 21:51:40 +0200 | <hellwolf> | cabal, or stack has, I know of. |
| 2025-05-04 21:51:35 +0200 | <hellwolf> | runghc has script header too? |
| 2025-05-04 21:51:28 +0200 | <hellwolf> | that's right |
| 2025-05-04 21:51:15 +0200 | <haskellbridge> | <sm> though you could specify them in the script header too I expect |
| 2025-05-04 21:51:06 +0200 | <hellwolf> | though, I do have a few to list beyond GHC2024 :D |
| 2025-05-04 21:50:37 +0200 | <hellwolf> | I learned that now. |
| 2025-05-04 21:50:30 +0200 | <haskellbridge> | <sm> more verbosity.. but more robust |
| 2025-05-04 21:50:30 +0200 | rvalue- | rvalue |
| 2025-05-04 21:50:07 +0200 | <haskellbridge> | <sm> that's why a lot of people write them in the modules |
| 2025-05-04 21:49:27 +0200 | <hellwolf> | gosh, side effect of relying on build system to list default extensions. |
| 2025-05-04 21:49:11 +0200 | <hellwolf> | I tried runghc: it has one other problem, I listed some defaultr extensions in cabal file :D |
| 2025-05-04 21:49:02 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e71c4f52d4f1201e65d300bb.dip0.t-ipconnect.de) acidjnk |
| 2025-05-04 21:48:40 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e71c4f524d98fe298d45bbdf.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2025-05-04 21:46:12 +0200 | <haskellbridge> | <sm> yes, you can add the --system-ghc and --no-install-ghc flags |
| 2025-05-04 21:46:03 +0200 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) (Quit: Client closed) |
| 2025-05-04 21:45:18 +0200 | <tomsmeding> | sm: can you also put `system-ghc: True` in a stack script somehow, so that it uses GHCup's GHC? |
| 2025-05-04 21:44:54 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 260 seconds) |
| 2025-05-04 21:44:45 +0200 | <hellwolf> | but you said no stack.yml needed, hmm |
| 2025-05-04 21:44:12 +0200 | <hellwolf> | *two |
| 2025-05-04 21:44:03 +0200 | <hellwolf> | sm: thanks for the tips... I am just wary of having to maintain to build system. |
| 2025-05-04 21:43:58 +0200 | <tomsmeding> | hellwolf: geekosaur's suggestion of `cabal install --lib --package-env=. ...` sounds like the least-friction approach with cabal, maybe |
| 2025-05-04 21:43:46 +0200 | rvalue- | (~rvalue@user/rvalue) rvalue |
| 2025-05-04 21:43:36 +0200 | <haskellbridge> | <sm> just to be clear hellwolf, and of course use what you prefer: a stack script doesn't require "configuring stack", eg no stack.yaml needed |
| 2025-05-04 21:43:30 +0200 | <hellwolf> | maybe I should really do that, for now. |
| 2025-05-04 21:43:12 +0200 | <hellwolf> | I know how to run raw ghc with --package-db... |
| 2025-05-04 21:42:45 +0200 | <hellwolf> | Easy said than done, due to time. I go to zurihac pre event though, hopefully I can learn from some people to bootstrap Cabal contribution there. |
| 2025-05-04 21:42:19 +0200 | <geekosaur> | meanwhile the only quickfix I can think of is `cabal install --lib --package-env=. <dependencies of script>`, then `runghc script.hs` shopuld work in that directory |
| 2025-05-04 21:42:13 +0200 | <hellwolf> | I cannot. But now I learned enough of how these works, after setting up my own customized haskell playground instances, I think I can manage. But maybe I should contribute to Cabal so more people can benefit. |
| 2025-05-04 21:41:26 +0200 | <haskellbridge> | <sm> I guess you can't use a simple runhaskell script because you want to depend on packages |
| 2025-05-04 21:41:21 +0200 | <haskellbridge> | <sm> stack is easy |
| 2025-05-04 21:41:15 +0200 | <geekosaur> | might put up a cabal issue then |
| 2025-05-04 21:41:06 +0200 | <hellwolf> | But my project is too big and I haven't configured stack :/ |
| 2025-05-04 21:40:50 +0200 | <hellwolf> | I remember that behaviour of stack, I really like |
| 2025-05-04 21:39:10 +0200 | <haskellbridge> | <sm> 👍️ |
| 2025-05-04 21:38:34 +0200 | <geekosaur> | sm, it's not explicitly stated but look for "The executable is cached…" |
| 2025-05-04 21:38:31 +0200 | <haskellbridge> | <sm> a stack script will run interpreted by default, unless you add --compile |
| 2025-05-04 21:38:04 +0200 | <hellwolf> | though, repl maybe is -O0, it might be a bit slower to compile at some point. Currently, compiling the target binary itself seems the slow one. |
| 2025-05-04 21:37:41 +0200 | Arpad | (~Arpad@2a02:ab88:38d:4700::b0d5) |
| 2025-05-04 21:37:31 +0200 | <haskellbridge> | <sm> geekosaur I believe you, but it's not mentioned at https://cabal.readthedocs.io/en/latest/cabal-commands.html#cabal-run |
| 2025-05-04 21:37:01 +0200 | <hellwolf> | and it seems slower than just repl it. |
| 2025-05-04 21:36:53 +0200 | <hellwolf> | so, this is the context: for my edsl project, compiling to a binary seems unnecessary, since all it does is to spit out the code once to the stdout. |
| 2025-05-04 21:36:21 +0200 | <geekosaur> | I don't thinlk there's a reasonable way to make runghc work for this |
| 2025-05-04 21:36:21 +0200 | <monochrom> | Even for .cabal/packages too. |
| 2025-05-04 21:36:00 +0200 | <geekosaur> | echo :main (args, if needed) | cabal repl --repl-args Foo.hs |
| 2025-05-04 21:35:34 +0200 | <monochrom> | Oh I add some commands in my .profile to clean out that. Because I already need that for my $HOME/tmp and $HOME/Downloads |
| 2025-05-04 21:35:22 +0200 | <hellwolf> | shall I do unix way "echo main" | cabal repl? |
| 2025-05-04 21:35:18 +0200 | <geekosaur> | not easily, I think |
| 2025-05-04 21:34:57 +0200 | <hellwolf> | can I specify entry point for a "cabal repl" session to emulate that? |