From issues-reply at bitbucket.org  Fri Jul  3 13:27:38 2015
From: issues-reply at bitbucket.org (Suminda Dharmasena)
Date: Fri, 03 Jul 2015 11:27:38 -0000
Subject: [pypy-issue] Issue #2073: Windows 64 (pypy/pypy)
Message-ID: <20150703112738.5924.58381@app12.ash-private.bitbucket.org>

New issue 2073: Windows 64
https://bitbucket.org/pypy/pypy/issue/2073/windows-64

Suminda Dharmasena:

Can you iron out the issues and make a Windows 64 version of the software?



From issues-reply at bitbucket.org  Fri Jul  3 20:21:12 2015
From: issues-reply at bitbucket.org (Pete Vine)
Date: Fri, 03 Jul 2015 18:21:12 -0000
Subject: [pypy-issue] Issue #2074: Pypy3 2.4.0 translation fails (non-sse2
 backend) (pypy/pypy)
Message-ID: <20150703182112.18121.14585@app03.ash-private.bitbucket.org>

New issue 2074: Pypy3 2.4.0 translation fails (non-sse2 backend)
https://bitbucket.org/pypy/pypy/issue/2074/pypy3-240-translation-fails-non-sse2

Pete Vine:

Here's the result of trying to build pypy3 patched as per issue #2060 using pypy2 (previously patched and built accordingly):

PYPY_GC_MAX_DELTA=200MB pypy ../../rpython/bin/rpython -Ojit --jit-backend=x86-without-sse2 targetpypystandalone

[translation:info] Error:
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/translator/goal/translate.py", line 316, in main
[translation:info]     drv.proceed(goals)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/translator/driver.py", line 532, in proceed
[translation:info]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/translator/tool/taskengine.py", line 114, in _execute
[translation:info]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/translator/driver.py", line 276, in _do
[translation:info]     res = func()
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/translator/driver.py", line 359, in task_pyjitpl_lltype
[translation:info]     backend_name=self.config.translation.jit_backend, inline=True)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/jit/metainterp/warmspot.py", line 50, in apply_jit
[translation:info]     warmrunnerdesc.finish()
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/jit/metainterp/warmspot.py", line 243, in finish
[translation:info]     self.annhelper.finish()
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/annlowlevel.py", line 219, in finish
[translation:info]     self.finish_rtype()
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/annlowlevel.py", line 269, in finish_rtype
[translation:info]     rtyper.specialize_more_blocks()
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rtyper.py", line 218, in specialize_more_blocks
[translation:info]     self.specialize_block(block)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rtyper.py", line 336, in specialize_block
[translation:info]     self.translate_hl_to_ll(hop, varmapping)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rtyper.py", line 465, in translate_hl_to_ll
[translation:info]     resultvar = hop.dispatch()
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rtyper.py", line 687, in dispatch
[translation:info]     return translate_meth(self)
[translation:info]    File "<35196-codegen /home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rtyper.py:535>", line 4, in translate_op_call_args
[translation:info]     return r_arg1.rtype_call_args(hop)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rpbc.py", line 671, in rtype_call_args
[translation:info]     return self.redispatch_call(hop, call_args=True)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rpbc.py", line 698, in redispatch_call
[translation:info]     hop.llops, hop)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rclass.py", line 487, in rtype_new_instance
[translation:info]     return rinstance.new_instance(llops, classcallhop)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/lltypesystem/rclass.py", line 531, in new_instance
[translation:info]     r.convert_desc_or_const(value))
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/rmodel.py", line 116, in convert_desc_or_const
[translation:info]     return self.convert_const(desc_or_const.value)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/rtyper/lltypesystem/rpbc.py", line 158, in convert_const
[translation:info]     funcdesc = self.rtyper.annotator.bookkeeper.getdesc(value)
[translation:info]    File "/home/petevine/unpacked/pypy3-2.4.0-src/rpython/annotator/bookkeeper.py", line 394, in getdesc
[translation:info]     raise Exception("%s: %r" % (msg, pyobj))
[translation:ERROR] Exception: unexpected prebuilt constant: <staticmethod object at 0x0cd7158c>


Is there a way to continue from the Pdb+ prompt? (after some changes to the code naturally)



From issues-reply at bitbucket.org  Fri Jul  3 22:25:04 2015
From: issues-reply at bitbucket.org (Stefano Rivera)
Date: Fri, 03 Jul 2015 20:25:04 -0000
Subject: [pypy-issue] Issue #2075: pypy: Segmentation fault when printing
 unpickled generator (pypy/pypy)
Message-ID: <20150703202504.21907.70125@app06.ash-private.bitbucket.org>

New issue 2075: pypy: Segmentation fault when printing unpickled generator
https://bitbucket.org/pypy/pypy/issue/2075/pypy-segmentation-fault-when-printing

Stefano Rivera:

>From https://bugs.debian.org/786738:


```
#!python

import pickle

def f():
  yield 0

x = f()
x.next()
try:
  x.next()
except StopIteration:
  y = pickle.loads(pickle.dumps(x))
  print(y)
```

Segfaults on the print.

cPython refuses to pickle generators at all:

```
Traceback (most recent call last):
  File "test.py", line 11, in <module>
    y = pickle.loads(pickle.dumps(x))
  File "/usr/lib/python2.7/pickle.py", line 1374, in dumps
    Pickler(file, protocol).dump(obj)
  File "/usr/lib/python2.7/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/lib/python2.7/pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "/usr/lib/python2.7/copy_reg.py", line 70, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle generator objects
```




From issues-reply at bitbucket.org  Mon Jul  6 04:21:25 2015
From: issues-reply at bitbucket.org (Ruochen Huang)
Date: Mon, 06 Jul 2015 02:21:25 -0000
Subject: [pypy-issue] Issue #2076: Pyrlang float datatype dead in
 virtualiazble array when switched out with bridge (pypy/pypy)
Message-ID: <20150706022125.22956.13926@app06.ash-private.bitbucket.org>

New issue 2076: Pyrlang float datatype dead in virtualiazble array when switched out with bridge
https://bitbucket.org/pypy/pypy/issue/2076/pyrlang-float-datatype-dead-in

Ruochen Huang:

Hi all, 
The float type in Pyrlang is simply a wrapper class of RPython float type.
My test Erlang script tried to do something like sum(list(3.1415926,3.1415926,3.1415926...)), so the JIT generated a trace that extract one element from the list, and add it into the sum result, and then the next element...
On the other hand, there is a yield counter in dispatch loop, around the bytecode IS_NONEMPLY_LIST (or any other if-statement-like bytecode instruction), when the counter reduced to 0, the process (dispatch loop) will be switched out.
I also annotated the X_Register as virtualiazble to improve the accessing performance.

My situation is that, when I execute the test Erlang script with large scale, the switched-out-path will be recorded as a bridge, which ended with a finish(Constr(ptr35) ...), and the computing result will be wrong. (say computing a 1000000 length list, the result should be 3141592.65359 but I only got 18.849556).

I also tried Erlang Integer for the same function, it worked well.
Tried executing without scheduler, worked well.
Tried less scale so the switched-out-path will not be recorded as bridge, worked well.
Tried removing the virtualiable in X Register, worked well.

