- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 7534 LazyListMorph>>selectionFrameForRow: fails with a 'should not happen' IS BACK

by Goubier Thierry

Le 18/02/2013 22:28, Sean P. DeNigris a Ã©crit : > http://code.google.com/p/pharo/issues/detail?id=7534 http://code.google.com/p/pharo/issues/detail?id=7509 With Igor suggestions on how to correct that :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 19, 2013

Re: [Pharo-project] Phexample should methods

by Adrian Kuhn

On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote: > 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? Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with. Other than Ruby we cannot break free from classes and methods (imposed by the Smalltalk IDE rather than the language) so its what we must work with. Personally I like to have a 1:1 mapping between classes and "test classes" as in Stack and StackExamples and then use "test method" names to describe the examples. And then other "test classes" with more complex use cases that cover features involving more than one class. I am not sure if we ever implemented the following idea, but I seem to recall that I used to name some of my "methods" inside the "example classes" with names such as #givenAnEmptyStack or #givenAStackWithTwoElements and then sending these to create the fixture in the "test methods" #shouldAddElement or #shouldFailWhenPoppingFromEmptyStack etc ... Essentially, everything you ever type and evaluate in a workspace should be turned into an example, see http://qr.ae/10yZR Think of it, having a "save as example" menu item available on *every* text selection in the system would be so awesome! > PS: It is also inconsistent with Phexample's own #isTest: implementation, which uses #beginsWith: Oops, that's a bug, #theMoreGeneralCaseShouldApply :) Even though personally I prefer to not use should inside the name in order to limit the pollution for the selection name space with regard to Smalltalk's simple autocomplete ... --AA

Feb. 19, 2013

Re: [Pharo-project] Migrated SS/Growl to Pharo/Archive

by Ben Coman

Mariano Martinez Peck wrote: > On Mon, Feb 18, 2013 at 9:55 AM, Ben Coman <btc(a)openinworld.com> wrote: > > >> Mariano Martinez Peck wrote: >> >> >>> On Sun, Feb 17, 2013 at 2:56 PM, stephane ducasse >>> <stephane.ducasse(a)free.fr>**wrote: >>> >>> >>> >>> >>>> >>>>> Stef, now that you are migrating everything to SmalltalkHub, are you: >>>>> >>>>> - putting a big text in the old repositories saying "PROJECT XXX WAS >>>>> >>>>> >>>>> >>>> MOVED TO YYY". Because then we run in problems where people refer/commit >>>> to >>>> old repos >>>> >>>> >>>> >>>>> - make old project repo read only >>>>> >>>>> >>>>> >>>> I did it for all the projects that I administrate. >>>> >>>> >>>> >>>> >>>> >>> Excellent :) >>> >>> >>> >>> >>> >>> >> I am wondering if perhaps someone accessing one of those repositories via >> Monticello might miss that. Perhaps a final package with filename >> "package.movedToSmalltalkhub.**mcz" would be useful (or maybe just >> overkill) >> >> >> > Yes, I was thinking the same for "deprecating a package". In fuel we have > lots of packages that with newer versions are deprecated. And when you > browse with Monticello you still see them around... Moving them to another > repo is not an option because it would mean to update all previous versions > in ConfgiurationOfFuel. So I was also thinking about committing a last > version like: FuelXXXDeprecated-THIS_PACKAGE_IS_DEPRECATED.nnn.mzc. > > Cheers, > > > To ensure it sorts in a proper order, by default (unless you have tested somethign else) I would keep as close to the standard package filename as possible and just replace the Author with 'Deprecated'. eg: FuelXXX-Author.nnn.mcz might be FuelXXX-DeprecatedUseFuelYYY.nnn+1.mcz

Feb. 19, 2013

Re: [Pharo-project] Smalllint for Traits

by Gabriel Cotelli

