On Sun, Jul 26, 2009 at 02:55:58AM +0200, Hanno Schlichting wrote: > On Sat, Jul 25, 2009 at 8:01 PM, Shane Hathaway<sh...@hathawaymix.org> wrote: > > Hanno Schlichting wrote: > >> > >> I kind of suspect that we are seeing the results of > >> http://www.python.org/dev/peps/pep-0353 though. > > > > That is very likely. BTW, that PEP links to a handy tool that reveals most > > 64 bit portability issues in Python-oriented C code. > > Right, I've given that a shot and it reports plenty of problems for > Acquisition.c for example. In addition to the general compiler > warnings it spits out, which don't tell me much. > > >> From what I understand we need to change code in C extension modules > >> following the instructions in that PEP, to be able to run code > >> reliably on 64-bit platforms. To my knowledge nobody changed any C > >> code in Zope yet to do so. > > > > We fixed the C portability problems in Zope 3 a while back, but it seems we > > didn't fix the extensions that are specific to Zope 2. > > How thorough has that been?
I'm not familiar with the source code of the extension modules, and I haven't reviewed them for possible 64-bit issues. But we've been running a Zope 3 app in production on 64-bit Linux for almost two years now. No 64-bit-related problems bit us so far. There's a buildbot for Zope 3.4 packages that runs their tests on 32 and 64 bit platforms on Python 2.4 and 2.5: http://zope3.pov.lt/buildbot/ Currently ZODB tests are disabled on it because they used to have irritating spurious failures that seem to be related to the speed of the machine rather than its platform. I believe there's a similar buildbot for Zope 3.5 KGS out there somewhere. > I can see the Py_ssize_t in some of the c > files in zope.* packages, but looking for example at: > > http://svn.zope.org/zope.proxy/trunk/src/zope/proxy/_zope_proxy_proxy.c?rev=95468&view=markup > > I see a stuff like this: > > PyObject * > WrapperType_Lookup(PyTypeObject *type, PyObject *name) > { > int i, n; > > [...] > > n = PyTuple_GET_SIZE(mro) - 1; > > [...] > } > > where PyTuple_GET_SIZE is defined to return a Py_ssize_t and not an int. It shouldn't be a problem until you start seeing tuples with 2 billion items in them, no? > Either I misunderstand something here or I was just "lucky" to find > something like this as my first test. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital signature
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )