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

Defining declarations located in main.c

Expand Messages
  • Walter Briscoe
    In a recent thread, it would have been useful to replace Vim s main.c with the following code. /* Dummy Vim to exercise mch_FullName() */ typedef unsigned char
    Message 1 of 3 , Apr 2, 2003
    • 0 Attachment
      In a recent thread, it would have been useful to replace Vim's main.c
      with the following code.
      /* Dummy Vim to exercise mch_FullName() */

      typedef unsigned char char_u;
      # define __ARGS(x) x
      int mch_FullName __ARGS((char_u *fname, char_u *buf, int len, int force));

      #include <stdio.h>

      int main(int argc, char **argv) {
      char_u buf[256];

      printf("argc = %d, argv[1] = \"%s\"\n", argc, argv[1]);
      (void)mch_FullName(argv[1], buf, sizeof buf, 1);
      printf("buf = \"%s\"\n", buf);

      return 0;
      }

      (What I actually did was construct a one module program with the
      relevant pieces of Vim; doing this is a tedious process.)

      That fails to link with about 550 unresolved external symbols because
      the defining declarations of many names are located in main.c. Ideally,
      I would like main.c only to have the defining declaration of main() to
      simplify the sort of construction I have just tried to illustrate. One
      benefit is that constructing testbeds for low-level Vim functions
      becomes a LOT easier. Also main() is something of a monolith consisting
      of about 1800 lines of code. I find it difficult to get a handle on such
      extended functions and would like to factor out a series of static
      functions. My preference would be to have all function communication
      done with parameters; that can look a bit unwieldy; I think it shows the
      complication inherent in the underlying design. The cost of this is a
      small amount of communication code, my time in producing it, and the
      cost of solving any bugs I let out the door. The first extra benefit is
      that it allows next commands in a debugger to run a chunk of code and
      step where a closer focus is needed. It also makes any desired change
      much easier to implement.

      I have done this in the past for my own purposes; the work got scrapped
      when I absorbed patches. I want to avoid hitting Bram with a change
      which requires an extended dialog to establish its value.
      So, I'm starting the dialog before!
      --
      Walter Briscoe
    • Bram Moolenaar
      ... This is always tricky, various dependencies exist. It s mostly a lot easier to keep everything, and add the thing that you want to test near the end of
      Message 2 of 3 , Apr 2, 2003
      • 0 Attachment
        Walter Briscoe wrote:

        > In a recent thread, it would have been useful to replace Vim's main.c
        > with the following code.
        > /* Dummy Vim to exercise mch_FullName() */
        >
        > typedef unsigned char char_u;
        > # define __ARGS(x) x
        > int mch_FullName __ARGS((char_u *fname, char_u *buf, int len, int force));
        >
        > #include <stdio.h>
        >
        > int main(int argc, char **argv) {
        > char_u buf[256];
        >
        > printf("argc = %d, argv[1] = \"%s\"\n", argc, argv[1]);
        > (void)mch_FullName(argv[1], buf, sizeof buf, 1);
        > printf("buf = \"%s\"\n", buf);
        >
        > return 0;
        > }
        >
        > (What I actually did was construct a one module program with the
        > relevant pieces of Vim; doing this is a tedious process.)

        This is always tricky, various dependencies exist. It's mostly a lot
        easier to keep everything, and add the thing that you want to test near
        the end of main(). That a lot of things won't ever be used is
        irrelevant.

        > Also main() is something of a monolith consisting
        > of about 1800 lines of code. I find it difficult to get a handle on such
        > extended functions and would like to factor out a series of static
        > functions. My preference would be to have all function communication
        > done with parameters; that can look a bit unwieldy; I think it shows the
        > complication inherent in the underlying design. The cost of this is a
        > small amount of communication code, my time in producing it, and the
        > cost of solving any bugs I let out the door. The first extra benefit is
        > that it allows next commands in a debugger to run a chunk of code and
        > step where a closer focus is needed. It also makes any desired change
        > much easier to implement.

        Yes, main() has grown into a very long function, it's not nice. Some
        parts could be split off to separate functions.

        > I have done this in the past for my own purposes; the work got scrapped
        > when I absorbed patches. I want to avoid hitting Bram with a change
        > which requires an extended dialog to establish its value.
        > So, I'm starting the dialog before!

        If you really think this is worth working on, explain me what to change,
        rather than sending a diff. My code is always a few steps ahead and the
        code in main() does change, thus I would have to check every diff you
        send carefully. Making the changes myself is easier and avoids subtle
        mistakes.

        Don't overestimate the advantages of splitting up main(). The resulting
        code won't be simpler, only the overview would be better.

        --
        FATHER: Who are you?
        PRINCE: I'm ... your son ...
        FATHER: Not you.
        LAUNCELOT: I'm ... er ... Sir Launcelot, sir.
        "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 ... [snip] ... We agree in
        Message 3 of 3 , Apr 2, 2003
        • 0 Attachment
          In message <200304022134.h32LYb414977@...> of Wed, 2 Apr 2003
          23:34:37 in , Bram Moolenaar <Bram@...> writes
          >
          >Walter Briscoe wrote:
          >
          >> In a recent thread, it would have been useful to replace Vim's main.c
          >> with the following code.
          [snip]
          >
          >This is always tricky, various dependencies exist. It's mostly a lot
          >easier to keep everything, and add the thing that you want to test near
          >the end of main(). That a lot of things won't ever be used is
          >irrelevant.
          >
          >> Also main() is something of a monolith consisting
          >> of about 1800 lines of code. I find it difficult to get a handle on such
          >> extended functions and would like to factor out a series of static
          >> functions. My preference would be to have all function communication
          >> done with parameters; that can look a bit unwieldy; I think it shows the
          >> complication inherent in the underlying design. The cost of this is a
          >> small amount of communication code, my time in producing it, and the
          >> cost of solving any bugs I let out the door. The first extra benefit is
          >> that it allows next commands in a debugger to run a chunk of code and
          >> step where a closer focus is needed. It also makes any desired change
          >> much easier to implement.
          >
          >Yes, main() has grown into a very long function, it's not nice. Some
          >parts could be split off to separate functions.
          We agree in principle.

          >
          >> I have done this in the past for my own purposes; the work got scrapped
          >> when I absorbed patches. I want to avoid hitting Bram with a change
          >> which requires an extended dialog to establish its value.
          >> So, I'm starting the dialog before!
          >
          >If you really think this is worth working on, explain me what to change,
          >rather than sending a diff. My code is always a few steps ahead and the
          >code in main() does change, thus I would have to check every diff you
          >send carefully. Making the changes myself is easier and avoids subtle
          >mistakes.
          I will continue this in private email. The process is likely to be slow;
          I will make small changes and present them as both text and diffs. Let
          us see what we can cook together!

          >
          >Don't overestimate the advantages of splitting up main(). The resulting
          >code won't be simpler, only the overview would be better.
          I think what you say is similar to my words: "... all function
          communication done with parameters; that can look a bit unwieldy; I
          think it shows the complication inherent in the underlying design.".
          --
          Walter Briscoe
        Your message has been successfully submitted and would be delivered to recipients shortly.