- Pharo-dev - lists.pharo.org

Re: [Pharo-project] some patterns I would like to **kill**

by Igor Stasenko

On 23 October 2010 21:47, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Hey, I want some credit here - for coming to Squeak's possible defense :) > > All I am saying is that there is a possible space/speed tradeoff with a twist. Â There was a fair amount written about these decisions, which is why I know anything at all about them. Â Adding an instance variable for a rarely used sub-morph of a widely-instantiated morph might be an opportunity to fail to learn from history. Â Most likely, the patterns Stef has noticed are simply mis-uses of sparse storage. Â The best way to proceed would be to find an example of it that has many instances in the image, profile, fix, and profile again to see if the fix hurts performance (or perhaps helps it). Â The usual caveats about benchmarking being really hard to do well apply, of course. > I did some experiment(s) with Morphic, placing many morph aspects into properties dictioary (such as color, border, borderwidth etc), and these values are used in rendering all the time. And i didn't noticed heavy speed degradation. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Saturday, October 23, 2010 11:00 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] some patterns I would like to **kill** > > On 23 October 2010 17:13, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Stef, >> >> Of course. Â But in terms of avoiding unintended consequences, just consider the points I raised. Â Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used. >> > Well, one way or another you have to tame the complexity somehow. > Be it extra instvar, or putting it into extensions doesn't changes the > model's concept: you need a reference to some object > which is responsible for some specific stuff. > > >> Bill >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Saturday, October 23, 2010 7:33 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] some patterns I would like to **kill** >> >> I think that if you have a container that contains morphs probably findA and other queries are useful. >> Now for a button that is also at the same place a field is the best. >> >> Stef >> >> >> On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> #respondsTo: - no argument. Â More defensive programming (aka masked bugs). Â Tests like this have their place, but are over-used in Squeak. >>> >>> Using #submorphs *might* be easier to defend. Â Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. Â An instance variable could also cache stale information. Â Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read. >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] >>> Sent: Thursday, October 21, 2010 4:47 PM >>> To: Pharo Development >>> Subject: [Pharo-project] some patterns I would like to **kill** >>> >>> Hi >>> >>> I was reading Pluggable and friends >>> I identified some patterns. >>> >>> >>> The respondsTo plague >>> Examples: >>> >>> color := self fillStyle asColor. >>> Â Â Â Â (self labelMorph respondsTo: #enabled:) >>> Â Â Â Â Â Â Â Â ifTrue: [self labelMorph enabled: self enabled]. >>> Â Â Â Â (self labelMorph respondsTo: #interactionState:) >>> Â Â Â Â Â Â Â Â ifTrue: [self labelMorph interactionState: self interactionState] >>> >>> (self labelMorph respondsTo: #enabled:) ifTrue: [ >>> Â Â Â Â self labelMorph enabled: aBoolean]. >>> >>> (self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]]) >>> >>> >>> by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed. >>> >>> >>> Using submorphs to avoid one single inst var makes code quite ugly to read: >>> >>> >>> labelMorph >>> Â Â Â Â "Answer the actual label morph." >>> >>> Â Â Â Â self hasSubmorphs ifFalse: [^nil]. >>> Â Â Â Â self firstSubmorph hasSubmorphs ifFalse: [^nil]. >>> Â Â Â Â ^self firstSubmorph firstSubmorph >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 24, 2010

[Pharo-project] Deprecation policy (was: Re: Object>>at:modify:???)

by Levente Uzonyi

