[PEAK] A few issues and suggestions
Sergey Schetinin
maluke at gmail.com
Wed Nov 5 19:58:15 EST 2008
On Wed, Nov 5, 2008 at 18:58, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 04:37 PM 11/5/2008 +0200, Sergey Schetinin wrote:
>>
>> One more issue:
>>
>> File "c:\files\checkouts\trellis\peak\events\stm.py", line 470, in
>> atomically
>> return super(Controller,self).atomically(self._process, func, args, kw)
>> File "c:\files\checkouts\trellis\peak\events\stm.py", line 186, in
>> atomically
>> self.cleanup(*sys.exc_info())
>> File "c:\files\checkouts\trellis\peak\events\stm.py", line 182, in
>> atomically
>> retval = func(*args, **kw)
>> File "c:\files\checkouts\trellis\peak\events\stm.py", line 486, in
>> _process
>> self.run_rule(listener)
>> File "c:\files\checkouts\trellis\peak\events\stm.py", line 364, in
>> run_rule
>> listener.run()
>> File "c:\files\checkouts\trellis\peak\events\trellis.py", line 559, in
>> run
>> raise AssertionError("This should never happen!", self)
>> AssertionError: ('This should never happen!', Cell(<bound method
>> VPanel._minh of <gui5.models.VPanel object at 0x00C8CBB0>>, 0))
>>
>>
>>
>> And the rule for which that happens looks like this:
>>
>> @maintain(initially=0)
>> def _minh(self):
>> prev = self._minh
>> if prev == 0 and self.live:
>> return self.height
>> return prev
>
> Unfortunately, the rule itself will give us no clue of what happened.
> Basically, it looks like for this to have happened, the cell had to have
> been assigned to between the time it was scheduled, and the time it was run.
> I suspect it could be triggered by a sequence like:
>
> cell A depends on B and C
> B depends on C
> C triggers a change in B
> B sets a value in A
>
> Probably, setting a value should cancel the scheduled rule if it doesn't
> need initialization. I suggest adding an "else: cancel(self)" to the "if
> self._needs_init:" block in Cell.set_value. If that makes the problem go
> away, the above hypotheses are probably correct.
I have to keep things going and get the product out of the door, so I
scrapped that code and went for a little different ruleset which seems
to be more bulletproof, so I can't immediately confirm if the
suggested fix works, sorry. However, I'm pretty sure that rule wasn't
being assigned at all, which is also confirmed by the fact that I have
successfully changed it to be a @compute without any other changes in
the code. Also, while I was trying to figure out what was wrong about
it, I tried returning something else in the last line: "return 10"
instead of "return prev". Strangely, with that the error went away,
which, combined with being a bit tired, convinced me I had no clue
what's going on and moved on to implement the component differently.
I will report if I will stumble into this issue again. Thanks for your help.
More information about the PEAK
mailing list