Hi Norbert,
I have been examining your problem. Yes, the Ptolemy workflow works
for me under Kepler and the Kepler version does not. But how was the
Kepler version built? I can save the Ptolemy wf in Kepler and the port
types are not set (i.e. the wf works). There is no NondeterministicMerge
actor in the Kepler actor list, so I had to use the menu
'Tools/Instantiate Component' to get it to appear in Kepler. Still no
problem with the port types!
Was the NondeterministicMerge actor somehow added to Kepler's actor
list?
Dan Higgins
-----
Norbert Podhorszki wrote:
Hi,
,
We have hit a type problem in Kepler with Bruce while playing with the
NondeterministicMerge actor and then found an interesting and annoying
difference between the type checking in Kepler and Ptolemy. Now we
know how to solve the problem by specifying the types manually but
still we wonder if this is a bug or just a side-effect how Kepler
stores actors in its xml.
The model
=========
In the attached examples, there is a simple pipeline
Record Assembler --- Nondet.Merge --- Record Disassembler
i.e. we want to push record tokens through the model.
The Ptolemy version (built under Ptolemy) works as expected, even
under Kepler. The Kepler version, however, does not run because we get
an error from the type checker:
ptolemy.kernel.util.InternalErrorException: Type resolution failed
because
of an error during type inference
in .NondetMerge_TypeError_Kepler
Because:
Invalid type for input port
in .NondetMerge_TypeError_Kepler.Record Disassembler
The difference
==============
Replacing the NondeterministicMerge entity manually in the Kepler
workflow xml with the entity in the Ptolemy model (see
NondetMerge_TypeError_KP.xml), the error disappears.
The difference between the two entities is that while Ptolemy only
declares the class
<entity name="NondeterministicMerge"
class="ptolemy.domains.pn.kernel.NondeterministicMerge">
<property name="_location"
class="ptolemy.kernel.util.Location" value="[350.0, 160.0]">
</property>
</entity>
Kepler enumerates the ports and their types as well, which, in the
case of NondeterministicMerge are 'general'.
<entity name="NondeterministicMerge"
class="ptolemy.domains.pn.kernel.NondeterministicMerge">
<property name="_location"
class="ptolemy.kernel.util.Location" value="[350.0, 160.0]">
</property>
<port name="input" class="ptolemy.actor.TypedIOPort">
<property name="input"/>
<property name="multiport"/>
<property name="_type" class="ptolemy.actor.TypeAttribute"
value="general">
</property>
</port>
<port name="output" class="ptolemy.actor.TypedIOPort">
<property name="output"/>
<property name="_type" class="ptolemy.actor.TypeAttribute"
value="general">
</property>
</port>
</entity>
The manual solution
===================
AFAIK, the type checker then will not climb down from the top
'general' to find that always just RecordType tokens will be emitted.
If we set the types of the input and output ports of the actor to our
specific record type in the GUI, then it works again.
Then why do we complain?
========================
First of all we wonder if this is necessary to be this way in Kepler.
Second, how many actors may be there that can bring such a surprise to
the developer.
Third, no one should wonder that the beginner developer is completely
lost since he does not understand the Ptolemy error message, and
actually he made nothing wrong, so after crawling through the hopeless
route down to hell, desperately looks for advise from an experienced
developer, who also has no idea. Lots of trials, small test examples
and changing from Kepler to Ptolemy for counter-testing reveals what's
wrong (since the error message does not reveal it) and finally the
solution come. Since the beginner developer committed nothing wrong,
it would be good not to get into such situation.
Oh and yes, I know that he should not go with the nondet merge at all
and I will help him to create a DDF solution for his problem.
Eventually. ;-)
Best regards
Norbert
Norbert Podhorszki
------------------------------------
University of California, Davis
Department of Computer Science
1 Shields Ave, 2236 Kemper Hall
Davis, CA 95616
(530) 752-5076
[EMAIL PROTECTED]
----------------------------------
------------------------------------------------------------------------
_______________________________________________
Kepler-dev mailing list
[EMAIL PROTECTED]
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
