queued GHCi commands are not resume context specific
I think it is a bug that the second part (:continue
) of the command :cmd return "rv\n:continue"
is executed in a different context than the first part (rv (request for the value of rv variable)). Notice that we did not stop at breakpoint 1 (line 7). Well, the stop happened but it continued immediately because of queued :continue
command. But the command was queued in the context of breakpoint 0 and not breakpoint 1.
status:0 peter@metod [716] ~/tmp
% grep -n '^' b.hs
1:fn :: Int -> Int
2:fn x =
3: let rv = add x 1 in
4: rv
5:
6:add :: Int -> Int -> Int
7:add a b = a + b
status:0 peter@metod [717] ~/tmp
% ghci b.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( b.hs, interpreted )
Ok, modules loaded: Main.
*Main> :set stop :list
*Main> :break 4
Breakpoint 0 activated at b.hs:4:2-3
*Main> :break 7
Breakpoint 1 activated at b.hs:7:0-14
*Main> fn 100
Stopped at b.hs:4:2-3
_result :: Int = _
rv :: Int = _
3 let rv = add x 1 in
4 rv
5
[b.hs:4:2-3] *Main> :cmd return "rv\n:continue"
Stopped at b.hs:7:0-14
_result :: Int = _
6 add :: Int -> Int -> Int
7 add a b = a + b
8
101
[b.hs:4:2-3] *Main> :continue
101
*Main> :q
Leaving GHCi.
status:0 peter@metod [718] ~/tmp
%
The log was done with 6.10.1 but it is the same with 6.10.3.[[BR]] I posted about this to the ghc users list about 2 months ago but nobody responded. My guess is nobody minds either way since nobody scripts breakpoints. At least it would be fine to know whether a patch fixing this has a chance to be accepted.
Trac metadata
Trac field | Value |
---|---|
Version | 6.10.3 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | GHCi |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |