October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] HashTable vs Dictionary

by StÃ©phane Ducasse

Yes I know Now in pharo if I do not change the hash of my objects and I get a lot of them in a dictionary I do get bad hash: at least this is what I understood from the limited number of hash bits. So this means that by default we have bad performance. no? Stef >> yyyyyyyyeeeeeeeeeeesssssssssssssssssssssssss >> and get linearrrrrrrrrrrrrrrrrrrrrly boring and slow. > > Yes, but only if your objects don't implement #hash properly. HashMap > trades space and time to get O(1) behavior IF you have lots of > elements with bad hash values. If the hash values are good (which is > the case most of the time) or if you have not that many elements > (which is the case most of the time), it is a waste of time and space > though. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

[Pharo-project] found a mac magsafe power adapter

by StÃ©phane Ducasse

one of the pharo sprinter forgot his adaptor :) let me know that we ship it by post Stef

Oct. 22, 2009

[Pharo-project] the we site does not point to the rc1 image/

by StÃ©phane Ducasse

can somebody fix it? Stef

Oct. 22, 2009

Re: [Pharo-project] feedback about the "new inspector"

by George Herolyants

2009/10/22 Johan Brichau <johan.brichau(a)uclouvain.be>: > My comment relates to having the 'Class' link in the tree. I have > never wanted to inspect the class of an object at that level when > inspecting 'regular objects'. Instead, I want to know the Object's > class and use the convenient class browsers to find which methods the > object understands. Oh, sorry for misunderstanding :) Of course I'm fully agreed with you.

Oct. 22, 2009

Re: [Pharo-project] feedback about the "new inspector"

by Johan Brichau

On 22 Oct 2009, at 11:03, George Herolyants wrote: > 2009/10/21 Johan Brichau <johan.brichau(a)uclouvain.be>: >> - Do not 'inspect/explore' the class as a normal object but make it >> jump to a browser instead > > I don't agree with it. Class is a normal object and must be inspected > as all other objects, I think. But, it would be great to have menu > item or shortcut to open the class being inspected in a browser. Of course, inspecting classes as normal objects should still be possible using the inspector. In essence, 'Object inspect' should still open the normal inspector. My comment relates to having the 'Class' link in the tree. I have never wanted to inspect the class of an object at that level when inspecting 'regular objects'. Instead, I want to know the Object's class and use the convenient class browsers to find which methods the object understands. cheers ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Oct. 22, 2009

Re: [Pharo-project] feedback about the "new inspector"

by George Herolyants

2009/10/21 Johan Brichau <johan.brichau(a)uclouvain.be>: > - Do not 'inspect/explore' the class as a normal object but make it > jump to a browser instead I don't agree with it. Class is a normal object and must be inspected as all other objects, I think. But, it would be great to have menu item or shortcut to open the class being inspected in a browser. I'm not very experienced squeak/pharo user but as for me, I've used the object explorer most of the time instead of inspector. So I like the new inspector.

Oct. 22, 2009

Re: [Pharo-project] feedback about the "new inspector"

by StÃ©phane Ducasse

