[squeak-dev] Re: [Pharo-project] Prune stack serialization

Eliot Miranda eliot.miranda at gmail.com
Fri Dec 2 20:46:18 UTC 2011


On Fri, Dec 2, 2011 at 12:40 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> On Fri, Dec 2, 2011 at 8:30 PM, Juan Vuletich <juan at jvuletich.org> wrote:
>
>> Eliot Miranda wrote:
>>
>>>
>>>
>>> On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck <
>>> marianopeck at gmail.com <mailto:marianopeck at gmail.com>**> wrote:
>>>
>>>    Thanks both. I am right to assume that if the block refers to temp
>>>    vars, parameters, or whatever in another scope, then such solution
>>>    won't work. I mean, if I have this example for example:
>>>
>>>    | bytes result blah |
>>>    blah := 42.
>>>    bytes := FLSerializer serializeToByteArray: (SortedCollection
>>>    sortBlock: [:a :b | (a + blah) > b ]).
>>>
>>>    Then the 'blah' is in a different context. So the mentioned
>>>    solution works for "clean" closures, which are "self contained".
>>>    In the other cases (such as this example), we should serialize the
>>>    whole stack. Is this correct?
>>>
>>>
>>> No.  The closure implementation arranges that any and all temporary
>>> variables accessed by the closure are directly accessible from the closure
>>> without accessing the outer contexts.
>>>  ...
>>>
>>
>> WRT clean closures, check what I did in Cuis to serialize
>> SortedCollections. See implementors and senders of #isClean.
>>
>>
> Nice. Thanks Juan. I was checking your code, and that's exactly why I
> asked Eliot. In your method you say:
>
> isClean
>     "A clean closure is one that doesn't really need the home context
> because:
>         - It doesn't send messages to self or super
>         - It doesn't access any instance variable
>         - It doesn't access any outer temp
>         - It doesn't do ^ return"
> .....
>
> So... my question is, WHAT do I need to serialize if I want to be able to
> serialize also "non clean".
>

IMO, dy default, everything reachable from the closure, including the
outerContext chain and their senders.  But that's only a default.  What
makes sense in any given context is up to the application, e.g. see
Seaside.  One size won't fit all.  You should handle the common cases (e.g.
clean blocks and everything else) and leave it up to the user to figure out
what they need to do in complex situations, making sure you provide them
with the hooks they'll need, such as the ability to substitute objects when
serializing etc, and perhaps some useful examples.

I mean, for each item on that list, what do I need apart from the closure
> instance and the receiver and method from the outerContext ?  the whole
> stack of contexts ?
>
>
> Thanks a lot in advance!
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20111202/de84b447/attachment.htm


More information about the Squeak-dev mailing list