On Sat, 23 Oct 2010, Mariano Martinez Peck wrote: > On Sat, Oct 23, 2010 at 1:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> wrote: > >> Ok we can deprecate it. >> >> > ys, but please please please use deprecated: anExplanationString on: date > in: version Wouldn't it be easier to rely on method timestamps + a version cache, than spreading redundant information all over the place? Something like: Object >> deprecated: anExplanationString "Warn that the sending method has been deprecated." (Deprecation method: thisContext sender method explanation: anExplanationString on: (TimeStamp fromMethodTimeStamp: thisContext sender method timeStamp) date "Or something nicer") signal Deprecation class >> method: aCompiledMethod explanation: anExplanationString on: date ^self new method: aCompiledMethod explanation: anExplanationString on: date asString in: (SystemVersion alphaVersionAt: date) Someone has to implement #alphaVersionAt: (which is easy, but SystemVersion has to be modified). Finally the developement process has to follow some simple rules. Levente > > cheers > > mariano > > >> On Oct 22, 2010, at 11:04 PM, Hernan Wilkinson wrote: >> >>> In a 1.1 image I have, the class HttpRequest is using that message... >>> >>> On Thu, Oct 21, 2010 at 4:08 PM, stephane ducasse < >> stephane.ducasse(a)free.fr> wrote: >>> I would like to deprecate the following method since nobody use it. >>> What do you think? >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> -- >>> HernÃ¡n Wilkinson >>> Agile Software Development, Teaching & Coaching >>> Mobile: +54 - 911 - 4470 - 7207 >>> email: hernan.wilkinson(a)10Pines.com >>> site: http://www.10Pines.com >>> >>> _______________________________________________ >>> 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. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sat, 23 Oct 2010, StÃ©phane Ducasse wrote: >> >> There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. >> >> >> That's a nice solution, but it means that Traits have to be in the Kernel. I have three problems with Traits: >> 1) they are stateless >> 2) they are different from classes >> 3) incomplete tools support (this may be fixed in Pharo, but I doubt it is) > > 1) we build some code to see if we really need state and this is not that obvious and adding state is not trivial Not trivial? Maybe not, but only a little bit harder than trivial. > 2) well, this is difficult to get the money for the butter and the butter - we are trying. If you can compose classes the way you can add a trait to a class now with class and optional method level instance+class variable mapping, then you're done. It would be a lot simpler to use it _and_ it would also be a lot easier to implement it. Especially the tools part. > 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. Tools are a must. No tools - no users. > > So for now identifying traits and learning is the way. Then we can refactor, redesign Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. Levente > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] Proposal: adding 261 named colors

by Schwab,Wilhelm K

I don't like the idea of instantiating red if the name is not recognized. Since you don't have selectors (900+ might be a bit much), the compiler/Shout won't catch mistakes, and it will be an ongoing source of silent failures. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Johan Fabry [jfabry(a)dcc.uchile.cl] Sent: Saturday, October 23, 2010 5:29 PM To: Pharo Development Subject: [Pharo-project] Proposal: adding 261 named colors Hi all, in the work of AspectMaps I was a bit let down by the named colors Pharo provides (Color red et cetera). Now I am happy to say that thanks to the XKCD color survey I was able to improve on this. I can now use 261 named colors thanks to a XKCDColor class, and I'd like to share the code, ideally to be included into Pharo. The code is available in bugreport http://code.google.com/p/pharo/issues/detail?id=3148 Here is the class comment fo XKCDColor: ---snip--- A color named according to the XKCD color survey, as published in http://blog.xkcd.com/2010/05/03/color-survey-results/ ("Over five million colors were named across 222,500 user sessions.") Of the full table of 954 colors that is published only those were selected that did not have a space in their name, ignoring e.g. electric lime, nasty green, macaroni and cheese, pinkish tan, but also light light blue, strong blue. This results in a table of 261 named colors, but with duplicates such as ochre and ocre. These were left in since as they are common misspellings it is more convenient for the user. To instantiate: XCDColor named: aString where aString is one of the 261 named colors. If the name is not known, the color red is instantiated. Instances of XKCDColor know their XKCD color name, returned by the name accessor. Thanks to Randall Monroe of http://xkcd.com for providing the data. ---snip--- And here is a picture of all the colors (Generated with Mondrian :-) )

Oct. 23, 2010

Re: [Pharo-project] How removing a class can broke DataStream/ReferenceStream/SmartRefStream

by Schwab,Wilhelm K

