October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [:bool : method | bool or: [method name = #y]]).

by Lukas Renggli

> I found that the compiler accepts > > [:bool : method | method] > > which is strange to me. In method headers you also put a space between colon and argument. Lukas > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 14, 2008

[Pharo-project] [:bool : method | bool or: [method name = #y]]).

by StÃ©phane Ducasse

Hi I found that the compiler accepts [:bool : method | method] which is strange to me. Stef

Oct. 14, 2008

[Pharo-project] Fwd: [squeak-dev] re: About classVariables

by StÃ©phane Ducasse

> A nice fix. > http://code.google.com/p/pharo/issues/detail?id=246&colspec=ID%20Type%20Sta… The discussion on squeakdev was interesting. > Stef > > Begin forwarded message: > >> From: "Eliot Miranda" <eliot.miranda(a)gmail.com> >> Date: October 13, 2008 9:43:15 PM CEDT >> To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org >> > >> Subject: Re: [squeak-dev] re: About classVariables >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> >> >> >> On Mon, Oct 13, 2008 at 2:02 AM, Martin Beck <martin.beck(a)hpi.uni-potsdam.de >> > wrote: >> Craig Latta wrote: >> > >> > Hi Stef-- >> > >> >> To my stupefaction I discovered that the classVariables of a >> class are >> >> not the same as the ones of its metaclass. >> >> >> >> TheRoot classVarNames ~= TheRoot class classVarNames >> >> >> >> Does any body have some ideas why this is like that? For me this >> is a >> >> conceptual bug. >> > >> > Actually, metaclasses don't really have class variables at >> all. >> > Class variables are defined by Class, which is a sibling of >> Metaclass, >> > not a superclass. There's a method in Behavior which just answers >> a new >> > empty Set for classVarNames; this is what you're invoking when you >> > evaluate [TheRoot class classVarNames]. >> > >> However, >> >> TheRoot classPool = TheRoot class classPool >> >> evaluates to true... >> >> Regards, >> Martin >> >> One fix is to add the following method: >> ------------8<----------- >> !Metaclass methodsFor: 'class variables' stamp: 'eem 10/13/2008 >> 12:37'! >> classVarNames >> "Answer a Set of the names of the class variables defined in the >> receiver's instance." >> >> ^thisClass classVarNames! ! >> ------------8<----------- >> c.f. Metaclass>>classPool. >> >> But a better fix is to move Class>>classVarNames to ClassDescription: >> ------------8<----------- >> 'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 13 >> October 2008 at 12:41:36 pm'! >> >> !ClassDescription methodsFor: 'class variables' stamp: 'eem >> 10/13/2008 12:41'! >> classVarNames >> "Answer a Set of the names of the class variables defined in the >> receiver." >> >> ^self classPool keys! ! >> >> Class removeSelector: #classVarNames! >> ------------8<----------- >> >> Whoever said that the class variables of a metaclass should be >> those of Metaclass is very wrong. Code compiled in the context of >> a metaclass includes the class variables of the non-metaclass >> (metaclass's instance), otherwise one couldn't access class >> variables in class-side methods. >> > > >

Oct. 14, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Dan Corneanu

I use pharo0.1-10082dev08.10.1 You are right, it works for the dev image with no updates. If I load the latest code updates it does not work anymore. World -> Pharo -> Update code from server On Sun, Oct 12, 2008 at 1:48 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Fri, Oct 10, 2008 at 10:38 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: >> but completion is not working in the dev image :) Has the >> shortcut changed? I use CTRL-Space. > > It should work. What image are you using exactly? I use TAB instead of > CTRL-Space, but both should work. > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Oct. 14, 2008

Re: [Pharo-project] Long term GUI plans for Pharo

by StÃ©phane Ducasse

> Hi, > > >> Long plans without money ? > > Yeees :-) >> >> Anyway let me give a try: >> - we want to make sure that several and different GUI frameworks >> can be plugged. >> - for the moment mike is designing a better Event hierarchy and >> should clean >> the polling of events. >> - at the same time polymorph should be integrated and we will >> cure Morphic ugly and useless experiments >> - in parallel alain is developing Miro which may use 5 classes of >> Morphic. He will be using >> the new event hierarchy. Right now he was looking for a layout >> engine (we pointed to the one of Sophie). >> - there is Rome to talk to cairo. > > so Rome later will be the Interface for pluggable GUI Frameworks as > stated above? may be > > >> >> so the key point is for now >> - cleaning >> - making sure that we do not have the >> Smalltalk isMorphic kind of pluggability in the future >> - be opportunistic >> > > Sounds good and it seems it is in the right hands. Cool! you are welcome to contribute Stef

Oct. 14, 2008

Re: [Pharo-project] Long term GUI plans for Pharo

by Hans N Beck

Hi, > Long plans without money ? Yeees :-) > > Anyway let me give a try: > - we want to make sure that several and different GUI frameworks > can be plugged. > - for the moment mike is designing a better Event hierarchy and > should clean > the polling of events. > - at the same time polymorph should be integrated and we will > cure Morphic ugly and useless experiments > - in parallel alain is developing Miro which may use 5 classes of > Morphic. He will be using > the new event hierarchy. Right now he was looking for a layout > engine (we pointed to the one of Sophie). > - there is Rome to talk to cairo. so Rome later will be the Interface for pluggable GUI Frameworks as stated above? > > so the key point is for now > - cleaning > - making sure that we do not have the > Smalltalk isMorphic kind of pluggability in the future > - be opportunistic > Sounds good and it seems it is in the right hands. Cool! Best regards Hans > > > > On Oct 14, 2008, at 8:27 AM, Hans N Beck wrote: > >> >> Hi all, >> >> I remember darkly a discussion about possibilities to give Sqeak or >> Pharo indepenend Windows not enclosed in a main window. >> >> An other point was to make Cairo the render base for all. >> >> So related to this points, what are the long term plans for pharo? >> >> Regards >> >> Hans >> --------------- >> >> Hans Beck >> Walzbachtal >> Germany >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2008

Re: [Pharo-project] Long term GUI plans for Pharo

by StÃ©phane Ducasse

Long plans without money ? Anyway let me give a try: - we want to make sure that several and different GUI frameworks can be plugged. - for the moment mike is designing a better Event hierarchy and should clean the polling of events. - at the same time polymorph should be integrated and we will cure Morphic ugly and useless experiments - in parallel alain is developing Miro which may use 5 classes of Morphic. He will be using the new event hierarchy. Right now he was looking for a layout engine (we pointed to the one of Sophie). - there is Rome to talk to cairo. so the key point is for now - cleaning - making sure that we do not have the Smalltalk isMorphic kind of pluggability in the future - be opportunistic Stef On Oct 14, 2008, at 8:27 AM, Hans N Beck wrote: > > Hi all, > > I remember darkly a discussion about possibilities to give Sqeak or > Pharo indepenend Windows not enclosed in a main window. > > An other point was to make Cairo the render base for all. > > So related to this points, what are the long term plans for pharo? > > Regards > > Hans > --------------- > > Hans Beck > Walzbachtal > Germany > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2008

Re: [Pharo-project] SLICE-Mantis-Collection-Fix-mining-nice-2

by StÃ©phane Ducasse

On Oct 13, 2008, at 10:15 PM, nicolas cellier wrote: > > Please note that original Collections-nice.111 had the deprecated > method (at least my local copy of it) > > SequenceableCollection>>startsWith: aCollection > > self deprecated: 'Use beginsWith:.'. > ^self beginsWith: aCollection > > > Maybe Stef was overzealous because I replaced two sole senders in > base image (Service-Base-nice.38) ? Strange strange since I did not change anything. May be I forgot to push Service-Base38 to pharo or it did not load when I loaded the slice. Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2008

Re: [Pharo-project] Re: SLICE-Mantis-Collection-Fix-mining-nice-2

by StÃ©phane Ducasse

On Oc > Please note that original Collections-nice.111 has the deprecated > method > (at least my local copy of it). > > SequenceableCollection>>startsWith: aCollection > > self deprecated: 'Use beginsWith:.'. > ^self beginsWith: aCollection > > > Since I replaced two sole senders in Base image (Service-Base-nice. > 38), > maybe Stef was overzealous ? No I did not changed anything. So this is strange because we should not loose code like that.

Oct. 14, 2008

Re: [Pharo-project] Re: SLICE-Mantis-Collection-Fix-mining-nice-2

by StÃ©phane Ducasse

OK Indeed I thought that it was a better version. On Oct 14, 2008, at 12:28 AM, nicolas cellier wrote: > Adrian Lienhard <adi@...> writes: > >> >> >> On Oct 13, 2008, at 22:40 , StÃ©phane Ducasse wrote: >> >>> But I harvested them in 10093 :) >> >> Oh, really? When I merged the slice from the inbox I think I saw >> changes and I don't think your log mentions these fixes. >> >> Adrian >> > > Seems like there is a little confusion between Collection and > KernelNumber > > Stef collected SLICE-Mantis-Collection-Fix-mining-nice-2 > Adrian collected SLICE-Mantis-KernelNumber-Fix-mining-nice-1 > > Cheers > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2008