Code::Blocks

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: dmoore on September 21, 2006, 10:58:46 pm

Title: Support for Interpreted Languages?
Post by: dmoore on September 21, 2006, 10:58:46 pm
I've seen some discussion on these boards re making projects wizards to support intepreted languages such as Matlab and R. Presumably, the same could also be done for more generic languages such as Python and Ruby. I'd hate to see Code::Blocks end up like Eclipse (a big, bloated, sluggish, memory hungry beast) but it would be very handy to be able to setup, edit and run interpreted language projects. Can the existing plugin framework handle this?

As an example, lets take my second favorite language Python (they're all my second favorites :D). I can open python files in the editor and seem to get basic code coloring, folding etc. (is this just default behavior of scintilla or something?) What I'd like to do is add a wizard for a python project. When the project is activated, c/c++ related elements of the GUI shoud be deactivated/hidden (e.g. compile etc.). However, I should be able to run the project in a console/new window and debug interactively (the latter would take some work, but could hook into Code::Blocks existing framework for debugging, such as tool bars. There should also be a dialog to enter Python specific configuration. So is all of this possible from within the current CB plugin framework??

cheers

(edited: title)
Title: Re: Projects for Interpreted Languages
Post by: mandrav on September 21, 2006, 11:33:37 pm
In short, no.
There are plans to support (i.e. not just editing) languages other than C/C++, but it won't happen in the near future.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on September 22, 2006, 04:36:15 am
So how about something a little simpler instead of offering full blown project support for interpreted languages. They are typically used as "glue" languages anyway, so the project infrastructure is usually unecessary.

Playing around in code::blocks I notice that it is possible to add groupings for different sources, allowing those sources to be added to any project and kept separate from everything else. So I'm thinking that I could write a plugin that adds a "Python", "Ruby" or, more generically, a "Scripting" menu that has (initially) a few options

* Config: setup location of interpreter, specify environment variables, command line options etc. [persistent]
* Current Interpreter Target: presents user with a list of the relevant sources as a possible run target. Allows additional environment variables, command line options. [save this target specific info in a target config file]
* Run Target: executes the target in a new window (asks user to save etc. first)
* Run Interpreter: run the interpreter in a new window

I have no experience with the CB plugin framework, but have written a variety of GUI bits and pieces in the past and have been looking at the source for some of the current CB plugins. I have a lot on my plate at the moment, so if someone wants to jump in first with this or something better, be my guest.
Title: Re: Support for Interpreted Languages?
Post by: mandrav on September 22, 2006, 08:23:10 am
What you 're describing is trivial to do with a very simple plugin. So simple that might even serve as a plugin tutorial that actually does something more than greeting the world ;).
Title: Re: Support for Interpreted Languages?
Post by: mandrav on September 22, 2006, 12:51:56 pm
...and so I decided to write this tutorial. Hopefully it will help many would-be-plugin-developers :)

Work in progress: http://wiki.codeblocks.org/index.php?title=Creating_a_plugin_that_actually_does_something
Title: Re: Support for Interpreted Languages?
Post by: dmoore on September 22, 2006, 02:40:32 pm
you, sir, are a great man :D
I look forward to the conclusion of the wiki entry. I'll use that code as a template for adding some more integrated language support when you're done. (at a minimum I want to add debugging support, which is certainly a less trivial task, requires language specific coding and more hooks into CB)

BTW where do i get the latest version of the SDK? I could only find the RC2 SDK, but in the Sep 20 recent nightly builds the entry says several things about about plugins changing...

cheers
Title: Re: Support for Interpreted Languages?
Post by: mandrav on September 22, 2006, 03:04:30 pm
BTW where do i get the latest version of the SDK? I could only find the RC2 SDK, but in the Sep 20 recent nightly builds the entry says several things about about plugins changing...

Obviously, we can't distribute the SDK of the development version as a package because it is changing. To build a plugin for the development version, your only option is to first build the development version yourself. It's not hard and it takes less than 30 minutes (including building wxWidgets).
For more info, check Installing Code::Blocks from source on Windows (http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows) (sorry if I guessed your platform wrong :)).
Title: Re: Support for Interpreted Languages?
Post by: dmoore on September 22, 2006, 03:20:44 pm
my apologies. I downloaded the source yesterday, but didn't look for the latest version of the SDK in the most natural place...  :oops:
don't worry, I have no particular aversion to compiling source (boost libraries and wxwidgets yesterday). I assume your wiki entry will be based off the latest version of the SDK then?

