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

[Pharo-project] Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... )

by StÃ©phane Ducasse

Hi nicolas I saw the following: Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... ) Now I recall why I introduced anArray (....) for printing. This is for case where the { . } does not work. Imagine that you have an object that does not have a printing version The key point of the design of self evaluating was that you could select an expression ie {10@20 . 30@20} and print it and get the same object this way we could manipulate a lot of objects much better in an inspector or debugger. So if we { anObjectWithAWrongForm . 10@20} it defeats the purpose of self evaluating. since there are situations like that anyway this is why we decided to have anArray( ....) to really indicate that this could not be self evaluating. The form #() and {} on the other sides where always something that we could manipulate. so I had the impression that fixing some classes would be nicer than removing the distinction. Stef

Nov. 1, 2009

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

by StÃ©phane Ducasse

Yes for weak, I agree for set may be some people use that. Now I would like to hear levente usage of announcement. And igor having a simple but COMMON infrastructure is important so we need the core. Now I would also like to know the cost of always broadcasting. I do not remember correctly but in vassili'blog there were some points to avoid that. Because in the past, in Smalltalk the dependency where broadcasting to all the dependents and this was inadequate and after they introduce on:when:..... to get only the right listener updated. Stef On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote: >> In current core image, Announcements is quite small (just around 10 >> methods totally) and i doubt it provides enough >> flexibility which would not require adding & reinventing additional >> useful stuff on top of it. > > I have used these announcements in many large projects and I never > needed to add anything. In fact, I would even vote to remove > AnnouncementSet as I never used it or saw it used anywhere. Initially, > I found it cool because the same trick is applied in the Exception > hierarchy. Major projects like OmniBrowser (and to some extent also > Seaside) use an even smaller subset of the functionality provided in > the core package. > > The only thing that is maybe missing are weak announcements. I guess > that could be useful, if Pharo provided a solid implementation of weak > objects. > > 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

Nov. 1, 2009

Re: [Pharo-project] call for helping me sorting out what to integrate :)

by StÃ©phane Ducasse

Ok I will let martin and andres have a look because I'm not enough expert in that. On Nov 1, 2009, at 4:30 AM, Ralph Boland wrote: >> >> Hi guys >> >> It would help me to know the pending bugs that you fixed and that we >> should integrate. >> Of course everything should be on the bugtracker but I would like to >> know for example >> when there is a consensus for the hash implementation when it is >> ready >> to go in 1.1. >> >> In the meantime I will go over the bugtracker and pick up what is >> available (ie tagged 1.1 and fixed). >> It is important that we tag systematically the issues that will be >> integrated in 1.1 as 1.1 so that after >> we can follow. Some of the old entries integrated in 1.0 are not >> tagged 1.0 and may be we should script >> the bugtracker. > > I assume that it is planned to add some version of my/Levente's > FasterSets code to Phare 1.1. > If so, then then it may be confusing to make the FasterSets code and > any hashedCollections code at the same time. > I thus suggest that a final decision on FasterSets be made and get > the changes done so any changes to hashedCollections can be done > on top of FasterSets rather than in parallel. > > Regards, > > Ralph Boland > > -- > Volume * Density = Mass. > Volume / Density = Intelligence. > The latter equation explains the > essentially equal intelligence of men and woman > and the capabilities of some commonly used operating systems. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 1, 2009

Re: [Pharo-project] [update 1.1] #11020

by StÃ©phane Ducasse

Argh the image I used was polluted. I will fix that today. Stef On Oct 31, 2009, at 11:38 PM, Nicolas Cellier wrote: > What is RPackage ? > It seems to cause a failure during upgrade > > 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> 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 >> >> >> _______________________________________________ >> 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

Nov. 1, 2009

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

by Lukas Renggli

> But if it so stripped to bare-bones, then where the benefits to use > exactly Announcements? I would rather like to hear what this "more wide functionality" is all about? So far you only argued that big is better. I don't buy that. This is old, but "Small is the new big" ;-) A smaller infrastructure also means: - easier to learn - less code that rots - less code to maintain - less code duplication - less code to test - loose coupling - smaller image Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 1, 2009

Re: [Pharo-project] call for helping me sorting out what to integrate :)

by Ralph Boland

> > Hi guys > > It would help me to know the pending bugs that you fixed and that we > should integrate. > Of course everything should be on the bugtracker but I would like to > know for example > when there is a consensus for the hash implementation when it is ready > to go in 1.1. > > In the meantime I will go over the bugtracker and pick up what is > available (ie tagged 1.1 and fixed). > It is important that we tag systematically the issues that will be > integrated in 1.1 as 1.1 so that after > we can follow. Some of the old entries integrated in 1.0 are not > tagged 1.0 and may be we should script > the bugtracker. I assume that it is planned to add some version of my/Levente's FasterSets code to Phare 1.1. If so, then then it may be confusing to make the FasterSets code and any hashedCollections code at the same time. I thus suggest that a final decision on FasterSets be made and get the changes done so any changes to hashedCollections can be done on top of FasterSets rather than in parallel. Regards, Ralph Boland -- Volume * Density = Mass. Volume / Density = Intelligence. The latter equation explains the essentially equal intelligence of men and woman and the capabilities of some commonly used operating systems.

Nov. 1, 2009

Re: [Pharo-project] Author of method

by Schwab,Wilhelm K

Thanks!!! -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Saturday, October 31, 2009 1:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Author of method 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 1, 2009