- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] could we stop to create spaghetti code?

by Tudor Girba

And if we are at it, the SpecDebugger still requires the EyeInspector to be the default inspector: https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-requir… Cheers, Doru On Wed, Dec 11, 2013 at 1:15 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 11 Dec 2013, at 11:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > EyeInspector should not depend on Nautilus. > > > > icon > > ^ (self value iconOrThumbnailOfSize: 16) > > ifNil: [ self value class nautilusIcon ] > > > > ^^^^^^^^^^^^^^^^^^^^^^ > > > > > https://pharo.fogbugz.com/f/cases/12392/EyeInspector-should-not-depend-on-N… > > > > Now we are trying to fix it. The question is how to dispatch. > > May be we should extract from Nautilus the nautilusIcon if the > eyeInspector use it. > > > > I think the idea here is that maybe a class should have an icon. > Independend of Nautilus.\ > (either just icon or toolIcon). > > Marcus > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 11, 2013

Re: [Pharo-dev] [ANN] Neo-Caching

by Sven Van Caekenberghe

Hi Jan, On 11 Dec 2013, at 12:49, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi, > >> By default, no concurrent access protection takes place, but optionally a semaphore for mutual exclusion can be used. This slows down access. >> >> cache useSemaphore. >> > > There was enough "awesomes" already :-) so now some critics :-) I like constructive feedback ! > Wouldn't it be better to rename #useSemaphore to #beThreadSafe > or #beSynchronized. Yes, specifying the goal/result is better than specifying the means. I think I will go for #beThreadSafe (although threads in Pharo are called Processes ;-). The last one reminds me of Java and we donât have a âsynchronisedâ concept in Pharo AFAIK. > Also I would use recursion lock (monitor, if you like) rather than plain mutex. Iâve used both, they both work. But I must admit that in my mind the difference is not very clear. A monitor can be re-entered while a semaphore cannot, but I doubt this is necessary here. Any other reasons to choose one over the other ? Speed ? Sven > Best, Jan >

Dec. 11, 2013

Re: [Pharo-dev] could we stop to create spaghetti code?

by Marcus Denker

On 11 Dec 2013, at 11:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > EyeInspector should not depend on Nautilus. > > icon > ^ (self value iconOrThumbnailOfSize: 16) > ifNil: [ self value class nautilusIcon ] > > ^^^^^^^^^^^^^^^^^^^^^^ > > https://pharo.fogbugz.com/f/cases/12392/EyeInspector-should-not-depend-on-N… > > Now we are trying to fix it. The question is how to dispatch. > May be we should extract from Nautilus the nautilusIcon if the eyeInspector use it. > I think the idea here is that maybe a class should have an icon. Independend of Nautilus.\ (either just icon or toolIcon). Marcus

Dec. 11, 2013

Re: [Pharo-dev] Package unloading and extensions

by StÃ©phane Ducasse

> We did another experience: > we moved all the methods in *Nautilus extension and unloaded it but it failed. > The methods were not unloaded. In fact this is worse: - we create a new package extensions - did RPackageOrganizer initializeDefaultFromMC. - move all the method to *Nautilus - then we unload them but and we get the methods iconNamed: smallSizeNamed iconNamed:ifNone: and normalSizeNamed (which are normally in accessing when you open the browse, but in polymorph-widgets when displayed using the messageBrowser-implementor) in the *Nautilus extensions. So there is a real bug in there. Stef > > On Dec 11, 2013, at 11:45 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> This is strange so I report it. >> When we unload Nautilus package we still get the methods in ThemeIcons with category >> *Nautilus-contents and antoher one *Nautilus-icons >> >> so we thought that unload does not unload extensions whose name is composed (*Nautilus vs. *Nautilus-icons) >> so we built a case with a package and extensions (on instance and class side of different classes). >> But unload was unloading them perfectly: *Box, *Box-green, *Box-foo >> >> the only difference is that the second experience we did we used the UI MC browser while else we used >> some script ie >> >> (MCWorkingCopy forPackage: (MCPackage named: 'Nautilus')) unload. >> >> So we are puzzled. >> >> Stef and Pavel > >

