From tracker at bugs.pypy.org  Sun Jul  3 01:31:28 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 02 Jul 2011 23:31:28 +0000
Subject: [pypy-issue] [issue767] copy.deepcopy is slower than cpython
In-Reply-To: <1309123235.59.0.562866927911.issue767@bugs.pypy.org>
Message-ID: <1309649488.94.0.436829512553.issue767@bugs.pypy.org>


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

So I haven't backported the fix from CPython yet, however with the type-
specialized dicts we are now within ~3% of CPython on this code (nice work 
Carl!).

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

From tracker at bugs.pypy.org  Sun Jul  3 09:42:40 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 03 Jul 2011 07:42:40 +0000
Subject: [pypy-issue] [issue742] pyrepl bug with tuple.__<tab><tab>
In-Reply-To: <1307470044.73.0.248410014433.issue742@bugs.pypy.org>
Message-ID: <1309678960.88.0.965807972263.issue742@bugs.pypy.org>


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

Closing since it's not a pure-pypy problem.

----------
status: chatting -> wontfix

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

From tracker at bugs.pypy.org  Sun Jul  3 09:43:15 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 03 Jul 2011 07:43:15 +0000
Subject: [pypy-issue] [issue774] Telco benchmark got slower
In-Reply-To: <1309678995.86.0.522812840288.issue774@bugs.pypy.org>
Message-ID: <1309678995.86.0.522812840288.issue774@bugs.pypy.org>


New submission from Fijal <fijall at gmail.com>:

So we don't forget

http://speed.pypy.org/timeline/?exe=1&base=none&ben=telco&env=tannit&revs=50

----------
messages: 2716
nosy: fijal, pypy-issue
priority: bug
status: unread
title: Telco benchmark got slower

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

From tracker at bugs.pypy.org  Sun Jul  3 09:43:56 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 03 Jul 2011 07:43:56 +0000
Subject: [pypy-issue] [issue775] bm_mako got slower
In-Reply-To: <1309679036.24.0.307631636135.issue775@bugs.pypy.org>
Message-ID: <1309679036.24.0.307631636135.issue775@bugs.pypy.org>


New submission from Fijal <fijall at gmail.com>:

So we don't forget

http://speed.pypy.org/timeline/?exe=1&base=none&ben=bm_mako&env=tannit&revs=50

----------
messages: 2717
nosy: fijal, pypy-issue
priority: bug
status: unread
title: bm_mako got slower

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

From tracker at bugs.pypy.org  Mon Jul  4 07:42:31 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 04 Jul 2011 05:42:31 +0000
Subject: [pypy-issue] [issue776] Micronumpy pow and mod
In-Reply-To: <1309758151.5.0.918461740557.issue776@bugs.pypy.org>
Message-ID: <1309758151.5.0.918461740557.issue776@bugs.pypy.org>


New submission from Justin Peel <peelpy at gmail.com>:

I made a simple attempt at adding pow and mod to numpy arrays. The mod in 
particular certainly isn't very essential for float arrays, but it was easy to 
put in place.

----------
files: numpy_pow_mod.patch
messages: 2718
nosy: fijal, justinpeel, pypy-issue
priority: feature
status: unread
title: Micronumpy pow and mod

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

From tracker at bugs.pypy.org  Mon Jul  4 08:23:16 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 04 Jul 2011 06:23:16 +0000
Subject: [pypy-issue] [issue777] Unary functions pos, neg,
	and abs for numpy arrays in micronumpy
In-Reply-To: <1309760596.79.0.504522192848.issue777@bugs.pypy.org>
Message-ID: <1309760596.79.0.504522192848.issue777@bugs.pypy.org>


New submission from Justin Peel <peelpy at gmail.com>:

Added unary function ability to numpy arrays and implemented pos, neg and abs for 
them. pos does nothing to the array so there might be a better way to do it. 
However, I doubt that anyone uses it. It is just good to have there for 
completeness. Please check that I coded unary functions correctly. I was basing 
my implementation off of the binop code.

----------
files: numpy_unary_pos_neg_abs.patch
messages: 2719
nosy: fijal, justinpeel, pypy-issue
priority: feature
status: unread
title: Unary functions pos, neg, and abs for numpy arrays in micronumpy

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

From tracker at bugs.pypy.org  Mon Jul  4 10:11:41 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 04 Jul 2011 08:11:41 +0000
Subject: [pypy-issue] [issue698] silence gcc ERRORs during compilation
In-Reply-To: <1304164218.31.0.0561022094379.issue698@>
Message-ID: <1309767101.09.0.540860143998.issue698@bugs.pypy.org>


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

I believe this is fixed

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

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

From tracker at bugs.pypy.org  Mon Jul  4 10:16:03 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 04 Jul 2011 08:16:03 +0000
Subject: [pypy-issue] [issue662] [PATCH] functional distutils for installing
	C extensions
In-Reply-To: <1299432839.34.0.219138682981.issue662@>
Message-ID: <1309767363.4.0.538899107589.issue662@bugs.pypy.org>


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

I don't think creating a makefile is really that great idea. Maybe we should 
have a python file created during translation that contains all the information?

Sorry for a very late response.
Cheers,
fijal

----------
nosy: +fijal

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

From tracker at bugs.pypy.org  Mon Jul  4 12:58:57 2011
From: tracker at bugs.pypy.org (Samuel Ytterbrink)
Date: Mon, 04 Jul 2011 10:58:57 +0000
Subject: [pypy-issue] [issue778] Old License and Credits Links in Interpreter
In-Reply-To: <1309777137.77.0.784343429615.issue778@bugs.pypy.org>
Message-ID: <1309777137.77.0.784343429615.issue778@bugs.pypy.org>


New submission from Samuel Ytterbrink <neppord at gmail.com>:

I suspect that this should be updated, though i might be wrong. The copyright 
however is correct.

Error:

Python 2.7.1 (aefc70438132+, Apr 29 2011, 12:45:42)
[PyPy 1.5.0-alpha0 with MSC v.1600 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``Is there a pypy time? - if you
can feel it (?) then there is''
>>>> credits
PyPy is maintained by the PyPy developers: http://codespeak.net/pypy
>>>> license
See http://codespeak.net/svn/pypy/dist/LICENSE
>>>>

----------
messages: 2723
nosy: neppord, pypy-issue
priority: bug
status: unread
title: Old License and Credits Links in Interpreter

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

From tracker at bugs.pypy.org  Mon Jul  4 21:04:15 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 04 Jul 2011 19:04:15 +0000
Subject: [pypy-issue] [issue778] Old License and Credits Links in Interpreter
In-Reply-To: <1309777137.77.0.784343429615.issue778@bugs.pypy.org>
Message-ID: <1309806255.59.0.893942275744.issue778@bugs.pypy.org>


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

This has already been fixed

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

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

From tracker at bugs.pypy.org  Mon Jul  4 21:13:17 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 04 Jul 2011 19:13:17 +0000
Subject: [pypy-issue] [issue752] Support for dtypes in numpy-exp branches'
	micronumpy
In-Reply-To: <1308083392.77.0.675236112429.issue752@bugs.pypy.org>
Message-ID: <1309806797.5.0.402476039328.issue752@bugs.pypy.org>


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

I'm closing this issue for now. I think dtype support has to be written from 
scratch and there is no point in keeping this open. Feel free to reopen if 
needed.

----------
status: chatting -> wontfix

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

From tracker at bugs.pypy.org  Mon Jul  4 21:55:18 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 04 Jul 2011 19:55:18 +0000
Subject: [pypy-issue] [issue776] Micronumpy pow and mod
In-Reply-To: <1309758151.5.0.918461740557.issue776@bugs.pypy.org>
Message-ID: <1309809318.62.0.912440973599.issue776@bugs.pypy.org>


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

Commited in bff49201da90

----------
status: unread -> resolved

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

From tracker at bugs.pypy.org  Mon Jul  4 21:58:26 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 04 Jul 2011 19:58:26 +0000
Subject: [pypy-issue] [issue777] Unary functions pos, neg,
	and abs for numpy arrays in micronumpy
In-Reply-To: <1309760596.79.0.504522192848.issue777@bugs.pypy.org>
Message-ID: <1309809506.32.0.678482024547.issue777@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Added a jit test.

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

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

From tracker at bugs.pypy.org  Mon Jul  4 22:13:35 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 04 Jul 2011 20:13:35 +0000
Subject: [pypy-issue] [issue777] Unary functions pos, neg,
	and abs for numpy arrays in micronumpy
In-Reply-To: <1309760596.79.0.504522192848.issue777@bugs.pypy.org>
Message-ID: <1309810415.96.0.522818149765.issue777@bugs.pypy.org>


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

commited in f5220ca4563e

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

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

From tracker at bugs.pypy.org  Tue Jul  5 01:48:11 2011
From: tracker at bugs.pypy.org (Jose Antonio Martin H.)
Date: Mon, 04 Jul 2011 23:48:11 +0000
Subject: [pypy-issue] [issue779] Can't install anything on windows with mingw
In-Reply-To: <4E124ED1.5010602@fdi.ucm.es>
Message-ID: <4E124ED1.5010602@fdi.ucm.es>


New submission from Jose Antonio Martin H. <jamartinh at fdi.ucm.es>:

Hi, I am trying to install several pypy packages on windows.

I use mingw32 as a compiler.

I can use mingw32 perfectly with python27 but the distutils version that 
ships with pypy give me several errors.

for instance:

   File 
"D:\pypy27\lib-python\modified-2.7\distutils\cygwinccompiler.py", line 
380, in check_config_h
     fn = sysconfig.get_config_h_filename()
AttributeError: 'module' object has no attribute 'get_config_h_filename'

If I modify distutils to correct this then I obtain another error:

   File 
"D:\pypy27\lib-python\modified-2.7\distutils\cygwinccompiler.py", line 
79, in get_msvcr
     raise ValueError("Unknown MS Compiler version %s " % msc_ver)
ValueError: Unknown MS Compiler version 1600

So, it seems that pypy does not support mingw32 (cygwincompiler) ?

Thanks a lot.

----------
messages: 2729
nosy: jamartinh, pypy-issue
status: unread
title: Can't  install anything on windows with mingw

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

From tracker at bugs.pypy.org  Tue Jul  5 07:56:35 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 05 Jul 2011 05:56:35 +0000
Subject: [pypy-issue] [issue779] Can't install anything on windows with mingw
In-Reply-To: <4E124ED1.5010602@fdi.ucm.es>
Message-ID: <1309845395.11.0.366623684805.issue779@bugs.pypy.org>


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

Our win32 build uses Visual Studio 2010, and this part of distutils has not been 
adapted for it...
It's not too difficult to add it though.  Can you try with the following 
modifications?


--- a/lib-python/modified-2.7/distutils/cygwinccompiler.py	Mon Jul 04 
13:32:21 2011 -0700
+++ b/lib-python/modified-2.7/distutils/cygwinccompiler.py	Tue Jul 05 
07:53:22 2011 +0200
@@ -75,6 +75,9 @@
         elif msc_ver == '1500':
             # VS2008 / MSVC 9.0
             return ['msvcr90']
+        elif msc_ver == '1600':
+            # VS2010 / MSVC 10.0
+            return ['msvcr100']
         else:
             raise ValueError("Unknown MS Compiler version %s " % msc_ver)

----------
nosy: +afa
priority:  -> bug
status: unread -> chatting

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

From tracker at bugs.pypy.org  Tue Jul  5 09:12:19 2011
From: tracker at bugs.pypy.org (Jose Antonio Martin H.)
Date: Tue, 05 Jul 2011 07:12:19 +0000
Subject: [pypy-issue] [issue779] Can't install anything on windows with mingw
In-Reply-To: <1309845395.11.0.366623684805.issue779@bugs.pypy.org>
Message-ID: <4E12B94D.20802@fdi.ucm.es>


Jose Antonio Martin H. <jamartinh at fdi.ucm.es> added the comment:

Yes, it works! Thanks
-Jose

El 05/07/2011 7:56, Amaury Forgeot d Arc escribi?:
>
> Amaury Forgeot d Arc<amauryfa at gmail.com>  added the comment:
>
> Our win32 build uses Visual Studio 2010, and this part of distutils has not been
> adapted for it...
> It's not too difficult to add it though.  Can you try with the following
> modifications?
>
>
> --- a/lib-python/modified-2.7/distutils/cygwinccompiler.py	Mon Jul 04
> 13:32:21 2011 -0700
> +++ b/lib-python/modified-2.7/distutils/cygwinccompiler.py	Tue Jul 05
> 07:53:22 2011 +0200
> @@ -75,6 +75,9 @@
>           elif msc_ver == '1500':
>               # VS2008 / MSVC 9.0
>               return ['msvcr90']
> +        elif msc_ver == '1600':
> +            # VS2010 / MSVC 10.0
> +            return ['msvcr100']
>           else:
>               raise ValueError("Unknown MS Compiler version %s " % msc_ver)
>
> ----------
> nosy: +afa
> priority:  ->  bug
> status: unread ->  chatting
>
> ________________________________________
> PyPy bug tracker<tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue779>
> ________________________________________

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

From tracker at bugs.pypy.org  Tue Jul  5 09:21:02 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 05 Jul 2011 07:21:02 +0000
Subject: [pypy-issue] [issue779] Can't install anything on windows with mingw
In-Reply-To: <4E124ED1.5010602@fdi.ucm.es>
Message-ID: <1309850462.32.0.725146112663.issue779@bugs.pypy.org>


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

Amaury: can you commit it then?

----------
nosy: +fijal

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

From tracker at bugs.pypy.org  Tue Jul  5 10:15:49 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 05 Jul 2011 08:15:49 +0000
Subject: [pypy-issue] [issue779] Can't install anything on windows with mingw
In-Reply-To: <4E124ED1.5010602@fdi.ucm.es>
Message-ID: <1309853749.04.0.818412365546.issue779@bugs.pypy.org>


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

Done with fa231fb66d6c.
jamartinh, how did you work around the 'get_config_h_filename' issue?

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

From tracker at bugs.pypy.org  Tue Jul  5 10:42:13 2011
From: tracker at bugs.pypy.org (Jose Antonio Martin H.)
Date: Tue, 05 Jul 2011 08:42:13 +0000
Subject: [pypy-issue] [issue779] Can't install anything on windows with mingw
In-Reply-To: <1309853749.04.0.818412365546.issue779@bugs.pypy.org>
Message-ID: <4E12CE61.2020100@fdi.ucm.es>


Jose Antonio Martin H. <jamartinh at fdi.ucm.es> added the comment:

Hi,

By now,

forcing it!

     from distutils import sysconfig
     from distutils.sysconfig_cpython import get_config_h_filename
     import string
     # if sys.version contains GCC then python was compiled with
     # GCC, and the pyconfig.h file should be OK
     if string.find(sys.version,"GCC") >= 0:
         return (CONFIG_H_OK, "sys.version mentions 'GCC'")

     #fn = sysconfig.get_config_h_filename()
     fn = get_config_h_filename()

El 05/07/2011 10:15, Amaury Forgeot d Arc escribi?:
>
> Amaury Forgeot d Arc<amauryfa at gmail.com>  added the comment:
>
> Done with fa231fb66d6c.
> jamartinh, how did you work around the 'get_config_h_filename' issue?
>
> ________________________________________
> PyPy bug tracker<tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue779>
> ________________________________________

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

From tracker at bugs.pypy.org  Tue Jul  5 11:51:17 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 05 Jul 2011 09:51:17 +0000
Subject: [pypy-issue] [issue743] Patch: comtypes works with these changes
In-Reply-To: <1307630646.08.0.209251613631.issue743@bugs.pypy.org>
Message-ID: <1309859477.85.0.233769392787.issue743@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

thank you Thomas.  I committed the changes in 634a87b2adbf.
Note that I converted the test from unittest to py.test, but I don't have a
windows box around to check that it actually works.

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

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

From tracker at bugs.pypy.org  Tue Jul  5 20:16:05 2011
From: tracker at bugs.pypy.org (Christian Tismer)
Date: Tue, 05 Jul 2011 18:16:05 +0000
Subject: [pypy-issue] [issue780] test_ll2ctypes.py -k test_arrayofstruct
	Error!
In-Reply-To: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>
Message-ID: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>


New submission from Christian Tismer <tismer at stackless.com>:

This looks like a weird bug.

When running test_ll2ctypes without "-k" selection, all tests work.
With "-k -k test_arrayofstruct", this tests fails.

The second assert
    assert ac.contents.items[2].x == 102
fails. I debugged this and found that the array element returned
is always the first element.

Tested: (branch, os, python)
default, win32, python 2.6.2
default, osx64, python 2.6.1
win64 test, win32, python 2.6.2
win64 test, win64, python 2.7.2

Looks like something behaves wrong the first time, maybe
different behavior when initializing the type cache?

cheers - chris

----------
messages: 2736
nosy: ctismer, pypy-issue
priority: critical
status: unread
title: test_ll2ctypes.py -k test_arrayofstruct Error!

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

From tracker at bugs.pypy.org  Tue Jul  5 20:22:07 2011
From: tracker at bugs.pypy.org (Christian Tismer)
Date: Tue, 05 Jul 2011 18:22:07 +0000
Subject: [pypy-issue] [issue780] test_ll2ctypes.py -k test_arrayofstruct
	Error!
In-Reply-To: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>
Message-ID: <1309890127.39.0.933172798384.issue780@bugs.pypy.org>


Christian Tismer <tismer at stackless.com> added the comment:

Typo:
   With "-k -k test_arrayofstruct", this tests fails.
should read
   With "-k test_arrayofstruct", this tests fails.

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

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

From tracker at bugs.pypy.org  Wed Jul  6 05:46:33 2011
From: tracker at bugs.pypy.org (Ismael)
Date: Wed, 06 Jul 2011 03:46:33 +0000
Subject: [pypy-issue] [issue781] Confusing error message on "with"
In-Reply-To: <1309923993.89.0.148109696461.issue781@bugs.pypy.org>
Message-ID: <1309923993.89.0.148109696461.issue781@bugs.pypy.org>


New submission from Ismael <ismaelgfk at gmail.com>:

Using the "with" statement wrongly results in a confusing error message.

Code (originally written by Alex Gaynor):

class Timer(object):
    def __enter__(self):
        self.start = time.time()
    def __exit__(self, exc_type, exc_val, tb):
        print "Section time: ", time.time() - self.start

#Note the error here, I call the class, not an instance
with Timer:
    pass

---------------------

Compare the CPython 2.6 error:

ismael at chaos:~/Escritorio$ python slow.py 
Traceback (most recent call last):
  File "slow.py", line 31, in <module>
    with Timer:
TypeError: unbound method __enter__() must be called with Timer instance as
first argument (got nothing instead)


Against PyPy 1.5:

ismael at chaos:~/Escritorio$ ~/pypy/bin/pypy slow.py 
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "slow.py", line 31, in <module>
    with Timer:
AttributeError: __exit__

----------
messages: 2738
nosy: Ismael, pypy-issue
priority: wish
release: 1.5
status: unread
title: Confusing error message on "with"

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

From tracker at bugs.pypy.org  Wed Jul  6 05:49:38 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 06 Jul 2011 03:49:38 +0000
Subject: [pypy-issue] [issue781] Confusing error message on "with"
In-Reply-To: <1309923993.89.0.148109696461.issue781@bugs.pypy.org>
Message-ID: <1309924178.97.0.333482938143.issue781@bugs.pypy.org>


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

Note that CPython 2.7 gives the same error as PyPy, so you might want to file 
this one upstream, we probably just copied their impl.

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

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

From tracker at bugs.pypy.org  Wed Jul  6 05:59:36 2011
From: tracker at bugs.pypy.org (Ismael)
Date: Wed, 06 Jul 2011 03:59:36 +0000
Subject: [pypy-issue] [issue781] Confusing error message on "with"
In-Reply-To: <1309923993.89.0.148109696461.issue781@bugs.pypy.org>
Message-ID: <1309924776.22.0.118615167196.issue781@bugs.pypy.org>


Ismael <ismaelgfk at gmail.com> added the comment:

Submitted there too: http://bugs.python.org/issue12503

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

From tracker at bugs.pypy.org  Wed Jul  6 07:00:36 2011
From: tracker at bugs.pypy.org (Ismael)
Date: Wed, 06 Jul 2011 05:00:36 +0000
Subject: [pypy-issue] [issue782] Order of calls changes performance
In-Reply-To: <1309928436.49.0.58232724526.issue782@bugs.pypy.org>
Message-ID: <1309928436.49.0.58232724526.issue782@bugs.pypy.org>


New submission from Ismael <ismaelgfk at gmail.com>:

In the following code, the order of calls alters the performance.

First case: running calc first, then calc_arr second:

ismael at chaos:~/Escritorio$ ~/pypy/bin/pypy slow.py 
Section time:  0.865699052811 -- Calc
Section time:  0.757493019104 -- Calc_arr

So, here, best time for calc_arr is 0.75s. It doesn't matter if I run it 10
times, it still about that fast.

Now, running calc_arr first and calc second:

ismael at chaos:~/Escritorio$ ~/pypy/bin/pypy slow.py 
Section time:  0.400774002075 -- Calc_arr
Section time:  1.53682088852 -- Calc

The method that took 0.7s now takes 0.4! And the one that took 0.8s now takes 1.5!


For comparison, PyPy latest (45351) is even worse:

ismael at chaos:~/Escritorio$
~/pypy/pypylatest/pypy-c-jit-45351-2630c86662b4-linux64/bin/pypy slow.py 
Section time:  0.940190792084 -- Calc
Section time:  0.925091981888 -- Calc_arr

ismael at chaos:~/Escritorio$
~/pypy/pypylatest/pypy-c-jit-45351-2630c86662b4-linux64/bin/pypy slow.py 
Section time:  0.418694019318 -- Calc_arr
Section time:  1.73908495903 -- Calc



Code modified from
http://technicaldiscovery.blogspot.com/2011/07/speeding-up-python-again.html

class Timer(object):
    def __enter__(self):
        self.start = time.time()
    def __exit__(self, exc_type, exc_val, tb):
        print "Section time: ", time.time() - self.start

import array
import time

dx = 0.1
dy = 0.1
dx2 = dx*dx
dy2 = dy*dy

def py_update(u,nx,ny):
    for i in xrange(1,nx-1):
        for j in xrange(1, ny-1):
            u[i][j] = ((u[i+1][j] + u[i-1][j]) * dy2 +
                      (u[i][j+1] + u[i][j-1]) * dx2) / (2*(dx2+dy2))

def calc(N, Niter=100):
    u = [[0.0]*N for i in xrange(N)]
    for i in xrange(N):
        u[0][i] = 1.0
    for i in range(Niter):
        py_update(u,N,N)
    return u
   
def calc_arr(N, Niter=100):
    u = [array.array("d", [0.0])*N for i in xrange(N)]
    for i in xrange(N):
        u[0][i] = 1.0
    for i in range(Niter):
        py_update(u,N,N)
    return u

#Compare this:
with Timer():
    u = calc_arr(150,1000)

with Timer():
    u = calc(150,1000)

#To this (comment the previous section):
with Timer():
    u = calc(150,1000)

with Timer():
    u = calc_arr(150,1000)

----------
messages: 2741
nosy: Ismael, pypy-issue
priority: bug
release: 1.5
status: unread
title: Order of calls changes performance

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

From tracker at bugs.pypy.org  Wed Jul  6 16:31:27 2011
From: tracker at bugs.pypy.org (Marko Kreen)
Date: Wed, 06 Jul 2011 14:31:27 +0000
Subject: [pypy-issue] [issue783] subprocess cannot handle unicode args
In-Reply-To: <1309962687.3.0.947652570439.issue783@bugs.pypy.org>
Message-ID: <1309962687.3.0.947652570439.issue783@bugs.pypy.org>


New submission from Marko Kreen <markokr at gmail.com>:

subprocess should use LANG encoding when preparing args, but instead
uses 'ascii', which throws error on non-ascii string.

Attached code works across Python 2.4 .. 3.2 and Jython, but crashes on PyPy:

$ pypy ./ucode.py 
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "./ucode.py", line 12, in <module>
    p = subprocess.Popen(cmd)
  File "/opt/apps/pypy/lib-python/modified-2.7/subprocess.py", line 672, in __init__
    errread, errwrite)
  File "/opt/apps/pypy/lib-python/modified-2.7/subprocess.py", line 1206, in
