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

Re: VIM 7.0026: failed tests

Expand Messages
  • Johnny Blaze
    ... Bram, The problem with test11 appears to be the gnuwin32 port of sed. This version of sed operates in text mode by default, which changes line-endings to
    Message 1 of 27 , Jan 3, 2005
    • 0 Attachment
      On Sun, 02 Jan 2005 22:33:08 +0100, Bram Moolenaar <Bram@...> wrote:
      >
      > Johnny Blaze wrote:
      >
      > > test11 and test30 still fail. I used "cvs co -kb vim7/src/testdir"
      > > after removing testdir. -kb is supposed to use the same line endings
      > > as stored in CVS.
      >
      > test11 fails if gzip is not available. Perhaps that's the problem you
      > are encountering?
      >
      > It appears the test[11|30].[in|ok] files in CVS are identical to what I
      > have. Another cause for problems is a diff program that can't handle
      > the different line endings.

      Bram,

      The problem with test11 appears to be the gnuwin32 port of sed. This
      version of sed operates in text mode by default, which changes
      line-endings to the native system (only if sed changes something, if
      you run a cat-like sed script, it appears to put out what you put in).
      If you run it in binary mode, it leaves line-endings alone.

      I changed the sed command in test11.in to sed -B s/e/E ... and it works fine.

      Again on test30, If I put the snapshot-zip version of test30.ok in the
      working directory and cvs update test30.ok it shows that it was
      locally modified. If I cvs update -kb test30.ok (-kb is supposed to
      use the same line-endings as stored in the repos.) it still shows
      modified. Vim sees test30.ok as ff=unix, so fixff will cause test30
      to fail if you put the snapshot version in.

      --

      . o O pyromancer O o .
    • Walter Briscoe
      In message of Tue, 4 Jan 2005 09:40:59 in , Johnny Blaze writes ... -B is not a standard
      Message 2 of 27 , Jan 4, 2005
      • 0 Attachment
        In message <804f592d05010319402ef2deab@...> of Tue, 4 Jan
        2005 09:40:59 in , Johnny Blaze <pyromancer@...> writes
        >On Sun, 02 Jan 2005 22:33:08 +0100, Bram Moolenaar <Bram@...> wrote:
        >>
        >> Johnny Blaze wrote:
        >>
        >> > test11 and test30 still fail. I used "cvs co -kb vim7/src/testdir"
        >> > after removing testdir. -kb is supposed to use the same line endings
        >> > as stored in CVS.
        >>
        >> test11 fails if gzip is not available. Perhaps that's the problem you
        >> are encountering?
        >>
        >> It appears the test[11|30].[in|ok] files in CVS are identical to what I
        >> have. Another cause for problems is a diff program that can't handle
        >> the different line endings.
        >
        >Bram,
        >
        >The problem with test11 appears to be the gnuwin32 port of sed. This
        >version of sed operates in text mode by default, which changes
        >line-endings to the native system (only if sed changes something, if
        >you run a cat-like sed script, it appears to put out what you put in).
        > If you run it in binary mode, it leaves line-endings alone.
        >
        >I changed the sed command in test11.in to sed -B s/e/E ... and it works fine.

        -B is not a standard flag in sed which only operates on text files.

        I download the UNIX files to an MS system. I have to convert line
        endings for tests. I do this with the following in a .bat file:

        tar c testdir | gzip -c > testdir.tar.gz
        move testdir testdir.0 > nul
        untar -cq testdir.tar.gz

        :: vim.bat sets echo off
        call vim.bat -eu NONE "+set backup backupext=.0 ff=dos" +wq Make_ivc.mak
        @if not %makevim%.==. @echo on
        call vim.bat -eu NONE "+set backup backupext=.0 ff=dos" +wq vim16.def
        @if not %makevim%.==. @echo on
        call vim.bat -eu NONE "+set backup backupext=.0 ff=dos" +wq vim.rc
        @if not %makevim%.==. @echo on

        (The echo manipulation code above is unnecessary. "vim ..." allows vim
        to change reporting in the calling script; "call vim ..." isolates the
        effect.)

        As I found using vim to change line endings was painfully slow, I use
        untar from ftp://ftp.cs.pdx.edu/pub/elvis/untar.c. - a 40k portable file

        I don't have time now to get back up to speed on vim testing.

        BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
        asserted a change was an optimisation. A long time ago, I absorbed 3
        optimisation rules which I paraphrase as: don't; don't yet; measure.
        --
        Walter Briscoe
      • Bram Moolenaar
        ... Ah, that explains the problems. The -B argument is not available elsewhere, thus we can t use that. You can try adding a command to remove the extra CR
        Message 3 of 27 , Jan 4, 2005
        • 0 Attachment
          Johnny Blaze wrote:

          > The problem with test11 appears to be the gnuwin32 port of sed. This
          > version of sed operates in text mode by default, which changes
          > line-endings to the native system (only if sed changes something, if
          > you run a cat-like sed script, it appears to put out what you put in).
          > If you run it in binary mode, it leaves line-endings alone.
          >
          > I changed the sed command in test11.in to sed -B s/e/E ... and it
          > works fine.

          Ah, that explains the problems. The -B argument is not available
          elsewhere, thus we can't use that. You can try adding a command to
          remove the extra CR characters:

          *** testdir/test11.in~ Sun Jul 18 21:46:21 2004
          --- testdir/test11.in Tue Jan 4 09:55:07 2005
          ***************
          *** 44,49 ****
          --- 44,50 ----
          :au FilterReadPost *.out '[,']s/x/X/g
          :e! test.out " Edit the output file
          :23,$!cat
          + :23,$s/\r$// " remove CR for when sed adds them
          :au! FileReadPre *.gz !gzip -d <afile>
          :au FileReadPre *.gz call rename(expand("<afile>:r"), expand("<afile>"))
          :au! FileReadPost *.gz '[,']s/l/L/

          > Again on test30, If I put the snapshot-zip version of test30.ok in the
          > working directory and cvs update test30.ok it shows that it was
          > locally modified. If I cvs update -kb test30.ok (-kb is supposed to
          > use the same line-endings as stored in the repos.) it still shows
          > modified. Vim sees test30.ok as ff=unix, so fixff will cause test30
          > to fail if you put the snapshot version in.

          I don't understand this. It works fine for me, thus the version of
          test30.ok in the snapshot should be OK. Note that it is in unix format,
          thus fixff must change it to dos format. If you compare the files after
          that they will differ.

          I just checked again that the current files (snapshot 29) work fine for
          me. That is using Make_mvc.mak.

          --
          hundred-and-one symptoms of being an internet addict:
          218. Your spouse hands you a gift wrapped magnet with your PC's name
          on it and you accuse him or her of genocide.

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
          \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
        • Johnny Blaze
          ... This works excellently. ... I found something that does work. (I have attached a patch for src/testdir/Make_dos.mak. Basically duplicate fixff s only
          Message 4 of 27 , Jan 4, 2005
          • 0 Attachment
            On Tue, 04 Jan 2005 11:18:31 +0100, Bram Moolenaar <Bram@...> wrote:
            >
            > Johnny Blaze wrote:
            >
            > > The problem with test11 appears to be the gnuwin32 port of sed. This
            > > version of sed operates in text mode by default, which changes
            > > line-endings to the native system (only if sed changes something, if
            > > you run a cat-like sed script, it appears to put out what you put in).
            > > If you run it in binary mode, it leaves line-endings alone.
            > >
            > > I changed the sed command in test11.in to sed -B s/e/E ... and it
            > > works fine.
            >
            > Ah, that explains the problems. The -B argument is not available
            > elsewhere, thus we can't use that. You can try adding a command to
            > remove the extra CR characters:
            >
            > *** testdir/test11.in~ Sun Jul 18 21:46:21 2004
            > --- testdir/test11.in Tue Jan 4 09:55:07 2005
            > ***************
            > *** 44,49 ****
            > --- 44,50 ----
            > :au FilterReadPost *.out '[,']s/x/X/g
            > :e! test.out " Edit the output file
            > :23,$!cat
            > + :23,$s/\r$// " remove CR for when sed adds them
            > :au! FileReadPre *.gz !gzip -d <afile>
            > :au FileReadPre *.gz call rename(expand("<afile>:r"), expand("<afile>"))
            > :au! FileReadPost *.gz '[,']s/l/L/

            This works excellently.

            > I don't understand this. It works fine for me, thus the version of
            > test30.ok in the snapshot should be OK. Note that it is in unix format,
            > thus fixff must change it to dos format. If you compare the files after
            > that they will differ.
            >
            > I just checked again that the current files (snapshot 29) work fine for
            > me. That is using Make_mvc.mak.

            I found something that does work. (I have attached a patch for
            src/testdir/Make_dos.mak. Basically duplicate fixff's only action and
            change ff=dos to ff=unix and make it only for test30.ok.

            @@ -46,6 +45,7 @@

            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 test30.ok

            -------------

            That seems to work everytime even after deleting the file (test30.ok)
            and pulling another from CVS.

            Its kinda kludgy, but it works.

            --

            . o O pyromancer O o .
          • Bram Moolenaar
            ... I don t like this solution, because it makes an exception for one file. It does point in the right direction: Apparently it worked for me because my diff
            Message 5 of 27 , Jan 4, 2005
            • 0 Attachment
              Johnny Blaze wrote:

              > > I don't understand this. It works fine for me, thus the version of
              > > test30.ok in the snapshot should be OK. Note that it is in unix
              > > format, thus fixff must change it to dos format. If you compare the
              > > files after that they will differ.
              > >
              > > I just checked again that the current files (snapshot 29) work fine for
              > > me. That is using Make_mvc.mak.
              >
              > I found something that does work. (I have attached a patch for
              > src/testdir/Make_dos.mak. Basically duplicate fixff's only action and
              > change ff=dos to ff=unix and make it only for test30.ok.

              I don't like this solution, because it makes an exception for one file.
              It does point in the right direction: Apparently it worked for me
              because my "diff" ignored differences in dos/unix file formats.
              test30.ok would be dos and test30.out will be unix format.

              For DOS I prefer all file formats to be dos (after fixff), so that there
              are no exceptions.

              Besides this, using the "cat" command will break the test for people
              that don't have it. I'll change the test to avoid it. Makes it
              portable and faster too.

              --
              hundred-and-one symptoms of being an internet addict:
              225. You sign up for free subscriptions for all the computer magazines

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
            • Johnny Blaze
              ... Thanks Bram. -- . o O pyromancer O o .
              Message 6 of 27 , Jan 4, 2005
              • 0 Attachment
                On Tue, 04 Jan 2005 16:07:50 +0100, Bram Moolenaar <Bram@...> wrote:
                > For DOS I prefer all file formats to be dos (after fixff), so that there
                > are no exceptions.
                >
                > Besides this, using the "cat" command will break the test for people
                > that don't have it. I'll change the test to avoid it. Makes it
                > portable and faster too.

                Thanks Bram.

                --

                . o O pyromancer O o .
              • Johnny Blaze
                On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe ... Bram s got it fixed without using the -B switch. So now, its nice and portable. ... I ve been looking for
                Message 7 of 27 , Jan 5, 2005
                • 0 Attachment
                  On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe
                  <wbriscoe@...> wrote:
                  > -B is not a standard flag in sed which only operates on text files.
                  >
                  > I download the UNIX files to an MS system. I have to convert line
                  > endings for tests. I do this with the following in a .bat file:
                  > [snip]

                  Bram's got it fixed without using the -B switch. So now, its nice and portable.

                  > BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
                  > asserted a change was an optimisation. A long time ago, I absorbed 3
                  > optimisation rules which I paraphrase as: don't; don't yet; measure.

                  I've been looking for an MS equivalent of time on linux. I was going
                  to time vim as it went through the tests... it should give a profile
                  of vim doing alot of different things. then some simple load times.

                  The data that I have now... It "pops" faster (loads) on both a 1.8GHz
                  P4 and a 3.0GHz than it does with CPUNR=i686. It takes longer to
                  compile, and it runs the tests faster. As you can see I have no hard
                  numbers as of yet.


                  --

                  . o O pyromancer O o .
                • Walter Briscoe
                  In message of Wed, 5 Jan 2005 18:36:52 in , Johnny Blaze writes ... Good! ... Look for
                  Message 8 of 27 , Jan 6, 2005
                  • 0 Attachment
                    In message <804f592d050105043637e68b22@...> of Wed, 5 Jan
                    2005 18:36:52 in , Johnny Blaze <pyromancer@...> writes
                    >On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe
                    ><wbriscoe@...> wrote:
                    >> -B is not a standard flag in sed which only operates on text files.
                    >>
                    >> I download the UNIX files to an MS system. I have to convert line
                    >> endings for tests. I do this with the following in a .bat file:
                    >> [snip]
                    >
                    >Bram's got it fixed without using the -B switch. So now, its nice and portable.
                    Good!

                    >
                    >> BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
                    >> asserted a change was an optimisation. A long time ago, I absorbed 3
                    >> optimisation rules which I paraphrase as: don't; don't yet; measure.
                    >
                    >I've been looking for an MS equivalent of time on linux. I was going
                    >to time vim as it went through the tests... it should give a profile
                    >of vim doing alot of different things. then some simple load times.
                    Look for timethis.exe which is a crude MS elapsed time measurer. If you
                    can't find it, I will send you a copy. Time comparison is REALLY hard
                    due to caching. On UNIX (AIX), I never found satisfactory way to flush
                    cache. I wrote a small MS program to time repeated runs of a given
                    program. It measures mean and standard deviation of execution times. You
                    then need standard difference of means techniques to estimate
                    probability of chance giving observed results. I attach source. Real
                    gonad crusher is that execution times are not normally distributed and I
                    have no theory to compare anything else. It is easy where something
                    takes one hour rather than six. It is really hard when it takes 59
                    minutes rather than 60. I think you should probably reboot your machine
                    before making each measurement to have any chance of repeatable results.
                    You then have a problem that your repeatable results may not be typical.

                    >
                    >The data that I have now... It "pops" faster (loads) on both a 1.8GHz
                    >P4 and a 3.0GHz than it does with CPUNR=i686. It takes longer to
                    >compile, and it runs the tests faster. As you can see I have no hard
                    >numbers as of yet.

                    With rare exceptions, such as searching multi-megabyte files or running
                    it once for each file in a directory, I find vim is fast enough.
                    The former case can be sped by avoiding expensive things like
                    'incsearch'; the latter by running vim once for all files in a directory
                    if one has enough effort to improve the algorithm. That effort is not
                    usually available.
                  • Antoine J. Mechelynck
                    Bram Moolenaar wrote: [...] ... Dos has equivalents of the cat command for the most common cases, as follows: Copy to stdout: Unix: cat foo.bar Dos: type
                    Message 9 of 27 , Jan 7, 2005
                    • 0 Attachment
                      Bram Moolenaar wrote:
                      [...]
                      > Besides this, using the "cat" command will break the test for people
                      > that don't have it. I'll change the test to avoid it. Makes it
                      > portable and faster too.
                      >

                      Dos has equivalents of the "cat" command for the most common cases, as
                      follows:

                      Copy to stdout:
                      Unix: cat foo.bar
                      Dos: type foo.bar

                      Append:
                      Unix: cat foo.txt >> bar.txt
                      Dos: type foo.txt >> bar.txt

                      Concatenate:
                      Unix: cat file1 file2 file3 > file4
                      Dos: copy /B file1+file2+file3 file4

                      (the /B is optional, it forces "binary" or "raw" mode. /A would mean
                      "ASCII" or "cooked" mode instead, including stop on Ctrl-Z and add
                      Ctrl-Z at EOF if not present. The default depends on the file type
                      [extension or device name].)

                      Just FYI (my 0,02€).
                      Best regards,
                      Tony.
                    • Antoine J. Mechelynck
                      Johnny Blaze wrote: [...] ... [...] I m not sure what time on Linux does but Dos has date and time commands: DATE [new date] TIME [new time] Arguments (if
                      Message 10 of 27 , Jan 7, 2005
                      • 0 Attachment
                        Johnny Blaze wrote:
                        [...]
                        > I've been looking for an MS equivalent of time on linux. I was going
                        > to time vim as it went through the tests... it should give a profile
                        > of vim doing alot of different things. then some simple load times.
                        [...]

                        I'm not sure what time on Linux does but Dos has "date" and "time" commands:

                        DATE [new date]

                        TIME [new time]

                        Arguments (if present) are locale-dependent. If called without an
                        argument, each of these commands displays the current value then asks
                        for a new setting. (The prompt for DATE tells you which format is
                        expected.) A workaround (to display the date/time without changing it)
                        would be

                        DATE < nul
                        TIME < nul

                        but of course they still display the prompts, which may in this case be
                        regarded as interspersed garbage. This may or may not suit you.

                        In CMD.EXE only (not in COMMAND.COM), and only when command extensions
                        are enabled, you can also use

                        DATE /T
                        TIME /T

                        to display the current values with no prompting. On my system,
                        "time<nul" displays the time to the last tenth of a second, but "time/t"
                        only gives it to the minute, which might not be precise enough for you.

                        Note: IIRC (and if ECHO ON displays the %PROMPT% -- I haven't tested it
                        recently in batch), you can also achieve timestamping of all commands in
                        a batch script with

                        ECHO ON
                        PROMPT $D^I$T$_$P$G

                        instead of the more usual "@ECHO OFF" at the start. ^I is an actual hard
                        tab (or spaces if you like that better). This gives a timestamp (to the
                        tenth of a second in COMMAND.COM or CMD.EXE) immediately above each
                        executed command. Or remove the $_$P and you get the timestamp (instead
                        of the current drive and directory) left of the > prompt.

                        HTH,
                        Tony.
                      • Johnny Blaze
                        I compiled two different versions. The only difference is CPUNR=i686 and CPUNR=P4. These are from the vim7 module in CVS current as of 10:00PM CST
                        Message 11 of 27 , Jan 7, 2005
                        • 0 Attachment
                          I compiled two different versions. The only difference is CPUNR=i686
                          and CPUNR=P4. These are from the vim7 module in CVS current as of
                          10:00PM CST 1/6/2004.

                          I ran two test runs for the cli and the gui

                          Test1: run the test suite
                          Test2: load vim and quit immediately ((g)vim +q) in the build
                          directory, which should mean minimal options/plugins etc.

                          Note: the gui tests are a little skewed (they should be shorter)
                          since when the gui runs the tests, vimrun pops a window that you have
                          to press enter before it returns control. I practiced a few times and
                          think that the skew is minimal.

                          Test System: P4 2.6GHz, 1GB Ram (DDR200), UDMA hard drive, WinXPSP2

                          Results:

                          Test1:
                          --------
                          (i686, cli) = 1:08.750
                          (P4, cli) = 1:07.562
                          ========
                          difference: P4 1.188 seconds faster

                          (i686, gui) = 1:17.985
                          (P4, gui) = 1:16.203
                          ========
                          difference: P4 1.782 seconds faster

                          Test2:
                          --------
                          (i686, cli) = 0.360
                          (P4, cli) = 0.344
                          =========
                          difference: P4 0.016 seconds faster

                          (i686, gui) = 0.531
                          (P4, gui) = 0.484
                          =========
                          difference: P4 0.047 seconds faster

                          I've noticed that several people were sceptical about any performance
                          gain. I realize that these gains are quite small, but they are
                          performance gains. Seeing as how there were no actual code changes
                          needed to get this performance increase, only a different compiler
                          option, I don't know why anyone would protest the option being
                          available.


                          On Thu, 6 Jan 2005 09:38:06 +0000, Walter Briscoe
                          <wbriscoe@...> wrote:
                          > In message <804f592d050105043637e68b22@...> of Wed, 5 Jan
                          > 2005 18:36:52 in , Johnny Blaze <pyromancer@...> writes
                          > >On Tue, 4 Jan 2005 08:01:21 +0000, Walter Briscoe
                          > ><wbriscoe@...> wrote:
                          > >> -B is not a standard flag in sed which only operates on text files.
                          > >>
                          > >> I download the UNIX files to an MS system. I have to convert line
                          > >> endings for tests. I do this with the following in a .bat file:
                          > >> [snip]
                          > >
                          > >Bram's got it fixed without using the -B switch. So now, its nice and portable.
                          > Good!
                          >
                          > >
                          > >> BTW Johnny, you did not reply to "Scenario? Numbers?" from me when you
                          > >> asserted a change was an optimisation. A long time ago, I absorbed 3
                          > >> optimisation rules which I paraphrase as: don't; don't yet; measure.
                          > >
                          > >I've been looking for an MS equivalent of time on linux. I was going
                          > >to time vim as it went through the tests... it should give a profile
                          > >of vim doing alot of different things. then some simple load times.
                          > Look for timethis.exe which is a crude MS elapsed time measurer. If you
                          > can't find it, I will send you a copy. Time comparison is REALLY hard
                          > due to caching. On UNIX (AIX), I never found satisfactory way to flush
                          > cache. I wrote a small MS program to time repeated runs of a given
                          > program. It measures mean and standard deviation of execution times. You
                          > then need standard difference of means techniques to estimate
                          > probability of chance giving observed results. I attach source. Real
                          > gonad crusher is that execution times are not normally distributed and I
                          > have no theory to compare anything else. It is easy where something
                          > takes one hour rather than six. It is really hard when it takes 59
                          > minutes rather than 60. I think you should probably reboot your machine
                          > before making each measurement to have any chance of repeatable results.
                          > You then have a problem that your repeatable results may not be typical.
                          >
                          > >
                          > >The data that I have now... It "pops" faster (loads) on both a 1.8GHz
                          > >P4 and a 3.0GHz than it does with CPUNR=i686. It takes longer to
                          > >compile, and it runs the tests faster. As you can see I have no hard
                          > >numbers as of yet.
                          >
                          > With rare exceptions, such as searching multi-megabyte files or running
                          > it once for each file in a directory, I find vim is fast enough.
                          > The former case can be sped by avoiding expensive things like
                          > 'incsearch'; the latter by running vim once for all files in a directory
                          > if one has enough effort to improve the algorithm. That effort is not
                          > usually available.
                          >
                          >
                          > --
                          > Walter Briscoe
                          >
                          >
                          >
                          >


                          --

                          . o O pyromancer O o .
                        • Dan Sharp
                          ... Sorry for not thinking of this earlier, but would you care to change the P4 option value to pentium4 instead? This would make it consistent with the gcc
                          Message 12 of 27 , Jan 7, 2005
                          • 0 Attachment
                            Johnny Blaze wrote:
                            > On Sat, 01 Jan 2005 14:23:06 +0100, Bram Moolenaar <Bram@...> wrote:
                            >
                            >>>I have attached a patch to Make_mvc.mak. It adds another CPUNR option
                            >>>and removes some debug options from CFLAGS, PDB, and LINK_PDB.
                            >>>
                            >>>CPUNR: Adds "P4" to the list. It uses the options /G7 and /arch:SSE2.
                            >>> This causes CL to optimize the code specifically for P4 and AMD
                            >>>processors that implement SSE2 instructions. /arch:SSE2 is a new
                            >>>option as of VC7.0.
                            >>
                            >>Looks OK. P4 also needs to be added to the comments at line 58.
                            >
                            >
                            > got it.

                            Sorry for not thinking of this earlier, but would you care to change the
                            P4 option value to pentium4 instead? This would make it consistent with
                            the gcc values for ARCH (and formerly CPUNR) in Make_cyg.mak and
                            Make_ming.mak, which include values like i386, i486, i586, i686,
                            pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4,
                            prescott, nocona, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4,
                            athlon-xp, athlon-mp, winchip-c6, winchip2 and c3 [from the gcc 3.3.3
                            man page]. I don't know if the msvc compiler supports all these
                            targets, but for those it does I think it would be a good idea to use a
                            matching name.

                            Also, in earlier messages it was decided to remove the CPUNR option from
                            Make_cyg.mak and Make_ming.mak in favor of ARCH. I was wondering if
                            the ARCH option could be renamed CPUNR as well. It would still do
                            everything that ARCH currently does, and everything the previous CPUNR
                            option did would still be removed. Alternatively, the CPUNR option in
                            Make_mvc.mak and Make_bc5.mak could be renamed ARCH.

                            The main reason for the above two suggestions is consistency. The four
                            win32 makefiles (Make_bc5.mak, Make_cyg.mak, Make_ming.mak, and
                            Make_mvc.mak) should have as much in common as possible so that you can
                            use the same compile options for each one. The above two changes would
                            let CPUNR=pentium4 work in all four makefiles (in Make_bc5.mak it would
                            be unrecognized and simply get converted to i386).

                            Dan Sharp
                          • Bram Moolenaar
                            ... Does MSVC understand pentium4 ? Then we can change P4 to pentium4. ... For things that are CPU numbers we should use CPUNR. ARCH sounds more like
                            Message 13 of 27 , Jan 8, 2005
                            • 0 Attachment
                              Dan Sharp wrote:

                              > >>Looks OK. P4 also needs to be added to the comments at line 58.
                              >
                              > Sorry for not thinking of this earlier, but would you care to change the
                              > P4 option value to pentium4 instead? This would make it consistent with
                              > the gcc values for ARCH (and formerly CPUNR) in Make_cyg.mak and
                              > Make_ming.mak, which include values like i386, i486, i586, i686,
                              > pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4,
                              > prescott, nocona, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4,
                              > athlon-xp, athlon-mp, winchip-c6, winchip2 and c3 [from the gcc 3.3.3
                              > man page]. I don't know if the msvc compiler supports all these
                              > targets, but for those it does I think it would be a good idea to use a
                              > matching name.

                              Does MSVC understand "pentium4"? Then we can change P4 to pentium4.

                              > Also, in earlier messages it was decided to remove the CPUNR option from
                              > Make_cyg.mak and Make_ming.mak in favor of ARCH. I was wondering if
                              > the ARCH option could be renamed CPUNR as well. It would still do
                              > everything that ARCH currently does, and everything the previous CPUNR
                              > option did would still be removed. Alternatively, the CPUNR option in
                              > Make_mvc.mak and Make_bc5.mak could be renamed ARCH.

                              For things that are CPU numbers we should use CPUNR. ARCH sounds more
                              like "architecture", which could mean many things.

                              > The main reason for the above two suggestions is consistency. The four
                              > win32 makefiles (Make_bc5.mak, Make_cyg.mak, Make_ming.mak, and
                              > Make_mvc.mak) should have as much in common as possible so that you can
                              > use the same compile options for each one. The above two changes would
                              > let CPUNR=pentium4 work in all four makefiles (in Make_bc5.mak it would
                              > be unrecognized and simply get converted to i386).

                              That's good. For Vim 7 we can make changes like this.

                              --
                              GOD: That is your purpose Arthur ... the Quest for the Holy Grail ...
                              "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/ \\\
                              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                              \\\ Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                            • Dan Sharp
                              ... Not directly, but that doesn t matter. Make_mvc.mak just looks at the value of CPUNR and converts it to the appropriate /Gx option, so it really shouldn t
                              Message 14 of 27 , Jan 8, 2005
                              • 0 Attachment
                                Bram Moolenaar wrote:

                                > Dan Sharp wrote:
                                >
                                >>>> Looks OK. P4 also needs to be added to the comments at line 58.
                                >>
                                >>
                                >> Sorry for not thinking of this earlier, but would you care to change
                                >> the P4 option value to pentium4 instead? This would make it
                                >> consistent with the gcc values for ARCH (and formerly CPUNR) in
                                >> Make_cyg.mak and Make_ming.mak, which include values like i386, i486,
                                >> i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3,
                                >> pentium4, prescott, nocona, k6, k6-2, k6-3, athlon, athlon-tbird,
                                >> athlon-4, athlon-xp, athlon-mp, winchip-c6, winchip2 and c3 [from the
                                >> gcc 3.3.3 man page]. I don't know if the msvc compiler supports all
                                >> these targets, but for those it does I think it would be a good idea
                                >> to use a matching name.
                                >
                                > Does MSVC understand "pentium4"? Then we can change P4 to pentium4.

                                Not directly, but that doesn't matter. Make_mvc.mak just looks at the
                                value of CPUNR and converts it to the appropriate /Gx option, so it
                                really shouldn't matter which label is used to assign the value.
                                Make_cyg.mak and Make_ming.mak are the ones that use the value directly
                                (-march=$CPUNR) so those must use use correct value, like pentium4.

                                >> Also, in earlier messages it was decided to remove the CPUNR option
                                >> from Make_cyg.mak and Make_ming.mak in favor of ARCH. I was
                                >> wondering if the ARCH option could be renamed CPUNR as well. It
                                >> would still do everything that ARCH currently does, and everything
                                >> the previous CPUNR option did would still be removed. Alternatively,
                                >> the CPUNR option in Make_mvc.mak and Make_bc5.mak could be renamed
                                >> ARCH.
                                >
                                > For things that are CPU numbers we should use CPUNR. ARCH sounds more
                                > like "architecture", which could mean many things.

                                Sounds good. The ARCH option does mean architecture, because that is
                                what is getting set by it (the -march compile flag) for gcc. The CPUNR
                                option was used to set the -mcpu compile flag for gcc. MSVC and BCC55
                                only have one option to set, but I am not sure if it corresponds more to
                                the -march or the -mcpu option. Using CPUNR for all of them would
                                probably be the safest bet.

                                Dan Sharp
                              Your message has been successfully submitted and would be delivered to recipients shortly.