- Pharo-users - lists.pharo.org

Re: [Pharo-users] UserManager class missing in Pharo 5

by stepharo

We removed it because it was a plague. The design was totally wrong a huge global variable with everybody refering to it. This was exactly the same bad design as the one of the Preferences singleton facade that we replaced by the great Settings design. Did you read the chapter on Settings? Do you understand its design? Each component defines its own setting and provide a way to change them. The flow is local to the component. Then via introspection a tool the setting browser can collect metadata on setting and let the user change them. So we get a modular and layered architecture. Settings can be applied on minimal image without any problem we can have a kernel without settings or with. Because we would like to do the same for permissions. In a nutshell: Every tools or application should define it permission And provide a way to change them. Tell me if you need more explanation. Now it will not be for Pharo 50. Stef /16 14:28, kmo a Ã©crit : > The UserManager class has disappeared in Pharo 5. > > I was using it as a convenient way to restrict what a user can do with a > delivered application: > > UserManager currentUser permissions isRoot: false. > > Is the class gone for good? Is there a equivalent in Pharo 5? > > > > -- > View this message in context: http://forum.world.st/UserManager-class-missing-in-Pharo-5-tp4891617.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 24, 2016

Re: [Pharo-users] Strange behaviour with traits

by stepharo

Really few people used them deeply like that. So you may have found a bug. Le 23/4/16 17:08, Hilaire a Ã©crit : > Hi, > > I have noted somehow that some of my traits get altered by the Pharo > (Nautilus, source code import, Trait system?): > > I have traits of trait, and some got inherited methods turned as trait > methods (duplicated from the parent trait). > > Any one seen strange unreliable behaviour with traits? > > Hilaire > >

April 24, 2016

Re: [Pharo-users] Pillar: PRTemplate?

by Martin Dias

Thanks Yann. Ecstatic is currently using Pillar 0.62. Finally it's not necessary to upgrade now so we can wait. Martin On Sat, Apr 23, 2016 at 1:30 PM, Yann Dubois <yann59.dubois(a)gmail.com> wrote: > Hi, > > PRTemplate was removed in the development version because our goal is > simplify Pillar. To do this, we want Pillar generate only the content of a > document, so the template system was removed. If you want use PRTemplate, > you can use the last stable release of Pillar, and if you want use the > development version, you wil need to write a Makefile (Our Makefile is not > useful for the moment) and put the content in a template engine like > Mustache (the Pharo version is usable with a command line since this week). > > Yann > > 2016-04-23 18:18 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > >> Hi Pillar developers, >> >> A method in Ecstatic [1] references a class named PRTemplate (as well as >> PRTemplateError), which probably existed in a previous version of Pillar. >> Do you know what happened to it? I'm trying to update Ecstatic code to work >> with latest Pillar version released. >> >> Regards, >> Martin >> >> [1]: https://github.com/guillep/ecstatic >> > >

April 23, 2016

Re: [Pharo-users] Pillar: PRTemplate?

by Yann Dubois

Hi, PRTemplate was removed in the development version because our goal is simplify Pillar. To do this, we want Pillar generate only the content of a document, so the template system was removed. If you want use PRTemplate, you can use the last stable release of Pillar, and if you want use the development version, you wil need to write a Makefile (Our Makefile is not useful for the moment) and put the content in a template engine like Mustache (the Pharo version is usable with a command line since this week). Yann 2016-04-23 18:18 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > Hi Pillar developers, > > A method in Ecstatic [1] references a class named PRTemplate (as well as > PRTemplateError), which probably existed in a previous version of Pillar. > Do you know what happened to it? I'm trying to update Ecstatic code to work > with latest Pillar version released. > > Regards, > Martin > > [1]: https://github.com/guillep/ecstatic >

April 23, 2016

Pillar: PRTemplate?

by Martin Dias

Hi Pillar developers, A method in Ecstatic [1] references a class named PRTemplate (as well as PRTemplateError), which probably existed in a previous version of Pillar. Do you know what happened to it? I'm trying to update Ecstatic code to work with latest Pillar version released. Regards, Martin [1]: https://github.com/guillep/ecstatic

