- Pharo-dev - lists.pharo.org

[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

[Pharo-project] strange behavior of tests
by StÃ©phane Ducasse Feb. 10, 2013

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

Feb. 10, 2013

Hi dale I'm migrating Moose and I got the following question. In terms of granularity of dependency when depending of project. Before we had Fame that depended directly on one package of phexample. baseline11: spec <version: '1.1-baseline'> spec for: #'common' do: [ spec blessing: #'baseline'. spec description: 'Baseline 1.1 first version on SmalltalkHub, copied from baseline 1.0 on SqueakSource'. spec repository: 'http://www.smalltalkhub.com/mc/Moose/Fame/main'. spec package: 'Fame-Core'; package: 'Fame-Util'; package: 'Fame-ImportExport' with: [spec requires: #('Fame-Core' ) ]; package: 'Fame-SmalltalkBinding' with: [spec requires: #('Fame-Core' ) ]; package: 'Fame-Example'; package: 'Phexample' with: [spec repository: 'http://www.squeaksource.com/phexample' ]; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ package: 'Fame-Tests-Core' with: [spec requires: #('Fame-Core' 'Fame-Example' 'Phexample' ) ]. spec group: 'Core' with: #('Fame-Core' 'Fame-ImportExport' 'Fame-Util' 'Fame-SmalltalkBinding' ); group: 'Tests' with: #('Fame-Tests-Core' ) ]. Stefan created a configuration for PhExample so the Fame baseline now depends on the Phexample project baseline12: spec <version: '1.2-baseline'> spec for: #'common' do: [ spec blessing: #'baseline'. spec description: 'Baseline 1.2 to make explicit that Fame depends on HashTable and Phexample (now on smalltalkHub and with working configurations'. spec repository: 'http://www.smalltalkhub.com/mc/Moose/Fame/main'. spec project: 'HashTable' with: [ spec className: 'ConfigurationOfHashTable'; versionString: #stable; repository: 'http://www.smalltalkhub.com/mc/Moose/HashTable/main' ]. spec project: 'Phexample' with: [ spec className: 'ConfigurationOfPhexample'; versionString: #stable; repository: 'http://www.smalltalkhub.com/mc/Phexample/main' ]. spec package: 'Fame-Core' with: [spec requires: 'HashTable']; package: 'Fame-Util'; package: 'Fame-ImportExport' with: [spec requires: #('Fame-Core' ) ]; package: 'Fame-SmalltalkBinding' with: [spec requires: #('Fame-Core' ) ]; package: 'Fame-Example'; package: 'Fame-Tests-Core' with: [spec requires: #('Fame-Core' 'Fame-Example') ]. spec group: 'Core' with: #('Fame-Core' 'Fame-ImportExport' 'Fame-Util' 'Fame-SmalltalkBinding' ); group: 'Tests' with: #('Fame-Tests-Core' ) ]. Now my question we got from package: 'Fame-Tests-Core' with: [spec requires: #('Fame-Core' 'Fame-Example' 'Phexample' ) ]. to a dependency between project and I was wondering if this is ok because may be a project is large and we only depend on a small part. Then doing so we are also losing the information that this is Fame-Tests-Core that introduces the dependency to PhExample and for large project such information can be important So is there a way to keep it? Stef

4 5