bashdb-pydb — Discusson for Extended Python debugger

[Bashdb-pydb] Added Ability to change -W options in running programs

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

I made a small addition, I've meant to do. Basically I've added the
ability to change the python warning options, e.g. -Werror,
-We:Deprecation, etc.

The actual commands are "set warnoptions [opt..]" and "show
warnoptions". As is customary, "warnoptions" can be to the point of
making it unique across other commands. Currently this would is just
the letter "w". However should "show warranty" get added, it you'd
then have to use "warn" as the minimum abbreviation.

[Bashdb-pydb] Pydb 1.19 released

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

Release done. Thanks to Len Gamburg for helping in testing the release
out. (Remaining bugs in the release are mine though.)

[Bashdb-pydb] pydb demo on showmedo.com

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

I've put a small demo some of the features that distinguishes pydb from
pdb (and other debuggers) at: 

http://showmedo.com/videos/video?name=pythonBernsteinPydbIntro&fromSeriesID=28

As an added bonus you can hear me trip over the English language as
she is spoken. Lot's of um's" and uh's.

[Bashdb-pydb] pydb 1.19 release on Oct 27th

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

I'm planning release 1.19 on Oct 27th. A candidate tarball can be found at
http://bashdb.sf.net/pydb-1.19rc.tar.gz

If you have time to test this, I'd appreciate it.

Here are the changes over the last release:

* info threads: merge in terse display (Python 2.5, threadframe)
  and sort by thread name (Python 2.5)

* Add optional position argument on "continue" command.

* Add pydb.runl() and pydb.runv() forms to facilitate debugging a
  program from inside a Python shell.

* fix thread bugs: on startup with threading we stopped one statement
  too soon. more careful about storing into variables used in
  threading which are not locked (and so could be changed during a
  thread switch)

* fix bugs in signal handling. 

* Add "stack" and "nostack" to list of things that can be done when
  a signal is received.

* things to make more ipython friendly.

* Improve pydb manual

Thanks

[Bashdb-pydb] Possibly another release in 3-4 weeks

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

Recently I've been seeing at what it would take to make pydb work
inside of ipython. Some info on this has been posted to the
ipython-dev mailing list. So far things have been pretty easy. It
seems that another ipython release (0.7.3) is likely to happen in
about 3-4 weeks and the ipython folks so far have been positive about
getting the pydb support into that release.

It might be best to coordinate a pydb release to go with that since
there the recent changes have been to make working inside ipython
better.

In particular, one thing of general interest when working inside any
python shell is that I've added pydb.runv() and and pydb.runl()
functions to start a debugger session. For example if you are in the
stock Python shell. You can do something like this:
  >>>> import pydb
  >>>> pydb.runl("--threading", "--nx", "/tmp/test.py", "--option1", "arg1")
to start a debugger session. 

The pydb.runv() form might look like this:

  >>>> args=("--threading", "--nx", "/tmp/test.py", "--option1", "arg1")
  >>>> pydb.runv(args)

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
>

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=

[Bashdb-pydb] Some possible thread debug additions

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

I don't expect to make any of the following changes soon (if ever),
but I like open up for general comments possible extensions to thread
debugging I've been considering.

Basically I've been thinking of allowing a thread name to be specified
on "next", "step" and "continue" statements. Also I've considered
allowing "self" to be used as thread name to indicate the current
thread. Another thing in the back of my mind is to allow the thread
number to be used instead of the thread name. (If Python pre 2.5 is
used and no threadframe module is installed this may be more
convenient).

I don't really know about any of this since I don't do that much (if
any) thread debugging.

[Bashdb-pydb] 2 bugs - are they bugs or limitations, or incorrect installtion?

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

I just entered two bugs related to new functionally with --threading option=
. I do not know if pydb developers will have time to look at them in the ne=
ar future. But I am really interesting if some one from developer group cou=
ld comment on at some point.
=20
Thank you.
=20
Len.
_________________________________________________________________
Search=97Your way, your world, right now!
http://imagine-windowslive.com/minisites/searchlaunch/?locale=3Den-us&FORM=
=3DWLMTAG =

[Bashdb-pydb] Test - Please Ignore

[iglen <ig...@ho...>]

I am apologizing for the noise. I have been having trouble to see my own
messages as well as replies. I am trying to see if it was a temporary glitch
or there are other issues with my valid email address.

[Bashdb-pydb] How to add PYTHONPATH for Pydb emacs session

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

Works for me. 

Although in pdb, I have found myself writing a wrapper script as you
seem to indicate, with recent versions of pydb, normally you don't
need to. (Well, at least I don't and *I'm* normal.)  pydb tries to install a
symlink in your a binary directory to the python script.

 # ls -l /usr/local/bin/pydb
  lrwxrwxrwx 1 root root 45 2006-09-16 20:37 /usr/local/bin/pydb -> /usr/lib/python2.4/site-packages/pydb/pydb.py


