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

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

by Reg Krock

Also, for an instance class defined as a variableSubclass, the contents of the 'slots' are not displayed in the inspector. This is decidedly unhelpful. Define class as: Object variableSubclass: #MyClass instanceVariableNames: '' classVariableBanes: '' poolDictionaries: '' category: 'MyCat' Create an instance and execute it as follows (MyClass new: 5) inspect and you will not see the 5 slots. Regards, Reg > I haven't used this new inspector much, but so far I'm not thrilled > either. > > As a concrete example, do "Undeclared inspect". In the old dictionary > inspector I get all the keys in the left pane and the selected key's > value in the right pane. It is simple but it provides the info I need. > In the new inspector there is too much stuff that I don't care about, > like class and methods. Why would I want to look at the class > Dictionary or at the bytecodes of a method of this class? Sometimes I > do, but in this case I know how to get there in other ways. Btw, what > I don't understand is why the keys of the dictionary are all displayed > in square brackets. It somehow suggests that these are blocks, but > they are plain symbols. > > Also I miss menu items. For instance, in the old dictionary inspector > there is a menu item "reference" that you get by right clicking on a > key. In the example of inspecting the undeclared dictionary, this item > is key to find where the undeclared bindings come from. Also I miss > the menu item "Chase pointers". > > Hence, as an improvement I suggest to remove all Class and Methods > entries in the trees and check the lost menu items. > > Cheers, > Adrian > > > > On Oct 21, 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 21, 2009

Re: [Pharo-project] HashTable vs Dictionary

by Lukas Renggli

> 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

Oct. 21, 2009

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

by Adrian Lienhard

I haven't used this new inspector much, but so far I'm not thrilled either. As a concrete example, do "Undeclared inspect". In the old dictionary inspector I get all the keys in the left pane and the selected key's value in the right pane. It is simple but it provides the info I need. In the new inspector there is too much stuff that I don't care about, like class and methods. Why would I want to look at the class Dictionary or at the bytecodes of a method of this class? Sometimes I do, but in this case I know how to get there in other ways. Btw, what I don't understand is why the keys of the dictionary are all displayed in square brackets. It somehow suggests that these are blocks, but they are plain symbols. Also I miss menu items. For instance, in the old dictionary inspector there is a menu item "reference" that you get by right clicking on a key. In the example of inspecting the undeclared dictionary, this item is key to find where the undeclared bindings come from. Also I miss the menu item "Chase pointers". Hence, as an improvement I suggest to remove all Class and Methods entries in the trees and check the lost menu items. Cheers, Adrian On Oct 21, 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

Oct. 21, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by Alexandre Bergel

Yes. "Kind of" is the right term. In Smalltalk, an object cannot access variables of another instance of the same class. Whereas in Java this is allowed. Cheers, Alexandre On 21 Oct 2009, at 09:59, Gerben van de Wiel wrote: > Thank you very much, if i understand it correctly then instance vars > in SmallTalk are "kind of" protected members in languages like Java > and C#? > > Regards, > Gerben > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 21, 2009

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

by Schwab,Wilhelm K

Stef, I had an open mind about it at first, but after having to retreat to an older image for a while and then seeing it again, (I respect you guys too much to soften this) I want no part of it (though I will look at improvements you want us to try). The choice of a simple inspector and the explorer is hard to beat - I can easily toggle between them with a right click. Anything that tries to do a shotgun wedding of the two ideas is a loser IMHO. I do some expensive computation, and I use a fair amount of lazy initialization, network proxies, etc. to soften the blow. There are times when the explorer is an expensive way to go. The new inspector will likely suffer the same problem, and I find it a serious step backward from explorer. The new inspector reminds me of something I wrote for browsing Dolphin code, IIRC at a package level. It was helpful, but not all that much, so I would use it only when I _really_ got lost. The mission was different, but I suspect the fate of the new inspector would be the same - I might use at times if it were offered by say control-shift-i vs. control-i for the regular inspector, but I prefer the existing tools. Just my 2 asCents. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, October 21, 2009 8:55 AM To: Pharo Development Subject: [Pharo-project] feedback about the "new inspector" 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

Oct. 21, 2009

Re: [Pharo-project] thanks to all the sprinters

by StÃ©phane Ducasse