(and windows is correct. I think I must write like a windows person. I tried Ubuntu recently and it looks very interesting)
Title: Re: Support for Interpreted Languages?
Post by: dmoore on September 22, 2006, 10:30:52 pm
I comiled a working version of CB from the nightly builds. Unfortunately, it looks like I have a build (19th or 20th sep) whose plugin wizard produce code that's incompatible with the latest version of the sdk. When I try to compile the template code generated by the wiz, it doesn't understand any of the preprocessor functions (I'm assuming they're preprocessor functions) such as

Code: [Select]
CB_DECLARE_PLUGIN();
I assume if I wait a day or two I will be able to download a nightly build with a compatible wizard?
Title: Re: Support for Interpreted Languages?
Post by: mandrav on September 23, 2006, 12:15:37 am
This was fixed earlier today (revision 2988).
Title: Re: Support for Interpreted Languages?
Post by: dmoore on September 29, 2006, 07:33:35 pm
ok, I managed to get a very simple plugin to work that creates an "Interpreters" menu with a few options and adds a context menu item for right clicks on the project tree to execute relevant scripts (I only add this item to the context menu if the file extension matches a known type). So far I only have it setup to handle python files, but it will be easy to add support for any interpreter. I'm using wxExecute to run the interpreter.

Before I really jump into the deep end and work on debug support (more questions on that later) I have two quick questions:
1. is there away to register file type classes from the plugin? it's easy to do manually through the menus: Project -> Project Tree -> Edit file types & categories or the Project Tree context menu, but i may as well automate this if possible
2. Is there a standard format for plugin settings and configuration files? Where are they stored? I want to store the list of interpreters, paths, command strings etc.
Title: Re: Support for Interpreted Languages?
Post by: mandrav on September 29, 2006, 09:36:16 pm
Quote
1. is there away to register file type classes from the plugin?

Unfortunately, not yet.

Quote
2. Is there a standard format for plugin settings and configuration files? Where are they stored? I want to store the list of interpreters, paths, command strings etc.

ConfigManager comes to the rescue ;).

Code: C++
  1. ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("your_plugin_name"));
  2. cfg->Write(_T("/any/kind/of/path"), some_string);
  3. cfg->Write(_T("/paths/are/not/filesystem/paths"), some_float);
  4. cfg->Write(_T("/paths/are/just/a/way/for/you/to/organize/data"), some_bool);
  5.  
  6. some_string = cfg->Read(_T("/another/path"), a_default_string_if_the_key_doesnt_exist);
  7. some_int = cfg->ReadInt(_T("/always/start/the/paths/with/a/slash"), a default_int);
  8.  
  9. ...and so on and so forth...
  10.  

For more info, check ConfigManager's documentation and, as always, consult the other plugins' sources :).
Title: Re: Support for Interpreted Languages?
Post by: dmoore on September 29, 2006, 11:10:35 pm
thanks! more soon.
Title: Re: Support for Interpreted Languages?
Post by: Game_Ender on September 30, 2006, 10:30:48 pm
I am sure you aware of PyDev (http://pydev.sourceforge.net/) but perhaps you could port over the Java based python debugger for use in Code::Blocks.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on October 04, 2006, 07:25:22 pm
I am sure you aware of PyDev (http://pydev.sourceforge.net/) but perhaps you could port over the Java based python debugger for use in Code::Blocks.

Yes, I use PyDev and its pretty darn good. However, I don't think I want to go down that path (seems like I would have to know too much about Java libraries and the Eclipse SDK - no thanks). My current plan is to pass commands to the internal debuggers provided by most interpreted languages by rerouting std in/out. it should be possible to set up REGEX commands to obtain the current code position etc (I know I can do this for python and, probably, ruby). Ideally the user would setup a debug config file that contains the definitions required to pass commands to the debugger and interpret its output. If someone has better ideas I'm all ears.

Anyway, here is the code for the interpreters plugin to date. I used the data specification for the interpreters that Mandrav provided in the Wiki. There's some ugliness in the code and UI that I will eventually clean up. (blame it on unfamiliarity with wxWidgets)

Features:
add & edit interpreters + associated actions in the environment settings dialog (I'm using the build icon). (these are stored persistently)
Interpreters menu: run interpreter actions on a file target (selected using a file dialog - currently uses a "*.*" wildcard extension instead of the correct one)
Project Tree Context menu: run interpreter actions on selected file (obviously you have to add your file to the project first)

Feedback appreciated.

EDIT: Plugin removed - reposted on next page.
Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on October 04, 2006, 11:34:37 pm
Feedback appreciated.
Compiles & runs fine here. Anyway: One annoying thing I have discovered. Once you choose "Run..." from the interpreters menu an OpenFile dialog appears. But if you click "Cancel" in this dialog the plugin complains that the target does not exist and won't let you out of this loop until you really select a file.
In addition one time I run C::B again all my interpreters (well, one -Python- for this time ;-)) were lost. I have no clue why, maybe it was my fault.
Anyway: Nice work!!! 8)
With regards, Morten.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on October 04, 2006, 11:59:13 pm
Compiles & runs fine here. Anyway: One annoying thing I have discovered. Once you choose "Run..." from the interpreters menu an OpenFile dialog appears. But if you click "Cancel" in this dialog the plugin complains that the target does not exist and won't let you out of this loop until you really select a file.

oops. I changed one of my event handlers at the last minute. should be an easy fix.

In addition one time I run C::B again all my interpreters (well, one -Python- for this time ;-)) were lost. I have no clue why, maybe it was my fault.

