<div dir="ltr"><div dir="ltr"><div>Hi Roland,</div><div><br></div><div>Thanks for looking into these.</div><div><br></div><div>> 
I looked into the testcases 'plugins09', 'plugins10' and 'plugins11' and
 found the following: GHC-Windows uses BufferMode 'BlockBuffering 
Nothing', however, GHC-Linux uses 'LineBuffering'. <br></div><div><br></div><div>Ah, yes, this isn't technically a Linux vs Windows thing, GHC will always default to LineBuffering for terminals and BlockBuffering for anything else. The issue is that msys2 terminals have std handles that are backed by files instead of pipes. This is an artifact of how they try to emulate posix shells, See <a href="https://github.com/msys2/msys2/wiki/Porting#standard-streams-in-mintty">https://github.com/msys2/msys2/wiki/Porting#standard-streams-in-mintty</a>.  
This means that when GHC runs inside an msys2 program such as bash it'll always default to BlockBuffering.

</div><div><br></div><div>> 
I don't know anything about the "Why" and "Where" in the GHC IO module on Windows, so I'm unable to come up with a patch. <br></div><div><br></div><div>The above said the handles should be getting flushed when the finalizers are run, but these aren't 100% guaranteed so if the tests rely on this then your solution (to force buffer mode to LineBuffering) sounds like perfectly adequate.  Could you put a patch up with that?</div><div><br></div><div>My new I/O manager takes a different approach to determine the buffer mode, but I still have some kinks to work out before posting it.</div><div><br></div><div>> 
PS: I can't say anything about the tests 'plugin-recomp-pure' and 
'plugin-recomp-impure' as these tests run successfully on my (slow) 
Windows box. <br></div><div><br></div><div>These don't fail for me or harbormaster either, so if Simon is able to consistently reproduce these then I'll have to ask him for a core dump so I can take a look.</div><div><br></div><div>Thanks again,</div><div>I appreciate the help!</div><div><br></div><div>Regards,</div><div>Tamar<br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 3:34 PM Roland Senn <<a href="mailto:rsx@bluewin.ch">rsx@bluewin.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi Tamar,</div><div><br></div><div>I looked into the testcases 'plugins09', 'plugins10' and 'plugins11' and found the following: GHC-Windows uses BufferMode 'BlockBuffering Nothing', however, GHC-Linux uses 'LineBuffering'.</div><div><br></div><div>If I add an 'import System.IO' and the line 'liftIO $ hSetBuffering stdout LineBuffer' as first line in the do block of the function '.../testuite/tests/plugins/simple-plugin/Simple/SourcePlugin.hs:parsedPlugin' then all 3 tests pass successfully on Windows!</div><div><br></div><div>I don't know anything about the "Why" and "Where" in the GHC IO module on Windows, so I'm unable to come up with a patch.</div><div><br></div><div>Regards</div><div>   Roland</div><div></div><div><br></div><div>PS: I can't say anything about the tests 'plugin-recomp-pure' and 'plugin-recomp-impure' as these tests run successfully on my (slow) Windows box.</div><div><br></div><div>Am Sonntag, den 02.12.2018, 20:42 +0000 schrieb Phyx:</div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hi Simon,</div><div><br></div><div>That's a bit better (still need to figure out why the recent threading issues, but one problem at a time :) )</div><div><br></div><div>From that list T10672_x64 is one I'm looking at already, seems to have something to do with the libstdc++ destructors.</div><div>Plugins 09 and 10 are the other two I know about, but haven't had time to look at them yet. Frankly I know too little about plugins to make an accurate determination here, but the input files are empty</div><div>yet it expects output, so I don't know what it's supposed to do here.  If someone who knows more about plugins can chime in that would save some time.</div><div><br></div><div>The segfaulting plugin I haven't triaged yet. Now the remaining failures aside from T14452 that Roland is taking care of, seem to have to do with your locale in your console.  You seem to be running the</div><div>tests in a console that has latin-1 locale? So some unicode characters fail encoding/decoding.</div><div><br></div><div>If it's a Windows shell you can change it to utf-8 using "chcp 
65001", if it's an msys2 shell, what does "locale" return?</div><div><br></div><div>For reference mine is</div><div><br></div><div>$ locale<br>LANG=en_GB.UTF-8<br>LC_CTYPE="en_GB.UTF-8"<br>LC_NUMERIC="en_GB.UTF-8"<br>LC_TIME="en_GB.UTF-8"<br>LC_COLLATE="en_GB.UTF-8"<br>LC_MONETARY="en_GB.UTF-8"<br>LC_MESSAGES="en_GB.UTF-8"<br>LC_ALL=</div><div><br></div><div>If it does say latin1 you can change it with</div><div><br></div><div>export 
LANG=en_GB.UTF-8 <br></div><div><br></div><div>This should fix more of the tests.</div><div><br></div><div>The reason I don't mark the remaining tests as expect fail yet is because I haven't had the time to triage them, so I don't know their severity and</div><div>last time there were a few nasty issues hidden in them.</div><div><br></div><div>Unfortunately I won't have time to look at them till next weekend.</div><div><br></div><div>Thanks,</div><div>Tamar<br></div></div></div><br><div class="gmail_quote"><div dir="ltr"><br></div></div></blockquote></div></blockquote></div>