GHCi debugger tasks

I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these.

easy

moderate

• :force should catch exceptions, so [1,2,undefined] would display as [1,2,< exception >]
• show variables with unboxed types.
• tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh)

unknown, or require thinking about

• Some kind of "step over" or "next" command is needed.

• perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get thrown away by :continue)

• Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way.

• When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this be fixed?

• threads and breakpoints.

• It's a bit strange that in "f = e" you don't get a breakpoint covering the whole binding, but in "f x = e" you do.

changed milestone to %6.10 branch

changed weight to 5

added GHCi Ttask Trac import labels

mentioned in issue #1379

changed the description

changed the description

removing a couple of items that are done or have other tickets.

Trac metadata

Trac field	Value
Architecture	Unknown → Unknown/Multiple

Trac metadata

Trac field	Value
Operating system	Unknown → Unknown/Multiple

Some ideas:

• Some kind of step over or next...[[BR]]

Isn't :steplocal or :stepmodule it? Looks like already done.

• We can disable a breakpoint with...[[BR]]

A breakpoint which has a code attached to it should not print anything not printed by the attached code. Well, except the command prompt printed if the attached code does not issue :continue. This would be handy. I asked for it also in my comment to #2737. If this is not done then custom implementation of features like conditional breakpoint or breakpoint setup solely to monitor value changes (an alternative to printf debugging) spit out a lot of garbage. The garbage can be suppressed but that suppresses also the legitimate program output. If you implement this then implementing flag for disabling breakpoints (a point later on) is not needed.

• if a :force results in a breakpoint...[[BR]]

:force hitting a breakpoint should either print more information about the breakpoint or it should not print anything at all. The current situation is the worst one (it does something in the middle :) ). See also #2950 (closed). Anyway, I like the fact that :force does not stop at breakpoints. This ticket #2946 is related to :force too.

* Some kind of step over or next...[[BR]] Now I see what was meant. It can be achieved with something like :cmd return "_result\n:step". Though I do not have any workaround for step out (would require dynamic stack?).

Attached file noBreakInfo.patch (download).

patch: do not print anything to stdout when stopping at a breakpoint with custom code defined

Thanks for the patch Peter, I'll push it as soon as I run validate on it

assigned to @trac-igloo

Validated and pushed

Sun Feb 22 20:55:51 CET 2009  Peter Hercek <phercek@gmail.com>
  * Do not print anything to stdout when stopping at a breakpoint with custom code attached

Ian, this patch can be merged to 6.10, but do not close the ticket yet.

assigned to @trac-mnislaih and unassigned @trac-igloo

Merged.

changed milestone to %6.12 branch

changed milestone to %6.12.3

removed milestone

changed weight to 3

Trac metadata

Trac field	Value
Priority	normal → low

changed milestone to %7.0.2

changed milestone to %7.2.1

changed milestone to %7.4.1

changed milestone to %7.6.1

changed weight to 0

Trac metadata

Trac field	Value
Priority	low → lowest

changed milestone to %7.6.2

See also #1379.

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure

changed milestone to %7.10.1

Moving to 7.10.1.

removed milestone

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

changed milestone to %8.0.1

Milestone renamed

added debugger label

added Plow label

changed the description

I removed the following 2 items from the ticket:

We can disable a breakpoint with ":set stop N :continue", but this still prints out the breakpoint info when we stop. Should we print the info only if there were no commands?

Flag to disable breakpoints?

Reason: With the implementation of the 2 commands :enable and :disable (see #2215 (closed)) both requests are implemented. GHC version 8.10.1

removed milestone

changed the description

I removed the entry

• for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us show the enclosing binding(s) for each breakpoint in the UI (eg. "Stopped in M.f (M.hs:40:23-28)").

Reason: Obviously this has been implemented a long time ago between GHC 7.10.3 and GHC 8.0.1

GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
[1 of 2] Compiling T3000S           ( T3000S.hs, interpreted )
[2 of 2] Compiling Main             ( T3000.hs, interpreted )
Ok, modules loaded: T3000S, Main.
*Main> :break T3000S 7
Breakpoint 0 activated at T3000S.hs:7:18-36
*Main> main
 Stopped at T3000S.hs:7:18-36

GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/roland/.ghci
[1 of 2] Compiling T3000S           ( T3000S.hs, interpreted )
[2 of 2] Compiling Main             ( T3000.hs, interpreted )
Ok, modules loaded: T3000S, Main.
*Main> :break T3000S 7
Breakpoint 0 activated at T3000S.hs:7:18-36
*Main> main
 Stopped in T3000S.sshow.nest, T3000S.hs:7:18-36

Compare Stopped at T3000S.hs:7:18-36 vs Stopped in T3000S.sshow.nest, T3000S.hs:7:18-36

changed the description

I removed the entry:

if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get "*** Ignoring breakpoint").

Reason:

After the implementation of #2950 (closed) (!2143 (merged)) in GHCi >= 8.12.1 we have the following situation:

• The :force command really does what the user requests: It forces the value! It also shows which breakpoints were hit during the :force operation eg *** Ignoring breakpoint [T2950M.hs:4:26-35]

• If the user wants the system to stop at the next breakpoint, (s)he can just do an evaluation instead of a :force.

changed the description

I removed the entry

• Autocompletion for :break only provides names, not modules

Reason:

The fixes for #17989 (closed) (!3042 (closed)) and #3000 (closed) (!3268 (closed)) provide this feature.