Top Up Prev Next Bottom Contents Index Search

6.11 Changes since Ptolemy0.6

Ptolemy 0.7 introduces several changes related to porthole type resolution. Older versions used a much simpler ANYTYPE resolution algorithm, which essentially amounted to just pass 2 ("feed back") of the present method. That had the serious deficiency that it couldn't decide what to do with fork stars feeding inputs of multiple types. For example, a fork star receiving INT and outputting to INT and FLOAT portholes would lead to a type resolution error. In essence, the old code insisted on being able to push type conversions back across a fork, and would fail if it couldn't assign the same type to all the fork outputs. The new algorithm solves this problem by delaying type conversions until after a fork. Occasionally this will introduce some inefficiency. For example, if a fork receives INT and feeds two FLOATs, the new method leads to a type conversion being done separately on each fork output, whereas the old method would have generated only one conversion at the fork input. The improved ease of use of the new method is judged well worth this loss.

Formerly, the member ports of a multiporthole were always constrained to have the same resolved type. This is no longer true, since it gets in the way for polymorphic stars. But if a multiporthole is tied to another porthole via inheritTypeFrom, then each member porthole will still be constrained to match the type of that other porthole, at least in terms of preferred type.

Formerly, the HOF stars acted during the galaxy "setup" phase, in which each block within the galaxy receives its setup call. This proved inadequate because porthole type resolution is done during setup; by the time a HOF star acted, the types of the portholes connected to it would already have been resolved. For example, a HOFNop star formerly constrained all the particles passing through it to be of the same type, because the porthole resolver insisted on being able to choose a unique type for the HOFNop's output porthole, even though that porthole is just a dummy that won't even exist at runtime. In Ptolemy 0.7, a "preinitialize" phase has been added so that HOF stars can rewire the galaxy and remove themselves before any block setup or porthole type resolution occurs. The constraints on porthole types are then only those resulting from the rewired schematic.

Top Up Prev Next Bottom Contents Index Search
Copyright © 1990-1997, University of California. All rights reserved.