Newest at the top
| 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? |
| 2025-05-04 21:34:44 +0200 | <hellwolf> | 30 |
| 2025-05-04 21:34:44 +0200 | <hellwolf> | ls ~/.cabal/script-builds/| wc -l |
| 2025-05-04 21:34:44 +0200 | <hellwolf> | no, not acceptable because it litters: |
| 2025-05-04 21:34:43 +0200 | <geekosaur> | --repl-options? |
| 2025-05-04 21:34:35 +0200 | <[exa]> | is there some kinda -c,--command option for repl? |
| 2025-05-04 21:34:31 +0200 | <geekosaur> | (it was actually added in 3.6 iirc, but it compiled every time; as of 3.8 it compiles only if the script is changed) |
| 2025-05-04 21:34:05 +0200 | <monochrom> | If you truly insist on interpreting, yeah cabal repl |
| 2025-05-04 21:33:56 +0200 | <[exa]> | `echo :main | cabal repl` ? >:) |
| 2025-05-04 21:33:53 +0200 | <haskellbridge> | <sm> 👀 |
| 2025-05-04 21:32:53 +0200 | <geekosaur> | @sm, these days (since cabal 3.8) scripts are compiled, just like stack does |
| 2025-05-04 21:31:33 +0200 | <monochrom> | `cabal run` can run it, but it compiles first. Is that acceptable? |
| 2025-05-04 21:31:14 +0200 | pavonia | (~user@user/siracusa) siracusa |