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?

Or can you suggest me some other way/workaround, how to get/generate the
source code of a block?

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 <marcus.den...@inria.fr> wrote:

>
> On 08 Oct 2014, at 18:28, Camille Teruel <camille.ter...@gmail.com> wrote:
>
>
> On 8 oct. 2014, at 17:49, Marcus Denker <marcus.den...@inria.fr> wrote:
>
>
> On 08 Oct 2014, at 16:46, Jan Kurš <k...@iam.unibe.ch> 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
>
>
>

Reply via email to