You can reproduce the bug by:
1. clone or pull my repository from https://hrc706 at bitbucket.org/hrc706/pyrlang.git.
2. rpython -Ojit targettest.py
3. ./targettest-c test_beam/test_pi.beam test_s 1000000 (will output 18.849556)
    ./targettest-c test_beam/test_pi.beam test_s 100000 (will output 314159.265359, as expected)
    ./targettest-c test_beam/test_pi.beam test_si 100000 (executing the test function with integers, always output the correct result)

You can also check the Erlang script source at test_beam/test_pi.erl if you like :-).




From issues-reply at bitbucket.org  Wed Jul  8 12:50:43 2015
From: issues-reply at bitbucket.org (Naoki INADA)
Date: Wed, 08 Jul 2015 10:50:43 -0000
Subject: [pypy-issue] Issue #2077: json.loads() for unicode is 5x slower
 than bytes (pypy/pypy)
Message-ID: <20150708105043.5988.55082@app01.ash-private.bitbucket.org>

New issue 2077: json.loads() for unicode is 5x slower than bytes
https://bitbucket.org/pypy/pypy/issues/2077/jsonloads-for-unicode-is-5x-slower-than

Naoki INADA:

PyPy version: 2.6.0-osx64 (fcdb94156515, May 26 2015, 12:34:34)
Benchmark: https://gist.github.com/methane/b5b1dbe181e06f0f6365



From issues-reply at bitbucket.org  Sat Jul 11 21:23:52 2015
From: issues-reply at bitbucket.org (V G)
Date: Sat, 11 Jul 2015 19:23:52 -0000
Subject: [pypy-issue] Issue #2078: py3.3: build failure (pypy/pypy)
Message-ID: <20150711192352.3787.72636@app12.ash-private.bitbucket.org>

New issue 2078: py3.3: build failure
https://bitbucket.org/pypy/pypy/issues/2078/py33-build-failure

V G:

Platform: x86-64

```? lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 15.04
Release:    15.04
Codename:   vivid
```

```
? hg summary
parent: 78498:1c0541a5be95
 Fix __qualname__ of built-in class methods.
branch: py3.3
commit: (clean)
update: (current)
```

```
[Timer] Timings:
[Timer] annotate                       ---  565.1 s
[Timer] rtype_lltype                   ---  617.6 s
[Timer] pyjitpl_lltype                 ---  145.3 s
[Timer] ===========================================
[Timer] Total:                         --- 1328.0 s
[translation:info] Error:
[translation:info]    File "/home/veegee/build/pypy/rpython/translator/goal/translate.py", line 318, in main
[translation:info]     drv.proceed(goals)
[translation:info]    File "/home/veegee/build/pypy/rpython/translator/driver.py", line 542, in proceed
[translation:info]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:info]    File "/home/veegee/build/pypy/rpython/translator/tool/taskengine.py", line 114, in _execute
[translation:info]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:info]    File "/home/veegee/build/pypy/rpython/translator/driver.py", line 277, in _do
[translation:info]     res = func()
[translation:info]    File "/home/veegee/build/pypy/rpython/translator/driver.py", line 360, in task_pyjitpl_lltype
[translation:info]     backend_name=self.config.translation.jit_backend, inline=True)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/metainterp/warmspot.py", line 48, in apply_jit
[translation:info]     **kwds)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/metainterp/warmspot.py", line 235, in __init__
[translation:info]     self.codewriter.make_jitcodes(verbose=verbose)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/codewriter/codewriter.py", line 72, in make_jitcodes
[translation:info]     self.transform_graph_to_jitcode(graph, jitcode, verbose)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/codewriter/codewriter.py", line 41, in transform_graph_to_jitcode
[translation:info]     transform_graph(graph, self.cpu, self.callcontrol, portal_jd)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/codewriter/jtransform.py", line 30, in transform_graph
[translation:info]     t.transform(graph)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/codewriter/jtransform.py", line 70, in transform
[translation:info]     self.optimize_block(block)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/codewriter/jtransform.py", line 94, in optimize_block
[translation:info]     oplist = self.rewrite_operation(op)
[translation:info]    File "/home/veegee/build/pypy/rpython/jit/codewriter/jtransform.py", line 233, in rewrite_operation
[translation:info]     " in %r" % (op, getattr(self, 'graph', '?')))
[translation:ERROR] Exception: the JIT doesn't support the operation v3592 = debug_flush() in <FunctionGraph of (rpython.rlib.rposix:1374)exit at 0x36f60480>
[translation] start debugger...
> /home/veegee/build/pypy/rpython/jit/codewriter/jtransform.py(233)rewrite_operation()
-> " in %r" % (op, getattr(self, 'graph', '?')))
```



From issues-reply at bitbucket.org  Mon Jul 13 05:13:44 2015
From: issues-reply at bitbucket.org (Alex Gaynor)
Date: Mon, 13 Jul 2015 03:13:44 -0000
Subject: [pypy-issue] Issue #2079: Behavior difference from CPython with
 mixins and __weakref__ (pypy/pypy)
Message-ID: <20150713031344.27983.97782@app09.ash-private.bitbucket.org>

New issue 2079: Behavior difference from CPython with mixins and __weakref__
https://bitbucket.org/pypy/pypy/issues/2079/behavior-difference-from-cpython-with

Alex Gaynor:

Given this code:

```python
class _BaseAddress(object):
    pass


class _BaseV4(object):
    __slots__ = ()


class IPv4Address(_BaseV4, _BaseAddress):
    __slots__ = ('__weakref__',)
```

CPython 2.7.10 has no problem, but PyPy gives:

```pytb
Traceback (most recent call last):
  File "<builtin>/app_main.py", line 75, in run_toplevel
  File "ipaddress.py", line 9, in <module>
    class IPv4Address(_BaseV4, _BaseAddress):
TypeError: __weakref__ slot disallowed: we already got one
```

This breaks the `ipaddress` package from PyPI.



From issues-reply at bitbucket.org  Wed Jul 15 06:55:43 2015
From: issues-reply at bitbucket.org (HawkOwl)
Date: Wed, 15 Jul 2015 04:55:43 -0000
Subject: [pypy-issue] Issue #2080: _sqlite3_build.py on FreeBSD doesn't obey
 LDFLAGS et al (pypy/pypy)
Message-ID: <20150715045543.27663.86319@app10.ash-private.bitbucket.org>

New issue 2080: _sqlite3_build.py on FreeBSD doesn't obey LDFLAGS et al
https://bitbucket.org/pypy/pypy/issues/2080/_sqlite3_buildpy-on-freebsd-doesnt-obey

HawkOwl:

I'm packaging with:

```
cd /tmp/pypy-build/pypy/tool/release
export CPPFLAGS=\"-I/opt/crossbar/include -O3 -march=core2 -mtune=generic\" CXX=\"clang++36\" CFLAGS=\"-I/opt/crossbar/include -O3 -march=core2 -mtune=generic\" LDFLAGS=\"-L/opt/crossbar/lib -Wl,-s -Wl,-rpath,/opt/crossbar/lib\" CC=\"clang36\" PKG_CONFIG_PATH=\"/opt/crossbar/lib/pkgconfig/\"
/usr/bin/env python2 package.py --without-tk --archive-name pypy_built --targetdir ~/
```

