March 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #164: Integrate Clap

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #164 was: FAILURE. The Pull Request #2377 was integrated: "Integrate Clap" Pull request url: https://github.com/pharo-project/pharo/pull/2377 Issue Url: https://pharo.fogbugz.com/f/cases/2377 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2019

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

by Attila Magyar

Thanks for the explanation Torsten. I do use setUp for initialization but one exception is BabyMock2TesCase which serves as a base class for other tests. The reason why its variables are created in the init is that the users would likely forget sending a setUp to the super class in their own setUp. I'm glad there are rules defined for this now. However I still have mixed feelings about this. The usage of cleanUpInstanceVariables feels like a hack and runCase feels broken from symmetrical point of view. If a convention breaks something, it's not just a convention anymore and should be enforced more strictly. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 20, 2019

Re: [Pharo-dev] About a better filedialog

by Hilaire

Something as simple as in the current filedialog will be far than enough: an option to toggle a preview display. It is then the responsibility of the user to code the preview view. I am afraid an inspector view will look too hackish for a user like a teacher or a kid. Hilaire Le 19/03/2019 Ã 20:42, Peter Uhnak a Ã©critÂ : > Preview is indeed not supported. My original idea was to show a > regular GTInspector view on the file, but I never got around to > implementing it. -- Dr. Geo http://drgeo.eu

March 20, 2019

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

by Torsten Bergmann

Attila wrote: >why don't we reinitialize them before running the test? SUnit does - but requires it to be in #setUp. One just has to follow the SUnit framework rules. So if one implements MyTest>>initialize super initialize. s := OrderedCollection new. "note that this is initialized here not in the setUp as we normally do" then this is not the problem or werd behavior of BabyMock, SUnit or Pharo. It is a problem of the Test class (and of the one who implemented a test like this) as the developer did then not follow Sunit framework rules and best practice patterns. If you look into Simple Smalltalk Testing: With Patterns from Kent Beck (see http://swing.fit.cvut.cz/projects/stx/doc/online/english/tools/misc/testfra…) it clearly says: "Override setUp to initialize the variables" <quote> Design a test fixture. - Subclass TestCase - Add an instance variable for each known object in the fixture - Override setUp to initialize the variables </quote> One just have to stick to the rules - if not then for sure you might run into side effects or weird behavior. Max wrote: > I understand your grief. My solution: never use #initalize in tests, use > #setUp to initialize instance variables. Yes - I also wonder why you use #initialize instead of #setUp in a test? Also the expectation for someone to read or check a test would be to look in #setUp, not in #initialize because of the SUnit standards. So it is the way SUnit was defined, works and always worked (even unit testing in non Smalltalk solutions): - #setUp 1. setup all nececessary thing BEFORE running or rerunning a test 2. as test's could inherit from other (base) tests the #setUp method should always start with a "super setUp" call - #tearDown 3. cleanup after running each test case 4. as test's could inherit from each other and resources might need to be freed in reverse order (compared to allocation in #setup) the #tearDown should always end with a "super tearDown" call I invested lot of time last year to clean up also tests for Pharo 7: - to follow SUnit standard - to introduce two new ruls (ShouldSendSuperSetUpAsFirstMessage and ShouldSendSuperTearDownAsLastMessage) so developers can see when they violate 2. or 3. - introduced a release test to keep this quality level (see "ProperlyImplementedSUnitClassesTest" checking for alignment with 2. and 3. for all tests in our base image) All our tests follow this standard and use #setUp and if you now check using TestCase allSubclasses select: [:each | each methodDictionary keys includes: #initialize ] the only test who uses #initialize is TimeMeasuringTest but for the sole reason to provide the possibility to measure time when debugging. Which is fine and no violation of the definition and rules. Bye T.

March 20, 2019

[Pharo 8.0] Build #163: 2925-Integrate-latest-version-of-Hiedra

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #163 was: SUCCESS. The Pull Request #2926 was integrated: "2925-Integrate-latest-version-of-Hiedra" Pull request url: https://github.com/pharo-project/pharo/pull/2926 Issue Url: https://pharo.fogbugz.com/f/cases/2925 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2019

[Pharo 8.0] Build #162: 2690-22595-Median-is-not-calculated-correctly-for-even-sizes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #162 was: FAILURE. The Pull Request #2923 was integrated: "2690-22595-Median-is-not-calculated-correctly-for-even-sizes" Pull request url: https://github.com/pharo-project/pharo/pull/2923 Issue Url: https://pharo.fogbugz.com/f/cases/2690 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2019

[Pharo 8.0] Build #161: 2782-Athens-does-not-have-a-way-to-set-and-get-the-fill-rule

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #161 was: FAILURE. The Pull Request #2924 was integrated: "2782-Athens-does-not-have-a-way-to-set-and-get-the-fill-rule" Pull request url: https://github.com/pharo-project/pharo/pull/2924 Issue Url: https://pharo.fogbugz.com/f/cases/2782 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2019

Re: [Pharo-dev] About a better filedialog

by Peter Uhnak

Preview is indeed not supported. My original idea was to show a regular GTInspector view on the file, but I never got around to implementing it. On Tue, Mar 19, 2019 at 8:36 PM Hilaire <hilaire(a)drgeo.eu> wrote: > For DrGeo, when loading a sketch from an arbitrary location, I use the > preview feature of the polymorph File Dialog. I don't see it in this > simple replacement of File Dialog. > > Hilaire > > Le 18/03/2019 Ã 20:31, ducasse a Ã©crit : > > what do you think? > > > > https://github.com/Ducasse/file-dialog > > -- > Dr. Geo > http://drgeo.eu > > > >

March 19, 2019

Re: [Pharo-dev] About a better filedialog

by Hilaire

For DrGeo, when loading a sketch from an arbitrary location,Â I use the preview feature of the polymorph File Dialog. I don't see it in this simple replacement of File Dialog. Hilaire Le 18/03/2019 Ã 20:31, ducasse a Ã©critÂ : > what do you think? > > https://github.com/Ducasse/file-dialog -- Dr. Geo http://drgeo.eu

March 19, 2019

[Pharo 8.0] Build #160: 2918-accessesSlot: should use #isAccessedIn: method

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #160 was: SUCCESS. The Pull Request #2919 was integrated: "2918-accessesSlot: should use #isAccessedIn: method" Pull request url: https://github.com/pharo-project/pharo/pull/2919 Issue Url: https://pharo.fogbugz.com/f/cases/backstop Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 19, 2019