lf-lang / lingua-franca

Intuitive concurrent programming in any language
https://www.lf-lang.org
Other
224 stars 60 forks source link

Show causality interface on reactors with hidden (collapsed) contents #208

Open lhstrh opened 3 years ago

lhstrh commented 3 years ago

It occurred to me that it could be useful to graphically illustrate on collapsed reactors what inputs each of its output depend on using dotted lines. It's not always obvious to the programmer which dependencies exist, and such a feature would allow the programmer to reason about the possibility of cycles without having to study the internals of the reactor.

a-sr commented 3 years ago

Sounds good, I will try to come up with a prototype for that.

Is there already a utility class that provides me these dependencies? Is the ReactionGraph that we used for cycle detection capable of this?

lhstrh commented 3 years ago

Great! A utility class to provide those particular dependencies isn't there yet, but I'll ping you once it's ready.

a-sr commented 3 years ago

I created a prototype for port dependencies in collapsed reactors. The result looks like this.

port-dependencies

If there are dependencies, the reactor label is moved to the top with a margin to ports, to make space for them. The dependencies are routed directly. This is more compact and actually the orthogonal routing that is used for other connections inside reactors does not work well and raises additional problems with the layout.

Does this match your expectations? Do you have any comments?

The implementation is committed but currently inactive since it only uses a mockup dependency analysis for testing. As soon as the utility class is ready I can activate it.

edwardalee commented 3 years ago

Very cool! This looks perfect to me...

Edward


Edward A. Lee EECS, UC Berkeley eal@eecs.berkeley.edu http://eecs.berkeley.edu/~eal

On Sep 10, 2020, at 6:00 AM, Alexander SR notifications@github.com wrote:

 I created a prototype for port dependencies in collapsed reactors. The result looks like this.

If there are dependencies, the reactor label is moved to the top with a margin to ports, to make space for them. The dependencies are routed directly. This is more compact and actually the orthogonal routing that is used for other connections inside reactors does not work well and raises additional problems with the layout.

Does this match your expectations? Do you have any comments?

The implementation is committed but currently inactive since it only uses a mockup dependency analysis for testing. As soon as the utility class is ready I can activate it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

edwardalee commented 1 month ago

The getProperty function with LINKED_INSTANCE maybe can be used to get a ReactorInstance from the KNode object. The ReactorInstance class has a getPaths function that might be useful for determining which outputs depend on which inputs.

soerendomroes commented 1 month ago

@edwardalee You can find the reactor by looking at the model element property of a KNode. See https://github.com/kieler/KLighD/blob/86f5b925a426298b0f7b0ae5ccd892e82b0b4a17/plugins/de.cau.cs.kieler.klighd/src/de/cau/cs/kieler/klighd/internal/util/KlighdInternalProperties.java#L50