Bug in newArray() macro function (was "Re: Strange variable type for arrays filled from a dialog in macro language ?")

[lechristophe]

Hi,

I think there is a (maybe) related problem with the newArray()
function. The following macro:

test=newArray(0,1,2,3);
test2=newArray(test[0],test[1]);
print(test2[0]);

gives the following error (with 1.45q):

 ")" expected in line 2
test2=newArray(test[0]<,>test[1]);

I would expect this syntax to work?

Thanks for your help,

Christophe



On Thu, Sep 29, 2011 at 04:14, Rasband, Wayne (NIH/NIMH) [E]
<[hidden email]> wrote:

>
> On Sep 28, 2011, at 7:30 AM, Christophe Leterrier wrote:
>
> > Hi,
> >
> > Please consider the following macro snippet:
> >
> > Dialog.create("Dialog");
> > Dialog.addString("string 1", "1");
> > Dialog.addString("string 2", "2");
> > Dialog.addString("string 3", "No");
> > Dialog.show();
> > TEXT1=Dialog.getString();
> > TEXT2=Dialog.getString();
> > TEXT3=Dialog.getString();
> >
> > ARRAY=newArray("1", "2", "No");
> > if (ARRAY[2]=="No") print("success");
> >
> > ARRAYDIALOG=newArray(TEXT1, TEXT2, TEXT3);
> > if (ARRAYDIALOG[2]=="No") print("success");
> >
> > ARRAY and ARRAYDIALOG should be exactly the same, containing three strings
> > "1", "2" and "No". ARRAY is directly defined, whereas ARRAYDIALOG is defined
> > via a dialog box that gets the user to enter strings. Just run the macro and
> > click "OK" in the Dialog, leaving the default text values. The test on
> > ARRAY[2] prints "success", but the second test for ARRAYDIALOG[2]=="No"
> > unexpectedly triggers the error "Number or numeric function expected".
> >
> > I think this is a bug that has to do with the types of variables returned by
> > Dialog.getString(). Or am I confused ?
>
> It is a bug in the newArray() function that is fixed in the ImageJ 1.45q daily build.
>
> -wayne

[Herbie-6]

Christophe,

similar to last time's situation. If you can live with number as
strings you may try:

test = newArray( 0, 1, 2, 3 );
test2 = newArray( ""+test[0], test[1] );
print( test2[0] );

which runs fine for me.

Best

                   Herbie

          ------------------------
          <http://www.gluender.de>

>Hi,
>
>I think there is a (maybe) related problem with the newArray()
>function. The following macro:
>
>test=newArray(0,1,2,3);
>test2=newArray(test[0],test[1]);
>print(test2[0]);
>
>gives the following error (with 1.45q):
>
>  ")" expected in line 2
>test2=newArray(test[0]<,>test[1]);
>
>I would expect this syntax to work?
>
>Thanks for your help,
>
>Christophe
>
>
>
>On Thu, Sep 29, 2011 at 04:14, Rasband, Wayne (NIH/NIMH) [E]
><[hidden email]> wrote:
>>
>>  On Sep 28, 2011, at 7:30 AM, Christophe Leterrier wrote:
>>
>>  > Hi,
>>  >
>>  > Please consider the following macro snippet:
>>  >
>>  > Dialog.create("Dialog");
>>  > Dialog.addString("string 1", "1");
>>  > Dialog.addString("string 2", "2");
>>  > Dialog.addString("string 3", "No");
>>  > Dialog.show();
>>  > TEXT1=Dialog.getString();
>>  > TEXT2=Dialog.getString();
>>  > TEXT3=Dialog.getString();
>>  >
>>  > ARRAY=newArray("1", "2", "No");
>>  > if (ARRAY[2]=="No") print("success");
>>  >
>>  > ARRAYDIALOG=newArray(TEXT1, TEXT2, TEXT3);
>>  > if (ARRAYDIALOG[2]=="No") print("success");
>>  >
>>  > ARRAY and ARRAYDIALOG should be exactly the same, containing three strings
>>  > "1", "2" and "No". ARRAY is directly defined, whereas
>>ARRAYDIALOG is defined
>>  > via a dialog box that gets the user to enter strings. Just run
>>the macro and
>>  > click "OK" in the Dialog, leaving the default text values. The test on
>>  > ARRAY[2] prints "success", but the second test for ARRAYDIALOG[2]=="No"
>>  > unexpectedly triggers the error "Number or numeric function expected".
>>  >
>>  > I think this is a bug that has to do with the types of variables
>>returned by
>>  > Dialog.getString(). Or am I confused ?
>>
>>  It is a bug in the newArray() function that is fixed in the ImageJ
>>1.45q daily build.
>>
>>  -wayne

[Rasband, Wayne (NIH/NIMH) [E]]