_execute_child
    raise child_exception
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2:
ordinal not in range(128)

$ echo $LANG
en_US.UTF-8
$ pypy --version
Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:34)
[PyPy 1.5.0-alpha0 with GCC 4.4.3]

----------
files: ucode.py
messages: 2742
nosy: mkz, pypy-issue
priority: bug
status: unread
title: subprocess cannot handle unicode args

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

From tracker at bugs.pypy.org  Wed Jul  6 21:59:54 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Wed, 06 Jul 2011 19:59:54 +0000
Subject: [pypy-issue] [issue784] [PATCH] Binascii's crc32 function is doing
	unnecessary	operations
In-Reply-To: <1309982394.86.0.97738868933.issue784@bugs.pypy.org>
Message-ID: <1309982394.86.0.97738868933.issue784@bugs.pypy.org>


New submission from Justin Peel <peelpy at gmail.com>:

Binascii's crc32 function has a line that is inside of a loop that shouldn't be. 
This is slowing it down significantly.

----------
files: binascii_crc32.patch
messages: 2743
nosy: justinpeel, pypy-issue
priority: bug
status: unread
title: [PATCH] Binascii's crc32 function is doing unnecessary operations

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

From tracker at bugs.pypy.org  Thu Jul  7 00:30:37 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Wed, 06 Jul 2011 22:30:37 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>


New submission from Justin Peel <peelpy at gmail.com>:

Added sum, prod, max, min, any, and all to numpy arrays. Regular tests all work 
correctly, but there is something still keeping the zjit test from working.

----------
files: numpy_reduce_functions.patch
messages: 2744
nosy: fijal, justinpeel, pypy-issue
priority: feature
status: unread
title: Reduce-like functions for micronumpy

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

From tracker at bugs.pypy.org  Thu Jul  7 12:01:43 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 07 Jul 2011 10:01:43 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310032903.19.0.473158686851.issue785@bugs.pypy.org>


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

There should be more than one jitdriver. Essentially one per loop that has jit 
merge point. Let's discuss it on IRC today :)

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

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

From tracker at bugs.pypy.org  Thu Jul  7 17:04:07 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Thu, 07 Jul 2011 15:04:07 +0000
Subject: [pypy-issue] [issue784] [PATCH] Binascii's crc32 function is doing
	unnecessary	operations
In-Reply-To: <1309982394.86.0.97738868933.issue784@bugs.pypy.org>
Message-ID: <1310051047.97.0.218315320021.issue784@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

applied in 2d192eaab45f

----------
status: unread -> resolved

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

From tracker at bugs.pypy.org  Fri Jul  8 05:38:10 2011
From: tracker at bugs.pypy.org (Simon)
Date: Fri, 08 Jul 2011 03:38:10 +0000
Subject: [pypy-issue] [issue786] Module re,
	\d does with re.U option does not work the same way as with CPython
In-Reply-To: <1310096290.69.0.649047120907.issue786@bugs.pypy.org>
Message-ID: <1310096290.69.0.649047120907.issue786@bugs.pypy.org>


New submission from Simon <simon.corston at nuance.com>:

\d is interpreted as [0-9] but with the re.U option in CPython it gets
interpreted as anything having the Unicode character attribute of digit.

This means that in CPython, \d will match the superscript 3 when used with re.U.
In Pypy, it doesn't leading to diffs in output for the same regex.

This behavior is analogous to the intepretation of \w according to the re.U
switch, which _does_ work correctly in pypy.

Repro code attached.

----------
files: repro.py
messages: 2747
nosy: linguist, pypy-issue
priority: bug
release: 1.5
status: unread
title: Module re, \d does with re.U option does not work the same way as with CPython

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue786>
________________________________________
-------------- next part --------------
import re

foo=u'\N{SUPERSCRIPT THREE}'

# With the re.U switch, \d matches more than just 0-9
unicodeDigitMatcher=re.compile(r'\d', re.U)

# Returns True in CPython, False in Pypy
print unicodeDigitMatcher.match(foo) is not None

# Without the re.U switch, \d matches only 0-9
arabicDigitMatcher=re.compile(r'\d')

# Returns False in Cpython and False in Pypy
print arabicDigitMatcher.match(foo) is not None

From tracker at bugs.pypy.org  Fri Jul  8 05:54:24 2011
From: tracker at bugs.pypy.org (Simon)
Date: Fri, 08 Jul 2011 03:54:24 +0000
Subject: [pypy-issue] [issue786] Module re,
	\d with re.U option does not work the same way as with CPython
In-Reply-To: <1310096290.69.0.649047120907.issue786@bugs.pypy.org>
Message-ID: <1310097264.85.0.847522104941.issue786@bugs.pypy.org>


Simon <simon.corston at nuance.com> added the comment:

PS from http://docs.python.org/library/re.html

\d
    When the UNICODE flag is not specified, matches any decimal digit; this is
equivalent to the set [0-9]. With UNICODE, it will match whatever is classified
as a decimal digit in the Unicode character properties database.

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

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

From tracker at bugs.pypy.org  Fri Jul  8 16:44:55 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 08 Jul 2011 14:44:55 +0000
Subject: [pypy-issue] [issue585] Missing euc-kr encoding
In-Reply-To: <1291220452.63.0.778360043449.issue585@>
Message-ID: <1310136295.13.0.852787559283.issue585@bugs.pypy.org>


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

In-progress.  Still missing the four classes
Multibyte{IncrementalEncoder,IncrementalDecoder,StreamReader,StreamWriter}.

----------
nosy: +arigo
release: 1.4 -> 1.5.1

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

From tracker at bugs.pypy.org  Fri Jul  8 18:08:11 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 08 Jul 2011 16:08:11 +0000
Subject: [pypy-issue] [issue782] Order of calls changes performance
In-Reply-To: <1309928436.49.0.58232724526.issue782@bugs.pypy.org>
Message-ID: <1310141291.43.0.366539106206.issue782@bugs.pypy.org>


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

This is due to the fact that they are both using the same helper, py_update(),
with a different type of argument.  This causes the 2nd run to slow down.  If we
duplicate py_update() and call one or the other in calc() and calc_arr(), then
calc() takes always ~0.4 secs and calc_arr() always ~0.9 secs, independently on
the order in which they run.

This may be considered worth investigating, but may require some careful tweaks
in the JIT.  I would say it's a task "for later maybe"...

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

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

From tracker at bugs.pypy.org  Fri Jul  8 20:25:56 2011
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Fri, 08 Jul 2011 18:25:56 +0000
Subject: [pypy-issue] [issue687] Patch to make the generated C filenames
	reflect the	RPython source filenames
In-Reply-To: <1303167550.88.0.74790300324.issue687@>
Message-ID: <1310149556.7.0.228312575694.issue687@bugs.pypy.org>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Is now a better time to get this merged?

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

From tracker at bugs.pypy.org  Sat Jul  9 01:50:02 2011
From: tracker at bugs.pypy.org (Ilya Osadchiy)
Date: Fri, 08 Jul 2011 23:50:02 +0000
Subject: [pypy-issue] [issue770] bzip2 decompression significantly slower
	than on CPython
In-Reply-To: <1309347691.11.0.161586857791.issue770@bugs.pypy.org>
Message-ID: <1310169002.1.0.0860789305417.issue770@bugs.pypy.org>


Ilya Osadchiy <osadchiy.ilya at gmail.com> added the comment:

Duplicate of issue #733

----------
nosy: +snus-mumrik
status: unread -> duplicate

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

From tracker at bugs.pypy.org  Sat Jul  9 15:02:45 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Sat, 09 Jul 2011 13:02:45 +0000
Subject: [pypy-issue] [issue733] bz2 decompression is very slow
In-Reply-To: <1306785194.2.0.717331507866.issue733@bugs.pypy.org>
Message-ID: <1310216565.24.0.953318790343.issue733@bugs.pypy.org>


Xavier Morel <bugs.pypy.org at masklinn.net> added the comment:

Pasting observations I put in duplicate 770 on the same problem:

Using a clone of pypy's hg repo (working copy included) as my tar base,
decompressing to fs using `tarfile`.

Test archives created using BSDTAR, default options (`tar cjf` and `tar czf`),
likewise for tar's decompression baseline (`tar xf` in both 
cases)

hg id of local Pypy clone is 27df060341f0 tip

OS is OSX 10.6.8

Decompressors tested:
* CPython is Python 2.7.2
* Pypy 1.5 is Python 2.7.1 (?, May 22 2011, 11:59:12) [PyPy 1.5.0-alpha0 with
GCC 4.0.1] from macports
* Pypy trunk is Pypy-65b1ed60d7da from nightlies
* Tar is bsdtar 2.6.2 - libarchive 2.6.2

CPython and Pypy were running the exact same script, which can be found at the
end of the comment

All measurements were performed via `time` and are in minute:seconds, they're
the decompression times.

First I tested the behavior for gzipped files, in order to get an idea of what I
could expect:
* tar: 0:19
* CPython: 0:31
* Pypy 1.5: 0:47
* Pypy trunk: 0:43

Pypy is ~50% slower than CPython, itself ~50% slower than the native tar.

Then I tested using a bz2-compressed archive:
* tar: 0:54
* CPython: 1:10
* Pypy 1.5: hard crash
* Pypy trunk: 2:58

pypy is 200% slower than CPython, which is a significant slowdown. I believe it
might be a source of performance issues when 
installing bz2-packed modules via pip.

Decompression script:
import tarfile
import sys

tar = tarfile.open(sys.argv[1])
tar.extractall()
tar.close()

----------
nosy: +masklinn

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

From tracker at bugs.pypy.org  Sat Jul  9 20:02:41 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 09 Jul 2011 18:02:41 +0000
Subject: [pypy-issue] [issue787] Crash in the assembler backend when running
	Django
In-Reply-To: <1310234561.52.0.793947069726.issue787@bugs.pypy.org>
Message-ID: <1310234561.52.0.793947069726.issue787@bugs.pypy.org>


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

As seen under gdb:


alex at alex-gaynor-laptop:~/projects/django$ PYTHONPATH=`pwd` gdb --args 
~/projects/pypy/pypy-c tests/runtests.py --settings=test_sqlite 
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/alex/projects/pypy/pypy-c...(no debugging symbols 
found)...done.
(gdb) run
Starting program: /home/alex/projects/pypy/pypy-c tests/runtests.py --
settings=test_sqlite
[Thread debugging using libthread_db enabled]
Creating test database for alias 'default'...
Creating test database for alias 'other'...
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
.................s..............................................................
.......s...
Program received signal SIGSEGV, Segmentation fault.
0x000000000097dc2c in pypy_g_encode_rex___72.clone.0 ()
(gdb) bt
#0  0x000000000097dc2c in pypy_g_encode_rex___72.clone.0 ()
#1  0x000000000097dfdf in pypy_g_encode__star_2_14 ()
#2  0x0000000000e88254 in pypy_g_Assembler386_assemble_bridge ()
#3  0x0000000000dc3ca0 in pypy_g_send_bridge_to_backend ()
#4  0x0000000000d30d88 in pypy_g_compile_new_bridge ()
#5  0x0000000000c07922 in pypy_g_MetaInterp_compile_done_with_this_frame ()
#6  0x0000000000b64feb in pypy_g_MetaInterp_finishframe ()
#7  0x0000000000a5cfd3 in pypy_g_handler_ref_return ()
#8  0x000000000098aca2 in pypy_g_MIFrame_run_one_step ()
#9  0x00000000009335a8 in pypy_g_MetaInterp__interpret ()
#10 0x00000000008d3969 in pypy_g_MetaInterp_interpret ()
#11 0x0000000000f5b443 in pypy_g_MetaInterp__handle_guard_failure ()
#12 0x0000000000f63cab in pypy_g_MetaInterp_handle_guard_failure ()
#13 0x00000000008bb17b in pypy_g_assembler_call_helper_1 ()
#14 0x00007ffff3a1b901 in ?? ()
#15 0x0000000000000003 in ?? ()
#16 0xffffffffffffffff in ?? ()
#17 0x0000000003096f00 in ?? ()
#18 0x00007ffff4fd8da0 in ?? ()
#19 0x0000000000000000 in ?? ()