`/opt/crossbar/lib` contains:
```
lrwxr-xr-x  1 crossbar  wheel       19 Jul 14 14:55 libsqlite3.so -> libsqlite3.so.0.8.6
lrwxr-xr-x  1 crossbar  wheel       19 Jul 14 14:55 libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rwxr-xr-x  1 crossbar  wheel  1229776 Jul 14 14:55 libsqlite3.so.0.8.6
```

`/opt/crossbar/include` contains:
```
-rw-r--r--  1 crossbar  wheel  378697 Jul 14 14:55 sqlite3.h
-rw-r--r--  1 crossbar  wheel   27763 Jul 14 14:55 sqlite3ext.h
```

If I don't have sqlite3 on the system, it says it can't find sqlite. If I install global sqlite, then compile it, and run `ldd`, it says:
```
pypy_built/lib_pypy/_sqlite3_cffi.pypy-26.so:
        libsqlite3.so.0 => /opt/crossbar/lib/libsqlite3.so.0 (0x801609000)
        libc.so.7 => /lib/libc.so.7 (0x80081f000)
        libthr.so.3 => /lib/libthr.so.3 (0x801935000)
```

So the build can't find the local lib, but it links against it anyway if there's the global one?




From issues-reply at bitbucket.org  Thu Jul 16 03:45:05 2015
From: issues-reply at bitbucket.org (heiher)
Date: Thu, 16 Jul 2015 01:45:05 -0000
Subject: [pypy-issue] Issue #2081: stacklet: Add support for mips64
	(pypy/pypy)
Message-ID: <20150716014505.20152.55383@app03.ash-private.bitbucket.org>

New issue 2081: stacklet: Add support for mips64
https://bitbucket.org/pypy/pypy/issues/2081/stacklet-add-support-for-mips64

heiher:

Hi,

This patch add stacklet support for mips64.



From issues-reply at bitbucket.org  Thu Jul 16 13:56:13 2015
From: issues-reply at bitbucket.org (Jelle Smet)
Date: Thu, 16 Jul 2015 11:56:13 -0000
Subject: [pypy-issue] Issue #2082: Cannot import syslog module (pypy/pypy)
Message-ID: <20150716115613.7297.65012@app09.ash-private.bitbucket.org>

New issue 2082: Cannot import syslog module
https://bitbucket.org/pypy/pypy/issues/2082/cannot-import-syslog-module

Jelle Smet:

Compiling pypy-2.6.0 from source using


```
#!bash

pypy ../../rpython/bin/rpython -Ojit targetpypystandalone
```


Works as exepected no errors returned.
When starting the interpreter and import **syslog** I get:


```
#!python

Python 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jul 15 2015, 19:42:38)
[PyPy 2.6.0 with GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import syslog
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/smetj/data/python/source/pypy-2.6.0-src/lib_pypy/syslog.py", line 16, in <module>
    from _syslog_cffi import ffi, lib
ImportError: No module named _syslog_cffi
>>>> 
```

Other 




From issues-reply at bitbucket.org  Fri Jul 17 10:18:42 2015
From: issues-reply at bitbucket.org (David MacIver)
Date: Fri, 17 Jul 2015 08:18:42 -0000
Subject: [pypy-issue] Issue #2083: type(None).__repr__(None) gives type
	error (pypy/pypy)
Message-ID: <20150717081842.27650.8407@app03.ash-private.bitbucket.org>

New issue 2083: type(None).__repr__(None) gives type error
https://bitbucket.org/pypy/pypy/issues/2083/type-none-__repr__-none-gives-type-error

David MacIver:

This should return "None" and does on CPython 2.7.10, but on pypy it instead gives a TypeError:

```
>>>> type(None).__repr__(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __repr__() takes exactly 1 argument (2 given)
```



From issues-reply at bitbucket.org  Fri Jul 17 13:58:57 2015
From: issues-reply at bitbucket.org (Tobias Pape)
Date: Fri, 17 Jul 2015 11:58:57 -0000
Subject: [pypy-issue] Issue #2084: PyPy crash on (probably) negative index
 access (pypy/pypy)
Message-ID: <20150717115857.14650.38617@app07.ash-private.bitbucket.org>

New issue 2084: PyPy crash on (probably) negative index access
https://bitbucket.org/pypy/pypy/issues/2084/pypy-crash-on-probably-negative-index

Tobias Pape:

Assertion Hit in CPython:

```
Exception: 
Traceback (most recent call last):
  File "targetrsqueak.py", line 320, in <module>
    sys.exit(f(sys.argv))
  File "targetrsqueak.py", line 92, in safe_entry_point
    return entry_point(argv)
  File "targetrsqueak.py", line 232, in entry_point
    w_result = execute_context(interp, context)
  File "targetrsqueak.py", line 304, in execute_context
    return interp.interpret_toplevel(s_frame.w_self())
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/interpreter.py", line 282, in interpret_toplevel
    self.loop(w_frame)
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/interpreter.py", line 125, in loop
    self.stack_frame(s_context, None)
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/interpreter.py", line 150, in stack_frame
    self.loop_bytecodes(s_frame, may_context_switch)
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/interpreter.py", line 189, in loop_bytecodes
    self.step(s_context)
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/interpreter.py", line 223, in step
    return getattr(context, methname)(self, bytecode)
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/interpreter_bytecodes.py", line 35, in bytecode_implementation_wrapper
    return actual_implementation_method(self, interp, current_bytecode, *parameters)
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/interpreter_bytecodes.py", line 457, in returnTopFromMethodBytecode
    return self._return(self.pop(), interp)
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/storage_contexts.py", line 409, in pop
    ret = self.stack_get(ptr)   # you get OverflowError if the stack is empty
  File "/Users/tobias/dev/pypy/lang-smalltalk/spyvm/storage_contexts.py", line 394, in stack_get
    assert index0 >= 0
AssertionError
[12] > /Users/tobias/dev/pypy/lang-smalltalk/spyvm/storage_contexts.py(394)stack_get()
-> assert index0 >= 0
(Pdb++) index0
-1
```

LLDB backtrace for Segfault with pypy (__32bit build OSX__, but also happens on Win32)
(
Python 2.7.9 (9c4588d731b7fe0b08669bd732c2b676cb0a8233, Apr 22 2015, 12:13:28)
[PyPy 2.5.1 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]
)

````
* thread #1: tid = 0x4f719c, 0x0032e2b7 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0xbf7fffec)
    frame #0: 0x0032e2b7 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 7
libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 7:
-> 0x32e2b7:  calll  0x32e2bc                  ; pypy_g__flat_pycall__AccessDirect_None + 12
   0x32e2bc:  popl   %edi
   0x32e2bd:  movl   0x40(%esp), %eax
   0x32e2c1:  movl   0x24(%eax), %ecx
