FIJI/IJ2 script editor

[Leon Espinosa-3]

Dear developers, I prefer to repport those problems here because I do not know if this is actually the "bugs" or a scheduled behavior of the editor change ... Some things do not work and others work differently by compared to FIJI/IJ1

in FIJI/IJ2
IJ.wait(1000);
in the editor "python" fails
in the editor javascript fails.
in the jython interpreter fails
in the javascript interpreter works OK

other IJ methods seems to work but I have not tested it all...


in FIJI/IJ1 javascript and python editor
IJ.beep();  OK

in FIJI/IJ2 editor javascript
IJ.beep();  fails
in FIJI/IJ2 javascript interpreter OK

in FIJI/IJ1 "python" editor
IJ.beep();  OK
in FIJI/IJ2 "python" editor
IJ.beep()   fails

in FIJI/IJ2 "python" editor
from ij import IJ as IJ
IJ.beep()    OK

in FIJI/IJ2 "python" interpreter
IJ.beep()  OK

I was unable to import ij.IJ in the FIJI/IJ2 javascript editor with "import ij.IJ.*;"  while  " from ij import IJ as IJ" works with the "python" editor...


I hope it helps for this great project
Thank you to all !!!

Leon

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Leon,

On Thu, 19 Jun 2014, Leon Espinosa wrote:

> I prefer to repport those problems here because I do not know if this is
> actually the "bugs" or a scheduled behavior of the editor change ...
> Some things do not work and others work differently by compared to
> FIJI/IJ1
>
> in FIJI/IJ2
> IJ.wait(1000);
> in the editor "python" fails
> in the editor javascript fails.
> in the jython interpreter fails
> in the javascript interpreter works OK

Please note that the interpreters will go away unless somebody else puts
in the work to port them to the SciJava scripting framework. (The reason
for SciJava's scripting framework's existence is exactly those
inconsistencies in IJ1's and previous Fiji's scripting which you pointed
out.)

As I just wrote in a mail to Christophe, the auto-imports (which you can
switch on in the script editor, but you should not!) are a dangeours
business. It's sloppy and will bite you *in the future*. When somebody
else introduces classes with the same name, and you will be puzzled no end
why things broke.

> in FIJI/IJ1 javascript and python editor
> IJ.beep();  OK
>
> in FIJI/IJ2 editor javascript
> IJ.beep();  fails
> in FIJI/IJ2 javascript interpreter OK
>
> in FIJI/IJ1 "python" editor
> IJ.beep();  OK
> in FIJI/IJ2 "python" editor
> IJ.beep()   fails
>
> in FIJI/IJ2 "python" editor
> from ij import IJ as IJ
> IJ.beep()    OK
>
> in FIJI/IJ2 "python" interpreter
> IJ.beep()  OK
>
> I was unable to import ij.IJ in the FIJI/IJ2 javascript editor with
> "import ij.IJ.*;"  while  " from ij import IJ as IJ" works with the
> "python" editor...

Yes, Javascript's syntax is a bit funky:

        importClass(Packages.ij.IJ);

Please, for all of our sakes (but especially mine because I want to spend
my time coding instead): use explicit imports all the time! And that
includes very much avoiding wildcard imports (i.e. *no* "import ij.*"!).

If anyone thinks wildcard imports are a Good Thing, I would like to remind
that someone that I had to spend a good 80 hours in total on that stupid
TextField issue with the Volume Viewer. And those issues were only caused
*by the use of wildcard imports*. On the caller's side.

Therefore, do everybody a favor, do not use auto-imports or wildcard
imports. Like, ever.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Leon Espinosa-3]

Perfect Johannes (and Jan) thank you !! I will never never use auto imports again or wilcards. So, another issue related how do you know where are the packages? (in order to put the right import command). In python/jython import ij.IJ works, in javascript the name is Packages.ij.IJ  how to know the correct name for a command in a particular language ?
Sorry for this poor knowledge of coding bases...

Leon



Le 19 juin 2014 à 16:54, Johannes Schindelin a écrit :

> Hi Leon,
>
> On Thu, 19 Jun 2014, Leon Espinosa wrote:
>
>> I prefer to repport those problems here because I do not know if this is
>> actually the "bugs" or a scheduled behavior of the editor change ...
>> Some things do not work and others work differently by compared to
>> FIJI/IJ1
>>
>> in FIJI/IJ2
>> IJ.wait(1000);
>> in the editor "python" fails
>> in the editor javascript fails.
>> in the jython interpreter fails
>> in the javascript interpreter works OK
>
> Please note that the interpreters will go away unless somebody else puts
> in the work to port them to the SciJava scripting framework. (The reason
> for SciJava's scripting framework's existence is exactly those
> inconsistencies in IJ1's and previous Fiji's scripting which you pointed
> out.)
>
> As I just wrote in a mail to Christophe, the auto-imports (which you can
> switch on in the script editor, but you should not!) are a dangeours
> business. It's sloppy and will bite you *in the future*. When somebody
> else introduces classes with the same name, and you will be puzzled no end
> why things broke.
>
>> in FIJI/IJ1 javascript and python editor
>> IJ.beep();  OK
>>
>> in FIJI/IJ2 editor javascript
>> IJ.beep();  fails
>> in FIJI/IJ2 javascript interpreter OK
>>
>> in FIJI/IJ1 "python" editor
>> IJ.beep();  OK
>> in FIJI/IJ2 "python" editor
>> IJ.beep()   fails
>>
>> in FIJI/IJ2 "python" editor
>> from ij import IJ as IJ
>> IJ.beep()    OK
>>
>> in FIJI/IJ2 "python" interpreter
>> IJ.beep()  OK
>>
>> I was unable to import ij.IJ in the FIJI/IJ2 javascript editor with
>> "import ij.IJ.*;"  while  " from ij import IJ as IJ" works with the
>> "python" editor...
>
> Yes, Javascript's syntax is a bit funky:
>
> importClass(Packages.ij.IJ);
>
> Please, for all of our sakes (but especially mine because I want to spend
> my time coding instead): use explicit imports all the time! And that
> includes very much avoiding wildcard imports (i.e. *no* "import ij.*"!).
>
> If anyone thinks wildcard imports are a Good Thing, I would like to remind
> that someone that I had to spend a good 80 hours in total on that stupid
> TextField issue with the Volume Viewer. And those issues were only caused
> *by the use of wildcard imports*. On the caller's side.
>
> Therefore, do everybody a favor, do not use auto-imports or wildcard
> imports. Like, ever.
>
> Ciao,
> Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Saalfeld, Stephan]

Hi Johannes and all Fiji-/ImageJ2 developers,

in my opinion, the interpreters are the most useful piece of Fiji.
Where everything else fails, the interpreters enable me to inspect,
test, prototype, and investigate.  We have entire workflows that heavily
depend on the stateful interactive behavior of the interpreters vs. the
monolithic stateless execution of scripts in the editor.  TrakEM2, as it
stands, is practically unusable without using an interpreter to
communicate with it.  The interpreters are Fiji's terminals.  Taking
them away is equivalent to removing the terminal from an operating
system.  I hope you feel with me that this is an outrageous idea.  It
does harm to people who rely on Fiji to do their work.

I agree that auto-imports are in principle evil and I remember that we
were all clear about that when you introduced them.  However, I see them
being extraordinarily useful in the terminal style use of the
interpreters that enabled me to efficiently work with Fiji in the past.
So why not letting the interpreters try to auto-import what's possible
and not doing so in the entirely different editor environment?

Whatever happens to auto-imports, please leave the interpreters in
place!  Please do not remove them just because you wish to have
everything prematurely streamlined with a particular library concept
that you consider superior tho the current state.  If the new library
concept makes it complicated to keep the interpreters, then this library
design has failed.  Fiji is not a toy, it's a tool to do work with.
Fiji needs a terminal!

Please keep Fiji's terminal!

Thanks and sorry for being polemic,
Stephan


On Thu, 2014-06-19 at 16:54 +0200, Johannes Schindelin wrote:

