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

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

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

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

Re: [Pharo-project] some patterns I would like to **kill**
by StÃ©phane Ducasse Oct. 23, 2010

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

[Pharo-project] [update 1.2] #12207
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

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

1 0

Re: [Pharo-project] pregunta mundo Pharo
by Mariano Martinez Peck Oct. 23, 2010

Oct. 23, 2010

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

1 1

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

Oct. 23, 2010

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.

1 0

[Pharo-project] akuhn/SUnit: run faster tests first & step through tests
by Adrian Kuhn Oct. 23, 2010

Oct. 23, 2010

Hi Pharo list, The lastest akuhn/SUnit runs fasters tests first. When running your test suite for the second time, faster tests are run first. For the whole 9000 tests in the dev image, this means that the first 8000 tests are run in like 10 milliseconds. Also I fixed the menues in the test runner, you can now mark either all or single tests are expected defect. If you mark expected defects through the UI they are stored on the class side. The #expectedFailures method on the instance side is still taken into account for compatibility, but storing expected defects on the class side is the preferred way to do it now. I also cleared up the vocabulary. There are no more history on the class side, rather there are two histories one called "last run" and one called "expected defects" that both serve different purposes. The "last run" history is used to mark test results in the browser. The "expected defects" history is used to keep track of expected / unexpected defects. (As far I know, the icons in O2 show this as well.) Plus I added the ability to step through a failed tests. This stops right before the actual test method, rather than at the failed assertion. To step through a failed test, run your tests with the test runner and use the menu of test failures or errors. (OB and O2 might consider adding this option as well. In particular in combination with running fasters tests first a "run and debug/step-through first failure" might be interesting.) To load akuhn/SUnit gofer SystemChangeNotifier uniqueInstance noMoreNotificationsFor: TestCase. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load. Thank you all for the awesome feedback last time! More is welcome :) --AA

3 5

Re: [Pharo-project] a useful check
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

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

2 1

[Pharo-project] if you want to join the pharo sprint
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

skype stducasse, we chat there. Stef

1 0

[Pharo-project] Pharo article in linuxMag fr
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

> > > Just to say that recently, there were/are 2 articles about Pharo in GNU Linux Magazine (http://www.gnulinuxmag.com/) a french mag. > One was publish in the n130, about a presentation of Pharo. > One will be published in one week in the n132, about Gofer. > > Cheers, > --- > Jannik Laval >

4 4

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

Oct. 23, 2010

12205 ----- Issue 2619: ignore vm parameters with nil value in MessageTally, so it can be used in Cog Issue 1885: Disable Scroll Wrapping in PluggableListMorph Issue 3142: Updater package has no repository Issue 2876: setStandardClass: aClass methodSymbol: methodSym (first part) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Pavel can you check :)
by StÃ©phane Ducasse Oct. 23, 2010

Oct. 23, 2010

Apparently when we browse Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) we get a problem because there is a nil in the set. Can you have a look? Stef

1 0

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

Oct. 23, 2010

12204 ----- Issue 2868: allClassesUsingPool: allClassesUsingPoolVariable: for systemNavigation Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph Issue 3130: MethodReference >> #isLocalSelector should not be part of Monticello package Issue 3095: Character isLiteral is in wrong category Issue 3134: Cleaning uniclasses from smartRefStream -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] some patterns I would like to **kill**
by stephane ducasse Oct. 22, 2010

Oct. 22, 2010

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

2 1

[Pharo-project] About Object and Model
by stephane ducasse Oct. 22, 2010

Oct. 22, 2010

Hi guys I'm reading Object and I have the impression that some methods are in Object while there should be on Model. when: anEventSelector send: aMessageSelector to: anObject exclusive: aValueHolder okToClose.... taskbarIcon taskbarLabel May be some of these methods should grouped in traits, then applied to Model. Then if the user wants something else than Model to play the game he can simply apply a trait. I think that this hierarchical decomposition is often forcing us to stack methods in the wrong place I think that the composition is way stronger and much more flexible than hierarchical ordering. tell me what you think. I would like to have a nice Object class. Stef

2 1

[Pharo-project] What is a primitive method?
by Oscar E A Callau Oct. 22, 2010

Oct. 22, 2010

Hi all, I have a (basic) question: What is a primitive method? In pharo 1.1.1, we have CompiledMethod>>primitive that basically return: 0 if the method is not a primitive method >0 otherwise But if you execute this on i.e. Number>>isNumber or Morph>>#model compiled methods you get that these two are primitive methods. Are they primitive methods? Other (related) question is: When I executed the expression: SystemNavigation default allPrimitiveMethods , I get a OrderedCollection with 5581 elements. Are all those methods, primitive methods? Thanks in advance

3 5

[Pharo-project] a useful check
by Eliot Miranda Oct. 22, 2010

Oct. 22, 2010

Hi All, I just stumbled across a bug of mine which is a rare but easy-to-make slip, that of an unused block, e.g. expr ifTrue: [[something that doesn't get done]]. Here's a check for it (I'll check it in as a SysdtemNavigation method and perhaps the RB includes it in its lint tests). There's one method in Squeak trunk that falls foul of this. "Scan for the byte following each block creation being the pop bytecode." 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]]]

1 0

[Pharo-project] Latest OB, category autocompletion does always a lowercase
by Mariano Martinez Peck Oct. 22, 2010

Oct. 22, 2010

Hi. In the latest OB code, when I put "add category" to a method, and I start to type...it automatically finds several categories, but it always put lowercase to the name. For example, I have Package called *MyApp and I want to create a method category for that....when I type, the option showed is *myapp Would be great if this is case sensitive. Cheers Mariano

3 5

[Pharo-project] Explicit ordering of submorphs
by Fernando olivero Oct. 22, 2010

Oct. 22, 2010

Currently, the submorph order isn't explicit. Which means that adding several submorphs in a certain order, is no guarantee that they will appear in the desired order when laid out using a LayoutPolicy. Because the #morphicLayoutNumber is used. I've propose the following: 1. Add Morph>>precedence 2. Add Morph>>orderedSubmorphs 3. Modify the existing LayoutPolicies to use orderedSubmorphs instead of submorphsDo: ISSUE 3136.

1 2

[Pharo-project] Latest OB code, running single test erases the colors of the rest
by Mariano Martinez Peck Oct. 22, 2010

Oct. 22, 2010

Hi. I I have a TestCase, and with cmd + t, I run a particular test method, all the little small bolls from the other test methods are lost and initialized again with gray :( they would be maintained. thanks mariano

1 0