> On 10 Oct 2014, at 10:57, Jan Kurš <[email protected]> wrote:
>
> Hi All,
>
> Thank you for the replies. I see it is not an easy bug to fix. Do you have
> any idea, when this can be fixed?
>
I will try to fix it next week...
> Or can you suggest me some other way/workaround, how to get/generate the
> source code of a block?
>
The old compiler used a hack to decompile blocks for getting a textual
representation… one could port
the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I actually
like the current scheme of
using the byte code-offset-to-AST mapping more).
Marcus
> Thank you very much!
> Cheers,
> Jan
>
> BTW, the tests to execute:
> self assert: [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] asString = '[ :ctx | [ ctx
> atEnd ] ifTrue: [ ] ]'
> self assert: [ :ctx | [ ctx atEnd ] whileTrue: [ ] ] asString = '[ :ctx | [
> ctx atEnd ] whileTrue: [ ] ]'
>
>
>
> On 8 October 2014 18:43, Marcus Denker <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On 08 Oct 2014, at 18:28, Camille Teruel <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>> On 8 oct. 2014, at 17:49, Marcus Denker <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>>
>>>> On 08 Oct 2014, at 16:46, Jan Kurš <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I need to extract a source code from a block closure and I found something
>>>> strange:
>>>>
>>>> [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] .
>>>> [ :ctx | [ ctx atEnd ] whileTrue:[ ] ].
>>>>
>>>> Print of the first line returns:
>>>> '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]'
>>>>
>>>> Print of the second line returns:
>>>> '[ ctx atEnd ]'
>>>>
>>>> And honestly, I have no idea why. This behaviour was observed in Pharo3
>>>> and Pharo4.
>>>>
>>>> Is there a way how to get a consistent result, i.e. '[ :ctx | [ ctx atEnd
>>>> ] whileTrue:[ ] ]' for a second line?
>>>
>>>
>>> I think this is an example that exposes a bug that we still have in the
>>> source mapping… on Context, see
>>>
>>> sourceNode
>>> "Return the source node of the method or the block corresponding to the
>>> receiver"
>>> ^ (method sourceNodeForPC: self neighborPCWithCorrectMapping)
>>> enclosingMethodOrBlockNode
>>> "Uncomment the following once the pc->AST mapping is fixed"
>>> "^ (method sourceNodeForPC: (pc ifNil: [ self startpc ]))
>>> enclosingMethodOrBlockNode"
>>>
>>> #neighborPCWithCorrectMapping returns the inner send, which is wrong… this
>>> method needs to be rethought.
>>
>> Yes it should. But that's not easy with optimized loop messages like
>> whileTrue: & co.
>> Ideally, the source mapping needs to be fixed because that's the reason this
>> method exists in the first place.
>
> The first step is to record a range for the byte code that an IRNode creates…
>
>> Or else we accepts that "1 to: 1 do: [ :i | ^ thisContext sourceNode ]"
>> returns a method node instead of a block node and use a different
>> implementation.
>>
>>>
>>> Marcus
>
>
