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]