Newest at the top
| 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 |
| 2025-05-04 21:30:34 +0200 | <haskellbridge> | <sm> a cabal script does that I think |
| 2025-05-04 21:25:45 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-05-04 21:25:07 +0200 | <hellwolf> | I might have asked, but I can're call. Can you use cabal to run a Main module in interpretation mode, as opposed to compiling it? |
| 2025-05-04 21:18:44 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 245 seconds) |
| 2025-05-04 21:12:20 +0200 | califax | (~califax@user/califx) califx |
| 2025-05-04 21:12:06 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-05-04 21:07:38 +0200 | ljdarj1 | ljdarj |
| 2025-05-04 21:07:38 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-05-04 21:04:26 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-05-04 21:00:43 +0200 | caconym7 | (~caconym@user/caconym) caconym |
| 2025-05-04 21:00:18 +0200 | <int-e> | (I don't know, but it's not obvious where the speedup would come from when rediscovering the path to the leaf to update is a bunch of machine word comparisons. Building up and repeatedly invoking an a -> Seq a function isn't totally free either) |
| 2025-05-04 21:00:02 +0200 | caconym7 | (~caconym@user/caconym) (Quit: bye) |
| 2025-05-04 20:58:23 +0200 | <int-e> | (I'm still unconvinced that you can get a meaningful speedup over this naive implementation.) |
| 2025-05-04 20:57:23 +0200 | <monochrom> | Unified: There is 1 kind of library: n people use the library and n people complain about it. >:) |