From tracker at bugs.pypy.org  Fri Oct  4 17:02:32 2013
From: tracker at bugs.pypy.org (Romain Guillebert)
Date: Fri, 04 Oct 2013 15:02:32 +0000
Subject: [pypy-issue] [issue1589] numpy: Structured arrays give odd behavior
In-Reply-To: <1377313189.98.0.193986333307.issue1589@bugs.pypy.org>
Message-ID: <1380898952.31.0.119065210214.issue1589@bugs.pypy.org>


Romain Guillebert <romain.py at gmail.com> added the comment:

I'm working on it right now so it's fine

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1589>
________________________________________

From tracker at bugs.pypy.org  Fri Oct  4 20:23:33 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 04 Oct 2013 18:23:33 +0000
Subject: [pypy-issue] [issue1618] PyPy 5x slower than CPython on benchmark
In-Reply-To: <1380911013.66.0.530612656229.issue1618@bugs.pypy.org>
Message-ID: <1380911013.66.0.530612656229.issue1618@bugs.pypy.org>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

This seems to be as a result of `pow()` on longs being slower. To reproduce:

get the code from https://github.com/dstufft/ed25519/pull/1

and run: `time python -u signfast.py < sign.input`, for me it takes about 16 
seconds on CPython, and about 80 seconds under PyPy.

----------
messages: 6242
nosy: agaynor, pypy-issue
priority: performance bug
status: unread
title: PyPy 5x slower than CPython on benchmark

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1618>
________________________________________

From tracker at bugs.pypy.org  Fri Oct  4 21:35:39 2013
From: tracker at bugs.pypy.org (Romain Guillebert)
Date: Fri, 04 Oct 2013 19:35:39 +0000
Subject: [pypy-issue] [issue1589] numpy: Structured arrays give odd behavior
In-Reply-To: <1377313189.98.0.193986333307.issue1589@bugs.pypy.org>
Message-ID: <1380915339.4.0.0152871581958.issue1589@bugs.pypy.org>


Romain Guillebert <romain.py at gmail.com> added the comment:

Fixed in 9e583c8e7b41

----------
status: in-progress -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1589>
________________________________________

From tracker at bugs.pypy.org  Sat Oct  5 09:15:48 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 05 Oct 2013 07:15:48 +0000
Subject: [pypy-issue] [issue1618] PyPy 5x slower than CPython on benchmark
In-Reply-To: <1380911013.66.0.530612656229.issue1618@bugs.pypy.org>
Message-ID: <1380957348.73.0.439355776267.issue1618@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This page returns 404

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1618>
________________________________________

From tracker at bugs.pypy.org  Sat Oct  5 09:22:16 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 05 Oct 2013 07:22:16 +0000
Subject: [pypy-issue] [issue1618] PyPy 5x slower than CPython on benchmark
In-Reply-To: <1380911013.66.0.530612656229.issue1618@bugs.pypy.org>
Message-ID: <1380957736.6.0.433074490207.issue1618@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Sigh, you want to check it out at this revision: 
https://github.com/pyca/ed25519/commit/9f3e838d90ded42a86ec74c5e9f5e37dec8122a0

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1618>
________________________________________

From tracker at bugs.pypy.org  Sat Oct  5 15:34:55 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 05 Oct 2013 13:34:55 +0000
Subject: [pypy-issue] [issue1618] PyPy 5x slower than CPython on benchmark
In-Reply-To: <1380911013.66.0.530612656229.issue1618@bugs.pypy.org>
Message-ID: <1380980095.78.0.845787972922.issue1618@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Fixed in d7d63baf7ea4.

----------
nosy: +arigo
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1618>
________________________________________

From tracker at bugs.pypy.org  Sun Oct  6 01:06:55 2013
From: tracker at bugs.pypy.org (Donald Stufft)
Date: Sat, 05 Oct 2013 23:06:55 +0000
Subject: [pypy-issue] [issue1619] Segfault when running tests (cffi C
	Module) only on PyPy
In-Reply-To: <1381014415.94.0.709480446655.issue1619@bugs.pypy.org>
Message-ID: <1381014415.94.0.709480446655.issue1619@bugs.pypy.org>


New submission from Donald Stufft <donald.stufft at gmail.com>:

Steps to reproduce:

# I'm using:
# $ pypy --version
# Python 2.7.3 (480845e6b1dd, Jul 31 2013, 10:58:28)
# [PyPy 2.1.0 with GCC 4.2.1 Compatible Clang Compiler]
 
$ git clone https://github.com/pyca/pynacl.git
$ git checkout be8940fec1729fbae58f51bc1d80970dd9c2813c
$ python setup.py install
$ pip install pytest
$ py.test

It seems to work fine if I run it without the jit. The latest nightly exhibits
this behavior as well.

----------
messages: 6247
nosy: dstufft, pypy-issue
priority: bug
status: unread
title: Segfault when running tests (cffi C Module) only on PyPy

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1619>
________________________________________