Hi, The license page needs an update, "Copyright (c) Pharo Project, and Contributors Copyright (c) 1996-2008 " must be "Copyright (c) Pharo Project, and Contributors Copyright (c) 1996*-2013*" ? Maybe "The Distribution Agreement" can be updated with the Pharo consortium as the distributor? On Mon, Feb 18, 2013 at 9:38 PM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > Hi, check out the following links. > > http://www.pharo-project.org/license > > > http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgre… > > Saludos, > Fernando > > On Tue, Feb 19, 2013 at 1:01 AM, aizcorbe > <juansebastian.aizcorbe(a)gmail.com> wrote: > > No, i didn't sign any licence, what is this about? > > > > > > > > -- > > View this message in context: > http://forum.world.st/Smalllint-for-Traits-tp4662559p4670573.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > >

Feb. 19, 2013

Re: [Pharo-project] Smalllint for Traits

by Fernando Olivero

Hi, check out the following links. http://www.pharo-project.org/license http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgre… Saludos, Fernando On Tue, Feb 19, 2013 at 1:01 AM, aizcorbe <juansebastian.aizcorbe(a)gmail.com> wrote: > No, i didn't sign any licence, what is this about? > > > > -- > View this message in context: http://forum.world.st/Smalllint-for-Traits-tp4662559p4670573.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 19, 2013

Re: [Pharo-project] Smalllint for Traits

by aizcorbe

No, i didn't sign any licence, what is this about? -- View this message in context: http://forum.world.st/Smalllint-for-Traits-tp4662559p4670573.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 19, 2013

[Pharo-project] Magritte and Spec

by DeNigris Sean

Since I'm using Spec for all my Pharo UIs, I'm interested in having Spec as the backend to Magritte. If anyone is interested, I started an experiment at http://ss3.gemstone.com/ss/SpdPlayground/ . Look for the Magritte-Spec package. Cheers, Sean

Feb. 18, 2013

[Pharo-project] Issue 7534 LazyListMorph>>selectionFrameForRow: fails with a 'should not happen' IS BACK

by Sean P. DeNigris

http://code.google.com/p/pharo/issues/detail?id=7534 -- View this message in context: http://forum.world.st/Issue-7534-LazyListMorph-selectionFrameForRow-fails-w… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 18, 2013

[Pharo-project] Magritte3 in Pharo 2.0

by DeNigris Sean

I was pleasantly surprised that Magritte loaded without any hiccups :) The only failing tests seem to be related to: - includesSubString: -> includesSubstring: - time printing w/without milliseconds - FileDirectory Cheers, Sean

Feb. 18, 2013

Re: [Pharo-project] Migrated SS/Growl to Pharo/Archive

by Mariano Martinez Peck

On Mon, Feb 18, 2013 at 9:55 AM, Ben Coman <btc(a)openinworld.com> wrote: > Mariano Martinez Peck wrote: > >> On Sun, Feb 17, 2013 at 2:56 PM, stephane ducasse >> <stephane.ducasse(a)free.fr>**wrote: >> >> >> >>> >>> >>>> Stef, now that you are migrating everything to SmalltalkHub, are you: >>>> >>>> - putting a big text in the old repositories saying "PROJECT XXX WAS >>>> >>>> >>> MOVED TO YYY". Because then we run in problems where people refer/commit >>> to >>> old repos >>> >>> >>>> - make old project repo read only >>>> >>>> >>> I did it for all the projects that I administrate. >>> >>> >>> >>> >> Excellent :) >> >> >> >> >> > > I am wondering if perhaps someone accessing one of those repositories via > Monticello might miss that. Perhaps a final package with filename > "package.movedToSmalltalkhub.**mcz" would be useful (or maybe just > overkill) > > Yes, I was thinking the same for "deprecating a package". In fuel we have lots of packages that with newer versions are deprecated. And when you browse with Monticello you still see them around... Moving them to another repo is not an option because it would mean to update all previous versions in ConfgiurationOfFuel. So I was also thinking about committing a last version like: FuelXXXDeprecated-THIS_PACKAGE_IS_DEPRECATED.nnn.mzc. Cheers, -- Mariano http://marianopeck.wordpress.com

Feb. 18, 2013