[kepler-dev] Very strange issue with Kepler-1.0/Kepler-2.0 compatibility across actors
Christopher Brooks
cxh at eecs.berkeley.edu
Sat Feb 12 15:08:06 PST 2011
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
--
Christopher Brooks, PMP University of California
CHESS Executive Director US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670
More information about the Kepler-dev
mailing list