Re: [Pharo-dev] [regression reporter]regression occurred

[Cyril Ferlicot Delbecque]

On 24/02/2016 09:07, Sven Van Caekenberghe wrote:
> The following test seems to be failing a lot lately on the CI infrastructure, 
> yet it always succeeds for me on my machine. Is there anybody who sees this 
> fail on their machines ?
> 
>> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
>>
>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
>>
>> 1 regressions found.
>>  Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
> 
> 

It does not fail all the time but on my Mac with a stable connection with:

20 timesRepeat: [
Transcript show: Time now asString, ': '.
Transcript show: (ZnHTTPSTests new setTestSelector: #testAmazonAWS; 
run);
cr
]

I got:


12:19:52.230023 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:19:53.028736 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:19:53.92617 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:19:55.23689 pm: 1 run, 0 passes, 0 skipped, 0 expected failures, 0
failures, 1 errors, 0 unexpected passes
12:20:35.851549 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:36.991826 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:37.955399 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:38.930401 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:39.81128 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:40.775596 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:42.524211 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:43.326577 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:44.291269 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:45.313826 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:46.949006 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:48.581509 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:49.546702 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:50.435629 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:51.403718 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes
12:20:53.225974 pm: 1 run, 1 passes, 0 skipped, 0 expected failures, 0
failures, 0 errors, 0 unexpected passes


So there was one test that failed.

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] [regression reporter]regression occurred

[Max Leske]

> On 24 Feb 2016, at 11:21, Sven Van Caekenberghe  wrote:
> 
> 
>> On 24 Feb 2016, at 11:09, Max Leske  wrote:
>> 
>> Here’s an idea:
>> 
>> 1. exclude Zinc tests from the validation tests
>> 2. after the build, trigger a Travis build on Github via API (I just set 
>> that up for Fuel, so I can provide help there)
>> 3. the Travis build only runs the Zinc tests
>> 4. read build results from Travis
>> 
>> Very ugly, I know. But it’s done rather quickly and should solve all the 
>> network problems.
> 
> I don't think the current problem is severe enough to put much work in it, 
> right now.
> 
> But would it not be much better to run everything (all tests) on Travis ? 
> 
> At first, maybe just as a limited experiment ? I would love to see that.

Sure. That wouldn’t be hard (although I think support for Windows is missing 
for the Smalltalk language, but I’m sure Fabio Niephaus would help us out 
there). We could use the Jenkins job as a trigger (or create a second job for 
experimenting first). In the long run, we probably would want to use the push / 
pull request hook to trigger the build but for quickly hacking things together 
I suggest using the API trigger.

I don’t have enough permissions on Github and Jenkins to pull this off alone 
but I’d be happy to help setting up the Travis stuff and providing the trigger 
script.

> 
>> Max
>> 
>>> On 24 Feb 2016, at 11:01, Marcus Denker  wrote:
>>> 
>>> The problem is that managing a CI server for a project like Pharo would be
>>> one full time engineer in a company, we do not have the manpower.
>>> 
>>> So we need to find solutions that are cheap to do.
>>> 
 On 24 Feb 2016, at 10:50, Ben Coman  wrote:
 
 Maybe there can be a pre-test run at the shell level to flag that the
 required network connectivity is available to run that test inside the
 image. Pharo startup could read them in while starting.
 cheers -ben
 
 On Wed, Feb 24, 2016 at 5:38 PM, Marcus Denker  
 wrote:
> one idea could be to add this to the filter of the CI runner.
> 
> It seems it fails due to network setup problems that are specific to the 
> CI server...
> 
>> On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
>> 
>> The following test seems to be failing a lot lately on the CI 
>> infrastructure, yet it always succeeds for me on my machine. Is there 
>> anybody who sees this fail on their machines ?
>> 
>>> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
>>> 
>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
>>> 
>>> 1 regressions found.
>>> Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
>> 
>> 
> 
> 
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

> On 24 Feb 2016, at 11:09, Max Leske  wrote:
> 
> Here’s an idea:
> 
> 1. exclude Zinc tests from the validation tests
> 2. after the build, trigger a Travis build on Github via API (I just set that 
> up for Fuel, so I can provide help there)
> 3. the Travis build only runs the Zinc tests
> 4. read build results from Travis
> 
> Very ugly, I know. But it’s done rather quickly and should solve all the 
> network problems.

I don't think the current problem is severe enough to put much work in it, 
right now.

But would it not be much better to run everything (all tests) on Travis ? 

At first, maybe just as a limited experiment ? I would love to see that.

> Max
> 
>> On 24 Feb 2016, at 11:01, Marcus Denker  wrote:
>> 
>> The problem is that managing a CI server for a project like Pharo would be
>> one full time engineer in a company, we do not have the manpower.
>> 
>> So we need to find solutions that are cheap to do.
>> 
>>> On 24 Feb 2016, at 10:50, Ben Coman  wrote:
>>> 
>>> Maybe there can be a pre-test run at the shell level to flag that the
>>> required network connectivity is available to run that test inside the
>>> image. Pharo startup could read them in while starting.
>>> cheers -ben
>>> 
>>> On Wed, Feb 24, 2016 at 5:38 PM, Marcus Denker  
>>> wrote:
 one idea could be to add this to the filter of the CI runner.
 
 It seems it fails due to network setup problems that are specific to the 
 CI server...
 
> On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
> 
> The following test seems to be failing a lot lately on the CI 
> infrastructure, yet it always succeeds for me on my machine. Is there 
> anybody who sees this fail on their machines ?
> 
>> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
>> 
>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
>> 
>> 1 regressions found.
>> Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
> 
> 
 
 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Max Leske]

Here’s an idea:

1. exclude Zinc tests from the validation tests
2. after the build, trigger a Travis build on Github via API (I just set that 
up for Fuel, so I can provide help there)
3. the Travis build only runs the Zinc tests
4. read build results from Travis

Very ugly, I know. But it’s done rather quickly and should solve all the 
network problems.

Max

> On 24 Feb 2016, at 11:01, Marcus Denker  wrote:
> 
> The problem is that managing a CI server for a project like Pharo would be
> one full time engineer in a company, we do not have the manpower.
> 
> So we need to find solutions that are cheap to do.
> 
>> On 24 Feb 2016, at 10:50, Ben Coman  wrote:
>> 
>> Maybe there can be a pre-test run at the shell level to flag that the
>> required network connectivity is available to run that test inside the
>> image. Pharo startup could read them in while starting.
>> cheers -ben
>> 
>> On Wed, Feb 24, 2016 at 5:38 PM, Marcus Denker  
>> wrote:
>>> one idea could be to add this to the filter of the CI runner.
>>> 
>>> It seems it fails due to network setup problems that are specific to the CI 
>>> server...
>>> 
 On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
 
 The following test seems to be failing a lot lately on the CI 
 infrastructure, yet it always succeeds for me on my machine. Is there 
 anybody who sees this fail on their machines ?
 
> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
> 
> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
> 
> 1 regressions found.
> Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
 
 
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

The problem is that managing a CI server for a project like Pharo would be
one full time engineer in a company, we do not have the manpower.

So we need to find solutions that are cheap to do.

> On 24 Feb 2016, at 10:50, Ben Coman  wrote:
> 
> Maybe there can be a pre-test run at the shell level to flag that the
> required network connectivity is available to run that test inside the
> image. Pharo startup could read them in while starting.
> cheers -ben
> 
> On Wed, Feb 24, 2016 at 5:38 PM, Marcus Denker  wrote:
>> one idea could be to add this to the filter of the CI runner.
>> 
>> It seems it fails due to network setup problems that are specific to the CI 
>> server...
>> 
>>> On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
>>> 
>>> The following test seems to be failing a lot lately on the CI 
>>> infrastructure, yet it always succeeds for me on my machine. Is there 
>>> anybody who sees this fail on their machines ?
>>> 
 On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
 
 https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
 
 1 regressions found.
 Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
>>> 
>>> 
>> 
>> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

> On 24 Feb 2016, at 10:50, Ben Coman  wrote:
> 
> Maybe there can be a pre-test run at the shell level to flag that the
> required network connectivity is available to run that test inside the
> image. Pharo startup could read them in while starting.

These networking problems are issues specific to the CI infrastructure. But 
these are real bugs: we don't know why they happen, we have no idea. It is not 
that there is no network, else almost everything would fail immediately. It 
should not be too much asked in the 21st century for a server to be able to 
access any website, right ?

> cheers -ben
> 
> On Wed, Feb 24, 2016 at 5:38 PM, Marcus Denker  wrote:
>> one idea could be to add this to the filter of the CI runner.
>> 
>> It seems it fails due to network setup problems that are specific to the CI 
>> server...
>> 
>>> On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
>>> 
>>> The following test seems to be failing a lot lately on the CI 
>>> infrastructure, yet it always succeeds for me on my machine. Is there 
>>> anybody who sees this fail on their machines ?
>>> 
 On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
 
 https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
 
 1 regressions found.
 Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
>>> 
>>> 
>> 
>> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Ben Coman]

Maybe there can be a pre-test run at the shell level to flag that the
required network connectivity is available to run that test inside the
image. Pharo startup could read them in while starting.
cheers -ben

On Wed, Feb 24, 2016 at 5:38 PM, Marcus Denker  wrote:
> one idea could be to add this to the filter of the CI runner.
>
> It seems it fails due to network setup problems that are specific to the CI 
> server...
>
>> On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
>>
>> The following test seems to be failing a lot lately on the CI 
>> infrastructure, yet it always succeeds for me on my machine. Is there 
>> anybody who sees this fail on their machines ?
>>
>>> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
>>>
>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
>>>
>>> 1 regressions found.
>>> Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
>>
>>
>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Ben Coman]

On Wed, Feb 24, 2016 at 4:07 PM, Sven Van Caekenberghe  wrote:
> The following test seems to be failing a lot lately on the CI infrastructure,

On a related topic, its hard for an individual person to notice when
this sort of commonly failing test occurs.  All they see is the one
issue they are working on. Having a daily email of the top 5 failing
tests would help  quicker squash such cases. But probably just an idea
for the back burner.
cheers -ben

> yet it always succeeds for me on my machine. Is there anybody who sees this 
> fail on their machines ?
>
>> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
>>
>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
>>
>> 1 regressions found.
>>  Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

one idea could be to add this to the filter of the CI runner.

It seems it fails due to network setup problems that are specific to the CI 
server...

> On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
> 
> The following test seems to be failing a lot lately on the CI infrastructure, 
> yet it always succeeds for me on my machine. Is there anybody who sees this 
> fail on their machines ?
> 
>> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
>> 
>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
>> 
>> 1 regressions found.
>> Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Max Leske]

OS X 10.11.3

./pharo Pharo.image test --junit-xml-output 
'^(?!Metacello)(?!NativeBoost)[M-Z].*'

4146 run, 4122 passes, 17 failures, 7 errors.


Output from the CI build:

4146 run, 4121 passes, 17 failures, 8 errors.

> On 24 Feb 2016, at 09:07, Sven Van Caekenberghe  wrote:
> 
> The following test seems to be failing a lot lately on the CI infrastructure, 
> yet it always succeeds for me on my machine. Is there anybody who sees this 
> fail on their machines ?
> 
>> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
>> 
>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
>> 
>> 1 regressions found.
>> Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

The following test seems to be failing a lot lately on the CI infrastructure, 
yet it always succeeds for me on my machine. Is there anybody who sees this 
fail on their machines ?

> On 24 Feb 2016, at 08:36, no-re...@ci.inria.fr wrote:
> 
> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=mac/755/
> 
> 1 regressions found.
>  Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

> On 08 Jan 2016, at 09:05, no-re...@ci.inria.fr wrote:
> 
> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-A-L/label=mac/643/
> 
> 4 regressions found.
>  Collections.Tests.Strings.StringTest.testUnCategorizedMethods
>  Kernel.Tests.Classes.BehaviorTest.testUnCategorizedMethods
>  Kernel.Tests.Methods.CompiledMethodTest.testComparison
>  Kernel.Tests.Objects.ObjectTest.testUnCategorizedMethods

https://pharo.fogbugz.com/f/cases/17345/Fix-some-uncategorized-methods-left-after-spur-conversion

Re: [Pharo-dev] [regression reporter]regression occurred

[Andrei Chis]

On Fri, Feb 27, 2015 at 6:03 PM, Andrei Chis 
wrote:

> Thanks :)
> We would still want to do one more update, maybe today or tomorrow, to add
> the extension for recording user data.
>

The last update for GTools that adds a bigger features is ready for review:
https://pharo.fogbugz.com/f/cases/15018/Integrate-GT-tools-with-event-recoder-in-spotter



Cheers,
Andrei



> Afterwards it's bug fixing mode.
>
> On Fri, Feb 27, 2015 at 5:37 PM, Marcus Denker 
> wrote:
>
>>
>>
>> On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis > > wrote:
>>
>>> The issue is waiting integration:
>>> https://pharo.fogbugz.com/f/cases/14993/Integrate-GTools
>>> There are still some more bugs to fix but we should integrate
>>> nevertheless.
>>>
>>
>> In 40 update #520
>>
>> Marcus
>>
>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Tudor Girba]

Thank you!

Doru

On Fri, Feb 27, 2015 at 5:37 PM, Marcus Denker 
wrote:

>
>
> On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis 
> wrote:
>
>> The issue is waiting integration:
>> https://pharo.fogbugz.com/f/cases/14993/Integrate-GTools
>> There are still some more bugs to fix but we should integrate
>> nevertheless.
>>
>
> In 40 update #520
>
> Marcus
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] [regression reporter]regression occurred

[Andrei Chis]

Thanks :)
We would still want to do one more update, maybe today or tomorrow, to add
the extension for recording user data.
Afterwards it's bug fixing mode.

On Fri, Feb 27, 2015 at 5:37 PM, Marcus Denker 
wrote:

>
>
> On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis 
> wrote:
>
>> The issue is waiting integration:
>> https://pharo.fogbugz.com/f/cases/14993/Integrate-GTools
>> There are still some more bugs to fix but we should integrate
>> nevertheless.
>>
>
> In 40 update #520
>
> Marcus
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On Fri, Feb 27, 2015 at 10:22 AM, Andrei Chis 
wrote:

> The issue is waiting integration:
> https://pharo.fogbugz.com/f/cases/14993/Integrate-GTools
> There are still some more bugs to fix but we should integrate nevertheless.
>

In 40 update #520

Marcus

Re: [Pharo-dev] [regression reporter]regression occurred

[Andrei Chis]

The issue is waiting integration:
https://pharo.fogbugz.com/f/cases/14993/Integrate-GTools
There are still some more bugs to fix but we should integrate nevertheless.

Cheers,
Andrei

On Thu, Feb 26, 2015 at 3:46 PM, Sven Van Caekenberghe  wrote:

>
> > On 26 Feb 2015, at 15:35, Ben Coman  wrote:
> >
> >> On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe"  wrote:
> >> Number>>#brickValue: must die !
> >>
> >> > On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote:
> >> >
> >> >
> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
> >> >
> >> > 1 regressions found.
> >> >
> KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
> >>
> >>
> >
> > On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker 
> wrote:
> >
> >> On 25 Feb 2015, at 16:04, Aliaksei Syrel  wrote:
> >> It is already fixed and will be integrated with GT
> >>
> > When will this happen? this test fails since *WEEKS*, yet I could have
> fixed it in 5 minutes. But I can’t.
> > We make ourselves completely powerless. This does not make me feel good.
> >
> > On Wed, Feb 25, 2015 at 11:11 PM, Aliaksei Syrel 
> wrote:
> >
> > Normally GT should be released more often. This time while Jenkins was
> down we did a lot of changes and now it takes some time to prepare
> everything for integration. Also at the moment of previous release moose
> didn't run tests like BehaviourTest and others. :)
> >
> >
> >
> > Thats a fair reason, but philosophically we still have a feature branch
> holding up a bug fix, because we have a a single-branch workflow.
>  Consider a future where Pharo has more external packages, where a
> hypothetical package (with less diligent developers than GT) has a longer
> feature development cycle.  Should bug fixes be held up?  Or should
> external packages have a bug-fix-branch and a feature-development-branch -
> with a workflow where before the feature-development-branch is integrated,
> it merges in any bug-fix-branch commits.
>
> I think that in certain cases (something urgent, something really
> annoying) it would be OK to patch it directly. It is then up to the
> external package maintainers to pick up the change up stream.
>
> Working with components/modules should not limit what we do.
>
> Of course, for new features this would not be OK.
>
> > p.s. It would be interesting if we could get a github-style commit
> network graph derived from mcz files.
> >
> > cheers -ben
> >
>
>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

