pdb mini-sprint report and questions
Hi, to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on pdb issues today. I'm pleased to report that 14 issues could be closed, and pdb got a range of small new features, such as commands on the command line, "until <lineno>" or "longlist" showing all the code for the current function (the latter courtesy of Antonio Cuni's pdb++). One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb. However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it. Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required "!" or "print" that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent? Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Fri, Jul 30, 2010 at 3:45 PM, Georg Brandl <g.brandl@gmx.net> wrote:
to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on pdb issues today. I'm pleased to report that 14 issues could be closed, and pdb got a range of small new features, such as commands on the command line, "until <lineno>" or "longlist" showing all the code for the current function (the latter courtesy of Antonio Cuni's pdb++).
One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb.
However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it.
Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required "!" or "print" that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent?
Warning: 'p' is *not* the same as 'print'. 'p' is a built-in command that prints the expression's repr(). 'print' OTOH falls back through the interpreter and executes a print statement or function, which prints the str(). For me personally, the problem this feature tries to address is never a problem (of course I am probably unique as far as pdb users go :-) so I'd like a way to turn it off.
Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions...
Cool. -- --Guido van Rossum (python.org/~guido)
Am 31.07.2010 01:01, schrieb Guido van Rossum:
On Fri, Jul 30, 2010 at 3:45 PM, Georg Brandl <g.brandl@gmx.net> wrote:
to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on pdb issues today. I'm pleased to report that 14 issues could be closed, and pdb got a range of small new features, such as commands on the command line, "until <lineno>" or "longlist" showing all the code for the current function (the latter courtesy of Antonio Cuni's pdb++).
One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb.
However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it.
Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required "!" or "print" that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent?
Warning: 'p' is *not* the same as 'print'. 'p' is a built-in command that prints the expression's repr(). 'print' OTOH falls back through the interpreter and executes a print statement or function, which prints the str().
Not in py3k -- 'print' is an alias for 'p' there, otherwise 'print x' would be a syntax error.
For me personally, the problem this feature tries to address is never a problem (of course I am probably unique as far as pdb users go :-) so I'd like a way to turn it off.
Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions...
Cool.
I take it you'd like to see them? ;) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Fri, Jul 30, 2010 at 4:07 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 31.07.2010 01:01, schrieb Guido van Rossum:
Warning: 'p' is *not* the same as 'print'. 'p' is a built-in command that prints the expression's repr(). 'print' OTOH falls back through the interpreter and executes a print statement or function, which prints the str().
Not in py3k -- 'print' is an alias for 'p' there, otherwise 'print x' would be a syntax error.
Ah, ok, even better.
For me personally, the problem this feature tries to address is never a problem (of course I am probably unique as far as pdb users go :-) so I'd like a way to turn it off.
Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions...
Cool.
I take it you'd like to see them? ;)
Sorry, yes, I meant that as a "kewl" cool, not "lukewarm" cool. IOW +1, not +0. :) -- --Guido van Rossum (python.org/~guido)
On Jul 31, 2010, at 12:45 AM, Georg Brandl wrote:
to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on pdb issues today. I'm pleased to report that 14 issues could be closed, and pdb got a range of small new features, such as commands on the command line, "until <lineno>" or "longlist" showing all the code for the current function (the latter courtesy of Antonio Cuni's pdb++).
I haven't played with pdb++ (I might have to do something about that) but it's awesome that you're giving pdb some love.
One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb.
That *would* be nice.
Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required "!" or "print" that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent?
Not that important to me...
Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions...
...but watch expressions - and the equivalent of gdb's 'display' command - would be very cool. `interact` would also be useful and probably pretty easy to add. -Barry
Hello, I'm the submitter of the original patch and would like to help with it if I can.
One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb.
However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it.
For whatever it's worth, it worked for me with python trunk (2.x) on Vista, when I tried it manually. But I don't know how to implement the unit test there (subprocess module doesn't support sending SIGINT programmatically on windows either). So the test_pdb2 test does not check signal behavior on Windows platforms. Buildbot failures are still a total mystery for me ;-): the failures were happening elsewhere and seemed to be unrelated to test_pdb2. Is there any other way to apply the patch and run the tests on failing platforms? Ilya
Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required "!" or "print" that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent?
Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions...
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
_______________________________________________ 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/ilya.sandler%40gmail.com
On Mon, Aug 2, 2010 at 10:10 AM, Ilya Sandler <ilya.sandler@gmail.com> wrote:
Hello,
I'm the submitter of the original patch and would like to help with it if I can.
One issue that's not yet closed is #7245, which adds a (very nice IMO) feature: when you press Ctrl-C while the program being debugged runs, you will not get a traceback but execution is suspended, and you can debug from the current point of execution -- just like in gdb.
However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it.
For whatever it's worth, it worked for me with python trunk (2.x) on Vista, when I tried it manually. But I don't know how to implement the unit test there (subprocess module doesn't support sending SIGINT programmatically on windows either). So the test_pdb2 test does not check signal behavior on Windows platforms.
I haven't looked at the relevant patch to check if this is applicable to the test case, but actually sending a Ctrl-C character to stdin (via a pipe) can work (although I think there can be some weirdness if the parent process has no console). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Barry Warsaw -
Georg Brandl -
Guido van Rossum -
Ilya Sandler -
Nick Coghlan