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

Re: status of tests in src/testdir?

Expand Messages
  • Bram Moolenaar
    ... On Linux they do. Some tests may not work on Windows. Some may not work when some external commands are missing. ... Path expansion has been unreliable,
    Message 1 of 9 , Apr 2 1:44 PM
    View Source
    • 0 Attachment
      David Pope wrote:

      > I've been trying to get the tests to run cleanly (host and target: Windows
      > 7 x64), but I'm not having much luck with some of them. Are they
      > up-to-date and expected to run cleanly?

      On Linux they do. Some tests may not work on Windows. Some may not
      work when some external commands are missing.

      > I've been assuming that any issues I'm finding are due to my own
      > environment, of course. But test 73, for example, isn't cooperating. It
      > tests autocompletion for the :find command, and several of its tests set
      > the '**' wildchar in the path option, e.g.
      >
      > set path=Xfind/**
      >
      > It's not working right. When troubleshooting I found this note at the end
      > of editing.txt:
      >
      > Note that completion for ":find", ":sfind", and ":tabfind" commands do
      > not
      > currently work with 'path' items that contain a url or use the double
      > star
      > (/usr/**2) or upward search (;) notations. >
      >
      > Is the doc accurate? If so, what does that mean for the test?

      Path expansion has been unreliable, I have suggested to do a rewrite,
      but that hasn't happened yet. Test 73 is included for Mingw and DOS
      though, thus I think they do work, or did work at some point in time.

      > Since I've encountered a handful of other tests that seem to exhibit a
      > little "bit rot" (my own environment may still be the culprit, of course),
      > I figured now would be a good time to ask whether they're expected to run
      > on Windows 7, before I continue digging in. I've already been running
      > under the debugger and I have a clue to what's going on, but the find-files
      > code is a lot to digest.

      The tests should either succeed or be skipped. What Makefile are you
      using?

      --
      DINGO: Wicked wicked Zoot ... she is a bad person and she must pay the
      penalty. And here in Castle Anthrax, we have but one punishment
      ... you must tie her down on a bed ... and spank her. Come!
      GIRLS: A spanking! A spanking!
      "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
      ... 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
      Message 2 of 9 , Apr 2 11:31 PM
      View Source
      • 0 Attachment
        On Mon, Apr 2, 2012 at 9:04 AM, David Pope <d.e.pope@...> wrote:
        > It's not working right. When troubleshooting I found this note at the end
        > of editing.txt:
        >
        > Note that completion for ":find", ":sfind", and ":tabfind" commands do
        > not
        > currently work with 'path' items that contain a url or use the double
        > star
        > (/usr/**2) or upward search (;) notations. >
        >
        > Is the doc accurate? If so, what does that mean for the test?

        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:

        ---- 8< ----
        diff -r 2cfb68fa26cd runtime/doc/editing.txt
        --- a/runtime/doc/editing.txt Wed Mar 28 20:51:51 2012 +0200
        +++ b/runtime/doc/editing.txt Tue Apr 03 13:46:19 2012 +0800
        @@ -1641,6 +1641,6 @@

        Note that completion for ":find", ":sfind", and ":tabfind" commands do not
        currently work with 'path' items that contain a url or use the double star
        - (/usr/**2) or upward search (;) notations. >
        + with depth limiter (/usr/**2) or upward search (;) notations. >

        vim:tw=78:ts=8:ft=help:norl:
        ---- >8 ----

        An example to show differences in behavior between the :find completion
        and find command for the /path/**N notation (the former does not support
        it while the latter do):

        If you had a file:

        /in/challenger/deep/JimmyHoffa.txt

        And you do:

        :set path=/in/**2
        :find JimmyHoffa.txt<enter>

        will open the file

        /in/challenger/deep/JimmyHoffa.txt

        while

        :set path=/in/**2
        :find JimmyHoffa<tab>

        will not be able to suggest any completion at all (note the <enter> vs.
        <tab> issuance at the end of the :find commands above).

        This is because the :find completion uses globpath() to find the
        possible candidates and globpath() does not support the depth limiting
        **N notation or upward search as documented at the end of ":help
        globpath()":

        Upwards search and limiting the depth of "**" is not
        supported, thus using 'path' will not always work properly.

        IIRC, the patch and its corresponding test (test73) as of changeset
        1ead15c2ffd0 worked fine on both Linux and Windows 7 x64, using
        msvc-vim. I could not remember if I ever tried running the test in mingw
        vim and/or DJGPP vim. Which environment did you use to compile vim in? I
        might be able to rerun the test in the same environment as yours on my
        PC at home and report my findings here.

        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
        ... Yes, I m using Make_dos.mak. I m only working with the tests included there. ... OK, I ll dig deeper and try to isolate the issue. I m not working with
        Message 3 of 9 , Apr 3 8:36 AM
        View Source
        • 0 Attachment
          On Mon, Apr 2, 2012 at 4:44 PM, Bram Moolenaar <Bram@...> wrote:

          David Pope wrote:

          > I've been trying to get the tests to run cleanly (host and target: Windows
          > 7 x64), but I'm not having much luck with some of them.  Are they
          > up-to-date and expected to run cleanly?

          On Linux they do.  Some tests may not work on Windows.  Some may not
          work when some external commands are missing.

          Yes, I'm using Make_dos.mak.  I'm only working with the tests included there.
           
          Path expansion has been unreliable, I have suggested to do a rewrite,
          but that hasn't happened yet. Test 73 is included for Mingw and DOS
          though, thus I think they do work, or did work at some point in time.

          OK, I'll dig deeper and try to isolate the issue.  I'm not working with 100% clean code, so I'll get the test set up to run on vanilla before reporting further results.

          ----
          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
        • 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 4 of 9 , Apr 3 10:36 PM
          View Source
          • 0 Attachment
            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 5 of 9 , Apr 5 6:38 AM
            View Source
            • 0 Attachment
              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 6 of 9 , Apr 6 4:11 AM
              View Source
              • 0 Attachment
                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 7 of 9 , Apr 8 6:36 PM
                View Source
                • 0 Attachment
                  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 8 of 9 , Apr 9 3:31 AM
                  View Source
                  • 0 Attachment
                    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.