Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Snakes in the Blocks: A python plugin

(1/3) > >>

dmoore:
Python plugins for Code::Blocks are now hosted on github. Goto: https://github.com/spillz/codeblocks-python


Updated 12/12/2006

I have finally set up a Berlios project to host my plugins for Interpreted Languages support in Code::Blocks

http://developer.berlios.de/projects/cbilplugin/

The project contains code for both the Python and generic Interpreted Languages plugins.

A windows binary of Code::Blocks with both plugins installed can be found here:
http://prdownload.berlios.de/cbilplugin/CodeBlocks_unicode_rev3369_with_IL_plugins_Rev1.exe
(this build includes all Code::Blocks standard and contributed plugins)

Python Plugin

Source code here: http://prdownload.berlios.de/cbilplugin/CBPythonPlugin.zip

if you use the windows binary you only need to follow steps 2,7,8,9,10 after extracting the binary in a suitable location

DISCLAIMER: Use this plugin at your own risk. If the snake bites, it's nothing personal :)


Source compiling instructions

NOTE: My project files may not work correctly with your installation - you may need to play with settings

    1. Download the codeblocks source, wxwidgets and gnu compiler suite (mingw for windows users)
        * Follow the instructions here: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows
        * Make sure that CB and WX variables define appropriate paths under Settings->Global Variables. For CB this is the "src" folder of your codeblocks source install, and for wxwidgets the root folder of you wxwidgets install
    2. Download and install Python from http://www.python.org (I've tested with versions 2.4 and 2.5, but others should work)
    3. Download the python plugin source files from the link above and extract the source somewhere useful
    4. The plugin source contains a required patch for C::B in the resources folder called debug_breakpoints.patch
        * To apply the patch you must have a patch tool. On win32, I use http://gnuwin32.sourceforge.net/packages/patch.htm
        * It is best to install to the patch tool to a location in the windows path (I used the mingw\bin folder)
        * Copy the patch file to the root folder of your C::B source
        * At the command line, change directory to your C::B source and type
            patch -p0 -i debug_breakpoints.patch
        * This should make the required changes to C::B
    5. Open the CBPythonPlugin project file in C::B and build it. The build automatically copies \PythonPlugin.dll and PythonPlugin.zip to the default build location of your C::B source (from the root it should be src\devel\share\Codeblocks\plugins\ and src\devel\share\Codeblocks\
    6. Now close down C::B and copy the \PythonPlugin.dll and PythonPlugin.zip files to the appropriate folders in your C::B executable installation
    7. Start C::B. The python plugin should load without errors and you should see a Python menu on the menubar.
    8. Goto Settings->Environment and scoll down to the python settings (it users a gear icon for now, that will change to our friend, the snake, in the future...)
        * Set the python executable (the default python.exe should work for windows users if python is in your windows path - if it is not then specify the full path - e.g. c:\python25\python.exe)
        * The default debug command line will work with Python 2.5, 2.4 and probably earlier Python versions that have pdb (the python debugger)
        * The default python file extensions will be acceptable to most windows users
        * The list box for regular expression is presently not functional (and may never be)
    9. Go to Project->Project Tree->Edit Files types & Categories and add a python category for extensions .py (and optionally .pyw). This will keep python sources separate from other file categories in the project tree.
    10. The first time you open a python file, you will be prompted whether to use the internal editor or an external program - use the internal editor.


Three methods to start a debug session
    1. Choose "Start Debug" from the Python menu, this will prompt you with a file dialog
    2. Right click in the editor pane of an open python source file and select "Python Debug"
    3. Right click on a python source in the project tree and select "Python Debug"

What you should see
The debugger will start promptly, open and activate the selected file in C::B and show a code position arrow at the first line of code (much like the GDB debugger). Output from the program AND the debugger is routed to the PyDebugger log window (eventually I will do a better job of separating program output from debugger output)

Debugger Actions
You can
    * Continue: By selecting "Continue" from the python menu or clicking the continue button on the python toolbar
    * Move to the next line in the current block: By selecting "Next" from the python menu or clicking the "Next line" python toolbar button
    * Step to the next instruction (even if it is in a subordinate block of code such as a function call): By selecting "Step" from the python menu or clicking the "Step into" button on the python toolber
    * Stop debugging: Select stop on the menu or the toolbar
    * Add/Remove breakpoints: You can add or remove breakpoints by left clicking on the left margin of any open python source file (this is true whether or not you are currently debugging).
    * Watch variables: Select "View Watch" from the python menu. See python debugger watch in the documentation folder below
    * Issue commands directly to the debugger and/or your program: Select "Send Command to Debugger" from the python menu
    * (In the future: Step out, Run to cursor, Conditional breakpoints will be supported.)

Known issues
    * Stopping a debug session can be hit or miss. You may need to kill the process occasionally (for windows right click on the windows taskbar -> Task Manager -> Processes tab -> scroll to python, select it and click end now.
    * By default, the python debugger enters a post mortem debugger state if there is an uncaught exception. this isn't handled very carefully in the plugin, but you should be able to issue commands to the debugger and possible watch variables in this state.
    * The plugin parses the debugger command prompt "(Pdb) " - if your program produces this as output it will cause unpredictable results (I will eventually change the debugger command prompt to somehing less likely to appear as program output or find a better way of handling program output)
    * The plugin does not echo debbugger command input in the watch

The Documentation folder in the source contains additional details

enjoy!

mandrav:
Very nice work, dmoore :) (although I don't know Python so I can't comment about the plugin usage).

What I wanted to say is that maybe it 'd be better if you could provide a binary release of the plugin too, so that users can install and try it without having to build wx and C::B by themselves. That's why the plugin system was revamped lately, to allow installing/uninstalling plugins on the fly (through menu "Plugins->Manage plugins").
To create a .cbplugin file of your plugin just go to "Plugins->Manage plugins", select your plugin from the list and click on "Export" :).
This will help you get feedback from more users, I believe ;).

dmoore:
I'll do that, but only one hitch.

To supply only a dll, someone will have to apply patch #1625. This allows two debuggers to receive breakpoint commands from the editor and allows plugins to retrieve a vector of breakpoints from the editor. Coding style may not quite suit C::B tastes...

Alternatively I can provide a full build of codeblocks with the plugin installed.

dmoore:
btw, there is a very small sample python file in the test folder. this will give a taste. I'll put up a more substantial and interesting sample later that might sell a few people on the virtues of python (or turn them off completely)

mandrav:

--- Quote ---This allows two debuggers to receive breakpoint commands from the editor
--- End quote ---

I see. This, as well as the current implementation, is a hack though. What I plan to add soon is a language enum so that each compiler/debugger can report the languages it supports. Consequently, the editor will send breakpoint events to the debugger that should handle them.


--- Quote ---and allows plugins to retrieve a vector of breakpoints from the editor
--- End quote ---

What's the use of this?
The point of having breakpoint events in the first place is to alert the debugger that a breakpoint has been set/unset. The debugger then can use whatever internal struct is appropriate to keep this info around. The editors don't keep this information around (other than marking the affected lines).

Navigation

[0] Message Index

[#] Next page