From issues-reply at bitbucket.org Wed Nov 1 14:11:39 2017 From: issues-reply at bitbucket.org (David Naylor) Date: Wed, 01 Nov 2017 18:11:39 +0000 (UTC) Subject: [pypy-issue] Issue #2694: [patch] ctypes.CDLL: implement handle argument (pypy/pypy) Message-ID: <20171101181139.13332.29965@celery-worker-108.ash1.bb-inf.net> New issue 2694: [patch] ctypes.CDLL: implement handle argument https://bitbucket.org/pypy/pypy/issues/2694/patch-ctypescdll-implement-handle-argument David Naylor: PyPy internally didn't implement the handle argument (or CDLL._handle property). The oversight was likely due to CPython reaching into the internals of the CDLL library from the _ctypes.so code. The attached patch implements handle by extending RPython's libffi.CDLL to use the handle if provided (otherwise using dlopen to get the handle). In turn _rawffi.alt.CDLL is extended to pass handle through from ctypes to libffi. A default value of 0 is used (instead of None) as 0 is the equivalent of NULL and is the error condition from dlopen. The attached patch fixes both PyPy and PyPy3. This fixes the rtld_default_lib code in ll2types on FreeBSD. From issues-reply at bitbucket.org Wed Nov 1 14:15:25 2017 From: issues-reply at bitbucket.org (David Naylor) Date: Wed, 01 Nov 2017 18:15:25 +0000 (UTC) Subject: [pypy-issue] Issue #2695: [patch] fail early in ll2types for RTLD code (pypy/pypy) Message-ID: <20171101181525.26183.52397@celery-worker-107.ash1.bb-inf.net> New issue 2695: [patch] fail early in ll2types for RTLD code https://bitbucket.org/pypy/pypy/issues/2695/patch-fail-early-in-ll2types-for-rtld-code David Naylor: When looking up the dl* functions from the rtld_default_lib, instead of using the helper and falling through to the standard library, directly lookup the function and fail if not found. Failure here is correct as rtld_default_lib is required to provide the specified functions. Also, fix the name of the library: the dl* functions are provided by elf-ld.so.1. From issues-reply at bitbucket.org Wed Nov 1 14:20:58 2017 From: issues-reply at bitbucket.org (David Naylor) Date: Wed, 01 Nov 2017 18:20:58 +0000 (UTC) Subject: [pypy-issue] Issue #2696: [patch] fix various tests on FreeBSD (pypy/pypy) Message-ID: <20171101182058.34573.18628@celery-worker-107.ash1.bb-inf.net> New issue 2696: [patch] fix various tests on FreeBSD https://bitbucket.org/pypy/pypy/issues/2696/patch-fix-various-tests-on-freebsd David Naylor: Enable tests that now run on FreeBSD: - termios - pyrepl (and fix skipif on 'freebsd', instead of the more limited case 'kfreebsd') Mark tests as xfail on FreeBSD: - _vmprof.test_get_profile_path Sundry: - test_recompile: libc++ defines char16_t and char32_t for __cplusplus < 201103 From issues-reply at bitbucket.org Wed Nov 1 14:25:09 2017 From: issues-reply at bitbucket.org (David Naylor) Date: Wed, 01 Nov 2017 18:25:09 +0000 (UTC) Subject: [pypy-issue] Issue #2697: [patch] fix compilation on FreeBSD (pypy/pypy) Message-ID: <20171101182509.39870.69752@celery-worker-108.ash1.bb-inf.net> New issue 2697: [patch] fix compilation on FreeBSD https://bitbucket.org/pypy/pypy/issues/2697/patch-fix-compilation-on-freebsd David Naylor: - cpyext: make 'darwin' the fall-through case to define (compile|link)_extra as None. Fixes use-before-define error - rvmprof: - on FreeBSD PyPy needs to link to libunwind - fix missing ';' in statement - indicate unwind functions only need to support local (makes linking easier on FreeBSD) From issues-reply at bitbucket.org Tue Nov 7 04:28:07 2017 From: issues-reply at bitbucket.org (Edward Beech) Date: Tue, 07 Nov 2017 09:28:07 +0000 (UTC) Subject: [pypy-issue] Issue #2698: Suspected memory leak with pysnmp==4.4.1 on PyPy 5.9 only (Python seems fine) (pypy/pypy) Message-ID: <20171107092807.12403.74459@celery-worker-106.ash1.bb-inf.net> New issue 2698: Suspected memory leak with pysnmp==4.4.1 on PyPy 5.9 only (Python seems fine) https://bitbucket.org/pypy/pypy/issues/2698/suspected-memory-leak-with-pysnmp-441-on Edward Beech: The code to reproduce is fairly simple- obviously you'll need PyPy 5.9 installed first as well as pysnmp==4.4.1. ``` #!python from pysnmp.hlapi import SnmpEngine, UdpTransportTarget, ContextData, ObjectType, ObjectIdentity, getCmd, UsmUserData, usmHMACSHAAuthProtocol, usmAesCfb128Protocol ITERATIONS = 65536 for i in range(0, ITERATIONS): snmp_engine = SnmpEngine() context_data = ContextData() errorIndication, errorStatus, errorIndex, varBinds = next( getCmd( snmp_engine, UsmUserData( userName='some_username', authKey='some_auth_key', privKey='some_priv_key, authProtocol=usmHMACSHAAuthProtocol, privProtocol=usmAesCfb128Protocol, ), UdpTransportTarget( ('some_host', 161), timeout=5, retries=2, ), context_data, ObjectType(ObjectIdentity('.1.3.6.1.2.1.1.5.0')) ) ) print '{0}/{1} - {2}'.format(i + 1, ITERATIONS, varBinds) del snmp_engine del context_data ``` Under PyPy 5.9 memory use steadily increases until (in my experience) MacOS crashes; in Python however, all seems fine. I've also raised an issue on the [PySNMP Github page.](https://github.com/etingof/pysnmp/issues/103) From issues-reply at bitbucket.org Thu Nov 9 16:01:56 2017 From: issues-reply at bitbucket.org (Bruno Oliveira) Date: Thu, 09 Nov 2017 21:01:56 +0000 (UTC) Subject: [pypy-issue] Issue #2699: warnings.warn fails with non-ascii unicode strings on PyPy2 5.9.0 (pypy/pypy) Message-ID: <20171109210156.11721.76140@celery-worker-109.ash1.bb-inf.net> New issue 2699: warnings.warn fails with non-ascii unicode strings on PyPy2 5.9.0 https://bitbucket.org/pypy/pypy/issues/2699/warningswarn-fails-with-non-ascii-unicode Bruno Oliveira: Hi, `warnings.warn` in recent versions breaks when passed `non-ascii` unicode on Windows: ```python # -*- coding: utf8 -*- import warnings warnings.warn(u"??") ``` Running this produces this output: ``` C:\pytest\.pypy\bin\pypy.exe C:/pytest/.tmp/test_pypy_unicode.py Traceback (most recent call last): File "C:/pytest/.tmp/test_pypy_unicode.py", line 3, in warnings.warn(u"??") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) ``` I'm not sure in which version this started to break, but we detected this on the pytest's test suite when a test started to break all of sudden. [Here's a link](https://ci.appveyor.com/project/pytestbot/pytest/build/1.0.3355/job/1sfgibpuk38ol3i4) to one of the AppVeyor failures. Interestingly, running the same code under CPython does not produce **any** output and returns zero to the OS. But if we change the string to something `ascii` compatible, than both CPython and PyPy print the correct output: ``` pypy .tmp\test_pypy_unicode.py .tmp\test_pypy_unicode.py:4: UserWarning: foo warnings.warn('foo') ``` ``` python.exe .tmp\test_pypy_unicode.py .tmp\test_pypy_unicode.py:4: UserWarning: foo warnings.warn('foo') ``` **PyPy2 version info** ``` pypy --version Python 2.7.13 (c2437cf9b7f1, Sep 24 2017, 17:23:53) [PyPy 5.9.0 with MSC v.1500 32 bit] ``` Thanks for all the hard work! From issues-reply at bitbucket.org Thu Nov 9 21:22:59 2017 From: issues-reply at bitbucket.org (Chris AtLee) Date: Fri, 10 Nov 2017 02:22:59 +0000 (UTC) Subject: [pypy-issue] Issue #2700: slow warmup running Firefox taskgraph generation (pypy/pypy) Message-ID: <20171110022258.34405.48528@celery-worker-109.ash1.bb-inf.net> New issue 2700: slow warmup running Firefox taskgraph generation https://bitbucket.org/pypy/pypy/issues/2700/slow-warmup-running-firefox-taskgraph Chris AtLee: To reproduce: - clone https://hg.mozilla.org/mozilla-central revision 2e4bef09de27 - download https://queue.taskcluster.net/v1/task/dcvqqnj4RkaJGACao955TA/runs/0/artifacts/public/parameters.yml - run `time pypy ./mach taskgraph target -p parameters.yml > /dev/null` this takes about 20s on my system next, modify taskcluster/mach_commands.py so that we duplicate the call to show_taskgraph: ``` diff --git a/taskcluster/mach_commands.py b/taskcluster/mach_commands.py --- a/taskcluster/mach_commands.py +++ b/taskcluster/mach_commands.py @@ -79,16 +79,17 @@ class MachCommands(MachCommandBase): @ShowTaskGraphSubCommand('taskgraph', 'full', description="Show the full taskgraph") def taskgraph_full(self, **options): return self.show_taskgraph('full_task_graph', options) @ShowTaskGraphSubCommand('taskgraph', 'target', description="Show the target task set") def taskgraph_target(self, **options): + self.show_taskgraph('target_task_set', options) return self.show_taskgraph('target_task_set', options) @ShowTaskGraphSubCommand('taskgraph', 'target-graph', description="Show the target taskgraph") def taskgraph_target_taskgraph(self, **options): return self.show_taskgraph('target_task_graph', options) @ShowTaskGraphSubCommand('taskgraph', 'optimized', ``` re-run `mach taskgraph`. This time is takes about 34 seconds. I think this means that the second pass only takes 14 seconds to run. From issues-reply at bitbucket.org Mon Nov 13 04:56:26 2017 From: issues-reply at bitbucket.org (Davide Depau) Date: Mon, 13 Nov 2017 09:56:26 +0000 (UTC) Subject: [pypy-issue] Issue #2701: Future imports not allowed after docstrings (pypy/pypy) Message-ID: <20171113095626.12770.30343@celery-worker-109.ash1.bb-inf.net> New issue 2701: Future imports not allowed after docstrings https://bitbucket.org/pypy/pypy/issues/2701/future-imports-not-allowed-after Davide Depau: The [Python language reference](https://docs.python.org/2/reference/simple_stmts.html#future) clearly states that future statements are allowed after docstrings: > A future statement must appear near the top of the module. The only lines that can appear before a future statement are: > > - the module docstring (if any), > - comments, > - blank lines, and > - other future statements. However PyPy seems not to like it very much. See my pull request to OctoPrint: https://github.com/foosel/OctoPrint/pull/2217 The fact that in some file there is a future import, a docstring and then another future import makes PyPy crash, while CPython accepts it just fine. ``` SyntaxError: __future__ statements must appear at beginning of file ``` Code that triggers it: ```python from __future__ import absolute_import """ [Module docstring] """ from __future__ import absolute_import, division, print_function ``` While this obviously the best code one could write (in fact they merged my PR that fixes it), it still valid and PyPy should accept it. From issues-reply at bitbucket.org Fri Nov 17 04:54:31 2017 From: issues-reply at bitbucket.org (davoud taghawi-nejad) Date: Fri, 17 Nov 2017 09:54:31 +0000 (UTC) Subject: [pypy-issue] Issue #2702: pypy3 5.9.0 not available for maxos64 (pypy/pypy) Message-ID: <20171117095431.9349.58956@celery-worker-109.ash1.bb-inf.net> New issue 2702: pypy3 5.9.0 not available for maxos64 https://bitbucket.org/pypy/pypy/issues/2702/pypy3-590-not-available-for-maxos64 davoud taghawi-nejad: there is no pypy3 5.9.0 available for maxos64. Responsible: mattip From issues-reply at bitbucket.org Tue Nov 21 04:16:11 2017 From: issues-reply at bitbucket.org (Holger Grund) Date: Tue, 21 Nov 2017 09:16:11 +0000 (UTC) Subject: [pypy-issue] Issue #2703: PyPy3 bitfields reversed from expected value (pypy/pypy) Message-ID: <20171121091611.39141.59764@celery-worker-110.ash1.bb-inf.net> New issue 2703: PyPy3 bitfields reversed from expected value https://bitbucket.org/pypy/pypy/issues/2703/pypy3-bitfields-reversed-from-expected Holger Grund: Bitfields in BigendianStructures are not allocated in the same way as for CPython on x86-64 Linux at least. Per ABI big-endian bitfields should be allocated from high to low bit, but PyPy?s ctypes doesn?t do that. Observe: ``` #!python import ctypes class Foo(ctypes.BigEndianStructure): _fields_ = ( ('first', ctypes.c_uint8, 4), ('second', ctypes.c_uint8, 4)) f = Foo(first=0,second=15) print('%r' % list(bytes(f))) ``` PyPy3 prints [240]. CPython prints [15]. From issues-reply at bitbucket.org Tue Nov 28 11:00:46 2017 From: issues-reply at bitbucket.org (Carl Friedrich Bolz-Tereick) Date: Tue, 28 Nov 2017 16:00:46 +0000 (UTC) Subject: [pypy-issue] Issue #2704: Undefined behavior in RPython via the C backend (pypy/pypy) Message-ID: <20171128160046.4176.12813@celery-worker-110.ash1.bb-inf.net> New issue 2704: Undefined behavior in RPython via the C backend https://bitbucket.org/pypy/pypy/issues/2704/undefined-behavior-in-rpython-via-the-c Carl Friedrich Bolz-Tereick: We did not completely decide so far whether int-addition (and other ops) in RPython must behave a) by wrapping around or b) by having undefined behavior on overflow. Right now, the C backend and parts of the JIT implements b). However, we definitely have code where we use int operations that overflow and we expect a), most notably a lot of hash computations (eg ``W_TupleObject._descr_hash_*``). This has the potential (maybe unlikely though?) of causing miscompilation of PyPy at any point in the future when GCC (or the JIT) gets smarter about reasoning about ints.