pdb.py Uses the Breakpoint class so one can enable/disable breakpoints,
set temporary ones, set ignore counts, and conditions. The last
can be set using the 'b' command
b 243 , i>4 ( b 243,i>4 if you are space adverse)
or with the condition command so conditions can be changed
for a particular breakpoint.
Breakpoints are numbered from 1 on, and if a breakpoint is deleted,
the number is not reused. All the breakpoint handling commands
refer to breakpoints by number. To be consistent, the clear command
does so as well, which is the one change from the original pdb that
is not transparent. Thus only the breakpoint command 'b' uses a
line number or file:line or method. You can also give
b whrandom.random and the method will be searched for along
sys.path. This is implemented with an 'egrep' command and so
is not as portable as it might be. [ see lineinfo() and
lineinfoCmd ]
Breakpoints cannot be set at a line that is blank or a '#' comment
or starts a triply quoted comment. This is because I would like
this behavior in my DDD interface and think it reasonable for
pdb as well. It can be removed readily, however as it is all
incorporated in the routine checkline(). If one attempts to
set a breakpoint at a 'def' line, the breakpoint is automatically
moved to the first executable line after the 'def'. This too is
in checkline().
do_EOF() returns zero so typing an end-of-file character as a command
does nothing. 'quit' does the quitting.
The routine defaultFile() is present so as to preserve the current
pdb behavior and yet allow me to override it in pydb.
There's some code in lineinfo() that is probably mainly useful only
for pydb and if you prefer, much up to the comment "Best first guess"
could be removed.
Keith Davidson provided the code for handling $HOME/.pdbrc and
./.pdbrc, and it has been incorporated. He also provided the
alias handling routine. I modified it a bit so it could live
nicely in precmd(). He and I have been in contact; he has the
new pdb (and pydb) with his code incorporated. He also asked
about the possibility of allowing multiple commands on one
line, such as step;step or s;s or with an alias such as
alias ct tbreak %1 ; continue
and since it was so easy, that's in place as well. It's a simple
'split the line at the first ";"' operation and puts the second
half in the command queue (self.cmdqueue). This has the unfortunate
effect of destroying a line like print "i: "+i+"; j: "+j
but either there's a simple way to deal with this, or my attitude
will remain that pdb is a debugger, not a compiler/parser/etc.
An alias like alias 4s s;;s;
will work because the adjacent and trailing ";" act like a <cr> which
repeats the last command. Of course, either s;s;s;s or s;;; would be
a bit more sensible.
The help commands have been updated.
bdb.py now has a class definition called Breakpoint along with
associated methods. There's no reason why this class has to
be there; if you prefer it elsewhere, 'tis easily done.
(Minor reformatting by GvR; e.g. moved Breakpoint's doc string to
proper point.)
cmd.py has incorporated the changes we discussed a couple of weeks ago
(a command queue, returning line from precmd, and stop from postcmd)
and some changes to help that were occasioned because I wanted to
inherit from pdb which inherits from cmd.py and the help routine
didn't look for commands or the associated help deeply enough.
change error messages to be a little more straightforward
change definition of FULL_PATH so that an error is raised if the
setuid wrapper is used un-edited
1. use dict.get instead of try/except KeyError
2. if the url scheme is 'http' then avoid the series of
'if var in [someseq]:'. instead, inline all of the code.
3. find = string.find
1) I added a command queue which is helpful to me (at least so far) and
would also allow syntax like 's;s' (step; step) in conjunction with precmd
2) doc_leader allows the derived class to print a message before the help
output. Defaults to current practise of a blank line
3) nohelp allows one to override the 'No help on' message. I need
'Undefined command: "%s". Try "help".'
4) Pass line to self.precmd to allow one to do some parsing: change first
word to lower case, strip out a leading number, whatever.
5) Pass the result of onecmd and the input line to postcmd. This allows
one to ponder the stop result before it is effective.
6) emptyline() requires a if self.lastcmd: conditional because if the
first command is null (<cr>), you get an infinite recursion with the
code as it stands.
that file in fact did not exist or at least was not used. Change this
so that __file__ is *only* set to the .pyc/.pyo file when it actually
read the code object from it; otherwise __file__ is set to the .py
file.
happen when you use a non-keyword argument after a keyword argument,
and in this case you also get a syntax error. I fully suspect that
the underflow is caused by the code that stops generating code when it
detects the syntax error, but I can't find the culprit right now. I
know, I know.)
The MS compiler doesn't call it 'long long', it uses __int64,
so a new #define, LONG_LONG, has been added and all occurrences
of 'long long' are replaced with it.
Jack Jansen