Debugging just one function
Curioso
several functions, one of which is *wantedFunction()*. The module does
not have a
if __name__== '__main__' :
....
wantedFunction()
....
launcher section. What steps should be taken to debug directly
*wantedFunction()* with *Winpdb*?
This is what I have been doing:
I open *varia.py* with *Winpdb* and everything works as expected:
*varia.py* shows in the *Source* panel and the *C* position indicator
is at the first line of the script. I set the cursor at a line placed
after the function that I want to check (the one I have been calling
*wantedFunction()*) and give the *Run to line* instruction: the *L*
position indicator goes where it should and where I wanted it. The
list in the *Locals* group of the *Namespace* panel shows that
*wantedFunction()* has been duly taken in and is available (and the
same happens in the *Globals* group). I set a breakpoint at the first
line of *wantedFunction()*; it shows as set by the red background. I
execute *wantedFunction()* via *exec* or *eval* at the *Command*
panel ... and, although it is clear that the function has been
executed, because its result is shown, the line pointer never goes to
the breakpoint position and there is not the slightest possibility of
stepping into the body of the function for inspecting the detailed
evolution.
The sentence *... its result is shown* should be nuanced. When the
execution is done via *eval wantedFunction()*, the result really
appears in the *Console* panel. But when the execution is done via
*exec wantedFunction()*, the message "Textual output will be done at
the debuggee." appears there, but nothing shows at the debugee window.
This is however right, as *wantedFunction()* does not perform any
*print* or similar operation; it only returns values; they show if the
instruction given is *exec print(wantedFunction())* instead.
Although I have read carefully all available information about
*Winpdb* I cannot imagine what I should do to make this work as
intended. It is now mainly a question of intellectual curiosity,
because this shows that I do not understand well how the debugging
process develops or why it cannot be done, but it is also something
that interests me practically: I would really like to be able to debug
functions this way.
Any hint or explanation would be mostly appreciated. Thanks in
advance.
Paco.
Nir Aides
--
You received this message because you are subscribed to the Google Groups "Winpdb" group.
To post to this group, send email to win...@googlegroups.com.
To unsubscribe from this group, send email to winpdb+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/winpdb?hl=en.
Francisco Gracia
I also think that it could be an interesting feature to incorporate.
What is more, I consider that it could contribute much to improve the
concept one can form of *rpdb2/Winpdb*, because the fact that it can
reach the state that I described initially is not only frustrating for
the user, but can be considered quite inconsistent, if not outright
contradictory, with such an impressive piece of software: one is
interested in *cold testing* the internal workings of an algorithm;
sets up a powerful debugger; submits the source code to it, which
declares explicitly to have taken hold of it; and then the algorithm
either cannot be run at all (as happens with *rpdb2*) or it is run
kind of subreptitiously outside of the debugger (as with *winpdb*).
If, as you kindly tell me, it is a design constraint what dictates
such behaviour, it will probably be determined by the consecution of
some other more important and exclusive goal of the program. This
would be perfectly understandable. Only that in this case it would be
convenient that the fact were clearly and explicitly advertised in the
general description of the purpose and characteristics of the program,
so that the potential beneficiary understands under which
circumstances the use of *rpdb2/Winpdb* is reasonable and wholly
justified.
Congratulations and thanks again for such a nice program,
Paco