On Fri, Dec 2, 2011 at 8:18 PM, Mariano Martinez Peck <marianopeck@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.


has the return something to do with this?

Thanks


Thanks!

Thanks!


On Fri, Dec 2, 2011 at 7:41 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:


On Fri, Dec 2, 2011 at 10:20 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2011/12/2 Martin Dias <tinchodias@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