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

Re: [Pharo-project] dictionary value is an array?

by Lukas Renggli

It always annoyed me that #keys and #values create a new collection object. Form an object-oriented stand-point of view, what would rather make sense is to return a collection that delegates to the dictionary. For example, DictionaryKeys would be a subclass of Collection, behave like a Set and be implemented along ... Dictionary>>keys ^ DictionaryKeys on: self DictionaryKeys>>do: aBlock dictionary keysDo: aBlock DictionaryKeys>>includes: anObject ^ dictionary includesKey: anObject DictionaryKeys>>species ^ Set I bet that this would not only result in a major performance improvement, but also greatly reduce memory consumption. Furthermore it would solve the problem that #keys suddenly has totally different performance characteristics as we decide to return an Array instead of a Set. For example, it wouldn't matter anymore if you wrote aDictionary includesKey: #foo or aDictionary keys includes: #foo I see only obvious problem for such an approach and this is when the dictionary changes and the keys are stored somewhere. Some users might not expect the keys to change too. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 31, 2009

Re: [Pharo-project] dictionary value is an array?

by Nicolas Cellier

2009/10/31 Igor Stasenko <siguctua(a)gmail.com>: > 2009/10/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> Hi nicolas >>> >>> If I remember you proposed fixes to have dictionary values -> array? >>> Is it correct? >>> >>> I was wondering why? >>> Because a set makes more sense to me since >>> Â Â Â Â - the order of the elements in values is not useful (because they >>> come from a dict) >>> Â Â Â Â - the occurrences not really either >>> Â Â Â Â - we cannot add to the results so we should create another collection >>> >>> May be I'm totally wrong with the changes but I think that values >>> should be set while keys an array. >>> I would be interested in discussion on that. >>> >>> Stef >>> >>> >> >> Dictionary values is already an Array... >> I proposed to change keys accordingly. >> >> Historically, they were a Bag and a Set because they were unordered. >> >> But very few or no sender expect a behavior specific to a Bag or a Set. >> Most just do: select: collect: asArray asSortedCollection etc... >> That's where an Array outperforms a Set or a Bag. >> >> So we are paying the price of a Set or a Bag almost for nothing... >> And that is why you can see a #fasterKeys. >> >> The drawback is that a few senders will add: to or remove: from keys. >> My estimation is around 5%. >> Inside the image, no problem, it is easy to fix, just write >> (someDictionary keys asSet). >> But that put a load on package maintainers. >> > > +1 Nicolas. Personally, i think that modifying a collection which not > constructed by your own code > is bad programming style, because you never know where this collection > is came from and you can't be sure that there is no other users of it, > which in own turn may modify it at any moment, while often you > assuming that only you own the collection and don't expecting any > modifications to it except in own code. > So, IMO this approach is error prone, and you should never use > #remove: or #add: with collections which constructed by separate > package/layer, and instead, use #asSet, #asOrderedCollection and, of > course #copy, before starting manipulating its elements. > I agree. removing from another one's collection is not that well behaved ! It's putting expectations higher than necessary. I see this as a sort of optimization breaking encapsulation... I want to come with a better optimization. Unfortunately, historical uses will be found here and there, #keys being a well-known case. We have to put pressure on maintainers... Who ever takes this path shall be ready to sell the idea, and prove that gains > costs. A team modifying kernel in uncompatible manner (and we have to, or just stick to Squeak 3.7) shall provide support for a smooth transiiton. Sometimes I feel it would be convenient to inquire a code base larger than just an image, so that we can emit proposals and sell the idea rather than just waiting for complaints passively.... Nicolas > >> Nicolas >> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] vm on ubuntu

by Schwab,Wilhelm K

Doru, My machine is busy with an upgrade to 9.10 as I type, so I won't be able to check this for a while. IIRC, there at least was an entry for Squeak in the package manager. It was perhaps a couple of years ago that I used it; it worked well, but the version of Squeak that was installed was dated even at the time. See the message I just posted about using a shell script for another option. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Tudor Girba Sent: Saturday, October 31, 2009 8:56 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] vm on ubuntu Hmm, I get the following error: >>>>sudo apt-get install squeak-vm Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package squeak-vm I am running on Ubuntu 8.04.3 LTS. Doru On 31 Oct 2009, at 14:31, Lukas Renggli wrote: >> What is the preferred way to install a Pharo vm on Ubuntu? > > The instructions in the Seaside book should work: > > http://book.seaside.st/book/advanced/deployment/deployment-apache/inst > all-vm > > Did you try that? > > Cheers, > 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 -- www.tudorgirba.com "Every thing has its own flow." _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] vm on ubuntu