April 23, 2016

Strange behaviour with traits

by Hilaire

Hi, I have noted somehow that some of my traits get altered by the Pharo (Nautilus, source code import, Trait system?): I have traits of trait, and some got inherited methods turned as trait methods (duplicated from the parent trait). Any one seen strange unreliable behaviour with traits? Hilaire -- Dr. Geo http://drgeo.eu

April 23, 2016

UserManager class missing in Pharo 5

by kmo

The UserManager class has disappeared in Pharo 5. I was using it as a convenient way to restrict what a user can do with a delivered application: UserManager currentUser permissions isRoot: false. Is the class gone for good? Is there a equivalent in Pharo 5? -- View this message in context: http://forum.world.st/UserManager-class-missing-in-Pharo-5-tp4891617.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 23, 2016

Re: [Pharo-users] Tabular ODS import

by Alistair Grant

On Thu, Apr 21, 2016 at 07:49:24PM -0700, John Pfersich wrote: > > > On Apr 20, 2016, at 23:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > >> On Wed, Apr 20, 2016 at 11:43:19PM +0200, Cyril Ferlicot D. wrote: > >> Le 20/04/2016 22:47, Alistair Grant a Ã©crit : > >> If you use several times the same code you can also give a name to the > >> tab (2 click on "Page") and after you can save the playground code. Via > >> the spotter you can use the name of the tab to get a playground with the > >> code. > > > > This sounds great, but I can't reproduce it. Would you mind clarifying > > what you mean by "2 click on Page"? I tried clicking on the various > > buttons, and clicking action-clicking, and middle buttong click on the > > tab name ("Page"), without success (Pharo 5.0 50702). > > I think you want to double click on "Page". At least it works on Mac OSX and Pharo 5. Ohh, of course (feeling embarrassed now). Thanks! Alistair

April 22, 2016

Re: [Pharo-users] About Traits

by Stephan Eggermont

On 22-04-16 17:04, Hilaire wrote: > Hi Julien, > > > Le 22/04/2016 16:45, Julien Delplanque a Ã©crit : >> Hello, >> >> I have a question about Trait. >> >> Is it ok, in the design point of view, to use them to force an object to >> implement an interface? > Why not using a parent abstract class for that, with required method > answering #subclassResponsability? > > Then from your tests in subclasses, you check > > self shouldnt: [instance toto] raise: SubclassResponsabilty > That limits one to one interface. Why not use a test testTheConformingImplementation self assert: ((AConformingImplementation selectors) asOrderedCollection addAll: (AnInterfaceClass selectors)) asSet = (AConformingImplementation selectors) asSet

April 22, 2016

Re: [Pharo-users] About Traits

by Julien Delplanque

On 22/04/16 17:04, Hilaire wrote: > Hi Julien, > > > Le 22/04/2016 16:45, Julien Delplanque a Ã©crit : >> Hello, >> >> I have a question about Trait. >> >> Is it ok, in the design point of view, to use them to force an object to >> implement an interface? > Why not using a parent abstract class for that, with required method > answering #subclassResponsability? Yes this is what I do for now. But what if I do not want to force the use of inheritance? > > Then from your tests in subclasses, you check > > self shouldnt: [instance toto] raise: SubclassResponsabilty > This wont work if the object does not implement #toto at all. >> Like that it would be possible to check (via an #assert: for example) if >> a class provides the interface required. >> >> I read some things I found on the net about Traits and already used >> TComparable but I never created one myself and I am not sure to >> understand this concept entirely. > > With Trait you add behavior to a class. TComparable adds behavior to > your class, your instance are then comparable. Is it a problem? Isn't it similar to Java's interface? I see traits as a mix between Java's abstract classes and Java's interface since you can define methods and let some of them abstract but you can not define instance variables. But maybe I am wrong, that is why I ask :)... Julien

April 22, 2016