- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Give http://ss3.gemstone.com/ss/MetaRepoForPharo20 some love !

by stephane ducasse

I committed Merlin. I played with it and it is a good wizard builder we should use it more often. Stef On Feb 6, 2013, at 6:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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: > > <Screen Shot 2013-02-06 at 18.43.00.png> > > 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 >

Feb. 10, 2013

Re: [Pharo-project] Empty top level class category

by Sean P. DeNigris

(RPackageSet named: 'Spec-Tools') systemCategories includes: #'Spec-Tools'. false before 20526, true thereafter -- View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050p4669082.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 10, 2013

Re: [Pharo-project] Empty top level class category

by stephane ducasse

do you have a reproducible case? Stef On Feb 10, 2013, at 9:50 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > From the issue... > > This doesn't look right to me... > Item was changed: > ----- Method: RPackageSet>>systemCategories (in category 'system > compatibility') -----systemCategories > + ^systemCategories ifNil: [ systemCategories := (self packages collect: > #packageName) asSet asArray].! > - ^systemCategories ifNil: [ systemCategories := (self > collectFromAllPackages: #systemCategories) asSet asArray].! > > system categories ~= packages. RPackage has a 'Spec-Tools' package, even > though there is no such system category. > > > > -- > View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050p4669078.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 10, 2013

Re: [Pharo-project] Empty top level class category

by Sean P. DeNigris

>From the issue... This doesn't look right to me... Item was changed: ----- Method: RPackageSet>>systemCategories (in category 'system compatibility') -----systemCategories + ^systemCategories ifNil: [ systemCategories := (self packages collect: #packageName) asSet asArray].! - ^systemCategories ifNil: [ systemCategories := (self collectFromAllPackages: #systemCategories) asSet asArray].! system categories ~= packages. RPackage has a 'Spec-Tools' package, even though there is no such system category. -- View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050p4669078.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 10, 2013

Re: [Pharo-project] Phexample should methods

by Sean P. DeNigris

This is great. I love the matchers in Phexample (although I'm not sold on the test dependency part. I think dependent tests should be skipped, not failed... yet I digress...) Stefan Marr-3 wrote > Note that it is #includesSubString, in contrast to #beginsWith:. > Is that on purpose? This means that should can't appear in any non-test selector in a test class. As cool as #barShouldBeSomething looks, I don't think it's worth the confusion. And as you alluded to, it might encourage poor test design Stefan Marr-3 wrote > PS: It is also inconsistent with Phexample's own #isTest: implementation, > which uses #beginsWith: There should be one place in the image that defines what a test is. I'm guessing it would be packaged with SUnit, then Nautilus, Phexample, etc can refer to or alter it and get the change everywhere. HTH, Sean -- View this message in context: http://forum.world.st/Phexample-should-methods-tp4669070p4669077.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 10, 2013

Re: [Pharo-project] Phexample should methods

by stephane ducasse

On Feb 10, 2013, at 9:39 PM, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > 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? I have no idea. I was confused by the fact that should beTrue returns nil and other. And I was trapped with the interaction with Job progress. > 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 > >

Feb. 10, 2013

Re: [Pharo-project] Empty top level class category

by stephane ducasse

This bug is a vicious one and today I saw it again when I wanted to load the version of stefan of phexample on top of the version of squeaksource. It will keep us busyâ¦.. argh Stef > Issue 7478: [BUG]: Empty top level class category creation > > Tracked it down to starting with the following update... > 20526 > ----- > > Issue 7284 : Cannot run gofer load twice => Error: cannot remove non empty > category > http://code.google.com/p/pharo/issues/detail?can=2&q=7284 > > (part 1) > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-EstebanLorenzano.209.diff > > > > -- > View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050p4669067.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 10, 2013

[Pharo-project] Phexample should methods

by Stefan Marr

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

Feb. 10, 2013

Re: [Pharo-project] Empty top level class category

by Sean P. DeNigris

Issue 7478: [BUG]: Empty top level class category creation Tracked it down to starting with the following update... 20526 ----- Issue 7284 : Cannot run gofer load twice => Error: cannot remove non empty category http://code.google.com/p/pharo/issues/detail?can=2&q=7284 (part 1) Diff information: http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-EstebanLorenzano.209.diff -- View this message in context: http://forum.world.st/Empty-top-level-class-category-tp4669050p4669067.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 10, 2013

Re: [Pharo-project] About common semantics :)

by stephane ducasse

Dale I have another question what is the interaction between saying that a given version is stable using a symbolic version and having the development tag in the version? For example I'm migrating merlin and I have stable: spec <symbolicVersion: #'stable'> spec for: #'common' version: '1.5'. development: spec <symbolicVersion: #'development'> spec for: #'common' version: '1.7'. version15: spec <version: '1.5' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'development'. spec description: '1.4 : Replaced PluggableListMorphOfMany by PluggableListMorph'. spec author: 'AlexandreBergel'. spec timestamp: '9/30/2011 09:52'. spec package: 'Merlin' with: 'Merlin-AlexandreBergel.137'. ]. version17: spec <version: '1.7' imports: #('1.0-baseline' )> spec for: #'common' do: [ spec blessing: #'development'. spec description: '1.6 : Removed dependency from BlockContext. Merged with last version'. spec author: 'AlexandreBergel'. spec timestamp: '11/21/2012 08:42'. spec package: 'Merlin' with: 'Merlin-AlexandreBergel.141'. ]. so when do we tag a version as release? because apparently without doing it it still works. Stef

Feb. 10, 2013