April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Sean P. DeNigris

Thierry Goubier wrote > So, on a regular basis, you have a message which says: I tried to load the > project X inside Pharo (where X, as an older version, is inside Pharo > already) and it breaks here and there. Isn't that what locking is for in the Metacello scripting API? ----- Cheers, Sean -- View this message in context: http://forum.world.st/missing-packages-in-the-Pharo50-repository-tp4820696p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Esteban Lorenzano

> On 21 Apr 2015, at 12:52, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-04-21 11:49 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > >> On 21 Apr 2015, at 11:42, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> btw, how do you merge Configurations? For example, if I fix something "X" in my image and continue to work in it a month while the Image Configurations move forward, how do avoid losing that fix when I update to the latest Configuration ? > > you *do not* merge configurations. > if you fix something in a âconfiguredâ project, you submit your change to proper repository (not as a SLICE, as regular packages), which in time will be included (or not, if âproject ownerâ rejects it) in a new configutation that will be included in Pharo. > > The problem is that the configuration of the project used to version that project inside the Pharo image isn't versionned inside Pharo, but instead in the project itself. > > So, on a regular basis, you have a message which says: I tried to load the project X inside Pharo (where X, as an older version, is inside Pharo already) and it breaks here and there. > > It will bite us when we'll try to make use of the Minimal image and rebuilt stuff on top of it; all those external projects have a tendency to redefine their configurations and semantic versions on a regular basis, and Pharo does not record where and which; which will make reproducing out of a Minimal image a real pain, with breakages appearing from one day to another. > > > thatâs how any complex project worksâ¦ and thatâs how we should work too. SLICES are just a patch that exists because our system still not modular enough. configurations have versions. the problem is that I made a mistake and I allowed people to express their integrable versions as â#developmentââ¦ while is easier for them, it proved to be a problem because it breaks update process. So, solution is simple: no âsymbolicâ version will be allowed to be integrated: just fixed number versions. Then update process will know which package versions to load. > > Well, current system isn't much better, IMHO. believe me, it is. would be better if system would be modular so we do not need to change everything to change a bitâ¦ but weâll arrive there. > > A simple solution, would be to version in PharoXX/main, the exact configuration used to load the external project. nope, solution is to explicit version to load :) Esteban > > It is not the case today. > > Thierry > > >> >> Actually I guess it would be useful if a Configuration could be merged with the same GUI that merges a Slice. > > wellâ¦ monkey and integrator app (integrators use it) does the proper loading. > But I insist: configurations are not merged: versions are loaded, instead. > > cheers. > Esteban > >> >> cheers -ben >> >> On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> > On 21 Apr 2015, at 08:06, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> > >> > It means that we should also add the repositories of these projects so that MC can merge no? >> well, but you should not merge this projects :) >> >> > >> > Le 20/4/15 22:19, Esteban Lorenzano a Ã©crit : >> >> they are handled separately, through configurations. >> >> >> >> cheers, >> >> Esteban >> >> >> >>> On 20 Apr 2015, at 21:02, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >>> >> >>> Hi, >> >>> >> >>> these packages do not have a version in the Pharo50 repository: >> >>> >> >>> Athens-Balloon >> >>> Athens-Cairo >> >>> Athens-CairoPools >> >>> Athens-Core >> >>> Athens-Examples >> >>> Athens-Morphic >> >>> Athens-Text >> >>> ConfigurationOfAthens >> >>> ConfigurationOfGlamourCore >> >>> ConfigurationOfGTInspectorCore >> >>> ConfigurationOfGToolkitCore >> >>> ConfigurationOfGTPlaygroundCore >> >>> ConfigurationOfGTSpotter >> >>> ConfigurationOfOSWindow >> >>> ConfigurationOfRubric >> >>> ConfigurationOfShoreLineReporter >> >>> ConfigurationOfTxText >> >>> ConfigurationOfVersionner >> >>> ConfigurationOfZincHTTPComponents >> >>> Glamour-Announcements >> >>> Glamour-Browsers >> >>> Glamour-Core >> >>> Glamour-Examples >> >>> Glamour-Helpers >> >>> Glamour-Morphic-Brick >> >>> Glamour-Morphic-Brick-Tests >> >>> Glamour-Morphic-Pager >> >>> Glamour-Morphic-Renderer >> >>> Glamour-Morphic-Theme >> >>> Glamour-Morphic-Widgets >> >>> Glamour-Presentations >> >>> Glamour-Rubric-Presentations >> >>> Glamour-Tests-Core >> >>> Glamour-Tests-Morphic >> >>> Glamour-Tests-Resources >> >>> Glamour-Tests-Rubric >> >>> GT-Inspector >> >>> GT-InspectorExtensions-Core >> >>> GT-Playground >> >>> GT-Spotter >> >>> GT-Spotter-EventRecorder >> >>> GT-SpotterExtensions-Core >> >>> GT-Tests-Inspector >> >>> GT-Tests-Playground >> >>> GT-Tests-Spotter >> >>> OSWindow-SDL2 >> >>> OSWindow-VM >> >>> Rubric >> >>> ShoreLine-Report-Core >> >>> ShoreLine-Report-Settings >> >>> ShoreLine-Report-UI >> >>> TxText-AthensTests >> >>> TxText-Model >> >>> TxText-Styler >> >>> TxTextTests-Model >> >>> Versionner-Core-Commands >> >>> Versionner-Core-Model >> >>> Versionner-Spec-Browser >> >>> Versionner-Tests-Core-Model >> >>> Zinc-HTTP >> >>> Zinc-Character-Encoding-Core >> >>> Zinc-Character-Encoding-Tests >> >>> Zinc-Resource-Meta-Core >> >>> Zinc-Resource-Meta-Tests >> >>> Zinc-Tests >> >>> Zinc-Zodiac >> >>> Zodiac-Core >> >>> Zodiac-Tests >> >>> >> >>> Cheers, >> >>> -- Pavel >> >>> >> >> >> >> >> > >> > >> >> >> > >

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Thierry Goubier

2015-04-21 11:49 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 21 Apr 2015, at 11:42, Ben Coman <btc(a)openinworld.com> wrote: > > btw, how do you merge Configurations? For example, if I fix something "X" > in my image and continue to work in it a month while the Image > Configurations move forward, how do avoid losing that fix when I update to > the latest Configuration ? > > > you *do not* merge configurations. > if you fix something in a "configured" project, you submit your change to > proper repository (not as a SLICE, as regular packages), which in time will > be included (or not, if "project owner" rejects it) in a new configutation > that will be included in Pharo. > The problem is that the configuration of the project used to version that project inside the Pharo image isn't versionned inside Pharo, but instead in the project itself. So, on a regular basis, you have a message which says: I tried to load the project X inside Pharo (where X, as an older version, is inside Pharo already) and it breaks here and there. It will bite us when we'll try to make use of the Minimal image and rebuilt stuff on top of it; all those external projects have a tendency to redefine their configurations and semantic versions on a regular basis, and Pharo does not record where and which; which will make reproducing out of a Minimal image a real pain, with breakages appearing from one day to another. > > that's how any complex project works... and that's how we should work too. > SLICES are just a patch that exists because our system still not modular > enough. > Well, current system isn't much better, IMHO. A simple solution, would be to version in PharoXX/main, the exact configuration used to load the external project. It is not the case today. Thierry > > > Actually I guess it would be useful if a Configuration could be merged > with the same GUI that merges a Slice. > > > well... monkey and integrator app (integrators use it) does the proper > loading. > But I insist: configurations are not merged: versions are loaded, instead. > > cheers. > Esteban > > > cheers -ben > > On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> > On 21 Apr 2015, at 08:06, stepharo <stepharo(a)free.fr> wrote: >> > >> > It means that we should also add the repositories of these projects so >> that MC can merge no? >> well, but you should not merge this projects :) >> >> > >> > Le 20/4/15 22:19, Esteban Lorenzano a Ã©crit : >> >> they are handled separately, through configurations. >> >> >> >> cheers, >> >> Esteban >> >> >> >>> On 20 Apr 2015, at 21:02, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> these packages do not have a version in the Pharo50 repository: >> >>> >> >>> Athens-Balloon >> >>> Athens-Cairo >> >>> Athens-CairoPools >> >>> Athens-Core >> >>> Athens-Examples >> >>> Athens-Morphic >> >>> Athens-Text >> >>> ConfigurationOfAthens >> >>> ConfigurationOfGlamourCore >> >>> ConfigurationOfGTInspectorCore >> >>> ConfigurationOfGToolkitCore >> >>> ConfigurationOfGTPlaygroundCore >> >>> ConfigurationOfGTSpotter >> >>> ConfigurationOfOSWindow >> >>> ConfigurationOfRubric >> >>> ConfigurationOfShoreLineReporter >> >>> ConfigurationOfTxText >> >>> ConfigurationOfVersionner >> >>> ConfigurationOfZincHTTPComponents >> >>> Glamour-Announcements >> >>> Glamour-Browsers >> >>> Glamour-Core >> >>> Glamour-Examples >> >>> Glamour-Helpers >> >>> Glamour-Morphic-Brick >> >>> Glamour-Morphic-Brick-Tests >> >>> Glamour-Morphic-Pager >> >>> Glamour-Morphic-Renderer >> >>> Glamour-Morphic-Theme >> >>> Glamour-Morphic-Widgets >> >>> Glamour-Presentations >> >>> Glamour-Rubric-Presentations >> >>> Glamour-Tests-Core >> >>> Glamour-Tests-Morphic >> >>> Glamour-Tests-Resources >> >>> Glamour-Tests-Rubric >> >>> GT-Inspector >> >>> GT-InspectorExtensions-Core >> >>> GT-Playground >> >>> GT-Spotter >> >>> GT-Spotter-EventRecorder >> >>> GT-SpotterExtensions-Core >> >>> GT-Tests-Inspector >> >>> GT-Tests-Playground >> >>> GT-Tests-Spotter >> >>> OSWindow-SDL2 >> >>> OSWindow-VM >> >>> Rubric >> >>> ShoreLine-Report-Core >> >>> ShoreLine-Report-Settings >> >>> ShoreLine-Report-UI >> >>> TxText-AthensTests >> >>> TxText-Model >> >>> TxText-Styler >> >>> TxTextTests-Model >> >>> Versionner-Core-Commands >> >>> Versionner-Core-Model >> >>> Versionner-Spec-Browser >> >>> Versionner-Tests-Core-Model >> >>> Zinc-HTTP >> >>> Zinc-Character-Encoding-Core >> >>> Zinc-Character-Encoding-Tests >> >>> Zinc-Resource-Meta-Core >> >>> Zinc-Resource-Meta-Tests >> >>> Zinc-Tests >> >>> Zinc-Zodiac >> >>> Zodiac-Core >> >>> Zodiac-Tests >> >>> >> >>> Cheers, >> >>> -- Pavel >> >>> >> >> >> >> >> > >> > >> >> >> > >

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Christophe Demarey