I have had some trouble with wxString and ConfigManager. I thought I had resolved everything, but maybe not.

thanks for finding these.

In addition to debug support, I'm planning to add a recent command list to the interpreters menu that saves the last 5 (or so) command strings (EDIT:) and add the option to not have an Interpreters menu at all (i.e. just offer context clicks on the project tree for those who don't want excessive menus on the menubar)

any suggests on how to reduce DLL bloat? (5mb  :shock:)
Title: Re: Support for Interpreted Languages?
Post by: dmoore on October 05, 2006, 05:16:37 am
I've removed the repeated file prompting bug

plugin source code attached.

(EDIT: corrected some bugs that somehow crept in)

[attachment deleted by admin]
Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on October 05, 2006, 08:07:36 am
any suggests on how to reduce DLL bloat? (5mb  :shock:)
Sure: Remove the compiler option "-DcbDEBUG" and add "-s" (strip symbols) instead. This should help. ;-)
BTW: The bug seems to have disappeared in the new version. And I haven't had a loss of settings anymore... I believe it was really my fault becasue the code seems to be ok from a quick inspection.
With regards, Morten.
Title: Re: Support for Interpreted Languages?
Post by: keenblade on November 18, 2006, 07:52:09 pm
you should have told me that people were actually using the InterpretedLangs plugin. I fixed the bugs weeks ago [...]
Well what get's posted here is automatically used - you can count on that. ;-)
I heard rumors that even the major guru liked InterpretedLangs...

Hi, dmoore. You can count me, too. Will you continue InterpretedLangs plugin? You are my hope to use prolog language within Code::Blocks. I even managed to start swi-prolog minimized with your plugin :)
I am looking forward to your plugin.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 18, 2006, 11:18:52 pm
Thanks for the feedback Morten and keenblade. I guess it is good to hear people have found the plugin useful. So with that in mind, I'll fix the windows pathnames bug and post the latest version of interpreted langs shortly. Has anyone tried it on Linux (I'm lucky if i boot my linux installation more than about an hour a month so i haven't had a chance). I'm embarassed that people have been using such a buggy version (especially when you see how stupid the menu bug makes me look  :lol:). I can't promise there won't be bugs left, but it should at least be usable. (Morten: I'm not sure whether i fixed the down button crash)

I want to spend most of my time working with the python plugin. My original vision was (and still is) to work on a generic runner/debugger/project manager plugin for any interpreted language, but I decided I needed a case study to determine the flexibility a generic plugin would require and Python is my language of the moment. So I'll come back to interpreted langs from time to time. One obvious thing I can add is the option to run the interpreter in a codeblocks dockable window.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 19, 2006, 12:20:47 am
Ok, my CVS server is down (harddrive), but I'm pretty sure this version is close to the latest (my one fear is that this isn't a complete fix of the dreaded menu bug - at least it didn't show up in my testing). I did a quick patch of the path name bug by simply subtituting the windows short name for the interpreter executable and the source file path. The down move crash in the environment settings didn't show up, so I'm pretty sure I fixed it, but possibly not. The code is also very messy and needs a clean up.

If anyone wants to see specific features added let me know. I'm thinking about adding user specified flags to actions for things like input/output redirection and specifying unix style vs windows style path names (the latter is important for pdb, the python debugger, for some reason it expects unix style "/" for pathname separators even on windows). debugger support within CB is a little trickier. I have it working for pdb in my python plugin (albeit with a patch to the C::B sdk), but making that sufficiently generic to handle any debugger that has redirectible output without requiring custom c/c++ code will take some work.

Two other things:

1. Thomas's alternative to wxExecute would probably come in handy here
2. Someone (probably me) should write the tutorial wiki entry for this plugin



[attachment deleted by admin]
Title: Re: Support for Interpreted Languages?
Post by: keenblade on November 19, 2006, 12:39:15 am
... One obvious thing I can add is the option to run the interpreter in a codeblocks dockable window.
That's what I exactly need. Hope you have time to do.
Title: Re: Support for Interpreted Languages?
Post by: keenblade on November 19, 2006, 01:35:47 am
 I can't build the new version. It gives this error referring to #include <sdk.h>:
InterpretedLangs.h:21: calling fdopen: No such file or directory

It seems Code::Blocks has troubles with the paths. At the project build options -> Directories -> Compiler this line exists;
$(#cb)\sdk
 When I select it and press edit -> browse, It finds the sdk directory successfuly. Global variables are also set. I can build Code::Blocks itself successfuly.

Any idea?

I use;
Code::Blocks svn build 3236
Title: Re: Support for Interpreted Languages?
Post by: Pecan on November 19, 2006, 02:10:57 am
I can't build the new version. It gives this error referring to #include <sdk.h>:
InterpretedLangs.h:21: calling fdopen: No such file or directory

It seems Code::Blocks has troubles with the paths. At the project build options -> Directories -> Compiler this line exists;
$(#cb)\sdk
 When I select it and press edit -> browse, It finds the sdk directory successfuly. Global variables are also set. I can build Code::Blocks itself successfuly.

Any idea?

I use;
Code::Blocks svn build 3236

Caused by an incorrect arrangement of #includes and pre-compiled header.
Or an -include sdk.h flag in the project while using pre-compiled headers.

Title: Re: Support for Interpreted Languages?
Post by: keenblade on November 19, 2006, 03:39:57 am
If I choose build target as release, it compiles. Because sdk.h is not used. Build log says;
InterpretedLangs.cpp:1: warning: ...sdk.h.gch: not used because `cbDEBUG' not defined.

If I choose build target as default, it gives "not found sdk.h" error.

Now that I build the plugin, It's enough now for me. So far it did not crash.
Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on November 19, 2006, 09:36:06 am
...sdk.h.gch: not used because `cbDEBUG' not defined.
Yes, that's easy to resolve:
Remove the _GNU_SomeWhat_ define, add cbDEBUG and TIXML_HAVE_STL and this issue is gone. It works with PCH then.
With regards, Morten.
Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on November 19, 2006, 10:48:13 am
...here comes my very little "update": Fixing the compiling warnings + PCH issues, optimising the project file and fixing the bug with .size()-1.
Please verify that you setup the variables WX_SUFFIX and WX_CFG so that they match your configuration. Note that only the debug release (which is the default one) will use PCH.
With regards, Morten.

[attachment deleted by admin]
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 19, 2006, 02:59:22 pm
...here comes my very little "update": Fixing the compiling warnings + PCH issues, optimising the project file and fixing the bug with .size()-1.
Please verify that you setup the variables WX_SUFFIX and WX_CFG so that they match your configuration. Note that only the debug release (which is the default one) will use PCH.
With regards, Morten.

thanks Morten!
Title: Re: Support for Interpreted Languages?
Post by: keenblade on November 19, 2006, 10:34:47 pm
As stated before

"Once you choose "Run..." from the interpreters menu an OpenFile dialog appears."

I think if a file is already open within ide, then this file must be processed without asking. Or this type of behaviour can be specified from the settings page.

BTW, Could InterpretedLangs plugin can be the part of svn repository?

Thanks for fixing, Morten.
Title: Re: Support for Interpreted Languages?
Post by: Game_Ender on November 20, 2006, 02:52:43 am
I think it would make more sense if he got his own project on Berlios or Sourceforge.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 20, 2006, 03:05:34 am
As stated before

"Once you choose "Run..." from the interpreters menu an OpenFile dialog appears."

I think if a file is already open within ide, then this file must be processed without asking. Or this type of behaviour can be specified from the settings page.

Personally, I like that it works this way as I don't necessarily want to have to open a file before I run it or run the currently active file. What I wanted to do was respond to right clicks in the editors tabs and/or editor pane with menu options for the appropriate actions. At the time, I couldn't tell whether the sdk allowed this behavior, because i was very unfamiliar with the C::B code. I'll have another look and make this change if possible. Will this be acceptable? My other plan is to put the last 10 executed commands directly in the interpreters menu as another shortcut way to execute commonly run scripts. These will be stored persistently.

In the mean time, if your source file is added to a project, you can right click the file in the project tree pane and you will be offered the appropriate actions.

So my current todo list for the interpreted languages plugin:

1. context action clicks in the editor pane/tabs of relevant sources (PARTLY COMPLETE)
2. recent command list on the interpreters menu
3. rerouting console input and output to a dockable window in codeblocks (there will be a few problems implementing this but its not a big deal to get very basic functionality)
4. add additional variables for the action commands (such as $activefile, $allopenfiles etc). also support iterative commands and macromanager variables

Let me know of any other bugs, undesired behaviors or things to add to the list.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 20, 2006, 03:17:10 am
I think it would make more sense if he got his own project on Berlios or Sourceforge.

I need to clean up the code before it goes into any repository, but especially the C::B one (quite a bit of experimental stuff in there)

BTW: How long will it take to get my debug patch (#1625) approved?
Title: Re: Support for Interpreted Languages?
Post by: Game_Ender on November 20, 2006, 05:47:26 am
Why don't you take python's moto: "Release early release often", nothing wrong with placing alpha quality code in a repository.  When the code is in heavy state of flux you will be able to track changes better when using source control.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 20, 2006, 05:58:27 am
Why don't you take python's moto: "Release early release often", nothing wrong with placing alpha quality code in a repository.  When the code is in heavy state of flux you will be able to track changes better when using source control.

:)

until 2 days ago I had source control on my home server. hard drive broke and I'm waiting on a new one. Perhaps that is an object lesson in the value of a professionally managed external repository. I'll look into setting up a berlios project.

-----------------------------------

anyway, here is the fix to number one on my list. I would probably have completed number 2 as well but Morten's fix to the project file didn't work with my setup because i don't have the project in the contrib folder. I spent too much time messing around with the settings to try to make the project neutral with respect to folder location, but the debugger refused to cooperate, so i had to revert to my original project file. I'll fix this eventually, but I've removed the project file altogether from this version (use your own or Morten's/mine from the previous posts)

to explain the addition: you can now right click in the editor pane of the source file giving you the option to run actions on the script (file is not saved automatically, but i can change this). unfortunately you can't right click on the editor tabs (doesn't generate messages context menu) or the opened files list (does generate messages, but I wasn't sure how to determine the file that was clicked)
Title: Re: Support for Interpreted Languages?
Post by: keenblade on November 20, 2006, 03:14:59 pm
Personally, I like that it works this way as I don't necessarily want to have to open a file before I run it or run the currently active file.
That's ok. Also to keep your personal taste and to add some more usability, what do you think about using $processafile that means process the active file in ide like this:

load;$processafile $interpreter $file

Additionaly There are times I have more than one file open. I want to process them all like this:

consult;$processallfiles $interpreter consult('$files').

So, All the files are processed with a sequence like this:

consult;$interpreter consult('$file1').
consult;$interpreter consult('$file2').
consult;$interpreter consult('$file_etc').
that would be cool.

What I wanted to do was respond to right clicks in the editors tabs and/or editor pane with menu options for the appropriate actions...  Will this be acceptable? My other plan is to put the last 10 executed commands directly in the interpreters menu as another shortcut way to execute commonly run scripts. These will be stored persistently...
2. recent command list on the interpreters menu
It's nice if right clicks would bring a compact menu gathered within an "InterpretedLang" or something smilar.
Recent command list on the interpreters menu is also nice.
3. rerouting console input and output to a dockable window in codeblocks (there will be a few problems implementing this but its not a big deal)
That's what I'm eager with.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 20, 2006, 06:34:23 pm
Quote
what do you think about using $processafile that means process the active file in ide like this:

load;$processafile $interpreter $file

Additionaly There are times I have more than one file open. I want to process them all like this:

consult;$processallfiles $interpreter consult('$files').

Nice. I have thought about adding some more variables for the actions (such as $activefile, $allopenfiles, $allprojectfiles). since you are thinking along the same lines I'll put it on the todo list. running a sequence of commands is a pretty cute idea - I'd like to think some more about the syntax for this. Unfortunately, I have a busy week at work this week, so I doubt I'll get to look at the code again till sometime next week (my priority will be to get 2 and 3 working first, then I'll look at this issue). In any case, you are welcome to modify the code - this is open source after all. With that in mind i'll also setup a project on Berlios soon.

Quote
It's nice if right clicks would bring a compact menu gathered within an "InterpretedLang" or something smilar.
Recent command list on the interpreters menu is also nice

a submenu on the context menu? (should be easy enough).

This reminds me of another potentially annoying "feature": the actions are only populated for the first interpreter matching the wildcard (hence the ability to move priority up/down in the environment settings) - maybe I should provide all matching interpreters. An example of the use of multiple interpreters on the same file extension is when you want to test code that works on Python 2.4 against Python 2.5
Title: Re: Support for Interpreted Languages?
Post by: dmoore on November 21, 2006, 09:37:54 pm
Caused by an incorrect arrangement of #includes and pre-compiled header.
Or an -include sdk.h flag in the project while using pre-compiled headers.

could someone please explain this to me in more detail, so I can put up error free project files? (I'm not all the familiar with correct PCH usage, especially as regards the C::B sdk)

thanks,
Damien
Title: Re: Support for Interpreted Languages?
Post by: dmoore on December 12, 2006, 08:42:23 pm
files for this project can now be found at my berlios project site: https://developer.berlios.de/projects/cbilplugin/
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 06, 2007, 05:49:34 pm
An update on this project:

I've just added very basic support for spawning new interpreter shells in a wxFlatnotebook (which is embedded in a CB dockable window). There's still a lot of work to do with translating keycodes etc, but you should be able to get very basic console based scripts running in the window.

files

here's a link to a win32 build of CB (rev. 4064) with the plugin installed (rev 15 of my svn): http://prdownload.berlios.de/cbilplugin/CodeBlocksRev4084_ILpluginsRev15_wx263_1.exe - run the executable and choose an extraction path

the project source is attached to this post (also in my SVN - see my sig) and contains windows and linux projects (note that I use --personality=debug in the cb runner exec arguments, so don't be surprised if your layout is not how you like it - you can always copy your default.conf to debug.conf before you start). EDIT: Source updated 3:17pm 6/6/2007

info

To make an interpreter action launch in the notebook you just need to add the character "W" to the semi-colon separated action string (e.g. "Run;$interpreter $file;W" (see the screenshot in my next post). You might also need to tell your intepreter to run in an unbuffered mode (e.g. in python I specify python -u) to enure that output appears. To delete process from the notebook just click on the "x" in the tab - if it is still running you will get a warning (you may need to kill more than once and the project may fail to die properly)


TODOs (feel free to add to these):
* report stderr
* improve keycodes handling (ctrl-key sequences etc)
* more macro substitutions (eg. $ALL_OPEN_FILES)
* smarter file handling (only ask for files to open if there is a $file in the argument list, dont offer actions that don't apply to individual files for context clicks etc)
* better process handling (killing etc)
* allow subclasses from the basic terminal control for more sophisticated interpreters (e.g. I plan to write a simple python interpreter, because the standard dos python shell cannot be piped in interactive mode)
* add to the UI (drag and drop etc)
* update my berlios site (eventually)

[attachment deleted by admin]
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 06, 2007, 05:58:18 pm
a screenshot

[attachment deleted by admin]
Title: Re: Support for Interpreted Languages?
Post by: David Perfors on June 06, 2007, 06:01:12 pm
Very nice to see this plugin, I think I will take a look into it :)
ps. why don't you put the release on the berlios server? You already have a project there :)
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 06, 2007, 06:02:28 pm
it'll get there eventually - i just hate berlios...

EDIT: I've uploaded the source into my berlios svn repository (follow the link in my sig). The bonus is I've added stderr handling (will appear as red text in the control)
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 08, 2007, 10:25:30 pm
I'm thinking I should rename this plugin "Shell Tools". I will soon add enough additional functionality to make the Tools menu obsolete.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 11, 2007, 04:45:35 am
I've just commited Revision 15 of the Interpreted Langs plugins:

* enhanced process redirection (fewer bugs) to the Shells dockable
* more action options: the action string format is now "name;command;[W|C];working directory;environment var set". (environment var set is not supported yet)
* in the action string, W refers to launching process in dockable window, C refers to using the cb Console runner (required for non-gui intepreters) - anything else refers to a default wxExecute process launch of the command.
* supports Macro substitution for command and working directory - see the Tools menu (configure tools) to see examples of the variables supported
* context menu is smarter (right click project/editor pane of a relevant file) - only actions that include $file in the command string report in the context menu.

source available from svn of my cbilplugins project on berlios (see my sig). win32 c::b build (rev 4084) available here: http://developer.berlios.de/project/showfiles.php?group_id=7745&release_id=12931

still to do:
1. add smart options to the interpreter menu (run available actions on current file, run actions on open files etc)
2. add persistent command history to interpreter menu
3. more macro variables (e.g. pass multiple files to a single commnad, edit control prompts for program arguments)
4. better keyboard I/O handling for redirected processes (e.g. customizing key codes for different types platforms, toggle wordwrap, autoscroll)
5. rework the shell control interface for reuse in other scipted language related plugins (example: a python terminal inherits from the default terminal, but generates python related event (e.g. goto file location on error))
6. file explorer window (file manipulation from the comfort of cb)
Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on June 13, 2007, 09:23:15 pm
I've just commited Revision 15 of the Interpreted Langs plugins:
Hmmmm... whereas all previous versions work properly I have an issue with this one: First I had to point to the Python include/lib folder the first time for compilation which wasn't considered in the project files. It compiled/linked fine but now whenever I start C::B I receive an error, that the python plugin could not be loaded. What am I missing? Do I need to put e.g. the Python DLL somewhere?! What's behind the dependency on Python?!
With regards, Morten.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 13, 2007, 10:02:15 pm
sorry about the current state of that plugin -- you should just remove py_embedder.cpp, py_embedder.h, libpython and any python related vars from the project as that is purely experimental stuff. I'm eventually going to implement symbol browsing and code completion for python using an embedded python interpreter. I'll remove the files from the default build target in a future commit (soon)

anyway, as soon as I'm done updating the InterpretedLangs plugin (currently working on a file explorer tab in the management pane -- Check out the latest SVN, then I'll do some more work on the menus and intepreter actions) I'm going to tie the Python plugin more closely to the InterpretedLangs plugin. so consider the current python plugin as being in a deprecated state until that time...
Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on June 13, 2007, 10:24:08 pm
sorry about the current state of that plugin -- you should just remove py_embedder.cpp, py_embedder.h, libpython and any python related vars from the project [...]
Alright... will do that... thanks! :P Sounds interesting what you still have in mind! 8)
BTW: You can use a branch for this experimental stuff thus trunk would always be a "usable" version. SVN can do so much more that "just trunk". ;-)
With regards, Morten.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 13, 2007, 10:39:46 pm
BTW: You can use a branch for this experimental stuff thus trunk would always be a "usable" version. SVN can do so much more that "just trunk". ;-)
With regards, Morten.

