On Mon, 30 Jan 2006, Kevin Ruland wrote:
Bertram,
Things like static type checking may be optional (to the workflow) in
the sense that one could still execute a workflow without having done
the static type checking step or perhaps the workflow could be executed
if static type checking fails (user override?).
Is this really true? I don't think so in Ptolemy -- i.e., ptolemy throws
exceptions if unexpected types are found. In general, I'm not sure that
for standard ptolemy/kepler type workflows, it even makes sense to run
them if they are not type safe.
-shawn
In this sense, data
loading is different because it is necessary to have successfully
completed data loading prior to execution.
Also, if some actor somewhere does do something extremely time consuming
in it's initialize method, there is currently no pleasant way to
interrupt it. The user can click on the stop button, and it does appear
to have some effect -- that is, it's indentation changes when pressed --
however, it does not interrupt the processing. This behavior could be
considered a but itself. Either the stop button needs to be disabled
until it can do something useful, or it should stop the workflow
regardless of its execution state.
I have been given no requirements for the data loading process - other
than to see if we can make ptexecute work correctly.
Kevin
Bertram Ludaescher wrote:
Kevin:
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
capabilities.
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?
cheers
Bertram
On Sun, 29 Jan 2006 17:51:11 -0600
Kevin Ruland [EMAIL PROTECTED] wrote:
KR
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
called).
KR
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
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()
fails.
KR
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
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
think?
KR
KR Kevin
KR
KR
KR Posted to the ptolemy-hackers mailing list. Please send administrative
KR mail for this list to: [EMAIL PROTECTED]
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
