[Pharo-users] ImageWorker error in P6.1

[Martin Dias]

Hello!

The ImageWorker project, that provides the possibility to fork a OS process
with a copy of current image, was working fine in Pharo 60400 but it's not
working on latest 6.1. The output there is "External Image Failed: 256".

Any hint?



Steps to reproduce error:

1. download:

curl get.pharo.org/60+vm | bash

2. load:

Metacello new
repository: 'http://www.smalltalkhub.com/mc/PharoExtras/ImageWorker/main';
configuration: 'ImageWorker';
version: #stable;
load.
3. inspect:

ImageWorker
do: [ 1+2 ]
within: 1 seconds
onTimeout: [ self error: 'timeout' ].


Cheers,
Martín

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

[Stephane Ducasse]

Agreed!
In that case denis we should add a bug entry and clean the complete image.

And no asClass sucks and we do not want to use thisContext.
Why can we do simple thing and avoid to add more accidental complexity.

Stef

On Sat, Feb 10, 2018 at 7:18 PM, Denis Kudriashov  wrote:
>
> 2018-02-10 20:59 GMT+03:00 Stephane Ducasse :
>>
>> Please to not use an unary on Symbol
>> Dispatch on something.
>>
>> self class environment at: #Array
>> is the best
>
>
> We should not use collection API for reflection calls. It makes them very
> difficult to find. Let's use explicit names like:
>
> self class environment classNamed: #Array
>
>
> From the other side we all agree that #asClass is super handy method. And we
> can fix it to respect sender environment using thisContext. It will affects
> performance but with our super powerful metalinks it can be easily cached
> (#asMethodConst is implemented that way).
> So we can make environment completely transparent for users.
>
> Best regards,
> Denis
>
>>
>> For Modules, we made progress and got bitten by many issues and teaching
>> load.
>>
>>
>> Stef
>>
>> On Sat, Feb 10, 2018 at 4:50 PM, Clément Bera 
>> wrote:
>> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >  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 :
>> >> > 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 
>> >> > 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
>>
>

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

[Denis Kudriashov]

2018-02-10 20:59 GMT+03:00 Stephane Ducasse :

> Please to not use an unary on Symbol
> Dispatch on something.
>
> self class environment at: #Array
> is the best
>

We should not use collection API for reflection calls. It makes them very
difficult to find. Let's use explicit names like:

self class environment classNamed: #Array


>From the other side we all agree that #asClass is super handy method. And
we can fix it to respect sender environment using thisContext. It will
affects performance but with our super powerful metalinks it can be easily
cached (#asMethodConst is implemented that way).
So we can make environment completely transparent for users.

Best regards,
Denis


> For Modules, we made progress and got bitten by many issues and teaching
> load.
>
>
> Stef
>
> On Sat, Feb 10, 2018 at 4:50 PM, Clément Bera 
> wrote:
> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
> >  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 :
> >> > 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 
> 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
>
>

Re: [Pharo-users] How to have an in-image map (morph/spec/brick) showing a gps location

[Stephane Ducasse]

Sven in Roassal you can see them in the examples menu.

On Fri, Feb 9, 2018 at 10:20 AM, Cédrick Béler  wrote:
> Thanks all,
>
> I’ll give a try to roassal so.
>
> Cheers,
>
> Cedrick
>
>> Le 9 févr. 2018 à 08:59, Thierry Goubier  a écrit 
>> :
>>
>> 2018-02-09 7:50 GMT+01:00 Sven Van Caekenberghe :
>>>
>>>
 On 9 Feb 2018, at 06:40, Thierry Goubier  wrote:

 Le 09/02/2018 à 00:46, Arturo Zambrano a écrit :
> I used Roassal + OSM and worked perfectly (2 year ago at least). Although 
> I think there is no support for something like a tiles cache.

 We did the OSM support with an in-image tiles cache, but limited to the 
 current map section being viewed.

 It would be easy to add an on-disk cache to that code.

 Thierry

> On Thu, Feb 8, 2018 at 7:46 AM, Cédrick Béler  > wrote:
>   Hello,
>   I would like to have a representation of a map in the image to show
>   (my) GPS coordinates.
>   I haven’t really tried nor searched yet but I’ve seen Roassal
>   examples that could do the job, especially the Open Street Map
>   integration.
>   So does people here have advices on how to to that (having a morph
>   that shows a map and positions) ?
>   Ideally I would like to have it work offline (meaning I download
>   first tiles…or a vectorized map would do the job too).
>   TIA,
>   Cédrick
>>>
>>> Thierry,
>>>
>>> Where are the load instructions ? Does it still work for Pharo 7 ?
>>
>> It should still be part of Roassal, with some issues with the data
>> sources used to retrieve cities coordinates (they went offline!).
>>
>> I haven't started working with Pharo 7 yet, so I can't say.
>>
>> Thierry
>>
>>> Sven
>>>
>>>
>>
>

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

[Stephane Ducasse]

Please to not use an unary on Symbol
Dispatch on something.

self class environment at: #Array
is the best

For Modules, we made progress and got bitten by many issues and teaching load.


Stef

On Sat, Feb 10, 2018 at 4:50 PM, Clément Bera  wrote:
> On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>  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 :
>> > 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  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

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

[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  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

Re: [Pharo-users] Code formatting in CustomHelp

[Stephane Ducasse]

Why don't you extend ProfStef?

On Thu, Feb 8, 2018 at 3:20 PM, Cédrick Béler  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

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

[Clément Bera]

On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand <
hernan.mora...@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 :
> > 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  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

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

[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 :
> 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  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

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

[Esteban A. Maringolo]

2018-02-10 11:33 GMT-03:00 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.

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

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

[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  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 
> 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  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

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

[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 
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  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
> 
>

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

[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  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

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

[jtuc...@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:jtuc...@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

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

[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