Le 21 avr. 2015 Ã 11:38, Esteban Lorenzano a Ã©crit : > >> On 21 Apr 2015, at 10:22, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >> >> Le 20 avr. 2015 Ã 18:23, Sean P. DeNigris a Ã©crit : >> >>> Sean P. DeNigris wrote >>>> refactor so that all those places use one implementation somewhere. >>> >>> In fact, searching the sources for "beginsWith: 'test'", the logic is >>> duplicated quite a bit. And someone even snuck your proposed change into >>> CompiledMethod>>#isTestMethod, so now we already have two conflicting >>> concepts of what a test selector is in Core. >> >> In fact, I already did the changes in an image (but not published, I wait for feedback) and I also noticed the duplicated logic. >> Monty also pointed me to take care of this problem: https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-…. >> >> What I did is really simple: >> In TestCase Class, >> add >> <Capture dâÃ©cran 2015-04-21 Ã 10.12.36.png> > > hi, side note: > take into account that the use of #or: as you are using it is not recommended. > Better something like: > > firstTerm > or: [ secondTerm > or: [ thirdTerm > or [ etc. ] ] ] > > yes, is uglier, but faster :) ok ;)

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Christophe Demarey

Le 21 avr. 2015 Ã 10:44, Sven Van Caekenberghe a Ã©crit : > >> On 21 Apr 2015, at 10:36, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >> To come back to my proposition, it is just a first step to BDD to not prevent people to define tests with something like shouldAccountBalanceBePositiveAfterEachOperation (more behavior driven) rather than testMyWonderfulMethod that may leads people to test the implementation details and not the expected behavior. > > Not that your naming ideas are bad, but right now you can write > > testAccountShouldBePositiveAfterEachOperation > > which is not that bad I agree. I do not want to push things that won't be used. That's why I did not yet proposed a slice. Maybe I will just let it as it is now and just propose to include the refactoring to have the logic of the test selection in one place. With Guille, we discussed a bit around tests and came to the conclusion that it would be good to have a blog post or a book chapter on test solutions and how to test the good thing. We have, for example: SUnit BabyMock (http://smalltalkhub.com/#!/~zeroflag/BabyMock2) Mocketry (http://smalltalkhub.com/#!/~dionisiy/Mocketry) PhExample (http://smalltalkhub.com/#!/~PharoExtras/Phexample) BoTest (http://smalltalkhub.com/#!/~CAR/BoTest) Kiwi TDD (https://www.youtube.com/watch?v=m2t_MbVAdis) and maybe others. Thanks for the feedback.

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Esteban Lorenzano

> On 21 Apr 2015, at 11:42, Ben Coman <btc(a)openinworld.com> wrote: > > btw, how do you merge Configurations? For example, if I fix something "X" in my image and continue to work in it a month while the Image Configurations move forward, how do avoid losing that fix when I update to the latest Configuration ? you *do not* merge configurations. if you fix something in a âconfiguredâ project, you submit your change to proper repository (not as a SLICE, as regular packages), which in time will be included (or not, if âproject ownerâ rejects it) in a new configutation that will be included in Pharo. thatâs how any complex project worksâ¦ and thatâs how we should work too. SLICES are just a patch that exists because our system still not modular enough. > > Actually I guess it would be useful if a Configuration could be merged with the same GUI that merges a Slice. wellâ¦ monkey and integrator app (integrators use it) does the proper loading. But I insist: configurations are not merged: versions are loaded, instead. cheers. Esteban > > cheers -ben > > On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > On 21 Apr 2015, at 08:06, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > > It means that we should also add the repositories of these projects so that MC can merge no? > well, but you should not merge this projects :) > > > > > Le 20/4/15 22:19, Esteban Lorenzano a Ã©crit : > >> they are handled separately, through configurations. > >> > >> cheers, > >> Esteban > >> > >>> On 20 Apr 2015, at 21:02, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > >>> > >>> Hi, > >>> > >>> these packages do not have a version in the Pharo50 repository: > >>> > >>> Athens-Balloon > >>> Athens-Cairo > >>> Athens-CairoPools > >>> Athens-Core > >>> Athens-Examples > >>> Athens-Morphic > >>> Athens-Text > >>> ConfigurationOfAthens > >>> ConfigurationOfGlamourCore > >>> ConfigurationOfGTInspectorCore > >>> ConfigurationOfGToolkitCore > >>> ConfigurationOfGTPlaygroundCore > >>> ConfigurationOfGTSpotter > >>> ConfigurationOfOSWindow > >>> ConfigurationOfRubric > >>> ConfigurationOfShoreLineReporter > >>> ConfigurationOfTxText > >>> ConfigurationOfVersionner > >>> ConfigurationOfZincHTTPComponents > >>> Glamour-Announcements > >>> Glamour-Browsers > >>> Glamour-Core > >>> Glamour-Examples > >>> Glamour-Helpers > >>> Glamour-Morphic-Brick > >>> Glamour-Morphic-Brick-Tests > >>> Glamour-Morphic-Pager > >>> Glamour-Morphic-Renderer > >>> Glamour-Morphic-Theme > >>> Glamour-Morphic-Widgets > >>> Glamour-Presentations > >>> Glamour-Rubric-Presentations > >>> Glamour-Tests-Core > >>> Glamour-Tests-Morphic > >>> Glamour-Tests-Resources > >>> Glamour-Tests-Rubric > >>> GT-Inspector > >>> GT-InspectorExtensions-Core > >>> GT-Playground > >>> GT-Spotter > >>> GT-Spotter-EventRecorder > >>> GT-SpotterExtensions-Core > >>> GT-Tests-Inspector > >>> GT-Tests-Playground > >>> GT-Tests-Spotter > >>> OSWindow-SDL2 > >>> OSWindow-VM > >>> Rubric > >>> ShoreLine-Report-Core > >>> ShoreLine-Report-Settings > >>> ShoreLine-Report-UI > >>> TxText-AthensTests > >>> TxText-Model > >>> TxText-Styler > >>> TxTextTests-Model > >>> Versionner-Core-Commands > >>> Versionner-Core-Model > >>> Versionner-Spec-Browser > >>> Versionner-Tests-Core-Model > >>> Zinc-HTTP > >>> Zinc-Character-Encoding-Core > >>> Zinc-Character-Encoding-Tests > >>> Zinc-Resource-Meta-Core > >>> Zinc-Resource-Meta-Tests > >>> Zinc-Tests > >>> Zinc-Zodiac > >>> Zodiac-Core > >>> Zodiac-Tests > >>> > >>> Cheers, > >>> -- Pavel > >>> > >> > >> > > > > > > >

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Ben Coman

