Hi Ken,
On 12/30/2015 12:35 PM, Ken Takata wrote:
Hi Michael,
2015/12/31 Thu 2:10:14 UTC+9 Michael Soyka wrote:
On 12/30/2015 11:40 AM, Bram Moolenaar wrote:
Ken Takata wrote:
2015/12/30 Wed 22:46:09: UTC+9 Bram Moolenaar wrote:
I wrote:
Ken Takata wrote:
2015/12/29 Tue 21:59:54 UTC+9 Bram Moolenaar wrote:
Ken Takata wrote:
2015/12/29 Tue 6:25:06 UTC+9 Bram Moolenaar wrote:
Christian Brabandt wrote:
On Mo, 28 Dez 2015, Bram Moolenaar wrote:
Patch 7.4.982
Problem: Keeping the list of tests updated is a hassle.
Solution: Move the list to a separate file, so that it only needs to be
udpated in one place.
Files: src/testdir/Make_amiga.mak, src/testdir/Make_dos.mak,
src/testdir/Make_ming.mak, src/testdir/Make_os2.mak,
src/testdir/Make_vms.mms, src/testdir/Makefile,
src/testdir/Make_all.mak
Starting from this patch, this breaks appveyor:
This built timed out after 60 minutes when trying to run test49:
https://ci.appveyor.com/project/chrisbra/vim/build/204
After that patch, it fails when copying test49.in:
https://ci.appveyor.com/project/chrisbra/vim/build/205
https://ci.appveyor.com/project/chrisbra/vim/build/206
Don't know, what the problem is and how to solve it.
I noticed. Somehow test49.in wasn't processed. It was not in the list
of tests for MS-Windows before, so I removed it in patch 7.4.986.
Now it appears it doesn't run any tests...
OK, I can reproduce it locally.
It's because appveyor doesn't specify a target, and the first dependency
is in Make_all.mak:
test49.out: test49.vim
I'll specify a default target before including Make_all.mak
After 7.4.988, still something strange happen. When running a single test
as the following:
nmake -f Make_dos.mak clean
nmake -f Make_dos.mak VIMPROG=..\gvim test86.out
Copy command fails like this:
https://ci.appveyor.com/project/chrisbra/vim/build/206
Maybe this is caused by that testXX.out has multiple dependency rules.
Attached patch fixes this.
That problem has already been fixed. We are now back to test 86
failing. Before the diff was just one line, now it's a big difference.
On my system the test passes without problems. It might depend on the
Python version.
No, it still occurs:
https://ci.appveyor.com/project/k-takata/vim/build/37
I changed appveyor.yml to execute only test11:
https://github.com/k-takata/vim/commit/d16eba3da82b8e7ba6dd672650eeb5b89225eab5
Well, I don't know what your setup is, but for the main Vim repository
the builds pass now.
My setup is here:
https://github.com/k-takata/vim/commit/d16eba3da82b8e7ba6dd672650eeb5b89225eab5
I just commented out the following line:
nmake -f Make_dos.mak VIMPROG=..\gvim
and added the following line instead:
nmake -f Make_dos.mak VIMPROG=..\gvim test11.out
This failure doesn't seem to happen when running all tests, but it happens
when running a single test.
This is very annoying for me now.
Let me include your change. I suppose the order of the rules matters
for the order in which the commands are executed.
I wrote another patch. This is simpler than before, but I don't understand
why this patch solves the problem:
Apparently the line you moved down must be after the rule that copies
the input files to dostmp.
I wonder if we can get rid of this anyway, the tests should be able to
run with Unix file format. I wonder what files if we skip this step and
s/files/fails/
if we can fix that.
I'd like to try to run the tests with Unix file format when I have time.
The DOS/MS-Windows files are currently distributed in dos fileformat.
I'm considering dropping that in 7.5, so that the files are identical to
what one gets from github.
Git has a configuration option "core.autocrlf" that enables/disables
linefeed-to-carriagereturnLinefeed and reverse conversions.
If the client-side sets this to true, this conversion is done
automatically by the client. The server-side has no control over what
the client does. The "ProGit" book discusses this chapter 8.1.
I don't think it works well. When I tried similar configuration on mercurial,
it didn't work because some of the test input files contains some control
codes including "\r". Some files were handled as binary files, and "\r" was
converted to "\r\n".
We also need to care about the mercurial mirror repository.
I don't disagree with anything you've said. It would seem to follow
that the test files themselves should not include such characters other
than as line terminators.
In view of this, it looks like Vim will have to continue to assume
responsibility for ensuring the appropriate line endings.
Regards,
Ken Takata
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
