December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Voronoi diagram

by NISHIHARA Satoshi

Voronoi-2d-Diagram, you can install from Configuration browser of 2.0. ;-) 2013/12/8 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Check this out > > http://www.smalltalkhub.com/#!/~goonsh/Voronoi-2d-Diagram > http://www.squeaksource.com/VoronoiDiagram.html > > There is also an old package implementing Voronoi diagrams also, I can have > a look if you those are not enough for your needs. > Cheers > > HernÃ¡n > > El 07/12/2013 13:59, Natalia Tymchuk escribiÃ³: > >> Hello. >> I started implementing visualization of Voronoi diagrams and I need to >> do a lot of operations on the lines and polygons. I have some questions: >> Is it implemented somewhere? >> Did somebody do something with the Voronoi diagrams? >> >> Best regards, >> Natalia >> >> > > -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]

Dec. 10, 2013

[ANN] Neo-Caching

by Sven Van Caekenberghe

Hi, Caching is an important technique to trade time (speed of execution) for space (memory consumption) in computation. Used correctly, caching can significantly improve an applicationâs performance. Given the key/value nature of a cache, a Dictionary is often the first data structure used for implementing it. This is however not a good idea since a simple Dictionary is unbounded by definition and can/will lead to explosive cache growth. Quick and dirty hacks to turn a Dictionary into a least-recently-used (LRU) and/or time-to-live (TTL) based limited cache are often incorrect and inefficient. The LRUCache implementation currently in Pharo is too simple and not efficient, being O(n) on its main operation. Pharo deserves and needs a good LRU/TTL cache implementation that can/should be used uniformly in various places of the system and in code built on top of it. That is why I implemented a proposal. Neo-Caching is an implementation of both a good LRU cache as well as a TTL extension of it. The caches are easy to use, yet have a number of interesting features. The implementation is properly O(1) on its main operations and is 2 to 3 times faster than LRUCache. The package also contains a double linked list implementation. The code comes with a full set of unit tests. There are class and method comments and the code is easy to read. The code (which has no dependencies) can be found here http://mc.stfx.eu/Neo http://www.smalltalkhub.com/mc/SvenVanCaekenberghe/Neo/main There is only one package to load. The code has been written in Pharo 3.0 but it should run on older versions as well. Code Letâs create a 16K ordered collection of keys that have some repetitions in them with a reasonable distribution: data := Array streamContents: [ :out | 1 to: 4096 do: [ :each | each primeFactorsOn: out. out nextPut: each ] ]. data := data collect: [ :each | each asWords ]. By using #asWords the keys have better hash properties. Now, we put all this in a cache: cache := NeoLRUCache new. cache maximumWeight: 512. cache factory: [ :key | key ]. data do: [ :each | cache at: each ]. cache. ==> a NeoLRUCache(#512 512/512 [ 1 ] [ :key | key ] 72%) We had a 72% hit ratio, which is good. The cache is of course full, 512/512 with 512 entries (not necessarily the same thing, see further). We can now benchmark this: [ data do: [ :each | cache at: each ] ] bench. ==> '35.8 per second.â And compare it to LRUCache: cache := LRUCache size: 512 factory: [ :key | key ]. [ data do: [ :each | cache at: each ] ] bench. ==> '12.6 per second.â Features Instead of just counting the number of entries, which is the default behaviour, the concept of weight is used to determine when a cache is full. For each cached value, a block or selector is used to compute its weight. When adding a new entry causes the weight to exceed a maximum, eviction of the least recently used item(s) takes place, until the weight is again below the maximum. cache computeWeight: #sizeInMemory; maximumWeight: 16*1024. Will keep the cache below 16Kb in real memory usage. This can be very useful when caching various sized images or MC packages, for example. By default, no concurrent access protection takes place, but optionally a semaphore for mutual exclusion can be used. This slows down access. cache useSemaphore. NeoTTLCache extends NeoLRUCache by maintaining a timestamp for each cached value. Upon cache hit, there is a check to see if this timestamp is not older than the allowed time to live. If so, the value is stale and will be recomputed. (cache := NeoTTLCache new) timeToLive: 10 minutes; factory: [ :key | ZnEasy get: key ]; maximumWeight: 32*1024; computeWeight: #contentLength. cache at: âhttp://zn.stfx.eu/zn/numbers.txt'. ==> a ZnResponse(200 OK text/plain;charset=utf-8 71B) cache ==> a NeoTTLCache(#1 71/32768 #contentLength [ :key | ZnEasy get: key ] 0% 0:00:10:00) Would be a simple HTTP cache, keeping resolved URLs in memory for 10 minutes maximum before refreshing them. It uses #contentLength on ZnResponse to compute the weight. You can see from the print string that there is now 1 entry, while the weight is 17 bytes out of 32768. These are the main points, please have a look at the code. Feedback is welcome. Regards, Sven

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Roberto Minelli

