- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] ExpectedFailures in SUnit
by StÃ©phane Ducasse Oct. 23, 2010

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

Re: [Pharo-project] Object>>at:modify:???
by StÃ©phane Ducasse Oct. 23, 2010

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

Re: [Pharo-project] fixed issue 3029
by StÃ©phane Ducasse Oct. 23, 2010

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

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

Oct. 23, 2010

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

1 0

Oct. 23, 2010

+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

2 1

Oct. 23, 2010

On Oct 23, 2010, at 1:58 PM, Igor Stasenko wrote: > On 23 October 2010 14:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 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. >> > > <sarcasm> > if morph having a random submorphs, inserted out of nowhere, just for > fun to see what happen. then yes.. findA is userful, as well as > respondsTo: > </sarcasm> I like your sarcasm, we are all in sync on that Open a 3.8 or 3.9 and check findA: > but if we are talking about specific morphs, like Pluggable and > friends, who serving a certain purpose (building UI from spec), > where no place for 'random', then this truly a bad design. :) > >> 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 >> > > > > -- > 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

2 1