by Tudor Girba

Hmm, I get the following error: >>>>sudo apt-get install squeak-vm Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package squeak-vm I am running on Ubuntu 8.04.3 LTS. Doru On 31 Oct 2009, at 14:31, Lukas Renggli wrote: >> What is the preferred way to install a Pharo vm on Ubuntu? > > The instructions in the Seaside book should work: > > http://book.seaside.st/book/advanced/deployment/deployment-apache/install-vm > > Did you try that? > > Cheers, > 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 -- www.tudorgirba.com "Every thing has its own flow."

Oct. 31, 2009

Re: [Pharo-project] Fwd: Adding FasterSets to Pharo: update

by Nicolas Cellier

2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Thanks. I push the discussion to pharo since lot of people are > interested. > > Stef > > Begin forwarded message: > >> From: Ralph Boland <rpboland(a)gmail.com> >> Date: October 29, 2009 11:43:04 PM GMT+01:00 >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Cc: Levente Uzonyi <leves(a)elte.hu> >> Subject: Adding FasterSets to Pharo: update >> >> I took a look at FasterSets and Levente Uzonyi's version. >> I compared the two versions as of the first release of Levente's >> version to Squeak. Â Note that he has released additional >> changes since then. >> Here is my report. >> >> 1) Â Bugs: >> >> Â Â FasterSets has two problems: >> Â Â Â a) Â KeyedIdentitySet is missing method Â ScanForNil: >> Â Â Â b) Â PluggableSet is missing method Â NoCompareOrGrowAddAll: >> Â Â Both cases should cause failure. Â Note that I have been using >> Â Â this code for years without problem. Â I assume that is because >> the subset >> Â Â of Squeak that I used doesn't include using these classes. >> Â Â These problems are easily fixed. >> >> Â Â In Levente's code class WeakKeyToCollectionDictionary->rehash >> seems to be >> Â Â missing. Â This appears to be a mistate to me but I will live it >> to Levente to explain >> Â Â it. Â The fix, if needed, is simple. >> >> 2) Code quality: >> Â Â For me the code quality is about the same but Levente considers >> his version to be better. >> Â Â In any case changes in one version is easily ported to the other >> so it would be easy to >> Â Â perform any cleanup you might want. Â Three notes in particular. >> Â Â Â a) Â Levente's version of Â rehash is cleaner and should be used >> instead of mine. >> Â Â Â b) Â Levente's version does not use method Â scanForNilFrom: Â (He >> would probably call >> Â Â Â Â Â the method scanForEmptySlotFrom:). >> Â Â Â Â Â I don't know why he didn't do this: it clearly cleaner. >> >> Â 3 Performance. >> Â Â Â a) According to Levente's stats Â rehash is clearly faster in >> his version than mine. Â I see >> Â Â Â Â Â no reason no not prefer his version to mine. >> >> Â Â Â b) The improvement in performance for method add: Â in >> Levente's version >> Â Â Â Â Â is insignificant Â (appx 1%); Â this difference could easily >> be made up in minor >> Â Â Â Â Â changes to my code. Â Thus here I consider there to be no >> difference. >> >> Â Â Â b) Â Levente's version does not apply the FasterSets idea to >> MethodDictionary. >> Â Â Â Â Â I am not sure why he did not do this but it may have >> something to do with the fact that >> Â Â Â Â Â mistakes can easily corrupt your image. Â The version in >> FasterSets works fine though >> Â Â Â Â Â it took three tries for me to get it right (mostly because >> of carelessness). >> >> Â Â Â c) Â I left methods Â intersection and nastyAddNew: out of classes >> Set and Dictionary for >> Â Â Â Â Â Â the initial version of FasterSets to keep the number of >> changes to a minimum. >> Â Â Â Â Â Â At your request I added them to the current version. >> These methods are not in >> Â Â Â Â Â Â Levente's version. Â They are public methods that provide >> performance improvements. >> Â Â Â Â Â Â If desired they could easily be added to Levente's version. >> >> >> Based on the above I would Â say that there is not a great deal of >> difference between Levente's version and mine but what difference >> there is favors his version. >> >> I recommend that >> >> Â Â 1) Â You use Levente's version. >> Â Â 2) Â Sort out the issue of no rehash method for Class >> WeakKeyToCollectionDictionary. >> Â Â 3) Â Modify his code to use method scanForNilFrom: Â (calling it >> scanForEmptySlotFrom:). >> Â Â 4) Â Decide if you want to add methods Â intersect: and >> nastyAddNew:. >> Â Â Â Â Â I can add these if you want. >> Â Â 5) Release a version of Pharo with these changes. >> Â Â 6) Â In the following release of Pharo add the changes to >> MethodDictionary to use The >> Â Â Â Â Â FasterSets Idea. Â I sugggest doing this separately from >> everything else just because it is a >> Â Â Â Â Â bit hairy. Â I would not leave this change out because >> MethodDictionary is too important >> Â Â Â Â Â a class not to have these improvements. >> >> >> One final comment. Â If you really want to make the Set hierarchy >> better I would suggest that >> you move the Dictionary hierarchy out of the Set hierarchy >> altogether. Â This means some >> duplication of code but makes for a much cleaner implementation. Â For >> example you get to >> avoid the mess with MethodDictionary. Â Of the three implementations >> of Smalltalk that I >> have looked at Â Squeak/Pharo is the only version that uses one >> hierarchy. >> This is probably too major a change to make but at least you now know >> my opinion on the >> Â matter. >> You dont have to duplicate. You can just derive the two classes from a common HashedCollection ancestor. http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/117894.html Nicolas >> >> You can post this on the Pharo newsgroup if you like but perhaps you >> should get Levente's >> opinion first. >> >> Â Regards >> >> Â Ralph Boland > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 31, 2009

