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

[Pharo-project] Sprint information

by StÃ©phane Ducasse

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

Oct. 15, 2009

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

by Martin McClure

csrabak(a)bol.com.br wrote: >> 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. Agreed. [...] >> 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? Ah, sorry for the confusion. What I'm talking about here (and I assumed Alexandre was as well, but I could be mistaken) is indeed the use of #assert: or some other message to test runtime invariants. So you'd put something like: self assert: [startIndex < endIndex]. somewhere in the main code of your application, not in test code. The nice thing about using blocks is that the assertion code inside the block doesn't run if global assertions are turned off, or if (as Alexandre suggests) you temporarily override #assert: in your class to do nothing. It's this rather separate use that I was suggesting might want a different selector, and gave #run:forResult: as one possible example. Regards, -Martin

Oct. 15, 2009

[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