Hi Marcel,

On Wed, Dec 15, 2021 at 12:48 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Eliot --
>
> Here is an example to clarify the issue:
>
> | method block |
> method := WorldState >> #doOneCycleNowFor:.
> block := method literalAt: 7.
> block method decompileWithTemps nodesDo:
>     [:node| (node pc isVariableBinding and: [node pc key == block method])
> ifTrue: [^node]].
> self error.
>
> There are not valid pc's set in this scenario.
>

Yes there are :-)  You're confusing blocks and block methods.  This works:

| method compiledBlock |
method := WorldState >> #doOneCycleNowFor:.
compiledBlock := method literalAt: 7.
compiledBlock decompileWithTemps nodesDo:
    [:node| (node pc isVariableBinding and: [node pc key == compiledBlock])
ifTrue: [^node]].
self error

CompiledBlock>>method answers the CompiledMethod the CompiledBlock is
nested within.


> Best,
> Marcel
>
> Am 15.12.2021 09:39:36 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hi Eliot --
>
> (Full)BlockClosure works fine. I am talking about CompiledBlock.
>
> Best,
> Marcel
>
> Am 14.12.2021 23:29:42 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Dec 14, 2021 at 2:27 PM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>>
>> On Tue, Dec 14, 2021 at 5:19 AM Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>>> Hi all --
>>>
>>> Decompilation for instances of CompiledBlock is currently wrong. It just
>>> treats the CompiledMethod where the CompiledBlock is embedded.
>>>
>>
>> Well, it's been that way for a long time and there's something to do with
>> method wrappers (see methodForDecompile) that I don't understand that makes
>> me leery of just changing this.
>>
>>
>>> Compare the following two examples:
>>>
>>> [3+4] method "i.e., compiledCode" decompile decompileString.
>>> [3+4] decompile decompileString.
>>>
>>> Well, first, the message #method on FullBlockClosure  is misleading
>>> because we are looking for the compiled-code object, which is an instance
>>> of CompiledBlock here.
>>>
>>> Anyway, I then tried to understand how to make Decompiler >>
>>> decompileBlock: work for CompiledBlock and not just FullBlockClosure. It
>>> turns out, that there is no #pc set in any decompiled parse node.
>>>
>>> How to find a CompiledBlock's parse node in a CompiledMethod's parse
>>> tree?
>>>
>>
>> See Decompiler>>decompileBlock:
>>
>> | block |
>> block := [3+4].
>> block method decompileWithTemps nodesDo:
>>    [:node| (node pc isVariableBinding and: [node pc key = block method])
>> ifTrue: [^node]]
>>
>> =>  {[3 + 4]}
>>
>> i.e. the decompiler carefully sets the pc of a full block node to an
>> association so you can find the thing.
>>
>
> and #== works the same/is to be preferred:
>
> | block |
> block := [3+4].
> block method decompileWithTemps nodesDo:
>     [:node| (node pc isVariableBinding and: [node pc key == block method])
> ifTrue: [^node]]
>
>>
>> Now, as far as changing things to work the way you expect, I don't
>> object, provided you check out MethodWrappers, etc.
>> CompiledMethod>>methodForDecompile has my initials on it, but I didn't
>> write it.  So what its comment means I don't know but we shoud find out
>> before we break things.
>>
>> CompiledMethod>>methodForDecompile
>>     "This is a hook to allow recursive methods like MwMethodWrapper to
>> avoid infinite recursion."
>>     ^self
>>
>> I *really* don't like this method, but presumably it's there for a reason.
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211215/f94ddbb3/attachment.html>