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

2013-04-10 Thread David Malcolm
On Wed, 2013-04-10 at 01:45 +0200, David Ostrovsky wrote: On Tue, 2013-04-09 at 11:26 -0400, David Malcolm wrote: [...snip...] http://docs.python.org/devguide/gdb.html#gdb-7-and-later In particular: (gdb) py-list should give you python source code for the current python frame.

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

2013-04-10 Thread David Ostrovsky
On Wed, 2013-04-10 at 10:35 -0400, David Malcolm wrote: Works like a charm here on OpenSUSE 12.3 too, with system python3.3: [...snip...] Good to hear. FWIW there are some more notes on how I made the debugging just work on Fedora here:

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

2013-04-10 Thread Tom Tromey
David == David Ostrovsky d.ostrov...@gmx.de writes: David The only question is now, how to skip the manual sourcing of David libpython.py? If i understand it right, it happens automagically on David Fedora? Yes, Fedora installs /usr/lib/debug/usr/lib64/libpython2.7.so.1.0.debug-gdb.py

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

2013-04-09 Thread Michael Meeks
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

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

2013-04-09 Thread d . ostrovsky
Quoting Michael Meeks michael.me...@suse.com: 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

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

2013-04-09 Thread David Malcolm
On Tue, 2013-04-09 at 11:22 +0100, Michael Meeks wrote: 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

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

2013-04-09 Thread David Ostrovsky
On Tue, 2013-04-09 at 11:26 -0400, David Malcolm wrote: On Tue, 2013-04-09 at 11:22 +0100, Michael Meeks wrote: 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

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

2013-04-08 Thread Noel Grandin
On 2013-04-05 23:44, Michael Stahl wrote: so i spent the day trying to understand soffice bootstrap and moving the proposed Python unit tests in-process to see if that makes this more acceptable for people. I consider this acceptable. So you can consider my objection to python unit tests

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

2013-04-08 Thread Tom Tromey
Michael == Michael Stahl mst...@redhat.com writes: 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

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

2013-04-08 Thread David Malcolm
On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote: Michael == Michael Stahl mst...@redhat.com writes: 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

claims of python unit test un-debugability considered somewhat exaggerated

2013-04-05 Thread Michael Stahl
so i spent the day trying to understand soffice bootstrap and moving the proposed Python unit tests in-process to see if that makes this more acceptable for people. https://gerrit.libreoffice.org/#/c/3215/ this runs inside gdb in the same way as the CppUnit ones: (cd sw make subsequentcheck