Hi Wayne,<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">Why would you want to base the macro interpreter on Beanshell? This is going to require a *lot* of work and the resulting Beanshell-based language is unlikely to be 100% backward compatible. I thought the plan for handling backward compatibility was to hand off legacy macros and plugins to IJ1.<br>
</blockquote>
<br>The plan until recently was indeed to merely support IJ1 macros as-is, within the legacy layer. That is, existing macros would work as before, but no new IJ2 functionality would be accessible via macros. However, after hearing from people about how they would like to see the macro language truly work in IJ2 (e.g., <a href="http://imagejdev.org/pipermail/imagej-devel/2011-September/000480.html">http://imagejdev.org/pipermail/imagej-devel/2011-September/000480.html</a>), Johannes and I discussed whether another solution might be possible. As Johannes says, we already have a proof-of-concept Beanshell-based version of the macro language, so it is looking quite doable right now—not an enormous effort to develop or maintain. If it turns out to be a huge burden, we can fall back to our original strategy, but it is worth a try to make IJ2 accessible via macros.<br>
<br>Regards,<br>Curtis<br><br><div class="gmail_quote">On Wed, Sep 14, 2011 at 1:58 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:schindelin@wisc.edu">schindelin@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Dear Wayne,<br>
<br>
[re-Cc:ing the list, since I think that this issue is of broader<br>
interest.]<br>
<br>
On Wed, 14 Sep 2011, Rasband, Wayne (NIH/NIMH) [E] wrote:<br>
<div class="im"><br>
> On Sep 14, 2011, at 2:09 AM, Johannes Schindelin wrote:<br>
><br>
> > I now have a proof-of concept of the Macro interpreter based on<br>
> > Beanshell. Note: it only supports the getDimensions() function for<br>
> > now. As described earlier, the problem is that that function takes<br>
> > possibly uninitialized variables by reference rather than values,<br>
> > which is fully out of line with the syntax of Beanshell (or C or<br>
> > Java).<br>
> ><br>
> > Instead of forking Beanshell, I decided it'd be better to use<br>
> > javassist to rewrite a few method calls here and there. I also wanted<br>
> > to make sure that these modifications do not affect Beanshell itself,<br>
> > and I put a particular focus on making it possible to load the<br>
> > Beanshell classes before doing the Javassist modifications (because it<br>
> > would lead to nasty side effects otherwise).<br>
><br>
</div>> Why would you want to base the macro interpreter on Beanshell? This is<br>
> going to require a *lot* of work and the resulting Beanshell-based<br>
> language is unlikely to be 100% backward compatible. I thought the plan<br>
> for handling backward compatibility was to hand off legacy macros and<br>
> plugins to IJ1.<br>
<br>
There are a lot of power users out there who need the macro language to<br>
exist also in IJ2. So we cannot simply drop it.<br>
<br>
But the legacy macros will not handle IJ2 properly. So we need something<br>
better.<br>
<br>
Also, the limitations of the Macro language are rather severe, not being<br>
able to interact with the Java API. Now is the time to break that barrier.<br>
<br>
There is another rather big problem with the Macro language that I'd like<br>
to address at the same time: the functions of the macro language are not<br>
available to Java programmers. In many cases, one can work around that by<br>
adding chunks of Java code (but there is no consistent way how to<br>
translate calls to macro functions into Java code), but in some cases, it<br>
is plainly impossible to do the same thing in Java which is very easy in<br>
macros (because of the use of package-local methods and fields).<br>
<br>
As I suggested at multiple occasions, a properly designed macro interface<br>
should have a 1:1 correspondence in the Java API. Because if you need to<br>
be able to do something using macros, there is no good reason to believe<br>
that the same functionality should be lacking from the Java-accessible<br>
API.<br>
<br>
With the redesign, there will be finally a Java class that defines all the<br>
macro functions, so we have that 1:1 correspondence not only in the usage,<br>
but it will indeed be the very same code performing the actions, so there<br>
is no room for inconsistencies between macros and plugins.<br>
<br>
Yes, it will be a lot of work, but I dare to hope that you will notify me<br>
whenever you change something in the macro language so that I can take<br>
care of the IJ2 version thereof.<br>
<br>
Unfortunately, given the architecture of the IJ1 Macro interpreter, I do<br>
not see any chance to modify the IJ1 code such that it naturally<br>
transforms into the IJ2 Macro interpreter. If you do see such a chance,<br>
please enlighten me.<br>
<br>
Ciao,<br>
<font color="#888888">Johannes<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a><br>
<a href="http://imagejdev.org/mailman/listinfo/imagej-devel" target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a><br>
</div></div></blockquote></div><br>