June 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] trait question

by Sebastian Tleye

I also like this uniform because it's easier to program, Up to now i haven't had the need to separate them. 2013/6/30 Tudor Girba <tudor(a)tudorgirba.com> > +1 > > Keeping things uniform is a plus in this case, even though we might lose > some flexibility. > > Doru > > > On Sun, Jun 30, 2013 at 9:01 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Ok I slept and now my brain is working. >> I think that having classTrait and trait together is important because >> else it would be the mess when >> you have a class method that uses an instance methods (both define in a >> trait). >> So conceptually this is one trait like in smalltalk you have one class >> and its metaclass. >> >> The model is similar and to represent class trait we have a ClassTrait >> class. >> >> Stef >> >> >> On Jun 30, 2013, at 1:04 AM, Camillo Bruni <camillobruni(a)gmail.com> >> wrote: >> >> > so let's discuss that on monday with the trait specialists Damien et >> Sebastian :) >> > >> > On 2013-06-29, at 23:34, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> yes, i don't know if it good or bad, but i'd rather prefer that traits >> >> applied to Behavior, >> >> but not to Class (which has two entangled behaviors). But maybe for >> >> human comprehension it is better.. >> >> but not for implementing, because it certainly makes model more >> complex. >> >> >> >> On 29 June 2013 22:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> >> >>> On 2013-06-29, at 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >> >>>> On 29 June 2013 21:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >>>>> >> >>>>> On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>>>> >> >>>>>> On 29 June 2013 20:12, Camillo Bruni <camillobruni(a)gmail.com> >> wrote: >> >>>>>>> Working on the new class builder I have a hard time figuring out >> the full trait >> >>>>>>> semantics. >> >>>>>>> >> >>>>>>> If I use a trait on instance side, does that imply that its >> classTrait on the >> >>>>>>> metaclass? >> >>>>> >> >>>>> No. I do not think so (I will have to think). >> >>>>> Normally Trait and ClassTrait are two different classes. NOw I do >> not remember if a trait is composed >> >>>>> of a classTrait too. >> >>>>> >> >>>> Trait has 'classTrait' >> >>> >> >>> yes, but the strange part is, that if you use a Trait on the >> instance-side it >> >>> will automatically install the class trait as well. >> >>> >> >>> ClassDescription subclass: #Class >> >>> uses: TClass >> >>> ... >> >>> >> >>> and the users >> >>> >> >>> TClass users => an IdentitySet(Class) >> >>> TClass classTrait users => an IdentitySet(Class class) >> >>> >> >>> so in this case it implies that when you use a Trait on the instance >> side it will >> >>> apply also it's classTrait to the class side. So is it ok then to >> enforce that in >> >>> the new class builder? >> >>> >> >>> Currently you can do the following in the new class builder: >> >>> >> >>> PharoClassInstaller make: [:builder| >> >>> builder >> >>> superclass: Object; >> >>> name: 'Foo'; >> >>> traitComposition: TClass ] >> >>> >> >>> which will explicitely NOT install `TClass classTrait` in `Foo class`. >> >>> Does this behavior make sense? >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 30, 2013

Re: [Pharo-users] trait question

by Tudor Girba

+1 Keeping things uniform is a plus in this case, even though we might lose some flexibility. Doru On Sun, Jun 30, 2013 at 9:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ok I slept and now my brain is working. > I think that having classTrait and trait together is important because > else it would be the mess when > you have a class method that uses an instance methods (both define in a > trait). > So conceptually this is one trait like in smalltalk you have one class and > its metaclass. > > The model is similar and to represent class trait we have a ClassTrait > class. > > Stef > > > On Jun 30, 2013, at 1:04 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > so let's discuss that on monday with the trait specialists Damien et > Sebastian :) > > > > On 2013-06-29, at 23:34, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> yes, i don't know if it good or bad, but i'd rather prefer that traits > >> applied to Behavior, > >> but not to Class (which has two entangled behaviors). But maybe for > >> human comprehension it is better.. > >> but not for implementing, because it certainly makes model more complex. > >> > >> On 29 June 2013 22:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >>> > >>> On 2013-06-29, at 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> > >>>> On 29 June 2013 21:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >>>>> > >>>>> On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >>>>> > >>>>>> On 29 June 2013 20:12, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > >>>>>>> Working on the new class builder I have a hard time figuring out > the full trait > >>>>>>> semantics. > >>>>>>> > >>>>>>> If I use a trait on instance side, does that imply that its > classTrait on the > >>>>>>> metaclass? > >>>>> > >>>>> No. I do not think so (I will have to think). > >>>>> Normally Trait and ClassTrait are two different classes. NOw I do > not remember if a trait is composed > >>>>> of a classTrait too. > >>>>> > >>>> Trait has 'classTrait' > >>> > >>> yes, but the strange part is, that if you use a Trait on the > instance-side it > >>> will automatically install the class trait as well. > >>> > >>> ClassDescription subclass: #Class > >>> uses: TClass > >>> ... > >>> > >>> and the users > >>> > >>> TClass users => an IdentitySet(Class) > >>> TClass classTrait users => an IdentitySet(Class class) > >>> > >>> so in this case it implies that when you use a Trait on the instance > side it will > >>> apply also it's classTrait to the class side. So is it ok then to > enforce that in > >>> the new class builder? > >>> > >>> Currently you can do the following in the new class builder: > >>> > >>> PharoClassInstaller make: [:builder| > >>> builder > >>> superclass: Object; > >>> name: 'Foo'; > >>> traitComposition: TClass ] > >>> > >>> which will explicitely NOT install `TClass classTrait` in `Foo class`. > >>> Does this behavior make sense? > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 30, 2013

Re: [Pharo-users] PBE Suggestion: Minor improvement? to pharo.sh

by StÃ©phane Ducasse

On Jun 30, 2013, at 6:12 AM, Kevin Cole <dc.loco(a)gmail.com> wrote: > Hi, > > Given that I now have both the newer VM and image from the Ubuntu Pharo PPA, > and the VM and image from PBE, opening a file browser and clicking on an > image saved from PBE fails, because it wants to open the newer VM. Indeed. Better use the VM that is packed with the PBE image. > No problem. I'll just use pharo.sh from the CLI. Oh, wait. It always wants > to use Contents/Resources/pharo.image. > > No problem. Fix pharo.sh so that it accepts an optional parameter specifying > the image name to open, sans path and ".image". Not especially brilliant, > and bash experts might have a better way (or caveats as to why this is a bad > idea), but now I have something that behaves, with very few changes to the > original pharo.sh: > > "./pharo.sh" opens the default Contents/Resources/pharo.image > "./pharo.sh myPharo" opens Contents/Resources/myPharo.image > > I've posted my minor variation on the distributed pharo.sh below: Thanks. Stef > ____________________________________________________________ > > #!/bin/sh > > # path > ROOT=`dirname $0` > BASE="$ROOT/Contents/Linux" > IMAGES="$ROOT/Contents/Resources" > IMAGE="${1:-pharo}" > > # execute > exec "$BASE/squeakvm" \ > -plugins "$BASE" \ > -encoding latin1 \ > -vm-display-X11 \ > "$IMAGES/$IMAGE.image" >

June 30, 2013

Re: [Pharo-users] Remove a dependency (was Re: How to do this in Pharo 2?)

by StÃ©phane Ducasse

Hi donald you have to define a configurationOfLog4J by hand (soon there will be a tool) Have a look at the metacello chapter http://rmod.lille.inria.fr/pbe2/ You can look for example at the Soup project in PharoExtras on SmalltalkHub to get an example. Now for your problem apparently you somehow requires the package Bindings-Core and when you load Log4J the system does not how to find it. Stef On Jun 30, 2013, at 1:04 AM, Donald <dmacq(a)instantiations.com> wrote: > On 6/29/2013 7:00 PM, Mariano Martinez Peck wrote: >> Hi Donald, >> >> I guess there should be a ConfigurationOfLog4j (or similar name) that defines the versions, the baselines, dependencies, etc. Imagine this (similarly) as a ConfigurationMap. So I guess what you have to do is to take ConfigurationOfLog4j, edit the necessary #baselineXXX method and remove the #requires that brings Bindings-Core. >> >> Torsten, where is the conf? > ok. Where does ConfigurationOfLog4j live? > > Sorry to be dense, but Envy takes care of these things for me day to day. > > -- > Donald [|] > > A bad day in [] is better than a good day in {}

June 30, 2013

Re: [Pharo-users] trait question

by StÃ©phane Ducasse

Ok I slept and now my brain is working. I think that having classTrait and trait together is important because else it would be the mess when you have a class method that uses an instance methods (both define in a trait). So conceptually this is one trait like in smalltalk you have one class and its metaclass. The model is similar and to represent class trait we have a ClassTrait class. Stef On Jun 30, 2013, at 1:04 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > so let's discuss that on monday with the trait specialists Damien et Sebastian :) > > On 2013-06-29, at 23:34, Igor Stasenko <siguctua(a)gmail.com> wrote: >> yes, i don't know if it good or bad, but i'd rather prefer that traits >> applied to Behavior, >> but not to Class (which has two entangled behaviors). But maybe for >> human comprehension it is better.. >> but not for implementing, because it certainly makes model more complex. >> >> On 29 June 2013 22:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> On 2013-06-29, at 22:32, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 29 June 2013 21:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> On Jun 29, 2013, at 8:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>>> On 29 June 2013 20:12, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>>>> Working on the new class builder I have a hard time figuring out the full trait >>>>>>> semantics. >>>>>>> >>>>>>> If I use a trait on instance side, does that imply that its classTrait on the >>>>>>> metaclass? >>>>> >>>>> No. I do not think so (I will have to think). >>>>> Normally Trait and ClassTrait are two different classes. NOw I do not remember if a trait is composed >>>>> of a classTrait too. >>>>> >>>> Trait has 'classTrait' >>> >>> yes, but the strange part is, that if you use a Trait on the instance-side it >>> will automatically install the class trait as well. >>> >>> ClassDescription subclass: #Class >>> uses: TClass >>> ... >>> >>> and the users >>> >>> TClass users => an IdentitySet(Class) >>> TClass classTrait users => an IdentitySet(Class class) >>> >>> so in this case it implies that when you use a Trait on the instance side it will >>> apply also it's classTrait to the class side. So is it ok then to enforce that in >>> the new class builder? >>> >>> Currently you can do the following in the new class builder: >>> >>> PharoClassInstaller make: [:builder| >>> builder >>> superclass: Object; >>> name: 'Foo'; >>> traitComposition: TClass ] >>> >>> which will explicitely NOT install `TClass classTrait` in `Foo class`. >>> Does this behavior make sense? >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