> On 26 Feb 2015, at 15:35, Ben Coman  wrote:
> 
>> On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe"  wrote:
>> Number>>#brickValue: must die !
>> 
>> > On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote:
>> >
>> > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
>> >
>> > 1 regressions found.
>> >  
>> > KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
>> 
>> 
> 
> On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker  wrote:
> 
>> On 25 Feb 2015, at 16:04, Aliaksei Syrel  wrote:
>> It is already fixed and will be integrated with GT
>> 
> When will this happen? this test fails since *WEEKS*, yet I could have fixed 
> it in 5 minutes. But I can’t.
> We make ourselves completely powerless. This does not make me feel good. 
>  
> On Wed, Feb 25, 2015 at 11:11 PM, Aliaksei Syrel  wrote:
> 
> Normally GT should be released more often. This time while Jenkins was down 
> we did a lot of changes and now it takes some time to prepare everything for 
> integration. Also at the moment of previous release moose didn't run tests 
> like BehaviourTest and others. :)
> 
> 
> 
> Thats a fair reason, but philosophically we still have a feature branch 
> holding up a bug fix, because we have a a single-branch workflow.   Consider 
> a future where Pharo has more external packages, where a hypothetical package 
> (with less diligent developers than GT) has a longer feature development 
> cycle.  Should bug fixes be held up?  Or should external packages have a 
> bug-fix-branch and a feature-development-branch - with a workflow where 
> before the feature-development-branch is integrated, it merges in any 
> bug-fix-branch commits.

I think that in certain cases (something urgent, something really annoying) it 
would be OK to patch it directly. It is then up to the external package 
maintainers to pick up the change up stream.

Working with components/modules should not limit what we do.

Of course, for new features this would not be OK.

> p.s. It would be interesting if we could get a github-style commit network 
> graph derived from mcz files.
> 
> cheers -ben 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Ben Coman]

On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe"  wrote:

> Number>>#brickValue: must die !
>
> > On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote:
> >
> >
> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
> >
> > 1 regressions found.
> >
> KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
>
>
>
On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker 
 wrote:

>
> On 25 Feb 2015, at 16:04, Aliaksei Syrel  wrote:
>
> It is already fixed and will be integrated with GT
>
> When will this happen? this test fails since *WEEKS*, yet I could have
> fixed it in 5 minutes. But I can’t.
> We make ourselves completely powerless. This does not make me feel good.
>

On Wed, Feb 25, 2015 at 11:11 PM, Aliaksei Syrel 
wrote:
>
>
> Normally GT should be released more often. This time while Jenkins was
> down we did a lot of changes and now it takes some time to prepare
> everything for integration. Also at the moment of previous release moose
> didn't run tests like BehaviourTest and others. :)
>
>
>
Thats a fair reason, but philosophically we still have a feature branch
holding up a bug fix, because we have a a single-branch workflow.
Consider a future where Pharo has more external packages, where a
hypothetical package (with less diligent developers than GT) has a longer
feature development cycle.  Should bug fixes be held up?  Or should
external packages have a bug-fix-branch and a feature-development-branch -
with a workflow where before the feature-development-branch is integrated,
it merges in any bug-fix-branch commits.

p.s. It would be interesting if we could get a github-style commit network
graph derived from mcz files.

cheers -ben

Re: [Pharo-dev] [regression reporter]regression occurred

[Tudor Girba]

The next integration will happen tomorrow. Andrei is preparing it.

Doru

--
www.tudorgirba.com

"Every thing has its own flow"

> On 25 Feb 2015, at 16:11, Aliaksei Syrel  wrote:
> 
> Hi, 
>> When will this happen? this test fails since *WEEKS*, yet I could have fixed 
>> it in 5 minutes. But I can’t.
>> We make ourselves completely powerless. This does not make me feel good. 
> 
> Normally GT should be released more often. This time while Jenkins was down 
> we did a lot of changes and now it takes some time to prepare everything for 
> integration. Also at the moment of previous release moose didn't run tests 
> like BehaviourTest and others. :)
> 
> Cheers,
> Alex 
> 
>> On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker  
>> wrote:
>> 
>>> On 25 Feb 2015, at 16:04, Aliaksei Syrel  wrote:
>>> 
>>> Hi,
>>> 
>>> It is already fixed and will be integrated with GT
>>> 
>> 
>> When will this happen? this test fails since *WEEKS*, yet I could have fixed 
>> it in 5 minutes. But I can’t.
>> We make ourselves completely powerless. This does not make me feel good. 
>> 
>> 
 On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe"  wrote:
 Number>>#brickValue: must die !
 
 > On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote:
 >
 > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
 >
 > 1 regressions found.
 >  
 > KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
 
 
>> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Aliaksei Syrel]

Hi,

> When will this happen? this test fails since *WEEKS*, yet I could have
> fixed it in 5 minutes. But I can’t.
> We make ourselves completely powerless. This does not make me feel good.


Normally GT should be released more often. This time while Jenkins was down
we did a lot of changes and now it takes some time to prepare everything
for integration. Also at the moment of previous release moose didn't run
tests like BehaviourTest and others. :)

Cheers,
Alex

On Wed, Feb 25, 2015 at 4:07 PM, Marcus Denker 
wrote:

>
> On 25 Feb 2015, at 16:04, Aliaksei Syrel  wrote:
>
> Hi,
>
> It is already fixed and will be integrated with GT
>
> When will this happen? this test fails since *WEEKS*, yet I could have
> fixed it in 5 minutes. But I can’t.
> We make ourselves completely powerless. This does not make me feel good.
>
>
> On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe"  wrote:
>
>> Number>>#brickValue: must die !
>>
>> > On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote:
>> >
>> >
>> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
>> >
>> > 1 regressions found.
>> >
>> KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
>>
>>
>>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Aliaksei Syrel]

Hi,

It is already fixed and will be integrated with GT
On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe"  wrote:

> Number>>#brickValue: must die !
>
> > On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote:
> >
> >
> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
> >
> > 1 regressions found.
> >
> KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
>
>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

> On 25 Feb 2015, at 16:04, Aliaksei Syrel  wrote:
> 
> Hi,
> 
> It is already fixed and will be integrated with GT
> 
When will this happen? this test fails since *WEEKS*, yet I could have fixed it 
in 5 minutes. But I can’t.
We make ourselves completely powerless. This does not make me feel good. 


> On Feb 25, 2015 3:58 PM, "Sven Van Caekenberghe"  > wrote:
> Number>>#brickValue: must die !
> 
> > On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr 
> >  wrote:
> >
> > https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
> >  
> > 
> >
> > 1 regressions found.
> >  
> > KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

Number>>#brickValue: must die !

> On 25 Feb 2015, at 15:53, no-re...@ci.inria.fr wrote:
> 
> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/585/
> 
> 1 regressions found.
>  
> KernelTests.Numbers.NumberTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

I added a SLICE to 
https://pharo.fogbugz.com/f/cases/13395/Add-SHA256-HashFunction that adds the 
comment

On 26 Jun 2014, at 08:57, Sven Van Caekenberghe  wrote:

> 
> On 26 Jun 2014, at 08:35, Marcus Denker  wrote:
> 
>> 
>> On 26 Jun 2014, at 08:20, Sven Van Caekenberghe  wrote:
>> 
>>> I have not yet downloaded a latest image and tried it myself, but I do not 
>>> understand why
>>> 
>>> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/lastCompletedBuild/testReport/Tests.System.Hashing/SHA256Test/testClassComment/
>>> 
>>> fails, it does not fail in my working image (see my file out).
>>> 
>>> That is the only problem left, the renaming is not necessary if this 
>>> problem can be fixed.
>>> 
>> 
>> Nautilus does not run the tests that are inherited (we should fix that).
>> 
>> If you use the Testrunner, the test fails.
> 
> I know.
> 
>> It can be fixed by adding a class comment.
> 
> I never publish anything without a class comment, it was there in the file 
> out, SHA256.st
> 
> I will have a look at the 40 image myself.

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

On 26 Jun 2014, at 08:35, Marcus Denker  wrote:

