Hi, I took a bit of time to describe how the GTInspector works, what makes it different, and to provide hints for several usage scenarios. http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed It's a long post, I know :), but please take a look. As you might know, this is the default inspector in the Moose image, but it can also be loaded in a fresh Pharo image. I am particularly interested in the following: - if you never used it, and tried it now, what don't you like? - if you used it, was there anything that you did not know? - and of course, what do you like about it? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
Hi Doru, I have never used it till 2 days ago when I was playing with Andrei to do something. The only thing I can say is that it âfeelsâ strange at the beginning⦠I am not used to this horizontal navigation⦠I am more used to spawning a lot of small inspectors that I can also use to compare things, i.e., one inspector close to the other. Apart from that, Andrei told me it takes time but then you get used to it and you love it. Letâs see. Cheers, R On Dec 19, 2013, at 7:50 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I took a bit of time to describe how the GTInspector works, what makes it different, and to provide hints for several usage scenarios. http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed
It's a long post, I know :), but please take a look. As you might know, this is the default inspector in the Moose image, but it can also be loaded in a fresh Pharo image.
I am particularly interested in the following: - if you never used it, and tried it now, what don't you like? - if you used it, was there anything that you did not know? - and of course, what do you like about it?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Hi Roberto, Thanks for expressing an interest :). Please let us know when you encounter something that does not work for you. This is a critical tool in a Pharo environment and we need all the feedback we can get to improve it. It can indeed feel strange at first as it requires you to work a bit differently. Just out of curiosity: have you read the post already? Does it address your concerns? Dies it provide hints for how your workflow can be different? Cheers, Doru On Thu, Dec 19, 2013 at 9:38 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Hi Doru,
I have never used it till 2 days ago when I was playing with Andrei to do something.
The only thing I can say is that it âfeelsâ strange at the beginning⦠I am not used to this horizontal navigation⦠I am more used to spawning a lot of small inspectors that I can also use to compare things, i.e., one inspector close to the other.
Apart from that, Andrei told me it takes time but then you get used to it and you love it. Letâs see.
Cheers, R
On Dec 19, 2013, at 7:50 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I took a bit of time to describe how the GTInspector works, what makes it different, and to provide hints for several usage scenarios.
http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed
It's a long post, I know :), but please take a look. As you might know,
this is the default inspector in the Moose image, but it can also be loaded in a fresh Pharo image.
I am particularly interested in the following: - if you never used it, and tried it now, what don't you like? - if you used it, was there anything that you did not know? - and of course, what do you like about it?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
That is a good observation :). You do not like the underscore, or the "sel" entry? If you talk about the underscore, I just wanted a way to distinguish between special variables. You also see the same "notation" in the debugger (variables like _self and _thisContext). If you talk about the entry altogether, this part is more experimental. Some people did not like the printout in the comment, and then I added _self to show the print string next to it. I am still not decided on showing it. What do other think about it? Cheers, Doru On Thu, Dec 19, 2013 at 9:57 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Ah, yes, and I donât like the _self. Why would you want to do that ??
-- www.tudorgirba.com "Every thing has its own flow"
On 19 Dec 2013, at 22:26, Tudor Girba <tudor@tudorgirba.com> wrote:
That is a good observation :).
You do not like the underscore, or the "sel" entry?
If you talk about the underscore, I just wanted a way to distinguish between special variables. You also see the same "notation" in the debugger (variables like _self and _thisContext).
If you talk about the entry altogether, this part is more experimental. Some people did not like the printout in the comment, and then I added _self to show the print string next to it. I am still not decided on showing it. What do other think about it?
Cheers, Doru
I guess you need self for objects without instance variables. I donât like the underscore, every Smalltalker should know about self, super and thisContext. You could make them bold or italic or gray.
On Thu, Dec 19, 2013 at 9:57 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: Ah, yes, and I donât like the _self. Why would you want to do that ??
Hi Sven, I agree with the underscore point of view, and I like the idea of graying it out. I added an issue for it: https://code.google.com/p/moose-technology/issues/detail?id=1035 Cheers, Doru On Fri, Dec 20, 2013 at 2:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 Dec 2013, at 22:26, Tudor Girba <tudor@tudorgirba.com> wrote:
That is a good observation :).
You do not like the underscore, or the "sel" entry?
If you talk about the underscore, I just wanted a way to distinguish between special variables. You also see the same "notation" in the debugger (variables like _self and _thisContext).
If you talk about the entry altogether, this part is more experimental. Some people did not like the printout in the comment, and then I added _self to show the print string next to it. I am still not decided on showing it. What do other think about it?
Cheers, Doru
I guess you need self for objects without instance variables.
I donât like the underscore, every Smalltalker should know about self, super and thisContext. You could make them bold or italic or gray.
On Thu, Dec 19, 2013 at 9:57 PM, Sven Van Caekenberghe <sven@stfx.eu>
wrote:
Ah, yes, and I donât like the _self. Why would you want to do that ??
-- www.tudorgirba.com "Every thing has its own flow"
Hi Doru, On 19 Dec 2013, at 07:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I took a bit of time to describe how the GTInspector works, what makes it different, and to provide hints for several usage scenarios. http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed
It's a long post, I know :), but please take a look. As you might know, this is the default inspector in the Moose image, but it can also be loaded in a fresh Pharo image.
I am particularly interested in the following: - if you never used it, and tried it now, what don't you like? - if you used it, was there anything that you did not know? - and of course, what do you like about it?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
I read the blog post and installed the code in my working Pharo 3 image. First off, I like the debugger, it feels polished, and I like the inspector, it is quite interesting. The clear tables for instance variables names and values and dictionary keys and values are much better. SequenceableCollection indexes would be nice. Paging is cool. I miss an option to go back to less columns, like from 1 to 2 and back to 1, I canât seem to deselect something in the first one, which would be a way to let the second one disappear again. I hope I am making myself clear ;-) We have specialised inspectors for Integer and Float (and maybe some more) standard in Pharo, showing more high level virtual fields, it would be nice if you could implement those as well, maybe as alternative views. Which brings me to my final question: how do I write simple custom inspectors, given that I am not familiar with Glamour/Moose - that could maybe be another blog post ? Anyway, thanks for pushing this ! Sven PS: I wonder whether it would be possible to have both types of inspectors/debuggers available at the same time, so that one can switch on the fly, compare them, use one or the other depending on the task ? -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Hi Sven, On Thu, Dec 19, 2013 at 9:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Doru,
On 19 Dec 2013, at 07:50, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I took a bit of time to describe how the GTInspector works, what makes it different, and to provide hints for several usage scenarios.
http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed
It's a long post, I know :), but please take a look. As you might know,
this is the default inspector in the Moose image, but it can also be loaded in a fresh Pharo image.
I am particularly interested in the following: - if you never used it, and tried it now, what don't you like? - if you used it, was there anything that you did not know? - and of course, what do you like about it?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
I read the blog post and installed the code in my working Pharo 3 image. First off, I like the debugger, it feels polished,
Thanks. The debugger is particularly interesting when you get into supported specific cases. But, already Andrei and Alex worked on a cool extension for the debugger that highlights on the stack the entries that come from the same class or from the same package. This is quite educating. Both debugging and inspecting are so under developed that we have a ton of potential in front of us. But, let's talk about this in a separate thread :).
and I like the inspector, it is quite interesting. The clear tables for instance variables names and values and dictionary keys and values are much better.
Thanks.
SequenceableCollection indexes would be nice. Paging is cool.
What do you mean by indexes? The position of an item in the collection? I miss an option to go back to less columns, like from 1 to 2 and back to
1, I canât seem to deselect something in the first one, which would be a way to let the second one disappear again. I hope I am making myself clear ;-)
Yes, I agree. This is an extension I want for Glamour in general: to grow a pane to fill the window (similar to what happens in Eclipse). This will help you switch between floating navigation mode and more in-depth work mode.
We have specialised inspectors for Integer and Float (and maybe some more) standard in Pharo, showing more high level virtual fields, it would be nice if you could implement those as well, maybe as alternative views.
Certainly. That is the whole idea: create more dedicated presentations to serve dedicated use cases. I do not know the use case for this, but let's make an exercise out of it. Can you tell me what exactly would be interested in seeing? So, if you have an Integer or a Float what code would you like to trigger and have presented?
Which brings me to my final question: how do I write simple custom inspectors, given that I am not familiar with Glamour/Moose - that could maybe be another blog post ?
At the end of the post, there is a "Be moldable" section in which I am hinting at the process. Essentially, you have to extend your object with a method that follows this pattern: YourClass>>gtInspectorYourPresentationIn: composite <gtInspectorPresentationOrder: 30> composite "followed by Glamour code to construct presentations" The post shows this example: RGMethodDefinition>> gtInspectorSendersIn: composite <gtInspectorPresentationOrder: 30> composite list title: 'Senders'; display: [ self compiledMethod implementors ] So, to find more examples, simply search for senders of #gtInspectorPresentationOrder: (or just inspect the symbol to see what happens :)), and you will see all extensions in the image. I would like to make all presentation tabs to give you the possibility to jump to the implementation so that you can see more examples (like with halos). In any case, I will write another post with some more implementation examples.
Anyway, thanks for pushing this !
Thanks for looking into it :) Sven
PS: I wonder whether it would be possible to have both types of inspectors/debuggers available at the same time, so that one can switch on the fly, compare them, use one or the other depending on the task ?
Marcus says that there is an intention of having multiple alternative tools be described via pragmas and be switchable from the settings browser. However, I am not really convinced this is the way to go. I would be more interested in what does not work to make one work smoothly. But, besides the Float and Integer views, do you happen to have something else that you cannot do as easily with the GTInspector? Cheers, Doru --
Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
-- www.tudorgirba.com "Every thing has its own flow"
On 19 Dec 2013, at 22:08, Tudor Girba <tudor@tudorgirba.com> wrote:
SequenceableCollection indexes would be nice. Paging is cool.
What do you mean by indexes? The position of an item in the collection?
Yes,
I miss an option to go back to less columns, like from 1 to 2 and back to 1, I canât seem to deselect something in the first one, which would be a way to let the second one disappear again. I hope I am making myself clear ;-)
Yes, I agree. This is an extension I want for Glamour in general: to grow a pane to fill the window (similar to what happens in Eclipse). This will help you switch between floating navigation mode and more in-depth work mode.
That would be cool.
We have specialised inspectors for Integer and Float (and maybe some more) standard in Pharo, showing more high level virtual fields, it would be nice if you could implement those as well, maybe as alternative views.
Certainly. That is the whole idea: create more dedicated presentations to serve dedicated use cases. I do not know the use case for this, but let's make an exercise out of it. Can you tell me what exactly would be interested in seeing? So, if you have an Integer or a Float what code would you like to trigger and have presented?
Some of this got lost when EyeInspector got introduced, here are some screenshots from an older image: I can think of alternative representations for lots of classes.
Which brings me to my final question: how do I write simple custom inspectors, given that I am not familiar with Glamour/Moose - that could maybe be another blog post ?
At the end of the post, there is a "Be moldable" section in which I am hinting at the process. Essentially, you have to extend your object with a method that follows this pattern:
YourClass>>gtInspectorYourPresentationIn: composite <gtInspectorPresentationOrder: 30> composite "followed by Glamour code to construct presentations"
The post shows this example: RGMethodDefinition>> gtInspectorSendersIn: composite <gtInspectorPresentationOrder: 30> composite list title: 'Senders'; display: [ self compiledMethod implementors ]
So, to find more examples, simply search for senders of #gtInspectorPresentationOrder: (or just inspect the symbol to see what happens :)), and you will see all extensions in the image.
I would like to make all presentation tabs to give you the possibility to jump to the implementation so that you can see more examples (like with halos). In any case, I will write another post with some more implementation examples.
Yes, I read everything, and I did some code reading, but I felt a bit helpless ;-)
Anyway, thanks for pushing this !
Thanks for looking into it :)
Sven
PS: I wonder whether it would be possible to have both types of inspectors/debuggers available at the same time, so that one can switch on the fly, compare them, use one or the other depending on the task ?
Marcus says that there is an intention of having multiple alternative tools be described via pragmas and be switchable from the settings browser. However, I am not really convinced this is the way to go. I would be more interested in what does not work to make one work smoothly.
I donât mean switching using a Setting (although that would be good to have too), I meant command-i for normal inspectors, command-shift-i for GT inspectors, or something like that.
Hi Sven, Thanks for the suggestions. Integer and Float now have specific extensions to the State presentation. [image: Inline image 3] [image: Inline image 1] You can see more details about how this works here: http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspect... Cheers, Doru
Also, as you pointed out, it is indeed better for a SequenceableCollection to show the indexes for each item. So, now the inspector shows it as well. [image: Inline image 1] Cheers, Doru On Sat, Dec 21, 2013 at 11:45 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Sven,
Thanks for the suggestions. Integer and Float now have specific extensions to the State presentation.
[image: Inline image 3]
[image: Inline image 1]
You can see more details about how this works here:
http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspect...
Cheers, Doru
-- www.tudorgirba.com "Every thing has its own flow"
participants (3)
-
roberto.minelli@usi.ch -
Sven Van Caekenberghe -
Tudor Girba