(lldb) bt
* thread #1: tid = 0x4f719c, 0x0032e2b7 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0xbf7fffec)
  * frame #0: 0x0032e2b7 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 7
    frame #1: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #2: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #3: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #4: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #5: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #6: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #7: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #8: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #9: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #10: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #11: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #12: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #13: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #14: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #15: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #16: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #17: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #18: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #19: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #20: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #21: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #22: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #23: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #24: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #25: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #26: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #27: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #28: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #29: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #30: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #31: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #32: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #33: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #34: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #35: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #36: 0x0035de8c libpypy-c.dylib`pypy_g_CALL_FUNCTION__AccessDirect_None + 124
    frame #37: 0x0035887a libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 12426
    frame #38: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #39: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #40: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #41: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #42: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #43: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #44: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #45: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #46: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #47: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #48: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #49: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #50: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #51: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #52: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #53: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #54: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #55: 0x0034175e libpypy-c.dylib`pypy_g_PyCode_funcrun + 670
    frame #56: 0x00326984 libpypy-c.dylib`pypy_g_Function_call_args + 68
    frame #57: 0x008645ee libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 1870
    frame #58: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #59: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #60: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #61: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #62: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #63: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #64: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #65: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #66: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #67: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #68: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #69: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #70: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #71: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #72: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #73: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #74: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #75: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #76: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #77: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #78: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #79: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #80: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #81: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #82: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #83: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #84: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #85: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #86: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #87: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #88: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #89: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #90: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #91: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #92: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #93: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #94: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #95: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #96: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #97: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #98: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #99: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #100: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #101: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #102: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #103: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #104: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #105: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #106: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #107: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #108: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #109: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #110: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #111: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #112: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #113: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #114: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #115: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #116: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #117: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #118: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #119: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #120: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #121: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #122: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #123: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #124: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #125: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #126: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #127: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #128: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #129: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #130: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #131: 0x0032e564 libpypy-c.dylib`pypy_g__flat_pycall__AccessDirect_None + 692
    frame #132: 0x0032d84e libpypy-c.dylib`pypy_g_funccall_valuestack__AccessDirect_None + 350
    frame #133: 0x0030ec38 libpypy-c.dylib`pypy_g_call_valuestack__AccessDirect_None + 552
    frame #134: 0x00863f8d libpypy-c.dylib`pypy_g_CALL_METHOD__AccessDirect_star_1 + 237
    frame #135: 0x00358d54 libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 13668
    frame #136: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #137: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #138: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #139: 0x0080046f libpypy-c.dylib`pypy_g_PyFrame_dispatch + 47
    frame #140: 0x00349724 libpypy-c.dylib`pypy_g_PyFrame_execute_frame + 1348
    frame #141: 0x00348f3a libpypy-c.dylib`pypy_g_PyFrame_run + 218
    frame #142: 0x0034175e libpypy-c.dylib`pypy_g_PyCode_funcrun + 670
    frame #143: 0x000a5fc6 libpypy-c.dylib`pypy_g_call_stub + 38
    frame #144: 0x00ad8e0c libpypy-c.dylib`pypy_g_handler_inline_call_r_r + 716
    frame #145: 0x00ad034a libpypy-c.dylib`pypy_g_dispatch_loop + 3050
    frame #146: 0x00acf16d libpypy-c.dylib`pypy_g_BlackholeInterpreter_run + 93
    frame #147: 0x00ace3e4 libpypy-c.dylib`pypy_g_BlackholeInterpreter__resume_mainloop + 100
    frame #148: 0x00ace179 libpypy-c.dylib`pypy_g__run_forever + 105
    frame #149: 0x00af58e9 libpypy-c.dylib`pypy_g_ResumeGuardDescr_handle_fail + 505
    frame #150: 0x00cb7ce5 libpypy-c.dylib`pypy_g_execute_assembler__star_2_2 + 453
    frame #151: 0x00cb7435 libpypy-c.dylib`pypy_g_maybe_compile_and_run__star_5 + 981
    frame #152: 0x00800634 libpypy-c.dylib`pypy_g_jump_absolute__AccessDirect_None + 100
    frame #153: 0x00359b5e libpypy-c.dylib`pypy_g_dispatch_bytecode__AccessDirect_None + 17262
    frame #154: 0x00355408 libpypy-c.dylib`pypy_g_handle_bytecode__AccessDirect_None + 72
    frame #155: 0x008004f6 libpypy-c.dylib`pypy_g_portal_3 + 118
    frame #156: 0x00c735a9 libpypy-c.dylib`pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter + 569
    frame #157: 0x00c79ca1 libpypy-c.dylib`pypy_g_handle_jitexception_3 + 97
    frame #158: 0x00c79b89 libpypy-c.dylib`pypy_g_assembler_call_helper_3 + 217
````



From issues-reply at bitbucket.org  Sat Jul 18 22:52:58 2015
From: issues-reply at bitbucket.org (Ronan Lamy)
Date: Sat, 18 Jul 2015 20:52:58 -0000
Subject: [pypy-issue] Issue #2085: Mistranslation on PyPy when mixing
 properties and regular attributes (pypy/pypy)
Message-ID: <20150718205258.8095.81866@app01.ash-private.bitbucket.org>

New issue 2085: Mistranslation on PyPy when mixing properties and regular attributes
https://bitbucket.org/pypy/pypy/issues/2085/mistranslation-on-pypy-when-mixing

Ronan Lamy:

Cf. test added in f7292d9

This works on CPython, by raising UnionError, but gets silently translated to something wrong on PyPy.



From issues-reply at bitbucket.org  Mon Jul 20 12:16:51 2015
From: issues-reply at bitbucket.org (Jelle Smet)
Date: Mon, 20 Jul 2015 10:16:51 -0000
Subject: [pypy-issue] Issue #2086: Unable to compile on Alpine Linux
	(pypy/pypy)
Message-ID: <20150720101651.31865.66963@app10.ash-private.bitbucket.org>

New issue 2086: Unable to compile on Alpine Linux
https://bitbucket.org/pypy/pypy/issues/2086/unable-to-compile-on-alpine-linux

Jelle Smet:

Hi all,

When compiling pypy-2.6.0 from source on Alpine Linux (inside container) I run into following error:


