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
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.