Newest at the top
| 2025-01-08 20:02:30 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2025-01-08 19:56:21 +0100 | Guest20 | (~Guest20@136.158.16.131) () |
| 2025-01-08 19:56:11 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-01-08 19:55:53 +0100 | Guest20 | (~Guest20@136.158.16.131) |
| 2025-01-08 19:51:53 +0100 | <mari41300> | well does not sound wrong but not sure whether the structure of the cabal file could affect compilation in the interpreter. I would be surprised |
| 2025-01-08 19:48:05 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-01-08 19:46:43 +0100 | <smiesner> | maybe that's the wrong way? |
| 2025-01-08 19:46:33 +0100 | <smiesner> | i list Lexer and Parser (as i named the modules) in exposed-modules of the library in my cabal file |
| 2025-01-08 19:45:40 +0100 | <mari41300> | hmm single package then |
| 2025-01-08 19:45:39 +0100 | <smiesner> | :r does not rebuild the parsers |
| 2025-01-08 19:45:18 +0100 | <smiesner> | my project? so far only happy and alex files :) |
| 2025-01-08 19:44:40 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:9be8:50a:7d0a:fa49) fun-safe-math |
| 2025-01-08 19:44:21 +0100 | <mari41300> | not sure, i think recompiling worked fine for me when i had the chance to leverage the repl. Maybe a complex project with multiple packages? |
| 2025-01-08 19:43:09 +0100 | <mari41300> | meh |
| 2025-01-08 19:43:02 +0100 | <smiesner> | nope.. |
| 2025-01-08 19:41:11 +0100 | mari41300 | crosses fingers |
| 2025-01-08 19:40:47 +0100 | <smiesner> | maybe its :l Parser again |
| 2025-01-08 19:40:41 +0100 | <smiesner> | ah but wait |
| 2025-01-08 19:40:03 +0100 | <smiesner> | sadly no |
| 2025-01-08 19:39:57 +0100 | <mari41300> | huh, :r not enough, i guess |
| 2025-01-08 19:39:23 +0100 | <smiesner> | i have to use cabal build, cabal repl, :l Parser all the time |
| 2025-01-08 19:38:51 +0100 | <smiesner> | does anyone have a tip how i can use cabal repl effectively with happy and alex? how can i regenerate .hs files, build and reload? |
| 2025-01-08 19:38:42 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:25c5:ab3d:d3f4:6796) (Ping timeout: 246 seconds) |
| 2025-01-08 19:35:21 +0100 | mari-estel | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 2025-01-08 19:34:57 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-01-08 19:34:57 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 276 seconds) |
| 2025-01-08 19:33:58 +0100 | mari41300 | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 19:33:10 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-01-08 19:26:38 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 19:22:01 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-08 19:19:29 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-01-08 19:16:19 +0100 | plitter | (~plitter@user/plitter) (Ping timeout: 264 seconds) |
| 2025-01-08 19:14:08 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-01-08 19:05:30 +0100 | sprotte24 | (~sprotte24@p200300d16f1e660091235e642331973a.dip0.t-ipconnect.de) |
| 2025-01-08 19:03:47 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) |
| 2025-01-08 18:58:43 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-01-08 18:49:54 +0100 | <int-e> | But also because the ghc-pkg wrapper script sets a bunch of paths that are hard to figure out otherwise. |
| 2025-01-08 18:49:07 +0100 | <int-e> | geekosaur: I guess partly because the Cabal versions used may be different. |
| 2025-01-08 18:48:19 +0100 | <int-e> | geekosaur: I don't think that's correct. Yes, ghc-pkg uses (parts of) the Cabal library. But it's still invoked by Cabal or at least cabal-install anyway. |
| 2025-01-08 18:47:48 +0100 | <int-e> | There's also some baked-in paths here: ghc --print-global-package-db |
| 2025-01-08 18:45:41 +0100 | <hseg> | OK, I don't quite follow, but that's as deep as I can afford to go down this rabbit hole right now |
| 2025-01-08 18:43:22 +0100 | <geekosaur> | that si, ghc-pkg is a wrapper around the Cabal library's package db management |
| 2025-01-08 18:43:00 +0100 | <geekosaur> | that said, it does not use ghc-pkg because it *is* ghc-pkg |
| 2025-01-08 18:42:54 +0100 | <int-e> | well using System.Process |
| 2025-01-08 18:42:47 +0100 | <geekosaur> | it runs a lot of external programs, actually |
| 2025-01-08 18:42:06 +0100 | <hseg> | what, with system("ghc-pkg ...")? I doubt that |
| 2025-01-08 18:41:32 +0100 | <int-e> | I'm pretty sure the Cabal library interrogates ghc-pkg too. |
| 2025-01-08 18:40:56 +0100 | <hseg> | cabal-plan needs to be able to find the Cabal store |
| 2025-01-08 18:40:43 +0100 | <hseg> | no, I meant from within haskell source |
| 2025-01-08 18:40:43 +0100 | <geekosaur> | if you want the file, ghc --print-global-package-db |