Re: [Python-Dev] Pep 393 and debugging
I wonder if there is a way to make this situation easier? Perhaps for debug builds, we can store some debug information in the frame object, e.g. utf8 encoding of the filename and function? I'd like to stress Benjamin's recommendation. Dave Malcolm's gdb extensions (requires gdb with Python support) are really powerful; they will automatically render PyObject* by displaying the actual logical value (and not just for strings). Failing that, I use _PyObject_Dump to display strings; this requires a debugger that can call functions in the debuggee (like gdb). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pep 393 and debugging
Thanks, _PyObject_Dump sounds like just the ticket. Most of the time, the VS2010 debugger can just run functions willie nillie and thing should simply work. Frá: Martin v. Löwis [mar...@v.loewis.de] Sent: 7. apríl 2012 09:08 To: Kristján Valur Jónsson Cc: python-dev@python.org Efni: Re: [Python-Dev] Pep 393 and debugging I wonder if there is a way to make this situation easier? Perhaps for debug builds, we can store some debug information in the frame object, e.g. utf8 encoding of the filename and function? I'd like to stress Benjamin's recommendation. Dave Malcolm's gdb extensions (requires gdb with Python support) are really powerful; they will automatically render PyObject* by displaying the actual logical value (and not just for strings). Failing that, I use _PyObject_Dump to display strings; this requires a debugger that can call functions in the debuggee (like gdb). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pep 393 and debugging
I just had my first fun with Pep 393 strings and debuggers. Trying to debug a deadlocked python program, I'm trying to figure out the callstack of the thread in the debugger. I ended up with something like: (char*)((PyASCIIObject*)(tstate-frame-f_code-co_filename))[1] while previously, it was sufficient to do (PyUnicodeObject*)(tstate-frame-f_code-co_filename) Obviously this won't work for non-ASCII objects. I wonder if there is a way to make this situation easier? Perhaps for debug builds, we can store some debug information in the frame object, e.g. utf8 encoding of the filename and function? K ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pep 393 and debugging
2012/4/6 Kristján Valur Jónsson krist...@ccpgames.com: I wonder if there is a way to make this situation easier? Perhaps for debug builds, we can store some debug information in the frame object, e.g. utf8 encoding of the filename and function? Have you tried using the cpython gdb plugin? It should repr these things for you. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
