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

[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

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

Oct. 23, 2010

skype stducasse, we chat there. Stef

1 0

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