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 <[email protected]> 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 <[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
