- Pharo-users - lists.pharo.org

Re: [Pharo-users] Playgound inspecting

by Tudor Girba

Hi Nicolai, > On Apr 27, 2016, at 11:12 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-04-27 23:07 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 27/04/2016 22:55, Esteban Lorenzano a Ã©crit : > > On 27 Apr 2016, at 22:52, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Doru, > > Le 27/04/2016 22:38, Tudor Girba a Ã©crit : > Hi, > > On Apr 27, 2016, at 10:17 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 27/04/2016 21:26, Hilaire a Ã©crit : > Now I remember I already asked several months ago, and it does not > work. > > Editing on the value does not work for me. > > http://forum.world.st/GL-inspector-editing-attribute-td4837704.html > > The same mis fortune is encountered with Pharo5 > > I don't imagine how it can be like that and I fell unproductive now > with > Playground and GTInspector, althought I acknowledge there are nice > ideas > in these new tools but it can't be at the price of productivity. > > Hopefully you can switch to Workspace and EyeInspector. > > With the help of Nicolai Hess, we worked a bit on improving syntax > colouring for the EyeInspector and this has been integrated. Maybe > someone can look into doing the same with GT (to correctly set > #doItReceiver, #doItContext and a few other things related to syntax > highlighting). > > What exactly is the problem in GT regarding syntax highlighting? > > If you inspect a morph (say GTInspector inspect: Morph new), when you > type bounds (one of Morph instance variables) in the text pane below, > you get a red == erroneous / undefined var. > > but thatâs not a syntax highlighting problem: is a bindings problem :P > > both > > binding, because glamours smalltalk code mode automatically creates bindings (when OCASTSemantic analyzer tries to > lookup a variable) (see glamours workspacebinding strategy) > > and styling > because for a "raw"-tab inspector pane, glamour does not set the classOrMetaClass attribute of the styler. I am looking at this issue right now: https://pharo.fogbugz.com/f/cases/17948/Bindings-in-the-evaluator-pane-in-I… Could you explain why setting the classOrMetaClass is important in this context if we add the bindings to the instance variables? Cheers, Doru > > I can let you try to solve it by playing with the bindings ;) > > Thierry > > Esteban > > > In the latest 5.0, in EyeInspector, it will correctly highlight bounds > as a defined variable. > > Moreover, and the source of the first complaint, in GTInspector, > inspecting bounds will give a nil answer instead of the morph bounds. > Whereas EyeInspector will properly answer (0@0) corner: (50@40). > > Thierry > > Cheers, > Doru > > > By the way, would someone know how to force the styler to re-style a > text? When selecting another element in for example a > EyeTreeInspector, this changes the reference class for syntax > highlighting (and the styler correctly picks that) but the existing > text isn't re-colored. > > Thierry > > > Hilaire > > > Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : > HilaireFernandes wrote > instance variables evaluate to nil in the bottom area of the > integrated > inspector. > There is no direct inst var access from the playground. I was > initially > shocked by this as well and have had to resort to #instVarNamed: > on several > occasions. On the bright side, you can edit the values in place in the > 'Value' column above. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "Value is always contextual." -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

April 28, 2016

Re: [Pharo-users] Playgound inspecting

by Thierry Goubier

Le 27/04/2016 23:12, Nicolai Hess a Ã©crit : > > > 2016-04-27 23:07 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > Le 27/04/2016 22:55, Esteban Lorenzano a Ã©crit : > > > On 27 Apr 2016, at 22:52, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>> wrote: > > Hi Doru, > > Le 27/04/2016 22:38, Tudor Girba a Ã©crit : > > Hi, > > On Apr 27, 2016, at 10:17 PM, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>> wrote: > > Le 27/04/2016 21:26, Hilaire a Ã©crit : > > Now I remember I already asked several months > ago, and it does not > work. > > Editing on the value does not work for me. > > http://forum.world.st/GL-inspector-editing-attribute-td4837704.html > > The same mis fortune is encountered with Pharo5 > > I don't imagine how it can be like that and I > fell unproductive now > with > Playground and GTInspector, althought I > acknowledge there are nice > ideas > in these new tools but it can't be at the price > of productivity. > > Hopefully you can switch to Workspace and > EyeInspector. > > > With the help of Nicolai Hess, we worked a bit on > improving syntax > colouring for the EyeInspector and this has been > integrated. Maybe > someone can look into doing the same with GT (to > correctly set > #doItReceiver, #doItContext and a few other things > related to syntax > highlighting). > > > What exactly is the problem in GT regarding syntax > highlighting? > > > If you inspect a morph (say GTInspector inspect: Morph new), > when you > type bounds (one of Morph instance variables) in the text > pane below, > you get a red == erroneous / undefined var. > > > but thatâs not a syntax highlighting problem: is a bindings > problem :P > > > both > > binding, because glamours smalltalk code mode automatically creates > bindings (when OCASTSemantic analyzer tries to > lookup a variable) (see glamours workspacebinding strategy) Ah, this feature in that context is interesting... At first, in our Morph example with bounds you get an undefined binding; and then, when you do it, it becomes a binding, so no more red, but it then masks the Morph instance bounds. Challenging to explain, that one :) Thierry > and styling > because for a "raw"-tab inspector pane, glamour does not set the > classOrMetaClass attribute of the styler. > > > I can let you try to solve it by playing with the bindings ;) > > Thierry > > Esteban > > > In the latest 5.0, in EyeInspector, it will correctly > highlight bounds > as a defined variable. > > Moreover, and the source of the first complaint, in GTInspector, > inspecting bounds will give a nil answer instead of the > morph bounds. > Whereas EyeInspector will properly answer (0@0) corner: (50@40). > > Thierry > > Cheers, > Doru > > > By the way, would someone know how to force the > styler to re-style a > text? When selecting another element in for example a > EyeTreeInspector, this changes the reference class > for syntax > highlighting (and the styler correctly picks that) > but the existing > text isn't re-colored. > > Thierry > > > Hilaire > > > Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : > > HilaireFernandes wrote > > instance variables evaluate to nil > in the bottom area of the > integrated > inspector. > > There is no direct inst var access from the > playground. I was > initially > shocked by this as well and have had to > resort to #instVarNamed: > on several > occasions. On the bright side, you can edit > the values in place in the > 'Value' column above. > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Value is always contextual." > > > > >

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Nicolai Hess

