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

Dan Higgins higgins at nceas.ucsb.edu
Tue May 29 10:53:52 PDT 2007

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

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 
> ------------------------------------

More information about the Kepler-dev mailing list