On Oct 14, 2011, at 11:36 AM, Christophe Leterrier wrote:

> Hi,
>
> I think there is a (maybe) related problem with the newArray()
> function. The following macro:
>
> test=newArray(0,1,2,3);
> test2=newArray(test[0],test[1]);
> print(test2[0]);
>
> gives the following error (with 1.45q):
>
>  ")" expected in line 2
> test2=newArray(test[0]<,>test[1]);
>
> I would expect this syntax to work?

This bug is fixed in the 1.45r daily build.

Thanks to Norbert Vischer, the daily build also supports auto-expanding arrays. Here is an example:

  requires("1.45r");
  cars = newArray;
  cars[0] = "Saab";
  cars[1] = "Volvo";
  cars[2] = "BMW";
  cars[4] = "Ford";
  for (i=0; i<cars.length; i++)
      print(cars[i]);

The statement

  cars = newArray;

is equivalent to

  cars = newArray(0);

-wayne

[dscho]

Hi Wayne,

On Fri, 14 Oct 2011, Rasband, Wayne (NIH/NIMH) [E] wrote:

> On Oct 14, 2011, at 11:36 AM, Christophe Leterrier wrote:
>
> > I think there is a (maybe) related problem with the newArray()
> > function. The following macro:
> >
> > test=newArray(0,1,2,3);
> > test2=newArray(test[0],test[1]);
> > print(test2[0]);
> >
> > gives the following error (with 1.45q):
> >
> >  ")" expected in line 2
> > test2=newArray(test[0]<,>test[1]);
> >
> > I would expect this syntax to work?
>
> This bug is fixed in the 1.45r daily build.
>
> Thanks to Norbert Vischer, the daily build also supports auto-expanding arrays. Here is an example:
>
>   requires("1.45r");
>   cars = newArray;
>   cars[0] = "Saab";
>   cars[1] = "Volvo";
>   cars[2] = "BMW";
>   cars[4] = "Ford";
>   for (i=0; i<cars.length; i++)
>       print(cars[i]);
>
> The statement
>
>   cars = newArray;
>
> is equivalent to
>
>   cars = newArray(0);

This feature will make it much harder, or even impossible, to support the
macro language with reasonable effort in ImageJ2.

Ciao,
Johannes

[Albert Cardona-2]

2011/10/14 Johannes Schindelin <[hidden email]>:

> Hi Wayne,
>
> On Fri, 14 Oct 2011, Rasband, Wayne (NIH/NIMH) [E] wrote:
>
>> On Oct 14, 2011, at 11:36 AM, Christophe Leterrier wrote:
>>
>> > I think there is a (maybe) related problem with the newArray()
>> > function. The following macro:
>> >
>> > test=newArray(0,1,2,3);
>> > test2=newArray(test[0],test[1]);
>> > print(test2[0]);
>> >
>> > gives the following error (with 1.45q):
>> >
>> >  ")" expected in line 2
>> > test2=newArray(test[0]<,>test[1]);
>> >
>> > I would expect this syntax to work?
>>
>> This bug is fixed in the 1.45r daily build.
>>
>> Thanks to Norbert Vischer, the daily build also supports auto-expanding arrays. Here is an example:
>>
>>   requires("1.45r");
>>   cars = newArray;
>>   cars[0] = "Saab";
>>   cars[1] = "Volvo";
>>   cars[2] = "BMW";
>>   cars[4] = "Ford";
>>   for (i=0; i<cars.length; i++)
>>       print(cars[i]);
>>
>> The statement
>>
>>   cars = newArray;
>>
>> is equivalent to
>>
>>   cars = newArray(0);
>
> This feature will make it much harder, or even impossible, to support the
> macro language with reasonable effort in ImageJ2.

Johannes,

couldn't it be done by using a TreeMap and each array assignment as a
TreeMap.put?

Just use integers as array keys. The TreeMap (which is a SortedMap)
will take care of the order when iterating.

Albert




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

[dscho]

Dear Albert,

[heads-up: this mail is long, but I tried to keep the in-depth
information in footnotes.]

On Sat, 15 Oct 2011, Albert Cardona wrote:

> 2011/10/14 Johannes Schindelin <[hidden email]>:
>
> > On Fri, 14 Oct 2011, Rasband, Wayne (NIH/NIMH) [E] wrote:
> >
> >> Thanks to Norbert Vischer, the daily build also supports
> >> auto-expanding arrays. Here is an example:
> >>
> >>   requires("1.45r");
> >>   cars = newArray;
> >>   cars[0] = "Saab";
> >>   cars[1] = "Volvo";
> >>   cars[2] = "BMW";
> >>   cars[4] = "Ford";
> >>   for (i=0; i<cars.length; i++)
> >>       print(cars[i]);
> >>
> >> The statement
> >>
> >>   cars = newArray;
> >>
> >> is equivalent to
> >>
> >>   cars = newArray(0);
> >
> > This feature will make it much harder, or even impossible, to support
> > the macro language with reasonable effort in ImageJ2.
>
> couldn't it be done by using a TreeMap and each array assignment as a
> TreeMap.put?
>
> Just use integers as array keys. The TreeMap (which is a SortedMap)
> will take care of the order when iterating.

