Make error in $PTII/doc
A small bug: Freshly checked out PTII, "./configure; make fast install" get: making install in ./doc make[1]: Entering directory `/home/welson/cvs/byucc/dsynth/libs/ptII/doc' sed -e 's@" target="_top">@#in_browser">@' \ -e '[EMAIL PROTECTED]" target="body">@main.htm">@' \ -e '[EMAIL PROTECTED]@@' \ main.htm > mainVergil.htm awk -f ../doc/javahtml.awk mainVergil.htm > mainVergilPtiny.htm awk -f ../doc/ptinyKepler.awk mainVergilPtiny.htm > mainVergilPtinyKepler.htm awk: fatal: can't open source file `../doc/ptinyKepler.awk' for reading (No such file or directory) make[1]: *** [mainVergilPtinyKepler.htm] Error 2 make[1]: Leaving directory `/home/welson/cvs/byucc/dsynth/libs/ptII/doc' make: *** [subinstall] Error 2 Missing $PTII/doc/ptinyKepler.awk, somebody can check it in? Welson Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
Re: Can "stop" interrupt "initialize()"
At 01:49 PM 1/30/2006 -0600, Kevin Ruland wrote: Every Director has a method isStopRequested(). A long running initialize() method should just call this method and abort if it returns true... 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? Call getDirector(). I wouldn't do this as a spin wait, though. Instead, in the long running thread, periodically call isStopRequested() at points where it would be safe to abort. This is much safer than calling interrupt() on a thread, which can leave objects in an undefined state. 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. getManager(). 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()"
At 05:51 PM 1/29/2006 -0600, Kevin Ruland wrote: 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 pushing the stop button will cause the stop() and stopFire() methods to both be called on the actor. 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? I would suggest that this interaction be part of the actor design, not the Ptolemy kernel. The actor should control the thread interactions. You could make a base class for a family of such actors the provides the basic framework... 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]
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()"
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()"
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()"
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()"
Bertram Ludaescher wrote: On Mon, 30 Jan 2006 08:41:50 -0600 Kevin Ruland <[EMAIL PROTECTED]> wrote: KR> KR> Bertram, KR> KR> Things like static type checking may be optional (to the workflow) in KR> the sense that one could still execute a workflow without having done KR> the static type checking step or perhaps the workflow could be executed KR> if static type checking fails (user override?). In this sense, data KR> loading is different because it is necessary to have successfully KR> completed data loading prior to execution. I agree that e.g. static type checking is (typically) optional Also it is different from data loading. On the other hand, there are similarities between a long-running job / actor and the data loading. Whenever things take a very long time, a different "mode of operation" seems necessary. This what I was arguing for (different stages or phases) in the light of long-running data loading operations on start-up. For example, wouldn't it be useful to have the possibility that the user chooses which dataset is being loaded before it is actually loaded at startup? I suppose you're thinking of something like firefox's download manager. That would be very nice but would be a new feature which needs to be approved soon in order to be included in the feature freeze at the end of Feb. Bring it up next week and we can discuss its utility, in this context, as well as feasibility. KR> Also, if some actor somewhere does do something extremely time consuming KR> in it's initialize method, there is currently no pleasant way to KR> interrupt it. The user can click on the stop button, and it does appear Maybe we should discourage such practice, i.e., having time consuming initializes. A rule of thumb could be: if it takes longer than a few seconds, it should be NOT part of the initialization phase, but a separate phase!? (obviously this needs some more thought) Right. Since initialize cannot be interrupted, I should think that it would be even shorter than a few seconds. In the case of these actors, right now they just verify that the data load is complete. If it isn't complete then they raise the IllegalActionException which can be interpreted as either "not ready yet" (in this case), or "improperly configured" (as should be the case for other actors). My understanding of the initialize() method is it is supposed to verify proper configuration. This brings me to another idea, instead of having initialize() in these data actors block for completion of download, it would be completely possible for them to block in prefire or fire. That is, they don't wait until they are actually called upon to do something useful. I will play with this and see if stop then does what I hope it to. KR> to have some effect -- that is, it's indentation changes when pressed -- KR> however, it does not interrupt the processing. This behavior could be KR> considered a but itself. Either the stop button needs to be disabled KR> until it can do something useful, or it should stop the workflow KR> regardless of its execution state. I guess in Ptolemy, hitting 'stop' implies that the system goes into a "defined state" so that when hitting 'resume' (currently the same as 'play' ;-) things are consistent. A "hard interrupt" would probably causes problems with restarting later!? It would be possible, in this case, for stop to terminate the d/l, then play/pause, would simply restart the d/l. KR> I have been given no requirements for the data loading process - other KR> than to see if we can make ptexecute work correctly. For the particular workflow at hand, could the dataloading be moved from the init phase to a later phase (when 'play' has been hit)? Or is the data loading already happing at 'play' time!? The data load actually happens before play. The user has no control over its beginning or end - this is perhaps a bad thing. Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
Re: Can "stop" interrupt "initialize()"
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?). 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]