> 
> On 26 Jun 2014, at 08:20, Sven Van Caekenberghe  wrote:
> 
>> I have not yet downloaded a latest image and tried it myself, but I do not 
>> understand why
>> 
>> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/lastCompletedBuild/testReport/Tests.System.Hashing/SHA256Test/testClassComment/
>> 
>> fails, it does not fail in my working image (see my file out).
>> 
>> That is the only problem left, the renaming is not necessary if this problem 
>> can be fixed.
>> 
> 
> Nautilus does not run the tests that are inherited (we should fix that).
> 
> If you use the Testrunner, the test fails.

I know.

> It can be fixed by adding a class comment.

I never publish anything without a class comment, it was there in the file out, 
SHA256.st

I will have a look at the 40 image myself.

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On 26 Jun 2014, at 08:20, Sven Van Caekenberghe  wrote:

> I have not yet downloaded a latest image and tried it myself, but I do not 
> understand why
> 
> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/lastCompletedBuild/testReport/Tests.System.Hashing/SHA256Test/testClassComment/
> 
> fails, it does not fail in my working image (see my file out).
> 
> That is the only problem left, the renaming is not necessary if this problem 
> can be fixed.
> 

Nautilus does not run the tests that are inherited (we should fix that).

If you use the Testrunner, the test fails.

It can be fixed by adding a class comment.

Marcus

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

I have not yet downloaded a latest image and tried it myself, but I do not 
understand why

https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/lastCompletedBuild/testReport/Tests.System.Hashing/SHA256Test/testClassComment/

fails, it does not fail in my working image (see my file out).

That is the only problem left, the renaming is not necessary if this problem 
can be fixed.

On 26 Jun 2014, at 08:15, Marcus Denker  wrote:

> 
> On 26 Jun 2014, at 08:13, Sven Van Caekenberghe  wrote:
> 
>> I reopened https://pharo.fogbugz.com/f/cases/13395/Add-SHA256-HashFunction
>> 
> 
> Why? i fixed that already yesterday (by renaming the class so the default 
> works…)
> 
> Is it important to re-name it again and add the #classToBeTested?
> 
>> On 26 Jun 2014, at 07:45, stepharo  wrote:
>> 
>>> no problem open a bug entry.
>>> 
>>> Stef
>>> 
>>> On 25/6/14 10:37, Sven Van Caekenberghe wrote:
 On 25 Jun 2014, at 10:06, no-re...@ci.inria.fr wrote:
 
> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/45/
> 
> 5 regressions found.
> Tests.System.Hashing.SHA256Tests.testClassComment
> Tests.System.Hashing.SHA256Tests.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
> Tests.System.Hashing.SHA256Tests.testNew
> Tests.System.Hashing.SHA256Tests.testTraitExplicitRequirementMethodsMustBeImplementedInTheClassOrInASuperclass
> Tests.System.Hashing.SHA256Tests.testUnCategorizedMethods
 I didn't see that SHA256Tests subclassed ClassTestCase (I copied it from 
 SHA1Test), this needs to be added in protocol 'coverage' of SHA256Tests, 
 instance side:
 
 classToBeTested
 ^ SHA256
 
 Sorry about that.
 
 Sven
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On 26 Jun 2014, at 08:13, Sven Van Caekenberghe  wrote:

> I reopened https://pharo.fogbugz.com/f/cases/13395/Add-SHA256-HashFunction
> 

Why? i fixed that already yesterday (by renaming the class so the default 
works…)

Is it important to re-name it again and add the #classToBeTested?

> On 26 Jun 2014, at 07:45, stepharo  wrote:
> 
>> no problem open a bug entry.
>> 
>> Stef
>> 
>> On 25/6/14 10:37, Sven Van Caekenberghe wrote:
>>> On 25 Jun 2014, at 10:06, no-re...@ci.inria.fr wrote:
>>> 
 https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/45/
 
 5 regressions found.
 Tests.System.Hashing.SHA256Tests.testClassComment
 Tests.System.Hashing.SHA256Tests.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
 Tests.System.Hashing.SHA256Tests.testNew
 Tests.System.Hashing.SHA256Tests.testTraitExplicitRequirementMethodsMustBeImplementedInTheClassOrInASuperclass
 Tests.System.Hashing.SHA256Tests.testUnCategorizedMethods
>>> I didn't see that SHA256Tests subclassed ClassTestCase (I copied it from 
>>> SHA1Test), this needs to be added in protocol 'coverage' of SHA256Tests, 
>>> instance side:
>>> 
>>> classToBeTested
>>>  ^ SHA256
>>> 
>>> Sorry about that.
>>> 
>>> Sven
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

I reopened https://pharo.fogbugz.com/f/cases/13395/Add-SHA256-HashFunction

On 26 Jun 2014, at 07:45, stepharo  wrote:

> no problem open a bug entry.
> 
> Stef
> 
> On 25/6/14 10:37, Sven Van Caekenberghe wrote:
>> On 25 Jun 2014, at 10:06, no-re...@ci.inria.fr wrote:
>> 
>>> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/45/
>>> 
>>> 5 regressions found.
>>>  Tests.System.Hashing.SHA256Tests.testClassComment
>>>  
>>> Tests.System.Hashing.SHA256Tests.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
>>>  Tests.System.Hashing.SHA256Tests.testNew
>>>  
>>> Tests.System.Hashing.SHA256Tests.testTraitExplicitRequirementMethodsMustBeImplementedInTheClassOrInASuperclass
>>>  Tests.System.Hashing.SHA256Tests.testUnCategorizedMethods
>> I didn't see that SHA256Tests subclassed ClassTestCase (I copied it from 
>> SHA1Test), this needs to be added in protocol 'coverage' of SHA256Tests, 
>> instance side:
>> 
>> classToBeTested
>>   ^ SHA256
>> 
>> Sorry about that.
>> 
>> Sven
>> 
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[stepharo]

no problem open a bug entry.

Stef

On 25/6/14 10:37, Sven Van Caekenberghe wrote:

On 25 Jun 2014, at 10:06, no-re...@ci.inria.fr wrote:


https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/45/

5 regressions found.
  Tests.System.Hashing.SHA256Tests.testClassComment
  
Tests.System.Hashing.SHA256Tests.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
  Tests.System.Hashing.SHA256Tests.testNew
  
Tests.System.Hashing.SHA256Tests.testTraitExplicitRequirementMethodsMustBeImplementedInTheClassOrInASuperclass
  Tests.System.Hashing.SHA256Tests.testUnCategorizedMethods

I didn't see that SHA256Tests subclassed ClassTestCase (I copied it from 
SHA1Test), this needs to be added in protocol 'coverage' of SHA256Tests, 
instance side:

classToBeTested
   ^ SHA256

Sorry about that.

Sven

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

On 25 Jun 2014, at 10:06, no-re...@ci.inria.fr wrote:

> https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-2.1-Validation-M-Z/label=mac/45/
> 
> 5 regressions found.
>  Tests.System.Hashing.SHA256Tests.testClassComment
>  
> Tests.System.Hashing.SHA256Tests.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses
>  Tests.System.Hashing.SHA256Tests.testNew
>  
> Tests.System.Hashing.SHA256Tests.testTraitExplicitRequirementMethodsMustBeImplementedInTheClassOrInASuperclass
>  Tests.System.Hashing.SHA256Tests.testUnCategorizedMethods

I didn't see that SHA256Tests subclassed ClassTestCase (I copied it from 
SHA1Test), this needs to be added in protocol 'coverage' of SHA256Tests, 
instance side:

classToBeTested
  ^ SHA256

Sorry about that.

Sven

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

On 2014-02-20, at 15:18, Marcus Denker  wrote:

> 
> On 20 Feb 2014, at 13:57, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 20 Feb 2014, at 13:32, Camillo Bruni  wrote:
>> 
>>> This test is really fragile... If you look at the code you'll see that
>>> it has already been patched to cope with some defects under linux.
>>> 
>>> - Maybe one try is to increase the wait time?
>>> - make sure the fork happens at higher priority than the surrounding thread
>>> - skip it :P
>> 
>> Someone should make a choice…
> 
> I vote for skipping it for now

Fine with me: skip + issue tracker entry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On 20 Feb 2014, at 13:57, Sven Van Caekenberghe  wrote:

> 
> On 20 Feb 2014, at 13:32, Camillo Bruni  wrote:
> 
>> This test is really fragile... If you look at the code you'll see that
>> it has already been patched to cope with some defects under linux.
>> 
>> - Maybe one try is to increase the wait time?
>> - make sure the fork happens at higher priority than the surrounding thread
>> - skip it :P
> 
> Someone should make a choice…

I vote for skipping it for now

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

On 20 Feb 2014, at 13:32, Camillo Bruni  wrote:

> This test is really fragile... If you look at the code you'll see that
> it has already been patched to cope with some defects under linux.
> 
> - Maybe one try is to increase the wait time?
> - make sure the fork happens at higher priority than the surrounding thread
> - skip it :P

Someone should make a choice...

> On 2014-02-20, at 11:09, Sven Van Caekenberghe  wrote:
>> Camillo (as you wrote this stuff),
>> 
>> The test below often fails on the CI servers (as now again in the last two 
>> builds), timing tests are brittle there.
>> 
>> Is this test necessary the way it is written now, what do you think ?
>> 
>> Sven
>> 
>> Begin forwarded message:
>> 
>>> From: no-re...@ci.inria.fr
>>> Subject: [regression reporter]regression occurred
>>> Date: 26 Jan 2014 16:17:25 GMT+1
>>> To: marcus.den...@inria.fr, esteba...@gmail.com, s...@stfx.eu
>>> 
>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label=win/891/
>>> 
>>> 1 regressions found.
>>> KernelTests.Methods.BlockClosureTest.testOnForkErrorTakesLessThanOneSecond
>> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

This test is really fragile... If you look at the code you'll see that
it has already been patched to cope with some defects under linux.

- Maybe one try is to increase the wait time?
- make sure the fork happens at higher priority than the surrounding thread
- skip it :P

On 2014-02-20, at 11:09, Sven Van Caekenberghe  wrote:
> Camillo (as you wrote this stuff),
> 
> The test below often fails on the CI servers (as now again in the last two 
> builds), timing tests are brittle there.
> 
> Is this test necessary the way it is written now, what do you think ?
> 
> Sven
> 
> Begin forwarded message:
> 
>> From: no-re...@ci.inria.fr
>> Subject: [regression reporter]regression occurred
>> Date: 26 Jan 2014 16:17:25 GMT+1
>> To: marcus.den...@inria.fr, esteba...@gmail.com, s...@stfx.eu
>> 
>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label=win/891/
>> 
>> 1 regressions found.
>> KernelTests.Methods.BlockClosureTest.testOnForkErrorTakesLessThanOneSecond
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On 26 Jan 2014, at 16:25, Sven Van Caekenberghe  wrote:

> Camillo (as you wrote this stuff),
> 

he is nit subscribe to the list as he needs to finish writing the thesis, try 
send him a private mail.

> The test below often fails on the CI servers, timing tests are brittle there.
> 
> Is this test necessary the way it is written now, what do you think ?
> 
> Sven
> 
> Begin forwarded message:
> 
>> From: no-re...@ci.inria.fr
>> Subject: [regression reporter]regression occurred
>> Date: 26 Jan 2014 16:17:25 GMT+1
>> To: marcus.den...@inria.fr, esteba...@gmail.com, s...@stfx.eu
>> 
>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label=win/891/
>> 
>> 1 regressions found.
>> KernelTests.Methods.BlockClosureTest.testOnForkErrorTakesLessThanOneSecond
> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On 22 Jan 2014, at 16:49, Sven Van Caekenberghe  wrote:

> 
> On 22 Jan 2014, at 16:43, no-re...@ci.inria.fr wrote:
> 
>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label=win/884/
>> 
>> 1 regressions found.
>> KernelTests.Methods.BlockClosureTest.testOnForkErrorTakesLessThanOneSecond
> 
> I think that all tests with time constraints are brittle: sometimes the 
> slaves are extremely slow. I had a couple of these in my packages and I 
> changed them all to just run without the time constraint.

yes, we should do that.

Marcus

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

On 22 Jan 2014, at 16:43, no-re...@ci.inria.fr wrote:

> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label=win/884/
> 
> 1 regressions found.
>  KernelTests.Methods.BlockClosureTest.testOnForkErrorTakesLessThanOneSecond

I think that all tests with time constraints are brittle: sometimes the slaves 
are extremely slow. I had a couple of these in my packages and I changed them 
all to just run without the time constraint.

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

The idea would be that the whole integration fails with only a single test 
failing.
But for that the monkey has to be at 100% ;) and we're at 95% or so and only 
integrate
a single issue at a time and then rerun all validations, but thats future talk.

For now, I think the only reasonable thing is to look at the build each friday 
and
make it green, since classifying tests is not that easy, and the jenkins setup 
is
already close to be unmaintainable.

