[kepler-dev] Can "stop" interrupt "initialize()"

Laura L. Downey ldowney at lternet.edu
Wed Feb 1 08:23:09 PST 2006


Just some clarification here... are you suggesting that we implement start,
pause and stop buttons for execution of individual actors within a workflow?
And are you extended that to the issue of downloading data too?

Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM  87131-0001
505.277.3157 office
505.610.9657 mobile
505.277-2541 fax
ldowney at lternet.edu

-----Original Message-----
From: kepler-dev-bounces at ecoinformatics.org
[mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Bertram
Sent: Sunday, January 29, 2006 7:53 PM
To: Kevin Ruland
Cc: ptolemy-hackers at bennett.EECS.Berkeley.EDU; kepler-dev
Subject: Re: [kepler-dev] Can "stop" interrupt "initialize()"


Your suggestion about changing things in the "guts" of Ptolemy scares
me a bit. Moreover, I think it's probably not needed.

We had recently an exchange (on kepler-dev) about different workflow
stages or phases, among them something that could be called "data
staging". I think it's time we recognize that we need to state the
requirements data staging, then come up with a design that extend
Ptolemy/Kepler without further overloading the native Ptolemy

In particular, I think the "VCR buttons" for "Play", "Pause", and
"Stop" need to be augmented with other buttons for data staging (if
necessary), static type checking (when desired) etc. Doing things
under the (Ptolemy) hood doesn't seem like a good idea.

Is there a requirements or design document for the features you've
described and that we need? If not, we should probably put this on the
agenda of the upcoming Kepler meeting..

What do you think?



>>> On Sun, 29 Jan 2006 17:51:11 -0600
>>> Kevin Ruland <kruland at ku.edu> wrote: 
KR> Hi.
KR> In Kepler we have some actors which download large volume of data in the

KR> background.  They do this without any control from the director.  In 
KR> essence this is done when the actor is instantiated and should complete 
KR> prior to the user running the workflow (ie, before initialize() is
KR> I was looking at the problem we're having with ptexecute where these 
KR> workflows bomb because ptexecute does not know that it needs to wait 
KR> until the data is loaded before executing the workflow.
KR> I was thinking of two different alternatives here.  The first is to have

KR> initialize() verify that the data download is complete and raise an 
KR> IllegalActionException if it is not complete.  This provides feedback to

KR> a real user when they press "go" too soon, but does not fix the problem 
KR> we have with ptexecute because it will just bomb when initialize()
KR> The other alternative is to have initialize() block until the data is 
KR> downloaded.  This solves the ptexecute problem.  The problem now is with

KR> the UI.  After a real user presses "go", the "stop" button does not 
KR> appear to do anything.  I believe that stop does not attempt to 
KR> interrupt actors stuck in initialize().
KR> I think the best solution overall, is to have the stop button actually 
KR> interrupt the workflow thread.  The InterruptedException could be 
KR> trapped and converted into an IllegalActionException.  Unfortunately, 
KR> such a change would very likely be deep in the guts of Ptolemy, and 
KR> could potentially have other unintended consequences.  What do you
KR> Kevin
KR> Posted to the ptolemy-hackers mailing list.  Please send administrative
KR> mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu

Kepler-dev mailing list
Kepler-dev at ecoinformatics.org

More information about the Kepler-dev mailing list