[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

Martin v. Löwis added the comment: Thanks for the patch; applied as r80324. As it is an improvement over the status quo, I've applied it; I'll also be closing this issue. I still get test failures which I report as a separate bug report. As for displaying strings: I think it should do what gd

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

Dave Malcolm added the comment: I'm attaching a new version of the patch, for the py3k branch. I changed my mind back about the breakpoint, using "id" and "builtin_id" as in my original patch. I prefer it since it has a single argument, which makes it very convenient to work with in the vari

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

Dave Malcolm added the comment: Thanks; I'm working on a newer version of the patch based on what's in SVN. I prefer your choice of breakpoint, and I've changed my mind about the python2 vs python3 proxyval handling. Hope to have a fresh patch later today. -- _

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

STINNER Victor added the comment: > Looking at issue 8480, it looks like this a partial fix was applied, Martin fixed calls to assertListing(). I renamed PyStringObjectStr to PyBytesStringPtr and used a breakpoint on textiowrapper_write() instead of PyObject_Dump(). Your patch uses a breakpoi

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

Changes by Dave Malcolm : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

Dave Malcolm added the comment: Looking at issue 8480, it looks like this a partial fix was applied, which will mean this patch will no longer apply. Should I regenerate a patch against what's now in SVN, or should we use my patch? -- ___ Python t

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

Dave Malcolm added the comment: > Should we call it libpython3.py, in order to distinguish it from the 2.x > version? We could; it gets copied to python-gdb.py by the Makefile though. The code is intended to track the low-level implementation details of the tree that its in, so I'd expect the

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

Antoine Pitrou added the comment: Should we call it libpython3.py, in order to distinguish it from the 2.x version? -- nosy: +pitrou ___ Python tracker ___ _

[issue8380] Port of the gdb7 debugging hooks to the "py3k" branch

New submission from Dave Malcolm : I'm attaching a patch for the py3k branch to port the gdb hooks to Python 3. The libpython.py code installed to python-gdb.py "knows" about the internal details of the Python within the tree. This patch makes the necessary changes to that code for the intern