2016-04-27 23:07 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 27/04/2016 22:55, Esteban Lorenzano a Ã©crit : > >> >> On 27 Apr 2016, at 22:52, Thierry Goubier <thierry.goubier(a)gmail.com >>> <mailto:thierry.goubier@gmail.com>> wrote: >>> >>> Hi Doru, >>> >>> Le 27/04/2016 22:38, Tudor Girba a Ã©crit : >>> >>>> Hi, >>>> >>>> On Apr 27, 2016, at 10:17 PM, Thierry Goubier >>>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>>>> >>>>> Le 27/04/2016 21:26, Hilaire a Ã©crit : >>>>> >>>>>> Now I remember I already asked several months ago, and it does not >>>>>> work. >>>>>> >>>>>> Editing on the value does not work for me. >>>>>> >>>>>> http://forum.world.st/GL-inspector-editing-attribute-td4837704.html >>>>>> >>>>>> The same mis fortune is encountered with Pharo5 >>>>>> >>>>>> I don't imagine how it can be like that and I fell unproductive now >>>>>> with >>>>>> Playground and GTInspector, althought I acknowledge there are nice >>>>>> ideas >>>>>> in these new tools but it can't be at the price of productivity. >>>>>> >>>>>> Hopefully you can switch to Workspace and EyeInspector. >>>>>> >>>>> >>>>> With the help of Nicolai Hess, we worked a bit on improving syntax >>>>> colouring for the EyeInspector and this has been integrated. Maybe >>>>> someone can look into doing the same with GT (to correctly set >>>>> #doItReceiver, #doItContext and a few other things related to syntax >>>>> highlighting). >>>>> >>>> >>>> What exactly is the problem in GT regarding syntax highlighting? >>>> >>> >>> If you inspect a morph (say GTInspector inspect: Morph new), when you >>> type bounds (one of Morph instance variables) in the text pane below, >>> you get a red == erroneous / undefined var. >>> >> >> but thatâs not a syntax highlighting problem: is a bindings problem :P >> > both binding, because glamours smalltalk code mode automatically creates bindings (when OCASTSemantic analyzer tries to lookup a variable) (see glamours workspacebinding strategy) and styling because for a "raw"-tab inspector pane, glamour does not set the classOrMetaClass attribute of the styler. > > I can let you try to solve it by playing with the bindings ;) > > Thierry > > Esteban >> >> >>> In the latest 5.0, in EyeInspector, it will correctly highlight bounds >>> as a defined variable. >>> >>> Moreover, and the source of the first complaint, in GTInspector, >>> inspecting bounds will give a nil answer instead of the morph bounds. >>> Whereas EyeInspector will properly answer (0@0) corner: (50@40). >>> >>> Thierry >>> >>> Cheers, >>>> Doru >>>> >>>> >>>> By the way, would someone know how to force the styler to re-style a >>>>> text? When selecting another element in for example a >>>>> EyeTreeInspector, this changes the reference class for syntax >>>>> highlighting (and the styler correctly picks that) but the existing >>>>> text isn't re-colored. >>>>> >>>>> Thierry >>>>> >>>>> >>>>>> Hilaire >>>>>> >>>>>> >>>>>> Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >>>>>> >>>>>>> HilaireFernandes wrote >>>>>>> >>>>>>>> instance variables evaluate to nil in the bottom area of the >>>>>>>>> integrated >>>>>>>>> inspector. >>>>>>>>> >>>>>>>> There is no direct inst var access from the playground. I was >>>>>>> initially >>>>>>> shocked by this as well and have had to resort to #instVarNamed: >>>>>>> on several >>>>>>> occasions. On the bright side, you can edit the values in place in >>>>>>> the >>>>>>> 'Value' column above. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> -- >>>> www.tudorgirba.com <http://www.tudorgirba.com> >>>> www.feenk.com >>>> >>>> "Value is always contextual." >>>> >>> >> > >

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Thierry Goubier

Le 27/04/2016 22:55, Esteban Lorenzano a Ã©crit : > >> On 27 Apr 2016, at 22:52, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Doru, >> >> Le 27/04/2016 22:38, Tudor Girba a Ã©crit : >>> Hi, >>> >>>> On Apr 27, 2016, at 10:17 PM, Thierry Goubier >>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>>> >>>> Le 27/04/2016 21:26, Hilaire a Ã©crit : >>>>> Now I remember I already asked several months ago, and it does not >>>>> work. >>>>> >>>>> Editing on the value does not work for me. >>>>> >>>>> http://forum.world.st/GL-inspector-editing-attribute-td4837704.html >>>>> >>>>> The same mis fortune is encountered with Pharo5 >>>>> >>>>> I don't imagine how it can be like that and I fell unproductive now >>>>> with >>>>> Playground and GTInspector, althought I acknowledge there are nice >>>>> ideas >>>>> in these new tools but it can't be at the price of productivity. >>>>> >>>>> Hopefully you can switch to Workspace and EyeInspector. >>>> >>>> With the help of Nicolai Hess, we worked a bit on improving syntax >>>> colouring for the EyeInspector and this has been integrated. Maybe >>>> someone can look into doing the same with GT (to correctly set >>>> #doItReceiver, #doItContext and a few other things related to syntax >>>> highlighting). >>> >>> What exactly is the problem in GT regarding syntax highlighting? >> >> If you inspect a morph (say GTInspector inspect: Morph new), when you >> type bounds (one of Morph instance variables) in the text pane below, >> you get a red == erroneous / undefined var. > > but thatâs not a syntax highlighting problem: is a bindings problem :P I can let you try to solve it by playing with the bindings ;) Thierry > Esteban > >> >> In the latest 5.0, in EyeInspector, it will correctly highlight bounds >> as a defined variable. >> >> Moreover, and the source of the first complaint, in GTInspector, >> inspecting bounds will give a nil answer instead of the morph bounds. >> Whereas EyeInspector will properly answer (0@0) corner: (50@40). >> >> Thierry >> >>> Cheers, >>> Doru >>> >>> >>>> By the way, would someone know how to force the styler to re-style a >>>> text? When selecting another element in for example a >>>> EyeTreeInspector, this changes the reference class for syntax >>>> highlighting (and the styler correctly picks that) but the existing >>>> text isn't re-colored. >>>> >>>> Thierry >>>> >>>>> >>>>> Hilaire >>>>> >>>>> >>>>> Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >>>>>> HilaireFernandes wrote >>>>>>>> instance variables evaluate to nil in the bottom area of the >>>>>>>> integrated >>>>>>>> inspector. >>>>>> There is no direct inst var access from the playground. I was >>>>>> initially >>>>>> shocked by this as well and have had to resort to #instVarNamed: >>>>>> on several >>>>>> occasions. On the bright side, you can edit the values in place in the >>>>>> 'Value' column above. >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> www.feenk.com >>> >>> "Value is always contextual." >

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Esteban Lorenzano

