Sun, 09 Oct 2016 12:58:22 +0200 store: py26 compat, don't use a dict comprehension
Martijn Pieters <mjpieters@fb.com> [Sun, 09 Oct 2016 12:58:22 +0200] rev 30108
store: py26 compat, don't use a dict comprehension
Sat, 08 Oct 2016 16:51:18 +0200 dirs: document performance reasons for bypassing Python C API
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Oct 2016 16:51:18 +0200] rev 30107
dirs: document performance reasons for bypassing Python C API So someone isn't tempted to change it.
Sat, 08 Oct 2016 16:20:21 +0200 dirs: port PyInt code to work on Python 3
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Oct 2016 16:20:21 +0200] rev 30106
dirs: port PyInt code to work on Python 3 PyIntObject no longer exists in Python 3. Instead, there is PyLongObject. Furthermore, PyInt_AS_LONG is a macro referencing a struct member. PyInt_AS_LONG doesn't exist in Python 3 and PyLong_AS_LONG is a #define for PyLong_AsLong, which is a function. So assigning to the return value of PyLong_AS_LONG doesn't work. This patch introduces a macro for obtaining the value of an integer-like type that works on Python 2 and Python 3. On Python 3, we access the struct field of the underlying PyLongObjet directly, without overflow checking. This is essentially the same as what Python 2 was doing except using a PyLong instead of a PyInt.
Sat, 08 Oct 2016 14:31:59 +0200 dirs: convert PyString to PyBytes
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Oct 2016 14:31:59 +0200] rev 30105
dirs: convert PyString to PyBytes PyStringObject was renamed to PyBytes in Python 3 along with the corresponding PyString* functions and macros. PyString* doesn't exist in Python 3. But PyBytes* is an alias to PyString in Python 2. So rewrite PyString* to PyBytes* for Python 2/3 dual compatibility.
Sat, 08 Oct 2016 16:02:51 +0200 dirs: inline string macros
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Oct 2016 16:02:51 +0200] rev 30104
dirs: inline string macros The old code happened to work because of how the macro was defined. This no longer works in Python 3. Furthermore, assigning to a macro just feels weird. So just inline the macro.
Sat, 08 Oct 2016 22:44:02 +0200 parsers: use PyVarObject_HEAD_INIT
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Oct 2016 22:44:02 +0200] rev 30103
parsers: use PyVarObject_HEAD_INIT The macro changed slightly in Python 3, introducing curly brackets that somehow confuse Clang into issuing a ton of compiler warnings. Using PyVarObject_HEAD_INIT makes these go away. It's worth noting that the code is identical: the 2nd argument to PyVarObject_HEAD_INIT is assigned to the ob_size field and is inserted immediately after "PyObject_HEAD_INIT(type)" is generated. Compilers are weird.
Sat, 08 Oct 2016 22:21:22 +0200 pathencode: use Py_SIZE directly
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Oct 2016 22:21:22 +0200] rev 30102
pathencode: use Py_SIZE directly On Python 2, PyBytes_GET_SIZE is the same as PyString_GET_SIZE which is the same as Py_SIZE which resolves to a struct member. On Python 3, PyBytes_GET_SIZE is "(assert(PyBytes_Check(op)),Py_SIZE(op))". The compiler barfs when assigning to this version. This patch simply changes PyBytes_GET_SIZE to Py_SIZE. On Python 2, there is no effective change in behavior. On Python 3, we drop the PyBytes_Check(). However, in all cases we have explicitly created a PyBytesObject in the same function, so the PyBytes_Check() is guaranteed to be true. Despite this, code changes over time, so I've added added assert() in all callers so we can catch this in debug builds. With this patch, all mercurial.* C extensions now compile on Python 3 on my OS X machine. There are several compiler warnings and I'm sure there are incompatibilities with Python 3, including possibly segfaults. But it is a milestone.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip