February 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20533
by Marcus Denker Feb. 11, 2013

Feb. 11, 2013

20533 ----- Issue 7476: eval command line handler uses cr instead of lf http://code.google.com/p/pharo/issues/detail?id=7476 Issue 7474: Make ReleaseTest error messages more readable http://code.google.com/p/pharo/issues/detail?id=7474 Issue 7472: Improve CommandLine TestRunner stability http://code.google.com/p/pharo/issues/detail?id=7472 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.504.diff http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.79.diff http://ss3.gemstone.com/ss/Pharo20/SUnit-UI-MarcusDenker.60.diff

1 0

[Pharo-project] Empty top level class category
by Sean P. DeNigris Feb. 10, 2013

Feb. 10, 2013

If you load slice 6657 "[ENH] Spec Request : make nextFocus / previousFocus Keymapping-based", there will be an extra, empty Spec-Tools category created, causing Spec-Tools to be marked dirty in the MC Browser. -- View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 9

[Pharo-project] Give http://ss3.gemstone.com/ss/MetaRepoForPharo20 some love !
by Sven Van Caekenberghe Feb. 10, 2013

Feb. 10, 2013

With 2.0 almost ready, it would be great if everybody gave http://ss3.gemstone.com/ss/MetaRepoForPharo20 some love. Currently, the Configuration Browser looks like this: I am missing many, many, well know, useful packages right there. So if you have some generally useful package you maintain and that you know loads and works well with Pharo 2.0 (and that you are willing to maintain), please copy its Metacello Configuration in http://ss3.gemstone.com/ss/MetaRepoForPharo20 ! That is really all there is to it. You will make life for others so much easier, and improve exposure for the software you wrote. Let's make one-click installs real. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

3 3

[Pharo-project] Phexample should methods
by Stefan Marr Feb. 10, 2013

Feb. 10, 2013

While wondering how to simply support Pharo 1.4 and Pharo 2.0 at the same time, I noticed something I didn't think about before. Phexample does use the following code to identify what a test method is: each numArgs isZero and: [ (each asLowercase includesSubString: 'should') Note that it is #includesSubString, in contrast to #beginsWith:. Is that on purpose? Is this feature supposed to be used? That gives rise to example-driven testing ala: Foo >> #barShouldBeSomething So far, I tried to avoid that, and make examples that are really focused on one specific subject, which is represented by the class name. Any opinions on that? Best regards Stefan PS: It is also inconsistent with Phexample's own #isTest: implementation, which uses #beginsWith: -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

3 2

[Pharo-project] About common semantics :)
by stephane ducasse Feb. 10, 2013

Feb. 10, 2013

Dale working on phexample (which worked well on 2.0) I changed stable: spec <symbolicVersion: #stable> spec for: #'common' version: '1.0'. into stable: spec <symbolicVersion: #stable> spec for: #'pharo1.4.x' version: '1.1'. spec for: #'pharo2.x' version: '1.0'. because I could not get the version running in 1.4 (deprecated method usage). version11: spec <version: '1.1' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 1.4'. spec author: 'StephaneDucasse'. spec timestamp: '2/10/2013 17:46'. spec package: 'Phexample' with: 'Phexample-StephaneDucasse.68'. ]. version10: spec <version: '1.0' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 2.0'. spec author: 'StefanMarr'. spec timestamp: '2/8/2013 11:46'. spec package: 'Phexample' with: 'Phexample-StefanMarr.67'. ]. Now the semantics of common in symbolic version versus in version is not clear to me. Should I transform version10: spec <version: '1.0' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 2.0'. spec author: 'StefanMarr'. spec timestamp: '2/8/2013 11:46'. spec package: 'Phexample' with: 'Phexample-StefanMarr.67'. ]. into version10: spec <version: '1.0' imports: #('1.0-baseline' )> spec for: #'pharo2.x' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 2.0'. spec author: 'StefanMarr'. spec timestamp: '2/8/2013 11:46'. spec package: 'Phexample' with: 'Phexample-StefanMarr.67'. ]. and version11: spec <version: '1.1' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 1.4'. spec author: 'StephaneDucasse'. spec timestamp: '2/10/2013 17:46'. spec package: 'Phexample' with: 'Phexample-StephaneDucasse.68'. ]. into version11: spec <version: '1.1' imports: #('1.0-baseline' )> spec for: #'pharo1.4.x' do: [ spec blessing: #'release'. spec description: 'initial version working well for Pharo 1.4'. spec author: 'StephaneDucasse'. spec timestamp: '2/10/2013 17:46'. spec package: 'Phexample' with: 'Phexample-StephaneDucasse.68'. ]. Thanks Stef

3 3

[Pharo-project] Fwd: I will customize phexample to work on both 1.4 and 2.0
by Stefan Marr Feb. 10, 2013

Feb. 10, 2013

Hi Stef: Begin forwarded message: > because now it only works on 2.0 > So I will use symbolic versions for real. > I think that you are working on 2.0. > On 1.4 I get DNU due to substrings... What's the best way to handle such trivial difference between different versions, or even dialects? So, the problem is basically #includesSubString: vs. #includesSubstring:, used by a single method. Creating a version specific package just for that methods seems to be exaggerated. However, you committed now Phexample-StephaneDucasse.68 that is based on Phexample-StefanMarr.67. I think, in general that will lead to mighty confusion because it is not a general fix, but Pharo 1.4 specific. The latest version now breaks on Pharo 2.0 again (with a deprecation...) Wouldn't it have been better to properly branch off this change and commit it to Phexample.Pharo1.4-StephaneDucasse.68 for instance? Any other good approach to handle such small differences in a scalable way would also be interesting... Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

4 3

[Pharo-project] INI file in 2.0 one-click and Win-Executable
by Torsten Bergmann Feb. 10, 2013

Feb. 10, 2013

The new one-click on the CI server contains an *.ini file. But it is named CogVM.ini and since the VM is called NBCog.exe it's useless. Maybe this is already taken care of since I've seen a thread about the naming of the VM. IMHO we should have: - Pharo.exe - Pharo.ini and a resource section within the executable that contains the details about the VM type (Cog, NB, ...), the distributor and (file) version. We already discussed this in 2011 (!) here: http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/49287 and it is a shame that we made no progress for such simple enhancements. Thanks Torsten

3 2

Feb. 10, 2013

This is strange I was running the tests of the fame project MCHttpRepository location: 'http://www.smalltalkhub.com/mc/Moose/Fame/main' user: 'StephaneDucasse' password: '' when I run the tests they get red and I get a lot of zeroDivide errorâ¦. something related to the progress bar because I get a division by zero When I edit the code so that the division is never 0 just adding + 1 as in the method progress ^ (currentValue - min) / ((max - min) + 1) the tests get green. I'm puzzled. Stef

1 0

[Pharo-project] Pharo Regression Tests
by Camillo Bruni Feb. 10, 2013

Feb. 10, 2013

I think I got the regression tests working ;) https://ci.inria.fr/pharo/job/Pharo-2.0-Regression-Tests/ and it detected the first bug in the `eval` command line handler, which would output a cr instead of an lf ;)

1 0

Feb. 10, 2013

Hi guys I'm trying to debug some phexample tests. Now I do not get why the following expression printer stream contents isString should beTrue returns nil when printer stream contents isString is true. Stef

2 1