Maxim Philippov wrote:
[...]
> > If i'm correct then instead of Py_ssize_t len = 0, you should
> > replace that line with PyInt len;
> >
> > This will be defined correctly near the top of if_python.c and work
> > in both cases. In any case, my original patch should have been done
> > that way. Ugh.
[...]
> Hi Sean.
>
> Finally I get it =) Since vim may load libpython dynamically,
> PY_SSIZE_T_CLEAN doesn't do its macro magic, namely it doesn't change
> PyArg_ParseTuple symbol name to _PyArg_ParseTuple_SizeT (as You can
> see in /usr/include/python*/modsupport.h).
>
> Now patch is a bit more complicated, please look attached
> py_sizet_syms.patch
Do I understand it correctly that this goes on top of the patch that
changes the type of "len"?
How do I describe the problem this fixes in one or two sentences?
--
WOMAN: I didn't know we had a king. I thought we were an autonomous
collective.
DENNIS: You're fooling yourself. We're living in a dictatorship. A
self-perpetuating autocracy in which the working classes--
WOMAN: Oh there you go, bringing class into it again.
DENNIS: That's what it's all about if only people would--
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- [email protected] -- 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
