Re: claims of python unit test un-debugability considered somewhat exaggerated

Hi guys,

On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote:
> CCing David Malcolm.
>
> Michael> (gdb) py-bt
>
> I just wanted to mention here that Phil Muldoon is working on a "frame
> filter" patch series that is basically "pretty printing for stack
> frames".  With this in place you'll no longer need a special command --
> with appropriate support from Python, you'll be able to see interpreted
> frames interleaved with the low-level C frames.

        Oh - nice ! :-)

> This series is nearing final review now and should appear in gdb 7.7,
> later this year.

        Excellent news indeed.

> I think we're planning to rewrite the existing "py-bt" code into frame
> filter form ourselves.

        So - in which case this significantly reduces the problems of using
python for debugging; I assume that with py-bt - there are still issues
with interleaving two tools for printing parts of backtraces when we
call several times to and fro between C++ and python.

> Eventually we'd like to have more full support for "mixed" interpreter
> and C debugging.  However this is a ways off.

        For me, clearly seeing the python line numbers is the key rather than
the interpreter details - we treat python itself as working black-box -
and the script itself as the problem ;-)

        So - re-examining my requirements:

>     + debug-ability - when the test fails - and the best tests are
>       written to fail regularly ;-) we need to be able -very-simply-
>       to get a backtrace we can work with - without a ton of
>       training, reading a dozen wiki pages, poking for obscure
>       symbols, etc.

        Michael - as/when a python unit test fails - can we make the magic
environment variables that are listed include some debugging
instructions that include the "py-bt" detail etc. so that everything
needed is in the failure message ? when we're in the automatic trace
collection mode (I forget what env. var that is) do we dump the python
pieces as well ? Also - can we distribute / include / install the magic
that makes 'py-bt' work - not sure it works for me (on openSUSE - at
least a facile start gdb, type py-bt fails in spades ;-)

>        + that backtrace should not have big, opaque chunks that
>         are either empty (cf. Java) or point to random / irrelevant
>         pieces of C/C++ interpreter code - Python / StarBasic &
>         others. It should allow interactive inspection of variables
>         up and down the stack.

        It seems that this is getting towards working on modern Linux systems.
Do we get variable inspection sorted out there as well ?

>       + reliability and performance: new unit tests should be small,
>         fast, non-duplicative (ie. re-using existing code &
>         frameworks)

        I guess re-using the existing C++ test code / bootstrapping framework
mostly avoids duplication here; and either way unit tests are (sadly)
one of the more duplicative pieces of code we have.

>       + ideally - the unit tests should run -in-the-same-process-
>         which significantly helps with the above performance,
>         debugging, reliability and more.

        And this is now fixed; so - David & Michael - thanks for working on
this - looks like a good solution with a brighter future :-)

        Thanks,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot