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

[Shawn Bowers]

I think it is ok to check into the exp directory for exactly the
purpose you describe below. And, I believe we should be, when time
allows, working to generally fold exp back into the ptolemy codebase.

Until now, I believe exp only contained changes to the gui.  So my
previous comments were primarily directed at the checkins of
core/kernel classes like IOPort.  I think these changes should be on a
"fast track" for folding back into the ptolemy tree and testing, etc.,
as they can have large impacts if they introduce bugs.

I am not against checking the code in, and don't think it should be
removed (unless it is folded into the ptolemy tree or is not needed).
But, for these kernel classes, it would be good if there were a note
to kepler-dev, e.g., that these have been checked in and their
purpose, allowing folks to comment on the changes, etc.  This way, we
may be able to avoid possible pitfalls.

Thanks for contributing to kepler Oscar! I think these provenance
additions are very exciting.

-shawn

Oscar Barney wrote:
 > 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
 >>
 >>
 >
 > _______________________________________________
 > Kepler-dev mailing list
 > Kepler-dev at ecoinformatics.org
 > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev