Project

General

Profile

Bug #5146

modifying and saving the composite sinewave actor fails

Added by Matt Jones almost 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Immediate
Category:
core
Target version:
Start date:
08/11/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5146

Description

Trying to make changes to the Sinewave actor that ships with Kepler and then trying to save that actor as a KAR file fails with an error, and the new copy of the actor in the new KAR file is not saved correctly (the output port is missing and not connected, and there are three new boxes labeled "kepler:frequency", "kepler:phase". and "kepler:output" that were not in the original actor.

To reproduce:

1) Drag sinewave to canvas, select, and open
2) Modify the Annotation text to say something different.
3) Close the sinewave actor
4) An error will pop up, with the text "Save changes to jar:file:/Applications/Kepler-2.0/Kepler.app/Kepler/ptolemy-8.0.0/target/ptolemy-8.0.jar!/ptolemy/actor/lib/Sinewave.xml"

5) Click 'Save', which brings up the file naming dialog, choose a new name for the KAR (Sinewave2.kar), and click 'Save' (you may also get prompted to select a semantic type)
6) Locate the new KAR in the components panel and drag the contained actor onto the canvas
7a) The actor will be missing an output port
7b) Opening the actor will show new boxes that didn't exist before, and the missing output port

Expected behavior:
There should be no error associated with saving on top of a jar file (this is a KAR file save). The actor should have an output port connected to the same relation as before, and the square boxes should not exist. The actor copy should be identical to the original on the canvas (except maybe the LSID should have changed).

See attached screenshot showing the misconfigured actor.

modified-sinewave-composite.png (27.6 KB) modified-sinewave-composite.png Matt Jones, 08/11/2010 05:53 PM

Related issues

Blocked by Kepler - Bug #5149: kar file saving problems.New08/16/2010

History

#1 Updated by Madhusudan Gujral almost 9 years ago

I played with Sinewave actor and noticed exactly same behavior as described. When I tried to change annotation, changes are reflected in the annotation component. However, they are not reflected on the canvas. Which indicated that annotation actor has changed in Kepler 2.x vs when the Sinewave actor was created. So I went ahead and created a composite actor with the same components as Sinewave actor using Kepler 2.x to see if the new composite actor behaves differently and what are the main differences in moml files. Results are following, the new composite actor behaves exactly the way it should. I can change the annotation and changes are reflected on the canvas. I can save it as a kar file and open without problem. Here are the main difference in he moml structure

(New Composite Actor)

<entity name="CompositeActor" class="org.kepler.moml.CompositeClassEntity">
<property name="_createdBy" class="ptolemy.kernel.attributes.VersionAttribute" value="8.1.devel">
</property>
<property name="Annotation" class="ptolemy.vergil.kernel.attributes.TextAttribute">
<property name="_hideName" class="ptolemy.data.expr.SingletonParameter" value="true">
</property>
........
</property>
<port name="frequency" class="ptolemy.actor.parameters.ParameterPort">
<property name="input"/>
<property name="dataType" value="unknown" class="ptolemy.kernel.util.StringAttribute"/>
<property name="isMultiport" value="false" class="ptolemy.kernel.util.StringAttribute"/>
<property name="_location" class="ptolemy.kernel.util.Location" value="{75.0, 115.0}">
</property>
</port>
......
</entity>

(Existing Sinewave actor)

<entity name="Sinewave" class="org.kepler.moml.CompositeClassEntity">
<property name="_createdBy" class="ptolemy.kernel.attributes.VersionAttribute" value="7.1.devel">
</property>

&lt;property name="annotation" class="ptolemy.kernel.util.Attribute"&gt;
&lt;property name="_hideName" class="ptolemy.kernel.util.SingletonAttribute"&gt;
&lt;/property&gt;
.......
&lt;/property&gt;
&lt;property name="frequency" class="ptolemy.actor.parameters.PortParameter" value="440.0"&gt;
&lt;property name="_hideName" class="ptolemy.kernel.util.SingletonAttribute"&gt;
&lt;/property&gt;
&lt;property name="_icon" class="ptolemy.vergil.icon.ValueIcon"&gt;
&lt;/property&gt;
&lt;property name="_iconDescription" class="ptolemy.kernel.util.SingletonConfigurableAttribute"&gt;
&lt;configure&gt;
&lt;svg&gt;
&lt;polyline points="-15,-15, 3,-5, -16,5" style="stroke:black"&gt;&lt;/polyline&gt;
&lt;polygon points="-22,-1, -22,4, -10,-5, -22,-14, -22,-9, -30,-9, -30, -1" style="fill:lightGray"&gt;&lt;/polygon&gt;
&lt;/svg&gt;
&lt;/configure&gt;
&lt;/property&gt;
&lt;property name="_smallIconDescription" class="ptolemy.kernel.util.SingletonConfigurableAttribute"&gt;
&lt;configure&gt;
&lt;svg&gt;
&lt;text x="20" style="font-size:14; font-family:SansSerif; fill:black" y="20"&gt;-P
&lt;/text&gt;
&lt;/svg&gt;
&lt;/configure&gt;
&lt;/property&gt;
&lt;property name="_editorFactory" class="ptolemy.vergil.toolbox.VisibleParameterEditorFactory"&gt;
&lt;/property&gt;
&lt;property name="_location" class="ptolemy.kernel.util.Location" value="[100.0, 120.0]"&gt;
&lt;/property&gt;
&lt;/property&gt;
..