btw, how do you merge Configurations? For example, if I fix something "X" in my image and continue to work in it a month while the Image Configurations move forward, how do avoid losing that fix when I update to the latest Configuration ? Actually I guess it would be useful if a Configuration could be merged with the same GUI that merges a Slice. cheers -ben On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 21 Apr 2015, at 08:06, stepharo <stepharo(a)free.fr> wrote: > > > > It means that we should also add the repositories of these projects so > that MC can merge no? > well, but you should not merge this projects :) > > > > > Le 20/4/15 22:19, Esteban Lorenzano a Ã©crit : > >> they are handled separately, through configurations. > >> > >> cheers, > >> Esteban > >> > >>> On 20 Apr 2015, at 21:02, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >>> > >>> Hi, > >>> > >>> these packages do not have a version in the Pharo50 repository: > >>> > >>> Athens-Balloon > >>> Athens-Cairo > >>> Athens-CairoPools > >>> Athens-Core > >>> Athens-Examples > >>> Athens-Morphic > >>> Athens-Text > >>> ConfigurationOfAthens > >>> ConfigurationOfGlamourCore > >>> ConfigurationOfGTInspectorCore > >>> ConfigurationOfGToolkitCore > >>> ConfigurationOfGTPlaygroundCore > >>> ConfigurationOfGTSpotter > >>> ConfigurationOfOSWindow > >>> ConfigurationOfRubric > >>> ConfigurationOfShoreLineReporter > >>> ConfigurationOfTxText > >>> ConfigurationOfVersionner > >>> ConfigurationOfZincHTTPComponents > >>> Glamour-Announcements > >>> Glamour-Browsers > >>> Glamour-Core > >>> Glamour-Examples > >>> Glamour-Helpers > >>> Glamour-Morphic-Brick > >>> Glamour-Morphic-Brick-Tests > >>> Glamour-Morphic-Pager > >>> Glamour-Morphic-Renderer > >>> Glamour-Morphic-Theme > >>> Glamour-Morphic-Widgets > >>> Glamour-Presentations > >>> Glamour-Rubric-Presentations > >>> Glamour-Tests-Core > >>> Glamour-Tests-Morphic > >>> Glamour-Tests-Resources > >>> Glamour-Tests-Rubric > >>> GT-Inspector > >>> GT-InspectorExtensions-Core > >>> GT-Playground > >>> GT-Spotter > >>> GT-Spotter-EventRecorder > >>> GT-SpotterExtensions-Core > >>> GT-Tests-Inspector > >>> GT-Tests-Playground > >>> GT-Tests-Spotter > >>> OSWindow-SDL2 > >>> OSWindow-VM > >>> Rubric > >>> ShoreLine-Report-Core > >>> ShoreLine-Report-Settings > >>> ShoreLine-Report-UI > >>> TxText-AthensTests > >>> TxText-Model > >>> TxText-Styler > >>> TxTextTests-Model > >>> Versionner-Core-Commands > >>> Versionner-Core-Model > >>> Versionner-Spec-Browser > >>> Versionner-Tests-Core-Model > >>> Zinc-HTTP > >>> Zinc-Character-Encoding-Core > >>> Zinc-Character-Encoding-Tests > >>> Zinc-Resource-Meta-Core > >>> Zinc-Resource-Meta-Tests > >>> Zinc-Tests > >>> Zinc-Zodiac > >>> Zodiac-Core > >>> Zodiac-Tests > >>> > >>> Cheers, > >>> -- Pavel > >>> > >> > >> > > > > > > >

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Esteban Lorenzano

