[kepler-dev] [Ptolemy] Increasing the componentization of Ptolemy II
Christopher Brooks
cxh at eecs.berkeley.edu
Mon Sep 29 13:40:58 PDT 2008
Hi Brian,
Now that we have http://ptolemy.org, it seems like going with
org.ptolemy is better than edu.berkeley.eecs.ptolemy:
- org.ptolemy is less typing than edu.berkeley.eecs.ptolemy
- org.ptolemy better represents the community. Ptolemy is not
just about our work here at Berkeley. Plenty of other people
contribute.
About the packaging:
Yes, keeping headless execution working is key.
There is some slightly out of date notes at
https://dev.kepler-project.org/developers/reference/ptolemy-package-dependencies
Friday's effort yielded these projects:
bash-3.2$ ls triq
features plugins
bash-3.2$ ls triq/features
ptolemy.ptiny
bash-3.2$ ls triq/plugins
com.microstar.xml ptolemy.domains.de.demo
diva ptolemy.domains.de.doc
ptolemy.actor ptolemy.domains.fsm
ptolemy.actor.gui ptolemy.domains.fsm.demo
ptolemy.actor.lib ptolemy.domains.fsm.doc
ptolemy.actor.lib.colt ptolemy.domains.hdf
ptolemy.actor.lib.colt.demo ptolemy.domains.hdf.demo
ptolemy.actor.lib.comm.demo ptolemy.domains.hdf.doc
ptolemy.actor.lib.gui ptolemy.domains.pn
ptolemy.actor.lib.hoc.demo ptolemy.domains.pn.demo
ptolemy.actor.lib.image ptolemy.domains.pn.doc
ptolemy.actor.lib.javasound.demo ptolemy.domains.rendezvous
ptolemy.actor.lib.jni ptolemy.domains.rendezvous.demo
ptolemy.actor.lib.python ptolemy.domains.rendezvous.doc
ptolemy.actor.lib.python.demo ptolemy.domains.sdf
ptolemy.actor.lib.security.demo ptolemy.domains.sdf.lib.vq
ptolemy.actor.ptalon ptolemy.domains.sr
ptolemy.actor.ptalon.antlr ptolemy.domains.sr.demo
ptolemy.actor.ptalon.demo ptolemy.domains.sr.doc
ptolemy.codegen ptolemy.graph
ptolemy.codegen.demo ptolemy.gui
ptolemy.data ptolemy.kernel
ptolemy.data.type.demo ptolemy.math
ptolemy.data.unit.demo ptolemy.media
ptolemy.domains.ct ptolemy.moml
ptolemy.domains.ct.demo ptolemy.moml.demo
ptolemy.domains.ct.doc ptolemy.plot
ptolemy.domains.ddf ptolemy.util
ptolemy.domains.ddf.demo ptolemy.vergil
ptolemy.domains.ddf.doc ptolemy.vergil.kernel.attributes.demo
ptolemy.domains.de
A few notes:
- com.microstar.xml needs to be in a separate bundle from moml because
the plotter uses it. Also, we have talked about using a different
XML parser some day.
- common domain polymorphic actors are in a separate bundle:
ptolemy.actor.lib
- Other actors are in their own packages.
- the domains consist of the director and any domain specific non-gui actors
- domain specific gui actors are in a separate package
- domain specific documentation is in a separate package
We might be able to use features to combine the ptiny domains into
one feature. We could then combine the ptiny domains and the execution
engine and moml into a headless ptiny feature.
Interesting about the Eclipse buddy policy, I'll have to think about that.
The biggest problem I have with moving the code into separate Eclipse
projects is that now it becomes much more difficult to run Ptolemy
from the command line using the java command.
java -classpath $PTII ptolemy.vergil.VergilApplication
works.
If we move the code into separate Eclipse projects, and someone does
not want to use Eclipse, then the classpath is very long or else
the compile needs to be smart enough to drop all the .class files in
a common build directory.
One other problem is that the Eclipse/Ant infrastructure is quite
difficult to use for a nightly build or headless build. It can be made
to work, but to actually find the definitions of the rules is difficult
and involves many files. Compare this to how Kepler currently compiles
Ptolemy, which requires one ant file. The Ptolemy makefiles system
involves running configure and then at compile time, three makefiles
are used.
An alternative to moving code around would be to leave the files where
they are and us make or ant to build the bundles. I'm ready to leave
make, but ant seems like a worse version of make (editing xml files by
hand is a bug, not a feature). I didn't find good support for managing
bundles with Maven, though it is probably out there. Also, maven seems
somewhat dogmatic about how code should be laid out. I don't by the
various separations they seem to promote.
_Christopher
Brian Hudson wrote:
> Hey Chris,
>
> We've been experimenting with using Eclipse and OSGi to build bundles
> of the Ptolemy II code base.
>
>
> Good to hear, I'm glad you are moving in this direction. It will
> certainly be useful for the NOEM project at AFRL.
>
> 1) Is this the time to refactor the ptolemy.* packages to
> org.ptolemy.*?
>
>
> I'd say its a good time. I'm curious, why are you going with
> org.ptolemy.* versus something like edu.ucb.ptolemy.* or something similar?
>
> 2) It is not clear to me what the proper level of granularity is for
> the bundles.
>
>
> This seems to be the most common question projects have when they begin
> to move over to this platform. Bundles per package isn't the way too go.
> I think that you're moving in the right direction with bundling similar
> functionality together.
>
> I'd like to be able to only include the things that are required for
> headless execution of models. It seems you are moving towards something
> like that when you mention splitting out the UI-based actors.
>
> I'd be interested in seeing your list of bundles. A rough outline of how
> I think I'd break them up is something like:
> - kernel
> - ui actors
> - actors specific to a domain
> - actors that require things like sound, JAI, JNI etc
> - domains
> - demos
> - docs
> - vergil
> - plot
>
>
> I think it is mentioned in the Ptolemy documentation that adding a new
> actor to the system is sort of painful at the moment. I think the
> Eclipse extension registry would be a a good way to remedy this. It
> becomes more obvious how things should be bundled when you begin to
> consider how you would set up extension-points and extensions in Ptolemy
> (if you were to go this route).
>
> Currently in our project we have to use the Eclipse buddy policies. We
> use this in NOEM quite often because we have several bundles (plugins)
> which contain custom actors. We have one Ptolemy bundle that simply
> wraps the jars included with the Ptolemy install. Our bundles depend on
> that Ptolemy bundle because they extend NamedObj (or some other Ptolemy
> class), but the Ptolemy bundle must also depend on them so that the
> MoMLParser can find them. We accomplish this by adding
> Eclipse-RegisterBuddy: <ptolemy bundle id> in each bundles MANIFEST.MF.
> An Actor extension, and an extension-registry-aware MoMLParser would fix
> this and make Ptolemy II really plug and play actor-wise (this of course
> doesn't address the issue of having the actor show in Vergils tree). I
> could quickly code up an example of this if there was any interest.
>
> Brian
>
> On Mon, Sep 29, 2008 at 2:44 PM, Christopher Brooks
> <cxh at eecs.berkeley.edu <mailto:cxh at eecs.berkeley.edu>> wrote:
>
> We have been working on increasing the level of componentization of
> Ptolemy II. Hauke Fuhrmann is visiting us here at Berkelely. Hauke
> is interested in using Ptolemy II as the computational engine behind
> Keiler (http://www.informatik.uni-kiel.de/en/rtsys/kieler/).
>
> We've been experimenting with using Eclipse and OSGi to build bundles
> of the Ptolemy II code base.
> On Friday, I hacked up a script that creates the ~60 bundles needed to
> run the Ptiny version of Vergil. Ptiny is just the common domains
> like SDF, CT, DE, FSM etc. The bundles don't directly compile
> becase CT and FSM have a cross dependency, but the exercise prompted
> me to fix several issues.
>
>
> There are some open questions:
>
> 1) Is this the time to refactor the ptolemy.* packages to
> org.ptolemy.*?
>
> The MoMLFilter will likely handle much of the backward compatibility
> for running models.
>
> All of the code that calls ptolemy.* packages would need to be updated.
>
> All of the tcl tests would need to be updated. This would take a
> few days.
>
>
> 2) It is not clear to me what the proper level of granularity is for
> the bundles.
> - We could have a bundle per package. This seems like too fine a
> granularity - we will end up with hundreds of bundles.
>
> - We could have many bundles that include common functionality.
> This is the level of granularity for the 60 bundles that were created
> for Ptiny. For example, we have a ptolemy.actor.actorKore bundle that
> consists of the commonly used base actors in ptolemy (strings,
> conversions etc.) It makes no sense to have one bundle per package
> here, because if you use one class, then it is likely that classes
> from other nearby packages will be used.
>
> - We could use the bundles that were used for WebStart and izPack
> in Ptolemy II 7.0.1. <http://7.0.1.> I decided that these bundles
> were too coarse
> because they tended to include gui code with non-gui code. For example
> ptolemy/ptsupport.jar included the kernel, actor framemwork and actors.
> ptolemy/actor/actor.jar, which was part of ptsupport.actor included
> the actor framework and graphical and non-graphical actors.
> plotapplication included ptolemy/plot/compat.jar, which is support
> for pxgraph.
>
> 3) Right now, the interface and the implementation are in the same
> bundle. Eventually, we should move away from this. However, it
> seems like a very large step right now.
>
> _Christopher
>
> --
> 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
>
> _______________________________________________
> Ptolemy maillist - Ptolemy at chess.eecs.berkeley.edu
> <mailto:Ptolemy at chess.eecs.berkeley.edu>
> http://chess.eecs.berkeley.edu/ptolemy/listinfo/ptolemy
>
>
--
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
More information about the Kepler-dev
mailing list