Sun, 09 Oct 2016 05:51:04 -0700 templater: provide arithmetic operations on integers
Simon Farnsworth <simonfar@fb.com> [Sun, 09 Oct 2016 05:51:04 -0700] rev 30115
templater: provide arithmetic operations on integers The termwidth template keyword is of limited use without some way to ensure that margins are respected. Provide a full set of arithmetic operators (four basic operations plus the mod function, defined to match Python's // for division), so that you can create termwidth based layouts that match the user's terminal size
Sun, 09 Oct 2016 15:54:42 +0200 eol: store and reuse pattern matchers instead of creating in tight loop
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Oct 2016 15:54:42 +0200] rev 30114
eol: store and reuse pattern matchers instead of creating in tight loop More "right" and more efficient.
Sun, 09 Oct 2016 15:42:42 +0200 eol: fix variable naming - call it _eolmatch instead of _eolfile
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Oct 2016 15:42:42 +0200] rev 30113
eol: fix variable naming - call it _eolmatch instead of _eolfile It is not the file but a match object based on it.
Sun, 09 Oct 2016 13:50:53 +0200 parsers: move PyInt aliasing out of util.h
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 09 Oct 2016 13:50:53 +0200] rev 30112
parsers: move PyInt aliasing out of util.h The PyInt aliasing is only used by parsers.c. Since we don't want to encourage the use of PyInt parsing, move the aliasing to parsers.c.
Sun, 09 Oct 2016 13:47:46 +0200 osutil: use PyLongObject on Python 3 for listdir_slot
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 09 Oct 2016 13:47:46 +0200] rev 30111
osutil: use PyLongObject on Python 3 for listdir_slot This code looks performance sensitive. So let's retain PyIntObject on Python 2 and use PyLongObject explicitly on Python 3.
Sun, 09 Oct 2016 13:41:18 +0200 osutil: use PyLongObject in recvfds
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 09 Oct 2016 13:41:18 +0200] rev 30110
osutil: use PyLongObject in recvfds PyIntObject doesn't exist in Python 3. While PyIntObject is preferred on Python 2 because it is a fixed capacity and faster, the difference between PyIntObject and PyLongObject for scenarios where performance isn't critical or the caller isn't performing type checking shouldn't be relevant. So change recvfds to return a list of longs instead of ints on Python 2.
Sun, 09 Oct 2016 12:37:10 +0200 py3: use encoding.environ instead of os.environ
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 09 Oct 2016 12:37:10 +0200] rev 30109
py3: use encoding.environ instead of os.environ This complains while running hg version on Python 3.5
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip