Extend BeanShell support?
Locked
 
|
Dear Wayne (and others),
Are there plans to allow .bsh scripts to be run from the Plugins> menu, similarly to .js, .ijm? I guess this would also allow BeansShell scripts to be listed by the command finder (Right now these 2 features are only possible in IJ2 and in Fiji[1]). I'm wondering if ij.plugin.Macro_Runner could be modified to allow this, but things are probably much more complicated than that, and maybe BeanShell is supposed to remain "experimental" in IJ1? I'm OK in using BeanShell exclusively in Fiji, just came across these issues and though to bring them to discussion, -tiago [1] <http://fiji.sc/cgi-bin/gitweb.cgi?p=fiji.git;a=tree;f=src-plugins/BeanShell_Interpreter/src/main/java/BSH;> -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Tiago (and others),
It’s certainly possible in principal because I’ve implemented similar functionality in a personal fork of ImageJ to run Python scripts from ImageJ’s plugin menus (these scripts can be even simpler than .bsh IJ plugins IMO), and it turns a great program into an even greater one! :) However, my understanding is since baseline ImageJ is public domain, Jython (which has the Python license and I use to implement this functionality) are not compatible otherwise I would have contributed them upstream. Perhaps I’m wrong? Anyways, since BeanShell can be LGPL, presumably it would be OK to be distributed with (and called by) the public domain ImageJ base? I’m curious as well; best regards all, John Le 23 févr. 2013 à 18:47, Tiago Ferreira a écrit : > Dear Wayne (and others), > > Are there plans to allow .bsh scripts to be run from the Plugins> menu, similarly to .js, .ijm? > I guess this would also allow BeansShell scripts to be listed by the command finder > (Right now these 2 features are only possible in IJ2 and in Fiji[1]). > > I'm wondering if ij.plugin.Macro_Runner could be modified to allow this, but things are probably much > more complicated than that, and maybe BeanShell is supposed to remain "experimental" in IJ1? > > I'm OK in using BeanShell exclusively in Fiji, just came across these issues and though to bring > them to discussion, > > -tiago > > > [1] <http://fiji.sc/cgi-bin/gitweb.cgi?p=fiji.git;a=tree;f=src-plugins/BeanShell_Interpreter/src/main/java/BSH;> > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
Hi Tiago & everyone,
As you know, Fiji already provides support for Beanshell and many other scripting languages. What would be the advantage of integrating it into "vanilla" ImageJ? -Curtis On Feb 23, 2013 5:49 PM, "John Hayes" <[hidden email]> wrote: > Dear Tiago (and others), > > It’s certainly possible in principal because I’ve implemented similar > functionality in a personal fork of ImageJ to run Python scripts from > ImageJ’s plugin menus (these scripts can be even simpler than .bsh IJ > plugins IMO), and it turns a great program into an even greater one! :) > > However, my understanding is since baseline ImageJ is public domain, > Jython (which has the Python license and I use to implement this > functionality) are not compatible otherwise I would have contributed them > upstream. Perhaps I’m wrong? > > Anyways, since BeanShell can be LGPL, presumably it would be OK to be > distributed with (and called by) the public domain ImageJ base? > > I’m curious as well; best regards all, > > John > > Le 23 févr. 2013 à 18:47, Tiago Ferreira a écrit : > > > Dear Wayne (and others), > > > > Are there plans to allow .bsh scripts to be run from the Plugins> menu, > similarly to .js, .ijm? > > I guess this would also allow BeansShell scripts to be listed by the > command finder > > (Right now these 2 features are only possible in IJ2 and in Fiji[1]). > > > > I'm wondering if ij.plugin.Macro_Runner could be modified to allow this, > but things are probably much > > more complicated than that, and maybe BeanShell is supposed to remain > "experimental" in IJ1? > > > > I'm OK in using BeanShell exclusively in Fiji, just came across these > issues and though to bring > > them to discussion, > > > > -tiago > > > > > > [1] < > http://fiji.sc/cgi-bin/gitweb.cgi?p=fiji.git;a=tree;f=src-plugins/BeanShell_Interpreter/src/main/java/BSH > ;> > > -- > > 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 |
|
|
Hi Curtis (and others),
I have a great deal of respect for Fiji and I know it is terrific for many people, but for my needs, it’s like using a sledge-hammer when only a smaller hammer is needed and the size of the sledge-hammer can be intimidating to some people. Python (or BeanShell) in the vanilla ImageJ is quite useful (or invisible) for anyone and seems well-suited for the « core » distribution (ala the Linux kernel to extend the Fiji/Linux-distro analogy). It makes things hugely more useful, but without the less useful baggage for any given naive user. But in my last post, I should have also included this opinion about linking to LGPL code in Java from a real lawyer (I think): http://www.gnu.org/licenses/lgpl-java.html I believe BeanShell should be callable from vanilla ImageJ if it is just kept in a separate .jar. Best regards all, John Le 24 févr. 2013 à 01:19, Curtis Rueden a écrit : > Hi Tiago & everyone, > > As you know, Fiji already provides support for Beanshell and many other > scripting languages. What would be the advantage of integrating it into > "vanilla" ImageJ? > > -Curtis > On Feb 23, 2013 5:49 PM, "John Hayes" <[hidden email]> wrote: > >> Dear Tiago (and others), >> >> It’s certainly possible in principal because I’ve implemented similar >> functionality in a personal fork of ImageJ to run Python scripts from >> ImageJ’s plugin menus (these scripts can be even simpler than .bsh IJ >> plugins IMO), and it turns a great program into an even greater one! :) >> >> However, my understanding is since baseline ImageJ is public domain, >> Jython (which has the Python license and I use to implement this >> functionality) are not compatible otherwise I would have contributed them >> upstream. Perhaps I’m wrong? >> >> Anyways, since BeanShell can be LGPL, presumably it would be OK to be >> distributed with (and called by) the public domain ImageJ base? >> >> I’m curious as well; best regards all, >> >> John >> >> Le 23 févr. 2013 à 18:47, Tiago Ferreira a écrit : >> >>> Dear Wayne (and others), >>> >>> Are there plans to allow .bsh scripts to be run from the Plugins> menu, >> similarly to .js, .ijm? >>> I guess this would also allow BeansShell scripts to be listed by the >> command finder >>> (Right now these 2 features are only possible in IJ2 and in Fiji[1]). >>> >>> I'm wondering if ij.plugin.Macro_Runner could be modified to allow this, >> but things are probably much >>> more complicated than that, and maybe BeanShell is supposed to remain >> "experimental" in IJ1? >>> >>> I'm OK in using BeanShell exclusively in Fiji, just came across these >> issues and though to bring >>> them to discussion, >>> >>> -tiago >>> >>> >>> [1] < >> http://fiji.sc/cgi-bin/gitweb.cgi?p=fiji.git;a=tree;f=src-plugins/BeanShell_Interpreter/src/main/java/BSH >> ;> >>> -- >>> 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 |
Re: Extend BeanShell support?
|
|
In reply to this post by Tiago Ferreira-2
On Feb 23, 2013, at 12:47 PM, Tiago Ferreira wrote:
> Dear Wayne (and others), > > Are there plans to allow .bsh scripts to be run from the Plugins> menu, similarly to .js, .ijm? > I guess this would also allow BeansShell scripts to be listed by the command finder > (Right now these 2 features are only possible in IJ2 and in Fiji[1]). BeanShell scripts are supported in the ImageJ 1.47m daily build. You can run them from the macro editor using the Macros>Evaluate BeanShell command and install them in the Plugins> menu using the new Plugins>Install command. The BeanShell interpreter is downloaded from http://imagej.nih.gov/ij/plugins/bsh/ as needed. -wayne > I'm wondering if ij.plugin.Macro_Runner could be modified to allow this, but things are probably much > more complicated than that, and maybe BeanShell is supposed to remain "experimental" in IJ1? > > I'm OK in using BeanShell exclusively in Fiji, just came across these issues and though to bring > them to discussion, > > -tiago > > > [1] <http://fiji.sc/cgi-bin/gitweb.cgi?p=fiji.git;a=tree;f=src-plugins/BeanShell_Interpreter/src/main/java/BSH;> -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Extend BeanShell support?
|
|
In reply to this post by ctrueden
On 2013.02.23, at 19:19 , Curtis Rueden wrote:
> What would be the advantage of integrating it into "vanilla" ImageJ? Well not many indeed, apart from the fact it would be easier to share scripts without worrying about which IJ distribution is on the other side. I mentioned BeanShell and not other scripting languages because IJ's text editor can run .bsh scripts since 1.47e and because I'm guessing BeanShell will become extremely popular among all users (which never really happened, e.g., with JavaScript). But I may be completely wrong, -tiago -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
My 2 cents: Jython is still the way to go because why live with Java and BeanShell’s faux Java-syntax for help (that is WAY TOO explicative) and when they have such horrible syntax to begin with?
Go with a sensible language that’s basically formalized « pseudocode », but that’s just my POV (i.e., Python/Jython)... I swear I can teach useful Python/Jython code to any moron scientist in an hour who has had no coding experience. With Java/BeanShell, not so much, principally because it is unnecessarily verbose and dazzles the student post-haste, but that’s maybe just my opinion... The consequences of the above for me (and the rest of us) is that we have to spend time answering amateur questions that should be dealt with otherwise. Ideally, I would like to see a community of Python/Jython developers with their own mailing list that were serving modules to the « ImageJ » kernel and related projects. That hasn’t developed principally because ImageJ has not traditionally been friendly to embedded Python/Jython scripts as far as I can tell... Am I wrong and any bright people have good suggestions to alleviate this problem? Wayne and colleagues, I do LOVE ImageJ, and yet it still has potential for greater things IMO and from my scientific perspective... John Le 24 févr. 2013 à 02:17, Tiago Ferreira a écrit : > On 2013.02.23, at 19:19 , Curtis Rueden wrote: >> What would be the advantage of integrating it into "vanilla" ImageJ? > > Well not many indeed, apart from the fact it would be easier to share scripts > without worrying about which IJ distribution is on the other side. > > I mentioned BeanShell and not other scripting languages because IJ's text editor > can run .bsh scripts since 1.47e and because I'm guessing BeanShell will become > extremely popular among all users (which never really happened, e.g., with > JavaScript). > > But I may be completely wrong, > > -tiago > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi John,
On Sun, 24 Feb 2013, John Hayes wrote: > My 2 cents: Jython is still the way to go because why live with Java and > BeanShell’s faux Java-syntax for help (that is WAY TOO explicative) and > when they have such horrible syntax to begin with? You prove Curtis' point that there needs to be support for a wider range of languages. As fervently and absolutely as you love Python, others do love other scripting languages instead, not Python. As to Tiago's request: I do agree that it would be nice to have a way to call .bsh scripts in vanilla ImageJ. However, if you start out that way, you will end up with exactly the same scripting infrastructure as in Fiji, and you will end up almost rewriting it exactly the same way we did with ImageJ2. This comes back to John's sledge-hammer argument: every single time I did something for someone who wanted "just plain ImageJ", it ended up in adding so many plugins that it would have been a lot less hassle to just install Fiji to begin with. There is one middle-ground, though: a large part of Fiji's components are mutually independent, only relying on a small set of core components [*1*]. You could strip down Fiji enough so that it is a very small package, and the updater actually would help you: it checks for dependencies when you ask it to remove components. After you're done deleting stuff you think is unnecessary, you could use the Fiji Package Maker (if Fiji_Developer.jar is still installed...) to make your own, tiny, custom Fiji version. That way, you could have a custom, frugal Fiji version that comes with support for only your favorite scripting language [*2*]. Ciao, Johannes Footnote *1*: more and more core Fiji stuff actually moves to ImageJ2; indeed, the updater already is part of ImageJ2 and Fiji's updater is only a caller of the Fiji one. The good part for you: ImageJ2 is extremely modular. Once Fiji's scripting support moved completely to ImageJ2, you will be able to install a tiny core scripting component and a tiny Beanshell component and the vanilla Beanshell library for Beanshell support. It does not get more customizable than that. Footnote *2*: If you keep the updater component installed, the users can re-install again every component they find too useful to be uninstalled. It would also have the advantage of keeping the installed components up-to-date. -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi Johannes (and others),
I really appreciate your detailed response. Please see my responses embedded below: Le 24 févr. 2013 à 19:43, Johannes Schindelin a écrit : > Hi John, > > On Sun, 24 Feb 2013, John Hayes wrote: > >> My 2 cents: Jython is still the way to go because why live with Java and >> BeanShell’s faux Java-syntax for help (that is WAY TOO explicative) and >> when they have such horrible syntax to begin with? > > You prove Curtis' point that there needs to be support for a wider range > of languages. As fervently and absolutely as you love Python, others do > love other scripting languages instead, not Python. > As to Tiago's request: I do agree that it would be nice to have a way to > call .bsh scripts in vanilla ImageJ. I agree, and I would potentially extend that to any LGPL language, and would be happy to implement similar functionality if it’s of interest upstream because I do use those scripts as well (e.g., a dispatching mechanism that tries to dispatch certain script files to certain interpreters -- this is doable IMO and we can talk about if you like). Anyway, in particular, I like how BeanShell (as opposed to Jython) is LGPL, which should make it easier to integrate into the base IJ project -- I’ll have to look into the other languages Fiji supports. For example, I have a kludgy solution that I call a BeanShellRunner, which spawns a thread running a .bsh script that can be scripted through macros, but I believe something comparable is already present in Fiji for most scripting languages. (Please see my next point) > However, if you start out that way, you will end up with exactly the same > scripting infrastructure as in Fiji, and you will end up almost rewriting > it exactly the same way we did with ImageJ2. Fair enough, and you’ve motivated me to look more recently at Fiji’s scripting mechanisms, which I’m quite impressed with now. Previously, I was somehow under the mistaken impression that scripts in Fiji had to extend the Plugin/PluginFilter interfaces to run (which is bizarre and unnecessarily complicated) and which it doesn’t seem to have now anyway. I like that a lot, and this is how I implemented my Jython code, and I think this kind of feature would be most useful in mainland ImageJ. > This comes back to John's sledge-hammer argument: every single time I did > something for someone who wanted "just plain ImageJ", it ended up in > adding so many plugins that it would have been a lot less hassle to just > install Fiji to begin with. > > There is one middle-ground, though: a large part of Fiji's components are > mutually independent, only relying on a small set of core components > [*1*]. You could strip down Fiji enough so that it is a very small > package, and the updater actually would help you: it checks for > dependencies when you ask it to remove components. > > After you're done deleting stuff you think is unnecessary, you could use > the Fiji Package Maker (if Fiji_Developer.jar is still installed...) to > make your own, tiny, custom Fiji version. > > That way, you could have a custom, frugal Fiji version that comes with > support for only your favorite scripting language [*2*]. I typically do Ca2+-imaging and electrophysiology work (which is not alien to the mailing list except in terms of respondents), and « simple immuno » reconstructions (merging 3 or 4 channels in one plane) is all I need. For the Ca2+-imaging, Fiji (or ImageJ) are not explicitly (or well) designed for this from what I can tell, so I write my own plugins. For immunos, TrackEM and many of the baseline Fiji plugins (that have an audience and are very impressive from my POV) are not for me because they are overkill for me, and they really are a sledgehammer when all I need is to automatically generate composite images (i.e., « scripted » vanilla ImageJ -- with Python, BeanShell, other scripts). The mutually independent point in the above quote is the most valid from my POV, and perhaps the Fiji plugin updater does this now because I’ve heard of big advances there; that is, having a module that includes X plugins associated with EM anatomy, or a module that includes X plugins for physiology analysis, or X module that includes XXX plugins for their area. That could be how things are organized now, and if so, I apologize for the bother. Logical modules based on sub-discipline makes sense to me to fine grain beyond the default sledge-hammers I was alluding to... All that said, I do strongly support you and the rest of the IJ/IJ2/Fiji crew because I think a lot of what my work has built off was impossible without you and I would like to contribute back if the contributions are welcome -- please just let me know if I can help. My comments were meant simply as constructive criticisms and I’m not trying to be an arsehole. I’m happy to help and rather familiar with the baseline API, but would prefere to stick to the strictly PD (public-domain) or GPL2 crowd as Fiji is. Sincerely, best regards, John > > Ciao, > Johannes > > Footnote *1*: more and more core Fiji stuff actually moves to ImageJ2; > indeed, the updater already is part of ImageJ2 and Fiji's updater is only > a caller of the Fiji one. The good part for you: ImageJ2 is extremely > modular. Once Fiji's scripting support moved completely to ImageJ2, you > will be able to install a tiny core scripting component and a tiny > Beanshell component and the vanilla Beanshell library for Beanshell > support. It does not get more customizable than that. > > Footnote *2*: If you keep the updater component installed, the users can > re-install again every component they find too useful to be uninstalled. > It would also have the advantage of keeping the installed components > up-to-date. > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |