- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Sprint information

by StÃ©phane Ducasse

Tell them a lot of great hellos from us :) > http://atnd.org/events/1593 and that pharo needs them :) Stef

Oct. 16, 2009

Re: [Pharo-project] About TestCase >> assert:

by StÃ©phane Ducasse

> There are inconsistencies that bother me. > > * TestCase>>assert: in most Smalltalks accepts only a boolean. In > Pharo, > it accepts either a boolean or a block. This makes tests less > portable. +1 > * TestCase>>assert:equals: (a very useful method) does not accept a > block. Anyone used to giving blocks to #assert: would probably expect > this method to accept a block. +1 consistency is nice. > * Object assert: accepts a boolean or a block. I don't know of any > standard for this. me neither > * BlockClosure>>assert does not take any arguments, so I feel it is > very > clean. +1 > Proposed changes: (based on earlier discussion plus personal opinion) > > TestCase>>assert: should only accept a boolean. This brings > compatibility with other Smalltalks, and consistency with > TestCase>>assert:equals:. + 1 > Object>>assert: should be removed/deprecated in favor of > BlockClosure>>assert. This removes confusion with TestCase>>assert:. deprecation! > Object>>assert:description: and Object>>assert:descriptionBlock: > should > be removed/deprecated in favor of (new) > BlockClosure>>assertWithDescription:, which accepts either a block > or a > string. This provides convenient invariant and pre/post condition > testing. Let us do that. Any taker? Stef > > > Opinions? > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 16, 2009

Re: [Pharo-project] About TestCase >> assert:

by StÃ©phane Ducasse

Hi martin I agree should: is not that communicating. I would favor [] assert [] assertWithDescription: 'funky preconditions' Stef On Oct 15, 2009, at 8:35 PM, Martin McClure wrote: > Henrik Johansen wrote: >> Why not rename Object>>assert: to should:, so it avoids breaking >> polymorphism, and keep TestCase>>assert: reserved for a boolean >> argument >> to stay compatible with SUnit in other dialects? >> >> On the negative side, it might not be as intuitive using should: for >> pre/post-assertions, as well as inconvenient to remember the >> difference >> between assert: and should: in TestCases. Not big enough negatives to >> outweigh the benefits though, imo. >> > > Henry, > > Sorry, I hadn't read this mail before making a proposal. > > I agree that renaming Object>>assert: to #should: would be an > improvement. But I still think it's probably better to remove it > altogether and send #assert to a block. It may just be me, but I've > always felt that as a selector 'should' doesn't really communicate the > intent as well as 'assert'. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 16, 2009

Re: [Pharo-project] About TestCase >> assert:

by StÃ©phane Ducasse

Yes and this is really important because pre and post are valuable for software engineering quality promotion. Stef On Oct 16, 2009, at 1:55 AM, csrabak(a)bol.com.br wrote: > Em 15/10/2009 04:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > escreveu: > > I see. Eiffel ideas cross breeding Pharo Smalltalk! > >> >> The idea is that one day or later we will have to think about >> the benefit of pre and post condition. So assert: in object >> makes a lot of sense. >> >> Now indeed it would be good that all the tests use assert: >> without block and use should: for that case. >> >> Stef On Oct 15, 2009, at 3:55 AM, csrabak(a)bol.com.br wrote: >> >>> I don't either, but I find strange the complete hierarchy of >>> classes of Pharo having a method assert: available. Perhaps >>> I'm blindfolded and Pharo and Squeak have found a wider use >>> for assertions? >> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 16, 2009

Re: [Pharo-project] Google code / test running

by Michael Roberts

sounds good i will check it out Mike On Thu, Oct 15, 2009 at 11:18 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > The SqueakSVN pages moved to: > http://www.hpi.uni-potsdam.de/hirschfeld/projects/ssvn/index.html > > Maybe it is of use to automate the SVN tasks ... > > Bye > T. > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2009

Re: [Pharo-project] Sprint information

by Serge Stinckwich

I could not attend unfortunately. Enjoy the Pharo sprint ! I will present the Pharo project to the Nagoya Smalltalkers meeting in december : http://atnd.org/events/1593 Best regards, 2009/10/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > Here are some information about the sprint. > > The place is located at LIFL in a room close to our office. > Â Â Â Â http://rmod.lille.inria.fr > Â Â Â Â check at the bottom of the page (pay attention our physical address > is not the same than our mail address. > Â Â Â Â We are NOT in the INRIA building. > > In short you should take the metro up to Cite Scientifique and walk > south until the round point and turn right after a moment > you should have a parking on your left and the building is doing a > kind of large L > > The entrance in the building is at the crossing of the L. > > Now the building will be closed on saturday and I can open the door. > I plan to be at the lab at 9h00. > > Now I do not have a mobile phone... so it would be good that we share > mobile numbers so that > we have a base for connecting us. > The idea is that we will write on a sheet of paper the mobile phone > number of the first one that will arrive. > > Stef > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Oct. 16, 2009

