March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11262

by StÃ©phane Ducasse

11262 ----- - Issue 2018: remove #clone (thanks Philippe) Stef Philippe is getting champion in removing Object method (the competition is getting tough)

March 13, 2010

[Pharo-project] Questions about TextMorph

by Fernando olivero

I building a new TextMorph, in the context of porting Cuis Editors. I'm having problems understanding some behavior of TexMorph, 1. Whats the purpose of predecessor and successor in TextMorph? 2. Why does the paragraph needs to be lazily initialized. Im my implementation of TextMorph i have neither and i don't see a good reason to add them. Fernando

March 13, 2010

Re: [Pharo-project] Collection

by Igor Stasenko

On 13 March 2010 13:24, Stephan Eggermont <stephan(a)stack.nl> wrote: > Igor wrote: >>If such kind of collections didn't existed over more than >>30 years of smalltalk existance, what makes you think >>that there a big interest in having them today? > Memory. Without the memory to use them, the need was > not there. >>Of course, they could occupy some niche, but i doubt >>that they will replace an existing classes in a day-to-day use. > In a 64 bit system, it is not a niche. You simply need a set of > collection classes that work well with millions an tens of millions > of elements, not just 100.000s. What you talking about is an edge case in currently existing systems. And its easy to prove: (OrderedCollection allInstances collect: [:each | each size ]) asBag sortedCounts {2956->0 . 1054->1 . 570->4 . 457->5 . 387->6 . 288->2 . 247->3 . 222->7 . 162->8 . 145->9 . 83->10 . 66->11 . 41->12 . 27->14 . 18->13 . 14->15 . 11->16 . 8->30 . 6->17 . 6->25 . 5->36 . 4->21 . 4->27 . 4->42 . 3->26 . 2->18 . 2->23 . 2->24 . 2->35 . 2->44 . 2->52 . 2->222 . 2->336 . 2->1352 . 1->20 . 1->22 . 1->32 . 1->33 . 1->34 . 1->38 . 1->43 . 1->48 . 1->53 . 1->69 . 1->73 . 1->74 . 1->89 . 1->90 . 1->100 . 1->120 . 1->121 . 1->129 . 1->131 . 1->133 . 1->137 . 1->158 . 1->167 . 1->177 . 1->190 . 1->197 . 1->198 . 1->206 . 1->219 . 1->231 . 1->232 . 1->278 . 1->293 . 1->312 . 1->317 . 1->354 . 1->359 . 1->372 . 1->394 . 1->412 . 1->482 . 1->565 . 1->605 . 1->640 . 1->670 . 1->680 . 1->694 . 1->751 . 1->872} and until this list will show a 5% or more presence of collections which having 100000 and more elements, i don't see a pressing need in doing something, because obviously, a current implementation which works fine for general cases. Or do you think that on 64 bit systems the above distribution will be different? >>Besides, many projects implementing own kinds of collections, >>specific to their needs. > That is exactly what you want to avoid. I've had to implement > these collections too often. > So, what stopping you from creating a separate package, say CollectionsXL and add there a generalized versions of collections which optimized for working with extremely large datasets? > Stephan > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 13, 2010

[Pharo-project] [update 1.1] #11260

by StÃ©phane Ducasse

11260 ----- - Issue 2111: Object>>initialExtent - Issue 2133: AllChangeSets size == 8482 ... and I m not explicitly using ChangeSets (part one) - Issue 2106: NullStream bern sprinters....

March 13, 2010

[Pharo-project] [update 1.1] #11261

by StÃ©phane Ducasse

11261 ----- - Issue 1978: Refactored DirectoryEntry by Chris Muller (tx Philippe) - Issue 2137: TextConverter cleaning Removes unneccessary complexity from TextConverter>> nextPutAll:toStream, use streamContents for code clarity in String>>convertToWithConverter. - Issue 1656: remove #asOOP Stef

March 13, 2010

[Pharo-project] [update] #10513

by Adrian Lienhard

10513 ----- Issue 2102: Fix the fact that local temp can shadow silently instance var (thanks Jorge and Lukas!) Running all tests I get: 7137 run, 7120 passes, 17 expected failures, 0 failures, 0 errors, 0 unexpected passes :) Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

March 13, 2010

Re: [Pharo-project] Collection

by Stephan Eggermont

Igor wrote: >If such kind of collections didn't existed over more than >30 years of smalltalk existance, what makes you think >that there a big interest in having them today? Memory. Without the memory to use them, the need was not there. >Of course, they could occupy some niche, but i doubt >that they will replace an existing classes in a day-to-day use. In a 64 bit system, it is not a niche. You simply need a set of collection classes that work well with millions an tens of millions of elements, not just 100.000s. >Besides, many projects implementing own kinds of collections, >specific to their needs. That is exactly what you want to avoid. I've had to implement these collections too often. Stephan

March 13, 2010

Re: [Pharo-project] Collection

by Igor Stasenko

On 13 March 2010 12:56, Stephan Eggermont <stephan(a)stack.nl> wrote: > Igor wrote: >>Yes. Use right tool for to do job. >>An OrderedCollection can't satisfy every possible combination of >>tasks, which developer facing. > > So, these collections are currently missing. And as all current > code is bound to the current implementations, switching > implementation on size is the prefered approach. > If such kind of collections didn't existed over more than 30 years of smalltalk existance, what makes you think that there a big interest in having them today? Of course, they could occupy some niche, but i doubt that they will replace an existing classes in a day-to-day use. Besides, many projects implementing own kinds of collections, specific to their needs. > Stephan > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 13, 2010

Re: [Pharo-project] Collection

by Stephan Eggermont

Igor wrote: >Yes. Use right tool for to do job. >An OrderedCollection can't satisfy every possible combination of >tasks, which developer facing. So, these collections are currently missing. And as all current code is bound to the current implementations, switching implementation on size is the prefered approach. Stephan

March 13, 2010

Re: [Pharo-project] collections

by Igor Stasenko

On 13 March 2010 12:20, Stephan Eggermont <stephan(a)stack.nl> wrote: > Levente wrote: >>How bad do they perform? Do you have benchmarks? > With a > coll := OrderedCollection new. > 1 to: 10000000 do: [:i | coll add: i]. > > a profile of: > 1 to: 100 do: [:i | coll add: i beforeIndex: 10] > here takes 1438 ms. Moving memory gets to be slow. > All operations that start taking O(#elements) time are > no longer funny. > > The usual thing to do is to start using multiple blocks > of memory (like a BTree). Doubling size when growing > is also not an acceptable strategy when getting close to > total ram capacity. > Yes. Use right tool for to do job. An OrderedCollection can't satisfy every possible combination of tasks, which developer facing. >From this point, i barely see how we can achieve a substantial improvements in current implementation. And i think if we talk about collections, we should be focused more on a refactoring (use traits) for better library design, which will make implemetation more compact and cleaner. > Stephan > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 13, 2010