> Hi Leon,
>
> On Thu, 19 Jun 2014, Leon Espinosa wrote:
>
> > I prefer to repport those problems here because I do not know if this is
> > actually the "bugs" or a scheduled behavior of the editor change ...
> > Some things do not work and others work differently by compared to
> > FIJI/IJ1
> >
> > in FIJI/IJ2
> > IJ.wait(1000);
> > in the editor "python" fails
> > in the editor javascript fails.
> > in the jython interpreter fails
> > in the javascript interpreter works OK
>
> Please note that the interpreters will go away unless somebody else puts
> in the work to port them to the SciJava scripting framework. (The reason
> for SciJava's scripting framework's existence is exactly those
> inconsistencies in IJ1's and previous Fiji's scripting which you pointed
> out.)
>
> As I just wrote in a mail to Christophe, the auto-imports (which you can
> switch on in the script editor, but you should not!) are a dangeours
> business. It's sloppy and will bite you *in the future*. When somebody
> else introduces classes with the same name, and you will be puzzled no end
> why things broke.
>
> > in FIJI/IJ1 javascript and python editor
> > IJ.beep();  OK
> >
> > in FIJI/IJ2 editor javascript
> > IJ.beep();  fails
> > in FIJI/IJ2 javascript interpreter OK
> >
> > in FIJI/IJ1 "python" editor
> > IJ.beep();  OK
> > in FIJI/IJ2 "python" editor
> > IJ.beep()   fails
> >
> > in FIJI/IJ2 "python" editor
> > from ij import IJ as IJ
> > IJ.beep()    OK
> >
> > in FIJI/IJ2 "python" interpreter
> > IJ.beep()  OK
> >
> > I was unable to import ij.IJ in the FIJI/IJ2 javascript editor with
> > "import ij.IJ.*;"  while  " from ij import IJ as IJ" works with the
> > "python" editor...
>
> Yes, Javascript's syntax is a bit funky:
>
> importClass(Packages.ij.IJ);
>
> Please, for all of our sakes (but especially mine because I want to spend
> my time coding instead): use explicit imports all the time! And that
> includes very much avoiding wildcard imports (i.e. *no* "import ij.*"!).
>
> If anyone thinks wildcard imports are a Good Thing, I would like to remind
> that someone that I had to spend a good 80 hours in total on that stupid
> TextField issue with the Volume Viewer. And those issues were only caused
> *by the use of wildcard imports*. On the caller's side.
>
> Therefore, do everybody a favor, do not use auto-imports or wildcard
> imports. Like, ever.
>
> Ciao,
> Johannes
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--

Stephan Saalfeld, Ph.D.
Group Leader
Janelia Farm Research Campus
19700 Helix Drive | Ashburn, VA 20147
Phone: [phone] | Fax: [phone]
[hidden email]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Niko Ehrenfeuchter]

Dear IJ2 developers,

On 19.06.2014 17:49, Stephan Saalfeld wrote:
>
> Please keep Fiji's terminal!
>

I fully agree with Stephan on the interpreters topic, please please
please keep them! They make my scripting live incredibly much easier.

For the auto-imports stuff, I share Johannes' opinion. They're evil.

Thanks for all your work!
~Niko

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Albert Cardona-2]

As the creator of the interpreters, I would prefer if they were to remain.

But note that most of their functionality has been co-opted into the Script
Editor, which can be superior in some ways. Here is how I have used the
Script Editor like an interpreter:

1. Write a line of code.
2. Select it and execute just that line.
3. Write another line below
4. Select both lines and execute them, or just select the new line and
execute it in isolation.

That said, the *key difference* that makes the interpreters unique, and
better for a lot of use cases, is that the interpreter has *state* across
multiple executions. In other words, following from the example above, the
interpreters don't need to rerun the prior lines to execute the new line.

What I have wanted for some time was to merge the interpreters with the
Script Editor: to add a REPL (an interpreter) as a tiled window at the
bottom of the script editor, in the language of every tab. The state of one
such REPL would be unique for each tab. Someday.

For now, retaining the interpreters is the most appropriate, given their
unique capability of retaining state across executions.

Removing the auto-imports is fine, and these can be replaced by reading a
startup script specific of each language (as is common in many REPLs out
there).

Albert



2014-06-19 11:49 GMT-04:00 Stephan Saalfeld <[hidden email]>:

