- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.2] #12210

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 5:16 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 12210 > ----- > > Issue 2653: Editor cursor fix > Issue 3015: When a test is restarted in the debugger, #tearDown and > #setUp and not send > This is excellent and I suffer this problem several times. Thanks Hernan!!! > Issue 1853: NetNameResolver localHostAddress returns public or private > address instead of loopback address. > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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] Smells looking at collections

by Levente Uzonyi

On Sat, 23 Oct 2010, jaayer wrote: > ---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- >Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. > > >So I looked that the documentation of each of these classes: > > >Association:Â I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. > > >Magnitude:Â I'm the abstract class Magnitude that provides common protocol for objects that have >the ability to be compared along a linear dimension, such as dates or times. > Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >Character and LookupKey. > > > >Based on this, I think this relation is conceptually WRONG. >If the idea is to reuse code then composition should be used instead of inheritance. > > > > >What do you think? > >Saludos! >Nico. >blog: nicopaez.wordpress.com 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) Levente _______________________________________________ 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] fixed issue 3025

by Marcus Denker

On Oct 23, 2010, at 5:05 PM, Fabrizio Perin wrote: > fixed 3025 > > http://code.google.com/p/pharo/issues/detail?id=3025. > > code in slice SLICE-Issue-3025-removedtest-FabrizioPerin.1.mcz in pharoinbox. > > The Slice seems to be empty -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

[Pharo-project] [update 1.2] #12210

by Marcus Denker

12210 ----- Issue 2653: Editor cursor fix Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send Issue 1853: NetNameResolver localHostAddress returns public or private address instead of loopback address. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

[Pharo-project] fixed issue 3025

by Fabrizio Perin

fixed 3025 http://code.google.com/p/pharo/issues/detail?id=3025. code in slice SLICE-Issue-3025-removedtest-FabrizioPerin.1.mcz in pharoinbox. Cheers, Fabrizio

Oct. 23, 2010

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

by Igor Stasenko

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.

Oct. 23, 2010

Re: [Pharo-project] Smells looking at collections

by jaayer

---- On Fri, 22 Oct 2010 04:56:28 -0700 NicolÃ¡s Paez wrote ---- >Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude.It is really strange for me because inheritance represent a "is-a" relation. > > >So I looked that the documentation of each of these classes: > > >Association:Â I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. > > >Magnitude:Â I'm the abstract class Magnitude that provides common protocol for objects that have >the ability to be compared along a linear dimension, such as dates or times. > Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as >Character and LookupKey. > > > >Based on this, I think this relation is conceptually WRONG. >If the idea is to reuse code then composition should be used instead of inheritance. > > > > >What do you think? > >Saludos! >Nico. >blog: nicopaez.wordpress.com 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.

Oct. 23, 2010

[Pharo-project] [update 1.2] #12209

by Marcus Denker

12209 ----- Issue 3049: ClassBuilderTest Issue 1746: ReferenceStream>>readOnlyFileNamed: is missing Issue 1981: Raising DuplicateError Exception in class builder Issue 2525: SystemWindow out of focus color wrong Issue 3143: To mark a test as an expected failure, one has to overwrite expectedFailures -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

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

by Schwab,Wilhelm K

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. 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

Oct. 23, 2010

Re: [Pharo-project] ExpectedFailures in SUnit

by StÃ©phane Ducasse

Tx niko Stef On Oct 23, 2010, at 3:52 PM, Niko Schwarz wrote: > I created an issue and submitted a fix: > http://code.google.com/p/pharo/issues/detail?id=3143 > > Niko > > On Wed, Oct 20, 2010 at 3:48 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> +1 >> the problem is that we should sync with nial for SUNit but since brest I do not know what really make progress. >> I still want to know the status of a test. what is red or not when it was packaged and shipped or is is my system the problem >> >> Stef >> On Oct 20, 2010, at 1:41 PM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Wed, Oct 20, 2010 at 12:15 PM, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >>> Hi, >>> >>> Currently, to mark a test as an expected failure, `expectedFailures` >>> should be overwritten >>> (http://stackoverflow.com/questions/3976596/how-to-mark-expected-failures-in…) >>> That's a bit tricky to figure out, so I added a comment to the method: >>> SUnit-NikoSchwarz.114. However, I think it's still a usability bug: >>> marking something as an expectedFailure isn't visible inside the test. >>> >>> I think expectedFailures should look through the pragmas of its tests >>> and return an array of all method names that contain the pragma >>> <expectedFailure>. >>> >>> Yes, that's better. But in addition, sometimes we need conditions. For example: >>> >>> Smalltalk listPlugins contains: 'blahhh' ifFalse[ expectedFailures add: 'testBlah' ] >>> >>> or whatever condition. Can you do that with pragmas? >>> >>> the other problem is that we don't have expectedErrors as well. This is bad and confusing. >>> >>> cheers >>> >>> mariano >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Niko >>> >>> -- >>> 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 >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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