April 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Playgound inspecting

by Nicolai Hess

2016-04-28 7:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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? > That depends on how you want to add bindints for instance variables. For evaluating expressions with instance variables, OCASTSemantic analyzer already knows how to lookup the variable binding from the OCInstanceScope (it does not work at the moment, because inspect (the requestor) is asked first, and it creates a binding on the fly). For syntax highlighting, the styler needs to know if a classOrMetaClass attribute is set, otherwise it does not create a compilation context that can lookup up with the correct instance scope. (see SHRBTextStyler>>#privateStyle: ) If you omit to create bindings on the fly for instance variables, you need to set the classOrMetaClass attribute but if you include the instance variable bindings and the GT inspector (the requestor in #lookupVar: ) is responsible for finding the correct var, it may work without setting the classOrMetaClass attribute - I don't know for sure. > > 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

Change Playground title based on the name of the first pane

by Peter UhnÃ¡k

Hi, would it be possible to change the Playground title when the first page changed? I know I can change the title through the top right corner, but just a double click might be more useful. Plus there could be some automatic naming pattern, because it would be nice to still see that it is playgroundâ¦ for example I tend to name them: "PL @ custom name". Thanks, Peter

April 28, 2016

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