Re: [Pharo-project] About TestCase >> assert:

by Mariano Martinez Peck

I like the ability I have to generate big and interesting threads from a little question hahaha. On Thu, Oct 15, 2009 at 8:55 PM, <csrabak(a)bol.com.br> wrote: > Em 15/10/2009 04:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > escreveu: > > I see. Eiffel ideas cross breeding Pharo Smalltalk! > > > > > The idea is that one day or later we will have to think about > > the benefit of pre and post condition. So assert: in object > > makes a lot of sense. > > > > Now indeed it would be good that all the tests use assert: > > without block and use should: for that case. > > > > Stef On Oct 15, 2009, at 3:55 AM, csrabak(a)bol.com.br wrote: > > > > > I don't either, but I find strange the complete hierarchy of > > > classes of Pharo having a method assert: available. Perhaps > > > I'm blindfolded and Pharo and Squeak have found a wider use > > > for assertions? > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 16, 2009

Re: [Pharo-project] About TestCase >> assert:

by csrabak＠bol.com.br

Em 15/10/2009 04:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escreveu: I see. Eiffel ideas cross breeding Pharo Smalltalk! > > The idea is that one day or later we will have to think about > the benefit of pre and post condition. So assert: in object > makes a lot of sense. > > Now indeed it would be good that all the tests use assert: > without block and use should: for that case. > > Stef On Oct 15, 2009, at 3:55 AM, csrabak(a)bol.com.br wrote: > > > I don't either, but I find strange the complete hierarchy of > > classes of Pharo having a method assert: available. Perhaps > > I'm blindfolded and Pharo and Squeak have found a wider use > > for assertions? >

Oct. 15, 2009

Re: [Pharo-project] Polymorph observations

by Schwab,Wilhelm K

Gary, Thanks for the pointers. Your point on default models is well-taken, but nothing (not much anyway) prevents their being replaced when something such as an aspect value adaptor is indicated. Changing models on the fly has long been a weakness of Dolphin; Object Arts essentially said "do as we say, not as we do." I think we can find ways to make it all work as one would hope. At a minimum, there should be alternative factory selectors that do not require the selection aspects when those do nothing besides support the user interface (which I submit is probably more often than not). Details aside, Polymorph is very impressive work - thanks for making it available to us!! Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Thursday, October 15, 2009 5:43 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Polymorph observations Thanks Bill. The "Squeak" way allows double-click just inside the first quote to select the relevant snippet of course though ;-) Perhaps default models would be a good idea though it can, with over-reliance, tend to distance things from the real model... Nothing in TEasilyThemed for splitters. Note that Polymorph only fixes issues with SystemWindow splitter usage at present, rather than arbitrary owner morphs. Given a system window: win addPaneVSplitterBetween: morph1 and: {morph2}. main splitters last color: win paneColor. Given other morphs (for the moment). aMorph addPaneVSplitterBetween: morph1 and: {morph2}. aMorph splitters last color: aMorph paneColor; addLeftOrTop: morph1; addRightOrBottom: morph2. Regards, Gary ----- Original Message ----- From: Schwab,Wilhelm K<mailto:bschwab@anest.ufl.edu> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, October 13, 2009 2:10 AM Subject: [Pharo-project] Polymorph observations Gary, I have done a little with Polymorph and am quite impressed. A small usability suggestion for the examples is to include comments with the text on a line by itself. It is a lot easier to execute something formatted as " ThisOrThat example ThisOrThat someOtherExample " than it is the (very common in Squeak) "GoAhead iChallengeYouToSelectMe andMissTheQuotes". On to more substantive things. TEasilyThemed is a big help, but some model and/or presenter classes would help. Consider a list. One has to define an aspect for the selection index and initialize it to zero. Similar comments apply to trees, with the added wrinkle of wrapping the nodes with appropriate objects. Dolphin's MVP framework creates default models that can be replaced. One weakness of the defaults is that they can take significant time to create for substantial objects. I hacked around that, and we could easily design it out of anything that we build. Dolphin lists and trees treat their selection in terms of the object selected rather than the index. One can get and set the index if needed, but it is not generally as interesting as the object behind the selection. One good thing about specifying the aspect is that one can can connect a view to an aspect of any model. Dolphin allows for the same flexibility via value adapters and type converters. Does TEasilyThemed include helpers for creating splitters? Bill ________________________________ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2009

[Pharo-project] Google code / test running

by Torsten Bergmann

The SqueakSVN pages moved to: http://www.hpi.uni-potsdam.de/hirschfeld/projects/ssvn/index.html Maybe it is of use to automate the SVN tasks ... Bye T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Oct. 15, 2009