you've correctly surmised that I'm something of a vcs neophyte. :)
for now, I think having a second "experimental" build target will work just as well, because then I won't have to keep updating the branch for changes that i make to the trunk. There are lots of changes that I plan to make to the core python plugin that will remain compatible with the experimental bits.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 16, 2007, 03:50:08 pm
latest build (rev 31), which includes a file explorer here:

http://developer.berlios.de/project/showfiles.php?group_id=7745&release_id=12952

Notes:
This self-extracting executable contains Code::Blocks, the CBIL plugins compiled for win32 using wxWidgets
 2.8.4 (dll included). Extract the file to your preferred directory and run codeblocks.exe

Disable plugins by starting codeblocks.exe and selecting Plugins->Management

IntepretedLangs and Python Plugin settings are available from Settings->Environment

Main features:
InterpetedLangs:
* Customizable Interpeter Actions that can be issued from the interpreters menu or with context clicks in Project Tree/File Explorer/Editor Pane. Customized actions support global/custom variable substitions, working directory specification, command line args, dockable vs console running mode
* File Explorer - provides a view of the file system (it's a tab in the management window).
* Launch multiple process with output piped to a tabbed "shells window". Run an interpreter action using option "W" in the action string (to run an interpreter in the cbconsole runnner use "C" in the action string). for example a python run action string to run a script in a dockable winodw tab might look like this: "Run;$interpeter -u $file;W;;" (the last to spaces are for setting the working directory and (not implemented) environment variable set)


Python Plugin (currently in a functional, though soon to be improved state)
* run python files with context clicks or from the Python menu
* debug python files (includes a watch, breakpoints, toolbar and code navigation in the cb editor)

Changes(from rev 15)

http://svn.berlios.de/wsvn/cbilplugin/?op=log&rev=0&sc=0&isdir=1

Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on June 17, 2007, 07:48:53 pm
latest build (rev 31), which includes a file explorer here:
I guess it's rev 35 already...?! ;-)
Two notes I'd like to tell:
1.) in InterpretedLangs.h: You need to include sdk.h *first*. Please change the code to:
Code: [Select]
#include <sdk.h>
#include <cbplugin.h> // for "class cbPlugin"
2.) in FileExplorer.h: According to you path settings you need to use <sdk.h> instead of "sdk.h" for th include. (Notice that I have changed that on 1.) too).
After these changes I was able to compile... now I'm testing... ;-)
With regards, Morten.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 17, 2007, 09:46:44 pm
thanks for the notes morten. I still don't fully understand the plugin architecture in cb. Should the "#include <sdk.h>" still come after the wx includes?