> On 27 Apr 2016, at 22:52, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Doru, > > Le 27/04/2016 22:38, Tudor Girba a Ã©crit : >> Hi, >> >>> On Apr 27, 2016, at 10:17 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Le 27/04/2016 21:26, Hilaire a Ã©crit : >>>> Now I remember I already asked several months ago, and it does not work. >>>> >>>> Editing on the value does not work for me. >>>> >>>> http://forum.world.st/GL-inspector-editing-attribute-td4837704.html >>>> >>>> The same mis fortune is encountered with Pharo5 >>>> >>>> I don't imagine how it can be like that and I fell unproductive now with >>>> Playground and GTInspector, althought I acknowledge there are nice ideas >>>> in these new tools but it can't be at the price of productivity. >>>> >>>> Hopefully you can switch to Workspace and EyeInspector. >>> >>> With the help of Nicolai Hess, we worked a bit on improving syntax colouring for the EyeInspector and this has been integrated. Maybe someone can look into doing the same with GT (to correctly set #doItReceiver, #doItContext and a few other things related to syntax highlighting). >> >> What exactly is the problem in GT regarding syntax highlighting? > > If you inspect a morph (say GTInspector inspect: Morph new), when you type bounds (one of Morph instance variables) in the text pane below, you get a red == erroneous / undefined var. but thatâs not a syntax highlighting problem: is a bindings problem :P Esteban > > In the latest 5.0, in EyeInspector, it will correctly highlight bounds as a defined variable. > > Moreover, and the source of the first complaint, in GTInspector, inspecting bounds will give a nil answer instead of the morph bounds. Whereas EyeInspector will properly answer (0@0) corner: (50@40). > > Thierry > >> Cheers, >> Doru >> >> >>> By the way, would someone know how to force the styler to re-style a text? When selecting another element in for example a EyeTreeInspector, this changes the reference class for syntax highlighting (and the styler correctly picks that) but the existing text isn't re-colored. >>> >>> Thierry >>> >>>> >>>> Hilaire >>>> >>>> >>>> Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >>>>> HilaireFernandes wrote >>>>>>> instance variables evaluate to nil in the bottom area of the integrated >>>>>>> inspector. >>>>> There is no direct inst var access from the playground. I was initially >>>>> shocked by this as well and have had to resort to #instVarNamed: on several >>>>> occasions. On the bright side, you can edit the values in place in the >>>>> 'Value' column above. >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Value is always contextual."

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Thierry Goubier