</entity>

The existing Sinewave actor is using ptolemy kernel 7.1 and new Composite actor uses kernel 8.1. In addition, there are changes in the 'annotation' object, portparameters etc.

So what are our options:

1) Should we replace the existing actor with the new one with identical functionality? Will it cause conflict in older workflows where this actor is used?

2) Should we just replace the moml components in the existing actor with the new one?

3) Are should we employ some other approach?

#2 Updated by Aaron Aaron over 8 years ago

This is most likely an issue with the ActorMetadata class. I will look into it. First task may be to document how/what Kepler is doing to ptolemy moml when it gets converted into ActorMetadata objects. It's definitely a funky operation and may have broken from changes to ptolemy. I'll start by refreshing my memory on what is going on there and will attempt to document it here, https://kepler-project.org/developers/teams/framework/kepler-moml/actormetadata
Hopefully a solution that is backward compatible will present itself along the way.

#3 Updated by Aaron Aaron over 8 years ago

This is a tough one. As a first step I have added code to KeplerGraphTableau to correctly retrieve the LSID when opening an actor in a new window. Before it was just always assigning a new LSID to actors opened from a workflow canvas. Now if you right click on a Composite entity on the canvas (like Sinewave) and choose "Open Actor", then View LSID on the opened canvas it should match the LSID of the actor you opened.

Still have not figured out why the ports are getting messed up...

#4 Updated by Aaron Aaron over 8 years ago

OK, some progress on this bug. I've narrowed it down to being an issue with the Sinewave actor being a class definition. The proper way to deal with this has not come to me yet but the facts are this:

After dragging sinewave to the canvas, and opening the actor in a new window you can view the xml and see that it is a class definition that you are editing:

<class name="Sinewave" extends="ptolemy.actor.TypedCompositeActor">
<property name="_createdBy"
class="ptolemy.kernel.attributes.VersionAttribute"
value="8.1.devel">
</property>
....
</class>

If you then edit and save it to an archive, extract the xml and view it you will see that it gets saved as a CompositeClassEntity with a class attribute of TypedCompositeActor along with a bunch of links at the bottom

<entity name="Sinewave" class="org.kepler.moml.CompositeClassEntity">
<property name="entityId"
value="urn:lsid:kepler-project.org/ns/:513:243:2"
class="org.kepler.moml.NamedObjId" />
<property name="class"
value="ptolemy.actor.TypedCompositeActor"
class="ptolemy.kernel.util.StringAttribute">
<property name="id" value="null"
class="ptolemy.kernel.util.StringAttribute" />
</property>
....
<link port="output" relation="relation3" />
<link port="Ramp.output" relation="relation" />
<link port="TrigFunction.input" relation="relation4" />
<link port="TrigFunction.output" relation="relation3" />
<link port="Const.output" relation="relation2" />
<link port="AddSubtract.plus" relation="relation" />
<link port="AddSubtract.plus" relation="relation2" />
<link port="AddSubtract.output" relation="relation4" />
</entity>

Now if you change the ptolemy.actor.TypedCompositeActor to be ptolemy.actor.lib.Sinewave and delete all the links at the bottom then everything is hunky dory the next time you open the actor (don't forget to clean your cache after replacing the kar).

So from here I will try to modify the ActorMetadata object (which is used when saving CompositeEntities: see KARBuilder.handleInitiatorList()) to handle InstantiableNamedObjects that are class definitions. That should solve this problem but may have side effects elsewhere. If that doesn't work I will try kludging the save system to recognize class definitions and handle it at a that level. Yet another way to possibly handle this is to recognize class definitions when workflows are being opened in the KeplerGraphTableau.

to be continued...

#5 Updated by Aaron Aaron over 8 years ago

Kepler Revision 26595 reflects the changes I've made in an attempt to solve this bug. Because of how composite actors are opened by right clicking on them and choosing "Open Actor" I've used a new Attribute, TransientStringAttribute, to store the class information. This attribute is recognized now by the ActorMetadata class during save to properly output the right xml. Also as a part of this I discovered issues with the LSID not getting properly updated on class definitions that are opened this way, I've made some progress at trying to fix this but it is still an issue, I'll open a new bug for that.

Will leave this open for now until others can test it.

#6 Updated by Derik Barseghian over 8 years ago

i agreed to test this...

#7 Updated by Aaron Aaron over 8 years ago

Derik tested this too and it looks like the specific issue described here has been fixed. We noticed a few other funny things that will get their own bugs and be linked to this one in case there is some connection. Closing this bug.

#8 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 5146

Also available in: Atom PDF