- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Tell me about your workflow

by Goubier Thierry

Le 11/12/2013 15:18, Sebastian Sastre a Ã©crit : > Are you using git with your Pharo based software? Yes > If you do, are you using filetree? gitfiletree (it uses the filetree code path for writing, and a git archive path for reading) > I ask because I'm worried about scale. > > I have packages (in the order of hundreds of classes) and save delays > and package click delays are starting to demand patience in a way that > doesn't feel like the right path Which operations ? I didn't remember noticing much with 179 classes on a laptop without a SSD. > All that is with a SSD disk, otherwise save delays would be /way/ beyond > unacceptable I'd like to know more, and understand the reason, for sure. As far as I know, filetree will rewrite the whole package to disk everytime... and maybe optimising that could be the solution. Thierry > sebastian <https://about.me/sebastianconcept> > > o/ > > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 11, 2013

Tell me about your workflow

by Sebastian Sastre

Are you using git with your Pharo based software? If you do, are you using filetree? I ask because I'm worried about scale. I have packages (in the order of hundreds of classes) and save delays and package click delays are starting to demand patience in a way that doesn't feel like the right path All that is with a SSD disk, otherwise save delays would be way beyond unacceptable sebastian o/

Dec. 11, 2013

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

Does it means, when I start to type â-Pâ it will display all the packages which contain class with character âpâ or âPâ? In order to be consists we should use the same regular expressions as for packages. So, If I want all packages which contain class beginning with âpâ, it should be â-^pâ. Regular expressions are case insensitive. Thanks, Jura El 11-12-2013, a las 4:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > No in fact this is about filtering classes directly without opening the finder > >>> Hi Stef, >>> >>> I am thinking about the -Point suggestion. Why this? Why not to use Cmd+f,cmd+c (find class), or shift+enter (spotlight)? >> >> Indeed we do not need it :) >> >> > >

Dec. 11, 2013

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

El 11-12-2013, a las 4:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > > On Dec 10, 2013, at 11:42 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > >> We can use any regular expression. For that reason I am thinking how to do the filter feature more apparent. Maybe a ghost text is enough. I will play with it. > > ghosttext is simple and working. OK, I did it this way and we will see :-) https://pharo.fogbugz.com/f/cases/12384/Package-filter-dialog-Make-the-feat… Thanks, Jura >> >> Jura >> >> El 10-12-2013, a las 19:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: >> >>> I like it! >>> use it all the time. I was not aware that we could use | >>> >>> >>>> >>>> El 10-12-2013, a las 9:12, Alexandre Bergel <alexandre.bergel(a)me.com> escribiÃ³: >>>> >>>>>> If I search for something, I always Shift-Enter and that works super. For the rest, there are menus and keyboard shortcuts. >>>>> >>>>> Actually, this is quite different. Shift-Enter this is for searching. The textfield in Nautilus is for filtering packages >>>>> >>>> >>>> Yes, the package filter allows to see only packages you are interested. See the attachment. >>>> Cheers, >>>> Jura >>>> >>>> <Captura de pantalla 2013-12-10 a la(s) 18.24.33.png> >>>> >>>> >>>>> Alexandre >>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >

Dec. 11, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30636 Home: https://github.com/pharo-project/pharo-core

Dec. 11, 2013

[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