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

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

Re: [Pharo-project] I will customize phexample to work on both 1.4 and 2.0

by stephane ducasse

I have no idea. I'm sorry but I'm rather busy (in fact more than busy). I will not have the time to produce a version that works for other dialects. Now if this is a problem I will simply fork the project. We have to migrate Moose to 2.0 and this is not an easy task. We want to rewrite all the configurations and I have no time for the rest. As you know my goal is to make sure that people can make money with Smalltalk and we are working hard on that, we are building a company and I want it to succeed. So there is only that and Pharo in my radar. Stef > 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 > >

Feb. 10, 2013

Re: [Pharo-project] INI file in 2.0 one-click and Win-Executable

by Marcus Denker

On Feb 10, 2013, at 8:00 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. > Yes, we made the one click work the last working build of the VMs we could find, which was NBCog. We need to get the build working and get the VM from there. This will be Pharo.exe And for 3.0 we should have -> real installers for every platform -> They come with a read-only image as part of the install that is started when you start the VM form e.g. the start menu -> Save then saves the VM like a document to the users dir -> klicking on such an image starts it ->This image is one file, simplifying everything. Marcus

Feb. 10, 2013