[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-devel
Subject:    Re: [darcs-devel] [patch2021] replace shelly with turtle
From:       Ben Franksen <ben.franksen () online ! de>
Date:       2020-05-31 22:21:13
Message-ID: rb1akp$pql$1 () ciao ! gmane ! io
[Download RAW message or body]

Am 31.05.20 um 22:29 schrieb Ganesh Sittampalam:
> On 31/05/2020 19:52, Ben Franksen wrote:
> 
>> That made me think that perhaps using an absolute path for the bash
>> command may be more fail safe, but I wasn't sure what the "right" bash
>> would be for Windows! Now that you found out that indeed we should use
>> the bash from mingw, perhaps we can fix this simply by replacing
>>
>>   proc "bash" ["test"]
>>
>> with
>>
>>   proc "/bin/bash" ["test"]
>>
>> or perhaps
>>
>>   proc "/usr/bin/env" ["bash", "test"]
>>
>> (which coincides with the shebang line in our scripts)
> 
> The latter seems most attractive given the connection with our scripts.
> Unfortunately, it doesn't work. This isn't surprising given that the
> darcs-test exe is just a standard Windows exe, so it doesn't go through
> the mingw path translation.

Ugh, of course.

> What's worse is that non-existent paths seem to cause a hang instead of
> a nice error :-)
> 
> I tried giving an explicit Windows path to bash
> (c:/msys64/usr/bin/bash.exe) and made some progress: the shell tests do
> mostly run now. However subjectively it seems really slow, even by the
> usual standards of the tests on Windows, and at least harness.sh fails.
> My full run has only got to 'c' so far so I don't know what else there
> is yet :-)

This doesn't sound good at all. I see no reason why turtle should be
noticeably slower than shelly on Windows, but if you can make sure this
is the case, perhaps by measuring with -t <expression that matches just
a few tests>, then I don't think we should use it.

> Explicitly pointing to a specific mingw install folder, even if it is
> the default one, isn't great. So I think the next things for me to do are:
> 
>  - Do some actual timings to see if there is a speed difference
>  - Investigate harness.sh and any other failures
>  - Think about a cleaner way to specify the path
>  - Investigate the hang with a non-existent path
> 
> I guess this will be a bit of a slog. How much do we gain from the
> shelly=>turtle change?

Technically, not that much. In fact, turtle has a few disadvantages
compared to shelly, I think I mentioned them in one of the patch logs or
on the tracker. I do like the new code in D.T.Shell a lot better than
what we had before, but I guess that's mainly because it was a clean
re-write, and we could probably do a similar re-write based on shelly.

I think the main point of the move was to throw out the bundled old
version of shelly. This was never intended to be anything other than a
stop-gap measure. It also means users who install from hackage cannot
run the test suite. Also I wasn't 100% comfortable that such bundling is
legally allowed, given the different licenses. Aren't we a member of the
free software conservancy or something? They could probably answer that
question.

I have also looked at another alternative, namely shellmate. This is
conceptually similar to shelly (it is a reader monad over IO and thus
can handle environment and working directory in a thread safe manner),
but overall looks simpler and better structured. It has the advantage of
using plain String/FilePath in its API, instead of Text and the
deprecated system-filepath used by shelly and turtle. Not sure how well
it is (or will be) maintained though and I also don't know for sure
whether it has all the features we need.

Cheers
Ben

_______________________________________________
darcs-devel mailing list
darcs-devel@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-devel
[prev in list] [next in list] [prev in thread] [next in thread]