From issues-reply at bitbucket.org Fri May 1 10:00:35 2015 From: issues-reply at bitbucket.org (Majid Mobini) Date: Fri, 01 May 2015 08:00:35 -0000 Subject: [pypy-issue] Issue #2036: sandbox timeout issue (pypy/pypy) Message-ID: <20150501080035.890.30714@app10.ash-private.bitbucket.org> New issue 2036: sandbox timeout issue https://bitbucket.org/pypy/pypy/issue/2036/sandbox-timeout-issue Majid Mobini: Hi. It seems that timeout detection doesn't work when there is input/raw_input in the code but no input given to the program. From issues-reply at bitbucket.org Mon May 4 16:15:33 2015 From: issues-reply at bitbucket.org (ceridwenv) Date: Mon, 04 May 2015 14:15:33 -0000 Subject: [pypy-issue] Issue #2037: Possible import problem (pypy/pypy) Message-ID: <20150504141533.21734.57402@app03.ash-private.bitbucket.org> New issue 2037: Possible import problem https://bitbucket.org/pypy/pypy/issue/2037/possible-import-problem ceridwenv: I have a directory with two files and no `__init__.py`, `pmv` and `rename_by_title.py`. In `pmv`, I have: ``` #!bash from rename_by_title import * ``` When I call `pmv` using an absolute path using pypy like: ``` #!bash pypy ~/code/scripts/pdf_namer/pmv ``` The import fails. On cpython 2.7.9, it succeeds. Both sys.paths have '' in them and no other directory that should include my home directory (the other entries all point to /usr/). This is on an Ubuntu 15.04 system using packaged cpython and pypy from the PPA. From issues-reply at bitbucket.org Mon May 4 17:43:27 2015 From: issues-reply at bitbucket.org (mattip) Date: Mon, 04 May 2015 15:43:27 -0000 Subject: [pypy-issue] Issue #2038: add icon to pypy (pypy/pypy) Message-ID: <20150504154327.26604.9016@app10.ash-private.bitbucket.org> New issue 2038: add icon to pypy https://bitbucket.org/pypy/pypy/issue/2038/add-icon-to-pypy mattip: Eun Che suggested on the mailing list that we add an icon to pypy (on windows), and donated the artwork attached. On windows, this is done via a resource file (*.rc), which would also be an opportunity to add a versioninfo block At the same time, perhaps we could add a command to do:: editbin /LARGEADDRESSAWARE pypy.exe so that pypy by default on 64 bit windows can access up to 4GB Responsible: mattip From issues-reply at bitbucket.org Tue May 5 14:21:55 2015 From: issues-reply at bitbucket.org (Jason Madden) Date: Tue, 05 May 2015 12:21:55 -0000 Subject: [pypy-issue] Issue #2039: delattr() and del can raise TypeError when CPython would raise AttributeError (pypy/pypy) Message-ID: <20150505122155.27184.45204@app04.ash-private.bitbucket.org> New issue 2039: delattr() and del can raise TypeError when CPython would raise AttributeError https://bitbucket.org/pypy/pypy/issue/2039/delattr-and-del-can-raise-typeerror-when Jason Madden: Given an instance whose class contains a data descriptor that does not implement `__delete__`, using `delattr()` (or `del`) on that descriptor raises `TypeError` under PyPy, but `AttributeError` under CPython. CPython (2.7 here, but the same thing happens with 3.4): ``` $ python Python 2.7.9 (default, Dec 13 2014, 15:13:49) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class FieldProperty(object): ... def __get__(self, inst, klass): ... if inst is None: return self ... return 42 ... def __set__(self, inst, value): ... pass ... >>> class WithProperty(object): ... field = FieldProperty() ... >>> with_property = WithProperty() >>> delattr(with_property, 'field') Traceback (most recent call last): File "", line 1, in AttributeError: __delete__ ``` PyPy: ``` $ pypy Python 2.7.9 (9c4588d731b7, Mar 23 2015, 16:20:40) [PyPy 2.5.1 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> class FieldProperty(object): .... def __get__(self, inst, klass): .... if inst is None: return self .... return 42 .... def __set__(self, inst, value): .... pass .... .... >>>> class WithProperty(object): .... field = FieldProperty() .... .... >>>> with_property = WithProperty() >>>> delattr(with_property, 'field') Traceback (most recent call last): File "", line 1, in TypeError: 'FieldProperty' object is not a descriptor with delete ``` We ran into this testing a large Zope-based application where these kind of descriptors are common. It can break code expecting to catch only `AttributeError`. As far as I can tell, the Python language spec is silent on what happens in this scenario. The closest I've found is when it gives this example in [section 3.4.2.3](https://docs.python.org/2/reference/datamodel.html#invoking-descriptors): > Instance Binding > > If binding to a new-style object instance, `a.x` is transformed into the call: `type(a).__dict__['x'].__get__(a, type(a))`. That seems to suggest the `AttributeError` is to be expected. An `AttributeError` is also least surprising because that's what happens in both implementations when deleting a standard `@property` that doesn't specify a `__delete__`, or when deleting an attribute that just doesn't exist: PyPy, but CPython behaves the same: ``` >>>> class WithBuiltinProperty(object): .... @property .... def x(self): .... return 1 .... .... >>>> with_builtin_property = WithBuiltinProperty() >>>> delattr(with_builtin_property, 'x') Traceback (most recent call last): File "", line 1, in AttributeError: can't delete attribute >>>> delattr(with_builtin_property, 'dne') Traceback (most recent call last): File "", line 1, in AttributeError: 'WithBuiltinProperty' object has no attribute 'dne' ``` From issues-reply at bitbucket.org Tue May 5 21:46:30 2015 From: issues-reply at bitbucket.org (Volodymyr Vladymyrov) Date: Tue, 05 May 2015 19:46:30 -0000 Subject: [pypy-issue] Issue #2040: pypy processed abnormaly exists because of gdbm fatal errors (pypy/pypy) Message-ID: <20150505194630.12336.18703@app12.ash-private.bitbucket.org> New issue 2040: pypy processed abnormaly exists because of gdbm fatal errors https://bitbucket.org/pypy/pypy/issue/2040/pypy-processed-abnormaly-exists-because-of Volodymyr Vladymyrov: We use gdbm from pypy - the app has multiple processes accessing same gdbm file in parallel. Python 2.7.6 (32f35069a16d819b58c1b6efb17c44e3e53397b2, Aug 19 2014, 23:32:55) [PyPy 2.3.1 with GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] Several times a day every process exists with gdbm fatal error. I've seen several kinds of errors: ``` gdbm fatal: lseek error ``` ``` gdbm fatal: malloc error ``` ``` #!python if key not in self.db: File "/usr/lib64/pypy-2.3.1/lib_pypy/gdbm.py", line 97, in __contains__ self._check_closed() File "/usr/lib64/pypy-2.3.1/lib_pypy/gdbm.py", line 144, in _check_closed raise error("GDBM object has already been closed") error: GDBM object has already been closed ``` Also I've seen this trace: ``` *** glibc detected *** /usr/bin/pypy: double free or corruption (out): 0x00007f15a81a2180 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3061075e66] /lib64/libc.so.6[0x30610789b3] /usr/lib64/libgdbm.so.2(_gdbm_read_entry+0x4c)[0x7f15b5ef482c] /usr/lib64/libgdbm.so.2(_gdbm_findkey+0x120)[0x7f15b5ef4a50] /usr/lib64/libgdbm.so.2(gdbm_exists+0x1b)[0x7f15b5ef36ab] [0x7f1596157c12] ======= Memory map: ======== 00400000-0184e000 r-xp 00000000 08:03 268691 /usr/lib64/pypy-2.3.1/bin/pypy 01a4d000-03099000 rw-p 0144d000 08:03 268691 /usr/lib64/pypy-2.3.1/bin/pypy 03099000-030bb000 rw-p 00000000 00:00 0 03298000-0329e000 rw-p 02a98000 08:03 268691 /usr/lib64/pypy-2.3.1/bin/pypy 04b7b000-06b59000 rw-p 00000000 00:00 0 06b59000-208e7000 rw-p 00000000 00:00 0 3060c00000-3060c20000 r-xp 00000000 08:03 141727 /lib64/ld-2.12.so 3060e1f000-3060e20000 r--p 0001f000 08:03 141727 /lib64/ld-2.12.so 3060e20000-3060e21000 rw-p 00020000 08:03 141727 /lib64/ld-2.12.so 3060e21000-3060e22000 rw-p 00000000 00:00 0 3061000000-306118a000 r-xp 00000000 08:03 141731 /lib64/libc-2.12.so 306118a000-306138a000 ---p 0018a000 08:03 141731 /lib64/libc-2.12.so 306138a000-306138e000 r--p 0018a000 08:03 141731 /lib64/libc-2.12.so 306138e000-306138f000 rw-p 0018e000 08:03 141731 /lib64/libc-2.12.so 306138f000-3061394000 rw-p 00000000 00:00 0 3061400000-3061402000 r-xp 00000000 08:03 141751 /lib64/libdl-2.12.so 3061402000-3061602000 ---p 00002000 08:03 141751 /lib64/libdl-2.12.so 3061602000-3061603000 r--p 00002000 08:03 141751 /lib64/libdl-2.12.so 3061603000-3061604000 rw-p 00003000 08:03 141751 /lib64/libdl-2.12.so 3061800000-3061817000 r-xp 00000000 08:03 141745 /lib64/libpthread-2.12.so 3061817000-3061a17000 ---p 00017000 08:03 141745 /lib64/libpthread-2.12.so 3061a17000-3061a18000 r--p 00017000 08:03 141745 /lib64/libpthread-2.12.so 3061a18000-3061a19000 rw-p 00018000 08:03 141745 /lib64/libpthread-2.12.so 3061a19000-3061a1d000 rw-p 00000000 00:00 0 3061c00000-3061c83000 r-xp 00000000 08:03 141749 /lib64/libm-2.12.so 3061c83000-3061e82000 ---p 00083000 08:03 141749 /lib64/libm-2.12.so 3061e82000-3061e83000 r--p 00082000 08:03 141749 /lib64/libm-2.12.so 3061e83000-3061e84000 rw-p 00083000 08:03 141749 /lib64/libm-2.12.so 3062000000-3062015000 r-xp 00000000 08:03 136447 /lib64/libz.so.1.2.3 3062015000-3062214000 ---p 00015000 08:03 136447 /lib64/libz.so.1.2.3 3062214000-3062215000 r--p 00014000 08:03 136447 /lib64/libz.so.1.2.3 3062215000-3062216000 rw-p 00015000 08:03 136447 /lib64/libz.so.1.2.3 3062400000-3062407000 r-xp 00000000 08:03 141752 /lib64/librt-2.12.so 3062407000-3062606000 ---p 00007000 08:03 141752 /lib64/librt-2.12.so 3062606000-3062607000 r--p 00006000 08:03 141752 /lib64/librt-2.12.so 3062607000-3062608000 rw-p 00007000 08:03 141752 /lib64/librt-2.12.so 3062800000-306281d000 r-xp 00000000 08:03 141763 /lib64/libselinux.so.1 306281d000-3062a1c000 ---p 0001d000 08:03 141763 /lib64/libselinux.so.1 3062a1c000-3062a1d000 r--p 0001c000 08:03 141763 /lib64/libselinux.so.1 3062a1d000-3062a1e000 rw-p 0001d000 08:03 141763 /lib64/libselinux.so.1 3062a1e000-3062a1f000 rw-p 00000000 00:00 0 3062c00000-3062c07000 r-xp 00000000 08:03 1055746 /usr/lib64/libffi.so.5.0.6 3062c07000-3062e07000 ---p 00007000 08:03 1055746 /usr/lib64/libffi.so.5.0.6 3062e07000-3062e08000 rw-p 00007000 08:03 1055746 /usr/lib64/libffi.so.5.0.6 3063000000-3063016000 r-xp 00000000 08:03 131205 /lib64/libresolv-2.12.so 3063016000-3063216000 ---p 00016000 08:03 131205 /lib64/libresolv-2.12.so 3063216000-3063217000 r--p 00016000 08:03 131205 /lib64/libresolv-2.12.so 3063217000-3063218000 rw-p 00017000 08:03 131205 /lib64/libresolv-2.12.so 3063218000-306321a000 rw-p 00000000 00:00 0 3063400000-3063403000 r-xp 00000000 08:03 141429 /lib64/libcom_err.so.2.1 3063403000-3063602000 ---p 00003000 08:03 141429 /lib64/libcom_err.so.2.1 3063602000-3063603000 r--p 00002000 08:03 141429 /lib64/libcom_err.so.2.1 3063603000-3063604000 rw-p 00003000 08:03 141429 /lib64/libcom_err.so.2.1 3063800000-306385d000 r-xp 00000000 08:03 141756 /lib64/libfreebl3.so 306385d000-3063a5c000 ---p 0005d000 08:03 141756 /lib64/libfreebl3.so 3063a5c000-3063a5d000 r--p 0005c000 08:03 141756 /lib64/libfreebl3.so 3063a5d000-3063a5e000 rw-p 0005d000 08:03 141756 /lib64/libfreebl3.so 3063a5e000-3063a62000 rw-p 00000000 00:00 0 3063c00000-3063c02000 r-xp 00000000 08:03 131531 /lib64/libutil-2.12.so 3063c02000-3063e01000 ---p 00002000 08:03 131531 /lib64/libutil-2.12.so 3063e01000-3063e02000 r--p 00001000 08:03 131531 /lib64/libutil-2.12.so 3063e02000-3063e03000 rw-p 00002000 08:03 131531 /lib64/libutil-2.12.so 3064000000-3064007000 r-xp 00000000 08:03 141757 /lib64/libcrypt-2.12.so 3064007000-3064207000 ---p 00007000 08:03 141757 /lib64/libcrypt-2.12.so 3064207000-3064208000 r--p 00007000 08:03 141757 /lib64/libcrypt-2.12.so 3064208000-3064209000 rw-p 00008000 08:03 141757 /lib64/libcrypt-2.12.so 3064209000-3064237000 rw-p 00000000 00:00 0 3064400000-306441d000 r-xp 00000000 08:03 141451 /lib64/libtinfo.so.5.7 306441d000-306461d000 ---p 0001d000 08:03 141451 /lib64/libtinfo.so.5.7 306461d000-3064621000 rw-p 0001d000 08:03 141451 /lib64/libtinfo.so.5.7 3065c00000-3065db5000 r-xp 00000000 08:03 1053887 /usr/lib64/libcrypto.so.1.0.1e 3065db5000-3065fb5000 ---p 001b5000 08:03 1053887 /usr/lib64/libcrypto.so.1.0.1e 3065fb5000-3065fd0000 r--p 001b5000 08:03 1053887 /usr/lib64/libcrypto.so.1.0.1e 3065fd0000-3065fdc000 rw-p 001d0000 08:03 1053887 /usr/lib64/libcrypto.so.1.0.1e 3065fdc000-3065fe0000 rw-p 00000000 00:00 0 3066000000-3066010000 r-xp 00000000 08:03 141779 /lib64/libbz2.so.1.0.4 3066010000-306620f000 ---p 00010000 08:03 141779 /lib64/libbz2.so.1.0.4 306620f000-3066211000 rw-p 0000f000 08:03 141779 /lib64/libbz2.so.1.0.4 3066400000-3066429000 r-xp 00000000 08:03 141789 /lib64/libk5crypto.so.3.1 3066429000-3066629000 ---p 00029000 08:03 141789 /lib64/libk5crypto.so.3.1 3066629000-306662a000 r--p 00029000 08:03 141789 /lib64/libk5crypto.so.3.1 306662a000-306662b000 rw-p 0002a000 08:03 141789 /lib64/libk5crypto.so.3.1 306662b000-306662c000 rw-p 00000000 00:00 0 3066800000-3066841000 r-xp 00000000 08:03 141791 /lib64/libgssapi_krb5.so.2.2 3066841000-3066a41000 ---p 00041000 08:03 141791 /lib64/libgssapi_krb5.so.2.2 3066a41000-3066a42000 r--p 00041000 08:03 141791 /lib64/libgssapi_krb5.so.2.2 3066a42000-3066a44000 rw-p 00042000 08:03 141791 /lib64/libgssapi_krb5.so.2.2 3066c00000-3066c0a000 r-xp 00000000 08:03 141788 /lib64/libkrb5support.so.0.1 3066c0a000-3066e09000 ---p 0000a000 08:03 141788 /lib64/libkrb5support.so.0.1 3066e09000-3066e0a000 r--p 00009000 08:03 141788 /lib64/libkrb5support.so.0.1 3066e0a000-3066e0b000 rw-p 0000a000 08:03 141788 /lib64/libkrb5support.so.0.1 3067000000-30670db000 r-xp 00000000 08:03 141790 /lib64/libkrb5.so.3.3 30670db000-30672da000 ---p 000db000 08:03 141790 /lib64/libkrb5.so.3.3 30672da000-30672e4000 r--p 000da000 08:03 141790 /lib64/libkrb5.so.3.3 30672e4000-30672e6000 rw-p 000e4000 08:03 141790 /lib64/libkrb5.so.3.3 3067400000-3067402000 r-xp 00000000 08:03 136441 /lib64/libkeyutils.so.1.3 3067402000-3067601000 ---p 00002000 08:03 136441 /lib64/libkeyutils.so.1.3 3067601000-3067602000 r--p 00001000 08:03 136441 /lib64/libkeyutils.so.1.3 3067602000-3067603000 rw-p 00002000 08:03 136441 /lib64/libkeyutils.so.1.3 3067800000-3067861000 r-xp 00000000 08:03 1055668 /usr/lib64/libssl.so.1.0.1e 3067861000-3067a61000 ---p 00061000 08:03 1055668 /usr/lib64/libssl.so.1.0.1e 3067a61000-3067a65000 r--p 00061000 08:03 1055668 /usr/lib64/libssl.so.1.0.1e 3067a65000-3067a6c000 rw-p 00065000 08:03 1055668 /usr/lib64/libssl.so.1.0.1e 3067c00000-3067c26000 r-xp 00000000 08:03 131176 /lib64/libexpat.so.1.5.2 3067c26000-3067e25000 ---p 00026000 08:03 131176 /lib64/libexpat.so.1.5.2 3067e25000-3067e28000 rw-p 00025000 08:03 131176 /lib64/libexpat.so.1.5.2 3068400000-3068422000 r-xp 00000000 08:03 136446 /lib64/libncurses.so.5.7 3068422000-3068621000 ---p 00022000 08:03 136446 /lib64/libncurses.so.5.7 3068621000-3068622000 rw-p 00021000 08:03 136446 /lib64/libncurses.so.5.7 7f1560000000-7f1563fe6000 rw-p 00000000 00:00 0 7f1563fe6000-7f1564000000 ---p 00000000 00:00 0 7f1568000000-7f156b082000 rw-p 00000000 00:00 0 7f156b082000-7f156c000000 ---p 00000000 00:00 0 7f1570000000-7f1574000000 rw-p 00000000 00:00 0 7f1577dbe000-7f1577dff000 r-xp 00000000 08:03 401411 /usr/lib64/pypy-2.3.1/site-packages/cryptography/_Cryptography_cffi_f3e4673fx399b1113.pypy-23.so 7f1577dff000-7f1577ffe000 ---p 00041000 08:03 401411 /usr/lib64/pypy-2.3.1/site-packages/cryptography/_Cryptography_cffi_f3e4673fx399b1113.pypy-23.so 7f1577ffe000-7f1578000000 rw-p 00040000 08:03 401411 /usr/lib64/pypy-2.3.1/site-packages/cryptography/_Cryptography_cffi_f3e4673fx399b1113.pypy-23.so 7f1578000000-7f157bfee000 rw-p 00000000 00:00 0 7f157bfee000-7f157c000000 ---p 00000000 00:00 0 7f157c000000-7f157ffb2000 rw-p 00000000 00:00 0 7f157ffb2000-7f1580000000 ---p 00000000 00:00 0 7f1584000000-7f1587fb8000 rw-p 00000000 00:00 0 7f1587fb8000-7f1588000000 ---p 00000000 00:00 0 7f158bfff000-7f1590000000 rw-p 00000000 00:00 0 7f1590000000-7f1590c65000 rw-p 00000000 00:00 0 7f1590c65000-7f1594000000 ---p 00000000 00:00 0 7f159608b000-7f159618b000 rwxp 00000000 00:00 0 7f159618b000-7f1597590000 rw-p 00000000 00:00 0 7f1597991000-7f1597d92000 rw-p 00000000 00:00 0 7f1598000000-7f159c000000 rw-p 00000000 00:00 0 7f159c000000-7f159fe5c000 rw-p 00000000 00:00 0 7f159fe5c000-7f15a0000000 ---p 00000000 00:00 0 7f15a0000000-7f15a037d000 rw-p 00000000 00:00 0 7f15a037d000-7f15a4000000 ---p 00000000 00:00 0 7f15a440c000-7f15a480c000 rwxp 00000000 00:00 0 7f15a4bdb000-7f15a4ddb000 rwxp 00000000 00:00 0 7f15a4ddb000-7f15a4de0000 r-xp 00000000 08:03 131100 /lib64/libnss_dns-2.12.so 7f15a4de0000-7f15a4fdf000 ---p 00005000 08:03 131100 /lib64/libnss_dns-2.12.so 7f15a4fdf000-7f15a4fe0000 r--p 00004000 08:03 131100 /lib64/libnss_dns-2.12.so 7f15a4fe0000-7f15a4fe1000 rw-p 00005000 08:03 131100 /lib64/libnss_dns-2.12.so 7f15a4fe1000-7f15a4fec000 r-xp 00000000 08:06 6556626 /.../__pycache__/_cffi__g511f7c39x1f2cb7a3.pypy-23.so 7f15a4fec000-7f15a51eb000 ---p 0000b000 08:06 6556626 /.../__pycache__/_cffi__g511f7c39x1f2cb7a3.pypy-23.so 7f15a51eb000-7f15a51ef000 rw-p 0000a000 08:06 6556626 /.../__pycache__/_cffi__g511f7c39x1f2cb7a3.pypy-23.so 7f15a51ef000-7f15a51f6000 r-xp 00000000 08:03 1061242 /usr/lib64/libprotobuf-c.so.1.0.0 7f15a51f6000-7f15a53f5000 ---p 00007000 08:03 1061242 /usr/lib64/libprotobuf-c.so.1.0.0 7f15a53f5000-7f15a53f6000 rw-p 00006000 08:03 1061242 /usr/lib64/libprotobuf-c.so.1.0.0 7f15a53f6000-7f15a5409000 r-xp 00000000 08:06 6556482 /.../__pycache__/_cffi__g5f3c3c2x3a5ac0fb.pypy-23.so 7f15a5409000-7f15a5609000 ---p 00013000 08:06 6556482 /.../__pycache__/_cffi__g5f3c3c2x3a5ac0fb.pypy-23.so 7f15a5609000-7f15a5610000 rw-p 00013000 08:06 6556482 /.../__pycache__/_cffi__g5f3c3c2x3a5ac0fb.pypy-23.so 7f15a5610000-7f15a5751000 rw-p 00000000 00:00 0 7f15a5751000-7f15a5752000 ---p 00000000 00:00 0 7f15a5752000-7f15a6293000 rw-p 00000000 00:00 0 7f15a6293000-7f15a6294000 ---p 00000000 00:00 0 7f15a6294000-7f15a6c94000 rw-p 00000000 00:00 0 7f15a6c94000-7f15a6cdd000 r-xp 00000000 08:03 1054896 /usr/lib64/libboost_program_options-mt.so.5 7f15a6cdd000-7f15a6edd000 ---p 00049000 08:03 1054896 /usr/lib64/libboost_program_options-mt.so.5 7f15a6edd000-7f15a6ee1000 rw-p 00049000 08:03 1054896 /usr/lib64/libboost_program_options-mt.so.5 7f15a6ee1000-7f15a6ee4000 r-xp 00000000 08:03 1050223 /usr/lib64/liballreduce.so.0 7f15a6ee4000-7f15a70e4000 ---p 00003000 08:03 1050223 /usr/lib64/liballreduce.so.0 7f15a70e4000-7f15a70e5000 rw-p 00003000 08:03 1050223 /usr/lib64/liballreduce.so.0 7f15a70e5000-7f15a71f6000 r-xp 00000000 08:03 1067920 /usr/lib64/libvw.so.0 7f15a71f6000-7f15a73f6000 ---p 00111000 08:03 1067920 /usr/lib64/libvw.so.0 7f15a73f6000-7f15a73fc000 rw-p 00111000 08:03 1067920 /usr/lib64/libvw.so.0 7f15a73fc000-7f15a73ff000 r-xp 00000000 08:03 1067833 /usr/lib64/libvw_c_wrapper.so.0 7f15a73ff000-7f15a75fe000 ---p 00003000 08:03 1067833 /usr/lib64/libvw_c_wrapper.so.0 7f15a75fe000-7f15a75ff000 rw-p 00002000 08:03 1067833 /usr/lib64/libvw_c_wrapper.so.0 7f15a75ff000-7f15a7600000 ---p 00000000 00:00 0 7f15a7600000-7f15a8000000 rw-p 00000000 00:00 0 7f15a8000000-7f15a85f0000 rw-p 00000000 00:00 0 7f15a85f0000-7f15ac000000 ---p 00000000 00:00 0 7f15ac0ae000-7f15ac0c4000 r-xp 00000000 08:03 141750 /lib64/libgcc_s-4.4.7-20120601.so.1 7f15ac0c4000-7f15ac2c3000 ---p 00016000 08:03 141750 /lib64/libgcc_s-4.4.7-20120601.so.1 7f15ac2c3000-7f15ac2c4000 rw-p 00015000 08:03 141750 /lib64/libgcc_s-4.4.7-20120601.so.1 7f15ac2c4000-7f15ac3ac000 r-xp 00000000 08:03 1054915 /usr/lib64/libstdc++.so.6.0.13 7f15ac3ac000-7f15ac5ac000 ---p 000e8000 08:03 1054915 /usr/lib64/libstdc++.so.6.0.13 7f15ac5ac000-7f15ac5b3000 r--p 000e8000 08:03 1054915 /usr/lib64/libstdc++.so.6.0.13 7f15ac5b3000-7f15ac5b5000 rw-p 000ef000 08:03 1054915 /usr/lib64/libstdc++.so.6.0.13 7f15ac5b5000-7f15ac5ca000 rw-p 00000000 00:00 0 7f15ac5ca000-7f15ac6a8000 r-xp 00000000 08:03 1065402 /usr/lib64/libpcache.so 7f15ac6a8000-7f15ac8a8000 ---p 000de000 08:03 1065402 /usr/lib64/libpcache.so 7f15ac8a8000-7f15ac8b0000 rw-p 000de000 08:03 1065402 /usr/lib64/libpcache.so 7f15ac8b0000-7f15b0000000 r--s 00000000 08:03 398741 /usr/share/GeoIP/GeoIPCity.dat 7f15b0000000-7f15b0161000 rw-p 00000000 00:00 0 7f15b0161000-7f15b4000000 ---p 00000000 00:00 0 7f15b4063000-7f15b4064000 r-xp 00000000 08:06 6555832 /.../__pycache__/_cffi__g6666dc4fx2cba47ec.pypy-23.so 7f15b4064000-7f15b4263000 ---p 00001000 08:06 6555832 /.../__pycache__/_cffi__g6666dc4fx2cba47ec.pypy-23.so 7f15b4263000-7f15b4264000 rw-p 00000000 08:06 6555832 /.../__pycache__/_cffi__g6666dc4fx2cba47ec.pypy-23.so 7f15b4264000-7f15b4265000 r-xp 00000000 08:06 6554851 /.../__pycache__/_cffi__g17b18f9fx1c222708.pypy-23.so 7f15b4265000-7f15b4465000 ---p 00001000 08:06 6554851 /.../__pycache__/_cffi__g17b18f9fx1c222708.pypy-23.so 7f15b4465000-7f15b4466000 rw-p 00001000 08:06 6554851 /.../__pycache__/_cffi__g17b18f9fx1c222708.pypy-23.so 7f15b4466000-7f15b46e8000 rw-p 00000000 00:00 0 7f15b46e8000-7f15b46e9000 ---p 00000000 00:00 0 7f15b46e9000-7f15b522a000 rw-p 00000000 00:00 0 7f15b522a000-7f15b522b000 ---p 00000000 00:00 0 7f15b522b000-7f15b5cec000 rw-p 00000000 00:00 0 7f15b5cec000-7f15b5cf0000 r-xp 00000000 08:03 141764 /lib64/libuuid.so.1.3.0 7f15b5cf0000-7f15b5eef000 ---p 00004000 08:03 141764 /lib64/libuuid.so.1.3.0 7f15b5eef000-7f15b5ef0000 rw-p 00003000 08:03 141764 /lib64/libuuid.so.1.3.0 7f15b5ef0000-7f15b5ef6000 r-xp 00000000 08:03 1050404 /usr/lib64/libgdbm.so.2.0.0 7f15b5ef6000-7f15b60f5000 ---p 00006000 08:03 1050404 /usr/lib64/libgdbm.so.2.0.0 7f15b60f5000-7f15b60f6000 rw-p 00005000 08:03 1050404 /usr/lib64/libgdbm.so.2.0.0 7f15b60f6000-7f15b60f8000 r-xp 00000000 08:03 268458 /usr/lib64/pypy-2.3.1/lib_pypy/__pycache__/_cffi__g154eb17fxf13cf229.pypy-23.so 7f15b60f8000-7f15b62f7000 ---p 00002000 08:03 268458 /usr/lib64/pypy-2.3.1/lib_pypy/__pycache__/_cffi__g154eb17fxf13cf229.pypy-23.so 7f15b62f7000-7f15b62f8000 rw-p 00001000 08:03 268458 /usr/lib64/pypy-2.3.1/lib_pypy/__pycache__/_cffi__g154eb17fxf13cf229.pypy-23.so 7f15b62f8000-7f15b6439000 rw-p 00000000 00:00 0 7f15b6439000-7f15b643a000 ---p 00000000 00:00 0 7f15b643a000-7f15b6e3a000 rw-p 00000000 00:00 0 7f15b6e3a000-7f15b707e000 rw-p 00000000 00:00 0 7f15b707e000-7f15b708a000 r-xp 00000000 08:03 133857 /lib64/libnss_files-2.12.so 7f15b708a000-7f15b728a000 ---p 0000c000 08:03 133857 /lib64/libnss_files-2.12.so 7f15b728a000-7f15b728b000 r--p 0000c000 08:03 133857 /lib64/libnss_files-2.12.so 7f15b728b000-7f15b728c000 rw-p 0000d000 08:03 133857 /lib64/libnss_files-2.12.so 7f15b7295000-7f15b73d7000 rw-p 00000000 00:00 0 7f15b73d7000-7f15b74d7000 rwxp 00000000 00:00 0 7f15b74d7000-7f15b7e47000 rw-p 00000000 00:00 0 7f15b7e4e000-7f15b7e4f000 rw-p 00000000 00:00 0 7f15b7e4f000-7f15b7e50000 rwxp 00000000 00:00 0 7f15b7e50000-7f15b7e92000 rw-p 00000000 00:00 0 7fffff6ca000-7fffff6df000 rw-p 00000000 00:00 0 [stack] 7fffff72b000-7fffff72c000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] ``` From issues-reply at bitbucket.org Wed May 6 12:01:54 2015 From: issues-reply at bitbucket.org (Edd Barrett) Date: Wed, 06 May 2015 10:01:54 -0000 Subject: [pypy-issue] Issue #2041: RPython: detect_number_of_processors() doesn't understand OpenBSD. (pypy/pypy) Message-ID: <20150506100154.21647.1841@app06.ash-private.bitbucket.org> New issue 2041: RPython: detect_number_of_processors() doesn't understand OpenBSD. https://bitbucket.org/pypy/pypy/issue/2041/rpython-detect_number_of_processors-doesnt Edd Barrett: I notice that translation doesn't use 'gmake -j' on OpenBSD. I think the reason is that detect_number_of_processors() does not have an implementation for OpenBSD. It just returns 1, so make is not parallel. I will fix this. Opening a bug in the meantime. Responsible: vext01 From issues-reply at bitbucket.org Fri May 8 09:13:38 2015 From: issues-reply at bitbucket.org (Sheng Lu) Date: Fri, 08 May 2015 07:13:38 -0000 Subject: [pypy-issue] Issue #2042: pypy memory allocate error. (pypy/pypy) Message-ID: <20150508071338.23935.53144@app09.ash-private.bitbucket.org> New issue 2042: pypy memory allocate error. https://bitbucket.org/pypy/pypy/issue/2042/pypy-memory-allocate-error Sheng Lu: I use pypy 2.5.1, windows 7 my commend is: C:\Dataload\Dataload Executables\AO3Dataload\src>pypy mmtmain.py -E PYPY_GC_MAX_DELTA=4.0GB But I still get the error feedback from my pypy and rpython Getting all related products info... RPython traceback: File "rpython_jit_metainterp_warmspot.c", line 1300, in ll_portal_runner__Unsi gned_Bool_pypy_interpreter File "rpython_jit_metainterp_warmstate.c", line 4795, in maybe_compile_and_run __star_5 File "rpython_jit_metainterp_warmstate.c", line 10053, in execute_assembler__s tar_2_2 File "rpython_jit_metainterp_compile.c", line 5694, in DoneWithThisFrameDescrR ef_handle_fail out of memory: couldn't allocate the next arena This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I think this is my memory limited. but as I show I enlarge the max memory to 4.0GB, but still get the error.(I do not believe this program will really spend as much as 4.0GB memory.) which environment parameter I should also set? From issues-reply at bitbucket.org Sat May 9 02:58:39 2015 From: issues-reply at bitbucket.org (Max Grender-Jones) Date: Sat, 09 May 2015 00:58:39 -0000 Subject: [pypy-issue] Issue #2043: functools.partial doesn't behave the same way under CPython and PyPy when not given arguments (pypy/pypy) Message-ID: <20150509005839.20515.51501@app04.ash-private.bitbucket.org> New issue 2043: functools.partial doesn't behave the same way under CPython and PyPy when not given arguments https://bitbucket.org/pypy/pypy/issue/2043/functoolspartial-doesnt-behave-the-same Max Grender-Jones: If no keyword arguments are provided, `keywords` should be an empty `dict` not `None` ``` $ python Python 2.7.9 (default, Apr 7 2015, 07:58:25) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from functools import partial >>> partial(int, *[1], **{}).keywords {} ``` vs ``` $ pypy Python 2.7.9 (9c4588d731b7fe0b08669bd732c2b676cb0a8233, Mar 31 2015, 07:55:22) [PyPy 2.5.1 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> from functools import partial >>>> partial(int, *[1], **{}).keywords >>>> ``` From issues-reply at bitbucket.org Sat May 9 14:22:08 2015 From: issues-reply at bitbucket.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=) Date: Sat, 09 May 2015 12:22:08 -0000 Subject: [pypy-issue] Issue #2044: PYTHONOPTIMIZE is not supported (pypy/pypy) Message-ID: <20150509122208.29805.87378@app14.ash-private.bitbucket.org> New issue 2044: PYTHONOPTIMIZE is not supported https://bitbucket.org/pypy/pypy/issue/2044/pythonoptimize-is-not-supported Alex Gr?nholm: The environment variable PYTHONOPTIMIZE should set __debug__ to False like it does on CPython, but it doesn't on PyPy. From issues-reply at bitbucket.org Sat May 9 16:55:42 2015 From: issues-reply at bitbucket.org (Omer Katz) Date: Sat, 09 May 2015 14:55:42 -0000 Subject: [pypy-issue] Issue #2045: Create a TransactionQueue for running a low number of tasks (pypy/pypy) Message-ID: <20150509145542.22465.48799@app04.ash-private.bitbucket.org> New issue 2045: Create a TransactionQueue for running a low number of tasks https://bitbucket.org/pypy/pypy/issue/2045/create-a-transactionqueue-for-running-a Omer Katz: The TransactionQueue is meant to run a lot of tasks due to implementation trade offs. It'd be nice to be able to parallelize 4 or 10 tasks as well. From issues-reply at bitbucket.org Tue May 12 22:13:34 2015 From: issues-reply at bitbucket.org (Ed Baskerville) Date: Tue, 12 May 2015 20:13:34 -0000 Subject: [pypy-issue] Issue #2046: Incorrect in-place sort behavior in numpy array slice (pypy/pypy) Message-ID: <20150512201334.10125.8271@app11.ash-private.bitbucket.org> New issue 2046: Incorrect in-place sort behavior in numpy array slice https://bitbucket.org/pypy/pypy/issue/2046/incorrect-in-place-sort-behavior-in-numpy Ed Baskerville: In PyPy 2.5.1, OS X binary build, PyPy's numpy fork, sorting a column slice of a 2D numpy array can result in incorrect behavior. In this case, the mistaken modifications are not restricted to the column being sorted: ```{python} >>>> import numpy >>>> x = numpy.array([[2,0],[1,0]]) >>>> x array([[2, 0], [1, 0]]) >>>> x[0,:].sort() >>>> x array([[0, 2], [1, 0]]) ``` The behavior should be (as generated using Python 2.7.9/Anaconda 2.0.1): ```{python} >>> import numpy >>> x = numpy.array([[2,0],[1,0]]) >>> x array([[2, 0], [1, 0]]) >>> x[:,0].sort() >>> x array([[1, 0], [2, 0]]) ``` From issues-reply at bitbucket.org Wed May 13 17:51:38 2015 From: issues-reply at bitbucket.org (Anton Dries) Date: Wed, 13 May 2015 15:51:38 -0000 Subject: [pypy-issue] Issue #2047: Contextmanager's (aka `with` block) __exit__ function not always called (pypy/pypy) Message-ID: <20150513155138.29439.18118@app02.ash-private.bitbucket.org> New issue 2047: Contextmanager's (aka `with` block) __exit__ function not always called https://bitbucket.org/pypy/pypy/issue/2047/contextmanagers-aka-with-block-__exit__ Anton Dries: In some cases PyPy doesn't execute the __exit__ function of a user-defined context manager. Problem still persists in latest build (linux64 of 2015-05-13). Minimal example attached. Expected output (as in CPython) (numbers may vary): ('ENTER', 140373335131152) ('EXIT', 140373335131152) 6 PyPy output: ('ENTER', 139827597959816L) 6 From issues-reply at bitbucket.org Thu May 14 05:32:16 2015 From: issues-reply at bitbucket.org (posita) Date: Thu, 14 May 2015 03:32:16 -0000 Subject: [pypy-issue] Issue #2048: datetime.utcfromtimestamp barfs when calling divmod(, ) (pypy/pypy) Message-ID: <20150514033216.12941.55943@app11.ash-private.bitbucket.org> New issue 2048: datetime.utcfromtimestamp barfs when calling divmod(, ) https://bitbucket.org/pypy/pypy/issue/2048/datetimeutcfromtimestamp-barfs-when posita: The effect of this is hidden by the fact that the native `int`'s `__divmod__` method accepts `float`s: ```py >>>> from datetime import datetime >>>> i = int(1431216000) >>>> type(i) >>>> divmod(i, 1.0) (1431216000.0, 0.0) >>>> datetime.utcfromtimestamp(i) datetime.datetime(2015, 5, 10, 0, 0) ``` However, [`future`](http://python-future.org/)'s `int` implementation does not: ```py >>>> from builtins import int as _int >>>> import future >>>> future.__version__ '0.14.3' >>>> j = _int(i) >>>> type(j) >>>> i == j True >>>> datetime.utcfromtimestamp(j) Traceback (most recent call last): File "", line 1, in File "/Users/matt/.site/lib/pypy/lib_pypy/datetime.py", line 1530, in utcfromtimestamp t, frac = divmod(t, 1.0) File ".../site-packages/future-0.14.3-py2.7.egg/future/types/newint.py", line 204, in __divmod__ return (newint(value[0]), newint(value[1])) TypeError: 'NotImplemented' object is not subscriptable ``` Now, before everybody jumps up and [points figures at `future`](https://github.com/PythonCharmers/python-future/issues/144), cPython *seems* to promote `future`'s `newint` to a native `int` or `float` or something, because calling [*its* `datetime.utcfromtimestamp`](https://github.com/python/cpython/blob/aa8ea3a6be22c92e774df90c6a6ee697915ca8ec/Lib/datetime.py#L1398) *works* with `future`'s `newint`s (despite PyPy's [very similar implementation](/pypy/pypy/src/bdf0f94b1bd21c29a5996d536af123e1e5cadbad/lib_pypy/datetime.py?at=default#cl-1530)): ```py >>> from datetime import datetime >>> i = int(1431216000) >>> from builtins import int as _int >>> import future >>> future.__version__ '0.14.3' >>> type(i) >>> j = _int(i) >>> type(j) >>> i == j True >>> divmod(i, 1.0) (1431216000.0, 0.0) >>> divmod(j, 1.0) Traceback (most recent call last): File "", line 1, in File ".../site-packages/future/types/newint.py", line 204, in __divmod__ return (newint(value[0]), newint(value[1])) TypeError: 'NotImplementedType' object has no attribute '__getitem__' >>> datetime.utcfromtimestamp(i) datetime.datetime(2015, 5, 10, 0, 0) >>> datetime.utcfromtimestamp(j) datetime.datetime(2015, 5, 10, 0, 0) ``` [![Whoa, WHAT?!](http://matt.bogosian.net/img/doris.png)](http://b1nd1.deviantart.com/art/Doris-156093096) From issues-reply at bitbucket.org Tue May 19 19:10:21 2015 From: issues-reply at bitbucket.org (Jason Madden) Date: Tue, 19 May 2015 17:10:21 -0000 Subject: [pypy-issue] Issue #2049: `enumerate` is relatively very slow under PyPy (but relatively fast under CPython) (pypy/pypy) Message-ID: <20150519171021.22127.65084@app08.ash-private.bitbucket.org> New issue 2049: `enumerate` is relatively very slow under PyPy (but relatively fast under CPython) https://bitbucket.org/pypy/pypy/issue/2049/enumerate-is-relatively-very-slow-under Jason Madden: While working on a PyPy compatible version of the `persistent` library, we noticed that the performance of the `enumerate` function is quite slow relative to maintaining the iteration count manually. In CPython, exactly the opposite is true and enumerate is faster. Tres Seaver [encouraged me to open a bug report.](https://github.com/zopefoundation/persistent/pull/20#discussion-diff-30593623) Given code similar to this (based on what Persistent was doing): ```python from collections import deque class Ring(object): def __init__(self): self.ring = deque() for i in range(3000): self.ring.append(i) def delete_with_enumerate(self, obj): for i, o in enumerate(self.ring): if o == obj: del self.ring[i] return 1 def delete_without_enumerate(self, obj): i = 0 for o in self.ring: if o == obj: del self.ring[i] return 1 i += 1 def test_enumerate(): ring = Ring() for i in range(3000, 0, -1): ring.delete_with_enumerate(i) def test_without_enumerate(): ring = Ring() for i in range(3000, 0, -1): ring.delete_without_enumerate(i) ``` Using the `timeit` module to run the two functions 100 times, taking the best of 20 runs (for a total run time for each function of nearly a minute on my machine) produces these results: | | PyPy 2.5.1 | CPython 2.7.9 | |------------|--------------:|-------------------| test_enumerate | 25.8ms | 352 ms | test_without_enumerate | 14.8ms| 414ms | % slowdown | 74% | -15% | In other words, using `enumerate` slows PyPy down by 74% (relative to counting by hand), whereas it speeds up CPython by 15%. PyPy is impressively fast here, of course, but removing `enumerate` speeds it up even more, which is the opposite of a CPython user's intuition and experience. From issues-reply at bitbucket.org Fri May 22 06:02:43 2015 From: issues-reply at bitbucket.org (posita) Date: Fri, 22 May 2015 04:02:43 -0000 Subject: [pypy-issue] Issue #2050: `package.py` doesn't have `--without-gdbm` option (pypy/pypy) Message-ID: <20150522040243.10869.20300@app07.ash-private.bitbucket.org> New issue 2050: `package.py` doesn't have `--without-gdbm` option https://bitbucket.org/pypy/pypy/issue/2050/packagepy-doesnt-have-without-gdbm-option posita: I'm trying to package PyPy without gdbm. `package.py` recommends using the `--without-gdbm` option to suppress the error. ```sh % ./pypy-c pypy/tool/release/package.py --override_pypy_c ./pypy-c lib_pypy/__pycache__/_cffi__gc4433c0bxb981b228.c:53:22: fatal error: gdbm.h: No such file or directory #include "gdbm.h" ^ compilation terminated. Traceback (most recent call last): File "/app_main.py", line 75, in run_toplevel File "/app_main.py", line 588, in run_it File "", line 1, in File "/tmp/build/pypy-2.5.1-src/lib_pypy/gdbm.py", line 69, in raise ImportError('%s: %s' %(e.__class__.__name__, e)) ImportError: VerificationError: CompileError: command 'cc' failed with exit status 1 Building gdbm bindings failed. You can either install development headers package or add --without-gdbm option to skip packaging binary CFFI extension. ... % echo $? 255 ``` But you can't use it: ```sh % ./pypy-c pypy/tool/release/package.py --override_pypy_c ./pypy-c --without-gdbm usage: package.py [-h] [--without-tk] [--without-cffi] [--nostrip] [--rename_pypy_c PYPY_C] [--archive-name NAME] [--builddir BUILDDIR] [--targetdir TARGETDIR] [--override_pypy_c OVERRIDE_PYPY_C] ... package.py: error: unrecognized arguments: --without-gdbm ``` It looks like only `tk` and `cffi` can be excluded. From issues-reply at bitbucket.org Sun May 24 08:53:15 2015 From: issues-reply at bitbucket.org (LEI WANG) Date: Sun, 24 May 2015 06:53:15 -0000 Subject: [pypy-issue] Issue #2051: PyPy 'super' object has no attribute .... (pypy/pypy) Message-ID: <20150524065315.28084.93577@app13.ash-private.bitbucket.org> New issue 2051: PyPy 'super' object has no attribute .... https://bitbucket.org/pypy/pypy/issue/2051/pypy-super-object-has-no-attribute LEI WANG: I thinks this is a bug with PyPy. Initially, my codes works very well with Python3 compiler. However when I run the my codes by pypy:


super(matrixArrayLists, self).clear()

the super class is type object 'list' Wangs-MacBook-Pro:PyMatrix wangyi$ /Users/wangyi/pypy3-2.4.0-osx64/bin/pypy3 matrixArray.py Traceback (most recent call last): File "matrixArray.py", line 1840, in [['300', '301', '302'], ['310', '311', '312'], ['320', '321', '322']] File "matrixArray.py", line 1643, in __init__ super(matrixArrayNum, self).__init__(*args, **hints) File "matrixArray.py", line 404, in __init__ self.setUp( args[0], self.r, self.c, self.ori_mem ) File "matrixArray.py", line 777, in setUp self.clear() File "matrixArray.py", line 763, in clear super(matrixArrayLists, self).clear() AttributeError: 'super' object has no attribute 'clear' Can anybody show me how to resolve this annoying problem. B.T.W, I am new to pypy and want to use pip3 install some packages like statistics in MacOS. The issue is no latest 'pip3' available for my curl, where those available are too old for python2. Is there anyone show me how to use curl -O http to download 'pip3' AND use PyPy + pip3 to install new packages to Pypy compiler? From issues-reply at bitbucket.org Tue May 26 03:59:45 2015 From: issues-reply at bitbucket.org (magxx) Date: Tue, 26 May 2015 01:59:45 -0000 Subject: [pypy-issue] Issue #2052: Regex module memory leak/crash (pypy/pypy) Message-ID: <20150526015945.1727.15879@app03.ash-private.bitbucket.org> New issue 2052: Regex module memory leak/crash https://bitbucket.org/pypy/pypy/issue/2052/regex-module-memory-leak-crash magxx: While using the [regex](https://pypi.python.org/pypi/regex/2015.05.10) module when parsing a lot of data (I have ~1GB of lines) I've notice that at a certain point the code balloons in memory usage to about 200MB/s. I highly suspect it has something to do with regex.finditer() as if I have that line of code the memory leak will occur. When parsing a small 30MB file this issue did not get a chance to arise. The code looks like: ``` #!python int_group_test = special_end_regex.search(string) if int_group_test: new_string = string[:int_group_test.start()] last_splitter = [m.end() for m in dash_regex.finditer(new_string)] ``` I have tried both 32 and 64 bit versions of PyPy with the same result. If the re module is used instead then this problem does not occur. I also used CPython with regex and re and both succeed without any such memory leaks. From issues-reply at bitbucket.org Tue May 26 05:45:41 2015 From: issues-reply at bitbucket.org (dmw) Date: Tue, 26 May 2015 03:45:41 -0000 Subject: [pypy-issue] Issue #2053: lib_pypy/gdbm.py: package.py produces binary on OS X with hard-coded path (pypy/pypy) Message-ID: <20150526034541.10315.95270@app04.ash-private.bitbucket.org> New issue 2053: lib_pypy/gdbm.py: package.py produces binary on OS X with hard-coded path https://bitbucket.org/pypy/pypy/issue/2053/lib_pypy-gdbmpy-packagepy-produces-binary dmw: Prior to CFFI 1.0, gdbm.py would be compiled on first import of the module on OS X, causing either a descriptive exception or a successful compilation against the user's installed version. However, OS X does not ship with GDBM, one must install if from Homebrew (/usr/local/lib), MacPorts (/opt/local/lib), pkgsrc (/usr/pkg/lib) or one of the various custom binaries around. A subsequent run of package.py will produce a gdbm.so with a load command hard-wired to the path to GDBM on the build machine. Perhaps consider disabling static compilation of GDBM on OS X? I think the remaining alternative is to require a specific GDBM distribution, or bundle GDBM with PyPy, which probably presents some fun licensing issue. From issues-reply at bitbucket.org Wed May 27 15:07:26 2015 From: issues-reply at bitbucket.org (enomad) Date: Wed, 27 May 2015 13:07:26 -0000 Subject: [pypy-issue] Issue #2054: Add the end of ast node to parser. (pypy/pypy) Message-ID: <20150527130726.1274.61493@app10.ash-private.bitbucket.org> New issue 2054: Add the end of ast node to parser. https://bitbucket.org/pypy/pypy/issue/2054/add-the-end-of-ast-node-to-parser enomad: Hi. I want to do some contribution to [rope library](https://github.com/python-rope/rope). As I know it is the only library for code refactoring for python. To have ability to do code changes AST must have the offset of the end of statement. Now it is implemented by [ad-hoc](https://github.com/python-rope/rope/blob/master/rope/refactor/patchedast.py) and cant parse many of python sources. I want to implement this feature on existing parser, and probably take pypy is good idea. I have already added to Python.asdl extra attributes, created [script](https://gist.github.com/enomado/f7c1e6702ae2fb03156c) to test my changes. Now I'm adding to [astbuilder](https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/astbuilder.py) something like ``` #!python node = traverse(value_child) return ast.Assign(targets, value_expr, stmt.lineno, stmt.column, node.lineno, node.column+len(node.value)) ``` **And now i want to ask for advice.** 1. Should I do standalone fork of pypy's parser OR it can be merged to pypy ? 2. My be I'm doing something needless ?