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

Bertram Ludaescher ludaesch at ucdavis.edu
Tue Oct 25 08:57:31 PDT 2005


Hi Ilkay:

Maybe one thing to avoid surprises would be to run part of the
discussion over kepler-dev (as you suggest) since not everybody is on
IRC--actually nobody is on IRC all the time ;-)
Also, since kepler-dev is archived, one can always go back to see why
particular decisions were made..

my $0.02 on this..

Bertram


>>> On Tue, 25 Oct 2005 08:36:13 -0700
>>> Ilkay Altintas <altintas at sdsc.edu> wrote: 
IA> 
IA> Hi Guys,
IA> How to do this best was asked and discussed (with the few who  
IA> responded) on the Kepler irc channel before Oscar has checked in the  
IA> new classes to the exp directory. Next time we'll also query on the  
IA> kepler-dev for ideas before we do such a change.
IA> 
IA> We sure need to be careful about what to check in as exp, but we also  
IA> need to check these in somehow. We can't check them into Ptolemy  
IA> without testing them further IMHO.
IA> 
IA> Any ideas on how to do these check-ins more robust?
IA> 
IA> Thanks,
IA> -ilkay
IA> 
IA> 
IA> On Oct 25, 2005, at 8:18 AM, Chad Berkley wrote:
IA> 
>> 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
IA> 
IA> _______________________________________________
IA> Kepler-dev mailing list
IA> Kepler-dev at ecoinformatics.org
IA> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev



More information about the Kepler-dev mailing list