As Shrek says when he first entered Duloc: ``It's quiet here... Too quiet!''
A little while ago I asked if there was a way get get some sort of object
which indicates the exact position from caller. Again, line number doesn't
really cut it since there can be many statements on a line.
I just ran across this very amusing blog:
As a result, in a couple of the Ruby trepanning debuggers I now detect
immediate recursion and instead of repeating those lines over and over
again I give a count of the repetitions. (I still should handle indirect
More generally, it would be nice if the various packages that print stack
traces as well as those inside Perl core detect recursion and try to reduce
duplication of long traces by giving such summary information.
However in order to do this one really does need a more precise location
than that which caller gives. I could give an example here of how line
number isn't precise, but I suspect you all get the idea.
- - - -
Last, in the interest of creating more noise. Let me say I've now put on
CPAN the first version of Devel::Trepan. As before, there is still an awful
lot that could be done and I think is straightforward to add.
The release is good enough for me to use, and I tend to be a little bit
more fussy than most when it comes to debugging. The amount of additional
work I put on this will probably be determined by interest and my needs.
So in closing I'll mention a couple more interesting and unique things in
* POSIX style set -x tracing. On occasion people tell me that they don't
want a debugger all they want is POSIX-style tracing. So that's there now.
You have this turned on from the start and not enter the debugger or you
can turn it on inside the debugger and then run "continue".
* In passing I previously mention in the last post command aliases. For
complicated things one can create a macro which is simply an anonymous Perl
subroutine. Simple, powerful and Perl!
* There is a settings "set timer on" which will tell you the elapsed time
between debugger entry. I have used that in the past to give me a feel for
the difference in speed between "step over", "finish" and "continue", but
one could also use it to measure the time the debugged program takes.
* Entering Psh. In Python and Ruby folks typically want to enter a shell
rather than have to work within the confines of the debugger shell. If you
want to enter Psh inside the debugger you can. If there are other shells,
especially ones that allow themselves to be embedded, I don't mind adding
more. In fact, I had to monkey patch Psh to get it to embed. The one
caveat with going into a shell is the name scoping problem. You generally
don't see "my" variables. However inside the debugger whenever you evaluate
an expression it gets saved in the global @DB::D array. So inside the
debugger before entering Psh one could evaluate variables that you might
want to use.