[kepler-dev] [Fwd: [kepler-cvs] kepler/src/exp/ptolemy/actor/process ProcessThread.java]

[Oscar Barney]

Hi all,

First, for those of you that don't know me, I am Oscar Barney from the 
University of Utah and have been working with Ilkay and the Scientific 
Process Automation group on provenance and smart reruns stuff. 

I agree with Shawn and Chad.  The idea, as Ilkay said, was to check them 
into exp temporarily so that they could be farther tested before 
checking them into Ptolemy.  The goal here was just to do farther 
testing but not long term maintenance like everyone has pointed out.  I 
am open to any suggestions and would be OK with removing them from the 
exp directory.  We could put them somewhere else and then whoever tests 
them farther could just copy them into their own exp directory.

=========== An explanation of the changes =========

I did not change the functionality of any of the classes but just made 
some additions.  When I met with Ilkay this summer to design the 
provenance recorder we decided to design it like a Ptolemy 
ExecutionListener that the manager already had some facilities for.  
There is a Kepler hot topics page that describes some of our ideas 
called Stand-alone Kepler Provenance Framework.

What I did was create a class called ProvenanceExecutionListener that 
implements the ChangeListener and ExecutionListener interfaces.  A class 
that implements these interfaces and is registered with the Manager will 
get notified of changes made to the model(ChangeListener stuff) and 
events related to the execution of the model(ExecutionListener stuff).  
Also for provenance specific purposes I added some additional events to 
the Manager such as one that notifies the provenance recorder that a 
token was sent.  This is why IOPort was modified.  If there is a 
listener that wants to save the tokens, IOPort will notify the manager 
whan a token is sent.  The Manager then notifies the Provenance 
Recorder.  The manager is also in charge of registering and 
unregistering the Provenance Recorder so a function was added for each 
of these purposes.

The class FunctionDependencyOfModel is one I added that basically just 
creates a graph that represents the whole model.  In essence it keeps 
track of the "wiring."  It is mostly useful for smart reruns stuff but 
we have an option in the Provenance Recorder where you can have this 
graph printed out.  NOTE: the smart reruns stuff was not checked in and 
is still a prototype.

Christopher Brooks has given me some ideas about how to get around 
adding stuff to the ProcessThread and the StaticScheduler.  I had made 
an addition that notified the Provenance Recorder when actors were about 
to fire for the "Execution Log" that is described on the Hot topics 
page.  I think we can work around this or give up this notification 
since we were not sure people would need it anyway.

I am glad that we are all discussing this now.  The "smart reruns" stuff 
will again require a few additions which will be much easier to make 
after we figure out how to go about it.

Thanks for all the input and sorry for the confusion,

Oscar Barney
U. Utah


Chad Berkley wrote:

>Yeah, I'm not sure this is a good idea adding so many exp files.  I  
>think these changes can probably be made in the PTII tree if they're  
>essential.  I think we really need to minimize the number of classes  
>in the exp directory or we're going to be in for a huge headache the  
>next time those classes change in PTII.
>
>chad
>
>On Oct 24, 2005, at 11:22 PM, Shawn Bowers wrote:
>
>  
>
>>Hi all,
>>
>>I am getting a little nervous about some of the new checkins to exp.
>>In particular, some of the fundamental classes like IOPort, Manager,
>>StaticScheduler, etc.  I think it would be great if prior to checking
>>in fundamental classes such as this into the exp directory, if a few
>>folks could make sure they are "bullet proof" ... perhaps this has
>>already been done.  My concern is that this has the potential of
>>adding bugs that may be very hard to find for folks.
>>
>>Also, Oscar, you might want to send a note to kepler-dev explaining
>>what changes you are making to these classes.  I think these are the
>>first non-gui type classes that have been modified within Kepler, so
>>it would be educational for us to hear what changes were necessary,
>>etc.
>>
>>Thanks,
>>-shawn
>>
>>-------- Original Message --------
>>Subject: [kepler-cvs] kepler/src/exp/ptolemy/actor/process  
>>ProcessThread.java
>>Date: Mon, 24 Oct 2005 20:38:20 -0700 (PDT)
>>From: barney at ecoinformatics.org (Oscar Barney)
>>To: kepler-cvs at ecoinformatics.org
>>
>>barney      05/10/24 20:38:20
>>
>>   Removed:     src/exp/ptolemy/actor/process ProcessThread.java
>>   Log:
>>   removed because of reasons that Christopher Brooks mentioned(it  
>>is important
>>and being modified allot by the ptolemy people).  ProcessThread did  
>>not preform
>>a critical function with the Provenance listener and we can work  
>>probably work
>>around having it modified.
>>_______________________________________________
>>Kepler-cvs mailing list
>>Kepler-cvs at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/ 
>>kepler-cvs
>>_______________________________________________
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/ 
>>kepler-dev
>>
>>
>>    
>>
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>  
>