[kepler-dev] Hiding port names

Tue Jul 27 08:26:08 PDT 2004

I suspect that the problem might have something to do with creating
tar files in the ptII tree.

Oddly, I was able to get Kepler built without much of a hitch using my
usual ptII tree and a new Kepler tree under Cygwin.  I believe I also
built and ran on a Linux box.

My notes at
http://chess.eecs.berkeley.edu/ptolemy/projects/kepler.htm
(visible to ptolemy group members, not kepler-ites)
say:

--start--
   1. Request an account via http://kepler.ecoinformatics.org/
   2. Once you get an account log on to ecoinformatics.org and change
      your password
   3. Then check out the tree with
      cvs -d :ext:yourlogin at cvs.ecoinformatics.org:/cvs co kepler

   4. You can look over the cvs repository with:
      http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/
   5. The Kepler installation instructions are in kepler/docs/INSTALL,
      below are some further notes.
      (Kepler Eclipse instructions)
   6. Set the KEPLER environment variable to point to your kepler
      installation. PTII should of course be set.
   7. Kepler requires Apache Ant, which can be found at
      http://ant.apache.org/
      Installation instructions can be found on the Ptolemy Ant Page.
   8. To see what targets can be built:

      cd $KEPLER
      ant

   9. To build Ptolemy

      ant ptolemy

  10. To run Kepler

      ant run

      I was having problems with ant run, where it was hanging on CVS,
      so I set up CVS so that I could log in to cvs.ecoinformatics.org
      without a password by running the following command under
      Windows and crating ~/.ssh/authorized_keys2 on the cvs server:

       scp -p ~/.ssh/id_rsa.pub
       yourlogin at cvs.ecoinformatics.org:~/.ssh/authorized_keys2
--end--

I suspect that I had run "make install" in my ptII tree before trying
the build.

The next step would be to try checking out a clean ptII tree and
working from there.
Unfortunately, since you are connected via dialup, this would be very
slow.

It is interesting that we ended up with the same error message
when we built from your regular ptII tree that you use with Eclipse
and with your non-eclipse ptII tree.

Concerning opening the cvs tree, I'm all for it, below are my
concerns:

1) The code should be under the Ptolemy-style copyright.  It is ok if
someone besides the Regents holds the copyright.  I strongly prefer
that GPL'd code not be checked in to the core of Ptolemy, that is that
Ptolemy should start up and be useful without GPL'd code.  GPL'd code
in extensions is ok.

Since it seems like most of the Kepler code is using a Ptolemy style
copyright, this should not be a problem.

2) New code needs to follow the Ptolemy coding conventions.  If it
does not, then I end up fixing it.

3) Wholesale copying of classes to make minor changes is ultimately
not worth it.  If need be, we can modify the parent classes.  Copy and
paste changes mean we need to maintain the code in multiple places

4) Changing the look and feel should not be done lightly.  Ideally,
new additions should be optionally configurable.  For example, the
Thales single window interface is optional.  I would prefer to see the
Kepler tabbed interface to the actor pane left as an optional choice,
and I would prefer to see having scrollbars on the graph viewer as
something that is optional.  These features are cool and interesting,
but Edward and Steve should probably have say in whether it is the
default for Ptolemy.

5) New code should have either Tcl based unit tests or model based
auto tests.  (see $PTII/doc/coding/testing.htm) 

6) Bug fixes to the Ptolemy tree should have tests that illustrate 
the bug and then pass when the fix is installed.  This is not always
possible, but it is a big help

I'm more than willing to grant read/write access to anyone in the
Kepler group that wants read/write access.  The reason we don't
grant read/write access immediately is because it takes extra work
dealing with the departmental user id database to get a Unix
account for cvs read/write access.

We had talked about making the CVS tree publically readable, perhaps
also with a snapshot facility where we would mark versions that pass
certain tests as "working" and make those available as tar files or as
cvs branches.  In principle, this could occur after 4.0.1 is out,
though I have some other tasks ahead of me first.

-Christopher

--------

    At 08:09 AM 7/26/2004 -0800, Matt Jones wrote:
    >Yeah, we fully intend to support the CVS HEAD for PTII in our kepler 
    >builds, as it seems like the only way to really keep synchronized.  Over 
    >the last week several of us have been building against the CVS head, with 
    >mixed results.  Sometimes it works, sometimes not...haven't yet figured 
    >out the differences among these builds yet that cause the failures.  We'll

    >get the issues worked out fully and then post instructions on the web 
    >site.  It should be as simple as checking out the two trees, set 2 env 
    >vars, then run 'ant ptolemy run'.  I think the problems we are hitting are

    >due to us not encoding in our ant build some of the dependencies that you 
    >cover in your makefiles.

    I doubt this... We do builds with Eclipse, which don't use
    the makefile dependencies either...

    Ideally, I would like to be able to have Kepler and Ptolemy II as
    two Eclipse projects, and not use either ant or make... But this
    is a personal preference.

    I think it would be very helpful if some of us would routinely
    build the kepler tree against our current repository... This way,
    we could check for problems before checking in major changes to
    our tree...

    However, I still can't get the ant build to yield an executable
    kepler... Any ideas about the problem I reported?  I suspect a classpath
    problem, but I haven't been able to figure it out...

    >In addition, we need a way to try to incorporate Kepler changes into the 
    >PTII tree.  We are working on a variety of changes relating to data access

    >and semantic typing, and several of these require UI changes in 
    >vergil.  We have been developing them using the ptolemy extension 
    >mechanism through the configuration, so they could be used or not 
    >depending on how the configuration is set up.  But there are many areas of

    >vergil which are not configurable, and so we are extending those areas to 
    >be configurable where needed.  Ultimately, we need to contribute this code

    >to PTII through the code review process -- I think the easiest way to do 
    >this is to have a couple of Kepler developers who have write access to the

    >PTII CVS tree and can contribute code after consultation with PTII 
    >developers (like Christopher and yourself).

    This sounds like the right approach...

    >In many ways I would prefer to not have to maintain two separate CVS trees

    >at all, but I currently don't see a good way to do this because we want 
    >the Kepler project to be fully open to a variety of contributors, while 
    >the PTII tree is really reserved for the Berkeley Ptolemy project.  But it

    >would be nice to use just a single integrated tree.  I would be interested

    >in chatting with you about whether you could see the two projects really 
    >sharing a cvs tree or not, given the project management implications this 
    >would have.

    In practice, we have a fairly informal mechanism where people
    with access to the tree self-regulate.  Those with less experience,
    for example, don't check in changes to the kernel package without
    running them by others.  Moreover, we have regions of the tree
    where "anything goes" (at one extreme, we
    have an "apps" directory containing
    unproven and sometimes very rough projects).

    I could see this mechanism extending to a larger group...

    Edward

    ------------
    Edward A. Lee, Professor
    518 Cory Hall, UC Berkeley, Berkeley, CA 94720
    phone: 510-642-0455, fax: 510-642-2739
    eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal

    _______________________________________________
    kepler-dev mailing list
    kepler-dev at ecoinformatics.org
    http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
--------