Simon Marlow wrote:
Claus Reinke wrote:
Perhaps someone could help me to understand how the debugger is
supposed to be used, as I tend to have this problem, too:
- when I'm at a break point, I'd really like to see the current scope
or, if that is too expensive, the next enclosing scope, in full
(not only would that tell me what instantiation of my code I'm in,
it would also seem necessary if I want to reconstruct what the
current expression is)
I don't understand what you mean here - surely in order to "reconstruct
what the current expression is" you only need to know the values of the
free variables of that expression? Also I don't understand what you
mean by the "next enclosing scope". Could you give an example?
Maybe what Claus means is that he would like to see the dynamic
stack and be able to traverse it and at each location in the
dynamic stack he could investigate the free variables in the
expression (corresponding to the dynamic stack slot). I actually
considered this as a feature request but I decided that I would
like to have this implemented sooner:
http://hackage.haskell.org/trac/ghc/ticket/2737
Currently, I only use the debugger rarely, and almost always have to
switch to trace/etc to pin down what it is hinting at. What is the
intended usage pattern that makes the debugger more effective/
convenient than trace/etc, and usable without resorting to the latter?
Set a breakpoint on an expression that has the variable you're
interested in free, and display its value. If your variable isn't free
in the expression you want to set a breakpoint on, then you can add a
dummy reference to it.
Actually I use it a bit differently mostly because I know
(or I'm guessing) where the bug is located and set a breakpoint
at a place which is hit just after the wrong decision happens.
The "just after wrong decision" requirement is there so that
I do not need to have too complicated expressions in the
conditional breakpoint. Then I count how many times the
breakpoint is hit of find some other expression which is
true just before the hit I'm interested in (the hit with bug).
I modify the script of the breakpoint so that it stops just
before the hit I'm iterested in and restart. After restart
the debugger stops at the modified breakpoint and I continue
with either :steplocal or :trace. This is so that I have
values of previous expressions in the trace history. Then
(If I used :trace) I check the values in the trace history
to find out why I got at the wrong place.
The procedure is quite complicated but I do not know about
quicker way to position the debugger at the right place
and with the right variable values caught in the trace
history.
If I would not know the approximate location of the bug
then hpc can help.
For more simple things "printf debugging" is just enough.
Peter.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
