When we come to do this, could there be some mechanism to scale *all*
these timeouts.
For example, to investigate VM crashes we might want to run all tests
under a debug VM
which would greatly extend the time taken for each test, and it would
be a pain to get a bundle of false positives. Perhaps
I moved issue to Pharo 7
2017-02-16 13:33 GMT+01:00 Denis Kudriashov :
> Hi.
>
> In Pharo 6 we introduced time limit for tests. Currently it is set to 1
> minute by default. And concrete test cases or single tests can redefine it
> with suitable value. There is also setting
2017-02-16 14:59 GMT+01:00 Ben Coman :
> But this could conceivably cause more erroneous failures by the CI
> monkey, which slows down progress up to the Release.
>
I would not wrote this mail without Monkey :). With "2 seconds" Monkey was
happy.
>
> +1 for doing it
2017-02-16 14:46 GMT+01:00 Guillermo Polito :
>
>> It solved very easily. "Watchdog process" just checks that test process
>> isSuspended or not. If it is not suspended timeout is signalled. Test
>> process is suspended only when debugged.
>>
>
> Ok. Is something like
On Thu, Feb 16, 2017 at 9:32 PM, Denis Kudriashov wrote:
>
> 2017-02-16 14:26 GMT+01:00 Sven Van Caekenberghe :
>>
>> But we could integrate the patch (his work marking slow tests) and the
>> code, and then disable the enforcing mechanism. That will allow us to
On Thu, Feb 16, 2017 at 2:31 PM, Denis Kudriashov
wrote:
>
> 2017-02-16 13:49 GMT+01:00 Guillermo Polito :
>
>> I vote for not introducing during code-freeze.
>>
>
> I understand it but these behaviour was introduced in Pharo 6. And It is
>
2017-02-16 14:35 GMT+01:00 Sven Van Caekenberghe :
> But did you not mark more tests with custom timeouts ?
Yes, couple test cases. And actually all slow tests (from previous fixes
too) are marked with 10 seconds. Current default 1 minute is to not affect
possible external
> On 16 Feb 2017, at 14:32, Denis Kudriashov wrote:
>
>
> 2017-02-16 14:26 GMT+01:00 Sven Van Caekenberghe :
> But we could integrate the patch (his work marking slow tests) and the code,
> and then disable the enforcing mechanism. That will allow us to
2017-02-16 14:26 GMT+01:00 Sven Van Caekenberghe :
> But we could integrate the patch (his work marking slow tests) and the
> code, and then disable the enforcing mechanism. That will allow us to
> re-able it quickly later on.
It is already in image. My patch only enable small
2017-02-16 13:49 GMT+01:00 Guillermo Polito :
> I vote for not introducing during code-freeze.
>
I understand it but these behaviour was introduced in Pharo 6. And It is
already used quite long time. So it could be considered as small
improvements to already integrated
But we could integrate the patch (his work marking slow tests) and the code,
and then disable the enforcing mechanism. That will allow us to re-able it
quickly later on.
> On 16 Feb 2017, at 14:23, Esteban Lorenzano wrote:
>
>
>> On 16 Feb 2017, at 13:49, Guillermo
> On 16 Feb 2017, at 13:49, Guillermo Polito wrote:
>
> I vote for not introducing during code-freeze.
+1: not in code freeze.
>
> We can discuss it for Pharo 7, I'm not against actually. But I have some
> concerns:
>
> - How does it work when we are debugging?
>
I vote for not introducing during code-freeze.
We can discuss it for Pharo 7, I'm not against actually. But I have some
concerns:
- How does it work when we are debugging?
I mean, imagine I'm running a test, a debugger is open, and I start working
on it. How do these timeout currently work in
Hi.
In Pharo 6 we introduced time limit for tests. Currently it is set to 1
minute by default. And concrete test cases or single tests can redefine it
with suitable value. There is also setting to change default limit globally
which should help to not adopt external projects immediately if
14 matches
Mail list logo