Python Debugger

[dmoore]

I'm finally starting to revise the python debugger again. I plan to post questions and issues re using the new debugger API here (mostly intended for obfuscated).

To test:
1. Checkout the code to your contrib directory (this assumes you are using C::B to build C::B and the plugins)

Code: [Select]

svn checkout http://svn.berlios.de/svnroot/repos/cbilplugin/trunk/PythonDebugger

2. When you build the project within C::B it will install itself into devel like any other contrib plugin.

3. Make sure python is in your path

4. Open a sample python program

5. Set Python Debugger as the active debugger: Debug -> Active Debuggers -> PyDebugger

6. F8 will start debugging on the python program in the active editor (I may add python project support later), F7 to step through the code, F4 to run to cursor etc

Stepping through code, call stack and breakpoints all sort of work. Using the watch will crash C::B (still working on it) Watch now sort of working (shows children (but not children of children), no changing of values)

[oBFusCATed]

1. Checkout the code to your contrib directory (this assumes you are using C::B to build C::B and the plugins)

Code: [Select]

svn checkout http://svn.berlios.de/svnroot/repos/cbilplugin/trunk/PythonDebugger
2. When you build the project within C::B it will install itself into devel like any other contrib plugin.

This is a part of C::B development I dislike, too much.
You can inspect my plugin to how I workaround this project and how I'm able to develop plugins without the need to put them in the contrib dir.
I even have an autotools system.

Here is a link to the plugin: svn://cmpt.benbmp.org/cb_gdb_mi/debbugger_gdbmi

[dmoore]

1. Checkout the code to your contrib directory (this assumes you are using C::B to build C::B and the plugins)

Code: [Select]

svn checkout http://svn.berlios.de/svnroot/repos/cbilplugin/trunk/PythonDebugger
2. When you build the project within C::B it will install itself into devel like any other contrib plugin.

This is a part of C::B development I dislike, too much.

Actually, my description wasn't quite right. You don't have to install to checkout to the contrib dir, what you do have to do is set a "cb" global variable that points to the C::B source location. The plugin will be deployed into the devel folder there. (I may have broken something on Windows, so you may actually need to put it in the contrib dir.) I prefer to do my development this way because it means I can tinker with C::B sources as I develop my plugins.