On Dec 10, 2013, at 4:19 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Do I really need to respond to this? No. > Well you're lucky, my child not yet awoke: Is this a threat? :lol: > 1) size is often implemented O(1) above is O(n) > 2) typing size is very short compared to open code you provided > 3) size has many senders which makes it worth > 4) size is part of ANSI > Which of these points apply to (someCollection collectAsSet: #asUppercase) vs (someCollection collect: #asUppercase as: Set). Anyway, this is an endless discussion. You have your point. I have mine. I have my own #collectAsSet: and I am fine with that and I will never use #collect:as: > But you could find better example of some more questionable methods in Squeak/Pharo. > > 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > So if "self do: [:each | tally := tally + 1]" computes the size of a collection, why do we need the #size selector? > > On Dec 10, 2013, at 3:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > So if collect:as: does the job why the hell add yet another selector? > > >

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Nicolas Cellier

Do I really need to respond to this? Well you're lucky, my child not yet awoke: 1) size is often implemented O(1) above is O(n) 2) typing size is very short compared to open code you provided 3) size has many senders which makes it worth 4) size is part of ANSI Which of these points apply to (someCollection collectAsSet: #asUppercase) vs (someCollection collect: #asUppercase as: Set). But you could find better example of some more questionable methods in Squeak/Pharo. 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > So if "self do: [:each | tally := tally + 1]" computes the size of a > collection, why do we need the #size selector? > > On Dec 10, 2013, at 3:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > So if collect:as: does the job why the hell add yet another selector? > > >

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Roberto Minelli

So if "self do: [:each | tally := tally + 1]" computes the size of a collection, why do we need the #size selector? On Dec 10, 2013, at 3:08 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > So if collect:as: does the job why the hell add yet another selector?

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Igor Stasenko

On 10 December 2013 14:47, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > A fact is that there are way too many methods in (Sequenceable)Collection > already, with duplicated implementations/features. > So if collect:as: does the job why the hell add yet another selector? > > +1 > > 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > >> IMHO having two common usages of #flatCollect:as: and #collect:as: is >> good. Then, do whatever you want. In my image I have #collectAsSet:. >> >> On Dec 10, 2013, at 2:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> > IMO, if there is an error, then is the presence of #flatCollectAsSet:, >> not the absence of the other(s). >> > >> > Esteban >> > >> > >> > On Tue, Dec 10, 2013 at 2:38 PM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > And then rejectAsSet: selectAsHeap: etc... >> > A big -1 >> > >> > >> > 2013/12/10 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> > >> > On 10 Dec 2013, at 14:26, Roberto Minelli <roberto.minelli(a)usi.ch> >> wrote: >> > >> > > No. Since #flatCollectAsSet: is in the image, #collectAsSet: should >> be in the image as well. >> > > >> > > And then, since we want clean code #collectAsSet: is cleaner than >> #collect:as:. >> > >> > Yes, but this also means that you need to implement: >> > >> > collectAsArray: >> > collectAsOrderedCollection: >> > collectAsBag: >> > â¦ >> > >> > :) >> > >> > > >> > > On Dec 10, 2013, at 2:23 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > > >> > >> I don't think it has to be in the image, >> > >> >> > >> After all, you can just replace your calls for #collect:as: >> > >> >> > >> Esteban >> > >> >> > >> >> > >> >> > >> >> > >> On Tue, Dec 10, 2013 at 2:21 PM, Roberto Minelli < >> roberto.minelli(a)usi.ch> wrote: >> > >> Hi, >> > >> >> > >> In Pharo 3 you guys integrated Doruâs CollectionsExtension package, >> which is great. >> > >> >> > >> You forgot, however, to integrate the utility method #collectAsSet: >> I was using in several places in my code. >> > >> >> > >> It should be simply >> > >> ^ self collect: aBlock as: Set >> > >> >> > >> Could someone please put this in the standard image please? Thanks. >> > >> >> > >> Cheers, >> > >> R >> > >> >> > > >> > > >> > >> > >> > >> > >> >> >> > -- Best regards, Igor Stasenko.

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Nicolas Cellier

A fact is that there are way too many methods in (Sequenceable)Collection already, with duplicated implementations/features. So if collect:as: does the job why the hell add yet another selector? 2013/12/10 Roberto Minelli <roberto.minelli(a)usi.ch> > IMHO having two common usages of #flatCollect:as: and #collect:as: is > good. Then, do whatever you want. In my image I have #collectAsSet:. > > On Dec 10, 2013, at 2:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > IMO, if there is an error, then is the presence of #flatCollectAsSet:, > not the absence of the other(s). > > > > Esteban > > > > > > On Tue, Dec 10, 2013 at 2:38 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > And then rejectAsSet: selectAsHeap: etc... > > A big -1 > > > > > > 2013/12/10 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > > > > On 10 Dec 2013, at 14:26, Roberto Minelli <roberto.minelli(a)usi.ch> > wrote: > > > > > No. Since #flatCollectAsSet: is in the image, #collectAsSet: should be > in the image as well. > > > > > > And then, since we want clean code #collectAsSet: is cleaner than > #collect:as:. > > > > Yes, but this also means that you need to implement: > > > > collectAsArray: > > collectAsOrderedCollection: > > collectAsBag: > > â¦ > > > > :) > > > > > > > > On Dec 10, 2013, at 2:23 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > > >> I don't think it has to be in the image, > > >> > > >> After all, you can just replace your calls for #collect:as: > > >> > > >> Esteban > > >> > > >> > > >> > > >> > > >> On Tue, Dec 10, 2013 at 2:21 PM, Roberto Minelli < > roberto.minelli(a)usi.ch> wrote: > > >> Hi, > > >> > > >> In Pharo 3 you guys integrated Doruâs CollectionsExtension package, > which is great. > > >> > > >> You forgot, however, to integrate the utility method #collectAsSet: I > was using in several places in my code. > > >> > > >> It should be simply > > >> ^ self collect: aBlock as: Set > > >> > > >> Could someone please put this in the standard image please? Thanks. > > >> > > >> Cheers, > > >> R > > >> > > > > > > > > > > > > > > > > >

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Roberto Minelli

IMHO having two common usages of #flatCollect:as: and #collect:as: is good. Then, do whatever you want. In my image I have #collectAsSet:. On Dec 10, 2013, at 2:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > IMO, if there is an error, then is the presence of #flatCollectAsSet:, not the absence of the other(s). > > Esteban > > > On Tue, Dec 10, 2013 at 2:38 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > And then rejectAsSet: selectAsHeap: etc... > A big -1 > > > 2013/12/10 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > > On 10 Dec 2013, at 14:26, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > > No. Since #flatCollectAsSet: is in the image, #collectAsSet: should be in the image as well. > > > > And then, since we want clean code #collectAsSet: is cleaner than #collect:as:. > > Yes, but this also means that you need to implement: > > collectAsArray: > collectAsOrderedCollection: > collectAsBag: > â¦ > > :) > > > > > On Dec 10, 2013, at 2:23 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> I don't think it has to be in the image, > >> > >> After all, you can just replace your calls for #collect:as: > >> > >> Esteban > >> > >> > >> > >> > >> On Tue, Dec 10, 2013 at 2:21 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > >> Hi, > >> > >> In Pharo 3 you guys integrated Doruâs CollectionsExtension package, which is great. > >> > >> You forgot, however, to integrate the utility method #collectAsSet: I was using in several places in my code. > >> > >> It should be simply > >> ^ self collect: aBlock as: Set > >> > >> Could someone please put this in the standard image please? Thanks. > >> > >> Cheers, > >> R > >> > > > > > > > >

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Yuriy Tymchuk