> On 21 Apr 2015, at 10:22, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 20 avr. 2015 Ã 18:23, Sean P. DeNigris a Ã©crit : > >> Sean P. DeNigris wrote >>> refactor so that all those places use one implementation somewhere. >> >> In fact, searching the sources for "beginsWith: 'test'", the logic is >> duplicated quite a bit. And someone even snuck your proposed change into >> CompiledMethod>>#isTestMethod, so now we already have two conflicting >> concepts of what a test selector is in Core. > > In fact, I already did the changes in an image (but not published, I wait for feedback) and I also noticed the duplicated logic. > Monty also pointed me to take care of this problem: https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-… <https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-…>. > > What I did is really simple: > In TestCase Class, > add > <Capture dâÃ©cran 2015-04-21 Ã 10.12.36.png> hi, side note: take into account that the use of #or: as you are using it is not recommended. Better something like: firstTerm or: [ secondTerm or: [ thirdTerm or [ etc. ] ] ] yes, is uglier, but faster :) cheers, Esteban > update #testSelectors and #methodChanged: to use #isTestSelector: > update shouldInheritSelectors to fix a wrong behavior > In ClassTestCase, update selectorsTested to use #isTestSelector: > Update Nautilus extension method CompiledMethod>>isTestMethod to use TestCase>>#isTestSelector: > > I will add a slice for that but I'm not sure if it is a good idea to include tests beginning with deny.

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Stephan Eggermont

