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.
