On Mon, Sep 26, 2011 at 12:49 PM, Reini Urban <rur...@x-ray.at> wrote:
> 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.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.
>
