Author Topic: Snakes in the Blocks: A python plugin  (Read 24569 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Snakes in the Blocks: A python plugin
« on: November 22, 2006, 04:35:46 am »
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!
« Last Edit: January 26, 2015, 09:30:41 pm by dmoore »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Snakes on a Plane: A python plugin
« Reply #1 on: November 22, 2006, 09:52:32 am »
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 ;).
Be patient!
This bug will be fixed soon...

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes on a Plane: A python plugin
« Reply #2 on: November 22, 2006, 02:30:08 pm »
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.

« Last Edit: November 22, 2006, 02:35:38 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes on a Plane: A python plugin
« Reply #3 on: November 22, 2006, 02:32:29 pm »
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)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Snakes on a Plane: A python plugin
« Reply #4 on: November 22, 2006, 02:42:54 pm »
Quote
This allows two debuggers to receive breakpoint commands from the editor

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

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).
Be patient!
This bug will be fixed soon...

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes on a Plane: A python plugin
« Reply #5 on: November 22, 2006, 02:57:20 pm »
I agree that both are only short term hacks.

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

it seems to me that 1. breakpoints are being needlessly stored and processed repeatedly in the editor and in plugins (extra work) 2. it is too easy to lose synch with where the editor breakpoints are as someone edits and renames files, so why not have a means to validate them? (I have experienced repeated problems with the gdbdebugger). In my code, i retrieve the full list each time the debugger starts, and use the add/remove events to respond to commands while debugging. But ultimately, it's up to you. I can work around it.

Some of the gdbdebugger code also needs to change sometime in the future to make it share (for instance gdbdebugger responds affirmatively to all breakpoint requests, even if the file is not on the list of known file types)

EDIT: my ideal would be for editor manager / some other manager (say "debugger manager") to do more of the work.
« Last Edit: November 22, 2006, 03:02:28 pm by dmoore »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Snakes on a Plane: A python plugin
« Reply #6 on: November 22, 2006, 03:24:49 pm »
Quote
it seems to me that 1. breakpoints are being needlessly stored and processed repeatedly in the editor and in plugins (extra work) 2. it is too easy to lose synch with where the editor breakpoints are as someone edits and renames files, so why not have a means to validate them? (I have experienced repeated problems with the gdbdebugger). In my code, i retrieve the full list each time the debugger starts, and use the add/remove events to respond to commands while debugging. But ultimately, it's up to you. I can work around it.

Although I can agree with your arguments, I have to tell you that at first the editor was keeping the breakpoints. The debugger just asked for them before starting and responded to events while running. Pretty much what you described that your plugin does.
There's one major gotcha with this approach though, which was the reason to change the design to what it is now: it only kept a list of breakpoints for open editors. So if you put a breakpoint, closed the editor and then started debugging, the breakpoint was never set. It was actually "lost" the moment the editor was closed.

I 'm not saying that the current approach is the best possible but it does have the fewest problems. Let me think it through again, now that a second debugger plugin (this one) is available...
Be patient!
This bug will be fixed soon...

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes on a Plane: A python plugin
« Reply #7 on: November 22, 2006, 03:46:17 pm »
Quote
it only kept a list of breakpoints for open editors. So if you put a breakpoint, closed the editor and then started debugging, the breakpoint was never set. It was actually "lost" the moment the editor was closed.

yeah, i figured this would be a problem, but it is a low priority issue for me at this point. sounds like a job for "debuggermanager".

if not, i agree i would also need to keep track of breakpoints in the plugin, but it would still be useful for the plugin to request the editors breakpoints and resolve any conflicts before starting a session.

for what it's worth, the hacks I wrote should be invisible to anyone who doesn't use the python plugin and avoid *most* conflicts with gdbdebugger for anyone who does use it.

EDIT: and one more thing. under the current system there is also an onus on the plugin to check when files are reopened to reinstate the breakpoint markings (again, more duplicated work)
« Last Edit: November 22, 2006, 03:50:31 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes on a Plane: A python plugin
« Reply #8 on: November 22, 2006, 07:42:34 pm »
I've created a C::B binary from the latest source with plugin installed. (see the first post)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes in the Blocks: A python plugin
« Reply #9 on: December 12, 2006, 08:40:17 pm »
I've fixed a few more bugs and enabled the subversion repository for my Interpreted Languages and Python Plugins at the berlios site. You can also download a Code::Blocks binary containing both plugins. See the first post for links.

Offline Etienne

  • Multiple posting newcomer
  • *
  • Posts: 14
Re: Snakes in the Blocks: A python plugin
« Reply #10 on: November 26, 2008, 10:59:50 am »
Hello,

I would like to use CB as the main IDE for Octave, so I downloaded the latest ShellExtention and CBILplugin, and tried it.

These are very nices plugin, specially for my prefered IL language ( www.octave.org , a Matlab replacement), specially because the best IDE is far from CB.

But, actually, I can't help having a usable debugging session:
- Octave reload every debug time , wich is slow , and forget variables from last session (so I am unable to debug).
- CB ask where is the script file every time I start a debug session , can it be possible to use (and save) the actual edited file?
- How to add watch/breakpoints?
- How to have a console, to plot some data, for example?

Or, if it is not possible, can we script CB, to add these fonctionnalities?

Thanks for all.

Etienne

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes in the Blocks: A python plugin
« Reply #11 on: November 26, 2008, 09:40:36 pm »
But, actually, I can't help having a usable debugging session:
- Octave reload every debug time , wich is slow , and forget variables from last session (so I am unable to debug).

CB ships with a debugger for c/c++ code. My python plugin offers python debugging. If you want GUI support for debugging octave you would need to write your own plugin (or extend one of the existing ones). If you are happy to launch an external console and use octave's command line debugger (assuming this exists) then you could use the ShellExtensions plugin to do this.

Quote
- CB ask where is the script file every time I start a debug session , can it be possible to use (and save) the actual edited file?

You can use my ShellExtension plugin to create a custom command to launch an external console debug session on the currently active file (e.g. for python the command would be something like "python -m pdb $file". You should then be able to right click in the editing pane and run that command on the selected file. That will launch an external console to do command line debugging (it won't be integrated with CB of course)

Quote
- How to add watch/breakpoints?

you can see how I did this in the python plugin source code

Quote
- How to have a console, to plot some data, for example?

non-trivial to embed gui consoles in CB. It can be done, but you'll have quite a job ahead of you.

Quote
Or, if it is not possible, can we script CB, to add these fonctionnalities?

writing an octave plugin would be your best course of action.

if you want to discuss this further I suggest starting a new thread

Offline epsilon_da

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Snakes in the Blocks: A python plugin
« Reply #12 on: April 17, 2009, 12:54:04 am »

Hello dmoore.
Is there any chances to add this Python plugin to main stream?

Compiling it seems to be too tricky.

Maybe can you setup a Build Service in
https://build.opensuse.org/
http://software.opensuse.org/search?q=codeblocks

This service will cover many distributions and keep them up to date, with your plugin, with fast no work for you.


Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Snakes in the Blocks: A python plugin
« Reply #13 on: April 22, 2009, 06:28:01 pm »

Hello dmoore.
Is there any chances to add this Python plugin to main stream?

eventually. if you ever get it to compile you will see it needs a LOT of work. let me know if you need help compiling...

Quote
Compiling it seems to be too tricky.

it will be quicker for me to show you how to build it than for me to setup a build service :) (don't get me wrong, that looks interesting, I just don't have time right now)