[kepler-dev] extending Ptolemy's moml filters
Daniel Crawl
crawl at sdsc.edu
Mon Jun 2 13:52:00 PDT 2008
Hi Christopher,
I am interested in creating these tests, but there appears
to be problems with ptjacl.jar. Attached is the output from
'make tests'. I believe the relevant messages are:
CLASSPATH="../../../..:/Users/crawl/k/ptII/vendors/jython/jython.jar:/Users/crawl/k/ptII/lib/ptjacl.jar"
"/usr/bin/java" -Xmx500M "-Dptolemy.ptII.dir=/Users/crawl/k/ptII"
tcl.lang.Shell alljtests.tcl
couldn't read file "alljtests.tcl"
CLASSPATH="../../../..:/Users/crawl/k/ptII/vendors/jython/jython.jar:/Users/crawl/k/ptII/lib/ptjacl.jar"
"/usr/bin/java" -Xmx500M "-Dptolemy.ptII.dir=/Users/crawl/k/ptII"
tcl.lang.Shell ../../../../util/testsuite/auto.tcl
couldn't read file "../../../../util/testsuite/auto.tcl"
What version of jacl does ptjacl.jar use? (Is the source for
ptjacl available?) If I replace ptjacl.jar with one I built
from jacl 1.4.1, the tests run, but several fail (see attachment).
This could be due to not having the Ptolemy localizations.
Have you used ptjacl on a Mac?
--dan
Christopher Brooks wrote:
> Hi Daniel,
>
> Thanks, your changes look good! Many thanks for following the Ptolemy
> coding style. The only change I made was that in
> PropertyClassChanges, the remove and put methods were not
> alphabetical. This could have been a pre-existing condition, I did
> not check.
>
> I considered adding a interface called MappedMoMLFilter, that would
> extend the MoMLFilter interface and add these methods:
>
> public static void clear();
> public void put(String className, HashMap portNameMap);
> public void remove(String className);
>
> However the filter seemed odd, since the put() methods are a putting a
> classname and HashMap, which seems very filter specific and might be
> hard to explain in documentation for the MappedMoMLFilter. If we get
> more MoMLFilters like PortNameChanges and PropertyClassChanges, then
> maybe we should add an interface.
>
> It looks like there are no tests for these new methods, see
> http://chess.eecs.berkeley.edu/ptexternal/nightly/coverage.html#ptolemy.moml.filter
> If you are feeling daring, you could add tests by adding
> moml/filter/test/PortNameChanges.tcl and PropertyClassChanges.tcl
> and creating Unit tests. If you do this, you would also need to
> edit moml/filter/test/makefile and add the new .tcl files.
>
> How I would test these is by looking at BackwardCompatibility.tcl and
> creating a small piece of MoML that gets filtered with and without
> put(), remove() and clear() called.
>
> Thanks again for adding these methods.
>
> _Christopher
>
>
> --------
>
>
> Developers,
>
> There are now Kepler-specific moml filters that rely on these
> new accessor methods. You will probably need to update your
> Ptolemy CVS.
>
> Thanks,
>
> --dan
>
>
> Christopher Brooks wrote:
> > Hi Daniel,
> >
> > I'd prefer to see accessor methods added instead of making the HashMap
> > public. The reason is that information hiding is, in general, good.
> >
> > RemoveGraphicalClasses has
> >
> > public static void clear()
> > public void remove(String className)
> > public void put(String className, String replacement)
> >
> > I've used these methods for some time and it has worked out.
> > I might be good to have an accessor method that would return
> > probably a copy of the HashMap, but I have not needed it.
> >
> > If you want, you could add similar methods to the filters in which you
> > are interested. It might make sense to add these methods to the
> > MoMLFilter baseclass. However, I don't think all MoMLFilters have
> > HashMaps, so it might not make sense. Though we could add an
> > interface that had these methods defined
> >
> > If you are willing to make the changes in the Ptolemy style, then I
> > could give you write access to the Ptolemy II tree and you could add
> > them. To do this, go to
> > http://chess.eecs.berkeley.edu/options
> > and request a CVS account.
> >
> > If you go the route of updating the Ptolemy II tree, then you could do
> > what Chad usually does, which is drop me a line before and after he
> > makes changes. This is somewhat optional, but it helps me keep track
> > of what is going in and I tend to sometimes review the changes and see
> > if there are other places similar changes should go.
> >
> > _Christopher
> >
> >
> > Hi Christopher,
> >
> > I would like to use Ptolemy's backwards-compatibility moml filters
> > to provide the same functionality for Kepler. However, the HashMaps
> > that contain the changes for each filter are private. What do you
> > think of making these protected or adding a public method to update
> > them?
> >
> > --dan
> > --------
> >
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> --------
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tests-jacl1.4.1.txt
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20080602/8a743df0/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tests-ptjacl.txt
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20080602/8a743df0/attachment-0005.txt>
More information about the Kepler-dev
mailing list