On 21/04/15 10:14, Miguel Moquillon wrote: > In BDD each functionalities are describes as : > > As a <role> > I want <some feature> > So that <I gain a benefit> > > And the functionality is described in different scenarios (nominal and > error ones) : > Given <some initial context> > When <an event occurs> > Then <ensure some outcomes> This can be mapped rather easily on a subclass of TestCase, even the variants with tabled examples. With glamour now in the core, it is easy to make a specialized browser (and editor) for these tests. Given and When map to setUp, then to the test. Just add BDDGoal BDDStakeHolder and BDDFeature and make sure that a BDDTest refers to them. Stephan

April 21, 2015

Re: [Pharo-dev] Little fix to MC merge facility

by Thierry Goubier

2015-04-21 10:45 GMT+02:00 Jan Vrany <jan.vrany(a)fit.cvut.cz>: > On Tue, 2015-04-21 at 08:41 +0200, Thierry Goubier wrote: > > Le 21/04/2015 07:46, stepharo a Ã©crit : > > > > > >> No, I changed MCMethodDefinition>>= to be more relaxed about > > >> sources and treat two sources that differ only in leading/trailing > > >> spaces as "same". This way, these methods do not occur in merge tool > > >> at all. > > >> This is just a quick fix - much better would be to compare AST's and > > >> treat whitespace-changes specially (i.e., provide a filter to > show/hide > > >> whitespace-only-changes). > > > > > > OK now I wonder if we want to have methods with different end of line > > > conventions in the system. > > > > I pushed a change to MCMethodDefinition>>#= a short while ago because > > source code was seeing line ending changes... > > Could you point me to that? If you don't mind, I'll merge it as it could > help to solve problems I might soon run into :-) > Well, this is just the line in the "=" which says: aDefinition source withSqueakLineEndings = self source withSqueakLineEndings > > > > > AST-based comparison would be nice there; however what about the cost? > > Some of MC operations are already fairly slow as they are now. > > If done on a tool level (where this belongs to IMO) it won't be much of > a problem. Only one might have to wait for window to come up a > little longer... > The problem is that this = is used whenever you want to load a method definition or to determine what are the changes you want to save. Repeat by the number of methods and you start to see an effect ;) Try loading Roassal for an example of what I mean... In the other hand, as long as we're using the RBParser to get an AST, parsing is fast. Thierry > > > > Thierry > > > > > I do not remember the discussion we got long time ago. > > > > > > Stef > > >>> Do you think that we should integrate it? > > >> Yes. > > >> > > >>> Stef > > >>> > > >>> Le 20/4/15 12:36, Jan Vrany a Ã©crit : > > >>>> Hi, > > >>>> > > >>>> I just wanted to merge some code in Monticello and the merge tool > > >>>> marked all methods as conflict because their source differ in > trailing > > >>>> whitespace (newline). The diff panel on the right does not show any > > >>>> difference. > > >>>> > > >>>> > http://smalltalkhub.com/#!/~JanVrany/Misc/versions/Monticello-Fixes-JanVran… > > >>>> > > >>>> > > >>>> Here's a fix for this particular problem in case somebody runs into > the > > >>>> same problem. > > >>>> > > >>>> Best, Jan > > >>>> > > >>>> > > >>>> > > >>> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > >

April 21, 2015