hello,

I'm trying to embed a debugger into an editor.
I'm only interested in high level debugging.
The first question is what debugger is the best for my purpose ?
(pdb, pydb, rpdb2, smart debugger, extended debugger ?

Second question, in none of the above debuggers (except rpdb2),
I can find a "break now",
so it seems impossible to me to detect unlimited while loops ?

For the moment I started with pdb, because most of the debuggers seems
to be an extension on pdb.
When I launch the debugger ( winXP, Python 2.5) from with my editor
python -u -m pdb D:\\Data\\test_IDE.py
I get this error
IOError: (2, 'No such file or directory', 'D:\\Data\test_IDE.py')
NOTICE 1 backslash ----------------------------------^

If I launch the debugger with
python -u -m pdb D:/Data/test_IDE.py
It runs fine.

This looks like a bug to me.
What's the best way to report these kind of bugs ?

Although I mostly use os.path.join to be OS independent,
these kind of bugs give me the impression,
that I can better do the join myself and always use forward slashes.
Is this a valid conclusion ?

thanks,
Stef Mientki

On Sep 4, 4:22*pm, Stef Mientki <stef.mien...@gmail.comwrote:

hello,
>
I'm trying to embed a debugger into an editor.
I'm only interested in high level debugging.
The first question is what debugger is the best for my purpose ?
(pdb, pydb, rpdb2, smart debugger, extended debugger ?
>
Second question, in none of the above debuggers (except rpdb2),
I can find a *"break now",
so it seems impossible to me to detect unlimited while loops ?
>
For the moment I started with pdb, because most of the debuggers seems
to be an extension on pdb.
When I launch the debugger ( winXP, Python 2.5) from with my editor
* python -u -m pdb *D:\\Data\\test_IDE.py
I get this error
* IOError: (2, 'No such file or directory', 'D:\\Data\test_IDE.py')
NOTICE 1 backslash ----------------------------------^
>
If I launch the debugger with
* python -u -m pdb *D:/Data/test_IDE.py
It runs fine.
>
This looks like a bug to me.
What's the best way to report these kind of bugs ?
>
Although I mostly use os.path.join to be OS independent,
these kind of bugs give me the impression,
that I can better do the join myself and always use forward slashes.
Is this a valid conclusion ?
>
thanks,
Stef Mientki

Stef,

I discovered the same problem too with my editor. I solved it by
using only the file name, and setting the initial directory on the
executable.

For something pdb doesn't have, can you look at it yourself? Or, can
you write your own ad hoc, specialized to detecting while loops, using
settrace and 'except KeyboardInterrupt'?

castironpi <castironpi@gmail.comwrites:

On Sep 4, 4:22*pm, Stef Mientki <stef.mien...@gmail.comwrote:

>
Stef,
>
I discovered the same problem too with my editor. I solved it by
using only the file name, and setting the initial directory on the
executable.

I don't know if this helps, but in pydb there is an option to set the
initial directory the debugger works in. Inside the debugger there is
the gdb command "cd".

Stef Mientki <stef.mientki@gmail.comwrites:

hello,
>
I'm trying to embed a debugger into an editor.
I'm only interested in high level debugging.
The first question is what debugger is the best for my purpose ?
(pdb, pydb, rpdb2, smart debugger, extended debugger ?
>
Second question, in none of the above debuggers (except rpdb2),
I can find a "break now",
so it seems impossible to me to detect unlimited while loops ?

I am not sure what you mean by "break now". pdb and pydb allow direct
calls from a program to the debugger via set_trace (which in pydb is
deprecated in favor of I think the more descriptive name: debugger)

But I suspect this is not what you mean to "detect unlimited while
loops"; pydb also has gdb-style signal handling that allows for entry
into the debugger when the debugged python process receives a
particular signal. "info handle" lists all of the interrupts and what
action is to be taken on each. See
http://bashdb.sourceforge.net/pydb/pydb/lib/node38.html

However I believe that signals are only handled by the main thread; so
if that's blocked, the python process won't see the signal.

>
For the moment I started with pdb, because most of the debuggers seems
to be an extension on pdb.
When I launch the debugger ( winXP, Python 2.5) from with my editor
python -u -m pdb D:\\Data\\test_IDE.py
I get this error
IOError: (2, 'No such file or directory', 'D:\\Data\test_IDE.py')
NOTICE 1 backslash ----------------------------------^
>
If I launch the debugger with
python -u -m pdb D:/Data/test_IDE.py
It runs fine.
>
This looks like a bug to me.
What's the best way to report these kind of bugs ?

winpdb, pydb and pdb (part of Python) all have Sourceforge projects
which have bug trackers. For pdb, in the past people includng myself,
have reported features, patches and bugs in the Python tracker;
eventually it gets handled. (Eventually in my case means a year or
so.) But if my information is incorrect or out of date, no doubt
someone will correct me.

As mentioned in the last paragraph, pydb also is a Sourceforge project
(part of bashdb) which has a tracker for bug reporting. Using the bug
tracker I think is better than discussing pydb bugs in c.l.p. By
extension, I assume the same is also true for the other debuggers.

Finally, I think rpdb2 is part of the winpdb project on Sourceforge
and again has a bug tracker. My sense is that Nir Aides is very good
about handling bugs reported in winpdb/rpdb.

>
Although I mostly use os.path.join to be OS independent,
these kind of bugs give me the impression,
that I can better do the join myself and always use forward slashes.
Is this a valid conclusion ?
>
thanks,
Stef Mientki

R. Bernstein wrote:

Stef Mientki <stef.mientki@gmail.comwrites:
>
>

>
I am not sure what you mean by "break now". pdb and pydb allow direct
calls from a program to the debugger via set_trace (which in pydb is
deprecated in favor of I think the more descriptive name: debugger)
>
But I suspect this is not what you mean to "detect unlimited while
loops"; pydb also has gdb-style signal handling that allows for entry
into the debugger when the debugged python process receives a
particular signal. "info handle" lists all of the interrupts and what
action is to be taken on each. See
http://bashdb.sourceforge.net/pydb/pydb/lib/node38.html
>
However I believe that signals are only handled by the main thread; so
if that's blocked, the python process won't see the signal.
>

Thanks,
Yes, I think the trace option can do the job,
certainly if I display every line.
Didn't know pdb had something like settrace ( the information on pdb is
very condensed ;-)

>

>
winpdb, pydb and pdb (part of Python) all have Sourceforge projects
which have bug trackers. For pdb, in the past people includng myself,
have reported features, patches and bugs in the Python tracker;
eventually it gets handled. (Eventually in my case means a year or
so.) But if my information is incorrect or out of date, no doubt
someone will correct me.
>

I'll take a look, for the sake of our children ;-)

As mentioned in the last paragraph, pydb also is a Sourceforge project
(part of bashdb) which has a tracker for bug reporting. Using the bug
tracker I think is better than discussing pydb bugs in c.l.p.

c.l.p. ?

By
extension, I assume the same is also true for the other debuggers.
>
Finally, I think rpdb2 is part of the winpdb project on Sourceforge
and again has a bug tracker. My sense is that Nir Aides is very good
about handling bugs reported in winpdb/rpdb.
>

Yes I started with rpdb2,
and indeed Nir Aides is very helpfull,
but I think interfaceing rpdb2 is a little too difficult for me,
but I'll certainly add winpdb as the option for external debugging.

For now I think pydb is the choice,
better control and more functions than pdb,
and almost just as easy.

cheers,
Stef

>

--
http://mail.python.org/mailman/listinfo/python-list
>

Stef Mientki <stef.mientki@gmail.comwrites:

From: Stef Mientki <stef.mientki@gmail.com>
Subject: Re: pdb bug and questions
Newsgroups: comp.lang.python
To: "python-list@python.org" <python-list@python.org>
Date: Fri, 05 Sep 2008 22:06:19 +0200
>
R. Bernstein wrote:

Thanks,
Yes, I think the trace option can do the job,
certainly if I display every line.
Didn't know pdb had something like settrace ( the information on pdb
is very condensed ;-)

It sounds to me like there may be some confusion -- if at least on my
part. pdb's set_trace (with the underscore) is documented here:
http://docs.python.org/lib/module-pdb.html . Yes, perhaps it would be
nice if that document gave an example. But set_trace is a method call,
not an option.

There is a pydb debugger *command* called "set trace" as well as a
command-line option (-X --trace) which turns on line tracing and is
something totally different. It can be fun to use that with "set
linetrace delay" in an editor to allow one to watch the lines execute
as the program runs. I did this with emacs in this video:

http://showmedo.com/videos/video?nam...romSeriesID=28

I'll take a look, for the sake of our children ;-)

c.l.p. ?

This newsgroup, comp.lang.python.

Yes I started with rpdb2,
and indeed Nir Aides is very helpfull,
but I think interfaceing rpdb2 is a little too difficult for me,
>
For now I think pydb is the choice,
better control and more functions than pdb,
and almost just as easy.

If there are things that are unnecessarily awkward, and especially if
you can think of a way to make pydb better (that hasn't been suggested
before), please submit a feature request in the tracker for
pydb. Thanks.

R. Bernstein wrote:

I didn't notice your name before,
but I must say Rocky Bernstein is also very helpfull ;-)
thanks !!

For now I'm going to implement a simple interface between my program and
any debugger,
so I can easily change between the different debuggers.
And certainly I've still to read some more docs about the debuggers.

cheers,
Stef