I remembered this situation was true in a bug report. Seemingly it is when you do context sourceNode on a dead context.
2014/1/27 Nicolai Hess <[email protected]> > 2014-01-27 Camille Teruel <[email protected]> > > >> On 27 janv. 2014, at 10:44, Camille Teruel <[email protected]> >> wrote: >> >> >> On 27 janv. 2014, at 09:28, Clément Bera <[email protected]> wrote: >> >> Hello, >> >> I don't think this line was there by mistake. In some cases, the activePC >> with this code is lower than the startpc and then the debugger shows an >> error 'no ast node found at this pc' and cannot properly highlight the >> current executed code because the pc is outside the method bytecode. >> >> >> Ok, thanks Clément. >> So shouldn't it be: activePC <= self *home* startpc ifTrue: [ activePC >> := pc ] since self may be the context of a block? >> >> >> We looked at the issue with Clément and we agreed on adding #home. >> Fix in inbox. >> Nicolai what do you think? >> >> >> I remember adding this line as a hack to fix a bug report.... But I don't >> remember any more... >> >> Here's an extract from my blog post, at that time the method had not this >> line, and we added it due to a bug report: >> >> *in a debugger, the context on the top of the stack does not highlight >> the same way other contexts does. In fact, the top context highlights the >> instruction in source code that *will* be executed in the next step. On the >> contrary, all the other contexts highlights the instruction in source code >> that *has been* executed previously. That means that you need to take care >> about that in the mapping to highlight the correct range.* >> >> *Right now we had to keep the old mapping API so there is a method >> named rangeForPC:contextIsActiveContext: that has a boolean as second >> argument. With this boolean you know if you need to look for the range of >> the current pc (first argument) of the previous pc of the first argument. >> On the old mapping, they needed the exact pc for their pc to abstract pc >> mapping. So they needed a method previousPCFor: to handle the case of >> multiple byte code instructions. But we don’t care, as the pc will be used >> in the scan of instructionForPC:, so we just need to do pc – 1.* >> >> >> >> >> >> >> >> >> >> *The result is : >> DebuggerMethodMapOpal>>#rangeForPC: aPC >> contextIsActiveContext:contextIsActive >> "return the debug highlight for aPC"| pc |pc := contextIsActive ifTrue: >> [aPC] ifFalse: [aPC - 1].^ (methodNode sourceNodeForPC: pc) >> debugHighlightRangeRBMethodNode>>#sourceNodeForPC: anInteger ^ (self ir >> instructionForPC: anInteger) sourceNode* >> >> >> >> >> *IRMethod>>#instructionForPC: aPC 0 to: -3 by: -1 do: [ : off |(self >> firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - off) ]) >> ifNotNil: [:it |^it]] * >> >> >> 2014/1/27 Camille Teruel <[email protected]> >> >>> >>> On 27 janv. 2014, at 08:44, Marcus Denker <[email protected]> >>> wrote: >>> >>> >>> On 26 Jan 2014, at 10:08, Camille Teruel <[email protected]> >>> wrote: >>> >>> [ [ ] ] >>> prints: >>> [ ] >>> instead of: >>> [ [ ] ] >>> >>> and >>> [ :arg | [ arg ] ] >>> prints: >>> DoIt >>> ^ [ :arg | [ arg ] ] yourself >>> instead of: >>> [ :arg | [ arg ] ] >>> >>> >>> Apparently it's the print that is not correct because of problem in >>> #sourceNode. >>> Any clue? Marcus? Clément? >>> >>> >>> Other than “the devil is in the details” (this is all far too complex >>> for my taste, implementation wise…) >>> >>> Can you add an issue? My problem is that i have no time right now to >>> even think about it… >>> >>> >>> My problem is that I found a fix with try-and-fail without really >>> understanding the code. >>> I just found that problematic examples were passing through that >>> condition whereas non problematic examples were not. >>> I looked at the versions and though that you may have left this line by >>> error. >>> I removed it and so far, it *seems* to work. So the fix is there but I >>> have no clue if it's correct or not. >>> Here it the case: >>> https://pharo.fogbugz.com/f/cases/12732/sourceNode-broken >>> >>> >>> Marcus >>> >>> >>> >> >> >> > I am lost :) > > It looks right, I did some tests and it works. > > But I fail to see, > in what situation would this be true: > > activePC <= self home startpc > > > >