From tracker at bugs.pypy.org  Sun Oct  6 17:37:26 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 06 Oct 2013 15:37:26 +0000
Subject: [pypy-issue] [issue1619] Segfault when running tests (cffi C
	Module) only on PyPy
In-Reply-To: <1381014415.94.0.709480446655.issue1619@bugs.pypy.org>
Message-ID: <1381073846.2.0.423667230109.issue1619@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Should be fixed by b355653b712a and previous checkins.  Thanks!

----------
nosy: +arigo
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1619>
________________________________________

From tracker at bugs.pypy.org  Tue Oct  8 14:52:50 2013
From: tracker at bugs.pypy.org (Romain Guillebert)
Date: Tue, 08 Oct 2013 12:52:50 +0000
Subject: [pypy-issue] [issue1598] Multiplication of np.ndarray with a Python
	int or float	results in loss of dtype
In-Reply-To: <1378916361.75.0.325559638918.issue1598@bugs.pypy.org>
Message-ID: <1381236770.29.0.36512720234.issue1598@bugs.pypy.org>


Romain Guillebert <romain.py at gmail.com> added the comment:

Fixed by 2e8639dfd82e

----------
status: in-progress -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1598>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 17:06:11 2013
From: tracker at bugs.pypy.org (Yury V. Zaytsev)
Date: Wed, 09 Oct 2013 15:06:11 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>


New submission from Yury V. Zaytsev <yury at shurup.com>:

>>>> import cpyext; cpyext.load_module("test_getitem.so", "test_getitem")
>>>> import test_getitem

>>>> test_getitem.test_getitem( (1,2,3) )
3

>>>> import array
>>>> x = array.array('i'); x.fromlist([1,2,3])
>>>> test_getitem.test_getitem( x )
3

<--- works as expected

>>>> import numpy as np
>>>> z = np.array( (1,2,3) )
>>>> test_getitem.test_getitem( z )
Fatal error in cpyext, CPython compatibility layer, calling PyObject_GetItem
Either report a bug or consider not using this particular extension
<OperationError object at 0x7f4af4af4f40>
RPython traceback:
  File "pypy_module_cpyext_api.c", line 48510, in PyObject_GetItem
  File "pypy_module_cpyext_pyobject.c", line 602, in make_ref
  File "pypy_module_cpyext_pyobject.c", line 1625, in create_ref
  File "pypy_module_cpyext_pyobject.c", line 4535, in BaseCpyTypedescr_allocate
  File "pypy_module_cpyext_pyobject.c", line 602, in make_ref
  File "pypy_module_cpyext_pyobject.c", line 1525, in create_ref
  File "pypy_module_cpyext_typeobject.c", line 19153, in type_attach
  File "pypy_module_cpyext_typeobject.c", line 19902, in best_base
Segmentation fault (core dumped)

<--- FAIL

----------
messages: 6251
nosy: fijal, pypy-issue, zaytsev
priority: bug
release: ???
status: unread
title: CPyExt: PyObject_GetItem() fails on NumPyPy array objects

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 17:39:08 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Oct 2013 15:39:08 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381333148.96.0.974482314972.issue1621@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A unit test will tell for sure, but:

- z[2] returns a object of type numpy.int64

- this type has two base classes:
>>>> type(z[2]).__bases__
(<type 'numpypy.signedinteger'>, <type 'int'>)

- Both types have a different "TypeDef" (see interp_boxes.py)

- So typeobject.base_base() decides that there is no common solid base (=a layout for the PyObject structure), and raises
    TypeError("multiple bases have instance lay-out conflict")


There is another implementation of best_base in objspace.std.typeobject, I don't remember why it could not be used.

----------
nosy: +amaury
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 17:42:54 2013
From: tracker at bugs.pypy.org (Yury V. Zaytsev)
Date: Wed, 09 Oct 2013 15:42:54 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381333374.38.0.0914017841202.issue1621@bugs.pypy.org>


Yury V. Zaytsev <yury at shurup.com> added the comment:

Test:

$ hg diff
diff -r 798905aca6f1 pypy/module/cpyext/test/test_cpyext.py
--- a/pypy/module/cpyext/test/test_cpyext.py	Wed Oct 09 10:51:55 2013 +0200
+++ b/pypy/module/cpyext/test/test_cpyext.py	Wed Oct 09 17:42:20 2013 +0200
@@ -99,7 +99,7 @@
 class LeakCheckingTest(object):
     """Base class for all cpyext tests."""
     spaceconfig = dict(usemodules=['cpyext', 'thread', '_rawffi', 'array',
-                                   'itertools', 'rctime', 'binascii'])
+                                   'itertools', 'rctime', 'binascii',
'micronumpy'])
     spaceconfig['std.withmethodcache'] = True
 
     enable_leak_checking = True
diff -r 798905aca6f1 pypy/module/cpyext/test/test_object.py
--- a/pypy/module/cpyext/test/test_object.py	Wed Oct 09 10:51:55 2013 +0200
+++ b/pypy/module/cpyext/test/test_object.py	Wed Oct 09 17:42:20 2013 +0200
@@ -92,6 +92,12 @@
         assert api.PyErr_Occurred() is space.w_KeyError
         api.PyErr_Clear()
 