```
#!text

... snip ...

[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-2.6.0-1/testing_1/testing_1.c
[694d6] translation-task}
[translation:info] Compiling c source...
[694d6] {translation-task
starting compile_c
[platform:execute] make  in /tmp/usession-release-2.6.0-1/testing_1


[platform:Error] In file included from common_header.h:116:0,
[platform:Error]                  from testing_1.c:1:
[platform:Error] /usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]
[platform:Error]  #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
[platform:Error]   ^
[platform:Error] In file included from common_header.h:116:0,
[platform:Error]                  from data_pypy_goal_targetpypystandalone.c:4:
[platform:Error] /usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]
[platform:Error]  #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
[platform:Error]   ^
[platform:Error] In file included from common_header.h:185:0,
[platform:Error]                  from testing_1.c:1:

...snip...

[translation:ERROR]     In file included from common_header.h:116:0,
[translation:ERROR]                      from rpython_translator_exceptiontransform.c:4:
[translation:ERROR]     /usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]
[translation:ERROR]      #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
[translation:ERROR]       ^
[translation:ERROR]     In file included from common_header.h:185:0,
[translation:ERROR]                      from rpython_translator_exceptiontransform.c:4:
[translation:ERROR]     /usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]
[translation:ERROR]      #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
[translation:ERROR]       ^
[translation:ERROR]     modsupport.c: In function 'va_build_value':
[translation:ERROR]     modsupport.c:452:9: error: assignment to expression with array type
[translation:ERROR]          lva = va;
[translation:ERROR]              ^
[translation:ERROR]     make: *** [modsupport.gcmap] Error 1
[translation:ERROR]     make: *** Waiting for unfinished jobs....
[translation:ERROR]     """)
[translation] start debugger...
> /home/smetj/pypy/src/pypy-2.6.0-src/rpython/translator/platform/__init__.py(151)_handle_error()
-> raise CompilationError(stdout, stderr)
(Pdb+) 
```
Please let me know if more info is required.



From issues-reply at bitbucket.org  Mon Jul 20 17:26:47 2015
From: issues-reply at bitbucket.org (Richard Plangger)
Date: Mon, 20 Jul 2015 15:26:47 -0000
Subject: [pypy-issue] Issue #2087: NumPy Any/All character and (pypy/pypy)
Message-ID: <20150720152647.18806.17271@app12.ash-private.bitbucket.org>

New issue 2087: NumPy Any/All character and
https://bitbucket.org/pypy/pypy/issues/2087/numpy-any-all-character-and

Richard Plangger:

>>> numpy.all([1,2,256]*1000) # pypy 2.6.0
False
>>> numpy.all([1,2,256]*1000) # python 2.7.10
True

That is the trace:

label(p27, i26, p1, i32, i9, i33, descr=TargetToken(51234744))
(numpy_reduce: no get_printable_location)
guard_early_exit(descr=<Guard0x26ca860>)
i36 = raw_load(i9, i32, descr=<ArrayS 8>)
guard_not_invalidated(descr=<Guard0x26ca8c0>)
i37 = i36 & 255
guard(i37 is true)
i38 = getarrayitem_raw(140216103876730, 1, descr=<ArrayU 1>)
guard(i38 == 0)
i39 = getarrayitem_raw(140216103876728, 0, descr=<ArrayU 1>)
i40 = i26 + 1
i41 = i32 + 8
i42 = i40 >= i33
guard(i42 is false) show bridge  (run 9800 times, ~0%)
guard(i39 == 1)
(numpy_reduce: no get_printable_location)
jump(p27, i40, p1, i41, i9, i33, descr=TargetToken(51234744))



From issues-reply at bitbucket.org  Mon Jul 20 21:01:10 2015
From: issues-reply at bitbucket.org (lesshaste)
Date: Mon, 20 Jul 2015 19:01:10 -0000
Subject: [pypy-issue] Issue #2088: automatic casting does not work in linalg
	(pypy/pypy)
Message-ID: <20150720190110.7417.17006@app04.ash-private.bitbucket.org>

New issue 2088: automatic casting does not work in linalg
https://bitbucket.org/pypy/pypy/issues/2088/automatic-casting-does-not-work-in-linalg

lesshaste:

In ipython the following works

ipython
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
Type "copyright", "credits" or "license" for more information.

IPython 1.2.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import numpy

In [2]: A =  [[1,0],[0,1]]

In [3]: numpy.linalg.det(A)
Out[3]: 1.0


but in Python 2.7.9 (2.6.0+dfsg-1~ppa0+ubuntu14.04, Jun 08 2015, 14:48:00)  with numpy from July 20 it doesn't.

