Re: Tmux helps to debug perl fork()s
On Mon, Dec 3, 2012 at 9:06 AM, Peter Vereshagin wrote: > Hello. > > 2012/12/03 08:51:28 -0500 Rocky Bernstein => To Richard > Foley : > RB> Something I think about when I read about things like this whether > there > RB> some sort of unifying principle that could be used in other debuggers > or > RB> for other similar sorts of programs. Is there some support that a > debugger > RB> should be providing to make things like this easier? > > I think it's about a standard for the program interface that majority of > debuggers should follow. > I'm not sure what you mean. Suggest something. > > Debug::Fork::Tmux can redefine some other function (and/or a global > variable) > from another debugger. In this case the feature to implement can be the > 'let > user to tweak a namespace other than DB to inject to'. Very obvious. > Devel::Trepan has lots of non-DB spaces one can tweak to. But again, I am not exactly sure what you mean so it would help if you could be very specific. > > RB> Too often, especially with the venerable Perl debugger, you read about > RB> patch someone has that made that does some interesting thing. Or s a > trick > RB> you can do in order to get something done that is commonly needed. It > feels > RB> less like the "art" but rather knowing about a number of isolated > tricks, > RB> or worse, workarounds that is relevant for one debugger on one > programming > RB> language. > > I don't patch the debugger, sorry. > > When needed, the critical mass of 'isolated tricks and workarounds' can be > collected into one distribution, and documented in details in one place, > can't > them? > > RB> That said, of course, all of this is cool. > > Great. > > My main target with Debug::Fork::Tmux was to make a convinient build > environment, including docs, for better and faster releasing. > > Otherwise the one can use a couple of lines to use Tmux for that same > purpose. > > RB> > Here is an interesting module from Peter Vereshagin which might help > with > RB> > debugging forks under the perl debugger, if you use tmux version 1.6+ > RB> > > RB> > http://search.cpan.org/dist/Debug-Fork-Tmux > > -- > Peter Vereshagin (http://vereshagin.org) pgp: > A0E26627 >
Re: Tmux helps to debug perl fork()s
Something I think about when I read about things like this whether there some sort of unifying principle that could be used in other debuggers or for other similar sorts of programs. Is there some support that a debugger should be providing to make things like this easier? Too often, especially with the venerable Perl debugger, you read about patch someone has that made that does some interesting thing. Or s a trick you can do in order to get something done that is commonly needed. It feels less like the "art" but rather knowing about a number of isolated tricks, or worse, workarounds that is relevant for one debugger on one programming language. That said, of course, all of this is cool. On Mon, Dec 3, 2012 at 4:34 AM, Richard Foley wrote: > Here is an interesting module from Peter Vereshagin which might help with > debugging forks under the perl debugger, if you use tmux version 1.6+ > > http://search.cpan.org/dist/Debug-Fork-Tmux > > -- > Ciao > > Richard Foley > > http://www.rfi.net/books.html > >
Re: What is the history behind the DB module?
On Fri, Sep 14, 2012 at 3:47 AM, Shlomi Fish wrote: > Hi Rocky, > > On Thu, 13 Sep 2012 19:40:53 -0400 > Rocky Bernstein wrote: > > > http://perldoc.perl.org/DB.html mentions a "programmatic interface to > > the Perl debugging API". > > > > As far as I can tell it hasn't really changed at all since Perl 5.8 > > and not much between that and 5.6 except bug fixes. Why was this not > > more widely adopted? > > I guess not too many people need to write custom debuggers. I am weary of arguments of the form because if X isn't used much something that X attempts to address is not needed by too many people. First, from what I've seen there have been a number of "custom debuggers" including a large number of customization of perl5db: for remote execution or handling syntax highlighting. I just became aware of a recent YAPC paper on trying to automatically figure out when an input line in perl5db is not finished so as to offer another read rather than eval the line. And consider dtrace which is popular. From what I understand, that is used for custom tracing which to me amounts to the same thing as debugging. dtrace doesn't sport a REPL although one could probably add that into the callback. Now back to the DB module. Although it may appear to advertise itself as for writing REPL debuggers, it doesn't have to be used that way. So perhaps the DB API module was not advertising itself in not the most encompassing way. One of the ideas that I think is right about the DB module is the fact that programs can register for a callback. Supposedly DB handles all of the lower-level boilerplate DB module stuff. One might imagine registering a callback when various events occur to be something that should be put in the Perl core, but since all of this code can be written in Perl (as evidence by the DB module), why then put it in the Perl core? And finally coming back to the original question, I was hoping that someone who was working on perl5db at the time could elaborate on what specifically happened here, rather than speculatively what might have happened. > Furthermore, it > seems that many Perl developers avoid using the debugger in favour of print > statements and other stuff like that. > > Regards, > > Shlomi Fish > > -- > - > Shlomi Fish http://www.shlomifish.org/ > What Makes Software Apps High Quality - http://shlom.in/sw-quality > > Quark: “Too much of a good thing is a bad thing. But only for your > customers”. > Rule of acquisition No. 172. > — Star Trek, “We, the Living Dead” by Shlomi Fish > > Please reply to list if it's a mailing list post - http://shlom.in/reply . >
Re: Call perl5db or trepan.pl from re.pl
On Sat, Jan 7, 2012 at 11:42 PM (a long while ago), Rocky Bernstein
> - - -
>
> I was looking at perl5db code and noticed that numeric value of @dbline is
> its COP reference. (In trepan.pl "info program" now shows this when it is
> available). I thought this would be a win for being able to more precisely
> indicate where you are and to set breakpoints within lines which have
> multiple statements on them.
>
> Such an example line might be:
>
> if ($x) { $y--; if ($y) { $z += 1 } else { $z -= 1 }; } else { $z = 10 };
>
> If you disassemble via B::Concise, you'll see several COPs for this line.
> However the @dbline entry for that line always seems to be the first COP
> rather than the one that called DB::DB.
>
What I've been looking for is Devel::Callsite
Call perl5db or trepan.pl from re.pl
I recently I've written Devel::REPL plugins to call a trepan or perl5db
debugger from re.pl via Enbugger.
If there are other plugins for this, I'd be interested to compare.
https://github.com/rocky/Perl-Devel-Trepan-Shell has the code.
In my repl.rc load the plugins:
$_REPL->load_plugin('Trepan');
$_REPL->load_plugin('Perl5db');
Then to get into the debugger
%trepan your-code-here
or
%perl5db some-other-code-here
More could be done to better show return values, and there are some
weirdnesses in the trepan plugin when re.pl
is exited, but overall it works.
- - -
I was looking at perl5db code and noticed that numeric value of @dbline is
its COP reference. (In trepan.pl "info program" now shows this when it is
available). I thought this would be a win for being able to more precisely
indicate where you are and to set breakpoints within lines which have
multiple statements on them.
Such an example line might be:
if ($x) { $y--; if ($y) { $z += 1 } else { $z -= 1 }; } else { $z = 10 };
If you disassemble via B::Concise, you'll see several COPs for this line.
However the @dbline entry for that line always seems to be the first COP
rather than the one that called DB::DB.
Re: RFC Devel::Trepan
On Sun, Dec 18, 2011 at 11:42 AM, Rocky Bernstein wrote: > With the recent release of Devel::Trepan (0.1.4), I am at a juncture of > next steps. So I thought I would solicit feedback. ... > Other miscellaneous items: > > - adding history save/restore. Term::ReadLine::Perl doesn't have > StifleHistory and ReadHistory. Perhaps the way to go would be to > add those to Term::ReadLine::Perl > > - Add gdb-like signal handling routines "handle". > Recent releases now have this. Some more shake-down is needed. But in doing this, the lack of evaluating frames other than the top became more apparent. When we enter the debugger's signal handler, the top-most frames are the debugger boilerplate subroutine; those subroutine(s) should be hidden and ignored. Therefore, in preparation of improving evaluation in the signal handler, I added code to do evaluation via PadWalker and Eval::WithLexicals. It's better than nothing, but it is unreliable. So right now I give a warning when this code is used. Given this unreliability and code complication, in my view changes to the Perl Runtime to add eval_n() is the most important thing that will help debugging. Since Devel::Trepan debugger now supports Perl 5.8.8 and greater, I will have to keep the existing ugly mess of code around. But I will also need an alternative (simpler) version using eval_n(). I believe I can isolate existing evaluation code to a single file containing the two namespaces it needs: DB and Devel::Trepan::CmdProcessor. And I will also need some way to select between the two files at install time or run time. > - Making restart better by saving and restoring debugger state. > > - More remote debugging features. >
Re: breakpoint bug in the debugger
At the risk of beating an already dead horse, since setting a breakpoint on a "use" statement is likely to continue to cause confusions like this, I've added a hack in Devel::Trepan to see if the line that a breakpoint has been set at starts with the regexp /^\s*use\s+/. If so, a warning is issued given. The breakpoint is still set - it is just a warning. There are many ways that this heuristic can fail. For example setting a breakpoint on a line with: use English; $x = 3; may "skip" the "use" and still stop on the assignment statement. On Mon, Dec 19, 2011 at 12:20 AM, Rocky Bernstein wrote: > A while back on Tue, 31 May 2011 18:20:51 -0700 Conor wrote: > > Not exactly a high priority bug, but I found that if you set a breakpoint >> on >> a line where a 'use' statement exists, the breakpoint will show as set and >> the debugger won't complain: >> $ perl -d breakpoint-bug.pl >> Loading DB routines from perl5db.pl version 1.32 >> Editor support available. >> Enter h or `h h' for help, or `man perldebug' for more help. >> main::(breakpoint-bug.pl:7): >> 7: print "hello!\n"; >> DB<1> b 9 >> DB<2> v >> 4: use strict; >> 5: use warnings; >> 6 >> 7==> print "hello!\n"; >> 8 >> 9:b use Data::Dumper; >> 10 >> 11: print "goodbye!\n"; >> 12 >> 13: exit 0; >> DB<2> >> But, if you 'c' from line 7, you skip over the breakpoint on 9 as if it >> wasn't there. It isn't a huge problem (and I really should keep all of my >> 'use' statements at the beginning of the script), but I figured it was >> worth >> a mention. >> I couldn't figure out how to actually file a bug at http://rt.perl.organd >> http://search.cpan.org/~jesse/perl-5.14.0/lib/perl5db.pl didn't have the >> usual 'View/Report Bugs' that most modules have. I'm happy to file a bug >> if >> someone could point me in the right direction. >> -Conor > > > I just looked at this. I don't think there is a bug here. > > The code has a "use" statement. A breakpoint is set on that which the > reporter doesn't feel is respected. > However, recall that "use" happens at compile time and this occurs before > the first stop you see in the debugger. > > To verify this when I issued: > $Data::Dumper::VERSION from Devel::Trepan stopped at line 7, I got a > version string, e.g. '2.124'. (in perl5db use "p $Data::Dumper::VERSION" > > Change the "use" to a "require" which then changes the semantics, and > you'll things will work as you seem to expect it to would above. > > So in sum, I don't think there is a bug. Just perhaps confusion about how > execution works -- which I admit is confusing. > > >
Re: breakpoint bug in the debugger
A while back on Tue, 31 May 2011 18:20:51 -0700 Conor wrote: Not exactly a high priority bug, but I found that if you set a breakpoint on > a line where a 'use' statement exists, the breakpoint will show as set and > the debugger won't complain: > $ perl -d breakpoint-bug.pl > Loading DB routines from perl5db.pl version 1.32 > Editor support available. > Enter h or `h h' for help, or `man perldebug' for more help. > main::(breakpoint-bug.pl:7): > 7: print "hello!\n"; > DB<1> b 9 > DB<2> v > 4: use strict; > 5: use warnings; > 6 > 7==> print "hello!\n"; > 8 > 9:b use Data::Dumper; > 10 > 11: print "goodbye!\n"; > 12 > 13: exit 0; > DB<2> > But, if you 'c' from line 7, you skip over the breakpoint on 9 as if it > wasn't there. It isn't a huge problem (and I really should keep all of my > 'use' statements at the beginning of the script), but I figured it was > worth > a mention. > I couldn't figure out how to actually file a bug at http://rt.perl.org and > http://search.cpan.org/~jesse/perl-5.14.0/lib/perl5db.pl didn't have the > usual 'View/Report Bugs' that most modules have. I'm happy to file a bug if > someone could point me in the right direction. > -Conor I just looked at this. I don't think there is a bug here. The code has a "use" statement. A breakpoint is set on that which the reporter doesn't feel is respected. However, recall that "use" happens at compile time and this occurs before the first stop you see in the debugger. To verify this when I issued: $Data::Dumper::VERSION from Devel::Trepan stopped at line 7, I got a version string, e.g. '2.124'. (in perl5db use "p $Data::Dumper::VERSION" Change the "use" to a "require" which then changes the semantics, and you'll things will work as you seem to expect it to would above. So in sum, I don't think there is a bug. Just perhaps confusion about how execution works -- which I admit is confusing.
RFC Devel::Trepan
With the recent release of Devel::Trepan (0.1.4), I am at a juncture of next steps. So I thought I would solicit feedback. The good news from my standpoint is that things are good enough for my needs. And I can be picky. Devel::Trepan has been tested on a number of Unix platforms thanks to CPANTS. And I have tested it on Windows under cygwin, Strawberry and ActiveState Perl. Of course this doesn't mean there is not much that *could* be improved. Originally I had included support to go into an interactive psh shell; that required some monkey-patching of psh. I have request the change get added to psh with no motion or acknowledgement so far. Since psh development seems to be stalled, I've since removed that support. Instead Devel::REPL which seems much better suited. The down side of Devel::REPL is that it pulls in a huge set of other packages, starting with Moose. So to do this, it would be done in a separate add-on package. Speaking of splitting things off as a separate package... Devel::Trepan itself is large and could be split in two possibly with benefit. Part of the effort of writing Devel::Trepan included modularizing and modernizing the DB package a little. So that could be split off. Right now one require's or use's Devel::Trepan::DB. But due to Perl's debugger requirements, it works in the DB namespace. Devel::Trepan::DB would not be a total replacement for perl5db.pl. However if a command part were written, then it could be. The command part I think could be fairly lean. Another direction to move is going backward to allow support for Perl before version 5.10.0. The current code does not fundamentally need 5.10.0. Although I used features from 5.10 like 'state' and 'switch' and //= assignment, the code could be rewritten without that making it a little bit uglier. But I wonder how widespread perl 5.8.x is. And going in the opposite direction, I could start patching Perl to add two features that I think would help debugging. The first change is to add some sort of eval_n where one can eval in the context of a prior call frame. This is would not only obviate the use of Eval::StackTrace::WithLexicals, Devel::StrackTrace::WithLexicals, Peek, and the PadWalker packages but would handle "local" variables. So it would be more reliable. Equally important is that the structure of the debugger could become less convoluted. The other small change would be add to caller() a number indicating the Perl5 Node that is currently under execution. This number can then be used to disambiguate the various places one can be when one is stopped in a given line. I believe this is a pretty simple change to make, but it would mean a change to Perl5 and therefore might take a while, depending on when the next release is scheduled. Other miscellaneous items: - adding history save/restore. Term::ReadLine::Perl doesn't have StifleHistory and ReadHistory. Perhaps the way to go would be to add those to Term::ReadLine::Perl - Add gdb-like signal handling routines "handle". - Making restart better by saving and restoring debugger state. - More remote debugging features.
accelerated stepping from a old thread and Perl changes.
I was looking at old debugger list postings on "accelerated stepping". The general problem of how to make stepping feel right is a well trodden topic. So let me describe how the trepanning debuggers such as Devel::Trepan partially address this. The idea builds on something Kent Sibilev added to ruby-debug, and as far as I know he was the first to do this. There is a setting called "set different" in ruby-debug (originally called "set force") which can be "on" or "off". When "on" the setting causes "next" and "step" commands to stop at a different line numbers for a given frame. The stack frame is used because one wants to treat recursive calls as "different". In the trepanning debuggers, I added "+" and "-" suffixes to the "step" and "next" commands which over-ride the default setting.
Re: PadWalker, eval and perl5db
On Wed, Nov 23, 2011 at 8:06 AM, Brock wrote: > On Sun, 20 Nov 2011 Rocky Bernstein wrote: > > I've briefly looked at PadWalker which can look at "my" and "our" > > variables on a call stack. And while this is very useful, it is not > > the same as being able to evaluate a string in the context of a stack > > frame. > > > > Has anyone tried to create such an eval? A simple suggested interface > > would be to pass it an integer which indicates the call stack frame to > > use. > > You might take a look at Eval::WithLexicals and how it is used in > Plack::Middleware::InteractiveDebugger (which, upon die(), lets the user > open a web-based REPL at any level of the call stack). Looks like there > is some manual work you have to do though. > Thanks! I think I now understand how it's done. Sort of. Devel::StrackTrace::WithLexicals uses PadWalker to create a hash of of all the lexical variables for a given call frame. Eval::WithLexicals is then passed that hash. By the way, this is similar to how Python's eval works. And then comes the complicated part, Eval::WithLexicals uses that hash somehow in a string eval. How this works is not obvious to me, but the next couple of days I'll probably figure this out as I have a good debugger that can track nicely through string evals which is used a bit here. Eval::WithLexicals (and Eval::WithLexicals::WithHintPersistence ) then needs to put changed values back someplace. (Perhaps this id done via B::svref_2object.) So one thing that needs to be checked in my use is that the values do indeed get put back into the right place in the call stack and not just say in the hash created by Devel::StackTrace::WithLexicals. Another thing that seems to be something that could go wrong is in handling local variables, because PadWaker doesn't handle local variables. Suppose I have a local variable $a defined in main and a couple of calls down I have another local $a --alsi in package main::. I am not sure how I would be able to access the outer or main-most $a to read the value. (Actually here is a bad way and one that is sort of used in the first Ruby debugger: On every call create a closure with all of the values. This is horrendously slow.) And looking at WithLexical.pm's code, there is this comment in _record_caller_data(): # PadWalker ignores eval block and eval string so we must do so too. So this could also be another source of discrepancy people may run into. Given all of this -- and I am sorry if this was a bit long -- it seems that life would be much simpler and more reliable if Perl just had a eval_n function which did the evaluations n levels down the call stack. Looking at the C code, one can get a PERL_CONTEXT from the call stack and somehow one just needs to make sure that this is what is used by this new eval_n routine.
PadWalker, eval and perl5db
In working on the Trepanning debugger for Perl which in large part is modernizing and modularizing perl5db, I keep running into the limitations of eval. In both Ruby and Python, one can pass arguments in addition to the string to evaluate which controls the environment or context that evaluation uses. Lacking this, evaluations in perl5db need to be done in the DB namespace - but inside the "eval", one must first switch back to the debugged program namespace, e.g. "main". Consider what this does in debuggers that want to modularize code and move code and modules out of the DB namespace. In the trepanning debugger there is an object which is the command processor. It is pretty much a self-contained read-eval-print loop. But the eval part of it has to go back to DB any time an evaluation needs to be done. So some mechanism needed to ping-pong values back and forth between the command loop and DB. Another limitation of the Perl debuggers is that they can only evaluate expressions which may contain "my" variables in the context of the point of the stopped program, not call-stack frames further down. I've briefly looked at PadWalker which can look at "my" and "our" variables on a call stack. And while this is very useful, it is not the same as being able to evaluate a string in the context of a stack frame. Has anyone tried to create such an eval? A simple suggested interface would be to pass it an integer which indicates the call stack frame to use. Thanks.
Post announcement of new debugger Devel::Trepan
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.
Re: Pre announcement of yet another Perl debugger
On Mon, Sep 26, 2011 at 12:49 PM, Reini Urban 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"
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.
>
Pre announcement of yet another Perl debugger
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.