> Hi Johannes and all Fiji-/ImageJ2 developers,
>
> in my opinion, the interpreters are the most useful piece of Fiji.
> Where everything else fails, the interpreters enable me to inspect,
> test, prototype, and investigate.  We have entire workflows that heavily
> depend on the stateful interactive behavior of the interpreters vs. the
> monolithic stateless execution of scripts in the editor.  TrakEM2, as it
> stands, is practically unusable without using an interpreter to
> communicate with it.  The interpreters are Fiji's terminals.  Taking
> them away is equivalent to removing the terminal from an operating
> system.  I hope you feel with me that this is an outrageous idea.  It
> does harm to people who rely on Fiji to do their work.
>
> I agree that auto-imports are in principle evil and I remember that we
> were all clear about that when you introduced them.  However, I see them
> being extraordinarily useful in the terminal style use of the
> interpreters that enabled me to efficiently work with Fiji in the past.
> So why not letting the interpreters try to auto-import what's possible
> and not doing so in the entirely different editor environment?
>
> Whatever happens to auto-imports, please leave the interpreters in
> place!  Please do not remove them just because you wish to have
> everything prematurely streamlined with a particular library concept
> that you consider superior tho the current state.  If the new library
> concept makes it complicated to keep the interpreters, then this library
> design has failed.  Fiji is not a toy, it's a tool to do work with.
> Fiji needs a terminal!
>
> Please keep Fiji's terminal!
>
> Thanks and sorry for being polemic,
> Stephan
>
>
> On Thu, 2014-06-19 at 16:54 +0200, Johannes Schindelin wrote:
> > Hi Leon,
> >
> > On Thu, 19 Jun 2014, Leon Espinosa wrote:
> >
> > > I prefer to repport those problems here because I do not know if this
> is
> > > actually the "bugs" or a scheduled behavior of the editor change ...
> > > Some things do not work and others work differently by compared to
> > > FIJI/IJ1
> > >
> > > in FIJI/IJ2
> > > IJ.wait(1000);
> > > in the editor "python" fails
> > > in the editor javascript fails.
> > > in the jython interpreter fails
> > > in the javascript interpreter works OK
> >
> > Please note that the interpreters will go away unless somebody else puts
> > in the work to port them to the SciJava scripting framework. (The reason
> > for SciJava's scripting framework's existence is exactly those
> > inconsistencies in IJ1's and previous Fiji's scripting which you pointed
> > out.)
> >
> > As I just wrote in a mail to Christophe, the auto-imports (which you can
> > switch on in the script editor, but you should not!) are a dangeours
> > business. It's sloppy and will bite you *in the future*. When somebody
> > else introduces classes with the same name, and you will be puzzled no
> end
> > why things broke.
> >
> > > in FIJI/IJ1 javascript and python editor
> > > IJ.beep();  OK
> > >
> > > in FIJI/IJ2 editor javascript
> > > IJ.beep();  fails
> > > in FIJI/IJ2 javascript interpreter OK
> > >
> > > in FIJI/IJ1 "python" editor
> > > IJ.beep();  OK
> > > in FIJI/IJ2 "python" editor
> > > IJ.beep()   fails
> > >
> > > in FIJI/IJ2 "python" editor
> > > from ij import IJ as IJ
> > > IJ.beep()    OK
> > >
> > > in FIJI/IJ2 "python" interpreter
> > > IJ.beep()  OK
> > >
> > > I was unable to import ij.IJ in the FIJI/IJ2 javascript editor with
> > > "import ij.IJ.*;"  while  " from ij import IJ as IJ" works with the
> > > "python" editor...
> >
> > Yes, Javascript's syntax is a bit funky:
> >
> >       importClass(Packages.ij.IJ);
> >
> > Please, for all of our sakes (but especially mine because I want to spend
> > my time coding instead): use explicit imports all the time! And that
> > includes very much avoiding wildcard imports (i.e. *no* "import ij.*"!).
> >
> > If anyone thinks wildcard imports are a Good Thing, I would like to
> remind
> > that someone that I had to spend a good 80 hours in total on that stupid
> > TextField issue with the Volume Viewer. And those issues were only caused
> > *by the use of wildcard imports*. On the caller's side.
> >
> > Therefore, do everybody a favor, do not use auto-imports or wildcard
> > imports. Like, ever.
> >
> > Ciao,
> > Johannes
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
>
> Stephan Saalfeld, Ph.D.
> Group Leader
> Janelia Farm Research Campus
> 19700 Helix Drive | Ashburn, VA 20147
> Phone: [phone] | Fax: [phone]
> [hidden email]
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
http://albert.rierol.net
http://www.ini.uzh.ch/~acardona/

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Leon,

> how to know the correct name for a command in a particular language ?

It is documented on the wiki on each respective language's page; links at:
http://wiki.imagej.net/Scripting#Supported_languages

E.g., for Javascript:
http://wiki.imagej.net/Javascript_Scripting#Importing_packages_and_classes
(though note that the docs are out of date w.r.t. the auto-import info)

Regards,
Curtis


On Thu, Jun 19, 2014 at 10:18 AM, Leon Espinosa <[hidden email]>
wrote:

