Re: RFC Devel::Trepan

--f46d0416ffd9c6777f04b5951e7e
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Dec 18, 2011 at 11:42 AM, Rocky Bernstein <[email protected]> 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.
>

--f46d0416ffd9c6777f04b5951e7e--