> On 08 Oct 2014, at 18:28, Camille Teruel <[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
