On 14 févr. 2014, at 00:45, Nicolai Hess <nicolaihess@web.de> wrote:
Thank you camille, I still don't fully understand, why it is so hard to make it work for all use cases. It looks like a simple thing, make a sourceNode for the current context!
So for me it looks like the main problem is to distinguish these cases: Create a SourceNode for a) Method or b) Block or c) MethodContext or d) BlockContext and at the moment we are mixing case c/d/b
It's easy for method and block. For MethodContext, it's harder. I would love if I could write: MethodContext>>sourceNode ^ self isBlockContext ifTrue: [ closureOrNil sourceNode ] ifFalse: [ method sourceNode ]. but it doesn't work because inlined blocks don't create a new context: 1 to: 1 do: [ :i | ^ thisContext isBlockContext ] returns false. So instead we have to rely on pc->IR nodes and IR nodes->AST nodes mappings. But everything is not mapped as you would expect yet in these two mappings. I found that: - the (pushLiteral: nil) bytecodes used to mark the number of block temporaries have corresponding IR nodes but these node are mapped with the AST block node instead of the AST sequence node. - the (pushTemp: n) bytecodes used to push the copied values of blocks don't have corresponding IR nodes so no AST node is associated with them. - the block return bytecodes are mapped to the block node instead of the sequence. Fixing these mapping is not easy, and it's too big a change for Pharo 3. So we have to deal with the current mapping for now.
Thank you ben, for finding/looking at the failing tests.
(I wished we would have an improved debugger, showing sourcecode, AST, IR and bytecode linked together :-)
2014-02-13 16:27 GMT+01:00 Camille Teruel <camille.teruel@gmail.com>: Hi Nicolai,
I opened the issue 12875 and committed a fix. Can you look at it?
On 11 févr. 2014, at 11:54, Nicolai Hess <nicolaihess@web.de> wrote:
Ben, Camille, can you take a look at this code |a b| a:='String'. b:='t'. a collectWithIndex:[:c :i | c < b]
Debug this code and step over until you reach the collectWithIndex: method, the context inspector will show a,b,c,i even though only a and b are in the current scope. And it'll show the wrong values a->'String' b->'String' c->'String' i->'t'
(This does not happen with old compiler and it does not happen in 307052)