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

[pharo-project/pharo-core] d296eb: 30636

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: d296eb7bef29cc140bfcb99f7bd1af703295e70b https://github.com/pharo-project/pharo-core/commit/d296eb7bef29cc140bfcb99f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-11 (Wed, 11 Dec 2013) Changed paths: A MenuRegistration.package/MenuRegistration.class/instance/printing/printOn_.st A MenuRegistration.package/MenuRegistration.class/instance/spec accessing/enabledBlock.st A MenuRegistration.package/MenuRegistration.class/instance/spec accessing/enabledBlock_.st A MenuRegistration.package/MenuRegistration.class/instance/spec accessing/enabled_.st M Nautilus.package/Nautilus.class/class/browser compatibility/fullOnClass_selector_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/updatePackages.st R NautilusCommon.package/extension/MenuRegistration/instance/enabledBlock_.st R NautilusCommon.package/extension/MenuRegistration/instance/enabled_.st R NautilusCommon.package/extension/MenuRegistration/instance/printOn_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script291.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30636.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/Finder.class/instance/private-example/computeWithMethodFinder_.st M Tools.package/FinderUI.class/instance/buttons behavior/environmentButtonLabel.st Log Message: ----------- 30636 - Issue 12390 MenuRegistation is bogus https://pharo.fogbugz.com/f/cases/12390/MenuRegistation-is-bogus - Issue 12387 Finder displays too many strings around arguments https://pharo.fogbugz.com/f/cases/12387/Finder-displays-too-many-strings-ar… - Issue 12393 MessageNotUnderstood: receiver of "ui" is nil https://pharo.fogbugz.com/f/cases/12393/MessageNotUnderstood-receiver-of-ui… - Issue 12383 Loose package selection on using package filter https://pharo.fogbugz.com/f/cases/12383/Loose-package-selection-on-using-pa… http://files.pharo.org/image/30/30636.zip

Dec. 11, 2013

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

by Sven Van Caekenberghe

On 11 Dec 2013, at 13:42, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 11/12/13 12:20, Sven Van Caekenberghe wrote: >> 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, > > That's exactly the difference, subtle but important :-) > > but I doubt this is necessary here. > > Imagine you need Fibonacci number and want to cache them for speed. > How would one do that? Obvious solution would be: > > fibCache := NeoCache ... > fibCache factory: [:key | (fibCache at: key - 1) + (fibCache at: key - 1) ]. > > If I understood the code correctly `fibCache at: 10` would hang, right? OK, you convinced me ! Thanks for the explanation. I will even make the fib example part of the unit tests. But I will probably change it to [ :key | key < 2 ifTrue: [ key ] ifFalse: [ (fibCache at: key - 1) + (fibCache at: key - 1) ] ] ;-) >> >> Any other reasons to choose one over the other ? Speed ? > > Speed-wise, it depends on implementation. The cost of recursion > lock could be reduced to couple machine instructions in case > there's no contention (which is usually the case). Iâll measure it. > Actually, this would make an interesting use-case for NB... > >> >> Sven >> >>> Best, Jan

Dec. 11, 2013

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

by Jan Vrany

On 11/12/13 12:20, Sven Van Caekenberghe wrote: > 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, That's exactly the difference, subtle but important :-) but I doubt this is necessary here. Imagine you need Fibonacci number and want to cache them for speed. How would one do that? Obvious solution would be: fibCache := NeoCache ... fibCache factory: [:key | (fibCache at: key - 1) + (fibCache at: key - 1) ]. If I understood the code correctly `fibCache at: 10` would hang, right? > > Any other reasons to choose one over the other ? Speed ? Speed-wise, it depends on implementation. The cost of recursion lock could be reduced to couple machine instructions in case there's no contention (which is usually the case). Actually, this would make an interesting use-case for NB... > > Sven > >> Best, Jan >> > > >

Dec. 11, 2013

Fwd: Categories, packages, and tags [cont'd]

by Roberto Minelli

Hi guys, I have a question about the new âPackageTreeModelââ¦ In a previous discussion (https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg09271.html) we discussed about the new package model. Now I understood it but I am wondering one thing. Since Stef said that categories will be removed, i.e., the ByteSymbol representation of what I used to call packages, I am wondering how one could ask the system which are the installed packages, tags, etc. In short I want to know which is the best method to ask what used to be âSystemOrganization categoriesâ. Thanks in advance, R

Dec. 11, 2013

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

by Sven Van Caekenberghe

On 11 Dec 2013, at 12:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 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 :). In any case: https://pharo.fogbugz.com/f/cases/12398/Update-LRUCache-Implementation There are currently only 3 LRUCache users, the risk is minimal, I think. BTW, the reason I started this is because I want better caching for Monticello stuff. You know, the multiple MBâs being used/waisted when you work for a couple of days in the same image, the result of boundless caching using stupid dictionaries. But I am waiting for this reckless young Swiss guy coming back after his thesis is written ;-) > 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] 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