On Thu, 23 Aug 2018 at 07:38, Eliot Miranda <eliot.miranda@gmail.com> wrote:Hi Bert,On Wed, Aug 22, 2018 at 3:57 PM Bert Freudenberg <bert@freudenbergs.de> wrote:On Mon, 20 Aug 2018 at 16:06, Chris Muller <asqueaker@gmail.com> wrote:I would never have guessed that fix. It seems better, thanks. I
think the ifNil: check is not quite working, it seems to "stay" on the
assignment for two steps, then skips over the #ifNil: check.
It does now highlight the cases its checking, which is very nice.The debugger's highlighting is actually very simple: It looks up which parse node has the current context's pc, and uses the source map to find the interval (a.k.a. source range) in the source code to highlight.This information comes from the compiler. It's parsing the source code into a tree of parse nodes, while its encoder records their source range. Then the compiler traverses that tree to emit byte code, recording the pc in each node.To fix the highlighting we just need to ensure that when the debugger stops on a pc, that pc is actually found in the right parse node, and the node has the right source range associated.I was about to do a fix for ifNil etc. but I see Eliot beat me to it in Compiler-eem.391. That's a one-line fix too, the recorded pc was just too far ahead.But the fix is incomplete. Replace ifNil: by an ifNil:ifNotNil: in Chris' example and one sees the same failure to emphasize anything for the == nil send hidden in the inlined ifNil:ifNotNil:That's because it fails to assign a source range to the hidden "== nil" message node.Fixed inCompiler-bf.393.There's still a minor glitch when the ifNotNil: block has an argument. In that case the compiler creates a hidden assignment node for the argument,butthe debugger stopsonceon that assignment, and stops again on the"== nil"comparison.Itreally should jump over the assignment, but I'm not sure how to arrange that.
- Bert -