Mailman 3 November 2012 - pypy-issue

[issue833] missing functions in the os module
by teepark 13 May '14

13 May '14

New submission from teepark <travis.parker(a)gmail.com>: I ran into this when I needed os.fchmod, but there are quite a few names not present in pypy's os module (I'm on x86_64 linux, and I'm sure many of these aren't guaranteed to be there for any platform, but pypy on x86_64 linux should probably include them): - getlogin - confstr - getresgid - tcsetpgrp - statvfs - setresgid - initgroups - fstatvfs - getresuid - fchmod - setresuid - tcgetpgrp - confstr_names - setgroups - pathconf - fchown - openpty - ctermid - statvfs_result Please change the priority if "feature" isn't appropriate - it doesn't feel right but I don't know that cpython compatibility issues are being treated as bugs. ---------- messages: 2975 nosy: pypy-issue, teepark priority: feature status: unread title: missing functions in the os module ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue833> ________________________________________

6 13

[issue1259] module __file__ attribute shows wrong path
by David 09 May '14

09 May '14

New submission from David <david.schneider(a)uni-duesseldorf.de>: The __file__ attribute for some modules shows a path corresponding to the system where pypy was translated and not where it is running. This causes one of the module/math app-level tests that use this attribute to load the math_testcases.txt file to fail, if the test are run on a different machine as the one used for translation. Examples: >>>> import math; math.__file__ '/Users/pypy/buildslave/pypy-c-jit-macosx-x86-64/build/pypy/module/math' or >>>> import abc; abc.__file__ '/Users/pypy/buildslave/pypy-c-jit-macosx-x86-64/build/lib-python/2.7/abc.py' In other cases, like ctypes, the behavior is as expected, e.g.: >>>> import ctypes; ctypes.__file__ '/opt/pypy/lib-python/2.7/ctypes/__init__.pyc' ---------- messages: 4736 nosy: bivab, pypy-issue priority: bug status: unread title: module __file__ attribute shows wrong path ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1259> ________________________________________

6 15

[issue644] Add option parser to package.py
by Dan 09 May '14

09 May '14

New submission from Dan <dcolish(a)gmail.com>: I've been using package.py a lot more often now and I find an option parser interface to be nice for command line scripts. I've written one for package.py, but I believe it will require buildbot updates since buildbot is calling the old interface. ---------- effort: ??? files: package.diff messages: 2169 nosy: dcolish, pypy-issue priority: wish release: ??? status: in-progress title: Add option parser to package.py _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue644> _______________________________________________________

2 1

[issue1128] add the possibility to search on the release field on roundup
by Antonio Cuni 08 May '14

08 May '14

New submission from Antonio Cuni <anto.cuni(a)gmail.com>: there should be a way to display all the issues which belongs to a specific release ---------- assignedto: ronny messages: 4258 nosy: pypy-issue, ronny priority: feature status: unread title: add the possibility to search on the release field on roundup ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1128> ________________________________________

3 2

[issue662] get_config_vars has nothing for CC, while expected internally
by Martijn 08 May '14

08 May '14

New submission from Martijn <ss(a)kleptog.org>: Currently distutils.sysconfig.get_config_vars() has no value for CC. This means that when you try to build a C extension using distutils it breaks, because distutils internally uses get_config_vars() to determine the compiler (distutils/ccompiler.py). Attached is a patch that works for me, with this C extensions build normally (excluding cpyext problems). But this may be a layering violation, so I'll leave it to you guys to determine the correct fix. In any case it's an improvement which improves compatibility. ---------- effort: ??? files: distutils.patch messages: 2267 nosy: kleptog, pypy-issue priority: feature release: ??? status: unread title: get_config_vars has nothing for CC, while expected internally _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue662> _______________________________________________________

4 3

[issue955] move struct.Struct to interplevel
by Alex Gaynor 06 May '14

06 May '14

New submission from Alex Gaynor <alex.gaynor(a)gmail.com>: There are a few reasons and issues to be fixed: 1) format should be immutable on the Struct instance 2) format should be promoted so that unpack/pack loops are unrolled correctly 3) it should work nicer with buffers Discussion from IRC: [6:24 PM] <Alex_Gaynor> arigato: so struct.unpack is very fast because the JIT checks if the format str is constant and if it is unrolsl the loops [6:24 PM] <arigato> ah, bah [6:24 PM] <Alex_Gaynor> arigato: however if you have x = Struct("format str"); for i n xrange(100): x.unpack(i) or so, the string isn't constant [6:24 PM] <Alex_Gaynor> it'd be ok if Struct was a global or something [6:24 PM] <Alex_Gaynor> I would if Struct instances should just promote their format and be done with it [6:24 PM] <arigato> and even not, because x.format is not a constant attribute [6:25 PM] <Alex_Gaynor> is it constant on CPython? [6:25 PM] <arigato> I suppose, but right now it's written at app-level [6:25 PM] <arigato> in pypy [6:25 PM] ⇐ lucian (~lucian@cpc1-newc15-2-0- cust84.gate.cable.virginmedia.com) quit: Ping timeout: 240 seconds [6:25 PM] <Alex_Gaynor> arigato: yes, I guess it might make sense to move it to interplevel so we can make it const and do the promotion [6:25 PM] <Alex_Gaynor> I think promote makes sense here [6:25 PM] <arigato> yes and no, as usual [6:26 PM] <Alex_Gaynor> indeed [6:26 PM] <arigato> e.g. what if someone does x = Struct("i" * n) [6:27 PM] <arigato> well I suppose that he's punished and it's his fault, or something [6:27 PM] <Alex_Gaynor> indeed, as always the mess of heuristics :/ [6:27 PM] <arigato> yes [6:27 PM] <exarkun> I did that this afternoon. [6:27 PM] <arigato> ah no, it's potentially a bad idea to promote a string, anyway [6:27 PM] ⇐ JaRoel|4d (~jaroel|4d@2001:980:7133:1:317d:e87f:5636:fdbe) quit: Remote host closed the connection [6:28 PM] <arigato> I think it's promoting the pointer, not the actual string content [6:28 PM] <Alex_Gaynor> arigato: err, yes, we have string_promote nowadays though [6:28 PM] <arigato> ah, ok Benchmark: http://pastebin.com/brfj0Aq9 ---------- messages: 3546 nosy: agaynor, pypy-issue priority: performance bug status: unread title: move struct.Struct to interplevel ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue955> ________________________________________

