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

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by Igor Stasenko

AXAnnouncements is pretty small and accompanied with tests. So why not integrate it + removing 'AX' prefix because, as decided previously, it should be in Pharo core? 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > what would be good is to have a small discussion on the key and > minimal features that could be added to Announcements, > add some tests and code. > > Stef > On Oct 31, 2009, at 5:17 PM, StÃ©phane Ducasse wrote: > >> Levente >> >> what I would really love :) >> is if you could provide some extensions to the new version based on >> your experience. >> I think that Announcements are a bit limited right now. Then the core >> would be enhanced and we >> could clarified the license. >> >> Stef >> >> On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote: >> >>> Hi! >>> >>> Just to make things clear, AXAnnouncements >>> - is not "a port of the original announcement implementation" >>> - is (more or less) based on Vassili Bykov's blog >>> Â (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Ann… >>> ) >>> Â just like the Announcements package in Pharo >>> - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html >>> ). >>> We implemented the framework as the blog entries came out and >>> integrated >>> it into our rudimentary ajax framework (that's where the AX prefix >>> came >>> from). Later we abandoned the ajax framework but found announcements >>> really useful (especially with seaside components), so we extracted >>> the >>> code and moved it to squeaksource. Our ajax framework demo was >>> available >>> at http://axdemo.seasidehosting.st/. >>> >>> For a quick comparison: AXAnnouncements is bloated and has lower code >>> quality than Announcements, but it implements more features, like >>> suspension and interception of announcements, weak subscriptions and >>> allows different base class for the announcements hierarchy per >>> announcer. >>> >>> Cheers, >>> Levente >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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] [update 1.1] #11020

by StÃ©phane Ducasse

nicolas could you check because I have some tests that fail on Float. stef On Oct 31, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: > 11020 > ----- > > - Issue 1387: Mantis 7409 arcTan: has a specific implementation near > zero and negativeZero > Test and patch for http://code.google.com/p/pharo/issues/detail?id=1387 > http://bugs.squeak.org/view.php?id=7409 > make arcTan: behave like libm atan2 near zero and negativeZero > > - Issue 1390: Print literals exactly when decompiled > > - Issue 1388: FixedIdentitySet #arraySize has no senders > > - Issue 1331: DNU upon file-in of changeset > > > stef > > _______________________________________________ > 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] Hashed collection improvements: Some code

by StÃ©phane Ducasse

oh this would be good. Stef On Oct 31, 2009, at 7:19 PM, Andres Valloud wrote: > Ok, I can prepare the checkpointed changesets for Martin's changes > then. > > StÃ©phane Ducasse wrote: >> Ok since there were some other discussions I think that andres and >> martin got a consensus >> on the solution (I had the impression that the one of martin was >> prefered). >> So as soon as the code is ok we will integrate that. >> >> Stef >> >> >> >> On Oct 29, 2009, at 10:39 AM, Nicolas Cellier wrote: >> >> >>> After-thoughts: my opinion is: >>> Martin solution is more pragmatical : it is tailored for getting >>> most >>> improvment with minimal change in system. >>> But formally, I prefer Andres design for it's clarity. >>> - I do not like the idea that #identityHash and #primIdentityHash do >>> behave differently >>> - #scaledIdentityHash does clearly express itself on the contrary >>> But that turns into german discussions ;) >>> >>> Nicolas >>> >>> 2009/10/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>> 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>>> Martin >>>>> >>>>> are these changes related to the graphs you sent? >>>>> I will have a look after my hospital check. >>>>> Andres? Nicolas? >>>>> Any feedback? >>>>> Martin I imagine that I can package the changes :) >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>> This has been pretty well explained by Martin and Andres. >>>> The decision you have to make is : >>>> >>>> - choose Martin change, make speed improvment for most senders of >>>> #identityHash, but eventually break a few senders and let package >>>> maintainers fix it (example Magma) >>>> - choose Andres change, assure 100% compatibility, let the >>>> responsibility to package maintainers to use new message for >>>> improving >>>> speed. >>>> >>>> In both cases, package maintainer might have to maintain different >>>> branch for Squeak and Pharo, but I guess the solution would be >>>> adopted >>>> soon in Squeak/trunk. >>>> >>>> I would tend to be conservative, but I recently took the opposite >>>> path >>>> with #keys and #selectors in trunk, so I just can't give you my >>>> personal preference, it's 50-50... >>>> Whatever the choice, #identityHash usage is worth a review by >>>> package >>>> maintainers anyway. >>>> >>>> Note that this is closely related to >>>> http://bugs.squeak.org/view.php?id=1876 and >>>> http://code.google.com/p/pharo/issues/detail?id=213 >>>> Amazing the issue is still there when workarounds are known for so >>>> long... So please do something! >>>> >>>> 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 >> . >> >> > > _______________________________________________ > 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] Bitten by MethodReference

by StÃ©phane Ducasse

for storing package information for method for example. And this is not clear to me that method should know their selector so a compiled method could be a pure vm entity and a methodref its metaobject :) Stef On Oct 31, 2009, at 6:55 PM, Adrian Lienhard wrote: > I think that a main reason for using MethodReference was to be able to > capture the class in which a method is installed and the method's > selector. Before method properties were introduced, a method did not > know its class and selector and hence all classes had to be searched > to find this out (the method was named #who returning an array with > the class and selector ;)). > > I don't see any reason why MethodReference would still be useful as > you can just reference a CompiledMethod directly. > > Adrian > > On Oct 31, 2009, at 13:59 , Igor Stasenko wrote: > >> 2009/10/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Hi >>> >>> just to share a ugly design point with MethodReference >>> >>> MethodReference are created using >>> >>> MethodReference class: aClass symbol: aSymbol >>> >>> however they store the class ***name*** >>> >>> and after when you query the class using either actualClass or >>> methodClass >>> you get the class that is in Smalltalk. >>> >>> So if like me you copied the class then you will get another version >>> of your class >>> even if this is the right one you use to create the >>> MethodReference.... >>> >>> One of these days we will have to check that >>> >> >> Yes, i wondering myself, what is the point to reference the methods >> in >> such style. >> The way, how actual class & its method get resolved makes it >> impossible to reference a method in >> arbitrary class object, especially one which is not installed into >> system dictionary. >> >> I think its lacking additional form of indirection, which should be >> an >> environment object who is responsible for >> delivering the method's source code along with resolving the class by >> its name. Without such indirection, i see no point in having a >> MethodReference per se, >> because you can always do the same thing by yourself , i.e. >> (Smalltalk >> at: #SomeClass) methodDict at: #someSelector. >> Without that, i see no point why i would want to use it, because it >> always points to same thing, no matter where i using the >> MethodReference. >> >>> Stef >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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

[Pharo-project] [update 1.1] #11020

by StÃ©phane Ducasse

11020 ----- - Issue 1387: Mantis 7409 arcTan: has a specific implementation near zero and negativeZero Test and patch for http://code.google.com/p/pharo/issues/detail?id=1387 http://bugs.squeak.org/view.php?id=7409 make arcTan: behave like libm atan2 near zero and negativeZero - Issue 1390: Print literals exactly when decompiled - Issue 1388: FixedIdentitySet #arraySize has no senders - Issue 1331: DNU upon file-in of changeset stef

Oct. 31, 2009

Re: [Pharo-project] Author of method

by Adrian Lienhard

