You are a hero. Much appreciated. I'll look into adding the SMOP.
On Sep 25, 2011 11:22 PM, "Rocky Bernstein" <rocky.bernst...@gmail.com>
wrote:
> With much trepidation, recently I started porting my trepanning debugger
to
> 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.