This is semi-reproducible, when running Django I usually see either it, or an 
RPython error in force_virtual.

----------
messages: 2754
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: Crash in the assembler backend when running Django

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

From tracker at bugs.pypy.org  Sat Jul  9 20:25:52 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 09 Jul 2011 18:25:52 +0000
Subject: [pypy-issue] [issue764] segfault with identity_dict
In-Reply-To: <1309031684.91.0.783421956965.issue764@bugs.pypy.org>
Message-ID: <1310235952.87.0.841054285992.issue764@bugs.pypy.org>


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

Closing this, as it does appear to be out of stack.

----------
status: chatting -> wontfix

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

From tracker at bugs.pypy.org  Sun Jul 10 11:53:46 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Sun, 10 Jul 2011 09:53:46 +0000
Subject: [pypy-issue] [issue787] Crash in the assembler backend when running
	Django
In-Reply-To: <1310234561.52.0.793947069726.issue787@bugs.pypy.org>
Message-ID: <1310291626.02.0.571606637926.issue787@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

have you tried to run it on a "make lldebug" pypy?

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

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

From tracker at bugs.pypy.org  Sun Jul 10 14:12:29 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 10 Jul 2011 12:12:29 +0000
Subject: [pypy-issue] [issue787] Crash in the assembler backend when running
	Django
In-Reply-To: <1310234561.52.0.793947069726.issue787@bugs.pypy.org>
Message-ID: <1310299949.58.0.386269297006.issue787@bugs.pypy.org>


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

Also, to make this report a bit more exemplar of how we'd usually like them, can
you specify which version of django you run it with (ideally including a
download url), and the revision of the pypy-c?  (I already got indirectly the
info that it's on Linux 64.)

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

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

From tracker at bugs.pypy.org  Sun Jul 10 19:45:30 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 10 Jul 2011 17:45:30 +0000
Subject: [pypy-issue] [issue787] Crash in the assembler backend when running
	Django
In-Reply-To: <1310234561.52.0.793947069726.issue787@bugs.pypy.org>
Message-ID: <1310319930.95.0.451526396984.issue787@bugs.pypy.org>


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

This is Django trunk (svn URL: svn co 
http://code.djangoproject.com/svn/django/trunk/) with a PyPy from yesterday.

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

From tracker at bugs.pypy.org  Sun Jul 10 22:31:46 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sun, 10 Jul 2011 20:31:46 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310329906.72.0.456486544463.issue785@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

I got everything working and added the dot method as well; I implemented it as a 
multiply and a sum. The reduce-like function ended up messier than I had 
originally thought it would be. It might be better to go with different reduce 
functions for different groups: one for sum and prod, one for max and min, and 
one for any and all. Should I go in that direction or is the current version 
acceptable?

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

From tracker at bugs.pypy.org  Sun Jul 10 22:36:16 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 10 Jul 2011 20:36:16 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310330176.34.0.854422580434.issue785@bugs.pypy.org>


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

a) You have some 8 space indents in there, please 4 space everywhere

b) that reduce_one function is getting large and scary, is there any reason it 
can't be split up into a few seperate ones, it looks like the cases are somewhat 
distinct.  Otherwise looks ok to me.

----------
nosy: +agaynor

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

From tracker at bugs.pypy.org  Sun Jul 10 22:52:11 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sun, 10 Jul 2011 20:52:11 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310331131.21.0.924578189793.issue785@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

In reply to Alex, you're quite right about a.). That is quite embarassing - I 
think it happened when I was copying things around. I agree with you on b.) too. 
I just thought that I would ask before going forward with some minor surgery. 
I'll just trust my instincts next time.

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

From tracker at bugs.pypy.org  Mon Jul 11 00:37:03 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sun, 10 Jul 2011 22:37:03 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310337423.9.0.661269596352.issue785@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Okay, I redid it all so it isn't quite so ugly. Let me know if you have any 
further suggestions.

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

From tracker at bugs.pypy.org  Mon Jul 11 07:29:22 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 11 Jul 2011 05:29:22 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310362162.47.0.915502899818.issue785@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Fixed one line in dot.

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

From tracker at bugs.pypy.org  Mon Jul 11 07:35:49 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 11 Jul 2011 05:35:49 +0000
Subject: [pypy-issue] [issue788] [PATCH] Added radd, rsub,
	etc to numpy arrays
In-Reply-To: <1310362549.36.0.266133624569.issue788@bugs.pypy.org>
Message-ID: <1310362549.36.0.266133624569.issue788@bugs.pypy.org>


New submission from Justin Peel <peelpy at gmail.com>:

Without radd and so on you can do things like 'arr + 3.0' but not '3.0 + arr'. It 
was quite simple to put these in.

----------
messages: 2764
nosy: fijal, justinpeel, pypy-issue
priority: bug
status: unread
title: [PATCH] Added radd, rsub, etc to numpy arrays

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

From tracker at bugs.pypy.org  Mon Jul 11 11:28:19 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Jul 2011 09:28:19 +0000
Subject: [pypy-issue] [issue782] Order of calls changes performance
In-Reply-To: <1309928436.49.0.58232724526.issue782@bugs.pypy.org>
Message-ID: <1310376499.86.0.260658447428.issue782@bugs.pypy.org>


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

Isn't the thing going to pretty much disappear once we merge hakan's branches for 
improving bridges?

----------
nosy: +fijal

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

From tracker at bugs.pypy.org  Mon Jul 11 11:29:47 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Jul 2011 09:29:47 +0000
Subject: [pypy-issue] [issue687] Patch to make the generated C filenames
	reflect the	RPython source filenames
In-Reply-To: <1303167550.88.0.74790300324.issue687@>
Message-ID: <1310376587.2.0.417017756215.issue687@bugs.pypy.org>


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

Eh, sorry for not replying to it earlier. Will have a quick look soon

----------
nosy: +fijal

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

From tracker at bugs.pypy.org  Mon Jul 11 11:56:36 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Jul 2011 09:56:36 +0000
Subject: [pypy-issue] [issue788] [PATCH] Added radd, rsub,
	etc to numpy arrays
In-Reply-To: <1310362549.36.0.266133624569.issue788@bugs.pypy.org>
Message-ID: <1310378196.11.0.294844906152.issue788@bugs.pypy.org>


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

You forgot to put the patch in though

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

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

From tracker at bugs.pypy.org  Mon Jul 11 12:13:01 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Jul 2011 10:13:01 +0000
Subject: [pypy-issue] [issue782] Order of calls changes performance
In-Reply-To: <1309928436.49.0.58232724526.issue782@bugs.pypy.org>
Message-ID: <1310379181.14.0.968363377842.issue782@bugs.pypy.org>


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

A bit of nitpicking (I can fix it myself).

_reduce_any_all_impl is returning an impl which is almost entirely different 
depending on a flag, it's also called once with flag = True and once with False.

Wouldn't it be simpler to just have descr_any and descr_all as separate 
functions without all the metaprogramming?

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

From tracker at bugs.pypy.org  Mon Jul 11 12:13:41 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Jul 2011 10:13:41 +0000
Subject: [pypy-issue] [issue782] Order of calls changes performance
In-Reply-To: <1309928436.49.0.58232724526.issue782@bugs.pypy.org>
Message-ID: <1310379221.52.0.843323799462.issue782@bugs.pypy.org>


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

Uh sorry, previous comment went to the wrong issue

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

From tracker at bugs.pypy.org  Mon Jul 11 12:14:21 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Jul 2011 10:14:21 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310379261.75.0.959390842604.issue785@bugs.pypy.org>


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

A bit of nitpicking (I can fix it myself).

_reduce_any_all_impl is returning an impl which is almost entirely different 
depending on a flag, it's also called once with flag = True and once with False.

Wouldn't it be simpler to just have descr_any and descr_all as separate 
functions without all the metaprogramming?

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

From tracker at bugs.pypy.org  Mon Jul 11 16:15:26 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 11 Jul 2011 14:15:26 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310393726.92.0.286809377413.issue785@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Yes, fijal, you're quite right. Now the any and all functions are separated.

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

From tracker at bugs.pypy.org  Mon Jul 11 16:18:41 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 11 Jul 2011 14:18:41 +0000
Subject: [pypy-issue] [issue788] [PATCH] Added radd, rsub,
	etc to numpy arrays
In-Reply-To: <1310362549.36.0.266133624569.issue788@bugs.pypy.org>
Message-ID: <1310393921.35.0.779540613795.issue788@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Patch added.

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

From tracker at bugs.pypy.org  Mon Jul 11 17:28:01 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 11 Jul 2011 15:28:01 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310398081.78.0.585300644844.issue785@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Also added a small patch for changing the mean method to use the sum method.

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

From tracker at bugs.pypy.org  Mon Jul 11 17:53:11 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 11 Jul 2011 15:53:11 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310399591.9.0.343828642382.issue785@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Also added in argmin and argmax since they are also reduce-like functions.

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

From tracker at bugs.pypy.org  Mon Jul 11 18:11:21 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 11 Jul 2011 16:11:21 +0000
Subject: [pypy-issue] [issue733] bz2 decompression is very slow
In-Reply-To: <1306785194.2.0.717331507866.issue733@bugs.pypy.org>
Message-ID: <1310400681.23.0.655495098272.issue733@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

I just thought that I'd post the current results on the tests that jonash was 
using:

python2.7.1 and bz2:
500000 0.00
1000000 0.01
5000000 0.03
10000000 0.05
100000000 0.53

pypy nightly and bz2:
500000 0.00
1000000 0.01
5000000 0.05
10000000 0.09
100000000 0.80

python2.7.1 and gzip:
500000 0.00
1000000 0.00
5000000 0.03
10000000 0.06
100000000 0.61

pypy nightly and gzip:
500000 0.01
1000000 0.02
5000000 0.13
10000000 0.24
100000000 2.06

So things are better for both of them, but gzip in particular is still really 
struggling in pypy.

----------
nosy: +justinpeel

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

From tracker at bugs.pypy.org  Mon Jul 11 19:15:44 2011
From: tracker at bugs.pypy.org (David Ripton)
Date: Mon, 11 Jul 2011 17:15:44 +0000
Subject: [pypy-issue] [issue678] stack overflow issue
In-Reply-To: <1301575901.04.0.601080933679.issue678@>
Message-ID: <1310404544.88.0.362625271019.issue678@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

This seems okay with a nightly build from 4170cb013928

Python 2.7.1 (6438187093b6, Jul 11 2011, 15:37:19)
[PyPy 1.5.0-alpha0 with GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``psyco eats one brain per inch of
progress''
>>>> def f(): f()
>>>> for i in range(10000):
....  try: f()
....  except RuntimeError: pass
.... 
>>>>

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

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

From tracker at bugs.pypy.org  Mon Jul 11 19:37:46 2011
From: tracker at bugs.pypy.org (David Ripton)
Date: Mon, 11 Jul 2011 17:37:46 +0000
Subject: [pypy-issue] [issue786] Module re,
	\d with re.U option does not work the same way as with CPython
In-Reply-To: <1310096290.69.0.649047120907.issue786@bugs.pypy.org>
Message-ID: <1310405866.06.0.059154802734.issue786@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

I see False False on CPython 2.7 (on Ubuntu 11.04 64-bit), just like on PyPy.

So if there's a bug in PyPy here, the same bug exists in (at least some versions
of) CPython.

----------
nosy: +dripton

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

From tracker at bugs.pypy.org  Mon Jul 11 23:17:11 2011
From: tracker at bugs.pypy.org (Martijn)
Date: Mon, 11 Jul 2011 21:17:11 +0000
Subject: [pypy-issue] [issue662] [PATCH] functional distutils for installing
	C extensions
In-Reply-To: <1299432839.34.0.219138682981.issue662@>
Message-ID: <1310419031.31.0.379938015663.issue662@bugs.pypy.org>


Martijn <ss at kleptog.org> added the comment:

Well, you could do that. The goal here was to be able to use an unmodified
distutils. If however you don't mind maintaining a private copy of distutils
then other solutions are possible.

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

From tracker at bugs.pypy.org  Tue Jul 12 00:17:25 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 11 Jul 2011 22:17:25 +0000
Subject: [pypy-issue] [issue687] Patch to make the generated C filenames
	reflect the	RPython source filenames
In-Reply-To: <1303167550.88.0.74790300324.issue687@>
Message-ID: <1310422645.27.0.108005440948.issue687@bugs.pypy.org>


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

Merged in 658bf014477b, thanks Dave!

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

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

From tracker at bugs.pypy.org  Tue Jul 12 00:33:06 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Jul 2011 22:33:06 +0000
Subject: [pypy-issue] [issue785] Reduce-like functions for micronumpy
In-Reply-To: <1309991437.62.0.173119070653.issue785@bugs.pypy.org>
Message-ID: <1310423586.99.0.82036552224.issue785@bugs.pypy.org>


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

Commited in 516f5a4af65d

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

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

From tracker at bugs.pypy.org  Tue Jul 12 01:16:09 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 11 Jul 2011 23:16:09 +0000
Subject: [pypy-issue] [issue789] (reported) gunicorn slower under PyPy than
	CPython
In-Reply-To: <1310426169.45.0.440555747772.issue789@bugs.pypy.org>
Message-ID: <1310426169.45.0.440555747772.issue789@bugs.pypy.org>


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

http://paste.pocoo.org/show/436485/ is the simple hello world app, and the
output when run under AB, this was done using gunicorn, a pure python preforking
HTTP server.  This was pypy 1.5

----------
messages: 2781
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: (reported) gunicorn slower under PyPy than CPython

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

From tracker at bugs.pypy.org  Tue Jul 12 09:46:05 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 12 Jul 2011 07:46:05 +0000
Subject: [pypy-issue] [issue788] [PATCH] Added radd, rsub,
	etc to numpy arrays
In-Reply-To: <1310362549.36.0.266133624569.issue788@bugs.pypy.org>
Message-ID: <1310456765.24.0.0698596159324.issue788@bugs.pypy.org>


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

Closing then

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

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

From tracker at bugs.pypy.org  Tue Jul 12 10:07:51 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 12 Jul 2011 08:07:51 +0000
Subject: [pypy-issue] [issue780] test_ll2ctypes.py -k test_arrayofstruct
	Error!
In-Reply-To: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>
Message-ID: <1310458071.32.0.703016919225.issue780@bugs.pypy.org>


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

This kind of looks like a ctypes bug to me although it's not completely 
impossible to rule out some ll2ctypes problem.

The problem really is that x.items[n] returns the correct thing, but if you cast 
items to a different pointer and then get an item, it's always the first element 
(why?)

----------
nosy: +fijal

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

From amauryfa at gmail.com  Tue Jul 12 10:33:56 2011
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 12 Jul 2011 10:33:56 +0200
Subject: [pypy-issue] [issue780] test_ll2ctypes.py -k test_arrayofstruct
	Error!
In-Reply-To: <1310458071.32.0.703016919225.issue780@bugs.pypy.org>
References: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>
	<1310458071.32.0.703016919225.issue780@bugs.pypy.org>
Message-ID: <CAGmFidarhAnMeHnKTCZ_0eVNMmwYSvq5tPPvZjvGg=U6qQHkNA@mail.gmail.com>

Hi,

2011/7/12 Fijal <tracker at bugs.pypy.org>

> This kind of looks like a ctypes bug to me although it's not completely
> impossible to rule out some ll2ctypes problem.
>

This is both a ll2ctype issue and a ctypes bug.
- a ll2ctype issue, because it builds an array of an incomplete Structure
(i.e. _fields_ is not yet set); it's the expression "MAX_SIZE * ctypes_item"
- a ctypes bug, because it should not allow this: the * operation should
mark ctypes_item as "final"
and disallow the future change to _fields_.

This script reproduces it:
http://paste.pocoo.org/show/433681/

The fix is to delay the construction of the array.
I have a change in my workspace, will try to commit it tonight.

-- 
Amaury Forgeot d'Arc

From tracker at bugs.pypy.org  Tue Jul 12 11:55:43 2011
From: tracker at bugs.pypy.org (Christian Tismer)
Date: Tue, 12 Jul 2011 09:55:43 +0000
Subject: [pypy-issue] [issue780] test_ll2ctypes.py -k test_arrayofstruct
	Error!
In-Reply-To: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>
Message-ID: <1310464543.61.0.338903871476.issue780@bugs.pypy.org>


Christian Tismer <tismer at stackless.com> added the comment:

Great analysis, thanks!

How did you find this: was it visible from a debugger?
I looked quite a lot with Wing Ide, but was probably not used
to it enough to know what to expect when (like the state of _fields_).

Relaxed, because it's a problem local to ll2ctypes :-)

----------
priority: critical -> bug

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

From tracker at bugs.pypy.org  Tue Jul 12 12:01:45 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 12 Jul 2011 10:01:45 +0000
Subject: [pypy-issue] [issue780] test_ll2ctypes.py -k test_arrayofstruct
	Error!
In-Reply-To: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>
Message-ID: <1310464905.5.0.268576150404.issue780@bugs.pypy.org>


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

> How did you find this: was it visible from a debugger?
I added a lot of prints; I noticed that before and after a ctypes.cast(), the 
values were different, then I saw that ctypes.sizeof() returned zero...

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

From tracker at bugs.pypy.org  Tue Jul 12 16:39:50 2011
From: tracker at bugs.pypy.org (jayqhacker)
Date: Tue, 12 Jul 2011 14:39:50 +0000
Subject: [pypy-issue] [issue790] SSL and bz2 lib paths are broken on RHEL 5
In-Reply-To: <1310481590.34.0.804672541181.issue790@bugs.pypy.org>
Message-ID: <1310481590.34.0.804672541181.issue790@bugs.pypy.org>


New submission from jayqhacker <jayqhacker at gmail.com>:

PyPy 1.5 can't find some of it's shared libraries on RedHat 5.  PyPy seems to be
looking for two "significant digits" in the version number, whereas RedHat
provides one and three.

PyPy wants:

libssl.so.0.9.8
libcrypto.so.0.9.8
libbz2.so.1.0

RedHat 5.5 provides:

/lib64/libssl.so.6
/lib64/libssl.so.0.9.8e
/lib64/libcrypto.so.6
/lib64/libcrypto.so.0.9.8e
/usr/lib64/libbz2.so
/usr/lib64/libbz2.so.1
/usr/lib64/libbbz2.so.1.0.3

It would be nice if PyPy ran out of the box on RedHat 5.

----------
messages: 2787
nosy: jayqhacker, pypy-issue
priority: bug
release: 1.5
status: unread
title: SSL and bz2 lib paths are broken on RHEL 5

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

From tracker at bugs.pypy.org  Tue Jul 12 17:37:58 2011
From: tracker at bugs.pypy.org (jayqhacker)
Date: Tue, 12 Jul 2011 15:37:58 +0000
Subject: [pypy-issue] [issue791] Simple wordcount is significantly slower
	and fatter than	CPython
In-Reply-To: <1310485078.56.0.855118946444.issue791@bugs.pypy.org>
Message-ID: <1310485078.56.0.855118946444.issue791@bugs.pypy.org>


New submission from jayqhacker <jayqhacker at gmail.com>:

import sys
from collections import Counter

for key, value in Counter(sys.stdin).iteritems():
    print key[:-1], value


On 64-bit Linux with 10M random lines (~600 MB):
CPython 2.7.1 : 41s,  1400 MB RSS
PyPy 1.5      : 117s, 2200 MB RSS

Input generated with:
tr -cd '[:alnum:]\n' < /dev/urandom | head -10000000 > 10M.txt

----------
messages: 2788
nosy: jayqhacker, pypy-issue
priority: bug
release: 1.5
status: unread
title: Simple wordcount is significantly slower and fatter than CPython

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

From tracker at bugs.pypy.org  Tue Jul 12 17:56:08 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 12 Jul 2011 15:56:08 +0000
Subject: [pypy-issue] [issue790] SSL and bz2 lib paths are broken on RHEL 5
In-Reply-To: <1310481590.34.0.804672541181.issue790@bugs.pypy.org>
Message-ID: <1310486168.99.0.725074855744.issue790@bugs.pypy.org>


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

I suppose you are talking about the prebuilt binaries.  Yes, it would be nice if
Linux supported prebuilt binaries that link with many libraries and still load
on all common distributions.  Unfortunately, the last time I looked it was a
total mess.  What is the current state of affairs?

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

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

From tracker at bugs.pypy.org  Tue Jul 12 18:02:03 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 12 Jul 2011 16:02:03 +0000
Subject: [pypy-issue] [issue791] Simple wordcount is significantly slower
	and fatter than	CPython
In-Reply-To: <1310485078.56.0.855118946444.issue791@bugs.pypy.org>
Message-ID: <1310486523.9.0.326879158096.issue791@bugs.pypy.org>


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

The situation is slightly, but not significantly improved on trunk, will investigate more.


alex at alex-gaynor-laptop:/tmp$ time python test.py < 10M.txt > /dev/null 

real	0m18.750s
user	0m17.720s
sys	0m0.840s
alex at alex-gaynor-laptop:/tmp$ time pypy test.py < 10M.txt > /dev/null 

real	1m19.780s
user	1m16.920s
sys	0m1.620s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/pypy/pypy-c test.py < 10M.txt > /dev/null 

real	1m6.281s
user	1m4.760s
sys	0m1.170s

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

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

From tracker at bugs.pypy.org  Wed Jul 13 00:01:11 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 12 Jul 2011 22:01:11 +0000
Subject: [pypy-issue] [issue780] test_ll2ctypes.py -k test_arrayofstruct
	Error!
In-Reply-To: <1309889765.08.0.619903910524.issue780@bugs.pypy.org>
Message-ID: <1310508071.96.0.809392374026.issue780@bugs.pypy.org>


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

Fixed with cb7edff773d0

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

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

From tracker at bugs.pypy.org  Wed Jul 13 09:26:03 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Wed, 13 Jul 2011 07:26:03 +0000
Subject: [pypy-issue] [issue756] _ffi out-of-bound integer
In-Reply-To: <1308486546.04.0.248507094962.issue756@bugs.pypy.org>
Message-ID: <1310541963.8.0.478817197885.issue756@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

fixed by 194dbf1456fc, 0022eb161caa and c88c99177447

----------
status: unread -> resolved

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

From tracker at bugs.pypy.org  Wed Jul 13 09:27:25 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 13 Jul 2011 07:27:25 +0000
Subject: [pypy-issue] [issue791] Simple wordcount is significantly slower
	and fatter than	CPython
In-Reply-To: <1310485078.56.0.855118946444.issue791@bugs.pypy.org>
Message-ID: <1310542045.15.0.244530200639.issue791@bugs.pypy.org>


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

So looking at just

c = Counter(sys.stdin)

2/3 of the time is spent in GC (60% of total in gc-minor) some of this is likely 
unavoidable, however there are two things we can do to improve the situation I 
think, one would be inlining into _file to avoid allocation W_StringObject 
(which just get unpacked because the dict is type specialized), and then there's 


p41 = new_with_vtable(ConstClass(W_IntObject))
((pypy.objspace.std.intobject.W_IntObject)p41).inst_intval = 1

in the loop, not sure what's up with that, as armin committed something that 
should turn objs with all constant fields into being preallocated.

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

From tracker at bugs.pypy.org  Wed Jul 13 10:13:35 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Wed, 13 Jul 2011 08:13:35 +0000
Subject: [pypy-issue] [issue792] builtin pow() gives wrong answer
In-Reply-To: <1310544815.87.0.878408212727.issue792@bugs.pypy.org>
Message-ID: <1310544815.87.0.878408212727.issue792@bugs.pypy.org>


New submission from Justin Peel <peelpy at gmail.com>:

By doing a simple comparison with the Python version of rbitint.py's counterpart 
in CPython, the only difference that I can see is that the constant SHIFT 
(PyLong_SHIFT in CPython) is defined as 31 in pypy and 30 or 15 in CPython 
depending on whether 64-bit integers are supported. I haven't taken the time to 
test if changing the SHIFT value will fix this or not and don't claim to 
understand the 5-ARY exponentiation algorithm, but it is the only discrepancy 
that I could find between the codes.

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

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

From tracker at bugs.pypy.org  Wed Jul 13 19:18:45 2011
From: tracker at bugs.pypy.org (Armin Ronacher)
Date: Wed, 13 Jul 2011 17:18:45 +0000
Subject: [pypy-issue] [issue793] Segfault in AST compilation if Pass is
	omitted
In-Reply-To: <1310577525.95.0.765671279723.issue793@bugs.pypy.org>
Message-ID: <1310577525.95.0.765671279723.issue793@bugs.pypy.org>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

The ExceptHandler AST node currently segfaults Python if an empty body list is
passed instead of ast.Pass().  While it's hard to tell if that is a bug or not,
it's certainly not what CPython is comfortable handling and also seems to bypass
the PyPy sanity checks which normally result in a debug output before the actual
segfault.

----------
assignedto: benjamin
messages: 2795
nosy: benjamin, mitsuhiko, pypy-issue
priority: bug
status: unread
title: Segfault in AST compilation if Pass is omitted

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

From tracker at bugs.pypy.org  Wed Jul 13 19:19:04 2011
From: tracker at bugs.pypy.org (Armin Ronacher)
Date: Wed, 13 Jul 2011 17:19:04 +0000
Subject: [pypy-issue] [issue793] Segfault in AST compilation if Pass is
	omitted
In-Reply-To: <1310577525.95.0.765671279723.issue793@bugs.pypy.org>
Message-ID: <1310577544.1.0.854332967486.issue793@bugs.pypy.org>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

It might also affect other situations, I have not looked at the code.

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

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

From tracker at bugs.pypy.org  Wed Jul 13 20:16:39 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 13 Jul 2011 18:16:39 +0000
Subject: [pypy-issue] [issue793] Segfault in AST compilation if Pass is
	omitted
In-Reply-To: <1310577525.95.0.765671279723.issue793@bugs.pypy.org>
Message-ID: <1310580999.17.0.37942249039.issue793@bugs.pypy.org>


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

Do you have an example, that could become a unit test?

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Wed Jul 13 22:57:26 2011
From: tracker at bugs.pypy.org (Renato)
Date: Wed, 13 Jul 2011 20:57:26 +0000
Subject: [pypy-issue] [issue792] builtin pow() gives wrong answer
In-Reply-To: <1310544815.87.0.878408212727.issue792@bugs.pypy.org>
Message-ID: <1310590646.38.0.84804466495.issue792@bugs.pypy.org>


Renato <renato.coutinho at gmail.com> added the comment:

Changing bigint.SHIFT to 30 did fix the problem. I don't know if this causes
other bugs, though.

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

From tracker at bugs.pypy.org  Wed Jul 13 23:21:45 2011
From: tracker at bugs.pypy.org (timo)
Date: Wed, 13 Jul 2011 21:21:45 +0000
Subject: [pypy-issue] [issue794] [patch] numpy: add __repr__ method
	implementation for array
In-Reply-To: <1310592105.03.0.71884211039.issue794@bugs.pypy.org>
Message-ID: <1310592105.03.0.71884211039.issue794@bugs.pypy.org>


New submission from timo <timonator at perpetuum-immobile.de>:

implemented __repr__ for numpy arrays. looks like this: repr(array(range(5))) == 
"array([0.0 1.0 2.0 3.0 4.0])".

with test case :)

----------
messages: 2799
nosy: agaynor, pypy-issue, timo
priority: feature
status: unread
title: [patch] numpy: add __repr__ method implementation for array

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

From tracker at bugs.pypy.org  Wed Jul 13 23:22:30 2011
From: tracker at bugs.pypy.org (timo)
Date: Wed, 13 Jul 2011 21:22:30 +0000
Subject: [pypy-issue] [issue794] [patch] numpy: add __repr__ method
	implementation for array
In-Reply-To: <1310592105.03.0.71884211039.issue794@bugs.pypy.org>
Message-ID: <1310592150.18.0.0340079708957.issue794@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

and this is the file that roundup swallowed

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

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

From tracker at bugs.pypy.org  Thu Jul 14 00:51:10 2011
From: tracker at bugs.pypy.org (Armin Ronacher)
Date: Wed, 13 Jul 2011 22:51:10 +0000
Subject: [pypy-issue] [issue793] Segfault in AST compilation if Pass is
	omitted
In-Reply-To: <1310577525.95.0.765671279723.issue793@bugs.pypy.org>
Message-ID: <1310597470.49.0.728059495692.issue793@bugs.pypy.org>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

Minimal example:


import ast

body = ast.fix_missing_locations(ast.Module([
    ast.TryExcept([ast.Pass()], [ast.ExceptHandler(
        ast.Name('Exception', ast.Load()), None, [])], [])
]))
exec compile(body, '<string>', 'exec')

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

From tracker at bugs.pypy.org  Thu Jul 14 10:41:50 2011
From: tracker at bugs.pypy.org (Armin Ronacher)
Date: Thu, 14 Jul 2011 08:41:50 +0000
Subject: [pypy-issue] [issue795] AST compiler ignores future imports that
	change semantics
In-Reply-To: <1310632910.93.0.936821560495.issue795@bugs.pypy.org>
Message-ID: <1310632910.93.0.936821560495.issue795@bugs.pypy.org>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Right now the PyPy AST compiler seems to ignore the division future import.  It
might also affect some others.


import ast

ns = {}
exec compile(ast.fix_missing_locations(ast.Module([
    ast.ImportFrom('__future__', [ast.alias('division', None)], -1),
    ast.Assign([ast.Name('result', ast.Store())],
               ast.BinOp(ast.Num(10), ast.Div(), ast.Num(4)))
])), '<string>', 'exec') in ns

print 'Expecting 2.5, got %r' % ns['result']


Prints 2.5 on Python, but 2 on PyPy.

----------
assignedto: benjamin
messages: 2802
nosy: benjamin, mitsuhiko, pypy-issue
priority: bug
status: unread
title: AST compiler ignores future imports that change semantics

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

From tracker at bugs.pypy.org  Thu Jul 14 11:08:19 2011
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Thu, 14 Jul 2011 09:08:19 +0000
Subject: [pypy-issue] [issue795] AST compiler ignores future imports that
	change semantics
In-Reply-To: <1310632910.93.0.936821560495.issue795@bugs.pypy.org>
Message-ID: <1310634499.44.0.92767764712.issue795@bugs.pypy.org>


Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

interestingly executing equivalent code yields correct results, while compiling
and executing the result of a ast.parse of that code doesnt

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

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

From tracker at bugs.pypy.org  Thu Jul 14 15:34:37 2011
From: tracker at bugs.pypy.org (Benjamin Peterson)
Date: Thu, 14 Jul 2011 13:34:37 +0000
Subject: [pypy-issue] [issue795] AST compiler ignores future imports that
	change semantics
In-Reply-To: <1310632910.93.0.936821560495.issue795@bugs.pypy.org>
Message-ID: <1310650477.9.0.66990147667.issue795@bugs.pypy.org>


Benjamin Peterson <benjamin at python.org> added the comment:

ee7992bb45f7

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

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

From tracker at bugs.pypy.org  Thu Jul 14 20:26:42 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 14 Jul 2011 18:26:42 +0000
Subject: [pypy-issue] [issue794] [patch] numpy: add __repr__ method
	implementation for array
In-Reply-To: <1310592105.03.0.71884211039.issue794@bugs.pypy.org>
Message-ID: <1310668001.93.0.256496278348.issue794@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Patch with some changes commited.

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

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

From tracker at bugs.pypy.org  Fri Jul 15 07:33:56 2011
From: tracker at bugs.pypy.org (Laura Creighton)
Date: Fri, 15 Jul 2011 05:33:56 +0000
Subject: [pypy-issue] [issue796] pypy/dist/pypy/doc/extending.html needs to
	be changed
In-Reply-To: <1310708036.62.0.940782470175.issue796@bugs.pypy.org>
Message-ID: <1310708036.62.0.940782470175.issue796@bugs.pypy.org>


New submission from Laura Creighton <lac at openend.se>:

ctypes is not super-slow now.  But I am not sure exactly what we want to say.

----------
messages: 2806
nosy: lac, pypy-issue
priority: bug
status: unread
title: pypy/dist/pypy/doc/extending.html needs to be changed

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

From tracker at bugs.pypy.org  Fri Jul 15 15:11:32 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Fri, 15 Jul 2011 13:11:32 +0000
Subject: [pypy-issue] [issue796] pypy/dist/pypy/doc/extending.html needs to
	be changed
In-Reply-To: <1310708036.62.0.940782470175.issue796@bugs.pypy.org>
Message-ID: <1310735492.89.0.231987106353.issue796@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

fixed by 87c5f89a4e78

----------
status: unread -> resolved

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

From tracker at bugs.pypy.org  Sat Jul 16 00:10:20 2011
From: tracker at bugs.pypy.org (Simon)
Date: Fri, 15 Jul 2011 22:10:20 +0000
Subject: [pypy-issue] [issue786] Module re,
	\d with re.U option does not work the same way as with CPython
In-Reply-To: <1310096290.69.0.649047120907.issue786@bugs.pypy.org>
Message-ID: <1310767820.93.0.702839304439.issue786@bugs.pypy.org>


Simon <simon.corston at nuance.com> added the comment:

To clarify: 

the expected output (which I observe in CPython 2.6.6 under Ubuntu 10.10 64 bit) is

True
False

i.e. the Unicode interpretation of \d matches the superscript 3 but the
non-Unicode interpretation does not.

Under Pypy I get

False
False
Under Pypy

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

From tracker at bugs.pypy.org  Sat Jul 16 02:00:37 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 16 Jul 2011 00:00:37 +0000
Subject: [pypy-issue] [issue797] Deadlock with threads
In-Reply-To: <1310774437.29.0.502693384399.issue797@bugs.pypy.org>
Message-ID: <1310774437.29.0.502693384399.issue797@bugs.pypy.org>


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

Running this code under PyPy trunk (or 1.5) on Linux 64 results in a deadlock:


import threading


def get_results():
    pass

def main():
    i = 0
    while i < 5000000:
        t = threading.Thread(target=get_results)
        t.start()
        t.join()
        i += 1
        if i % 1000 == 0:
            print i

main()