> Perfect Johannes (and Jan) thank you !! I will never never use auto
> imports again or wilcards. So, another issue related how do you know where
> are the packages? (in order to put the right import command). In
> python/jython import ij.IJ works, in javascript the name is Packages.ij.IJ
>  how to know the correct name for a command in a particular language ?
> Sorry for this poor knowledge of coding bases...
>
> Leon
>
>
>
> Le 19 juin 2014 à 16:54, Johannes Schindelin a écrit :
>
> > Hi Leon,
> >
> > On Thu, 19 Jun 2014, Leon Espinosa wrote:
> >
> >> I prefer to repport those problems here because I do not know if this is
> >> actually the "bugs" or a scheduled behavior of the editor change ...
> >> Some things do not work and others work differently by compared to
> >> FIJI/IJ1
> >>
> >> in FIJI/IJ2
> >> IJ.wait(1000);
> >> in the editor "python" fails
> >> in the editor javascript fails.
> >> in the jython interpreter fails
> >> in the javascript interpreter works OK
> >
> > Please note that the interpreters will go away unless somebody else puts
> > in the work to port them to the SciJava scripting framework. (The reason
> > for SciJava's scripting framework's existence is exactly those
> > inconsistencies in IJ1's and previous Fiji's scripting which you pointed
> > out.)
> >
> > As I just wrote in a mail to Christophe, the auto-imports (which you can
> > switch on in the script editor, but you should not!) are a dangeours
> > business. It's sloppy and will bite you *in the future*. When somebody
> > else introduces classes with the same name, and you will be puzzled no
> end
> > why things broke.
> >
> >> in FIJI/IJ1 javascript and python editor
> >> IJ.beep();  OK
> >>
> >> in FIJI/IJ2 editor javascript
> >> IJ.beep();  fails
> >> in FIJI/IJ2 javascript interpreter OK
> >>
> >> in FIJI/IJ1 "python" editor
> >> IJ.beep();  OK
> >> in FIJI/IJ2 "python" editor
> >> IJ.beep()   fails
> >>
> >> in FIJI/IJ2 "python" editor
> >> from ij import IJ as IJ
> >> IJ.beep()    OK
> >>
> >> in FIJI/IJ2 "python" interpreter
> >> IJ.beep()  OK
> >>
> >> I was unable to import ij.IJ in the FIJI/IJ2 javascript editor with
> >> "import ij.IJ.*;"  while  " from ij import IJ as IJ" works with the
> >> "python" editor...
> >
> > Yes, Javascript's syntax is a bit funky:
> >
> >       importClass(Packages.ij.IJ);
> >
> > Please, for all of our sakes (but especially mine because I want to spend
> > my time coding instead): use explicit imports all the time! And that
> > includes very much avoiding wildcard imports (i.e. *no* "import ij.*"!).
> >
> > If anyone thinks wildcard imports are a Good Thing, I would like to
> remind
> > that someone that I had to spend a good 80 hours in total on that stupid
> > TextField issue with the Volume Viewer. And those issues were only caused
> > *by the use of wildcard imports*. On the caller's side.
> >
> > Therefore, do everybody a favor, do not use auto-imports or wildcard
> > imports. Like, ever.
> >
> > Ciao,
> > Johannes
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Albert,

On Thu, 19 Jun 2014, Albert Cardona wrote:

> As the creator of the interpreters, I would prefer if they were to
> remain.

But... how dedicated are you in that goal? Will you port them to the
SciJava scripting framework, as I had indicated I would not be able afford
the time?

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Albert Cardona-2]

> On Jun 19, 2014, at 6:47 PM, Johannes Schindelin <[hidden email]> wrote:
>
> Hi Albert,
>
>> On Thu, 19 Jun 2014, Albert Cardona wrote:
>>
>> As the creator of the interpreters, I would prefer if they were to
>> remain.
>
> But... how dedicated are you in that goal? Will you port them to the
> SciJava scripting framework, as I had indicated I would not be able afford
> the time?
>
> Ciao,
> Johannes

Johannes,

Once you told me "never ever change a working system".

Why gut the working scripting framework to create a new one? It is orthogonal to image processing and any data structures.

Alert
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Albert & everyone,

> Why gut the working scripting framework to create a new one? It is
> orthogonal to image processing and any data structures.

The reasons we rewrote the scripting system are:

1) Integration with the ImageJ/SciJava module framework. This allows
scripts to declare typed inputs and outputs, which are usable from other
contexts besides just ImageJ.

Example scripts at:
*
https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_BeanShell.bsh
*
https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_JavaScript.js

Example commands in Java:
*
https://github.com/imagej/imagej-tutorials/tree/577286474be8399eb38d30d66cf0c35ee50bd929/simple-commands/src/main/java

Tutorial explaining modules:
*
https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/working-with-modules/src/main/java/WorkingWithModules.java

Such modules are UI agnostic, and already usable from CellProfiler, KNIME,
OMERO and Alida [1].

2) Extensibility. It is now feasible to add additional scripting languages
to ImageJ, because scripting languages are just plugins. Johannes has
already done Scala [2] and we are also half done with R [3]. No code
changes to the core codebase are required. So anyone can add a new ImageJ
update site that adds support for new scripting languages.

Regards,
Curtis

[1] See also: http://developer.imagej.net/2014/04/04/announcing-imagej-ops
[2] https://github.com/scijava/scripting-scala
[3] https://github.com/scijava/scripting-r