Hi Doru, Le 27/04/2016 22:38, Tudor Girba a Ã©crit : > Hi, > >> On Apr 27, 2016, at 10:17 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 27/04/2016 21:26, Hilaire a Ã©crit : >>> Now I remember I already asked several months ago, and it does not work. >>> >>> Editing on the value does not work for me. >>> >>> http://forum.world.st/GL-inspector-editing-attribute-td4837704.html >>> >>> The same mis fortune is encountered with Pharo5 >>> >>> I don't imagine how it can be like that and I fell unproductive now with >>> Playground and GTInspector, althought I acknowledge there are nice ideas >>> in these new tools but it can't be at the price of productivity. >>> >>> Hopefully you can switch to Workspace and EyeInspector. >> >> With the help of Nicolai Hess, we worked a bit on improving syntax colouring for the EyeInspector and this has been integrated. Maybe someone can look into doing the same with GT (to correctly set #doItReceiver, #doItContext and a few other things related to syntax highlighting). > > What exactly is the problem in GT regarding syntax highlighting? If you inspect a morph (say GTInspector inspect: Morph new), when you type bounds (one of Morph instance variables) in the text pane below, you get a red == erroneous / undefined var. In the latest 5.0, in EyeInspector, it will correctly highlight bounds as a defined variable. Moreover, and the source of the first complaint, in GTInspector, inspecting bounds will give a nil answer instead of the morph bounds. Whereas EyeInspector will properly answer (0@0) corner: (50@40). Thierry > Cheers, > Doru > > >> By the way, would someone know how to force the styler to re-style a text? When selecting another element in for example a EyeTreeInspector, this changes the reference class for syntax highlighting (and the styler correctly picks that) but the existing text isn't re-colored. >> >> Thierry >> >>> >>> Hilaire >>> >>> >>> Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >>>> HilaireFernandes wrote >>>>>> instance variables evaluate to nil in the bottom area of the integrated >>>>>> inspector. >>>> There is no direct inst var access from the playground. I was initially >>>> shocked by this as well and have had to resort to #instVarNamed: on several >>>> occasions. On the bright side, you can edit the values in place in the >>>> 'Value' column above. >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > > >

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Tudor Girba

Hi, > On Apr 27, 2016, at 10:17 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 27/04/2016 21:26, Hilaire a Ã©crit : >> Now I remember I already asked several months ago, and it does not work. >> >> Editing on the value does not work for me. >> >> http://forum.world.st/GL-inspector-editing-attribute-td4837704.html >> >> The same mis fortune is encountered with Pharo5 >> >> I don't imagine how it can be like that and I fell unproductive now with >> Playground and GTInspector, althought I acknowledge there are nice ideas >> in these new tools but it can't be at the price of productivity. >> >> Hopefully you can switch to Workspace and EyeInspector. > > With the help of Nicolai Hess, we worked a bit on improving syntax colouring for the EyeInspector and this has been integrated. Maybe someone can look into doing the same with GT (to correctly set #doItReceiver, #doItContext and a few other things related to syntax highlighting). What exactly is the problem in GT regarding syntax highlighting? Cheers, Doru > By the way, would someone know how to force the styler to re-style a text? When selecting another element in for example a EyeTreeInspector, this changes the reference class for syntax highlighting (and the styler correctly picks that) but the existing text isn't re-colored. > > Thierry > >> >> Hilaire >> >> >> Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >>> HilaireFernandes wrote >>>>> instance variables evaluate to nil in the bottom area of the integrated >>>>> inspector. >>> There is no direct inst var access from the playground. I was initially >>> shocked by this as well and have had to resort to #instVarNamed: on several >>> occasions. On the bright side, you can edit the values in place in the >>> 'Value' column above. >> > > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Thierry Goubier

Le 27/04/2016 22:28, Henrik Nergaard a Ã©crit : > By the way, would someone know how to force the styler to re-style a text? > RubShoutStylerDecorator>># refreshStyling Thanks. > So from the textArea something like: > (self decoratorNamed: #shoutStyler) ifNotNil: [ :styler | styler refreshStyling ] Ok, I see: just need to do self text: self text somewhere. I suspected that, but I thought there was a more elegant way ;) Thierry > Best regards, > Henrik > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Thierry Goubier > Sent: Wednesday, April 27, 2016 10:17 PM > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Playgound inspecting > > Le 27/04/2016 21:26, Hilaire a Ã©crit : >> Now I remember I already asked several months ago, and it does not work. >> >> Editing on the value does not work for me. >> >> http://forum.world.st/GL-inspector-editing-attribute-td4837704.html >> >> The same mis fortune is encountered with Pharo5 >> >> I don't imagine how it can be like that and I fell unproductive now >> with Playground and GTInspector, althought I acknowledge there are >> nice ideas in these new tools but it can't be at the price of productivity. >> >> Hopefully you can switch to Workspace and EyeInspector. > > With the help of Nicolai Hess, we worked a bit on improving syntax colouring for the EyeInspector and this has been integrated. Maybe someone can look into doing the same with GT (to correctly set #doItReceiver, #doItContext and a few other things related to syntax highlighting). > > By the way, would someone know how to force the styler to re-style a text? When selecting another element in for example a EyeTreeInspector, this changes the reference class for syntax highlighting (and the styler correctly picks that) but the existing text isn't re-colored. > > Thierry > >> >> Hilaire >> >> >> Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >>> HilaireFernandes wrote >>>>> instance variables evaluate to nil in the bottom area of the >>>>> integrated inspector. >>> There is no direct inst var access from the playground. I was >>> initially shocked by this as well and have had to resort to >>> #instVarNamed: on several occasions. On the bright side, you can edit >>> the values in place in the 'Value' column above. >> > > > >

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Henrik Nergaard