June 30, 2013

PBE Suggestion: Minor improvement? to pharo.sh

by Kevin Cole

Hi, Given that I now have both the newer VM and image from the Ubuntu Pharo PPA, and the VM and image from PBE, opening a file browser and clicking on an image saved from PBE fails, because it wants to open the newer VM. No problem. I'll just use pharo.sh from the CLI. Oh, wait. It always wants to use Contents/Resources/pharo.image. No problem. Fix pharo.sh so that it accepts an optional parameter specifying the image name to open, sans path and ".image". Not especially brilliant, and bash experts might have a better way (or caveats as to why this is a bad idea), but now I have something that behaves, with very few changes to the original pharo.sh: "./pharo.sh" opens the default Contents/Resources/pharo.image "./pharo.sh myPharo" opens Contents/Resources/myPharo.image I've posted my minor variation on the distributed pharo.sh below: ____________________________________________________________ #!/bin/sh # path ROOT=`dirname $0` BASE="$ROOT/Contents/Linux" IMAGES="$ROOT/Contents/Resources" IMAGE="${1:-pharo}" # execute exec "$BASE/squeakvm" \ -plugins "$BASE" \ -encoding latin1 \ -vm-display-X11 \ "$IMAGES/$IMAGE.image"

June 30, 2013

Fixed! (was Re: Remove a dependency (was Re: How to do this in Pharo 2?))

by Donald

On 6/29/2013 7:13 PM, Camillo Bruni wrote: ok. got it. I was in the wrong browser. The new version 17 of log4s in ss3.gemstone works without the dependency on Benoits Bindings package. Thanks to everyone for their help. Back into the arms of Envy. ;-) -- Donald [|] A bad day in [] is better than a good day in {}

June 30, 2013

Re: [Pharo-users] Remove a dependency (was Re: How to do this in Pharo 2?)

by Mariano Martinez Peck

On Sat, Jun 29, 2013 at 8:13 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2013-06-30, at 00:56, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > > On 2013-06-30, at 00:47, Donald <dmacq(a)instantiations.com> wrote: > > > >> On 6/29/2013 4:42 PM, Camillo Bruni wrote: > >>> look at String >> #format: > >> ok, got that fixed. > >> > >> how do I remove the log4s dependency on > >> > >> Bindings-Core-tbn.1? > >> > >> I don't seen anything in the Monticello browser that lets me > unload/unlink/remove etc. > > ok I finally understood... > > - Right click on the package in the Monticello Browser (use the search bar > on top) > - Remove required Package > - Recommit Log4s > > that should remove the dependency from the MC package\ ohhh, was it using MC requirements? > > FYI: please state clearly what you try to do next time with instructions to > reproduce ;) > -- Mariano http://marianopeck.wordpress.com

June 29, 2013

Re: [Pharo-users] Remove a dependency (was Re: How to do this in Pharo 2?)

by Camillo Bruni

On 2013-06-30, at 00:56, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-30, at 00:47, Donald <dmacq(a)instantiations.com> wrote: > >> On 6/29/2013 4:42 PM, Camillo Bruni wrote: >>> look at String >> #format: >> ok, got that fixed. >> >> how do I remove the log4s dependency on >> >> Bindings-Core-tbn.1? >> >> I don't seen anything in the Monticello browser that lets me unload/unlink/remove etc. ok I finally understood... - Right click on the package in the Monticello Browser (use the search bar on top) - Remove required Package - Recommit Log4s that should remove the dependency from the MC package. FYI: please state clearly what you try to do next time with instructions to reproduce ;)

June 29, 2013

Re: [Pharo-users] Remove a dependency (was Re: How to do this in Pharo 2?)

by Paul DeBruicker

And you're probably looking for ConfigurationOfLog4s rather than Log4j..... On 06/29/2013 04:04 PM, Donald wrote: > On 6/29/2013 7:00 PM, Mariano Martinez Peck wrote: >> Hi Donald, >> >> I guess there should be a ConfigurationOfLog4j (or similar name) that >> defines the versions, the baselines, dependencies, etc. Imagine this >> (similarly) as a ConfigurationMap. So I guess what you have to do is >> to take ConfigurationOfLog4j, edit the necessary #baselineXXX method >> and remove the #requires that brings Bindings-Core. >> >> Torsten, where is the conf? > ok. Where does ConfigurationOfLog4j live? > > Sorry to be dense, but Envy takes care of these things for me day to day. > > -- > Donald [|] > > A bad day in [] is better than a good day in {} >

June 29, 2013