On Thu, Jun 19, 2014 at 6:49 PM, Albert Cardona <[hidden email]> wrote:

> > On Jun 19, 2014, at 6:47 PM, Johannes Schindelin <
> [hidden email]> wrote:
> >
> > Hi Albert,
> >
> >> On Thu, 19 Jun 2014, Albert Cardona wrote:
> >>
> >> As the creator of the interpreters, I would prefer if they were to
> >> remain.
> >
> > But... how dedicated are you in that goal? Will you port them to the
> > SciJava scripting framework, as I had indicated I would not be able
> afford
> > the time?
> >
> > Ciao,
> > Johannes
>
>
> Johannes,
>
> Once you told me "never ever change a working system".
>
> Why gut the working scripting framework to create a new one? It is
> orthogonal to image processing and any data structures.
>
> Alert
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Albert Cardona-2]

Hi Curtis,

while this reads great, removing the interpreters is not an option, given
their key position in enabling straightforward interactive image processing
a-la Matlab, but with all the java and ImageJ-specific libraries.

Additionally and as I commented in the bug tracker (
http://fiji.sc/bugzilla/show_bug.cgi?id=793 ), the interpreters have unique
capabilities, and many users rely on them for both the execution of complex
pipelines and the testing out and development of programs.

A note about the typed inputs and outputs in scripts: while I understand
why you'd want this feature, it cannot come at the cost of removing and not
replacing existing functionality.

Albert


2014-06-24 10:52 GMT-04:00 Curtis Rueden <[hidden email]>:

> Hi Albert & everyone,
>
> > Why gut the working scripting framework to create a new one? It is
> > orthogonal to image processing and any data structures.
>
> The reasons we rewrote the scripting system are:
>
> 1) Integration with the ImageJ/SciJava module framework. This allows
> scripts to declare typed inputs and outputs, which are usable from other
> contexts besides just ImageJ.
>
> Example scripts at:
> *
>
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_BeanShell.bsh
> *
>
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_JavaScript.js
>
> Example commands in Java:
> *
>
> https://github.com/imagej/imagej-tutorials/tree/577286474be8399eb38d30d66cf0c35ee50bd929/simple-commands/src/main/java
>
> Tutorial explaining modules:
> *
>
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/working-with-modules/src/main/java/WorkingWithModules.java
>
> Such modules are UI agnostic, and already usable from CellProfiler, KNIME,
> OMERO and Alida [1].
>
> 2) Extensibility. It is now feasible to add additional scripting languages
> to ImageJ, because scripting languages are just plugins. Johannes has
> already done Scala [2] and we are also half done with R [3]. No code
> changes to the core codebase are required. So anyone can add a new ImageJ
> update site that adds support for new scripting languages.
>
> Regards,
> Curtis
>
> [1] See also: http://developer.imagej.net/2014/04/04/announcing-imagej-ops
> [2] https://github.com/scijava/scripting-scala
> [3] https://github.com/scijava/scripting-r
>
>
> On Thu, Jun 19, 2014 at 6:49 PM, Albert Cardona <[hidden email]>
> wrote:
>
> > > On Jun 19, 2014, at 6:47 PM, Johannes Schindelin <
> > [hidden email]> wrote:
> > >
> > > Hi Albert,
> > >
> > >> On Thu, 19 Jun 2014, Albert Cardona wrote:
> > >>
> > >> As the creator of the interpreters, I would prefer if they were to
> > >> remain.
> > >
> > > But... how dedicated are you in that goal? Will you port them to the
> > > SciJava scripting framework, as I had indicated I would not be able
> > afford
> > > the time?
> > >
> > > Ciao,
> > > Johannes
> >
> >
> > Johannes,
> >
> > Once you told me "never ever change a working system".
> >
> > Why gut the working scripting framework to create a new one? It is
> > orthogonal to image processing and any data structures.
> >
> > Alert
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
http://albert.rierol.net
http://www.ini.uzh.ch/~acardona/

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Saalfeld, Stephan]

Thanks Curtis.  And sorry again for being polemic in my last post.

I want to make sure that everybody understands that I am not questioning
the usability of the scripting system for what it's been designed for:
extensible, standardized execution of foreign language programs,
compatible with how ImageJ2's plugin system works (please correct me if
this is wrong).

However, the interpreters in Fiji serve a very different purpose:
stateful, UI interrupted, ad hoc communication with the running Fiji
instance.  Exactly in the same way I would use the terminal in an
operating system.  Example workflow:

# I want to assign a transformation of a TrakEM2 patch
# to other TrakEM2 patches in another project

# I click the patch that has the desired transformation