According to mitsuhiko it reproduces on OS X for him, but *not* when using 1.4.0.  I 
cannot reproduce this on Linux with --jit off.  This doesn't necessarily mean the JIT 
causes it unfortunately, it could be that the increased speed is the cause (which 
would explain why it doesn't reproduce on CPython possibly).  Or it could be a JIT 
bug.

----------
messages: 2809
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: Deadlock with threads

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

From tracker at bugs.pypy.org  Sat Jul 16 06:14:23 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sat, 16 Jul 2011 04:14:23 +0000
Subject: [pypy-issue] [issue786] Module re,
	\d with re.U option does not work the same way as with CPython
In-Reply-To: <1310096290.69.0.649047120907.issue786@bugs.pypy.org>
Message-ID: <1310789663.26.0.462970155989.issue786@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

It worked for me as linguist said in CPython 2.6 and as dripton said in CPython 
2.7. A version of CPython 3.3 that I have on my computer works just like CPython 
2.7. It seems like maybe this issue needs to be brought up with the Python core 
people first.

----------
nosy: +justinpeel

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

From tracker at bugs.pypy.org  Sat Jul 16 07:41:12 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sat, 16 Jul 2011 05:41:12 +0000
Subject: [pypy-issue] [issue791] Simple wordcount is significantly slower
	and fatter than	CPython
In-Reply-To: <1310485078.56.0.855118946444.issue791@bugs.pypy.org>
Message-ID: <1310794872.4.0.480007470837.issue791@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

I don't know how much help this will be, but I decided to do a break down on 
various operations. These were done with a file containing only a million 
generated strings rather than ten million because I didn't want to wait forever. 
I did each test several times to make sure that the timings were consistent and 
took the median value. Timings were all done on a 32-bit Linux system with the 
pypy nightly build from July 14th, 2011. CPython version was 2.7.1.

just Counter on stdin-
cpython: 1.171s
pypy: 3.148s

Counter w/ print key, value-
cpython: 2.297s
pypy: 6.355s

Counter w/ print key[:-1], value-
cpython: 2.472s
pypy: 7.214s

iterating line by line over stdin-
cpython: 0.247s
pypy: 0.485s

iterating line by line over stdin and printing each line-
cpython: 0.708s
pypy: 2.596s

This indicates to me that we need to work on speeding up printing, the Counter 
object, and slicing strings (maybe this is a GC issue as well?). Iterating over 
stdin can use some work too, but those other ones are more worrisome to me.

----------
nosy: +justinpeel

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

From tracker at bugs.pypy.org  Sat Jul 16 15:14:02 2011
From: tracker at bugs.pypy.org (timo)
Date: Sat, 16 Jul 2011 13:14:02 +0000
Subject: [pypy-issue] [issue706] `import pybrain` fails in 1.5 on OSX
In-Reply-To: <1304254267.44.0.60280835989.issue706@>
Message-ID: <1310822042.58.0.0699504496233.issue706@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

you need to install pybrain using pypy. pypy will not use the site-packages 
folder from python (especially not from python2.6, as pypy conforms to the 
python 2.7 spec now)

you would probably want to open a virtualenv (make sure you have a new version!) 
and from within it, using pypy, run pip install pybrain, that should then work.

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

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

From tracker at bugs.pypy.org  Sat Jul 16 15:40:16 2011
From: tracker at bugs.pypy.org (timo)
Date: Sat, 16 Jul 2011 13:40:16 +0000
Subject: [pypy-issue] [issue706] `import pybrain` fails in 1.5 on OSX
In-Reply-To: <1304254267.44.0.60280835989.issue706@>
Message-ID: <1310823616.01.0.590811320395.issue706@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

my apologies, i just tried it myself and you are going to run into another 
problem: pybrain needs scipy, which pypy doesn't support yet, due to the very 
limited numpy support.

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

From tracker at bugs.pypy.org  Sat Jul 16 15:45:06 2011
From: tracker at bugs.pypy.org (Albert Zeyer)
Date: Sat, 16 Jul 2011 13:45:06 +0000
Subject: [pypy-issue] [issue706] `import pybrain` fails in 1.5 on OSX
In-Reply-To: <1304254267.44.0.60280835989.issue706@>
Message-ID: <1310823906.12.0.0126869531815.issue706@bugs.pypy.org>


Albert Zeyer <albzey at gmail.com> added the comment:

Yea...

The SciPy/Numpy functions which are used by PyBrain are also only very basics ones 
(matrix multiplications, etc.), so it might be that not so much is missing.

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

From fijall at gmail.com  Sat Jul 16 15:57:30 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 16 Jul 2011 15:57:30 +0200
Subject: [pypy-issue] [issue706] `import pybrain` fails in 1.5 on OSX
In-Reply-To: <1310823906.12.0.0126869531815.issue706@bugs.pypy.org>
References: <1310823906.12.0.0126869531815.issue706@bugs.pypy.org>
Message-ID: <CAK5idxTXiCuFyBS23dnQF1oZQ1SENoNpwNHgby-qLLErLK24Uw@mail.gmail.com>

On Sat, Jul 16, 2011 at 3:45 PM, Albert Zeyer <tracker at bugs.pypy.org> wrote:
>
> Albert Zeyer <albzey at gmail.com> added the comment:
>
> Yea...
>
> The SciPy/Numpy functions which are used by PyBrain are also only very basics ones
> (matrix multiplications, etc.), so it might be that not so much is missing.

It would be good if you try and then report exactly what is missing

>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue706>
> ________________________________________
> _______________________________________________
> pypy-issue mailing list
> pypy-issue at python.org
> http://mail.python.org/mailman/listinfo/pypy-issue
>

From tracker at bugs.pypy.org  Sat Jul 16 19:43:23 2011
From: tracker at bugs.pypy.org (Dan Villiom Podlaski Christiansen)
Date: Sat, 16 Jul 2011 17:43:23 +0000
Subject: [pypy-issue] [issue766] Shadowstack root finder should be
	competitive with asmgcc	in speed
In-Reply-To: <1309087727.89.0.866221341976.issue766@bugs.pypy.org>
Message-ID: <1310838203.21.0.0912358147661.issue766@bugs.pypy.org>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

I did another benchmark run a couple of days ago; a full self-hosting translation 
of PyPy. Shadowstack did it ~2% slower, but that's including the C code.

/tmp/pypy-c-jit-45336-6d1937f2d0a9-osx64-shadowstack-clang/bin/pypy
[[Timer] Timings:
[Timer] annotate                       --- 1038.1 s
[Timer] rtype_lltype                   ---  507.8 s
[Timer] pyjitpl_lltype                 ---  777.1 s
[Timer] backendopt_lltype              ---  272.0 s
[Timer] stackcheckinsertion_lltype     ---   53.2 s
[Timer] database_c                     ---  439.4 s
[Timer] source_c                       ---  488.7 s
[Timer] compile_c                      ---  925.6 s
[Timer] ===========================================
[Timer] Total:                         --- 4502.0 s
$i ./translate.py -Ojit --batch  3520,69s user 45,93s system 78% cpu 1:16:03,38 
total

/tmp/pypy-c-jit-45336-6d1937f2d0a9-osx64/bin/pypy
[Timer] Timings:
[Timer] annotate                       --- 1044.8 s
[Timer] rtype_lltype                   ---  516.2 s
[Timer] pyjitpl_lltype                 ---  748.4 s
[Timer] backendopt_lltype              ---  262.9 s
[Timer] stackcheckinsertion_lltype     ---   58.6 s
[Timer] database_c                     ---  420.9 s
[Timer] source_c                       ---  484.4 s
[Timer] compile_c                      ---  950.0 s
[Timer] ===========================================
[Timer] Total:                         --- 4486.0 s
$i ./translate.py -Ojit --batch  3457,19s user 48,06s system 76% cpu 1:16:01,20 
total

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

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

From tracker at bugs.pypy.org  Sat Jul 16 22:17:43 2011
From: tracker at bugs.pypy.org (Dan Villiom Podlaski Christiansen)
Date: Sat, 16 Jul 2011 20:17:43 +0000
Subject: [pypy-issue] [issue766] Shadowstack root finder should be
	competitive with asmgcc	in speed
In-Reply-To: <1309087727.89.0.866221341976.issue766@bugs.pypy.org>
Message-ID: <1310847463.81.0.378761771599.issue766@bugs.pypy.org>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

mvt also did a run on Mac OS X, and his results mirror a run I just did: 
http://paste.pocoo.org/show/rTE982MptcWFWvgwj08N/

Shadowstack now varies from 5% faster to 15% slower.

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

From tracker at bugs.pypy.org  Sun Jul 17 03:25:49 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 17 Jul 2011 01:25:49 +0000
Subject: [pypy-issue] [issue787] Crash in the assembler backend when running
	Django
In-Reply-To: <1310234561.52.0.793947069726.issue787@bugs.pypy.org>
Message-ID: <1310865949.72.0.15778625722.issue787@bugs.pypy.org>


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

Armin fixed this, turns out the issue was with RPython __del__ calling the world.

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

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

From tracker at bugs.pypy.org  Tue Jul 19 12:26:30 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 19 Jul 2011 10:26:30 +0000
Subject: [pypy-issue] [issue797] Deadlock with threads
In-Reply-To: <1310774437.29.0.502693384399.issue797@bugs.pypy.org>
Message-ID: <1311071190.91.0.40235652287.issue797@bugs.pypy.org>


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

Fixed in 10d2740f6ab6

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

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

From tracker at bugs.pypy.org  Tue Jul 19 14:30:45 2011
From: tracker at bugs.pypy.org (David Griffin)
Date: Tue, 19 Jul 2011 12:30:45 +0000
Subject: [pypy-issue] [issue798] RPython: DictRepr instance has no attribute
	ll_str
In-Reply-To: <1311078645.0.0.218402655063.issue798@bugs.pypy.org>
Message-ID: <1311078645.0.0.218402655063.issue798@bugs.pypy.org>


New submission from David Griffin <habilain at gmail.com>:

Trying to translate the following code generates the unhelpful error message
"AttributeError: DictRepr instance has no attribute ll_str". 

def main(x):
  print {}
  return 0

def target(*args):
    return (main, None)

Cause: Dicts cannot be converted to strings in RPython, so the print fails.

Note that this bug doesn't have to be fixed; if nothing else, this bug report
will serve well in helping people find why their code won't translate, as the
only other reference to this error is an unsolved question in the PyPy IRC logs.

----------
messages: 2820
nosy: habilain, pypy-issue
priority: bug
status: chatting
title: RPython: DictRepr instance has no attribute ll_str

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

From tracker at bugs.pypy.org  Tue Jul 19 14:33:35 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 19 Jul 2011 12:33:35 +0000
Subject: [pypy-issue] [issue798] RPython: DictRepr instance has no attribute
	ll_str
In-Reply-To: <1311078645.0.0.218402655063.issue798@bugs.pypy.org>
Message-ID: <1311078815.65.0.230006853091.issue798@bugs.pypy.org>


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

Hi

RPython is not a general purpose language and I don't think providing a useful 
error message for each possible not-RPython problem is feasible. Feel free to 
provide a patch that improves the error message (like makes sure that you catch 
it during annotation), but this is a wontfix otherwise.

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

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

From tracker at bugs.pypy.org  Tue Jul 19 14:39:52 2011
From: tracker at bugs.pypy.org (David Griffin)
Date: Tue, 19 Jul 2011 12:39:52 +0000
Subject: [pypy-issue] [issue798] RPython: DictRepr instance has no attribute
	ll_str
In-Reply-To: <1311078645.0.0.218402655063.issue798@bugs.pypy.org>
Message-ID: <1311079192.61.0.0867805238627.issue798@bugs.pypy.org>


David Griffin <habilain at gmail.com> added the comment:

Indeed true; however I encountered the issue in some debug code for an
interpreter, which is RPythons primary use case. As I said, if nothing else the
bug report is useful to just highlight what the error message actually means
rather than getting a fix.

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

From tracker at bugs.pypy.org  Tue Jul 19 14:43:12 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 19 Jul 2011 12:43:12 +0000
Subject: [pypy-issue] [issue798] RPython: DictRepr instance has no attribute
	ll_str
In-Reply-To: <1311078645.0.0.218402655063.issue798@bugs.pypy.org>
Message-ID: <1311079392.12.0.913084482124.issue798@bugs.pypy.org>


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

Maybe a wiki page for PyPy on bitbucket would be better though?

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

From tracker at bugs.pypy.org  Tue Jul 19 14:56:24 2011
From: tracker at bugs.pypy.org (David Griffin)
Date: Tue, 19 Jul 2011 12:56:24 +0000
Subject: [pypy-issue] [issue798] RPython: DictRepr instance has no attribute
	ll_str
In-Reply-To: <1311078645.0.0.218402655063.issue798@bugs.pypy.org>
Message-ID: <1311080184.14.0.108805532937.issue798@bugs.pypy.org>


David Griffin <habilain at gmail.com> added the comment:

Good point. I made a Wiki page for cryptic error messages on the Pypy wiki page.
Hopefully other error messages can be added there as well.

https://bitbucket.org/pypy/pypy/wiki/CrypticErrorMessages

Also, that wiki page needs to be better advertised. I didn't know it existed up
until now.

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

From tracker at bugs.pypy.org  Tue Jul 19 20:22:35 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 19 Jul 2011 18:22:35 +0000
Subject: [pypy-issue] [issue799] Strange exception with threads
In-Reply-To: <1311099755.31.0.9334660034.issue799@bugs.pypy.org>
Message-ID: <1311099755.31.0.9334660034.issue799@bugs.pypy.org>


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

Now that the deadlock is fixed, there is now a rather strange exception which is 
non-deterministically produced (I've even seen the script exit successfully), 
the code:


import gc
import threading


def get_results():
    pass

def main():
    i = 0
    while i < 5000000:
        t = threading.Thread(target=get_results)
        t.start()
        t.join()
        i += 1
        if i % 1000 == 0:
            print i

main()


and the produced exception::


  File "app_main.py", line 53, in run_toplevel
  File "t.py", line 18, in <module>
    main()
  File "t.py", line 13, in main
    t.join()
  File "/home/alex/projects/pypy/lib-python/2.7/threading.py", line 630, in join
    if not self.__started.is_set():
AttributeError: 'int' object has no attribute 'is_set'
Exception AttributeError: "'int' object has no attribute 'is_set'" in 
threading._shutdown() ignored

----------
messages: 2825
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: Strange exception with threads

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

From tracker at bugs.pypy.org  Wed Jul 20 23:40:07 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 20 Jul 2011 21:40:07 +0000
Subject: [pypy-issue] [issue800] Don't allow arbitrary objects as exceptions
In-Reply-To: <1311197871.56.0.501499676007.issue800@bugs.pypy.org>
Message-ID: <1311198007.9.0.0410672071212.issue800@bugs.pypy.org>


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

Correct me if I'm wrong but I don't think you attached a patch

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

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

From tracker at bugs.pypy.org  Thu Jul 21 01:29:43 2011
From: tracker at bugs.pypy.org (Yesudeep Mangalapilly)
Date: Wed, 20 Jul 2011 23:29:43 +0000
Subject: [pypy-issue] [issue801] itertools/next(?) behavior incompatible
	with CPython
In-Reply-To: <1311204583.22.0.333294855897.issue801@bugs.pypy.org>
Message-ID: <1311204583.22.0.333294855897.issue801@bugs.pypy.org>


New submission from Yesudeep Mangalapilly <yesudeep at gmail.com>:

I believe either the itertools module or the next builtin
does not share exactly the same behavior with CPython.
Here's an extract from a library I'm working on: 

Sample Program
==============

    #!/usr/bin/env python
    # -*- coding: utf-8 -*-

    from itertools import islice

    def eat(iterator, n):
        next(islice(iterator, n, n), None)
    
    it = iter([1, 2, 3] * 4)
    eat(it, 9)
    x = tuple(it)
    print(x)
    assert x == (1, 2, 3)

Python 2.x or 3.x (expected behavior)
=====================================

    (1, 2, 3)

PyPy 1.5 (got behavior)
=======================

    (1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3)
    Traceback (most recent call last):
      File "app_main.py", line 53, in run_toplevel
      File "foobar.py", line 13, in <module>
        assert x == (1, 2, 3)
    AssertionError

----------
messages: 2831
nosy: pypy-issue, yesudeep
priority: bug
release: 1.5
status: unread
title: itertools/next(?) behavior incompatible with CPython

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

From tracker at bugs.pypy.org  Thu Jul 21 03:47:30 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 21 Jul 2011 01:47:30 +0000
Subject: [pypy-issue] [issue801] itertools/next(?) behavior incompatible
	with CPython
In-Reply-To: <1311204583.22.0.333294855897.issue801@bugs.pypy.org>
Message-ID: <1311212850.47.0.282517161661.issue801@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

The problem was with islice. I've attached a patch that fixes the problem and 
adds in a simple test for this behavior. If someone sees a simpler way of fixing 
it then please do so.

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

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

From tracker at bugs.pypy.org  Thu Jul 21 14:31:48 2011
From: tracker at bugs.pypy.org (Yesudeep Mangalapilly)
Date: Thu, 21 Jul 2011 12:31:48 +0000
Subject: [pypy-issue] [issue802] Incorrect error message when string split
	assignment	cannot unpack values
In-Reply-To: <1311251508.55.0.60139114275.issue802@bugs.pypy.org>
Message-ID: <1311251508.55.0.60139114275.issue802@bugs.pypy.org>


New submission from Yesudeep Mangalapilly <yesudeep at gmail.com>:

Incorrect error message generated when trying to 
unpack values in an assignment:

Current Behavior:
-----------------
    $ pypy
    Python 2.7.1 (b590cf6de419, Apr 30 2011, 03:30:00)
    [PyPy 1.5.0-alpha0 with GCC 4.0.1] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    And now for something completely different: ``<cami> I like workin with pypy,
    it's like speaking chinese''
    >>>> n, v = "something".split("=", 1)
    Traceback (most recent call last):
      File "<console>", line 1, in <module>
    ValueError: expected length 2, got 1

Expected Behavior:
------------------
    $ python
    Python 2.7.1 (r271:86832, Dec  4 2010, 05:03:53) 
    [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> n, v = "something".split("=", 1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: need more than 1 value to unpack


Essentially, the error message needs to be changed.
Some of our in-code asserts started failing because 
of this.

----------
messages: 2833
nosy: pypy-issue, yesudeep
priority: bug
status: unread
title: Incorrect error message when string split assignment cannot unpack values

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

From tracker at bugs.pypy.org  Thu Jul 21 14:33:21 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 21 Jul 2011 12:33:21 +0000
Subject: [pypy-issue] [issue802] Incorrect error message when string split
	assignment	cannot unpack values
In-Reply-To: <1311251508.55.0.60139114275.issue802@bugs.pypy.org>
Message-ID: <1311251601.38.0.016351984306.issue802@bugs.pypy.org>


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

Sorry, this is unlikely to be fixed.  The exact error messages of errors change
even from one version of CPython to the next one; relying on them in your tests
is bogus.

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

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

From tracker at bugs.pypy.org  Thu Jul 21 14:47:27 2011
From: tracker at bugs.pypy.org (Yesudeep Mangalapilly)
Date: Thu, 21 Jul 2011 12:47:27 +0000
Subject: [pypy-issue] [issue802] Incorrect error message when string split
	assignment	cannot unpack values
In-Reply-To: <1311251508.55.0.60139114275.issue802@bugs.pypy.org>
Message-ID: <1311252447.6.0.00455283292785.issue802@bugs.pypy.org>


Yesudeep Mangalapilly <yesudeep at gmail.com> added the comment:

I realize this is unlikely to be fixed
and hence have changed all the code that
relied on error messages to not do so.
However, there is quite a bit of code
out there that already does.

You're likely to receive a lot of 
frustrated users. =)

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

From tracker at bugs.pypy.org  Thu Jul 21 16:10:11 2011
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Thu, 21 Jul 2011 14:10:11 +0000
Subject: [pypy-issue] [issue802] Incorrect error message when string split
	assignment	cannot unpack values
In-Reply-To: <1311251508.55.0.60139114275.issue802@bugs.pypy.org>
Message-ID: <1311257411.04.0.182763171166.issue802@bugs.pypy.org>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

I agree with Armin, our message is more precise so it feels silly to change it.
Also, the strings of exceptions are not even the same between different CPython
versions, so relying on them is generally a bad idea.

----------
nosy: +cfbolz

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

From tracker at bugs.pypy.org  Thu Jul 21 16:17:06 2011
From: tracker at bugs.pypy.org (Yesudeep Mangalapilly)
Date: Thu, 21 Jul 2011 14:17:06 +0000
Subject: [pypy-issue] [issue802] Incorrect error message when string split
	assignment	cannot unpack values
In-Reply-To: <1311251508.55.0.60139114275.issue802@bugs.pypy.org>
Message-ID: <1311257826.15.0.545803507504.issue802@bugs.pypy.org>


Yesudeep Mangalapilly <yesudeep at gmail.com> added the comment:

Yep, I agree with the decision too.

Now, if the authors of the libraries
we're depending on would understand
that and accept patches without us
having to wait for weeks, that'd be 
great.

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

From tracker at bugs.pypy.org  Thu Jul 21 16:33:51 2011
From: tracker at bugs.pypy.org (Chris Lambacher)
Date: Thu, 21 Jul 2011 14:33:51 +0000
Subject: [pypy-issue] [issue803] Crash when with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>


New submission from Chris Lambacher <chris at kateandchris.net>:

Version: 45778:fba910e841e1 from trunk.

C:\work\cioc\pybuild\pyodbc>c:\work\pypy\pypy\pypy\translator\goal\pypy-c.exe
Python 2.7.1 (3f7ee4a5a25a, Jul 21 2011, 01:18:16)
[PyPy 1.6.0-dev1 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``topics are for the feeble
minded''
>>>> import os, platform
>>>> def getoutput(cmd):
....     pipe = os.popen(cmd, 'r')
....     text   = pipe.read().rstrip('\n')
....     status = pipe.close() or 0
....     return status, text
....
>>>> getoutput('git describe --tags --match 2.*')
missing liveness[116] in W_TypeObject.lookup_where_with_method_cache
RPython traceback:
  File "jit_metainterp_pyjitpl_1.c", line 18460, in MIFrame_capture_resumedata
  File "jit_metainterp_resume.c", line 3187, in capture_resumedata
  File "jit_metainterp_resume.c", line 3634, in _ensure_parent_resumedata
  File "jit_metainterp_pyjitpl_1.c", line 61156, in 
MIFrame_get_list_of_active_boxes
  File "jit_codewriter_jitcode.c", line 308, in JitCode__missing_liveness
Fatal RPython error: AssertionError

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

----------
messages: 2838
nosy: lambacck, pypy-issue
priority: bug
status: unread
title: Crash when with os.popen pipe

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

From tracker at bugs.pypy.org  Thu Jul 21 16:46:54 2011
From: tracker at bugs.pypy.org (Chris Lambacher)
Date: Thu, 21 Jul 2011 14:46:54 +0000
Subject: [pypy-issue] [issue803] Crash when with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1311259614.03.0.871154879055.issue803@bugs.pypy.org>


Chris Lambacher <chris at kateandchris.net> added the comment:

Note that importing platform *seems* to be important to the crash. When I take the 
import platform away, it does not crash.

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

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

From tracker at bugs.pypy.org  Thu Jul 21 17:07:52 2011
From: tracker at bugs.pypy.org (Albert Zeyer)
Date: Thu, 21 Jul 2011 15:07:52 +0000
Subject: [pypy-issue] [issue804] bug in initialization of ast.AST types
In-Reply-To: <1311260872.86.0.419198964942.issue804@bugs.pypy.org>
Message-ID: <1311260872.86.0.419198964942.issue804@bugs.pypy.org>


New submission from Albert Zeyer <albzey at gmail.com>:

Code:

```
import ast
n = ast.FunctionDef(name=None)
n.name = "foo"
print n.name
```

This prints `None` with PyPy 1.5.0-alpha0. And the expected `foo` with CPython 
2.6.

----------
messages: 2840
nosy: albert, pypy-issue
priority: bug
status: unread
title: bug in initialization of ast.AST types

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

From tracker at bugs.pypy.org  Fri Jul 22 00:17:31 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Jul 2011 22:17:31 +0000
Subject: [pypy-issue] [issue805] 64 bit 30% slower than 32bit pypy
In-Reply-To: <1311286651.76.0.72341859087.issue805@bugs.pypy.org>
Message-ID: <1311286651.76.0.72341859087.issue805@bugs.pypy.org>


New submission from Fijal <fijall at gmail.com>:

Attached example (regexes)

----------
messages: 2841
nosy: fijal, pypy-issue
priority: bug
status: unread
title: 64 bit 30% slower than 32bit pypy

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

From tracker at bugs.pypy.org  Fri Jul 22 15:15:57 2011
From: tracker at bugs.pypy.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:15:57 +0000
Subject: [pypy-issue] [issue806] crash when running Python code
In-Reply-To: <1311340557.95.0.641226391059.issue806@bugs.pypy.org>
Message-ID: <1311340557.95.0.641226391059.issue806@bugs.pypy.org>


New submission from Albert Zeyer <albzey at gmail.com>:

Code:

```
import ast

globalsDict = {}

fAst = ast.FunctionDef(
	name="foo",
	args=ast.arguments(
		args=[], vararg=None, kwarg=None, defaults=[],
		kwonlyargs=[], kw_defaults=[]),
	body=[], decorator_list=[])

exprAst = ast.Interactive(body=[fAst])
ast.fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, globalsDict, globalsDict)

print(globalsDict["foo"])
```

Also CPython 2.6, 2.7, 3.0 and 3.2 crash on this. They crash in the 
PyAST_Compile function.

----------
messages: 2842
nosy: albert, pypy-issue
priority: critical
release: 1.5
status: unread
title: crash when running Python code

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

From tracker at bugs.pypy.org  Fri Jul 22 15:17:15 2011
From: tracker at bugs.pypy.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:17:15 +0000
Subject: [pypy-issue] [issue806] crash when running Python code with
	`compile`
In-Reply-To: <1311340557.95.0.641226391059.issue806@bugs.pypy.org>
Message-ID: <1311340635.3.0.0862354208013.issue806@bugs.pypy.org>


Albert Zeyer <albzey at gmail.com> added the comment:

CPython bug report: http://bugs.python.org/issue12608
Question on StackOverflow: http://stackoverflow.com/questions/6778816/python-
getting-segmentation-fault-when-using-compile-eval

----------
status: unread -> chatting
title: crash when running Python code -> crash when running Python code with `compile`

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

From tracker at bugs.pypy.org  Fri Jul 22 17:32:02 2011
From: tracker at bugs.pypy.org (Chris Lambacher)
Date: Fri, 22 Jul 2011 15:32:02 +0000
Subject: [pypy-issue] [issue803] Crash with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1311348722.19.0.563121436182.issue803@bugs.pypy.org>


Chris Lambacher <chris at kateandchris.net> added the comment:

With head as of last night (45854:631e083bd996) now we get:

Unhandled exception at 0x101bf37f in pypy-c.exe: 0xC0000005: Access violation reading location 
0x00000004.

When I jump into the VS just in time debugger.

There are not debug symbols, so I don't know a source line. I do know that the exception is happening 
in libpypy-c.dll.

----------
title: Crash when with os.popen pipe -> Crash with os.popen pipe

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

From tracker at bugs.pypy.org  Fri Jul 22 21:35:13 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 22 Jul 2011 19:35:13 +0000
Subject: [pypy-issue] [issue803] Crash with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1311363313.97.0.617276759796.issue803@bugs.pypy.org>


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

Note that the win32 buildbot fails with the same error
(missing liveness[116] in W_TypeObject.lookup_where_with_method_cache)

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Sat Jul 23 03:41:51 2011
From: tracker at bugs.pypy.org (Chris Lambacher)
Date: Sat, 23 Jul 2011 01:41:51 +0000
Subject: [pypy-issue] [issue803] Crash with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1311385311.07.0.3048020231.issue803@bugs.pypy.org>


Chris Lambacher <chris at kateandchris.net> added the comment:

Hmm. I'm now on 45886:e24c11f9222b with debug=True set in 
pypy/jit/codewriter/codewriter.py. I am now not getting an error. Not sure if it 
is the new version or debug=True (leaning to new version).

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

From tracker at bugs.pypy.org  Sat Jul 23 10:41:25 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 23 Jul 2011 08:41:25 +0000
Subject: [pypy-issue] [issue803] Crash with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1311410485.24.0.459060882036.issue803@bugs.pypy.org>


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

Hi.

Can you paste the error somewhere?

----------
nosy: +fijal

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

From tracker at bugs.pypy.org  Sat Jul 23 23:04:03 2011
From: tracker at bugs.pypy.org (Albert Zeyer)
Date: Sat, 23 Jul 2011 21:04:03 +0000
Subject: [pypy-issue] [issue807] wrong exception with ctypes cast
In-Reply-To: <1311455043.26.0.949305341768.issue807@bugs.pypy.org>
Message-ID: <1311455043.26.0.949305341768.issue807@bugs.pypy.org>


New submission from Albert Zeyer <albzey at gmail.com>:

Code:

```
import ctypes
__dummy_b = ctypes.c_uint(0)
__dummy_b = ctypes.cast(ctypes.c_void_p(ctypes.cast(__dummy_b, 
ctypes.c_void_p).value), ctypes.POINTER(ctypes.c_char))
```

Expected exception (what I get with CPython 2.7.1):
ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type

Exception in PyPy 1.5:
AttributeError: 'int' object has no attribute 'value'

----------
messages: 2848
nosy: albert, pypy-issue
priority: bug
release: 1.5
status: unread
title: wrong exception with ctypes cast

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

From tracker at bugs.pypy.org  Sun Jul 24 02:10:05 2011
From: tracker at bugs.pypy.org (linq)
Date: Sun, 24 Jul 2011 00:10:05 +0000
Subject: [pypy-issue] [issue725] Bug in zipimporting in nested packages
In-Reply-To: <1305720180.28.0.132370010701.issue725@bugs.pypy.org>
Message-ID: <1311466205.89.0.00829779142455.issue725@bugs.pypy.org>


linq <relinquish at gmail.com> added the comment:

I can reproduce this issue on my machine running windows XP SP3. I am running
pypy 1.5.0-alpha0, and my traceback looks exactly like cool-RR's below. Here is
some relevant environment variables:

PATH=C:\windows\sylinqm32;C:\linq\p\pypy\pypy-1.5.0a0-win32;C:\linq\p\pypy\pypy-1.5.0a0-win32\lib-python\2.7;C:\linq\p\pypy\pypy-1.5.0a0-win32\lib_pypy

PYTHONPATH=C:\linq\p\pypy\pypy-1.5.0a0-win32;C:\linq\p\pypy\pypy-1.5.0a0-win32\lib-python;C:\linq\p\pypy\pypy-1.5.0a0-win32\lib_pypy;C:\linq\p\pypy\pypy-1.5.0a0-win32\site-packages

FYI, this issue is currently standing in my way of using virtualenv. Whenever I
try to create a new virtualenv, it attempts to download a setuptools egg which
then proceeds to fail with a similar error. I will file another issue report and
traceback if necessary.

----------
nosy: +linq

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

From tracker at bugs.pypy.org  Sun Jul 24 12:13:19 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 10:13:19 +0000
Subject: [pypy-issue] [issue806] crash when running Python code with
	`compile`
In-Reply-To: <1311340557.95.0.641226391059.issue806@bugs.pypy.org>
Message-ID: <1311502399.33.0.159344476856.issue806@bugs.pypy.org>


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

Fixed in c525a219909f.

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

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

From tracker at bugs.pypy.org  Sun Jul 24 12:43:20 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 10:43:20 +0000
Subject: [pypy-issue] [issue801] itertools/next(?) behavior incompatible
	with CPython
In-Reply-To: <1311204583.22.0.333294855897.issue801@bugs.pypy.org>
Message-ID: <1311504200.5.0.657195079563.issue801@bugs.pypy.org>


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

Fixed in b06b8d4e38c5, thanks!

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

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

From tracker at bugs.pypy.org  Sun Jul 24 13:03:43 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 11:03:43 +0000
Subject: [pypy-issue] [issue800] Don't allow arbitrary objects as exceptions
In-Reply-To: <1311197871.56.0.501499676007.issue800@bugs.pypy.org>
Message-ID: <1311505423.16.0.0155596616741.issue800@bugs.pypy.org>


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

Fixed in 97ce6ad3bd73.  Thanks!

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

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

From tracker at bugs.pypy.org  Sun Jul 24 13:40:14 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 11:40:14 +0000
Subject: [pypy-issue] [issue804] bug in initialization of ast.AST types
In-Reply-To: <1311260872.86.0.419198964942.issue804@bugs.pypy.org>
Message-ID: <1311507614.94.0.224728217542.issue804@bugs.pypy.org>


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

Fixed in e6712f5d73d8.  Thanks!

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

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

From tracker at bugs.pypy.org  Sun Jul 24 13:57:11 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 11:57:11 +0000
Subject: [pypy-issue] [issue793] Segfault in AST compilation if Pass is
	omitted
In-Reply-To: <1310577525.95.0.765671279723.issue793@bugs.pypy.org>
Message-ID: <1311508631.85.0.279543337101.issue793@bugs.pypy.org>


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

Fixed in 4d416d3a6e38.  Thanks!

Sorry benjamin, I fixed another issue first, and only came to this one later,
realizing that it was mostly the same thing.

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

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

From tracker at bugs.pypy.org  Sun Jul 24 14:24:18 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 12:24:18 +0000
Subject: [pypy-issue] [issue781] Confusing error message on "with"
In-Reply-To: <1309923993.89.0.148109696461.issue781@bugs.pypy.org>
Message-ID: <1311510258.86.0.541321205301.issue781@bugs.pypy.org>


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

No, we raise the error message explicitly in SETUP_WITH in pyopcode.  Easy to
fix (ea1d8b0f01bd).

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

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

From tracker at bugs.pypy.org  Sun Jul 24 14:30:29 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 12:30:29 +0000
Subject: [pypy-issue] [issue774] Telco benchmark got slower
In-Reply-To: <1309678995.86.0.522812840288.issue774@bugs.pypy.org>
Message-ID: <1311510629.52.0.759605230343.issue774@bugs.pypy.org>


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

It could be "f430562b29e8: merge jitcounter-on-function".  Do you still want to
keep this bug open, though?  It looks to me like a random effect of tracing,
maybe related to trace_limit.  And Telco is nowadays faster than it ever was.

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

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

From tracker at bugs.pypy.org  Sun Jul 24 14:36:03 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 12:36:03 +0000
Subject: [pypy-issue] [issue775] bm_mako got slower
In-Reply-To: <1309679036.24.0.307631636135.issue775@bugs.pypy.org>
Message-ID: <1311510963.94.0.101045246506.issue775@bugs.pypy.org>


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

It's likely "5b62f71347c8: Merged app level builder."

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

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

From tracker at bugs.pypy.org  Sun Jul 24 15:35:30 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 24 Jul 2011 13:35:30 +0000
Subject: [pypy-issue] [issue774] Telco benchmark got slower
In-Reply-To: <1309678995.86.0.522812840288.issue774@bugs.pypy.org>
Message-ID: <1311514530.74.0.273721886383.issue774@bugs.pypy.org>


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

Closing this. I think those are "random effects" that we can ignore.

----------
status: chatting -> wontfix

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

From tracker at bugs.pypy.org  Sun Jul 24 18:49:17 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 24 Jul 2011 16:49:17 +0000
Subject: [pypy-issue] [issue792] builtin pow() gives wrong answer
In-Reply-To: <1310544815.87.0.878408212727.issue792@bugs.pypy.org>
Message-ID: <1311526157.08.0.256346840481.issue792@bugs.pypy.org>


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

Fixed in 70d00af8294e.  Actually I just disabled the special path for
'pow(x,y,z)' for the case of huge 'y', which was buggy because it assumed that
SHIFT was a multiple of 5.  I'm ready to reintroduce it if really needed, but it
should be at most a constant factor's difference, not a better algorithmic factor.

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

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

From tracker at bugs.pypy.org  Mon Jul 25 20:11:34 2011
From: tracker at bugs.pypy.org (Chris Lambacher)
Date: Mon, 25 Jul 2011 18:11:34 +0000
Subject: [pypy-issue] [issue803] Crash with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1311617494.26.0.245106727263.issue803@bugs.pypy.org>


Chris Lambacher <chris at kateandchris.net> added the comment:

This is a problem again in 45964:b6be8465a274

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

From tracker at bugs.pypy.org  Mon Jul 25 20:50:55 2011
From: tracker at bugs.pypy.org (Connelly Barnes)
Date: Mon, 25 Jul 2011 18:50:55 +0000
Subject: [pypy-issue] [issue808] Pypy throws exception when typecasting
	array whereas	CPython doesn't
In-Reply-To: <1311619855.35.0.981990502118.issue808@bugs.pypy.org>
Message-ID: <1311619855.35.0.981990502118.issue808@bugs.pypy.org>


New submission from Connelly Barnes <connellybarnes at gmail.com>:

CPython can cast from any of the integer array types to float 'f' or double 'd'. 
In contrast, pypy fails with an exception:

Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
>>> a=array.array('i',[1,2,3])
>>> b=array.array('d',a)
>>> b
array('d', [1.0, 2.0, 3.0])

C:\Code\stock>pypy
Python 2.7.1 (aefc70438132+, Apr 29 2011, 12:45:42)
[PyPy 1.5.0-alpha0 with MSC v.1600 32 bit] on win32
>>>> a=array.array('i',[1,2,3])
>>>> b=array.array('d',a)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: can only extend with array of same kind

After fixing the bug, the following test should run without any exceptions (as 
it does in CPython). It currently raises a TypeError in Pypy:

>>> for itype in 'bBhHiIlL':
...   a = array.array(itype, [1, 2, 3])
...   assert array.array('d',a) == array.array('d',[1,2,3])
...   assert array.array('f',a) == array.array('f',[1,2,3])
...
>>>

----------
messages: 2861
nosy: connelly, pypy-issue
priority: bug
status: unread
title: Pypy throws exception when typecasting array whereas CPython doesn't

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

From tracker at bugs.pypy.org  Mon Jul 25 20:56:20 2011
From: tracker at bugs.pypy.org (Connelly Barnes)
Date: Mon, 25 Jul 2011 18:56:20 +0000
Subject: [pypy-issue] [issue808] Pypy throws exception when typecasting
	array whereas	CPython doesn't
In-Reply-To: <1311619855.35.0.981990502118.issue808@bugs.pypy.org>
Message-ID: <1311620180.36.0.93358981453.issue808@bugs.pypy.org>


Connelly Barnes <connellybarnes at gmail.com> added the comment:

Note that both CPython and Pypy raise an error when extending a float array with 
an integer array. So apparently Pypy's behavior in extend() is correct... 
Although this seems somewhat inconsistent of CPython.

C:\Code\stock>python
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
>>> a=array.array('f',[1,2,3])
>>> b=array.array('i',[4,5,6])
>>> a.extend(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only extend with array of same kind

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

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

From tracker at bugs.pypy.org  Tue Jul 26 00:33:35 2011
From: tracker at bugs.pypy.org (Tristan Seligmann)
Date: Mon, 25 Jul 2011 22:33:35 +0000
Subject: [pypy-issue] [issue809] Iterating sqlite cursor after executing a
	CREATE TABLE	statement fails
In-Reply-To: <1311633215.94.0.0379391444019.issue809@bugs.pypy.org>
Message-ID: <1311633215.94.0.0379391444019.issue809@bugs.pypy.org>


New submission from Tristan Seligmann <mithrandi at mithrandi.net>:

See attached python file for an SSCCE that demonstrates this issue.

----------
messages: 2863
nosy: pypy-issue
priority: feature
status: unread
title: Iterating sqlite cursor after executing a CREATE TABLE statement fails

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

From tracker at bugs.pypy.org  Tue Jul 26 14:55:04 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 26 Jul 2011 12:55:04 +0000
Subject: [pypy-issue] [issue737] Crash on OS X, maybe in RPyThreadAfterFork
In-Reply-To: <1307107329.87.0.9341809675.issue737@bugs.pypy.org>
Message-ID: <1311684904.74.0.846566902079.issue737@bugs.pypy.org>


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

This should have been fixed by the thread+fork work I did some time ago.  Can
you check?

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

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

From tracker at bugs.pypy.org  Tue Jul 26 15:27:38 2011
From: tracker at bugs.pypy.org (ymgve)
Date: Tue, 26 Jul 2011 13:27:38 +0000
Subject: [pypy-issue] [issue716] Crashes in hashlib on Windows
In-Reply-To: <1304768621.71.0.0122636956595.issue716@>
Message-ID: <1311686858.24.0.152167109417.issue716@bugs.pypy.org>


ymgve <ymgve.aa at gmail.com> added the comment:

Confirmed that it crashes here too. Windows 7 x64.

Build info:
Python 2.7.1 (aefc70438132+, Apr 29 2011, 12:45:42)
[PyPy 1.5.0-alpha0 with MSC v.1600 32 bit] on win32

I've attached another example. Changing the modulo number changes how many 
iterations it manages to do before it crashes. It crashes no matter the hash 
type (MD5, SHA1, SHA256, SHA512) and when using both digest() and hexdigest().

----------
nosy: +ymgve
title: Crashes with md5.hexdigest -> Crashes in hashlib on Windows

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

From tracker at bugs.pypy.org  Tue Jul 26 16:48:27 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 26 Jul 2011 14:48:27 +0000
Subject: [pypy-issue] [issue810] mmap on windows
In-Reply-To: <1311691707.43.0.380198087868.issue810@bugs.pypy.org>
Message-ID: <1311691707.43.0.380198087868.issue810@bugs.pypy.org>


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

mmap is likely broken on Windows with files larger than 2GB.  The corresponding
code in rlib/rmmap.py looks a bit random to me.

----------
messages: 2866
nosy: arigo, pypy-issue
priority: bug
status: unread
title: mmap on windows

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

From tracker at bugs.pypy.org  Tue Jul 26 17:06:01 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 26 Jul 2011 15:06:01 +0000
Subject: [pypy-issue] [issue810] mmap on windows
In-Reply-To: <1311691707.43.0.380198087868.issue810@bugs.pypy.org>
Message-ID: <1311692761.92.0.113835716738.issue810@bugs.pypy.org>


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

Well, on CPython the size is stored in a Py_ssize_t.

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

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

From tracker at bugs.pypy.org  Wed Jul 27 13:11:29 2011
From: tracker at bugs.pypy.org (aliles)
Date: Wed, 27 Jul 2011 11:11:29 +0000
Subject: [pypy-issue] [issue811] sys.excepthook not used by interactive
	interpreter
In-Reply-To: <1311765089.88.0.304830795357.issue811@bugs.pypy.org>
Message-ID: <1311765089.88.0.304830795357.issue811@bugs.pypy.org>


New submission from aliles <aaron.iles at gmail.com>:

Replacing sys.excepthook with an alternate function works if PyPy is not running 
as an interactive interpreter. The attached script works correctly if executed by 
PyPy, but not if imported into the interactive interpreter.

----------
files: excepthook.py
messages: 2868
nosy: aliles, pypy-issue
priority: bug
status: unread
title: sys.excepthook not used by interactive interpreter

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

From tracker at bugs.pypy.org  Wed Jul 27 13:25:20 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Wed, 27 Jul 2011 11:25:20 +0000
Subject: [pypy-issue] [issue807] wrong exception with ctypes cast
In-Reply-To: <1311455043.26.0.949305341768.issue807@bugs.pypy.org>
Message-ID: <1311765920.85.0.827718571336.issue807@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

fixed in e6043c6b9090

----------
status: unread -> resolved

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

From tracker at bugs.pypy.org  Wed Jul 27 13:33:36 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Wed, 27 Jul 2011 11:33:36 +0000
Subject: [pypy-issue] [issue811] sys.excepthook not used by interactive
	interpreter
In-Reply-To: <1311765089.88.0.304830795357.issue811@bugs.pypy.org>
Message-ID: <1311766416.81.0.135605663344.issue811@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

This is not a bug, CPython has the very same behavior:

$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import excepthook
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "excepthook.py", line 29, in <module>
    raise SyntaxError('FAIL')
SyntaxError: FAIL
>>> 

This happens because the interactive interpreter catches and prints the
exception by itself, so it never goes through the excepthook.

----------
status: unread -> invalid

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

From tracker at bugs.pypy.org  Wed Jul 27 13:37:17 2011
From: tracker at bugs.pypy.org (aliles)
Date: Wed, 27 Jul 2011 11:37:17 +0000
Subject: [pypy-issue] [issue811] sys.excepthook not used by interactive
	interpreter
In-Reply-To: <1311765089.88.0.304830795357.issue811@bugs.pypy.org>
Message-ID: <1311766637.13.0.975698761126.issue811@bugs.pypy.org>


aliles <aaron.iles at gmail.com> added the comment:

CPython 2.7.2 does exhibit this behaviour.

Python 2.7.2 (default, Jul  6 2011, 20:52:59) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import excepthook
Gulp!
>>>

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

From tracker at bugs.pypy.org  Wed Jul 27 13:42:49 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Wed, 27 Jul 2011 11:42:49 +0000
Subject: [pypy-issue] [issue811] sys.excepthook not used by interactive
	interpreter
In-Reply-To: <1311765089.88.0.304830795357.issue811@bugs.pypy.org>
Message-ID: <1311766969.86.0.72287555008.issue811@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

ah right, I suppose it's my fault :)
PyPy uses code.py to display the interactive prompt, while CPython has its own
written in C.

I got the same behavior on top of CPython because by default I use pyrepl (which
in turns uses code.py).  By disabling pyrepl, I can reproduce the "right"
behavior as well.

I suppose the bug belongs to code.py, you might want to submit it also upstream

----------
status: invalid -> chatting

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

From tracker at bugs.pypy.org  Wed Jul 27 14:11:21 2011
From: tracker at bugs.pypy.org (aliles)
Date: Wed, 27 Jul 2011 12:11:21 +0000
Subject: [pypy-issue] [issue811] sys.excepthook not used by interactive
	interpreter
In-Reply-To: <1311765089.88.0.304830795357.issue811@bugs.pypy.org>
Message-ID: <1311768681.49.0.559537866528.issue811@bugs.pypy.org>


aliles <aaron.iles at gmail.com> added the comment:

Whoa, that's a little more complicated than I was expecting. For completeness 
I've add a new file that reproduces the fault in code.py using an 
InteractiveConsole. I've submitted this upstream as issue 12643:
http://bugs.python.org/issue12643

Should I just close the bug here?

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

From tracker at bugs.pypy.org  Wed Jul 27 14:22:55 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 27 Jul 2011 12:22:55 +0000
Subject: [pypy-issue] [issue810] mmap on windows
In-Reply-To: <1311691707.43.0.380198087868.issue810@bugs.pypy.org>
Message-ID: <1311769375.23.0.830602870478.issue810@bugs.pypy.org>


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

>From a quick looking at the usage of "<<", what I meant is code like "size =
(high << 32) + low", which makes no sense on 32-bit and gives a warning by the C
compiler (which is how I found it out); and code like "if _64BIT: map_size =
(low << 32) + 1", which makes no sense for me so far, although that may just be
me not getting it.

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

From tracker at bugs.pypy.org  Wed Jul 27 22:59:15 2011
From: tracker at bugs.pypy.org (Jean-Paul Calderone)
Date: Wed, 27 Jul 2011 20:59:15 +0000
Subject: [pypy-issue] [issue737] Crash on OS X, maybe in RPyThreadAfterFork
In-Reply-To: <1307107329.87.0.9341809675.issue737@bugs.pypy.org>
Message-ID: <1311800355.14.0.506205145717.issue737@bugs.pypy.org>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Thanks.  I tested with a somewhat recent build, on Linux and OS X, and the 
problem appears resolved.

----------
status: testing -> resolved

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

From tracker at bugs.pypy.org  Thu Jul 28 02:20:18 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 28 Jul 2011 00:20:18 +0000
Subject: [pypy-issue] [issue767] copy.deepcopy is slower than cpython
In-Reply-To: <1309123235.59.0.562866927911.issue767@bugs.pypy.org>
Message-ID: <1311812418.11.0.734293694983.issue767@bugs.pypy.org>


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

Ok, going to mark this closed, as we are officially faster than CPython on this!  
We're even faster with the patch form CPython 12422 applied, but merging that in 
is a separate thing.

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

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

From tracker at bugs.pypy.org  Thu Jul 28 03:16:31 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 28 Jul 2011 01:16:31 +0000
Subject: [pypy-issue] [issue733] bz2 decompression is very slow
In-Reply-To: <1306785194.2.0.717331507866.issue733@bugs.pypy.org>
Message-ID: <1311815791.4.0.0557283057819.issue733@bugs.pypy.org>


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

So I just made gzip reading 50% faster with: 7cc899d8de19, by my measurements 
we're still 2x slower than CPython at the large size though.

----------
nosy: +agaynor

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

From tracker at bugs.pypy.org  Thu Jul 28 05:38:40 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 28 Jul 2011 03:38:40 +0000
Subject: [pypy-issue] [issue812] gc problem when dealing with numpy's
	virtual arrays
In-Reply-To: <1311824320.16.0.143442799401.issue812@bugs.pypy.org>
Message-ID: <1311824320.16.0.143442799401.issue812@bugs.pypy.org>


New submission from Justin Peel <peelpy at gmail.com>:

timonator found a bug when creating virtual arrays from binary operations and 
then printing the result repeatedly. However, if the length of the virtual array 
is printed first first and then the array is printed, there is no crash.

----------
files: np_gc_crash.py
messages: 2878
nosy: justinpeel, pypy-issue
priority: bug
status: unread
title: gc problem when dealing with numpy's virtual arrays

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

From tracker at bugs.pypy.org  Thu Jul 28 05:39:15 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 28 Jul 2011 03:39:15 +0000
Subject: [pypy-issue] [issue812] gc problem when dealing with numpy's
	virtual arrays
In-Reply-To: <1311824320.16.0.143442799401.issue812@bugs.pypy.org>
Message-ID: <1311824355.38.0.205147527337.issue812@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

Attached the crash message.

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

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue812>
________________________________________
-------------- next part --------------
[bogus _immutable_field_ declaration: <GcPtrFieldDescr pypy.module.micronumpy.interp_numarray.Call2.inst_left 28>]
[0.0 0.0 0.0 ..., 0.0 0.0 0.0]
RPython traceback:
  File "translator_goal_targetpypystandalone.c", line 1615, in entry_point
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 155, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "module_pypyjit_interp_jit.c", line 146, in portal
  File "interpreter_pyopcode.c", line 2935, in handle_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 7815, in dispatch_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 14609, in call_function__AccessDirect_None
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 155, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "module_pypyjit_interp_jit.c", line 146, in portal
  File "interpreter_pyopcode.c", line 2935, in handle_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 7428, in dispatch_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 14609, in call_function__AccessDirect_None
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 155, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "module_pypyjit_interp_jit.c", line 146, in portal
  File "interpreter_pyopcode.c", line 2935, in handle_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 8572, in dispatch_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 14609, in call_function__AccessDirect_None
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 155, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "module_pypyjit_interp_jit.c", line 146, in portal
  File "interpreter_pyopcode.c", line 2935, in handle_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 8465, in dispatch_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 20275, in EXEC_STMT__AccessDirect_None
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 155, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "module_pypyjit_interp_jit.c", line 146, in portal
  File "interpreter_pyopcode.c", line 2935, in handle_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 5293, in dispatch_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 11430, in CALL_FUNCTION__AccessDirect_None
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 155, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "module_pypyjit_interp_jit.c", line 146, in portal
  File "interpreter_pyopcode.c", line 2935, in handle_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 9559, in dispatch_bytecode__AccessDirect_None
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 155, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "module_pypyjit_interp_jit.c", line 146, in portal
  File "interpreter_pyopcode.c", line 2935, in handle_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 5293, in dispatch_bytecode__AccessDirect_None
  File "interpreter_pyopcode.c", line 11430, in CALL_FUNCTION__AccessDirect_None
  File "interpreter_pyframe.c", line 992, in PyFrame_execute_frame
  File "jit_metainterp_warmspot.c", line 323, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "jit_metainterp_warmstate.c", line 602, in maybe_compile_and_run__star_5
  File "jit_metainterp_pyjitpl.c", line 2483, in compile_and_run_once___pypy_jit_metainterp_jitdr
  File "jit_metainterp_pyjitpl.c", line 4245, in MetaInterp__compile_and_run_once
  File "jit_metainterp_pyjitpl.c", line 7002, in MetaInterp_interpret
  File "jit_metainterp_pyjitpl.c", line 9469, in MetaInterp__interpret
  File "jit_metainterp_pyjitpl.c", line 14210, in MIFrame_run_one_step
  File "jit_metainterp_pyjitpl.c", line 24230, in handler_ref_return
  File "jit_metainterp_pyjitpl.c", line 57439, in MetaInterp_finishframe
  File "jit_metainterp_pyjitpl.c", line 84057, in MetaInterp_compile_done_with_this_frame
  File "jit_metainterp_compile.c", line 6807, in compile_new_bridge
  File "jit_metainterp_optimize.c", line 89, in optimize_bridge
  File "jit_metainterp_optimize.c", line 336, in _optimize_bridge
  File "jit_metainterp_optimizeopt_optimizer.c", line 3053, in Optimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_heap.c", line 4822, in OptHeap_optimize_SETFIELD_GC
Fatal RPython error: BogusPureField

From tracker at bugs.pypy.org  Fri Jul 29 00:11:44 2011
From: tracker at bugs.pypy.org (Ismael)
Date: Thu, 28 Jul 2011 22:11:44 +0000
Subject: [pypy-issue] [issue721] pypy.org says front page "Download and try
	out the PyPy	release 1.4.1!"
In-Reply-To: <1305530773.75.0.980832820726.issue721@>
Message-ID: <1311891104.62.0.919149061696.issue721@bugs.pypy.org>


Ismael <ismaelgfk at gmail.com> added the comment:

Correct version is announced on the frontpage. Closing.

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

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

From tracker at bugs.pypy.org  Fri Jul 29 00:16:44 2011
From: tracker at bugs.pypy.org (Ismael)
Date: Thu, 28 Jul 2011 22:16:44 +0000
Subject: [pypy-issue] [issue813] Random is slower than cpython
In-Reply-To: <1311891404.35.0.986785735677.issue813@bugs.pypy.org>
Message-ID: <1311891404.35.0.986785735677.issue813@bugs.pypy.org>


New submission from Ismael <ismaelgfk at gmail.com>:

Random.random() is aprox. 10 times slower on PyPy, random.randint() is 2 times
slower.

Code:

from time import time
import random

ini = time()
for i in xrange(1000):
    random.random()
fin = time()
print "Random.random() ", fin - ini

ini = time()
for i in xrange(1000):
    random.randint(0, 10)
fin = time()
print "Random.randint() ", fin - ini

Timings:

Python 2.6.6:
ismael at chaos:~/workspace/testsum/src$ python test.py 
Random.random()  0.000263929367065
Random.randint()  0.00369191169739

Python 2.7:
ismael at chaos:~/workspace/testsum/src$ python2.7 test.py 
Random.random()  0.000288963317871
Random.randint()  0.00278496742249

PyPy trunk:
ismael at chaos:~/workspace/testsum/src$
~/pypy/pypylatest/pypy-c-jit-46033-811906ece2d8-linux64/bin/pypy test.py 
Random.random()  0.00127387046814
Random.randint()  0.00587606430054

PyPy 1.5:
ismael at chaos:~/workspace/testsum/src$ ~/pypy/bin/pypy test.py 
Random.random()  0.00275802612305
Random.randint()  0.00753998756409

----------
messages: 2881
nosy: Ismael, pypy-issue
priority: bug
status: unread
title: Random is slower than cpython

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

From tracker at bugs.pypy.org  Fri Jul 29 00:23:45 2011
From: tracker at bugs.pypy.org (Ismael)
Date: Thu, 28 Jul 2011 22:23:45 +0000
Subject: [pypy-issue] [issue814] Appending string is slower than cpython
In-Reply-To: <1311891825.05.0.98767349744.issue814@bugs.pypy.org>
Message-ID: <1311891825.05.0.98767349744.issue814@bugs.pypy.org>


New submission from Ismael <ismaelgfk at gmail.com>:

Code:

from time import time

ini = time()
s = ""
for i in xrange(100000):
    s += "23"
fin = time()
print "AppendStr: ", fin-ini

Timings:

Python 2.6:
ismael at chaos:~/workspace/testsum/src$ python stringtest.py 
AppendStr:  0.0206191539764

PyPy 1.5:
ismael at chaos:~/workspace/testsum/src$ ~/pypy/bin/pypy stringtest.py 
AppendStr:  5.54550814629

PyPy trunk:
ismael at chaos:~/workspace/testsum/src$
~/pypy/pypylatest/pypy-c-jit-46033-811906ece2d8-linux64/bin/pypy stringtest.py 
AppendStr:  5.64269804955

----------
messages: 2882
nosy: Ismael, pypy-issue
priority: bug
status: unread
title: Appending string is slower than cpython

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

From tracker at bugs.pypy.org  Fri Jul 29 00:24:56 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 28 Jul 2011 22:24:56 +0000
Subject: [pypy-issue] [issue814] Appending string is slower than cpython
In-Reply-To: <1311891825.05.0.98767349744.issue814@bugs.pypy.org>
Message-ID: <1311891896.89.0.423476064201.issue814@bugs.pypy.org>


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

Not a bug, CPython has ridiculous hacks in it.  This operation would be O(n**2) 
on CPython were it not for those, as it is on PyPy.  This won't be fixed.

----------
nosy: +agaynor
status: unread -> wontfix

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

From tracker at bugs.pypy.org  Fri Jul 29 00:26:28 2011
From: tracker at bugs.pypy.org (Jean-Paul Calderone)
Date: Thu, 28 Jul 2011 22:26:28 +0000
Subject: [pypy-issue] [issue813] Random is slower than cpython
In-Reply-To: <1311891404.35.0.986785735677.issue813@bugs.pypy.org>
Message-ID: <1311891988.13.0.217760785148.issue813@bugs.pypy.org>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Let the loops run a little longer, the story changes.  For 100000 loops:


Random.random()  0.0205929279327
Random.randint()  0.232482910156
exarkun at boson:/tmp$ ~/Downloads/pypy-c-jit-45960-c3cdcacec880-linux/bin/pypy 
zonk.py 
Random.random()  0.00938701629639
Random.randint()  0.0481588840485


This sounds a lot like "PyPy is slower than CPython in general until the JIT 
kicks in", and probably has nothing to do with the random module.

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

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

From tracker at bugs.pypy.org  Fri Jul 29 00:26:54 2011
From: tracker at bugs.pypy.org (Jean-Paul Calderone)
Date: Thu, 28 Jul 2011 22:26:54 +0000
Subject: [pypy-issue] [issue813] Random is slower than cpython
In-Reply-To: <1311891404.35.0.986785735677.issue813@bugs.pypy.org>
Message-ID: <1311892014.05.0.027498059585.issue813@bugs.pypy.org>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Oops, cut off the header for the first result, which was CPython 2.7.

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

From tracker at bugs.pypy.org  Fri Jul 29 00:34:37 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Thu, 28 Jul 2011 22:34:37 +0000
Subject: [pypy-issue] [issue814] Appending string is slower than cpython
In-Reply-To: <1311891825.05.0.98767349744.issue814@bugs.pypy.org>
Message-ID: <1311892477.92.0.450207874823.issue814@bugs.pypy.org>


Antonio Cuni <anto.cuni at gmail.com> added the comment:

note that we can get the same behavior by using the "withstrjoin" option. I
suppose we should try to enable it and see what is the effect on benchmarks.

----------
status: wontfix -> chatting

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

From tracker at bugs.pypy.org  Fri Jul 29 00:38:40 2011
From: tracker at bugs.pypy.org (Ismael)
Date: Thu, 28 Jul 2011 22:38:40 +0000
Subject: [pypy-issue] [issue814] Appending string is slower than cpython
In-Reply-To: <1311891896.89.0.423476064201.issue814@bugs.pypy.org>
Message-ID: <CALc6CL=UTj-n+nK3ZrZD9wRA8uLrfU=Vu7HnCbYYvJtAogzAgw@mail.gmail.com>


Ismael <ismaelgfk at gmail.com> added the comment:

Note that appending strings like this is "common behaviour" in
CPython. Perhaps this difference in behaviour should be mentioned in
the docs? Or in a special page for "performance Python"?

On Thu, Jul 28, 2011 at 7:24 PM, Alex Gaynor <tracker at bugs.pypy.org> wrote:
>
> Alex Gaynor <alex.gaynor at gmail.com> added the comment:
>
> Not a bug, CPython has ridiculous hacks in it. ?This operation would be O(n**2)
> on CPython were it not for those, as it is on PyPy. ?This won't be fixed.
>
> ----------
> nosy: +agaynor
> status: unread -> wontfix
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue814>
> ________________________________________
>

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

From benjamin at python.org  Fri Jul 29 00:44:27 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 28 Jul 2011 17:44:27 -0500
Subject: [pypy-issue] [issue814] Appending string is slower than cpython
In-Reply-To: <CALc6CL=UTj-n+nK3ZrZD9wRA8uLrfU=Vu7HnCbYYvJtAogzAgw@mail.gmail.com>
References: <1311891896.89.0.423476064201.issue814@bugs.pypy.org>
	<CALc6CL=UTj-n+nK3ZrZD9wRA8uLrfU=Vu7HnCbYYvJtAogzAgw@mail.gmail.com>
Message-ID: <CAPZV6o8=JaR40pm4j1kuAqrcsC8-WPj2LNs+Nfh6QsD5GHkW4A@mail.gmail.com>

It might be common behavior, but it's not a good idea or an idiom.
''.join() should be used everytime.

2011/7/28 Ismael <tracker at bugs.pypy.org>:
>
> Ismael <ismaelgfk at gmail.com> added the comment:
>
> Note that appending strings like this is "common behaviour" in
> CPython. Perhaps this difference in behaviour should be mentioned in
> the docs? Or in a special page for "performance Python"?
>
> On Thu, Jul 28, 2011 at 7:24 PM, Alex Gaynor <tracker at bugs.pypy.org> wrote:
>>
>> Alex Gaynor <alex.gaynor at gmail.com> added the comment:
>>
>> Not a bug, CPython has ridiculous hacks in it. ?This operation would be O(n**2)
>> on CPython were it not for those, as it is on PyPy. ?This won't be fixed.
>>
>> ----------
>> nosy: +agaynor
>> status: unread -> wontfix
>>
>> ________________________________________
>> PyPy bug tracker <tracker at bugs.pypy.org>
>> <https://bugs.pypy.org/issue814>
>> ________________________________________
>>
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue814>
> ________________________________________
> _______________________________________________
> pypy-issue mailing list
> pypy-issue at python.org
> http://mail.python.org/mailman/listinfo/pypy-issue
>



-- 
Regards,
Benjamin

From tracker at bugs.pypy.org  Fri Jul 29 11:30:50 2011
From: tracker at bugs.pypy.org (Christoph Zwerschke)
Date: Fri, 29 Jul 2011 09:30:50 +0000
Subject: [pypy-issue] [issue772] Bad permissions in release tar
In-Reply-To: <1309419720.49.0.602165830584.issue772@bugs.pypy.org>
Message-ID: <1311931850.92.0.459802771292.issue772@bugs.pypy.org>


Christoph Zwerschke <cito at online.de> added the comment:

You can easily fix the permissions with
chmod -R go+u,go-w /path/to/pypy

----------
nosy: +Cito

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

From tracker at bugs.pypy.org  Sat Jul 30 02:10:50 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 30 Jul 2011 00:10:50 +0000
Subject: [pypy-issue] [issue815] segfault in register allocator
In-Reply-To: <1311984650.55.0.724679378019.issue815@bugs.pypy.org>
Message-ID: <1311984650.55.0.724679378019.issue815@bugs.pypy.org>


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

On `unroll-if-alt` doing:

./pypy-c-new -S -mtimeit -s "i = 0" "'%d %d' % (i, i); i += 1"

Results in a segfault, using gdb, the bt is (I removed the frames below this, 
that aren't really relevant):

#0  0x0000000000a95664 in pypy_g_FrameManager_loc ()
#1  0x0000000000a98bba in pypy_g_RegisterManager_make_sure_var_in_reg ()
#2  0x0000000000a88281 in pypy_g_RegAlloc__consider_copystrcontent ()
#3  0x0000000000a7ca5d in pypy_g_RegAlloc_walk_operations ()
#4  0x0000000000d43125 in pypy_g_Assembler386__assemble ()
#5  0x0000000000d4c0c6 in pypy_g_Assembler386_assemble_loop ()
#6  0x0000000000d3c93f in pypy_g_send_loop_to_backend ()
#7  0x0000000000d3e9c8 in pypy_g_compile_new_loop ()
#8  0x0000000000a28de0 in pypy_g_MetaInterp_compile ()
#9  0x0000000000a2b30f in pypy_g_MetaInterp_reached_loop_header ()
#10 0x0000000000a1b37a in pypy_g_MIFrame_opimpl_jit_merge_point ()
#11 0x00000000009fcaa2 in pypy_g_MetaInterp__interpret ()
#12 0x00000000009fce50 in pypy_g_MetaInterp__compile_and_run_once ()
#13 0x00000000009fe6ab in 
pypy_g_compile_and_run_once___pypy_jit_metainterp_jitdr_1 ()
#14 0x0000000000f93b88 in pypy_g_maybe_compile_and_run__star_5_1 ()
#15 0x0000000000d26c35 in pypy_g_jump_absolute__AccessDirect_None ()
#16 0x0000000000487103 in pypy_g_handle_bytecode__AccessDirect_None ()
#17 0x0000000000d26832 in pypy_g_portal_1 ()
#18 0x0000000000981d74 in 
pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter ()
#19 0x0000000000abd875 in pypy_g_PyFrame_run ()

----------
messages: 2890
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: segfault in register allocator

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

From tracker at bugs.pypy.org  Sat Jul 30 04:48:22 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 30 Jul 2011 02:48:22 +0000
Subject: [pypy-issue] [issue815] segfault in register allocator
In-Reply-To: <1311984650.55.0.724679378019.issue815@bugs.pypy.org>
Message-ID: <1311994102.46.0.245015957377.issue815@bugs.pypy.org>


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

Compiled with lldebug, here's the position it crashes:


Program received signal SIGSEGV, Segmentation fault.
pypy_g_FrameManager_loc (l_self_10414=0x7ffff5b94510, l_box_82=<value optimized 
out>) at jit_backend_llsupport_regalloc.c:968
968		l_v1081674 = (struct pypy_object_vtable0 
*)_OP_GET_NEXT_GROUP_MEMBER((&pypy_g_typeinfo), (pypy_halfword_t)l_v1081643-
>_gcheader.h_tid, sizeof(struct pypy_type_info0));
(gdb) list
963		RPyField(l_self_10414, xfm_inst_frame_depth) = l_v1081669;
964		l_v1081671 = (struct pypy_object_vtable0 
*)_OP_GET_NEXT_GROUP_MEMBER((&pypy_g_typeinfo), (pypy_halfword_t)l_v1081649-
>_gcheader.h_tid, sizeof(struct pypy_type_info0));
965		l_v1081672 = (struct 
pypy_pypy_jit_backend_x86_regalloc_X86FrameManager_vtab0 *)l_v1081671;
966		l_v1081673 = RPyField(l_v1081672, xfm_cls_frame_pos);
967		l_v1081644 = RPyField(l_self_10414, xfm_inst_frame_depth);
968		l_v1081674 = (struct pypy_object_vtable0 
*)_OP_GET_NEXT_GROUP_MEMBER((&pypy_g_typeinfo), (pypy_halfword_t)l_v1081643-
>_gcheader.h_tid, sizeof(struct pypy_type_info0));
969		l_v1081675 = (struct 
pypy_pypy_jit_metainterp_history_AbstractValue_vtable0 *)l_v1081674;
970		l_v1081642 = RPyField(l_v1081675, av_cls_type);
971		switch (l_v1081673) {
972	    case ((char)0):

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

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

From tracker at bugs.pypy.org  Sat Jul 30 05:05:32 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 30 Jul 2011 03:05:32 +0000
Subject: [pypy-issue] [issue815] segfault in register allocator
In-Reply-To: <1311984650.55.0.724679378019.issue815@bugs.pypy.org>
Message-ID: <1311995132.14.0.0084525259973.issue815@bugs.pypy.org>


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

So I'm feeling pretty confident I confused the annotator somehow and passed a bad 
type somewhere.

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

From tracker at bugs.pypy.org  Sat Jul 30 06:03:01 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 30 Jul 2011 04:03:01 +0000
Subject: [pypy-issue] [issue815] segfault in register allocator
In-Reply-To: <1311984650.55.0.724679378019.issue815@bugs.pypy.org>
Message-ID: <1311998581.94.0.0483463524576.issue815@bugs.pypy.org>


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

Pff, bug on my part, sorry for the noise.

----------
status: chatting -> invalid

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

From tracker at bugs.pypy.org  Sun Jul 31 09:16:09 2011
From: tracker at bugs.pypy.org (Yesudeep Mangalapilly)
Date: Sun, 31 Jul 2011 07:16:09 +0000
Subject: [pypy-issue] [issue816] Pypy nightly missing module _ffi
In-Reply-To: <1312096569.04.0.650478860646.issue816@bugs.pypy.org>
Message-ID: <1312096569.04.0.650478860646.issue816@bugs.pypy.org>


New submission from Yesudeep Mangalapilly <yesudeep at gmail.com>:

Pip is rendered broken as a result.

Stacktrace:
-----------
    [TOX] ***reusing existing matching virtualenv pypy
    [TOX] ***upgrade-installing sdist
    [TOX] /Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/log$ ../bin/pip
install
--download-cache=/Users/gorakhargosh/Projects/workspace/mom/.tox/_download -U
--no-deps ../../dist/mom-0.0.1.zip >9.log
    [TOX] ERROR: invocation failed, logfile:
/Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/log/9.log
    [TOX] ERROR: /Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/log$
../bin/pip install
--download-cache=/Users/gorakhargosh/Projects/workspace/mom/.tox/_download -U
--no-deps ../../dist/mom-0.0.1.zip >9.log
    Traceback (most recent call last):
      File "app_main.py", line 53, in run_toplevel
      File "../bin/pip", line 9, in <module>
        load_entry_point('pip==1.0.2', 'console_scripts', 'pip')()
      File
"/Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/site-packages/distribute-0.6.19-py2.7.egg/pkg_resources.py",
line 337, in load_entry_point
        return get_distribution(dist).load_entry_point(group, name)
      File
"/Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/site-packages/distribute-0.6.19-py2.7.egg/pkg_resources.py",
line 2281, in load_entry_point
        return ep.load()
      File
"/Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/site-packages/distribute-0.6.19-py2.7.egg/pkg_resources.py",
line 1991, in load
        entry = __import__(self.module_name, globals(),globals(), ['__name__'])
      File
"/Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/site-packages/pip-1.0.2-py2.7.egg/pip/__init__.py",
line 10, in <module>
        from pip.backwardcompat import u, walk_packages, console_to_str
      File
"/Users/gorakhargosh/Projects/workspace/mom/.tox/pypy/site-packages/pip-1.0.2-py2.7.egg/pip/backwardcompat.py",
line 66, in <module>
        from urllib2 import URLError, HTTPError
      File "/Users/gorakhargosh/Applications/pypy/lib-python/2.7/urllib2.py",
line 111, in <module>
        from urllib import (unwrap, unquote, splittype, splithost, quote,
      File "/Users/gorakhargosh/Applications/pypy/lib-python/2.7/urllib.py",
line 1348, in <module>
        from _scproxy import _get_proxy_settings, _get_proxies
      File "/Users/gorakhargosh/Applications/pypy/lib_pypy/_scproxy.py", line 9,
in <module>
        from ctypes import c_int32, c_int64, c_void_p, c_char_p, c_int, cdll
      File
"/Users/gorakhargosh/Applications/pypy/lib-python/modified-2.7/ctypes/__init__.py",
line 10, in <module>
        import _ffi
    ImportError: No module named _ffi

    $ pypy --version
    Python 2.7.1 (65b1ed60d7da, Jul 12 2011, 02:00:13)
    [PyPy 1.5.0-alpha0 with GCC 4.0.1]

This issue does not exist in the release pypy 1.5 build.

----------
messages: 2894
nosy: pypy-issue, yesudeep
priority: bug
status: unread
title: Pypy nightly missing module _ffi

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

From tracker at bugs.pypy.org  Sun Jul 31 09:28:06 2011
From: tracker at bugs.pypy.org (Yesudeep Mangalapilly)
Date: Sun, 31 Jul 2011 07:28:06 +0000
Subject: [pypy-issue] [issue816] Pypy nightly missing module _ffi
In-Reply-To: <1312096569.04.0.650478860646.issue816@bugs.pypy.org>
Message-ID: <1312097286.02.0.216537538952.issue816@bugs.pypy.org>


Yesudeep Mangalapilly <yesudeep at gmail.com> added the comment:

Please close this issue. Deleting the .tox directory and re-running 
tox appears to have fixed it.

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

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