I treat autotools like plague. (They're great, just not for me.)

Thanks for the link.

[oBFusCATed]

I treat autotools like plague. (They're great, just not for me.)

It turned out that it is not that bad and it is the only (sensible) choice if you want to deploy free/open software on linux

[dmoore]

I treat autotools like plague. (They're great, just not for me.)

It turned out that it is not that bad and it is the only (sensible) choice if you want to deploy free/open software on linux

Absolutely agree. But never had the time to really understand it, and not sure I ever will. I don't do enough C/C++ development, or more specifically C/C++ deployment, to make it worthwhile. More to the point, on the C/C++ projects I've been involved in there's always someone who knows how to do it that's not me. And it doesn't stop there: if you want to deploy you have to understand package management as well. (I still have the scars from setting up a launchpad PPA -- aargh!). Keep in mind, my day job has next to nothing to do with software development.

Not to say that I am not willing to learn, just that I think I have better things to do. Are there any better guides than this one? http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool

PS: Updated the python debugger to support expanding the watch (not fully functional yet)

[oBFusCATed]

I read this http://www.flameeyes.eu/autotools-mythbuster/ it is modern docs for autotools, most of the info in the internet is hard to read and this is the major reason for autotools been not well understood by people.

[Alpha]

(I may add python project support later)

When/if this occurs, know that you have an interested user .

[dmoore]

(I may add python project support later)

When/if this occurs, know that you have an interested user .

Cool. Are you already developing Python projects in C::B? If so, how are you setting them up? (In the past I have simply used the file manager plugin to browse my python sources instead of setting up dedicated projects, but recently started creating projects with a target specifying the main script. I assume you would want the debugger to be able to start a debug session on this target? Anything else?)

Btw, this looks like an easy way to get python autocompletion into C::B: http://code.google.com/p/pysmell/
Hasn't been updated in a long time (2008), but the sources aren't terribly complicated

Re the Debugger (for obfuscated): Still stuck implementing watches. I get a crash every time I try to expand any watch that isn't the first watch item. This could be just something stupid on my part, but I suspect I may not be using cb::shared_ptr correctly. (my watch is derived from cbWatch, and there are lots of cb::shared_ptr<cbWatch> instances passed around that point to instances of my derived class)

[oBFusCATed]

Re the Debugger (for obfuscated): Still stuck implementing watches. I get a crash every time I try to expand any watch that isn't the first watch item. This could be just something stupid on my part, but I suspect I may not be using cb::shared_ptr correctly. (my watch is derived from cbWatch, and there are lots of cb::shared_ptr<cbWatch> instances passed around that point to instances of my derived class)

I have to check it, but I have no time at the moment, unfortunately.
But cb::shared_ptr<Base> supports managing Derived objects, but you have to have a virtual destructor.

[Alpha]

Are you already developing Python projects in C::B?

Not exactly; I more use Code::Blocks as an editor for individual Python files if it happens to already be open (which is most of the time).  For more significant Python work, I often use Eclipse, however, it is never fun trying to make an elephant dance, and I would like to transition my work to Code::Blocks as soon as it appears to have a minimum subset of features.
I have not had the chance to explore your plugin's capabilities yet, but yes, target aware debug sessions, and (essentially) the same other features of the current gdb debugger interface (I did not check to see how many of these you have created yet).

Other features that would be nice (though do not necessarily belong in this plugin) are a build target type of "MIME" (or "Other" or "Script") that will poll all applicable plugins to see if any of them support this target (probably by scanning file extensions) - the plugin would then take over building/running related operations (this would give a more seamless use than the workarounds currently required for languages that do not follow compile-link-run and allow users to remove any that were unnecessary), and code completion.  I will probably try my hand at working on these when I have enough time.  (These are just ideas, I am not expecting you to work on any of them, unless, of course, you want to.)

[dmoore]

Re the Debugger (for obfuscated): Still stuck implementing watches. I get a crash every time I try to expand any watch that isn't the first watch item. This could be just something stupid on my part, but I suspect I may not be using cb::shared_ptr correctly. (my watch is derived from cbWatch, and there are lots of cb::shared_ptr<cbWatch> instances passed around that point to instances of my derived class)

I have to check it, but I have no time at the moment, unfortunately.
But cb::shared_ptr<Base> supports managing Derived objects, but you have to have a virtual destructor.

Fixed. Stupid mistake on my part. (Missing braces around an if statement block -- too much python!). Code appears to work fine even without a destructor.

BTW, why in some places do you use cb::shared_ptr<OBJECT> and in others OBJECT::Pointer? I like the latter a lot more and would prefer to see it everywhere that you currently have cb::shared_ptr. Also, is it necessary to defined DerivedClass::Pointer (e.g. PyWatch::Pointer). Code seems to run fine even if it is not defined explicitly, since it gets derived from the base (cbWatch::Pointer).

[oBFusCATed]

dmoore: What are these places?

Probably one reason is that cb::shared_ptr<Object> compiles and works even if Object is forward declared.
Object::Pointer works only if you have the full declaration of Object and Object::Pointer can't be forward declared.

[dmoore]

dmoore: What are these places?

virtual methods in cbDebuggerPlugin

Probably one reason is that cb::shared_ptr<Object> compiles and works even if Object is forward declared.
Object::Pointer works only if you have the full declaration of Object and Object::Pointer can't be forward declared.

So you save yourself a #include in cbplugin.h, but then any debugger plugin will need that #include to implement their derived classes. Not sure I see the real advantage in doing it this way. (Why bother defining cbWatch::Pointer at all if it isn't going to be used consistently in the public facing part of the API?)

[oBFusCATed]

I think these have been added as work-arounds for the impossibility to forward declare them.
The thing is that if you can forward declare something you should do it.
This saves compilation time and minimizes the include statements in headers.
C::B is pretty bad in this regard by the way...

[dmoore]

I think these have been added as work-arounds for the impossibility to forward declare them.
The thing is that if you can forward declare something you should do it.
This saves compilation time and minimizes the include statements in headers.
C::B is pretty bad in this regard by the way...

The C::B way has been to adopt very similar coding standards to wxWidgets with all its legacy issues. I understand that there is some compile time efficiency gain to structuring your code like this, but IMHO it does not aid readability/manageability of code.

Anyway, I think there must be a better way of doing this than having two different but equivalent definitions for the pointer floating around. For me, any of these would be better:

a) use cb::shared_ptr everywhere
b) declare simple typedefs instead of defining the pointers as static class members (typedef cb::shared_ptr<cbWatch> cbWatchPtr)
c) do it more like the old C::B/wx way: pass around regular pointers.

If you don't like (c) then shouldn't we have an overall plan for moving away from old-style pointers in C::B? Having a patchwork of old and new style code is a mess.