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: http://funcall.blogspot.com/2011/03/tail-recursion-and-debugging.html 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 recursions.) 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 this debugger. * 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.