I think that frederick is on the list. Fred? On Oct 21, 2009, at 6:39 PM, Johan Brichau wrote: > I agree that we need to refine the ideas in the inspector. Is Frederic > on this list? > > I also understood from Niko on monday that he is working on an > alternative inspector that very much ressembles the one from > Visualworks (which I very much like). > > The expandable tree 'infinite inspector' is a good idea for exploring > an object's state but it should probably not be applied to everything > that one can navigate to from within the object (i.e. not for > methods). Getting to the methods from within the inspector is cool but > if they expand in the same tree as the state, you quickly end up with > a tree that does not show you anything anymore. After a couple of > expansions, I often get a tree mixing state and behavior on different > levels, with long method lists that require me to scroll through the > tree and close levels again to see what I want. In the end, I have no > easy way of navigating the object structure anymore because opening/ > closing the tree levels to see what I want in a single window becomes > not manageable. > > Here is what I would like to see happening (and I'm willing to help to > get there too!): > > - Double clicking on an item in the tree on the left should open a new > inspector window on that item (I really do not like adding it as a > root in the same window: I find it confusing having two roots). This > will already allow me to open up another view on the same structure or > keep a window open on certain structure so I can return to it > afterwards. > > - Do not make the methods expandable in the tree but rather open a > list of methods in the right-hand pane that can be selected (and > 'send' to the object if it's a unary message). Right now, selecting > methods will give the list of selectors, which is not so useful. > > - Use visual icons instead of 'Class' and 'Methods' (duno if this is > possible in the treemorph?) > > - Do not 'inspect/explore' the class as a normal object but make it > jump to a browser instead > > > > On 21 Oct 2009, at 15:54, StÃ©phane Ducasse wrote: > >> Hi guys >> >> we tried to use and force you to use the new inspector and it does >> not >> fly that well. >> I'm sure that frederick is open to suggestion so please send your >> remarks. Here were mine :) >> >> Stef >> >> >> Hello Stef, >> >> >> >> here what is really strange and annoying is that we cannot see the >> collection elements in the right pane >> >> Now it is fixed. >> >> on the left Elements is confusing. because this is not clear the >> relationship with array, firstInd.... >> It shows only elements of any kind of collection (it is simply a >> collect: [:o | o] on the collection). >> >> on the right this is also frustrating that we cannot modify, touch >> the >> elements. >> >> Ok... but you can expand the Elements, select the element you want to >> change, put the new value in the description pane and accept it. >> >> I'm not sure that we want to see the class (in an expandable manner). >> For the methods may be you want to stop and show the methods but >> expandabel >> may be by defualt you should not show the class and methods as >> expandable and have a menu entry doing that (expand) >> >> I'm not sure to understand what you want. For me the NewInspector it >> is a like an infinite inspector: if you want to go into an object, >> you >> can. So if you want to inspect a class or the methods, you should >> have >> the possibility to do it. >> >> FrÃ©d >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] making #classVarNames answer a sorted Array

by StÃ©phane Ducasse

so that we can discuss in the list > This is related to http://code.google.com/p/pharo/issues/detail? > id=1353 > > > According to usage of classVarNames, a sorted Array would behave > better > > - same class as instVarNames (I remember such discussion in Pharo) > - optimized without extra code cost (especially if keys are also an > Array) > - sorted Array do compare fast with = (better than Sets) > - no need to sort a sorted Array, so half senders will be simplified > > Delete commentComment 1 by bschwab(a)anest.ufl.edu, Today (11 hours ago) > This gives me Dolphin flashbacks to a change (IIRC in the RB) that > had to be > regressed because it broke the serializer. I am only now getting > close to using SIXX > (the presumptive successor to Dolphin's STB for me), so I do not > know whether the > analogy will hold. However, it seems to me that knowing the order > in which things > were defined is important. If a sender wants them sorted, a single > #asSortedCollection should "sort" the problem, but there is no way > to undo it if the > result is sorted before one sees it. Another option would be to add > #basicXYZ to > return the unsorted version of the collection and then do as you > propose; either way, > I think the unsorted order should be preserved for the sake of > serializers and > similar systems. > > Delete commentComment 2 by nicolas.cellier.aka.nice, Today (2 hours > ago) > The problem of current definition of classVarNames is precisly that > they are unordered. > The order is not defined by user, it just depend on the hash codes > of classVarNames > modulo the size of classPool, unless we sort them. > Please look at usage. > > On Oct 21, 2009, at 11:23 PM, Nicolas Cellier wrote: > Proposal is logged at http://code.google.com/p/pharo/issues/detail?id=1354 > Recently in trunk > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] make #keys answer an Array rather than a Set

by StÃ©phane Ducasse

