[kepler-dev] Changes in Type System Between Kepler 2.3 and 2.4

[Marten Lohstroh]

Scott,

This has been solved in the Ptolemy development tree.
TypedAtomicActor._defaultTypeConstraints() now no longer sets up type
constraints between a ParameterPort and a TypedIOPort. This prevents
parameters from inadvertently pushing up the types of output ports as
happened in the example you provided. Thanks for pointing this out!

Marten

--
Marten Lohstroh, Msc. | Associate Specialist
University of California | 545Q Cory Hall
Berkeley, CA 94720  | +1 510 282 9135


On Thu, Jan 23, 2014 at 2:15 AM, Marten Lohstroh
<marten at eecs.berkeley.edu> wrote:
> Scott,
> Excuse me for the late reply, I had overlooked this one.
> The problem is that somehow there exists a type constraint between the
> parameter Repeat.numberOfTimes and Repeat.output; and since the join
> of Int and Obj is General, a type conflict emerges. The mentioned type
> constraint, however, should not exist---that is, even without
> overriding _defaultTypeConstraints(). I need to do some deeper digging
> to solve this... I will get back to you asap.
> Marten
>
> --
> Marten Lohstroh, Msc. | Associate Specialist
> University of California | 545Q Cory Hall
> Berkeley, CA 94720  | +1 510 282 9135
>
>
> On Wed, Jan 8, 2014 at 9:46 AM, Scott Zimmer <szimmer at optensity.com> wrote:
>> I've attached a simple model that worked in Kepler 2.3 and does not work in
>> 2.4 or the trunk. The stack trace of the error is below. I can make the
>> model work by either
>> 1.  inserting a constraint into the constructor for
>> ptolemy.domains.sdf.lib.Repeat as follows: output.setTypeAtLeast(input)
>> or
>> 2.  configuring the output port of the Repeat actor and setting its type to
>> object.
>>
>> I am not really interested in just fixing this workflow, I am interested in
>> understanding what changed between Kepler 2.3 and 2.4 that introduces the
>> exception and whether this is expected behavior.  It seems to me that the
>> _defaultTypeConstraints() for the TypedAtomicActor is still setting an
>> inequality constraint for any TypedAtomicActors ports combinations where
>> neither the input nor the output has its type set.  This inequality
>> constraint appears to require the output type to be greater than or equal to
>> the types of any input ports as long as neither port type has been set.
>>
>> I don't see how the output port of repeat ever gets set to general. For what
>> it's worth, I don't see the same problems if I pass another type through the
>> Repeat actor.  The output type is set to the type of the input and the
>> workflow executes correctly.  I only see the problem when I pass an object
>> token through the Repeat actor.   I'd appreciate any insight you can
>> provide.
>>
>> Thanks,
>> Scott
>>
>> ptolemy.actor.TypeConflictException: Type conflicts occurred in
>> .RepeatTypeCheck on the following inequalities:
>>   (port .RepeatTypeCheck.Repeat.output: general) <= (port
>> .RepeatTypeCheck.Image Display.input: object(null))
>>
>>     at
>> ptolemy.actor.TypedCompositeActor.resolveTypes(TypedCompositeActor.java:401)
>>     at ptolemy.actor.Manager.resolveTypes(Manager.java:1151)
>>     at ptolemy.actor.Manager.preinitializeAndResolveTypes(Manager.java:987)
>>     at ptolemy.actor.Manager.initialize(Manager.java:661)
>>     at ptolemy.actor.Manager.execute(Manager.java:340)
>>     at ptolemy.actor.Manager.run(Manager.java:1202)
>>     at ptolemy.actor.Manager$PtolemyRunThread.run(Manager.java:1760)
>>
>> --
>> Scott Zimmer
>> szimmer at optensity.com
>> 512-299-7218
>>
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>