pypy-numpy/bin/pypy 
Python 2.7.9 (2.6.0+dfsg-1~ppa0+ubuntu14.04, Jun 08 2015, 14:48:00)
[PyPy 2.6.0 with GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy
>>>> A =  [[1,0],[0,1]]
>>>> numpy.linalg.det(A)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/pypy-numpy/site-packages/numpy/linalg/linalg.py", line 1734, in det
    return _umath_linalg.det(a, signature=signature).astype(result_t)
TypeError: input dtype [=i8,None,] did not match any known dtypes [=f4,=f4,=f8,=f8,=c8,=f4,=c16,=f8]



From issues-reply at bitbucket.org  Tue Jul 21 05:18:13 2015
From: issues-reply at bitbucket.org (Jay Oster)
Date: Tue, 21 Jul 2015 03:18:13 -0000
Subject: [pypy-issue] Issue #2089: Crash in PyPy 2.6.0 (linux64) with gevent
 1.1b1 (pypy/pypy)
Message-ID: <20150721031813.6748.95028@app05.ash-private.bitbucket.org>

New issue 2089: Crash in PyPy 2.6.0 (linux64) with gevent 1.1b1
https://bitbucket.org/pypy/pypy/issues/2089/crash-in-pypy-260-linux64-with-gevent-11b1

Jay Oster:

Minimal test case to reproduce: https://gist.github.com/parasyte/b3e0f80b81a9c7b291d3

Requires gevent 1.1b1:

```
#!bash

$ pip install --upgrade pip setuptools
$ pip install gevent==1.1b1
```

Occurs on pypy-2.6.0-linux64 (not on OSX). Earlier versions of PyPy are not affected.

While building this minimal test case, I determined that the crash is dependent on stack depth, which the `depth` function exploits with recursion.

`gevent.monkey.patch_builtins()` is new to 1.1b1, and patches `__import__` to operate atomically with a reentrant lock. This may be a gevent bug (I will file a ticket for their tracker as well.)

I've seen two different stack traces from RPython with this test case, just keep running it until and you'll eventually see both.

```
Fatal error in cpyext, CPython compatibility layer, calling PyObject_GetItem
Either report a bug or consider not using this particular extension
<OperationError object at 0x7f482cd96940>
RPython traceback:
  File "pypy_module_pypyjit_interp_jit.c", line 340, in portal_5
  File "pypy_interpreter_pyopcode.c", line 3578, in handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 5853, in dispatch_bytecode__AccessDirect_None
Segmentation fault (core dumped)
```

And this one less frequently:

```
Fatal error in cpyext, CPython compatibility layer, calling PyObject_GetItem
Either report a bug or consider not using this particular extension
<OperationError object at 0x7f4ff4e9df00>
RPython traceback:
  File "pypy_module_cpyext_api_1.c", line 17394, in PyPyObject_GetItem
  File "pypy_module_cpyext_pyobject.c", line 850, in make_ref
  File "pypy_module_cpyext_pyobject.c", line 1854, in create_ref
  File "pypy_module_cpyext_pyobject.c", line 4587, in BaseCpyTypedescr_allocate
  File "pypy_module_cpyext_pyobject.c", line 850, in make_ref
  File "pypy_module_cpyext_pyobject.c", line 1738, in create_ref
  File "pypy_module_cpyext_typeobject.c", line 35294, in type_attach
  File "pypy_objspace_std_objspace.c", line 1038, in getattr
  File "pypy_interpreter_gateway.c", line 846, in BuiltinCode2_fastcall_2
  File "pypy_interpreter_gateway.c", line 2779, in BuiltinCode_handle_exception
Segmentation fault (core dumped)
```



From issues-reply at bitbucket.org  Tue Jul 21 17:15:53 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Tue, 21 Jul 2015 15:15:53 -0000
Subject: [pypy-issue] Issue #2090: numpy: RPython OverflowError (pypy/pypy)
Message-ID: <20150721151553.7633.91517@app07.ash-private.bitbucket.org>

New issue 2090: numpy: RPython OverflowError
https://bitbucket.org/pypy/pypy/issues/2090/numpy-rpython-overflowerror

Armin Rigo:

``_numpypy.multiarray.ndarray([1,2,256]*10000)`` -> RPython fatal error: OverflowError



From issues-reply at bitbucket.org  Tue Jul 21 22:27:12 2015
From: issues-reply at bitbucket.org (Jason Madden)
Date: Tue, 21 Jul 2015 20:27:12 -0000
Subject: [pypy-issue] Issue #2091: non-blocking socket.send slow (gevent)
	(pypy/pypy)
Message-ID: <20150721202712.11255.69541@app07.ash-private.bitbucket.org>

New issue 2091: non-blocking socket.send slow (gevent)
https://bitbucket.org/pypy/pypy/issues/2091/non-blocking-socketsend-slow-gevent

Jason Madden:

gevent implements a blocking `socket.sendall` for non-blocking sockets with a simple loop over `socket.send`, catching EWOULDBLOCK as needed. (This isn't necessarily specific to gevent, of course.) In benchmarks, this is substantially slower under PyPy than it is under CPython, around 5 to 6 times slower.

Here's a small example that reproduces the problem; start the script once with an argument to be the server and put it in the background, then again to be the client. (This is a simplified, non-gevent version of [a benchmark Denis wrote](https://github.com/gevent/gevent/blob/master/greentest/bench_sendall.py); it's the only benchmark that PyPy is outperformed by CPython.)

```python
#! /usr/bin/env python
from __future__ import print_function
import sys
import time
import socket


def serve():
	server = socket.socket()
	server.bind(("127.0.0.1", 9999))
	server.listen(1)
	while True:
		client, _ = server.accept()

		while client.recv(4096):
			pass


def _sendall(conn, data):
	data_memory = memoryview(data) # if memoryview is left out, CPython gets slow; makes no diff to PyPy
	len_data_memory = len(data_memory)
	data_sent = 0
	while data_sent < len_data_memory:
		try:
			data_sent += conn._sock.send(data_memory[data_sent:])
		except socket.error as ex:
			if ex.args[0] == 35: # EWOULDBLOCK
				continue
			raise

def main():
	length = 50 * 0x100000
	data = b"x" * length
	spent_total = 0


	conn = socket.create_connection(("", 9999))
	conn._sock.setblocking(0) # non-blocking is crucial

	N = 20
	for i in range(N):
		start = time.time()
		_sendall(conn, data)
		spent = time.time() - start
		print("%.2f MB/s" % (length / spent / 0x100000))
		spent_total += spent

	print("~ %.2f MB/s" % (length * N / spent_total / 0x100000))


if __name__ == "__main__":
	if len(sys.argv) > 1:
		serve()
	else:
		main()
```

On one machine, CPython sends at ~ 1160MB/s, while PyPy 2.6/2.7 sends at ~150MB/s. 

The _sendall function is a simplified version of what gevent actually uses to implement `socket.sendall`. 

Interestingly, on CPython, if you take out the call to `memoryview` and instead pass the raw string argument to `socket.send`, it performs similarly to PyPy. This leads me to guess that it's something to do with pinning the buffer in memory repeatedly that's slowing PyPy down. 

I've tried variations on how the data gets sliced to no avail. I have found that increasing the socket's SO_SNDBUF increases performance---using a very large buffer gets us about halfway to CPython performance.

Is there anything I can do as a maintainer of gevent to improve the performance of `socket.sendall`? I'm not against using PyPy internal functions, I just couldn't find any to use :) Or should I recommend that users set large write buffers on their sockets? Or is this a "bug" in PyPy that can be improved?



From issues-reply at bitbucket.org  Wed Jul 22 01:43:31 2015
From: issues-reply at bitbucket.org (Ned Batchelder)
Date: Tue, 21 Jul 2015 23:43:31 -0000
Subject: [pypy-issue] Issue #2092: assertCountEqual gets wrong answer with
 list of tuples (pypy/pypy)
Message-ID: <20150721234331.3692.92946@app03.ash-private.bitbucket.org>

New issue 2092: assertCountEqual gets wrong answer with list of tuples
https://bitbucket.org/pypy/pypy/issues/2092/assertcountequal-gets-wrong-answer-with

Ned Batchelder:

With PyPy 3.2.5 (pypy 2.4.0.final.0), this code passes the first assertCountEqual, but fails on the second:
```
import unittest

d = [tuple(t) for t in [[1, 2], [3, -1], [2, 3], [-1, 1]]]

tc = unittest.TestCase()
tc.assertCountEqual(
    [(1, 2), (3, -1), (2, 3), (-1, 1)],
    [(-1, 1), (1, 2), (2, 3), (3, -1)]
    )
tc.assertCountEqual(
    d,
    [(-1, 1), (1, 2), (2, 3), (3, -1)]
    )
```
Output:
```
$ .tox/pypy3_24/bin/python foo.py
Traceback (most recent call last):
  File "foo.py", line 12, in <module>
    [(-1, 1), (1, 2), (2, 3), (3, -1)]
  File "/usr/local/pythonz/pythons/PyPy3-2.4.0/lib-python/3/unittest/case.py", line 1028, in assertCountEqual
    self.fail(msg)
  File "/usr/local/pythonz/pythons/PyPy3-2.4.0/lib-python/3/unittest/case.py", line 494, in fail
    raise self.failureException(msg)
AssertionError: Element counts were not equal:
First has 1, Second has 0:  (3, -1)
First has 1, Second has 0:  (-1, 1)
First has 0, Second has 1:  (-1, 1)
First has 0, Second has 1:  (3, -1)
```



From issues-reply at bitbucket.org  Wed Jul 22 15:57:55 2015
From: issues-reply at bitbucket.org (Tobias Pape)
Date: Wed, 22 Jul 2015 13:57:55 -0000
Subject: [pypy-issue] Issue #2093: PyPy 2.6.0 32bit on OSX has too large
	maxint. (pypy/pypy)
Message-ID: <20150722135755.23624.48326@app01.ash-private.bitbucket.org>

New issue 2093: PyPy 2.6.0 32bit on OSX has too large maxint.
https://bitbucket.org/pypy/pypy/issues/2093/pypy-260-32bit-on-osx-has-too-large-maxint

Tobias Pape:

