Newest at the top
| 2024-11-10 22:37:52 +0100 | CoolMa7 | (~CoolMa7@95.91.137.87) CoolMa7 |
| 2024-11-10 22:37:02 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 255 seconds) |
| 2024-11-10 22:34:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-10 22:29:44 +0100 | michalz | (~michalz@185.246.207.221) |
| 2024-11-10 22:24:26 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-11-10 22:23:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-11-10 22:18:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-10 22:14:47 +0100 | tv | (~tv@user/tv) tv |
| 2024-11-10 22:14:05 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 255 seconds) |
| 2024-11-10 22:12:33 +0100 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2024-11-10 22:09:33 +0100 | xdminsy | (~xdminsy@117.147.71.147) (Ping timeout: 265 seconds) |
| 2024-11-10 22:09:22 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-11-10 22:07:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-11-10 22:07:25 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3105-b12d-6cb6-6a29-cc7c-8727.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-10 22:05:25 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 248 seconds) |
| 2024-11-10 22:02:39 +0100 | <geekosaur> | but it doesn't sound like this, it involves Prelude |
| 2024-11-10 22:02:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-11-10 22:02:25 +0100 | <geekosaur> | mm, the manual does mention some ghci magic involving *-modules |
| 2024-11-10 22:02:10 +0100 | <tomsmeding> | I leave that to cabal and HLS people to figure out |
| 2024-11-10 22:01:58 +0100 | <tomsmeding> | I have no clue what's going on with multi-unit stuff :) |
| 2024-11-10 22:01:40 +0100 | <tomsmeding> | I don't think this is a cabal issue |
| 2024-11-10 22:01:29 +0100 | <geekosaur> | ther shenanigans are worse without multi-repl since cabal tries to sort-of simulate it |
| 2024-11-10 22:01:22 +0100 | <haskellbridge> | <sm> ok. |
| 2024-11-10 22:01:13 +0100 | <tomsmeding> | sm: I didn't try, but the behaviour that I dislike with `cabal repl` is completely reproduced with `ghci A.hs B.hs` |
| 2024-11-10 22:00:48 +0100 | <haskellbridge> | <sm> tomsmeding: did you get cabal to show its ghci command ? |
| 2024-11-10 22:00:39 +0100 | <tomsmeding> | (I am aware of the existence of intense shenanigans with multi-unit repls, and I don't want to go there) |
| 2024-11-10 22:00:21 +0100 | <tomsmeding> | so at least for the simple case of multiple modules from the same unit, ghci doesn't seem to have any problems |
| 2024-11-10 21:59:54 +0100 | <tomsmeding> | well `ghci A.hs B.hs` works perfectly well for me! |
| 2024-11-10 21:59:30 +0100 | <tomsmeding> | geekosaur: of course, I ~always go through `cabal repl`, so the discussion about plain ghci is academic and/or to figure out what's really happening underneath |
| 2024-11-10 21:59:29 +0100 | <haskellbridge> | <sm> agreed on complex, ghci's semantics and cabal's are each complicated on their own |
| 2024-11-10 21:59:14 +0100 | <geekosaur> | (trying to make ghci deal nicely with multiple modules when it generally doesn't so much) |
| 2024-11-10 21:58:59 +0100 | xdminsy | (~xdminsy@117.147.71.147) xdminsy |
| 2024-11-10 21:58:57 +0100 | <tomsmeding> | except for this stupid :r behaviour :p |
| 2024-11-10 21:58:52 +0100 | <tomsmeding> | I recall at least skimming the manual on this, and learning about the details of the syntax of `:m` and finding it useful |
| 2024-11-10 21:58:42 +0100 | <geekosaur> | I don't have a lot that doesn't require me to go through `cabal repl` and deal with whatever it's doing, which is moderately complex |
| 2024-11-10 21:58:22 +0100 | <haskellbridge> | <sm> geekosaur what is this witchcraft |
| 2024-11-10 21:57:50 +0100 | <tomsmeding> | int-e: ah, more relevant is `:show imports` |
| 2024-11-10 21:57:39 +0100 | <geekosaur> | I'm not poking ghci, I'm reading the ghci manual |
| 2024-11-10 21:57:33 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-11-10 21:57:04 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-11-10 21:57:03 +0100 | <tomsmeding> | does your ghci differ? |
| 2024-11-10 21:57:00 +0100 | <geekosaur> | I recall the manual being more explicit about this in the past, I think they "simplified" it at some point, to the point of making the details too obscure |
| 2024-11-10 21:56:58 +0100 | <tomsmeding> | well I very clearly see `*A>` in my prompt after `ghci A.hs B.hs`, and I can see names from A but not from B :p |
| 2024-11-10 21:56:33 +0100 | <geekosaur> | I think you'll have to ask #ghc for details at this point |
| 2024-11-10 21:56:19 +0100 | <geekosaur> | wait no, that gives you both, not just `A`. |
| 2024-11-10 21:55:19 +0100 | <geekosaur> | mm, maybe it's `:m` instead |
| 2024-11-10 21:55:13 +0100 | <tomsmeding> | whereas `ghci A.hs B.hs` gives me scope `*A` |
| 2024-11-10 21:54:52 +0100 | <tomsmeding> | geekosaur: not quite `:l A.hs` `:add B.hs`; if I literally type that, I end up with scope `*B` |
| 2024-11-10 21:54:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-10 21:54:32 +0100 | <geekosaur> | maybe #hackage knows |