From issues-reply at bitbucket.org Tue Dec 1 09:27:19 2015 From: issues-reply at bitbucket.org (jacobz_20) Date: Tue, 01 Dec 2015 14:27:19 -0000 Subject: [pypy-issue] Issue #2199: Data Descriptors incorrectly implemented (pypy/pypy) Message-ID: <20151201142719.6772.66585@celery-worker-101.ash1.bb-inf.net> New issue 2199: Data Descriptors incorrectly implemented https://bitbucket.org/pypy/pypy/issues/2199/data-descriptors-incorrectly-implemented jacobz_20: Consider the following descriptor: ``` #!python class desc: def __get__(self, instance, owner): return "get" def __delete__(self, instance): print("delete") ``` Pypy seems to not consider this to be a data descriptor. Assigning a value to an attribute of this descriptor type should raise an "AttributeError: __set__", but it instead saves the value on the instance dictionary. Then, when the attribute is looked up, it pulls it from the instance rather than calling __get__(). From issues-reply at bitbucket.org Wed Dec 2 05:19:08 2015 From: issues-reply at bitbucket.org (Konstantin Lopuhin) Date: Wed, 02 Dec 2015 10:19:08 -0000 Subject: [pypy-issue] Issue #2200: RuntimeError: maximum recursion depth exceeded on 4.0.1 (pypy/pypy) Message-ID: <20151202101908.18059.3267@celery-worker-102.ash1.bb-inf.net> New issue 2200: RuntimeError: maximum recursion depth exceeded on 4.0.1 https://bitbucket.org/pypy/pypy/issues/2200/runtimeerror-maximum-recursion-depth Konstantin Lopuhin: Note that this is not complete yet, but still: While running our internal app PyPy 4.0.0 was consistently failing with an exception "RuntimeError: maximum recursion depth exceeded" after running for a while, and there was clearly no recursion taking place, and the traceback was fairly short. After updating to 4.0.1 the error seemed to disappear, but now 4.0.1 (on another app) also failed with the same error, but this time it seems very rare. Is there anything I can do to gather more data when I get the crash again? This is not production, so I can add more logging or other things (but it will be hard to check with --jit=off as it seems quite rare). From issues-reply at bitbucket.org Wed Dec 2 19:20:23 2015 From: issues-reply at bitbucket.org (Pete Vine) Date: Thu, 03 Dec 2015 00:20:23 -0000 Subject: [pypy-issue] Issue #2201: Benchmark results unintelligible (pypy/pypy) Message-ID: <20151203002023.26239.32290@celery-worker-101.ash1.bb-inf.net> New issue 2201: Benchmark results unintelligible https://bitbucket.org/pypy/pypy/issues/2201/benchmark-results-unintelligible Pete Vine: Benchmarking two pypy binaries side by side (--changed option) prints the following example result to the console: ``` ### ai ### Min: 0.490526 -> 0.479404: 1.0232x faster Avg: 0.494283 -> 0.486747: 1.0155x faster Not significant Stddev: 0.00369 -> 0.00644: 1.7443x larger ``` Provided the results are being presented in their respective running order, there's no clue as to whether **more** is better/worse meaning it's impossible to know which binary was actually faster! From issues-reply at bitbucket.org Fri Dec 4 16:07:13 2015 From: issues-reply at bitbucket.org (Brian Corbin) Date: Fri, 04 Dec 2015 21:07:13 -0000 Subject: [pypy-issue] Issue #2202: strange results from uuid.uuid4() when generating many uuid4 values in a short period of time (pypy/pypy) Message-ID: <20151204210713.31016.61063@celery-worker-101.ash1.bb-inf.net> New issue 2202: strange results from uuid.uuid4() when generating many uuid4 values in a short period of time https://bitbucket.org/pypy/pypy/issues/2202/strange-results-from-uuiduuid4-when Brian Corbin: Hi, I've been working to switch a project over to run with pypy. Initial results show some significant speed ups in key parts of the project! I'm down to just a couple of test cases failing in this project when running under pypy. One of the test failures seems to be related to some strange behavior when generating a lot of uuid4 values back-to-back. One of these tests creates some sample dictionaries that each has a uuid associated with it. The test case used these uuids for a few things and it seemed to fail periodically because some of the uuid values ended up being the same on some of the dictionaries when we were expecting them all to have unique values. Here's a snippet to demonstrate the behavior I've been seeing with PyPy 4.0.1 in a Ubuntu VM: ``` $ uname -a Linux vagrant-ubuntu-trusty-64 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ python Python 2.7.10 (5f8302b8bf9f, Nov 18 2015, 10:46:46) [PyPy 4.0.1 with GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>> import uuid >>>> uuid._uuid_generate_random <_ctypes.function.CFuncPtrFast object at 0x00007f9fe88565a8> >>>> for i in range(1000): .... x = str(uuid.uuid4()) .... if '00000' in x: .... print(x) .... 04000000-0000-0000-0000-000000000000 ffffffff-ffff-ffff-788f-050000000000 ffffffff-ffff-ffff-788f-050000000000 04000000-0000-0000-ffff-ffffffffffff 908823e8-9f7f-0000-2805-000000000000 01000000-0000-0000-00c8-3de89f7f0000 000133e8-9f7f-0000-0000-000000000000 183fcbe8-9f7f-0000-0000-000000000000 00010000-0000-0000-000f-050000000000 00013ee8-9f7f-0000-788f-050000000000 ffffffff-ffff-ffff-788f-050000000000 01000000-0000-0000-ffff-ffffffffffff ffffffff-ffff-ffff-000f-050000000000 01000000-0000-0000-ffff-ffffffffffff 02000000-0000-0000-0832-cce89f7f0000 0001cde8-9f7f-0000-0000-000000000000 00000000-0000-0000-a834-cde89f7f0000 ffffffff-ffff-ffff-e015-080000000000 00000000-0000-0000-d6ff-ffffffffffff 00000000-0000-0000-0000-000000000000 14000000-0000-0000-0000-000000000000 d6ffffff-ffff-ffff-4090-060000000000 60e93de8-9f7f-0000-0000-000000000000 01000000-0000-0000-783b-cfe89f7f0000 00000000-0000-0000-387b-080000000000 ffffffff-ffff-ffff-0100-000000000000 ffffffff-ffff-ffff-0000-000000000000 00000000-0000-0000-0000-000000000000 b01fcfe8-9f7f-0000-2805-000000000000 00000000-0000-0000-ffff-ffffffffffff 00000000-0000-0000-809b-40e89f7f0000 01000000-0000-0000-7868-d0e89f7f0000 01000000-0000-0000-0100-000000000000 01000000-0000-0000-0001-3de89f7f0000 48770100-0000-0000-0000-000000000000 00000000-0000-0000-2805-000000000000 00000000-0000-0000-0200-000000000000 00000000-0000-0000-0000-000000000000 08000000-0000-0000-0300-000000000000 00000000-0000-0000-20cd-4dee9f7f0000 00000000-0000-0000-20c7-d1e89f7f0000 02000000-0000-0000-e00a-d2e89f7f0000 18480700-0800-0000-0000-000000000000 48770100-0000-0000-0000-000000000000 04000000-0000-0000-60d4-31e89f7f0000 2a000000-0000-0000-58b2-d2e89f7f0000 28050000-0000-0000-0200-000000000000 10710100-0000-0000-f065-080000000000 01000000-0000-0000-0101-cfe89f7f0000 00000000-0000-0000-0000-000000000000 ``` It seems like `_uuid_generate_random` path here https://bitbucket.org/pypy/pypy/src/80ce6004b46af7a7ece6e30f1a53f8c98ad97203/lib-python/2.7/uuid.py?at=default&fileviewer=file-view-default#uuid.py-609 is producing different results from ``` import os return UUID(bytes=os.urandom(16), version=4) ``` The latter approach actually works as expected and our test suite passes when that's used under pypy. For now, I've switched the project over to just use `UUID(bytes=os.urandom(16), version=4)` in place of `uuid.uuid4()` while trying to determine what's going on there. I wanted to share this in case anyone else runs into strange behavior when they're generating a number of uuid4 values in a short period of time with PyPy 4.0.1. Thank y'all for all the hard work on pypy! Brian From issues-reply at bitbucket.org Tue Dec 8 00:37:14 2015 From: issues-reply at bitbucket.org (Pete Vine) Date: Tue, 08 Dec 2015 05:37:14 -0000 Subject: [pypy-issue] Issue #2203: ARM regressions from 2.6.1 to 4.0.1 (pypy/pypy) Message-ID: <20151208053714.11116.45897@celery-worker-102.ash1.bb-inf.net> New issue 2203: ARM regressions from 2.6.1 to 4.0.1 https://bitbucket.org/pypy/pypy/issues/2203/arm-regressions-from-261-to-401 Pete Vine: You may find it interesting on a 1GB, cortex-a5 board, PyPy 2.6.1 is actually 2-25% faster in a few benchmarks: ``` bm_mdp -> 1.0193x faster crypto_pyaes -> 1.1196x faster django -> 1.0296x hexiom2 -> 1.2309x faster meteor-contest -> 1.0180x faster richards -> 1.2676x faster spectral-norm -> 1.1051x faster telco -> 1.1002x faster twisted_iteration -> 1.0277x faster ``` I'd also similarly benchmarked the slow-path versions of 32-bit x86 pypies in case you're interested. From issues-reply at bitbucket.org Tue Dec 8 05:51:04 2015 From: issues-reply at bitbucket.org (Carl Friedrich Bolz) Date: Tue, 08 Dec 2015 10:51:04 -0000 Subject: [pypy-issue] Issue #2204: Improve call family error (pypy/pypy) Message-ID: <20151208105104.17136.35350@celery-worker-104.ash1.bb-inf.net> New issue 2204: Improve call family error https://bitbucket.org/pypy/pypy/issues/2204/improve-call-family-error Carl Friedrich Bolz: Maciek found an inscrutable call table error today let's improve it: 11:39:53 cfbolz: yes, just check out the faster-blackhole at c5f87e2531d5 and run test_zrpy_gc.py in jit/backend/x86 From issues-reply at bitbucket.org Fri Dec 11 08:39:50 2015 From: issues-reply at bitbucket.org (Silvio Ricardo Cordeiro) Date: Fri, 11 Dec 2015 13:39:50 -0000 Subject: [pypy-issue] Issue #2205: Segfault on pyexpat.XMLParserType (pypy/pypy) Message-ID: <20151211133950.26778.98330@celery-worker-101.ash1.bb-inf.net> New issue 2205: Segfault on pyexpat.XMLParserType https://bitbucket.org/pypy/pypy/issues/2205/segfault-on-pyexpatxmlparsertype Silvio Ricardo Cordeiro: The attached code segfaults on PyPy 4.1.0 for any sufficiently large input XML I have tried. The problem seems to be the following expression: self._parser.CurrentColumnNumber The exact iteration where the segfault happens is unpredictable (but it always happens after processing around 5MB of XML). I have 30GB free memory, so it should not be an OOM problem. I understand the access through _start_list and _parse is not documented, but the crash seems to happen only when reading CurrentColumnNumber, which is a supported attribute for xmlparser objects. The segfault also happens with CurrentLineNumber. Any ideas on what's going on? Should I provide a sample XML displaying the bug? From issues-reply at bitbucket.org Sat Dec 12 10:37:51 2015 From: issues-reply at bitbucket.org (Armin Rigo) Date: Sat, 12 Dec 2015 15:37:51 -0000 Subject: [pypy-issue] Issue #2206: python parser bug (pypy/pypy) Message-ID: <20151212153751.14076.58392@celery-worker-103.ash1.bb-inf.net> New issue 2206: python parser bug https://bitbucket.org/pypy/pypy/issues/2206/python-parser-bug Armin Rigo: ``` pypy -c 'f = lambda: 1.0; g = lambda: 1; print g()' ``` prints 1.0 instead 1. (It's a bug shared with CPython.) From issues-reply at bitbucket.org Sun Dec 13 14:45:07 2015 From: issues-reply at bitbucket.org (Helder Eijs) Date: Sun, 13 Dec 2015 19:45:07 -0000 Subject: [pypy-issue] Issue #2207: Incorrect slicing of strings in a tight loop (pypy/pypy) Message-ID: <20151213194507.15058.29665@celery-worker-103.ash1.bb-inf.net> New issue 2207: Incorrect slicing of strings in a tight loop https://bitbucket.org/pypy/pypy/issues/2207/incorrect-slicing-of-strings-in-a-tight Helder Eijs: With pypy 4.0 and 4.0.1, I get incorrect results for the following piece of sample code, at least on x86_64: ``` #!python from binascii import hexlify from Crypto.Cipher import AES cipher = AES.new(b'0'*16, AES.MODE_ECB) result = b'0'*16 for x in xrange(10000): tmp = cipher.encrypt(result[:16]) assert len(tmp) == 16 result = tmp[8:] + tmp[:8] print "Result before slicing:", hexlify(tmp) print "Result after slicing :", hexlify(result) ``` Where the Crypto package is provided by [pycryptodome](https://pypi.python.org/pypi/pycryptodome/) (a pycrypto fork, v3.3.1) and the iteration count is sufficiently high (the problem does not show up with lower counts). The expected result (which I obtain with CPython 2.x and 3.x and PyPy 2.6.1) is: ``` #! Result before slicing: dce8c9ca76d5bd2b82ac0d53d7c7a1c7 Result after slicing : 82ac0d53d7c7a1c7dce8c9ca76d5bd2b ``` However, with PyPy 4.0 and 4.0.1 I surprisingly get garbage that varies per iteration, like: ``` Result before slicing: c7ad819348c586d8d03fe18e0dc928b2 Result after slicing : 48000000000000000000000000000000 ``` Other values are possible. Pycryptodome makes heavy use of cffi internally but the variable **tmp** is a simple byte string (created with the idiomatic ```ffi.buffer(xxx)[:]```). Small tweaks of the code above seem to fix the problem for some unknown reason. For instance, by replacing: ``` tmp = cipher.encrypt(result[:16]) ``` with the functionally equivalent: ``` tmp = cipher.encrypt(result) ``` I get the right result. From issues-reply at bitbucket.org Tue Dec 15 10:13:58 2015 From: issues-reply at bitbucket.org (Armin Rigo) Date: Tue, 15 Dec 2015 15:13:58 -0000 Subject: [pypy-issue] Issue #2210: another segfault with gevent (pypy/pypy) Message-ID: <20151215151358.55391.15015@celery-worker-102.ash1.bb-inf.net> New issue 2210: another segfault with gevent https://bitbucket.org/pypy/pypy/issues/2210/another-segfault-with-gevent Armin Rigo: https://github.com/gevent/gevent/issues/677 From issues-reply at bitbucket.org Tue Dec 15 16:30:17 2015 From: issues-reply at bitbucket.org (Vincent Legoll) Date: Tue, 15 Dec 2015 21:30:17 -0000 Subject: [pypy-issue] Issue #2211: cryptic translation error with extended slices use in rpython (pypy/pypy) Message-ID: <20151215213017.18052.89741@celery-worker-103.ash1.bb-inf.net> New issue 2211: cryptic translation error with extended slices use in rpython https://bitbucket.org/pypy/pypy/issues/2211/cryptic-translation-error-with-extended Vincent Legoll: When attempting to fix issue #2198, I stumbled upon a cryptic error message and Ronan asked me to report that. Happened at : https://bitbucket.org/pypy/pypy/pull-requests/369/fix-2198/diff#Lpypy/objspace/std/listobject.pyT1498 ``` #!raw translation:info] Error: [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/translator/goal/translate.py", line 318, in main [translation:info] drv.proceed(goals) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/translator/driver.py", line 550, in proceed [translation:info] result = self._execute(goals, task_skip = self._maybe_skip()) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/translator/tool/taskengine.py", line 114, in _execute [translation:info] res = self._do(goal, taskcallable, *args, **kwds) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/translator/driver.py", line 279, in _do [translation:info] res = func() [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/translator/driver.py", line 316, in task_annotate [translation:info] s = annotator.build_types(self.entry_point, self.inputtypes) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/annotator/annrpython.py", line 88, in build_types [translation:info] return self.build_graph_types(flowgraph, inputs_s, complete_now=complete_now) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/annotator/annrpython.py", line 134, in build_graph_types [translation:info] self.complete() [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/annotator/annrpython.py", line 188, in complete [translation:info] self.complete_pending_blocks() [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/annotator/annrpython.py", line 183, in complete_pending_blocks [translation:info] self.processblock(graph, block) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/annotator/annrpython.py", line 346, in processblock [translation:info] self.flowin(graph, block) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/annotator/annrpython.py", line 445, in flowin [translation:info] self.consider_op(op) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/annotator/annrpython.py", line 597, in consider_op [translation:info] resultcell = op.consider(self) [translation:info] File "/home/vlegoll/repo/upstream/pypy-for-upstream2/rpython/flowspace/operation.py", line 103, in consider [translation:info] spec = type(self).get_specialization(*args_s) [translation:ERROR] AttributeError: type object 'newslice' has no attribute 'get_specialization' [translation:ERROR] Processing block: [translation:ERROR] block at 662 is a [translation:ERROR] in (pypy.objspace.std.listobject:1457)FloatListStrategy.setslice [translation:ERROR] containing the following operations: [translation:ERROR] v482 = add(v481, slicelength_0) [translation:ERROR] v483 = newslice(v481, v482, step_0) [translation:ERROR] v484 = setitem(items_15, v483, other_items_0) [translation:ERROR] --end-- ``` From issues-reply at bitbucket.org Wed Dec 16 06:57:57 2015 From: issues-reply at bitbucket.org (Armin Rigo) Date: Wed, 16 Dec 2015 11:57:57 -0000 Subject: [pypy-issue] Issue #2212: black -> white pointer in the GC (pypy/pypy) Message-ID: <20151216115757.23286.2908@celery-worker-102.ash1.bb-inf.net> New issue 2212: black -> white pointer in the GC https://bitbucket.org/pypy/pypy/issues/2212/black-white-pointer-in-the-gc Armin Rigo: It is possible to hit this assertion in our incremental GC: ``` #!python ll_assert(False, "black -> white pointer found") ``` because of the JIT's rewrite.py, which will not put a write barrier before a ``setfield(p0, p1)`` if ``p1`` is an old constant. But p1 might be white and p0 black. I've no clue why the problem doesn't show up more often, but it triggers the assert above with the proper `PYPY_GC_*` env vars. I think that it is not an important issue: in this case, the constant `p1` is also always reachable from the CompiledLoop itself. If we reach the assert in the GC, it's because the ``setfield`` was executed recently, during the same major collection iteration. The loop itself is alive during this iteration---running JIT assembler relies on the loop being alive. So we will anyway see the same ConstPtr from the loop. Is the above reasoning correct? Am I missing an edge case? From issues-reply at bitbucket.org Tue Dec 22 07:43:17 2015 From: issues-reply at bitbucket.org (Tudor Aursulesei) Date: Tue, 22 Dec 2015 12:43:17 -0000 Subject: [pypy-issue] Issue #2213: pypy process hangs when using pycares and gevent (pypy/pypy) Message-ID: <20151222124317.20100.16779@celery-worker-104.ash1.bb-inf.net> New issue 2213: pypy process hangs when using pycares and gevent https://bitbucket.org/pypy/pypy/issues/2213/pypy-process-hangs-when-using-pycares-and Tudor Aursulesei: https://github.com/saghul/pycares/issues/21 https://github.com/gevent/gevent/issues/710 From issues-reply at bitbucket.org Thu Dec 24 01:55:04 2015 From: issues-reply at bitbucket.org (cheery) Date: Thu, 24 Dec 2015 06:55:04 -0000 Subject: [pypy-issue] Issue #2214: Difficulty getting StackletThread to work in my own project (pypy/pypy) Message-ID: <20151224065504.809.78582@celery-worker-102.ash1.bb-inf.net> New issue 2214: Difficulty getting StackletThread to work in my own project https://bitbucket.org/pypy/pypy/issues/2214/difficulty-getting-stackletthread-to-work cheery: I have quite of problem in my interpreter: https://github.com/cheery/lever/ Adding these pieces (the gc.collect was uncommented) brought along segmentation faults, memory corruption and sometimes an error message "gc roots not found!" https://github.com/cheery/lever/blob/master/runtime/stdlib/gc.py https://github.com/cheery/lever/blob/master/runtime/eventloop.py I think it may be in how I've implemented the greenlets in the language, or that I haven't done something, or then it's a bug in rpython. Here's the greenlet code btw: https://github.com/cheery/lever/blob/master/runtime/green.py Could you help me out here? I've tried to scope down the issue and at least need a way to diagnose what's wrong here. From issues-reply at bitbucket.org Thu Dec 24 13:35:15 2015 From: issues-reply at bitbucket.org (Jason Schulz) Date: Thu, 24 Dec 2015 18:35:15 -0000 Subject: [pypy-issue] Issue #2215: GCC Translation Error (-march=ivybridge) (pypy/pypy) Message-ID: <20151224183515.22519.63278@celery-worker-102.ash1.bb-inf.net> New issue 2215: GCC Translation Error (-march=ivybridge) https://bitbucket.org/pypy/pypy/issues/2215/gcc-translation-error-march-ivybridge Jason Schulz: There is a translation error with -march=ivybridge and GCC (4.9.3). [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 2084, in [translation:ERROR] tracker.process(f, g, filename=fn) [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 1977, in process [translation:ERROR] tracker = parser.process_function(lines, filename) [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 1489, in process_function [translation:ERROR] table = tracker.computegcmaptable(self.verbose) [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 59, in computegcmaptable [translation:ERROR] self.findframesize() [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 295, in findframesize [translation:ERROR] insn1.framesize = size_at_insn1 [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/../../../../rpython/translator/c/gcc/instruction.py", line 262, in __setattr__ [translation:ERROR] "unrecognized function prologue - " [translation:ERROR] AssertionError: unrecognized function prologue - only supports push %ebp; movl %esp, %ebp [translation:ERROR] make: *** [implement_11.gcmap] Error 1 [translation:ERROR] """) Everything builds correctly with -march=x86-64. From issues-reply at bitbucket.org Thu Dec 24 13:49:10 2015 From: issues-reply at bitbucket.org (Jason Schulz) Date: Thu, 24 Dec 2015 18:49:10 -0000 Subject: [pypy-issue] Issue #2216: Translation Error w/ Clang (pypy/pypy) Message-ID: <20151224184910.19132.35834@celery-worker-102.ash1.bb-inf.net> New issue 2216: Translation Error w/ Clang https://bitbucket.org/pypy/pypy/issues/2216/translation-error-w-clang Jason Schulz: PyPy doesn't seem to compile under Clang. [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 2084, in [translation:ERROR] tracker.process(f, g, filename=fn) [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 1975, in process [translation:ERROR] for in_function, lines in parser.find_functions(iterlines): [translation:ERROR] File "/var/tmp/portage/dev-python/pypy-4.0.1/work/pypy-4.0.1-src/rpython/translator/c/gcc/trackgcroot.py", line 1525, in find_functions [translation:ERROR] "missed the end of the previous function") [translation:ERROR] AssertionError: missed the end of the previous function [translation:ERROR] make: *** [testing_1.gcmap] Error 1 [translation:ERROR] make: *** Waiting for unfinished jobs.... I'm not sure if Clang is supported. From issues-reply at bitbucket.org Mon Dec 28 20:27:35 2015 From: issues-reply at bitbucket.org (mzakharo) Date: Tue, 29 Dec 2015 01:27:35 -0000 Subject: [pypy-issue] Issue #2217: Cross-translating cffi modules & unable to execute 'cc' (pypy/pypy) Message-ID: <20151229012735.40456.97310@celery-worker-101.ash1.bb-inf.net> New issue 2217: Cross-translating cffi modules & unable to execute 'cc' https://bitbucket.org/pypy/pypy/issues/2217/cross-translating-cffi-modules-unable-to mzakharo: When cross translating, building the cffi modules with the following command: ``` #!bash PYTHONPATH=. sb2 -t ARM ./pypy/goal/pypy-c pypy/tool/build_cffi_imports.py ``` fails with the following error: unable to execute 'cc': No such file or directory Attached patch fixes the error for me. PYPY version: 4.0.1 HOST: Linux 3.19.0-42-generic 14.04.1-Ubuntu SMP Fri Dec 18 10:24:49 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux TARGET: Linux qemuarm 4.1.8-yocto-standard PREEMPT Sun Dec 27 14:53:42 EST 2015 armv5tejl GNU/Linux From issues-reply at bitbucket.org Mon Dec 28 21:05:24 2015 From: issues-reply at bitbucket.org (mzakharo) Date: Tue, 29 Dec 2015 02:05:24 -0000 Subject: [pypy-issue] Issue #2218: Cross-translating on 64 bit host: recompile with -fPIC and -m32 (pypy/pypy) Message-ID: <20151229020524.2560.19163@celery-worker-101.ash1.bb-inf.net> New issue 2218: Cross-translating on 64 bit host: recompile with -fPIC and -m32 https://bitbucket.org/pypy/pypy/issues/2218/cross-translating-on-64-bit-host-recompile mzakharo: When cross-translating pypy 4.0.1 for 32-bit ARM on a 64 bit host (Ubuntu 14.04), the translation task: ``` #!bash pypy /rpython/bin/rpython -Ojit --platform=arm --gcrootfinder=shadowstack --jit-backend=arm targetpypystandalone.py ``` fails with: [platform:Error] /usr/bin/ld: /tmp/usession-release-4.0.1-59/rpython/translator/c/src/signals.o: relocation R_X86_64_32 against `pypysig_counter' can not be used when making a shared object; recompile with -fPIC [platform:Error] /tmp/usession-release-4.0.1-59/rpython/translator/c/src/signals.o: error adding symbols: Bad value [platform:Error] collect2: error: ld returned 1 exit status when I add the -fPIC, the error changes to: translation:ERROR] OSError: Cannot load library /tmp/usession-release-4.0.1-60/shared_cache/externmod.so: /tmp/usession-release-4.0.1-60/shared_cache/externmod.so: wrong ELF class: ELFCLASS64 Finally, The attached patch adds -m32 to args_for_shared() and get_shared_only_compile_flags(), which which fixes the problem for me. The patch is *hackish* - could someone please advise on what the correct solution would look like? From issues-reply at bitbucket.org Wed Dec 30 09:24:17 2015 From: issues-reply at bitbucket.org (Jeroen Zuiddam) Date: Wed, 30 Dec 2015 14:24:17 -0000 Subject: [pypy-issue] Issue #2219: Building pypy 4.0.1 from source on Fedora 22 (pypy/pypy) Message-ID: <20151230142417.11873.43132@celery-worker-102.ash1.bb-inf.net> New issue 2219: Building pypy 4.0.1 from source on Fedora 22 https://bitbucket.org/pypy/pypy/issues/2219/building-pypy-401-from-source-on-fedora-22 Jeroen Zuiddam: I am trying to build pypy 4.0.1 from source on Fedora 22 with these instructions: http://pypy.org/download.html#building-from-source. However, I am getting an error. This is the last part of the log. ``` [c:writing] rpython_rtyper_rfloat.c [c:writing] rpython_rtyper_rint.c [c:writing] rpython_rtyper_rlist.c [c:writing] rpython_rtyper_rrange.c [c:writing] rpython_rtyper_rstr.c [c:writing] rpython_tool_error.c [c:writing] rpython_translator_c_extfunc.c [c:writing] rpython_translator_exceptiontransform.c [translation:info] written: /tmp/usession-release-4.0.1-0/testing_1/testing_1.c [748c3] translation-task} [translation:info] Compiling c source... [748c3] {translation-task starting compile_c [platform:execute] make -j 4 in /tmp/usession-release-4.0.1-0/testing_1 [platform:Error] In file included from data_pypy_module_bz2_interp_bz2.c:6:0: [platform:Error] forwarddecl.h:1842:66: error: field ?member1183? has incomplete type [platform:Error] struct pypy_pypy_objspace_std_dictmultiobject_W_DictMultiIterV0 member1183; [platform:Error] ^ [platform:Error] make: *** [data_pypy_module_bz2_interp_bz2.gcmap] Error 1 [platform:Error] make: *** Waiting for unfinished jobs.... [748c8] translation-task} [Timer] Timings: [Timer] annotate --- 872.9 s [Timer] rtype_lltype --- 984.9 s [Timer] pyjitpl_lltype --- 1506.7 s [Timer] backendopt_lltype --- 299.3 s [Timer] stackcheckinsertion_lltype --- 175.9 s [Timer] database_c --- 447.6 s [Timer] source_c --- 451.5 s [Timer] compile_c --- 102.1 s [Timer] =========================================== [Timer] Total: --- 4841.0 s [translation:info] Error: [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/goal/translate.py", line 318, in main [translation:info] drv.proceed(goals) [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/driver.py", line 551, in proceed [translation:info] return self._execute(goals, task_skip = self._maybe_skip()) [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/tool/taskengine.py", line 114, in _execute [translation:info] res = self._do(goal, taskcallable, *args, **kwds) [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/driver.py", line 279, in _do [translation:info] res = func() [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/driver.py", line 517, in task_compile_c [translation:info] cbuilder.compile(**kwds) [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/c/genc.py", line 376, in compile [translation:info] extra_opts) [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/platform/posix.py", line 212, in execute_makefile [translation:info] self._handle_error(returncode, stdout, stderr, path.join('make')) [translation:info] File "/export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/platform/__init__.py", line 151, in _handle_error [translation:info] raise CompilationError(stdout, stderr) [translation:ERROR] CompilationError: CompilationError(err=""" [translation:ERROR] In file included from data_pypy_module_bz2_interp_bz2.c:6:0: [translation:ERROR] forwarddecl.h:1842:66: error: field ?member1183? has incomplete type [translation:ERROR] struct pypy_pypy_objspace_std_dictmultiobject_W_DictMultiIterV0 member1183; [translation:ERROR] ^ [translation:ERROR] make: *** [data_pypy_module_bz2_interp_bz2.gcmap] Error 1 [translation:ERROR] make: *** Waiting for unfinished jobs.... [translation:ERROR] """) [translation] start debugger... > /export/scratch1/jzuiddam/pypy-4.0.1-src/rpython/translator/platform/__init__.py(151)_handle_error() -> raise CompilationError(stdout, stderr) (Pdb+) ``` What can I do? Am I missing some dependency? From issues-reply at bitbucket.org Thu Dec 31 04:36:05 2015 From: issues-reply at bitbucket.org (jiamo) Date: Thu, 31 Dec 2015 09:36:05 -0000 Subject: [pypy-issue] Issue #2220: can't install numpy: AttributeError: 'FFI' object has no attribute 'set_source' (pypy/pypy) Message-ID: <20151231093605.17106.44761@celery-worker-101.ash1.bb-inf.net> New issue 2220: can't install numpy: AttributeError: 'FFI' object has no attribute 'set_source' https://bitbucket.org/pypy/pypy/issues/2220/cant-install-numpy-attributeerror-ffi jiamo: Follow the offical guide to install numpy: ``` #!shell git clone https://bitbucket.org/pypy/numpy.git cd numpy pypy setup.py install C:\numpy>pypy setup.py install Running from numpy source directory. D:\Program Files (x86)\pypy3-2.4.0-win32\lib-python\3\distutils\dist.py:257: UserWarning: Unknown distribution option: 'test warnings.warn(msg) blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in ['C:\\'] NOT AVAILABLE openblas_info: libraries openblas not found in ['C:\\'] NOT AVAILABLE atlas_3_10_blas_threads_info: Setting PTATLAS=ATLAS libraries tatlas not found in ['C:\\'] NOT AVAILABLE atlas_3_10_blas_info: libraries satlas not found in ['C:\\'] NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in ['C:\\'] NOT AVAILABLE atlas_blas_info: libraries f77blas,cblas,atlas not found in ['C:\\'] NOT AVAILABLE C:\Users\ikfb\numpy\numpy\distutils\system_info.py:1651: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) blas_info: libraries blas not found in ['C:\\'] NOT AVAILABLE C:\Users\ikfb\numpy\numpy\distutils\system_info.py:1660: UserWarning: Blas (http://www.netlib.org/blas/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [blas]) or by setting the BLAS environment variable. warnings.warn(BlasNotFoundError.__doc__) blas_src_info: NOT AVAILABLE C:\Users\ikfb\numpy\numpy\distutils\system_info.py:1663: UserWarning: Blas (http://www.netlib.org/blas/) sources not found. Directories to search for the sources can be specified in the numpy/distutils/site.cfg file (section [blas_src]) or by setting the BLAS_SRC environment variable. warnings.warn(BlasSrcNotFoundError.__doc__) NOT AVAILABLE non-existing path in 'numpy\\distutils': 'site.cfg' F2PY Version 2 Traceback (most recent call last): File "setup.py", line 278, in setup_package() File "setup.py", line 270, in setup_package setup(**metadata) File "C:\Users\ikfb\numpy\numpy\distutils\core.py", line 135, in setup config = configuration() File "setup.py", line 171, in configuration config.add_subpackage('numpy') File "C:\Users\ikfb\numpy\numpy\distutils\misc_util.py", line 1001, in add_subpackage caller_level = 2) File "C:\Users\ikfb\numpy\numpy\distutils\misc_util.py", line 970, in get_subpackage caller_level = caller_level + 1) File "C:\Users\ikfb\numpy\numpy\distutils\misc_util.py", line 907, in _get_configuration_from_setup_py config = setup_module.configuration(*args) File "numpy\setup.py", line 15, in configuration config.add_subpackage('fft') File "C:\Users\ikfb\numpy\numpy\distutils\misc_util.py", line 1001, in add_subpackage caller_level = 2) File "C:\Users\ikfb\numpy\numpy\distutils\misc_util.py", line 970, in get_subpackage caller_level = caller_level + 1) File "C:\Users\ikfb\numpy\numpy\distutils\misc_util.py", line 907, in _get_configuration_from_setup_py config = setup_module.configuration(*args) File "numpy\fft\setup.py", line 17, in configuration from _fft_build import ffi File "numpy\fft\_fft_build.py", line 15, in ffi.set_source('numpy.fft._fft_cffi', ''' AttributeError: 'FFI' object has no attribute 'set_source' ```