For PyPy 2.5.1:
````
$ file bin/pypy-c-2.5.1 
bin/pypy-c-2.5.1: Mach-O executable i386
$ bin/pypy-c-2.5.1 
Python 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jul 20 2015, 10:00:51)
[PyPy 2.6.0 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``1.1 final released:
http://codespeak.net/pypy/dist/pypy/doc/release-1.1.0.html''
>>>> import sys
>>>> sys.maxint
2147483647
````

For PyPy 2.6.0:
````
$ bin/pypy-c-2.6.0
bin/pypy-c-2.6.0: Mach-O executable i386
$ bin/pypy-c-2.6.0
Python 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jun 02 2015, 18:28:40)
[PyPy 2.6.0 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.
And now for something completely different: ``running tests is essential for
developing pypy -- uh? did I break the test? (fijal)''
>>>> import sys
>>>> sys.maxint
9223372036854775807
````

The latter should be not a number >32bit.




From issues-reply at bitbucket.org  Wed Jul 22 17:54:25 2015
From: issues-reply at bitbucket.org (mattip)
Date: Wed, 22 Jul 2015 15:54:25 -0000
Subject: [pypy-issue] Issue #2094: crash in nightly -A tests,
 somewhere in micronumpy? (pypy/pypy)
Message-ID: <20150722155425.23426.52873@app02.ash-private.bitbucket.org>

New issue 2094: crash in nightly -A tests, somewhere in micronumpy?
https://bitbucket.org/pypy/pypy/issues/2094/crash-in-nightly-a-tests-somewhere-in

mattip:

http://buildbot.pypy.org/summary/longrepr?testname=&builder=pypy-c-jit-linux-x86-32&build=2764&mod=module%2Fmicronumpy%2Ftest

I can reproduce only on the first run of a fresh unzip of the nightly, after that the tests pass 

``../pypy-c-jit-78634-b0a67e1d9a20-linux64/bin/pypy pytest.py -A pypy/module/micronumpy/test/test_ndarray.py``



From issues-reply at bitbucket.org  Wed Jul 22 23:34:52 2015
From: issues-reply at bitbucket.org (kmod)
Date: Wed, 22 Jul 2015 21:34:52 -0000
Subject: [pypy-issue] Issue #2095: type(obj) should not call obj's
 metaclass's __getattribute__ (pypy/pypy)
Message-ID: <20150722213452.20471.58591@app01.ash-private.bitbucket.org>

New issue 2095: type(obj) should not call obj's metaclass's __getattribute__
https://bitbucket.org/pypy/pypy/issues/2095/type-obj-should-not-call-objs-metaclasss

kmod:

Not really sure what's going on here, but this code produces different output between CPython  (2.7.6) and PyPy (2.6.0):

```
class M(type):
    def __getattribute__(self, attr):
        print "getattribute", attr
        raise Exception()

class C(object):
    __metaclass__ = M

c = C()
print type(c)
```

PyPy calls `__getattribute__("__class__")` but cpython does not.  Not sure why the exception doesn't get propagated or the return value (if one was generated) gets ignored.



From issues-reply at bitbucket.org  Wed Jul 22 23:39:49 2015
From: issues-reply at bitbucket.org (kmod)
Date: Wed, 22 Jul 2015 21:39:49 -0000
Subject: [pypy-issue] Issue #2096: isinstance(obj,
 cls) should not call __instancecheck__ if type(obj)==cls (pypy/pypy)
Message-ID: <20150722213949.20400.77725@app04.ash-private.bitbucket.org>

New issue 2096: isinstance(obj, cls) should not call __instancecheck__ if type(obj)==cls
https://bitbucket.org/pypy/pypy/issues/2096/isinstance-obj-cls-should-not-call

kmod:

CPython fast-paths this case to always return true.  Seems like probably user error if instancecheck returns false for instances of that type :P but it's still a difference:

```
class M(type):
    def __instancecheck__(self, obj):
        print "instancecheck", type(obj)
        return False

class C(object):
    __metaclass__ = M

class D(C):
    pass

d = D()
print isinstance(d, C) # should call instancecheck
print isinstance(d, D) # should not call instancecheck
```

In the second isinstance(), CPython (2.7.6) doesn't call instancecheck, but PyPy (2.6.0) does.



From issues-reply at bitbucket.org  Fri Jul 24 04:00:10 2015
From: issues-reply at bitbucket.org (David MacIver)
Date: Fri, 24 Jul 2015 02:00:10 -0000
Subject: [pypy-issue] Issue #2097: Occasional KeyError in sqlite3 driver
	(pypy/pypy)
Message-ID: <20150724020010.661.31818@app01.ash-private.bitbucket.org>

New issue 2097: Occasional KeyError in sqlite3 driver
https://bitbucket.org/pypy/pypy/issues/2097/occasional-keyerror-in-sqlite3-driver

David MacIver:

I'm not sure what's changed (it would be on my end rather than yours), but recently I've been seeing the following exception every now and then in the Hypothesis django tests - it only happens every few days and I don't have a reproducible test case, but I thought I'd mention it speculatively in case it was obvious to someone what was going on.

I'm only seeing this on pypy, and a KeyError is the sort of thing that shouldn't escape closing an sqlite3 connection, so there's definitely a bug in here somewhere.

This is running pypy 2.6.0 on linux (specifically on Travis).

```
ImportError: Failed to import test module: tests.django.toystore.test_fixtures
Traceback (most recent call last):
  File "/home/travis/.pyenv/versions/pypy-2.6.0/lib-python/2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/home/travis/.pyenv/versions/pypy-2.6.0/lib-python/2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "tests/django/toystore/test_fixtures.py", line 55, in <module>
    lambda x: x.store_set.count() >= 2
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/hypothesis/extra/django/fixtures.py", line 102, in fixture
    return Fixture(strategy, constraint, execute)
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/hypothesis/extra/django/fixtures.py", line 51, in __init__
    self._set_template()
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/hypothesis/extra/django/fixtures.py", line 74, in _set_template
    verbosity=verbosity, interactive=False
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/django/test/runner.py", line 370, in setup_databases
    serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE", True),
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/django/db/backends/base/creation.py", line 356, in create_test_db
    self.connection.close()
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/django/db/backends/sqlite3/base.py", line 226, in close
    BaseDatabaseWrapper.close(self)
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/django/db/backends/base/base.py", line 198, in close
    self._close()
  File "/home/travis/build/DRMacIver/hypothesis/.tox/pypy/site-packages/django/db/backends/base/base.py", line 152, in _close
    return self.connection.close()
  File "/home/travis/.pyenv/versions/pypy-2.6.0/lib_pypy/_sqlite3.py", line 256, in close
    self._finalize_raw_statement(stmt)
  File "/home/travis/.pyenv/versions/pypy-2.6.0/lib_pypy/_sqlite3.py", line 348, in _finalize_raw_statement
    self.__rawstatements.remove(_statement)
KeyError: <cdata 'sqlite3_stmt *' 0x3995dc8>
```



From issues-reply at bitbucket.org  Fri Jul 24 14:55:05 2015
From: issues-reply at bitbucket.org (Patrick Varley)
Date: Fri, 24 Jul 2015 12:55:05 -0000
Subject: [pypy-issue] Issue #2098: Segfault in
 pypy_g_IncrementalMiniMarkGC_visit (pypy/pypy)
Message-ID: <20150724125505.8329.19172@app05.ash-private.bitbucket.org>

