Hi, I added bindings in a new version of GTInspector and it seems to work without setting the classOrMetaClass: https://pharo.fogbugz.com/f/cases/17948/Bindings-in-the-evaluator-pane-in-Inspector
Could you test? Cheers, Doru > On Apr 28, 2016, at 10:05 AM, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > > > 2016-04-28 9:51 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: > > > 2016-04-28 7:20 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > Hi Nicolai, > > > On Apr 27, 2016, at 11:12 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > > > > > 2016-04-27 23:07 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com>: > > Le 27/04/2016 22:55, Esteban Lorenzano a écrit : > > > > On 27 Apr 2016, at 22:52, Thierry Goubier <thierry.goub...@gmail.com > > <mailto:thierry.goub...@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.goub...@gmail.com <mailto:thierry.goub...@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-Inspector > > 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. > > I think I tried that one when looking at the styler workspace style issue and > it didn't work. Some of the comments about styling and bindings seems out of > date, and the RB based styler behaves differently. > > Thierry > > > > > > 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." -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."
