> -----Original Message----- > From: Bram Moolenaar [mailto:[email protected]] > Sent: Monday, April 04, 2016 2:20 PM > To: Owen Leibman > Cc: [email protected] > Subject: RE: Question About test.ok in Old Style Tests > > > Owen 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). > > What still isn't clear for me: If these files are in ASCII (or Latin1), > how does the EBCDIC sort ortder apply? There must be some conversion > happening somewhere. So, even though 'encoding' is latin1, the text is > actually in EBCDIC? If you use "ga" on the characters you mention, what > is the output?
This is the difference between "character set" and "encoding". Both ISO8859-1 and IBM-1047 use the Latin1 character set; they just encode the characters differently. "ga" for "1" returns, as expected, the EBCDIC values: <1> 241, Hex f1, Octal 361 > > > If you feel that the EBCDIC sort should be returning the same order as > > ASCII, then the sort needs to be changed for EBCDIC. > > I'm fine with EBCDIC sort order when editing EBCDIC. But when editing > ASCII/Latin then that sort order is expected. On z/OS, IBM-1047 is the only encoding supported for vim. Any attempt to change it is met with "E519". We could probably do better than that, but it would (probably) be a big project. It would certainly have value, but the product as currently shipped on z/OS is "good enough". For now, an ASCII/ISO8859-1/UTF-8 file would have to be iconv'ed before we could use it with vim. Note that README_os390.txt gives specific instructions for performing this conversion on all the files that are shipped with vim before starting to configure and make it. So, in the case of the test files, that's where the conversion is happening. > > > 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. > > OK, so we most likely do need to check the ebcdic feature to decide what > the output should be. One other way is to have configure produce > something in auto/config.mk, so that it can be used in the Makefile. > > > > 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. > > It's worth it though. Looks like at least test55 is already doing most > stuff, but instead of dumping the output in a file should use > assert_equal(). > > > 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). > > Although that is probably the simplest way, it's postponing the work for > the conversion to new style tests (and increasing it). I will look into this. While I'm doing so, I would still appreciate an answer to the original question. Is testdir/Makefile correct when it uses $*.ok rather than test.ok in its diffs? > > -- > hundred-and-one symptoms of being an internet addict: > 225. You sign up for free subscriptions for all the computer magazines > > /// 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 > /// 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.
