On Fri, Dec 2, 2011 at 11:33 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> On Fri, Dec 2, 2011 at 8:18 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>>>> Is this clear or as clear as mud?
>>>>
>>>
>>> Much clear now. One last question. So far, then, I didn't find/think a
>>> scenario where serializing the whole stack (from a closure)  make sense.
>>> So, if I just want to serialize a closure and be able to materialize it,
>>> then it is *never* necessary the whole stack, in all scenarios?  or I am
>>> missing a case where the whole stack is needed?   I am talking only about
>>> when serializing closures, because if I directly serialize a MethodContext,
>>> it may happen that I want the whole stack (like the example I showed in
>>> ESUG where I serialized the whole Debugger and then I continue debugging in
>>> another image).
>>>
>>>
>> For example, would this work?
>>
>>
>> | bytes result blah |
>> blah := 42.
>> bytes := FLSerializer serializeToByteArray: (SortedCollection sortBlock:
>> [:a :b | (a + blah) > b. ^ blah ]).
>>
>>
> of course it doesn't make sense to do a return there. I was just an
> example, imagine another place where there is a blockclosure I want to
> serialize and there is a return inside.
>

To be able to return one needs the sender of the home context (the context
at the end of the outerContext chain).  But note that if the block contains
a return and one returns form it this is a "side-ways" return.  The return
isn't from the stack that invoked the block.  So it is "dangerous".  It
might work, it might not. Caveat emptor.  Note that if serializing contexts
in applications like Seaside one obviously does want to serialize a portion
of the stack.  But here the application is knowledgeable enough to manage
the (de)serialized contexts correctly (just as the system does when loading
a snapshot, which is effectively full of serialized contexts).

>
>
>
>
>> has the return something to do with this?
>>
>> Thanks
>>
>>
>> Thanks!
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda at gmail.com
>>>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier <
>>>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>>>
>>>>>>> 2011/12/2 Martin Dias <tinchodias at gmail.com>:
>>>>>>> > Hi folks
>>>>>>> >
>>>>>>> > In Fuel, we serialize a block closure with its state, including its
>>>>>>> > outerContext. This enables to serialize a sorted collection with
>>>>>>> its
>>>>>>> > sortBlock:
>>>>>>> >
>>>>>>> > | bytes result |
>>>>>>> > bytes := FLSerializer serializeToByteArray: (SortedCollection
>>>>>>> sortBlock: [:a
>>>>>>> > :b | a > b ]).
>>>>>>> > result := FLMaterializer materializeFromByteArray: bytes.
>>>>>>> > result
>>>>>>> > addAll: #(1 2 3);
>>>>>>> > yourself.
>>>>>>> > ---> a SortedCollection(3 2 1)
>>>>>>> >
>>>>>>> > Here the problem: the byte array is huge! (800kb) because we are
>>>>>>> serializing
>>>>>>> > unneeded context for the sort block.
>>>>>>> >
>>>>>>> > We wonder how to prune it and save time and space.
>>>>>>> >
>>>>>>> > Thanks in advance
>>>>>>> > Martín
>>>>>>>
>>>>>>> In the case of such clean block, there is no need of outer context
>>>>>>> during block execution.
>>>>>>> However I don't know if implementation makes it possible to ignore
>>>>>>> the
>>>>>>> context...
>>>>>>> That's more a question directed to Eliot ;)
>>>>>>>
>>>>>>
>>>>>> Arguably there is a bug in my closure implementation, which is that
>>>>>> both the receiver and the method are fetched from the outerContext.  That's
>>>>>> not a bug which can be fixed without a new VM/image combination and may be
>>>>>> something I'll look at long-term, but is something we have to live with at
>>>>>> the moment.  This means that you *do* have to serialize the outerContext.
>>>>>>  But the outerContext is used only for the receiver and method.  So you
>>>>>> don't need to full serialize the outerContext.  In particular you don't
>>>>>> need to serialize any of the outerContext's stack contents or its sender.
>>>>>>  This needs special handling, I guess in BlockClosure, to substitute a
>>>>>> suitably reduced outerContext, but it shouldn't be hard to do.  e.g.
>>>>>>
>>>>>> BlockClosure methods for: '*Fuel-serialization'
>>>>>> outerContextForSerialization
>>>>>> ^MethodContext
>>>>>> sender: nil
>>>>>>  receiver outerContext receiver
>>>>>> method: outerContext method
>>>>>> args: #()
>>>>>>
>>>>>>
>>>>>> BlockClosure methods for: '*Fuel-serialization'
>>>>>> outerContextForSerialization
>>>>>> ^MethodContext
>>>>>>  sender: nil
>>>>>> receiver self receiver
>>>>>> method: self method
>>>>>>  args: #()
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> best,
>>>>>> Eliot
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> best,
>>>> Eliot
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
>
>


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