debugging bug

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

debugging bug

Chris Muller-4
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.

Best,
  Chris

Reply | Threaded
Open this post in threaded view
|

Re: debugging bug

Bert Freudenberg
On Sat, 18 Aug 2018 at 19:08, Chris Muller <[hidden email]> wrote:
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.

Fixed in
Compiler-bf.390
, I think.

- Bert -

 


Reply | Threaded
Open this post in threaded view
|

Re: debugging bug

Chris Muller-3
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.

 - Chris


On Mon, Aug 20, 2018 at 1:26 AM, Bert Freudenberg <[hidden email]> wrote:

> On Sat, 18 Aug 2018 at 19:08, Chris Muller <[hidden email]> wrote:
>>
>> 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.
>
>
> Fixed in
> Compiler-bf.390
> , I think.
>
> - Bert -
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: debugging bug

Bert Freudenberg
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. 

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: debugging bug

Eliot Miranda-2
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:

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: debugging bug

Bert Freudenberg


On Thu, 23 Aug 2018 at 07:38, Eliot Miranda <[hidden email]> wrote:
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:

That's because it fails to assign a source range to the hidden "== nil" message node.

Fixed in
Compiler-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
,
but
 the debugger stop
s
once
on that assignment, and stops again on the
"== nil"
comparison.
It 
really should jump over the assignment, but I'm not sure how to arrange that.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: debugging bug

Eliot Miranda-2
Hi Bert,

On Aug 23, 2018, at 7:58 PM, Bert Freudenberg <[hidden email]> wrote:



On Thu, 23 Aug 2018 at 07:38, Eliot Miranda <[hidden email]> wrote:
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:

That's because it fails to assign a source range to the hidden "== nil" message node.

Fixed in
Compiler-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
,
but
 the debugger stop
s
once
on that assignment, and stops again on the
"== nil"
comparison.
It 
really should jump over the assignment, but I'm not sure how to arrange that.

It can’t be fixed at the step level, which is checking willSend willReturn and willAssign.  But it could be fixed in the Debugger itself *provided* source ranges are correct and reliable.  If source ranges are correct then in step the Debugger can remember the current source range, ask the context to step, and if 
 - the next source range (& context) is the same
  - willAssign was true and willSend is true and peeking for the selector answers #==. and top of stack is nil
then the Debugger itself can add the extra step


- Bert -