Pre announcement of yet another Perl debugger
Rocky Bernstein
Perl.
Perl has always had a really good debugger, so said above, I undertook this
with some hesitation.
As someone who doesn't always work in Perl, the stock Perl debugger,
perl5db.pl has always felt to me a little bit of a one off.
For example, I can't think of another debugger that uses T to show a
backtrace, and backtraces in debuggers usually include the point where one
is stopped. The fact that there are no frame switching commands (in gdb:
"up", "down", and "frame") may be related to the fact that evaluation in
Perl's debugger works only on the top-most frame. But even given this, I
think this not having frame switching commands is a misguided decision since
frame switching is also useful for things like setting breakpoints or
listing code.
So one motivation for writing a debugger (or rewriting per5db or porting the
Ruby trepanning debugger - take your pick) was to provide more gdb-like
commands. Another goal was to have something a little more modular and
testable. And a third was to provide some of the things I think are cool in
the trepanning debugger that I think are lacking in perl5db.
Although the work is far from complete, already there are things in there I
think cool. For example code is syntax highlighted
via Syntax::Highlight::Perl::Improved. (I haven't put in the "list" command
though.) There is Readline debugger command completion. One of the cool
kinds of completion is on the "eval" command where the current line of
source will be filled in. There is an eval? command which I've found useful
in stripping off common expression parts of a statement. For example eval?
of "return foo(a,b,c)" would be foo(a,b,c). Or eval? of "my $x=foo(a,b,c)"
would be evaluate "$x = foo(a,b,c)"; eval? of "if ($x > 5) {" would be
"($x > 5)". And so on.
When something is evaluated the return value is saved in a global array in
the DB namespace.
Since eval context determines how something is evaluated, there are commands
for evaluating an expression either in a hash, array and scalar context.
(See eval@ eval$ and eval% with command aliases @, $ and %).
The way the code is currently structured, commands reside in a "command"
directory and each command is a file/module in that directory. Given this,
it's possible for users to add their own commands in a user command
directory. And although I don't intend on doing this, it would be possible
to just redo the existing perl5db commands using the Trepanning command
framework. The advantage here is that commands would be included in command
completion and documented in the help system. Oh, did I mention that rather
extensive help is available for each command, and that you can list
categories of commands as is done in gdb?
Ok. Enough advertising. The code resides on github right now in
https://github.com/rocky/Perl-Devel-Trepan. It'll make its way to CPAN as a
package at some point. There are still a number of things to add before
general release, but so far what needs adding is just SMOP (small matter of
programming): code and tests to be ported from the Ruby trepanning debugger
or adapted from perl5db.
Rocky Bernstein
> You are a hero.
>
Thanks for the kind words, but, no, really you guys are. Coming back to Perl
from Ruby (via Python) I have come to appreciate how much of the greatness
of Ruby was in fact there in Perl. (Example: in Perl, like Ruby but as
opposed to Python one can "reopen" classes not just by eval'ing strings but
also by having the same packages named in many files. And on the other hand
one can put many packages inside a single file. All of this facilitates
aspect-oriented programming.)
> Much appreciated. I'll look into adding the SMOP.
>
I would really appreciate that. My Perl style still has a bit to be desired
and I am sure the command code could be DRY'd (Do not Repeat Yourself) a lot
more.
In reviewing the current state of debuggers in Perl, I was looking at the
B-Debugger. At run-time, is there a way one can figure out exactly where one
is in the parse or evaluation tree? I think it would be neat to be able to
report, on demand, where one is evaluation tree. Because that is much more
precise than a file and line number where, among other things, there can be
many statements on a single line.
On Sep 25, 2011 11:22 PM, "Rocky Bernstein" <rocky.b...@gmail.com>
wrote:
