Re: A potential approach to making tests faster on Windows

2018-04-06 Thread Stefan Beller
On Fri, Apr 6, 2018 at 2:40 PM, Jeff King wrote: > On Tue, Apr 03, 2018 at 06:00:05PM +0200, Johannes Schindelin wrote: > >> > But if we're at the point of creating custom C builtins for >> > busybox/dash/etc, you should be able to create a primitive for "read >> > this using

Re: A potential approach to making tests faster on Windows

2018-04-06 Thread Jeff King
On Tue, Apr 03, 2018 at 06:00:05PM +0200, Johannes Schindelin wrote: > > But if we're at the point of creating custom C builtins for > > busybox/dash/etc, you should be able to create a primitive for "read > > this using buffered stdio, other processes be damned, and return one > > line at a

Re: A potential approach to making tests faster on Windows

2018-04-03 Thread Eric Sunshine
On Tue, Apr 3, 2018 at 5:49 AM, Johannes Schindelin wrote: > My main evidence that shell scripts on macOS are slower than on Linux was > the difference of the improvement incurred by moving more things from > git-rebase--interactive.sh into sequencer.c: Linux saw an

Re: A potential approach to making tests faster on Windows

2018-04-03 Thread Johannes Schindelin
Hi Peff, On Tue, 3 Apr 2018, Jeff King wrote: > On Tue, Apr 03, 2018 at 01:43:10PM +0200, Johannes Schindelin wrote: > > > > I don't have time or interest to work on this now, but thought it was > > > interesting to share. This assumes that something in shellscript like: > > > > > > while

Re: A potential approach to making tests faster on Windows

2018-04-03 Thread Johannes Schindelin
Hi Ævar, On Tue, 3 Apr 2018, Ævar Arnfjörð Bjarmason wrote: > [...] I think it would be really interesting to see the third > approach I suggested, i.e. hack the shell to make the test_cmp a builtin > and test that. Then you won't fork, but will get the advantage of your > fast C codepath. That

Re: A potential approach to making tests faster on Windows

2018-04-03 Thread Jeff King
On Tue, Apr 03, 2018 at 01:43:10PM +0200, Johannes Schindelin wrote: > > I don't have time or interest to work on this now, but thought it was > > interesting to share. This assumes that something in shellscript like: > > > > while echo foo; do echo bar; done > > > > Is no slower on Windows

Re: A potential approach to making tests faster on Windows

2018-04-03 Thread Johannes Schindelin
Hi Ævar, On Fri, 30 Mar 2018, Ævar Arnfjörð Bjarmason wrote: > On Fri, Mar 30 2018, Johannes Schindelin wrote [expressing frustrations > about Windows test suite slowness]: To be precise (and I think it is important to be precise here): it is not the Windows test suite about which I talked, it

Re: A potential approach to making tests faster on Windows

2018-04-03 Thread Ævar Arnfjörð Bjarmason
On Tue, Apr 03 2018, Johannes Schindelin wrote: > Hi Peff, > > On Fri, 30 Mar 2018, Jeff King wrote: > >> On Fri, Mar 30, 2018 at 08:45:45PM +0200, Ævar Arnfjörð Bjarmason wrote: >> >> > I've wondered for a while whether it wouldn't be a viable approach to >> > make something like an interpreter

Re: A potential approach to making tests faster on Windows

2018-04-03 Thread Johannes Schindelin
Hi Peff, On Fri, 30 Mar 2018, Jeff King wrote: > On Fri, Mar 30, 2018 at 08:45:45PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > I've wondered for a while whether it wouldn't be a viable approach to > > make something like an interpreter for our test suite to get around > > this problem, i.e.

Re: A potential approach to making tests faster on Windows

2018-03-30 Thread Jeff King
On Fri, Mar 30, 2018 at 08:45:45PM +0200, Ævar Arnfjörð Bjarmason wrote: > I've wondered for a while whether it wouldn't be a viable approach to > make something like an interpreter for our test suite to get around this > problem, i.e. much of it's very repetitive and just using a few shell >

Re: A potential approach to making tests faster on Windows

2018-03-30 Thread Junio C Hamano
Ævar Arnfjörð Bjarmason writes: > On Fri, Mar 30 2018, Johannes Schindelin wrote [expressing frustrations > about Windows test suite slowness]: > > I've wondered for a while whether it wouldn't be a viable approach to > make something like an interpreter for our test suite to