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

[Sergey Schetinin]

So here are the tests:

1. Link rollback

def connect(sensor):
    print 'connecting', sensor

connector = trellis.Connector(connect=connect, disconnect=lambda
sensor, key: None)
sensor = trellis.Cell(connector)

class SensorInitUndoTest(trellis.Component):
    trellis.attrs(v1=False)

    @trellis.maintain
    def a(self):
        if self.v1:
            return _Comp()

    @trellis.maintain
    def b(self):
        if self.v1:
            self.a

class _Comp(trellis.Component):
    @trellis.maintain
    def c(self):
        sensor.value


comp = SensorInitUndoTest()
comp.__cells__['a'].layer =  comp.__cells__['b'].layer + 1
comp.v1 = True
assert sensor.next_listener() is comp.a.__cells__['c']
assert sensor.listening is not trellis.NOT_GIVEN






2. Infinite retry loop. I mentioned this case before, but in this test
there's actually a circularity which is not detected.


class TestInfiniteLoop(trellis.Component):
    trellis.attrs(v1=False, v2=False)

    @trellis.maintain
    def a(self):
        print 'A'
        if self.v1:
            self.v2
            return True

    @trellis.maintain
    def b(self):
        print 'B'
        if self.v1:
            self.a
            self.v2 = True

comp = TestInfiniteLoop()
comp.v1 = True
# the circularity exists but is not detected (infinite retry loop)





3. CircularityError when there's no actual circularity. The order
rules should be evaluated is different based on v1, but there's no
circularity. Not an issue for me, but still an interesting case.

class TestFalseCircularity(trellis.Component):
    trellis.attrs(v1=False, v2=False)

    @trellis.maintain
    def a(self):
        if self.v1:
            self.v2
            return True

    @trellis.maintain
    def b(self):
        if self.v1:
            self.v2 = True
        else:
            self.a

comp = TestFalseCircularity()
comp.v1 = True
# there's no actual circularity, but the correct order can't be found
(CircularityError)




I was thinking about the odd case from my previous email and ISTM that
it's one of the cases when "read until write" doesn't really always
work (which you mentioned before). It's also an illustration why I
think that optional non-readonly rules are dangerous. We can't
prohibit them entirely because it would also make rules like
"make(ComponentSubclass)" invalid, but it would help if they were
better controlled which reminds me of one of the requirements I
considered necessary for side-txns. If rules during initializion were
denied write access to rules that were already read in this
transaction it would make rule initialization much safer, I think.
Something like ctrl.all_reads containing an aggregate of all
ctrl.reads for current transaction so far which would be checked to
not intersect with .writes for initializing rules. Or, probably, if
initialization schedules a rule which has already run (and not for
initialization) it should be considered an error, not only to fix the
inconsistency in that test, but also because a it's awful design when
optional rules mess with other cells that aren't optional and it
should be discouraged IMO.

Also, it might be a good idea to have two modes for trellis operation:
production with fewer checks and a debugging mode which would probably
be a bit slower but would check things much more rigorously, maybe
even collect some profiling stats etc. Debugging with Trellis can be
quite hard, so maybe something of this kind would help a bit.