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

[Pharo-project] smallDebugIcon kiss of death
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

smallDebugIcon "Answer a small debug icon." ^self smallDebugIcon Should be turned into ^ self smallErrorIcon Stef

1 0

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

Oct. 23, 2010

This is in 1.2 :) Stef On Oct 23, 2010, at 4:55 PM, 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. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] [update 1.2] #12209
by Marcus Denker Oct. 23, 2010

Oct. 23, 2010

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.

3 2

[Pharo-project] [update 1.2] #12210
by Marcus Denker Oct. 23, 2010

Oct. 23, 2010

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.

2 1

[Pharo-project] Smells looking at collections
by NicolÃ¡s Paez Oct. 23, 2010

Oct. 23, 2010

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

4 4

Re: [Pharo-project] fixed issue 3025
by Marcus Denker Oct. 23, 2010

Oct. 23, 2010

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.

1 0

[Pharo-project] fixed issue 3025
by Fabrizio Perin Oct. 23, 2010

Oct. 23, 2010

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

1 0

Oct. 23, 2010

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

1 0

Oct. 23, 2010

yes we probably should On Oct 23, 2010, at 4:04 PM, Guillermo Polito wrote: > Why not deprecate/remove the #deprecate: without the useful parameters? :D > > 2010/10/23 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 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 > > 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 > > > _______________________________________________ > 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

1 0

Oct. 23, 2010

Thanks man! On Oct 23, 2010, at 3:54 PM, Fabrizio Perin wrote: > Fixed issue 3029 > > http://code.google.com/p/pharo/issues/detail?id=3029 > > Restored the menu from ParagraphEditor yellowButtonMenu. Replaced the implementation of SmalltalkEditor class initializeYellowButtonMenu. > > Cheers > > Fabrizio > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0