<br><br><div class="gmail_quote">On Tue, May 18, 2010 at 4:10 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@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><div></div><div class="h5">On 19 May 2010 00:17, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> Hi Hans-Martin,<br>
><br>
> On Tue, May 18, 2010 at 12:15 PM, Hans-Martin Mosner <<a href="mailto:hmm@heeg.de">hmm@heeg.de</a>> wrote:<br>
>><br>
>> Hello,<br>
>> while looking at the decompiled code of some OMeta methods I noticed<br>
>> that the temp name handling in the decompiler seems to be broken.<br>
>> When you compile a method with temps that are referenced from blocks,<br>
>> the decompiler tends to rearrange the temp names, so this method<br>
>><br>
>> test<br>
>> | one two |<br>
>> two := 2.<br>
>> ^{[one := 1].<br>
>> [ [one + two] value]}<br>
>><br>
>> gets decompiled to this:<br>
>><br>
>> test<br>
>> | one two |<br>
>> one := 2.<br>
>> ^ {[two := 1]. [[two + one] value]}<br>
><br>
> OK, the issue in Squeak 4.1 is that the<br>
> CodeHolder>>decompiledSourceIntoContents method is out of date. Find<br>
> attached.<br>
><br>
>> But that's only a nuisance. The bug really shows up when you decompile a<br>
>> method compiled using OMeta.<br>
>> To see what I mean, load the OMeta2 package and have a look at method<br>
>> OMeta2AndOrOpt>>and.<br>
><br>
> Any way of reproducing this without OMeta, e.g. in a workspace?<br>
> e.g. to test the above I used things like<br>
> | mn m |<br>
> mn := Compiler new compile: 'test<br>
> | one two |<br>
> two := 2.<br>
> ^{[one := 1].<br>
> [ [one + two] value]}' in: nil class classified: nil notifying: nil<br>
> ifFail: nil.<br>
> m := (mn generate: #(0 0 0 0)) copyWithTempsFromMethodNode: mn.<br>
> {m decompile. m tempNamesString}<br>
> where in 4.1 "generate: #(0 0 0 0)" needs to be replaced with "generate:<br>
> CompiledMethodTrailer defaultMethodTrailer" (although asMethodTrailer on<br>
> ArrayedCollection would be nice for backward-compatibility).<br>
<br>
</div></div>There is a Behavior>>#defaultMethodTrailer , which is backwards compatible.<br></blockquote><div><br></div><div>CompiledMethod class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive: (and hence BytecodeAgnosticMethodNode>>generate:) is no longer backward-compatible. Call it with the old meaningless #(0 0 0 0) and you get an error. One might be able to provide backward-compatibility if there was an implementation of asMethodTrailer in Arrayed Collection that deferred to CompiledMethodTrailer and the relevant part of newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive: read:</div>
<div><br></div><div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>^ trailer asMethodTrailer createMethod: numberOfBytes</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> header: (nArgs bitShift: 24) +</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>(nTemps bitShift: 18) +</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(largeBit bitShift: 17) +</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(nLits bitShift: 9) +</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>primBits.</div><div><br></div><div>In any case the selector keyword is "trailerBytes:" not "methodTrailer:" or "trailer". IMO you should add a new method that takes a trailer and revert the old one to read</div>
<div><br></div><div><div>newBytes: numberOfBytes trailerBytes: trailer nArgs: nArgs nTemps: nTemps nStack: stackSize nLits: nLits primitive: primitiveIndex</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"Answer an instance of me. The header is specified by the message </div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>arguments. The remaining parts are not as yet determined."</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>^self newBytes: numberOfBytes</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>trailer: trailer asMethodTrailer</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>nArgs: nArgs</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>nTemps: nTemps</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>nStack: stackSize</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>nLits: nLits</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>primitive: primitiveIndex</div>
</div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So, one should use it instead of putting meaningless #(0 0 0 0) everywhere.<br></blockquote><div><br></div><div>Its not an issue of #(0 0 0 0) being meaningless. Its an issue of not breaking the old way where #(0 0 0 0) was used to mean empty.</div>
<div><br></div><div>best</div><div>Eliot </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
<br>
>><br>
>> Cheers,<br>
>> Hans-Martin<br>
>><br>
><br>
><br>
><br>
><br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</font></blockquote></div><br>