July 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Commenting test classes?

by Cyril Ferlicot D.

Le 04/07/2018 Ã 00:39, Tim Mackinnon a Ã©critÂ : > Au contraire - when looking at a Test - seeing inline the comment of the > class to remind me what Iâm supposed to be testing is actually quite > helpful. I fully expect this is where GtDocumentor is going to take us > (if we integrate it into our tools) - letting us inline things so we > donât have to go and hunt them out. > > In general most of my tests classes are here to test one class, then the name is "NameOfMyClassTests". In that case there is no need for a comment like "I am a test class for NameOfMyClass". I comment tests classes only when it's more functional tests and that they cover a part of the system. But I don't want to have to add comment such as "I am a test class for NameOfMyClass" for the vast majority of my test classes. -- Cyril Ferlicot https://ferlicot.fr

July 3, 2018

Re: [Pharo-dev] Commenting test classes?

by Tim Mackinnon

Au contraire - when looking at a Test - seeing inline the comment of the class to remind me what Iâm supposed to be testing is actually quite helpful. I fully expect this is where GtDocumentor is going to take us (if we integrate it into our tools) - letting us inline things so we donât have to go and hunt them out. > On 3 Jul 2018, at 22:32, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 03.07.2018 um 22:40 schrieb Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > >> And/Or we could display some automatic comment text (unless some is provided). >> >> Somethings like >> >> Tests for Xxx >> >> (Xxx comment eg I am class that provides services....) >> > Another example of counter productivity! > > Norbert >> >> >> >> >> Sent from my iPhone >> >> On 3 Jul 2018, at 20:21, Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> wrote: >> >>> Hi, >>> I think that for TestCase subclasses 90% of the time the comment end up in "Unit test of blablabl". Maybe a really complex test case justifies a comment, but it's not the common case. >>> If we can disable the missing comment feedback on TestCase subclasses I will certainly disable it. >>> >>> On Tue, Jul 3, 2018 at 3:48 PM Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> Hi. >>> >>> I noticed pull requests which add comments to test cases (class comments). >>> I guess the reason is that in Calypso uncommented classes are marked differently than in Nautilus and the exclamation does not disappear when class provides special icon like status of tests. >>> >>> So the question is do we really want people comment test cases? >>> I did not notice any meaningful comment from those PRs. It's like "Unit tests for mirror primitives" for MirrorPrimitiveTests (case 22207 <https://github.com/pharo-project/pharo/pull/1598>). >>> Personally I don't like such approach to put class name with spaces in the comment. It is useless and duplicated. >>> >>> Alternatively I can change uncommented mark to be like in Nautilus. >>> But I like Calypso approach because #systemIcon is not overridden by exclamation. If we want to keep it we need to introduce some #requiresComment to Class which will be overridden by TestCase. >>> >>> So what you think? >>> >>> >>> >>>

July 3, 2018

Re: [Pharo-dev] Commenting test classes?

by Norbert Hartl

> Am 03.07.2018 um 22:40 schrieb Tim Mackinnon <tim(a)testit.works>: > > And/Or we could display some automatic comment text (unless some is provided). > > Somethings like > > Tests for Xxx > > (Xxx comment eg I am class that provides services....) > Another example of counter productivity! Norbert > > > > > Sent from my iPhone > >> On 3 Jul 2018, at 20:21, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >> Hi, >> I think that for TestCase subclasses 90% of the time the comment end up in "Unit test of blablabl". Maybe a really complex test case justifies a comment, but it's not the common case. >> If we can disable the missing comment feedback on TestCase subclasses I will certainly disable it. >> >>> On Tue, Jul 3, 2018 at 3:48 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> Hi. >>> >>> I noticed pull requests which add comments to test cases (class comments). >>> I guess the reason is that in Calypso uncommented classes are marked differently than in Nautilus and the exclamation does not disappear when class provides special icon like status of tests. >>> >>> So the question is do we really want people comment test cases? >>> I did not notice any meaningful comment from those PRs. It's like "Unit tests for mirror primitives" for MirrorPrimitiveTests (case 22207). >>> Personally I don't like such approach to put class name with spaces in the comment. It is useless and duplicated. >>> >>> Alternatively I can change uncommented mark to be like in Nautilus. >>> But I like Calypso approach because #systemIcon is not overridden by exclamation. If we want to keep it we need to introduce some #requiresComment to Class which will be overridden by TestCase. >>> >>> So what you think? >>> >>> >>> >>>

July 3, 2018

Re: [Pharo-dev] Commenting test classes?

by Tim Mackinnon

And/Or we could display some automatic comment text (unless some is provided). Somethings like Tests for Xxx (Xxx comment eg I am class that provides services....) Sent from my iPhone > On 3 Jul 2018, at 20:21, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Hi, > I think that for TestCase subclasses 90% of the time the comment end up in "Unit test of blablabl". Maybe a really complex test case justifies a comment, but it's not the common case. > If we can disable the missing comment feedback on TestCase subclasses I will certainly disable it. > >> On Tue, Jul 3, 2018 at 3:48 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Hi. >> >> I noticed pull requests which add comments to test cases (class comments). >> I guess the reason is that in Calypso uncommented classes are marked differently than in Nautilus and the exclamation does not disappear when class provides special icon like status of tests. >> >> So the question is do we really want people comment test cases? >> I did not notice any meaningful comment from those PRs. It's like "Unit tests for mirror primitives" for MirrorPrimitiveTests (case 22207). >> Personally I don't like such approach to put class name with spaces in the comment. It is useless and duplicated. >> >> Alternatively I can change uncommented mark to be like in Nautilus. >> But I like Calypso approach because #systemIcon is not overridden by exclamation. If we want to keep it we need to introduce some #requiresComment to Class which will be overridden by TestCase. >> >> So what you think? >> >> >> >>

July 3, 2018

Re: [Pharo-dev] Commenting test classes?

by Gabriel Cotelli

Hi, I think that for TestCase subclasses 90% of the time the comment end up in "Unit test of blablabl". Maybe a really complex test case justifies a comment, but it's not the common case. If we can disable the missing comment feedback on TestCase subclasses I will certainly disable it. On Tue, Jul 3, 2018 at 3:48 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I noticed pull requests which add comments to test cases (class comments). > I guess the reason is that in Calypso uncommented classes are marked > differently than in Nautilus and the exclamation does not disappear when > class provides special icon like status of tests. > > So the question is do we really want people comment test cases? > I did not notice any meaningful comment from those PRs. It's like "Unit > tests for mirror primitives" for MirrorPrimitiveTests (case 22207 > <https://github.com/pharo-project/pharo/pull/1598>). > Personally I don't like such approach to put class name with spaces in the > comment. It is useless and duplicated. > > Alternatively I can change uncommented mark to be like in Nautilus. > But I like Calypso approach because #systemIcon is not overridden by > exclamation. If we want to keep it we need to introduce some > #requiresComment to Class which will be overridden by TestCase. > > So what you think? > > > > >

July 3, 2018

Commenting test classes?

by Denis Kudriashov

Hi. I noticed pull requests which add comments to test cases (class comments). I guess the reason is that in Calypso uncommented classes are marked differently than in Nautilus and the exclamation does not disappear when class provides special icon like status of tests. So the question is do we really want people comment test cases? I did not notice any meaningful comment from those PRs. It's like "Unit tests for mirror primitives" for MirrorPrimitiveTests (case 22207 <https://github.com/pharo-project/pharo/pull/1598>). Personally I don't like such approach to put class name with spaces in the comment. It is useless and duplicated. Alternatively I can change uncommented mark to be like in Nautilus. But I like Calypso approach because #systemIcon is not overridden by exclamation. If we want to keep it we need to introduce some #requiresComment to Class which will be overridden by TestCase. So what you think?

July 3, 2018

[Pharo 7.0-dev] Build #1110: 22225 Lint and formatting improvements in Compression package

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

There is a new Pharo build available! The status of the build #1110 was: FAILURE. The Pull Request #1610 was integrated: "22225 Lint and formatting improvements in Compression package" Pull request url: https://github.com/pharo-project/pharo/pull/1610 Issue Url: https://pharo.fogbugz.com/f/cases/22225 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 3, 2018

Re: [Pharo-dev] About the infinite debugger

by Marcus Denker

> On 30 Jun 2018, at 02:56, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Guille, > > On Jun 29, 2018, at 7:48 AM, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > >> Hi all, >> >> during today's sprint we have been working with lots of people on the infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/ <https://pharo.fogbugz.com/f/cases/22085/>). We have checked the emails sent in the latest month. Then, together with Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis all day. We have been also comparing the debuggers code between pharo 3/4 (where the bug was is present) and pharo 7, but this was not necessarily straight forward as the code is not the same and there is no easy diff... > > This is frustrating. I canât see the issue cuz I canât login to fogbugz. Having to login to read an issue is a major flaw. I can see it makes sense for submitting, but fir merely browsing it should be unacceptable. That said... > > The pragma <primitive: 199> actually sets the primitive number in the method, so it it not merely a pragma; it alters bits in the method that the VM uses to search for handler contexts. So why one would do that for evaluateSignal: makes no sense to me. The primitive should be set only in on:do: or something very similar (for example one could imagine adding on:or:do: instead of using , to construct an ExceptionSet). So I think removing it from evaluateSignal: is definitely the right thing to do. > > As far as tests for findNextHandlerFrom:, this is tested implicitly by any nested exception test so I expect you have several tests affected. ClÃ©ment points to a test that fails when not including <primitive: 199> in evaluateSignal: so more investigation is necessary. Difficult to do while bugs are hidden in fogbugz. When are they going to migrate the github where they belong? Yes, the idea was to move the issue tracker to GitHubâ¦ but after the release is done (as it requires changing again some things). The closed-ness of fugbugz is really annoying. Marcus

July 3, 2018

Re: [Pharo-dev] Promote new Pharo 7 VM?

by Alistair Grant

Hi Esteban, On Mon, 18 Jun 2018 at 23:15, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > yes, why not :) > but, remember the cycle: > > 1. two weeks in latest (that starts today) Just a friendly reminder that the two weeks is done... :-) Thanks, Alistair > 2. one month in stable 7.0 > 3. promote to stable 6.1 > > yes, is annoying, but is the scheme has worked the better to avoid problems. > > cheers, > Esteban > > > On 18 Jun 2018, at 14:20, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Esteban, > > > > Would you consider promoting a new Pharo 7 VM? > > > > 140ff02 should finally solve an issue I've had with time zones and DST > > on Windows in the FileAttributesPlugin. > > > > Testing I've done on this VM: > > > > - Loaded up and used my normal dev environment. > > - Run the full automated test suite on: > > -- Linux 64 bit > > -- Linux 32 bit > > -- Win 32 bit > > > > In each case the set of failures in my environment roughly aligns with > > the current stable VM and the proposed one. > > > > I guess if anyone else has any objections they'll reply to this. :-) > > > > Of course, if you've got any questions or concerns, please let me know. > > > > In case it is useful for anyone, download links are: > > > > Linux 64 bit: http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… > > Linux 32 bit: http://files.pharo.org/vm/pharo-spur32/linux/pharo-linux-i386threaded-20180… > > Mac 64 bit: > > - http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201806171702-14… > > - http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201806171702-14… > > Mac 32 bit: > > - http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201806171702-140f… > > - http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201806171702-140f… > > Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201806171702-140f… > > > > > > Thanks! > > Alistair > > > >

July 3, 2018

[Pharo 7.0-dev] Build #1109: 21671 - MemoryStore returns nil for file modificationTime (regression)

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

There is a new Pharo build available! The status of the build #1109 was: FAILURE. The Pull Request #1584 was integrated: "21671 - MemoryStore returns nil for file modificationTime (regression)" Pull request url: https://github.com/pharo-project/pharo/pull/1584 Issue Url: https://pharo.fogbugz.com/f/cases/21671 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 2, 2018