[kepler-dev] Working on a modified version of Kepler ImageJ actor

[Tony O'Hagan]

Dan,

Thanks for getting back to me.

I downloaded the ImageJ source v1.37v) from here:
http://rsb.info.nih.gov/ij/download/src/

The MacroRunner() constructor used by the IJMacro actor looks like this:

public MacroRunner(String macro) {
  this.macro = macro;
  thread = new Thread(this, "Macro$"); 
  thread.setPriority(Math.max(thread.getPriority()-2, Thread.MIN_PRIORITY));
  thread.start();
}

And as you can see, thread.start() in this constructor will cause the
MacroRunner.run() method to execute in a new thread. MacroRunner does not
provide a way to perform the needed thread.join() that would allow the
IJMacro Actor to wait until the macro completed.  

I had a quick look over the ImageJ API and noticed this alternative class
that may be what we're after:
   ij.plugin.Macro_Runner (different to ij.macro.MacroRunner).  

It includes this method ...
 String runMacro(String macro, String arg)
... that executes the macro *in the current thread*.  This should eliminate
the need to wait for the thread.  The only risk I can foresee is that a new
thread may be needed in order for the ImageJ Swing GUI to function when
macros are executed.  If so, then we can create and control this thread in
the IJMacro Actor code.  We can also more easily catch exceptions caused by
macro execution errors.

Regards,
Tony.


> -----Original Message-----
> From: Dan Higgins [mailto:higgins at nceas.ucsb.edu]
> Sent: Wednesday, 30 May 2007 3:54 AM
> To: Tony O'Hagan; Kepler-Dev
> Subject: Re: Working on a modified version of Kepler ImageJ actor
> 
> Hi Tony,
> 
>     Yes, the mr.run() statement was deliberately commented out in the
> IJMacro code. I found that simply creating mr in the
> 
> MacroRunner mr = new MacroRunner(macro);
> 
> statement caused the macrorunner to 'run' and leaving the mr.run()
> statement just executed it twice! I never had time to dig enough into
> the ImageJ code to figure out why!
> 
> The problem that caused me to add the sleep statement came up in a
> workflow that contained several IJMacro actors that ended up firing
> within a very short interval. The problem was that one of the actors
> never completed the ImageJ macro action assign to it. Adding that delay
> 'hack' fixed that problem. However, I suspect the underlying issue is a
> threading issue with Kepler and the MacroRunner thread in ImageJ. I have
> always found treading problems really hard to debug and have not spent
> enough time with ImageJ source to track down the issue.
> 
> Suggested changes and improvements to the ImageJ code are always
> welcome. Why don't you send me the source and I can see if it causes
> problems with any of the workflows I have been using.
> 
> Dan Higgins
> NCEAS
> 
> Tony O'Hagan wrote:
> > Dan,
> >
> > I'm part of the DART project at the University of Queensland. I've been
> > looking at the source code for the IJMacro Kepler actor component that I
> > understand you've developed.  Here's a code fragment from this:
> >
> > MacroRunner mr = new MacroRunner(macro);
> >
> > // The following arbitrary delay is needed to avoid problems with the
> > // MacroRunner thread when this method is called several times.
> > // (MacroRunner is an ImageJ class)
> > // Obviously, this is a 'hack'!!  (Dan Higgins - April 2007)
> > try {
> >   Thread.sleep(3000);
> > } catch (Exception e) { }
> >
> > // mr.run();
> >
> > I have a few questions ...
> > (a) Is the mr.run() deliberately disabled?   Perhaps you had problems
> > getting it to work.
> > (b) What kind of problems did you encounter that required the sleep()?
> >    I wondered if a yield() might solve the problem?
> >
> > Finally, I'm about to create a new ImageJ component under:
> >    package org.dart.imagej;
> >
> > Many components in Kepler appear to be grouped by organisation rather
> than
> > function.  This is a pity because it would make sense to put all ImageJ
> > components under one package name.  I suspect that package name changes
> to
> > Kepler components may break existing Kepler models.  Any suggestions to
> > resolve this are welcome.
> >
> > I've added a small factory class to manage a single instance of ImageJ.
> I
> > think it would make sense for our ImageJ classes to use this in place of
> > having to keep a static ij member in each class.
> >
> > BTW ... I've not yet requested read/write access to the Kepler CVS
> > repository and I won't be making any changes to your code without
> consulting
> > you.
> >
> > Regards,
> > Tony O'Hagan
> >
> > DART Project:
> > http://www.itee.uq.edu.au/~eresearch/projects/dart/index.php
> >
> > ------------------------------------
> > Tony O'Hagan, Senior Research Officer
> > ITEE, University of Queensland
> > tohagan at itee.uq.edu.au
> > tel: +61 7 3365-4556 mobile: 0421 230 767
> > Skype/Google Talk: tony.ohagan
> > MSN: tohagan at pobox.com
> > ------------------------------------
> >
> >
> >
> >