February 2018 - Pharo-users

Re: [Pharo-users] Object configuration idioms

by Christian Caldeiro

Maybe using directly TwitterClient, but using #doesNotUnderstand: to delegate there message sends to the configuration object(kind of a proxy pattern). That way the TwitterClient class doesn't became so heavy. Christian On Sun, Feb 11, 2018 at 1:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Why not directly on TwitterClient ? That would be easiest for the user, > then they do not need to know about TwitterConfiguration. Anyway, that is > how I do it most often. The disadvantage is that TwitterClient might become > a bit heavy, API wise, but you can delegate internally. > > > On 11 Feb 2018, at 16:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > are there any best practices/idioms in regards to object > configuration/building? > > > > Let's say I want to configure a TwitterClient that requires a username > and a password that is stored in a separate object TwitterConfiguration > > > > a) the basic approach (either separate sends or via cascade, that is not > relevant here) > > > > client := TwitterClient new. > > client configuration username: 'XX'. > > client configuration password: 'YY'. > > > > > > b) #in: ... > > > > It feels a bit more organized as it basically groups related operations > together. > > Also maybe avoiding demeter a bit? > > > > client := TwitterClient new. > > client configuration in: [ :config | > > config username: 'XX'. > > config password: 'YY'. > > ]. > > > > c) custom #somethingDo: method that basically does #in: > > > > Again, feels more organized. Additionally one could perform some > validation afterwards (to make sure the credentials are ok or whatever). > > > > client := TwitterClient new. > > client configurationDo: [ :config | > > config username: 'XX'. > > config password: 'YY' > > ]. > > > > Any thoughts on this? > > > > Thanks, > > Peter > > >

Feb. 11, 2018

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

by Denis Kudriashov

Hi Hernan. 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Hi Denis > > 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > > > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> > >> 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: > > > > Sorry I do not see it. > > The Collection API is beautiful, why couldn't be used for reflection? > We have around 3000 senders of #at: message in the image. Do you think it is easy to filter reflective calls? > I have no trouble finding #asClass senders, implementors, etc. > > What do you want to find? > > > self class environment classNamed: #Array > > > > Too much typing :) > > > > > 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 <bera.clement(a)gmail.com> > >> wrote: > >> > 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. 11, 2018

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

by HernÃ¡n Morales Durand

Hi Denis 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> 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: > Sorry I do not see it. The Collection API is beautiful, why couldn't be used for reflection? I have no trouble finding #asClass senders, implementors, etc. What do you want to find? > self class environment classNamed: #Array > Too much typing :) > > 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 <bera.clement(a)gmail.com> >> wrote: >> > 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. 11, 2018

Re: [Pharo-users] Object configuration idioms

by Sven Van Caekenberghe

Why not directly on TwitterClient ? That would be easiest for the user, then they do not need to know about TwitterConfiguration. Anyway, that is how I do it most often. The disadvantage is that TwitterClient might become a bit heavy, API wise, but you can delegate internally. > On 11 Feb 2018, at 16:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > are there any best practices/idioms in regards to object configuration/building? > > Let's say I want to configure a TwitterClient that requires a username and a password that is stored in a separate object TwitterConfiguration > > a) the basic approach (either separate sends or via cascade, that is not relevant here) > > client := TwitterClient new. > client configuration username: 'XX'. > client configuration password: 'YY'. > > > b) #in: ... > > It feels a bit more organized as it basically groups related operations together. > Also maybe avoiding demeter a bit? > > client := TwitterClient new. > client configuration in: [ :config | > config username: 'XX'. > config password: 'YY'. > ]. > > c) custom #somethingDo: method that basically does #in: > > Again, feels more organized. Additionally one could perform some validation afterwards (to make sure the credentials are ok or whatever). > > client := TwitterClient new. > client configurationDo: [ :config | > config username: 'XX'. > config password: 'YY' > ]. > > Any thoughts on this? > > Thanks, > Peter

Feb. 11, 2018

Object configuration idioms

by Peter UhnÃ¡k

Hi, are there any best practices/idioms in regards to object configuration/building? Let's say I want to configure a TwitterClient that requires a username and a password that is stored in a separate object TwitterConfiguration a) the basic approach (either separate sends or via cascade, that is not relevant here) client := TwitterClient new. client configuration username: 'XX'. client configuration password: 'YY'. b) #in: ... It feels a bit more organized as it basically groups related operations together. Also maybe avoiding demeter a bit? client := TwitterClient new. client configuration in: [ :config | config username: 'XX'. config password: 'YY'. ]. c) custom #somethingDo: method that basically does #in: Again, feels more organized. Additionally one could perform some validation afterwards (to make sure the credentials are ok or whatever). client := TwitterClient new. client configurationDo: [ :config | config username: 'XX'. config password: 'YY' ]. Any thoughts on this? Thanks, Peter

Feb. 11, 2018

ImageWorker error in P6.1

by 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

Feb. 10, 2018

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

by 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 <dionisiydk(a)gmail.com> wrote: > > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> 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 <bera.clement(a)gmail.com> >> wrote: >> > 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 Denis Kudriashov

2018-02-10 20:59 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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 <bera.clement(a)gmail.com> > wrote: > > 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] How to have an in-image map (morph/spec/brick) showing a gps location

by 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 <cdrick65(a)gmail.com> wrote: > Thanks all, > > Iâll give a try to roassal so. > > Cheers, > > Cedrick > >> Le 9 fÃ©vr. 2018 Ã 08:59, Thierry Goubier <thierry.goubier(a)gmail.com> a Ã©crit : >> >> 2018-02-09 7:50 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>>> On 9 Feb 2018, at 06:40, Thierry Goubier <thierry.goubier(a)gmail.com> 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 <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> 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 >>> >>> >> >

Feb. 10, 2018

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

by 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 <bera.clement(a)gmail.com> wrote: > 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