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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |