Python Debugger

[MortenMacFly]

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.

[oBFusCATed]

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

[Falldog]

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)

[dmoore]

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.

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.

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?

(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)

[Alpha]

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

wxString rpdb_file_path = ConfigManager::LocateDataFile(_T("python/PyDebugger/rpdb_wrap.py"), sdDataUser | sdDataGlobal);
if (rpdb_file_path.IsEmpty())
{
    // error, file not found
}

[dmoore]

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.

[Falldog]

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.

[dmoore]

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.

[daniloz]

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

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? 

[dmoore]

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.

[dmoore]

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)

[daniloz]

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

[dmoore]

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.