Code::Blocks

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: dmoore on July 25, 2012, 03:55:40 am

Title: Python Debugger
Post by: dmoore on July 25, 2012, 03:55:40 am
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)
Title: Re: Python Debugger
Post by: oBFusCATed on July 25, 2012, 09:29:06 am
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
Title: Re: Python Debugger
Post by: dmoore on July 25, 2012, 01:11:21 pm
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.
Title: Re: Python Debugger
Post by: oBFusCATed on July 25, 2012, 03:11:47 pm
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
Title: Re: Python Debugger
Post by: dmoore on July 25, 2012, 06:04:25 pm
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)
Title: Re: Python Debugger
Post by: oBFusCATed on July 25, 2012, 06:17:03 pm
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.
Title: Re: Python Debugger
Post by: Alpha on July 26, 2012, 06:14:04 pm
(I may add python project support later)
When/if this occurs, know that you have an interested user :).
Title: Re: Python Debugger
Post by: dmoore on July 27, 2012, 04:45:31 pm
(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)
Title: Re: Python Debugger
Post by: oBFusCATed on July 27, 2012, 04:56:00 pm
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.
Title: Re: Python Debugger
Post by: Alpha on July 28, 2012, 04:27:57 am
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.)
Title: Re: Python Debugger
Post by: dmoore on July 30, 2012, 06:40:46 pm
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).
Title: Re: Python Debugger
Post by: oBFusCATed on July 30, 2012, 08:13:01 pm
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.
Title: Re: Python Debugger
Post by: dmoore on July 30, 2012, 09:28:14 pm
dmoore: What are these places?

virtual methods in cbDebuggerPlugin

Quote
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?)
Title: Re: Python Debugger
Post by: oBFusCATed on July 30, 2012, 10:40:11 pm
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...
Title: Re: Python Debugger
Post by: dmoore on July 31, 2012, 03:39:30 pm
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.
Title: Re: Python Debugger
Post by: oBFusCATed on July 31, 2012, 04:04:17 pm
a) sounds like the way to go.
b) is not possible, because typedefs can't be forward declared, too.
c) won't be discussed at all, because it will make the code harder to maintain and will probably cause lots of memory leaks.
Title: Re: Python Debugger
Post by: dmoore on July 31, 2012, 05:30:55 pm
a) sounds like the way to go.
b) is not possible, because typedefs can't be forward declared, too.

I had no problems with (b):

Code: [Select]
#include <cbplugin.h>

typedef cb::shared_ptr<cbWatch> cbWatchPtr; // <-- This compiles fine
typedef cbWatch::Pointer cbWatchPtr2; // <--- This is an error
Title: Re: Python Debugger
Post by: oBFusCATed on July 31, 2012, 05:49:25 pm
The thing is that if we want to put typedef at the correct place (debuggermanager.h), we can't because forwarding typedefs doesn't work.
Title: Re: Python Debugger
Post by: dmoore on July 31, 2012, 06:14:06 pm
The thing is that if we want to put typedef at the correct place (debuggermanager.h), we can't because forwarding typedefs doesn't work.

Well you could do this

Code: [Select]
//debugger_pointers.h
class cbWatch;
typedef cb::shared_ptr<cbWatch> cbWatchPtr;
class cbBreakpoint;
typedef cb::shared_ptr<cbBreakpoint> cbBreakpointPtr;
...

//debuggermanager.h
#include "debugger_pointers.h"

//cbplugin.h
#include "debugger_pointers.h"

 ;)
Title: Re: Python Debugger
Post by: oBFusCATed on July 31, 2012, 07:06:18 pm
Yes, of course, if you have time and desire you can do it, too :)
Title: Re: Python Debugger
Post by: dmoore on August 08, 2012, 08:59:07 pm
Added a couple of small updates to the svn which fixed performance when expanding a watch item to show object members. It turns out that Regex can have really poor performance on seemingly simple searches.

Yes, of course, if you have time and desire you can do it, too :)

I played around with this:

Code: [Select]
class cbWatch;
typedef cb::shared_ptr<cbWatch> cbWatchPtr;

and (and as I suspect you already knew) it doesn't really help all that much, because at times you want cb::shared_ptr<Derived Class> instead, and so each plugin would need to define those typedefs as well.

