[kepler-dev] Running Ptolemy from the Kepler build

[Christopher Brooks]

Hi David,
The executive summary is that running Ptolemy II from the Kepler build
infrastructure is very slick.  However, I'm concerned that you have copied
many libraries into the kepler ptolemy-lib directory though.  I'm
concerned about the size of the download, the number of libraries
that are used very little and licensing issues.  However, I think we
can work on this, especially if the build system is capable of checking
for missing classes at buildtime.  Also, I'll go ahead and set up write
access to the Ptolemy II tree, just please follow our style guide and
don't do anything drastic.

Details are below.

David Welker wrote:
> Hi Christopher,
> 
> I just wanted to report to you that Ptolemy can now be run from build 
> used for Kepler.
> 
> To try this out, issue the following commands:
> 
> ant change-to -Dsuite=ptII
> 
> ant run
> 
> Anyway, I have the following requests:
> 
> (1) Please let me know if you observe any issues when running Ptolemy.


Looks really promising!

One issue is that it seems like you have checked in copies of
libraries that are used in the Ptolemy II tree.  This will result
in chaos as we slowly upgrade libraries in ptII/lib.  Is there
anyway to use just the libraries that are included in the ptII svn
repository?  Also, at build-time, the build system should check for
features such as Eclipse and then include the appropriate jar files.
This is what configure does for us.  I believe ant can check for classes
and take appropriate action, though I have not tried it with ant.

There are also some GPL'd libraries that are in the ptolemy-lib
svn repository.  I specifically try not to include GPL'd code
in the repository for fear of license chaos.

Having many libraries in ptolemy-lib also makes the svn download
huge, du -k kepler/ptolemy-lib comes in at 417Mb!

It looks like many libraries from Eclipse3.4.2 are included.
I'm not sure if the Eclipse libraries will work on multiple
architectures or not.
There are also a number of jar files included that are used
very little.

One issue is that having all these libraries makes it look like
Ptolemy II requires many external pieces of code, when in reality
the core requires no external jar files.  For example,
"java -classpath $PTII ptolemy.vergil.VergilApplication"
works without other jars.  The power of Ptolemy is that we make
it somewhat easy for developers to use third party software,
but the system is still useful without that software.

To get a more minimal set of jar files, try downloading the Ptolemy
II 7.0 Windows installer and look at the jar files included.  We don't
include all jar files in the Windows installer, just the ones
likely to be useful.

When I did
 > ant change-to -Dsuite=ptII
 >
 > ant run
I got:
run:
       [run] Exception in thread "main" java.lang.NoClassDefFoundError: 
org/kepler/core/loader/Loader

So, I suspect that there is a dependency here?

I did
ant change-to -Dsuite=kepler-trunk
ant run
ant change-to -Dsuite=ptII
ant run
and Ptolemy came up!

(BTW - If I run "ant change-to", can the error message list some of the
common suites such as kepler-trunk and vanilla-1.0?)

The way I check out Ptolemy is by following the links for the copyright
until I get to pages that expand various links.  Basically, just follow
the links at the bottom of the copyright pages.

For example,  in the splash screen, I click on "Copyright", which
brings up a page where I follow the "Other copyrights about this
configuration" link, which brings up a page where I follow the
"Other information about this configuration", which brings
up a page that brings up links that expand the configuration
and open all the demos.

In my configuration, it looks like there are problems with colt,
probably because ptcolt.jar is not found

These classes or actors were not found:
CCodeGenerator
JavaCodeGenerator
classes associated with the SerialComm.
CalInterpreter
PythonScript
x10 classes
Java3D

This is not a huge worry though, it is because the full version
of Ptolemy is being run.  You could try passing the runtime
configuration argument -ptinyKepler, which includes just the
features used by Kepler.  For example:
java -classpath $PTII ptolemy.vergil.VergilApplication -ptinyKepler
With -ptinyKepler, only Colt and Ptalon are missing

 > (2) I would appreciate your assistance in eliminating as many of the
 > remaining excludes as possible.

I'll take a look at the list of excludes, there are various simple
things that can be excluded.  I'll update the descriptive text
file.

I think we have the following possibilities
1) Have -ptinyKepler work, which would bring up the Vergil UI
and would not require lots of other jar files
2) Have the "full" version of Ptolemy II work, which does not
include all optional package.  This is what we ship as the
Windows installer
3) Have everything work.  This requires many jar files and will
not work on all platforms.  For example the Mac is missing JAI.

 > (3) I was also wondering whether I could have write access to the
 > Ptolemy repository.

Sure, I'll give you write access to repository.  Your changes must
follow the Ptolemy II style guide.  Most changes made by the Kepler
team to the Ptolemy II tree have been to support Kepler by making
it easier to extend the Ptolemy II classes.  My hope is that
your changes would follow this precedent and keep the current
Ptolemy II status quo, such as it is.  In the past, Edward and I
have discussed major changes by Kepler developers with those
developers before they went in.
The style guide is at 
http://ptolemy.berkeley.edu/ptolemyII/ptII7.0/ptII7.0.1/doc/coding/style.htm

BTW - One other thing is that I'd like there to be top level build.xml
file that would have the common rules in it.  Changing directories
to build-area seems kind of non-standard.  Having a top level
build.xml would help avoid some confusion.  What do you think?

Many thanks for your work with invoking Ptolemy II from within
the Kepler build framework.  I think if we will have a real winner
if we can avoid having duplicate libraries and have the system configure
itself depending on what libraries are to be found.

_Christopher


 >
 > Thanks!
 >
 > David




-- 
Christopher Brooks (cxh at eecs berkeley edu) University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480