On Fri, Dec 17, 2021 at 4:41 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Eliot --
>
> Thanks. Here is a changeset that drops #methodForDecompile and that
> changes CompiledCodeInspector to better support CompiledBlock instances.
>
> The recent implementation of MethodWrappers here (
> https://github.com/hpi-swa/MethodWrappers) does not need #methodForDecompile
> .
>
> Which other applications of object-as-method are out there working in
> recent Squeak needing the #methodForDecompile hook?
>

I wish I knew :-)  I agree.  Nuke methodForDecompile.

>
> Best,
> Marcel
>
> Am 16.12.2021 08:01:05 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> 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
>
>
>

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