I am new to Python and pydb, but experienced with Perl and "perl -d",
which is very similar. I am running Python 2.4.1 and pydb 1.20.
I don't understand the behavior of the pydb command "continue <n>"
with this combination of Python/pydb versions and am wondering if
I have found a bug. My understanding is that this command is
supposed to set a temporary breakpoint at line <n> of the file, and
then continue - i.e. it runs to line <n> and then stops. But it
doesn't work, best as I can tell.
I wrote a little hello-world type Python program, and if I run it
in pydb, I can do "b 5" then "continue", and the program runs to
line 5 and breaks. But if I just run "continue 5", the program
executes to the end without breaking.
It's a giant pain to have to do "b 5" <RETURN> "c" every time.
Is this a bug? If so, can it be worked around with an alias
(I haven't been able to figure out how to do multi-command
aliases).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This indeed was a bug which is now fixed in CVS. Thanks for reporting. The bug seemed to have to do with issuing this kind of "continue" statement initially. You would not, for example, notice the bug for example if you issued "step" and then ran your "continue 5".
One way to check to see if a debugger command works under *some* conditions is to check the regression tests to see if it is tried in one of the debugger-command files. These are test/*.cmd files. For example notice that test/brkpt2.cmd on line 38 has such a "continue" statment.
Finally, here is how you can create an equivalent alias. This also works in the last release and probably in the version you report having installed:
alias myc tbreak %1 ;; continue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rocky, thanks for the confirmation. I'll probably use the alias
for now and wait for the next release of pydb for a permanent fix.
The alias works, but unfortunately I now think I've found a but in
the way ~/.pydbrc is found. I'll post that in a separate thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am new to Python and pydb, but experienced with Perl and "perl -d",
which is very similar. I am running Python 2.4.1 and pydb 1.20.
I don't understand the behavior of the pydb command "continue <n>"
with this combination of Python/pydb versions and am wondering if
I have found a bug. My understanding is that this command is
supposed to set a temporary breakpoint at line <n> of the file, and
then continue - i.e. it runs to line <n> and then stops. But it
doesn't work, best as I can tell.
I wrote a little hello-world type Python program, and if I run it
in pydb, I can do "b 5" then "continue", and the program runs to
line 5 and breaks. But if I just run "continue 5", the program
executes to the end without breaking.
It's a giant pain to have to do "b 5" <RETURN> "c" every time.
Is this a bug? If so, can it be worked around with an alias
(I haven't been able to figure out how to do multi-command
aliases).
This indeed was a bug which is now fixed in CVS. Thanks for reporting. The bug seemed to have to do with issuing this kind of "continue" statement initially. You would not, for example, notice the bug for example if you issued "step" and then ran your "continue 5".
One way to check to see if a debugger command works under *some* conditions is to check the regression tests to see if it is tried in one of the debugger-command files. These are test/*.cmd files. For example notice that test/brkpt2.cmd on line 38 has such a "continue" statment.
Finally, here is how you can create an equivalent alias. This also works in the last release and probably in the version you report having installed:
alias myc tbreak %1 ;; continue
Rocky, thanks for the confirmation. I'll probably use the alias
for now and wait for the next release of pydb for a permanent fix.
The alias works, but unfortunately I now think I've found a but in
the way ~/.pydbrc is found. I'll post that in a separate thread.