SmartReferenceStream is indeed complicated, but it is also poorly designed. Dolphin's binary filer intuitively places versioning (of the serialized data streams) on the class side of each serialzed class or a proxy for same. The result is that the filer itself does not change as the classes it marshals change shape, nor does it try to think for the user and programmer or ask end users to debug conversion problems. If you think things are bad now, wait until you start stepping on Stef's and Sig's changes (for example purposes only) to the filer. SIXX tackles some of this, but I have yet to run into it, perhaps in part because it seems to work more by messages/aspects than by instance variables as Dolphin's filer. It is very possible that I have yet to push SIXX far enough to see problems, but I recommend having a look at it. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Saturday, October 23, 2010 4:08 PM To: Pharo Development Subject: [Pharo-project] How removing a class can broke DataStream/ReferenceStream/SmartRefStream Pharo core version: 12210 In Pharo 1.2, the class SoundBuffer was removed. DataStream >> initilize was modified, and just added an Smalltalk at: ifPresent: for such class. However, this broke DataStream and all its subclasses. This is because DataStream is chryptic, impossible to understand, and impossible to change. The changed affected when trying to write compiled methods (just by chance, because they were after in the list, of SoundBuffer). I've spent 3 hours to fix this bug grrrrr Fix in Inbox: Name: SLICE-Issue-3147-RomovingSoundBufferBrokeDataStream-MarianoMartinezPeck.1 Author: MarianoMartinezPeck Time: 23 October 2010, 10:07:35 pm UUID: c4f1cf01-b8b8-471d-b3c2-e67bdf08d8e5 Ancestors: Dependencies: System-Object Storage-MarianoMartinezPeck.112 Fix to issue 3147<http://code.google.com/p/pharo/issues/detail?id=3147>

Oct. 23, 2010

[Pharo-project] Proposal: adding 261 named colors

by Johan Fabry

Hi all, in the work of AspectMaps I was a bit let down by the named colors Pharo provides (Color red et cetera). Now I am happy to say that thanks to the XKCD color survey I was able to improve on this. I can now use 261 named colors thanks to a XKCDColor class, and I'd like to share the code, ideally to be included into Pharo. The code is available in bugreport http://code.google.com/p/pharo/issues/detail?id=3148 Here is the class comment fo XKCDColor: ---snip--- A color named according to the XKCD color survey, as published in http://blog.xkcd.com/2010/05/03/color-survey-results/ ("Over five million colors were named across 222,500 user sessions.") Of the full table of 954 colors that is published only those were selected that did not have a space in their name, ignoring e.g. electric lime, nasty green, macaroni and cheese, pinkish tan, but also light light blue, strong blue. This results in a table of 261 named colors, but with duplicates such as ochre and ocre. These were left in since as they are common misspellings it is more convenient for the user. To instantiate: XCDColor named: aString where aString is one of the 261 named colors. If the name is not known, the color red is instantiated. Instances of XKCDColor know their XKCD color name, returned by the name accessor. Thanks to Randall Monroe of http://xkcd.com for providing the data. ---snip--- And here is a picture of all the colors (Generated with Mondrian :-) ) -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Oct. 23, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by Adrian Kuhn

Sad to hear that. Technical difficulties, or just lack of customers? ^^ --AA On Oct 23, 2010, at 08:05 , StÃ©phane Ducasse wrote: > It was too difficult to integrate. > > Stef > > On Oct 23, 2010, at 2:01 PM, Niko Schwarz wrote: > >> What's the status of akuhn/SUnit? I couldn't find his code in 1.2 >> core. >> >> Niko >> >> On Wed, Feb 3, 2010 at 1:13 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> this loads well in the latest 1,1 core :) >>> so now we should really have a look and these cool changes >>> >>> Stef >>> >>> On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: >>> >>>> SystemChangeNotifier uniqueInstance >>>> noMoreNotificationsFor: TestCase. >>>> Gofer it >>>> disablePackageCache; >>>> squeaksource: 'akuhn'; >>>> package: 'SUnit'; >>>> package: 'SUnitGUI'; >>>> load. >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] Complete an Array

by Nicolas Cellier