2 2

[issue1328] cProfile: slow on built-in function calls
by Armin Rigo 01 May '14

01 May '14

New submission from Armin Rigo <armin.rigo(a)gmail.com>: The cProfile recording overhead with the JIT is low when counting function calls, but very high when counting calls to built-in functions. Jitviewer shows that it takes a lot of residual calls around a single call to a built-in function. It seems to me that we did not put enough efforts in optimizing this. A trivial example shows an overhead of about 500x: def f(n): lst = [] for i in xrange(n): lst.append(i) # built-in call lst.pop() # built-in call ---------- messages: 5010 nosy: arigo, pypy-issue priority: performance bug status: unread title: cProfile: slow on built-in function calls ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1328> ________________________________________

3 5

[issue818] MySQLdb-python 1.2.3 segmentation fault on PyPy 1.5 OSX 64bit
by Didip Kerabat 25 Apr '14

25 Apr '14

New submission from Didip Kerabat <didipk(a)gmail.com>: I'm not sure if this would help, but I documented the crash report here: https://gist.github.com/1120902 ---------- messages: 2901 nosy: didip, pypy-issue priority: bug status: unread title: MySQLdb-python 1.2.3 segmentation fault on PyPy 1.5 OSX 64bit ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue818> ________________________________________

3 2

[issue1185] [cpyext] Missing members in PyThreadState
by Colin Rice 24 Apr '14

24 Apr '14

New submission from Colin Rice <dah4k0r(a)gmail.com>: It appears that pypy doesn't define certain members namely: exc_type, exc_value, exc_tracebacl, curexc_type, curexc_value, curexc_traceback. See http://hg.python.org/cpython/file/d129982c063d/Include/pystate.h Bug appeared when trying to build gevent. ---------- messages: 4466 nosy: c00w, pypy-issue priority: bug status: unread title: [cpyext] Missing members in PyThreadState ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1185> ________________________________________

5 8

[issue1022] dict.update significantly slower than series of dict.__setitem__
by Xavier Morel 24 Apr '14

24 Apr '14

New submission from Xavier Morel <bugs.pypy.org(a)masklinn.net>: In CPython, as the number of keys grow dict.update settles at roughly half the speed of an equivalent bunch of dict[key]=value sequence: > python2.7 -m timeit -s 'd = {}' 'd["foo"] = 3' 'd["bar"] = 4' 'd["baz"] = 5' 'd["qux"] = 6' 'd["quux"] = 7' 1000000 loops, best of 3: 0.395 usec per loop > python2.7 -m timeit -s 'd = {}' 'd.update(foo=3, bar=4, baz=5, qux=6, quux=7)' 1000000 loops, best of 3: 0.657 usec per loop In Pypy, on the other hand, the difference in speed is on the order of 20x, even while setting 5 keys and dict.update is ~30% the speed of the equivalent call in CPython at almost 2µsec/loop to CPython's 0.66µsec/loop, while pypy's __setitem__ is more than 4 times faster than CPython: > pypy-c -m timeit -s 'd = {}' 'd["foo"] = 3' 'd["bar"] = 4' 'd["baz"] = 5' 'd["qux"] = 6' 'd["quux"] = 7' 10000000 loops, best of 3: 0.0877 usec per loop > pypy-c -m timeit -s 'd = {}' 'd.update(foo=3, bar=4, baz=5, qux=6, quux=7)' 100000 loops, best of 3: 1.95 usec per loop that kind-of bothers me, as I tend to use dict.update over long sequences of setitem for readability purpose. Now of course half a µsec per call is not a big difference in absolute, but still… Versions information: * OSX 10.6.8 * CPython 2.7.2 (Macports) * Pypy 1.7.0 Python 2.7.1 (?, Nov 24 2011, 10:57:50) (Macports) ---------- messages: 3814 nosy: masklinn, pypy-issue priority: performance bug status: unread title: dict.update significantly slower than series of dict.__setitem__ ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1022> ________________________________________

4 3