so that we can have a discussion in the list: > I recently carried this change in trunk (many commits). > > Context: traditionally st80 #keys answers a Set and #values answers > a Bag, > because both keys and values are unordered in a Dictionary. > > Squeak (and Pharo) #keys answer a Set, but #values answers with an > Array. > > This has some advantages: > 1) no code does expect a Bag specific protocol > 2) most code won't need to #add: to nor #remove: from values. > (this is not possible to perform these operations on an Array) > 3) creating and iterating an Array is much faster than a Bag, > because no > indirection, nor hash/lookup: is necessary, and no iteration on > empty slots > is necessary (a Set or Bag necessarily have empty slots). > > It happens that the same can be applied to #keys, because very few > senders > are using a Set specific protocol. > I did analyze this in the trunk image. > > There was already a #fasterKeys for that purpose that can happily be > cancelled. > > Drawbacks: > 1) break compatibility with a few external packages (that just a > matter of > adding asSet here and there, and this solution is inter dialect > compatible). > 2) changes might span across lot of packages > (exagerated in trunk because I adpoted then retracted #fasterKeys... > I did not dare breaking compatibility without Andreas agreement) > > Advantages: > 1) make #keys consistent with #values (same order, same class) > 2) optimize code without complexifying the code > > Delete commentComment 1 by nicolas.cellier.aka.nice, Today (11 hours > ago) > The same "optimization" can be applied on #selectors, and this is > related to this > subject because #selectors is defined in term of ^methodDict keys > On Oct 21, 2009, at 11:15 PM, Nicolas Cellier wrote: > >> I made a proposal here: >> http://code.google.com/p/pharo/issues/detail?id=1353 >> >> feel free to comment about it >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2009

Re: [Pharo-project] Perfect hash [was: Re: HashTable vs Dictionary]

by Igor Stasenko

2009/10/22 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Igor et al, > >> Let me simplify the goal of perfect hashing: >> - suppose you having N unique integer numbers, without strictly >> specified range (any number could lie in range 0..infinity). >> - now we need to find a function such that, for each element 'x' in >> the above finite set, following conditions met: >> >> 0 <= f(x) < k*N >> >> and for each pair of two different elements x , y in original set >> Â f(x) <> f(y) >> >> and k < infinity >> >> As you can see , this function maps an arbitrary integer values >> without specific range, to an >> integer values in range [0..k*N], (k>=1). >> Given that we need to deal with a limited number of elemens for each >> particular set of numbers, such function can be found. >> We just need to search for an optimal (minimal) k, which is < 2 and in >> perfect case == 1. >> >> > > I thought I'd point out a subtle potential problem. Â Assume N = 1000, > f(x_j) = j-1, and so k = 1 because 0 <= f(x_j) < N because 0 < j <= > 1000. Â Now, store x_{7i} in a Set, for all i such that 1 <= 7i <= 1000. > Clearly, f(x) is a perfect hash function as defined above. Â However, if > the size of the table used by the set is a multiple of 7, performance > will be terrible. > err.. i'm not sure i understood, if you having 1000 objects, which answering an unique hash values, which can be represented by: element hash == 7i and as you stating that 1 <= 7i <= 1000 , then there can't be 1000 unique hash values in this range for 1000 objects. Obviously you can have only 1000/7 unique hash values meeting such criteria. But if you read carefully, i'm not adressing the problem of duplicating hash values in input set, and presuming they are all unique. I'm not addressing the quality of hash function for object(s), i'm just illustrating a hash function which could be employed by set(s), which could work perfectly, once all objects having unique hash values. Surely, despite how good the hash function used by set, if hashes of its elements clashing, you will have a performance degradation. > By the way, you may want to check out the Hash Analysis Tool I wrote for > VisualWorks. Â It's in the public Store repository (bundle name "Hash > Analysis Tool", there's also an extensions bundle with more hash > functions and data sets). Â My blog has a (somewhat passable excuse for > a) manual here: > http://blogten.blogspot.com/2008/02/hash-analysis-tool-manual.html. > > Andres. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 22, 2009