Mailman 3 April 2013 - pypy-issue

[issue833] missing functions in the os module
by teepark May 13, 2014

May 13, 2014

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 May 9, 2014

May 9, 2014

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 May 9, 2014

May 9, 2014

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 May 8, 2014

May 8, 2014

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 May 8, 2014

May 8, 2014

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 May 6, 2014

May 6, 2014

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

[issue1430] Memory corruption on socket.gethostbyname_ex
by Vasily Evseenko May 2, 2014

May 2, 2014

New submission from Vasily Evseenko <svpcom(a)gmail.com>: There are some memory corruption while calling socket.gethostbyname_ex from the thread while other thread executes JIT'ed code: In such case socket.gethostbyname_ex returns random entries from /etc/hosts instead of DNS lookup. Notes from dev-list: --- - it reproduces even without a JIT-enabled pypy - PyPy uses gethostbyname() instead of gethostbyname_r() --- Affected versions: PyPy 1.8, 1.9, 2.0b1 on Linux (Fedora 16, Debian GNU/Linux 6.0) --- Python 2.7.3 (07e08e9c885ca67d89bcc304e45a32346daea2fa, Mar 19 2013, 07:39:19) [PyPy 2.0.0-beta1 with GCC 4.4.5] on linux2 Python 2.7.3 (07e08e9c885ca67d89bcc304e45a32346daea2fa, Dec 18 2012, 05:33:54) [PyPy 2.0.0-beta1 with GCC 4.6.3] on linux2 Python 2.7.2 (2346207d99463f299f09f3e151c9d5fa9158f71b, May 15 2012, 11:08:08) [PyPy 1.8.0 with GCC 4.6.3] on linux2 Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Oct 23 2012, 11:37:42) [PyPy 1.9.0 with GCC 4.6.3] on linux2 --- Not affected: PyPy 2.0b1 on MacOSX --- Python 2.7.3 (07e08e9c885ca67d89bcc304e45a32346daea2fa, Mar 19 2013, 07:52:27) [PyPy 2.0.0-beta1] on darwin Python 2.7.3 (7e4f0faa3d51, Nov 21 2012, 15:59:46) [PyPy 2.0.0-beta1 with GCC 4.2.1] on darwin --- ---------- files: test.py messages: 5489 nosy: pypy-issue, svpcom priority: critical release: 2.0 status: unread title: Memory corruption on socket.gethostbyname_ex ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1430> ________________________________________

3 6

[issue1328] cProfile: slow on built-in function calls
by Armin Rigo May 1, 2014

May 1, 2014

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

[issue1416] Fix ARM hard floats
by Fijal April 28, 2014

April 28, 2014

New submission from Fijal <fijall(a)gmail.com>: Hard floats on ARM backend are broken. This essentially prevents PyPy from working on virtually any interesting ARM. We should fix it before 2.0 final ---------- messages: 5423 nosy: fijal, pypy-issue priority: critical status: unread title: Fix ARM hard floats ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1416> ________________________________________

2 2

[issue1448] pytest on default does not support multi-inherited classes
by James Lan April 27, 2014

April 27, 2014

New submission from James Lan <jameslan(a)gmail.com>: On default branch, pytest is 2.2.4.dev2, which does not support multi-inherited classes, so that test cases for both jvm and cli backend can not run. On pytest-update branch, pytest is 2.3.5dev6, fixed this issue. Please merge it back to default. BTW, will it be better to use a released version of pytest instead of dev? ---------- messages: 5559 nosy: jameslan, pypy-issue priority: critical status: unread title: pytest on default does not support multi-inherited classes ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue1448> ________________________________________

4 4