The last author is stored in the source. You can get it (including the timestamp) as follows: (CompiledMethod compiledMethodAt: #timeStamp) timeStamp HTH, Adrian On Oct 31, 2009, at 19:40 , Schwab,Wilhelm K wrote: > Hello all, > > I'm stumped. How does the browser display the author initials/name/ > whatever-it-uses? Can I go from a CompiledMethod to the name of the > author? > > Bill > > > _______________________________________________ > 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

[Pharo-project] Author of method

by Schwab,Wilhelm K

Hello all, I'm stumped. How does the browser display the author initials/name/whatever-it-uses? Can I go from a CompiledMethod to the name of the author? Bill

Oct. 31, 2009

Re: [Pharo-project] Hashed collection improvements: Some code

by Andres Valloud

Ok, I can prepare the checkpointed changesets for Martin's changes then. StÃ©phane Ducasse wrote: > Ok since there were some other discussions I think that andres and > martin got a consensus > on the solution (I had the impression that the one of martin was > prefered). > So as soon as the code is ok we will integrate that. > > Stef > > > > On Oct 29, 2009, at 10:39 AM, Nicolas Cellier wrote: > > >> After-thoughts: my opinion is: >> Martin solution is more pragmatical : it is tailored for getting most >> improvment with minimal change in system. >> But formally, I prefer Andres design for it's clarity. >> - I do not like the idea that #identityHash and #primIdentityHash do >> behave differently >> - #scaledIdentityHash does clearly express itself on the contrary >> But that turns into german discussions ;) >> >> Nicolas >> >> 2009/10/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> >>> 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>>> Martin >>>> >>>> are these changes related to the graphs you sent? >>>> I will have a look after my hospital check. >>>> Andres? Nicolas? >>>> Any feedback? >>>> Martin I imagine that I can package the changes :) >>>> >>>> >>>> Stef >>>> >>>> >>> This has been pretty well explained by Martin and Andres. >>> The decision you have to make is : >>> >>> - choose Martin change, make speed improvment for most senders of >>> #identityHash, but eventually break a few senders and let package >>> maintainers fix it (example Magma) >>> - choose Andres change, assure 100% compatibility, let the >>> responsibility to package maintainers to use new message for >>> improving >>> speed. >>> >>> In both cases, package maintainer might have to maintain different >>> branch for Squeak and Pharo, but I guess the solution would be >>> adopted >>> soon in Squeak/trunk. >>> >>> I would tend to be conservative, but I recently took the opposite >>> path >>> with #keys and #selectors in trunk, so I just can't give you my >>> personal preference, it's 50-50... >>> Whatever the choice, #identityHash usage is worth a review by package >>> maintainers anyway. >>> >>> Note that this is closely related to >>> http://bugs.squeak.org/view.php?id=1876 and >>> http://code.google.com/p/pharo/issues/detail?id=213 >>> Amazing the issue is still there when workarounds are known for so >>> long... So please do something! >>> >>> 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 > . > >

Oct. 31, 2009

Re: [Pharo-project] Bitten by MethodReference

by Adrian Lienhard

I think that a main reason for using MethodReference was to be able to capture the class in which a method is installed and the method's selector. Before method properties were introduced, a method did not know its class and selector and hence all classes had to be searched to find this out (the method was named #who returning an array with the class and selector ;)). I don't see any reason why MethodReference would still be useful as you can just reference a CompiledMethod directly. Adrian On Oct 31, 2009, at 13:59 , Igor Stasenko wrote: > 2009/10/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi >> >> just to share a ugly design point with MethodReference >> >> MethodReference are created using >> >> MethodReference class: aClass symbol: aSymbol >> >> however they store the class ***name*** >> >> and after when you query the class using either actualClass or >> methodClass >> you get the class that is in Smalltalk. >> >> So if like me you copied the class then you will get another version >> of your class >> even if this is the right one you use to create the >> MethodReference.... >> >> One of these days we will have to check that >> > > Yes, i wondering myself, what is the point to reference the methods in > such style. > The way, how actual class & its method get resolved makes it > impossible to reference a method in > arbitrary class object, especially one which is not installed into > system dictionary. > > I think its lacking additional form of indirection, which should be an > environment object who is responsible for > delivering the method's source code along with resolving the class by > its name. Without such indirection, i see no point in having a > MethodReference per se, > because you can always do the same thing by yourself , i.e. (Smalltalk > at: #SomeClass) methodDict at: #someSelector. > Without that, i see no point why i would want to use it, because it > always points to same thing, no matter where i using the > MethodReference. > >> Stef >> >> _______________________________________________ >> 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] dictionary value is an array?

by Andres Valloud

Watch out, because code like this may or may not work: someDictionary keys do: [:each | each isNotInteresting ifTrue: [someDictionary removeKey: each]] Thus, I think keys should answer a new collection. If the intent is to iterate over the keys, then I'd send the message directly to the dictionary. Andres. Lukas Renggli wrote: > 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 > >

Oct. 31, 2009