I guess it's rev 35 already...?! ;-)

I'm using the berlios repository as my main repository for this project now, so all changes each day get commited. I still have lots to do... (not enough hours in the day)

Quote
After these changes I was able to compile... now I'm testing... ;-)

I'm sure you will encounter lots of bugs and missing features, so look forward to hearing from you. NB: the $paths specifier doesn't do anything useful at the moment because I still haven't implemented multi-select in the file explorer. anyway, the svn log will give you a good idea of what's there...
Title: Re: Support for Interpreted Languages?
Post by: killerbot on June 17, 2007, 10:18:53 pm
sdk.h and wx headers :

normally the order shouldn't matter, the headers files should play nice along.

However when including sdk.h first and then ifdef on CB_PRECOMP you can split further includes and when CB_PRECOMP is defined precompiled headers can kick in. But for this you need to check each time what sdk.h brings because if it brings a file you wanted to include, no need to include again in the ifdef part, but you have to include it in the #else part.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 17, 2007, 11:57:57 pm
thanks for the info killerbot

---

rev 36,37: updated headers per Mortens advice and fixed a bunch of bugs in FileExplorer popup menu commands (copy, rename, delete etc) (mostly affect win32 - damn wx inconsistencies)

Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 18, 2007, 12:20:59 am
latest win32 build here: http://developer.berlios.de/project/showfiles.php?group_id=7745&release_id=12960
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 19, 2007, 09:16:29 pm
rev 44 win32 build here: http://developer.berlios.de/project/showfiles.php?group_id=7745&release_id=12966

