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

Re: [Pharo-project] Proposal: adding 261 named colors
by StÃ©phane Ducasse Oct. 24, 2010

Oct. 24, 2010

ok I read the code :) I like 'swamp' Stef On Oct 23, 2010, at 11:30 PM, Johan Fabry wrote: > 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 :-) ) > > <Colors.png> > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] a bit of fun
by StÃ©phane Ducasse Oct. 24, 2010

Oct. 24, 2010

http://www.scribd.com/doc/38648591/About-Coders-new-version Stef

1 0

[Pharo-project] Issue 3152: wrong Monticello package dependencies
by Pavel Krivanek Oct. 24, 2010

Oct. 24, 2010

Hi, please integrate it soon: http://code.google.com/p/pharo/issues/detail?id=3152 Cheers, -- Pavel

1 0

[Pharo-project] [update 1.2] #12212
by Marcus Denker Oct. 24, 2010

Oct. 24, 2010

12212 ----- Issue 3137: Comment in Behavior >> allMethods is wrong Issue 3149: No setting in the setting browser Issue 3150: implementor of and sender of dont retrieve class side methods Issue 2340: Cursor for textEditor or new paragraph -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] some patterns I would like to **kill**
by StÃ©phane Ducasse Oct. 24, 2010

Oct. 24, 2010

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

3 6

[Pharo-project] #3149 and #3150
by Luc Fabresse Oct. 24, 2010

Oct. 24, 2010

A fix for : http://code.google.com/p/pharo/issues/detail?id=3149 http://code.google.com/p/pharo/issues/detail?id=3150 is attached. Tested in 12211. It was a bug introduced by my changes in SystemNavigation. Please, forgive me ;-) More unit tests are needed for SystemNavigation, SystemDictionary and SystemOrganization. I will write some. #Luc

1 0

[Pharo-project] [ANN] pre-build Core#12210
by Marcus Denker Oct. 24, 2010

Oct. 24, 2010

https://gforge.inria.fr/frs/download.php/27677/PharoCore-1.2-12210.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 2

[Pharo-project] [update 1.2] #12211
by Marcus Denker Oct. 24, 2010

Oct. 24, 2010

12211 ----- Issue 3141: nil when writeDefinition computing Issue 3147: How removing a class can broke DataStream/ReferenceStream/SmartRefStream Issue 3106: EToys resources relict in Form >> unhibernate Issue 3146: UIThemeStandardSqueaksmallDebugIcon is calling itself Issue 2525: SystemWindow out of focus color wrong Issue 1766: #objectForDataStream: should be in Package System-Serialization -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Oct. 24, 2010

johan what is the principle? There was a package on squeaksource or squeak map that adds a lot 512 or so color names. Stef

1 0

Oct. 23, 2010

> > 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 2) well, this is difficult to get the money for the butter and the butter - we are trying. 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. So for now identifying traits and learning is the way. Then we can refactor, redesign Stef

2 1