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

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

verveinJ cannot create mse with too big input

by Fabrizio Perin

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

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 Le 20/04/2015 12:02, Christophe Demarey a Ã©crit : > Hi, > > With BDD a current test practice is to start method names with 'should'. > It is not yet possible in Pharo but easily do-able (update of TestCase and some Nautilus methods). > I would like that Pharo detects tes methods all methods of a class subclassing (directly or not) TestCase AND starting with either 'test' or 'should'. > I also would like to add 'deny' to not use 'shouldNot' but here I'm not sure. > > WDYT? > > Christophe.

April 21, 2015

Re: [Pharo-dev] Recommended image resolution for Pillar books?

by Damien Cassou

Dmitri Zagidulin <dmitri(a)zagidulin.net> writes: > 2. Does it matter (is it advantageous) whether one puts the width= > attribute on the figure declarations? I would use the width attribute to size the image with respect to his surrounding text (e.g., half of the line width). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 21, 2015

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

by Esteban Lorenzano

> 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] Little fix to MC merge facility

by Thierry Goubier

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... AST-based comparison would be nice there; however what about the cost? Some of MC operations are already fairly slow as they are now. 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