From issues-reply at bitbucket.org  Sat Aug  1 07:01:40 2015
From: issues-reply at bitbucket.org (=?utf-8?q?Bartosz_Wr=C3=B3blewski?=)
Date: Sat, 01 Aug 2015 05:01:40 -0000
Subject: [pypy-issue] Issue #2103: PyPy fails to run with JIT and PAX
 enabled, doesn't produce a relevant error (pypy/pypy)
Message-ID: <20150801050140.31397.18465@app02.ash-private.bitbucket.org>

New issue 2103: PyPy fails to run with JIT and PAX enabled, doesn't produce a relevant error
https://bitbucket.org/pypy/pypy/issues/2103/pypy-fails-to-run-with-jit-and-pax-enabled

Bartosz Wr?blewski:

Tagging issue #2086 as well, since this happens on Alpine in particular.

After compiling PyPy with JIT enabled, on a system with PAX, running the interpreter will fail and return a `MemoryError` to the user, with no further comments.

Running with `--jit off` does resolve the issue, at the obvious expense of disabling JIT.

It is possible to run `paxctl -cm pypy-c` to opt-out of the PAX subsystem, as well.


Building through the Makefile will not trigger the problem immediately, but a build through `pypy rpython/bin/rpython --opt=jit pypy/goal/targetpypystandalone.py` will fail just after the compilation phase, again, producing no useful error.

A brief note outlining the issue should be added to the wiki build instructions.

Ideally, the build system should detect PAX on linux hosts, and alert the user.

Within PyPy itself, perhaps a better message could be returned if the failing mmap sets the error code to EPERM?



From issues-reply at bitbucket.org  Sun Aug  2 16:59:29 2015
From: issues-reply at bitbucket.org (TheLoneWolfling .)
Date: Sun, 02 Aug 2015 14:59:29 -0000
Subject: [pypy-issue] Issue #2104: Pypy3 2.4.0 slower than Python 3.4.2 for
 a function? (pypy/pypy)
Message-ID: <20150802145929.9922.4301@app05.ash-private.bitbucket.org>

New issue 2104: Pypy3 2.4.0 slower than Python 3.4.2 for a function?
https://bitbucket.org/pypy/pypy/issues/2104/pypy3-240-slower-than-python-342-for-a

TheLoneWolfling .:

With the following code:


```
#!python

import random, itertools, timeit

def atLeast(a,b,num):
    return sum(x==y for x,y in itertools.zip_longest(reversed(bin(a).partition('b')[-1]), reversed(bin(b).partition('b')[-1]), fillvalue='0')) >= num

print(timeit.timeit(stmt='atLeast(a,b,96)', setup='from __main__ import atLeast\nimport random\na=random.getrandbits(128)\nb=random.getrandbits(128)', number=100000))
```

I get the following:


```

C:\>python -V
Python 3.4.2

C:\>pypy -V
Python 3.2.5 (b2091e973da6, Oct 19 2014, 21:25:51)
[PyPy 2.4.0 with MSC v.1500 32 bit]

C:\>python pypyslow.py
3.167215612926586

C:\>pypy.exe pypyslow.py
3.3733670679044403
```
Note that Pypy is actually *slower* at running this function than stock Python is.

(I am aware that this is a really bad way to write this function, however I know PyPy likes to know about performance regressions. Just because this function is bad doesn't necessarily mean that there aren't any other functions that are well-written that exhibit this same problem.)

May be related to #2100.



From issues-reply at bitbucket.org  Sun Aug  2 17:08:22 2015
From: issues-reply at bitbucket.org (David Naylor)
Date: Sun, 02 Aug 2015 15:08:22 -0000
Subject: [pypy-issue] Issue #2105: [patch] tool/release/package.py does not
 work with --builddir (pypy/pypy)
Message-ID: <20150802150822.2337.58915@app11.ash-private.bitbucket.org>

New issue 2105: [patch] tool/release/package.py does not work with --builddir
https://bitbucket.org/pypy/pypy/issues/2105/patch-tool-release-packagepy-does-not-work

David Naylor:

When running package.py with a custom --builddir command it gives the following error:
```
# python2.7package.py --without-cffi --builddir $BUILDDIR

Traceback (most recent call last):
  File "/usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-295ee98b6928/pypy/tool/release/package.py", line 365, in <module>
    retval, _ = package(*sys.argv[1:])
  File "/usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-295ee98b6928/pypy/tool/release/package.py", line 344, in package
    return create_package(basedir, options, **kwds)
  File "/usr/local/home/dbn/ports/ports/lang/pypy/work/pypy-pypy-295ee98b6928/pypy/tool/release/package.py", line 139, in create_package
    pypydir = builddir.ensure(name, dir=True)
AttributeError: 'str' object has no attribute 'ensure'
```

