- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PluggableSet and KeyedSet serve the same purpose

by Marcus Denker

On Mar 13, 2010, at 3:03 PM, Niko Schwarz wrote: > Hi list, > > the purpose of PluggableSet and KeyedSet is the same: they're both > sets where the equivalence relation is overwritten by a block. > > One of the two should be removed. What do you think? Keyedset can be removed. (not used) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 13, 2010

[Pharo-project] PluggableSet and KeyedSet serve the same purpose

by Niko Schwarz

Hi list, the purpose of PluggableSet and KeyedSet is the same: they're both sets where the equivalence relation is overwritten by a block. One of the two should be removed. What do you think? Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

March 13, 2010

[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