newinspector?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

newinspector?

Stéphane Ducasse
Hi guys

again I did a demo of smalltalk and the newInspecotr got in my way.
I tried to analyze what did not work:
        - apparently the refresh does not work. Does change in instance variables get refreshed in the inspector?

I try to understand what get in my way in general.
        - when an object has few instance variable I think that it is lost in the sea of trees.

        - I think that the |> class is not useful at the top level.
        May be just having Class: and the class Name is enough no need for the |>
        May be the Class : ByteString should appear after the Elements:

        - the |> methods to be useful should be sorted by category
       
in the screenshot
        Why do I see the instance variable of the  dictionary (array and tally) I find that confusing?
        Because I get elements and at the same time the instance variables.

        I do not understand why some lines are bold and other blue

        When we click on connectInfo I see on the right pane
                - size : 5
                [#host] : a SocketAddress (size: 24)
                [#loginMethod] : #zork
                [#password] : nil
                [#port] : 110
                [#user] : 'stephane.ducasse'
        But I cannot modify anything.

        What is the point to have Elements expanded in the left pane when I get the contents by clicking on the instance
        variable and getting the contents on the right.

        Then Keys should probably close to Elements.

        I do not see the point to have |> for individual method
        I do not understand why we see Elements and ByteCode
                I get a DNU when I click on Elements of a method BTW


       
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Screen shot 2009-11-26 at 6.14.31 PM.png (95K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newinspector?

Adrian Lienhard
Just yesterday, I asked Frederic to remove the class and method  
entries that add a lot of the noise and are most often not needed. He  
committed a new version with these changes.

But from Stef's analysis it seems there is a bit more needed to make  
this inspector fly... And a really good inspector is key!

Another item to add to Stef's list: what is the point of the item  
"Keys"? I can see the keys of the dictionary already by opening  
"Elements". So this seems superfluous.

I wonder why inspecting a dictionary could not be reduced to the  
information that is actually of interest, namely the keys and their  
values. So when opening a dictionary, the subtree would directly  
display the keys in the left pane (no array, tally, Keys, Elements).  
If a key is selected, its value is printed in the right pane.  
Expanding a key would dive into its associated value. Actually, I  
think what I described here is more or less the behavior of the old  
explore tool.

Cheers,
Adrian


On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote:

> Hi guys
>
> again I did a demo of smalltalk and the newInspecotr got in my way.
> I tried to analyze what did not work:
> - apparently the refresh does not work. Does change in instance  
> variables get refreshed in the inspector?
>
> I try to understand what get in my way in general.
> - when an object has few instance variable I think that it is lost  
> in the sea of trees.
>
> - I think that the |> class is not useful at the top level.
> May be just having Class: and the class Name is enough no need for  
> the |>
> May be the Class : ByteString should appear after the Elements:
>
> - the |> methods to be useful should be sorted by category
>
> in the screenshot
> Why do I see the instance variable of the  dictionary (array and  
> tally) I find that confusing?
> Because I get elements and at the same time the instance variables.
>
> I do not understand why some lines are bold and other blue
>
> When we click on connectInfo I see on the right pane
> - size : 5
> [#host] : a SocketAddress (size: 24)
> [#loginMethod] : #zork
> [#password] : nil
> [#port] : 110
> [#user] : 'stephane.ducasse'
> But I cannot modify anything.
>
> What is the point to have Elements expanded in the left pane when I  
> get the contents by clicking on the instance
> variable and getting the contents on the right.
>
> Then Keys should probably close to Elements.
>
> I do not see the point to have |> for individual method
> I do not understand why we see Elements and ByteCode
> I get a DNU when I click on Elements of a method BTW
>
>
> <Screen shot 2009-11-26 at 6.14.31  
> PM.png>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: newinspector?

Stéphane Ducasse
Ok I will check.
may be we can have a mode that does not provide object interpretation (for dict we would only see
tally and array not the dictionary, ...).

Stef

On Nov 26, 2009, at 7:40 PM, Adrian Lienhard wrote:

> Just yesterday, I asked Frederic to remove the class and method  
> entries that add a lot of the noise and are most often not needed. He  
> committed a new version with these changes.
>
> But from Stef's analysis it seems there is a bit more needed to make  
> this inspector fly... And a really good inspector is key!
>
> Another item to add to Stef's list: what is the point of the item  
> "Keys"? I can see the keys of the dictionary already by opening  
> "Elements". So this seems superfluous.
>
> I wonder why inspecting a dictionary could not be reduced to the  
> information that is actually of interest, namely the keys and their  
> values. So when opening a dictionary, the subtree would directly  
> display the keys in the left pane (no array, tally, Keys, Elements).  
> If a key is selected, its value is printed in the right pane.  
> Expanding a key would dive into its associated value. Actually, I  
> think what I described here is more or less the behavior of the old  
> explore tool.
>
> Cheers,
> Adrian
>
>
> On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> again I did a demo of smalltalk and the newInspecotr got in my way.
>> I tried to analyze what did not work:
>> - apparently the refresh does not work. Does change in instance  
>> variables get refreshed in the inspector?
>>
>> I try to understand what get in my way in general.
>> - when an object has few instance variable I think that it is lost  
>> in the sea of trees.
>>
>> - I think that the |> class is not useful at the top level.
>> May be just having Class: and the class Name is enough no need for  
>> the |>
>> May be the Class : ByteString should appear after the Elements:
>>
>> - the |> methods to be useful should be sorted by category
>>
>> in the screenshot
>> Why do I see the instance variable of the  dictionary (array and  
>> tally) I find that confusing?
>> Because I get elements and at the same time the instance variables.
>>
>> I do not understand why some lines are bold and other blue
>>
>> When we click on connectInfo I see on the right pane
>> - size : 5
>> [#host] : a SocketAddress (size: 24)
>> [#loginMethod] : #zork
>> [#password] : nil
>> [#port] : 110
>> [#user] : 'stephane.ducasse'
>> But I cannot modify anything.
>>
>> What is the point to have Elements expanded in the left pane when I  
>> get the contents by clicking on the instance
>> variable and getting the contents on the right.
>>
>> Then Keys should probably close to Elements.
>>
>> I do not see the point to have |> for individual method
>> I do not understand why we see Elements and ByteCode
>> I get a DNU when I click on Elements of a method BTW
>>
>>
>> <Screen shot 2009-11-26 at 6.14.31  
>> PM.png>_______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: newinspector?

Peter Hugosson-Miller
Rather than a mode for inspecting dictionaries, wouldn't it be better  
to have a subclass, say DictionaryInspector, which could be selected  
as needed by means of an #inspectorClass method. Then, if more  
specializations turn up, they could be added in the same way.

Just a thought that struck me.

--
Cheers,
Peter.

On 26 nov 2009, at 20.01, Stéphane Ducasse <[hidden email]>  
wrote:

> Ok I will check.
> may be we can have a mode that does not provide object  
> interpretation (for dict we would only see
> tally and array not the dictionary, ...).
>
> Stef
>
> On Nov 26, 2009, at 7:40 PM, Adrian Lienhard wrote:
>
>> Just yesterday, I asked Frederic to remove the class and method
>> entries that add a lot of the noise and are most often not needed. He
>> committed a new version with these changes.
>>
>> But from Stef's analysis it seems there is a bit more needed to make
>> this inspector fly... And a really good inspector is key!
>>
>> Another item to add to Stef's list: what is the point of the item
>> "Keys"? I can see the keys of the dictionary already by opening
>> "Elements". So this seems superfluous.
>>
>> I wonder why inspecting a dictionary could not be reduced to the
>> information that is actually of interest, namely the keys and their
>> values. So when opening a dictionary, the subtree would directly
>> display the keys in the left pane (no array, tally, Keys, Elements).
>> If a key is selected, its value is printed in the right pane.
>> Expanding a key would dive into its associated value. Actually, I
>> think what I described here is more or less the behavior of the old
>> explore tool.
>>
>> Cheers,
>> Adrian
>>
>>
>> On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote:
>>
>>> Hi guys
>>>
>>> again I did a demo of smalltalk and the newInspecotr got in my way.
>>> I tried to analyze what did not work:
>>>    - apparently the refresh does not work. Does change in instance
>>> variables get refreshed in the inspector?
>>>
>>> I try to understand what get in my way in general.
>>>    - when an object has few instance variable I think that it is  
>>> lost
>>> in the sea of trees.
>>>
>>>    - I think that the |> class is not useful at the top level.
>>>    May be just having Class: and the class Name is enough no need  
>>> for
>>> the |>
>>>    May be the Class : ByteString should appear after the Elements:
>>>
>>>    - the |> methods to be useful should be sorted by category
>>>
>>> in the screenshot
>>>    Why do I see the instance variable of the  dictionary (array and
>>> tally) I find that confusing?
>>>    Because I get elements and at the same time the instance  
>>> variables.
>>>
>>>    I do not understand why some lines are bold and other blue
>>>
>>>    When we click on connectInfo I see on the right pane
>>>        - size : 5
>>>        [#host] : a SocketAddress (size: 24)
>>>        [#loginMethod] : #zork
>>>        [#password] : nil
>>>        [#port] : 110
>>>        [#user] : 'stephane.ducasse'
>>>    But I cannot modify anything.
>>>
>>>    What is the point to have Elements expanded in the left pane  
>>> when I
>>> get the contents by clicking on the instance
>>>    variable and getting the contents on the right.
>>>
>>>    Then Keys should probably close to Elements.
>>>
>>>    I do not see the point to have |> for individual method
>>>    I do not understand why we see Elements and ByteCode
>>>        I get a DNU when I click on Elements of a method BTW
>>>
>>>
>>>    <Screen shot 2009-11-26 at 6.14.31
>>> PM.png>_______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: newinspector?

Stéphane Ducasse
this is probably like that
but you may want to be able to swicth (ie inspect dictionary as default objects.)

On Nov 26, 2009, at 8:11 PM, Peter Hugosson-Miller wrote:

> Rather than a mode for inspecting dictionaries, wouldn't it be better  
> to have a subclass, say DictionaryInspector, which could be selected  
> as needed by means of an #inspectorClass method. Then, if more  
> specializations turn up, they could be added in the same way.
>
> Just a thought that struck me.
>
> --
> Cheers,
> Peter.
>
> On 26 nov 2009, at 20.01, Stéphane Ducasse <[hidden email]>  
> wrote:
>
>> Ok I will check.
>> may be we can have a mode that does not provide object  
>> interpretation (for dict we would only see
>> tally and array not the dictionary, ...).
>>
>> Stef
>>
>> On Nov 26, 2009, at 7:40 PM, Adrian Lienhard wrote:
>>
>>> Just yesterday, I asked Frederic to remove the class and method
>>> entries that add a lot of the noise and are most often not needed. He
>>> committed a new version with these changes.
>>>
>>> But from Stef's analysis it seems there is a bit more needed to make
>>> this inspector fly... And a really good inspector is key!
>>>
>>> Another item to add to Stef's list: what is the point of the item
>>> "Keys"? I can see the keys of the dictionary already by opening
>>> "Elements". So this seems superfluous.
>>>
>>> I wonder why inspecting a dictionary could not be reduced to the
>>> information that is actually of interest, namely the keys and their
>>> values. So when opening a dictionary, the subtree would directly
>>> display the keys in the left pane (no array, tally, Keys, Elements).
>>> If a key is selected, its value is printed in the right pane.
>>> Expanding a key would dive into its associated value. Actually, I
>>> think what I described here is more or less the behavior of the old
>>> explore tool.
>>>
>>> Cheers,
>>> Adrian
>>>
>>>
>>> On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote:
>>>
>>>> Hi guys
>>>>
>>>> again I did a demo of smalltalk and the newInspecotr got in my way.
>>>> I tried to analyze what did not work:
>>>>   - apparently the refresh does not work. Does change in instance
>>>> variables get refreshed in the inspector?
>>>>
>>>> I try to understand what get in my way in general.
>>>>   - when an object has few instance variable I think that it is  
>>>> lost
>>>> in the sea of trees.
>>>>
>>>>   - I think that the |> class is not useful at the top level.
>>>>   May be just having Class: and the class Name is enough no need  
>>>> for
>>>> the |>
>>>>   May be the Class : ByteString should appear after the Elements:
>>>>
>>>>   - the |> methods to be useful should be sorted by category
>>>>
>>>> in the screenshot
>>>>   Why do I see the instance variable of the  dictionary (array and
>>>> tally) I find that confusing?
>>>>   Because I get elements and at the same time the instance  
>>>> variables.
>>>>
>>>>   I do not understand why some lines are bold and other blue
>>>>
>>>>   When we click on connectInfo I see on the right pane
>>>>       - size : 5
>>>>       [#host] : a SocketAddress (size: 24)
>>>>       [#loginMethod] : #zork
>>>>       [#password] : nil
>>>>       [#port] : 110
>>>>       [#user] : 'stephane.ducasse'
>>>>   But I cannot modify anything.
>>>>
>>>>   What is the point to have Elements expanded in the left pane  
>>>> when I
>>>> get the contents by clicking on the instance
>>>>   variable and getting the contents on the right.
>>>>
>>>>   Then Keys should probably close to Elements.
>>>>
>>>>   I do not see the point to have |> for individual method
>>>>   I do not understand why we see Elements and ByteCode
>>>>       I get a DNU when I click on Elements of a method BTW
>>>>
>>>>
>>>>   <Screen shot 2009-11-26 at 6.14.31
>>>> PM.png>_______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: newinspector?

Adrian Lienhard
In reply to this post by Adrian Lienhard
Hi Frederic,

I just run into a problem: clicking on Elements of a NewInspector on a  
CompiledMethod gives an error: 'CompiledMethods may only be created  
with newMethod:header:'

Shall I create an issue in the Pharo tracker?

Adrian

On Nov 26, 2009, at 19:40 , Adrian Lienhard wrote:

> Just yesterday, I asked Frederic to remove the class and method
> entries that add a lot of the noise and are most often not needed. He
> committed a new version with these changes.
>
> But from Stef's analysis it seems there is a bit more needed to make
> this inspector fly... And a really good inspector is key!
>
> Another item to add to Stef's list: what is the point of the item
> "Keys"? I can see the keys of the dictionary already by opening
> "Elements". So this seems superfluous.
>
> I wonder why inspecting a dictionary could not be reduced to the
> information that is actually of interest, namely the keys and their
> values. So when opening a dictionary, the subtree would directly
> display the keys in the left pane (no array, tally, Keys, Elements).
> If a key is selected, its value is printed in the right pane.
> Expanding a key would dive into its associated value. Actually, I
> think what I described here is more or less the behavior of the old
> explore tool.
>
> Cheers,
> Adrian
>
>
> On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> again I did a demo of smalltalk and the newInspecotr got in my way.
>> I tried to analyze what did not work:
>> - apparently the refresh does not work. Does change in instance
>> variables get refreshed in the inspector?
>>
>> I try to understand what get in my way in general.
>> - when an object has few instance variable I think that it is lost
>> in the sea of trees.
>>
>> - I think that the |> class is not useful at the top level.
>> May be just having Class: and the class Name is enough no need for
>> the |>
>> May be the Class : ByteString should appear after the Elements:
>>
>> - the |> methods to be useful should be sorted by category
>>
>> in the screenshot
>> Why do I see the instance variable of the  dictionary (array and
>> tally) I find that confusing?
>> Because I get elements and at the same time the instance variables.
>>
>> I do not understand why some lines are bold and other blue
>>
>> When we click on connectInfo I see on the right pane
>> - size : 5
>> [#host] : a SocketAddress (size: 24)
>> [#loginMethod] : #zork
>> [#password] : nil
>> [#port] : 110
>> [#user] : 'stephane.ducasse'
>> But I cannot modify anything.
>>
>> What is the point to have Elements expanded in the left pane when I
>> get the contents by clicking on the instance
>> variable and getting the contents on the right.
>>
>> Then Keys should probably close to Elements.
>>
>> I do not see the point to have |> for individual method
>> I do not understand why we see Elements and ByteCode
>> I get a DNU when I click on Elements of a method BTW
>>
>>
>> <Screen shot 2009-11-26 at 6.14.31
>> PM.png>_______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: newinspector?

Adrian Lienhard
Great, thanks!
Adrian

On Dec 4, 2009, at 13:07 , Frederic Pluquet wrote:

> Hello Adrian,
>
> I deleted the Elements child in CompiledMethod (it had no sense in
> CompiledMethod).
> I added also added a literals child to inspect CompiledMethod literals
> easily.
>
> Fréd
> ----
> Frédéric Pluquet
> Université Libre de Bruxelles (ULB)
> Assistant
> http://www.ulb.ac.be/di/fpluquet
>
>
> On Thu, Dec 3, 2009 at 9:44 PM, Adrian Lienhard <[hidden email]>  
> wrote:
>
>> Hi Frederic,
>>
>> I just run into a problem: clicking on Elements of a NewInspector  
>> on a
>> CompiledMethod gives an error: 'CompiledMethods may only be created  
>> with
>> newMethod:header:'
>>
>> Shall I create an issue in the Pharo tracker?
>>
>> Adrian
>>
>>
>> On Nov 26, 2009, at 19:40 , Adrian Lienhard wrote:
>>
>> Just yesterday, I asked Frederic to remove the class and method
>>> entries that add a lot of the noise and are most often not needed.  
>>> He
>>> committed a new version with these changes.
>>>
>>> But from Stef's analysis it seems there is a bit more needed to make
>>> this inspector fly... And a really good inspector is key!
>>>
>>> Another item to add to Stef's list: what is the point of the item
>>> "Keys"? I can see the keys of the dictionary already by opening
>>> "Elements". So this seems superfluous.
>>>
>>> I wonder why inspecting a dictionary could not be reduced to the
>>> information that is actually of interest, namely the keys and their
>>> values. So when opening a dictionary, the subtree would directly
>>> display the keys in the left pane (no array, tally, Keys, Elements).
>>> If a key is selected, its value is printed in the right pane.
>>> Expanding a key would dive into its associated value. Actually, I
>>> think what I described here is more or less the behavior of the old
>>> explore tool.
>>>
>>> Cheers,
>>> Adrian
>>>
>>>
>>> On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote:
>>>
>>> Hi guys
>>>>
>>>> again I did a demo of smalltalk and the newInspecotr got in my way.
>>>> I tried to analyze what did not work:
>>>>       - apparently the refresh does not work. Does change in  
>>>> instance
>>>> variables get refreshed in the inspector?
>>>>
>>>> I try to understand what get in my way in general.
>>>>       - when an object has few instance variable I think that it  
>>>> is lost
>>>> in the sea of trees.
>>>>
>>>>       - I think that the |> class is not useful at the top level.
>>>>       May be just having Class: and the class Name is enough no  
>>>> need for
>>>> the |>
>>>>       May be the Class : ByteString should appear after the  
>>>> Elements:
>>>>
>>>>       - the |> methods to be useful should be sorted by category
>>>>
>>>> in the screenshot
>>>>       Why do I see the instance variable of the  dictionary  
>>>> (array and
>>>> tally) I find that confusing?
>>>>       Because I get elements and at the same time the instance
>>>> variables.
>>>>
>>>>       I do not understand why some lines are bold and other blue
>>>>
>>>>       When we click on connectInfo I see on the right pane
>>>>               - size : 5
>>>>               [#host] : a SocketAddress (size: 24)
>>>>               [#loginMethod] : #zork
>>>>               [#password] : nil
>>>>               [#port] : 110
>>>>               [#user] : 'stephane.ducasse'
>>>>       But I cannot modify anything.
>>>>
>>>>       What is the point to have Elements expanded in the left  
>>>> pane when
>>>> I
>>>> get the contents by clicking on the instance
>>>>       variable and getting the contents on the right.
>>>>
>>>>       Then Keys should probably close to Elements.
>>>>
>>>>       I do not see the point to have |> for individual method
>>>>       I do not understand why we see Elements and ByteCode
>>>>               I get a DNU when I click on Elements of a method BTW
>>>>
>>>>
>>>>       <Screen shot 2009-11-26 at 6.14.31
>>>> PM.png>_______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project