Thank you very much Eliot and Juan for this nice discussion. I have just commit this new functionality and it seems to work fine. I ended up using Eliot's #abstractBytecodes since the one from Juan didn't work out of the box in Pharo. <br>
<br><br><div class="gmail_quote">On Fri, Dec 2, 2011 at 10:38 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Juan,<br><br><div class="gmail_quote"><div class="im">On Fri, Dec 2, 2011 at 11:59 AM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>></span> wrote:<br></div>
<div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mariano Martinez Peck wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<br>
On Fri, Dec 2, 2011 at 9:46 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a> <mailto:<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.<u></u>com</a>>> wrote:<br>
<br>
<br>
<br>
On Fri, Dec 2, 2011 at 12:40 PM, Mariano Martinez Peck<br></div><div>
<<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a> <mailto:<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>><u></u>> wrote:<br>
<br>
<br>
<br>
On Fri, Dec 2, 2011 at 8:30 PM, Juan Vuletich<br></div><div>
<<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a> <mailto:<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>>> wrote:<br>
<br>
Eliot Miranda wrote:<br>
<br>
<br>
<br>
On Fri, Dec 2, 2011 at 10:55 AM, Mariano Martinez Peck<br>
<<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a> <mailto:<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>><br></div>
<mailto:<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a><div><div></div><div><br>
<mailto:<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>><u></u>>> wrote:<br>
<br>
Thanks both. I am right to assume that if the block<br>
refers to temp<br>
vars, parameters, or whatever in another scope,<br>
then such solution<br>
won't work. I mean, if I have this example for example:<br>
<br>
| bytes result blah |<br>
blah := 42.<br>
bytes := FLSerializer serializeToByteArray:<br>
(SortedCollection<br>
sortBlock: [:a :b | (a + blah) > b ]).<br>
<br>
Then the 'blah' is in a different context. So the<br>
mentioned<br>
solution works for "clean" closures, which are<br>
"self contained".<br>
In the other cases (such as this example), we<br>
should serialize the<br>
whole stack. Is this correct?<br>
<br>
<br>
No. The closure implementation arranges that any and<br>
all temporary variables accessed by the closure are<br>
directly accessible from the closure without accessing<br>
the outer contexts.<br>
...<br>
<br>
<br>
WRT clean closures, check what I did in Cuis to serialize<br>
SortedCollections. See implementors and senders of #isClean.<br>
<br>
<br>
Nice. Thanks Juan. I was checking your code, and that's<br>
exactly why I asked Eliot. In your method you say:<br>
<br>
isClean<br>
"A clean closure is one that doesn't really need the home<br>
context because:<br>
- It doesn't send messages to self or super<br>
- It doesn't access any instance variable<br>
- It doesn't access any outer temp<br>
- It doesn't do ^ return"<br>
.....<br>
<br>
So... my question is, WHAT do I need to serialize if I want to<br>
be able to serialize also "non clean".<br>
<br>
<br>
IMO, dy default, everything reachable from the closure, including<br>
the outerContext chain and their senders. But that's only a<br>
default. What makes sense in any given context is up to the<br>
application, e.g. see Seaside. One size won't fit all. You<br>
should handle the common cases (e.g. clean blocks and everything<br>
else) and leave it up to the user to figure out what they need to<br>
do in complex situations, making sure you provide them with the<br>
hooks they'll need, such as the ability to substitute objects when<br>
serializing etc, and perhaps some useful examples.<br>
<br>
<br>
+1 Then we will do the following: we will check whether the closure is clean. If it is, then we serialize just the closure plus its outerContext but only with receiver and method. If it is not clean, then we serialize the whole stack. That's all by default. If then someone needs something different, then to use the hooks :)<br>
So the final question is whether what Juan is using in Cuis is up to date. If it is, then I have all I need :)<br>
Thank you guys.<br>
</div></div></blockquote>
<br>
I can say that it does indeed work. But I'd be really grateful if Eliot took a good look at that code!<br></blockquote><div><br></div></div></div><div>There is a much better way, using InstructionStream>>interpreetNextInstructionFor: which abstracts away from the bytecode encoding and allows one to simply use messages. e.g. look at </div>
<div><br></div><div>BlockClosure methods for private</div><div><div>abstractBytecodes</div><div><span style="white-space:pre-wrap"> </span>"Answer an OrderedCollection of the abstract bytecodes sent in the receiver."</div>
<div><span style="white-space:pre-wrap"> </span>| scanner blockCreationMessage end abstractBytecodes |</div><div><span style="white-space:pre-wrap"> </span>scanner := InstructionStream new.</div>
<div><span style="white-space:pre-wrap"> </span>"find the creation message to find the extent of the block."</div><div><span style="white-space:pre-wrap"> </span>scanner method: self method pc: self method initialPC.</div>
<div><span style="white-space:pre-wrap"> </span>[scanner pc < startpc] whileTrue:</div><div><span style="white-space:pre-wrap"> </span>[[scanner interpretNextInstructionFor: nil]</div>
<div><span style="white-space:pre-wrap"> </span>on: MessageNotUnderstood</div><div><span style="white-space:pre-wrap"> </span>do: [:ex| blockCreationMessage := ex message]].</div><div>
<span style="white-space:pre-wrap"> </span>end := blockCreationMessage arguments last + startpc - 1.</div><div><span style="white-space:pre-wrap"> </span>"now collect all the bytecode messages in the block."</div>
<div><span style="white-space:pre-wrap"> </span>abstractBytecodes := OrderedCollection new.</div><div><span style="white-space:pre-wrap"> </span>scanner method: self method pc: startpc.</div>
<div><span style="white-space:pre-wrap"> </span>[scanner pc < end] whileTrue:</div><div><span style="white-space:pre-wrap"> </span>[[scanner interpretNextInstructionFor: nil]</div><div>
<span style="white-space:pre-wrap"> </span>on: MessageNotUnderstood</div><div><span style="white-space:pre-wrap"> </span>do: [:ex| abstractBytecodes add: ex message selector]].</div>
<div><span style="white-space:pre-wrap"> </span>^abstractBytecodes</div><div><br></div><div>and (SortedCollection sortBlock: [:a :b| a compare: b caseSensitive: false]) sortBlock abstractBytecodes evaluates to</div>
</div><div><br></div><div>an OrderedCollection(#pushTemporaryVariable: #pushTemporaryVariable: #pushConstant: #send:super:numArgs:)</div><div><br></div><div>So a check for clean blocks would check for a block's abstractBytecodes not including some particular set of banned messages (which I *think* is pushReceiver pushReceiverVariable: popIntoReceiverVariable: storeIntoReceiverVariable: methodReturnConstant: methodReturnReceiver methodReturnTop).</div>
<div><br></div><div>e.g.</div><div><br></div><div>isClean</div><div> ^(self abstractBytecodes intersection: #(pushReceiver pushReceiverVariable: popIntoReceiverVariable: storeIntoReceiverVariable: methodReturnConstant: methodReturnReceiver methodReturnTop)) isEmpty</div>
<div class="im">
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Juan Vuletich<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<br>
<br>
I mean, for each item on that list, what do I need apart from<br>
the closure instance and the receiver and method from the<br>
outerContext ? the whole stack of contexts ?<br>
<br>
<br>
Thanks a lot in advance!<br>
<br>
<br>
<br>
-- Mariano<br>
<a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.<u></u>com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- best,<br>
Eliot<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Mariano<br>
<a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.<u></u>com</a><br>
<br></div>
------------------------------<u></u>------------------------------<u></u>------------<br>
<br>
<br>
<br>
------------------------------<u></u>------------------------------<u></u>------------<br>
<br>
No virus found in this message.<br>
Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a> <<a href="http://www.avg.com" target="_blank">http://www.avg.com</a>><br>
Version: 10.0.1411 / Virus Database: 2102/4052 - Release Date: 12/02/11<br>
<br>
</blockquote>
<br>
<br>
</blockquote></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>
</font></span><br><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>