By the way, would someone know how to force the styler to re-style a text? RubShoutStylerDecorator>># refreshStyling So from the textArea something like: (self decoratorNamed: #shoutStyler) ifNotNil: [ :styler | styler refreshStyling ] Best regards, Henrik -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Thierry Goubier Sent: Wednesday, April 27, 2016 10:17 PM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Playgound inspecting Le 27/04/2016 21:26, Hilaire a Ã©crit : > Now I remember I already asked several months ago, and it does not work. > > Editing on the value does not work for me. > > http://forum.world.st/GL-inspector-editing-attribute-td4837704.html > > The same mis fortune is encountered with Pharo5 > > I don't imagine how it can be like that and I fell unproductive now > with Playground and GTInspector, althought I acknowledge there are > nice ideas in these new tools but it can't be at the price of productivity. > > Hopefully you can switch to Workspace and EyeInspector. With the help of Nicolai Hess, we worked a bit on improving syntax colouring for the EyeInspector and this has been integrated. Maybe someone can look into doing the same with GT (to correctly set #doItReceiver, #doItContext and a few other things related to syntax highlighting). By the way, would someone know how to force the styler to re-style a text? When selecting another element in for example a EyeTreeInspector, this changes the reference class for syntax highlighting (and the styler correctly picks that) but the existing text isn't re-colored. Thierry > > Hilaire > > > Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >> HilaireFernandes wrote >>>> instance variables evaluate to nil in the bottom area of the >>>> integrated inspector. >> There is no direct inst var access from the playground. I was >> initially shocked by this as well and have had to resort to >> #instVarNamed: on several occasions. On the bright side, you can edit >> the values in place in the 'Value' column above. >

April 27, 2016

Re: [Pharo-users] Playgound inspecting

by Thierry Goubier

Le 27/04/2016 21:26, Hilaire a Ã©crit : > Now I remember I already asked several months ago, and it does not work. > > Editing on the value does not work for me. > > http://forum.world.st/GL-inspector-editing-attribute-td4837704.html > > The same mis fortune is encountered with Pharo5 > > I don't imagine how it can be like that and I fell unproductive now with > Playground and GTInspector, althought I acknowledge there are nice ideas > in these new tools but it can't be at the price of productivity. > > Hopefully you can switch to Workspace and EyeInspector. With the help of Nicolai Hess, we worked a bit on improving syntax colouring for the EyeInspector and this has been integrated. Maybe someone can look into doing the same with GT (to correctly set #doItReceiver, #doItContext and a few other things related to syntax highlighting). By the way, would someone know how to force the styler to re-style a text? When selecting another element in for example a EyeTreeInspector, this changes the reference class for syntax highlighting (and the styler correctly picks that) but the existing text isn't re-colored. Thierry > > Hilaire > > > Le 27/04/2016 15:51, Sean P. DeNigris a Ã©crit : >> HilaireFernandes wrote >>>> instance variables evaluate to nil in the bottom area of the integrated >>>> inspector. >> There is no direct inst var access from the playground. I was initially >> shocked by this as well and have had to resort to #instVarNamed: on several >> occasions. On the bright side, you can edit the values in place in the >> 'Value' column above. >

April 27, 2016