Author Topic: Support for Interpreted Languages?  (Read 32894 times)

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Support for Interpreted Languages?
« Reply #30 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.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #31 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.
« Last Edit: November 20, 2006, 06:37:05 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #32 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?

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Support for Interpreted Languages?
« Reply #33 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.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #34 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)
« Last Edit: December 12, 2006, 08:41:40 pm by dmoore »

Offline keenblade

  • Multiple posting newcomer
  • *
  • Posts: 36
  • tao
    • keenblade
Re: Support for Interpreted Languages?
« Reply #35 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.
Anyway it\'s all the same at the end...

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #36 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
« Last Edit: November 20, 2006, 06:45:23 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #37 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

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #38 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/

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #39 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]
« Last Edit: June 14, 2007, 07:03:33 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #40 on: June 06, 2007, 05:58:18 pm »
a screenshot

[attachment deleted by admin]

Offline David Perfors

  • Developer
  • Lives here!
  • *****
  • Posts: 560
Re: Support for Interpreted Languages?
« Reply #41 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 :)
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #42 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)
« Last Edit: June 06, 2007, 09:14:23 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #43 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.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Support for Interpreted Languages?
« Reply #44 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)
« Last Edit: June 11, 2007, 05:02:15 pm by dmoore »