+    def test_getitem_numpypy(self, space, api):
+        w_obj = space.appexec([], """():
+            import numpypy as np
+            return np.array((1,2,3))""")
+        assert space.unwrap(api.PyObject_GetItem(w_obj, space.wrap(1))) == 2
+
     def test_size(self, space, api):
         assert api.PyObject_Size(space.newlist([space.w_None])) == 1

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 17:43:02 2013
From: tracker at bugs.pypy.org (Yury V. Zaytsev)
Date: Wed, 09 Oct 2013 15:43:02 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381333382.85.0.89101804039.issue1621@bugs.pypy.org>


Yury V. Zaytsev <yury at shurup.com> added the comment:

Failure:

$ ./pytest.py -x pypy/module/cpyext/test/test_object.py
===============================================================================================
test session starts
===============================================================================================
platform linux2 -- Python 2.6.6 -- pytest-2.2.4.dev2
pytest-2.2.4.dev2 from /home/zaytsev/src/pypy/pypy/pytest.pyc
collected 27 items 

pypy/module/cpyext/test/test_object.py .......F

====================================================================================================
FAILURES
=====================================================================================================
_________________________________________________________________________________________
TestObject.test_getitem_numpypy
_________________________________________________________________________________________

self = <pypy.module.cpyext.test.test_object.TestObject object at 0x637fad0>,
space = StdObjSpace, api = StdObjSpace

    def test_getitem_numpypy(self, space, api):
        w_obj = space.appexec([], """():
            import numpypy as np
            return np.array((1,2,3))""")
>       assert space.unwrap(api.PyObject_GetItem(w_obj, space.wrap(1))) == 2
E       assert W_Int64Box(2) == 2
E        +  where W_Int64Box(2) = <bound method StdObjSpace.unwrap of
StdObjSpace>(W_Int64Box(2))
E        +    where <bound method StdObjSpace.unwrap of StdObjSpace> =
StdObjSpace.unwrap
E        +    and   W_Int64Box(2) = <bound method CAPI.unwrapper of
StdObjSpace>(<pypy.module.micronumpy.base.W_NDimArray object at 0x6dadd50>,
W_IntObject(1))
E        +      where <bound method CAPI.unwrapper of StdObjSpace> =
StdObjSpace.PyObject_GetItem
E        +      and   W_IntObject(1) = <bound method StdObjSpace.wrap of
StdObjSpace>(1)
E        +        where <bound method StdObjSpace.wrap of StdObjSpace> =
StdObjSpace.wrap

pypy/module/cpyext/test/test_object.py:99: AssertionError
-------------------------------------------------------------------------------------------------
Captured stderr
-------------------------------------------------------------------------------------------------
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused
-fPIC -I/home/zaytsev/src/pypy/pypy/rpython/translator/c
/tmp/usession-default-9/module_cache/module_2.c -o
/tmp/usession-default-9/module_cache/module_2.o
[platform:execute] gcc -shared /tmp/usession-default-9/module_cache/module_2.o
-pthread
-Wl,--export-dynamic,--version-script=/tmp/usession-default-9/dynamic-symbols-2
-lrt -o /tmp/usession-default-9/shared_cache/externmod_0.so
=============================================================================================
short test summary info
=============================================================================================
FAIL pypy/module/cpyext/test/test_object.py::TestObject::()::test_getitem_numpypy
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Interrupted: stopping after 1 failures
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
=======================================================================================
1 failed, 7 passed in 26.15 seconds
=======================================================================================

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 19:03:46 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Oct 2013 17:03:46 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381338226.28.0.828855715902.issue1621@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the test, but I think it has two caveats:

- space.unwrap() cannot return a number, since the result is some numpy instance. You could use 
space.eq_w(w_result, space.wrap(2)) instead.

- api.PyObject_GetItem() does not try to convert the value to a PyObject* pointer; it only manipulates w_objects, 
so the initial issue is not reproduced here; try to use make_ref() on the result

Or don't use PyObject_GetItem at all: it's not part of the problem!
Only make_ref() of a numpy.int64(2) object.

Maybe something like:

w_obj = space.appexec([], """():
    import numpypy as np
    return np.int64(2)""")
ref = make_ref(space, w_obj)
api.Py_DecRef(ref)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 19:16:34 2013
From: tracker at bugs.pypy.org (Yury V. Zaytsev)
Date: Wed, 09 Oct 2013 17:16:34 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381338994.02.0.845871837048.issue1621@bugs.pypy.org>


Yury V. Zaytsev <yury at shurup.com> added the comment:

Amaury, excellent  advice! Sorry for being such a n00b, just trying to help to
sort out this issue.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 19:39:59 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Wed, 09 Oct 2013 17:39:59 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381340399.12.0.285783536733.issue1621@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

np, you are very welcome! pypy is not an easy language, thanks for your help.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 22:35:48 2013
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 09 Oct 2013 20:35:48 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381350948.45.0.826859357023.issue1621@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