(fewer bugs and a couple more features including partially implemented multi file selections in the file explorer: move, copy and delete will still only handle one file at a time, but intepreter actions that have $mpaths in their command line will receive a space separated string containing the path of all the selected files - good for an svn stat command)
Title: Re: Support for Interpreted Languages?
Post by: MortenMacFly on June 20, 2007, 08:32:28 am
rev 44 win32 build
Just a minor note: For FileExplorer: IsFileWritable() is a wx28 method of wxFileName. This breaks compilation under wx26.
With regards, Morten.
Title: Re: Support for Interpreted Languages?
Post by: dmoore on June 20, 2007, 01:34:44 pm
Yeah, I've switched to wx2.8 because (a) I couldn't get the sort override to work for the treectrl in 2.6 and (b) that wxFileName method isn't implemented (despite being documented in the wx2.6.3 manual -- WTF??). I guess I should use an #ifdef for that piece of code and people will just have to put up with the missing features in wx2.6.
Title: Re: Support for Interpreted Languages?
Post by: sonya on May 11, 2008, 09:02:59 pm
Wher I can download the source of CBILPlugin?
Title: Re: Support for Interpreted Languages?
Post by: dmoore on May 12, 2008, 02:54:39 am
http://developer.berlios.de/svn/?group_id=7745

two plugins there: "ShellExtensions" and "CBPythonPlugin"