Newest at the top
2025-05-04 21:54:32 +0200 | <hellwolf> | EOF |
2025-05-04 21:54:31 +0200 | <hellwolf> | runyol.cabal |
2025-05-04 21:54:31 +0200 | <hellwolf> | $cabal_path |
2025-05-04 21:54:31 +0200 | <hellwolf> | packages: |
2025-05-04 21:54:31 +0200 | <hellwolf> | package-dbs: clear, global, ${cabal_package_db}, ${yolc_package_db} |
2025-05-04 21:54:31 +0200 | <hellwolf> | cat <<EOF |
2025-05-04 21:53:32 +0200 | <haskellbridge> | <sm> plus, I think relying on hidden package environment files will suck |
2025-05-04 21:52:57 +0200 | <haskellbridge> | <sm> though, that's a pain because it varies between linux / mac / freebsd, whether env -S is required in the shebang line |
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. |