could organize one at Fosdem but this is just the beginning of winter holiday in france :( Stef On Oct 21, 2009, at 4:05 PM, Johan Brichau wrote: > Thanks to the hosts for organizing this! > > I'm looking forward to another sprint > > On 20 Oct 2009, at 18:16, StÃ©phane Ducasse wrote: > >> Hi >> >> I want to thank you all for the three or four last days. It was good >> energy. >> >> Stef >> >> PS: for the others, adrian took some notes for the next iteration >> http://code.google.com/p/pharo/wiki/Milestones >> >> The idea is to have some focused tasks beside the normal continuous >> improvement and also have previous >> items. >> >> stef >> >> _______________________________________________ >> 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. 21, 2009

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Exceptions-jcg.14.mcz

by StÃ©phane Ducasse

this is a fun other :) Stef On Oct 21, 2009, at 11:11 AM, CÃ©drick BÃ©ler wrote: > Useful ? > There are other related commits. > > Cheers > > ---------- Forwarded message ---------- > From: <commits(a)source.squeak.org> > Date: 2009/10/21 > Subject: [squeak-dev] The Trunk: Exceptions-jcg.14.mcz > To: squeak-dev(a)lists.squeakfoundation.org > > > Joshua Gargus uploaded a new version of Exceptions to project The > Trunk: > http://source.squeak.org/trunk/Exceptions-jcg.14.mcz > > ==================== Summary ==================== > > Name: Exceptions-jcg.14 > Author: jcg > Time: 21 October 2009, 12:59:37 pm > UUID: 6fba13f2-81a8-4949-8b9e-d5c10aa58da6 > Ancestors: Exceptions-nice.13 > > Add NotYetImplemented exception class. > > =============== Diff against Exceptions-nice.13 =============== > > Item was added: > + ----- Method: NotYetImplemented>>receiverClass:selector: (in > category 'initialize') ----- > + receiverClass: cls selector: sel > + receiverClass := cls. > + selector := sel.! > > Item was added: > + ----- Method: NotYetImplemented>>selector (in category > 'accessing') ----- > + selector > + ^selector! > > Item was added: > + Error subclass: #NotYetImplemented > + instanceVariableNames: 'receiverClass selector context' > + classVariableNames: '' > + poolDictionaries: '' > + category: 'Exceptions-Kernel'! > + > + !NotYetImplemented commentStamp: 'jcg 10/21/2009 00:58' prior: 0! > + Sent by #notYetImplemented. Better than the age-old behavior of > opening a notifier window, because this can be caught and handled > + > + Perhaps there should be a Morphic backstop to open a notifier if > no-one else handles the exception, but this doesn't seem too > important. > + ! > > Item was added: > + ----- Method: NotYetImplemented>>receiverClass (in category > 'accessing') ----- > + receiverClass > + ^receiverClass! > > Item was added: > + ----- Method: NotYetImplemented class>>signal (in category > 'signaling') ----- > + signal > + "Call only from #notYetImplemented. Find the context that > sent #nYI... this is the method that needs to be implemented." > + | ctxt ex | > + ctxt := thisContext sender sender. > + ex := self new. > + ex receiverClass: ctxt receiver class selector: ctxt selector. > + ex messageText: ctxt printString. > + ex signal. > + ! > > > > > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 21, 2009

Re: [Pharo-project] thanks to all the sprinters

by Johan Brichau

Thanks to the hosts for organizing this! I'm looking forward to another sprint On 20 Oct 2009, at 18:16, StÃ©phane Ducasse wrote: > Hi > > I want to thank you all for the three or four last days. It was good > energy. > > Stef > > PS: for the others, adrian took some notes for the next iteration > http://code.google.com/p/pharo/wiki/Milestones > > The idea is to have some focused tasks beside the normal continuous > improvement and also have previous > items. > > stef > > _______________________________________________ > 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

Oct. 21, 2009

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

by StÃ©phane Ducasse

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

Oct. 21, 2009

Re: [Pharo-project] HashTable vs Dictionary

by StÃ©phane Ducasse

> You are, of course, correct. I agree that the place to focus on is the > hash functions being used. And I believe that there are some simple > improvements that can be made. > > From a (very!) brief look, this HashTable implementation appears to be > inspired by difficulties caused by having only 4096 identity hash > values > in Squeak/Pharo. If you have a large collection using identity hash > you > will, by definition, have lots of collisions. yyyyyyyyeeeeeeeeeeesssssssssssssssssssssssss and get linearrrrrrrrrrrrrrrrrrrrrly boring and slow. > The *best* (and most difficult) solution is to increase the number of > identity hash values that can be stored in the object header. Until > that > can be done, we adjust as best we can... > > -------------- > > First, the identity-based collections. > > The current IdentitySet and IdentityDictionary implementations do > adjust > the hash function for large table sizes, with this code in #scanFor: > > finish > 4096 > ifTrue: [hash := anObject identityHash * (finish // 4096)] > ifFalse: [hash := anObject identityHash]. > start := (hash \\ finish) + 1. > > This makes IdentityDictionary pretty much as fast as it can be at most > sizes, but there's a problem here. Take a look at the HashTable > comparison graph: > > http://img247.echo.cx/img247/3702/chart8vv.png > > IdentityDictionary is fast at most sizes, but has problems right > around > 4K of size. I'm going to assert (without testing, always dangerous in > performance work!) that this is because the hash spreading algorithm > above but always leaves an area at the end of the table array that > never > gets any hash values mapped to it. This will be worst when the table > size is between 4K and 8K, when the multiplier is still 1. When the > number of objects in the dictionary gets high enough that the table > grows again, the hashes start being spread out and it gets fast again. > > I'd suggest trying replacing the above code with something like this: > > hash := anObject identityHash * (finish // 4096 + 1) > start := (hash \\ finish) + 1. > > Not only better performing (I expect) but simpler. Possibly even > better-performing might be this: > > hash := anObject identityHash * <well-chosen constant> > start := (hash \\ finish) + 1. > > where the constant is large enough to get a spread across most of the > positive SmallInteger range, but not large enough to exceed it. > Andres, > what's a good choice for the constant? Maybe a prime that is never > close > to a prime used for a table size in these collections? > > > --------------- > > As the graph shows, Dictionary has a real problem when grown above > 4000 > entries, and I would expect Set to have a similar problem. I assume > this > is with objects that do not define a well-spread hash function, such > as > objects that implement hash as identity hash. And this is quite a few > objects. > > I'd suggest using a hash-spreading function on the equality-based > collections as well. Something like that used for IdentitySet *could* > work, but if you give that formula objects whose hashes *are* already > well-spread across the entire SmallInteger range, on most entries > you'd > be creating short-lived large integers, and if you're looking for > performance you don't want to do that. Using #hashMultiply would > probably improve things quite a bit, though it might be possible to > do a > bit better than that. > > With changes along these lines, I agree with Andres that linear- > probing > collections should be able to equal or beat the performance of chained > collections, and are a better choice for general-purpose collections. > > Regards, > > -Martin Martin don;t you have some changes so that we could try :) Stef

Oct. 21, 2009