> On 2 Apr 2019, at 17:40, Guillermo Polito <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> 
> 
> On Tue, Apr 2, 2019 at 5:31 PM ducasse <[email protected] 
> <mailto:[email protected]>> wrote:
> Cool and thanks!
> I love this green bar and I will try to keep it green.
> Do you know if the test writing by pierre should be pushed in Pharo because I 
> have the impression that they will be red first 
> 
> Short answer: no :).
> Long answer: 
>   I've made a review and requested changes. The issue is related to the need 
> of the new VM.
>   The main problem is that the only way to test it properly is to open a 
> file, closing it and ask your system if the file is still open (which is OS 
> dependent e.g., calling lsof on unix/osx, or the equivalent on windows).
>   The second better test we can do is to try to open as many files as the 
> limit and check that we cannot open more files or that we do not segfault :) 
> but it's not super fun when debugging.
>   Maybe we can just close/ignore that PR?

Just to verify we are talking about: 
https://github.com/pharo-project/pharo/pull/3100 
<https://github.com/pharo-project/pharo/pull/3100>Then I will close it. 

Stef


> 
>> Hi all,
>> 
>> In a couple of minutes I've made some (not complicated) fixes to make Rubric 
>> tests green again:
>> https://github.com/pharo-project/pharo/pull/3129 
>> <https://github.com/pharo-project/pharo/pull/3129>
> 
> I will check them.
> We got some tests for maxlength and started with the stupid point.
> 
> Yeah, we have to fix some ugly stuff on it (the centered ghost text, the max 
> length...), but there is "no rush" :).
>> 
>> This is of course not a super Rubric enhancement (for which I've opened 
>> another issue requesting some missing feature 
>> https://github.com/pharo-project/pharo/issues/3128 
>> <https://github.com/pharo-project/pharo/issues/3128>) but this allows us to 
>> move on with a better infrastructure :).
>> 
>> There are still some some tests that fail from time to time, related to 
>> system announcers and finalization. See 
>> https://github.com/pharo-project/pharo/issues/2471 
>> <https://github.com/pharo-project/pharo/issues/2471>.
>> Though I've spent half a day yesterday and half today trying to track it 
>> down, I don't yet have a clear way of reproducing it. I've read the entire 
>> code that touches this part of the system and I really bet this is a race 
>> condition :).
>> So any second pair of eyes here would really be helpful!
> 
> I’m inherently race condition incompatible and just avoid concurrent 
> programming because I’m too dull on this. 
> 
> Even funnier is that I think the race condition happens during the stage 
> loading BaselineOfPharo. It's a super huge step, and we need better debugging 
> tools for that kind of scenarios...
>  
> 
>> Guille
> 
> 
> 
> -- 
>    
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> <http://www.cnrs.fr/>
> 
> Web: http://guillep.github.io <http://guillep.github.io/>
> Phone: +33 06 52 70 66 13

Reply via email to