[darcs-devel] my problems with tests that run ssh/curl

[Ben Franksen]

Am 16.07.20 um 13:01 schrieb Ganesh Sittampalam:
> On 16/07/2020 10:15, Ben Franksen wrote:
> 
>> another thing that came to my mind just now: doesn't Windows nowadays
>> come with a "native" version of bash (as part of the WSL aka Windows
>> Subsystem for Linux)? If we could use that instead of cygwin, perhaps
>> all your Windows test problems will go away?
> 
> I've played with it before, but it's quite unnative - it's more like
> Docker-lite than something that is genuinely integrated with the Windows
> ecosystem. So in particular I'm not sure that it would test what our
> users would actually be doing when using darcs outside WSL.

Hmm, yes. While WSL1 was more like what wine was for Linux, it seems
that WSL2 is more like a container, running a real Linux kernel.

However, I wonder if that really matters, assuming the darcs under test
is the native darcs.exe compiled on and for Windows. In some sense,
using bash scripts means we already test the wrong thing. For instance,
our test suite does *not* test that darcs behaves correctly when it gets
a native Windows path ("C:/...") as an argument. This suggests to me
that using WSL for testing might not be (much) worse than using cygwin.

I also wonder what your build environment is on Windows. And how (and
if) you are actually using the native darcs.exe (i.e. via powershell or
cmd.exe) for anything, so we have at least anecdotal evidence that it
does the right thing there.

> It might be
> time to take another look, but that'll of course take up more time
> itself :-)

Given how the situation on Windows deteriorates I guess we have to do
/something/.

See
https://docs.microsoft.com/en-us/windows/wsl/interop#run-windows-tools-from-linux
for how to run a native windows binary on WSL.

>> Don't you think we could at least try and debug this to find out *what*
>> makes it so slow in Windows? It could be anything, really, but my gut
>> feeling tells me it has to do with executing the 'bash test' command.
> 
> It's fairly well-known that Windows process creation is very slow
> compared to Linux, so scripts that rely on cheap composition of small
> utilities pay a huge performance penalty.> I'm less sure why things
> (probably) got a lot slower for me more recently. I should probably do
> some timing tests after rebooting to clear out the spyware, and/or try
> another computer to see if it behaves any differently.

That's what I meant. If it was slow but just tolerable before than why
has it gotten so much worse?

Cheers
Ben