Python Debugger

[oBFusCATed]

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?

[Falldog]

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?

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]

[dmoore]

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

[Falldog]

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...

[oBFusCATed]

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.

[dmoore]

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)

[oBFusCATed]

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.

[dmoore]

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

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.

[oBFusCATed]

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.

[MortenMacFly]

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...

[oBFusCATed]

Morten: How they separate the codecompletion? There is no API for the symbol browser, nor for the toolbar, nor for the auto complete list...

[Alpha]

I just thought I would mention, as there was some talk of possibly needing to parse JSON, that wxJSON has worked quite well when I have used it.

[oBFusCATed]

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.

[Falldog]

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)

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!?

[Falldog]

I just thought I would mention, as there was some talk of possibly needing to parse JSON, that 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!?