The attached patch fixes this by ensuring the builddir variable is of type py.path.  



From issues-reply at bitbucket.org  Sun Aug  2 17:10:12 2015
From: issues-reply at bitbucket.org (David Naylor)
Date: Sun, 02 Aug 2015 15:10:12 -0000
Subject: [pypy-issue] Issue #2106: [patch] add support for FreeBSD in
 detect_number_of_processors (pypy/pypy)
Message-ID: <20150802151012.8822.14639@app08.ash-private.bitbucket.org>

New issue 2106: [patch] add support for FreeBSD in detect_number_of_processors
https://bitbucket.org/pypy/pypy/issues/2106/patch-add-support-for-freebsd-in

David Naylor:

FreeBSD also uses sysctl (same as darwin) for detecting the number of CPUs.  

The attached patch adds support for FreeBSD and simplifies the interaction with sysctl somewhat.  



From issues-reply at bitbucket.org  Sun Aug  2 17:11:46 2015
From: issues-reply at bitbucket.org (David Naylor)
Date: Sun, 02 Aug 2015 15:11:46 -0000
Subject: [pypy-issue] Issue #2107: [patch] FreeBSD not need linking to libdl
 (rffi_platform) (pypy/pypy)
Message-ID: <20150802151146.11132.99962@app11.ash-private.bitbucket.org>

New issue 2107: [patch] FreeBSD not need linking to libdl (rffi_platform)
https://bitbucket.org/pypy/pypy/issues/2107/patch-freebsd-not-need-linking-to-libdl

David Naylor:

FreeBSD does not have a libdl.so (it is provided by libc.so I think).  

The attached patch excludes linking to libdl.so if platform is FreeBSD.  



From issues-reply at bitbucket.org  Wed Aug  5 18:18:12 2015
From: issues-reply at bitbucket.org (Brecht Machiels)
Date: Wed, 05 Aug 2015 16:18:12 -0000
Subject: [pypy-issue] Issue #2108: Inheriting from NoneType not consistent
 with CPython (pypy/pypy)
Message-ID: <20150805161812.25542.20732@app11.ash-private.bitbucket.org>

New issue 2108: Inheriting from NoneType not consistent with CPython
https://bitbucket.org/pypy/pypy/issues/2108/inheriting-from-nonetype-not-consistent

Brecht Machiels:

The following is OK on CPython (2 and 3), but fails on PyPy:

```
#!python

class Object(object): pass
class Null(Object, type(None)): pass
```

This should perhaps be considered a bug in CPython though, as 

```
#!python

bool(Null()) == True
```

and the following fail on CPython too:

```
#!python

class Null(object, type(None)): pass
```

```
#!python

class Null(type(None)): pass
```




From issues-reply at bitbucket.org  Wed Aug  5 20:00:32 2015
From: issues-reply at bitbucket.org (Wilfredo Sanchez)
Date: Wed, 05 Aug 2015 18:00:32 -0000
Subject: [pypy-issue] Issue #2109: Issue with W_ArrayTypeX.* file on
 case-insensitive filesystem (pypy/pypy)
Message-ID: <20150805180032.22477.99792@app11.ash-private.bitbucket.org>

New issue 2109: Issue with W_ArrayTypeX.* file on case-insensitive filesystem
https://bitbucket.org/pypy/pypy/issues/2109/issue-with-w_arraytypex-file-on-case

Wilfredo Sanchez:

In an email to pypy-dev, Cyrus Daboo explains:

Cyrus Daboo cyrus at daboo.name 
Wed Aug 5 17:59:54 CEST 2015

OS X defaults to having a case-insensitive file system. I believe there is 
a problem with building pypy from source on such a system.

During the build process I see files being written to the jitcodes 
directory in the /tmp build directory. There are some "W_ArrayTypeX.*" 
files being written there, where "X" is a typecode (which I believe comes 
from pypy/module/array/interp_array.py). The allowable codes come from the 
set "c, b, B, u, h, H, i, I, l, L, f or d". Note that there are a mixture 
of lower and upper case characters that are the same.

When I build on OS X, with an option to force an error when trying to 
create a file with a name that matches another, but with different case, I 
see this:

