Re: Trellis on_commit and Performers

>> I think this does what you want.  But it's a bit of a hack, though, because
>> the assumption underlying receive() is that it is being called from the
>> external side, not the trellis side of things.
>>
>> This means that if you write ``value`` during the same transaction as
>> anything that causes ``_value`` to be recalculated, then the recalculated
>> value will take precedence over the written value...  I think.  IOW, any
>> rules that depend on the value will get re-run, and the explicitly set value
>> will be ignored in this transaction (but set in wx post-transaction).
>
> This might be true for that order, but if the _value rule is
> calculated first, then set, then it results in InputConflict.
> For example, first, we create the wrapper for some panel and set
> layout rules for it, so it reads the actual wx size. Then we add it to
> another panel which also has a layout rule that changes the size of
> this first panel. That triggers the .receive which in turn calls
> Value.set_value which does the following check:
>
>        if value!=self._value:
>            if self._set_by is not ctrl.current_listener:
>                # already set by someone else
>                raise InputConflict(self._value, value, self._set_by,
> ctrl.current_listener) # XXX
>
> It fails, because _set_by is the size rule itself and current_listener
> is the layout rule for the parent panel.

By the way, exactly the same happens if the rule is a maintain (or
just a Cell(rule, None)), the .receive would be an assignment then,
but the cell is already set by the calculation in the rule itself, so
it's a conflict. It seems that I need a way to set a cell to new value
overriding whatever its rule had computed and rerunning dependencies
instead of raising an exception. One way to accomplish that, would be
to have one more layer, the top layer would check one cell (that is
set when writing) and if it contains some marker then return the value
of the cell we have now, this would effectively implement the
override, but actually it's exactly what I had with .pending_write,
and that didn't work well.

The other order (when we first set it to new value, then it's
recalculated due to an event) could happen if we write the size to wx
in the same transaction. Otherwise we write it in the wx
post-transaction (SetSize immediately calls the event handler) which
triggers the event sensor and forces the rule to recalculate, which is
ok as long as the SetSize for certain object is only called once in
that post-transaction, otherwise it would result in multiple .receive
calls for the same sensor and that's a conflict. This shouldn't happen
as long as the transaction that scheduled the calls worked correctly.
However, I wonder if there are cases when a different wx change would
send the same event. Well, there's hoping it would not happen..


-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter