bashdb-pydb

Re: [Bashdb-pydb] Some possible thread debug additions

[Leonid G. <ig...@ho...>]

First of all I want to express my appreciations of efforts that Pydb develo=
pers spent to bring such a superior alternative to the Pdb debugger.=20
=20
Second, a little disclaimer. I have a rather insignificant expertise in Pyt=
hon development in general and system Python programming in particular. My =
background in emacs, bdb, ddd and other UNIX/Linux technologies is also min=
uscule =96 although I have plenty of experience developing multi-threaded a=
pplication via C++ under Windows. Also my mail represents my own day-to-day=
 tactics of tackling variety of debugging issues, which may not be a typica=
l approach for other Python developers.
=20
1.    My bread-and-butter debugging scenario in multithreaded environment i=
s to debug rather small set of source lines at one time. I am typically set=
 few breakpoints in the code executed in thread of my interest and using st=
ep and next (or something like that) to go through my sources examining val=
ue of variables and looking close to code workflow. For that scenario I wou=
ld be definitely interested that step, next, finish and return would be con=
ducted ONLY in the context of current thread. To me continue statement is b=
it different. I would allow it to continue execution of all threads until a=
 BP hit in any of them. The other approach is to allow only current or spec=
ified thread to be continue implicitly should pause other threads execution=
 and while it may be technically feasible on Python it may not be desirable=
 in most of the cases =96 at least for me (one may argue to modify your sug=
gesting to use something like continue __all__ statement)
2.    Sometimes (although not as often as in first scenario) I do like to l=
ook at all or some other thread state (use something like =93info thread=94=
 statement). Typically I would need to do it to understand overall state of=
 execution, debugging for possible deadlocks, or understand dynamics of thr=
eads execution. One can also use this opportunity to move-on on debugging c=
ode executed in the different thread. If new code of interest has no breakp=
oints yet it often useful to put them there at this time and continue (see =
my comment above about continue statement) because quite often the current =
top os stack frame of the other thread(s) locate far apart from the debuggi=
ng area. Only in case if it is right near than your suggestion about next, =
step with thread=92s name/number would be very convenient. One may also sug=
gest to add a =93finish=94 statement to this list. Better yet provide =93fi=
nish=94 with additional optional numerical argument which would allow to fi=
nish more than one function at the time. One my add the same argument to =
=93next=94 statement and even =93step=94 although it probably will be less =
useful than finish.
3.    I would be interested to setup breakpoints only in particular thread =
using its name/number via some optional parameters for cases when you have =
few breakpoints in the code which executed simultaneously by many thread bu=
t you want to follow only one logical/physical thread. Or may be even have =
command which can modify BP to stick only to one, few or all threads. May b=
e this can be done using condition statement but I am not aware how.
4.    I would be interesting to have a statement which can specify to conti=
nue until the following line. One can probably do this with combination of =
tbreak and continue but that would be one statement less to type. Probably =
this can be achieved with alias and I need to run more experiments with thi=
s.
=20
=20
And last but not least, I would like to ask the question which may be sligh=
tly off topic. I would like to examine values via tool-tip if mouse hover o=
ver expression/selection for few seconds, set/remove/disable/display breakp=
oints on the same small vertical grey area where current execution triangle=
 cursor is displayed. I would even move to appropriate code location if dou=
ble-clicked on the stack frame. Or having split gud-xxx window which would =
constantly display =93display=94 values, list of break points and let=92s s=
ay list of threads. It probably can be done mostly in LISP and no one would=
 spent an effort but who said that we cannot dream J
=20
Thank you guys.
=20
Len.
=20
=20
=20
_________________________________________________________________
Share your special moments by uploading 500 photos per month to Windows Liv=
e Spaces=20
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=3Dhttp://=
www.get.live.com/spaces/features=

Re: [Bashdb-pydb] Some possible thread debug additions

[Leonid G. <ig...@ho...>]

I absolutely agree with you on the last paragraph and my last comment proba=
bly sounded somewhat condescending - I am sorry if it is sound like I was g=
iving implicit directions to "cadre of eager developers" about new features=
. I know that I should dig-in myself and just do it. It does not sounds ext=
remely complex but would require for me learning elisp which I want to do a=
nyway. Some of the suggested Pydb features it would be interesting to me fo=
r implement as well. I post that comment in small hope if some-one already =
did it or starting to do or even would say do not bother is way to complex.
=20
Please do no feel obligated or pressed in anyway by my long message. As I h=
ave said I do appreciate all that work that you and other people put in Pyd=
b and I am benefiting greatly from fruits of your labors. I just spew my br=
ain dump on the subject first because I am very interested in it and second=
 because I thought it could bring another user perspectives.
=20
Thank you.
=20
Len
=20
_________________________________________________________________
Try the new Live Search today!=20
http://imagine-windowslive.com/minisites/searchlaunch/?locale=3Den-us&FORM=
=3DWLMTAG =

Re: [Bashdb-pydb] Some possible thread debug additions

[R. B. <ro...@pa...>]

Gee, this is quite a bit of information. I'm not sure how to best make us=
e
of it. I was offering a very limited set of choices which might be added
sometime in the very vague future. Basically it sounds like, "step thread=
"
and "next thread" are useful, although no doubt there will be confusion
that this means to block all other threads and it doesn't.

Adding a location specification to the "continue" command is pretty easy
to do. Gdb doesn't have it on its "continue" command, but Perl's debugger
does as does the bash debugger (as well as probably other debuggers).
However it is also true, as you note, it's also pretty easy to add via an
alias.

