svn checkout http://svn.berlios.de/svnroot/repos/cbilplugin/trunk/PythonDebugger
1. Checkout the code to your contrib directory (this assumes you are using C::B to build C::B and the plugins)This is a part of C::B development I dislike, too much.Code2. When you build the project within C::B it will install itself into devel like any other contrib plugin.svn checkout http://svn.berlios.de/svnroot/repos/cbilplugin/trunk/PythonDebugger
1. Checkout the code to your contrib directory (this assumes you are using C::B to build C::B and the plugins)This is a part of C::B development I dislike, too much.Code2. When you build the project within C::B it will install itself into devel like any other contrib plugin.svn checkout http://svn.berlios.de/svnroot/repos/cbilplugin/trunk/PythonDebugger
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
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
(I may add python project support later)When/if this occurs, know that you have an interested user :).
(I may add python project support later)When/if this occurs, know that you have an interested user :).
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.
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.
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.
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.
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...
a) sounds like the way to go.
b) is not possible, because typedefs can't be forward declared, too.
#include <cbplugin.h>
typedef cb::shared_ptr<cbWatch> cbWatchPtr; // <-- This compiles fine
typedef cbWatch::Pointer cbWatchPtr2; // <--- This is an error
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.
//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"
Yes, of course, if you have time and desire you can do it, too :)
class cbWatch;
typedef cb::shared_ptr<cbWatch> cbWatchPtr;
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.
How can I build it in Windows?
What have you tried?Thanks,
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
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.
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.
I create the patch by Git, but it's size over the post maximumYou can pastebin it somewhere or you can post it in the patch tracker.
I create the patch by Git, but it's size over the post maximumYou can pastebin it somewhere or you can post it in the patch tracker.
By the way - have you tried to zip it?
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 :)ya, you look at the good point,
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
And... may I use the open source code(like rpdb2 or JsonCpp) directly in CB?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.
I am not sure the licence is okay...
And... may I use the open source code(like rpdb2 or JsonCpp) directly in CB?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.
I am not sure the licence is okay...
On the other, I am wondering about performance of current implementation in socket,
Maybe use pipe is better!?
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.
About the code-completion: We have to thing how to make an API for different languages or implementations.
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.
At the place I work most of the software is a mix of c++ and python, so getting python support integratedNo, 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...
in the IDE will be good for me. No matter I don't like python too much.
a) use cb::shared_ptr everywhereI'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.
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 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/))
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.
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!?
I tested briefly last night. No problems compiling. So far, two issues:thanks for your reply,
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?
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?I had merge local commit in this patch, but file too large(more than maximun attachment), I separate in 2 rar files
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
Do you mean that I create another my own repo to maintain these code? ???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? ???
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. :)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.
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.
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
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.
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.
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)
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).
wxString rpdb_file_path = ConfigManager::LocateDataFile(_T("python/PyDebugger/rpdb_wrap.py"), sdDataUser | sdDataGlobal);
if (rpdb_file_path.IsEmpty())
{
// error, file not found
}
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).
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.Yes, this is good point,
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)
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)'|