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

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

Re: [Pharo-project] Object>>at:modify:???

by StÃ©phane Ducasse

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

Oct. 23, 2010

Re: [Pharo-project] fixed issue 3029

by StÃ©phane Ducasse

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

Oct. 23, 2010

Re: [Pharo-project] Object>>at:modify:???

by Guillermo Polito

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 >

Oct. 23, 2010

[Pharo-project] fixed issue 3029

by Fabrizio Perin

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

Oct. 23, 2010

Re: [Pharo-project] ExpectedFailures in SUnit

by Niko Schwarz

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

Oct. 23, 2010

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

by Igor Stasenko

On 23 October 2010 15:04, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 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: > Actually this is a serious problem: how to keep flexibility, but at same time enforce some specific rules over 'random' cloud of data. My thought about it, that if some morph expects some hierarchical organization from submorphs (like label in button morph), then it should explicitly state that it expects a certain protocol to be supported by its submorphs, like #enabled: #contents: etc. So, then it could send these messages without any checks, and if DNU happens, then its a responsibility of those who made a mistake by putting wrong things inside a button. Another idea is to use a button as a 'decorator' to another morph, called 'label'. A label could have any number of arbitrary submorphs, but button could have only single submorph, up to the point that it could override #submorphs with: submorphs ^ { label } and dispatch #addSubmorph to a label: addSubmorph: aMorph ^ label addSubmorph: aMorph then it having total control over its contents (only single submorph, known that it understand a certain protocol), and everyone is happy: - user could put anything inside button - developer can be sure it will work without any problems, whatever you may put in it There could be other ways to solve that. >> 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 > > > _______________________________________________ > 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

[Pharo-project] [update 1.2] #12207

by StÃ©phane Ducasse

12207 ----- starting to clean systemNavigation and to make sure that it can work on an environment. Tx Luc Fabresse Stef

Oct. 23, 2010

Re: [Pharo-project] pregunta mundo Pharo

by Mariano Martinez Peck

upssss sorry....Wrong mail. Please ignore. thanks mariano 2010/10/23 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/10/23 Carlos Lombardi <carlombardi(a)gmail.com> > > Mariano >> >> ante todo buenos dÃas. Â¡Buenos dÃas! >> > > Que haces carlono!! todo bien? espero que si :) > > >> >> Ahora el asunto. Si quiero pedir al mundo que se agregue algo a Pharo, >> Â¿hay algÃºn medio adecuado y sencillo? >> >> > Lo mas facil es mandar un mail a la lista: > pharo-project(a)lists.gforge.inria.fr > Si no te queres subscrbir, podes postear desde: > http://forum.world.st/Pharo-Smalltalk-f1294837.html > O registrate en la mailing list y deci que no te manden mails y listo. > > DespuÃ©s, depende de lo que querias agregar. Si es al "Core", si es una > extension a paquetes externos (OB, RB, Shout, OCompletion, etc), o si queres > que directamente un nuevo paquete venga preinstalado en las imagenes Pharo. > > De chusma, que queres poner? > > abrazo > > mariano >

Oct. 23, 2010

Re: [Pharo-project] pregunta mundo Pharo

by Mariano Martinez Peck

2010/10/23 Carlos Lombardi <carlombardi(a)gmail.com> > Mariano > > ante todo buenos dÃas. Â¡Buenos dÃas! > Que haces carlono!! todo bien? espero que si :) > > Ahora el asunto. Si quiero pedir al mundo que se agregue algo a Pharo, Â¿hay > algÃºn medio adecuado y sencillo? > > Lo mas facil es mandar un mail a la lista: pharo-project(a)lists.gforge.inria.fr Si no te queres subscrbir, podes postear desde: http://forum.world.st/Pharo-Smalltalk-f1294837.html O registrate en la mailing list y deci que no te manden mails y listo. DespuÃ©s, depende de lo que querias agregar. Si es al "Core", si es una extension a paquetes externos (OB, RB, Shout, OCompletion, etc), o si queres que directamente un nuevo paquete venga preinstalado en las imagenes Pharo. De chusma, que queres poner? abrazo mariano

Oct. 23, 2010

Re: [Pharo-project] Complete an Array

by Luc Fabresse

Hi Simon, If I understand well, you should use a dot to separate the two expressions in the block. |test isFact| test := Array new:5. isFact := False. test doWithIndex:[ :each :i | ((each isNil) & (isFact = False)) ifTrue:[ test at:i put:'plain'. isFact := True ] ]. #Luc 2010/10/23 Simon De Baets <debaetssimon(a)gmail.com> > 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 > > > _______________________________________________ > 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

[Pharo-project] Complete an Array

by Simon De Baets

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

Oct. 23, 2010

[Pharo-project] [update 1.2] #12206

by Marcus Denker

