- Pharo-dev - lists.pharo.org

[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

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

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

Re: [Pharo-project] Smells looking at collections
by StÃ©phane Ducasse Oct. 23, 2010

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

[Pharo-project] How removing a class can broke DataStream/ReferenceStream/SmartRefStream
by Mariano Martinez Peck Oct. 23, 2010

Oct. 23, 2010

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>

2 1

Oct. 23, 2010

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

2 1

[Pharo-project] Complete an Array
by Simon De Baets Oct. 23, 2010

Oct. 23, 2010

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

3 2