ct = Display.getFront().getActive().getCoordinateTransform();

# I select some desired patches in the other project by clicking them

for (p : Display.getFront().getSelection().getSelected())
  p.setCoordinateTransform(ct);

That's my daily life.  There is no straight way to do this with the
script editor, a script, or a plugin, because they do not preserve state
between executions or require me to express the UI interaction with the
instance between the two script lines in the script (or wait for it
somehow).

I do not understand what parts of ImageJ2's scripting system would be
beneficial for this mode of operation and therefore do not understand
why the interpreters would need to be ported.

Again, I am sorry if I came across rude in my initial post, but I simply
panicked hearing in a side note that the key tool for my daily use of
Fiji would get removed for reasons that are beyond my understanding.

Thanks and best,
Stephan



On Tue, 2014-06-24 at 09:52 -0500, Curtis Rueden wrote:

> Hi Albert & everyone,
>
> > Why gut the working scripting framework to create a new one? It is
> > orthogonal to image processing and any data structures.
>
> The reasons we rewrote the scripting system are:
>
> 1) Integration with the ImageJ/SciJava module framework. This allows
> scripts to declare typed inputs and outputs, which are usable from other
> contexts besides just ImageJ.
>
> Example scripts at:
> *
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_BeanShell.bsh
> *
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_JavaScript.js
>
> Example commands in Java:
> *
> https://github.com/imagej/imagej-tutorials/tree/577286474be8399eb38d30d66cf0c35ee50bd929/simple-commands/src/main/java
>
> Tutorial explaining modules:
> *
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/working-with-modules/src/main/java/WorkingWithModules.java
>
> Such modules are UI agnostic, and already usable from CellProfiler, KNIME,
> OMERO and Alida [1].
>
> 2) Extensibility. It is now feasible to add additional scripting languages
> to ImageJ, because scripting languages are just plugins. Johannes has
> already done Scala [2] and we are also half done with R [3]. No code
> changes to the core codebase are required. So anyone can add a new ImageJ
> update site that adds support for new scripting languages.
>
> Regards,
> Curtis
>
> [1] See also: http://developer.imagej.net/2014/04/04/announcing-imagej-ops
> [2] https://github.com/scijava/scripting-scala
> [3] https://github.com/scijava/scripting-r
>
>
> On Thu, Jun 19, 2014 at 6:49 PM, Albert Cardona <[hidden email]> wrote:
>
> > > On Jun 19, 2014, at 6:47 PM, Johannes Schindelin <
> > [hidden email]> wrote:
> > >
> > > Hi Albert,
> > >
> > >> On Thu, 19 Jun 2014, Albert Cardona wrote:
> > >>
> > >> As the creator of the interpreters, I would prefer if they were to
> > >> remain.
> > >
> > > But... how dedicated are you in that goal? Will you port them to the
> > > SciJava scripting framework, as I had indicated I would not be able
> > afford
> > > the time?
> > >
> > > Ciao,
> > > Johannes
> >
> >
> > Johannes,
> >
> > Once you told me "never ever change a working system".
> >
> > Why gut the working scripting framework to create a new one? It is
> > orthogonal to image processing and any data structures.
> >
> > Alert
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[moosekaka]

Hi, I just updated my Fiji and it is now using IJ2 script editor, my question is how do I even start the script editor???? Right now I can open my old *ijm macros by opening them via the file/open menu and it automatically starts up the script editor but is there another way?

Also in the old script editor you could highlight a imageJ macro function, press F1 and get help on the function, now the new editor still highlights the function in a different color but I cant get help just by selecting the function.

thank you.

[jni]

I'm a little late to this discussion, but I'd like to also voice my support
for keeping the interpreters. I fully understand that open-source software
is severely time-restricted and that it takes more than votes to implement
a feature. However, the number of requests certainly affects prioritisation
so I thought writing was better than staying silent.