Things I don't like about the current implementation stand:
1/ It is confusing to refer to shared_ptr in some places and someclass::pointer in other places
2/ typedef shared_ptr<cbWatch> Pointer doesn't correctly inherit for derived classes (i.e. derived class still needs to define its own Pointer)
3/ someclass::pointer obscures that fact that this is a shared_ptr not a "*". (The implementation details matters when it comes time to clean up.)

Wouldn't the need for the plugin writers to use shared_ptr go away if the framework instead of the plugin provided the containers for the various lists of items. (Perhaps using a class template?)
Title: Re: Python Debugger
Post by: oBFusCATed on August 08, 2012, 09:13:24 pm
Wouldn't the need for the plugin writers to use shared_ptr go away if the framework instead of the plugin provided the containers for the various lists of items. (Perhaps using a class template?)
I'm not sure what are you talking exactly.

For the typedef you can try to remove it, I have no problem with it. And if it is confusing for you it will be for other, so removing the typedef is the only way forward.
Title: Re: Python Debugger
Post by: Falldog on August 18, 2012, 03:08:23 am
How can I build it in Windows?
Title: Re: Python Debugger
Post by: dmoore on August 18, 2012, 04:04:21 pm
How can I build it in Windows?

What have you tried?

There is a windows project file (cbp) but it may not be completely up to date (some tweaks required).

The most straightforward way is to start by compiling and running cb itslef from svn sources (see the wiki). Then copy the debugger code to src/plugins/contrib and try to build it from the provided project file. If you have problems let me know.
Title: Re: Python Debugger
Post by: Falldog on August 19, 2012, 04:09:08 pm
What have you tried?
There is a windows project file (cbp) but it may not be completely up to date (some tweaks required).
The most straightforward way is to start by compiling and running cb itslef from svn sources (see the wiki). Then copy the debugger code to src/plugins/contrib and try to build it from the provided project file. If you have problems let me know.
Thanks,
I had build it success,
And run in CB from output/, try edit a .py file, set PythonDebugger as active debugger,
1. I try to setting PythonDebugger info from Settings|Debugger|PyDebugger, it display nothing to setup, how can I setup the python path or other setting?
2. I don't know how to debug and set break point on PythonDebugger.dll,
   I run CB by CB, and set break point on PythonDebugger source code, it doesn't break on any break points.
   I run a CB, and try to run another CB(fail to launch 2 CB?) for attach process to debug -> fail
   How to debug on PythonDebugger plugin?
 ???

Thanks
Title: Re: Python Debugger
Post by: dmoore on August 19, 2012, 06:38:53 pm
Thanks,
I had build it success,

Good news!

Quote
And run in CB from output/, try edit a .py file, set PythonDebugger as active debugger,
1. I try to setting PythonDebugger info from Settings|Debugger|PyDebugger, it display nothing to setup, how can I setup the python path or other setting?

Not available yet. By default it uses the path of the script. If you need something else, as a workaround use os.chdir in your script.  I plan to add support for running pdb on the current target (if the current target is a python script) which will allow you to set per target options like command line args and working directories.

Quote
2. I don't know how to debug and set break point on PythonDebugger.dll,
   I run CB by CB, and set break point on PythonDebugger source code, it doesn't break on any break points.

Are you trying to debug python sources or C++ sources? It will only work on python sources.

Quote
  I run a CB, and try to run another CB(fail to launch 2 CB?) for attach process to debug -> fail
   How to debug on PythonDebugger plugin?
 ???

Thanks

Not sure what you are trying to do here. It sounds like you are trying to debug the debugger?
Title: Re: Python Debugger
Post by: Falldog on August 20, 2012, 04:22:01 am
Hi dmoore,
I am trying to modify PythonDebugger, so I want to debug the PythonDebugger source code(worte by you)
I had little experience on modify HAP Debuggerhttp://hapdebugger.sourceforge.net/ (http://hapdebugger.sourceforge.net/), but it only work on Windows :'(

So I try to use CB as IDE to develop PythonPlugin, just like you do.
But I am a newer of CB, don't know how to debug for the PythonDebugger

Please help to share that how to debug the PythonDebugger plugin, I will try to trace how it work and try add some features
 :)
Thanks a lot
Title: Re: Python Debugger
Post by: dmoore on August 20, 2012, 05:09:52 am
Please help to share that how to debug the PythonDebugger plugin, I will try to trace how it work and try add some features

