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