#1377: GHCi debugger tasks
---------------------------------+------------------------------------------
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: normal | Milestone: 6.10 branch
Component: GHCi | Version: 6.7
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Changes (by phercek):
* cc: [email protected] (added)
Comment:
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.
Anyway, I like the fact that :force does not stop at breakpoints. This
ticket #2946 is related to :force too.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1377#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
