<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 10:23 AM, Camille Teruel <span dir="ltr"><<a href="mailto:camille.teruel@gmail.com" target="_blank">camille.teruel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><div>On 10 août 2014, at 19:15, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hi Nicolai,<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 9:39 AM, Nicolai Hess <span dir="ltr"><<a href="mailto:nicolaihess@web.de" target="_blank">nicolaihess@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div><div>Hi Eliot,<br><br></div>I am pretty sure this is not a vm issue :)<br></div><div><br>The mustBeBooleanInMagic: creates a method on the fly and executes it with the <br>
</div><div>a context as argument.<br>
</div><div>The "ThisContext" is not the "thisContext", but the argument of the generated method.<br><br></div><div>This is the bytecode of the generated method:<br><br>17 <00> pushRcvr: 0<br>18 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 22 to 23<br>
22 <76> pushConstant: 1<br>23 <7D> blockReturn<br>24 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 28 to 29<br>28 <75> pushConstant: 0<br>29 <7D> blockReturn<br>30 <F0> send: ifTrue:ifFalse:<br>
31 <7C> returnTop<br><br></div><div>The original method is<br><br>foo<br> ^ notABool1 ifTrue:[1] ifFalse:[0]<br><br></div><div>The generated method compiles this part<br>notABool1 ifTrue:[1] ifFalse:[0]<br><br></div>
<div>to bytecode without the jumpFalse optimization. <br>The problem is that the receiver for the ifTrue:ifFalse send is accessed through<br></div><div>pushRcvr:0, whereas the thisContext is not the context of the original method anymore.<br>
</div></div></blockquote><div><br></div><div>Ah, now I know what's going on. Thanks. I like this experiment very much.</div><div><br></div><div>How do you extract the blocks from the method? Do you decompile or simply recompile from source or...?</div>
</div></div></div></blockquote><div><br></div></div></div><div>We just recompile the ast message node that triggered the error without optimizations and some rewriting (temps and returns).</div><div>Right now it works only for 'if' messages.</div>
<div>For 'while' messages I'm thinking about sending #truthValue to the value of the receiver block.</div><div class=""><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>Have (any of) you looked at implementing the mustBeBooleanMagic by interpreting the bytecodes that already exist in the method via some specialized interpreter instead of compiling a method on the fly?</div></div></div>
</div></blockquote><div><br></div></div><div>No but that would be interesting indeed :)</div><div>Another solution is to cache the generated methods somewhere instead of recompiling each time.</div></div></div></blockquote>
<div><br></div><div>In the method's properties.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5">
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nicolai</div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-08-10 17:34 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div dir="ltr">Hi Nicolai,<div><br></div><div> please try and remember to invlude vm-dev when you see a VM issue...<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 7:34 AM, Nicolai Hess <span dir="ltr"><<a href="mailto:nicolaihess@web.de" target="_blank">nicolaihess@web.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There is a certain risk, that the mustBeBooleanMagicIn method rewrite can crash the<br>
vm<br></div><a href="https://pharo.fogbugz.com/default.asp?13805" target="_blank">Issue 13805</a></div></blockquote><div><br></div><div>Since you're using the Opal compiler ca you add the description of the bytecode (aCompiledMethod symbolic) to the issue? I'll try and take a look soon but want to be sure I'm debugging the relevant code.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>The receiver of the rewritten method is the "nonboolean" value receiving the<br>
</div>
ifTrue:ifFalse: message. But the rewritten method can include <br>instvar accessor and self sends of the original method.<br><br></div>We can include more rewrite rules in mustBeBooleanMagicIn like<br></div> "rewrite instvar accessing"<br>
<div> context receiver class instVarNamesAndOffsetsDo: [ :n :o | <br> RBParseTreeRewriter new <br> replace: n with: ('ThisContext receiver instVarAt: ', o asString);<br> executeTree: methodNode.<br>
].<br></div><div>"rewrite self sends"<br></div><div> RBParseTreeRewriter new <br> replace: 'self' with: 'ThisContext receiver';<br> executeTree: methodNode.<br><br></div>
<div>But I don't know if this works for all possible situations. Or if there are<br>better ways to do the rewriting.</div></div></blockquote><div><br></div><div>Remember the mirror methods:</div><div> thisContext object: o instVarAt:</div>
<div>which doesn't send to o, reaching directly into it.</div><div><br></div><div>But what's the point of replacing "self" with "thisContext receiver"? The latter is potentially an extremely slow way of doing the former. The former won't create a context object in a method activation that doesn't need one (doesn't include a block), whereas the latter always will. But they will always yield the same result.</div>
</div>-- <br>curious,<div>Eliot</div></div></div></div></blockquote></div></div></blockquote></div>-- <br>best,<div>Eliot</div>
</div></div>
</blockquote></div></div></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>