Re: [Python-Dev] Developing/patching ctypes
Neal Norwitz wrote:
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
Would it be a solution to move the 'official' ctypes development into
Python SVN external/ctypes, or would this be considered abuse? Another
location in SVN could be used as well, if external is though to contain
only vendor drops...
Thomas,
I'd be fine with the official ctypes repo being Python SVN.
The attached patch fixes all the ctypes tests so they pass on amd64.
It also fixes several warnings. I'm not sure what else to do with the
patch. Let me know how you want to handle these in the future.
I'm not sure the patch is 100% correct. You will need to decide what
can be 64 bits and what can't. I believe
sq_{item,slice,ass_item,ass_slice} all need to use Py_ssize_t. The
types in ctypes.h may not require all the changes I made. I don't
know how you want to support older version, so I unconditionally
changed the types to Py_ssize_t.
n
Thanks, Neal, I'll look into that this night.
In the future I hope to have access to a amd64-linux system, and I'll try
to keep this stuff up-to-date myself.
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes (was: Re: integrating ctypes into python)
On Mon, 2006-03-13 at 21:38 -0800, Neal Norwitz wrote: On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote: Would it be a solution to move the 'official' ctypes development into Python SVN external/ctypes, or would this be considered abuse? Another location in SVN could be used as well, if external is though to contain only vendor drops... Thomas, I'd be fine with the official ctypes repo being Python SVN. The sandbox seems a fine place for this. It's what I'm currently doing with the email package. Two of the three versions are actually external'd from Python branches and contain extra stuff to enable standalone releases. The third is being developed first in the sandbox, but will soon be merged back into the trunk and then managed in the same way as the other two. Except for the usual headaches of managing three versions of a package, it's working out quite well. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes (was: Re: integrating ctypes into python)
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
Would it be a solution to move the 'official' ctypes development into
Python SVN external/ctypes, or would this be considered abuse? Another
location in SVN could be used as well, if external is though to contain
only vendor drops...
Thomas,
I'd be fine with the official ctypes repo being Python SVN.
The attached patch fixes all the ctypes tests so they pass on amd64.
It also fixes several warnings. I'm not sure what else to do with the
patch. Let me know how you want to handle these in the future.
I'm not sure the patch is 100% correct. You will need to decide what
can be 64 bits and what can't. I believe
sq_{item,slice,ass_item,ass_slice} all need to use Py_ssize_t. The
types in ctypes.h may not require all the changes I made. I don't
know how you want to support older version, so I unconditionally
changed the types to Py_ssize_t.
n
Index: Modules/_ctypes/callproc.c
===
--- Modules/_ctypes/callproc.c (revision 43021)
+++ Modules/_ctypes/callproc.c (working copy)
@@ -721,8 +721,9 @@
O_get), we have to call Py_DECREF because O_get has already
called Py_INCREF.
*/
- if (dict-getfunc == getentry(O)-getfunc)
+ if (dict-getfunc == getentry(O)-getfunc) {
Py_DECREF(retval);
+ }
} else
retval = CData_FromBaseObj(restype, NULL, 0, result);
Index: Modules/_ctypes/_ctypes.c
===
--- Modules/_ctypes/_ctypes.c (revision 43021)
+++ Modules/_ctypes/_ctypes.c (working copy)
@@ -335,7 +335,7 @@
};
static PyObject *
-CDataType_repeat(PyObject *self, int length)
+CDataType_repeat(PyObject *self, Py_ssize_t length)
{
return CreateArrayType(self, length);
}
@@ -695,7 +695,7 @@
CharArray_set_raw(CDataObject *self, PyObject *value)
{
char *ptr;
- int size;
+ Py_ssize_t size;
if (PyBuffer_Check(value)) {
size = value-ob_type-tp_as_buffer-bf_getreadbuffer(value, 0, (void *)ptr);
if (size 0)
@@ -1789,13 +1789,11 @@
{
char string[256]; /* XXX is that enough? */
char *cp = string;
- int len;
*cp++ = index + '0';
while (target-b_base) {
*cp++ = target-b_index + '0';
target = target-b_base;
}
- len = cp - string;
return PyString_FromStringAndSize(string, cp-string);
}
/* Keep a reference to 'keep' in the 'target', at index 'index' */
@@ -1806,7 +1804,7 @@
* key int the root object's _objects dict.
*/
static int
-KeepRef(CDataObject *target, int index, PyObject *keep)
+KeepRef(CDataObject *target, Py_ssize_t index, PyObject *keep)
{
int result;
CDataObject *ob;
@@ -1875,7 +1873,7 @@
{ NULL },
};
-static int CData_GetBuffer(CDataObject *self, int seg, void **pptr)
+static Py_ssize_t CData_GetBuffer(CDataObject *self, Py_ssize_t seg, void **pptr)
{
if (seg != 0) {
/* Hm. Must this set an exception? */
@@ -1885,7 +1883,7 @@
return self-b_size;
}
-static int CData_GetSegcount(CDataObject *self, int *lenp)
+static Py_ssize_t CData_GetSegcount(CDataObject *self, Py_ssize_t *lenp)
{
if (lenp)
*lenp = 1;
@@ -1893,10 +1891,10 @@
}
static PyBufferProcs CData_as_buffer = {
- (getreadbufferproc)CData_GetBuffer,
- (getwritebufferproc)CData_GetBuffer,
- (getsegcountproc)CData_GetSegcount,
- (getcharbufferproc)NULL,
+ (readbufferproc)CData_GetBuffer,
+ (writebufferproc)CData_GetBuffer,
+ (segcountproc)CData_GetSegcount,
+ (charbufferproc)NULL,
};
/*
@@ -1985,7 +1983,7 @@
}
PyObject *
-CData_FromBaseObj(PyObject *type, PyObject *base, int index, char *adr)
+CData_FromBaseObj(PyObject *type, PyObject *base, Py_ssize_t index, char *adr)
{
CDataObject *cmem;
StgDictObject *dict;
@@ -2064,7 +2062,7 @@
PyObject *
CData_get(PyObject *type, GETFUNC getfunc, PyObject *src,
- int index, int size, char *adr)
+ Py_ssize_t index, Py_ssize_t size, char *adr)
{
StgDictObject *dict;
if (getfunc)
@@ -2081,7 +2079,7 @@
*/
static PyObject *
_CData_set(CDataObject *dst, PyObject *type, SETFUNC setfunc, PyObject *value,
- int size, char *ptr)
+ Py_ssize_t size, char *ptr)
{
CDataObject *src;
@@ -2177,7 +2175,7 @@
*/
int
CData_set(PyObject *dst, PyObject *type, SETFUNC setfunc, PyObject *value,
- int index, int size, char *ptr)
+ Py_ssize_t index, Py_ssize_t size, char *ptr)
{
CDataObject *mem = (CDataObject *)dst;
PyObject *result;
@@ -3318,7 +3316,7 @@
if (kwds) {
PyObject *key, *value;
- int pos = 0;
+ Py_ssize_t pos = 0;
while(PyDict_Next(kwds, pos, key, value)) {
if (-1 == PyObject_SetAttr(self, key, value))
return -1;
@@ -3471,12 +3469,12 @@
}
static PyObject *
-Array_slice(CDataObject *self, int ilow, int ihigh)
+Array_slice(CDataObject *self, Py_ssize_t ilow, Py_ssize_t ihigh)
{
StgDictObject *stgdict, *itemdict;
PyObject *proto;
PyListObject *np;
- int i, len;
+ Py_ssize_t i, len;
if (ilow 0)
ilow = 0;
@@ -3587,13 +3585,13 @@
}
static PySequenceMethods Array_as_sequence =
Re: [Python-Dev] Developing/patching ctypes
Thomas Wouters wrote: On 3/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? They are now in http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/280/step-test/0 I suspect that some of those failures probably aren't ctypes failures, but re-running-ctype-tests-in-the-same-process failures (like the very first one) -- I get more errors when running -R:: than I do when running the test verbosely directly. I can reproduce that now - thanks for finding the problem. IMO, some of the ctypes tests are kind-of broken, since they keep state although they should not. Maybe re-running the test could be done in a freshly spawned Python? I'll try to fix the ctypes-tests starting on Monday, so I assume that would not be necessary. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Trent Mick wrote: I do this for ActivePython builds... by setting up the Platform SDK compiler I want in the environment and then using: devenv.com .../pcbuild.sln /useenv /build Release Right - that might be the easiest thing to do. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
On 3/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow?They are now inhttp://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/280/step-test/0 I suspect that some of those failures probably aren't ctypes failures, but re-running-ctype-tests-in-the-same-process failures (like the very first one) -- I get more errors when running -R:: than I do when running the test verbosely directly. Maybe re-running the test could be done in a freshly spawned Python? -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Wouters wrote: I suspect that some of those failures probably aren't ctypes failures, but re-running-ctype-tests-in-the-same-process failures (like the very first one) -- I get more errors when running -R:: than I do when running the test verbosely directly. Maybe re-running the test could be done in a freshly spawned Python? Feel free to implement that; buildbot will immediately pick it up. Getting the command line right might be a challenge though (plus finding the right Python interpreter, etc.) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Heller wrote: Would it be a solution to move the 'official' ctypes development into Python SVN external/ctypes, or would this be considered abuse? Another location in SVN could be used as well, if external is though to contain only vendor drops... external indeed is meant only for vendor drops. I personally don't mind having the upstream ctypes repository also in svn.python.org; this would be similar to distutils, setuptools, and (I think) the email package. Currently, some of them live in sandbox/trunk, but I wouldn't mind it living in /ctypes/trunk, either. Be aware that the set of committers to svn.python.org/projects is currently restricted to Python committers. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes (was: Re: integrating ctypes into python)
On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: Would it be a solution to move the 'official' ctypes development intoPython SVN external/ctypes, or would this be considered abuse?Anotherlocation in SVN could be used as well, if external is though to contain only vendor drops...If all the developers are also python-developers (or at least have svn access), and the source is supposed to be identical, SVN obviously beats SVN :) I can work equally well with the main repository in CVS, though, and I've had quite a bit of practice in merging changes. -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Wouters wrote: On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: Would it be a solution to move the 'official' ctypes development into Python SVN external/ctypes, or would this be considered abuse? Another location in SVN could be used as well, if external is though to contain only vendor drops... If all the developers are also python-developers (or at least have svn access), and the source is supposed to be identical, SVN obviously beats SVN I didn't know that SVN is *that great* :) ! :) I can work equally well with the main repository in CVS, though, and I've had quite a bit of practice in merging changes. Cool. Martin v. Löwis wrote: external indeed is meant only for vendor drops. I personally don't mind having the upstream ctypes repository also in svn.python.org; this would be similar to distutils, setuptools, and (I think) the email package. Currently, some of them live in sandbox/trunk, but I wouldn't mind it living in /ctypes/trunk, either. Be aware that the set of committers to svn.python.org/projects is currently restricted to Python committers. I think the currently active ctypes developers are also Python committers, additionally I've asked on the ctypes-users list for objections. I'll think about this stuff over the weekend, currently I tend to moving ctypes to Python SVN. Whether it will be /ctypes/trunk or sandbox/ctypes I don't really care. In the meantime, please: If anyone is going to make fixes to the ctypes source code (apart from Tim's regular whitespace cleanup), please do this in the ctypes CVS repository on sourceforge, in the trunk. If anyone (of the Python developers) wants to do this and doesn't currently have commit access, please mail me your SF userid privately. Note that both perky and Thomas Wouters have promised to do Py_ssize_t fixes - please coordinate that to avoid double work. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
[Thomas Heller] ... In the meantime, please: If anyone is going to make fixes to the ctypes source code (apart from Tim's regular whitespace cleanup), please do this in the ctypes CVS repository on sourceforge, in the trunk. FYI, my regular whitespace cleanup consists of running reindent.py from the root of a Python checkout (cd python; reindent.py -r .). There's nothing specific to the Python project about that little procedure, and, e.g., I regularly did the same for Zope Corp's ZODB project. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Tim Peters wrote: [Thomas Heller] ... In the meantime, please: If anyone is going to make fixes to the ctypes source code (apart from Tim's regular whitespace cleanup), please do this in the ctypes CVS repository on sourceforge, in the trunk. FYI, my regular whitespace cleanup consists of running reindent.py from the root of a Python checkout (cd python; reindent.py -r .). There's nothing specific to the Python project about that little procedure, and, e.g., I regularly did the same for Zope Corp's ZODB project. I've nothing against that, and I should myself get used to do the same in my own repositories from time to time. BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? Running the tests in verbose mode by default is probably not a good idea, because it may make tests fail, AFAIK. If not, I have no other choice (since I don't have a 64-bit machine myself) than to test this in the sourceforge compilefarm amd64 machine, which is a pain since they don't allow outbound network from there. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? Running the tests in verbose mode by default is probably not a good idea, because it may make tests fail, AFAIK. I want to modify regrtest so the traceback info is stored in a file, so you can still retrieve the data after a test run. I haven't started making this mod yet. If not, I have no other choice (since I don't have a 64-bit machine myself) than to test this in the sourceforge compilefarm amd64 machine, which is a pain since they don't allow outbound network from there. I ran the test manually last night, there were 12 errors IIRC. It was stuff like strings not being equal. I can't send you the verbose run right now. I'll try to do it when I get a chance, but that won't be before Sunday. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to use the Windows x86 FFI code, which does not compile with the AMD64 compiler. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Martin v. Löwis wrote: Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to use the Windows x86 FFI code, which does not compile with the AMD64 compiler. On such a machine probably other source files should be used. I have no such machine - is it possible to build the 64-bit version on a 32-bit machine (with the platform SDK)? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Neal Norwitz wrote: I want to modify regrtest so the traceback info is stored in a file, so you can still retrieve the data after a test run. I haven't started making this mod yet. I took a different approach now, adding an option to regrtest to re-run failed tests in verbose mode; this is what the buildbot now uses. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Neal Norwitz wrote: On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? Running the tests in verbose mode by default is probably not a good idea, because it may make tests fail, AFAIK. I want to modify regrtest so the traceback info is stored in a file, so you can still retrieve the data after a test run. I haven't started making this mod yet. There are also sporadic test failures on the OSX machine: http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/345/step-test/0 I think the test is broken - but what I find interesting is that in this case the actual failure is printed: test_set test_ctypes test test_ctypes failed -- Traceback (most recent call last): File /Users/buildslave/bb/trunk.4/build/Lib/ctypes/test/test_leaks.py, line 68, in test_cycles_refcount self.fail(leaking refcounts) AssertionError: leaking refcounts test_long_future Why is that? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Heller wrote: FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to use the Windows x86 FFI code, which does not compile with the AMD64 compiler. On such a machine probably other source files should be used. I have no such machine - is it possible to build the 64-bit version on a 32-bit machine (with the platform SDK)? Indeed, this is possible. I don't know of anybody who does so, so far, but in principle, the procedure is described in PCbuild/readme.txt. In essence, you install the platform SDK and vsextcomp, and then build the ReleaseAMD64 solution setting. OTOH, the distutils included with Python 2.5 also honor SDK environments (again), so if you install the platform SDK, open an IA64 or AMD64 build environment, and run upstream's setup.py, it /should/ just use the compiler, header files, etc in the path. If that would help, I could provide you with a Python 2.5 MSI file (for x86), to run distutils, and get the 2.5 headers. OTTH, a lot of things don't work on Win64, so people could probably readily accept the lack of ctypes. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Heller wrote: test_set test_ctypes test test_ctypes failed -- Traceback (most recent call last): File /Users/buildslave/bb/trunk.4/build/Lib/ctypes/test/test_leaks.py, line 68, in test_cycles_refcount self.fail(leaking refcounts) AssertionError: leaking refcounts test_long_future Why is that? Because it is just a single exception. For that, a traceback is printed. Not so for multiple failures. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? They are now in http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/280/step-test/0 Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
On such a machine probably other source files should be used. I have no such machine - is it possible to build the 64-bit version on a 32-bit machine (with the platform SDK)? Indeed, this is possible. I don't know of anybody who does so, so far, but in principle, the procedure is described in PCbuild/readme.txt. In essence, you install the platform SDK and vsextcomp, and then build the ReleaseAMD64 solution setting. I do this for ActivePython builds... by setting up the Platform SDK compiler I want in the environment and then using: devenv.com .../pcbuild.sln /useenv /build Release Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Developing/patching ctypes (was: Re: integrating ctypes into python)
[CC to python-dev again] Hye-Shik Chang wrote: On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: Hye-Shik Chang wrote: On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote: I've now committed ctypes 0.9.9.4 into SVN. It seems to build, at least on the buildbots that are online. Good work! It's all green on my machines (FreeBSD amd64/sparc64). But gcc outputs some warnings: 1) libffi/include/ffi.h.in: void (*fn)() - void (*void)(void) This is not the only file that would have to be changed. I wonder why they don't change it in gcc itself. This *is* the only change to calm gcc warnings down except Py_ssize_t stuff. :-) 2) many of Py_ssize_t / int prototype mismatches. (eg. sq_repeat) Could we make ctypes Py_ssize_t clean? 3) ctypes doesn't support Py_ssize_t nor ssize_t yet. Because major portion of our pythonapi uses it now, it would be better to have it. This should be done in ctypes CVS, and the result imported into python SVN after that. At least ctypes (the Python module) has an c_size_t type now ;-). I'll do it in this weekend. I saw that branch_1_0 is merged into HEAD. Which branch are you using for Python integration at now? I did 'cvs export -r release_0_9_9_4' from the SF repository and then imported this into python SVN external/ctypes-0.9.9.4. The 'release_0_9_9_4' tag is on the 'branch_1_0' branch. I moved on a little bit on that branch, later merged everything into SF CVS HEAD, and continued to work there. We'll have to coordinate this. Different people working in different repositories will become a maintaince nightmare, so there should be an official 'master' repository for ctypes. Question for python-dev: Would it be a solution to move the 'official' ctypes development into Python SVN external/ctypes, or would this be considered abuse? Another location in SVN could be used as well, if external is though to contain only vendor drops... Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
