- Pharo-dev - lists.pharo.org

[Pharo-project] [OT] Marry Xmas
by Igor Stasenko Dec. 26, 2009

Dec. 26, 2009

Hello, my best wishes to everyone! I enjoying to be a part of smalltalk community, its good spirit and friendly people. I'd like to thank everyone who actively participating in discussions, because that's the way we all have a chance to learn something new. And, of course, thanks to everyone who are pushing things forward. Do not hesitate to share your ideas and thoughts. We are need them, if we want to make better things. With all my respect to everyone, sincerely yours, Igor Stasenko.

1 0

[Pharo-project] 1696 ready to integrate
by Mariano Martinez Peck Dec. 25, 2009

Dec. 25, 2009

http://code.google.com/p/pharo/issues/detail?id=1696 In PharoInbox Name: SLICE-Issue1696-NewTestsToWeek-MarianoMartinezPeck.2 Author: MarianoMartinezPeck Time: 25 December 2009, 11:45:35 pm UUID: 19032e1f-517d-4e47-97dc-97da66fb19fb Ancestors: SLICE-Issue1696-NewTestsToWeek-MarianoMartinezPeck.1 Dependencies: KernelTests-MarianoMartinezPeck.185 Added tests for Week class methods indexOfDay:, nameOfDay: and dayNames. >From Andreas in Squeak trunk Name: KernelTests-ar.85 Author: ar Time: 25 August 2009, 8:22:23 am UUID: 4e893949-199f-dc4d-9585-0814f2d57630 Ancestors: KernelTests-mha.84, KernelTests-it.69 Merged KernelTests-it.69: Reformatted code in Week>>startDay. Added tests for Week class methods indexOfDay:, nameOfDay: and dayNames.

1 0

[Pharo-project] Need Levente Uzonyi license
by Mariano Martinez Peck Dec. 25, 2009

Dec. 25, 2009

Hi Levente: I would like to integrate some of your code (most changes to squeak) but as you may know, any code commited to Pharo must be MIT license and we need the sign of the author (http://www.pharo-project.org/license) Would you mind to send it ? Thank you very much. Mariano

3 3

[Pharo-project] 1695 ready to integrate
by Mariano Martinez Peck Dec. 25, 2009

Dec. 25, 2009

http://code.google.com/p/pharo/issues/detail?id=1695 Commited in PharoInbox: Name: SLICE-issue1695-PruneSearchInMonticello-MarianoMartinezPeck.2 Author: MarianoMartinezPeck Time: 25 December 2009, 11:12:33 pm UUID: cb9c068d-bc33-40b0-8ede-c2891cc99c2d Ancestors: SLICE-issue1695-PruneSearchInMonticello-MarianoMartinezPeck.1 Dependencies: Monticello-MarianoMartinezPeck.411 - prune search in MCFilteredVersionSorter >From squeak trunk: Name: Monticello-bf.341 Author: bf Time: 19 December 2009, 5:49:47 am UUID: ab5017e8-0082-4570-b6cb-1d678262ccfe Ancestors: Monticello-gsa.340 - prune search in MCFilteredVersionSorter

1 0

[Pharo-project] 1694 ready to integrate
by Mariano Martinez Peck Dec. 25, 2009

Dec. 25, 2009

http://code.google.com/p/pharo/issues/detail?id=1694 SLICE-issue1694-newTestsToProtoObject-MarianoMartinezPeck.2 En PharoInbox. After this update you should have 10 tests in ProtoObjectTest and all green. (before only 2 tests). Cheers, Mariano

1 0

[Pharo-project] about resetTo: in newFrom:
by StÃ©phane Ducasse Dec. 25, 2009

Dec. 25, 2009

Hi levente Reading your changes I was wondering if resetTo: should not be moved into OrderedCollection class >> new: and why only have it for the default new? OrderedCollection class >>newFrom: aCollection "Answer an instance of me containing the same elements as aCollection." + ^(self new: aCollection size) + resetTo: 1; + addAll: aCollection; + yourself - | newCollection | - newCollection := self new: aCollection size. - newCollection addAll: aCollection. - ^newCollection I did OrderedCollection new: 100. and contrary to what I expected firstIndex is not 1 but 33. Now when you add resetTo: 1 firstIndex get 1. new: anInteger "Create a collection with enough room allocated to contain up to anInteger elements. The new instance will be of size 0 (allocated room is not necessarily used)." ^self basicNew setCollection: (Array new: anInteger) setCollection: anArray array := anArray. self reset reset firstIndex := array size // 3 max: 1. lastIndex := firstIndex - 1

3 4

[Pharo-project] need hunter to kill the double paste bug.
by StÃ©phane Ducasse Dec. 25, 2009

Dec. 25, 2009

> Hi all, > > attached a little patch to capture events and paste buffer. > > If you encounter a double paste please take a look at > LastClipPaste and LastEvents. > > If this doesn't provide any clue, I will work out a more aggressive tracing approach. > > Didn't send it to the list as it patches into system methods. So as mike says pay attention this is hackish :) > > Michael >