That said, if you want to create a shell script, sure, you still
can. (Or at least I can ;-) Here's what I just tried on a SUSE GNU
linux box as seen above seems to want to put packages in
/usr/lib/python2.4/site-packages:

#!/bin/sh
export PYTHONPATH="/usr/lib/python2.4/site-packages/:$PYTHONPATH:"
/usr/lib/python2.4/site-packages/pydb/pydb.py $*

When I tried running the above script passing a little python program
when I got the pydb prompt. Just to make sure it's what I thought it
should be I ran this:

  (Pydb) import sys
  (Pydb) sys.version
  '2.4.2 (#1, May  2 2006, 08:13:46) \n[GCC 4.1.0 (SUSE Linux)]'
  (Pydb)

I've also installed Python 2.5 and that seems to want to put packages
in /usr/local/lib/python2.5/site-packages instead. So changing this to
the 2.5 location, as a test verified there was nothing magical:

#!/bin/sh
export PYTHONPATH="/usr/local/lib/python2.5/site-packages/:$PYTHONPATH"
/usr/local/lib/python2.5/site-packages/pydb/pydb.py $*

Running the same program stopped as before; upon checking I was indeed
getting something different:

  (Pydb) import sys
  (Pydb) sys.version
  '2.5 (r25:51908, Sep 19 2006, 21:51:15) \n[GCC 4.1.0 (SUSE Linux)]'
  (Pydb) 

To get working from GNU/Emacs. First make sure you can do the
above. :-) Then it is just a matter of entering that location when
prompted. For example, I called the script /tmp/mypdb.sh So when I run
meta-x pydb, and it shows:

  Run pydb (like this): pydb
        
I just change "pydb" to  "/tmp/mpydb.sh /tmp/my-python-script"

The next time I issue M-x pydb though, I get: 

  Run pydb (like this): /tmp/mpydb /tmp/my-python-script

which seems to make sense.

iglen writes:
 > Hi 
 > 
 > I posted the same question on the discussion group, but then I have found
 > this mailing list. Sorry if someone stumble across my duplicate question,  
 >  
 > Previously I have been using pdb and typically write pdb shell script
 > somewhere in the path which would setup PYTHONPATH and invoke python2.4
 > pdb.py somefile.py. 
 >  
 > It does not look like there is a simular way to do it with Pydb. I have
 > tried creating Pydb which launch python2.4 pydb.py somefile.py but it does
 > not appear to work. 
 >  
 > Please help. 
 >  
 > -Len
 > 
 > 
 > -------------------------------------------------------------------------
 > 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=join.php&p=sourceforge&CID=DEVDEV
 > _______________________________________________
 > Bashdb-pydb mailing list
 > Bas...@li...
 > https://lists.sourceforge.net/lists/listinfo/bashdb-pydb
 > 

[Bashdb-pydb] How to add PYTHONPATH for Pydb emacs session

[iglen <ig...@ho...>]

Hi 

I posted the same question on the discussion group, but then I have found
this mailing list. Sorry if someone stumble across my duplicate question,  
 
Previously I have been using pdb and typically write pdb shell script
somewhere in the path which would setup PYTHONPATH and invoke python2.4
pdb.py somefile.py. 
 
It does not look like there is a simular way to do it with Pydb. I have
tried creating Pydb which launch python2.4 pydb.py somefile.py but it does
not appear to work. 
 
Please help. 
 
-Len

[Bashdb-pydb] Release 1.18 probably the week of Sept 25-29

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

If you can test from CVS please do. If you need a candidate tarball,
contact me. New to this release is thread debugging. It is
experimental and optional; to use you need to specifiy the --threading
option or add to your program: 
    import pydb; 
     set_trace(add_threaddbg=True)

Here are the NEWS entries for this release.

* Start thread debugging: 
    info thread [thread-name] [terse|verbose]    - show thread info
    thread [thread-name [thread-name]...]  - switches thread
    qt                                     - quit current thread
    can set a breakpoint on a specific thread name.

* GDB-like signal handling. Some code based on Matt Fleming's 2006
  Summer-of-Code project. Gdb's "handle" and "signal" commands.

* Add hard kill. May be needed for thread debugging.

* Fix bug in handling temporary breakpoints (tbreak) caused by the
  difference in semantics between pdb's 'clear' command and pdb's
  (which calls this 'delete' and has a different meaning for 'clear').

* 'examine' command now shows object's instance variables.

* add gdb 'FILE' command: allow loading/running a file from within
  pydb. (The old pydb from ddd had it too.)