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

Re: Patch 7.1.306

Expand Messages
  • Tony Mechelynck
    ... After applying patches 7.1.306 to 7.1.308 (of which I haven t yet received the latter two by email) if_python.c: In function ‘VimToPython’:
    Message 1 of 5 , Jun 4, 2008
    • 0 Attachment
      On 04/06/08 10:59, Bram Moolenaar wrote:
      >
      > Patch 7.1.306
      > Problem: Some Unicode characters are handled like word characters while
      > they are symbols.
      > Solution: Adjust the table for Unicode classification.
      > Files: src/mbyte.c

      After applying patches 7.1.306 to 7.1.308 (of which I haven't yet
      received the latter two by email)

      if_python.c: In function ‘VimToPython’:
      if_python.c:1157: warning: format ‘%f’ expects type ‘double’, but
      argument 3 has type ‘long int’

      also, one of 37 hunks of 7.1.307 failed to patch in the "floating point"
      version but on eyeball inspection it was already included, though with
      an additional comment in the middle (hunk #10 at 1130, bracketed between
      #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point
      feature could now be made a part of the "standard" sources? Of course,
      if anyone gets cold feet, it can still be disabled at compile-time by
      commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or
      similar)


      Best regards,
      Tony.
      --
      ... so long as the people do not care to exercise their freedom, those
      who wish to tyrranize will do so; for tyrants are active and ardent,
      and will devote themselves in the name of any number of gods, religious
      and otherwise, to put shackles upon sleeping men.
      -- Voltarine de Cleyre

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Bram Moolenaar
      ... Are you sure you patched OK? I see: sprintf(buf, %f , our_tv- vval.v_float); That is clearly a double argument. ... The FEAT_FLOAT parts in if_python
      Message 2 of 5 , Jun 4, 2008
      • 0 Attachment
        Tony Mechelynck wrote:

        > On 04/06/08 10:59, Bram Moolenaar wrote:
        > >
        > > Patch 7.1.306
        > > Problem: Some Unicode characters are handled like word characters while
        > > they are symbols.
        > > Solution: Adjust the table for Unicode classification.
        > > Files: src/mbyte.c
        >
        > After applying patches 7.1.306 to 7.1.308 (of which I haven't yet
        > received the latter two by email)
        >
        > if_python.c: In function 'VimToPython':
        > if_python.c:1157: warning: format '%f' expects type 'double', but
        > argument 3 has type 'long int'

        Are you sure you patched OK? I see:

        sprintf(buf, "%f", our_tv->vval.v_float);

        That is clearly a double argument.

        > also, one of 37 hunks of 7.1.307 failed to patch in the "floating point"
        > version but on eyeball inspection it was already included, though with
        > an additional comment in the middle (hunk #10 at 1130, bracketed between
        > #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point
        > feature could now be made a part of the "standard" sources? Of course,
        > if anyone gets cold feet, it can still be disabled at compile-time by
        > commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or
        > similar)

        The FEAT_FLOAT parts in if_python shouldn't hurt, since FEAT_FLOAT isn't
        yet defined anywhere. Unless you are using the experimental floating
        point patch, but then it should work (if you avoid patching the same
        thing twice).

        I still have a few fixes in the pipeline for the floating point patch.

        --
        Imagine a world without hypothetical situations.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Tony Mechelynck
        ... sprintf(buf, %f , (long)our_tv- vval.v_float); That s part of that hulk which didn t apply, see below. I ll remove the typecast by hand. Here s the exact
        Message 3 of 5 , Jun 4, 2008
        • 0 Attachment
          On 04/06/08 17:24, Bram Moolenaar wrote:
          > Tony Mechelynck wrote:
          >
          >> On 04/06/08 10:59, Bram Moolenaar wrote:
          >>> Patch 7.1.306
          >>> Problem: Some Unicode characters are handled like word characters while
          >>> they are symbols.
          >>> Solution: Adjust the table for Unicode classification.
          >>> Files: src/mbyte.c
          >> After applying patches 7.1.306 to 7.1.308 (of which I haven't yet
          >> received the latter two by email)
          >>
          >> if_python.c: In function ‘VimToPython’:
          >> if_python.c:1157: warning: format ‘%f’ expects type ‘double’, but
          >> argument 3 has type ‘long int’
          >
          > Are you sure you patched OK? I see:
          >
          > sprintf(buf, "%f", our_tv->vval.v_float);

          sprintf(buf, "%f", (long)our_tv->vval.v_float);

          That's part of that hulk which didn't apply, see below. I'll remove the
          typecast by hand.

          Here's the exact text I have there, from #ifdef to #endif plus three
          lines of context either side, before removing that typecast:

          result = Py_BuildValue("s", buf);
          PyDict_SetItemString(lookupDict, ptrBuf, result);
          }
          #ifdef FEAT_FLOAT
          else if (our_tv->v_type == VAR_FLOAT)
          {
          char buf[NUMBUFLEN];

          /* For backwards compatibility numbers are stored as strings. */
          sprintf(buf, "%f", (long)our_tv->vval.v_float);
          result = Py_BuildValue("s", buf);
          PyDict_SetItemString(lookupDict, ptrBuf, result);
          }
          #endif
          else if (our_tv->v_type == VAR_LIST)
          {
          list_T *list = our_tv->vval.v_list;


          >
          > That is clearly a double argument.
          >
          >> also, one of 37 hunks of 7.1.307 failed to patch in the "floating point"
          >> version but on eyeball inspection it was already included, though with
          >> an additional comment in the middle (hunk #10 at 1130, bracketed between
          >> #ifdef FEAT_FLOAT and #endif). Bram, don't you think that floating point
          >> feature could now be made a part of the "standard" sources? Of course,
          >> if anyone gets cold feet, it can still be disabled at compile-time by
          >> commenting away line 384 of feature.h (to /* #define FEAT_FLOAT */ or
          >> similar)
          >
          > The FEAT_FLOAT parts in if_python shouldn't hurt, since FEAT_FLOAT isn't
          > yet defined anywhere. Unless you are using the experimental floating
          > point patch, but then it should work (if you avoid patching the same
          > thing twice).

          I am, and the patch program didn't reapply that hulk. I didn't check the
          other hulks (the ones which succeeded, sometimes with fuzz); I hope
          they're OK -- normally your diffs should have enough context for that. I
          still have (in a parallel directory structure) the version without the
          float patch but that's not the one I "install".

          >
          > I still have a few fixes in the pipeline for the floating point patch.
          >

          Aha! I can hardly wait.


          Best regards,
          Tony.
          --
          BLACK KNIGHT: None shall pass.
          ARTHUR: I have no quarrel with you, brave Sir knight, but I must cross
          this bridge.
          BLACK KNIGHT: Then you shall die.
          "Monty Python and the Holy Grail" PYTHON (MONTY)
          PICTURES LTD

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Bill McCarthy
          ... I also found 307-311 on the ftp site. After deleting from the patches those portions applicable to runtime files (such as optwin.vim), they built fine. I
          Message 4 of 5 , Jun 4, 2008
          • 0 Attachment
            On Wed 4-Jun-08 3:59am -0600, Bram Moolenaar wrote:

            > Patch 7.1.306

            I also found 307-311 on the ftp site. After deleting from
            the patches those portions applicable to runtime files (such
            as optwin.vim), they built fine.

            I then turned to floating point (which I last updated at
            305). Only if_python.c and version.c needed to be updated
            (or so I thought).

            After the patch to if_python.c failed completely, version.c
            patched fine.

            On further inspection I see that the standard if_python.c is
            already patched for floating point. So I just copied it and
            my floating point versions of vim and gvim are at 311.

            Since eval.c didn't change, I didn't need to apply John
            Beckett's fp patch - will that be included?

            I didn't have any of Tony's problems. I agree that it would
            be great to have fp in the main distribution.

            --
            Best regards,
            Bill


            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          Your message has been successfully submitted and would be delivered to recipients shortly.