February 2018 - Pharo-users

Re: [Pharo-users] cancel changes in Nautilus broken on 6.1?

by Stephane Ducasse

Hi Siemen I use often cmd-L too and may be we got a regression. And indeed I have the same behavior in Pharo 70. Can you try to see how to address it? Stef On Fri, Feb 9, 2018 at 8:37 PM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > Hi all, > > I downloaded Pharo 6.1 for OSX and whenever I revert changes in Nautilus > with CMD-L, the content is reverted and the orange dirty marker triangle > disappears. But when I switch to a different method, Nautilus shows the > 'Content has been modified. What do you want to do?' dialog, as it only > should when content is actually different. > > I use this all the time, I can't imagine I'm the only one, but I couldn't > find the problem mentioned anywhere. Does anyone else have it? What to do? > > -- Siemen

Feb. 10, 2018

Re: [Pharo-users] Code formatting in CustomHelp

by Stephane Ducasse

Why don't you extend ProfStef? On Thu, Feb 8, 2018 at 3:20 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi, > > Iâm doing some tutorials with the help system. > > In ProfStef, there is code formatting but not thrgouh the HelpBrowser. > In CustomHelp sublclasses, itâs possible to have some formatting (heading:, bold:, â¦). > > Do you know if itâs possible to have a #code: method so as to use shout specifically ? It doesnât seem obvious to me. > > TIA > > CÃ©drick

Feb. 10, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by ClÃ©ment Bera

On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi ClÃ©ment, > > First time I read about modules in Pharo. > What is a module exactly? What's the problem to solve? > It's similar to namespaces with some different, arguably better, features. Honestly I am not the expert on it so I would like some one else to answer. Among other things, it solves the problem of having 2 classes with the same name (avoiding the prefixes we have like in C). But reportedly that's just a side-effect and not the main problem to solve. > Cheers, > > HernÃ¡n > > 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > Hi, > > > > In short, everything that is not namespace/module compatible will be > > deprecated/changed/removed in the future, so it is not recommended to use > > it. > > > > a.2) #Array asClassInEnvironment: Smalltalk globals > > b.1) Smalltalk globals at: #Array > > => Ok-ish, note that you may need to change 'Smalltalk globals' the > > namespace/module when support for those will be added since Array will > be in > > a module. > > Maybe you want instead to use instead: > > > > c) self class environment at: #Array > > => this will work in the future if your code is a class which > > environment/namespace/module includes the Array class you would expect > > > > a.1) #Array asClass > > b.2) Smalltalk at: #Array > > b.3) Smalltalk classNamed: #Array > > => In which namespace/module are you looking for #Array ? In the future > this > > may be removed, alternatively it will work only for globals but not > globals > > inside namespace/module which won't work since Array will be in a module. > > > > > > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> > >> Hi, > >> > >> what is the canonical way to get a class from a symbol? > >> > >> a) Converting symbol into class via string protocol > >> > >> a.1) #Array asClass > >> I use this the most, because it is easy, uses unary selector, and so far > >> I've never ran into any issues. But apparently it is not good -- why? > >> > >> a.2) #Array asClassInEnvironment: Smalltalk globals > >> > >> b) Retriving the class by key from the system dictionary > >> > >> b.1) Smalltalk globals at: #Array > >> > >> b.2) Smalltalk at: #Array > >> > >> b.3) Smalltalk classNamed: #Array > >> > >> c) something else entirely? > >> > >> I get that using #asClass wouldn't work if there was a different > >> environment, however I don't even know in what situation there could be > a > >> different environment, so I cannot assert how problematic it is or > isn't. > >> > >> Thanks, > >> Peter > > > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Pharo consortium engineer > > https://clementbera.wordpress.com/ > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 10, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by HernÃ¡n Morales Durand

Hi ClÃ©ment, First time I read about modules in Pharo. What is a module exactly? What's the problem to solve? Cheers, HernÃ¡n 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi, > > In short, everything that is not namespace/module compatible will be > deprecated/changed/removed in the future, so it is not recommended to use > it. > > a.2) #Array asClassInEnvironment: Smalltalk globals > b.1) Smalltalk globals at: #Array > => Ok-ish, note that you may need to change 'Smalltalk globals' the > namespace/module when support for those will be added since Array will be in > a module. > Maybe you want instead to use instead: > > c) self class environment at: #Array > => this will work in the future if your code is a class which > environment/namespace/module includes the Array class you would expect > > a.1) #Array asClass > b.2) Smalltalk at: #Array > b.3) Smalltalk classNamed: #Array > => In which namespace/module are you looking for #Array ? In the future this > may be removed, alternatively it will work only for globals but not globals > inside namespace/module which won't work since Array will be in a module. > > > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> what is the canonical way to get a class from a symbol? >> >> a) Converting symbol into class via string protocol >> >> a.1) #Array asClass >> I use this the most, because it is easy, uses unary selector, and so far >> I've never ran into any issues. But apparently it is not good -- why? >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >> >> b) Retriving the class by key from the system dictionary >> >> b.1) Smalltalk globals at: #Array >> >> b.2) Smalltalk at: #Array >> >> b.3) Smalltalk classNamed: #Array >> >> c) something else entirely? >> >> I get that using #asClass wouldn't work if there was a different >> environment, however I don't even know in what situation there could be a >> different environment, so I cannot assert how problematic it is or isn't. >> >> Thanks, >> Peter > > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 10, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Esteban A. Maringolo

2018-02-10 11:33 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> c) self class environment at: #Array >> => this will work in the future if your code is a class which >> environment/namespace/module includes the Array class you would expect > > Let's say that namespaces are added; Array is now in the module > Collections.Array > My code is now in module MyProject.MyWhatever > > I would imagine that in such situation I would need to change the code > anyway, because it would try to look up MyProject.Array, no? > > So if the argument for asClass is based on future addition of modules, then > I will need to manually change it anyway regardless of what approach I used, > because I don't know in which namespace the class will end up. If it is as in VisualWorks, it creates references, and such references can be resolved dynamically. If the reference specifies a namespace, then something such as Core.OrderedCollection is resolved directly looking at the referenced namespace, otherwise it looks at the same namespace of the class or any namespace imported by the class definition. With the added complexity of "nested" namespaces (Smalltalk.Core, Smalltalk.Kernel, etc), and namespaces can also import other namespaces, e.g.: ``` Smalltalk defineNameSpace: #Seaside private: false imports: ' private Smalltalk.* private SUnit.* private Grease.* ' category: '' ``` I think that the explicit namespacing approach adds more complexity than anything else, I'd use a more dynamic approach, like using modules. Regards, Esteban A. Maringolo

Feb. 10, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by ClÃ©ment Bera

Modules can import other modules to be able to use their classes directly. Anyway, this is theory, there is no module implementation currently. But the idea in the recent versions of Pharo (5-6-7) was to start moving away from things like (Smalltalk at: #className) or (#className asClass) since it does not work with the module system that is going to be introduced. On Sat, Feb 10, 2018 at 3:33 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > c) self class environment at: #Array > > => this will work in the future if your code is a class which > environment/namespace/module includes the Array class you would expect > > Let's say that namespaces are added; Array is now in the module > Collections.Array > My code is now in module MyProject.MyWhatever > > I would imagine that in such situation I would need to change the code > anyway, because it would try to look up MyProject.Array, no? > > So if the argument for asClass is based on future addition of modules, > then I will need to manually change it anyway regardless of what approach I > used, because I don't know in which namespace the class will end up. > > Am I missing something? > > Thanks, > Peter > > > On Sat, Feb 10, 2018 at 1:47 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> Hi, >> >> In short, everything that is not namespace/module compatible will be >> deprecated/changed/removed in the future, so it is not recommended to use >> it. >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >> b.1) Smalltalk globals at: #Array >> => Ok-ish, note that you may need to change 'Smalltalk globals' the >> namespace/module when support for those will be added since Array will be >> in a module. >> Maybe you want instead to use instead: >> >> c) self class environment at: #Array >> => this will work in the future if your code is a class which >> environment/namespace/module includes the Array class you would expect >> >> a.1) #Array asClass >> b.2) Smalltalk at: #Array >> b.3) Smalltalk classNamed: #Array >> => In which namespace/module are you looking for #Array ? In the future >> this may be removed, alternatively it will work only for globals but not >> globals inside namespace/module which won't work since Array will be in a >> module. >> >> >> On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Hi, >>> >>> what is the canonical way to get a class from a symbol? >>> >>> a) Converting symbol into class via string protocol >>> >>> a.1) #Array asClass >>> I use this the most, because it is easy, uses unary selector, and so far >>> I've never ran into any issues. But apparently it is not good -- why? >>> >>> a.2) #Array asClassInEnvironment: Smalltalk globals >>> >>> b) Retriving the class by key from the system dictionary >>> >>> b.1) Smalltalk globals at: #Array >>> >>> b.2) Smalltalk at: #Array >>> >>> b.3) Smalltalk classNamed: #Array >>> >>> c) something else entirely? >>> >>> I get that using #asClass wouldn't work if there was a different >>> environment, however I don't even know in what situation there could be a >>> different environment, so I cannot assert how problematic it is or isn't. >>> >>> Thanks, >>> Peter >>> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve >> d >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >> 'Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >> > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 10, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Peter UhnÃ¡k

> c) self class environment at: #Array > => this will work in the future if your code is a class which environment/namespace/module includes the Array class you would expect Let's say that namespaces are added; Array is now in the module Collections.Array My code is now in module MyProject.MyWhatever I would imagine that in such situation I would need to change the code anyway, because it would try to look up MyProject.Array, no? So if the argument for asClass is based on future addition of modules, then I will need to manually change it anyway regardless of what approach I used, because I don't know in which namespace the class will end up. Am I missing something? Thanks, Peter On Sat, Feb 10, 2018 at 1:47 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi, > > In short, everything that is not namespace/module compatible will be > deprecated/changed/removed in the future, so it is not recommended to use > it. > > a.2) #Array asClassInEnvironment: Smalltalk globals > b.1) Smalltalk globals at: #Array > => Ok-ish, note that you may need to change 'Smalltalk globals' the > namespace/module when support for those will be added since Array will be > in a module. > Maybe you want instead to use instead: > > c) self class environment at: #Array > => this will work in the future if your code is a class which > environment/namespace/module includes the Array class you would expect > > a.1) #Array asClass > b.2) Smalltalk at: #Array > b.3) Smalltalk classNamed: #Array > => In which namespace/module are you looking for #Array ? In the future > this may be removed, alternatively it will work only for globals but not > globals inside namespace/module which won't work since Array will be in a > module. > > > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> what is the canonical way to get a class from a symbol? >> >> a) Converting symbol into class via string protocol >> >> a.1) #Array asClass >> I use this the most, because it is easy, uses unary selector, and so far >> I've never ran into any issues. But apparently it is not good -- why? >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >> >> b) Retriving the class by key from the system dictionary >> >> b.1) Smalltalk globals at: #Array >> >> b.2) Smalltalk at: #Array >> >> b.3) Smalltalk classNamed: #Array >> >> c) something else entirely? >> >> I get that using #asClass wouldn't work if there was a different >> environment, however I don't even know in what situation there could be a >> different environment, so I cannot assert how problematic it is or isn't. >> >> Thanks, >> Peter >> > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >

Feb. 10, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by ClÃ©ment Bera

Hi, In short, everything that is not namespace/module compatible will be deprecated/changed/removed in the future, so it is not recommended to use it. a.2) #Array asClassInEnvironment: Smalltalk globals b.1) Smalltalk globals at: #Array => Ok-ish, note that you may need to change 'Smalltalk globals' the namespace/module when support for those will be added since Array will be in a module. Maybe you want instead to use instead: c) self class environment at: #Array => this will work in the future if your code is a class which environment/namespace/module includes the Array class you would expect a.1) #Array asClass b.2) Smalltalk at: #Array b.3) Smalltalk classNamed: #Array => In which namespace/module are you looking for #Array ? In the future this may be removed, alternatively it will work only for globals but not globals inside namespace/module which won't work since Array will be in a module. On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > what is the canonical way to get a class from a symbol? > > a) Converting symbol into class via string protocol > > a.1) #Array asClass > I use this the most, because it is easy, uses unary selector, and so far > I've never ran into any issues. But apparently it is not good -- why? > > a.2) #Array asClassInEnvironment: Smalltalk globals > > b) Retriving the class by key from the system dictionary > > b.1) Smalltalk globals at: #Array > > b.2) Smalltalk at: #Array > > b.3) Smalltalk classNamed: #Array > > c) something else entirely? > > I get that using #asClass wouldn't work if there was a different > environment, however I don't even know in what situation there could be a > different environment, so I cannot assert how problematic it is or isn't. > > Thanks, > Peter > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 10, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by jtuchel＠objektfabrik.de

Peter, I have no answer for you as I am not a Pharo expert. It may be part of an answer to your question "why?", however. I think most if not all of the alternatives you mention are equally good as long as you assume there is only one place to look for Classes. As soon as you introduce namespaces to the equation, things get more complicated. Depending on the logic of new implementations of these lookup methods, the results may vary in such an environment. just my 2 cents Joachim Am 10.02.18 um 12:57 schrieb Peter UhnÃ¡k: > Hi, > > what is the canonical way to get a class from a symbol? > > a) Converting symbol into class via string protocol > > a.1) #Array asClass > I use this the most, because it is easy, uses unary selector, and so > far I've never ran into any issues. But apparently it is not good -- why? > > a.2) #Array asClassInEnvironment: Smalltalk globals > > b) Retriving the class by key from the system dictionary > > b.1) Smalltalk globals at: #Array > > b.2) Smalltalk at: #Array > > b.3) Smalltalk classNamed: #Array > > c) something else entirely? > > I get that using #asClass wouldn't work if there was a different > environment, however I don't even know in what situation there could > be a different environment, so I cannot assert how problematic it is > or isn't. > > Thanks, > Peter -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Feb. 10, 2018

canonical way to convert Symbol into Class (retrieve class by its name)

by Peter UhnÃ¡k

Hi, what is the canonical way to get a class from a symbol? a) Converting symbol into class via string protocol a.1) #Array asClass I use this the most, because it is easy, uses unary selector, and so far I've never ran into any issues. But apparently it is not good -- why? a.2) #Array asClassInEnvironment: Smalltalk globals b) Retriving the class by key from the system dictionary b.1) Smalltalk globals at: #Array b.2) Smalltalk at: #Array b.3) Smalltalk classNamed: #Array c) something else entirely? I get that using #asClass wouldn't work if there was a different environment, however I don't even know in what situation there could be a different environment, so I cannot assert how problematic it is or isn't. Thanks, Peter

Feb. 10, 2018