Sounds good. Quite a bit of work still needed :)

Re your debugging problem, it may be a bad setup in the PyDebugger project file. After you compile the plugin try switching back to CB project and debugging the default target.

Assume you were able to use the plugin to debug a python script.

Have you seen rpdb2? Eventually I want to use that (or something better) instead of pdb.
Title: Re: Python Debugger
Post by: Falldog on August 22, 2012, 02:37:00 am
Sounds good. Quite a bit of work still needed :)
Re your debugging problem, it may be a bad setup in the PyDebugger project file. After you compile the plugin try switching back to CB project and debugging the default target.
Assume you were able to use the plugin to debug a python script.
Have you seen rpdb2? Eventually I want to use that (or something better) instead of pdb.

Thanks a lot, I can trace CB & PyDebugger now
It's so stupid issue I meet, I try to trace code by "Run" not "Debug&Continue" ...  :-[

I doesn't know what is rpdb2... @@
I just study, maybe rpdb2 and pydb is good choice
Title: Re: Python Debugger
Post by: Falldog on September 21, 2012, 05:43:44 am
Please help to share that how to debug the PythonDebugger plugin, I will try to trace how it work and try add some features

Sounds good. Quite a bit of work still needed :)

Re your debugging problem, it may be a bad setup in the PyDebugger project file. After you compile the plugin try switching back to CB project and debugging the default target.

Assume you were able to use the plugin to debug a python script.

Have you seen rpdb2? Eventually I want to use that (or something better) instead of pdb.

hi dmoore,
I had modify some code to apply rpdb2
how can I provide it to you for review it?
I create the patch by Git, but it's size over the post maximum
Title: Re: Python Debugger
Post by: oBFusCATed on September 21, 2012, 08:45:08 am
I create the patch by Git, but it's size over the post maximum
You can pastebin it somewhere or you can post it in the patch tracker.
By the way - have you tried to zip it?
Title: Re: Python Debugger
Post by: Falldog on September 21, 2012, 12:28:27 pm
I create the patch by Git, but it's size over the post maximum
You can pastebin it somewhere or you can post it in the patch tracker.
By the way - have you tried to zip it?

Quote

Dear oBFusCATed,
you are so smart!
Thanks! XD

The patch include some python files, I don't know how to pack it for run-time use
Current stage, only can run in fix path of rpdb2.py (Please modify the EXECUTE_CMD macro in PyDebugger.cpp)
Non-finish work : watch children, and thread list

[attachment deleted by admin]
Title: Re: Python Debugger
Post by: dmoore on September 21, 2012, 03:25:58 pm
I haven't run it yet, but looking at the patch this looks very nice indeed! Some nice clean up of my ugly code too :)

One minor question is why not use something like XMLRPC instead of socket libs to make the remote calls back and forth a bit cleaner? (Built into python, a few options for C++, but nothing wxWidgets specific, I guess). I have some experimental code for a python interpreter around that uses XMLRPC.

This one looks like it has a simple API: http://xmlrpc-c.sourceforge.net/example-code.php
Title: Re: Python Debugger
Post by: Falldog on September 21, 2012, 04:51:13 pm
I haven't run it yet, but looking at the patch this looks very nice indeed! Some nice clean up of my ugly code too :)

One minor question is why not use something like XMLRPC instead of socket libs to make the remote calls back and forth a bit cleaner? (Built into python, a few options for C++, but nothing wxWidgets specific, I guess). I have some experimental code for a python interpreter around that uses XMLRPC.

This one looks like it has a simple API: http://xmlrpc-c.sourceforge.net/example-code.php
ya, you look at the good point,
I implement it in short term way,
maybe json or XMLRPC is good way in future.
I would like to use json (because I am not familiar with XMLRPC ...)
I had use json to handle socket related communication, and python had good support and easy with it

On the other, I am wondering about performance of current implementation in socket,
Maybe use pipe is better!?

And... may I use the open source code(like rpdb2 or JsonCpp) directly in CB?
I am not sure the licence is okay...
Title: Re: Python Debugger
Post by: oBFusCATed on September 21, 2012, 07:55:45 pm
And... may I use the open source code(like rpdb2 or JsonCpp) directly in CB?
I am not sure the licence is okay...
It depends on the future goals for the plugin. If you'd want to add it to our repo minimizing the dependencies should be your priority. Otherwise you can use whatever you want.
Title: Re: Python Debugger
Post by: dmoore on September 21, 2012, 08:54:01 pm
And... may I use the open source code(like rpdb2 or JsonCpp) directly in CB?
I am not sure the licence is okay...
It depends on the future goals for the plugin. If you'd want to add it to our repo minimizing the dependencies should be your priority. Otherwise you can use whatever you want.

