- Pharo-dev - lists.pharo.org

[Pharo-project] The package of ParagraphEditor
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

I never understood why a User Interface class was in the Kernel I'm curious to know what Pavel think about it ! Squeak/trunk put it to a better place: ParagraphEditor ( snip ) category: 'ST80-Controllers' Shouldn't Pharo follow this re-classification ? Nicolas

2 1

[Pharo-project] [update 1.1 ] #11011
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

11011 ----- - Issue 1357: use includesSelector: rather than selectors includes: Rationale for using #includesSelector: - a single message is better than two - an optimized method is better than a slow one The method is optimized because it directly ask methodDict includesKey: rather than creating an unecessary intermediate collection.

1 0

[Pharo-project] making #classVarNames answer a sorted Array
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

Proposal is logged at http://code.google.com/p/pharo/issues/detail?id=1354 Recently in trunk

2 2

[Pharo-project] found a mac magsafe power adapter
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

one of the pharo sprinter forgot his adaptor :) let me know that we ship it by post Stef

3 3

[Pharo-project] Question about PBE book by newbie, instance variables
by Gerben van de Wiel Oct. 22, 2009

Oct. 22, 2009

Hi, I am very new to Pharo and Smalltalk in general. When reading through the excellent PBE book i was wondering about something on page 32. In that piece of code the LOCell class is using some instance variables from it's super classes, and i was wondering if it isn't best practice to use message to self using the accessing methods so instead of. bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16). or is good to use both or is there something i don't know (maybe it is faster to use instance vars then sending a new message and traverse the inheritance tree). regards, Gerben van de Wiel

6 8

[Pharo-project] thanks to all the sprinters
by stephan＠stack.nl Oct. 22, 2009

Oct. 22, 2009

> could organize one at Fosdem but this is just the beginning of > winter holiday in france :( > > Stef FOSDEM would be good. Saturday 6 and sunday 7 februari 2010, Brussels. Stephan

1 0

[Pharo-project] make #keys answer an Array rather than a Set
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

I made a proposal here: http://code.google.com/p/pharo/issues/detail?id=1353 feel free to comment about it

2 1

[Pharo-project] issue 429: collapseAll
by Laval Jannik Oct. 22, 2009

Oct. 22, 2009

Hi all, In issue 429, when we do a "collapse all windows" PasteUpMorph>>collapseAll is invoked. This method collapse non window elements. But, when we do an "expand all windows", only windows are expanded. So my question is: Do we want to collapse all non window elements ? If yes, we must to expand them in "expand all windows" If no, I remove this behavior. Cheers, --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

1 0

Re: [Pharo-project] [squeak-dev] Re: Issue with traits
by Ken.Dickey Oct. 22, 2009

Oct. 22, 2009

Why not share the code? Â Just use a "cell" to hold the class and have methodClass accessor do the indirection. If you have a bit in the method header, the VM could use it as a 0/1 index into the code to call to do (or not do) the extra indirection. Â Just think of the a trait method as a closure which is parameterized on the class. Am I missing something deep here? -KenD > Message: 7 > Date: Wed, 21 Oct 2009 09:41:08 +0200 > From: Adrian Lienhard <adi(a)netstyle.ch> > Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits > To: The general-purpose Squeak developers list > Â Â Â Â Â Â Â Â <squeak-dev(a)lists.squeakfoundation.org>, Â Â Â Â Â Â Â Pharo Development > Â Â Â Â Â Â Â Â <pharo-project(a)lists.gforge.inria.fr> > Message-ID: <3C7E5C51-21A8-483A-81A0-40854430A43B(a)netstyle.ch> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > I've fixed this issue in Pharo a couple of months ago. CompiledMethods Â > are not shared anymore, so methodClass returns the expected class. At Â > the time I implemented traits (2004?), there were no method properties Â > and hence sharing compiled methods worked -- of course except for Â > super sends in which case the method was always recompiled (so the Â > answer to Andreas' question below is b)). > > Cheers, > Adrian

2 1

[Pharo-project] MC 1.6 status?
by Igor Stasenko Oct. 21, 2009

Oct. 21, 2009

Hello people, i'd like to see some answers about the fate of MC 1.6. and its current situation. 1. I think everyone wants to have an atomic loading. But according to my knowledge, MC 1.6. has some problems with Traits, which prevets us from using it & fully replace the older version. 2. Besides of that, are there any other reasons to not have it? So, please, can we disscuss (friendly & constructive), what we might need to have it integrated in Squeak and in Pharo, so we could benefit from having an atomic loading? -- Best regards, Igor Stasenko AKA sig.

3 6