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 <[email protected]> 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 > [email protected] > 512-299-7218 > > > _______________________________________________ > Kepler-dev mailing list > [email protected] > http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev > _______________________________________________ Kepler-dev mailing list [email protected] http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
