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

Thomas Wouters wrote:

On 3/10/06, 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...

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

[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.

On 3/10/06, 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/s...

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

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

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

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

...

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 TrentM@ActiveState.com

On 3/10/06, "Martin v. Löwis" 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/s...

...

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/ste...

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 Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Thomas Wouters wrote:

On 3/10/06, "Martin v. Löwis" 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/s...

...

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/ste...

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

Neal Norwitz wrote:

On 3/9/06, 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...

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