I wrote a blog post a few months ago detailing
<http://ilovesymposia.com/2014/02/26/fiji-jython/> how useful I found the
interpreter to develop my scripts (tip #4). I would hate for that post to
be obsolete so soon after I wrote it. =P

Additionally, I find it surprising that this move is being considered given
that (at least) two prominent Fiji developers are not on board... Coming
from the Python world, where the Python 3 transition remains stalled after
6 years, I think that such a divisive move will split the Fiji development
community, with many continuing to use the IJ1 version while others move to
IJ2. That can't be a good thing.

Again, I don't really have a solution for this... Just a suggestion that
support maybe should be higher on developers' list than it currently is.

Juan.


On Tue, Jun 24, 2014 at 10:59 AM, Stephan Saalfeld <
[hidden email]> wrote:

> Thanks Curtis.  And sorry again for being polemic in my last post.
>
> I want to make sure that everybody understands that I am not questioning
> the usability of the scripting system for what it's been designed for:
> extensible, standardized execution of foreign language programs,
> compatible with how ImageJ2's plugin system works (please correct me if
> this is wrong).
>
> However, the interpreters in Fiji serve a very different purpose:
> stateful, UI interrupted, ad hoc communication with the running Fiji
> instance.  Exactly in the same way I would use the terminal in an
> operating system.  Example workflow:
>
> # I want to assign a transformation of a TrakEM2 patch
> # to other TrakEM2 patches in another project
>
> # I click the patch that has the desired transformation
>
> ct = Display.getFront().getActive().getCoordinateTransform();
>
> # I select some desired patches in the other project by clicking them
>
> for (p : Display.getFront().getSelection().getSelected())
>   p.setCoordinateTransform(ct);
>
> That's my daily life.  There is no straight way to do this with the
> script editor, a script, or a plugin, because they do not preserve state
> between executions or require me to express the UI interaction with the
> instance between the two script lines in the script (or wait for it
> somehow).
>
> I do not understand what parts of ImageJ2's scripting system would be
> beneficial for this mode of operation and therefore do not understand
> why the interpreters would need to be ported.
>
> Again, I am sorry if I came across rude in my initial post, but I simply
> panicked hearing in a side note that the key tool for my daily use of
> Fiji would get removed for reasons that are beyond my understanding.
>
> Thanks and best,
> Stephan
>
>
>
> On Tue, 2014-06-24 at 09:52 -0500, Curtis Rueden wrote:
> > Hi Albert & everyone,
> >
> > > Why gut the working scripting framework to create a new one? It is
> > > orthogonal to image processing and any data structures.
> >
> > The reasons we rewrote the scripting system are:
> >
> > 1) Integration with the ImageJ/SciJava module framework. This allows
> > scripts to declare typed inputs and outputs, which are usable from other
> > contexts besides just ImageJ.
> >
> > Example scripts at:
> > *
> >
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_BeanShell.bsh
> > *
> >
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/widget-demo/scripts/Widgets_JavaScript.js
> >
> > Example commands in Java:
> > *
> >
> https://github.com/imagej/imagej-tutorials/tree/577286474be8399eb38d30d66cf0c35ee50bd929/simple-commands/src/main/java
> >
> > Tutorial explaining modules:
> > *
> >
> https://github.com/imagej/imagej-tutorials/blob/577286474be8399eb38d30d66cf0c35ee50bd929/working-with-modules/src/main/java/WorkingWithModules.java
> >
> > Such modules are UI agnostic, and already usable from CellProfiler,
> KNIME,
> > OMERO and Alida [1].
> >
> > 2) Extensibility. It is now feasible to add additional scripting
> languages
> > to ImageJ, because scripting languages are just plugins. Johannes has
> > already done Scala [2] and we are also half done with R [3]. No code
> > changes to the core codebase are required. So anyone can add a new ImageJ
> > update site that adds support for new scripting languages.
> >
> > Regards,
> > Curtis
> >
> > [1] See also:
> http://developer.imagej.net/2014/04/04/announcing-imagej-ops
> > [2] https://github.com/scijava/scripting-scala
> > [3] https://github.com/scijava/scripting-r
> >
> >
> > On Thu, Jun 19, 2014 at 6:49 PM, Albert Cardona <[hidden email]>
> wrote:
> >
> > > > On Jun 19, 2014, at 6:47 PM, Johannes Schindelin <
> > > [hidden email]> wrote:
> > > >
> > > > Hi Albert,
> > > >
> > > >> On Thu, 19 Jun 2014, Albert Cardona wrote:
> > > >>
> > > >> As the creator of the interpreters, I would prefer if they were to
> > > >> remain.
> > > >
> > > > But... how dedicated are you in that goal? Will you port them to the
> > > > SciJava scripting framework, as I had indicated I would not be able
> > > afford
> > > > the time?
> > > >
> > > > Ciao,
> > > > Johannes
> > >
> > >
> > > Johannes,
> > >
> > > Once you told me "never ever change a working system".
> > >
> > > Why gut the working scripting framework to create a new one? It is
> > > orthogonal to image processing and any data structures.
> > >
> > > Alert
> > > --
> > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> > >
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Juan,

On Fri, 18 Jul 2014, Juan Nunez-Iglesias wrote:

> I'm a little late to this discussion, but I'd like to also voice my support
> for keeping the interpreters.

Noted.

:-)

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html