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
On Sat, 18 Aug 2018 at 19:08, Chris Muller ma.chris.m@gmail.com 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 -
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 bert@freudenbergs.de wrote:
On Sat, 18 Aug 2018 at 19:08, Chris Muller ma.chris.m@gmail.com 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 -
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.
- Bert -
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:
_,,,^..^,,,_ best, Eliot
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 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 -
Hi Bert,
On Aug 23, 2018, at 7:58 PM, Bert Freudenberg bert@freudenbergs.de wrote:
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 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 stops 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 -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Chris Muller -
Eliot Miranda