block temps not in scope in debugger?

Andy/Blair:

I am having a problem that when a walkback occurs inside a one-argument
block, sometimes the block variable is not displayed in the variables
pane. Also, selecting the variable in the method and evaluating it results
in the message 'line 1: undeclared 'myvar'. There always seems to be one
variable in the variable pane with no name which appears to have the value
of the missing variable.

Simple code doesn't exhibit this problem so I don't have a test case so
far.

If I do the live update, it shows no patches available so I guess I am up
to date.

-alan r.

Alan,

> I am having a problem that when a walkback occurs inside a one-argument
> block, sometimes the block variable is not displayed in the variables
> pane. Also, selecting the variable in the method and evaluating it results
> in the message 'line 1: undeclared 'myvar'. There always seems to be one
> variable in the variable pane with no name which appears to have the value
> of the missing variable.

I've seen this too.  Sometimes the variables list has items that have nil or
blank (not sure which though I'll try to remember to investigate next time)
variable names but are selectable and, at least sometimes, display a value
that can be useful.  Normally when this happens, I just do a better job of
placing a break point and start over.


> Simple code doesn't exhibit this problem so I don't have a test case so
> far.

Ditto.


> If I do the live update, it shows no patches available so I guess I am up
> to date.

I am definitely _not_ up to date, and I see it too, so it's probably been
with us for a while.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Alan

You wrote in message news:[hidden email]...
> Andy/Blair:
>
> I am having a problem that when a walkback occurs inside a one-argument
> block, sometimes the block variable is not displayed in the variables
> pane. Also, selecting the variable in the method and evaluating it results
> in the message 'line 1: undeclared 'myvar'. There always seems to be one
> variable in the variable pane with no name which appears to have the value
> of the missing variable.

There is an obscure bug in the compiler's 'temp map' generation that
occassionally causes the debugger to show temps as out of scope when they
are not. Since Dolphin (up to the as yet unreleased version 6) implements
Smalltalk-80 style blocks, all the temps in a block are allocated fixed
slots in the home method context. This means that the temps are still
available even when they have gone out of scope, and so the debugger shows
them as unnamed entries. The workarounds for the bug are either to rearrange
your code slightly while debugging (perhaps by inserting an additional null
statement at the end of the block, e.g. '1+2', or to view the unnamed
variable slot.

>
> Simple code doesn't exhibit this problem so I don't have a test case so
> far.

I you do come across a simple case it would be useful in getting this fixed
in D5.

>
> If I do the live update, it shows no patches available so I guess I am up
> to date.

Unfortunately it will not be possible to patch this via Live Update, since
it will require a new compiler DLL.

Regards

Blair

> I you do come across a simple case it would be useful in getting this
fixed
> in D5.
We're experiencing this problem too. It wasn't there in Dolphin 5.0 so far I
know. A simple testcase would be
[#(1 2 3) do: [:each | each = 2 ifTrue: [Error signal: 'Error']]] on: Error
do: [:ex | self halt]

Evaluate this in a workspace and click on Debug. I don't see the variable ex
in D5.1 and I see it in D5.01.

An another problem with the debugger is the different behaviour of Step
Into. You can "step into" this code snippet in D5.0 and in D5.1 and you'll
see the difference.