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

Re: [Pharo-dev] Searchbar in the browser

by StÃ©phane Ducasse

On Dec 10, 2013, at 9:22 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > 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. 10, 2013

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

by StÃ©phane Ducasse

Sven thanks a lot How can we resist to push this in Pharo 30 :) 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. 10, 2013

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

by StÃ©phane Ducasse

Is sven the one? You would look cool with keanu glasses :)

Dec. 10, 2013

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

by StÃ©phane Ducasse

> At the end, anyway, Steph and Marcus decide. No :) We decide. So YOUR point of views are important because we can be in a bad mood not smart enough or whatever :). Now at the end of this discussion I have the impression that having collect:as: and flatCollect:as: would be good and enough Notice that I'm dead (gave 3 hours lectures from 6 - 9h and before talk from 1h30 to 6 about Smalltalk and research with guys at Prague) Stef

Dec. 10, 2013

Re: [Pharo-dev] promoting latest vm as stable

by StÃ©phane Ducasse

This is REALLY IMPORTANT. Because people are still downloading Pharo2.0 with the old VM. I think that we should have a better way to handle that. Stef On Dec 10, 2013, at 1:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi guys, > > I would want to promote the latest vm as "stable". > Can you download and try it, in case something is not working fine? > > you can get it by: > > curl get.pharo.org/vmLatest > > or download at: > > mac: latest.zip > win: latest.zip > linux: latest.zip > > cheers, > Esteban > > > >

Dec. 10, 2013

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

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 > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 10, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Nicolas Cellier

The more you add, the more you'll have to remove 2013/12/10 Damien Cassou <damien.cassou(a)gmail.com> > > On Dec 5, 2013 10:50 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > > > > There are several different approaches in different places: > > > > - FileStream reads strings by default. #binary and #ascii switch between > formats. File streams use an internal buffer which is either a String > (default) or a ByteArray. Itâs even possible to switch between binary and > ascii midstream without losing information (if done right) because it only > affects the buffer. > > - ReadStream and WriteStream cannot change their format. Their behavior > is determined by the underlying collection. Forcing conversions (e.g. by > #asString) can lead to loss of information > > - RWBinaryOrTextStream (and other subclasses of ReadWriteStream) also > support the #binary #ascii method of switching format. Default is #ascii > > - SocketStream uses the same #binary / #ascii mechanism. Default is > #ascii > > - ZnLimitedReadStream uses the same #binary / #ascii mechanism. Default > is #binary (implicit); depends on the underlying stream > > > > I think the pattern to follow is clear: ReadStream and WriteStream > should allow switching format with #ascii and #binary, default should be > #ascii. However, I suspect thereâs a reason that these classes donât > support switching, namely that switching makes the implementation more > complicated and also slower because more checks need to be made. > > > > The easiest solution I see would be to implement something like this: > > > > ReadStream>>next > > ^ self isBinary > > ifTrue: [ self basicNext asCharacter ] > > ifFalse: [ self basicNext ] > > > > However, #next et al. are implemented in a plugin and the primitive > method looks like this: > > > > ReadStream>>next > > <primitive: 65> > > position >= readLimit > > ifTrue: [^nil] > > ifFalse: [^collection at: (position := position + 1)] > > > > This means the collection instance variable has to hold either a binary > or a string collection. > > > > Iâve found a solution which would work and Iâve whipped up a working way > (thereâs space for improvementâ¦): > > > > ReadStream>>binary > > collection isString ifFalse: [ ^ self ]. > > collection := (ByteArray new: collection size) copyReplaceFrom: 1 to: > collection size with: collection > > > > ReadStrem>>ascii > > collection isString ifTrue: [ ^ self ]. > > collection := (String new: collection size) copyReplaceFrom: 1 to: > collection size with: collection > > > > @Damien > > opposed to what I wrote earlier, #asString does *not* destroy > non-printable characters. Instead, every byte (from 0 to 255) is encoded as > a character and thus the string can be converted back to a ByteArray > *without* loss of information. Sorry about that. > > Thank you very much for your analysis. I'm a bit reluctant to change > ReadStream now, but I could be ok with enough unit tests. > Another potential solution: What about adding a #binaryReadStream method > to the memory file system as a workaround before the introduction of > xstreams ? > > > With this change in place the 12259 would become obsolete. > > > > Please let me know what you think. This is a pretty big change that > might have a lot of consequences in the image. > > > > Cheers, > > Max > > > > On 04.12.2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: > > > >> Let me see what I can come up with. > >> > >> > >> On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> > >>> Thanks Max for the report. Do you have an idea on how we could solve > the problem ? The previous behaviour was not acceptable either because the > streams that came out of a memory filesystem were the only ones with binary > content > >>> > >>> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > >>>> > >>>> Damien, Marcus > >>>> > >>>> this change breaks a lot of things in FileSystem-Git. I donât > disagree with the idea that reading characters should be default (one could > argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because > unprintable characters are discarded! So if my ByteArray is a NULL > terminated string, for instance, I can not check for the NULL termination > anymore. > >>>> > >>>> Cheers, > >>>> Max > >> > >> > > >

Dec. 10, 2013

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

Hi, I think to do package filter feature apparent by adding âinfo buttonâ. See the attached picture. When clicked on the info button, help dialog will appear. What do you think? Can someone give me ideas how to implement it? What classes I should be interested, etc. Thanks, Jura El 08-12-2013, a las 12:33, Alexandre Bergel <alexandre.bergel(a)me.com> escribiÃ³: > Hi All, > > You may have noticed that Nautilus now has a search bar next to the list of packages. I personally find this extremely useful. This is the work of Juraj and he is interested in hearing your feedback. > > The textfield accepts regular expression. It means that entering âRoassalâ will display all the packages having the word âRoassalâ in it (e.g., RoassalExtra, ConfigurationOfRoassal). If I enter â^Roassalâ, it displays all the packages that begin with âRoassalâ. (e.g., RoassalExtra). > > Any idea how to make this feature more apparent? Anything else you want to see with the searching in the browser? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

Dec. 10, 2013

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

El 09-12-2013, a las 7:25, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > On 09 Dec 2013, at 11:20, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> What I would like, is a setting to remove it. >> I usually do not use the packages list, >> and once you end up tabbing in the search field, >> you can not escape without your mouse, >> and this is really grinding my gears :s >> >> So if I could just disable it, I would appreciate it :) > > The tabbing should be fixed in addition. > Can I ask for a case, in order to understand? Thanks. Jura > Marcus

Dec. 10, 2013

Re: [Pharo-dev] Searchbar in the browser

by Juraj Kubelka

El 08-12-2013, a las 15:04, kilon alios <kilon.alios(a)gmail.com> escribiÃ³: > Emacs employs fuzzy completion. That means that you only have to type a partial match that exists in anywhere in the result or even fragments of a partial match making for very flexible search. For example if I look for "filesystem" and yet I type"systemfile" or "sysfile" or "file-syse" etc, the search will still able to locate the "filesystem" packages and all its classes. > Do you know where it is implemented? A filename and function name? Thanks, Jura > I used this completion both for code completion and file path completion , but I am pretty sure it works everywhere inside emacs. > > That also mean a unified search for everything, classes, methods etc . Without of course ruling out focused search of any kind , regex and existing ways to search in Pharo. > > But I want to say that I am very happy we have this functionality in pharo. Thank you. > > > On Sun, Dec 8, 2013 at 7:48 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Another pponit about the search > > it would be good to have the following behavior > I type TOOLS > > I see all the packages with TOOLS > > I select one > > then I removed TOOLS from the search bar > > -> the selected package stays selected > > Stef > >

Dec. 10, 2013