[kepler-dev] Very strange issue with Kepler-1.0/Kepler-2.0 compatibility across actors

Michal Owsiak michalo at man.poznan.pl
Sat Feb 12 15:17:04 PST 2011


Hello Chris,

thanks for your detailed explanation.

However, there is one thing that bothers me. If you take a look at the 
actor: Image Reader -> right click -> Open actor (using Kepler-2.0), you 
will see that this actor uses:


...
import ptolemy.data.type.BaseType;
import ptolemy.kernel.CompositeEntity;
import ptolemy.kernel.util.Attribute;
import ptolemy.kernel.util.IllegalActionException;
import ptolemy.kernel.util.NameDuplicationException;
...

     public ImageReader(CompositeEntity container, String name)
             throws IllegalActionException, NameDuplicationException {
         super(container, name);

         // Set the type of the output port.
         //output.setMultiport(true);
         output.setTypeEquals(BaseType.OBJECT);

         fileOrURL = new FileParameter(this, "fileOrURL");
     }


In this case, this actor uses the same package and the same type: 
BaseType.OBJECT

However, it doesn't rise the exception during initialization. And this 
is really tricky.

Cheers

Michal



> Hi Michal,
>
> Ah. I guess we lost backward compatibility around Object Tokens
> between Kepler-1.0 and Kepler-2.0. Kepler-1.0 corresponds with
> Ptolemy II 7.0 (I think) and Kepler-2.0 corresponds with Ptolemy II 8.0.
>
> Diffing BaseType.java yields:
>
> ptII at bennett 2% diff ptII{7.0,8.0}/ptII/ptolemy/data/type/BaseType.java
> diff ptII{7.0,8.0}/ptII/ptolemy/data/type/BaseType.java
> 3c3
> < Copyright (c) 1997-2008 The Regents of the University of California.
> ---
>  > Copyright (c) 1997-2010 The Regents of the University of California.
> 34a35
>  > import ptolemy.data.ActorToken;
> 44d44
> < import ptolemy.data.ObjectToken;
> 55c55
> <
> //////////////////////////////////////////////////////////////////////////
> ---
>  > ///////////////////////////////////////////////////////////////////
> 63c63
> < @version $Id: BaseType.java,v 1.109 2008/01/24 00:34:02 cxh Exp $
> ---
>  > @version $Id: BaseType.java 57040 2010-01-27 20:52:32Z cxh $
> 122c122
> < /** Return an instance of this class that corresponds to tokens
> ---
>  > /** Return an instance of Type of that corresponds to tokens
> 335c335
> < /** The bottom element of the data type lattice. */
> ---
>  > /** The bottom element of the array type lattice. */
> 555,569d554
> < public static class ObjectType extends BaseType {
> < private ObjectType() {
> < super(ObjectToken.class, "Object");
> < }
> <
> < public Token convert(Token t) throws IllegalActionException {
> < return ObjectToken.convert(t);
> < }
> <
> < public int getTypeHash() {
> < return 8;
> < }
> < }
> <
> < /** The object data type. */
> 571a557,559
>  > /** The actor data type. */
>  > public static final Type ACTOR = ActorToken.TYPE;
>  >
> 731a720,738
>  > /** Setting the type of something to RECORD allows it to take
>  > * on a value that is any record with any fields. This is because
>  > * a lossless conversion any such record to an empty record just
>  > * returns the original record. So to force something to have a
>  > * record type without specifying what fields it should have, do
>  > * <pre>
>  > * something.setTypeEquals(BaseType.RECORD);
>  > * </pre>
>  > * To allow the type to resolve to a specific record type (with
>  > * particular fields), do instead
>  > * <pre>
>  > * something.setTypeAtMost(BaseType.RECORD);
>  > * </pre>
>  > * This will work for example to require a parameter to have a record
>  > * value, but to allow its type to resolve to the specific record
>  > * specified.
>  > */
>  > static public final RecordType RECORD = RecordType.EMPTY_RECORD;
>  >
>
>
> So, BaseType in Kepler-1.0 has ObjectType declared in the BaseType.java
> and BaseType in Kepler-2.0 does not. Apparently, this makes a difference.
>
> Running javap shows these differences:
>
> ptII at bennett 3% javap -classpath ptII7.0/ptII/ptolemy/ptsupport.jar
> ptolemy.data.type.BaseType >& /tmp/BaseType7.0
> ptII at bennett 4% javap -classpath ptII8.0/ptII/ptolemy/ptsupport.jar
> ptolemy.data.type.BaseType >& /tmp/BaseType8.0
> ptII at bennett 5% diff /tmp/BaseType7.0 /tmp/BaseType8.0
> diff /tmp/BaseType7.0 /tmp/BaseType8.0
> 22c22,23
> < public static final ptolemy.data.type.BaseType$ObjectType OBJECT;
> ---
>  > public static final ptolemy.data.type.ObjectType OBJECT;
>  > public static final ptolemy.data.type.Type ACTOR;
> 30a32
>  > public static final ptolemy.data.type.RecordType RECORD;
> ptII at bennett 6%
>
>
>
> These changes to BaseType.java are of interest, especially r49121
>
> r49220 | tfeng | 2008-04-11 16:40:13 -0700 (Fri, 11 Apr 2008) | 2 lines
>
> Small bugfixes in the expression language, and make
> object(NamedObj).getAttribute(name) return an ObjectToken instead of the
> value of the attribute. However, object(NamedObj).name still returns the
> value, not the ObjectToken, for backward compatibility.
>
> ------------------------------------------------------------------------
> r49121 | tfeng | 2008-03-30 15:01:31 -0700 (Sun, 30 Mar 2008) | 2 lines
>
> ObjectType moved out of the BaseType class, though BaseType.OBJECT still
> exists for backward compatibility. ObjectTypes now form a lattice them
> selves, with a top element denoting an ObjectType that accepts any
> ObjectToken.
>
> ------------------------------------------------------------------------
> r49054 | tfeng | 2008-03-29 17:44:35 -0700 (Sat, 29 Mar 2008) | 2 lines
>
> The object type is extended with a field that indicates the Java class
> of the value. ObjectToken is changed accordingly, so that when getType()
> is called, an ObjectType with the correct Java class is returned, not
> the universal type (BaseType.OBJECT). In the expression language, a
> function "object(...)" is added to return the specific object type. For
> example, object("ptolemy.kernel.Port") returns an ObjectType that is
> compatible with any ObjectToken that has a port as its value.
>
>
>
> I don't have a good solution for this issue. You could try putting
> the 7.0 code back in and have ptolemy.data.type.BaseType.ObjectToken be a
> wrapper for ptolemy.data.type.ObjectToken.
>
> This is not good that we've lost backward compatibility, this will affect
> actors that have custom tokens like the actor.lib.image actors.
>
> _Christopher
>
>
> On 2/12/11 12:44 PM, Michal Owsiak wrote:
>> I have to maintain two version of the Kepler at the same time.
>>
>> Compiling part of my project only once is quite convenient, because I
>> can use it as a library, and have it the same in both versions of Kepler.
>>
>> However, recently, I have encountered this strange issue with missing
>> OBJECT field.
>>
>> I will take a look at this issue once again and consider separate
>> compilation of codes.
>>
>> Cheers
>>
>> Michal
>>
>>> Well, I can see compiling it with 1.0 and then using the resulting
>>> class file in 2.0 might be problematic. Is there a reason you're not
>>> compiling this with 2.0? I tried it out under 2.0 (the development
>>> branch, so it was compiled under 2.0 as well) and it worked.
>>>
>>> (Forgot to cc kepler-dev at first)
>>>
>>> 2011/2/11 Michal Owsiak<michal.owsiak at man.poznan.pl>:
>>>> Hello Sean,
>>>>
>>>> I have even simplified the use-case.
>>>>
>>>> Please find reduced version of the actor. It doesn't require
>>>> anything apart
>>>> from ptolemy classes.
>>>>
>>>> I am not sure whether this is a factor here, but. If you compile
>>>> this class
>>>> using Kepler-1.0.0 sources, and you will try to import it into
>>>> Kepler-2.0
>>>> you should get the error related to missing OBJECT field.
>>>>
>>>> import java.awt.Image;
>>>> import java.net.MalformedURLException;
>>>> import java.net.URL;
>>>>
>>>> import javax.swing.ImageIcon;
>>>>
>>>> import ptolemy.actor.TypedIOPort;
>>>> import ptolemy.actor.lib.Source;
>>>> import ptolemy.data.AWTImageToken;
>>>> import ptolemy.data.StringToken;
>>>> import ptolemy.kernel.CompositeEntity;
>>>> import ptolemy.kernel.util.IllegalActionException;
>>>> import ptolemy.kernel.util.NameDuplicationException;
>>>>
>>>> public class ReadImage extends Source {
>>>> public ReadImage(CompositeEntity container, String name)
>>>> throws IllegalActionException, NameDuplicationException {
>>>> super(container, name);
>>>>
>>>> imagePort = new TypedIOPort(this, "imageFile", true, false);
>>>> imagePort.setTypeEquals(ptolemy.data.type.BaseType.STRING);
>>>>
>>>> output.setTypeEquals(ptolemy.data.type.BaseType.OBJECT);
>>>>
>>>> }
>>>> public static final String REVISION = "$Revision: 2289 $";
>>>>
>>>> public TypedIOPort imagePort;
>>>>
>>>> public void fire() throws IllegalActionException {
>>>> super.fire();
>>>>
>>>> String imageString = null;
>>>> if(imagePort.getWidth() != 0&& imagePort.hasToken(0)) {
>>>> StringToken imagePortToken = (StringToken) imagePort.get(0);
>>>> imageString = imagePortToken.stringValue();
>>>> }
>>>>
>>>> if (imageString == null) {
>>>> throw new IllegalActionException("sourceURL was null");
>>>> } else {
>>>> try {
>>>> _url = new URL(imageString);
>>>>
>>>> _fileRoot = _url.getFile();
>>>> _image = new ImageIcon(_fileRoot).getImage();
>>>>
>>>> if ((_image.getWidth(null) == -1)&& (_image.getHeight(null) == -1))
>>>> {
>>>> throw new IllegalActionException("incorrect image");
>>>> } else {
>>>> output.broadcast(new AWTImageToken(_image));
>>>> }
>>>>
>>>> } catch (MalformedURLException e) {
>>>> throw new IllegalActionException("sourceURL is incorrect");
>>>> }
>>>> }
>>>> }
>>>>
>>>> private String _fileRoot;
>>>> private Image _image;
>>>> private URL _url;
>>>> }
>>>>
>>>>
>>>>> I'd be glad to help. That's quite a strange error. Could I get a copy
>>>>> of your Constants class so I can try to reproduce it? If you have a
>>>>> sample workflow that uses the ImageReaderPort that would be helpful as
>>>>> well.
>>>>>
>>>>> - Sean
>>>>>
>>>>> 2011/2/11 Michal Owsiak<michal.owsiak at man.poznan.pl>:
>>>>>>
>>>>>> java.lang.NoSuchFieldError: OBJECT
>>>>>> at
>>>>>>
>>>>>> pl.psnc.kepler.common.actor.ImageReaderPort.<init>(ImageReaderPort.java:91)
>>>>>>
>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>>>>> Method)
>>>>>> at
>>>>>>
>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>>>>>>
>>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>>>>>> at ptolemy.moml.MoMLParser._createInstance(MoMLParser.java:4243)
>>>>>> at ptolemy.moml.MoMLParser._createEntity(MoMLParser.java:4043)
>>>>>> at ptolemy.moml.MoMLParser.startElement(MoMLParser.java:2493)
>>>>>> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:921)
>>>>>> at com.microstar.xml.XmlParser.parseContent(XmlParser.java:1104)
>>>>>> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:924)
>>>>>> at com.microstar.xml.XmlParser.parseContent(XmlParser.java:1104)
>>>>>> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:924)
>>>>>> at com.microstar.xml.XmlParser.parseContent(XmlParser.java:1104)
>>>>>> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:924)
>>>>>> at com.microstar.xml.XmlParser.parseDocument(XmlParser.java:481)
>>>>>> at com.microstar.xml.XmlParser.doParse(XmlParser.java:159)
>>>>>> at com.microstar.xml.XmlParser.parse(XmlParser.java:132)
>>>>>> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1418)
>>>>>> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1354)
>>>>>> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1298)
>>>>>> at
>>>>>>
>>>>>> ptolemy.actor.gui.PtolemyEffigy$Factory.createEffigy(PtolemyEffigy.java:420)
>>>>>>
>>>>>> at
>>>>>> ptolemy.actor.gui.EffigyFactory.createEffigy(EffigyFactory.java:233)
>>>>>> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:823)
>>>>>> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:783)
>>>>>> at
>>>>>> org.kepler.gui.kar.OpenArchiveAction._read(OpenArchiveAction.java:328)
>>>>>>
>>>>>> at
>>>>>> org.kepler.gui.kar.OpenArchiveAction._open(OpenArchiveAction.java:257)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> org.kepler.gui.kar.OpenArchiveAction.actionPerformed(OpenArchiveAction.java:190)
>>>>>>
>>>>>> at
>>>>>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2028)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2351)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
>>>>>>
>>>>>> at
>>>>>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
>>>>>>
>>>>>> at javax.swing.AbstractButton.doClick(AbstractButton.java:389)
>>>>>> at
>>>>>> com.apple.laf.ScreenMenuItem.actionPerformed(ScreenMenuItem.java:95)
>>>>>> at java.awt.MenuItem.processActionEvent(MenuItem.java:627)
>>>>>> at java.awt.MenuItem.processEvent(MenuItem.java:586)
>>>>>> at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:317)
>>>>>> at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:305)
>>>>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:638)
>>>>>> at
>>>>>>
>>>>>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
>>>>>>
>>>>>> at
>>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
>>>>>> at
>>>>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
>>>>>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Michal Owsiak<michal.owsiak at man.poznan.pl>
>>>>
>>>> Institute of Bioorganic Chemistry PAS
>>>> Poznan Supercomputing and Networking Center
>>>> Noskowskiego 12/14, 61-704 Poznan, POLAND
>>>>
>>>> http://www.man.poznan.pl
>>>>
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at kepler-project.org
>>> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>



More information about the Kepler-dev mailing list