There is not the faintest problem with the semantics this tries to do. You
could even use a LinkedHashMap. But the _syntax_ abuses a formerly
well-defined (and well-established, when you know a lot of programming
languages) paradigm to shoehorne in a desired functionality.

And the _syntax_ changes are incompatible with any of our plans to support
the macro language[*1*].

I would have _much_ preferred it if better programming languages were
supported by ImageJ, and for the recorder to gain a well-designed
language-agnostic layer. You probably remember our attempts to get this
into ImageJ with the CommandListenerPlus and the Python recorder, none of
which made it. Not even the Javascript recorder is well abstracted, and as
a consequence the three recorder modes -- macro, Javascript, Java -- all
have their own, unrelated sets of bugs.

Now, the big plan for ImageJ2 was always to be fully backwards compatible,
right? You know that I pushed for this harder than anybody else. I
convinced you and Grant and Curtis that we'd lose users if we would not
provide this.[*2*]

Now, with this addition to the macro language, there is no way anymore to
provide full backwards-compatibility without an unreasonable effort.

Remember: in ImageJ2 we want that well-designed, language-agnostic layer
that allows us to plug _any_ language with even more ease than you managed
already with the AbstractInterpreter in Fiji. Just think about it: plug
Scala in and - abracadabra - you can record Scala scripts. That is what I
am aming for.

But we cannot really rewrite[*3*] nor maintain the macro language in such
an infrastructure. It would be a big project on its own for which we lack
the time, and besides, I always hated the fact that the macro API and the
Java API differ.

We had long discussions about this in the ImageJ project, and we ended up
with the following compromise: we would implement as much as possible of
the macro API in a single class, as static functions[*4*]. Then we would
pick the language most similar to the macro language for which we have an
implementation which is maintained well by a 3rd party: Beanshell. And
then we would work around issues[*5*].

The advantages are galore: well-maintained (and we do not have to take
care of it), shared API between macros and programs (and for that matter,
all the scripting languages), new API functions automatically trickle down
from Java to the macros, i.e. you do not have to do twice the work to
support macro users and Java users when adding features, it's faster, it's
much easier to start out writing a macro and then turning it into a proper
plugin, you can use tons of 3rd party libraries, you could even interact
with native libraries if you so wish, and many, many more.

But that new syntax for auto-expanding arrays is not "around-worakable",
short of rewriting the complete parser, which -- as I mentioned -- is
infeasible.

In short: my dreams have been shattered, we cannot have full
backwards-compatibility in ImageJ2.

I hope this clarifies the situation,
Johannes

P.S.: Big warning to all the macro language users out there: if you want
to run your macros in the future without being stuck with an obsolete
version of ImageJ, do not use the auto-expanding arrays feature. If you
need some advanced feature like that, use a well-established language that
supports it, like Python.

P.P.S.: I hope it is now abundantly clear that I put a lot of thought into
this, and that my despair about the array syntax is not one of my common
overreactions.

Footnote [*1*]: The syntax changes are only compatible with the
        one plan I am not willing to accept: limiting macros to ImageJ1
        functionality, including the restriction to 4 data types, to 5
        dimensions, to all-of-your-data-in-memory or at least the complete
        slices -- including your 32k by 32k slices which cannot fit into
        Java arrays and therefore cannot be processed with ImageJ1.

        I think you agree that this is a direction that is unsustainable.

Footnote [*2*]: The first big collection of plugins, MacBiophotonics,
        might serve as a big warning: a lot of the plugins do not work
        with newer ImageJ versions. They are broken by newer ImageJ
        versions. So the users stay with the old ImageJ version, which is
        broken in other ways.

        So what people do is to have multiple ImageJ installations, with
        disjunct sets of plugins. And then they start them one after
        another, saving and opening intermediate images.

        Or they turn away from ImageJ in disgust.

        I had a lot of "fun" with that in my former job in the Image
        Processing Facility in Dresden, where users wanted to keep
        existing setups running but still wanted new functionality. It's
        a nightmare situation for any maintainer worth her salt.