If we plan to add more support for python (e.g. code completion) then it might make more sense to do stuff outside of contrib and then use whatever dependencies we need to get the job done efficiently. The fortran plugin, which is maintained in an external repo but linked to contrib might be a good model for what to do here. I suspect that C/C++ will always be the core focus of mainline C::B development.

I don't think licenses of the libs we've mentioned should be an issue. They are all MIT/BSD.

On the other, I am wondering about performance of current implementation in socket,
Maybe use pipe is better!?

I doubt it would make all that much difference for this application, but I don't know for sure. Can jsonrpc be configured to use a pipe instead of socket? (something like this (http://code.google.com/p/pipe-rpc/))
Title: Re: Python Debugger
Post by: oBFusCATed on September 21, 2012, 09:32:04 pm
I suppose having more languages supported in the main repo is better in terms of designing things.
I've not tried the fortran stuff, but I'm sure it does some hacks or duplicates features that are C/C++ only.

At the place I work most of the software is a mix of c++ and python, so getting python support integrated
in the IDE will be good for me. No matter I don't like python too much.

About the code-completion: We have to thing how to make an API for different languages or implementations.
Title: Re: Python Debugger
Post by: dmoore on September 21, 2012, 09:51:10 pm
I suppose having more languages supported in the main repo is better in terms of designing things.
I've not tried the fortran stuff, but I'm sure it does some hacks or duplicates features that are C/C++ only.

good point

Quote
About the code-completion: We have to thing how to make an API for different languages or implementations.

Yes. Would require something analogous to your debugger work, I guess. Alternatively, we could just find some way to add language modules to the current codecompletion plugin.
Title: Re: Python Debugger
Post by: oBFusCATed on September 21, 2012, 10:03:31 pm
Alternatively, we could just find some way to add language modules to the current codecompletion plugin.
But then you'll need to implement plugins inside the CC plugin, which doesn't sound nice. If it is common code or UI it should be move in the SDK.
Title: Re: Python Debugger
Post by: MortenMacFly on September 21, 2012, 10:24:04 pm
At the place I work most of the software is a mix of c++ and python, so getting python support integrated
in the IDE will be good for me. No matter I don't like python too much.
No, its quite nice separated. The last separation missing comes with the patch of danslemi nobody takes care of: To make indention become a plugin. I wonder wy nobody says "please commit!". I did - because this one of the last pieces missing for being able to support several languages and having separated their "specialities" just nice...

Please vote for danselmi - its all I can say...
Title: Re: Python Debugger
Post by: oBFusCATed on September 21, 2012, 10:45:08 pm
Morten: How they separate the codecompletion? There is no API for the symbol browser, nor for the toolbar, nor for the auto complete list...
Title: Re: Python Debugger
Post by: Alpha on September 22, 2012, 12:17:42 am
I just thought I would mention, as there was some talk of possibly needing to parse JSON, that wxJSON (http://luccat.users.sourceforge.net/wxjson/) has worked quite well when I have used it.
Title: Re: Python Debugger
Post by: oBFusCATed on September 22, 2012, 12:41:40 am
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.
I've switched all the code to cb::shared_ptr. Probably the plugin will fail to build, so it will need some fixing. Both gdb plugins have been fixed.
Title: Re: Python Debugger
Post by: Falldog on September 22, 2012, 01:47:17 am
I doubt it would make all that much difference for this application, but I don't know for sure. Can jsonrpc be configured to use a pipe instead of socket? (something like this (http://code.google.com/p/pipe-rpc/))

It seem to use socket for rpc, no matter in json or xml
I would like to implement in simple communication by socket or pipe? (just read/write). and message data structure in json
It maybe work!? ::)
Title: Re: Python Debugger
Post by: Falldog on September 22, 2012, 01:50:23 am
I just thought I would mention, as there was some talk of possibly needing to parse JSON, that wxJSON (http://luccat.users.sourceforge.net/wxjson/) has worked quite well when I have used it.

it's good news for using wxJson in CB, it seem not merge in wxWidgets core
I should add these files directly in project!?
Title: Re: Python Debugger
Post by: dmoore on September 22, 2012, 01:54:27 am
quote]
it's good news for using wxJson in CB, it seem not merge in wxWidgets core
I should add these files directly in project!?

