[PEAK] A few issues and suggestions

[Sergey Schetinin]

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