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

[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

[Pharo-project] Alien-Core-kdt.59
by Ken Treis Oct. 21, 2009

Oct. 21, 2009

AlienWeakTable sends #copyGrownBy: to both of its internal arrays, but it looks like neither Squeak nor Pharo implement it in the collection hierarchy. Pharo has #grownBy:, but Squeak doesn't. So in Alien-Core- kdt.59, I implemented SequenceableCollection>>copyGrownBy: by copying in the Pharo implementation of #grownBy:. This should solve some nastiness that could happen when the table hit its initial maximum (1024 objects). -- Ken Treis Miriam Technologies, Inc.

1 0

[Pharo-project] Stack re-implemented
by Niko Schwarz Oct. 21, 2009

Oct. 21, 2009

Hi list, issue 1336 proposes re-implementing Stack using the new LinkedList which can take arbitrary objects. I committed the code and it was really straightforward to do. Now stack is implemented in 3 one-line methods, removing about 10 methods, and removing one class (StackLink). Please see http://code.google.com/p/pharo/issues/detail?id=1336 or SLICE-issue-1336-StackReimplemented-NikoSchwarz.2. in the inbox. Cheers, Niko

1 0

Oct. 21, 2009

When coding in the debugger, and accessing directly an instvar, writing code after the instvar raises a Message not understood as the debugger map is nil. http://code.google.com/p/pharo/issues/detail?id=1351 -- CÃ©drick

2 2

Oct. 21, 2009

Hi I want to thank you all for the three or four last days. It was good energy. Stef PS: for the others, adrian took some notes for the next iteration http://code.google.com/p/pharo/wiki/Milestones The idea is to have some focused tasks beside the normal continuous improvement and also have previous items. stef

2 2

Oct. 21, 2009

Useful ? There are other related commits. Cheers ---------- Forwarded message ---------- From: <commits(a)source.squeak.org> Date: 2009/10/21 Subject: [squeak-dev] The Trunk: Exceptions-jcg.14.mcz To: squeak-dev(a)lists.squeakfoundation.org Joshua Gargus uploaded a new version of Exceptions to project The Trunk: http://source.squeak.org/trunk/Exceptions-jcg.14.mcz ==================== Summary ==================== Name: Exceptions-jcg.14 Author: jcg Time: 21 October 2009, 12:59:37 pm UUID: 6fba13f2-81a8-4949-8b9e-d5c10aa58da6 Ancestors: Exceptions-nice.13 Add NotYetImplemented exception class. =============== Diff against Exceptions-nice.13 =============== Item was added: + ----- Method: NotYetImplemented>>receiverClass:selector: (in category 'initialize') ----- + receiverClass: cls selector: sel + receiverClass := cls. + selector := sel.! Item was added: + ----- Method: NotYetImplemented>>selector (in category 'accessing') ----- + selector + ^selector! Item was added: + Error subclass: #NotYetImplemented + instanceVariableNames: 'receiverClass selector context' + classVariableNames: '' + poolDictionaries: '' + category: 'Exceptions-Kernel'! + + !NotYetImplemented commentStamp: 'jcg 10/21/2009 00:58' prior: 0! + Sent by #notYetImplemented. Better than the age-old behavior of opening a notifier window, because this can be caught and handled + + Perhaps there should be a Morphic backstop to open a notifier if no-one else handles the exception, but this doesn't seem too important. + ! Item was added: + ----- Method: NotYetImplemented>>receiverClass (in category 'accessing') ----- + receiverClass + ^receiverClass! Item was added: + ----- Method: NotYetImplemented class>>signal (in category 'signaling') ----- + signal + "Call only from #notYetImplemented. Find the context that sent #nYI... this is the method that needs to be implemented." + | ctxt ex | + ctxt := thisContext sender sender. + ex := self new. + ex receiverClass: ctxt receiver class selector: ctxt selector. + ex messageText: ctxt printString. + ex signal. + ! -- CÃ©drick

2 1