[kepler-dev] Re: [SDM-SPA] RFC new directory structure
ludaesch at sdsc.edu
Thu Mar 18 07:58:44 PST 2004
Thanks very much for your insightful mail from a Ptolemy perspective
and preview of features that are coming in the next release.
I'm cross-posting to SDM-DEV for now, but encourage those who are on
SDM-DEV but not Kepler-dev to subscribe to the latter to automatically
get such info in the future (provided of course they need to know
what's going on in Kepler/SPA).
Here is the URL:
>>>>> "EAL" == Edward A Lee <eal at eecs.berkeley.edu> writes:
EAL> At 11:54 PM 3/17/2004 -0800, Efrat Jaeger wrote:
>> Hi all,
>> While making all these changes, I'd like to suggest another "rule", to avoid
>> overwriting Ptolemy files (if possible?). Now that we are wiser and have a
>> better understanding of the system, the exp directory can possibly be
>> disposed by extending the Ptolemy type classes instead of overwriting them.
>> Matt, Can the configuration file extend the Ptolemy one? Otherwise once
>> Kepler is loaded, Ptolemy can no longer be loaded.
EAL> I would like to second this...
EAL> There is a huge amount happening currently in the Ptolemy development
EAL> tree, and if Kepler has overwritten files, it will be a great deal
EAL> of effort to integrate Kepler with a new version of Ptolemy...
EAL> Some of the things that are happening that are pertinent
EAL> - classes and inheritance at the block diagram level
EAL> - much smaller XML files
EAL> - wireless domain
EAL> - icon editor (and animated icons)
EAL> - higher order components
EAL> - lifecycle management components
EAL> - decorative elements in block diagrams (boxes, etc.)
EAL> - "expert" mode parameter editing
EAL> We are hoping to package these as a release (4.0) in April/May...
EAL> Hopefully, most changes can be made by subclassing. When you
EAL> need changes to the base class, please send me a diff and I'll
EAL> see whether we can get them incorporated in the current version
EAL> of the base class (e.g., change a private variable to protected).
EAL> Please do not copy a Ptolemy class into a new package and modify
EAL> it, if at all possible... This creates a maintenance nightmare
EAL> (we already have this problem with some of the classes that
EAL> Thales contributed, and will likely eventually abandon these
EAL> classes because of that ... unless we can find the bandwidth
EAL> to rewrite them to use subclassing instead of copying).
EAL> Edward A. Lee, Professor
EAL> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
EAL> phone: 510-642-0455, fax: 510-642-2739
EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
EAL> kepler-dev mailing list
EAL> kepler-dev at ecoinformatics.org
More information about the Kepler-dev