New issue 2098: Segfault  in pypy_g_IncrementalMiniMarkGC_visit
https://bitbucket.org/pypy/pypy/issues/2098/segfault-in

Patrick Varley:

# Environment #

* OS: OS X 10.10.4 (14E46)
* Python: 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jun 02 2015, 18:26:45)
* Pypy: PyPy 2.6.0 with GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) Pypy was installed from homebrew.

# Problem #
I have a script that run successfully with Pypy 2.5.1, when I upgrade to Pypy 2.6.0, it sometimes produces a segfaults.

Here is the backtrace from the core dump:

```
(lldb) target create "/usr/local/bin/pypy" --core "/cores/core.59563"
warning: (x86_64) /cores/core.59563 load command 295 LC_SEGMENT_64 has a fileoff + filesize (0x2af9a000) that extends beyond the end of the file (0x2af99000), the segment will be truncated to match
warning: (x86_64) /cores/core.59563 load command 296 LC_SEGMENT_64 has a fileoff (0x2af9a000) that extends beyond the end of the file (0x2af99000), ignoring this section
Core file '/cores/core.59563' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0x0000, 0x0000000100eb47be libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_visit + 59, stop reason = signal SIGSTOP
    frame #0: 0x0000000100eb47be libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_visit + 59
libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_visit:
->  0x100eb47be <+59>: testb  $0x1, 0x3(%rax,%rcx)
    0x100eb47c3 <+64>: je     0x100eb47fe               ; <+123>
    0x100eb47c5 <+66>: movq   %r14, %rdi
    0x100eb47c8 <+69>: movq   %rbx, %rsi
(lldb) bt all
* thread #1: tid = 0x0000, 0x0000000100eb47be libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_visit + 59, stop reason = signal SIGSTOP
  * frame #0: 0x0000000100eb47be libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_visit + 59
    frame #1: 0x0000000100eb2869 libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_visit_all_objects_step + 79
    frame #2: 0x0000000100eb19ab libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_major_collection_step + 456
    frame #3: 0x0000000100eb0354 libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_collect_and_reserve + 290
    frame #4: 0x0000000100eb3b9d libpypy-c.dylib`pypy_g_IncrementalMiniMarkGC_malloc_fixedsize + 228
    frame #5: 0x0000000105100c1d

```

Unfortunately I will not be able to provide the core dump or the script as it contains sensitive information.  I'm happy to run any lldb command that is required to debug this further.



From issues-reply at bitbucket.org  Fri Jul 24 16:50:13 2015
From: issues-reply at bitbucket.org (coldmind)
Date: Fri, 24 Jul 2015 14:50:13 -0000
Subject: [pypy-issue] Issue #2099: Unable to run sanboxed interactive shell
 from-the-box (pypy/pypy)
Message-ID: <20150724145013.18954.90058@app12.ash-private.bitbucket.org>

New issue 2099: Unable to run sanboxed interactive shell from-the-box
https://bitbucket.org/pypy/pypy/issues/2099/unable-to-run-sanboxed-interactive-shell

coldmind:

When building a sandboxed binary as described in documentation and trying to run it by `./pypy_interact.py ../goal/pypy-c-sandbox`, it fails because of https://bitbucket.org/pypy/pypy/src/1caecf593f7ce229f555eee026a10b37fd7d517c/lib_pypy/_pypy_irc_topic.py?at=default#_pypy_irc_topic.py-246, which is importing `time` module which is not works now with sandbox.

Should I find a way to get a timestamp bypassing time module?



From issues-reply at bitbucket.org  Sun Jul 26 19:30:47 2015
From: issues-reply at bitbucket.org (Elliot Gorokhovsky)
Date: Sun, 26 Jul 2015 17:30:47 -0000
Subject: [pypy-issue] Issue #2100: sum(map(foo)) is much slower than for
	loop (pypy/pypy)
Message-ID: <20150726173047.2409.40622@app13.ash-private.bitbucket.org>

New issue 2100: sum(map(foo)) is much slower than for loop
https://bitbucket.org/pypy/pypy/issues/2100/sum-map-foo-is-much-slower-than-for-loop

Elliot Gorokhovsky:

Hi, I originally had the following code:

```
#!python

sum(map(lambda x_bit, y_bit: x_bit & y_bit, x, reversed(y)))
```
It was extremely slow, I profiled it at more than 82 sec for an input that called it a few hundred thousand times. I then changed it, at the recommendation of [stack overflow](http://stackoverflow.com/questions/31639519/optimizing-python-one-liner/31639699#31639699), to this:

```
#!python

s = 0
for i,j in zip(x, reversed(y)):
    s += i & j
```
This profiled at about 12 sec on the same input. Why can't the JIT accelerate sum and map operations? I shoudln't have to explicitly write them out.



From issues-reply at bitbucket.org  Wed Jul 29 11:58:06 2015
From: issues-reply at bitbucket.org (Richard Plangger)
Date: Wed, 29 Jul 2015 09:58:06 -0000
Subject: [pypy-issue] Issue #2101: cast float to bool spurious behaviour
	(pypy/pypy)
Message-ID: <20150729095806.21647.49944@app01.ash-private.bitbucket.org>

New issue 2101: cast float to bool spurious behaviour
https://bitbucket.org/pypy/pypy/issues/2101/cast-float-to-bool-spurious-behaviour

Richard Plangger:

Related to #2087 float cast to bool is handled wrong in the JIT. Consider this example:

```
#!python
try:
    from _numpypy import multiarray as np
except ImportError:
    import numpy as np
a = np.array([0] * 100, dtype='float')
a[50] = 0.1
for i in range(10000):
    assert a.any()
```

Python 2.7.10 does not assert, whereas PyPy 2.6.0 does.
Problem: JIT emits cast_float_to_int, which cuts of the numbers after the comma. The right behavior would be to use float_is_ture. See 4fead7c7623f (jtransform.py & flatten.py)

Can someone confirm that this is the right solution?





From issues-reply at bitbucket.org  Fri Jul 31 23:31:33 2015
From: issues-reply at bitbucket.org (David MacIver)
Date: Fri, 31 Jul 2015 21:31:33 -0000
Subject: [pypy-issue] Issue #2102: Mysterious segfault in Hypothesis
	(pypy/pypy)
Message-ID: <20150731213133.19511.69354@app04.ash-private.bitbucket.org>

New issue 2102: Mysterious segfault in Hypothesis
https://bitbucket.org/pypy/pypy/issues/2102/mysterious-segfault-in-hypothesis

David MacIver:

Sorry. I've tried to turn this into something small and self contained and I simply haven't been able to. Also I'm currently on the worst internet connection in the world, which makes it hard for me to try out a debug or development build of pypy.

The attached file pretty consistently segfaults for me when run under pypy-2.6.0 under 64-bit Linux against my current upcoming branch in Hypothesis (commit 1c33291ae76e4a7e546362c8f4104fdf3b3c11b5 of https://github.com/DRMacIver/hypothesis.git).

The problem is introduced in commit f6f07bf0437458d4851ac1fae56b2d2a64d5b791. Reverting this commit makes it go away.