Newest at the top
| 2025-05-04 22:05:45 +0200 | <int-e> | err, --ghc-arg= |
| 2025-05-04 22:05:33 +0200 | <hellwolf> | let me see if it's faster |
| 2025-05-04 22:05:18 +0200 | <hellwolf> | hurray |
| 2025-05-04 22:05:12 +0200 | <hellwolf> | it worked |
| 2025-05-04 22:05:11 +0200 | <int-e> | does `cabal run` even work for the thing you're testing |
| 2025-05-04 22:05:01 +0200 | <int-e> | runghc will probably need something like runghc -ghc-arg=-i -ghc-arg=exe Main.hs |
| 2025-05-04 22:03:51 +0200 | <hellwolf> | | Internal error when trying to open a repl for the package fake-package-0. The package is not in the set of available targets for the project plan, which would suggest an inconsistency between readTargetSelectors and resolveTargets. |
| 2025-05-04 22:01:20 +0200 | <int-e> | maybe: cabal -v0 repl --repl-options="-e main" |
| 2025-05-04 21:58:10 +0200 | <hellwolf> | didn't work |
| 2025-05-04 21:58:08 +0200 | <hellwolf> | cabal exec runghc runyol |
| 2025-05-04 21:56:58 +0200 | <geekosaur> | cabal exec runghc … ? |
| 2025-05-04 21:56:48 +0200 | <hellwolf> | anyways, feeling like beating a dead horse now, I guess I will have to live with it or do something about it either using stack just for this or fix cabal. |
| 2025-05-04 21:55:45 +0200 | <hellwolf> | *I just want to |
| 2025-05-04 21:55:36 +0200 | <hellwolf> | now that I have that cabal project file, I just run that within a interpretation mode. |
| 2025-05-04 21:55:20 +0200 | Square | (~Square@user/square) Square |
| 2025-05-04 21:54:48 +0200 | <hellwolf> | I create cabal project file and run cabal <-- what I do |
| 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. |