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.