- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] new 10095 prebuild image

by Marcus Denker

Hi, There is now a new core image available based on 10095: https://gforge.inria.fr/frs/download.php/9395/Pharo0.1-10095.zip one-click will come soon, too. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 15, 2008

Re: [Pharo-project] PluggableMultiSelectList, ListStub (SUnitToolBuilder)

by Michael Roberts

http://code.google.com/p/pharo/wiki/HowToContribute which is roughly 1) Sign the agreement 2) Check the issue tracker, you could also check Mantis 3) Create an entry on the issue tracker if you want to, either with a CS or reference to a SLICE in the PharoInbox, 4) discuss here or watch what people comment on the tracker cheers, Mike

Oct. 14, 2008

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

by Dan Corneanu

I've put up a small change set with fixes as suggested in http://bugs.squeak.org/view.php?id=6798. I have tested the change set in pharo0.1-10082dev08.10.1 and it works OK. A comment on the OBNode>>isDescendentOf: method would have spared me a lot of effort. I had a hard time finding out that self isDescendentOf: self should return true. Best regards, Dan Corneanu.

Oct. 14, 2008

[Pharo-project] PluggableMultiSelectList, ListStub (SUnitToolBuilder)

by John Thornborrow

Hello List, I've hit an error when using SUnit to test a morphic window that uses PluggableMultiSelectList - I've got a fix, and want to contribute, but don't want to tread on anyones toes, so I'm asking the following: 1) What is the correct process for contributing code? 2) Has anyone else hit this problem, and/or have (maybe better) plans to solve? Many thanks, and regards, John. ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Oct. 14, 2008

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