[ImageJ-devel] Macros and scripting in Imagej 2.0

Grant B. Harris gharris at mbl.edu
Thu Sep 8 12:18:37 CDT 2011


There are a number of different issues around 'Scripting'...

-- A "Default" IJ2 Scripting Language

I think when we speak of a script, we are referring to a 'high-level', 
domain-specific  language that makes it easy/ier to do image 
processing.  The ImageJ Macro language is certainly such a thing; so 
perhaps the question is whether it provides a good starting point for IJ2.

Since existing IJ1 Macros will continue to function through the Legacy 
layer,
we could 'migrate' the IJ1 Macro language to BeanShell with some changes 
that make it consonant with Java/C; that way users of IJ1 macros would 
only need to understand the changes, but would otherwise find it familiar.

-- Script Execution

The real value of the Java 6 ScriptingEngine is that it provides 
execution polyglotinousness.  ;-0
So plugins/modules written in any suppported language can be easily used 
by a naive user.

-- 'Macro' Recording

The ability to record events (macros) is useful for:
     - creating a sequence of actions that the user just wants to 
repeat.  In this case, the language used for the encoding is not 
important, as long as it works.
     - creating code that is the basis for a script or program that they 
want to write.  In this case, the user wants a choice of the language 
for the code that results from the recording.

-- Development Tools

     - Interactive Interpreter provides:
         - single stepping
         - keeping states and evaluating incrementally

     The interpretted scripting languages have interactive consoles that 
can be embedded in an application. (e.g. BeanShell and Jython have an 
interactive console, Clojure has its REPL.)

     - Code Editor provides
         - syntax highlighting
         - code completion
         - refactoring

     An editor may be integrated with an interactive console, allowing 
one or more lines to be selected and interpretted/executed.

     - Debugger might provide:
         - single stepping
         - setting breakpoints
         - state inspector of objects and variables
         - setting watches

     Jython has a debugging framework 
(http://www.jython.org/docs/library/bdb.html) and there are a variety of 
debugging tools that we might possible incorportate.

What development tools can we realisticly provide?  At some point a 
developer may be better served by an IDE.  Eclipse and NetBeans have 
plugins for most of the languages of consequence.

-- Grant


On 9/7/2011 5:54 PM, Johannes Schindelin wrote:
> Hi Grant,
>
> On Wed, 7 Sep 2011, Grant B. Harris wrote:
>
>> -- Scripting Languages
>>
>> Our plan is to use the scripting engine in Java 6 (JSR-223 Scripting for
>> the Java Platform).  This enables us to be
>> polyglotic/language-agnostic... Jython, Closure, JavaScript, etc.
> That's all good and well, but (correct me where I am wrong) JSR-223 does
> not support
>
> 	- single stepping
> 	- setting breakpoints
> 	- keeping states and evaluating incrementally
> 	- syntax highlighting
>
> All of these are required for development. (We do not support any single
> stepping nor similar in the Fiji Script Editor yet, but that is something
> we need to fix).
>
>> As mentioned in the chat, BeanShell is interesting for the fact that it
>> is syntactically very similar to the ImageJ Macro language - The Macro
>> Language is a DSL (domain specific language) for image processing and
>> manipulating the ImageJ environment.  "Porting" it to Beanshell (as
>> suggested by Dscho) sounds like a good idea.
> But it is not at all without problems. The most urgent problem is that the
> macro language has this quite surprising feature that you can assign
> variables thusly:
>
> 	getDimensions(width, height, depth, channels, frames);
>
> That is so out of line with C/Java like languages that it is impossible to
> support in Beanshell. I am currently looking into hacking the Beanshell
> interpreter to work around such problems, but it is hard.
>
> Ciao,
> Dscho
>




More information about the ImageJ-devel mailing list