6 20

Re: [Pharo-project] #sortBlock:
by Julian Fitzell Dec. 25, 2009

Dec. 25, 2009

On Thu, Dec 24, 2009 at 12:19 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> #sortBlock: is defined by ANSI on SortedCollection as an accessor and >>>> an instance creation method. That's what it sounds like and shouldn't >>>> be implemented on non-sorted collections. >>> >>> Why? what would be the reason not to use sortBlock: for others? >> >> The intention is different. #sortBlock: tells a collection to maintain >> itself as sorted even after additions and deletions. This message is not >> appropriate for collections that do not have that ability. >> >> #sortBlock: is not the best name for this functionality, but I think >> it's bad to use #sortBlock: with a different meaning. > > I agree :) > Now SortedCollection should understand sort too which uses sortBlock: > My main concern is polymorphism between collection which are nearly the same! #sortBlock: is an accessor for the sortBlock instance variable on SortedCollection. It makes no sense for a collection that doesn't have that instance variable to have that accessor. That's like saying Array should implement #hashBlock: because PluggableSet has it... Julian

3 6

[Pharo-project] Issue 1690: New method trailer format for Pharo
by Igor Stasenko Dec. 25, 2009

Dec. 25, 2009

I reviewed the trailers changesets and adopted them for Pharo.. Please, tell me how it goes. -- Best regards, Igor Stasenko AKA sig.

2 1

Dec. 25, 2009

resent from a discussion on squeak-dev Hi David, Interesting! To my mind that definition is incorrect. I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be BlockClosure methods for accessing sender ^self home sender A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller. But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method. I think I may have screwed up badly here and that the correct implementations should be MethodContext methods for accessing caller ^closureOrNil ifNil: [self error: 'this is a method activation and so has no caller'] ifNotNil: [sender] sender ^closureOrNil ifNil: [sender] ifNotNil: [closureOrNil outerContext sender] BlockClosure methods for accessing sender ^outerContext sender and either BlockClosure methods for accessing caller "Since a BlockClosure is by definition not an activation it does not have a caller. It has a sender because it is always created within the context of a method." ^nil or BlockClosure methods for accessing caller ^self error: 'this is an inactive block and so has no caller' I believe the pre-closure definitions are ContextPart methods for accessing sender ^sender BlockContext methods for accessing caller ^sender which to my mind is missing BlockContext methods for accessing sender ^home sender What do people think the right definitions should be? - Show quoted text - On Fri, Dec 18, 2009 at 8:36 PM, <commits(a)source.squeak.org> wrote: David T. Lewis uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-dtl.331.mcz ==================== Summary ==================== Name: Kernel-dtl.331 Author: dtl Time: 18 December 2009, 11:32:44 am UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e Ancestors: Kernel-bs.330 Add BlockClosure>>sender required for MessageTally class>>tallySends: Harvested from Pharo (nice 4/14/2009 19:09). =============== Diff against Kernel-bs.330 =============== Item was added: + ----- Method: BlockClosure>>sender (in category 'debugger access') ----- + sender + "Answer the context that sent the message that created the receiver." + + ^outerContext sender!

1 0