One can't preempt a thread in Python, so a gdb-style "thread" command is
impossible. The closest one can get is to switch threads after performing
the statement after one is currently stopped at. And even here this has
problems. First, unless one is stopped in all threads that the debugger
has control over, it can't be done reliably. Second, even if the debugger
has control over all threads, trying to restrict execution to a particula=
r
thread and then running the statement that you are stopped at could
conceivably cause a situation where threads are deadlocked. Such a
"thread" command was in pydb CVS up until just before the release. I
removed it because it was likely to cause too many headaches. And you've
confirmed this was probably the right thing to do. If you are issuing bug
requests about having to issue a step in thread debugging (fixed in CVS)
or that "next" in thread debugging sometimes acts like "step", this was
much more serious.

Lastly a comment with respect to wanting features, inexperience in this o=
r
that area and hoping there's a cadre of programmers out there who are jus=
t
waiting for the suggestion on things you want. The best way to make sure
something gets done is to dig in and do it. I often hear, "gee I'd really
like this or that but I really don't know all that much about it." If I
had waited for someone else to improve the Python debugger (or the write =
a
debugger for bash or GNU make or write a cross-platform CD reading
library) it would have never have happened. I suggested the debugger for
GNU a year before I did the work. And prior to undertaking these things
I'd hardly consider myself an expert in them. I'm not sure I would even
now. My exposure to Python is less than a year, and as I mentioned
previously, I really don't use threads or do thread debugging all that
much.

> First of all I want to express my appreciations of efforts that Pydb
> developers spent to bring such a superior alternative to the Pdb debugg=
er.
>
> Second, a little disclaimer. I have a rather insignificant expertise in
> Python development in general and system Python programming in particul=
ar.
> My background in emacs, bdb, ddd and other UNIX/Linux technologies is a=
lso
> minuscule =96 although I have plenty of experience developing multi-thr=
eaded
> application via C++ under Windows. Also my mail represents my own
> day-to-day tactics of tackling variety of debugging issues, which may n=
ot
> be a typical approach for other Python developers.
>
> 1.    My bread-and-butter debugging scenario in multithreaded environme=
nt
> is to debug rather small set of source lines at one time. I am typicall=
y
> set few breakpoints in the code executed in thread of my interest and
> using step and next (or something like that) to go through my sources
> examining value of variables and looking close to code workflow. For th=
at
> scenario I would be definitely interested that step, next, finish and
> return would be conducted ONLY in the context of current thread. To me
> continue statement is bit different. I would allow it to continue
> execution of all threads until a BP hit in any of them. The other appro=
ach
> is to allow only current or specified thread to be continue implicitly
> should pause other threads execution and while it may be technically
> feasible on Python it may not be desirable in most of the cases =96 at =
least
> for me (one may argue to modify your suggesting to use something like
> continue __all__ statement)
> 2.    Sometimes (although not as often as in first scenario) I do like =
to
> look at all or some other thread state (use something like =93info thre=
ad=94
> statement). Typically I would need to do it to understand overall state=
 of
> execution, debugging for possible deadlocks, or understand dynamics of
> threads execution. One can also use this opportunity to move-on on
> debugging code executed in the different thread. If new code of interes=
t
> has no breakpoints yet it often useful to put them there at this time a=
nd
> continue (see my comment above about continue statement) because quite
> often the current top os stack frame of the other thread(s) locate far
> apart from the debugging area. Only in case if it is right near than yo=
ur
> suggestion about next, step with thread=92s name/number would be very
> convenient. One may also suggest to add a =93finish=94 statement to thi=
s list.
> Better yet provide =93finish=94 with additional optional numerical argu=
ment
> which would allow to finish more than one function at the time. One my =
add
> the same argument to =93next=94 statement and even =93step=94 although =
it probably
> will be less useful than finish.
> 3.    I would be interested to setup breakpoints only in particular thr=
ead
> using its name/number via some optional parameters for cases when you h=
ave
> few breakpoints in the code which executed simultaneously by many threa=
d
> but you want to follow only one logical/physical thread. Or may be even
> have command which can modify BP to stick only to one, few or all threa=
ds.
> May be this can be done using condition statement but I am not aware ho=
w.
> 4.    I would be interesting to have a statement which can specify to
> continue until the following line. One can probably do this with
> combination of tbreak and continue but that would be one statement less=
 to
> type. Probably this can be achieved with alias and I need to run more
> experiments with this.
>
>
> And last but not least, I would like to ask the question which may be
> slightly off topic. I would like to examine values via tool-tip if mous=
e
> hover over expression/selection for few seconds,
> set/remove/disable/display breakpoints on the same small vertical grey
> area where current execution triangle cursor is displayed. I would even
> move to appropriate code location if double-clicked on the stack frame.=
 Or
> having split gud-xxx window which would constantly display =93display=94
> values, list of break points and let=92s say list of threads. It probab=
ly
> can be done mostly in LISP and no one would spent an effort but who sai=
d
> that we cannot dream J
>
> Thank you guys.
>
> Len.
>
>
>
> _________________________________________________________________
> Share your special moments by uploading 500 photos per month to Windows
> Live Spaces
> http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=3Dhtt=
p://www.get.live.com/spaces/features-------------------------------------=
------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV_______________________________________________
> Bashdb-pydb mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-pydb
>