- Pharo-users - lists.pharo.org

Re: [Pharo-users] Object configuration idioms

by Stephan Eggermont

Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Are you talking about the solution described in this mailing list thread Yes, that's the one. I would welcome a (blog)post about this Stephan

Feb. 12, 2018

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

by Siemen Baader

Hi Stef, On Sat, Feb 10, 2018 at 6:22 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Siemen > > I use often cmd-L too and may be we got a regression. > I'm pretty sure I started doing it after I saw you do it in the MOOC ;) And indeed I have the same behavior in Pharo 70. > Can you try to see how to address it? > Yes, I can try to look into it. I don't have any clear idea where to start other than browsing Nautilus code and perhaps uses of NautilusChanged, but perhaps it is not that hard to find. -- Siemen > > 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. 12, 2018

Re: [Pharo-users] Object configuration idioms

by Sean P. DeNigris

Stephan Eggermont-3 wrote > See the recent post about using volatile memory to avoid passwords and > sessions being stored in the image Are you talking about the solution described in this mailing list thread [1]: >For my use case, since this api key is only sent to an ffi callout, >my solution was to read the password from file into volatile memory so >it disappears when the VM exits. See this line.... > externalVolatileSecret := ExternalAddress gcallocate: externalSize . Is there also a blog post? 1. http://forum.world.st/ANN-sentry-io-OSS-error-tracking-platform-SDK-tp50659… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 12, 2018

Re: [Pharo-users] Roassal to ODG

by Arturo Zambrano

On Fri, Feb 9, 2018 at 5:35 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > There is SVG exporter. > Yes, I'm aware of that. > > I've never heard about ODG, is it commonly used outside of OpenOffice > itself? > Not much, you are right. SVG should suffice, my point is generating a kind of flowcharts that may need manual edition. When I open the generated SVG, reasonably , every piece of the graphic is separated (you know simple arrow is three separated lines, and things like that)... I would like to generate something like a Visio drawing... but in the open source world... so I though generating an ODG would be a good alternative. I'm not familiar with SVG details, if it is possible to group shapes and lines that would be OK. So I want to re post my question: "What is the best option to generate an editable flow chart from Pharo (Roassal)?" Thanks for your feedback Peter! best regards > Peter > > On Fri, Feb 9, 2018 at 9:29 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi Arturo >> >> I have no idea about the answer. But hello from snowy France :) >> > Hi Stef, Hope everyone is OK with the icy winter :) best regards. > >> Stef >> >> On Fri, Feb 9, 2018 at 6:49 PM, Arturo Zambrano >> <arturo.zambrano(a)gmail.com> wrote: >> > Hi all, >> > Is there any project for exporting Roassal to ODG (vector graphic >> format >> > from open document format standard)? The closest thing I could find is >> > RTPDFExporter (the generated PDF can be opened using (Libre/S/G)Office >> > suite). >> > >> > If there no such exporter, how difficult should it be to build one, >> > compared to RTPDFExporter? >> > >> > TIA >> > Arturo >> >> >

Feb. 12, 2018

Re: [Pharo-users] Object configuration idioms

by Stephan Eggermont

Christian Haider <christian.haider(a)smalltalked-visuals.com> wrote: > sorry to jump in here, but I think that this pattern is bad The example with user and password is very atypical, as it has different security requirements from most other code. See the recent post about using volatile memory to avoid passwords and sessions being stored in the image Stephan

Feb. 12, 2018

Re: [Pharo-users] Object configuration idioms

by Christian Haider

Hi, sorry to jump in here, but I think that this pattern is bad. For your approach, you need to have setters on the configuration. Do you really want to have methods to set the username and password from the outside â maybe even after you logged in? To me an object like your configuration should be a value, which can be created but may never be modified after creation. For this I would define a constructor: TwitterConfiguration class>>username: aString password: anotherString | inst | inst := self new. inst initializeUsername: aString password: anotherString. ^inst And an initializer: TwitterConfiguration>> initializeUsername: aString password: anotherString username := aString. password := anotherString The two setters #username: and #password: should be deleted. With TwitterClient at top, I would use constructors as well: TwitterClient class>>username: aString password: anotherString | inst | inst := self new. inst initializeConfiguration: (TwitterConfiguration username: aString password: anotherString). ^inst The nice thing about constructors is that the user knows what arguments are expected to get a valid object. The initializers are intentionally prefixed with the cumbersome âinitializeâ¦â to indicate that they should not be confused with (multi-)setters. (in VW, I additionally make these kinds of objects immutable to really make sure that the object cannot be modified after creation.) So, please, think twice about using setters. They should be not used for initialization / configuration! My 2 cents. Cheers, Christian Von: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] Im Auftrag von Peter UhnÃ¡k Gesendet: Sonntag, 11. Februar 2018 16:26 An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Betreff: [Pharo-users] Object configuration idioms 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. 12, 2018