I think that collectAsSet: is used a lot because we convert collection and remove duplicates. So it wonât be the same with select: . But I prefer to use #removeDuplicates, because this explicitly says: I want to remove duplicates, and not use a side effects of Set. Anyway have a nice day guys, we are building an amazing system. Cheers! Uko On 10 Dec 2013, at 14:38, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > And then rejectAsSet: selectAsHeap: etc... > A big -1 > > > 2013/12/10 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > > On 10 Dec 2013, at 14:26, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > > No. Since #flatCollectAsSet: is in the image, #collectAsSet: should be in the image as well. > > > > And then, since we want clean code #collectAsSet: is cleaner than #collect:as:. > > Yes, but this also means that you need to implement: > > collectAsArray: > collectAsOrderedCollection: > collectAsBag: > â¦ > > :) > > > > > On Dec 10, 2013, at 2:23 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> I don't think it has to be in the image, > >> > >> After all, you can just replace your calls for #collect:as: > >> > >> Esteban > >> > >> > >> > >> > >> On Tue, Dec 10, 2013 at 2:21 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > >> Hi, > >> > >> In Pharo 3 you guys integrated Doruâs CollectionsExtension package, which is great. > >> > >> You forgot, however, to integrate the utility method #collectAsSet: I was using in several places in my code. > >> > >> It should be simply > >> ^ self collect: aBlock as: Set > >> > >> Could someone please put this in the standard image please? Thanks. > >> > >> Cheers, > >> R > >> > > > > > > >

Dec. 10, 2013

Re: [Pharo-dev] Missing collectAsSet: in Pharo 3.0

by Esteban Lorenzano

IMO, if there is an error, then is the presence of #flatCollectAsSet:, not the absence of the other(s). Esteban On Tue, Dec 10, 2013 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > And then rejectAsSet: selectAsHeap: etc... > A big -1 > > > 2013/12/10 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > >> >> On 10 Dec 2013, at 14:26, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: >> >> > No. Since #flatCollectAsSet: is in the image, #collectAsSet: should be >> in the image as well. >> > >> > And then, since we want clean code #collectAsSet: is cleaner than >> #collect:as:. >> >> Yes, but this also means that you need to implement: >> >> collectAsArray: >> collectAsOrderedCollection: >> collectAsBag: >> â¦ >> >> :) >> >> > >> > On Dec 10, 2013, at 2:23 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > >> >> I don't think it has to be in the image, >> >> >> >> After all, you can just replace your calls for #collect:as: >> >> >> >> Esteban >> >> >> >> >> >> >> >> >> >> On Tue, Dec 10, 2013 at 2:21 PM, Roberto Minelli < >> roberto.minelli(a)usi.ch> wrote: >> >> Hi, >> >> >> >> In Pharo 3 you guys integrated Doruâs CollectionsExtension package, >> which is great. >> >> >> >> You forgot, however, to integrate the utility method #collectAsSet: I >> was using in several places in my code. >> >> >> >> It should be simply >> >> ^ self collect: aBlock as: Set >> >> >> >> Could someone please put this in the standard image please? Thanks. >> >> >> >> Cheers, >> >> R >> >> >> > >> > >> >> >> >

Dec. 10, 2013