For now, yes. I hope to test what you have done so far over the weekend.
Title: Re: Python Debugger
Post by: dmoore on September 22, 2012, 01:13:24 pm
I tested briefly last night. No problems compiling. So far, two issues:

1. The debugger always wants to run the same script. (Perhaps this is my fault)
2. On Linux, the target just runs to completion without stopping at a breakpoint and then drops to the gnome terminal. What features are supposed to work?
Title: Re: Python Debugger
Post by: Falldog on September 22, 2012, 03:06:49 pm
I tested briefly last night. No problems compiling. So far, two issues:

1. The debugger always wants to run the same script. (Perhaps this is my fault)
2. On Linux, the target just runs to completion without stopping at a breakpoint and then drops to the gnome terminal. What features are supposed to work?
thanks for your reply,
I attached the patch just for you to review the architecture, I doesn't refine my code yet....
I think current solution is okay for now, but I should wrapper the data structure by json
maybe wait me to modify the code to stable, then I will patch again

The Linux problem, I think it may be the path compare issue, I will prepare Linux environment to test it until I refined my code
Title: Re: Python Debugger
Post by: Falldog on October 02, 2012, 11:29:54 am
Where can I put the xxx.py for PyDebugger to use it?
It need the py file when deubgger run with python
zip file seems only for xrc file

Or just create a folder "PyDebugger" under CB::share/CodeBlocks/plugin when release to general user?
Title: Re: Python Debugger
Post by: dmoore on October 03, 2012, 02:10:10 am
Use "extra files"

See here: http://forums.codeblocks.org/index.php/topic,6338.0.html

(I never did finish that wiki page  :-[ )
Title: Re: Python Debugger
Post by: Falldog on October 10, 2012, 03:29:17 am
Dear dmoore,

I had refine my code in new patch
* Fix - Linux breakpoint issue
* Add Debugger setting panel
* Communicate with python debug server in JSON
* Refine watch children mechanism (not perfect yet, update when call stack updated)
* Support thread list
* Run time will read the python files from $(cb)\share\CodeBlocks\python\PyDebugger
* Add update.py for copy python files into devel/output for debugging

[attachment deleted by admin]

[attachment deleted by admin]
Title: Re: Python Debugger
Post by: dmoore on October 11, 2012, 10:20:39 pm
Dear dmoore,

I had refine my code in new patch
* Fix - Linux breakpoint issue
* Add Debugger setting panel
* Communicate with python debug server in JSON
* Refine watch children mechanism (not perfect yet, update when call stack updated)
* Support thread list
* Run time will read the python files from $(cb)\share\CodeBlocks\python\PyDebugger
* Add update.py for copy python files into devel/output for debugging

Thanks. I'll try to test it out in the next week or so. Why are there two patch files?
Title: Re: Python Debugger
Post by: Falldog on October 13, 2012, 03:47:32 pm
Thanks. I'll try to test it out in the next week or so. Why are there two patch files?
I had merge local commit in this patch, but file too large(more than maximun attachment), I separate in 2 rar files

[attachment deleted by admin]
Title: Re: Python Debugger
Post by: dmoore on October 13, 2012, 03:57:42 pm
Thanks. I'll try to test it out in the next week or so. Why are there two patch files?
I had merge local commit in this patch, but file too large(more than maximun attachment), I separate in 2 rar files

Maybe you should put the code on a public repo?
Title: Re: Python Debugger
Post by: Falldog on October 13, 2012, 04:14:09 pm
Thanks. I'll try to test it out in the next week or so. Why are there two patch files?
I had merge local commit in this patch, but file too large(more than maximun attachment), I separate in 2 rar files

Maybe you should put the code on a public repo?
Do you mean that I create another my own repo to maintain these code?  ???
Title: Re: Python Debugger
Post by: dmoore on October 13, 2012, 04:28:11 pm
Do you mean that I create another my own repo to maintain these code?  ???

Yes, just because it is any easy way to share the code that you are working on. Of course, I will be happy to merge it into mine when you think its ready. Alternatively, you are welcome to use a branch of my Berlios repo if you have an account there. But repos are cheap. Without too much hassle, you can sign up at github or launchpad and get free repo public space that I and others can pull from.
Title: Re: Python Debugger
Post by: Falldog on October 13, 2012, 04:54:54 pm
Yes, just because it is any easy way to share the code that you are working on. Of course, I will be happy to merge it into mine when you think its ready. Alternatively, you are welcome to use a branch of my Berlios repo if you have an account there. But repos are cheap. Without too much hassle, you can sign up at github or launchpad and get free repo public space that I and others can pull from.

It sounds great! I think I will create a github account to do it. :)

