debugging bug

Of course!  Right after just posting those test results I encountered
a bug with debugging case statements.

| str char | str := '1234' readStream.
char := str next.
char ifNil: [ Error signal ].
char caseOf: {
    [$4] -> ['four'].
    [$3] -> ['three' asUppercase].
    [$2] -> ['two'].
    [$1] -> ['one' asUppercase].
} otherwise: [ 'No' ]

The issue is that it highlights "signal" of "Error signal".

It's also interesting, but somewhat understandable, that it doesn't
highlight the blocks with no message sends in them.

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.

On Mon, 20 Aug 2018 at 16:06, Chris Muller <[hidden email]> 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. 

Hi Bert,

On Wed, Aug 22, 2018 at 3:57 PM Bert Freudenberg <[hidden email]> wrote:

On Mon, 20 Aug 2018 at 16:06, Chris Muller <[hidden email]> 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: