Confused about the GTInspector State Tab
I am confused about the GTInspector State tab. What is its definition ? I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. Why then does it not show all variable content and only named variables ? Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. How can I inspect an individual character of a String ? Or an individual byte ? Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. I could propose changes or a slice, but I think we should agree on the definition of 'State' first. Sven
I agree. I often want to see the real implementation and not the view that the system wants me to believe. Stef
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
Sven
Sven Van Caekenberghe wrote:
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
Sven
If its a raw slots view you want, maybe that tab should be called 'Slots' ? cheers -ben
cool thing of this new inspector is that is super easy to extend with what you want So wouldnât be complicated to add that functionality :) Esteban
On 01 Oct 2014, at 15:51, Ben Coman <btc@openInWorld.com> wrote:
Sven Van Caekenberghe wrote:
I am confused about the GTInspector State tab. What is its definition ? I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. Why then does it not show all variable content and only named variables ? Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. How can I inspect an individual character of a String ? Or an individual byte ? Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. I could propose changes or a slice, but I think we should agree on the definition of 'State' first. Sven
If its a raw slots view you want, maybe that tab should be called 'Slots' ? cheers -ben
But we cannot all start doing different things, right ? There should be some design and structure, that is why I am asking. On 01 Oct 2014, at 15:59, Esteban Lorenzano <estebanlm@gmail.com> wrote:
cool thing of this new inspector is that is super easy to extend with what you want So wouldnât be complicated to add that functionality :)
Esteban
On 01 Oct 2014, at 15:51, Ben Coman <btc@openInWorld.com> wrote:
Sven Van Caekenberghe wrote:
I am confused about the GTInspector State tab. What is its definition ? I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. Why then does it not show all variable content and only named variables ? Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. How can I inspect an individual character of a String ? Or an individual byte ? Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. I could propose changes or a slice, but I think we should agree on the definition of 'State' first. Sven
If its a raw slots view you want, maybe that tab should be called 'Slots' ? cheers -ben
On 01 Oct 2014, at 15:08, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
I think this is just a matter of iterating, e.g. Dictionary has it already correct: State show the raw state (array, tally), while the âitemsâ view shows nicely key->values. an example where it fails is CompiledMethod, it has a Bytecode view, but in addition a (virtual) âall byte codesâ variable in the raw view. (and more). I think we need -> the raw state for every object (like the old basic inspector) -> this might not be the default view for all objects, though. (the default should present something useful). This means, maybe having the notion of a default view would be nice. -> work to add more views to everything interesting. Marcus
Hi, Indeed, the goal of State is to show the raw state of every object. In case we miss something, we should add that. Sven, if you see that this is not happening, let's start on a case to case basis. Btw, if you want to know what gets shown in State, you can simply inspect the result of Object>>#gtInspectorVariableValuePairs. You can also override that for your own objects if you want. You can see a post explaining this here: http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspect... The default view is specified by the order. So, the first view is the default one. We made the State view has order 10. If you define a view with a lower order, it will appear first. We have to experiment here with different objects. For example, for collections, a better default view would be the items. We did not do that until now in order to not alienate even more the users. But, I think now it's time to do it. Cheers, Doru On Wed, Oct 1, 2014 at 4:22 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Oct 2014, at 15:08, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
I think this is just a matter of iterating, e.g. Dictionary has it already correct: State show the raw state (array, tally), while the âitemsâ view shows nicely key->values.
an example where it fails is CompiledMethod, it has a Bytecode view, but in addition a (virtual) âall byte codesâ variable in the raw view. (and more).
I think we need -> the raw state for every object (like the old basic inspector) -> this might not be the default view for all objects, though. (the default should present something useful). This means, maybe having the notion of a default view would be nice. -> work to add more views to everything interesting.
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
On 1/10/14 16:30, Tudor Girba wrote:
Hi,
Indeed, the goal of State is to show the raw state of every object. In case we miss something, we should add that. Sven, if you see that this is not happening, let's start on a case to case basis.
Doru call it "raw" and not state. Especially if state may interpret the state
Btw, if you want to know what gets shown in State, you can simply inspect the result of Object>>#gtInspectorVariableValuePairs. You can also override that for your own objects if you want. You can see a post explaining this here: http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspect...
The default view is specified by the order. So, the first view is the default one. We made the State view has order 10. If you define a view with a lower order, it will appear first. We have to experiment here with different objects. For example, for collections, a better default view would be the items. We did not do that until now in order to not alienate even more the users. But, I think now it's time to do it.
yes
Cheers, Doru
On Wed, Oct 1, 2014 at 4:22 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 01 Oct 2014, at 15:08, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
> I am confused about the GTInspector State tab. What is its definition ? > > I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views. > > Why then does it not show all variable content and only named variables ? > > Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all. > > How can I inspect an individual character of a String ? Or an individual byte ? > > Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view. > > In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing. > > I could propose changes or a slice, but I think we should agree on the definition of 'State' first. >
I think this is just a matter of iterating, e.g. Dictionary has it already correct: State show the raw state (array, tally), while the âitemsâ view shows nicely key->values.
an example where it fails is CompiledMethod, it has a Bytecode view, but in addition a (virtual) âall byte codesâ variable in the raw view. (and more).
I think we need -> the raw state for every object (like the old basic inspector) -> this might not be the default view for all objects, though. (the default should present something useful). This means, maybe having the notion of a default view would be nice. -> work to add more views to everything interesting.
Marcus
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
On Wed, Oct 1, 2014 at 3:08 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Yes, I think that this should be the main purpose of the State tab. (behave like EyeBasicInspector). The only difference right now is in the way collections are handled. Collections should have an items views. Now sure why it is missing for String and ByteArray. Maybe we thought it's not really needed. As we display the elements of a collection in a dedicated tab, then indeed, the State view only shows self, which is not so nice. Still for objects like Integer, Float, CompiledMethod I'd like that the State view contains some meta variables. I'd prefer this rather to switching between two tabs. Now I also get your point about seeing only the raw fundamental data of an object. We could be to improve the state view to add both all the variable + some meta variables and make it clear what are the meta variables. For example display all the meta variables at the top on a slightly different background. We definitely need to iterate more :) Cheers, Andrei
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
Sven
To distinguish between the different types of variables, we could add another column with a tag, like we have in the GTDebugger (e.g., Slot / Derived). What do you think? Cheers, Doru On Wed, Oct 1, 2014 at 4:28 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
On Wed, Oct 1, 2014 at 3:08 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Yes, I think that this should be the main purpose of the State tab. (behave like EyeBasicInspector).
The only difference right now is in the way collections are handled. Collections should have an items views. Now sure why it is missing for String and ByteArray. Maybe we thought it's not really needed.
As we display the elements of a collection in a dedicated tab, then indeed, the State view only shows self, which is not so nice.
Still for objects like Integer, Float, CompiledMethod I'd like that the State view contains some meta variables. I'd prefer this rather to switching between two tabs.
Now I also get your point about seeing only the raw fundamental data of an object. We could be to improve the state view to add both all the variable + some meta variables and make it clear what are the meta variables. For example display all the meta variables at the top on a slightly different background.
We definitely need to iterate more :)
Cheers, Andrei
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
Sven
-- www.tudorgirba.com "Every thing has its own flow"
Hmm, a column for a tag would take even more space and for most objects it will only be Slot. Also with the icons and the arrow for collapsing it might not look so good. The other solution is to display all derived variables at the top, perhaps with a different color or/and in italic. On Wed, Oct 1, 2014 at 4:32 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
To distinguish between the different types of variables, we could add another column with a tag, like we have in the GTDebugger (e.g., Slot / Derived). What do you think?
Cheers, Doru
On Wed, Oct 1, 2014 at 4:28 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
On Wed, Oct 1, 2014 at 3:08 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Yes, I think that this should be the main purpose of the State tab. (behave like EyeBasicInspector).
The only difference right now is in the way collections are handled. Collections should have an items views. Now sure why it is missing for String and ByteArray. Maybe we thought it's not really needed.
As we display the elements of a collection in a dedicated tab, then indeed, the State view only shows self, which is not so nice.
Still for objects like Integer, Float, CompiledMethod I'd like that the State view contains some meta variables. I'd prefer this rather to switching between two tabs.
Now I also get your point about seeing only the raw fundamental data of an object. We could be to improve the state view to add both all the variable + some meta variables and make it clear what are the meta variables. For example display all the meta variables at the top on a slightly different background.
We definitely need to iterate more :)
Cheers, Andrei
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
To distinguish between the different types of variables, we could add another column with a tag, like we have in the GTDebugger (e.g., Slot / Derived). What do you think?
I do not like slots. Because not all the objects have that. Raw Items are working better to me
Cheers, Doru
On Wed, Oct 1, 2014 at 4:28 PM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
On Wed, Oct 1, 2014 at 3:08 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Yes, I think that this should be the main purpose of the State tab. (behave like EyeBasicInspector).
The only difference right now is in the way collections are handled. Collections should have an items views. Now sure why it is missing for String and ByteArray. Maybe we thought it's not really needed.
As we display the elements of a collection in a dedicated tab, then indeed, the State view only shows self, which is not so nice.
Still for objects like Integer, Float, CompiledMethod I'd like that the State view contains some meta variables. I'd prefer this rather to switching between two tabs.
Now I also get your point about seeing only the raw fundamental data of an object. We could be to improve the state view to add both all the variable + some meta variables and make it clear what are the meta variables. For example display all the meta variables at the top on a slightly different background.
We definitely need to iterate more :)
Cheers, Andrei
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
Sven
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
On 1 oct. 2014, at 18:38, stepharo <stepharo@free.fr> wrote:
To distinguish between the different types of variables, we could add another column with a tag, like we have in the GTDebugger (e.g., Slot / Derived). What do you think?
I do not like slots. Because not all the objects have that.
Apart from the variable part, all the state of any object is represented via slots. But the state view can easily find out that it's displaying an instance of a variable class and act accordingly. I like Doru's solution because it permits any object to have a good default state view without having to implement a bunch of special views. And if you want to see only the real layout of the object, you can always click on the 'iv' tag to filter out virtual slots. So you have one view to show all the relevant state information in one pane and a way to filter/sort it easily. Camille
Raw Items
are working better to me
Cheers, Doru
On Wed, Oct 1, 2014 at 4:28 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
On Wed, Oct 1, 2014 at 3:08 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: I am confused about the GTInspector State tab. What is its definition ?
I would say that it shows the raw, fundamental, implementation form of the object, in essence what EyeBasicInspector showed. And that additional tabs offer alternative, more user friendly views.
Yes, I think that this should be the main purpose of the State tab. (behave like EyeBasicInspector).
The only difference right now is in the way collections are handled. Collections should have an items views. Now sure why it is missing for String and ByteArray. Maybe we thought it's not really needed.
As we display the elements of a collection in a dedicated tab, then indeed, the State view only shows self, which is not so nice.
Still for objects like Integer, Float, CompiledMethod I'd like that the State view contains some meta variables. I'd prefer this rather to switching between two tabs.
Now I also get your point about seeing only the raw fundamental data of an object. We could be to improve the state view to add both all the variable + some meta variables and make it clear what are the meta variables. For example display all the meta variables at the top on a slightly different background.
We definitely need to iterate more :)
Cheers, Andrei
Why then does it not show all variable content and only named variables ?
Try inspecting a [Byte]String or [Byte]Array. The State view is useless, it just shows self. Some of these have an items view, but not all.
How can I inspect an individual character of a String ? Or an individual byte ?
Consider a Float. The State view should show the two (meaningless) slots because that is how Floats are (currently) implemented, and then another tab should show the sign, mantissa, exponent view.
In the Eye inspectors we also confused these two aspects in a single view, which is wrong in hindsight, IMHO. It should be crystal clear for a user whether a slot is real or an alternative view of describing the same thing.
I could propose changes or a slice, but I think we should agree on the definition of 'State' first.
Sven
-- www.tudorgirba.com
"Every thing has its own flow"
participants (8)
-
Andrei Chis -
Ben Coman -
Camille Teruel -
Esteban Lorenzano -
Marcus Denker -
stepharo -
Sven Van Caekenberghe -
Tudor Girba