Matthew Thornely has a very reasonable feature request form the debugger:
"Display the stack in a list control in a separate tab
on the Debugger Panel, similar to VisualStudio.
Double-clicking on an item in the stack list should
open the function at that stack level."
This goes a bit beyond the scrope of the current plugin, which is by no means meant to be a full scale debugger like you might find in eric3.
It seems to me that, with regards to future development of drpython, there are 3 major features that are missing:
1. A FullScale Debugger
2. A Project Manager
3. RAD for GUI Design
Here are my thoughts on them (at the moment):
1. Not worth it. This is a LOT of work, and I think eric3 has this covered perfectly.
2. Needed, but I am very lazy, so who knows when I might get to it?
3. I would like to add a plugin for wxGlade. I may actually get to this at some point (In the past, segfaults running wxGlade alone have put me off).
I've also been looking into spending some time working on wxPython itself. Depending on whether or not I want to play with c++ again, I was thinking about trying to tweak stc performance under GTK2. I also was looking at writing wxMouseGestures, and wxPieMenu classes.
Of course this could all be Py in the Sky.
1) I agree, this would be lot of work, and to reinvent
we could post a message to "Project Help wanted":
The first Python debugger fully written in wxPython and to integrate in drPython :)
I sometime fire up Hap Debugger, but the project has
stopped, and run only on Windows Platforms.
2) I use Sessions Manager and Find Files, and so
I (personally) don't see any need of project manager.
And if you open a file, the current directory is used
MouseGestures sounds cool.
what about winpdb? ... the forum is probably to old
1) Hmmmm... Perhaps see if we could port the eric3 debugger to wx? Perhaps a collaborative effort? I think a solid python debugger that is made gui independent would be ideal (so any editor out there could use it).
The project stopped for HAP? Bummer.
2) Yes, but it has been requested, and having integrated: to do list, changelog, project explorer, publish (zip/tar) options would be useful.
I actually plan on playing with MouseGestures before I start on 3.8.0.
>The project stopped for HAP? Bummer.
Sorry, I had the impression, and the last release
was one year ago.
From a post in their forum:
I haven't had time to do much with Hap for a while. Humongous has moved away from using Python as a primary part of its game development so I don't get paid to improve it anymore - I've also been really busy working on the next round of games.
If anyone is interested in helping contribute or maintain the project I'd be happy to give you rights to the SF page.
but i saw a new release on 15.December 2004
>1) Hmmmm... Perhaps see if we could port the eric3 debugger to wx?
I forget to say, wow, if a python-debugger with
wxPython could be realized, I think, you
will become history :)
From the gui a kind of visual c++ debugger?
I havn't been here for a long time, but I still care about this project. Because I'm busing in my own project NewEdit, and I can not catch your paces now.
But I want to say boa has a fully wxPython debugger. And I also want to have a debugger in my project, but the work will be harder, and I didn't want to copy all of the code from it. Maybe I can only write a simply debugger finally. :)
Oh yes, of course; I only forgot that.
But nevertheless, a debugger like that one in Visual Studio as standalone program or integrated in DrPython
would be awesome.
Hap Debugger seems pretty close to it.
Boa does have a fully wxPython debugger, and I could look into that. I am not sure how easy it would be to port it. Basically what I have in mind is a standard debugger (wxPythonDebugger.py) that you could drop into any wxpython program, and easily communicate with it. It is possible that more work could be done on SimpleDebugger, or that the Boa Debugger, Eric3 debugger, or HAP would be best.
The design goal is something any editor could use (for example, NewEdit or Pype) with the greatest ease possible.
by the way, its good to hear from you limodou. Out of curioisity, have you updated your project to use wxPython 2.5.x?
I should perhaps mention that I do not use debuggers.
I sort of did when I was first learning c++ in high school, but I quickly moved to debugging by printing to stdout, and have done so ever since (in c, c++, java, php, python, etc.). I find that thinking about the code, and what it does is far more beneficial that stepping through to find the error. With this in mind, when it comes time to have a feature list for what a debugger should do, I am definitely not the best person to write such a list!
So what should a debugger accomplish? What features should it have?
I'v review the debugger code of BOA. And I found that it uses client/server debug mode. The server has a connection layer, so the server can be different. And the server will run as a socket server implementing with simplexmlrpc(I think it'll simplify the function call). Is this can be seen standerd alone? If I want to implement myself debugger according to boa, and without copying all the code from it, I think it'll still harder to me. Because there are a lot of things I'll learning first.
My project can support 2.4 and 2.5. And I still use old event bind method(EVT_*).
BTW, I don't use any debugger either.
Sorry about the late response. Just got back from a nice long vacation.
I do use debuggers, in both C++ and Python. IMO, Visual Studio 6.0 is the best model on which to design a graphical debugger. HAP was based on Visual Studio, but has some problems (more than made up for by being free and open source!) I consider Boa a bad choice as a model for a debugger, at least from a graphical view point. I'll list specific criticisms if requested. Unfortunately, Eric3 is not really an option for most Windows users due to the QT licensing restrictions. I've yet to discover a real professional quality debugger for Python, which is why it would be a great pluggin for DrPython!
Here is my list of important features for a debugger. I'm only listing features that are not already available in Simple Debugger. I've also mentioned specific problems with HAP.
1. Break points:
a. Breakpoint manager window (very nice feature missing in HAP)
b. Conditional breakpoints (useful feature missing in HAP. Easy to work
around in Python)
c. Ability to temporarily disable breakpoints: Useful, but optional
2. Traceback Stack:
a. Stack displayed in a list
Note: The method of displaying the stack in HAP is not so good
b. clicking on an item in the list sets the current context
Note: This feature works only partially in HAP. Clicking on a stack
item sets the file and line number correctly, but the context does
not change, making it impossible to view local variables at various
locations in the stack.
3. Watch windows:
a. Elements to display in a watch window can be dragged 'n' dropped
from the editor. (doesn't work in HAP).
b. Multiple watch windows using a tab control (only a single watch window
c. Note: Having a window that displays all local and/or global variables is
less useful than programmable watch windows. Actually, if there are a
lot of globals and/or local variables, then displaying them will
destroy the performance of the debugger.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.