- Pharo-dev - lists.pharo.org

[Pharo-project] Google code / test running

by Torsten Bergmann

Havent tried it but there is a SqueakSVN project to get access to SVN: http://map.squeak.org/package/184ebabe-a32c-403f-8088-ff85233cabca/autovers… Read more here: http://news.squeak.org/2008/09/16/subversion-integration-for-squeak/ Bye Torsten -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02

Oct. 15, 2009

[Pharo-project] Google code / test running

by Michael Roberts

I have uploaded a GoogleCode package to PharoTaskForces. It is an improvement on the baseline test scripts. To get going have a look at PharoTestScript and modify some of the constants. If you want to participate running tests you need to first checkout the wiki using svn. You can see how that is done in the code or just follow google's help page. You need your profile password to do commits. I have a minimal svn wrapper which is intended to be hooked up to e.g OSProcess but that is just scaffolding until i can test it. The operation is basically runs all the tests, write out a wiki page, and add & commit to the wiki. There is more to do, but it is better than the original changeset. cheers, Mike

Oct. 15, 2009

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

by Alexandre Bergel

> Agreed. I prefer, though, to use BlockClosure>>assert, so usage > becomes > something like: > > [2 + 2 = 5] assert. > > I see that this is already implemented, based on Object>>assert: I agree this is more concise, there is no reference to "self" to formulate the assertion. Having to use "self" in "self assert:" has more to do with an unnecessary convention than bringing a real value. In that case, disabling assertion has to be done by modifying BlockClosure>>assert. > 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. > > * 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. The method assert:equals: should accept a block in my opinion. TestCase>>assert:equals: may be rewritten as: assert: expectedAsBlockOrValue equals: actualAsBlockOrValue | v1 v2 | v1 := expectedAsBlockOrValue value. v2 := actualAsBlockOrValue value. ^ self assert: (v1 = v2) description: (self comparingStringBetween: v1 and: v2) > * Object assert: accepts a boolean or a block. I don't know of any > standard for this. No standard as far as I know > * BlockClosure>>assert does not take any arguments, so I feel it is > very > clean. But you need to modify it to cancel runtime checks > 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:. assert:equals: could also be updated. Some test units in the image use [] as arguments to assert: and deny:. StringTest is one of them. > Object>>assert: should be removed/deprecated in favor of > BlockClosure>>assert. This removes confusion with TestCase>>assert:. Ideally, this is valuable. However, there is a number of tests that use Object>>assert: (and not only my code :-). ZipEncoderTree is an example > 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. #assertWithDescription: is useful yes. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 15, 2009

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

by Martin McClure

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

Oct. 15, 2009

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

by Martin McClure

Alexandre Bergel wrote: >> 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: > [...] > > This is exactly what I had in mind > I regularly use assert: to describe invariant, pre and postcondition. > This complement testing pretty well in my opinion. Agreed. I prefer, though, to use BlockClosure>>assert, so usage becomes something like: [2 + 2 = 5] assert. I see that this is already implemented, based on Object>>assert: 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. * 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. * Object assert: accepts a boolean or a block. I don't know of any standard for this. * BlockClosure>>assert does not take any arguments, so I feel it is very clean. 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:. Object>>assert: should be removed/deprecated in favor of BlockClosure>>assert. This removes confusion with TestCase>>assert:. 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. Opinions? -Martin

Oct. 15, 2009

Re: [Pharo-project] Sprint information

by Tudor Girba

I will also see to arrive early :) My phone is: +41 76 579 0423 Cheers, Doru On 15 Oct 2009, at 15:01, Oscar Nierstrasz wrote: > > I plan to arrive early. +41 78 628 0817 > > - on > > On 15 Oct 2009, at 09:18, StÃ©phane Ducasse wrote: > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

Oct. 15, 2009

[Pharo-project] [update] #10471

by StÃ©phane Ducasse

10471 ----- - Issue 1309: Date and time speedup creation from squeaktrunk - Issue 1233: Needs changes after fix 1129 Stef

Oct. 15, 2009

Re: [Pharo-project] New items in Pharo Core merger

by Gary Chambers

Means digging into/modifying MC itself I fear... >From what I've investigated, the MCMergeResolutionRequest mechanism only handles changes to the state or what is to be merged when conflicting (within same package)... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, October 15, 2009 2:37 PM Subject: Re: [Pharo-project] New items in Pharo Core merger >I think that we should really improve the merge tool to help us > so any step in that direction is welcomed. > > Stef > > On Oct 15, 2009, at 12:52 PM, Henrik Johansen wrote: > >> Would it be possible to enable "Keep current version" (ie, don't >> install >> the version from the thing being merged) to the menu list for New >> items >> in the Monticello merger? >> It's kind of hard to f.ex. merge Squeak-trunk Collections, containing >> Base64MimeConverter, when in Pharo, that Class exists in a different >> package. >> At least as far as I can tell (haven't actually done it, as I don't >> feel >> like resolving the 260 other conflicts just to find out), applying the >> merge will result in move the class. >> Alternatively to check if the item already exists in the system, but >> in >> a different package, and mark that as a conflict. >> >> Cheers, >> Henry >> >> _______________________________________________ >> 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

Oct. 15, 2009

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

by Alexandre Bergel

>>> 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: [...] This is exactly what I had in mind I regularly use assert: to describe invariant, pre and postcondition. This complement testing pretty well in my opinion. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 15, 2009

Re: [Pharo-project] New items in Pharo Core merger

by StÃ©phane Ducasse

I think that we should really improve the merge tool to help us so any step in that direction is welcomed. Stef On Oct 15, 2009, at 12:52 PM, Henrik Johansen wrote: > Would it be possible to enable "Keep current version" (ie, don't > install > the version from the thing being merged) to the menu list for New > items > in the Monticello merger? > It's kind of hard to f.ex. merge Squeak-trunk Collections, containing > Base64MimeConverter, when in Pharo, that Class exists in a different > package. > At least as far as I can tell (haven't actually done it, as I don't > feel > like resolving the 260 other conflicts just to find out), applying the > merge will result in move the class. > Alternatively to check if the item already exists in the system, but > in > a different package, and mark that as a conflict. > > Cheers, > Henry > > _______________________________________________ > 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