Re: A few issues and suggestions

After thinking about it a bit more, I think the guess about "schedule
then assign" scenario might be close, because IIRC the issue with
rollback setting .next_listener of a constant surfaced when tinkering
with the same rules. I would imagine there was in fact an assignment
to that rule somewhere, but when I was using @compute for it, it
happened early enough and converted it into a constant, which would
result in that other issue instead. It is fairly non-trivial though,
and I didn't have much luck stripping it down to a test case.

On Thu, Nov 6, 2008 at 05:03, Sergey Schetinin <[email protected]> wrote:
> I brough that code back in to test. This time it results in the
> infinite loop I described earlier. I did add the "else: cancel(self)"
> block anyway, to see what happens. And it broke the loop, but the
> results didn't seem right either -- it apparently have broken a lot of
> rule dependency chains. I mean, even without that _minh rule, the
> addition of that else clause messes things up completely as well.
>
> On Wed, Nov 5, 2008 at 18:58, Phillip J. Eby <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> 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.
>>
>>
>
>
>
> --
> Best Regards,
> Sergey Schetinin
>
> http://s3bk.com/ -- S3 Backup
> http://word-to-html.com/ -- Word to HTML Converter
>



-- 
Best Regards,
Sergey Schetinin

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