[PEAK] A few issues and suggestions

[Sergey Schetinin]

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





On Wed, Nov 5, 2008 at 02:37, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:30 PM 11/4/2008 +0200, Sergey Schetinin wrote:
>>
>> I applied the suggested fix and it resolved the issue in the app as
>> well, thanks!
>>
>> I see how it wouldn't work for AddOns though, so I guess it's better
>> to avoid mixing Components and Addons, or at least only create them in
>> top-level, non-undoable code and not inside rules.
>
> Either that, or make the addition undoable, but that only works correctly in
> an unthreaded program.  (Of course, there are no guarantees *anything* works
> correctly in a threaded program.  And in any case the trellis only supports
> threading in theory, not practice: cells would need to have their manager
> attribute set to some sort of lock in order to be (somewhat) safe.)
>
>
>> On Tue, Nov 4, 2008 at 22:14, Sergey Schetinin <maluke at gmail.com> wrote:
>> > On Tue, Nov 4, 2008 at 16:36, Phillip J. Eby <pje at telecommunity.com>
>> > wrote:
>> >> I don't see from this example why .c's initialization *shouldn't* be
>> >> undone,
>> >> unless you're saying that the make() isn't also being undone...  in
>> >> which
>> >> case the test should be about that.
>> >
>> > You're right, but in the app it wasn't obvious that the problem is
>> > with make, what was apparent is that some changes from __init__ don't
>> > stick. So, I didn't know what the problem is exactly, until I figured
>> > out the test case.
>> >
>> >> It seems to me that the real issue here is that CellAttribute and
>> >> TodoProperty don't undo-log their addition of a cell to a Component's
>> >> __cells__.  I didn't originally do this because then the Cells() addon
>> >> would
>> >> need to support locking to be able to be threadsafe in the future.  But
>> >> I
>> >> suppose that bridge can be crossed later.
>> >>
>> >> Is there any other reason besides this inconsistency, that the
>> >> component
>> >> __init__ shouldn't be undone?
>> >
>> > No, I think this is it.
>> >
>> >> (Btw, the same problem occurs with cells in addons and services, and
>> >> won't
>> >> be fixed by undo-logging the cell creation.  It's a big open issue at
>> >> the
>> >> moment, since even avoiding an __init__ doesn't help.  In essence, undo
>> >> logging and "write-until-read" consistency simply don't mix, and
>> >>  Addons,
>> >> services, and the Cells() map all run off the write-until-read model.)
>> >>
>> >> At 05:09 AM 11/4/2008 +0200, Sergey Schetinin wrote:
>> >>>
>> >>> Here's the test case:
>> >>>
>> >>> class C(Component):
>> >>>    x = attr(0)
>> >>>    def __init__(self):
>> >>>        self.x = 10
>> >>>        @on_undo
>> >>>        def undo():
>> >>>            print 'UNDO'
>> >>>
>> >>>
>> >>> class TC(Component):
>> >>>    c = make(C)
>> >>>    x = attr(0)
>> >>>    y = attr(0)
>> >>>
>> >>>    @maintain
>> >>>    def test(self):
>> >>>        if self.x:
>> >>>            self.c
>> >>>            self.y
>> >>>
>> >>>    @maintain
>> >>>    def write(self):
>> >>>        self.y = self.x
>> >>>
>> >>>
>> >>> tc = TC()
>> >>>
>> >>> @atomically
>> >>> def test():
>> >>>    tc.x = 1
>> >>>    tc.test
>> >>>
>> >>> print tc.c.x
>> >>>
>> >>> # prints UNDO \ 0
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Nov 4, 2008 at 04:51, Sergey Schetinin <maluke at gmail.com>
>> >>> wrote:
>> >>> >> Thanks for your help identifying and fixing the problems.  I've
>> >>> >> checked
>> >>> >> in
>> >>> >> fixes, as described here:
>> >>> >>
>> >>> >> http://svn.eby-sarna.com?rev=2595&view=rev
>> >>> >
>> >>> > Thanks a lot. However, I see that some problems, that I thought was
>> >>> > related to my monkeypatching, didn't go away, what happens in effect
>> >>> > is that changes done Component.__init__ get rolled back. I'm working
>> >>> > on a test case for this, and I've noticed something I didn't think
>> >>> > about before. In the following example __init__ reads data it
>> >>> > shouldn't. This isn't a problem normally, but something to keep in
>> >>> > mind when writing components' __init__
>> >>> >
>> >>> > class TC(Component):
>> >>> >    y = attr(0)
>> >>> >
>> >>> >    def __init__(self):
>> >>> >        print self.read # 0
>> >>> >
>> >>> >    @compute
>> >>> >    def read(self):
>> >>> >        return self.y
>> >>> >
>> >>> >    @maintain
>> >>> >    def write(self):
>> >>> >        self.y = 5
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 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
>> >
>>
>>
>>
>> --
>> 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