- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo by example

by Schwab,Wilhelm K

Stef, My printed copy arrived today. It looks like a really good book. There are some headings that have missing letters, for example, see pg. 27 ("A rst application") pg. 215 (section 10.4, "Using streams for le access"); the 10-07 pdf looks ok, so this could be a Lulu mistake. I reserve the right to retract this as I continue reading, but the dropped letters all appear to be from (sub)section names, and so far, they do *not* look like areas that were "low on ink." The adjacent text looks crisp; it simply looks as though the letters were somehow dropped from the titles. One small suggestion/request for future prined copies would be to make the pages a little wider and move the text outward slightly. As it is, it sometimes gets a little tight into the spine. Nice job - thanks to all involve for writing it! Bill

Oct. 15, 2009

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

by csrabak＠bol.com.br

Em 14/10/2009 20:59, Martin McClure <martin(a)hand2mouse.com> escreveu: > csrabak(a)bol.com.br wrote: > > Em 14/10/2009 17:11, Alexandre Bergel escreveu: > > > >>> In Squeak 3.10 TestCase >> assert: aBooleanOrBlock Squeak > >>> 3.8, Dolphin and VAST (I don't know others) have: TestCase > >>>>> assert: aBoolean So...is there a reason of doing that? Is > >>> this expected? > >> I do not see any particular reason. But having > >> Object>>assert: aBlock is important, since one can simply > >> redefine assert: in a class to supress all assertions. > > Which begs the question: then why the same method is > > re-implemented in TestCase anyway? > > ...just thinking 'aloud'... > > TestCase>>assert:, by convention, accepts a Boolean, and could > be extended to also accept a block (and apparently has been so > extended in Squeak). I see. I _think_ the idea of having it more 'compatible' with other dialects changing it back to accept a Boolean and keeping TestCase>>should: aBlock is a better way. > > Object>>assert: *should* accept a block, and it isn't really > useful for it to accept a Boolean. I was keeping with your and Alexandre's reasoning, but when I look for HierarchyImplementors of #assert: starting from Object the only one I get (in a Pharo1.0beta dev image updated to 10470) are: Object>>assert: {error handling} TestCase>>assert: {accessing} So in Pharo we brought a functionality very up in the hierarchy. > As Alexandre says, you can suppress assertions by redefining > #assert:. One could also make Object>>assert: depend on some > variable somewhere to determine whether to actually run the > assertion blocks. Then you can turn assertions on and off > system-wide, and not be running that assertion code in the > blocks all the time. If you accepted a boolean, you'd be running > the assertion expression whether assertions were turned on or > not, which is undesirable. > > It's not too nice if Object>>assert: and TestCase>>assert: take > different kinds of arguments > > TestCase>>assert: takes a Boolean. I suspect that's too widely > used to change. I agrre as I wrote above, for blocks we have TestCase>>should:. > I don't know how widely used Object>>assert: is. Perhaps we > could have a different selector for that which takes a > block. 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? > Maybe a selector that implies more strongly that its > argument should be a block. I think TestCase>>should: suffices for that. > Our test framework (which I believe > predates SUnit) uses #run:forResult:, with a block for the first > argument and the expected result of evaluating the block as the > second argument. I like this for a couple of reasons -- run: > strongly implies that it should take a block argument, and > giving the expected result separately allows failure messages of > the form "Expected ; got " which is handy anytime but *really* > useful when failures are not easily reproducible. Yes, I see, but I think this is lateral to this discussion! > > Regards, > > -Martin > > > P.S. -- the following is marginally related: > > In performance-critical code that is executed *very* frequently, > even making a message send and checking whether assertions are > turned on or not can have too much impact. In those situations, > I banish all assertions to a subclass, which has methods of this > general form: > > someMethod | result | self assert: [assertions appropriate on > entry to this method]. result := super someMethod. self > assert: [assertions appropriate on exit from this method]. > ^result. > > Then to turn assertions on or off, I have code that can change > the class of the instances, and switch whether new instances are > of the no-assertions class or the with-assertions subclass. > > This allows the application to run at full speed when assertions > are turned off, a real advantage in some cases. This also > separates the normal code from the assertion code, which has > both advantages and disadvantages. > I really don't follow this, are you using assertions for checking invariants a la Eiffel?

Oct. 15, 2009

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

by csrabak＠bol.com.br

Em 14/10/2009 17:06, Mariano Martinez Peck <marianopeck(a)gmail.com> escreveu: > Hi folks:During this week someone wanted to use SqueakDBX in > Squeak 3.8 and at the same time another person (thanks Marcelo > Cortez!!!) has ported it to Dolphin. And I found something weird in > TestCase >> assert: > > In Squeak 3.10 TestCase >> assert: aBooleanOrBlock > > Squeak 3.8, Dolphin and VAST (I don't know others) have: > > TestCase >> assert: aBoolean > > So...is there a reason of doing that? Is this expected? > FWIW in VW it's also TestCase>>assert: aBoolean, and there is not an Object>>assert: method there.

Oct. 15, 2009

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

by Martin McClure

csrabak(a)bol.com.br wrote: > Em 14/10/2009 17:11, Alexandre Bergel <alexandre(a)bergel.eu> escreveu: > >>> In Squeak 3.10 TestCase >> assert: aBooleanOrBlock >>> Squeak 3.8, Dolphin and VAST (I don't know others) have: TestCase >>>>> assert: aBoolean >>> So...is there a reason of doing that? Is this expected? >> I do not see any particular reason. But having Object>>assert: >> aBlock is important, since one can simply redefine assert: in a >> class to supress all assertions. > > Which begs the question: then why the same method is re-implemented in TestCase anyway? ...just thinking 'aloud'... TestCase>>assert:, by convention, accepts a Boolean, and could be extended to also accept a block (and apparently has been so extended in Squeak). Object>>assert: *should* accept a block, and it isn't really useful for it to accept a Boolean. As Alexandre says, you can suppress assertions by redefining #assert:. One could also make Object>>assert: depend on some variable somewhere to determine whether to actually run the assertion blocks. Then you can turn assertions on and off system-wide, and not be running that assertion code in the blocks all the time. If you accepted a boolean, you'd be running the assertion expression whether assertions were turned on or not, which is undesirable. It's not too nice if Object>>assert: and TestCase>>assert: take different kinds of arguments TestCase>>assert: takes a Boolean. I suspect that's too widely used to change. I don't know how widely used Object>>assert: is. Perhaps we could have a different selector for that which takes a block. Maybe a selector that implies more strongly that its argument should be a block. Our test framework (which I believe predates SUnit) uses #run:forResult:, with a block for the first argument and the expected result of evaluating the block as the second argument. I like this for a couple of reasons -- run: strongly implies that it should take a block argument, and giving the expected result separately allows failure messages of the form "Expected <a>; got <b>" which is handy anytime but *really* useful when failures are not easily reproducible. Regards, -Martin P.S. -- the following is marginally related: In performance-critical code that is executed *very* frequently, even making a message send and checking whether assertions are turned on or not can have too much impact. In those situations, I banish all assertions to a subclass, which has methods of this general form: someMethod | result | self assert: [assertions appropriate on entry to this method]. result := super someMethod. self assert: [assertions appropriate on exit from this method]. ^result. Then to turn assertions on or off, I have code that can change the class of the instances, and switch whether new instances are of the no-assertions class or the with-assertions subclass. This allows the application to run at full speed when assertions are turned off, a real advantage in some cases. This also separates the normal code from the assertion code, which has both advantages and disadvantages.

Oct. 14, 2009

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

by csrabak＠bol.com.br

Em 14/10/2009 17:11, Alexandre Bergel <alexandre(a)bergel.eu> escreveu: > > > In Squeak 3.10 TestCase >> assert: aBooleanOrBlock > > Squeak 3.8, Dolphin and VAST (I don't know others) have: TestCase > > >> assert: aBoolean > > So...is there a reason of doing that? Is this expected? > > I do not see any particular reason. But having Object>>assert: > aBlock is important, since one can simply redefine assert: in a > class to supress all assertions. Which begs the question: then why the same method is re-implemented in TestCase anyway?

Oct. 14, 2009

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

by Michael Roberts

Early sunit i believe had self should: [1 = 2] vs self assert: 1 = 2. Perhaps as Alex says the api has moved... cheers, Mike

Oct. 14, 2009

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

by Nicolas Cellier

This is a facility... If you want to be portable, don't use it. Maybe (self should: aBlock) is portable if you really want a block... Nicolas 2009/10/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi folks:During this week someone wanted to use SqueakDBX in Squeak 3.8 and > at the same time another person (thanks Marcelo Cortez!!!) has ported it to > Dolphin. And I found something weird in TestCase >> assert: > > In Squeak 3.10Â TestCase >> assert: aBooleanOrBlock > > Squeak 3.8, Dolphin and VAST (I don't know others) have: > > TestCase >> assert: aBoolean > > So...is there a reason of doing that? Is this expected? > > cheers > > mariano > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2009

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

by Alexandre Bergel

> In Squeak 3.10 TestCase >> assert: aBooleanOrBlock > > Squeak 3.8, Dolphin and VAST (I don't know others) have: > TestCase >> assert: aBoolean > > So...is there a reason of doing that? Is this expected? I do not see any particular reason. But having Object>>assert: aBlock is important, since one can simply redefine assert: in a class to supress all assertions. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 14, 2009

[Pharo-project] About TestCase >> assert:

by Mariano Martinez Peck

Hi folks:During this week someone wanted to use SqueakDBX in Squeak 3.8 and at the same time another person (thanks Marcelo Cortez!!!) has ported it to Dolphin. And I found something weird in TestCase >> assert: In Squeak 3.10 TestCase >> assert: aBooleanOrBlock Squeak 3.8, Dolphin and VAST (I don't know others) have: TestCase >> assert: aBoolean So...is there a reason of doing that? Is this expected? cheers mariano

Oct. 14, 2009

Re: [Pharo-project] Deleting morphs from the yellow button menu

by CÃ©drick BÃ©ler

http://code.google.com/p/pharo/issues/detail?id=1305 2009/10/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > yes :) > > On Oct 14, 2009, at 3:17 PM, CÃ©drick BÃ©ler wrote: > > > Is it useful ? Do I open a ticket for that ? > > > > Cheers > > > > 2009/10/14 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> > > Hi, > > > > With the attached changed set, it's now possible to delete morph > > from the right click menu (see the pic). > > > > > > ps: I also renamed 'selection' to 'halo on' (and halo off). Not sure > > this is a good choice. > > > > hth, > > > > -- > > CÃ©drick > > > > > > > > -- > > CÃ©drick > > _______________________________________________ > > 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 > -- CÃ©drick

Oct. 14, 2009