On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Feb 3, 2017 at 12:28 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
>
> 2017-02-02 17:16 GMT+01:00 John Brant <brant@refactoryworkers.com>:
>>
>> I think my preference would be to have several tabs for the variables. In
>> addition to the one tab that we have now that shows all variables, I can
>> think of tabs for locals, inst vars, interesting variables, watched
>> variables/expressions, and stack variables. Locals would show just the
>> method/block arguments and any temps defined in the method.
>> Inst vars would
>> show the object's inst vars (and maybe class vars, however these would only
>> appear after the inst vars).
>>
>> Interesting variables would show locals and inst vars used by the method.
>> The locals would be limited to the ones that are still active at the current
>> location in the method. For example, if you are in a block, it would only
>> show variables used in the block.

>> Also, if you are before(/after) the first(/final) use of the variable,
>> it wouldn't show in the interesting list.

I'm not sure I'd like variables slipping in and out and rearranging
the middle of the list I'm looking at.�� Perhaps scope could be
indicated another way like greying out variables.�� It would be okay
for block variables to be added at the bottom.

>> Interesting variables should also do some analysis to see what accessor
>> methods are used and show their corresponding variables.

This is a nice idea.�� It need not only be for interesting variables.
Ideally it would be a tab in the next pane to the right of the [Meta]
tab, but I guess its difficult since that pane is concerned with the
object, and linking back to the variable holding could be difficult.

>>
>> Watched variables/expressions would be user controlled. The user could
>> add/remove variables or expressions. These variables/expressions would
>> remain across different methods. If a variable didn't exist in the other
>> method, "Invalid" could be displayed.

I really miss this from my TurboPascal days.
The difficulty of course is avoiding side effects.

>>
>> Finally, stack variables would display the whole stack and not just the
>> top item. I like the ability to see the stack top, but it really doesn't
>> work if you want to see the first argument of a two argument message send.
>> For example, if you debug "Array with: OrderedCollection new with: Set new",
>> stepping over the "OrderedCollection new" immediately pushes the "Set" class
>> on the stack so you can't see the "OrderedCollection new" object.

Perhaps the stack could be another tab next to [Variables] ?
Or maybe it [Stack] would be better as a tab of thisContext's next pane.


Actually you can try... ��

Context>>stackValueMap
| stackValues stackDepth|
stackValues := OrderedCollection new.
stackDepth := self basicSize min: 21.
(stackDepth to: 1 by: -1) do: [ :index | ��
|key|
key := (index = stackDepth) ifTrue: ['Top'] ifFalse: [(stackDepth - index + 1) asString].
stackValues add: (key -> (self basicAt: index))
].
^stackValues

Context>>gtInspectorStackValuesIn: composite
<gtInspectorPresentationOrder: 40>
| stackValues |
stackValues := self stackValues.
^ (composite table)
title: 'Stack';
display: [ self stackValueMap ];
column: 'Depth' evaluated: [ :assoc | assoc key ] width: 50;
column: 'Item' evaluated: [ :assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ]


I'm not sure whether the #stackValueMap is an appropriate name. Perhaps it should be #methodStackValueMap or something else?�� Similar for the tab name. ��

And I don't know what the magic number 21 is, as I queried here...

cheers -ben