From issues-reply at bitbucket.org Sun May 1 05:00:30 2016 From: issues-reply at bitbucket.org (Armin Rigo) Date: Sun, 01 May 2016 09:00:30 -0000 Subject: [pypy-issue] Issue #2287: __del__ on subclasses of some built-in types can crash (pypy/pypy) Message-ID: <20160501090030.79822.12724@celery-worker-102.ash1.bb-inf.net> New issue 2287: __del__ on subclasses of some built-in types can crash https://bitbucket.org/pypy/pypy/issues/2287/__del__-on-subclasses-of-some-built-in Armin Rigo: This crashes PyPy: ``` #!python import array, gc class X(array.array): def __del__(self): global saved saved = self while True: X('i', [2,3,4]) gc.collect() saved[0] += 1 ``` The issue is that when we have both an app-level and an interp-level ``__del__``, and the interp-level one is supposed to be a lightweight finalizer, we call the interp-level one always after calling the app-level one. But the lightweight finalizer of classes like W_Array is written with this basic property in mind: after it is called, there should be no more references to the object. A proper fix is involved; I suppose we should give a try again to the ``gc-del`` branch. From issues-reply at bitbucket.org Sun May 1 06:15:23 2016 From: issues-reply at bitbucket.org (David MacIver) Date: Sun, 01 May 2016 10:15:23 -0000 Subject: [pypy-issue] Issue #2288: OperationError with an error in a setprofile function at process exit (pypy/pypy) Message-ID: <20160501101523.57787.16695@celery-worker-102.ash1.bb-inf.net> New issue 2288: OperationError with an error in a setprofile function at process exit https://bitbucket.org/pypy/pypy/issues/2288/operationerror-with-an-error-in-a David MacIver: If I run the following file: ```python import sys t = [0] def ca(f, v, g): if v == 'call': t.pop() def o(): raise ValueError() sys.setprofile(ca) o() ``` Gives the following output: ``` debug: OperationError: debug: operror-type: IndexError debug: operror-value: list index out of range ``` While it should probably (and CPython does) print a ValueError plus a stack trace. From issues-reply at bitbucket.org Sun May 1 23:19:56 2016 From: issues-reply at bitbucket.org (Tristan Seligmann) Date: Mon, 02 May 2016 03:19:56 -0000 Subject: [pypy-issue] Issue #2289: Incorrect Unicode normalization (pypy/pypy) Message-ID: <20160502031956.47058.93484@celery-worker-102.ash1.bb-inf.net> New issue 2289: Incorrect Unicode normalization https://bitbucket.org/pypy/pypy/issues/2289/incorrect-unicode-normalization Tristan Seligmann: ``` mithrandi at lorien ~> python -V Python 2.7.11+ mithrandi at lorien ~> python -c 'from unicodedata import normalize; print repr(normalize("NFC", u"\uafb8\u11a7"))' u'\uafb8\u11a7' mithrandi at lorien ~> pypy -V Python 2.7.10 (5.1+dfsg-1, Apr 30 2016, 13:28:43) [PyPy 5.1.0 with GCC 5.3.1 20160424] mithrandi at lorien ~> pypy -c 'from unicodedata import normalize; print repr(normalize("NFC", u"\uafb8\u11a7"))' u'\uafb8' ``` Happens with PyPy 5.0.0 as well, at least (I didn't try any other versions). As far as I can tell, the PyPy normalization is wrong here and the CPython one is correct. From issues-reply at bitbucket.org Tue May 3 10:42:20 2016 From: issues-reply at bitbucket.org (FredStober) Date: Tue, 03 May 2016 14:42:20 -0000 Subject: [pypy-issue] Issue #2290: segfault in pypy 2.2.1 (pypy/pypy) Message-ID: <20160503144220.37766.9933@celery-worker-101.ash1.bb-inf.net> New issue 2290: segfault in pypy 2.2.1 https://bitbucket.org/pypy/pypy/issues/2290/segfault-in-pypy-221 FredStober: Hi, I have another code that *sometimes* crashes with a segfault. I've reduced the problem to a small test program. It crashes reliably with my pypy 2.2.1 that is bundled with Ubuntu 14.04.4 LTS (Python 2.7.3 (2.2.1+dfsg-1ubuntu0.3, Sep 30 2015, 15:18:40); [PyPy 2.2.1 with GCC 4.8.4] on linux2): ``` #!python class Wrapper(object): pass while True: lines = [] for i in range(100000): # larger numbers => larger crash probability (originally read from a file) lines.append('a=a') for line in lines: map(str.strip, line.split('=', 1)) tmp = {'1': None, '2': None, '3': None, '4': None, '5': None, '6': None, Wrapper(): None} for jobNum in range(2): # len = 16! map(tmp.get, tmp.keys()) ``` I've been unable to reproduce the problem with PyPy 5.2.0-alpha0 (Apr 22 2016, 22:07:05) [357a144f9ea1]. However the code seems to be very sensitive to the memory layout (after changing to range(15), the problem disappears). From issues-reply at bitbucket.org Wed May 4 02:33:58 2016 From: issues-reply at bitbucket.org (Sandeep Srinivasa) Date: Wed, 04 May 2016 06:33:58 -0000 Subject: [pypy-issue] Issue #2291: Please create snap packages (pypy/pypy) Message-ID: <20160504063358.17011.5505@celery-worker-101.ash1.bb-inf.net> New issue 2291: Please create snap packages https://bitbucket.org/pypy/pypy/issues/2291/please-create-snap-packages Sandeep Srinivasa: https://blog.mozilla.org/futurereleases/2016/04/21/firefox-default-browser-for-linux-users-ubuntu-new-snap-format-coming-soon/ ``` #!text Ubuntu version 16.04 will include the introduction of the snap infrastructure. With the snap format, we will be able to continually optimize Firefox on Ubuntu. Like our rapid engineering release cycle, snap format will allow us to provide Linux users the most up-to-date features, in particular security patches, even after major Operating System ship dates. ``` Snap packages are a new, secure, independent way of distributing software. Mozilla has already committed to release snap packages according to its own release cycle. Remember snap packages do not conflict with distro installed packages (of the same name). Additional resources * https://developer.ubuntu.com/en/snappy/build-apps/ * https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ * http://webchat.freenode.net/?channels=snappy Responsible: arigo From issues-reply at bitbucket.org Thu May 5 13:41:14 2016 From: issues-reply at bitbucket.org (Tim Smith) Date: Thu, 05 May 2016 17:41:14 -0000 Subject: [pypy-issue] Issue #2292: 5.1.1 source tarball is really 5.1.0? (pypy/pypy) Message-ID: <20160505174114.24099.90154@celery-worker-103.ash1.bb-inf.net> New issue 2292: 5.1.1 source tarball is really 5.1.0? https://bitbucket.org/pypy/pypy/issues/2292/511-source-tarball-is-really-510 Tim Smith: https://bitbucket.org/pypy/pypy/downloads/pypy-5.1.1-src.tar.bz2 has `PYPY_VERSION` defined to 5.1.0 in pypy/module/cpyext/include/patchlevel.h; pypy/module/sys/version.p has `PYPY_VERSION = (5, 1, 0, "final", 0)`. Does this need to be reissued? From issues-reply at bitbucket.org Sat May 7 16:00:15 2016 From: issues-reply at bitbucket.org (Jean-Louis Fuchs) Date: Sat, 07 May 2016 20:00:15 -0000 Subject: [pypy-issue] Issue #2293: Using codecs.open certian input causes a seek to crash (pypy/pypy) Message-ID: <20160507200015.13981.27473@celery-worker-101.ash1.bb-inf.net> New issue 2293: Using codecs.open certian input causes a seek to crash https://bitbucket.org/pypy/pypy/issues/2293/using-codecsopen-certian-input-causes-a Jean-Louis Fuchs: This is based on a [chardet-testfile](https://github.com/chardet/chardet/blob/master/tests/EUC-KR/jely.pe.kr.xml) I used code shrinker to create minimal example. To reproduce the problem: 1. Open the file with codecs.open 2. Read it with readlines 3. Then seek Example code and the problemdata is attached. This is the error: ``` #!bash $> python pypybug.py ???? Traceback (most recent call last): File "pypybug.py", line 6, in f.seek(0) File "/home/ganwell/.pyenv/versions/pypy-5.1/lib-python/2.7/codecs.py", line 709, in seek self.writer.reset() IOError: File not open for writing ``` And the testcode: ``` #!python import codecs with codecs.open("problemdata", "r", encoding="EUC-KR") as f: for x in f.readlines(): print(x) f.seek(0) ``` From issues-reply at bitbucket.org Tue May 10 13:34:40 2016 From: issues-reply at bitbucket.org (Eliot Moss) Date: Tue, 10 May 2016 17:34:40 -0000 Subject: [pypy-issue] Issue #2296: building on cygwin: base/logging.h not found (pypy/pypy) Message-ID: <20160510173440.12099.54036@celery-worker-101.ash1.bb-inf.net> New issue 2296: building on cygwin: base/logging.h not found https://bitbucket.org/pypy/pypy/issues/2296/building-on-cygwin-base-loggingh-not-found Eliot Moss: Friends -- I am trying to build pypy from source out of the box under cygwin (32 bit). After changing to use the cygwin python (2.7) for the build (instead of pypy, which is not installed yet) in rpython/bin/rpython, I encounter a roadblock with the vmprof part of the system wanting in #include base/logging.h, which does not seem to exist. It is supposed to define a macro or function called RAW_LOG. I would be grateful for any hints as to how to proceed ... Eliot Moss From issues-reply at bitbucket.org Wed May 11 11:41:37 2016 From: issues-reply at bitbucket.org (Eliot Moss) Date: Wed, 11 May 2016 15:41:37 -0000 Subject: [pypy-issue] Issue #2297: translation failure when building from source under cygwin (pypy/pypy) Message-ID: <20160511154137.70279.1713@celery-worker-102.ash1.bb-inf.net> New issue 2297: translation failure when building from source under cygwin https://bitbucket.org/pypy/pypy/issues/2297/translation-failure-when-building-from Eliot Moss: With the patch previously posted in another issue, I am able to get pretty far through the build on a system running the current Cygwin. It gets through annotate and rtype_lltype and almost immediately after that (before any other output, with --verbose turned on), it gets this: [translation:ERROR] ValueError: > is not in list I've played some with pypy/module/__builtin__/inter_classobj.py, thinking that the issue might be mismatch between a name like W_InstanceObject and the string given in the TypeDef ("instance"). I've done a number of attempted builds, and I've seen several different missing FunctionDesc errors, all about cpyext_tp_setattro_XXX where XXX is some class. I'd be grateful for hints as to how to fix this, or direction to some previous revision where things work better. (The nightly builds showed no revisions for linux 32 trunk (which seemed most relevant for a cygwin build) that had NO failures. I picked the one with only one failure, a failure that did not seem relevant to what I am trying to do, namely e61e2f4a32fa.) As a side note, I wonder about whether you would be willing to arrange for regular testing of cygwin builds. Regards -- Eliot Moss PS -- What I am trying to do is to get organized for having some summer students work on retargeting pypy to a new target, the Mu Micro Virtual Machine (a project you can find on GitHub). From issues-reply at bitbucket.org Wed May 11 22:02:48 2016 From: issues-reply at bitbucket.org (Eliot Moss) Date: Thu, 12 May 2016 02:02:48 -0000 Subject: [pypy-issue] Issue #2298: cygwin build fails for release-5.1.1 (pypy/pypy) Message-ID: <20160512020248.29679.83824@celery-worker-103.ash1.bb-inf.net> New issue 2298: cygwin build fails for release-5.1.1 https://bitbucket.org/pypy/pypy/issues/2298/cygwin-build-fails-for-release-511 Eliot Moss: For the record, with the small patch previously submitted in issue [2296](https://bitbucket.org/pypy/pypy/issues/2296/building-on-cygwin-base-loggingh-not-found), the build gets through to the point where it tries to compile the generated C code. This failed, and in order to see if there was more than one problem, I did `make -k` and let the good compilations complete, and then `make -k` again to offer this list of problems: gcc -O3 -fomit-frame-pointer -Wall -Wno-unused -fvisibility=hidden -DPy_BUILD_CORE -DPy_BUILD_CORE -DPYPY_CPU_HAS_STANDARD_PRECISION -DPYPY_X86_CHECK_SSE2 -msse2 -mfpmath=sse -DPy_BUILD_CORE -o data_rpython_jit_metainterp.o -c data_rpython_jit_metainterp.c -I"/home/moss/projects/pypy/rpython"/translator/c -I"/home/moss/projects/pypy/rpython"/../pypy/module/_multibytecodec -I"/home/moss/projects/pypy/rpython"/rlib/rvmprof/src -I"/home/moss/projects/pypy/rpython"/../pypy/module/cpyext/include -I.. -I"/home/moss/projects/pypy/rpython"/../pypy/module/operator -I"/home/moss/projects/pypy/rpython"/../pypy/module/_cffi_backend/src data_rpython_jit_metainterp.c:52439:2: error: ?crypt? undeclared here (not in a function) crypt, /* 1344 */ ^ Makefile:746: recipe for target 'data_rpython_jit_metainterp.o' failed make: *** [data_rpython_jit_metainterp.o] Error 1 gcc -O3 -fomit-frame-pointer -Wall -Wno-unused -fvisibility=hidden -DPy_BUILD_CORE -DPy_BUILD_CORE -DPYPY_CPU_HAS_STANDARD_PRECISION -DPYPY_X86_CHECK_SSE2 -msse2 -mfpmath=sse -DPy_BUILD_CORE -o nonfuncnodes_19.o -c nonfuncnodes_19.c -I"/home/moss/projects/pypy/rpython"/translator/c -I"/home/moss/projects/pypy/rpython"/../pypy/module/_multibytecodec -I"/home/moss/projects/pypy/rpython"/rlib/rvmprof/src -I"/home/moss/projects/pypy/rpython"/../pypy/module/cpyext/include -I.. -I"/home/moss/projects/pypy/rpython"/../pypy/module/operator -I"/home/moss/projects/pypy/rpython"/../pypy/module/_cffi_backend/src nonfuncnodes_19.c:33868:11: error: ?crypt? undeclared here (not in a function) ((Signed)crypt), /* 5 */ ^ Makefile:746: recipe for target 'nonfuncnodes_19.o' failed make: *** [nonfuncnodes_19.o] Error 1 gcc -O3 -fomit-frame-pointer -Wall -Wno-unused -fvisibility=hidden -DPy_BUILD_CORE -DPy_BUILD_CORE -DPYPY_CPU_HAS_STANDARD_PRECISION -DPYPY_X86_CHECK_SSE2 -msse2 -mfpmath=sse -DPy_BUILD_CORE -o ../module_cache/module_23.o -c ../module_cache/module_23.c -I"/home/moss/projects/pypy/rpython"/translator/c -I"/home/moss/projects/pypy/rpython"/../pypy/module/_multibytecodec -I"/home/moss/projects/pypy/rpython"/rlib/rvmprof/src -I"/home/moss/projects/pypy/rpython"/../pypy/module/cpyext/include -I.. -I"/home/moss/projects/pypy/rpython"/../pypy/module/operator -I"/home/moss/projects/pypy/rpython"/../pypy/module/_cffi_backend/src ../module_cache/module_23.c: In function ?_cffi_init_home?: ../module_cache/module_23.c:398:5: error: unknown type name ?Dl_info? Dl_info info; ^ ../module_cache/module_23.c:400:9: warning: implicit declaration of function ?dladdr? [-Wimplicit-function-declaration] if (dladdr(&_cffi_init, &info) == 0) { ^ ../module_cache/module_23.c:404:22: error: request for member ?dli_fname? in something not a structure or union if (realpath(info.dli_fname, output_home_path) == NULL) { ^ Makefile:746: recipe for target '../module_cache/module_23.o' failed make: *** [../module_cache/module_23.o] Error 1 make: Target 'all' not remade because of errors. So two failures are related to the name 'crypt' and two to other things. I will try an earlier stable release. It would be good to test at least major releases on cygwin if pypy is going to include build support for that platform, even if nightly checks aren't done. Regards - Eliot Moss From issues-reply at bitbucket.org Thu May 12 19:06:11 2016 From: issues-reply at bitbucket.org (Devin Jeanpierre) Date: Thu, 12 May 2016 23:06:11 -0000 Subject: [pypy-issue] Issue #2299: ptest.py --tb native fails with no output when there are application level errors (pypy/pypy) Message-ID: <20160512230611.29828.49996@celery-worker-103.ash1.bb-inf.net> New issue 2299: ptest.py --tb native fails with no output when there are application level errors https://bitbucket.org/pypy/pypy/issues/2299/ptestpy-tb-native-fails-with-no-output Devin Jeanpierre: If I break tests and run `python pytest.py --tb native -s pypy/module/cpyext/` ``` INTERNALERROR> Traceback (most recent call last): INTERNALERROR> File "_pytest/main.py", line 81, in wrap_session INTERNALERROR> doit(config, session) INTERNALERROR> File "_pytest/main.py", line 118, in _main INTERNALERROR> config.hook.pytest_runtestloop(session=session) INTERNALERROR> File "_pytest/core.py", line 377, in __call__ INTERNALERROR> return self._docall(methods, kwargs) INTERNALERROR> File "_pytest/core.py", line 388, in _docall INTERNALERROR> res = mc.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/main.py", line 138, in pytest_runtestloop INTERNALERROR> item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem) INTERNALERROR> File "_pytest/core.py", line 377, in __call__ INTERNALERROR> return self._docall(methods, kwargs) INTERNALERROR> File "_pytest/core.py", line 388, in _docall INTERNALERROR> res = mc.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/runner.py", line 64, in pytest_runtest_protocol INTERNALERROR> runtestprotocol(item, nextitem=nextitem) INTERNALERROR> File "_pytest/runner.py", line 74, in runtestprotocol INTERNALERROR> reports.append(call_and_report(item, "call", log)) INTERNALERROR> File "_pytest/runner.py", line 110, in call_and_report INTERNALERROR> report = hook.pytest_runtest_makereport(item=item, call=call) INTERNALERROR> File "_pytest/main.py", line 162, in call_matching_hooks INTERNALERROR> return hookmethod.pcall(plugins, **kwargs) INTERNALERROR> File "_pytest/core.py", line 381, in pcall INTERNALERROR> return self._docall(methods, kwargs) INTERNALERROR> File "_pytest/core.py", line 388, in _docall INTERNALERROR> res = mc.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/capture.py", line 246, in pytest_runtest_makereport INTERNALERROR> rep = __multicall__.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/skipping.py", line 168, in pytest_runtest_makereport INTERNALERROR> rep = __multicall__.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/runner.py", line 208, in pytest_runtest_makereport INTERNALERROR> longrepr = item.repr_failure(excinfo) INTERNALERROR> File "pypy/tool/pytest/apptest.py", line 62, in repr_failure INTERNALERROR> return super(AppTestFunction, self).repr_failure(excinfo) INTERNALERROR> File "_pytest/python.py", line 581, in repr_failure INTERNALERROR> style=self.config.option.tbstyle) INTERNALERROR> File "_pytest/python.py", line 576, in _repr_failure_py INTERNALERROR> style=style) INTERNALERROR> File "_pytest/main.py", line 388, in _repr_failure_py INTERNALERROR> style=style) INTERNALERROR> File "py/_code/code.py", line 400, in getrepr INTERNALERROR> self.type, INTERNALERROR> AttributeError: 'AppExceptionInfo' object has no attribute 'type' ``` If I fix that by setting self.type to None (dumb fix), it's broken at other levels: ``` INTERNALERROR> Traceback (most recent call last): INTERNALERROR> File "_pytest/main.py", line 81, in wrap_session INTERNALERROR> doit(config, session) INTERNALERROR> File "_pytest/main.py", line 118, in _main INTERNALERROR> config.hook.pytest_runtestloop(session=session) INTERNALERROR> File "_pytest/core.py", line 377, in __call__ INTERNALERROR> return self._docall(methods, kwargs) INTERNALERROR> File "_pytest/core.py", line 388, in _docall INTERNALERROR> res = mc.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/main.py", line 138, in pytest_runtestloop INTERNALERROR> item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem) INTERNALERROR> File "_pytest/core.py", line 377, in __call__ INTERNALERROR> return self._docall(methods, kwargs) INTERNALERROR> File "_pytest/core.py", line 388, in _docall INTERNALERROR> res = mc.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/runner.py", line 64, in pytest_runtest_protocol INTERNALERROR> runtestprotocol(item, nextitem=nextitem) INTERNALERROR> File "_pytest/runner.py", line 74, in runtestprotocol INTERNALERROR> reports.append(call_and_report(item, "call", log)) INTERNALERROR> File "_pytest/runner.py", line 110, in call_and_report INTERNALERROR> report = hook.pytest_runtest_makereport(item=item, call=call) INTERNALERROR> File "_pytest/main.py", line 162, in call_matching_hooks INTERNALERROR> return hookmethod.pcall(plugins, **kwargs) INTERNALERROR> File "_pytest/core.py", line 381, in pcall INTERNALERROR> return self._docall(methods, kwargs) INTERNALERROR> File "_pytest/core.py", line 388, in _docall INTERNALERROR> res = mc.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/capture.py", line 246, in pytest_runtest_makereport INTERNALERROR> rep = __multicall__.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/skipping.py", line 168, in pytest_runtest_makereport INTERNALERROR> rep = __multicall__.execute() INTERNALERROR> File "_pytest/core.py", line 289, in execute INTERNALERROR> res = method(**kwargs) INTERNALERROR> File "_pytest/runner.py", line 208, in pytest_runtest_makereport INTERNALERROR> longrepr = item.repr_failure(excinfo) INTERNALERROR> File "pypy/tool/pytest/apptest.py", line 62, in repr_failure INTERNALERROR> return super(AppTestFunction, self).repr_failure(excinfo) INTERNALERROR> File "_pytest/python.py", line 581, in repr_failure INTERNALERROR> style=self.config.option.tbstyle) INTERNALERROR> File "_pytest/python.py", line 576, in _repr_failure_py INTERNALERROR> style=style) INTERNALERROR> File "_pytest/main.py", line 388, in _repr_failure_py INTERNALERROR> style=style) INTERNALERROR> File "py/_code/code.py", line 402, in getrepr INTERNALERROR> self.traceback[0]._rawentry, INTERNALERROR> AttributeError: 'AppTracebackEntry' object has no attribute '_rawentry' ``` Basically AFAICT the interface is totally not compatible with what pytest is expecting. Workaround: don't use --tb native? From issues-reply at bitbucket.org Sat May 14 07:09:05 2016 From: issues-reply at bitbucket.org (Chi Hsuan Yen) Date: Sat, 14 May 2016 11:09:05 -0000 Subject: [pypy-issue] Issue #2300: PyPy3 2.4.0 OperationError/LookupError with virtualenv and a PATH with non-ASCII characters (pypy/pypy) Message-ID: <20160514110905.7963.95850@celery-worker-103.ash1.bb-inf.net> New issue 2300: PyPy3 2.4.0 OperationError/LookupError with virtualenv and a PATH with non-ASCII characters https://bitbucket.org/pypy/pypy/issues/2300/pypy3-240-operationerror-lookuperror-with Chi Hsuan Yen: ### Description: ### I'm trying to fix a virtualenv issue (https://github.com/pypa/virtualenv/issues/457). All tests on CPython pass and all on PyPy fails. [1] The PyPy2 test is OK on my machine, so I guess it's an Ubuntu issue. The PyPy3 test fails with an OperationError both on Travis CI and my machine: ``` debug: OperationError: debug: operror-type: LookupError debug: operror-value: no codec search functions registered: can't find encoding debug: OperationError: debug: operror-type: AttributeError debug: operror-value: stdout ``` ### Steps to reproduce: ### ``` $ git clone -b encoding-fix https://github.com/yan12125/virtualenv $ cd virtualenv $ pypy3 virtualenv.py ?? ``` The same result appears on Ubuntu 12.04 (Travis CI) [2] and Arch Linux (my machine). ### Additional info: ### PyPy3 version on my machine: ``` $ pypy3 -V Python 3.2.5 (b2091e973da69152b3f928bfaabd5d2347e6df46, Mar 04 2016, 07:08:30) [PyPy 2.4.0 with GCC 5.3.0] ``` And on Travis CI: ``` $ python --version Python 3.2.5 (b2091e973da6, Oct 19 2014, 18:29:55) [PyPy 2.4.0 with GCC 4.6.3] ``` [1] https://travis-ci.org/pypa/virtualenv/builds/130198936 [2] https://travis-ci.org/pypa/virtualenv/jobs/130198943 From issues-reply at bitbucket.org Sat May 14 21:33:47 2016 From: issues-reply at bitbucket.org (Jeff Carpenter) Date: Sun, 15 May 2016 01:33:47 -0000 Subject: [pypy-issue] Issue #2301: Dictionary Bug (pypy/pypy) Message-ID: <20160515013347.18951.82548@celery-worker-102.ash1.bb-inf.net> New issue 2301: Dictionary Bug https://bitbucket.org/pypy/pypy/issues/2301/dictionary-bug Jeff Carpenter: Got this exception when parsing and validating (mostly regex) a bunch of HTML files: ``` #!python Fatal error in cpyext, CPython compatibility layer, calling PyErr_GetExcInfo Either report a bug or consider not using this particular extension RPython traceback: File "pypy_module_cpyext_api.c", line 220317, in PyErr_GetExcInfo File "pypy_module_cpyext_pyerrors.c", line 9771, in PyErr_GetExcInfo File "pypy_module_cpyext_pyobject.c", line 547, in make_ref File "pypy_module_cpyext_pyobject.c", line 1385, in create_ref File "pypy_module_cpyext_pyobject.c", line 4093, in BaseCpyTypedescr_allocate File "pypy_module_cpyext_pyobject.c", line 547, in make_ref File "pypy_module_cpyext_pyobject.c", line 1308, in create_ref File "pypy_module_cpyext_typeobject.c", line 16849, in type_attach File "pypy_module_cpyext_typeobject.c", line 5385, in finish_type_2 File "pypy_module_cpyext_pyobject.c", line 542, in make_ref File "rpython_rtyper_lltypesystem_rdict.c", line 3695, in _ll_dict_setitem_lookup_done__v1888___simple_cal File "rpython_rtyper_lltypesystem_rdict.c", line 11218, in ll_dict_resize__dicttablePtr File "rpython_rtyper_lltypesystem_rdict.c", line 11277, in ll_dict_resize__dicttablePtr File "rpython_memory_gc_incminimark.c", line 2860, in IncrementalMiniMarkGC_external_malloc zsh: segmentation fault (core dumped) ./parse.py html/**/*.html ``` From issues-reply at bitbucket.org Fri May 20 08:17:00 2016 From: issues-reply at bitbucket.org (gzivdo) Date: Fri, 20 May 2016 12:17:00 -0000 Subject: [pypy-issue] Issue #2302: strange behavior with python-daemon and TimedRotatingFileHandler (pypy/pypy) Message-ID: <20160520121700.11503.15456@celery-worker-104.ash1.bb-inf.net> New issue 2302: strange behavior with python-daemon and TimedRotatingFileHandler https://bitbucket.org/pypy/pypy/issues/2302/strange-behavior-with-python-daemon-and gzivdo: This works fine with old pypy 2.x and with python 2.7, but not works with pypy 5.1.2 I am getting error: {code} Traceback (most recent call last): File "./123.py", line 83, in main() File "./123.py", line 43, in main pass IOError: [Errno 9] Bad file descriptor: '' {code} Sample code to reproduce: {code} #!/usr/local/pypy-centos7-x64/bin/pypy import daemon, signal, time, logging, os, sys, lockfile from logging.handlers import TimedRotatingFileHandler log = 'foo.log' def main(): while True: with os.popen('/usr/bin/lzcat some_test_file.lzma') as f: print f for line in f: pass logFormatter = logging.Formatter('%(asctime)s - %(levelname)s - %(message)s') logger = logging.getLogger() logger.setLevel(logging.DEBUG) fh = logging.FileHandler(log) #fh = TimedRotatingFileHandler(log, when="d", interval=1, backupCount=10) fh.setFormatter(logFormatter) logger.addHandler(fh) context = daemon.DaemonContext( files_preserve = [ fh.stream, ], stdout = fh.stream, #no formatting stderr = fh.stream, ) with context: main() {code} It stop working because of "from logging.handlers import TimedRotatingFileHandle", if i comment it - it works fine. From issues-reply at bitbucket.org Fri May 20 08:18:16 2016 From: issues-reply at bitbucket.org (Naoki INADA) Date: Fri, 20 May 2016 12:18:16 -0000 Subject: [pypy-issue] Issue #2303: struct.unpack() is 15x~ slower on bytearray than bytes. (pypy/pypy) Message-ID: <20160520121816.14011.53008@celery-worker-101.ash1.bb-inf.net> New issue 2303: struct.unpack() is 15x~ slower on bytearray than bytes. https://bitbucket.org/pypy/pypy/issues/2303/structunpack-is-15x-slower-on-bytearray Naoki INADA: PyPy 5.1.1 on Mac See this snippets: https://bitbucket.org/snippets/methane/5K6qB From issues-reply at bitbucket.org Sun May 22 05:18:38 2016 From: issues-reply at bitbucket.org (squeaky) Date: Sun, 22 May 2016 09:18:38 -0000 Subject: [pypy-issue] Issue #2304: time.get_clock_info(name) missing (pypy/pypy) Message-ID: <20160522091838.9304.28130@celery-worker-104.ash1.bb-inf.net> New issue 2304: time.get_clock_info(name) missing https://bitbucket.org/pypy/pypy/issues/2304/timeget_clock_info-name-missing squeaky: ``` #!python Python 3.3.5 (d463dd98e6a6, May 22 2016, 02:07:30) [PyPy 5.2.0-alpha0 with GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``the way to avoid a workaround is to introduce a stronger workaround somewhere else'' >>>> import time >>>> time.get_clock_info Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'get_clock_info' >>>> ``` From issues-reply at bitbucket.org Sun May 22 07:08:55 2016 From: issues-reply at bitbucket.org (squeaky) Date: Sun, 22 May 2016 11:08:55 -0000 Subject: [pypy-issue] Issue #2305: asyncio benchmarks from uvloop project slower on PyPy3 than on CPython (pypy/pypy) Message-ID: <20160522110855.57558.54799@celery-worker-102.ash1.bb-inf.net> New issue 2305: asyncio benchmarks from uvloop project slower on PyPy3 than on CPython https://bitbucket.org/pypy/pypy/issues/2305/asyncio-benchmarks-from-uvloop-project squeaky: http://magic.io/blog/uvloop-blazing-fast-python-networking/ ``` PyPy3 nightly server & client ----------------------------- 1KiB pypy3 client.py --num 10000 --workers 10 --msize 1000 will connect to: ('127.0.0.1', 25000) Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages 100000 in 27.98492121696472 3573.352921907783 requests/sec 10KiB pypy3 client.py --num 10000 --workers 10 --msize 10000 will connect to: ('127.0.0.1', 25000) Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages 100000 in 42.212645053863525 2368.9583979492295 requests/sec 100 KiB pypy3 client.py --num 10000 --workers 10 --msize 100000 will connect to: ('127.0.0.1', 25000) Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages 100000 in 231.10237002372742 432.7086736052639 requests/sec CPython 3.5 server & client --------------------------- 1KiB /usr/bin/python3.5 client.py --num 10000 --workers 10 --msize 1000 will connect to: ('127.0.0.1', 25000) Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages 100000 in 24.576037406921387 4069.004223269812 requests/sec 10KiB /usr/bin/python3.5 client.py --num 10000 --workers 10 --msize 10000 will connect to: ('127.0.0.1', 25000) Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages 100000 in 20.850675344467163 4796.007723871425 requests/sec 100KiB /usr/bin/python3.5 client.py --num 10000 --workers 10 --msize 100000 will connect to: ('127.0.0.1', 25000) Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages Sending 10000 messages 100000 in 52.21383476257324 1915.2012192691843 requests/sec ``` Steps to reproduce: I edited the benchmarks from https://github.com/MagicStack/uvloop/tree/master/examples/bench to not use `async` and `await` keywords ``` 1. Get the latest nightly of pypy3 2. If you are running a system that is not exactly like Ubuntu 14.04 LTS * `ldd bin/pypy3` to lookup broken symbols and libraries, * you can get openssl from http://packages.ubuntu.com/trusty/amd64/libssl1.0.0/download, unpack it and drop libssl.so.1.0.0 and libcrypto.so.1.0.0 into `bin` where `pypy3` binary resides * everything else works with symlinking in your `/usr/lib64` 3. Get the develop branch of virtualenv https://github.com/pypa/virtualenv/archive/develop.zip and unzip it 4. Given your pypy3 tarball was unpacked to `pypy-c-jit-84568-d463dd98e6a6-linux64`: LD_LIBRARY_PATH=pypy-c-jit-84568-d463dd98e6a6-linux64/bin virtualenv-develop/virtualenv.py -p pypy-c-jit-84568-d463dd98e6a6-linux64/bin/pypy3 venv-pypy3 5. Fix virtualenv by coping `libssl.so.1.0.0` and `libcrypto.so.1.0.0` into `venv-pypy3/bin` if you had problems with openssl 6. Activate virtualenv and `pip install asyncio` 6a. Fix missing `time.get_clock_info` in PyPy by hardcoding your monotonic clock resolution in `asyncio/base_events.py`, I got my resolution from CPython 3.5 Substitute self._clock_resolution = time.get_clock_info('monotonic').resolution with self._clock_resolution = 1e-09 7. Run the attached server.py python server.py --print 8. Run the client python client.py --num 10000 --workers 5 9. Play with other options and see your results ``` From issues-reply at bitbucket.org Sun May 22 19:18:56 2016 From: issues-reply at bitbucket.org (Philip Jenvey) Date: Sun, 22 May 2016 23:18:56 -0000 Subject: [pypy-issue] Issue #2306: PyPy3 stricter handling of __new__/__init__ arguments (pypy/pypy) Message-ID: <20160522231856.58230.2293@celery-worker-102.ash1.bb-inf.net> New issue 2306: PyPy3 stricter handling of __new__/__init__ arguments https://bitbucket.org/pypy/pypy/issues/2306/pypy3-stricter-handling-of-__new__ Philip Jenvey: Python 3 makes `object.__new/init__` stricter (raise TypeErrors) about accepting any arguments depending on whether or not these methods were overwritten. This is currently annoying to implement on PyPy because we don't perfectly match CPython's use of `__new/init__` methods (e.g. PyPy's type doesn't implement an `__init__`) and that causes the rules to go haywire: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/3314 CPython 2.x issues warnings in these cases (PyPy doesn't). That newinitwarn branch linked above is an attempt to see how many warnings would be issued on 2.7 -- by making them errors. It's currently very broken, due to lack of `type.__init__`, but likely needs more work after that one's fixed. Maybe we can emulate CPython by special casing not .is_heaptype -- we should probably just fix our mismatch `__new/init__`s though Py3k's test for this is: test_descr.test_object_new_and_init_with_parameters From issues-reply at bitbucket.org Thu May 26 19:16:28 2016 From: issues-reply at bitbucket.org (Philip Jenvey) Date: Thu, 26 May 2016 23:16:28 -0000 Subject: [pypy-issue] Issue #2307: Add PyPy3 str.casefold (pypy/pypy) Message-ID: <20160526231628.77665.75909@celery-worker-102.ash1.bb-inf.net> New issue 2307: Add PyPy3 str.casefold https://bitbucket.org/pypy/pypy/issues/2307/add-pypy3-strcasefold Philip Jenvey: Here's the CPython work for casefold: http://bugs.python.org/issue13752 From issues-reply at bitbucket.org Thu May 26 19:18:02 2016 From: issues-reply at bitbucket.org (Philip Jenvey) Date: Thu, 26 May 2016 23:18:02 -0000 Subject: [pypy-issue] Issue #2308: PyPy3: Use full unicode mappings for str.upper/lower/title (pypy/pypy) Message-ID: <20160526231802.16520.98850@celery-worker-103.ash1.bb-inf.net> New issue 2308: PyPy3: Use full unicode mappings for str.upper/lower/title https://bitbucket.org/pypy/pypy/issues/2308/pypy3-use-full-unicode-mappings-for Philip Jenvey: The CPython issue: http://bugs.python.org/issue12736 From issues-reply at bitbucket.org Thu May 26 19:34:09 2016 From: issues-reply at bitbucket.org (Philip Jenvey) Date: Thu, 26 May 2016 23:34:09 -0000 Subject: [pypy-issue] Issue #2309: Optimized Unicode Representation (pypy/pypy) Message-ID: <20160526233409.28753.39792@celery-worker-103.ash1.bb-inf.net> New issue 2309: Optimized Unicode Representation https://bitbucket.org/pypy/pypy/issues/2309/optimized-unicode-representation Philip Jenvey: PyPy needs PEP 393 like optimized unicode strings. This is for Python 3.3 compat and the potential space savings/perf, but it should work on PyPy2 as well The plan is to use utf-8 strings as the as the underlying storage wayedt made a prototype during GSoC in the utf8-unicode2 branch: https://bitbucket.org/pypy/pypy/branches/compare/utf8-unicode2%0Ddefault From issues-reply at bitbucket.org Sat May 28 00:49:37 2016 From: issues-reply at bitbucket.org (Philip Jenvey) Date: Sat, 28 May 2016 04:49:37 -0000 Subject: [pypy-issue] Issue #2310: PyPy3: Kill WindowsError (pypy/pypy) Message-ID: <20160528044937.39482.85545@celery-worker-102.ash1.bb-inf.net> New issue 2310: PyPy3: Kill WindowsError https://bitbucket.org/pypy/pypy/issues/2310/pypy3-kill-windowserror Philip Jenvey: Python 3.3 killed WindowsError (by making it an alias of OSError). That's the easy part, the work of this bug is making the changes to OSError that make it handle WindowsError's winerror attribute This is a big blocker for Windows support as can be seen by the buildbots currently failing in all the unittest teardown methods From issues-reply at bitbucket.org Sat May 28 16:05:24 2016 From: issues-reply at bitbucket.org (Frank Siler) Date: Sat, 28 May 2016 20:05:24 -0000 Subject: [pypy-issue] Issue #2311: from __future__ import division does not work when run from $PYTHONSTARTUP (pypy/pypy) Message-ID: <20160528200524.12616.7941@celery-worker-103.ash1.bb-inf.net> New issue 2311: from __future__ import division does not work when run from $PYTHONSTARTUP https://bitbucket.org/pypy/pypy/issues/2311/from-__future__-import-division-does-not Frank Siler: I am building 5.1.2 by hand to test, but I haven't found any recent tickets that seem on point for this. This is the stock MacPorts build out of MacOS 10.9. ``` % cat test.py from __future__ import division % PYTHONSTARTUP=test.py pypy Python 2.7.10 (b0a649e90b6642251fb4a765fe5b27a97b1319a9, May 08 2016, 04:42:24) [PyPy 5.1.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. >>>> 1/2 0 >>>> dir() ['__builtins__', '__doc__', '__name__', '__package__', 'division'] >>>> from __future__ import division >>>> 1/2 0.5 >>>> ``` From issues-reply at bitbucket.org Sat May 28 20:29:56 2016 From: issues-reply at bitbucket.org (Philip Jenvey) Date: Sun, 29 May 2016 00:29:56 -0000 Subject: [pypy-issue] Issue #2312: PyPy3 venv module doesn't work (pypy/pypy) Message-ID: <20160529002956.9719.420@celery-worker-103.ash1.bb-inf.net> New issue 2312: PyPy3 venv module doesn't work https://bitbucket.org/pypy/pypy/issues/2312/pypy3-venv-module-doesnt-work Philip Jenvey: Here's the CPython commit for venv: https://hg.python.org/cpython/rev/294f8aeb4d4b o we may need to tweak its path layout.. (or maybe adopt its layout) o venv'd pypy doesn't find the correct stdlib location. maybe partly due to above but it also needs changes from the above commit -- like the loading of venv's config file o venv 'copy' mode does not copy the libpypy dll. CPython assumes its dylib location is static whereas PyPy uses a more dynamic rpath (at least on some platforms). Copy mode is the default on Windows (as an aside virtualenv 15.0.2 works fine w/ the latest pypy3) From issues-reply at bitbucket.org Sun May 29 09:59:32 2016 From: issues-reply at bitbucket.org (Andrey Kashlak) Date: Sun, 29 May 2016 13:59:32 -0000 Subject: [pypy-issue] Issue #2313: Weird AssertionError with lxml and time modules (pypy/pypy) Message-ID: <20160529135932.20417.60626@celery-worker-104.ash1.bb-inf.net> New issue 2313: Weird AssertionError with lxml and time modules https://bitbucket.org/pypy/pypy/issues/2313/weird-assertionerror-with-lxml-and-time Andrey Kashlak: ``` #!python import time import lxml.html def main(): info = lxml.html.fragments_fromstring('
')[0] # Comment one of these lines ? segfault will disappear info.findall("li") time.strptime('1970-01-01T03:00:00', "%Y-%m-%dT%H:%M:%S") print('before segfault') info.findall('li') # <-- SEGFAULT HERE print('after segfault') if __name__ == '__main__': main() ``` ``` $ pypy pypytest.py before segfault RPython traceback: File "pypy_interpreter.c", line 39039, in BuiltinCodePassThroughArguments1_funcrun_obj File "pypy_module_cpyext_5.c", line 12787, in wrap_next File "pypy_module_cpyext_5.c", line 28060, in generic_cpy_call__StdObjSpaceConst_funcPtr_SomeI_13 Fatal RPython error: AssertionError Aborted (core dumped) ``` I don't know is it pypy or lxml problem, please redirect me if needed :) Arch Linux x86_64, pypy installed from repo Python 2.7.10 (b0a649e90b66, May 15 2016, 19:57:00) [PyPy 5.1.1 with GCC 6.1.1 20160501] on linux2 ----- P.S. pypy3 segfaults on "import lxml.html", but i think it is lxml bug P.P.S. Is there an instruction how to run the nightly build? From issues-reply at bitbucket.org Sun May 29 13:23:47 2016 From: issues-reply at bitbucket.org (John Vandenberg) Date: Sun, 29 May 2016 17:23:47 -0000 Subject: [pypy-issue] Issue #2314: RuntimeError: maximum recursion depth exceeded when altering sys.path with PYTHONIOENCODING set (pypy/pypy) Message-ID: <20160529172347.18822.36267@celery-worker-101.ash1.bb-inf.net> New issue 2314: RuntimeError: maximum recursion depth exceeded when altering sys.path with PYTHONIOENCODING set https://bitbucket.org/pypy/pypy/issues/2314/runtimeerror-maximum-recursion-depth John Vandenberg: With the sample script below, it works if PYTHONIOENCODING is not used, but fails when it is set with RuntimeError on v2.4.0-v5.1.1. ```python # -*- coding: utf-8 -*- u"""Foobar.""" import sys sys.path = (u'.', ) + tuple(sys.path[1:]) def help(): print(__doc__) if __name__ == '__main__': help() ``` Sample code here: https://github.com/jayvdb/my-ci-test/tree/8abaffadb50abb95fe256a87a5443cba08bcb4c3 Test results here: https://travis-ci.org/jayvdb/my-ci-test/builds/133756245 ```bash $ python pwb.py Foobar. $ PYTHONIOENCODING=UTF8 python pwb.py RuntimeError: maximum recursion depth exceeded ``` Removing use of `__doc__` or alteration of `sys.path` 'fixes' the problem.