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).
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?
> 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.
> 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).
--
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 ///
--
--
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.