2010/10/23 Luc Fabresse <luc.fabresse(a)gmail.com>: > Hi Simon, > Â If I understand well, you should use a dot to separate the two expressions > in the block. > |test isFact| > > test := Array new:5. > isFact := False. > test doWithIndex:[ :each :i | ((each isNil) & (isFact = False)) > Â Â Â ifTrue:[ > Â Â Â Â Â Â Â test at:i put:'plain'. > Â Â Â Â Â isFact := True > Â Â Â Â Â Â ] > Â Â Â ]. > > #Luc > Also using classes False and True rather than their instances false and true is questionnable. |test isFact| test := Array new:5. isFact := false. test doWithIndex:[ :each :i | ((each isNil) & (isFact not)) ifTrue:[ test at:i put:'plain'. isFact := true ] ]. This code find the first nil and replace it with 'plain', so it could be as well: | test isFact firstNilIndex | test := Array new: 5. firstNilIndex := test findFirst: [:each | each isNil]. isFact := firstNilIndex > 0. isFact ifTrue: [test at: firstNilIndex put: 'plain']. Nicolas > > 2010/10/23 Simon De Baets <debaetssimon(a)gmail.com> >> >> Hello, >> >> I use Pharo 1.1 .Â I want to add a new element in an array that have a >> part of nil element. I want to add this new element on the first nil case. I >> produce this code >> >> |test isFact| >> >> test := Array new:5. >> isFact := False. >> test doWithIndex:[ :each :i | ((each isNil) & (isFact = False)) >> Â Â Â ifTrue:[ >> Â Â Â Â Â Â Â test at:i put:'plain'; isFact := True >> Â Â Â Â Â Â ] >> Â Â Â ]. >> test. >> >> But it doesn't function because they are two instruction in the ifTrue >> bolck. So my question is : "How can i put two instructions in an ifTrue >> block?" >> >> Thanks, >> >> -- >> Simon De Baets, >> Etudiant en MA1 informatique Ã l'ULB >> >> >> _______________________________________________ >> 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. 23, 2010

[Pharo-project] How removing a class can broke DataStream/ReferenceStream/SmartRefStream

by Mariano Martinez Peck

Pharo core version: 12210 In Pharo 1.2, the class SoundBuffer was removed. DataStream >> initilize was modified, and just added an Smalltalk at: ifPresent: for such class. However, this broke DataStream and all its subclasses. This is because DataStream is chryptic, impossible to understand, and impossible to change. The changed affected when trying to write compiled methods (just by chance, because they were after in the list, of SoundBuffer). I've spent 3 hours to fix this bug grrrrr Fix in Inbox: Name: SLICE-Issue-3147-RomovingSoundBufferBrokeDataStream-MarianoMartinezPeck.1 Author: MarianoMartinezPeck Time: 23 October 2010, 10:07:35 pm UUID: c4f1cf01-b8b8-471d-b3c2-e67bdf08d8e5 Ancestors: Dependencies: System-Object Storage-MarianoMartinezPeck.112 Fix to issue 3147 <http://code.google.com/p/pharo/issues/detail?id=3147>

Oct. 23, 2010

[Pharo-project] Fwd: [Metacello] Re: problem with metacello in 1.2

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: October 23, 2010 9:31:33 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Re: [Metacello] Re: [Pharo-project] problem with metacello in 1.2 > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: October 23, 2010 9:31:23 PM GMT+02:00 > To: metacello(a)googlegroups.com > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Metacello] Re: [Pharo-project] problem with metacello in 1.2 > > > yes we spent some time trying to find what would be the problem > but we could not identify one version (image, vm) on which we got constantly the problem accross variation. > > Stef > On Oct 23, 2010, at 8:09 PM, Tudor Girba wrote: > >> Several people had the same problem today: Fabrizio and Jorge in Bern, and Jannik in Lille. And they had it with different versions of Pharo 1.2. >> >> Cheers, >> Doru >> >> >> On 23 Oct 2010, at 19:05, Mariano Martinez Peck wrote: >> >>> >>> >>> On Sat, Oct 23, 2010 at 7:05 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> Wierd...now I have the same problem :( >>> >>> >>> On Sat, Oct 23, 2010 at 6:06 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> I think you were having a problem with the internet connection. Here it is fine. >>> Try again ;) >>> >>> 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> >>> Hi all, >>> i was trying to make Moose loadable into a 1.2 i did try to run the configuration of Moose and i got an error at the very beginning caused by the configuration of metacello. Am i missing something or it actually should work? I did expect to have problem but not with the configuration of metacello. >>> >>> I'm using a >>> >>> Pharo image 12203 on a Squeak4.2.5beta1U VM >>> >>> To reproduce the error just open the image and execute in a workspace: >>> >>> Gofer new >>> squeaksource: 'Moose'; >>> package: 'ConfigurationOfMoose'; >>> load. >>> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault >>> >>> Attached the log. >>> >>> Thanks, >>> Fabrizio >>> >>> _______________________________________________ >>> 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 >> >> "One cannot do more than one can do." >> >> >> > > > >

Oct. 23, 2010