homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nobody
Recipients
Date 2000年07月31日.21:14:21
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: 1999年7月12日 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows
[Resubmitted by GvR]
It is a problem that bugged me for _ages_. Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)
The problem is simply: when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works. A "continue" command
functions as a step until you start debugging a frame below self.botframe.
It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.
The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.
My solution was this: instead of run() calling "exec" directly, it calls
another internal function. This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly. Then
stop_here is modified accordingly.
The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.
Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.
Thanks,
Mark.
====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open
History
Date User Action Args
2007年08月23日 13:49:25adminlinkissue210682 messages
2007年08月23日 13:49:25admincreate

AltStyle によって変換されたページ (->オリジナル) /