Here is a patch to test as amaury suggested, indeed the test fails with
'multiple bases have instance lay-out conflict'

diff -r d91e484f733e pypy/module/cpyext/test/test_typeobject.py
--- a/pypy/module/cpyext/test/test_typeobject.py	Wed Oct 09 19:17:04 2013 
+0200
+++ b/pypy/module/cpyext/test/test_typeobject.py	Wed Oct 09 23:33:25 2013 
+0300
@@ -322,6 +322,7 @@
 
 
 class TestTypes(BaseApiTest):
+    spaceconfig = dict(usemodules=['micronumpy', 'cpyext'])
     def test_type_attributes(self, space, api):
         w_class = space.appexec([], """():
             class A(object):
@@ -358,6 +359,13 @@
         assert w_obj is None
         assert api.PyErr_Occurred() is None
 
+    def test_ndarray_ref(self, space, api):
+        w_obj = space.appexec([], """():
+            import numpypy as np
+            return np.int64(2)""")
+        ref = make_ref(space, w_obj)
+        api.Py_DecRef(ref)
+
 class AppTestSlots(AppTestCpythonExtensionBase):
     def test_some_slots(self):
         module = self.import_extension('foo', [

----------
nosy: +mattip
status: chatting -> in-progress

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct  9 22:54:06 2013
From: tracker at bugs.pypy.org (Yury V. Zaytsev)
Date: Wed, 09 Oct 2013 20:54:06 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381352046.83.0.468885561656.issue1621@bugs.pypy.org>


Yury V. Zaytsev <yury at shurup.com> added the comment:

Yep, I've attached the patch and the trace in the previous comment. By the way,
when loading the original reproducer I had to do

    import cpyext; cpyext.load_module("test_getitem.so", "test_getitem")

before

    import test_getitem

Otherwise, it fails with "ImportError: No module named test_getitem".

Is this supposed to be this way or I have translated pypy in a wrong way /
running with incorrect arguments, etc.?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 10 11:44:13 2013
From: tracker at bugs.pypy.org (mattip)
Date: Thu, 10 Oct 2013 09:44:13 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381398253.82.0.575181839491.issue1621@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

tests pass on branch cpyext-best_base, can you download from here and test?
http://buildbot.pypy.org/nightly/cpyext-best_base/pypy-c-jit-67267-e409b611cf6d-
linux64.tar.bz2

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 10 14:59:38 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Thu, 10 Oct 2013 12:59:38 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381409978.87.0.562963934844.issue1621@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, test passes, but I think it does not do the correct thing:
best_base is numpypy.signedinteger, but the layout should be PyIntObject
(Because PyInt_Check() is True; maybe this should be part of the test as well)

I think the code should call check_and_find_best_base() instead, otherwise you completely bypass the check about "instance layout 
conflicts".

...but this does not work either. And it's not a cpyext issue, but a numpypy one.
The following code works on cpython, but fails on pypy:

    type('I', np.int64.__bases__, {})

It fails for two reasons:
- "type 'signedinteger' is not an acceptable base class"
- and if you try to bypass this check, you will get the "instance layout conflict" again.

We really have an issue with multiple inheritance of W_Objects.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Mon Oct 14 10:17:40 2013
From: tracker at bugs.pypy.org (David)
Date: Mon, 14 Oct 2013 08:17:40 +0000
Subject: [pypy-issue] [issue1534] PyPy does not handle "import SMBus" on
	RaspberryPi
In-Reply-To: <1373819072.27.0.488938624163.issue1534@bugs.pypy.org>
Message-ID: <1381738660.11.0.6554437196.issue1534@bugs.pypy.org>


David <david.schneider at uni-duesseldorf.de> added the comment:

I created a cffi based package that behaves like the C extension. 
https://pypi.python.org/pypi/smbus-cffi/0.1

----------
nosy: +bivab
status: chatting -> testing

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1534>
________________________________________

From tracker at bugs.pypy.org  Mon Oct 14 10:56:34 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Mon, 14 Oct 2013 08:56:34 +0000
Subject: [pypy-issue] [issue1534] PyPy does not handle "import SMBus" on
	RaspberryPi
In-Reply-To: <1373819072.27.0.488938624163.issue1534@bugs.pypy.org>
Message-ID: <1381740994.82.0.688755704814.issue1534@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I have some concerns about the @validate decorators (are addresses always 
instances of int? what about 0x80000000?)

Otherwise it looks good, and should be listed in 
https://bitbucket.org/pypy/compatibility/wiki/CCompatible

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1534>
________________________________________

From tracker at bugs.pypy.org  Mon Oct 14 11:13:42 2013
From: tracker at bugs.pypy.org (David)
Date: Mon, 14 Oct 2013 09:13:42 +0000
Subject: [pypy-issue] [issue1534] PyPy does not handle "import SMBus" on
	RaspberryPi
In-Reply-To: <1373819072.27.0.488938624163.issue1534@bugs.pypy.org>
Message-ID: <1381742022.72.0.582218035173.issue1534@bugs.pypy.org>


David <david.schneider at uni-duesseldorf.de> added the comment:

In this context address refers to the address of a device connected to the I2c 
bus, which is either a 7 or 10-bit value.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1534>
________________________________________

From tracker at bugs.pypy.org  Mon Oct 14 21:00:26 2013
From: tracker at bugs.pypy.org (Yury V. Zaytsev)
Date: Mon, 14 Oct 2013 19:00:26 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381777226.3.0.890019179627.issue1621@bugs.pypy.org>


Yury V. Zaytsev <yury at shurup.com> added the comment:

Hi Matti,

As I've already wrote you privately last week, I've tested it again and your fix
seems to work for me! Could this please be merged into the trunk?

Many thanks for your excellent work once again!

Z.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 15 06:18:17 2013
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 15 Oct 2013 04:18:17 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381810697.91.0.846751826795.issue1621@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

fixed in nightly builds, note that it still returns a numpy.int64 and not a 
native int, which AFAICT is cpython numpy compatible.

----------
status: in-progress -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 15 09:04:35 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Oct 2013 07:04:35 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381820675.65.0.649142280285.issue1621@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

...but not completely compatible:
PyInt_Check(obj) returns True, but ((PyIntObject*)obj)->ob_ival will be garbage.

----------
status: resolved -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 15 12:55:39 2013
From: tracker at bugs.pypy.org (Brian Kearns)
Date: Tue, 15 Oct 2013 10:55:39 +0000
Subject: [pypy-issue] [issue1548] numpypy ravel() bug
In-Reply-To: <1374224345.91.0.76779882319.issue1548@bugs.pypy.org>
Message-ID: <1381834539.7.0.81143925572.issue1548@bugs.pypy.org>


Brian Kearns <bdkearns at gmail.com> added the comment:

this was fixed at some point

----------
nosy: +bdk
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1548>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 15 19:44:37 2013
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 15 Oct 2013 17:44:37 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381859077.96.0.555034199766.issue1621@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

I opened a branch cpyext-int to test this and immediately ran into problems, does 
the fix in 2027437ec5a6 look right?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 15 20:43:45 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Oct 2013 18:43:45 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381862625.96.0.113689230961.issue1621@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, please revert this, in the official API those functions return PyObject:
    PyAPI_FUNC(PyObject *) PyInt_FromLong(long);

And it would not change anything, except maybe a pointer cast.
The point here is that we need cpyext to allocate a PyIntObject structure, i.e. call 
"int_realize()", and this is why the solid_base is important.

PyInt_Check(obj) && ((PyIntObject*)obj)->ob_ival
is the best test.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 15 21:08:20 2013
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 15 Oct 2013 19:08:20 +0000
Subject: [pypy-issue] [issue1621] CPyExt: PyObject_GetItem() fails on
	NumPyPy array objects
In-Reply-To: <1381331171.03.0.0475507919034.issue1621@bugs.pypy.org>
Message-ID: <1381864100.48.0.855362760439.issue1621@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

OK, I will revert but then test_int_cast fails, PyInt_FromLong is not calling 
int_realize() and ob_ival is not being set.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1621>
________________________________________

From tracker at bugs.pypy.org  Wed Oct 16 21:18:23 2013
From: tracker at bugs.pypy.org (Juan Orlandini)
Date: Wed, 16 Oct 2013 19:18:23 +0000
Subject: [pypy-issue] [issue1622] string replace is slower in pypy vs cpython
In-Reply-To: <1381951103.32.0.194991234213.issue1622@bugs.pypy.org>
Message-ID: <1381951103.32.0.194991234213.issue1622@bugs.pypy.org>


New submission from Juan Orlandini <tachijuan at gmail.com>:

When you run this:

import timeit
timeit.repeat(stmt='"
{0:08b}".format(int("123")).translate(string.maketrans("01","-*"))',setup='import 
string', number=1000000,repeat = 5)

The run time for PyPy is slower than CPython.

On a MacBook Air (5,2), the timeit output is:

PyPy: [4.286413908004761, 4.306797981262207, 4.228583097457886, 4.298407077789307, 
4.2970991134643555]
CPython: [2.817600965499878, 2.7548630237579346, 2.7212469577789307, 
2.7562379837036133, 2.761147975921631]

The equivalent expression:
timeit.repeat(stmt='"{0:08b}".format(int("123")).replace("1","*").replace("0","-
")',setup='', number=1000000,repeat = 5)

is faster on PyPy vs CPython:

PyPy: [0.5421171188354492, 0.536733865737915, 0.534991979598999, 
0.5270521640777588, 0.5374889373779297]
CPython: [2.2817749977111816, 2.288715124130249, 2.287511110305786, 
2.295119047164917, 2.2907910346984863]

Which is what I expected.

----------
messages: 6272
nosy: pypy-issue, tachijuan
priority: performance bug
release: 2.1
status: unread
title: string replace is slower in pypy vs cpython

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1622>
________________________________________

From tracker at bugs.pypy.org  Wed Oct 16 21:34:57 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 16 Oct 2013 19:34:57 +0000
Subject: [pypy-issue] [issue1622] string replace is slower in pypy vs cpython
In-Reply-To: <1381951103.32.0.194991234213.issue1622@bugs.pypy.org>
Message-ID: <1381952097.85.0.0486853678533.issue1622@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

The issue is about string.maketrans(): it's 10 or 20x slower.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1622>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 17 05:54:38 2013
From: tracker at bugs.pypy.org (Jason Oster)
Date: Thu, 17 Oct 2013 03:54:38 +0000
Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's
In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>
Message-ID: <1381982078.62.0.984145708013.issue867@bugs.pypy.org>


Jason Oster <jay at kodewerx.org> added the comment:

I have a similar, but not exact duplicate leak in urllib2 with PyPy 2.1. (Does not 
occur with python 2.7)

Attached a simple test case for it. The leak only occurs with SSL. E.g. changing 
the protocol to "http" in the test case makes the problem go away. And only when 
the response is a non-200. In other words, when urllib2 raises an exception on a 
HTTPS request == leak!

I also added a little workaround for other leaks in the exception handler, which 
at least fixes the case where a non-200 is returned (exception raised) with the 
HTTP protocol.

----------
nosy: +parasyte

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue867>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 17 06:12:35 2013
From: tracker at bugs.pypy.org (Jason Oster)
Date: Thu, 17 Oct 2013 04:12:35 +0000
Subject: [pypy-issue] [issue1623] httplib.HTTPSConnection leaks FDs
In-Reply-To: <1381983155.54.0.905747226504.issue1623@bugs.pypy.org>
Message-ID: <1381983155.54.0.905747226504.issue1623@bugs.pypy.org>


New submission from Jason Oster <jay at kodewerx.org>:

See also: https://bugs.pypy.org/issue867

When running the test case with PyPy 2.1, I get the following output:

jay at localhost:~$ pypy urllib2-leaks.py
total 0
lrwx------ 1 jay jay 64 Oct 16 21:08 0 -> /dev/pts/10
lrwx------ 1 jay jay 64 Oct 16 21:08 1 -> /dev/pts/10
lrwx------ 1 jay jay 64 Oct 16 21:08 2 -> /dev/pts/10
total 0
lrwx------ 1 jay jay 64 Oct 16 21:08 0 -> /dev/pts/10
lrwx------ 1 jay jay 64 Oct 16 21:08 1 -> /dev/pts/10
lrwx------ 1 jay jay 64 Oct 16 21:08 2 -> /dev/pts/10
lrwx------ 1 jay jay 64 Oct 16 21:08 3 -> socket:[75747073]

Changing the conn variable to httplib.HTTPConnection shows the bug only exists 
with HTTPS.

----------
files: httplib-leaks.py
messages: 6275
nosy: parasyte, pypy-issue
priority: bug
release: 2.1
status: unread
title: httplib.HTTPSConnection leaks FDs

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1623>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 17 06:13:19 2013
From: tracker at bugs.pypy.org (Jason Oster)
Date: Thu, 17 Oct 2013 04:13:19 +0000
Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's
In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>
Message-ID: <1381983199.74.0.581153662586.issue867@bugs.pypy.org>


Jason Oster <jay at kodewerx.org> added the comment:

Looks like the one I found is in httplib. New bug: https://bugs.pypy.org/issue1623

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue867>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 17 06:23:32 2013
From: tracker at bugs.pypy.org (Jason Oster)
Date: Thu, 17 Oct 2013 04:23:32 +0000
Subject: [pypy-issue] [issue1623] httplib.HTTPSConnection leaks FDs
In-Reply-To: <1381983155.54.0.905747226504.issue1623@bugs.pypy.org>
Message-ID: <1381983812.71.0.50870968877.issue1623@bugs.pypy.org>


Jason Oster <jay at kodewerx.org> added the comment:

And, here's a workaround:

fd = response.fileno()
data = response.read()
os.close(fd)

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1623>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 17 07:08:50 2013
From: tracker at bugs.pypy.org (Jason Oster)
Date: Thu, 17 Oct 2013 05:08:50 +0000
Subject: [pypy-issue] [issue1623] httplib.HTTPSConnection leaks FDs
In-Reply-To: <1381983155.54.0.905747226504.issue1623@bugs.pypy.org>
Message-ID: <1381986530.08.0.0496038012462.issue1623@bugs.pypy.org>


Jason Oster <jay at kodewerx.org> added the comment:

There appears to be a lot of other objects that stick around in memory without 
getting freed, because of this bug, though. I'm still investigating.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1623>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 22 20:42:48 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 22 Oct 2013 18:42:48 +0000
Subject: [pypy-issue] [issue1624] ffi.new(...) with array whose elements are
	not long sized	is slow
In-Reply-To: <1382467368.76.0.343422865323.issue1624@bugs.pypy.org>
Message-ID: <1382467368.76.0.343422865323.issue1624@bugs.pypy.org>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

This is because the fast path only works when `self.citem.is_long()`, we should 
have another fast path which works with integers of any size so, e.g. 
ffi.new("short[]", [...])` is also fast (it won't be as fast because of bounds 
checking, but shoudl be much faster). Right now it does space.listview(w_list) 
which results in allocating a new list and allocating each of the W_IntObjects

----------
messages: 6279
nosy: agaynor, pypy-issue
priority: performance bug
status: unread
title: ffi.new(...) with array whose elements are not long sized is slow

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1624>
________________________________________

From tracker at bugs.pypy.org  Wed Oct 23 04:36:17 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 23 Oct 2013 02:36:17 +0000
Subject: [pypy-issue] [issue1625] sys.settrace leads to tons of aborts
In-Reply-To: <1382495777.17.0.527042439227.issue1625@bugs.pypy.org>
Message-ID: <1382495777.17.0.527042439227.issue1625@bugs.pypy.org>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

The following program has many abort: vable escape, and I can't figure out where 
it escapes


import sys


def f():
    pass

def main():
    for i in xrange(10000):
        f()

sys.settrace(lambda *args, **kwargs: None)
main()

----------
messages: 6280
nosy: agaynor, pypy-issue
priority: performance bug
status: unread
title: sys.settrace leads to tons of aborts

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1625>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 24 08:08:13 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 24 Oct 2013 06:08:13 +0000
Subject: [pypy-issue] [issue1624] ffi.new(...) with array whose elements are
	not long sized	is slow
In-Reply-To: <1382467368.76.0.343422865323.issue1624@bugs.pypy.org>
Message-ID: <1382594893.33.0.0672593751449.issue1624@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Reviewing fast_cffi_list_init and working on it.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1624>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 24 10:25:00 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 24 Oct 2013 08:25:00 +0000
Subject: [pypy-issue] [issue1624] ffi.new(...) with array whose elements are
	not long sized	is slow
In-Reply-To: <1382467368.76.0.343422865323.issue1624@bugs.pypy.org>
Message-ID: <1382603100.83.0.123648239103.issue1624@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Done (deb9af94dcc2 to 20c63568140f).

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1624>
________________________________________

From tracker at bugs.pypy.org  Mon Oct 28 19:18:03 2013
From: tracker at bugs.pypy.org (jens diemer)
Date: Mon, 28 Oct 2013 18:18:03 +0000
Subject: [pypy-issue] [issue1626] Tkinter under windows...
In-Reply-To: <1382984283.04.0.269755630798.issue1626@bugs.pypy.org>
Message-ID: <1382984283.04.0.269755630798.issue1626@bugs.pypy.org>


New submission from jens diemer <bugs.pypy.org at jensdiemer.de>:

The documentation should explain how Tkinter can be used under Windows.

The old blog article
http://morepypy.blogspot.de/2011/04/using-tkinter-and-idle-with-pypy.html is
outdated and should be edited with a update notes.

----------
messages: 6283
nosy: jedie, pypy-issue
priority: wish
release: 2.1
status: unread
title: Tkinter under windows...

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1626>
________________________________________

From tracker at bugs.pypy.org  Mon Oct 28 19:25:10 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Oct 2013 18:25:10 +0000
Subject: [pypy-issue] [issue1626] Tkinter under windows...
In-Reply-To: <1382984283.04.0.269755630798.issue1626@bugs.pypy.org>
Message-ID: <1382984710.44.0.602728685113.issue1626@bugs.pypy.org>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

pypy 2.1 normally comes with Tkinter.
Did you try a simple "import Tkinter"?

----------
nosy: +amaury
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1626>
________________________________________

From tracker at bugs.pypy.org  Mon Oct 28 19:26:40 2013
From: tracker at bugs.pypy.org (jens diemer)
Date: Mon, 28 Oct 2013 18:26:40 +0000
Subject: [pypy-issue] [issue1626] Tkinter under windows...
In-Reply-To: <1382984283.04.0.269755630798.issue1626@bugs.pypy.org>
Message-ID: <1382984800.27.0.443971646548.issue1626@bugs.pypy.org>


jens diemer <bugs.pypy.org at jensdiemer.de> added the comment:

Yes:

    Python 2.7.3 (480845e6b1dd, Jul 31 2013, 09:10:30)
    [PyPy 2.1.0 with MSC v.1500 32 bit] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    And now for something completely different: ``we like complaints''
    >>>> import Tkinter
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "d:\pypy-2.1\lib-python\2.7\lib-tk\Tkinter.py", line 39, in <module>
        import _tkinter # If this fails your Python may not be configured for Tk
      File "d:\pypy-2.1\lib_pypy\_tkinter\__init__.py", line 13, in <module>
        from .tklib import tklib, tkffi
      File "d:\pypy-2.1\lib_pypy\_tkinter\tklib.py", line 113, in <module>
        libraries=['tcl', 'tk'],
      File "d:\pypy-2.1\lib_pypy\cffi\api.py", line 311, in verify
        lib = self.verifier.load_library()
      File "d:\pypy-2.1\lib_pypy\cffi\verifier.py", line 68, in load_library
        self.compile_module()
      File "d:\pypy-2.1\lib_pypy\cffi\verifier.py", line 56, in compile_module
        self._compile_module()
      File "d:\pypy-2.1\lib_pypy\cffi\verifier.py", line 131, in _compile_module
        outputfilename = ffiplatform.compile(tmpdir, self.get_extension())
      File "d:\pypy-2.1\lib_pypy\cffi\ffiplatform.py", line 25, in compile
        outputfilename = _build(tmpdir, ext)
      File "d:\pypy-2.1\lib_pypy\cffi\ffiplatform.py", line 47, in _build
        dist.run_command('build_ext')
      File "d:\pypy-2.1\lib-python\2.7\distutils\dist.py", line 972, in run_command
        cmd_obj.run()
      File "d:\pypy-2.1\lib-python\2.7\distutils\command\build_ext.py", line 349, in
     run
        self.build_extensions()
      File "d:\pypy-2.1\lib-python\2.7\distutils\command\build_ext.py", line 458, in
     build_extensions
        self.build_extension(ext)
      File "d:\pypy-2.1\lib-python\2.7\distutils\command\build_ext.py", line 508, in
     build_extension
        depends=ext.depends)
      File "d:\pypy-2.1\lib-python\2.7\distutils\msvc9compiler.py", line 473, in com
    pile
        self.initialize()
      File "d:\pypy-2.1\lib-python\2.7\distutils\msvc9compiler.py", line 383, in ini
    tialize
        vc_env = query_vcvarsall(VERSION, plat_spec)
      File "d:\pypy-2.1\lib-python\2.7\distutils\msvc9compiler.py", line 271, in que
    ry_vcvarsall
        raise DistutilsPlatformError("Unable to find vcvarsall.bat")
    DistutilsPlatformError: Unable to find vcvarsall.bat
    >>>>

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1626>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 29 08:52:49 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 29 Oct 2013 07:52:49 +0000
Subject: [pypy-issue] [issue1626] Tkinter under windows...
In-Reply-To: <1382984283.04.0.269755630798.issue1626@bugs.pypy.org>
Message-ID: <1383033169.85.0.203213300533.issue1626@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Tkinter is not precompiled on Windows.  See pypy/tool/release/package.py. 
Should it be?

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1626>
________________________________________

From tracker at bugs.pypy.org  Tue Oct 29 13:48:02 2013
From: tracker at bugs.pypy.org (jens diemer)
Date: Tue, 29 Oct 2013 12:48:02 +0000
Subject: [pypy-issue] [issue1626] Tkinter under windows...
In-Reply-To: <1382984283.04.0.269755630798.issue1626@bugs.pypy.org>
Message-ID: <1383050882.14.0.685305765038.issue1626@bugs.pypy.org>


jens diemer <bugs.pypy.org at jensdiemer.de> added the comment:

IMHO it should. compiling under windows is not so "easy" as under Linux. So many
users, included me, will have a problem.

A tutorial for compiling it, will be helpful, but not the best solution.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1626>
________________________________________

From tracker at bugs.pypy.org  Wed Oct 30 10:55:45 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 30 Oct 2013 09:55:45 +0000
Subject: [pypy-issue] [issue1620] os.setgroups not supported
In-Reply-To: <1381159526.38.0.515816155966.issue1620@bugs.pypy.org>
Message-ID: <1383126945.98.0.00929062813595.issue1620@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

See https://bugs.pypy.org/issue833 .

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1620>
________________________________________

From tracker at bugs.pypy.org  Wed Oct 30 10:58:08 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 30 Oct 2013 09:58:08 +0000
Subject: [pypy-issue] [issue532] Disable assert statements with -O flag
In-Reply-To: <1273850899.65.0.617610447211.issue532@>
Message-ID: <1383127088.32.0.418404323362.issue532@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Fixed in PyPy 2.1.0.

----------
nosy: +arigo
status: unread -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue532>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 31 09:34:23 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 31 Oct 2013 08:34:23 +0000
Subject: [pypy-issue] [issue1626] Tkinter under windows...
In-Reply-To: <1382984283.04.0.269755630798.issue1626@bugs.pypy.org>
Message-ID: <1383208463.36.0.528249742997.issue1626@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

That includes me too :-)  If anyone with Windows Superpowers knows how to fix
this --- what to install and where --- please do.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1626>
________________________________________

From tracker at bugs.pypy.org  Thu Oct 31 19:23:26 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 31 Oct 2013 18:23:26 +0000
Subject: [pypy-issue] [issue1627] json(ensure_ascii=False)
In-Reply-To: <1383243806.2.0.610349253877.issue1627@bugs.pypy.org>
Message-ID: <1383243806.2.0.610349253877.issue1627@bugs.pypy.org>


New submission from Armin Rigo <armin.rigo at gmail.com>:

json.dumps("\xc0", ensure_ascii=False)

On CPython this returns '"\xc0"', but on PyPy trunk this raises a
UnicodeDecodeError.

----------
messages: 6291
nosy: arigo, pypy-issue
priority: bug
status: unread
title: json(ensure_ascii=False)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1627>
________________________________________