Loading ...
Sorry, an error occurred while loading the content.
 

Re: status of tests in src/testdir?

Expand Messages
  • David Pope
    ... Thanks very much for responding Nazri. I rechecked my results on a clean(er) source tree and now the test runs flawlessly. So that means the problem is
    Message 1 of 9 , Apr 3, 2012
      On Tue, Apr 3, 2012 at 2:31 AM, Nazri Ramliy <ayiehere@...> wrote: 
      The doc is (just a teeny bit) inaccurate.

      I'm the one who wrote that note, and also the one who submitted the
      patch for the :find, :sfind and :tabfind completion, bugs and all :)

      For completion, the "/**" path specification is supported. The doc
      should be patched like this:

      [elided] 

      Thanks very much for responding Nazri.  I rechecked my results on a clean(er) source tree and now the test runs flawlessly.  So that means the problem is with my win32 symlink patch, which means your automated test served its purpose perfectly. :)  Onward to debugging my code...

      (To answer your question, I'm building x64 target using VS2010.)

      Separately, in order to get three of the tests to complete, I had to change the following line in Make_dos.mak:

       fixff:
              -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in *.ok
      -       -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q dotest.in
      +       -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q dotest.in test60.ok test71.ok test74.ok

      These three tests output in ff=unix, either explicitly (test 60) or implicitly (tests 71, 74), so the diff fails.  Do they run without modifications for you?

      ----
      David Pope

      --
      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
    • Bram Moolenaar
      ... That modification should not be necessary, since the line just above it includes *.ok and should fix all .ok files. Perhaps you are using a make that
      Message 2 of 9 , Apr 5, 2012
        David Pope wrote:

        > On Tue, Apr 3, 2012 at 2:31 AM, Nazri Ramliy <ayiehere@...> wrote:
        > >
        > > The doc is (just a teeny bit) inaccurate.
        > >
        > > I'm the one who wrote that note, and also the one who submitted the
        > > patch for the :find, :sfind and :tabfind completion, bugs and all :)
        > >
        > > For completion, the "/**" path specification is supported. The doc
        > > should be patched like this:
        > >
        > > [elided]
        >
        > Thanks very much for responding Nazri. I rechecked my results on a
        > clean(er) source tree and now the test runs flawlessly. So that means the
        > problem is with my win32 symlink patch, which means your automated test
        > served its purpose perfectly. :) Onward to debugging my code...
        >
        > (To answer your question, I'm building x64 target using VS2010.)
        >
        > Separately, in order to get three of the tests to complete, I had to change
        > the following line in Make_dos.mak:
        >
        > fixff:
        > -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in
        > *.ok
        > - -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q
        > dotest.in
        > + -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q
        > dotest.in test60.ok test71.ok test74.ok
        >
        > These three tests output in ff=unix, either explicitly (test 60) or
        > implicitly (tests 71, 74), so the diff fails. Do they run without
        > modifications for you?

        That modification should not be necessary, since the line just above it
        includes "*.ok" and should fix all .ok files. Perhaps you are using a
        make that expands wildcards and then runs into the maximum line length?

        --
        FATHER: One day, lad, all this will be yours ...
        PRINCE: What - the curtains?
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- 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
      • Nazri Ramliy
        ... Initially I ran nmake -f Make_mvc.mak test in the src directory and only test50 failed. Then I cd into testdir and do name -f Make_dos.mak clean ,
        Message 3 of 9 , Apr 6, 2012
          On Wed, Apr 4, 2012 at 1:36 PM, David Pope <d.e.pope@...> wrote:
          > These three tests output in ff=unix, either explicitly (test 60) or
          > implicitly (tests 71, 74), so the diff fails.  Do they run without
          > modifications for you?

          Initially I ran "nmake -f Make_mvc.mak test" in the src directory
          and only test50 failed.

          Then I cd into testdir and do "name -f Make_dos.mak clean", followed
          by "nmake -f Make_dos.mak" and all the test ran fine.

          This is on Windows 7 running in a vmware virtual machine installed using
          ievms (https://github.com/xdissent/ievms).

          Kind regards,

          Nazri

          --
          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
        • David Pope
          ... The first line in the target sets the ff to dos for all the .ok files, but tests 60, 71, and 74 generate files with ff=unix, so the diff fails due to the
          Message 4 of 9 , Apr 8, 2012
            On Thu, Apr 5, 2012 at 9:38 AM, Bram Moolenaar <Bram@...> wrote:

            David Pope wrote:
            Separately, in order to get three of the tests to complete, I had to change
            > the following line in Make_dos.mak:
            >
            >  fixff:
            >         -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=dos|upd" +q *.in
            > *.ok
            > -       -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q
            > dotest.in
            > +       -$(VIMPROG) -u dos.vim --noplugin "+argdo set ff=unix|upd" +q
            > dotest.in test60.ok test71.ok test74.ok
            >
            > These three tests output in ff=unix, either explicitly (test 60) or
            > implicitly (tests 71, 74), so the diff fails.  Do they run without
            > modifications for you?

            That modification should not be necessary, since the line just above it
            includes "*.ok" and should fix all .ok files.  Perhaps you are using a
            make that expands wildcards and then runs into the maximum line length?

            The first line in the target sets the ff to 'dos' for all the .ok files, but tests 60, 71, and 74 generate files with ff=unix, so the diff fails due to the line endings not matching.  test60 actually has the command ':set ff=unix' immediately before ':w'.  test74 uses ':redir' without setting ff, causing the output file to be generated with ff=unix.  test71 does some gnarly encryption stuff that I haven't tried to follow too closely yet.

            My change above switches those three .ok files _back_ to ff=unix so the tests pass; I looked at other options but they were more invasive.

            My procedure:
            1. Build vim in the src directory with 'nmake -f Make_mvc.mak FEATURES=HUGE MBYTE=yes'
            2. Run tests in the testdir directory with 'nmake -f Make_dos.mak clean', followed by 'nmake -f Make_dos.mak'.

            Nazri, can you check that those three tests are running and succeeding for you?  I'm mystified as to what might be going wrong.  Maybe the build options have some impact on the default fileformat?  Based on the 'set ff=unix' command in test60.in, I don't see how it could succeed after the 'fixff' target has been run, unless the diff utility ignores line endings.

            -- Dave

            --
            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
          • Nazri Ramliy
            ... Gladly. I ran the two instructions above and the all the test ran fine - I saw the ALL DONE text at the end with lines upon lines of the makefile
            Message 5 of 9 , Apr 9, 2012
              On Mon, Apr 9, 2012 at 9:36 AM, David Pope <d.e.pope@...> wrote:
              > 1. Build vim in the src directory with 'nmake -f Make_mvc.mak FEATURES=HUGE
              > MBYTE=yes'
              > 2. Run tests in the testdir directory with 'nmake -f Make_dos.mak clean',
              > followed by 'nmake -f Make_dos.mak'.
              >
              > Nazri, can you check that those three tests are running and succeeding for
              > you?  I'm mystified as to what might be going wrong.  Maybe the build
              > options have some impact on the default fileformat?  Based on the 'set
              > ff=unix' command in test60.in, I don't see how it could succeed after the
              > 'fixff' target has been run, unless the diff utility ignores line endings.

              Gladly.

              I ran the two instructions above and the all the test ran fine - I saw
              the "ALL DONE" text at the end with lines upon lines of the makefile
              deleting the *.out files before that. To be extra sure that I run the
              test on a pristine vim source I recloned the vim repository from
              google code. My diff is

              c:\> diff -v
              diff (GNU diffutils) 2.8.7
              Written by Paul Eggert, Mike Haertel, David hayes,
              Richard Stallman, and Len Tower.

              obtained from http://gnuwin32.sourceforge.net/packages/diffutils.htm.
              That may or may not be the cause of the differences in our vim test results.

              Let me know if I can help in any way.

              Nazri

              --
              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
            Your message has been successfully submitted and would be delivered to recipients shortly.