Inaccurate/uncontrolled dependecy tree for function properties

[adammorrissirrommada]

[this is an old problem, but noting it here so we can come back to it at some point)

We have previously noted a problem in which a function property that depends on another plugin could inadvertently use an old property value. e.g. a.X = '@b.X'could set a.X to the value of b.X from the PREVIOUS frame if a.X is evaluated first in the current frame.

The dependencies between plugins cannot be circular (obviously) and must be evaluated (updated) in the correct order to ensure that all values are current and accurate as they flow through the dependecy tree.

This is impossible with our current architecture because:

1) The order in which plugins respond to an event (e.g. beforeFrame()) is undefined and not guaranteed by Matlab, so updating of values in a certain order is not certain.

2) Even if plugin order could be enforced, there could be mutual dependencies between two plugins that cannot be kept accurate and aligned through global updating of one plugin before moving onto the next. e.g.a.X = '@b.X' and b.Y = '@a.size'. There's no icrularity here, but you'd need to update b.X and a.size FIRST before updating a.X and b.Y

The str2fun() utility could in principle identify the plugin dependencies and work out whether there is a likely synchronization problem (and suggest a different plugin order to solve it), but problem #2 would remain.

[bartkrekelberg]

Truly fixing this is probably not possible, but making users aware of potential issues is. The simplest thing to do would be to create a dependency list (at the time of function construction) and show the dependencies to the user in some graphical format. ( e.g. a list like: fix.X -> gabor.X), together with the order of plugins?

[bartkrekelberg]

Since we removed Matlab events (which led to the uncertain order of evaluation) this problem is fixed.

All plugins update in the pluginOrder , so a user can figure out which plugin is updated first, and can rearrange the order to get the right sequence.

Of course, there is no right sequence for issue 2. This would be good to note in the documentation (?!) but not worth fixing with code (as it would require some kind of update order at the level of parameters that is well beyond the current code).

@adammorrissirrommada , you agree? Close the issue?

[adammorrissirrommada]

One possible protection would be to force people to specify c.order before run time, with some useful info about dependencies displayed if not, to make sure the issue is known....

if you don't think that has value, yep, close it.

[bartkrekelberg]

Merged protectCIC branch. Added warnings about pluginOrder. Closed.