Re: [Pharo-users] Playgound inspecting

[Tudor Girba]

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  
> wrote:
> 
> 
> 
> 2016-04-28 9:51 GMT+02:00 Nicolai Hess :
> 
> 
> 2016-04-28 7:20 GMT+02:00 Tudor Girba :
> Hi Nicolai,
> 
> > On Apr 27, 2016, at 11:12 PM, Nicolai Hess  wrote:
> >
> >
> >
> > 2016-04-27 23:07 GMT+02:00 Thierry Goubier :
> > Le 27/04/2016 22:55, Esteban Lorenzano a écrit :
> >
> > On 27 Apr 2016, at 22:52, Thierry Goubier  > > wrote:
> >
> > Hi Doru,
> >
> > Le 27/04/2016 22:38, Tudor Girba a écrit :
> > Hi,
> >
> > On Apr 27, 2016, at 10:17 PM, Thierry Goubier
> > > 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 

Re: [Pharo-users] Moose-Algos-Graph Library in Pharo 5

[Tudor Girba]

Metacello new
configuration: 'MooseAlgos';
smalltalkhubUser: 'Moose' project: 'MooseAlgos';
version: #development;
load: 'Moose-Tests-Algos-Graph’

> On Apr 28, 2016, at 10:21 AM, Christophe Demarey 
>  wrote:
> 
> Metacello new
>   configuration: 'MooseAlgos';
>   smalltalkhubUser: 'Moose' project: 'MooseAlgos';
>   version: #bleedingEdge;
>   load: 'Moose-Tests-Algos-Graph'
> 
>> Le 25 avr. 2016 à 18:52, Volkert  a écrit :
>> 
>> Christophe, Alexandre, i will give it a try  How can i load 
>> "Moose-Tests-Algos-Graph" into Pharo 5.0?
>> 
>> Thanks, Volkert
>> 
>> On 25.04.2016 10:23, Christophe Demarey wrote:
>>> Hi,
>>> 
>>> Moose-Algos-Graph contains very classical algorithmes applying on graphes 
>>> (Breadth-first search, dijkstra, tarjan, topological sorting, etc).
>>> It is now in Pharo 5 because it is used by the dependency analyser.
>>> As Alexandre said, there are almost no documentation and it is not so easy 
>>> to combine algorithms (run an algo on the output of another algo).
>>> You can look at Moose-Tests-Algos-Graph package (to be loaded) and 
>>> DADependencyChecker>>#shortestPathToPackageIntroducingDependency:startingFrom:
>>>  for some examples.
>>> 
>>> Christophe
>>> 
>>> 
 Le 24 avr. 2016 à 20:55, Alexandre Bergel  a 
 écrit :
 
 Hi Volkert!
 
 This package contains some classical graph algorithms we use in software 
 analysis (e.g., clustering, strong component).
 Unfortunately, there is no much documentation about it. If you are using 
 these algorithms, then it would be great to write some documentation.
 
 In addition to this package, and as you know, Roassal offers many layout 
 algorithms.
 
 Regarding,
 Alexandre
 
> On Apr 24, 2016, at 6:39 AM, Volkert  
> wrote:
> 
> Dear all,
> 
> if have found the "Moose-Algos-Graph" package in Pharo 5. What is the 
> idea behind this package? Is this "the" official Pharo Graph Library?
> Do we have some examples how to use it?
> 
> LG,
> Volkert
> 
 -- 
 _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 Alexandre Bergel  http://www.bergel.eu
 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
 
 
 
 
>>> 
>> 
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

Re: [Pharo-users] Moose-Algos-Graph Library in Pharo 5

[Christophe Demarey]

Metacello new
configuration: 'MooseAlgos';
smalltalkhubUser: 'Moose' project: 'MooseAlgos';
version: #bleedingEdge;
load: 'Moose-Tests-Algos-Graph'

> Le 25 avr. 2016 à 18:52, Volkert  a écrit :
> 
> Christophe, Alexandre, i will give it a try  How can i load 
> "Moose-Tests-Algos-Graph" into Pharo 5.0?
> 
> Thanks, Volkert
> 
> On 25.04.2016 10:23, Christophe Demarey wrote:
>> Hi,
>> 
>> Moose-Algos-Graph contains very classical algorithmes applying on graphes 
>> (Breadth-first search, dijkstra, tarjan, topological sorting, etc).
>> It is now in Pharo 5 because it is used by the dependency analyser.
>> As Alexandre said, there are almost no documentation and it is not so easy 
>> to combine algorithms (run an algo on the output of another algo).
>> You can look at Moose-Tests-Algos-Graph package (to be loaded) and 
>> DADependencyChecker>>#shortestPathToPackageIntroducingDependency:startingFrom:
>>  for some examples.
>> 
>> Christophe
>> 
>> 
>>> Le 24 avr. 2016 à 20:55, Alexandre Bergel  a écrit 
>>> :
>>> 
>>> Hi Volkert!
>>> 
>>> This package contains some classical graph algorithms we use in software 
>>> analysis (e.g., clustering, strong component).
>>> Unfortunately, there is no much documentation about it. If you are using 
>>> these algorithms, then it would be great to write some documentation.
>>> 
>>> In addition to this package, and as you know, Roassal offers many layout 
>>> algorithms.
>>> 
>>> Regarding,
>>> Alexandre
>>> 
 On Apr 24, 2016, at 6:39 AM, Volkert  
 wrote:
 
 Dear all,
 
 if have found the "Moose-Algos-Graph" package in Pharo 5. What is the idea 
 behind this package? Is this "the" official Pharo Graph Library?
 Do we have some examples how to use it?
 
 LG,
 Volkert
 
>>> -- 
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-users] Playgound inspecting

[Thierry Goubier]

2016-04-28 9:51 GMT+02:00 Nicolai Hess :

>
>
> 2016-04-28 7:20 GMT+02:00 Tudor Girba :
>
>> Hi Nicolai,
>>
>> > On Apr 27, 2016, at 11:12 PM, Nicolai Hess 
>> wrote:
>> >
>> >
>> >
>> > 2016-04-27 23:07 GMT+02:00 Thierry Goubier :
>> > Le 27/04/2016 22:55, Esteban Lorenzano a écrit :
>> >
>> > On 27 Apr 2016, at 22:52, Thierry Goubier > > > wrote:
>> >
>> > Hi Doru,
>> >
>> > Le 27/04/2016 22:38, Tudor Girba a écrit :
>> > Hi,
>> >
>> > On Apr 27, 2016, at 10:17 PM, Thierry Goubier
>> > > 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 

Re: [Pharo-users] Playgound inspecting

[Nicolai Hess]

2016-04-28 7:20 GMT+02:00 Tudor Girba :

> Hi Nicolai,
>
> > On Apr 27, 2016, at 11:12 PM, Nicolai Hess 
> wrote:
> >
> >
> >
> > 2016-04-27 23:07 GMT+02:00 Thierry Goubier :
> > Le 27/04/2016 22:55, Esteban Lorenzano a écrit :
> >
> > On 27 Apr 2016, at 22:52, Thierry Goubier  > > wrote:
> >
> > Hi Doru,
> >
> > Le 27/04/2016 22:38, Tudor Girba a écrit :
> > Hi,
> >
> > On Apr 27, 2016, at 10:17 PM, Thierry Goubier
> > > 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.




>
> 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 
> > www.feenk.com
> >
> > "Value is always contextual."
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Problem solving efficiency grows with the abstractness level of problem
> understanding."
>
>
>
>
>
>

[Pharo-users] Change Playground title based on the name of the first pane

[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