Re: [Pharo-users] Object configuration idioms

by Henrik-Nergaard

Hi Peter, I would just fill in the configuration and have it give me the correct client which uses the configuration instance. ========================= | client | client := TwitterConfiguration new username: 'stuff'; password: 'password1'; port: '1234'; useHttps; client. TwitterConfiguration >> #client self perhapsValidateConfigurationHere. ^ self clientClassDependingOnConfiguration on: self ======================================== Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 11, 2018

Re: [Pharo-users] Object configuration idioms

by Norbert Hartl

> Am 11.02.2018 um 21:34 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Arghhhhhh no magic please. > I got burned by too much DNU override. + magic number Norbert > > > On Sun, Feb 11, 2018 at 8:17 PM, Christian Caldeiro > <christian.caldeiro(a)gmail.com> wrote: >> 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] How to have an in-image map (morph/spec/brick) showing a gps location

by Sven Van Caekenberghe

> On 11 Feb 2018, at 22:02, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > Beautiful, Sven! > > I have a publicity suggestion. Make a larger png of that and share it on Twitter and LinkedIn. > (And if you do, I would also suggest cascading the message sends to the camera.) > > I would love to share that around! This is not my work, it is one of several built-in examples. And this functionality is years old already. But I do agree that stuff like this should be promoted more, there are so many hidden gems everywhere. > On Sun, Feb 11, 2018 at 12:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 10 Feb 2018, at 19:00, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Sven in Roassal you can see them in the examples menu. > > Ah, and it all works out-of-the-box just-like-that in Pharo-7.0+alpha.build.493.sha.d53a70bc946ed83b046f61ac35f00c67fa77269a (32 Bit) on macOS. > > <Screen Shot 2018-02-11 at 21.21.59.png> > > Wow, amazing ! Very, very nice. > >> 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. 11, 2018

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

by Richard Sargent

There are two use cases that come immediately to mind. They may be the two most important. "As a Compiler, I need to be able to resolve a Symbol to a known Object." "As a Browser, I need to be able to identify the possible resolutions of a String to known Objects." I can elaborate on those, but I think they are pretty clear no matter what scopes, namespaces, environments, modules, or whatever one uses to organize things in the image. (One can even imagine an external registry of names that could be searched and yield up suggestions of external packages that would be needed.) On Sun, Feb 11, 2018 at 12:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2018-02-11 21:08 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> Denis >> >> we should introduce classNamed: now we can have traits and globals too :( >> > > Yes, we need to think about it. > > >> Idea? may be can still classNamed: >> >> Stef >> >> >> On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > >> > >> > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com>: >> >> >> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> > 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 still don't understand your use case, nor how the #at: is related >> >> with the #asClass issue. >> >> >> >> Do you mean **further** filtering for relflective sends? >> >> >> >> Does this affects common-usage beyond Browser development? >> > >> > >> > The Stef proposal was that we should never use #asClass in the code. It >> is >> > fine for scripting but not for the domain code by many reasons which >> were >> > discussed here and at the past. >> > >> > But I only commented the proposed replacement: >> > >> > self class environment at: #Object >> > >> > >> > If you do not like it, it is different story. I just described problem >> with >> > #at: message: >> > >> > We already replaced many #asClass users with this code. And now it is >> quite >> > difficult to find such places. They all hidden inside 3000 senders of >> #at:. >> > If we will use #classNamed: instead of #at: then simple senders query >> will >> > easily detect all reflective calls. >> > (we probably already use it but not in all places). >> > >> >> >> >> >> >> >> >> >> >> 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 >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> >> 'Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+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 >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> >> 'Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq&entry=gmail&source=g> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >> >

Feb. 11, 2018