> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bram Moolenaar > Sent: Monday, April 04, 2016 1:34 PM > To: Owen Leibman > Cc: [email protected] > Subject: RE: Question About test.ok in Old Style Tests > > > Owne Leibman wrote: > > > > > There are a number of tests which fail on z/OS due to ASCII-EBCDIC > > > > differences, e.g. sorts. > > > > It is not much of a problem to document and ignore these failures, > but > > > > it would be better to actually run a successful test on z/OS if > > > > possible. > > > > To do so, I hit on the idea of adding the following code to > test55.in, > > > > one of the failing tests: > > > > > > > > :if has('ebcdic') > > > > :silent !cp test55.ok.ebc test.ok > > > > :redraw! > > > > :endif > > > > > > > > This may or may not be a good approach - I would prefer not to > discuss > > > > its merits in this thread. > > > > What I would like to discuss is the fact that it didn't work. > > > > Inspecting testdir/Makefile shows why: > > > > > > > > .in.out: > > > > -rm -rf $*.failed test.ok $(RM_ON_RUN) > > > > cp $*.ok test.ok > > > > # ... many omitted lines ... > > > > # Check if the test.out file matches test.ok. > > > > @/bin/sh -c "if test -f test.out; then \ > > > > if diff test.out $*.ok; \ > > > > then mv -f test.out $*.out; \ > > > > else echo $* FAILED >>test.log; mv -f test.out > $*.failed; \ > > > > fi \ > > > > else echo $* NO OUTPUT >>test.log; \ > > > > fi" > > > > # more omitted lines > > > > -rm -rf X* test.ok viminfo > > > > > > > > It certainly appears that the intent was to create test.ok for use > in > > > > the diff. > > > > However, it is actually using $*.ok rather than test.ok in the > diff; > > > > that is why my test continues to fail. > > > > The only use made of test.ok is to create it at the start and > delete > > > > it at the end. > > > > Is there a reason why the diff is not using the file which was > created > > > > precisely for it? > > > > I made the appropriate substitution on a test ASCII system, and > all > > > > the tests seemed to run just fine. > > > > > > The way to do it is to copy test.ok to test.out. For example, > test11 > > > does this: > > > > > > :if !executable("gzip") > > > : e! test.ok > > > : w! test.out > > > : qa! > > > :endif > > > > No, that's not what I'm trying to accomplish. > > What you're suggesting causes the test to be bypassed altogether. > > I want to actually run the test and compare it to the correct output > file. > > Otherwise, we have no assurance that, for example, sorting in vim > > works correctly with ebcdic. > > Hmm, OK. But if the output is different, one might argue that it's the > wrong output, since Vim does not work as it does everywhere else. > > I assume you are editing a file that is ASCII or Latin, not EBCDIC. > I'm not quite sure why the sorting would be different if Vim was > compiled with EBCDIC, but editing an ASCII or Latin file. > Or is 'encoding' actually set to EBCDIC? >
Tests 55 and 57 sort plain text files. When sorted, test 55 line 13 is expected contain -1, 1, and b in that order. That is the correct sort order for ASCII (ISO8859-1) text (-1 starts with 0x2d, 1 starts with 0x31, b starts with 0x62). In EBCDIC (IBM-1047), however, the correct sort order is -1 (0x60), b (0x82), 1 (0xf1). If you feel that the EBCDIC sort should be returning the same order as ASCII, then the sort needs to be changed for EBCDIC. You would need to do an IBM-1047 to ISO8859-1 translation for all the data to be sorted on the input side, and the reverse on the output side. That would be a lot of work for not much, if any, gain. On the other hand, you might feel, as I do, that it is okay for the order to be environment-dependent, In that case, we should have either a separate test case for EBCDIC, or just a separate set of results. (Or the status quo - hoping, but not testing, that the EBCDIC sorts are okay.) > > > > > The alternative to this sort of approach is to skip test55 for > ebcdic, > > > > and add a new test55e which is skipped for non-EBCDIC. > > > > This seems clumsy, but it is admittedly easy enough to do. > > > > > > Another way is to adjust testdir/Make_all.mak, to move the tests > that > > > fail with EBCDIC separately. But that requires using another > makefile > > > or test target. What makefile do you use for this build? > > > > I just ran "make test" without specifying a file. > > I would like to avoid a separate makefile just for ebcdic, > > Especially since it could be handled correctly with the correct > > comparison after the test. > > Does that mean you are using "Makefile", the one that's for Unix? Yes I am. These tests are being run in Unix, namely on USS, Unix System Services for z/OS. > > For new style tests we could add a check for the ebcdic feature, but for > old style tests it's more difficult. If only few tests fail, perhaps > converting them to a new style test is the best solution. Converting test55, test57, and others that may crop up from old to new style is more work than I would wish to take on. The existing tests are fine with minor modifications. I would prefer to modify Makefile to use test.ok in order to not have to add new tests. But adding clones of test55 or test57 would also be acceptable if there's a reason not to modify Makefile (which is my original question). > > -- > hundred-and-one symptoms of being an internet addict: > 224. You set up your own Web page. You set up a Web page for each > of your kids... and your pets. > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net > \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ > \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org > /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org > /// > > -- > -- > 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. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -- -- 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.