Footnote [*3*]: We would have to rewrite the complete ImageJ macro
        language interpreter, because it is so tied-in with ImageJ (think
        for example the complete absence of the quite useful
        getSelectionCoordinates() macro function which provides the real
        ROI coordinates, not just the coordinates relative to the bounds).

        Plus: it has severe limitations, as you know: It cannot handle
        objects (required to interact with ImageJ2 effectively), its
        performance is bad because it has no intermediate P-code nor the
        option to compile to Java bytecode, it completely lacks options
        for multithreading which are an absolute must for the amounts of
        data we have to crunch these days, etc.

Footnote [*4*]: It really does not help that the macro language supports
        -- only in the builtin functions, mind you! -- passing variable
        _names_ rather than their values. Indeed, for functions such as
        Stack.getDimensions(), the variables do not need to be defined
        before calling the function, they _are_ defined by calling the
        function.

        Now, apart from the obvious problems this brings to consistency
        (with all the consequences it has on teachability: "but when I
        pass that variable to the function, the function changes it, no?")
        the problem is also that it meddles with scopes (as testified by
        the students' confusion) of variables.

        Those problems have been dealt with and learnt from when designing
        the language called Java, which is why it does not allow to pass
        variable names, only their values.

Footnote [*5*]: The issue about passing names of uninitialized variables
        cost me one week to work around. We do this now by run-time
        patching the Beanshell interpreter (so as not to interfer with
        standards-compliant Beanshell!).

        Other issues I am aware of and still have to work around:
        - The 'function' keyword needs to be ignored in the right places.
        - Single-quoted strings are forbidden in Beanshell.
        - Functions taking no parameters can be called as if they were
          variables, i.e. omitting the ellipsis '()'.
        - Beanshell does not support varargs yet.
        - Beanshell knows booleans and has to cast them to integers
          on-the-fly.

        These are all fixable, though, as they basically boil down to
        illegal syntax in Beanshell which I can intercept and handle at
        parse time.

        The array syntax which I am harping on boils down to a run-time
        error.

[Albert Cardona-2]

Dear Johannes,

thanks for the detailed explanations. The problem is evident now. I
support your decision to not be backwards-compatible with ImageJ-1
regarding this one feature, extensible arrays. What surprises me is
that other macro language features have not been a problem for
rewriting the macro language using the BeanShell language. Cheers to
you for accomplishing that feat.

I have not used the macro language in years, perhaps five years. I
find jython and clojure easier, more practical and, what matters, more
useful. The ImageJ Macro Recorder is invaluable in figuring out how to
run plugins on an image, as I elaborated on in the examples of the
Fiji Jython Tutorial:

  http://www.ini.uzh.ch/~acardona/fiji-tutorial/#figuring-out-plugin-parameters
  http://www.ini.uzh.ch/~acardona/fiji-tutorial/#running-command-on-an-image

As I have done before, I encourage ImageJ power-users reading this
email to not rely on the macro language for programs longer than about
10 lines. There are better alternatives.

Albert

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

[lechristophe]

Hi Albert, hi Johannes, hi ImageJers, hi IJ2 developers,

I just would like to add my 2c as an ImageJ/Fiji user. I'm in no way a
developer as my Java and programming skills are sadly still
non-existent, so I won't comment on the IJ2 design decisions, which I
will respect and adapt to as I can't participate in them.

I am, however, a long-time user of the macro language. As regards the
future, I'd be happy to learn Java or scripting languages to benefit
from the advantages you highlighted. Being just familiar with the
macro language (not Java), which scripting language would you suggest
? I heard Johannes' point about Beanshell being the closest to the
macro language. Or should I learn something else that I could use more
easily outside ImageJ/Fiji (Jython, Clojure, Javascript) ?

As regards the past, that would be really nice not having to re-write
all my ImageJ macros to use IJ2. Support for the IJ macro language,
even partial, would be really important for me and (at least I think)
a lot of other people.

Thanks for all the work,

Christophe.

PS/ Just out of curiosity, is there a difference between having an
expandable array function built into the macro language and using a
user-defined function such as:

function ArrayAppend(InputArray, ExtraValue) {
        OutputArray=newArray(InputArray.length+1);
        for (i=0; i<InputArray.length; i++)  OutputArray[i]=InputArray[i];
        OutputArray[InputArray.length]=ExtraValue;
        return OutputArray;
}

[Rasband, Wayne (NIH/NIMH) [E]]

On Oct 16, 2011, at 10:07 AM, Christophe Leterrier wrote:

> Hi Albert, hi Johannes, hi ImageJers, hi IJ2 developers,
>
> I just would like to add my 2c as an ImageJ/Fiji user. I'm in no way a
> developer as my Java and programming skills are sadly still
> non-existent, so I won't comment on the IJ2 design decisions, which I
> will respect and adapt to as I can't participate in them.
>
> I am, however, a long-time user of the macro language. As regards the
> future, I'd be happy to learn Java or scripting languages to benefit
> from the advantages you highlighted. Being just familiar with the
> macro language (not Java), which scripting language would you suggest
> ? I heard Johannes' point about Beanshell being the closest to the
> macro language. Or should I learn something else that I could use more
> easily outside ImageJ/Fiji (Jython, Clojure, Javascript) ?

I would suggest JavaScript. It is built into ImageJ, it is supported by the macro recorder, and it is closest to the macro language. The expandable array example macro I provided can by converted to JavaScript by changing "newArray" to "new Array". This is the JavaScript version:

  cars = new Array;
  cars[0] = "Saab";
  cars[1] = "Volvo";
  cars[2] = "BMW";
  cars[4] = "Ford";
  for (i=0; i<cars.length; i++)
      print(cars[i]);

> As regards the past, that would be really nice not having to re-write
> all my ImageJ macros to use IJ2. Support for the IJ macro language,
> even partial, would be really important for me and (at least I think)
> a lot of other people.
> Thanks for all the work,
>
> Christophe.
>
> PS/ Just out of curiosity, is there a difference between having an
> expandable array function built into the macro language and using a
> user-defined function such as:
>
> function ArrayAppend(InputArray, ExtraValue) {
> OutputArray=newArray(InputArray.length+1);
> for (i=0; i<InputArray.length; i++)  OutputArray[i]=InputArray[i];
> OutputArray[InputArray.length]=ExtraValue;
> return OutputArray;
> }

There is a difference in speed. This code

  a = newArray(0);
  for (i=0; i<5000; i++)
     a = ArrayAppend(a,i);

runs in 5.4 seconds, whereas this code

  a = newArray(0);
  for (i=0; i<5000; i++)
     a[i] = i;

runs in 3 milliseconds, 1800 times faster!

-wayne

[Albert Cardona-2]

2011/10/16 Rasband, Wayne (NIH/NIMH) [E] <[hidden email]>:

>> PS/ Just out of curiosity, is there a difference between having an
>> expandable array function built into the macro language and using a
>> user-defined function such as:
>>
>> function ArrayAppend(InputArray, ExtraValue) {
>>       OutputArray=newArray(InputArray.length+1);
>>       for (i=0; i<InputArray.length; i++)  OutputArray[i]=InputArray[i];
>>       OutputArray[InputArray.length]=ExtraValue;
>>       return OutputArray;
>> }
>
> There is a difference in speed. This code
>
>  a = newArray(0);
>  for (i=0; i<5000; i++)
>     a = ArrayAppend(a,i);
>
> runs in 5.4 seconds, whereas this code
>
>  a = newArray(0);
>  for (i=0; i<5000; i++)
>     a[i] = i;
>
> runs in 3 milliseconds, 1800 times faster!
>
> -wayne

Dear Wayne,

the following javascript code runs in 2 milliseconds:

var a = new Array(5000);
for (var i=0; i<5000; ++i)
  a[i] = i;

Notice the "array" (actually an object with a table of properties; in
this case the indices) is allocated in one shot.

The macro language, or any other very high-level scripting language
(like javascript and jython), are not meant for manipulating every
element, one by one, of the arrays of images. Rather, the macro
language excels at applying ImageJ-defined operations to entire
images, at java speed. Having variable-size arrays does not help this
specialized, excellent function of the macro language.

Furthermore, variable-sized arrays elevate the already high amount of
incidental complexity in the macro language. Wayne, I know it's a neat
feature to have, but it does not significantly improve ImageJ, and it
jeopardizes the ability of the ImageJ 2.0 project to keep full
compatibility with ImageJ 1.45*. Realize the macro language you
created is already so powerful that, as Christophe demonstrated, it
can emulate variable-sized arrays at speeds that are arguably
irrelevant for human interaction!

Best,

Albert

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

[Albert Cardona-2]

2011/10/16 Christophe Leterrier <[hidden email]>:

> Hi Albert, hi Johannes, hi ImageJers, hi IJ2 developers,
>
> I just would like to add my 2c as an ImageJ/Fiji user. I'm in no way a
> developer as my Java and programming skills are sadly still
> non-existent, so I won't comment on the IJ2 design decisions, which I
> will respect and adapt to as I can't participate in them.
>
> I am, however, a long-time user of the macro language. As regards the
> future, I'd be happy to learn Java or scripting languages to benefit
> from the advantages you highlighted. Being just familiar with the
> macro language (not Java), which scripting language would you suggest
> ? I heard Johannes' point about Beanshell being the closest to the
> macro language. Or should I learn something else that I could use more
> easily outside ImageJ/Fiji (Jython, Clojure, Javascript) ?

Dear Christophe,

I second Wayne: for scripting ImageJ, javascript is an excellent
language and its syntax is rather similar to that of the macro
language.

Some time ago I created a page with examples and documentation for
scripting ImageJ in javascript, available here:

 http://fiji.sc/wiki/index.php/Javascript_Scripting

The explanations from the Jython tutorial
(http://www.ini.uzh.ch/~acardona/fiji-tutorial/#figuring-out-plugin-parameters)
on how to apply plugins to images is also valid for javascript. One
would do:


importClass(Packages.ij.IJ);
var imp = IJ.getImage();
IJ.run(imp, "Median...", "radius=2");


Within ImageJ I think one doesn't need even to declare the imports;
these are handled automatically (ImageJ's javascript code interpreter
puts them in for you).


> As regards the past, that would be really nice not having to re-write
> all my ImageJ macros to use IJ2. Support for the IJ macro language,
> even partial, would be really important for me and (at least I think)
> a lot of other people.


I agree with you. I hope that Wayne will reconsider the new extensible
array feature.

Best,

Albert

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



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

[Michael Doube-3]

Dear all,

> As I have done before, I encourage ImageJ power-users reading this
> email to not rely on the macro language for programs longer than about
> 10 lines. There are better alternatives.

I took Albert's advice in the past (at the 2nd ImageJ meeting); the
result was BoneJ. It's good advice.

Michael

[Robert Dougherty]

Albert, Johannes,

This is Wayne you're arguing with. If he wants an expandable array, it should be provided. There is nothing wrong with the syntax and it is not hard to implement.  Use a Vector. The key characteristic of the macro language is that it does not require the user to worry about computer programming concepts like the size of an array.

Bob

>
> Dear Wayne,
>
> the following javascript code runs in 2 milliseconds:
>
> var a = new Array(5000);
> for (var i=0; i<5000; ++i)
>  a[i] = i;
>
> Notice the "array" (actually an object with a table of properties; in
> this case the indices) is allocated in one shot.
>
> The macro language, or any other very high-level scripting language
> (like javascript and jython), are not meant for manipulating every
> element, one by one, of the arrays of images. Rather, the macro
> language excels at applying ImageJ-defined operations to entire
> images, at java speed. Having variable-size arrays does not help this
> specialized, excellent function of the macro language.
>
> Furthermore, variable-sized arrays elevate the already high amount of
> incidental complexity in the macro language. Wayne, I know it's a neat
> feature to have, but it does not significantly improve ImageJ, and it
> jeopardizes the ability of the ImageJ 2.0 project to keep full
> compatibility with ImageJ 1.45*. Realize the macro language you
> created is already so powerful that, as Christophe demonstrated, it
> can emulate variable-sized arrays at speeds that are arguably
> irrelevant for human interaction!
>
> Best,
>
> Albert
>
> --
> http://albert.rierol.net
> http://www.ini.uzh.ch/~acardona/

Robert Dougherty, Ph.D.
President, OptiNav, Inc.
1414 127th Place NE #106
Bellevue, WA 98005
Tel. [phone]
FAX [phone]
www.optinav.com
[hidden email]

[Herbert M. Geller]

Dear All,

I am not an ImageJ "power user", I am a scientist who depends upon
ImageJ to get my work done.  I made the migration from NIH Image to
ImageJ (though not without some head-scratching).  But I have many, many
macros which I make use of in my research.  Wayne has been there for us
since the beginning.

The bottom line: let's make sure that any rewrites of ImageJ are
completely backwards compatible with ImageJ.  This is a program for
users, not for power users or for experienced programmers, and let's
please keep it that way.   The pressure to modernize should not outweigh
the need to keep the program useful for all, even those of us who gave
up programming after Fortran.

Thanks for all your efforts.

Herb Geller

On 10/16/2011 6:54 PM, Robert Dougherty wrote:

> Albert, Johannes,
>
> This is Wayne you're arguing with. If he wants an expandable array, it should be provided. There is nothing wrong with the syntax and it is not hard to implement.  Use a Vector. The key characteristic of the macro language is that it does not require the user to worry about computer programming concepts like the size of an array.
>
> Bob
>
>> Dear Wayne,
>>
>> the following javascript code runs in 2 milliseconds:
>>
>> var a = new Array(5000);
>> for (var i=0; i<5000; ++i)
>>   a[i] = i;
>>
>> Notice the "array" (actually an object with a table of properties; in
>> this case the indices) is allocated in one shot.
>>
>> The macro language, or any other very high-level scripting language
>> (like javascript and jython), are not meant for manipulating every
>> element, one by one, of the arrays of images. Rather, the macro
>> language excels at applying ImageJ-defined operations to entire
>> images, at java speed. Having variable-size arrays does not help this
>> specialized, excellent function of the macro language.
>>
>> Furthermore, variable-sized arrays elevate the already high amount of
>> incidental complexity in the macro language. Wayne, I know it's a neat
>> feature to have, but it does not significantly improve ImageJ, and it
>> jeopardizes the ability of the ImageJ 2.0 project to keep full
>> compatibility with ImageJ 1.45*. Realize the macro language you
>> created is already so powerful that, as Christophe demonstrated, it
>> can emulate variable-sized arrays at speeds that are arguably
>> irrelevant for human interaction!
>>
>> Best,
>>
>> Albert
>>
>> --
>> http://albert.rierol.net
>> http://www.ini.uzh.ch/~acardona/
> Robert Dougherty, Ph.D.
> President, OptiNav, Inc.
> 1414 127th Place NE #106
> Bellevue, WA 98005
> Tel. [phone]
> FAX [phone]
> www.optinav.com
> [hidden email]

--
--------------------------------------
Herbert M. Geller, Ph.D.
Developmental Neurobiology Section
National Heart Lung and Blood Institute, NIH
10 Center Drive MSC 1754
Bldg 10, Room 6D18
Bethesda, MD  20892-1754
Tel: [phone]; Fax: [phone]
e-mail: [hidden email]
Web: http://dir.nhlbi.nih.gov/labs/ldn/index.asp
---------------------------------------

[Aryeh Weiss]

On 10/17/11 12:54 AM, Robert Dougherty wrote:
> Albert, Johannes,
>
> This is Wayne you're arguing with. If he wants an expandable array,
> it should be provided. There is nothing wrong with the syntax and it
> is not hard to implement.  Use a Vector. The key characteristic of
> the macro language is that it does not require the user to worry
> about computer programming concepts like the size of an array.
>

I do not see anyone arguing. I see the people who make it possible for
us to have a very powerful image processing environment discussing how
best to continue the development of this tool.

I find the discussion interesting, and I am confident that the
developers will work this thing out.

I personally would like to see my macros (many of which are more than 10
lines) continue to work, but if instead I am told what will need to be
changed, I will manage with that.

--aryeh
--
Aryeh Weiss
School of Engineering
Bar Ilan University
Ramat Gan 52900 Israel

Ph:  972-3-5317638
FAX: [phone]

[Krs5]

Dear list members,



I realize with all the discussion at the moment about using the macro language yes or no and its backwards-compatible in the new ImageJ2 version that I might have to rethink some of the things I do here in Leicester, but I would like to announce the next ImageJ workshops: 'Introduction to ImageJ/FIJI' on Monday 19 December and 'Writing macros in ImageJ' on Tuesday 20 December. The workshops in July were absolutely oversubscribed and I got many request for a repeat.



Please visit the website: http://www.le.ac.uk/biochem/microscopy/ImageJ2011b.html



Best wishes



Kees





Dr Ir K.R. Straatman

Senior Experimental Officer

Centre for Core Biotechnology Services

College of Medicine, Biological Sciences and Psychology

http://www.le.ac.uk/biochem/microscopy/home.html



Postal address:

Department of Biochemistry

Henry Wellcome Building

University of Leicester

Lancaster Rd.

Leicester LE1 9HN

UK

tel.: + 44 (0)116 229 7085/252 2263

fax: + 44 (0)116 229 7031

[Krs5]

Dear all,

We have many users who have no background in programming and use the macro language because it is easy and does the job, so I really hope we don't lose this. When I was a postdoc I had the time to write some plugins but now I am too busy and I write all image analysis for ImageJ in the macro language and many more lines than 10. I don't know if this is good or bad but it is reality I am afraid. One thing that is not clear to me reading all the emails is if the macro language will disappear in Imagej2 and will only be backwards-compatible for existing macros or will there still be a macro language in ImageJ2? And if so, will this be the same as in ImageJ1 or a different language?

Best wishes

Kees




Dr Ir K.R. Straatman

Senior Experimental Officer

Centre for Core Biotechnology Services

College of Medicine, Biological Sciences and Psychology



http://www.le.ac.uk/biochem/microscopy/home.html






-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Albert Cardona
Sent: 16 October 2011 09:28
To: [hidden email]
Subject: Re: "cute" new syntax in macro language, was Re: Bug in newArray() macro function



Dear Johannes,



thanks for the detailed explanations. The problem is evident now. I

support your decision to not be backwards-compatible with ImageJ-1

regarding this one feature, extensible arrays. What surprises me is

that other macro language features have not been a problem for

rewriting the macro language using the BeanShell language. Cheers to

you for accomplishing that feat.



I have not used the macro language in years, perhaps five years. I

find jython and clojure easier, more practical and, what matters, more

useful. The ImageJ Macro Recorder is invaluable in figuring out how to

run plugins on an image, as I elaborated on in the examples of the

Fiji Jython Tutorial:



  http://www.ini.uzh.ch/~acardona/fiji-tutorial/#figuring-out-plugin-parameters

  http://www.ini.uzh.ch/~acardona/fiji-tutorial/#running-command-on-an-image



As I have done before, I encourage ImageJ power-users reading this

email to not rely on the macro language for programs longer than about

10 lines. There are better alternatives.



Albert



--

http://albert.rierol.net

http://www.ini.uzh.ch/~acardona/

[ctrueden]

Hi Herb,

The bottom line: let's make sure that any rewrites of ImageJ are completely
> backwards compatible with ImageJ.  This is a program for users, not for
> power users or for experienced programmers, and let's please keep it that
> way.   The pressure to modernize should not outweigh the need to keep the
> program useful for all, even those of us who gave up programming after
> Fortran.
>

We absolutely agree about backward compatibility being paramount, and as
mentioned previously, it is our #1 priority. We are also completely on the
same page that ImageJ is a program for everyone: users, power users and
programmers alike. One important reason that ImageJ has been so successful
is that it *has* attracted so many power users, who have contributed many
wonderful plugins and macros over the years. We are hoping to cultivate that
even further with ImageJ2, by providing an even more powerful and flexible
system for shared scientific image processing.

Regards,
Curtis & the Fiji/ImageJ2 team
http://imagejdev.org/
http://fiji.sc/


On Sun, Oct 16, 2011 at 8:11 PM, Herbert M. Geller <[hidden email]>wrote:

> Dear All,
>
> I am not an ImageJ "power user", I am a scientist who depends upon ImageJ
> to get my work done.  I made the migration from NIH Image to ImageJ (though
> not without some head-scratching).  But I have many, many macros which I
> make use of in my research.  Wayne has been there for us since the
> beginning.
>
> The bottom line: let's make sure that any rewrites of ImageJ are completely
> backwards compatible with ImageJ.  This is a program for users, not for
> power users or for experienced programmers, and let's please keep it that
> way.   The pressure to modernize should not outweigh the need to keep the
> program useful for all, even those of us who gave up programming after
> Fortran.
>
> Thanks for all your efforts.
>
> Herb Geller
>
>
> On 10/16/2011 6:54 PM, Robert Dougherty wrote:
>
>> Albert, Johannes,
>>
>> This is Wayne you're arguing with. If he wants an expandable array, it
>> should be provided. There is nothing wrong with the syntax and it is not
>> hard to implement.  Use a Vector. The key characteristic of the macro
>> language is that it does not require the user to worry about computer
>> programming concepts like the size of an array.
>>
>> Bob
>>
>>  Dear Wayne,
>>>
>>> the following javascript code runs in 2 milliseconds:
>>>
>>> var a = new Array(5000);
>>> for (var i=0; i<5000; ++i)
>>>  a[i] = i;
>>>
>>> Notice the "array" (actually an object with a table of properties; in
>>> this case the indices) is allocated in one shot.
>>>
>>> The macro language, or any other very high-level scripting language
>>> (like javascript and jython), are not meant for manipulating every
>>> element, one by one, of the arrays of images. Rather, the macro
>>> language excels at applying ImageJ-defined operations to entire
>>> images, at java speed. Having variable-size arrays does not help this
>>> specialized, excellent function of the macro language.
>>>
>>> Furthermore, variable-sized arrays elevate the already high amount of
>>> incidental complexity in the macro language. Wayne, I know it's a neat
>>> feature to have, but it does not significantly improve ImageJ, and it
>>> jeopardizes the ability of the ImageJ 2.0 project to keep full
>>> compatibility with ImageJ 1.45*. Realize the macro language you
>>> created is already so powerful that, as Christophe demonstrated, it
>>> can emulate variable-sized arrays at speeds that are arguably
>>> irrelevant for human interaction!
>>>
>>> Best,
>>>
>>> Albert
>>>
>>> --
>>> http://albert.rierol.net
>>> http://www.ini.uzh.ch/~**acardona/ <http://www.ini.uzh.ch/%7Eacardona/>
>>>
>> Robert Dougherty, Ph.D.
>> President, OptiNav, Inc.
>> 1414 127th Place NE #106
>> Bellevue, WA 98005
>> Tel. [phone]
>> FAX [phone]
>> www.optinav.com
>> [hidden email]
>>
>
> --
> ------------------------------**--------
> Herbert M. Geller, Ph.D.
> Developmental Neurobiology Section
> National Heart Lung and Blood Institute, NIH
> 10 Center Drive MSC 1754
> Bldg 10, Room 6D18
> Bethesda, MD  20892-1754
> Tel: [phone]; Fax: [phone]
> e-mail: [hidden email]
> Web: http://dir.nhlbi.nih.gov/labs/**ldn/index.asp<http://dir.nhlbi.nih.gov/labs/ldn/index.asp>
> ------------------------------**---------
>