Re: [Pharo-project] vm on ubuntu

by Schwab,Wilhelm K

Not knowing what to make of Squeak vs. Pharo (or perhaps waiting until there is an Ubuntu package for the Pharo VM), I simply unpacked the vm under ~Software/PharoVM and launch Pharo with a shell script that lists the full path to the vm and the image. Then I added an icon to my Programming menu with the script as an action. If any of that is non-obvious to you, feel free to ask questions. I have done something similar on Windows for years to avoid the moods and bloat of the Windows Installer, so a script to specify the vm and image struck me as the preferred way to make it work. I have not yet started to run my own services on Linux, and what I am recommending might(??) lead to problems with ownership of the path. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Saturday, October 31, 2009 8:31 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] vm on ubuntu > What is the preferred way to install a Pharo vm on Ubuntu? The instructions in the Seaside book should work: http://book.seaside.st/book/advanced/deployment/deployment-apache/install-vm Did you try that? Cheers, 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. 31, 2009

Re: [Pharo-project] dictionary value is an array?

by Igor Stasenko

2009/10/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Hi nicolas >> >> If I remember you proposed fixes to have dictionary values -> array? >> Is it correct? >> >> I was wondering why? >> Because a set makes more sense to me since >> Â Â Â Â - the order of the elements in values is not useful (because they >> come from a dict) >> Â Â Â Â - the occurrences not really either >> Â Â Â Â - we cannot add to the results so we should create another collection >> >> May be I'm totally wrong with the changes but I think that values >> should be set while keys an array. >> I would be interested in discussion on that. >> >> Stef >> >> > > Dictionary values is already an Array... > I proposed to change keys accordingly. > > Historically, they were a Bag and a Set because they were unordered. > > But very few or no sender expect a behavior specific to a Bag or a Set. > Most just do: select: collect: asArray asSortedCollection etc... > That's where an Array outperforms a Set or a Bag. > > So we are paying the price of a Set or a Bag almost for nothing... > And that is why you can see a #fasterKeys. > > The drawback is that a few senders will add: to or remove: from keys. > My estimation is around 5%. > Inside the image, no problem, it is easy to fix, just write > (someDictionary keys asSet). > But that put a load on package maintainers. > +1 Nicolas. Personally, i think that modifying a collection which not constructed by your own code is bad programming style, because you never know where this collection is came from and you can't be sure that there is no other users of it, which in own turn may modify it at any moment, while often you assuming that only you own the collection and don't expecting any modifications to it except in own code. So, IMO this approach is error prone, and you should never use #remove: or #add: with collections which constructed by separate package/layer, and instead, use #asSet, #asOrderedCollection and, of course #copy, before starting manipulating its elements. > Nicolas > >> >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 31, 2009