Dec. 11, 2013

Re: [Pharo-dev] Package unloading and extensions

by StÃ©phane Ducasse

We did another experience: we moved all the methods in *Nautilus extension and unloaded it but it failed. The methods were not unloaded. On Dec 11, 2013, at 11:45 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > This is strange so I report it. > When we unload Nautilus package we still get the methods in ThemeIcons with category > *Nautilus-contents and antoher one *Nautilus-icons > > so we thought that unload does not unload extensions whose name is composed (*Nautilus vs. *Nautilus-icons) > so we built a case with a package and extensions (on instance and class side of different classes). > But unload was unloading them perfectly: *Box, *Box-green, *Box-foo > > the only difference is that the second experience we did we used the UI MC browser while else we used > some script ie > > (MCWorkingCopy forPackage: (MCPackage named: 'Nautilus')) unload. > > So we are puzzled. > > Stef and Pavel

Dec. 11, 2013

Re: [Pharo-dev] [ANN] Neo-Caching

by Jan Vrany

Hi, > By default, no concurrent access protection takes place, but optionally a semaphore for mutual exclusion can be used. This slows down access. > > cache useSemaphore. > There was enough "awesomes" already :-) so now some critics :-) Wouldn't it be better to rename #useSemaphore to #beThreadSafe or #beSynchronized. Also I would use recursion lock (monitor, if you like) rather than plain mutex. Best, Jan

Dec. 11, 2013

Re: [Pharo-dev] [ANN] Neo-Caching

by StÃ©phane Ducasse

On Dec 11, 2013, at 12:29 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On Tue, Dec 10, 2013 at 11:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Sven thanks a lot > > yes! really cool! > > How can we resist to push this in Pharo 30 :) > > over my dead body :) > but in Pharo 4â¦ you are saying that you will let squeak be in advance compared to Pharo :) I cannot believe that :). Stef > > > Stef > > On Dec 10, 2013, at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > 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. 11, 2013

Re: [Pharo-dev] self item returns a string

by StÃ©phane Ducasse

Thanks a lot. I will check and resolve the bug. I wanted to continue working on unloading code so this is why we time bombed our investigation. Stef > > printing strings with quotes and doubling this quotes is done in > Finder>>computeWithMethodFinder: > > node formattedCode printOn: strm. > > replace it with > strm << node formattedCode. > > An awful big method btw. > > > nicolai >

Dec. 11, 2013

Re: [Pharo-dev] self item returns a string

by Nicolai Hess

2013/12/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Dec 11, 2013, at 10:31 AM, Benjamin < > Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > > Sorry but I wrote part of this code 3 years ago, so I really do not > remember :( > > > No problem. > We tried during 30 min with pavel but failed. We should have a look again. > > Stef > > > Ben > > On 11 Dec 2013, at 09:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Hi ben > > Im trying to fix the problem of the finder putting too many string around > the arguments. > if you type 'a' . 'b' . 'ab' and example > you will get '''a''' . '''b''' > > so I found that > > displayString > > self halt. > ^ self item asString > > self item returns a byteString and item is not redefined in FinderNode > > I tried to change it to > > displayString > > > ^ self item > > but self item is already '''a '''' > > the item on the node is already a '''a''''â¦. > > So I tried to check how the node were populated but I could not get > childrenItems to work. > > > > > printing strings with quotes and doubling this quotes is done in Finder>>computeWithMethodFinder: node formattedCode printOn: strm. replace it with strm << node formattedCode. An awful big method btw. nicolai

Dec. 11, 2013

Re: [Pharo-dev] [ANN] Neo-Caching

by Esteban Lorenzano

On Tue, Dec 10, 2013 at 11:09 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Sven thanks a lot > yes! really cool! > How can we resist to push this in Pharo 30 :) > over my dead body :) but in Pharo 4... > > Stef > > On Dec 10, 2013, at 4:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > 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. 11, 2013