And next step, I think I will try to study wizard script, and create PyDebugger project wizard for save PyDebugger own project
Any suggestion?
Title: Re: Python Debugger
Post by: MortenMacFly on October 14, 2012, 07:41:03 am
It sounds great! I think I will create a github account to do it. :)
For the record: I personally prefer SVN repos, because these we can integrate as "external" repo into the C::B repo. This allows the devs to stay independent but us/users to checkout the whole stuff.

At least this is true as long as we stick with SVN.
Title: Re: Python Debugger
Post by: dmoore on October 14, 2012, 04:43:26 pm
It sounds great! I think I will create a github account to do it. :)
For the record: I personally prefer SVN repos, because these we can integrate as "external" repo into the C::B repo. This allows the devs to stay independent but us/users to checkout the whole stuff.

At least this is true as long as we stick with SVN.

I plan to merge his stuff when it is ready into my SVN on berlios. In the meantime it is better for him to use *any* repo as opposed to just posting patches here. If you want, Morten, I can setup a python area of my berlios SVN repo (a tidy up of my trunk is long overdue) that C::B can pull from. This would be a combination of several plugins (embedded interpreter, code completion, debugger), but I guess I could combine them into a single C::B project with multiple plugin targets?
Title: Re: Python Debugger
Post by: dmoore on October 14, 2012, 05:22:51 pm
Thanks. I'll try to test it out in the next week or so. Why are there two patch files?
I had merge local commit in this patch, but file too large(more than maximun attachment), I separate in 2 rar files

Ok, I briefly tested this one. You should add a post build step to the project to copy the python files to the right place. You also missed XRC file in your zip command on Linux.

BTW, using  wxString rpdb_wrap_path = ConfigManager::GetDataFolder() + _T("/python/PyDebugger/rpdb_wrap.py");, you should test GetDataFolder with true and false. Depending on the setup, the python files could be installed to a global or local place.

I didn't have time to make these fixes myself, but I will take another look later. I did successfully compile the project.
Title: Re: Python Debugger
Post by: MortenMacFly on October 15, 2012, 07:35:23 am
If you want, Morten, I can setup a python area of my berlios SVN repo (a tidy up of my trunk is long overdue) that C::B can pull from. This would be a combination of several plugins (embedded interpreter, code completion, debugger), but I guess I could combine them into a single C::B project with multiple plugin targets?
As you like. I would leave them separated, unless they share some code base. Embedding external repos, or even sub-path's of repos is easy. So we can also embed only "http://svn.repo.com/trunk/sub/folder", if desired. Make up your mind and let me know when the time has come.
Title: Re: Python Debugger
Post by: oBFusCATed on October 15, 2012, 05:34:31 pm
For the python debugger or any other debugger my preference would be to integrate it/them directly in the repo, when they are ready to be used by normal people.
A path like src/plugins/debuggers/ sounds great to me :)
Title: Re: Python Debugger
Post by: Falldog on October 16, 2012, 02:40:08 am
Ok, I briefly tested this one. You should add a post build step to the project to copy the python files to the right place. You also missed XRC file in your zip command on Linux.

BTW, using  wxString rpdb_wrap_path = ConfigManager::GetDataFolder() + _T("/python/PyDebugger/rpdb_wrap.py");, you should test GetDataFolder with true and false. Depending on the setup, the python files could be installed to a global or local place.

I didn't have time to make these fixes myself, but I will take another look later. I did successfully compile the project.

hi dmoore,
thanks for your review

1. I did forgot add XRC into zip command in Linux
    Does the zip file should include extra files? It seem only need be included in zip only when install the plugin?
