[PEAK] @action rules in Trellis SVN

[Phillip J. Eby]

At 05:12 PM 8/8/2007 -0700, Grant Baillie wrote:

>On 8 Aug, 2007, at 16:55, Phillip J. Eby wrote:
>
>>>The difference between this and what's covered by the existing
>>>doctest is that I assign a value in the constructor. So far as I can
>>>tell, this shouldn't change the dependency graph, but that appears
>>>not to be the case?
>>
>>Can you send me the changed code?
>
>Whoops ... I meant:
>
>The difference between this and what's covered by the existing
>doctest is that I use keywords to assign values when creating the
>ChangeableRectangle. So, there are no code changes; just the extra
>doctest I included.

Gotcha.  I've now identified and fixed the problem in SVN.

The specific issue was that the precise initialization process for 
new cells was ill-defined in the case where you set a value in a cell 
that also has a rule.  In previous versions, the rule would take 
precedence during the pulse where the value was set, and a subsequent 
pulse would track the initial assignment.

This week, I changed things such that the initial pulse would use the 
explicitly-set value, and the rule didn't get a say.

Both of these approaches ended up with the set value eventually 
"winning", but the rule not running is a bad thing, as you saw.

So, the new approach now is that a value assigned to a newly-created, 
not-yet-read cell with a rule will be treated as if the value had 
been "there already", and the rule will be run to set up 
dependencies.  The rule's value will then rule (no pun intended) in 
the current pulse.

The other thing that this highlights is that Component creation 
should really be an atomic process, ala @modifier, because otherwise 
the cells in the component are being initialized in semi-random 
order.  In theory, setting one cell could lead to its rule reading 
other cells whose initial value hasn't yet been set.  So I'm going to 
add some more tests to see if that can actually happen right now, and 
then add a fix.

Thanks for finding this.