Re: [Pharo-project] Socket>>socketStream

by Schwab,Wilhelm K

Sig, An OO layer on top of procedural software does not have to be tied to the limitations of the procedural software, and in general should not be. You make refactoring of Socket sound like it can only be done by a complete slash and burn, when in fact it could be as simple as exposing behavior where it makes sense. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 7:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/31 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > Furthering a bad design practice does not illustrate an attempts to promote safe use of resources. Â If you knew that adding the behavior was a bad idea, why did you suggest it? > because, as to me, what you are proposing is equivalent to it. In smalltalk you can enforce the correct usage of provided functionality only by means of provided behavior. > Server behavior: consider listening on ports and accepting connections. Â True, that is BSD socket behavior, but you are trying to have it both ways. Â You cannot complain about superset behavior that I might introduce and then later say that the current design is ok because it uses the same shotgun wedding approach as BSD (aka a superset interface). > we have what we have. :) If you'd were writing own library for network communication which directly speaks with hardware (like in SqueakNOS), then you are free to do it differently. But Socket implementation depends on underlaying socket library, adopted by wide range of OSes working with wide range of hardware. It is good that we having something in common and don't need to invent or implement it from scratch. And despite how good or bad it is, it allows us to write portable software, including smalltalk, unless you refactor Socket class :) > Taking your approach, nothing in Squeak would ever get fixed. Â In fact, "well, YOU can always do such and such in YOUR image" was the usual argument used to block change in Squeak. Â Something to think about. > if there will be fix or extension in original socket library, only then we should consider synchronizing Socket class with it. > And yes, replacing the entire network system has crossed my mind. Â IPv4 and 6 are currently mixed into a big ball of mud (no offense to those working hard to add it, but it's not at all factored, and should be). Â I will hopefully soon be in a position to get network connections running across platforms, and I suspect that the errors reported some months ago will turn out to be due to the new sockets. Â Finally, we should have access to SSL sockets via OpenSSL. Â That might just drop in along side of the current socket system, but there might be room for a better solution, perhaps as an extension of Nile. > as long as you are using same library (sockets), i see not much reasons why we would need to drastically refactor the stuff. Because, with whatever code will wrap it, you end up using same system calls which expecting same argument types & returning same results. So, instead of 'better wrapper', we should expose these calls to language, as close as possible to original and this is the main role of Socket class. Then anyone is free to use them as he likes to. This is what i meant by talking about 'own subclass' and this is why i think that Socket class is bad place for refactory. My point is, that if you writing own library/classes, which having virtually no dependencies from other frameworks, then you are free to do it in any way you like to. But if your goal is to expose the functionality of existing library (such as sockets), then instead, you should be very pedantic and do it as much as close to original, despite how good or bad it is. Then you are opening doors to people who already used this library before, but in another environment/language. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] vm on ubuntu

by Lukas Renggli

> What is the preferred way to install a Pharo vm on Ubuntu? The instructions in the Seaside book should work: http://book.seaside.st/book/advanced/deployment/deployment-apache/install-vm Did you try that? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 31, 2009

[Pharo-project] Fwd: MouseOverHandler

by StÃ©phane Ducasse

Begin forwarded message: > From: Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > Date: October 29, 2009 2:02:32 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: MouseOverHandler > > Hi Stef, > do you know why the MouseOverHandler version I made is not in the > main image? the current version is not working well, under heavy use > it generates exceptions... > I'm attaching the version I wrote that I'm using without problem... > > Hernan.

Oct. 31, 2009