2. I doesn't familiar with ConfigManager::GetDataFolder(bool global), does you mean plugin extra files may be installed at local or global place after setup. So I need to test it with true/false to make sure the file exist?
sample code like:
     wxFileName rpdb_wrap_file_global( ConfigManager::GetDataFolder(true) + _T("/python/PyDebugger/rpdb_wrap.py") );
     wxFileName rpdb_wrap_file_local( ConfigManager::GetDataFolder(false) + _T("/python/PyDebugger/rpdb_wrap.py") );
     wxString rpdb_file_path;
     if(rpdb_wrap_file_global.FileExists()) rpdb_file_path = rpdb_wrap_file_global.GetFullPath();
     else if(rpdb_wrap_file_local.FileExists()) rpdb_file_path = rpdb_wrap_file_local.GetFullPath();

3. I compile project in windows will successful, but compile in Linux will treat warning as error, should I add some definition for Linux project to avoid the warning as error?
   Or I should fix all warning... ???, (most of the warning come from external library wxJson)
Title: Re: Python Debugger
Post by: dmoore on October 16, 2012, 03:56:18 am
1. I did forgot add XRC into zip command in Linux
    Does the zip file should include extra files? It seem only need be included in zip only when install the plugin?

No not for extra files.You only need to pack the extra files when you package everything into a cbplugin (but still not in the resources zip, but in the cbplugin zip itself). If you are manually installing to devel, just make sure to copy those extra files across as well as a post build step.

Quote
2. I doesn't familiar with ConfigManager::GetDataFolder(bool global), does you mean plugin extra files may be installed at local or global place after setup. So I need to test it with true/false to make sure the file exist?
sample code like:
    wxFileName rpdb_wrap_file_global( ConfigManager::GetDataFolder(true) + _T("/python/PyDebugger/rpdb_wrap.py") );
     wxFileName rpdb_wrap_file_local( ConfigManager::GetDataFolder(false) + _T("/python/PyDebugger/rpdb_wrap.py") );
     wxString rpdb_file_path;
     if(rpdb_wrap_file_global.FileExists()) rpdb_file_path = rpdb_wrap_file_global.GetFullPath();
     else if(rpdb_wrap_file_local.FileExists()) rpdb_file_path = rpdb_wrap_file_local.GetFullPath();


Yes, though I think it should probably prefer the local to global.

Quote
3. I compile project in windows will successful, but compile in Linux will treat warning as error, should I add some definition for Linux project to avoid the warning as error?
   Or I should fix all warning... ???,

I didn't have this problem on Linux. Do you somehow have treat warnings as errors set?

Quote
(most of the warning come from external library wxJson)

Thinking more about this. I noticed that rpdb2 uses an XMLRPC server for the communication between the command line debugger and the debuggee. That means you could bypass the command line debugger and communicate directly with the debuggee from the plugin using XMLRPC, which would probably give better performance.

I have XMLRPC set up and  working pretty nicely for the Python Code Completion plugin. A couple of modules takes care of all the grunt work (xmlrpc_embedder and XmlRpcEvents) and they could easily be deployed as a shared lib for the debugger as well. XMLRPC has the advantage of being built into python. I don't personally care about the distinction between XML and Json -- it's just an implementation detail. (I could even make the rpc module capable of supporting either)
Title: Re: Python Debugger
Post by: Alpha on October 16, 2012, 04:52:59 am
BTW, using  wxString rpdb_wrap_path = ConfigManager::GetDataFolder() + _T("/python/PyDebugger/rpdb_wrap.py");, you should test GetDataFolder with true and false. Depending on the setup, the python files could be installed to a global or local place.
Just an implementation note: I believe the preferred function is ConfigManager::GetFolder(SearchDirs dir) - so ConfigManager::GetFolder(sdDataUser) and ConfigManager::GetFolder(sdDataGlobal) would be used (which makes the purpose of the command a little more readable).

Edit: or even better:
Code: [Select]
wxString rpdb_file_path = ConfigManager::LocateDataFile(_T("python/PyDebugger/rpdb_wrap.py"), sdDataUser | sdDataGlobal);
if (rpdb_file_path.IsEmpty())
{
    // error, file not found
}
Title: Re: Python Debugger
Post by: dmoore on October 16, 2012, 04:55:02 am
BTW, using  wxString rpdb_wrap_path = ConfigManager::GetDataFolder() + _T("/python/PyDebugger/rpdb_wrap.py");, you should test GetDataFolder with true and false. Depending on the setup, the python files could be installed to a global or local place.
Just an implementation note: I believe the preferred function is ConfigManager::GetFolder(SearchDirs dir) - so ConfigManager::GetFolder(sdDataUser) and ConfigManager::GetFolder(sdDataGlobal) would be used (which makes the purpose of the command a little more readable).

