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

Tue Oct 25 09:51:11 PDT 2005

Hi Ilkay,

For the Ptolemy non-graphical code, check out a tree, check in the
changes, run the test suite:
  make tests
You can run this at any level, including the top.
Most tests pass, but some don't, so it is often worth running the
tests first and then making mods and running them again.
See $PTIII/doc/coding/testing.htm

Also, if you go to the copyright page by following an about:copyright
url, then there are links to open all the files in model page or
to expand the configuration.  This is a good way to find missing
classes.  I recently extended actor.gui.HTMLAbout
so it looks for attributes like _applicationDemos, which 
is an array of Strings naming files that should be expanded.
See $PTII/ptolemy/configs/viptos/configuration.xml

I'm game for implementing a graphical test harness.  I've looked in to
it in the past and not come up with a really good solution.  Maybe we
can collaborate on this?

BTW - I'd rather see the Ptolemy tree broken for a few hours than see
code duplication, especially of core classes.  When Edward and I have
taken user contributions and folded them in to the tree, the worst
problems have occurred when the contribution duplicated a class.  Now
we have more places to fix the same bug.  I know this drives Edward
nuts and gets him asking why-o-why did we take that user contribution.

If the Ptolemy tree does not have the proper extension points for
Kepler, then I consider that an architectural design flaw in Ptolemy
that we should remedy asap.  

_Christopher

--------

    I agree. In the future, we'll discuss these things on Kepler-dev.

    I actually like Shawn's idea of making sure that any code that will  
    affect the core is bullet-proof before it is checked in. I don't know a  
    good way of doing this. (Considering our experience in the past with  
    setting up code reviews.) Any suggestions?

    Thanks,
    -ilkay

    On Oct 25, 2005, at 8:57 AM, Bertram Ludaescher wrote:

    > 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

    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------