On 2013-10-21, at 23:24, Sven Van Caekenberghe  wrote:
> Tests that fail indicate that something is broken. They are like a kind of 
> todo. But sometimes they are hard to fix and remain open for a long time. I 
> understand that that conflicts with the notion of being 'all green all the 
> time'. Maybe we should classify them somehow ?
> 
> On 21 Oct 2013, at 23:08, Camillo Bruni  wrote:
> 
>> sad but true :(
>> 
>> On 2013-10-21, at 08:37, Marcus Denker  wrote:
>> 
>>> I have turned off these emails for now, they are too many and thus get 
>>> ignored
>>> (I have never seen anyone but me filing an issue tracker entry for a newly 
>>> failing test…)
>>> 
>>> Marcus
>>> 
>>> On Oct 21, 2013, at 8:32 AM, no-re...@ci.inria.fr wrote:
>>> 
 https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/label=win/21/
 
 2 regressions found.
 Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits
 Zinc.Tests.ZnServerTests.testEntityTooLarge


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

Tests that fail indicate that something is broken. They are like a kind of 
todo. But sometimes they are hard to fix and remain open for a long time. I 
understand that that conflicts with the notion of being 'all green all the 
time'. Maybe we should classify them somehow ?

On 21 Oct 2013, at 23:08, Camillo Bruni  wrote:

> sad but true :(
> 
> On 2013-10-21, at 08:37, Marcus Denker  wrote:
> 
>> I have turned off these emails for now, they are too many and thus get 
>> ignored
>> (I have never seen anyone but me filing an issue tracker entry for a newly 
>> failing test…)
>> 
>>  Marcus
>> 
>> On Oct 21, 2013, at 8:32 AM, no-re...@ci.inria.fr wrote:
>> 
>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/label=win/21/
>>> 
>>> 2 regressions found.
>>> Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits
>>> Zinc.Tests.ZnServerTests.testEntityTooLarge
>>> 
>> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

sad but true :(

On 2013-10-21, at 08:37, Marcus Denker  wrote:

> I have turned off these emails for now, they are too many and thus get ignored
> (I have never seen anyone but me filing an issue tracker entry for a newly 
> failing test…)
> 
>   Marcus
> 
> On Oct 21, 2013, at 8:32 AM, no-re...@ci.inria.fr wrote:
> 
>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/label=win/21/
>> 
>> 2 regressions found.
>> Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits
>> Zinc.Tests.ZnServerTests.testEntityTooLarge
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

I have turned off these emails for now, they are too many and thus get ignored
(I have never seen anyone but me filing an issue tracker entry for a newly 
failing test…)

Marcus

On Oct 21, 2013, at 8:32 AM, no-re...@ci.inria.fr wrote:

> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/label=win/21/
> 
> 2 regressions found.
>  
> Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits
>  Zinc.Tests.ZnServerTests.testEntityTooLarge
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

It gets strange by the minute… 
Are we sure that the VM did not change?

On Sep 27, 2013, at 9:41 AM, no-re...@ci.inria.fr wrote:

> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=win/535/
> 
> 20 regressions found.
>  CollectionsTests.Weak.WeakFinalizersTest.testNewFinalizationSupported
>  CollectionsTests.Weak.WeakRegistryTest.testFinalization
>  
> CollectionsTests.Weak.WeakRegistryTest.testFinalizationWithMultipleFinalizersPerObject
>  CollectionsTests.Weak.WeakRegistryTest.testFinalizationWithOnFork
>  
> CollectionsTests.Weak.WeakRegistryTest.testGrowingByAHighPriorityProcessDoesntLeak
>  CollectionsTests.Weak.WeakRegistryTest.testGrowingDoesntLeak
>  
> CollectionsTests.Weak.WeakRegistryTest.testRemovingByAHighPriorityProcessDoesntLeak
>  CollectionsTests.Weak.WeakRegistryTest.testRemovingDoesntLeak
>  Graphics.Tests.Files.PNGReadWriterTest.testBlue16
>  Graphics.Tests.Files.PNGReadWriterTest.testBlue32
>  Graphics.Tests.Files.PNGReadWriterTest.testBlue8
>  NativeBoost.Tests.NBCoreTests.testExternalResourceManagerFinalization
>  NativeBoost.Tests.NBCoreTests.testFinalization
>  NativeBoost.Tests.NBInterpreterProxyTest.testStackPointer
>  NativeBoost.Tests.NBInterpreterProxyTest.testStackPointer2
>  Tests.Finalization.ObjectFinalizerTests.testFinalizationOfMultipleResources
>  Tests.Monticello.MCDirectoryRepositoryTest.testAddAndLoad
>  Tests.Monticello.MCDirectoryRepositoryTest.testIncludesName
>  Tests.Monticello.MCDirectoryRepositoryTest.testLoadMissingNode
>  Tests.Monticello.MCDirectoryRepositoryTest.testStoreAndLoad
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

Perfect! Thanks for the quick response :P

On 2013-09-06, at 10:22, Fernando Olivero  
wrote:

> My bad, I fixed the Color class>fromString:.
> 
> I should've used  a detect:ifNone: instead of detect:
> 
> Fix here:
> https://pharo.fogbugz.com/f/cases/11534/ColorTest-is-failing
> 
> 
> 
> 
> On Fri, Sep 6, 2013 at 2:20 PM, Marcus Denker  wrote:
>> 
>> On Sep 6, 2013, at 2:17 PM, Sven Van Caekenberghe  wrote:
>> 
>>> Maybe some class #initialize did not run ?
>>> Remember: existing class initializers are only run when the source code 
>>> text changes.
>>> 
>> I added explicitly a call to initialize… the strange thing is that the 
>> change set seemed to work
>> fine.
>> 
>> Maybe we need to load it as a change set.
>> 
>> 
>>> On 06 Sep 2013, at 14:08, Camillo Bruni  wrote:
>>> 
 
 On 2013-09-06, at 09:03, Camillo Bruni  wrote:
> On 2013-09-06, at 08:59, no-re...@ci.inria.fr wrote:
>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/474/
>> 
>> 3 regressions found.
>> Graphics.Tests.Primitives.ColorTest.testAsHTMLColor
>> Graphics.Tests.Primitives.ColorTest.testColorFrom
>> Graphics.Tests.Primitives.ColorTest.testFromString
> 
> 
> Fernando this is all yours :)
 
 
 Arg, seems like this image is unusable in UI mode and fails on the same 
 things as the three testss :(
>>> 
>>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Fernando Olivero]

My bad, I fixed the Color class>fromString:.

I should've used  a detect:ifNone: instead of detect:

Fix here:
https://pharo.fogbugz.com/f/cases/11534/ColorTest-is-failing




On Fri, Sep 6, 2013 at 2:20 PM, Marcus Denker  wrote:
>
> On Sep 6, 2013, at 2:17 PM, Sven Van Caekenberghe  wrote:
>
>> Maybe some class #initialize did not run ?
>> Remember: existing class initializers are only run when the source code text 
>> changes.
>>
> I added explicitly a call to initialize… the strange thing is that the change 
> set seemed to work
> fine.
>
> Maybe we need to load it as a change set.
>
>
>> On 06 Sep 2013, at 14:08, Camillo Bruni  wrote:
>>
>>>
>>> On 2013-09-06, at 09:03, Camillo Bruni  wrote:
 On 2013-09-06, at 08:59, no-re...@ci.inria.fr wrote:
> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/474/
>
> 3 regressions found.
> Graphics.Tests.Primitives.ColorTest.testAsHTMLColor
> Graphics.Tests.Primitives.ColorTest.testColorFrom
> Graphics.Tests.Primitives.ColorTest.testFromString


 Fernando this is all yours :)
>>>
>>>
>>> Arg, seems like this image is unusable in UI mode and fails on the same 
>>> things as the three testss :(
>>
>>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On Sep 6, 2013, at 2:17 PM, Sven Van Caekenberghe  wrote:

> Maybe some class #initialize did not run ?
> Remember: existing class initializers are only run when the source code text 
> changes.
> 
I added explicitly a call to initialize… the strange thing is that the change 
set seemed to work
fine.

Maybe we need to load it as a change set.


> On 06 Sep 2013, at 14:08, Camillo Bruni  wrote:
> 
>> 
>> On 2013-09-06, at 09:03, Camillo Bruni  wrote:
>>> On 2013-09-06, at 08:59, no-re...@ci.inria.fr wrote:
 https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/474/
 
 3 regressions found.
 Graphics.Tests.Primitives.ColorTest.testAsHTMLColor
 Graphics.Tests.Primitives.ColorTest.testColorFrom
 Graphics.Tests.Primitives.ColorTest.testFromString
>>> 
>>> 
>>> Fernando this is all yours :)
>> 
>> 
>> Arg, seems like this image is unusable in UI mode and fails on the same 
>> things as the three testss :(
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

Ah right, let's try manually :), and yeah it's not always easy to modify
these core UI things without breaking it ;)

On 2013-09-06, at 09:17, Sven Van Caekenberghe  wrote:
> Maybe some class #initialize did not run ?
> Remember: existing class initializers are only run when the source code text 
> changes.
> 
> On 06 Sep 2013, at 14:08, Camillo Bruni  wrote:
> 
>> 
>> On 2013-09-06, at 09:03, Camillo Bruni  wrote:
>>> On 2013-09-06, at 08:59, no-re...@ci.inria.fr wrote:
 https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/474/
 
 3 regressions found.
 Graphics.Tests.Primitives.ColorTest.testAsHTMLColor
 Graphics.Tests.Primitives.ColorTest.testColorFrom
 Graphics.Tests.Primitives.ColorTest.testFromString
>>> 
>>> 
>>> Fernando this is all yours :)
>> 
>> 
>> Arg, seems like this image is unusable in UI mode and fails on the same 
>> things as the three testss :(
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

Maybe some class #initialize did not run ?
Remember: existing class initializers are only run when the source code text 
changes.

On 06 Sep 2013, at 14:08, Camillo Bruni  wrote:

> 
> On 2013-09-06, at 09:03, Camillo Bruni  wrote:
>> On 2013-09-06, at 08:59, no-re...@ci.inria.fr wrote:
>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/474/
>>> 
>>> 3 regressions found.
>>> Graphics.Tests.Primitives.ColorTest.testAsHTMLColor
>>> Graphics.Tests.Primitives.ColorTest.testColorFrom
>>> Graphics.Tests.Primitives.ColorTest.testFromString
>> 
>> 
>> Fernando this is all yours :)
> 
> 
> Arg, seems like this image is unusable in UI mode and fails on the same 
> things as the three testss :(

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

On 2013-09-06, at 09:03, Camillo Bruni  wrote:
> On 2013-09-06, at 08:59, no-re...@ci.inria.fr wrote:
>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/474/
>> 
>> 3 regressions found.
>> Graphics.Tests.Primitives.ColorTest.testAsHTMLColor
>> Graphics.Tests.Primitives.ColorTest.testColorFrom
>> Graphics.Tests.Primitives.ColorTest.testFromString
> 
> 
> Fernando this is all yours :)


Arg, seems like this image is unusable in UI mode and fails on the same things 
as the three testss :(


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

On 2013-09-06, at 08:59, no-re...@ci.inria.fr wrote:
> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/474/
> 
> 3 regressions found.
>  Graphics.Tests.Primitives.ColorTest.testAsHTMLColor
>  Graphics.Tests.Primitives.ColorTest.testColorFrom
>  Graphics.Tests.Primitives.ColorTest.testFromString


Fernando this is all yours :)


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

On 05 Sep 2013, at 15:14, Camillo Bruni  wrote:

> I think we already checked that, but it has nothing to do the with 
> a particular windows slave, no?

I am actually pretty clueless, I think this test just passes on Windows when 
run interactively in an image with UI.

> On 2013-09-05, at 10:07, Sven Van Caekenberghe  wrote:
>> On 05 Sep 2013, at 11:25, Damien Cassou  wrote:
>>> On Thu, Sep 5, 2013 at 9:51 AM,   wrote:
 1 regressions found.
 Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion
>>> 
>>> 
>>> it seems that this test fails very often. Can we do anything about it?
>> 
>> It only fails on Windows, and only from time to time ;-)
>> 
>> All it does is basically access one HTTPS URL
>> 
>> https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description
>> 
>> testGetPharoVersion
>>  | client lastBuildVersion version |
>>  self ensureSocketStreamFactory.
>>  self isNativeSSLPluginPresent ifFalse: [ ^ self ].
>>  lastBuildVersion := (client := ZnClient new)
>>beOneShot;
>>get: 
>> 'https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description'.
>>  self assert: client isSuccess.
>>  self assert: (client response contentType matches: ZnMimeType 
>> applicationXml).
>>  self assert: client response contentLength > 0.
>>  self assert: lastBuildVersion notNil.
>>  self assert: lastBuildVersion isString.
>>  self assert: lastBuildVersion size > 0.
>>  version := (lastBuildVersion copyAfter: $>) copyUpTo: $<.
>>  self deny: version isEmpty
>> 
>> This is a regression test for a bug that once existed, long ago. Normally, I 
>> try to add such a test for each issue that I fix.
>> 
>> Sven
>> 
>>> -- 
>>> Damien Cassou
>>> http://damiencassou.seasidehosting.st
>>> 
>>> "Success is the ability to go from one failure to another without
>>> losing enthusiasm."
>>> Winston Churchill
>>> 
>> 
>> 
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

I think we already checked that, but it has nothing to do the with 
a particular windows slave, no?

On 2013-09-05, at 10:07, Sven Van Caekenberghe  wrote:
> On 05 Sep 2013, at 11:25, Damien Cassou  wrote:
>> On Thu, Sep 5, 2013 at 9:51 AM,   wrote:
>>> 1 regressions found.
>>> Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion
>> 
>> 
>> it seems that this test fails very often. Can we do anything about it?
> 
> It only fails on Windows, and only from time to time ;-)
> 
> All it does is basically access one HTTPS URL
> 
> https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description
> 
> testGetPharoVersion
>   | client lastBuildVersion version |
>   self ensureSocketStreamFactory.
>   self isNativeSSLPluginPresent ifFalse: [ ^ self ].
>   lastBuildVersion := (client := ZnClient new)
> beOneShot;
> get: 
> 'https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description'.
>   self assert: client isSuccess.
>   self assert: (client response contentType matches: ZnMimeType 
> applicationXml).
>   self assert: client response contentLength > 0.
>   self assert: lastBuildVersion notNil.
>   self assert: lastBuildVersion isString.
>   self assert: lastBuildVersion size > 0.
>   version := (lastBuildVersion copyAfter: $>) copyUpTo: $<.
>   self deny: version isEmpty
> 
> This is a regression test for a bug that once existed, long ago. Normally, I 
> try to add such a test for each issue that I fix.
> 
> Sven
> 
>> -- 
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>> 
>> "Success is the ability to go from one failure to another without
>> losing enthusiasm."
>> Winston Churchill
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

On 05 Sep 2013, at 11:25, Damien Cassou  wrote:

> On Thu, Sep 5, 2013 at 9:51 AM,   wrote:
>> 1 regressions found.
>>  Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion
> 
> 
> it seems that this test fails very often. Can we do anything about it?

It only fails on Windows, and only from time to time ;-)

All it does is basically access one HTTPS URL

https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description

testGetPharoVersion
| client lastBuildVersion version |
self ensureSocketStreamFactory.
self isNativeSSLPluginPresent ifFalse: [ ^ self ].
lastBuildVersion := (client := ZnClient new)
  beOneShot;
  get: 
'https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/*/description'.
self assert: client isSuccess.
self assert: (client response contentType matches: ZnMimeType 
applicationXml).
self assert: client response contentLength > 0.
self assert: lastBuildVersion notNil.
self assert: lastBuildVersion isString.
self assert: lastBuildVersion size > 0.
version := (lastBuildVersion copyAfter: $>) copyUpTo: $<.
self deny: version isEmpty

This is a regression test for a bug that once existed, long ago. Normally, I 
try to add such a test for each issue that I fix.

Sven

> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Damien Cassou]

On Thu, Sep 5, 2013 at 9:51 AM,   wrote:
> 1 regressions found.
>   Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion


it seems that this test fails very often. Can we do anything about it?

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Re: [Pharo-dev] [regression reporter]regression occurred

[Sebastian Tleye]

fixing them...


2013/7/18 

>
> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/354/
>
> 2 regressions found.
>   Tests.Traits.TraitFileOutTest.testFileOutTrait
>   Tests.Traits.TraitTest.testPrinting
>
>

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

I think I should stop integrating anything until we have something that runs 
all tests of proposed improvements…
Like this I waste my time.

On Jul 15, 2013, at 9:09 AM, no-re...@ci.inria.fr wrote:

> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linux-stable-worker/343/
> 
> 3 regressions found.
>  AST.Interpreter.Test.ASTInterpreterTest.testSignalHalt
>  OpalCompiler.Tests.Misc.MethodMapTests.testMethodSourceNodeAtPC
>  OpalCompiler.Tests.Misc.MethodMapTests.testSimpleSourceMapping
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Sven Van Caekenberghe]

On 02 Jul 2013, at 15:07, no-re...@ci.inria.fr wrote:

> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=linux-stable-worker/293/
> 
> 3 regressions found.
>  Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory
>  ToolsTest.Debugger.DynamicMessageImplementorTest.testGenerateGetter
>  ToolsTest.Debugger.DynamicMessageImplementorTest.testGenerateSetter

It is a pity the release tests mostly fail during a Jenkins build, while they 
are all passing on a delivered image.

BTW, the process list is now clean on 3.0, great. Can make the one on 2.0 clean 
as well ?

Sven

Re: [Pharo-dev] [regression reporter]regression occurred

[Goubier Thierry]

Le 06/06/2013 11:17, Marcus Denker a écrit :

Now, 606 isn't available, no? I use get.pharo.org/20


Ah, then that is the problem… normally it is pushed automatically, but this 
seems to have failed.
I think we should just wait till the infrastructure is back and then redo the 
build.

Marcus


Ok, 606 is available now.

Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

>> 
> 
> I recreated a work image (20605), tested and saw the two failures:
> 
> FileSystem.Tests.Disk.FileHandleTest.testTruncate
> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
> 
> Then loaded SLICE-Issue-10411-flush-after-nextChunkPut-ThierryGoubier.1 (the 
> changes are visible :))
> 
> And ended with those two tests green.
> 
> (But with
> Refactoring.Tests.Changes.RBRefactoringChangeTests.tesValidTraitComposition(|2|3|4)
>  failures)
> 
> Now, 606 isn't available, no? I use get.pharo.org/20

Ah, then that is the problem… normally it is pushed automatically, but this 
seems to have failed.
I think we should just wait till the infrastructure is back and then redo the 
build.

Marcus

Re: [Pharo-dev] [regression reporter]regression occurred

[Goubier Thierry]

Le 06/06/2013 10:33, Marcus Denker a écrit :


On Jun 6, 2013, at 10:25 AM, Goubier Thierry  wrote:


Le 06/06/2013 08:32, Marcus Denker a écrit :


On Jun 5, 2013, at 4:10 PM, Goubier Thierry  wrote:


Le 05/06/2013 16:04, Marcus Denker a écrit :


On Jun 5, 2013, at 4:03 PM, Goubier Thierry  wrote:


Le 05/06/2013 15:56, Marcus Denker a écrit :


On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:


https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/

3 regressions found.
  FileSystem.Tests.Disk.FileHandleTest.testTruncate
  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload



Ok, so we have 2 independent issues;

1) testTruncate failing on recent Ubuntu in both 2.0 and 3.0

https://pharo.fogbugz.com/f/cases/10852

2) The slice I integrated was wrong / not complete:

  FileSystem.Tests.Disk.FileHandleTest.testTruncate
  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment


https://pharo.fogbugz.com/f/cases/10415

For this, I think the best would be to submit the missing code in some machine 
readable form
as I right now am a bit confused about what exactly "adding the right flush 
methods" means.


As far as I can browse, 
SLICE-Issue-10411-flush-after-nextChunkPut-ThierryGoubier.1 contains the 
correct code.