Good point. Thanks.
Title: Re: Python Debugger
Post by: Falldog on October 16, 2012, 06:08:24 am
Thinking more about this. I noticed that rpdb2 uses an XMLRPC server for the communication between the command line debugger and the debuggee. That means you could bypass the command line debugger and communicate directly with the debuggee from the plugin using XMLRPC, which would probably give better performance.

I have XMLRPC set up and  working pretty nicely for the Python Code Completion plugin. A couple of modules takes care of all the grunt work (xmlrpc_embedder and XmlRpcEvents) and they could easily be deployed as a shared lib for the debugger as well. XMLRPC has the advantage of being built into python. I don't personally care about the distinction between XML and Json -- it's just an implementation detail. (I could even make the rpc module capable of supporting either)
Yes, this is good point,
I had notice rpdb2 use XMLRPC to communicate between debugger and debuggee,
I think that I just too lazy to use rpdb_wrap.py directly.... it's the easy way to do :-\
maybe implement XMLRPC in PyDebugger to communicate with debuggee directly will win better performance
But I need some time to survey that, to make it possible.

Title: Re: Python Debugger
Post by: dmoore on October 16, 2012, 05:18:49 pm
I would suggest you get your current implementation working first. Then we can investigate alternatives. I find rpdb2.py very hard to grok. Not many comments, too much stuff in one file.
Title: Re: Python Debugger
Post by: daniloz on January 14, 2013, 08:42:54 am
Hi there,

I've just downloaded the Python Debugger plugin sources from http://svn.berlios.de/svnroot/repos/cbilplugin/trunk (rev. 408 from 08 Nov 2012) and tried to compile against the latest code::Blocks (rev. 8785) but i got the following errors:

Code: [Select]
C:\Work\codeblocks_trunk\src\plugins\cbilplugin\CBPythonPlugin\PyPlugin.h|64|error: conflicting return type specified for 'virtual bool PyPlugin::AddBreakpoint(const wxString&, int)'|
C:\Work\codeblocks_trunk\src\include\cbplugin.h|493|error:   overriding 'virtual std::tr1::shared_ptr<cbBreakpoint> cbDebuggerPlugin::AddBreakpoint(const wxString&, int)'|

Looks like the code in PyPlugin.* was not updated to reflect the latest changes in cbplugin.h.

Does anyone has a newer version that works?  ;)
Title: Re: Python Debugger
Post by: dmoore on January 15, 2013, 05:04:47 pm
I am pretty sure that I updated it on one of my machines a while back. The only question is which one :) I'll take a look when I get home tonight and commit it if I can find it. It's a pretty simple set of changes if I recall.
Title: Re: Python Debugger
Post by: dmoore on January 16, 2013, 04:01:57 am
It turned out that I had already committed the changes that I was thinking of...

Anyway, try svn updating to rev 409 and recompiling. With those small changes I was able to compile successfully  on linux and ran the plugin against the latest C::B trunk. However, I didn't see the same error message as yours on rev408,  so not 100% sure I have solved your problem. (Make sure you are using recent C::B headers)
Title: Re: Python Debugger
Post by: daniloz on January 16, 2013, 06:11:39 am
Thanks dmoore!

Actually, I made a mistake in my initial post, the error message I was seeing (and it's still there) is when compiling the Python-Plugin, not the Debugger.

I've tried r409 and the Debugger compiles well here, but with the Plugin, I still have the same message and I see that there's a change in the API which is not reflect into the plugin.

I'd love to help and provide a patch, but unfortunately right now, I don't have time....
Title: Re: Python Debugger
Post by: dmoore on January 16, 2013, 04:52:17 pm
I see. I need to clean up my repo as I don't maintain the python-plugin anymore. That plugin provides an older version of the python debugger interface that is much worse than what is offered by the PythonDebugger plugin. It also had a simple python interpreter window that never really worked very well, that I would like to fix one day. So you are better off with PythonDebugger and Tools+. Have you tried the PythonCodeCompletion? It needs a bit of work, but offers some basic completion functionality.