Re: Can stop interrupt initialize()
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]
Re: Can stop interrupt initialize()
No problem ... I thought you were referring to structural types -- int, string, array of double, etc. I agree with Bertram that structural type checking would be very useful to have has a button akin to a staging button, a run button, a stop button, and so on. The semantic type stuff is not essential to running a workflow -- -shawn On Mon, 30 Jan 2006, Kevin Ruland wrote: Shawn, I was not clear -- I was referring to the semantic type checking and the 'manual override' would only be for those users who have some deeper understanding of the data and don't want to go through the effort of annotating them correctly. In retrospect, I should not have spoken because I don't know what the desired functionality of this portion of the system is. Kevin Shawn Bowers wrote: 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. Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
Re: Can stop interrupt initialize()
At 08:41 AM 1/30/2006 -0600, Kevin Ruland wrote: 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. Every Director has a method isStopRequested(). A long running initialize() method should just call this method and abort if it returns true... I would be circumspect about adding additional phases. It could significantly increase the complexity for actor writers. Edward Edward A. Lee Professor, Chair of the EE Division, Associate Chair of EECS 231 Cory Hall, UC Berkeley, Berkeley, CA 94720 phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845 [EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
Re: Can stop interrupt initialize()
Edward A. Lee wrote: At 08:41 AM 1/30/2006 -0600, Kevin Ruland wrote: 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. Every Director has a method isStopRequested(). A long running initialize() method should just call this method and abort if it returns true... Edward, I think I can use this in some kind of spin wait. What's the easiest way for an actor get a handle to it's director? I did a little digging and noticed that Manager.finish() does a notifyAll(). Presumably I could tap into this as well and synchronize on the Manager object. Of course, I need to get my hands on the Manager, and there might be a different deadlock situation present. Thanks much. Kevin I would be circumspect about adding additional phases. It could significantly increase the complexity for actor writers. Edward Edward A. Lee Professor, Chair of the EE Division, Associate Chair of EECS 231 Cory Hall, UC Berkeley, Berkeley, CA 94720 phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845 [EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
Can stop interrupt initialize()
Hi. In Kepler we have some actors which download large volume of data in the background. They do this without any control from the director. In essence this is done when the actor is instantiated and should complete prior to the user running the workflow (ie, before initialize() is called). I was looking at the problem we're having with ptexecute where these workflows bomb because ptexecute does not know that it needs to wait until the data is loaded before executing the workflow. I was thinking of two different alternatives here. The first is to have initialize() verify that the data download is complete and raise an IllegalActionException if it is not complete. This provides feedback to a real user when they press go too soon, but does not fix the problem we have with ptexecute because it will just bomb when initialize() fails. The other alternative is to have initialize() block until the data is downloaded. This solves the ptexecute problem. The problem now is with the UI. After a real user presses go, the stop button does not appear to do anything. I believe that stop does not attempt to interrupt actors stuck in initialize(). I think the best solution overall, is to have the stop button actually interrupt the workflow thread. The InterruptedException could be trapped and converted into an IllegalActionException. Unfortunately, such a change would very likely be deep in the guts of Ptolemy, and could potentially have other unintended consequences. What do you think? Kevin Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]