12206 ----- Issue 2876: setStandardClass: aClass methodSymbol: methodSym (part2) Issue 3116: Reduce DecompilerTest failures to three legitimate failures. Issue 3140: Utilities removing -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

Re: [Pharo-project] Object>>at:modify:???

by Philippe Marschall

On 22.10.2010 23:04, Hernan Wilkinson wrote: > In a 1.1 image I have, the class HttpRequest is using that message... At least we should move it to Dictionary. But I think we can easily fix Kom. Cheers Philippe

Oct. 23, 2010

[Pharo-project] problem with metacello in 1.2

by Fabrizio Perin

Hi all, i was trying to make Moose loadable into a 1.2 i did try to run the configuration of Moose and i got an error at the very beginning caused by the configuration of metacello. Am i missing something or it actually should work? I did expect to have problem but not with the configuration of metacello. I'm using a Pharo image 12203 on a Squeak4.2.5beta1U VM To reproduce the error just open the image and execute in a workspace: Gofer new squeaksource: 'Moose'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault Attached the log. Thanks, Fabrizio

Oct. 23, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by StÃ©phane Ducasse

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

Oct. 23, 2010

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

by StÃ©phane Ducasse

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

Oct. 23, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by Niko Schwarz

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

Oct. 23, 2010

Re: [Pharo-project] a useful check

by Igor Stasenko

On 23 October 2010 14:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What is the way to fix that? > something ifTrue: [ [ code which never runs ] ] -->> something ifTrue: [ code which now can run ] unless, of course it is used like: block := something ifTrue: [ [block1 ] ] ifFalse: [ [block2]]. > >> SystemNavigation new browseAllSelect: >> Â Â Â [:m| | is | >> Â Â Â is := InstructionStream on: m. >> Â Â Â is scanFor: [:b| b = 143 and: [(m at: is thirdByte * 256 + is fourthByte + is pc + 4) = 135]]] > > > lookForCode: code ifDifferent: handleBlock > Â Â Â Â "We are expecting a certain numeric code next. > Â Â Â Â However, in the FTP protocol, multiple lines are allowed. > Â Â Â Â If the response is multi-line, the fourth character of the first line is a > Â Â Â Â $- and the last line repeats the numeric code but the code is followed by > Â Â Â Â a space. So it's possible that there are more lines left of the last response that > Â Â Â Â we need to throw away. We use peekForAll: so that we don't discard the > Â Â Â Â next response that is not a continuation line." > > > Â Â Â Â "check for multi-line response" > Â Â Â Â (self lastResponse size > 3 > Â Â Â Â Â Â Â Â Â Â Â Â and: [(self lastResponse at: 4) = $-]) > Â Â Â Â Â Â Â Â ifTrue: ["Discard continuation lines." > Â Â Â Â Â Â Â Â Â Â Â Â [ | headToDiscard | > Â Â Â Â Â Â Â Â Â Â Â Â headToDiscard := self lastResponse first: 4. > Â Â Â Â Â Â Â Â Â Â Â Â [[self stream peekForAll: headToDiscard] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â whileTrue: [self stream nextLine]] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â on: Exception > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â do: [:ex | ^handleBlock value: nil]]]. > Â Â Â Â ^ super lookForCode: code ifDifferent: handleBlock > _______________________________________________ > 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

[Pharo-project] if you want to join the pharo sprint

by StÃ©phane Ducasse

skype stducasse, we chat there. Stef

Oct. 23, 2010

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

by Igor Stasenko

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

Oct. 23, 2010

Re: [Pharo-project] Object>>at:modify:???

by Mariano Martinez Peck

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 >

Oct. 23, 2010

Re: [Pharo-project] a useful check

by StÃ©phane Ducasse

What is the way to fix that? > SystemNavigation new browseAllSelect: > [:m| | is | > is := InstructionStream on: m. > is scanFor: [:b| b = 143 and: [(m at: is thirdByte * 256 + is fourthByte + is pc + 4) = 135]]] lookForCode: code ifDifferent: handleBlock "We are expecting a certain numeric code next. However, in the FTP protocol, multiple lines are allowed. If the response is multi-line, the fourth character of the first line is a $- and the last line repeats the numeric code but the code is followed by a space. So it's possible that there are more lines left of the last response that we need to throw away. We use peekForAll: so that we don't discard the next response that is not a continuation line." "check for multi-line response" (self lastResponse size > 3 and: [(self lastResponse at: 4) = $-]) ifTrue: ["Discard continuation lines." [ | headToDiscard | headToDiscard := self lastResponse first: 4. [[self stream peekForAll: headToDiscard] whileTrue: [self stream nextLine]] on: Exception do: [:ex | ^handleBlock value: nil]]]. ^ super lookForCode: code ifDifferent: handleBlock

Oct. 23, 2010

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

by StÃ©phane Ducasse

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

Oct. 23, 2010