[PEAK] Re: Trellis: Sensor.listening and iter_listeners()

[Sergey Schetinin]

I was working on this test and found some other strange behavior:

from peak.events import trellis

def connect(sensor):
    print 'connecting', sensor
    #trace
connector = trellis.Connector(connect=connect, disconnect=lambda
sensor, key: None)
sensor = trellis.Cell(connector)


val1 = trellis.Value(False, False)
val2 = trellis.Value(True, False)

def cell():
    print 'cell'
    val1.value
    sensor.value
    #print '!'
    val2.value = False
    @trellis.on_undo
    def undo():
        print 'UNDO'

cell = trellis.Cell(cell, None)


def outer_cell():
    print 'outer_cell'
    if val1.value and val2.value:
        cell.value
        return True

outer_cell = trellis.Cell(outer_cell, None)


outer_cell.value
print '-'
val1.value = True
#print cell._needs_init

print val2.value, outer_cell.value

This prints "False True", but outer_cell is only true if val2 is true,
this is wrong again.



On Thu, Nov 13, 2008 at 11:25, Sergey Schetinin <maluke at gmail.com> wrote:
> On Thu, Nov 13, 2008 at 02:27, Phillip J. Eby <pje at telecommunity.com> wrote:
>> At 08:33 PM 11/12/2008 +0200, Sergey Schetinin wrote:
>>>
>>> The problem is caused by initialization not being undo-logged, so when
>>> the rule is initialized, its _process_reads sets .next_listener of
>>> some Sensor, but the Link creation is not undo-logged. Later, it all
>>> gets rolled back, and the schedule(self.update_connection) vanishes
>>> from the ctrl.commit, but the .next_listener is not rolled back, so
>>> next time the dependency is recreated was_seen is True and the
>>> _set_listener decides there's no need to schedule update_connection,
>>> so it never runs. Removing one "if undo" condition in final part of
>>> the _process_reads fixes the problem. Trellis test suite never passes
>>> for me (hangs up on "testSequentialCalls
>>> (test_trellis.TestReactorEventLoop) ..."), so I'm not sure if this
>>> breaks anything else.
>>>
>>> Initialization is once again a culprit of a hard to detect bug. =)
>>
>> Stranger still, I can't figure out what this suppression of undo-logging was
>> added to fix.  Removing both "if undo" conditions doesn't break any current
>> tests.  I don't see why it would be useful to not roll back such linkages,
>> since reference freshness is handled by not dropping links.
>>
>> I think this might have been another instance of being led astray by false
>> analogy, that in initialization we want to pretend things happened in a
>> previous transaction.  But the actual approach used here doesn't make any
>> sense.
>>
>> Very shortly after the "if undo"s were added, I made a fairly significant
>> change to how rule rollback was handled, and I dropped some code from a
>> newly added test that was probably driving the need for the if-undos.
>
> It would make sense if the _need_init changes weren't rolled back, but
> I see no other reason.
>
>> However, it'd still be nice to have something in the tests that covered the
>> undo-of-initialization case, and one to cover the sensor bug in particular.
>
> I can write one for this case, but the only part I'm not sure about is
> how to reliably force rules to roll back?
>



-- 
Best Regards,
Sergey Schetinin

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