[translation:ERROR] EEXIST: [File exists]: 
file('/tmp/usession-release-2.6.x-0/jitcodes/W_ArrayTypel._charbuf_stop', 
'w')

That is because "W_ArrayTypeL._charbuf_stop" exists - i.e., "l" and "L" are 
in conflict.

Now, I am not a PyPy dev expert, so I have no idea what the impact of this 
might be, but it seems wrong to me. Though I cannot detect any obvious 
problems in the built pypy binary.

I am not sure what an appropriate fix for this would be. Perhaps changing 
the typecode set to use unique characters (case insensitive) for all the 
different types?




From issues-reply at bitbucket.org  Fri Aug  7 22:03:46 2015
From: issues-reply at bitbucket.org (zorg24)
Date: Fri, 07 Aug 2015 20:03:46 -0000
Subject: [pypy-issue] Issue #2110: simple euler method example failing to
 converge (pypy/pypy)
Message-ID: <20150807200346.3880.88068@app06.ash-private.bitbucket.org>

New issue 2110: simple euler method example failing to converge
https://bitbucket.org/pypy/pypy/issues/2110/simple-euler-method-example-failing-to

zorg24:

This is a very naive attempt at performing at integrating y'=1/3x^2 over [0,1] with y(0)=0 using Euler's method, however for inc between 0.6e-7 and 1.3e-7 (I didn't try to be any more precise) it is failing to converge on my machine. For other values it runs quite fast as would be expected, also noteworthy is that it runs fine if line 6 is commented out.


```
#!python

def main():
	inc=1e-7
	result=0.0
	i=0.0
	while (i <= 1.0):
		result += inc * (1.0/3.0 * i * i)
		i += inc
	print(result)

main()
```




From issues-reply at bitbucket.org  Wed Aug 12 20:05:42 2015
From: issues-reply at bitbucket.org (David MacIver)
Date: Wed, 12 Aug 2015 18:05:42 -0000
Subject: [pypy-issue] Issue #2111: sys.settrace with a local function is
 about 40x slower than the same function at the top level (pypy/pypy)
Message-ID: <20150812180542.21154.935@app14.ash-private.bitbucket.org>

New issue 2111: sys.settrace with a local function is about 40x slower than the same function at the top level
https://bitbucket.org/pypy/pypy/issues/2111/syssettrace-with-a-local-function-is-about

David MacIver:

The following code demonstrates the issue. A trivial tracing function which does nothing doesn't cause much of a slow down when defined at the top level, but when the same function is defined locally it takes much much longer:


```
#!python

import sys
import random
import time


def hash_str(s):
    h = 0
    for c in s:
        h = (h * 31 + ord(c)) & (2 ** 64 - 1)
    return h

random.seed(1)
data = [
    hex(random.getrandbits(1024)) for _ in range(500)
]


def trace_global(frame, event, arg):
    return trace_global


def trace_and_hash_global(d):
    sys.settrace(trace_global)
    hash_str(d)
    sys.settrace(None)


def trace_and_hash_local(d):
    def trace_local(frame, event, arg):
        return trace_local
    sys.settrace(trace_local)
    hash_str(d)
    sys.settrace(None)


if __name__ == '__main__':
    for ex in [trace_and_hash_global, trace_and_hash_local]:
        start = time.time()
        for d in data:
            ex(d)
        print(ex.__name__, time.time() - start)

```

For me this prints:

```
('trace_and_hash_global', 0.07121396064758301)
('trace_and_hash_local', 2.784956932067871)
```

This is running on pypy 2.6.0 on linux.



From issues-reply at bitbucket.org  Wed Aug 12 20:11:14 2015
From: issues-reply at bitbucket.org (David Naylor)
Date: Wed, 12 Aug 2015 18:11:14 -0000
Subject: [pypy-issue] Issue #2112: [patch] properly detect arm on FreeBSD
	(pypy/pypy)
Message-ID: <20150812181114.14602.64742@app11.ash-private.bitbucket.org>

New issue 2112: [patch] properly detect arm on FreeBSD
https://bitbucket.org/pypy/pypy/issues/2112/patch-properly-detect-arm-on-freebsd

David Naylor:

On FreeBSD `uname -m` returns "arm" (and "arm64").  

The attached patch properly detects arm on FreeBSD.  



From issues-reply at bitbucket.org  Thu Aug 13 01:34:09 2015
From: issues-reply at bitbucket.org (Jason Madden)
Date: Wed, 12 Aug 2015 23:34:09 -0000
Subject: [pypy-issue] Issue #2113: Calling str.expandtabs(0) crashes with a
 floating point exception (pypy/pypy)
Message-ID: <20150812233409.22504.93987@app07.ash-private.bitbucket.org>

New issue 2113: Calling str.expandtabs(0) crashes with a floating point exception
https://bitbucket.org/pypy/pypy/issues/2113/calling-strexpandtabs-0-crashes-with-a

Jason Madden:

In PyPy 2.5.0, 2.6.0 and a recent 2.7 build, under both OS X and 64-bit Linux, using `expandtabs(0)` on either a byte string or unicode string crashes with a floating point exception (8). 

This is very easy to reproduce:

```
$ bin/pypy-2.6-linux_x86_64-portable/bin/pypy
Python 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jun 01 2015, 17:30:13)
[PyPy 2.6.0 with GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> t = u'strict digraph {\n\t1 -> 2;\n\t2 -> 3;\n}\n'
>>>> t.expandtabs(0)
Floating point exception
$
```

The OS X crash report states that it's of type ``EXC_ARITHMETIC`` and code ``EXC_I386_DIV (division by zero)``. 

This was noticed during the unittests for pygraphviz. 



From issues-reply at bitbucket.org  Fri Aug 14 08:30:47 2015
From: issues-reply at bitbucket.org (Ethan Huang)
Date: Fri, 14 Aug 2015 06:30:47 -0000
Subject: [pypy-issue] Issue #2114: cffi callback function pointer become
	invalid (pypy/pypy)
Message-ID: <20150814063047.23864.22845@app13.ash-private.bitbucket.org>

New issue 2114: cffi callback function pointer become invalid
https://bitbucket.org/pypy/pypy/issues/2114/cffi-callback-function-pointer-become

Ethan Huang:

Hi,

We embeded Pypy in C++ code, and used the callback function pointer to execute Python function.
And we noticed that, the callback function pointers might become invalid as the memory usage grows.
Here is the piece of test code:
   
    for(int i = 0; i < LOOP; i++){
       //read python code from file
       char* pyBuffer = readPyFile("test_Lower.py");
       pypy_execute_source_ptr(pyBuffer, &ptr);
       callers[i] = ptr.pyPtrs[0];
    }
    //check 1st function pointer and call python function
    caller = callers[0];
    ret = (*((char *(*)(char *))caller))("A");
    printf("%s\n", ret);

In the experiment, if the LOOP >150, caller becomes invalid, the callback to python function could not succeed, and "Segmentation fault" error was reported.
For more complex Python function, the valid LOOP might be smaller.

I am wondering whether the error was caused by GC in Pypy that recycled the function pointers.
In python fill_api() code, I have used a gloabl list to append function pointer, but it did not help.

#global list
no_gc = []
def fill_api(ptr):
   api = ffi.cast("struct pypyAPI*", ptr)
   api.pyPtrs[0] = test_Lower
   no_gc.append(api)
   no_gc.append(test_Lower)
   return api

And are there any methods to prevent such errors?



From issues-reply at bitbucket.org  Wed Aug 19 22:21:33 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Wed, 19 Aug 2015 20:21:33 -0000
Subject: [pypy-issue] Issue #2115: Revive the PPC backend (pypy/pypy)
Message-ID: <20150819202133.28043.37518@app12.ash-private.bitbucket.org>

New issue 2115: Revive the PPC backend
https://bitbucket.org/pypy/pypy/issues/2115/revive-the-ppc-backend

Armin Rigo:

The PPC backend should be revived.  As a first step I'd suggest merging "default" and the unfinished "ppc-updated-backend" branch (most recent check-in 2014-09-03), and then fixing stuff until we reach a state where it doesn't completely segfaults whenever we try to run any test.  As a target, for a first step: at least half the tests of test_runner.py should pass.



From issues-reply at bitbucket.org  Sat Aug 22 09:34:11 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 22 Aug 2015 07:34:11 -0000
Subject: [pypy-issue] Issue #2116: PPC backend #2: test_runner 3/4 passing
	(pypy/pypy)
Message-ID: <20150822073411.20033.50355@app14.ash-private.bitbucket.org>

New issue 2116: PPC backend #2: test_runner 3/4 passing
https://bitbucket.org/pypy/pypy/issues/2116/ppc-backend-2-test_runner-3-4-passing

Armin Rigo:

PPC backend: get the status of test_runner.py to "3/4rd passing".  This will require more work a bit everywhere.



From issues-reply at bitbucket.org  Sat Aug 22 09:35:20 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 22 Aug 2015 07:35:20 -0000
Subject: [pypy-issue] Issue #2117: PPC backend #3: test_runner.py passing
	(pypy/pypy)
Message-ID: <20150822073520.13266.25207@app08.ash-private.bitbucket.org>

New issue 2117: PPC backend #3: test_runner.py passing
https://bitbucket.org/pypy/pypy/issues/2117/ppc-backend-3-test_runnerpy-passing

Armin Rigo:

PPC backend: get test_runner.py fully or mostly passing.  There might be a
few possible exceptions related to the more advanced features, which
we can skip in this phase, but the remaining tests must pass.  I fear that this
will require a lot of fiddling around.



From issues-reply at bitbucket.org  Sat Aug 22 09:36:01 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 22 Aug 2015 07:36:01 -0000
Subject: [pypy-issue] Issue #2118: PPC backend #4: guards optimizations and
 corner cases (pypy/pypy)
Message-ID: <20150822073601.29566.82383@app04.ash-private.bitbucket.org>

New issue 2118: PPC backend #4: guards optimizations and corner cases
https://bitbucket.org/pypy/pypy/issues/2118/ppc-backend-4-guards-optimizations-and

Armin Rigo:

PPC backend: Optimize "prepare_int_lt" and other similar operations:
right now a "int_lt; guard_true" combination is produced as highly
inefficient assembler.  Also, the way we build "guard_xyz" operations
fails if the target of the branch is too far away (>32k I think).
Test this case and fix it.



From issues-reply at bitbucket.org  Sat Aug 22 09:40:20 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 22 Aug 2015 07:40:20 -0000
Subject: [pypy-issue] Issue #2119: PPC backend #5: GC (pypy/pypy)
Message-ID: <20150822074020.9462.92660@app03.ash-private.bitbucket.org>

New issue 2119: PPC backend #5: GC
https://bitbucket.org/pypy/pypy/issues/2119/ppc-backend-5-gc

Armin Rigo:

PPC backend: support for a non-testing, non-Boehm GC.  Implement the
various kinds of mallocs, the write barriers, and other GC-related code.



From issues-reply at bitbucket.org  Sat Aug 22 09:41:18 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 22 Aug 2015 07:41:18 -0000
Subject: [pypy-issue] Issue #2120: PPC backend #6: most tests should pass
	(pypy/pypy)
Message-ID: <20150822074118.24186.14349@app13.ash-private.bitbucket.org>

New issue 2120: PPC backend #6: most tests should pass
https://bitbucket.org/pypy/pypy/issues/2120/ppc-backend-6-most-tests-should-pass

Armin Rigo:

PPC backend: various remaining fixes, until most tests pass.  This
includes making sure that we have the relevant tests, copied and
adapted from another backend (say the x86 one).  This also includes
test_zll_stress_*.py from rpython/jit/backend/test.



From issues-reply at bitbucket.org  Sat Aug 22 09:41:54 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 22 Aug 2015 07:41:54 -0000
Subject: [pypy-issue] Issue #2121: PPC backend #7: PyPy translation
	(pypy/pypy)
Message-ID: <20150822074154.15378.999@app11.ash-private.bitbucket.org>

New issue 2121: PPC backend #7: PyPy translation
https://bitbucket.org/pypy/pypy/issues/2121/ppc-backend-7-pypy-translation

Armin Rigo:

PPC backend: all tests should pass, and a full PyPy translation should
work.  This will likely mean tracking and fixing an unknown number of
remaining bugs in gdb.



From issues-reply at bitbucket.org  Sat Aug 22 09:42:48 2015
From: issues-reply at bitbucket.org (Armin Rigo)
Date: Sat, 22 Aug 2015 07:42:48 -0000
Subject: [pypy-issue] Issue #2122: PPC backend #8: benchmarks and tweaks
	(pypy/pypy)
Message-ID: <20150822074248.13960.66722@app06.ash-private.bitbucket.org>

New issue 2122: PPC backend #8: benchmarks and tweaks
https://bitbucket.org/pypy/pypy/issues/2122/ppc-backend-8-benchmarks-and-tweaks

Armin Rigo:

PPC backend: do benchmarks and performance tweaks.

The final "deliverable" should be running the official PyPy benchmark suite and reporting the results.



From issues-reply at bitbucket.org  Mon Aug 24 15:30:27 2015
From: issues-reply at bitbucket.org (wil2015)
Date: Mon, 24 Aug 2015 13:30:27 -0000
Subject: [pypy-issue] Issue #2123: about license links (pypy/pypy)
Message-ID: <20150824133027.30172.58484@app02.ash-private.bitbucket.org>

New issue 2123: about license links
https://bitbucket.org/pypy/pypy/issues/2123/about-license-links

wil2015:

I noticed some project licenses included into this project seem just linked instead of providing original licenses. E.g. license of Python itself seems to be only provided by link in LICENSE file: http://www.python.org/doc/Copyright.html, and also this link is not valid now (Error 404).

I'm not lawyer and don't know if this is fine or not, but I'd think it's better to provide original file of license into project folder if the license itself require to do that, instead of just linking it.

Also I noticed the license of Python seems to have some words that may be appended or changed between versions. E.g. copyright years. This may also need to take into concern every time you update the library files from Python project, for example.

Also in LICENSE file, it says "Python Software License", but is this the correct name(s) of license(s) of Python? (You may see here for reference: https://docs.python.org/2/license.html)

Also, other license links may have same problem, I did not review all of them.



From issues-reply at bitbucket.org  Tue Aug 25 14:51:01 2015
From: issues-reply at bitbucket.org (recap)
Date: Tue, 25 Aug 2015 12:51:01 -0000
Subject: [pypy-issue] Issue #2124: ctypes from_buffer c_int TypeError
	(pypy/pypy)
Message-ID: <20150825125101.21517.25009@app10.ash-private.bitbucket.org>

New issue 2124: ctypes from_buffer c_int TypeError
https://bitbucket.org/pypy/pypy/issues/2124/ctypes-from_buffer-c_int-typeerror

recap:

with ctypes.c_int.from_buffer(buf) I get this exception

...basics.py, line 95, in from_buffer
    result._ensure_objects()['ffffffff'] = obj
TypeError: 'NoneType' object does not support item assignment

PyPy version:
[PyPy 2.6.0 with GCC 4.8.2] on linux2



From issues-reply at bitbucket.org  Tue Aug 25 17:07:06 2015
From: issues-reply at bitbucket.org (Jens Diemer)
Date: Tue, 25 Aug 2015 15:07:06 -0000
Subject: [pypy-issue] Issue #2125: Tcl doesn't work inside a virtualenv on
 Windows (pypy/pypy)
Message-ID: <20150825150706.15369.96461@app03.ash-private.bitbucket.org>

New issue 2125: Tcl doesn't work inside a virtualenv on Windows
https://bitbucket.org/pypy/pypy/issues/2125/tcl-doesnt-work-inside-a-virtualenv-on

Jens Diemer:

Using tkinter in virtualenv doesn't work with PyPy 2.6.0:

```
    c:/users/jens/appdata/roaming/dragonpy_env_pypy2/lib/tcl8.5 c:/users/jens/ap
pdata/roaming/dragonpy_env_pypy2/lib/tcl8.5 c:/users/jens/appdata/roaming/lib/tc
l8.5 c:/users/jens/appdata/roaming/dragonpy_env_pypy2/library c:/users/jens/appd
ata/roaming/library c:/users/jens/appdata/roaming/tcl8.5.13/library c:/users/jen
s/appdata/tcl8.5.13/library


This probably means that Tcl wasn't installed properly.
```

It's a kind of a known bug, see: https://github.com/pypa/virtualenv/issues/93

Work-a-round is to set ```os.environ["TCL_LIBRARY"]``` see also: https://github.com/pypa/virtualenv/issues/93#issuecomment-132483445

I have done this to the right place: ```C:\\pypy-2.6.0-win32\\tcl\\tcl8.5```

But it seems that the pypy version didn't use this?!?



From issues-reply at bitbucket.org  Wed Aug 26 21:12:13 2015
From: issues-reply at bitbucket.org (David Naylor)
Date: Wed, 26 Aug 2015 19:12:13 -0000
Subject: [pypy-issue] Issue #2126: [patch] correctly handle sys.platform for
 'freebsd' (pypy/pypy)
Message-ID: <20150826191213.13820.69995@app10.ash-private.bitbucket.org>

New issue 2126: [patch] correctly handle sys.platform for 'freebsd'
https://bitbucket.org/pypy/pypy/issues/2126/patch-correctly-handle-sysplatform-for

David Naylor:

With the EOL for FreeBSD 8 and newer versions of FreeBSD I have fixed all references to 'freebsd' to use sys.platform.startswith().  

This should not cause any issue as there is no special treatment by FreeBSD version and it makes to code future proof.  

I have classified this a a bug because lib_pypy/ctypes_support.py did not support 'freebsd10' and above.  



From issues-reply at bitbucket.org  Thu Aug 27 11:06:45 2015
From: issues-reply at bitbucket.org (Victor Sergienko)
Date: Thu, 27 Aug 2015 09:06:45 -0000
Subject: [pypy-issue] Issue #2127: datetime.timedelta.__mul__ causes
 OverflowError for random multiplier (pypy/pypy)
Message-ID: <20150827090645.863.57938@app01.ash-private.bitbucket.org>

New issue 2127: datetime.timedelta.__mul__ causes OverflowError for random multiplier
https://bitbucket.org/pypy/pypy/issues/2127/datetimetimedelta__mul__-causes

Victor Sergienko:

timezone.timedelta(weeks=52) * random.random() causes OverflowError:

      File "/Users/vic/Documents/pypy3/lib-python/3/datetime.py", line 534, in __mul__
        return self * a / b
      File "/Users/vic/Documents/pypy3/lib-python/3/datetime.py", line 531, in __mul__
        self._microseconds * other)
      File "/Users/vic/Documents/pypy3/lib-python/3/datetime.py", line 430, in __new__
        raise OverflowError("timedelta # of days is too large: %d" % d)
    OverflowError: timedelta # of days is too large: 2492507137960926996

Probably it's because of this implementation:

    def __mul__(self, other):
        ...
        if isinstance(other, float):
            a, b = other.as_integer_ratio()
            return self * a / b

where `as_integer_ratio()` returns a very big nominator and denominator - which is reasonable for random numbers.



From issues-reply at bitbucket.org  Sat Aug 29 21:31:24 2015
From: issues-reply at bitbucket.org (Adam McKenna)
Date: Sat, 29 Aug 2015 19:31:24 -0000
Subject: [pypy-issue] Issue #2128: PyPY breaks SSL connections in MySQLdb
	1.2.25 (pypy/pypy)
Message-ID: <20150829193124.17002.72597@app06.ash-private.bitbucket.org>

New issue 2128: PyPY breaks SSL connections in MySQLdb 1.2.25
https://bitbucket.org/pypy/pypy/issues/2128/pypy-breaks-ssl-connections-in-mysqldb

Adam McKenna:

With PyPy:

# pypy -m pip freeze|grep -i mysql
MySQL-python==1.2.5

Python 2.7.9 (295ee98b6928, May 31 2015, 07:29:04)
[PyPy 2.6.0 with GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import MySQLdb
>>>> ssl = {'cert': '/etc/mysql/ssl/client-cert.pem', 'key': '/etc/mysql/ssl/client-key.pem'}
>>>> dbh = MySQLdb.connect(host='db',user='mysql_test',passwd='hello',ssl=ssl)
SSL error: Unable to get certificate from ''
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/pypy-2.6.0-linux64/site-packages/MySQLdb/__init__.py", line 81, in Connect
    return Connection(*args, **kwargs)
  File "/usr/local/pypy-2.6.0-linux64/site-packages/MySQLdb/connections.py", line 193, in __init__
    super(Connection, self).__init__(*args, **kwargs2)
OperationalError: (2026, 'SSL connection error: Unable to get certificate')


With regular python 2.7.9:

Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import MySQLdb
>>> ssl = {'cert': '/etc/mysql/ssl/client-cert.pem', 'key': '/etc/mysql/ssl/client-key.pem'}
>>> dbh = MySQLdb.connect(host='db',user='mysql_test',passwd='hello',ssl=ssl)
>>> dbc = dbh.cursor()
>>> dbc.execute("show status like 'ssl_cipher'");
1L
>>> print dbc.fetchone()
('Ssl_cipher', 'DHE-RSA-AES256-SHA')

Using PyPY with a tuple for ssl (suggested by several StackExchange posts and other sites) does not return an error, however the select shows that no encryption is being used and MySQL rejects the connection if REQUIRE SSL is used.

>>>> import MySQLdb
>>>> ssl = ({'ca': '/etc/mysql/ssl/ca-cert.pem', 'cert': '/etc/mysql/ssl/client-cert.pem', 'key': '/etc/mysql/ssl/client-key.pem'},)
>>>> dbh = MySQLdb.connect(host='db',user='mysql_test',passwd='hello',ssl=ssl)
>>>> dbc = dbh.cursor()
>>>> dbc.execute("show status like 'ssl_cipher'");
1L
>>>> print dbc.fetchone()
('Ssl_cipher', '')

after adding REQUIRE SSL:

MariaDB [mysql]> grant select on mysql.* to mysql_test require ssl;
Query OK, 0 rows affected (0.00 sec)
MariaDB [mysql]> flush privileges;
Query OK, 0 rows affected (0.01 sec)

Python 2.7.9 (295ee98b6928, May 31 2015, 07:29:04)
[PyPy 2.6.0 with GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import MySQLdb
>>>> ssl = ({'ca': '/etc/mysql/ssl/ca-cert.pem', 'cert': '/etc/mysql/ssl/client-cert.pem', 'key': '/etc/mysql/ssl/client-key.pem'},)
>>>> dbh = MySQLdb.connect(host='db',user='mysql_test',passwd='hello',ssl=ssl)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/pypy-2.6.0-linux64/site-packages/MySQLdb/__init__.py", line 81, in Connect
    return Connection(*args, **kwargs)
  File "/usr/local/pypy-2.6.0-linux64/site-packages/MySQLdb/connections.py", line 193, in __init__
    super(Connection, self).__init__(*args, **kwargs2)
OperationalError: (1045, "Access denied for user 'mysql_test'@'[my ip]' (using password: YES)")



From issues-reply at bitbucket.org  Sat Aug 29 23:35:00 2015
From: issues-reply at bitbucket.org (Valentin Lorentz)
Date: Sat, 29 Aug 2015 21:35:00 -0000
Subject: [pypy-issue] Issue #2129: "local variable 'val' referenced before
 assignment" in lib_pypy/_sqlite3.py (pypy/pypy)
Message-ID: <20150829213500.25907.8266@app14.ash-private.bitbucket.org>

New issue 2129: "local variable 'val' referenced before assignment" in lib_pypy/_sqlite3.py
https://bitbucket.org/pypy/pypy/issues/2129/local-variable-val-referenced-before

Valentin Lorentz:

<pre>  File "/opt/python/pypy3-2.4.0/lib_pypy/_sqlite3.py", line 915, in wrapper
    return func(self, *args, **kwargs)
  File "/opt/python/pypy3-2.4.0/lib_pypy/_sqlite3.py", line 1084, in execute
    return self.__execute(False, sql, [params])
  File "/opt/python/pypy3-2.4.0/lib_pypy/_sqlite3.py", line 1051, in __execute
    self.__next_row = self.__fetch_one_row()
  File "/opt/python/pypy3-2.4.0/lib_pypy/_sqlite3.py", line 1004, in __fetch_one_row
    row.append(val)
UnboundLocalError: local variable 'val' referenced before assignment
```

I get this bug with Pypy3 2.4.0, but not with Pypy 2.5.0

I'm sorry, but I can't give you a small code to reproduce this bug, because I only get it on Travis CI and when running all of my test cases; in addition to it being random.

If you want to try it:

```
git clone https://github.com/ProgVal/Limnoria.git
cd Limnoria
pypy3 setup.py install --user
pypy3 `which supybot-test` -v test --plugins-dir=./build/lib*/supybot/plugins/ --no-network --disable-multiprocessing --exclude=./build/lib*/supybot/plugins/Scheduler --exclude=./build/lib*/supybot/plugins/Filter
```

You can also try this:

```
pypy3 `which supybot-test` -v plugins/Aka/
```

but it does not seem to trigger the bug.



From issues-reply at bitbucket.org  Mon Aug 31 08:53:32 2015
From: issues-reply at bitbucket.org (=?utf-8?q?Stanis=C5=82aw_Pitucha?=)
Date: Mon, 31 Aug 2015 06:53:32 -0000
Subject: [pypy-issue] Issue #2130: symtable module can't be imported
	(pypy/pypy)
Message-ID: <20150831065332.19907.29190@app13.ash-private.bitbucket.org>

New issue 2130: symtable module can't be imported
https://bitbucket.org/pypy/pypy/issues/2130/symtable-module-cant-be-imported

Stanis?aw Pitucha:

In both 2.5 and 2.6 releases, the `symtable` module cannot be loaded. The `symtable` itself is installed with pypy, but `_symtable` imported inside of it is missing.

I'm using the version installed from ppa, so I'm not sure if that's ppa/deb specific, or applies to the whole system.