[kepler-dev] [Fwd: [kepler-cvs] kepler/src/exp/ptolemy/actor/process ProcessThread.java]
oscar at sci.utah.edu
Tue Oct 25 09:38:49 PDT 2005
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,
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.
>On Oct 24, 2005, at 11:22 PM, Shawn Bowers wrote:
>>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,
>>-------- Original Message --------
>>Subject: [kepler-cvs] kepler/src/exp/ptolemy/actor/process
>>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
>> removed because of reasons that Christopher Brooks mentioned(it
>>and being modified allot by the ptolemy people). ProcessThread did
>>a critical function with the Provenance listener and we can work
>>around having it modified.
>>Kepler-cvs mailing list
>>Kepler-cvs at ecoinformatics.org
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
More information about the Kepler-dev