[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/ecoinformatics/pipermail/kepler-dev/attachments/20080602/8a743df0/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tests-ptjacl.txt
Url: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080602/8a743df0/attachment-0003.txt 


More information about the Kepler-dev mailing list