- Pharo-dev - lists.pharo.org

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

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

by Jan Vrany

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 :-) > > 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... > > 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

Re: [Pharo-dev] TDD and BDD

by Sven Van Caekenberghe

> 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

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Christophe Demarey

Hi, Le 21 avr. 2015 Ã 10:14, Miguel Moquillon a Ã©crit : > Hi, > > BDD and TDD stands for different purposes with different actors. > In BDD, stakeholders work on the functionalities of software units (coarse grain, black-box approach) whereas on TDD developers work on the object's features (fine-grain, white-box approach) that made the functionalities. So, the tooling in BDD should be different of the tooling used in TDD (BDD is more high-level than TDD). > > 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> > > Basic example: > > As a customer, > I want to withdraw cash from an ATM, > so that I donât have to wait in line at the bank. > > Scenario 1: Account is in credit > Given the account is in credit > And the card is valid > And the dispenser contains cash > When the customer requests cash > Then ensure the account is debited > And ensure cash is dispensed > And ensure the card is returned > > In fact, a useful and good BDD tool must provide : > a way to define a set of initial data > a DSL to define the functionalities and for each of them to express the scenarios according to the schema above > an engine that feeds automatically the scenario from the data set and that outputs the result. > Miguel Moquillon yes, you're right on all these points. I'm not aware of such a library for Pharo but it would be very nice. On top of that, you could add a dashboard collecting automatically these tests (that are more or less User Stories) to show your customer which user stories are completed. 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.

April 21, 2015

Re: [Pharo-dev] verveinJ cannot create mse with too big input

by Nicolas Anquetil

it is a know fact, not an error :-) Basically, verveinej has to maintain several models of the project in memory to be able to do its job if the project is too big, this might end up exploding the memory and giving unexpected results That's why we implemented the incremental parsing option Now, what you are reporting looks like a bug, but because of the conditions, I am not sure it is really one, especially if it works fine when you split the project in 2 You also have the option of twicking the calling script to increase java memory In the past, (sun) java used to require contiguous memory (just like pharo) but jikes removed this constraint I believe the new oracle java removed the constraint also, so you might be able to go pretty high in memory on a java execution ... Let us know if it works nicolas PS: This seems like a Moose-dev question rather than a pharo-dev one On 21/04/2015 10:21, Fabrizio Perin wrote: > Hello, > I was trying to create an MSE file with VerveinJ and I got an > incomplete MSE at the following error on the console: > > /Exception while Visiting famix repository entities. For example, this > might happen when an entity inside the repository has a property > refering to an entity outside the repository/ > / Entity ID: 69580 (a FAMIX.AnnotationInstanceAttribute), property: > parentAnnotationInstance/ > /Exception in thread "main" java.lang.NoClassDefFoundError: > fr/inria/verveine/core/gen/famix/NamedEntity/ > / at > ch.akuhn.fame.internal.RepositoryVisitor.acceptElement(RepositoryVisitor.java:111)/ > / at > ch.akuhn.fame.internal.RepositoryVisitor.acceptVisitor(RepositoryVisitor.java:162)/ > / at > ch.akuhn.fame.internal.RepositoryVisitor.run(RepositoryVisitor.java:207)/ > / at ch.akuhn.fame.Repository.accept(Repository.java:105)/ > / at ch.akuhn.fame.Repository.exportMSE(Repository.java:216)/ > / at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown > Source)/ > / at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown > Source)/ > / at eu.synectique.verveine.core.VerveineParser.emitMSE(Unknown > Source)/ > / at > eu.synectique.verveine.extractor.java.VerveineJParser.main(Unknown > Source)/ > /Caused by: java.lang.ClassNotFoundException: > fr.inria.verveine.core.gen.famix.NamedEntity/ > / at java.net.URLClassLoader$1.run(URLClassLoader.java:366)/ > / at java.net.URLClassLoader$1.run(URLClassLoader.java:355)/ > / at java.security.AccessController.doPrivileged(Native Method)/ > / at java.net.URLClassLoader.findClass(URLClassLoader.java:354)/ > / at java.lang.ClassLoader.loadClass(ClassLoader.java:423)/ > / at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)/ > / at java.lang.ClassLoader.loadClass(ClassLoader.java:356)/ > / ... 9 more / > / > / > / > / > I'm using windows, not sure how to get the version of verveinJ. The > same does not happen if I split the project in two parts and I parse > them separately. > > Is it known error or am I doing something wrong? > > Thanks in advance, > Fabrizio

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Christophe Demarey

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 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