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

RE: Another 9 in todo.txt

Expand Messages
  • Vince Negri
    ... Walter (and all), For some reason I had to apply the patch manually (probably my mail client trashing the tabs), but I can confirm a successful test
    Message 1 of 15 , Apr 1, 2003
    • 0 Attachment
      > This is a frightening truncation of the code. If Bram (or anybody else)
      > can point me at a URL for an obsolescent version of DJGPP, I will also
      > test against that.

      > Fixing mch_FullName() fixes the problem; w .bashrc while editing
      > bashrc~1 works with a vim.exe built with Make_djg.mak and DJGPP 2.04
      > alpha. It also works if the process is inverted. It also works with a
      > vimd.exe built with nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim".
      > I think we have a fix that is worth others trying to break.

      Walter (and all),

      For some reason I had to apply the patch manually (probably
      my mail client trashing the tabs), but I can confirm a
      successful test building with DJGPP version 2.02. :)

      Vince
      Legal Disclaimer: Any views expressed by the sender of this message are
      not necessarily those of Application Solutions Ltd. Information in this
      e-mail may be confidential and is for the use of the intended recipient
      only, no mistake in transmission is intended to waive or compromise such
      privilege. Please advise the sender if you receive this e-mail by mistake.
    • Bram Moolenaar
      ... Using _truename() sounds like a very nice and simple solution. Did you test that it also expand directory names, as in c: longna~1 file and corrects case
      Message 2 of 15 , Apr 2, 2003
      • 0 Attachment
        Walter Briscoe wrote:

        > >> >Yes, all this is supposed to be done by mch_FullName(). Somehow it
        > >> >doesn't work.
        > >>
        > >> The two versions of mch_FullName() in os_msdos.c and os_mswin.c give
        > >> different outputs from the same input. I think the code in os_msdos.c is
        > >> defective and am working on changing it.
        > >
        > >That's probably the right solution.
        > I am sorry it has taken me a long time to respond on this. I have some
        > work I am ready to show. It was developed as a stand-alone function and
        > then integrated into Vim. I looked at djg 2.03 documentation and found a
        > function which seems to hit the spot: _truename. I have done some
        > testing with the latest 2.03 build - to avoid the ntvdm.exe problems -
        > and with 2.04 alpha. I have exercised the code with W2KSP3 and W95. I
        > dare say it needs more testing; I have not been able to break it as I
        > easily could with the old code. The code is seriously shorter.

        Using _truename() sounds like a very nice and simple solution.
        Did you test that it also expand directory names, as in
        "c:\longna~1\file" and corrects case differences?

        > This is a frightening truncation of the code. If Bram (or anybody else)
        > can point me at a URL for an obsolescent version of DJGPP, I will also
        > test against that.

        DJGPP updates come out very slow, I believe 2.02 is from 2000. And it's
        free, thus updating to a recent version is always possible. Therefore,
        it's not too important to test with versions earlier than 2.02.

        > I found difficulties building with the 2.04 alpha.
        > gcc -c -O2 -DMSDOS -Iproto -Wall -Dinterrupt= -Dfar= -DMAXMEM=512 -D_NAIVE_DOS_REGS misc2.c -o obj/misc2.o
        > misc2.c: In function `putenv':
        > misc2.c:5371: argument `string' doesn't match prototype
        > c:/djgpp/include/stdlib.h:104: prototype declaration
        > make.exe: *** [obj/misc2.o] Error 1
        >
        > C:\wfb\vim\bld\vim61\src> sed 104!d < c:/djgpp/include/stdlib.h
        > int putenv(char *_val);
        >
        > C:\wfb\vim\bld\vim61\src> sed 5368,5371!d < misc2.c
        > int
        > putenv(string)
        > const char *string;
        > {
        >
        > IEEE Std 1003.1-2001 has
        > #include <stdlib.h>
        >
        > int putenv(char *string);
        >
        > My first response is to patch misc2.c. I see proto.h also has const. I
        > will not submit patches for this.

        There are conflicting standards for putenv(). I rather not change
        misc2.c, it has already been tested to work on many systems. If DJGPP
        does have a putenv() function, HAVE_PUTENV should be defined. That's
        should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
        check for DJGPP 2.04. Does it pass the version number somehow?

        > Fixing mch_FullName() fixes the problem; w .bashrc while editing
        > bashrc~1 works with a vim.exe built with Make_djg.mak and DJGPP 2.04
        > alpha. It also works if the process is inverted. It also works with a
        > vimd.exe built with nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim".
        > I think we have a fix that is worth others trying to break.

        Glad you managed to track it down and come up with a solution that makes
        the code simpler!

        --
        PRINCE: He's come to rescue me, father.
        LAUNCELOT: (embarrassed) Well, let's not jump to conclusions ...
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
      • Walter Briscoe
        In message of Wed, 2 Apr 2003 23:34:37 in , Bram Moolenaar writes ... Yes! Curiously, there
        Message 3 of 15 , Apr 2, 2003
        • 0 Attachment
          In message <200304022134.h32LYb414982@...> of Wed, 2 Apr 2003
          23:34:37 in , Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >> >> >Yes, all this is supposed to be done by mch_FullName(). Somehow it
          >> >> >doesn't work.
          >> >>
          >> >> The two versions of mch_FullName() in os_msdos.c and os_mswin.c give
          >> >> different outputs from the same input. I think the code in os_msdos.c is
          >> >> defective and am working on changing it.
          >> >
          >> >That's probably the right solution.
          >> I am sorry it has taken me a long time to respond on this. I have some
          >> work I am ready to show. It was developed as a stand-alone function and
          >> then integrated into Vim. I looked at djg 2.03 documentation and found a
          >> function which seems to hit the spot: _truename. I have done some
          >> testing with the latest 2.03 build - to avoid the ntvdm.exe problems -
          >> and with 2.04 alpha. I have exercised the code with W2KSP3 and W95. I
          >> dare say it needs more testing; I have not been able to break it as I
          >> easily could with the old code. The code is seriously shorter.
          >
          >Using _truename() sounds like a very nice and simple solution.
          >Did you test that it also expand directory names, as in
          >"c:\longna~1\file" and corrects case differences?
          Yes! Curiously, there seems to be case-distinction with device names
          too. One machine produces c: - another C:. I found no problem in any of
          this and so did not force C:

          >
          >> This is a frightening truncation of the code. If Bram (or anybody else)
          >> can point me at a URL for an obsolescent version of DJGPP, I will also
          >> test against that.
          >
          >DJGPP updates come out very slow, I believe 2.02 is from 2000. And it's
          >free, thus updating to a recent version is always possible. Therefore,
          >it's not too important to test with versions earlier than 2.02.
          Good!

          >
          >> I found difficulties building with the 2.04 alpha.
          >> gcc -c -O2 -DMSDOS -Iproto -Wall -Dinterrupt= -Dfar= -DMAXMEM=512 -
          >>D_NAIVE_DOS_REGS misc2.c -o obj/misc2.o
          >> misc2.c: In function `putenv':
          >> misc2.c:5371: argument `string' doesn't match prototype
          >> c:/djgpp/include/stdlib.h:104: prototype declaration
          >> make.exe: *** [obj/misc2.o] Error 1
          >>
          >> C:\wfb\vim\bld\vim61\src> sed 104!d < c:/djgpp/include/stdlib.h
          >> int putenv(char *_val);
          >>
          >> C:\wfb\vim\bld\vim61\src> sed 5368,5371!d < misc2.c
          >> int
          >> putenv(string)
          >> const char *string;
          >> {
          >>
          >> IEEE Std 1003.1-2001 has
          >> #include <stdlib.h>
          >>
          >> int putenv(char *string);
          >>
          >> My first response is to patch misc2.c. I see proto.h also has const. I
          >> will not submit patches for this.
          >
          >There are conflicting standards for putenv(). I rather not change
          >misc2.c, it has already been tested to work on many systems. If DJGPP
          >does have a putenv() function, HAVE_PUTENV should be defined. That's
          >should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
          >check for DJGPP 2.04. Does it pass the version number somehow?
          DJGPP does have putenv(). I built without diagnostic in 2.03 and 2.04
          with the following change:
          C:\wfb\vim\bld\vim61> diff -c src/0os_msdos.h src/os_msdos.h
          *** src/0os_msdos.h Sun Aug 5 16:18:34 2001
          --- src/os_msdos.h Wed Apr 2 23:03:12 2003
          ***************
          *** 39,44 ****
          --- 39,45 ----
          #endif
          #define BREAKCHECK_SKIP 1 /* call mch_breakcheck() each time, it's fast */
          #define HAVE_AVAIL_MEM
          + #define HAVE_PUTENV

          /*
          * Borland C++ 3.1 doesn't have _RTLENTRYF

          C:\wfb\vim\bld\vim61>

          Would Bram like the settings of HAVE_* to be checked?

          >
          >> Fixing mch_FullName() fixes the problem; w .bashrc while editing
          >> bashrc~1 works with a vim.exe built with Make_djg.mak and DJGPP 2.04
          >> alpha. It also works if the process is inverted. It also works with a
          >> vimd.exe built with nmake /f Make_ivc.mak cfg="Vim - Win32 Debug vim".
          >> I think we have a fix that is worth others trying to break.
          >
          >Glad you managed to track it down and come up with a solution that makes
          >the code simpler!
          Me too! I tend to be suspicious of a free lunch.
          --
          Walter Briscoe
        • Bram Moolenaar
          ... So long as on one machine both c:/file and C:/File are mapped to the exactly the same name, so that comparing the strings tells us if they are
          Message 4 of 15 , Apr 3, 2003
          • 0 Attachment
            Walter Briscoe wrote:

            > >Using _truename() sounds like a very nice and simple solution.
            > >Did you test that it also expand directory names, as in
            > >"c:\longna~1\file" and corrects case differences?
            > Yes! Curiously, there seems to be case-distinction with device names
            > too. One machine produces c: - another C:. I found no problem in any of
            > this and so did not force C:

            So long as on one machine both "c:/file" and "C:/File" are mapped to the
            exactly the same name, so that comparing the strings tells us if they
            are different files or not.

            > >There are conflicting standards for putenv(). I rather not change
            > >misc2.c, it has already been tested to work on many systems. If DJGPP
            > >does have a putenv() function, HAVE_PUTENV should be defined. That's
            > >should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
            > >check for DJGPP 2.04. Does it pass the version number somehow?
            >
            > DJGPP does have putenv(). I built without diagnostic in 2.03 and 2.04
            > with the following change:

            I vagually recall a problem with putenv(), I'm not sure it was with
            DJGPP. Can someone try this patch with DJGPP 2.02?

            > C:\wfb\vim\bld\vim61> diff -c src/0os_msdos.h src/os_msdos.h
            > *** src/0os_msdos.h Sun Aug 5 16:18:34 2001
            > --- src/os_msdos.h Wed Apr 2 23:03:12 2003
            > ***************
            > *** 39,44 ****
            > --- 39,45 ----
            > #endif
            > #define BREAKCHECK_SKIP 1 /* call mch_breakcheck() each time, it's fast */
            > #define HAVE_AVAIL_MEM
            > + #define HAVE_PUTENV
            >
            > /*
            > * Borland C++ 3.1 doesn't have _RTLENTRYF
            >

            > Would Bram like the settings of HAVE_* to be checked?

            What do you mean?

            --
            A mathematician is a device for turning coffee into theorems.
            Paul Erdos
            A computer programmer is a device for turning coffee into bugs.
            Bram Moolenaar

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
          • Walter Briscoe
            In message of Thu, 3 Apr 2003 22:27:35 in , Bram Moolenaar writes ... I can find no differences
            Message 5 of 15 , Apr 3, 2003
            • 0 Attachment
              In message <200304032027.h33KRZL13737@...> of Thu, 3 Apr 2003
              22:27:35 in , Bram Moolenaar <Bram@...> writes
              >
              >Walter Briscoe wrote:
              >
              >> >Using _truename() sounds like a very nice and simple solution.
              >> >Did you test that it also expand directory names, as in
              >> >"c:\longna~1\file" and corrects case differences?
              >> Yes! Curiously, there seems to be case-distinction with device names
              >> too. One machine produces c: - another C:. I found no problem in any of
              >> this and so did not force C:
              >
              >So long as on one machine both "c:/file" and "C:/File" are mapped to the
              >exactly the same name, so that comparing the strings tells us if they
              >are different files or not.
              I can find no differences with one program on one machine. .bashrc
              .BASHRC bashrc~1 and BASHRC~1 are all mapped to .bashrc. "c:/file"
              C:\FiLE etc. are all mapped to the same full name. On one W2K machine, I
              saw C: consistently; on another W95, I saw c: consistently. I saw
              nothing inconsistent on one machine.

              >
              >> >There are conflicting standards for putenv(). I rather not change
              >> >misc2.c, it has already been tested to work on many systems. If DJGPP
              >> >does have a putenv() function, HAVE_PUTENV should be defined. That's
              >> >should be in os_msdos.h. But if DJGPP 2.03 doesn't have it, we need a
              >> >check for DJGPP 2.04. Does it pass the version number somehow?
              >>
              >> DJGPP does have putenv(). I built without diagnostic in 2.03 and 2.04
              >> with the following change:
              >
              >I vagually recall a problem with putenv(), I'm not sure it was with
              >DJGPP. Can someone try this patch with DJGPP 2.02?
              Vince confirmed it builds; I don't think he checked it worked.

              >
              >> C:\wfb\vim\bld\vim61> diff -c src/0os_msdos.h src/os_msdos.h
              >> *** src/0os_msdos.h Sun Aug 5 16:18:34 2001
              >> --- src/os_msdos.h Wed Apr 2 23:03:12 2003
              >> ***************
              >> *** 39,44 ****
              >> --- 39,45 ----
              >> #endif
              >> #define BREAKCHECK_SKIP 1 /* call mch_breakcheck() each
              >>time, it's fast */
              >> #define HAVE_AVAIL_MEM
              >> + #define HAVE_PUTENV
              >>
              >> /*
              >> * Borland C++ 3.1 doesn't have _RTLENTRYF
              >>
              >
              >> Would Bram like the settings of HAVE_* to be checked?
              >
              >What do you mean?
              HAVE_* represented the series of names specified in config.h.in
              For example:
              ...
              #undef HAVE_USLEEP
              #undef HAVE_UTIME
              #undef HAVE_BIND_TEXTDOMAIN_CODESET

              /* Define if you do not have utime(), but do have the utimes() function. */
              #undef HAVE_UTIMES

              /* Define if you have the header file: */
              #undef HAVE_DIRENT_H
              #undef HAVE_ERRNO_H
              ...

              In a civilized (UNIX) world, those names are set by a configure script
              testing each in turn. At least one name (HAVE_PUTENV) was wrongly set in
              a djgpp environment. I offered to check them all.
              --
              Walter Briscoe
            • Vince Negri
              ... Seems ok with 2.02 here. Vince Legal Disclaimer: Any views expressed by the sender of this message are not necessarily those of Application Solutions Ltd.
              Message 6 of 15 , Apr 3, 2003
              • 0 Attachment
                > I vagually recall a problem with putenv(), I'm not sure it was with
                > DJGPP. Can someone try this patch with DJGPP 2.02?
                >>+ #define HAVE_PUTENV

                Seems ok with 2.02 here.

                Vince
                Legal Disclaimer: Any views expressed by the sender of this message are
                not necessarily those of Application Solutions Ltd. Information in this
                e-mail may be confidential and is for the use of the intended recipient
                only, no mistake in transmission is intended to waive or compromise such
                privilege. Please advise the sender if you receive this e-mail by mistake.
              • Vince Negri
                ... I did, and it did - files edited using the short name did not lose the long name when saved back. Vince Legal Disclaimer: Any views expressed by the sender
                Message 7 of 15 , Apr 3, 2003
                • 0 Attachment
                  > >I vagually recall a problem with putenv(), I'm not sure it was with
                  > >DJGPP. Can someone try this patch with DJGPP 2.02?
                  > Vince confirmed it builds; I don't think he checked it worked.

                  I did, and it did - files edited using the short name
                  did not lose the long name when saved back.

                  Vince


                  Legal Disclaimer: Any views expressed by the sender of this message are
                  not necessarily those of Application Solutions Ltd. Information in this
                  e-mail may be confidential and is for the use of the intended recipient
                  only, no mistake in transmission is intended to waive or compromise such
                  privilege. Please advise the sender if you receive this e-mail by mistake.
                • Walter Briscoe
                  In message of Fri, 4 Apr 2003 08:11:43 in , Vince Negri
                  Message 8 of 15 , Apr 4, 2003
                  • 0 Attachment
                    In message <35C843B8EC93D511844500306E0029B34974FA@...-
                    electronics.co.uk> of Fri, 4 Apr 2003 08:11:43 in , Vince Negri
                    <vnegri@...> writes
                    >> >I vagually recall a problem with putenv(), I'm not sure it was with
                    >> >DJGPP. Can someone try this patch with DJGPP 2.02?
                    >> Vince confirmed it builds; I don't think he checked it worked.
                    >
                    >I did, and it did - files edited using the short name
                    >did not lose the long name when saved back.
                    I think Bram was concerned about the working of putenv() in DJGPP 2.02.
                    I don't suppose you checked that! I'll construct a trivial test to save
                    you doing so:
                    C:\wfb\vim\bld\vim61\src> gcc -O2 -DMSDOS -Iproto -Wall -Dinterrupt= -Dfar= -DMAXMEM=512 -D_NAIVE_DOS_REGS tryenv.c -o tryenv.exe

                    C:\wfb\vim\bld\vim61\src> tryenv fred bill
                    Afore fred was "UnSeT"
                    After fred was "bill"
                    Used putenv("fred=bill")

                    C:\wfb\vim\bld\vim61\src> type tryenv.c
                    /* tryenv.c
                    *
                    * Trivial file to test putenv
                    *
                    * When Who What
                    * 2003-04-04 W.Briscoe Original
                    */
                    #include <stdio.h>
                    #include <stdlib.h>

                    int main(int argc, char ** argv) /* Don't care about incorrect arguments */
                    {
                    char *name = argv[1];
                    char *value = argv[2];
                    char *afore = getenv(name);
                    char *after;
                    static char setting[1024]; /* static for putenv() */

                    sprintf(setting, "%s=%s", name, value);
                    (void)putenv(setting);
                    after = getenv(name);
                    printf("Afore %s was \"%s\"\n", name, (afore) ? afore : "UnSeT");
                    printf("After %s was \"%s\"\n", name, (after) ? after : "UnSeT");
                    printf("Used putenv(\"%s\")\n", setting);
                    return 0;
                    }

                    C:\wfb\vim\bld\vim61\src>

                    By the way:
                    1) Can Vince use References: headers to allow thread link construction?
                    2) Bram, I went into an infinite loop again with make -f Make_djg.mak -n
                    as I attempted to grab a line to compile the new source. It took a fair
                    number of Cytl+C hits to kill the make. The "infinite" loop stops when
                    the machine runs out of virtual memory. It then sorts itself. I had not
                    rolled forward my --directory patch. I have still to acquire an
                    understanding of the internals of make. I did find a bug in the VC make
                    for it. :-) I suppose I ought to have a "pending" patches folder to deal
                    with such situations. It should reduce the incidence of inadvertently
                    destroyed work!! I am not ready to go for full source control.
                    --
                    Walter Briscoe
                  • Vince Negri
                    ... Thanks for the program. Seems to be fine: c: vim6 src tryenv fred bill Afore fred was UnSeT After fred was bill Used putenv( fred=bill ) ... I m stuck
                    Message 9 of 15 , Apr 4, 2003
                    • 0 Attachment
                      > I don't suppose you checked that! I'll construct a trivial test to save
                      > you doing so:

                      Thanks for the program. Seems to be fine:

                      c:\vim6\src>tryenv fred bill
                      Afore fred was "UnSeT"
                      After fred was "bill"
                      Used putenv("fred=bill")


                      > By the way:
                      > 1) Can Vince use References: headers to allow thread link construction?

                      I'm stuck with MS Outlook 97, sorry - by order of the boss :-/

                      Vince


                      Legal Disclaimer: Any views expressed by the sender of this message are
                      not necessarily those of Application Solutions Ltd. Information in this
                      e-mail may be confidential and is for the use of the intended recipient
                      only, no mistake in transmission is intended to waive or compromise such
                      privilege. Please advise the sender if you receive this e-mail by mistake.
                    • Bram Moolenaar
                      ... You could check them, but since Vim currently compiles fine, I would be surprised if the list is really wrong. Careful: DJGPP may implement some things in
                      Message 10 of 15 , Apr 4, 2003
                      • 0 Attachment
                        Walter Briscoe wrote:

                        > >> Would Bram like the settings of HAVE_* to be checked?
                        > >
                        > >What do you mean?
                        >
                        > HAVE_* represented the series of names specified in config.h.in
                        > For example:
                        > ...
                        > #undef HAVE_USLEEP
                        > #undef HAVE_UTIME
                        > #undef HAVE_BIND_TEXTDOMAIN_CODESET
                        >
                        > /* Define if you do not have utime(), but do have the utimes() function. */
                        > #undef HAVE_UTIMES
                        >
                        > /* Define if you have the header file: */
                        > #undef HAVE_DIRENT_H
                        > #undef HAVE_ERRNO_H
                        > ...
                        >
                        > In a civilized (UNIX) world, those names are set by a configure script
                        > testing each in turn. At least one name (HAVE_PUTENV) was wrongly set in
                        > a djgpp environment. I offered to check them all.

                        You could check them, but since Vim currently compiles fine, I would be
                        surprised if the list is really wrong. Careful: DJGPP may implement
                        some things in a way it doesn't work 100% for Vim and Vim must use its
                        internal function anyway.

                        --
                        Q: How many hardware engineers does it take to change a lightbulb?
                        A: None. We'll fix it in software.

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                        \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
                      Your message has been successfully submitted and would be delivered to recipients shortly.