On Sun, Dec 18, 2011 at 11:42 AM, Rocky Bernstein <ro...@gnu.org> 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. >