When I merge it in 2.0 606 I do not see any change..


Do you want me to retry generating a slice?


Maybe something is wrong with the image that was used to run the tests? Maybe 
that one actually was 605?

   Marcus


I recreated a work image (20605), tested and saw the two failures:

FileSystem.Tests.Disk.FileHandleTest.testTruncate
Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment

Then loaded SLICE-Issue-10411-flush-after-nextChunkPut-ThierryGoubier.1 
(the changes are visible :))


And ended with those two tests green.

(But with
Refactoring.Tests.Changes.RBRefactoringChangeTests.tesValidTraitComposition(|2|3|4) 
failures)


Now, 606 isn't available, no? I use get.pharo.org/20

Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On Jun 6, 2013, at 10:25 AM, Goubier Thierry  wrote:

> Le 06/06/2013 08:32, Marcus Denker a écrit :
>> 
>> On Jun 5, 2013, at 4:10 PM, Goubier Thierry  wrote:
>> 
>>> Le 05/06/2013 16:04, Marcus Denker a écrit :
 
 On Jun 5, 2013, at 4:03 PM, Goubier Thierry  wrote:
 
> Le 05/06/2013 15:56, Marcus Denker a écrit :
>> 
>> On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:
>> 
>>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/
>>> 
>>> 3 regressions found.
>>>  FileSystem.Tests.Disk.FileHandleTest.testTruncate
>>>  
>>> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
>>>  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload
>>> 
>> 
>> Ok, so we have 2 independent issues;
>> 
>> 1) testTruncate failing on recent Ubuntu in both 2.0 and 3.0
>>  
>>  https://pharo.fogbugz.com/f/cases/10852
>> 
>> 2) The slice I integrated was wrong / not complete:
>> 
>>  FileSystem.Tests.Disk.FileHandleTest.testTruncate
>>  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
>> 
>> 
>>  https://pharo.fogbugz.com/f/cases/10415
>> 
>> For this, I think the best would be to submit the missing code in some 
>> machine readable form
>> as I right now am a bit confused about what exactly "adding the right flush 
>> methods" means.
> 
> As far as I can browse, 
> SLICE-Issue-10411-flush-after-nextChunkPut-ThierryGoubier.1 contains the 
> correct code.
> 
When I merge it in 2.0 606 I do not see any change..

> Do you want me to retry generating a slice?

Maybe something is wrong with the image that was used to run the tests? Maybe 
that one actually was 605?

  Marcus

Re: [Pharo-dev] [regression reporter]regression occurred

[Goubier Thierry]

Le 06/06/2013 08:32, Marcus Denker a écrit :


On Jun 5, 2013, at 4:10 PM, Goubier Thierry  wrote:


Le 05/06/2013 16:04, Marcus Denker a écrit :


On Jun 5, 2013, at 4:03 PM, Goubier Thierry  wrote:


Le 05/06/2013 15:56, Marcus Denker a écrit :


On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:


https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/

3 regressions found.
  FileSystem.Tests.Disk.FileHandleTest.testTruncate
  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload



Ok, so we have 2 independent issues;

1) testTruncate failing on recent Ubuntu in both 2.0 and 3.0

https://pharo.fogbugz.com/f/cases/10852

2) The slice I integrated was wrong / not complete:

  FileSystem.Tests.Disk.FileHandleTest.testTruncate
  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment


https://pharo.fogbugz.com/f/cases/10415

For this, I think the best would be to submit the missing code in some machine 
readable form
as I right now am a bit confused about what exactly "adding the right flush 
methods" means.


As far as I can browse, 
SLICE-Issue-10411-flush-after-nextChunkPut-ThierryGoubier.1 contains the 
correct code.


Do you want me to retry generating a slice?

Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On Jun 5, 2013, at 4:10 PM, Goubier Thierry  wrote:

> Le 05/06/2013 16:04, Marcus Denker a écrit :
>> 
>> On Jun 5, 2013, at 4:03 PM, Goubier Thierry  wrote:
>> 
>>> Le 05/06/2013 15:56, Marcus Denker a écrit :
 
 On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:
 
> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/
> 
> 3 regressions found.
>  FileSystem.Tests.Disk.FileHandleTest.testTruncate
>  
> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
>  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload
> 

Ok, so we have 2 independent issues;

1) testTruncate failing on recent Ubuntu in both 2.0 and 3.0

https://pharo.fogbugz.com/f/cases/10852

2) The slice I integrated was wrong / not complete:

 FileSystem.Tests.Disk.FileHandleTest.testTruncate
 Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment


https://pharo.fogbugz.com/f/cases/10415

For this, I think the best would be to submit the missing code in some machine 
readable form
as I right now am a bit confused about what exactly "adding the right flush 
methods" means.

Marcus

Re: [Pharo-dev] [regression reporter]regression occurred

[Camillo Bruni]

On 2013-06-05, at 16:14, Goubier Thierry  wrote:

> Le 05/06/2013 16:04, Marcus Denker a écrit :
>> 
>> On Jun 5, 2013, at 4:03 PM, Goubier Thierry  wrote:
>> 
>>> Le 05/06/2013 15:56, Marcus Denker a écrit :
 
 On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:
 
> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/
> 
> 3 regressions found.
>  FileSystem.Tests.Disk.FileHandleTest.testTruncate
>  
> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
>  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload
> 
 
 Hhmm… not good.
 
Marcus
 
 
>>> Hey, did something went wrong on integration?
>> 
>> I guess so...
> 
> If I add the correction of 10415/10411, I solve the last two. However, there 
> is nothing on the path of the testTruncate which explains an effect of 
> 10411/10415. Has the test machine been updated and now exhibits the same libc 
> behavior as an ubuntu 13.04 ?

yes, we're running in barely-alive-emergency-mode, and the backup slave is 
running 13.04 :/

Re: [Pharo-dev] [regression reporter]regression occurred

[Goubier Thierry]

Le 05/06/2013 16:04, Marcus Denker a écrit :


On Jun 5, 2013, at 4:03 PM, Goubier Thierry  wrote:


Le 05/06/2013 15:56, Marcus Denker a écrit :


On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:


https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/

3 regressions found.
  FileSystem.Tests.Disk.FileHandleTest.testTruncate
  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload



Hhmm… not good.

Marcus



Hey, did something went wrong on integration?


I guess so...


If I add the correction of 10415/10411, I solve the last two. However, 
there is nothing on the path of the testTruncate which explains an 
effect of 10411/10415. Has the test machine been updated and now 
exhibits the same libc behavior as an ubuntu 13.04 ?


Thierry


The flush I added are not there in in the latest 2.0 image?

Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment

Of course, this one fail :(

Adding the flush where they are supposed to be solve that one...

Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95









--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On Jun 5, 2013, at 4:03 PM, Goubier Thierry  wrote:

> Le 05/06/2013 15:56, Marcus Denker a écrit :
>> 
>> On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:
>> 
>>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/
>>> 
>>> 3 regressions found.
>>>  FileSystem.Tests.Disk.FileHandleTest.testTruncate
>>>  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
>>>  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload
>>> 
>> 
>> Hhmm… not good.
>> 
>>  Marcus
>> 
>> 
> Hey, did something went wrong on integration?

I guess so...

> The flush I added are not there in in the latest 2.0 image?
> 
> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
> 
> Of course, this one fail :(
> 
> Adding the flush where they are supposed to be solve that one...
> 
> Thierry
> -- 
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
> 

Re: [Pharo-dev] [regression reporter]regression occurred

[Goubier Thierry]

Le 05/06/2013 15:56, Marcus Denker a écrit :


On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:


https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/

3 regressions found.
  FileSystem.Tests.Disk.FileHandleTest.testTruncate
  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload



Hhmm… not good.

Marcus


Hey, did something went wrong on integration? The flush I added are not 
there in in the latest 2.0 image?


Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment

Of course, this one fail :(

Adding the flush where they are supposed to be solve that one...

Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Re: [Pharo-dev] [regression reporter]regression occurred

[Marcus Denker]

On Jun 5, 2013, at 2:39 PM, no-re...@ci.inria.fr wrote:

> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=linux/247/
> 
> 3 regressions found.
>  FileSystem.Tests.Disk.FileHandleTest.testTruncate
>  Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment
>  Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload
> 

Hhmm… not good.

Marcus