From tracker at bugs.pypy.org  Thu Sep  1 07:47:51 2011
From: tracker at bugs.pypy.org (Didip Kerabat)
Date: Thu, 01 Sep 2011 05:47:51 +0000
Subject: [pypy-issue] [issue855] PyPy 1.6 and virtualenv 1.6.4 problem
In-Reply-To: <1314856071.34.0.062566582625.issue855@bugs.pypy.org>
Message-ID: <1314856071.34.0.062566582625.issue855@bugs.pypy.org>


New submission from Didip Kerabat <didipk at gmail.com>:

On OSX Snow Leopard, virtualenv -p failed to locate pypy-env/lib-python/2.7/os.py.

When browsing the directory, os.py is actually located under
pypy-env/lib-python/modified-2.7/os.py

See details here: https://gist.github.com/1185524

----------
messages: 3059
nosy: didip, pypy-issue
priority: bug
status: unread
title: PyPy 1.6 and virtualenv 1.6.4 problem

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

From tracker at bugs.pypy.org  Thu Sep  1 07:53:24 2011
From: tracker at bugs.pypy.org (Didip Kerabat)
Date: Thu, 01 Sep 2011 05:53:24 +0000
Subject: [pypy-issue] [issue855] PyPy 1.6 and virtualenv 1.6.4 problem
In-Reply-To: <1314856404.34.0.879416829531.issue855@bugs.pypy.org>
Message-ID: <1314856404.34.0.879416829531.issue855@bugs.pypy.org>


New submission from Didip Kerabat <didipk at gmail.com>:

Please ignore, the build script was failing the first time creating incorrect
directory structure.

When restarting from scratch, everything works fine.

----------
status: chatting -> invalid

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

From tracker at bugs.pypy.org  Thu Sep  1 12:50:53 2011
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Thu, 01 Sep 2011 10:50:53 +0000
Subject: [pypy-issue] [issue856] Print unicode data fails
In-Reply-To: <1314874253.94.0.774183257103.issue856@bugs.pypy.org>
Message-ID: <1314874253.94.0.774183257103.issue856@bugs.pypy.org>


New submission from Kostya Rybnikov <k.bx at ya.ru>:

I have file with following contents:

# -*- coding: utf-8 -*-

print u"???"

When I run it -- it fails (on stable 1.6 and today's nightly):

kost at kost-laptop:~/bin$ ./pypy-c-jit-46260-22863ec20f46-linux64/bin/pypy
~/Ubuntu\ One/playground/python/pypy_logging_unicode.py 
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "/home/kost/Ubuntu One/playground/python/pypy_logging_unicode.py", line
3, in <module>
    print u"???"
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2:
ordinal not in range(128)

Here's my env:

kost at kost-laptop:~/bin$ env | grep LANG
LANG=en_US.UTF-8
GDM_LANG=en_US
LANGUAGE=en_US:en

kost at kost-laptop:~/bin$ env
ORBIT_SOCKETDIR=/tmp/orbit-kost
SSH_AGENT_PID=1291
GIO_LAUNCHED_DESKTOP_FILE_PID=2970
TERM=xterm
SHELL=/bin/bash
XDG_SESSION_COOKIE=361e57ce5da7f98b5c2c263b00000007-1314171060.979094-1421235123
WINDOWID=81788932
OLDPWD=/home/kost/Ubuntu One/playground/python
GNOME_KEYRING_CONTROL=/tmp/keyring-YSwWbr
GTK_MODULES=canberra-gtk-module
USER=kost
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
SSH_AUTH_SOCK=/tmp/keyring-YSwWbr/ssh
SESSION_MANAGER=local/kost-laptop:@/tmp/.ICE-unix/1258,unix/kost-laptop:/tmp/.ICE-unix/1258
USERNAME=kost
DEFAULTS_PATH=/usr/share/gconf/gnome.default.path
GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/terminator.desktop
XDG_CONFIG_DIRS=/etc/xdg/xdg-gnome:/etc/xdg
PATH=/home/kost/bin/node/bin:/home/kost/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/var/lib/gems/1.8/bin
DESKTOP_SESSION=gnome
PWD=/home/kost/bin
GDM_KEYBOARD_LAYOUT=us
LANG=en_US.UTF-8
GDM_LANG=en_US
MANDATORY_PATH=/usr/share/gconf/gnome.mandatory.path
UBUNTU_MENUPROXY=libappmenu.so
COMPIZ_CONFIG_PROFILE=ubuntu
GDMSESSION=gnome
SHLVL=1
HOME=/home/kost
LANGUAGE=en_US:en
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LESS=-iMSx4 -FX
LOGNAME=kost
XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-PhTYFuPnC6,guid=96fd890a3afae4c68627c4dd0000000a
LESSOPEN=| /usr/bin/lesspipe %s
WINDOWPATH=7
DISPLAY=:0
LESSCLOSE=/usr/bin/lesspipe %s %s
COLORTERM=gnome-terminal
XAUTHORITY=/var/run/gdm/auth-for-kost-lTJtHF/database
_=/usr/bin/env

Thanks!

----------
messages: 3061
nosy: k_bx, pypy-issue
priority: bug
status: unread
title: Print unicode data fails

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

From tracker at bugs.pypy.org  Thu Sep  1 12:53:15 2011
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Thu, 01 Sep 2011 10:53:15 +0000
Subject: [pypy-issue] [issue857] u"%s" % O() that has unicode __repr__()
	fails
In-Reply-To: <1314874395.78.0.666670423859.issue857@bugs.pypy.org>
Message-ID: <1314874395.78.0.666670423859.issue857@bugs.pypy.org>


New submission from Kostya Rybnikov <k.bx at ya.ru>:

This code:

# -*- coding: utf-8 -*-

class O(object):
    def __repr__(self):
        return u"??????"

u"%s" % O()

fails:

(pypy)kost at kost-laptop:~/Ubuntu One/playground/python$ python
pypy_logging_unicode.py 
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "pypy_logging_unicode.py", line 7, in <module>
    u"%s" % O()
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-5:
ordinal not in range(128)

on pypy 1.6 and today's nightly build

----------
messages: 3062
nosy: k_bx, pypy-issue
priority: bug
status: unread
title: u"%s" % O() that has unicode __repr__() fails

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

From tracker at bugs.pypy.org  Thu Sep  1 17:00:53 2011
From: tracker at bugs.pypy.org (vad)
Date: Thu, 01 Sep 2011 15:00:53 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1314889253.97.0.682005634937.issue844@bugs.pypy.org>


vad <davide.setti at gmail.com> added the comment:

Ciao Anto,
seems still broken:

$ djangobench
Running all benchmarks
Control: Django 1.3 (in django-control)
Experiment: Django 1.3 (in django-experiment)

Running 'default_middleware' benchmark ...
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "/Users/vad/Source/Envs/djangobench-pypy16/bin/djangobench", line 8, in 
<module>
    load_entry_point('djangobench==0.9', 'console_scripts', 'djangobench')()
  File "/Users/vad/Source/Envs/djangobench-
pypy16/src/djangobench/djangobench/main.py", line 297, in main
    profile_dir = args.profile_dir
  File "/Users/vad/Source/Envs/djangobench-
pypy16/src/djangobench/djangobench/main.py", line 60, in run_benchmarks
    control_data = run_benchmark(benchmark, trials, control_env)
  File "/Users/vad/Source/Envs/djangobench-
pypy16/src/djangobench/djangobench/main.py", line 106, in run_benchmark
    out, _, _ = perf.CallAndCaptureOutput(command + ['-t', 1], env, 
track_memory=False, inherit_env=[])
  File "/Users/vad/Source/Envs/djangobench-
pypy16/src/djangobench/djangobench/perf.py", line 1026, in CallAndCaptureOutput
    raise RuntimeError("Benchmark died: " + stderr)
RuntimeError: Benchmark died: 'import site' failed
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "/Users/vad/Source/Envs/djangobench-
pypy16/src/djangobench/djangobench/benchmarks/default_middleware/benchmark.py", 
line 3, in <module>
    from django.test.client import Client
  File "/Users/vad/Source/Django/djangobench/django-
control/django/test/__init__.py", line 5, in <module>
    from django.test.client import Client, RequestFactory
  File "/Users/vad/Source/Django/djangobench/django-
control/django/test/client.py", line 1, in <module>
    import urllib
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/2.7/urllib.py", line 1348, 
in <module>
    from _scproxy import _get_proxy_settings, _get_proxies
  File "/Users/vad/Software/pypy/pypy-1.6/lib_pypy/_scproxy.py", line 64, in 
<module>
    ffi = _CFSetup()
  File "/Users/vad/Software/pypy/pypy-1.6/lib_pypy/_scproxy.py", line 17, in 
_CFSetup
    sc = cdll.LoadLibrary(find_library("SystemConfiguration"))
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/ctypes/util.py", line 76, in find_library
    from ctypes.macholib.dyld import dyld_find as _dyld_find
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/ctypes/macholib/dyld.py", line 21, in <module>
    os.path.expanduser("~/Library/Frameworks"),
  File "/Users/vad/Source/Envs/djangobench-pypy16/lib-python/2.7/posixpath.py", 
line 259, in expanduser
    import pwd
  File "/Users/vad/Software/pypy/pypy-1.6/lib_pypy/pwd.py", line 17, in <module>
    from ctypes_support import standard_c_lib as libc
  File "/Users/vad/Software/pypy/pypy-1.6/lib_pypy/ctypes_support.py", line 16, 
in <module>
    standard_c_lib = ctypes.CDLL(ctypes.util.find_library('c'))
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/ctypes/util.py", line 76, in find_library
    from ctypes.macholib.dyld import dyld_find as _dyld_find
ImportError: cannot import name 'dyld_find'

Thank you for the answer!

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

From tracker at bugs.pypy.org  Thu Sep  1 18:09:39 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Thu, 01 Sep 2011 16:09:39 +0000
Subject: [pypy-issue] [issue839] Sqlite in pypy 1.6 on amd64 is very slow :)
In-Reply-To: <1313914325.02.0.19991212695.issue839@bugs.pypy.org>
Message-ID: <1314893379.52.0.70415694555.issue839@bugs.pypy.org>


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

indeed, I confirm that sqlite3 is very slow on PyPy.
I tried with the following example:

def main():
    import sqlite3
    conn = sqlite3.connect(':memory:')
    conn.execute('CREATE TABLE foo(id INTEGER)')
    
    cursor = conn.cursor()
    for i in range(10000):
        SQL = 'INSERT INTO foo VALUES (0)'
        cursor.execute(SQL)

pypy-c took 1.11 seconds, while CPython 0.03 (!!)

Revisions 862677259356 and 72321d3c8b69 mitigates a bit the problem.  Now it
takes only 0.5 seconds on top of pypy-c, but it's still ~16x slower than
CPython. I'll try to investigate more

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

From tracker at bugs.pypy.org  Fri Sep  2 10:07:56 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 02 Sep 2011 08:07:56 +0000
Subject: [pypy-issue] [issue768] More built-in modules than in cpython
In-Reply-To: <1309124779.4.0.811648787211.issue768@bugs.pypy.org>
Message-ID: <1314950876.31.0.678103514741.issue768@bugs.pypy.org>


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

I'll close it. IT's not like CPython does not change it from one version to 
another.

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

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

From tracker at bugs.pypy.org  Fri Sep  2 10:43:47 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 02 Sep 2011 08:43:47 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314953027.45.0.677947861608.issue847@bugs.pypy.org>


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

Closing, seems to work.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 00:38:46 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 02 Sep 2011 22:38:46 +0000
Subject: [pypy-issue] [issue839] Sqlite in pypy 1.6 on amd64 is very slow :)
In-Reply-To: <1313914325.02.0.19991212695.issue839@bugs.pypy.org>
Message-ID: <1315003126.76.0.586323921422.issue839@bugs.pypy.org>


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

After the work Anto, I, (and I guess anyone else who committed anything else 
today :)) did using http://paste.pocoo.org/show/469210/ for benchmarking, we're 
slower for iteration #1, but after that we're basically tied.  I think we're 
close to SQLite itself being the bottleneck, but not there yet.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 05:16:19 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 03 Sep 2011 03:16:19 +0000
Subject: [pypy-issue] [issue858] Can't create a ctypes pointer to a bool:
In-Reply-To: <1315019779.8.0.569461468901.issue858@bugs.pypy.org>
Message-ID: <1315019779.8.0.569461468901.issue858@bugs.pypy.org>


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

>>>> import ctypes
>>>> ctypes.c_bool
<class 'ctypes.c_bool'>
>>>> ctypes.POINTER(ctypes.c_bool)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/alex/projects/pypy/lib_pypy/_ctypes/pointer.py", line 179, in 
POINTER
    {'_type_': cls})
  File "/home/alex/projects/pypy/lib_pypy/_ctypes/pointer.py", line 31, in 
__new__
    self.set_type(obj, typedict['_type_'])
  File "/home/alex/projects/pypy/lib_pypy/_ctypes/pointer.py", line 70, in 
set_type
    self._ffiargtype = _ffi.types.Pointer(TP.get_ffi_argtype())
  File "/home/alex/projects/pypy/lib_pypy/_ctypes/basics.py", line 57, in 
get_ffi_argtype
    self._ffiargtype = _shape_to_ffi_type(self._ffiargshape)
  File "/home/alex/projects/pypy/lib_pypy/_ctypes/basics.py", line 204, in 
_shape_to_ffi_type
    assert False, 'unknown shape %s' % (shape,)
AssertionError: unknown shape ?

----------
messages: 3069
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: Can't create a ctypes pointer to a bool:

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

From tracker at bugs.pypy.org  Sat Sep  3 05:29:04 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 03 Sep 2011 03:29:04 +0000
Subject: [pypy-issue] [issue859] numpy script has corrupted memory with JIT
In-Reply-To: <1315020544.58.0.448478930163.issue859@bugs.pypy.org>
Message-ID: <1315020544.58.0.448478930163.issue859@bugs.pypy.org>


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

running http://paste.pocoo.org/show/469313/ crashes on the 1034th iteration (only 
with the JIT), examining the contents of the array shows that not all the memory 
is zero'd

----------
messages: 3070
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: numpy script has corrupted memory with JIT

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

From tracker at bugs.pypy.org  Fri Sep  2 10:09:27 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 02 Sep 2011 08:09:27 +0000
Subject: [pypy-issue] [issue484] review listview()
In-Reply-To: <1258976630.77.0.968264842598.issue484@>
Message-ID: <1314950967.54.0.157261969333.issue484@bugs.pypy.org>


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

Ok, I'm closing this one, it's old and will be looked at in a branch.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 11:57:57 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 09:57:57 +0000
Subject: [pypy-issue] [issue856] Print unicode data fails
In-Reply-To: <1314874253.94.0.774183257103.issue856@bugs.pypy.org>
Message-ID: <1315043877.54.0.493456976489.issue856@bugs.pypy.org>


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

Fixed, maybe.  I'm a bit afraid that it might have broken something else...

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

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

From tracker at bugs.pypy.org  Sat Sep  3 12:00:19 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 10:00:19 +0000
Subject: [pypy-issue] [issue857] u"%s" % O() that has unicode __repr__()
	fails
In-Reply-To: <1314874395.78.0.666670423859.issue857@bugs.pypy.org>
Message-ID: <1315044019.46.0.264374409694.issue857@bugs.pypy.org>


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

But repr(O()) fails on both pypy and CPython 2.7.  "Great."

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

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

From tracker at bugs.pypy.org  Sat Sep  3 12:07:14 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 10:07:14 +0000
Subject: [pypy-issue] [issue857] u"%s" % O() that has unicode __repr__()
	fails
In-Reply-To: <1314874395.78.0.666670423859.issue857@bugs.pypy.org>
Message-ID: <1315044434.87.0.499873959505.issue857@bugs.pypy.org>


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

With a __repr__ that returns an unencodable unicode string, you will get an
encoding error on CPython if you try to do anything at all, like str(O()) or
repr(O()) or print O() or `O()`.  Even doing '%r' % O().  It seems that '%s' %
O() is the only thing that you can do.

Indeed, I can't believe it, but looking at the source code of CPython, there is
a special function _PyObject_Str() that is called *only* from '%s' formatting. 
All other places call PyObject_Str() or PyObject_Repr(), which will encode the
unicode string.  It makes no sense to me...  What should we do?  Copy this
horribly strange special case???

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

From tracker at bugs.pypy.org  Sat Sep  3 12:13:27 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 10:13:27 +0000
Subject: [pypy-issue] [issue858] Can't create a ctypes pointer to a bool:
In-Reply-To: <1315019779.8.0.569461468901.issue858@bugs.pypy.org>
Message-ID: <1315044807.81.0.295450734016.issue858@bugs.pypy.org>


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

Fixed in 7fdbf8332028.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 12:16:53 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 10:16:53 +0000
Subject: [pypy-issue] [issue852] from __future__ : trunk gives error while
	cpython 2.7 runs	ok
In-Reply-To: <1314642741.04.0.531257492224.issue852@bugs.pypy.org>
Message-ID: <1315045013.29.0.528682540964.issue852@bugs.pypy.org>


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

Note: the attached file aa.py has a space after the "\".  I can reproduce the
bug by removing the space.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 12:41:16 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 10:41:16 +0000
Subject: [pypy-issue] [issue852] from __future__ : trunk gives error while
	cpython 2.7 runs	ok
In-Reply-To: <1314642741.04.0.531257492224.issue852@bugs.pypy.org>
Message-ID: <1315046476.2.0.41592086888.issue852@bugs.pypy.org>


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

Should be fixed in 4de034d3fb88.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 12:50:28 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 10:50:28 +0000
Subject: [pypy-issue] [issue843] PyPy slower than CPython with puzzle problem
In-Reply-To: <1314167447.35.0.774659658214.issue843@bugs.pypy.org>
Message-ID: <1315047028.81.0.642751515883.issue843@bugs.pypy.org>


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

An optimization found in CPython but not in PyPy is for the case "s & s".  I
don't know if this is relevant...  It seems otherwise to be the same algorithm.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 17:25:39 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 03 Sep 2011 15:25:39 +0000
Subject: [pypy-issue] [issue853] Django crashes almost immediately on trying
	to run the	tests
In-Reply-To: <1314651819.6.0.00192404670335.issue853@bugs.pypy.org>
Message-ID: <1315063539.0.0.638137743215.issue853@bugs.pypy.org>


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

Fixed in 7c36492d9f9d

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

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

From tracker at bugs.pypy.org  Sat Sep  3 17:26:02 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 15:26:02 +0000
Subject: [pypy-issue] [issue719] stackless.coroutine cant switch to self
In-Reply-To: <1305184868.5.0.649497366063.issue719@>
Message-ID: <1315063562.75.0.547377996261.issue719@bugs.pypy.org>


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

Coroutines are disappearing now.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 17:30:06 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 03 Sep 2011 15:30:06 +0000
Subject: [pypy-issue] [issue845] ImportError: No module named cPickle
In-Reply-To: <1314297078.97.0.0821748628055.issue845@bugs.pypy.org>
Message-ID: <1315063806.41.0.284714706003.issue845@bugs.pypy.org>


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

The official pypy 1.6 zip file was fixed, and the nightly build is also correct.

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

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

From tracker at bugs.pypy.org  Sat Sep  3 20:58:26 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 03 Sep 2011 18:58:26 +0000
Subject: [pypy-issue] [issue860] SQLite statement cache breaks django tests
In-Reply-To: <1315076306.01.0.156261103676.issue860@bugs.pypy.org>
Message-ID: <1315076306.01.0.156261103676.issue860@bugs.pypy.org>


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

Haven't tracked down why this causes it, just that it does.  Manifests itself a 
queries returning incorrect results.

----------
messages: 3081
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: SQLite statement cache breaks django tests

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

From tracker at bugs.pypy.org  Sat Sep  3 21:17:56 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 03 Sep 2011 19:17:56 +0000
Subject: [pypy-issue] [issue860] SQLite statement cache breaks django tests
In-Reply-To: <1315076306.01.0.156261103676.issue860@bugs.pypy.org>
Message-ID: <1315077476.56.0.468946095768.issue860@bugs.pypy.org>


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

fixed in a81fdc11a502

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

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

From tracker at bugs.pypy.org  Sat Sep  3 22:41:17 2011
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Sat, 03 Sep 2011 20:41:17 +0000
Subject: [pypy-issue] [issue831] Codes instead of cyrillic letters in
	terminal
In-Reply-To: <1313515172.05.0.933055217929.issue831@bugs.pypy.org>
Message-ID: <1315082477.75.0.677100257883.issue831@bugs.pypy.org>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

should we close it?

----------
status: testing -> resolved

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

From tracker at bugs.pypy.org  Sun Sep  4 00:41:18 2011
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Sat, 03 Sep 2011 22:41:18 +0000
Subject: [pypy-issue] [issue783] subprocess cannot handle unicode args
In-Reply-To: <1309962687.3.0.947652570439.issue783@bugs.pypy.org>
Message-ID: <1315089678.82.0.155487749737.issue783@bugs.pypy.org>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

hm.. seems that my patch actually works. I tried with current trunk and py.py. 
translated ok, but make failed because ld couldn't find SSLv2_method. Can someone 
review?

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

From tracker at bugs.pypy.org  Sun Sep  4 17:34:43 2011
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Sun, 04 Sep 2011 15:34:43 +0000
Subject: [pypy-issue] [issue861] Interactive console doesn't represent
	unicode right
In-Reply-To: <1315150483.65.0.246361819531.issue861@bugs.pypy.org>
Message-ID: <1315150483.65.0.246361819531.issue861@bugs.pypy.org>


New submission from Kostya Rybnikov <k.bx at ya.ru>:

to make long story short:

kost at kost-laptop:~/bin$ ./pypy-c-jit-47053-8ae8f6105e07-linux64/bin/pypy 
Python 2.7.1 (8ae8f6105e07, Sep 04 2011, 03:31:47)
[PyPy 1.6.0-dev1 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``color-coded blues''
>>>> print u'??????'
????????????

----------
messages: 3085
nosy: k_bx, pypy-issue
priority: bug
status: unread
title: Interactive console doesn't represent unicode right

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

From tracker at bugs.pypy.org  Sun Sep  4 17:41:32 2011
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Sun, 04 Sep 2011 15:41:32 +0000
Subject: [pypy-issue] [issue857] u"%s" % O() that has unicode __repr__()
	fails
In-Reply-To: <1314874395.78.0.666670423859.issue857@bugs.pypy.org>
Message-ID: <1315150892.94.0.618960963857.issue857@bugs.pypy.org>


Kostya Rybnikov <k.bx at ya.ru> added the comment:

arigo: also, http://bugs.python.org/issue5876 ("__repr__ returning unicode
doesn't work when called implicitly"), so I'm not the first who saw that. But in
terms that this is considered as a bug (that should be fixed one day), I suggest
to make things right and work.

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

From tracker at bugs.pypy.org  Mon Sep  5 01:12:59 2011
From: tracker at bugs.pypy.org (timo)
Date: Sun, 04 Sep 2011 23:12:59 +0000
Subject: [pypy-issue] [issue862] patch for implementing numpy.bincount (at
	applevel)
In-Reply-To: <1315177979.5.0.587724497271.issue862@bugs.pypy.org>
Message-ID: <1315177979.5.0.587724497271.issue862@bugs.pypy.org>


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

Hello,

I implemented numpy.bincount at applevel, including a couple of tests.
Please consider merging it into 1.6.1, as well.

Thank you :)

----------
files: pypy_numpy_bincount.patch
messages: 3087
nosy: pypy-issue, timo
priority: feature
status: unread
title: patch for implementing numpy.bincount (at applevel)

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

From tracker at bugs.pypy.org  Mon Sep  5 10:11:14 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 05 Sep 2011 08:11:14 +0000
Subject: [pypy-issue] [issue839] Sqlite in pypy 1.6 on amd64 is very slow :)
In-Reply-To: <1313914325.02.0.19991212695.issue839@bugs.pypy.org>
Message-ID: <1315210274.76.0.457763680685.issue839@bugs.pypy.org>


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

As alex said, with the recent changes now sqlite3 is between 10% faster and 30%
slower than CPython.  Few notes:

- the first iteration is much slower on PyPy, because of the JIT warmup

- to get optimal results, we need to manually set trace_limit to 60000, else we
don't get the full ctypes/JIT optimization.  This is a problem, but it will
hopefully will fixed when we will be able to predict the trace length more
accurately in the frontend.

These are the results on my machine:
$ python bench.py
Took: 0.304196119308
Took: 0.30193901062
Took: 0.300392866135
Took: 0.301836013794
Took: 0.30334687233

$ pypy-c bench.py
Took: 0.797653198242
Took: 0.402196884155
Took: 0.398077964783
Took: 0.401179075241
Took: 0.40417098999

$ pypy-c --jit trace_limit=60000 bench.py
Took: 0.645992040634
Took: 0.284580945969
Took: 0.285857915878
Took: 0.282681941986
Took: 0.283298015594

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

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

From tracker at bugs.pypy.org  Mon Sep  5 10:11:59 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 05 Sep 2011 08:11:59 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315210319.53.0.663355649082.issue844@bugs.pypy.org>


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

sorry, I fear that I'd need access to a mac machine to fix it then :-(

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

From tracker at bugs.pypy.org  Mon Sep  5 14:38:25 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 05 Sep 2011 12:38:25 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315226305.73.0.552527542808.issue844@bugs.pypy.org>


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

I rewrote the pwd module at interp-level, should I commit it?

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

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

From tracker at bugs.pypy.org  Mon Sep  5 14:39:24 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 05 Sep 2011 12:39:24 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315226364.06.0.924969381151.issue844@bugs.pypy.org>


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

yes please :-)

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

From tracker at bugs.pypy.org  Mon Sep  5 15:18:36 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 Sep 2011 13:18:36 +0000
Subject: [pypy-issue] [issue827] import xml.etree.cElementTree fails
In-Reply-To: <1313114876.32.0.380028080401.issue827@bugs.pypy.org>
Message-ID: <1315228716.91.0.366765182726.issue827@bugs.pypy.org>


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

I checked in a lib_pypy/_elementtree.py similar to yours in eb4d7421fbe6, and
indeed lib-python/2.7/test/test_xml_etree_c.py passes now.  I hope that it means
it is good enough and won't need too many additional tweaking...

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

From tracker at bugs.pypy.org  Mon Sep  5 22:27:16 2011
From: tracker at bugs.pypy.org (Michael Schurter)
Date: Mon, 05 Sep 2011 20:27:16 +0000
Subject: [pypy-issue] [issue863] Implement sys._current_frames() for
	debugging purposes
In-Reply-To: <1315254436.82.0.529402839353.issue863@bugs.pypy.org>
Message-ID: <1315254436.82.0.529402839353.issue863@bugs.pypy.org>


New submission from Michael Schurter <m at schmichael.com>:

The sys._current_frames[1] function, while internal, is a useful tool when
debugging a multithreaded process.

sys._getframe's usefulness is limited as it only inspects the current thread's
stack.

Feel free to WONTFIX as this is obviously a CPython specific feature that should
never be relied upon by applications.

[1] http://docs.python.org/library/sys.html

----------
messages: 3093
nosy: pypy-issue, schmichael
priority: wish
status: unread
title: Implement sys._current_frames() for debugging purposes

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

From tracker at bugs.pypy.org  Mon Sep  5 22:28:39 2011
From: tracker at bugs.pypy.org (vad)
Date: Mon, 05 Sep 2011 20:28:39 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315254519.26.0.616320280055.issue844@bugs.pypy.org>


vad <davide.setti at gmail.com> added the comment:

please, tell me if i can help testing it on osx. thanks

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

From tracker at bugs.pypy.org  Mon Sep  5 23:22:44 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 05 Sep 2011 21:22:44 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315257764.72.0.483137711188.issue844@bugs.pypy.org>


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

21f8faf13c20 rewrites the pwd module at interp-level (without ctypes).
It should fix the issue.

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

From tracker at bugs.pypy.org  Tue Sep  6 01:31:22 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 05 Sep 2011 23:31:22 +0000
Subject: [pypy-issue] [issue863] Implement sys._current_frames() for
	debugging purposes
In-Reply-To: <1315254436.82.0.529402839353.issue863@bugs.pypy.org>
Message-ID: <1315265482.41.0.717700941045.issue863@bugs.pypy.org>


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

Implemented in 411a4e22b5bc
Not so difficult actually :)

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

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

From tracker at bugs.pypy.org  Tue Sep  6 06:27:34 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Sep 2011 04:27:34 +0000
Subject: [pypy-issue] [issue861] Interactive console doesn't represent
	unicode right
In-Reply-To: <1315150483.65.0.246361819531.issue861@bugs.pypy.org>
Message-ID: <1315283254.67.0.536590317752.issue861@bugs.pypy.org>


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

Fixed in 659f7a0b3256.

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

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

From tracker at bugs.pypy.org  Tue Sep  6 13:50:38 2011
From: tracker at bugs.pypy.org (vad)
Date: Tue, 06 Sep 2011 11:50:38 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315309838.02.0.629710894465.issue844@bugs.pypy.org>


vad <davide.setti at gmail.com> added the comment:

can i just apply that patch to the pypy 1.6 tarball i downloaded for osx?

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

From tracker at bugs.pypy.org  Tue Sep  6 13:54:27 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Sep 2011 11:54:27 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315310067.04.0.941637438232.issue844@bugs.pypy.org>


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

No, but you can download the nightly tarball from
http://buildbot.pypy.org/nightly/trunk/ --- at least when the OS/X buildslave is
up again :-(

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

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

From tracker at bugs.pypy.org  Tue Sep  6 18:47:12 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Sep 2011 16:47:12 +0000
Subject: [pypy-issue] [issue863] Implement sys._current_frames() for
	debugging purposes
In-Reply-To: <1315254436.82.0.529402839353.issue863@bugs.pypy.org>
Message-ID: <1315327632.46.0.902636717557.issue863@bugs.pypy.org>


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

Warning: it may not work correctly with the JIT.  We need to think about it. 
The issue is that it gives random other threads access to frames that are
supposedly "private", i.e. that have been "proven" not to escape.  I'm unsure
that calling f.mark_as_escaped() from another thread has the correct effect in
this context.

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

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

From tracker at bugs.pypy.org  Tue Sep  6 19:34:48 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Sep 2011 17:34:48 +0000
Subject: [pypy-issue] [issue857] u"%s" % O() that has unicode __repr__()
	fails
In-Reply-To: <1314874395.78.0.666670423859.issue857@bugs.pypy.org>
Message-ID: <1315330488.5.0.978723806724.issue857@bugs.pypy.org>


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

Fixed, works like CPython now.  The actual issue was actually not related to
string formatting at all.  It was just that object.__str__() was implemented by
calling space.repr(), instead of directly calling the __repr__() method.  The
difference is that the first does type checking on the result, while the latter
does not.  It's not the job of object.__str__() to do type checking, but of its
callers.  Added tests and fix in 09816858a87a.

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

From tracker at bugs.pypy.org  Wed Sep  7 03:23:53 2011
From: tracker at bugs.pypy.org (timo)
Date: Wed, 07 Sep 2011 01:23:53 +0000
Subject: [pypy-issue] [issue864] numpy: initialize empty/zeros/ones with a
	tuple as size	argument - with test
In-Reply-To: <1315358633.32.0.31400648599.issue864@bugs.pypy.org>
Message-ID: <1315358633.32.0.31400648599.issue864@bugs.pypy.org>


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

hello,

i just hacked together support for calling np.zeros((size,)) instead of 
np.zeros(size). feel free to clean up the helper function and please merge it 
for 1.6.1 :)

cheers
  - Timo

----------
files: pypy_numpy_tuples_shape_init.patch
messages: 3102
nosy: pypy-issue, timo
priority: feature
status: unread
title: numpy: initialize empty/zeros/ones with a tuple as size argument - with test

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

From tracker at bugs.pypy.org  Wed Sep  7 05:37:10 2011
From: tracker at bugs.pypy.org (timo)
Date: Wed, 07 Sep 2011 03:37:10 +0000
Subject: [pypy-issue] [issue731] Problem handling set operations
In-Reply-To: <1306517163.22.0.300457778584.issue731@bugs.pypy.org>
Message-ID: <1315366630.06.0.159219284167.issue731@bugs.pypy.org>


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

there are win32 nightly builds again. can this bug be closed as resolved?

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

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

From tracker at bugs.pypy.org  Wed Sep  7 12:54:44 2011
From: tracker at bugs.pypy.org (timo)
Date: Wed, 07 Sep 2011 10:54:44 +0000
Subject: [pypy-issue] [issue864] numpy: initialize empty/zeros/ones with a
	tuple as size	argument - with test
In-Reply-To: <1315358633.32.0.31400648599.issue864@bugs.pypy.org>
Message-ID: <1315392884.94.0.171360124535.issue864@bugs.pypy.org>


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

here's a second patch that depends on the first one for raising a ValueError 
instead of a MemoryError when size is negative.

I've considered adding the check to SingleDimArray.__init__, but I felt, that 
the SingleDimArray constructor will only be called from code that interfaces 
with applevel code, anyway, so rather than checking for valid sizes every single 
time such a SingleDimArray is created, it would be less of a performance hit to 
check for negative sizes in the interfacing code (in this case, the function 
that unwraps a w_int or w_tuple for sizes, that is now used for ones, zeros and 
empty.)

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

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

From tracker at bugs.pypy.org  Thu Sep  8 05:23:06 2011
From: tracker at bugs.pypy.org (Josh Ayers)
Date: Thu, 08 Sep 2011 03:23:06 +0000
Subject: [pypy-issue] [issue865] Struct.pack and unpack 3x and 6x slower
	than CPython
In-Reply-To: <1315452186.86.0.406624978683.issue865@bugs.pypy.org>
Message-ID: <1315452186.86.0.406624978683.issue865@bugs.pypy.org>


New submission from Josh Ayers <josh.ayers at gmail.com>:

Using struct.pack and struct.unpack is significantly slower on PyPy 1.6 than on
CPython 2.7.2 when packing a large list.  This is under Windows 7.

A summary of the timing results is shown below and the code used is attached. 
The attached code uses 4 byte integers.  Floats show similar results.

              4 MB              40 MB          80 MB
           pack  unpack      pack  unpack   pack  unpack
 CPython   0.13  0.03        1.30  0.29     2.60  0.60
 PyPy      0.43  0.20        3.90  1.77     8.03  3.59
 Factor    3.3x  6.7x        3.0x  6.1x     3.1x  6.0x

The benchmark code packs a large list, writes it to a file, then reads the file
back in and unpacks it.  I didn't include it in the table above, but the reading
portion was also slower in PyPy.  However, it wasn't as large of a difference as
the struct packing and unpacking portion.

----------
messages: 3105
nosy: jayers2003, pypy-issue
priority: feature
status: unread
title: Struct.pack and unpack 3x and 6x slower than CPython

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

From tracker at bugs.pypy.org  Thu Sep  8 05:59:57 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 08 Sep 2011 03:59:57 +0000
Subject: [pypy-issue] [issue865] Struct.pack and unpack 3x and 6x slower
	than CPython
In-Reply-To: <1315452186.86.0.406624978683.issue865@bugs.pypy.org>
Message-ID: <1315454397.31.0.17395359693.issue865@bugs.pypy.org>


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

Yes, struct.pack and struct.unpack are known to be slower, especially with ints. 
Alex Gaynor's unroll-if-alt branch, which I think will be merged soon, should 
help out a great deal with this.

Reading and writing to files are also known to be slow because of the extra 
memory allocation and copying currently needed in order to make sure that the 
buffers used for the actual reading and writing of the files are not moved 
during copying by the garbage collector. Some ideas have been discussed to try 
to remedy this, but no one has actually worked to fix it yet to my knowledge.

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

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

From tracker at bugs.pypy.org  Thu Sep  8 06:15:19 2011
From: tracker at bugs.pypy.org (Josh Ayers)
Date: Thu, 08 Sep 2011 04:15:19 +0000
Subject: [pypy-issue] [issue865] Struct.pack and unpack 3x and 6x slower
	than CPython
In-Reply-To: <1315452186.86.0.406624978683.issue865@bugs.pypy.org>
Message-ID: <1315455319.41.0.373983677275.issue865@bugs.pypy.org>


Josh Ayers <josh.ayers at gmail.com> added the comment:

Thanks for the update.  Glad to hear it's a known issue with at least a partial
solution in work.

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

From tracker at bugs.pypy.org  Thu Sep  8 07:58:51 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 08 Sep 2011 05:58:51 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>


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

I've attached my first attempt at speeding up string's join method. I'm creating 
an issue so that I can get some feedback. First, I used the following script for 
benchmarking:

x = ['abcdef']*100
for i in xrange(100000):
    ''.join(x)

Benchmark results:

             CPython 2.7:  0.22 seconds

Pypy nightly from Sept 3:  0.44 seconds

         Pypy with patch:  0.35 seconds

The attached patch does two things for speed: 1) the checks for if the separator 
isn't empty and if the index is not 0 are taken out of the loop by making two 
separate loops 2) changed from using w_str, a multi-method, to calling unwrap on 
the strings.

The first speed-up is the lesser of the two speed-ups and while it makes for a 
little more code, I thought it wrong to have extra unnecessary checks inside of 
the loop. The speed-up for this was only 3-5%.

The second speed-up is important because str_w is a slow multi-method. We 
already know from using space.isinstance that the objects are all strings, so I 
saw no reason to use the multi-method when unwrap is so much faster. Is there a 
reason that the str_w multi-method must be used? Unwrap appears to be 
implemented in the optional RopeObjects, StringBufferObjects and 
StringJoinObjects, but not for the StringSliceObjects. Do I need to implement 
unwrap for StringSliceObjects then? It should only be like 3 lines.

As far as how to get further speed improvements for join, space.isinstance is 
really quite slow. However, we should get a fast-path when listmultiobjects are 
finished. I think that this will get us most of the rest of the way to joining 
being at least as fast as CPython.

The other part that I see possibly being sped up in the StringBuilder part. With 
a debug build of pypy from trunk without this patch and using callgrind, the 
appending to StringBuilder was accountable for 26% of the total time, but only 
11% of that is spent memcpy. The rest of the time is spent making sure that the 
string array doesn't need to grow, getting the correct addresses for the source 
and the destination, and calculating the number of bytes to be copied. Maybe the 
StringBuilder could save the current address to be copied to for appending so 
that it doesn't have to be calculated each time? Of course, if the string array 
is grown then the address could be faulty, but we can still speed up the case 
where the array isn't grown. Anyway, it is just an idea so feel free to shoot it 
down (and hopefully suggest a better one).

----------
files: strjoin.patch
messages: 3108
nosy: justinpeel, pypy-issue
priority: feature
status: unread
title: [PATCH] join is slow about 2x slower than Python

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

From tracker at bugs.pypy.org  Thu Sep  8 08:51:14 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 08 Sep 2011 06:51:14 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315464674.86.0.78435209708.issue866@bugs.pypy.org>


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

fijal told me why this won't work and I wondered about it as I worked on it. We 
pretty much have to use str_w and I can't just assert that the object is of type 
W_StringObject because the object could be some other string derivative. I guess I 
need to speed up str_w. I'll keep this open for a few days because hopefully I'll 
have a new patch.

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

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

From tracker at bugs.pypy.org  Thu Sep  8 09:17:46 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 08 Sep 2011 07:17:46 +0000
Subject: [pypy-issue] [issue865] Struct.pack and unpack 3x and 6x slower
	than CPython
In-Reply-To: <1315452186.86.0.406624978683.issue865@bugs.pypy.org>
Message-ID: <1315466266.35.0.120791700781.issue865@bugs.pypy.org>


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

The attachment you referenced seems to have gotten lost, any chance you can 
upload it so I can take a look?

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

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

From tracker at bugs.pypy.org  Thu Sep  8 16:16:29 2011
From: tracker at bugs.pypy.org (timo)
Date: Thu, 08 Sep 2011 14:16:29 +0000
Subject: [pypy-issue] [issue731] Problem handling set operations
In-Reply-To: <1306517163.22.0.300457778584.issue731@bugs.pypy.org>
Message-ID: <1315491389.18.0.435935529214.issue731@bugs.pypy.org>


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

i disagree, i just run the pypy-c-jit build for windows 32bit on my linux 
machine using wine and i can say that it works no-problem. i got it from here:

http://buildbot.pypy.org/nightly/trunk/

running the little script from antocuni in msg2556 works no problem and running 
GraphLib.py seems to work, too.

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

From tracker at bugs.pypy.org  Thu Sep  8 16:20:00 2011
From: tracker at bugs.pypy.org (Josh Ayers)
Date: Thu, 08 Sep 2011 14:20:00 +0000
Subject: [pypy-issue] [issue865] Struct.pack and unpack 3x and 6x slower
	than CPython
In-Reply-To: <1315452186.86.0.406624978683.issue865@bugs.pypy.org>
Message-ID: <1315491600.15.0.378188384222.issue865@bugs.pypy.org>


Josh Ayers <josh.ayers at gmail.com> added the comment:

File attached.

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

From tracker at bugs.pypy.org  Thu Sep  8 16:25:18 2011
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Thu, 08 Sep 2011 14:25:18 +0000
Subject: [pypy-issue] [issue783] subprocess cannot handle unicode args
In-Reply-To: <1309962687.3.0.947652570439.issue783@bugs.pypy.org>
Message-ID: <1315491918.7.0.359737905546.issue783@bugs.pypy.org>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

add some tests - don't have posix.spawn* on Linux (they sit in os module) so 
can't test.

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

From tracker at bugs.pypy.org  Fri Sep  9 08:18:33 2011
From: tracker at bugs.pypy.org (Alex Krusz)
Date: Fri, 09 Sep 2011 06:18:33 +0000
Subject: [pypy-issue] [issue843] PyPy slower than CPython with puzzle problem
In-Reply-To: <1314167447.35.0.774659658214.issue843@bugs.pypy.org>
Message-ID: <1315549113.97.0.229467362884.issue843@bugs.pypy.org>


Alex Krusz <harfatum at gmail.com> added the comment:

Not sure if this merits a separate submission, but I tried re-doing the
generate_compatibility function without using a set & or disjoint operation at
all, but rather building up each row from scratch. This too results in slower
performance with PyPy (Windows 1.6 beta) than with CPython 2.7.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue843>
________________________________________
-------------- next part --------------
#Assuming you cannot lay the blocks upright! That would be another can of worms, but it'd be doable.

import time
from sys import argv
from itertools import combinations, product, chain

t1 = time.clock()

def all_single_rows(width):
    #returns a list of all the possible block patterns for n total blocks with k of length 3
    result = []
    n = width / 2
    #cutting off decimal if present
    width_parity = width % 2
    for i in xrange(n/3 + 1):
        for bits in combinations(xrange(n-i), 2*i + width_parity):
            s = [2] * (n-i)
            for bit in bits:
                s[bit] = 3
            result.append(s)
    return result

def flatten(listOfLists):
    #"Flatten one level of nesting" thanks to http://docs.python.org/library/itertools.html
    return chain.from_iterable(listOfLists)
    
def running_total(list):
    total = 0
    total_list = []
    for item_num in xrange(len(list)): #could do -1 because the last items in the running totals will always be identical
        total += list[item_num]
        total_list.append(total)
    total_list.append(0) #hacky; to make the "j+2" position checking work when generating the fixed_sum_begins
    return total_list
   
def permutations(length):
    # we know the blocks of length length have only one two... so we can shortcut this.
    # we can also pseudo-overload this function to return blocks of 2s by using negatives
    if length > 0:
        return [[[3]*i + [2] + [3]*(length-i-1) for i in xrange(length)]]
    elif length < 0:
        return [[[2]]]*-length
    else:
        return [[[3]]]
   
def generate_compatibility(single_rows, width):
    length = len(single_rows)
    compatibility = [set([]) for x in xrange(length)]
    running_totals = [[] for x in xrange(length)]
    
    running_totals = [running_total(single_rows[i]) for i in xrange(length)]
    #tally the running totals for each row
    
    fixed_sum_begin = [[ 5 - single_rows[i][0] ] for i in xrange(length)]
    fixed_part_begin = [[ 5 - single_rows[i][0] ] for i in xrange(length)]
    
    fixed_sum_end = [[5 - single_rows[i][-1]] for i in xrange(length)]
    fixed_part_end = [[5 - single_rows[i][-1]] for i in xrange(length)]
    
    variable_part = dict()
    compat_blocks = [[] for i in xrange(length)]
    
    for i in xrange(length): # for the running total list for each row
        if single_rows[i][0] == 2: #since all compatibility pairs are symmetric,
            continue                    #we can skip the ones that start with 2
        
        j = 0
        
        while ( ( single_rows[i][j+1] != 3 ) or ( not fixed_sum_begin[i][j] - running_totals[i][j] in (-1, -4)))\
            and fixed_sum_begin[i][j] < (width - 2)\
            and not (single_rows[i][j+1] == 2 and fixed_sum_begin[i][j] - running_totals[i][j+2] == -4):
            #while there is no choice, we can fill up the first part of the row
            if ( (running_totals[i][j+2] - fixed_sum_begin[i][j] != 3) and (running_totals[i][j+1] - fixed_sum_begin[i][j] != 3)\
                and (width - fixed_sum_begin[i][j] != 4)) or (width - fixed_sum_begin[i][j] == 3):
                fixed_sum_begin[i].append(fixed_sum_begin[i][j] + 3)
            #might not need this! it (should be) guaranteed
            elif ( (running_totals[i][j+1] - fixed_sum_begin[i][j] != 2) and (running_totals[i][j] - fixed_sum_begin[i][j] != 2))\
            or (width - running_totals[i][j] == 2):
                #is the == 2 necessary?
                fixed_sum_begin[i].append(fixed_sum_begin[i][j] + 2)
            else:
                print "Bug!"
            j += 1
            #Need to account for false choices near end of row, see 32232 in 18,3;
            #this is a hacky way to do it. Implementing the above steps in reverse
            #may be more elegant, but slower.
            
        if fixed_sum_begin[i][-1] == width - 4:
            fixed_sum_begin[i].extend([width-2,width])
        elif width - fixed_sum_begin[i][-1] == 2 or width - fixed_sum_begin[i][-1] == 3:
            fixed_sum_begin[i].append(width)
        elif fixed_sum_begin[i][-1] == width - 6 and running_totals[i][-3] == width - 2:
            fixed_sum_begin[i].extend([width-3,width])
        
        fixed_part_begin[i].extend([fixed_sum_begin[i][y]-fixed_sum_begin[i][y-1] for y in xrange(1,len(fixed_sum_begin[i]))])
        #this goes back from the summed fixed rows, to the originals (made of 2s and 3s)
        ###print "fixed",i, fixed_rows[i]
        ##print "fixed:",fixed_part_begin[i]
        
        count = 0
        j = 0
        chunks = []
        reverse_count = width
        
        if fixed_sum_begin[i][-1] != width:
            #first, generate the fixed ending for each row
            single_rows[i].reverse()
            running_totals[i] = running_total(single_rows[i])
            
            while ( ( single_rows[i][j+1] != 3 ) or ( not fixed_sum_end[i][j] - running_totals[i][j] in (-1, -4)))\
            and fixed_sum_end[i][j] < (width - fixed_sum_begin[i][-1])\
            and not (single_rows[i][j+1] == 2 and fixed_sum_end[i][j] - running_totals[i][j+2] == -4):
                #while there is no choice, we can fill up the first part of the row
                if ( (running_totals[i][j+2] - fixed_sum_end[i][j] != 3) and (running_totals[i][j+1] - fixed_sum_end[i][j] != 3)\
                    and (width - fixed_sum_end[i][j] != 4)) or (width - fixed_sum_end[i][j] == 3):
                    fixed_sum_end[i].append(fixed_sum_end[i][j] + 3)
                #might not need this! it (should be) guaranteed
                elif ( (running_totals[i][j+1] - fixed_sum_end[i][j] != 2) and (running_totals[i][j] - fixed_sum_end[i][j] != 2))\
                or (width - running_totals[i][j] == 2):
                    #is the == 2 necessary?
                    fixed_sum_end[i].append(fixed_sum_end[i][j] + 2)
                else:
                    print "Bug!"
                j += 1
            
            single_rows[i].reverse()
                
            fixed_part_end[i].extend([fixed_sum_end[i][y]-fixed_sum_end[i][y-1] for y in xrange(1,len(fixed_sum_end[i]))])
            
            fixed_part_end[i].reverse()
            
            if sum(fixed_part_begin[i]) + sum(fixed_part_end[i]) != width:
                count = 0
                for j in xrange(len(fixed_sum_begin[i]),len(single_rows[i])-len(fixed_sum_end[i])): #is this right
                    if single_rows[i][j] == 2:
                        
                        if single_rows[i][j-1] == 3:# and had_two: #think about if this works
                            if count:
                                chunks += [count+1]
                            count = 0
                        else:
                            count -= 1
                    else: # == 3
                        if single_rows[i][j-1] == 2 and j != len(fixed_sum_begin[i]):
                            if count:
                                chunks += [count]
                            count = 1
                        else:
                            count += 1
                
                if count: chunks += [count]
                    
                if fixed_sum_begin[i][-1] + fixed_sum_end[i][-1] +\
                sum([3*x-1 for x in chunks if x > 0]) +\
                sum([-2*x for x in chunks if x < 0]) < width:
                    chunks[-1] += 1
                    
        
        if fixed_sum_begin[i][-1] != width:
            variable_part[i] = map(flatten,product(*flatten(map(permutations,chunks))))
        
        
    for i in xrange(length):
        
        if single_rows[i][0] == 2:
            continue
        
        if not variable_part.get(i,[]):
            #if there's no variable part; i.e. the whole row is fixed
            ##print "total is", fixed_part_begin[i]
            compat_blocks[i] = [fixed_part_begin[i]]
        else:
            for j in [list(x) for x in variable_part[i]]:
                compat_blocks[i].append(fixed_part_begin[i]+j+fixed_part_end[i])
            

    for i in xrange(length):
        for j in xrange(len(compat_blocks[i])):
            try:
                compatibility[i].add(single_rows.index(compat_blocks[i][j]))
                compatibility[single_rows.index(compat_blocks[i][j])].add(i)
            except ValueError:
                print "bug! i,j:",i,j
            
    #print "final compat:"
    #for q in xrange(length):
    #    print q, compatibility[q]
    return compatibility

def find_total_walls(compatibility, rows_left):
    length = len(compatibility)
    previous_row = [1 for x in xrange(length)]
    
    for row in xrange(rows_left - 1):
        next_row_possibilities = [0 for x in xrange(length)]
        for compat_index in xrange(length):
            for x in compatibility[compat_index]:
                next_row_possibilities[x] += previous_row[compat_index]
        previous_row = next_row_possibilities
    
    return sum(next_row_possibilities)
    
raw_width, height = float(argv[1]), int(argv[2])
width = int(raw_width*2)/3
#convert to ints, which are nicer. blocks of width 3 and 4.5 are at a 2:3 ratio

single_rows = all_single_rows(width)
compatibility = generate_compatibility(single_rows, width)
total_walls = find_total_walls(compatibility, height)

print total_walls

t2 = time.clock()
print "Total time was", round(t2-t1, 3), "seconds."

From tracker at bugs.pypy.org  Sat Sep 10 00:08:29 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Fri, 09 Sep 2011 22:08:29 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315606109.39.0.238989238706.issue866@bugs.pypy.org>


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

I had another idea. Why not just make a fast path for when all the objects being 
joined are strings? I've attached a patch that does just that.

Benchmark results (code in initial post):

          CPython 2.7.1: 0.22 seconds

Pypy nightly from Sep 3: 0.45 seconds

    Pypy with fast path: 0.21 seconds

It will make things a little bit slower for string-derivative objects or when a 
join is called on a string and there are unicode objects in the list being 
joined. However, I think that the most common case by far is joining a bunch of 
basic strings. What does everyone think of this patch?

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

From tracker at bugs.pypy.org  Sat Sep 10 00:19:35 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 09 Sep 2011 22:19:35 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315606775.98.0.200894816003.issue866@bugs.pypy.org>


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

I think it'd be easier to wait until we have type-specialized lists, then doing 
that check will be even easier.

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

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

From tracker at bugs.pypy.org  Sat Sep 10 00:33:09 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Fri, 09 Sep 2011 22:33:09 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315607589.54.0.782038436555.issue866@bugs.pypy.org>


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

Yes, you're quite right. I should see if there's anything that I can do to move 
that along.

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

From tracker at bugs.pypy.org  Sat Sep 10 01:50:35 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Fri, 09 Sep 2011 23:50:35 +0000
Subject: [pypy-issue] [issue843] PyPy slower than CPython with puzzle problem
In-Reply-To: <1314167447.35.0.774659658214.issue843@bugs.pypy.org>
Message-ID: <1315612235.83.0.834896681096.issue843@bugs.pypy.org>


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

Most of the time is spent in list's index function in your non-set 
implementation. This is the case for both CPython and Pypy.
Multimethods make up a lot of the Pypy index's function's time for this code. 
Also, there is an unnecessary length check in equal_wrappeditems. In addition, 
this code should hopefully be sped up by the list-strategies branch when it is 
finished.

As a side note, you are doing each list.index twice with the same value.. which 
about halves the time for both CPython and Pypy when this is changed.

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

From tracker at bugs.pypy.org  Sat Sep 10 17:43:59 2011
From: tracker at bugs.pypy.org (Da_Blitz)
Date: Sat, 10 Sep 2011 15:43:59 +0000
Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's
In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>
Message-ID: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>


New submission from Da_Blitz <pypy at pocketnix.org>:

urllib2 in the stdlib leaks fd's if an exception is raised while opening a
connection

the issue occurs due to a socket being opened then an exception being raised
before an object with the socket is returned, leaving no way to explicitly close
the object. on cpython this would not be an issue as the object would lose all
references almost immediately however it lingers around with a proper GC causing
FD's to build up if the same condition happens repeatedly (eg a loop/web crawling)

the file enclosed is a script to generate the leakage, to run invok it as
follows <python> leak.py

pypy should start leaking FD's and can be see in /proc/<pid of leak.py>/fd

will be reporting issue upstream and hopefully getting a fix in the standard
library but have opened this ticket to get a patch merged earlier in
modified-2.7 when a patch becomes avalible

thanks goes to vak for reporting this issue and timonato1 for assistance

----------
files: leak.py
messages: 3120
nosy: dablitz, pypy-issue
priority: bug
status: unread
title: urllib2 on pypy can leak fd's

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

From tracker at bugs.pypy.org  Sat Sep 10 18:52:28 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Sat, 10 Sep 2011 16:52:28 +0000
Subject: [pypy-issue] [issue868] Pypy json.dumps >100% slower than CPython
	2.7, simplejson
In-Reply-To: <1315673548.25.0.59851723037.issue868@bugs.pypy.org>
Message-ID: <1315673548.25.0.59851723037.issue868@bugs.pypy.org>


New submission from Xavier Morel <bugs.pypy.org at masklinn.net>:

Test setup: 2010 15" Macbook Pro (2.4GHz i5, 8GB RAM, Intel X25M 160GB), OSX 10.6.8
Python 2.6.7 (Macports)
Python 2.7.2 (Macports)
Pypy 1.6.0 (Aug 22 2011, 12:40:28, Macports)
simplejson 2.2.1 (pypi/pip, includes C speedups)

* Pypy is very fast at dumping an empty dict (~2.2??s, Python 2.7 takes 5??s)
* Pypy is much slower as soon as there are data in the dict, getting performances closer to CPython 2.6 than CPython 2.7:
  - 5 keys, 2 integer values, 3 string values
    + Pypy runtime is 2x CPython 2.7
    + Pypy runtime is 0.62x CPython 2.6
  - 5 keys, 1 integer value, 1 string value, 3 simple dicts (from above)
    + Pypy runtime is 4.7x CPython 2.7
    + Pypy runtime is 0.7x CPython 2.6
* As can be seen above, Pypy's json.dumps performances worsen (relatively to CPython implementations) as the dict to dump gets bigger and more 
complex. The worst case is a ridiculous test file I found on the 'net (671K JSON file) where pypy completely breaks down, with a runtime of 
260x CPython 2.7 (interestingly, while CPython 2.6's json could not load the file if I dumped a pickle from CPython 2.7 and loaded it in 2.6 
CPython 2.6 could json.dumps it and had a similar breakdown: Pypy's runtime is only 1.55x CPython 2.6 on that ridiculously huge object)

python2.6 bench.py
Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.RuntimeError'> ignored
Test case: EMPTY
	 loops per run 1267170
	Best performances: 8.09 usec/loop
Test case: SIMPLE
	 loops per run 387650
	Best performances: 26.95 usec/loop
Test case: NESTED
	 loops per run 110270
	Best performances: 94.09 usec/loop
python2.7 bench.py
Test case: EMPTY
	 loops per run 1248310
	Best performances: 4.97 usec/loop
Test case: SIMPLE
	 loops per run 1219280
	Best performances: 8.25 usec/loop
Test case: NESTED
	 loops per run 724410
	Best performances: 13.99 usec/loop
Test case: HUGE
	 loops per run 3400
	Best performances: 3085.52 usec/loop
python2.7 bench.py --simplejson
Test case: EMPTY
	 loops per run 1726060
	Best performances: 5.80 usec/loop
Test case: SIMPLE
	 loops per run 1030550
	Best performances: 9.65 usec/loop
Test case: NESTED
	 loops per run 574570
	Best performances: 16.22 usec/loop
Test case: HUGE
	 loops per run 3620
	Best performances: 2821.45 usec/loop
pypy-c bench.py
Test case: EMPTY
	 loops per run 517820
	Best performances: 2.19 usec/loop
Test case: SIMPLE
	 loops per run 48360
	Best performances: 16.94 usec/loop
Test case: NESTED
	 loops per run 15900
	Best performances: 65.57 usec/loop
Test case: HUGE
	 loops per run 10
	Best performances: 801478.39 usec/loop

Bench file linked below, HUGE case testfile is http://json-test-suite.googlecode.com/files/sample.zip

----------
files: bench.py
messages: 3121
nosy: masklinn, pypy-issue
priority: bug
status: unread
title: Pypy json.dumps >100% slower than CPython 2.7, simplejson

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

From tracker at bugs.pypy.org  Sat Sep 10 19:07:57 2011
From: tracker at bugs.pypy.org (Michael Schurter)
Date: Sat, 10 Sep 2011 17:07:57 +0000
Subject: [pypy-issue] [issue869] Implement ctypes.<type>.from_buffer method
In-Reply-To: <1315674477.29.0.889845043655.issue869@bugs.pypy.org>
Message-ID: <1315674477.29.0.889845043655.issue869@bugs.pypy.org>


New submission from Michael Schurter <m at schmichael.com>:

http://docs.python.org/library/ctypes#ctypes._CData.from_buffer

It's handy.

----------
messages: 3122
nosy: pypy-issue, schmichael
priority: wish
status: unread
title: Implement ctypes.<type>.from_buffer method

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

From tracker at bugs.pypy.org  Sat Sep 10 19:25:03 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 10 Sep 2011 17:25:03 +0000
Subject: [pypy-issue] [issue869] Implement ctypes.<type>.from_buffer method
In-Reply-To: <1315674477.29.0.889845043655.issue869@bugs.pypy.org>
Message-ID: <1315675503.55.0.955767882845.issue869@bugs.pypy.org>


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

Ah, a "new in 2.6" method.  It's part of the ctypes tests that we skip so far
because they are testing features introduced in 2.6 or 2.7.  There are tons of
small features like this one...

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

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

From tracker at bugs.pypy.org  Sat Sep 10 19:43:44 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 10 Sep 2011 17:43:44 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315676624.23.0.740282982422.issue866@bugs.pypy.org>


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

I think it's worth it anyway.  Another patch attached, trying to get all checks
out of loops for the common case; can someone measure it?

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

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue866>
________________________________________
-------------- next part --------------
diff -r ca11f6ae93ae pypy/objspace/std/stringobject.py
--- a/pypy/objspace/std/stringobject.py	Fri Sep 09 22:59:33 2011 -0700
+++ b/pypy/objspace/std/stringobject.py	Sat Sep 10 19:43:24 2011 +0200
@@ -364,6 +364,9 @@
     reslen = len(self) * (size - 1)
     for i in range(size):
         w_s = list_w[i]
+        if isinstance(w_s, W_StringObject):
+            reslen += len(w_s._value)
+            continue
         if not space.is_true(space.isinstance(w_s, space.w_str)):
             if space.is_true(space.isinstance(w_s, space.w_unicode)):
                 # we need to rebuild w_list here, because the original
@@ -378,10 +381,14 @@
         reslen += len(space.str_w(w_s))
 
     sb = StringBuilder(reslen)
-    for i in range(size):
-        if self and i != 0:
+    if len(self) > 0:
+        sb.append(space.str_w(list_w[0]))
+        for i in range(1, size):
             sb.append(self)
-        sb.append(space.str_w(list_w[i]))
+            sb.append(space.str_w(list_w[i]))
+    else:
+        for i in range(size):
+            sb.append(space.str_w(list_w[i]))
     return space.wrap(sb.build())
 
 def str_rjust__String_ANY_ANY(space, w_self, w_arg, w_fillchar):

From tracker at bugs.pypy.org  Sat Sep 10 19:45:53 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 10 Sep 2011 17:45:53 +0000
Subject: [pypy-issue] [issue863] Implement sys._current_frames() for
	debugging purposes
In-Reply-To: <1315254436.82.0.529402839353.issue863@bugs.pypy.org>
Message-ID: <1315676753.94.0.934574808947.issue863@bugs.pypy.org>


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

It does not: a call that can release the GIL is not necessarily followed by a
GUARD_NOT_FORCED.  Random nonsense is likely to occur.

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

From tracker at bugs.pypy.org  Sun Sep 11 04:06:47 2011
From: tracker at bugs.pypy.org (Leandro Lameiro)
Date: Sun, 11 Sep 2011 02:06:47 +0000
Subject: [pypy-issue] [issue870] ctypes.byref does not accept offset argument
In-Reply-To: <1315706807.4.0.88443640901.issue870@bugs.pypy.org>
Message-ID: <1315706807.4.0.88443640901.issue870@bugs.pypy.org>


New submission from Leandro Lameiro <lameiro at gmail.com>:

According to http://docs.python.org/library/ctypes.html#ctypes.byref , the
offset argument to ctypes.byref was introduced in Python 2.6, but is missing in
PyPy 1.6.

(btw, the drop-down to select a release does not have 1.6 yet)

----------
messages: 3126
nosy: lameiro, pypy-issue
priority: feature
status: unread
title: ctypes.byref does not accept offset argument

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

From tracker at bugs.pypy.org  Sun Sep 11 05:20:35 2011
From: tracker at bugs.pypy.org (timo)
Date: Sun, 11 Sep 2011 03:20:35 +0000
Subject: [pypy-issue] [issue868] Pypy json.dumps >100% slower than CPython
	2.7, simplejson
In-Reply-To: <1315673548.25.0.59851723037.issue868@bugs.pypy.org>
Message-ID: <1315711235.46.0.836085251758.issue868@bugs.pypy.org>


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

I just quickly and very nonscientifically poked my head into the json encoder 
code from lib-python/modified-2.7 and was able to speed up the "huge" benchmark 
from 700000 usecs/loop to 200000 usecs/loop, just by putting None into the 
markers dictionary instead of the object itself. I'm positive that I can figure 
out a few more things that pypy really, really doesn't like - but first I'll 
catch some sleep.

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

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

From tracker at bugs.pypy.org  Sun Sep 11 09:09:22 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sun, 11 Sep 2011 07:09:22 +0000
Subject: [pypy-issue] [issue868] Pypy json.dumps >100% slower than CPython
	2.7, simplejson
In-Reply-To: <1315673548.25.0.59851723037.issue868@bugs.pypy.org>
Message-ID: <1315724962.64.0.216280015109.issue868@bugs.pypy.org>


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

Your speed-up is really GC-related. Basically, setting markers to None stops the 
creation of a huge dictionary when encoding a huge, very nested object and 
making big dictionaries has already been shown to have a major slowdown from the 
GC (can be up to 80% of the running time in some of my tests using a dict as a 
counter).

Aside from the GC-related stuff, one of the reasons that the json encoder is 
slower for pypy is that it has a lot of complex generators in it. I tried 
switching the encoder from using a bunch of generators to passing around a list 
that is appended to and I get about 50% speed-up for the NESTED dict when dumps-
ed 6000 times (I didn't try the whole benchmark). However, as I was told 
recently, the modified-2.7 files are modified only to get them working, not for 
speed. We want to basically leave the standard library files as they are.

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

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

From tracker at bugs.pypy.org  Sun Sep 11 17:22:54 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 11 Sep 2011 15:22:54 +0000
Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's
In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>
Message-ID: <1315754574.76.0.0377257571068.issue867@bugs.pypy.org>


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

A link to the upstream issue would be useful.

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

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

From tracker at bugs.pypy.org  Sun Sep 11 17:24:48 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 11 Sep 2011 15:24:48 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315754688.89.0.260270932388.issue866@bugs.pypy.org>


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

I'll measure it. Note that there is a branch to speedup join in general (space-
iterator-improvements), although I focused on not-a-list scenario for now.

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

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

From tracker at bugs.pypy.org  Mon Sep 12 00:22:36 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 11 Sep 2011 22:22:36 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315779756.0.0.296069013181.issue866@bugs.pypy.org>


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

I'm a bit unhappy about isinstance(w_x, W_StringObject) fastpath. Maybe str_w 
should not be a multimethod in the first place then if it's slow? Or maybe 
multimethods should be removed alltogether if they don't work quite that well? It 
should be a simple call in this particular case no?

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

From tracker at bugs.pypy.org  Mon Sep 12 08:12:00 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Mon, 12 Sep 2011 06:12:00 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1315807920.51.0.294636735615.issue866@bugs.pypy.org>


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

I attached another fastpath version which includes pulling the checks out of the 
final loop. Here are timings for the code in my initial posting:

CPython 2.7.1: 0.225 seconds

Pypy Sept 3 nightly: 0.441 seconds

Pypy w/ simplerpatch: 0.246 seconds

Pypy w/ strjoinbetter: 0.214 seconds

Pypy w/ strjoinbetter_v2: 0.204 seconds

I just did a bunch of manual timings and took what appeared to be the mode for 
each benchmark so these aren't very scientifically done. However, it should give 
you a good idea of the speed differences between the different versions.

If we actually don't want to do the fast path and want to focus on the 
multimethods, what needs to be done to remove the multimethods completely in 
pypy (it looks like a big job)? For instance, would str_w become basically a 
bunch of isinstance checks or what? 

What about the check if the object is w_str? space.isinstance checks are quite 
slow because they actually create a type object for the object and then search 
the mro of the type from what I remember. Is there a better way for 
space.isinstance to be implemented or to check if these objects are string 
derivative objects? CPython just uses a flag to check if the objects are strings 
if I remember correctly.

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

From tracker at bugs.pypy.org  Mon Sep 12 10:05:51 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 12 Sep 2011 08:05:51 +0000
Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's
In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>
Message-ID: <1315814751.5.0.629521839794.issue867@bugs.pypy.org>


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

Python 3 added a "ResourceWarning" which is printed (in debug mode only) when a 
socket is closed by its __del__ method.  Its urllib module should be much more 
gc-friendly.

Can someone try to reproduce the issue with a python3 compiled in debug mode?

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

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

From tracker at bugs.pypy.org  Mon Sep 12 14:23:18 2011
From: tracker at bugs.pypy.org (vad)
Date: Mon, 12 Sep 2011 12:23:18 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1315830198.3.0.0590561589503.issue844@bugs.pypy.org>


vad <davide.setti at gmail.com> added the comment:

it's ok now! thanks!

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

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

From tracker at bugs.pypy.org  Tue Sep 13 21:55:15 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 13 Sep 2011 19:55:15 +0000
Subject: [pypy-issue] [issue822] translation issues with openssl >= 1.0.0
In-Reply-To: <1312983210.86.0.828588560028.issue822@bugs.pypy.org>
Message-ID: <1315943715.14.0.693436719501.issue822@bugs.pypy.org>


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

Fixed with f7b15eb5fd58. Thanks for the report!

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

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

From tracker at bugs.pypy.org  Fri Sep 16 05:33:34 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Fri, 16 Sep 2011 03:33:34 +0000
Subject: [pypy-issue] [issue707] PyPy memory leak in 1.5 on OSX
In-Reply-To: <1304257672.83.0.27253908776.issue707@>
Message-ID: <1316144014.52.0.175043256478.issue707@bugs.pypy.org>


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

This is happening on other platforms and with the current Pypy. I've isolated 
the problem to be creating the parsers in pyexpat. I've attached a script that 
exhibits the leak. I put a input() on the last line so that it was easier to 
check the memory usage. On 64-bit linux machine, CPython is uses 2.7MB while 
Pypy uses 417MB. Increasing the number of loops will cause the leak to grow so 
be careful.

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

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

From tracker at bugs.pypy.org  Fri Sep 16 06:16:09 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Fri, 16 Sep 2011 04:16:09 +0000
Subject: [pypy-issue] [issue707] PyPy memory leak in 1.5 on OSX
In-Reply-To: <1304257672.83.0.27253908776.issue707@>
Message-ID: <1316146569.65.0.561883469382.issue707@bugs.pypy.org>


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

I think that the problem lies with line 404 of pypy/module/pyexpat_interp.py. 
CallbackData is created and put into the global_storage class's dict, but it is 
never deleted as far as I can tell. The only call to 
global_storage.free_nonmoving_id is in the __del__ of W_XMLParserType and then 
it casts the pointer itself to an int rather than using the id. It seems like 
using self.id there instead should get rid of the problem. What do you think?

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

From tracker at bugs.pypy.org  Fri Sep 16 06:18:02 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 16 Sep 2011 04:18:02 +0000
Subject: [pypy-issue] [issue707] PyPy memory leak in 1.5 on OSX
In-Reply-To: <1304257672.83.0.27253908776.issue707@>
Message-ID: <1316146682.86.0.0467891884533.issue707@bugs.pypy.org>


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

I think you're right, the current code looks bogus to me.

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

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

From tracker at bugs.pypy.org  Fri Sep 16 12:55:33 2011
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Fri, 16 Sep 2011 10:55:33 +0000
Subject: [pypy-issue] [issue871] almost order of magnitude slower than
	cpython for a	example program
In-Reply-To: <1316170533.09.0.439014432671.issue871@bugs.pypy.org>
Message-ID: <1316170533.09.0.439014432671.issue871@bugs.pypy.org>


New submission from Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>:

for a example program given on irc pypy is much slower than cpython

----------
files: solver.py
messages: 3139
nosy: pypy-issue, ronny
priority: wish
status: unread
title: almost order of magnitude slower than cpython for a example program

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

From tracker at bugs.pypy.org  Fri Sep 16 12:58:58 2011
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Fri, 16 Sep 2011 10:58:58 +0000
Subject: [pypy-issue] [issue871] almost order of magnitude slower than
	cpython for a	example program
In-Reply-To: <1316170533.09.0.439014432671.issue871@bugs.pypy.org>
Message-ID: <1316170738.27.0.959819748624.issue871@bugs.pypy.org>


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

if memoize is turned to a noop, the runtime is very close again

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

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

From tracker at bugs.pypy.org  Fri Sep 16 13:20:12 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 16 Sep 2011 11:20:12 +0000
Subject: [pypy-issue] [issue871] almost order of magnitude slower than
	cpython for a	example program
In-Reply-To: <1316170533.09.0.439014432671.issue871@bugs.pypy.org>
Message-ID: <1316172012.64.0.347706444858.issue871@bugs.pypy.org>


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

One of the issues is likely the __call__ or the __get__ special methods on the
class 'memoized'.  It makes little sense to have a class here anyway; the
version I post now, solver2.py, is twice as fast on CPython and 4 times as fast
on PyPy.  

The remainder of the difference is probably in the strange use of namedtuples,
which is done with the comment "# Not pretty way to define Vehicle class, but
fast", which usually means "I've taken efforts to make my code unreadable and
slow on PyPy".

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

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

From tracker at bugs.pypy.org  Fri Sep 16 13:40:16 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 16 Sep 2011 11:40:16 +0000
Subject: [pypy-issue] [issue871] almost order of magnitude slower than
	cpython for a	example program
In-Reply-To: <1316170533.09.0.439014432671.issue871@bugs.pypy.org>
Message-ID: <1316173216.34.0.402121324728.issue871@bugs.pypy.org>


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

Forget the numbers I report here.  When I run the same command line twice in a
row I get results that can vary by a factor of almost 3.  I have no clue why
because the program doesn't use the 'random' module, but I think that given that
it reports varying "Explored N nodes" when we run it twice in a row, it must be
some dictionary order or other similar issue.

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

From tracker at bugs.pypy.org  Sat Sep 17 13:35:07 2011
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Sat, 17 Sep 2011 11:35:07 +0000
Subject: [pypy-issue] [issue872] getpass.unix_getpass fails with "IOError:
	[Errno 29]	Illegal seek: '<fdopen>'"
In-Reply-To: <1316259307.04.0.352496531406.issue872@bugs.pypy.org>
Message-ID: <1316259307.04.0.352496531406.issue872@bugs.pypy.org>


New submission from Kostya Rybnikov <k.bx at ya.ru>:

kost at kost-laptop:~/bin$ ./pypy-c-jit-47308-1d95dfe42b4f-linux64/bin/pypy 
Python 2.7.1 (1d95dfe42b4f, Sep 17 2011, 02:02:04)
[PyPy 1.6.0-dev1 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``peephope optimizations are what a
Sufficiently Smart Compiler uses''
>>>> import getpass
>>>> getpass.unix_getpass()
Password: Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File
"/home/kost/bin/pypy-c-jit-47308-1d95dfe42b4f-linux64/lib-python/2.7/getpass.py", line
74, in unix_getpass
    stream.flush()  # issue7208
IOError: [Errno 29] Illegal seek: '<fdopen>'

----------
messages: 3143
nosy: k_bx, pypy-issue
priority: bug
status: unread
title: getpass.unix_getpass fails with "IOError: [Errno 29] Illegal seek: '<fdopen>'"

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

From tracker at bugs.pypy.org  Sat Sep 17 17:52:33 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sat, 17 Sep 2011 15:52:33 +0000
Subject: [pypy-issue] [issue707] PyPy memory leak in 1.5 on OSX
In-Reply-To: <1304257672.83.0.27253908776.issue707@>
Message-ID: <1316274753.47.0.525765081204.issue707@bugs.pypy.org>


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

Pyexpat wasn't allowing the parser object to be collected because it put each 
parser in a global_storage container. I used a weakref and memory seems to be 
under control. The pyexpat_leak.py code I put up maxes out just over 100 MB no 
matter how many loops are done. Albert's code now maxes out at about 25MB for me 
rather than over 600 MB.

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

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

From tracker at bugs.pypy.org  Sat Sep 17 20:27:22 2011
From: tracker at bugs.pypy.org (Valery)
Date: Sat, 17 Sep 2011 18:27:22 +0000
Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's
In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>
Message-ID: <1316284042.74.0.834021086355.issue867@bugs.pypy.org>


Valery <khamenya at gmail.com> added the comment:

perhaps related:
http://bugs.python.org/issue1208304

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

From tracker at bugs.pypy.org  Sat Sep 17 20:51:36 2011
From: tracker at bugs.pypy.org (Valery)
Date: Sat, 17 Sep 2011 18:51:36 +0000
Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's
In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org>
Message-ID: <1316285496.97.0.0906169941153.issue867@bugs.pypy.org>


Valery <khamenya at gmail.com> added the comment:

by the way, unlike CPython, pypy (e6ecaadbcaf8, Sep 08 2011, 14:39:29) is also 
flooding a lot of this during execution of leak.py:

socket closed
x
Ex: 'NoneType' object has no attribute 'close'

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

From tracker at bugs.pypy.org  Sun Sep 18 11:58:05 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 18 Sep 2011 09:58:05 +0000
Subject: [pypy-issue] [issue872] getpass.unix_getpass fails with "IOError:
	[Errno 29]	Illegal seek: '<fdopen>'"
In-Reply-To: <1316259307.04.0.352496531406.issue872@bugs.pypy.org>
Message-ID: <1316339885.82.0.391713907271.issue872@bugs.pypy.org>


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

Bah, CPython ignores completely calls to flush() if they raise.  Needs to be
carefully fixed everywhere in rlib/streamio.py.

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

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

From tracker at bugs.pypy.org  Sun Sep 18 12:07:32 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 18 Sep 2011 10:07:32 +0000
Subject: [pypy-issue] [issue872] getpass.unix_getpass fails with "IOError:
	[Errno 29]	Illegal seek: '<fdopen>'"
In-Reply-To: <1316259307.04.0.352496531406.issue872@bugs.pypy.org>
Message-ID: <1316340452.07.0.808960626983.issue872@bugs.pypy.org>


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

I wrote too quickly, based on observation.  But looking at the source code and
"man fflush", the issue seems to be really that fflush() only flushes the output
buffers, not the input buffers, whereas streamio.py will "flush" the input
buffers too and do a small seek backward to compensate.  I think that we should
just kill this behavior, unless there are interesting counter-examples for why
we should not.

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

From tracker at bugs.pypy.org  Sun Sep 18 19:13:52 2011
From: tracker at bugs.pypy.org (anon)
Date: Sun, 18 Sep 2011 17:13:52 +0000
Subject: [pypy-issue] [issue873] PyPy almost 300 times slower in recursive
	AST evaluation
In-Reply-To: <1316366032.78.0.118026987379.issue873@bugs.pypy.org>
Message-ID: <1316366032.78.0.118026987379.issue873@bugs.pypy.org>


New submission from anon <b10419697 at klzlk.com>:

http://paste.ubuntu.com/692408/

Evaluation takes:
0.05s with Python 2.7
14s with PyPy 1.6
1 minute with recent PyPy

----------
messages: 3149
nosy: anon, pypy-issue
priority: bug
status: unread
title: PyPy almost 300 times slower in recursive AST evaluation

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

From tracker at bugs.pypy.org  Sun Sep 18 19:20:19 2011
From: tracker at bugs.pypy.org (anon)
Date: Sun, 18 Sep 2011 17:20:19 +0000
Subject: [pypy-issue] [issue851] PyPy does not optimize division into shifts
In-Reply-To: <1314592869.4.0.0613723527312.issue851@bugs.pypy.org>
Message-ID: <1316366419.54.0.871876852972.issue851@bugs.pypy.org>


anon <b10419697 at klzlk.com> added the comment:

Is it possible to recognize the composite bytecode that i//2 is transformed into
and turn that into shifts?

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

From tracker at bugs.pypy.org  Sun Sep 18 19:22:50 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 18 Sep 2011 17:22:50 +0000
Subject: [pypy-issue] [issue851] PyPy does not optimize division into shifts
In-Reply-To: <1314592869.4.0.0613723527312.issue851@bugs.pypy.org>
Message-ID: <1316366570.92.0.113609866158.issue851@bugs.pypy.org>


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

Yes, it would, in theory be possible.  However ATM we don't really do any 
optimizations of this kind, if you're interested I'm sure someone could help you 
get started, however in the meantime I don't think this is high on any of our 
priority lists because there are other, bigger fruit.

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

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

From tracker at bugs.pypy.org  Mon Sep 19 09:28:04 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 19 Sep 2011 07:28:04 +0000
Subject: [pypy-issue] [issue873] PyPy almost 300 times slower in recursive
	AST evaluation
In-Reply-To: <1316366032.78.0.118026987379.issue873@bugs.pypy.org>
Message-ID: <1316417284.1.0.117064841408.issue873@bugs.pypy.org>


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

Copied demo here, rather than at a paste that may go away and which requires you
to login in order to download the plain text version(!).

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

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

From tracker at bugs.pypy.org  Mon Sep 19 10:12:15 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 19 Sep 2011 08:12:15 +0000
Subject: [pypy-issue] [issue873] PyPy almost 300 times slower in recursive
	AST evaluation
In-Reply-To: <1316366032.78.0.118026987379.issue873@bugs.pypy.org>
Message-ID: <1316419935.84.0.0585149745262.issue873@bugs.pypy.org>


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

I could reproduce on 64-bit linux, were it's incredibly slower to run with the
JIT rather than with "--jit off".  On 32-bit linux for some reason it always
crashes instead of raising StackOverflow; we also have to figure out why...

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

From tracker at bugs.pypy.org  Tue Sep 20 19:12:02 2011
From: tracker at bugs.pypy.org (rian)
Date: Tue, 20 Sep 2011 17:12:02 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>


New submission from rian <rian at alum.mit.edu>:

let's say i have a module called socket in my package. if i do this in a sibling 
module:

"""
from __future__ import (with_statement,
                        absolute_import)
import socket
socket.TCP_NODELAY
"""

that causes an attribute error in pypy 1.6 but doesn't in cpython, if i change it 
to:

"""
from __future__ import with_statement
from __future__ import absolute_import
import socket
socket.TCP_NODELAY
"""

it works in pypy and cpyhon

----------
messages: 3154
nosy: pypy-issue, rian
priority: bug
status: unread
title: importing multiple __future__ features in one statement doesn't work in pypy 1.6

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

From tracker at bugs.pypy.org  Tue Sep 20 19:26:04 2011
From: tracker at bugs.pypy.org (Benjamin Peterson)
Date: Tue, 20 Sep 2011 17:26:04 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316539564.38.0.324548881521.issue874@bugs.pypy.org>


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

Can you try with the nightly?

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

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

From tracker at bugs.pypy.org  Wed Sep 21 17:19:29 2011
From: tracker at bugs.pypy.org (Osvaldo)
Date: Wed, 21 Sep 2011 15:19:29 +0000
Subject: [pypy-issue] [issue875] Thrift installation error: cStringIO.h
	missing
In-Reply-To: <1316618369.5.0.0180470843305.issue875@bugs.pypy.org>
Message-ID: <1316618369.5.0.0180470843305.issue875@bugs.pypy.org>


New submission from Osvaldo <tupy at riachao.com>:

I created a pypy virtualenv and tried to install thrift 0.7.0 by using the pip.
I got the error: http://paste.pocoo.org/show/479924/

----------
files: 479924.txt
messages: 3156
nosy: pypy-issue, tupy
priority: bug
status: unread
title: Thrift installation error: cStringIO.h missing

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue875>
________________________________________
-------------- next part --------------
Downloading/unpacking thrift
  Downloading thrift-0.7.0.tar.gz
  Running setup.py egg_info for package thrift
    
Installing collected packages: thrift
  Running setup.py install for thrift
    building 'thrift.protocol.fastbinary' extension
    cc -fPIC -Wimplicit -I/opt/ENV/include -c src/protocol/fastbinary.c -o build/temp.linux-i686-2.7/src/protocol/fastbinary.o
    src/protocol/fastbinary.c:21: fatal error: cStringIO.h: No such file or directory
    compilation terminated.
    error: command 'cc' failed with exit status 1
    Complete output from command /opt/ENV/bin/pypy -c "import setuptools;__file__='/opt/ENV/build/thrift/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --single-version-externally-managed --record /tmp/pip-7MH5uR-record/install-record.txt --install-headers /opt/ENV/include/site/python2.7:
    running install

running build

running build_py

creating build

creating build/lib.linux-i686-2.7

creating build/lib.linux-i686-2.7/thrift

copying src/__init__.py -> build/lib.linux-i686-2.7/thrift

copying src/TSCons.py -> build/lib.linux-i686-2.7/thrift

copying src/Thrift.py -> build/lib.linux-i686-2.7/thrift

copying src/TSerialization.py -> build/lib.linux-i686-2.7/thrift

creating build/lib.linux-i686-2.7/thrift/protocol

copying src/protocol/TCompactProtocol.py -> build/lib.linux-i686-2.7/thrift/protocol

copying src/protocol/TProtocol.py -> build/lib.linux-i686-2.7/thrift/protocol

copying src/protocol/TBinaryProtocol.py -> build/lib.linux-i686-2.7/thrift/protocol

copying src/protocol/__init__.py -> build/lib.linux-i686-2.7/thrift/protocol

creating build/lib.linux-i686-2.7/thrift/transport

copying src/transport/TTwisted.py -> build/lib.linux-i686-2.7/thrift/transport

copying src/transport/THttpClient.py -> build/lib.linux-i686-2.7/thrift/transport

copying src/transport/__init__.py -> build/lib.linux-i686-2.7/thrift/transport

copying src/transport/TTransport.py -> build/lib.linux-i686-2.7/thrift/transport

copying src/transport/TZlibTransport.py -> build/lib.linux-i686-2.7/thrift/transport

copying src/transport/TSSLSocket.py -> build/lib.linux-i686-2.7/thrift/transport

copying src/transport/TSocket.py -> build/lib.linux-i686-2.7/thrift/transport

creating build/lib.linux-i686-2.7/thrift/server



copying src/server/THttpServer.py -> build/lib.linux-i686-2.7/thrift/server

copying src/server/TNonblockingServer.py -> build/lib.linux-i686-2.7/thrift/server

copying src/server/TServer.py -> build/lib.linux-i686-2.7/thrift/server

copying src/server/__init__.py -> build/lib.linux-i686-2.7/thrift/server

copying src/server/TProcessPoolServer.py -> build/lib.linux-i686-2.7/thrift/server

running build_ext

building 'thrift.protocol.fastbinary' extension

creating build/temp.linux-i686-2.7

creating build/temp.linux-i686-2.7/src

creating build/temp.linux-i686-2.7/src/protocol

cc -fPIC -Wimplicit -I/opt/ENV/include -c src/protocol/fastbinary.c -o build/temp.linux-i686-2.7/src/protocol/fastbinary.o

src/protocol/fastbinary.c:21: fatal error: cStringIO.h: No such file or directory

compilation terminated.

error: command 'cc' failed with exit status 1

----------------------------------------
Command /opt/ENV/bin/pypy -c "import setuptools;__file__='/opt/ENV/build/thrift/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --single-version-externally-managed --record /tmp/pip-7MH5uR-record/install-record.txt --install-headers /opt/ENV/include/site/python2.7 failed with error code 1
Storing complete log in /root/.pip/pip.log

From tracker at bugs.pypy.org  Thu Sep 22 04:37:54 2011
From: tracker at bugs.pypy.org (Stian Andreassen)
Date: Thu, 22 Sep 2011 02:37:54 +0000
Subject: [pypy-issue] [issue876] __builtins__ ain't modifyable in pypy,
	but it works in CPython 2.7.2.
In-Reply-To: <1316659074.54.0.916704762474.issue876@bugs.pypy.org>
Message-ID: <1316659074.54.0.916704762474.issue876@bugs.pypy.org>


New submission from Stian Andreassen <stian at tech1.org>:

__builtins__["something"] = "test"

Pypy gives:
Traceback (most recent call last):                                             
                                                                               
          
  File "<console>", line 1, in <module>                                        
                                                                               
          
TypeError: 'module' object does not support item assignment 

Python 2.7.2 have no problems doing this.

----------
messages: 3157
nosy: pypy-issue, stian
priority: bug
status: unread
title: __builtins__ ain't modifyable in pypy, but it works in CPython 2.7.2.

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

From tracker at bugs.pypy.org  Thu Sep 22 04:40:40 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 22 Sep 2011 02:40:40 +0000
Subject: [pypy-issue] [issue876] __builtins__ ain't modifyable in pypy,
	but it works in CPython 2.7.2.
In-Reply-To: <1316659074.54.0.916704762474.issue876@bugs.pypy.org>
Message-ID: <1316659240.97.0.068603716021.issue876@bugs.pypy.org>


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

CPython has some crazy inconsistancies around __builtins__, and PyPy doesn't
always match them, specifically sometimes it's a dictionary and other times it's
a module (as mentioned here:
http://pypy.readthedocs.org/en/latest/cpython_differences.html#miscellaneous) 
This is a known issue and won't be fixed.  However, you can have something that
works on both by doing:

import __builtin__
__builtin__.something = "test"

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

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

From tracker at bugs.pypy.org  Thu Sep 22 15:07:53 2011
From: tracker at bugs.pypy.org (Stian Andreassen)
Date: Thu, 22 Sep 2011 13:07:53 +0000
Subject: [pypy-issue] [issue876] __builtins__ ain't modifyable in pypy,
	but it works in CPython 2.7.2.
In-Reply-To: <1316659240.97.0.068603716021.issue876@bugs.pypy.org>
Message-ID: <a2b2f417a09d32edd04cd2fc62baa2f4@tech1.org>


Stian Andreassen <stian at tech1.org> added the comment:

Alright, that seems to do the trick. 

On Thu, 22 Sep 2011 02:40:40
+0000, Alex Gaynor wrote: 

CPython has some crazy inconsistancies around __builtins__, and PyPy
doesn't
> always match them, specifically sometimes it's a dictionary
and other times it's
> a module (as mentioned here:
>
http://pypy.readthedocs.org/en/latest/cpython_differences.html#miscellaneous
[2]) 
> This is a known issue and won't be fixed. However, you can have
something that
> works on both by doing:
> 
> import __builtin__
>
__builtin__.something = "test"
> 
> ----------
> nosy: +agaynor
>
status: unread -> wontfix
> 
>
________________________________________
> PyPy bug tracker 
> 
>
________________________________________

Links:
------
[1]
mailto:alex.gaynor at gmail.com
[2]
http://pypy.readthedocs.org/en/latest/cpython_differences.html#miscellaneous
[3]
mailto:tracker at bugs.pypy.org
[4] https://bugs.pypy.org/issue876

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

From tracker at bugs.pypy.org  Thu Sep 22 20:10:49 2011
From: tracker at bugs.pypy.org (timo)
Date: Thu, 22 Sep 2011 18:10:49 +0000
Subject: [pypy-issue] [issue877] [patch] implement numpy.random.{rand, randn,
	{set, get}_state, seed, standard_normal}
In-Reply-To: <1316715049.57.0.329936178107.issue877@bugs.pypy.org>
Message-ID: <1316715049.57.0.329936178107.issue877@bugs.pypy.org>


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

hello,

I implemented a few methods of numpy.random based on the random module. Of 
course, there's also a couple of tests.

----------
files: pypy_numpy_random_initial_work.patch
messages: 3160
nosy: pypy-issue, timo
priority: feature
status: unread
title: [patch] implement numpy.random.{rand,randn,{set,get}_state,seed,standard_normal}

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

From tracker at bugs.pypy.org  Thu Sep 22 20:42:41 2011
From: tracker at bugs.pypy.org (timo)
Date: Thu, 22 Sep 2011 18:42:41 +0000
Subject: [pypy-issue] [issue877] [patch] implement numpy.random.{rand, randn,
	{set, get}_state, seed, standard_normal}
In-Reply-To: <1316715049.57.0.329936178107.issue877@bugs.pypy.org>
Message-ID: <1316716961.83.0.149545356762.issue877@bugs.pypy.org>


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

here's a patch on top of the first one that adds random_integers and randint.

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

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

From tracker at bugs.pypy.org  Thu Sep 22 23:05:10 2011
From: tracker at bugs.pypy.org (yasirs)
Date: Thu, 22 Sep 2011 21:05:10 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>


New submission from yasirs <yasir.suhail at gmail.com>:

The default maximum open files for pypy is different from cPython and this has bad 
implications for compatibility. While trying to install sphinx (required for 
ipython) from https://bitbucket.org/birkenfeld/sphinx/, I get 
error: /opt/local/lib/pypy/site-packages/Sphinx-1.1predev_20110922-
py2.7.egg/sphinx/themes/agogo/theme.conf: Too many open files

----------
messages: 3162
nosy: pypy-issue, yasirs
priority: critical
status: unread
title: too many open files

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

From tracker at bugs.pypy.org  Thu Sep 22 23:06:49 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 22 Sep 2011 21:06:49 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316725609.4.0.151294542072.issue878@bugs.pypy.org>


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

Neither PyPy nor CPython have a maximum open file limit, your OS does.  This
error would occur because some application is not explicitly closing files, this
is a bug in their code, not in PyPy.

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

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

From tracker at bugs.pypy.org  Thu Sep 22 23:09:33 2011
From: tracker at bugs.pypy.org (yasirs)
Date: Thu, 22 Sep 2011 21:09:33 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316725773.01.0.540224746027.issue878@bugs.pypy.org>


yasirs <yasir.suhail at gmail.com> added the comment:

I am not sure why this happens really since CPython seems to be doing ok on 
this, an in pypy-c, I get 


>>>> resource.getrlimit(resource.RLIMIT_NOFILE)
(256L, 9223372036854775807L)

so it shouldn't be a problem.

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

From tracker at bugs.pypy.org  Thu Sep 22 23:10:50 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 22 Sep 2011 21:10:50 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316725850.71.0.79919233107.issue878@bugs.pypy.org>


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

It occurs because PyPy's GC doesn't immediately collect unreferenced objects, as
documented:
http://doc.pypy.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies

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

From tracker at bugs.pypy.org  Thu Sep 22 23:13:00 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 22 Sep 2011 21:13:00 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316725980.74.0.76351917573.issue878@bugs.pypy.org>


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

Do you have a traceback?

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

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

From tracker at bugs.pypy.org  Thu Sep 22 23:19:28 2011
From: tracker at bugs.pypy.org (yasirs)
Date: Thu, 22 Sep 2011 21:19:28 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316726368.31.0.156314704341.issue878@bugs.pypy.org>


yasirs <yasir.suhail at gmail.com> added the comment:

cros posted on sphinx: https://bitbucket.org/birkenfeld/sphinx/issue/770

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

From tracker at bugs.pypy.org  Fri Sep 23 00:16:31 2011
From: tracker at bugs.pypy.org (yasirs)
Date: Thu, 22 Sep 2011 22:16:31 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316729791.32.0.261777950086.issue878@bugs.pypy.org>


yasirs <yasir.suhail at gmail.com> added the comment:

If the GC is supposed to work differently, perhaps the distribute or setuptools 
need to be re-written to close files as they go? This is the traceback


> /opt/local/lib/pypy/lib-python/modified-2.7/distutils/core.py(152)setup()
-> dist.run_commands()
  /opt/local/lib/pypy/lib-python/modified-
2.7/distutils/dist.py(953)run_commands()
-> self.run_command(cmd)
  /opt/local/lib/pypy/lib-python/modified-
2.7/distutils/dist.py(972)run_command()
-> cmd_obj.run()
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/install.py(73)run()
-> self.do_egg_install()
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/install.py(101)do_egg_install()
-> cmd.run()
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/easy_install.py(345)run()
-> self.easy_install(spec, not self.no_deps)
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/easy_install.py(565)easy_install()
-> return self.install_item(None, spec, tmpdir, deps, True)
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/easy_install.py(615)install_item()
-> dists = self.install_eggs(spec, download, tmpdir)
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/easy_install.py(769)install_eggs()
-> return [self.install_egg(dist_filename, tmpdir)]
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/easy_install.py(843)install_egg()
-> (os.path.basename(egg_path),os.path.dirname(destination)))
  /opt/local/lib/pypy/lib-python/modified-2.7/distutils/cmd.py(349)execute()
-> util.execute(func, args, msg, dry_run=self.dry_run)
  /opt/local/lib/pypy/lib-python/modified-2.7/distutils/util.py(401)execute()
-> func(*args)
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/command/easy_install.py(1148)unpack_and_compile()
-> unpack_archive(egg_path, destination, pf)
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/archive_util.py(67)unpack_archive()
-> driver(filename, extract_dir, progress_filter)
  /opt/local/lib/pypy/site-packages/distribute-0.6.19-
py2.5.egg/setuptools/archive_util.py(155)unpack_zipfile()
-> f = open(target,'wb')

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

From benjamin at python.org  Fri Sep 23 00:24:29 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 22 Sep 2011 18:24:29 -0400
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316729791.32.0.261777950086.issue878@bugs.pypy.org>
References: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
	<1316729791.32.0.261777950086.issue878@bugs.pypy.org>
Message-ID: <CAPZV6o_TkeiM43Wb8S6dPNNsu9vjA7zFY70V2WDQgURu2GS3Xw@mail.gmail.com>

2011/9/22 yasirs <tracker at bugs.pypy.org>:
>
> yasirs <yasir.suhail at gmail.com> added the comment:
>
> If the GC is supposed to work differently, perhaps the distribute or setuptools
> need to be re-written to close files as they go? This is the traceback

Yes, they do; this is not, however, pypy's problem. :)


-- 
Regards,
Benjamin

From tracker at bugs.pypy.org  Fri Sep 23 00:34:54 2011
From: tracker at bugs.pypy.org (yasirs)
Date: Thu, 22 Sep 2011 22:34:54 +0000
Subject: [pypy-issue] [issue878] too many open files
In-Reply-To: <1316725510.98.0.71219979546.issue878@bugs.pypy.org>
Message-ID: <1316730894.84.0.187704718404.issue878@bugs.pypy.org>


yasirs <yasir.suhail at gmail.com> added the comment:

>> If the GC is supposed to work differently, perhaps the distribute or 
setuptools
>> need to be re-written to close files as they go? This is the traceback

>Yes, they do; this is not, however, pypy's problem. :)

Only as much as the standard package manager and installer doesn't work with 
pypy in some cases. Just perusing the setuptools code, it seems that they are 
closing files so I don't think it is that simple. Can anyone reproduce this 
though?

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

From tracker at bugs.pypy.org  Fri Sep 23 17:20:14 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 23 Sep 2011 15:20:14 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316791214.32.0.258408198126.issue874@bugs.pypy.org>


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

Doesn't work for me: the nightly shows the same problem as pypy 1.6.

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

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

From tracker at bugs.pypy.org  Fri Sep 23 17:28:00 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 23 Sep 2011 15:28:00 +0000
Subject: [pypy-issue] [issue872] getpass.unix_getpass fails with "IOError:
	[Errno 29]	Illegal seek: '<fdopen>'"
In-Reply-To: <1316259307.04.0.352496531406.issue872@bugs.pypy.org>
Message-ID: <1316791680.48.0.797023841157.issue872@bugs.pypy.org>


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

Read the "man fflush" too fast.  It indeed says that it flushes input buffers
too, but doesn't explain what it does if the underlying file descriptor doesn't
support lseek...  I guess I need to look into the source code of glibc :-/

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

From tracker at bugs.pypy.org  Fri Sep 23 19:06:15 2011
From: tracker at bugs.pypy.org (Benjamin Peterson)
Date: Fri, 23 Sep 2011 17:06:15 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316797575.26.0.156132505063.issue874@bugs.pypy.org>


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

8d3b0e8415de

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

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

From tracker at bugs.pypy.org  Fri Sep 23 19:29:28 2011
From: tracker at bugs.pypy.org (rian)
Date: Fri, 23 Sep 2011 17:29:28 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316798968.26.0.0733038448599.issue874@bugs.pypy.org>


rian <rian at alum.mit.edu> added the comment:

https://bitbucket.org/pypy/pypy/changeset/8d3b0e8415de

Hmm in the case where newline_ok is true and c != '\\' it seems you are swallowing 
an extra character. Shouldn't line 236 be indented once into the first "if slash" 
statement?

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

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

From tracker at bugs.pypy.org  Fri Sep 23 19:30:18 2011
From: tracker at bugs.pypy.org (rian)
Date: Fri, 23 Sep 2011 17:30:18 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316799018.93.0.74719888086.issue874@bugs.pypy.org>


rian <rian at alum.mit.edu> added the comment:

Otherwise thanks for the epic turnaround time!

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

From tracker at bugs.pypy.org  Fri Sep 23 19:33:22 2011
From: tracker at bugs.pypy.org (rian)
Date: Fri, 23 Sep 2011 17:33:22 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316799202.59.0.284035570311.issue874@bugs.pypy.org>


rian <rian at alum.mit.edu> added the comment:

Actually my mistake, I didn't realize that self.pos affected self.getc, ignore

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

From tracker at bugs.pypy.org  Fri Sep 23 19:42:14 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 23 Sep 2011 17:42:14 +0000
Subject: [pypy-issue] [issue874] importing multiple __future__ features in
	one statement	doesn't work in pypy 1.6
In-Reply-To: <1316538722.71.0.633779474342.issue874@bugs.pypy.org>
Message-ID: <1316799734.1.0.271310929581.issue874@bugs.pypy.org>


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

reclosing

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

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

From tracker at bugs.pypy.org  Fri Sep 23 19:43:41 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 23 Sep 2011 17:43:41 +0000
Subject: [pypy-issue] [issue875] Thrift installation error: cStringIO.h
	missing
In-Reply-To: <1316618369.5.0.0180470843305.issue875@bugs.pypy.org>
Message-ID: <1316799821.62.0.154831152892.issue875@bugs.pypy.org>


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

The C extension should not be built for performance purposes. I'm not 100% sure, 
but I think cStringIO.h is not a part of standard Python C interface.

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

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

From tracker at bugs.pypy.org  Fri Sep 23 19:44:33 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 23 Sep 2011 17:44:33 +0000
Subject: [pypy-issue] [issue875] Thrift installation error: cStringIO.h
	missing
In-Reply-To: <1316618369.5.0.0180470843305.issue875@bugs.pypy.org>
Message-ID: <1316799873.93.0.603023012203.issue875@bugs.pypy.org>


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

I remember looking at this, AFAICT thrift doesn't even use this C extension, so 
they really should disable it.

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

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

From tracker at bugs.pypy.org  Fri Sep 23 22:40:34 2011
From: tracker at bugs.pypy.org (yasirs)
Date: Fri, 23 Sep 2011 20:40:34 +0000
Subject: [pypy-issue] [issue879] curses doesnt load in PyPy 1.6.0 Macports
In-Reply-To: <1316810434.84.0.560417400301.issue879@bugs.pypy.org>
Message-ID: <1316810434.84.0.560417400301.issue879@bugs.pypy.org>


New submission from yasirs <yasir.suhail at gmail.com>:

I installed pypy through Macports, and when I try to import curses, it gives an 
error.


$ pypy-c 
Python 2.7.1 (?, Aug 22 2011, 11:29:45)
[PyPy 1.6.0] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``dystopian and utopian chairs''
>>>> import curses
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/opt/local/lib/pypy/lib-python/2.7/curses/__init__.py", line 15, in 
<module>
    from _curses import *
ImportError: No module named _curses
>>>>

----------
messages: 3180
nosy: pypy-issue, yasirs
priority: critical
status: unread
title: curses doesnt load in PyPy 1.6.0 Macports

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

From tracker at bugs.pypy.org  Fri Sep 23 22:49:07 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 23 Sep 2011 20:49:07 +0000
Subject: [pypy-issue] [issue879] curses doesnt load in PyPy 1.6.0 Macports
In-Reply-To: <1316810434.84.0.560417400301.issue879@bugs.pypy.org>
Message-ID: <1316810947.69.0.468752472932.issue879@bugs.pypy.org>


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

Well, PyPy doesn't support _curses. Not sure if it's a bug or a wontfix. Feel 
free to contribute the module though, say by using ctypes.

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

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

From tracker at bugs.pypy.org  Sat Sep 24 14:29:03 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 24 Sep 2011 12:29:03 +0000
Subject: [pypy-issue] [issue877] [patch] implement numpy.random.{rand, randn,
	{set, get}_state, seed, standard_normal}
In-Reply-To: <1316715049.57.0.329936178107.issue877@bugs.pypy.org>
Message-ID: <1316867343.47.0.255256244236.issue877@bugs.pypy.org>


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

Hi.

If this contains only appleveldefs (maybe that's what we want, maybe not), it 
should instead go to numpy in lib-pypy and we should rename micronumpy to _numpy 
that implements all interpreter level definitions. I would rather close this 
issue and give you commit rights so you can work on a branch.

Cheers,
fijal

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

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

From tracker at bugs.pypy.org  Sat Sep 24 17:05:36 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 24 Sep 2011 15:05:36 +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: <1316876736.55.0.500334335371.issue789@bugs.pypy.org>


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

As of nightly no longer true, closing :) After warmup we're 50% faster

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

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

From tracker at bugs.pypy.org  Sun Sep 25 06:57:00 2011
From: tracker at bugs.pypy.org (Ante)
Date: Sun, 25 Sep 2011 04:57:00 +0000
Subject: [pypy-issue] [issue880] Django/SQLite3 - 'One and only one
	statement required'	Warning
In-Reply-To: <1316926620.11.0.498276554023.issue880@bugs.pypy.org>
Message-ID: <1316926620.11.0.498276554023.issue880@bugs.pypy.org>


New submission from Ante <nikuda at gmail.com>:

Environment:

Request Method: GET
Request URL: http://127.0.0.1:8000/admin/

Django Version: 1.3.1
Python Version: 2.7.1
Installed Applications:
['django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'django.contrib.admin',
 'polls']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware')


Traceback:
File "/Users/Ante/.virtualenvs/prj/site-packages/django/core/handlers/base.py" in get_response
  111.                         response = callback(request, *callback_args, **callback_kwargs)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/contrib/admin/sites.py" in wrapper
  214.                 return self.admin_view(view, cacheable)(*args, **kwargs)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/utils/decorators.py" in _wrapped_view
  93.                     response = view_func(request, *args, **kwargs)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/views/decorators/cache.py" in 
_wrapped_view_func
  79.         response = view_func(request, *args, **kwargs)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/contrib/admin/sites.py" in inner
  195.             if not self.has_permission(request):
File "/Users/Ante/.virtualenvs/prj/site-packages/django/contrib/admin/sites.py" in has_permission
  148.         return request.user.is_active and request.user.is_staff
File "/Users/Ante/.virtualenvs/prj/site-packages/django/contrib/auth/middleware.py" in __get__
  9.             request._cached_user = get_user(request)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/contrib/auth/__init__.py" in get_user
  110.         user = backend.get_user(user_id) or AnonymousUser()
File "/Users/Ante/.virtualenvs/prj/site-packages/django/contrib/auth/backends.py" in get_user
  63.             return User.objects.get(pk=user_id)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/models/manager.py" in get
  132.         return self.get_query_set().get(*args, **kwargs)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/models/query.py" in get
  344.         num = len(clone)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/models/query.py" in __len__
  82.                 self._result_cache = list(self.iterator())
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/models/query.py" in iterator
  273.         for row in compiler.results_iter():
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/models/sql/compiler.py" in results_iter
  680.         for rows in self.execute_sql(MULTI):
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/models/sql/compiler.py" in execute_sql
  735.         cursor.execute(sql, params)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/backends/util.py" in execute
  34.             return self.cursor.execute(sql, params)
File "/Users/Ante/.virtualenvs/prj/site-packages/django/db/backends/sqlite3/base.py" in execute
  234.             return Database.Cursor.execute(self, query, params)
File "/Users/Ante/Python/pypy-1.6/lib_pypy/_sqlite3.py" in execute
  711.         self.statement = Statement(self, sql, self.row_factory)
File "/Users/Ante/Python/pypy-1.6/lib_pypy/_sqlite3.py" in __init__
  904.             raise Warning, "One and only one statement required"

Exception Type: Warning at /admin/
Exception Value: One and only one statement required

----------
messages: 3184
nosy: nikuda, pypy-issue
priority: bug
status: unread
title: Django/SQLite3 - 'One and only one statement required' Warning

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

From tracker at bugs.pypy.org  Sun Sep 25 08:57:20 2011
From: tracker at bugs.pypy.org (Ante)
Date: Sun, 25 Sep 2011 06:57:20 +0000
Subject: [pypy-issue] [issue881] Django - Fails to load dev server with
	autoreload
In-Reply-To: <1316933840.5.0.454405632501.issue881@bugs.pypy.org>
Message-ID: <1316933840.5.0.454405632501.issue881@bugs.pypy.org>


New submission from Ante <nikuda at gmail.com>:

PyPy 1.6 under virtualenv

'python manage.py runserver --noload' works.

'python manage.py runserver' fails with the following:

Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
Validating models...

  File "manage.py", line 14, in <module>
    execute_manager(settings)
  File "/Users/Ante/.virtualenvs/prj/site-
packages/django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "/Users/Ante/.virtualenvs/prj/site-
packages/django/core/management/__init__.py", line 379, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/Ante/.virtualenvs/prj/site-packages/django/core/management/base.py", 
line 191, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Users/Ante/.virtualenvs/prj/site-packages/django/core/management/base.py", 
line 220, in execute
    output = self.handle(*args, **options)
  File "/Users/Ante/.virtualenvs/prj/site-
packages/django/core/management/commands/runserver.py", line 67, in handle
    self.run(*args, **options)
  File "/Users/Ante/.virtualenvs/prj/site-
packages/django/core/management/commands/runserver.py", line 76, in run
    autoreload.main(self.inner_run, args, options)
  File "/Users/Ante/.virtualenvs/prj/site-packages/django/utils/autoreload.py", line 
138, in main
    reloader(main_func, args, kwargs)
  File "/Users/Ante/.virtualenvs/prj/site-packages/django/utils/autoreload.py", line 
111, in python_reloader
    reloader_thread()
  File "/Users/Ante/.virtualenvs/prj/site-packages/django/utils/autoreload.py", line 
90, in reloader_thread
    ensure_echo_on()
  File "/Users/Ante/.virtualenvs/prj/site-packages/django/utils/autoreload.py", line 
78, in ensure_echo_on
    attr_list = termios.tcgetattr(fd)
TypeError: unsupported operand type for int(): 'file'

----------
messages: 3185
nosy: nikuda, pypy-issue
priority: bug
status: unread
title: Django - Fails to load dev server with autoreload

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

From tracker at bugs.pypy.org  Sun Sep 25 15:20:02 2011
From: tracker at bugs.pypy.org (timo)
Date: Sun, 25 Sep 2011 13:20:02 +0000
Subject: [pypy-issue] [issue877] [patch] implement numpy.random.{rand, randn,
	{set, get}_state, seed, standard_normal}
In-Reply-To: <1316715049.57.0.329936178107.issue877@bugs.pypy.org>
Message-ID: <1316956802.65.0.570043074154.issue877@bugs.pypy.org>


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

in the branch separate-applevel-numpy I split micronumpy into _numpy and numpy, 
in numpy-random, based off of separate-applevel-numpy, I applied the two patches.

closing the bug.

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

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

From tracker at bugs.pypy.org  Mon Sep 26 00:04:48 2011
From: tracker at bugs.pypy.org (Henrik Vendelbo)
Date: Sun, 25 Sep 2011 22:04:48 +0000
Subject: [pypy-issue] [issue882] `import resource` fails
In-Reply-To: <1316988288.39.0.556894974857.issue882@bugs.pypy.org>
Message-ID: <1316988288.39.0.556894974857.issue882@bugs.pypy.org>


New submission from Henrik Vendelbo <henrik at thepia.com>:

`import resource` fails for version 1.6 on Linux

ImportError: No module named _resource_x86_32_

----------
messages: 3187
nosy: pypy-issue, thepian
priority: bug
status: unread
title: `import resource` fails

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

From tracker at bugs.pypy.org  Mon Sep 26 12:04:36 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 26 Sep 2011 10:04:36 +0000
Subject: [pypy-issue] [issue882] `import resource` fails
In-Reply-To: <1316988288.39.0.556894974857.issue882@bugs.pypy.org>
Message-ID: <1317031476.9.0.968970089849.issue882@bugs.pypy.org>


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

Works for me.  The file is in lib_pypy/ctypes_config_cache/_resource_x86_32_.py,
which is present in the binary distribution of pypy 1.6 jit for 32-bit Linux.

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

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

From tracker at bugs.pypy.org  Mon Sep 26 13:44:07 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Mon, 26 Sep 2011 11:44:07 +0000
Subject: [pypy-issue] [issue822] translation issues with openssl >= 1.0.0
In-Reply-To: <1312983210.86.0.828588560028.issue822@bugs.pypy.org>
Message-ID: <1317037447.79.0.756414690649.issue822@bugs.pypy.org>


Piotr Skamruk <piotr.skamruk at gmail.com> added the comment:

not exactly fixed. on which system did you tested this?
under debian sid, and under ubuntu 11.10 i have:



[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-default-2/platcheck_25.c -o /tmp/usession-default-
2/platcheck_25.o
[platform:Error] /tmp/usession-default-2/platcheck_25.c: In function 
?dump_section_OPENSSL_NO_SSL2?:
[platform:Error] /tmp/usession-default-2/platcheck_25.c:84:7: error: expected 
expression before ?)? token
[platform:Error] /tmp/usession-default-2/platcheck_25.c:85:32: error: expected 
expression before ?)? token
[platform:Error] /tmp/usession-default-2/platcheck_25.c:88:50: error: expected 
expression before ?)? token
[platform:Error] /tmp/usession-default-2/platcheck_25.c: In function 
?dump_section_SSLEAY_VERSION?:
[platform:Error] /tmp/usession-default-2/platcheck_25.c:109:12: warning: 
initialization discards ?const? qualifier from pointer target type [enabled by 
default]
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-default-2/platcheck_26.c -o /tmp/usession-default-
2/platcheck_26.o
[platform:Error] /tmp/usession-default-2/platcheck_26.c: In function 
?dump_section_OPENSSL_NO_SSL2?:
[platform:Error] /tmp/usession-default-2/platcheck_26.c:84:7: error: expected 
expression before ?)? token
[platform:Error] /tmp/usession-default-2/platcheck_26.c:85:32: error: expected 
expression before ?)? token
[platform:Error] /tmp/usession-default-2/platcheck_26.c:88:50: error: expected 
expression before ?)? token
[platform:Error] /tmp/usession-default-2/platcheck_26.c: In function 
?dump_section_SSLEAY_VERSION?:
[platform:Error] /tmp/usession-default-2/platcheck_26.c:109:12: warning: 
initialization discards ?const? qualifier from pointer target type [enabled by 
default]

and later:

[translation:WARNING] The module '_hashlib' is disabled
[translation:WARNING] because importing pypy.module._ssl.interp_ssl raised 
CompilationError
[translation:WARNING] CompilationError(err="""
[translation:WARNING] 	/tmp/usession-default-3/platcheck_25.c: In function 
?dump_section_OPENSSL_NO_SSL2?:
[translation:WARNING] 	/tmp/usession-default-3/platcheck_25.c:84:7: error: 
expected expression before ?)? token
[translation:WARNING] 	/tmp/usession-default-3/platcheck_25.c:85:32: error: 
expected expression before ?)? token
[translation:WARNING] 	/tmp/usession-default-3/platcheck_25.c:88:50: error: 
expected expression before ?)? token
[translation:WARNING] 	/tmp/usession-default-3/platcheck_25.c: In function 
?dump_section_SSLEAY_VERSION?:
[translation:WARNING] 	/tmp/usession-default-3/platcheck_25.c:109:12: warning: 
initialization discards ?const? qualifier from pointer target type [enabled by 
default]
[translation:WARNING] 	""")
[translation:WARNING] The module '_ssl' is disabled
[translation:WARNING] because importing pypy.module._ssl.interp_ssl raised 
CompilationError
[translation:WARNING] CompilationError(err="""
[translation:WARNING] 	/tmp/usession-default-3/platcheck_26.c: In function 
?dump_section_OPENSSL_NO_SSL2?:
[translation:WARNING] 	/tmp/usession-default-3/platcheck_26.c:84:7: error: 
expected expression before ?)? token
[translation:WARNING] 	/tmp/usession-default-3/platcheck_26.c:85:32: error: 
expected expression before ?)? token
[translation:WARNING] 	/tmp/usession-default-3/platcheck_26.c:88:50: error: 
expected expression before ?)? token
[translation:WARNING] 	/tmp/usession-default-3/platcheck_26.c: In function 
?dump_section_SSLEAY_VERSION?:
[translation:WARNING] 	/tmp/usession-default-3/platcheck_26.c:109:12: warning: 
initialization discards ?const? qualifier from pointer target type [enabled by 
default]
[translation:WARNING] 	""")

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

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

From tracker at bugs.pypy.org  Mon Sep 26 13:52:40 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 26 Sep 2011 11:52:40 +0000
Subject: [pypy-issue] [issue881] Django - Fails to load dev server with
	autoreload
In-Reply-To: <1316933840.5.0.454405632501.issue881@bugs.pypy.org>
Message-ID: <1317037960.09.0.422293541833.issue881@bugs.pypy.org>


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

This was fixed in 9d4eac09ef21

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

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

From tracker at bugs.pypy.org  Mon Sep 26 13:56:57 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Mon, 26 Sep 2011 11:56:57 +0000
Subject: [pypy-issue] [issue822] translation issues with openssl >= 1.0.0
In-Reply-To: <1312983210.86.0.828588560028.issue822@bugs.pypy.org>
Message-ID: <1317038217.47.0.955144075635.issue822@bugs.pypy.org>


Piotr Skamruk <piotr.skamruk at gmail.com> added the comment:

Little patch which works for me:

diff -r 99eb704c3dd1 pypy/rlib/ropenssl.py
--- a/pypy/rlib/ropenssl.py	Sat Sep 24 13:45:47 2011 +0200
+++ b/pypy/rlib/ropenssl.py	Mon Sep 26 13:55:03 2011 +0200
@@ -62,7 +62,7 @@
         "OPENSSL_VERSION_NUMBER")
     SSLEAY_VERSION = rffi_platform.DefinedConstantString(
         "SSLEAY_VERSION", "SSLeay_version(SSLEAY_VERSION)")
-    OPENSSL_NO_SSL2 = rffi_platform.DefinedConstantInteger(
+    OPENSSL_NO_SSL2 = rffi_platform.Defined(
         "OPENSSL_NO_SSL2")
     SSL_FILETYPE_PEM = rffi_platform.ConstantInteger("SSL_FILETYPE_PEM")
     SSL_OP_ALL = rffi_platform.ConstantInteger("SSL_OP_ALL")

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

From tracker at bugs.pypy.org  Tue Sep 27 01:05:07 2011
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Mon, 26 Sep 2011 23:05:07 +0000
Subject: [pypy-issue] [issue883] 'SemLock' object has no attribute
	'_after_fork'
In-Reply-To: <1317078307.16.0.037196563245.issue883@bugs.pypy.org>
Message-ID: <1317078307.16.0.037196563245.issue883@bugs.pypy.org>


New submission from Kostya Rybnikov <k.bx at ya.ru>:

Celery writes on start with pypy: after forker raised exception 'SemLock' object
has no attribute '_after_fork'

I will try to dig into to get as much info as possible later.

----------
messages: 3192
nosy: k_bx, pypy-issue
priority: bug
status: unread
title: 'SemLock' object has no attribute '_after_fork'

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

From tracker at bugs.pypy.org  Tue Sep 27 04:31:45 2011
From: tracker at bugs.pypy.org (Ante)
Date: Tue, 27 Sep 2011 02:31:45 +0000
Subject: [pypy-issue] [issue880] Django/SQLite3 - 'One and only one
	statement required'	Warning
In-Reply-To: <1316926620.11.0.498276554023.issue880@bugs.pypy.org>
Message-ID: <1317090705.05.0.985345514945.issue880@bugs.pypy.org>


Ante <nikuda at gmail.com> added the comment:

Seems to be working fine in PyPy nightly 3d8b5c3c699e.

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

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

From tracker at bugs.pypy.org  Tue Sep 27 08:55:29 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 27 Sep 2011 06:55:29 +0000
Subject: [pypy-issue] [issue883] 'SemLock' object has no attribute
	'_after_fork'
In-Reply-To: <1317078307.16.0.037196563245.issue883@bugs.pypy.org>
Message-ID: <1317106529.72.0.0590687078215.issue883@bugs.pypy.org>


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

Right, _multiprocessing.SemLock should have _after_fork(). In CPython it simply 
resets self->count to zero, and can be implemented trivially in 
pypy/module/_multiprocessing/interp_semaphore.py.

test_multiprocessing is skipped these days, but it's odd that it never displayed 
this error (maybe because _after_fork is called in a subprocess).

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

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

From tracker at bugs.pypy.org  Tue Sep 27 21:04:50 2011
From: tracker at bugs.pypy.org (Michael Schurter)
Date: Tue, 27 Sep 2011 19:04:50 +0000
Subject: [pypy-issue] [issue869] Implement ctypes.<type>.from_buffer method
In-Reply-To: <1315674477.29.0.889845043655.issue869@bugs.pypy.org>
Message-ID: <1317150290.58.0.682288230958.issue869@bugs.pypy.org>


Michael Schurter <m at schmichael.com> added the comment:

from_buffer is useful for more than just tests. They allow you to create ctypes
in, for example, memory mapped buffers for sharing between processes.

I've been using this feature extensively in a metrics/monitoring library I've
been working on and would love for it to be supported in PyPy (I went with
ctypes instead of C or Cython in hopes of getting "free" PyPy support from the
beginning).

https://github.com/schmichael/mmstats
http://schmichael.github.com/mmstats-talk/

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

From tracker at bugs.pypy.org  Tue Sep 27 21:05:27 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 27 Sep 2011 19:05:27 +0000
Subject: [pypy-issue] [issue869] Implement ctypes.<type>.from_buffer method
In-Reply-To: <1315674477.29.0.889845043655.issue869@bugs.pypy.org>
Message-ID: <1317150327.29.0.144314255505.issue869@bugs.pypy.org>


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

He wasn't saying it's only useful in tests, just that we don't have it because we 
skip too many tests ATM.

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

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

From tracker at bugs.pypy.org  Tue Sep 27 22:06:22 2011
From: tracker at bugs.pypy.org (timo)
Date: Tue, 27 Sep 2011 20:06:22 +0000
Subject: [pypy-issue] [issue864] numpy: initialize empty/zeros/ones with a
	tuple as size	argument - with test
In-Reply-To: <1315358633.32.0.31400648599.issue864@bugs.pypy.org>
Message-ID: <1317153982.96.0.363897377376.issue864@bugs.pypy.org>


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

these changes are now on the "separate-applevel-numpy" branch, awaiting review 
and merge.

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

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

From tracker at bugs.pypy.org  Tue Sep 27 22:07:43 2011
From: tracker at bugs.pypy.org (timo)
Date: Tue, 27 Sep 2011 20:07:43 +0000
Subject: [pypy-issue] [issue862] patch for implementing numpy.bincount (at
	applevel)
In-Reply-To: <1315177979.5.0.587724497271.issue862@bugs.pypy.org>
Message-ID: <1317154063.94.0.351720436675.issue862@bugs.pypy.org>


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

committed to "separate-applevel-numpy", awaiting review and merge.

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

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

From tracker at bugs.pypy.org  Tue Sep 27 23:47:06 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 27 Sep 2011 21:47:06 +0000
Subject: [pypy-issue] [issue822] translation issues with openssl >= 1.0.0
In-Reply-To: <1312983210.86.0.828588560028.issue822@bugs.pypy.org>
Message-ID: <1317160026.02.0.486946063403.issue822@bugs.pypy.org>


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

fixed in 0bc632abd204

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

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

From tracker at bugs.pypy.org  Tue Sep 27 23:50:02 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 27 Sep 2011 21:50:02 +0000
Subject: [pypy-issue] [issue883] 'SemLock' object has no attribute
	'_after_fork'
In-Reply-To: <1317078307.16.0.037196563245.issue883@bugs.pypy.org>
Message-ID: <1317160202.9.0.377695807658.issue883@bugs.pypy.org>


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

Implemented in dbe24f2e28bc
Actually if you add a logging handler in test_multiprocessing, this message 
appears every other line.  It's even possible that this fix will unblock 
test_multiprocessing.
Thanks a lot for the report!

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

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

From tracker at bugs.pypy.org  Wed Sep 28 04:14:21 2011
From: tracker at bugs.pypy.org (David Beazley)
Date: Wed, 28 Sep 2011 02:14:21 +0000
Subject: [pypy-issue] [issue884] Diabolical Multicore Thread Performance
In-Reply-To: <1317176061.39.0.582537402848.issue884@bugs.pypy.org>
Message-ID: <1317176061.39.0.582537402848.issue884@bugs.pypy.org>


New submission from David Beazley <dave at dabeaz.com>:

This problem is pretty easy to recreate.   I'm using pypy-1.6.

1. Go find a multicore machine with 4 or more cores (e.g., a 4-core MacBook Pro,
or 8-core Amazon EC2 Linux instance).

2. Launch pypy and spin up a single CPU-bound thread.

>>>> def spinner()
....     n = 0
....     while True:
....         n += 1
....
>>>> import threading
>>>> t = threading.Thread(target=spinner)
>>>> t.daemon=True
>>>> t.start()
>>>>

3. Sit back and observe that the interactive interpreter (and just about
everything else related to I/O) is so slow as to be nearly unresponsive (try
doing some things at the prompt).

The responsiveness gets significantly worse if the number of cores is increased.
 For example, I've been running some socket I/O benchmarks where I/O is mixed
with a *single* CPU-bound thread.  If there is a single CPU core, code runs in
about 0.05s.  With 4 cores+hyperthreading, the *same* test runs in 730s (a
slowdown of about 14600x).   The specifics of this test aren't so
interesting--you can easily observe a huge slowdown just by launching a thread
and trying to use the interactive prompt.

What's the cause?  I have no idea except that my machine does not appear to be
wildly thrashing (e.g., having a GIL battle).  Good luck ;-).

----------
assignedto: agaynor
messages: 3201
nosy: agaynor, dabeaz, pypy-issue
priority: bug
release: ???
status: unread
title: Diabolical Multicore Thread Performance

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

From tracker at bugs.pypy.org  Wed Sep 28 04:14:40 2011
From: tracker at bugs.pypy.org (anon)
Date: Wed, 28 Sep 2011 02:14:40 +0000
Subject: [pypy-issue] [issue885] Lack of libffi5 on Ubuntu 11.10 stops PyPy
	running
In-Reply-To: <1317176080.11.0.207082241886.issue885@bugs.pypy.org>
Message-ID: <1317176080.11.0.207082241886.issue885@bugs.pypy.org>


New submission from anon <b10419697 at klzlk.com>:

On Ubuntu 11.10 (Beta 2) when I try to run PyPy 1.6 or an in-development PyPy
build I get the following error:

error while loading shared libraries libffi.so.5: cannot open shared object
file: No such file or directory

PyPy runs happily on Ubuntu 11.04 however. The problem seems to be that Ubuntu
11.10 provides the newer version of the library as libffi.so.6 (corresponding to
the package libffi6 on Ubuntu 11.10) while PyPy links to libffi.so.5
(corresponding to the package libffi5 on Ubuntu 11.04).

Please ask if there's any further information I can provide.

----------
messages: 3202
nosy: anon, pypy-issue
priority: bug
status: unread
title: Lack of libffi5 on Ubuntu 11.10 stops PyPy running

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

From tracker at bugs.pypy.org  Wed Sep 28 04:35:08 2011
From: tracker at bugs.pypy.org (anon)
Date: Wed, 28 Sep 2011 02:35:08 +0000
Subject: [pypy-issue] [issue873] PyPy almost 300 times slower in recursive
	AST evaluation
In-Reply-To: <1316366032.78.0.118026987379.issue873@bugs.pypy.org>
Message-ID: <1317177308.53.0.70001757781.issue873@bugs.pypy.org>


anon <b10419697 at klzlk.com> added the comment:

It also produces a segfault when run with CPython 2.7 if the value on line 75 is
increased. It's worth noting that PyPy, unlike CPython, uses a huge amount of
memory too.

The program essentially creates an AST representing the recursive function f(x)
-> 1 if x<1 else f(x-1)+2. Each Node on the tree is stored as a list with the
first value the function and the other values the arguments. It's actually a
greatly simplified version of real code.

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

From tracker at bugs.pypy.org  Wed Sep 28 08:20:17 2011
From: tracker at bugs.pypy.org (Andrew Mahone)
Date: Wed, 28 Sep 2011 06:20:17 +0000
Subject: [pypy-issue] [issue886] unicode.translate behavior differs from
	CPython
In-Reply-To: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>
Message-ID: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>


New submission from Andrew Mahone <andrew.mahone at gmail.com>:

CPython's unicode.translate will actually work with lists, tuples, and strings
as well as dicts, retaining the advertised behavior with regard to elements not
in the translation mapping. On pypy, if an exception other than KeyError is
raised on lookup, translate raises an exception, rather than leaving the
character unchanged. This patch adds a test for the CPython behavior, and fixes
it by treating IndexError on lookup identically to KeyError.

----------
files: unicode_translate.patch
messages: 3204
nosy: pypy-issue
priority: bug
status: unread
title: unicode.translate behavior differs from CPython

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

From tracker at bugs.pypy.org  Wed Sep 28 08:57:08 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 28 Sep 2011 06:57:08 +0000
Subject: [pypy-issue] [issue886] unicode.translate behavior differs from
	CPython
In-Reply-To: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>
Message-ID: <1317193028.27.0.574769197349.issue886@bugs.pypy.org>


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

CPython catches LookupError instead (the common base class for KeyError and 
IndexError):
http://hg.python.org/cpython/file/8527427914a2/Objects/unicodeobject.c#l4849

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

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

From tracker at bugs.pypy.org  Wed Sep 28 09:05:23 2011
From: tracker at bugs.pypy.org (Andrew Mahone)
Date: Wed, 28 Sep 2011 07:05:23 +0000
Subject: [pypy-issue] [issue886] unicode.translate behavior differs from
	CPython
In-Reply-To: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>
Message-ID: <1317193523.39.0.960329014582.issue886@bugs.pypy.org>


Andrew Mahone <andrew.mahone at gmail.com> added the comment:

Thanks, I hadn't thought to look at CPython, or that it would be all that clear
what it did in C. using a single test vs w_LookupError works in the test on
py.py, I'm translating it now to make sure that is not a problem.

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

From tracker at bugs.pypy.org  Wed Sep 28 10:18:49 2011
From: tracker at bugs.pypy.org (Andrew Mahone)
Date: Wed, 28 Sep 2011 08:18:49 +0000
Subject: [pypy-issue] [issue886] unicode.translate behavior differs from
	CPython
In-Reply-To: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>
Message-ID: <1317197929.99.0.119761495217.issue886@bugs.pypy.org>


Andrew Mahone <andrew.mahone at gmail.com> added the comment:

Reworked patch using w_LookupError.

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

From tracker at bugs.pypy.org  Wed Sep 28 10:23:16 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 28 Sep 2011 08:23:16 +0000
Subject: [pypy-issue] [issue886] unicode.translate behavior differs from
	CPython
In-Reply-To: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>
Message-ID: <1317198196.3.0.657072078685.issue886@bugs.pypy.org>


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

You didn't upload the correct patch :-)

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

From tracker at bugs.pypy.org  Wed Sep 28 10:31:56 2011
From: tracker at bugs.pypy.org (Andrew Mahone)
Date: Wed, 28 Sep 2011 08:31:56 +0000
Subject: [pypy-issue] [issue886] unicode.translate behavior differs from
	CPython
In-Reply-To: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>
Message-ID: <1317198716.63.0.671488816768.issue886@bugs.pypy.org>


Andrew Mahone <andrew.mahone at gmail.com> added the comment:

Second patch corrected.

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

From tracker at bugs.pypy.org  Wed Sep 28 10:58:15 2011
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Wed, 28 Sep 2011 08:58:15 +0000
Subject: [pypy-issue] [issue883] 'SemLock' object has no attribute
	'_after_fork'
In-Reply-To: <1317078307.16.0.037196563245.issue883@bugs.pypy.org>
Message-ID: <1317200295.6.0.297368713604.issue883@bugs.pypy.org>


Kostya Rybnikov <k.bx at ya.ru> added the comment:

@afa always welcome :-)

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

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

From tracker at bugs.pypy.org  Wed Sep 28 13:37:50 2011
From: tracker at bugs.pypy.org (David Beazley)
Date: Wed, 28 Sep 2011 11:37:50 +0000
Subject: [pypy-issue] [issue884] Diabolical Multicore Thread Performance
In-Reply-To: <1317176061.39.0.582537402848.issue884@bugs.pypy.org>
Message-ID: <1317209870.3.0.472389346648.issue884@bugs.pypy.org>


David Beazley <dave at dabeaz.com> added the comment:

Attached is some benchmark code that can demonstrate the problem with some
socket messaging.

Run the program 'receiver.py' in one process.  Go to another process and run the
program 'sender.py'  (e.g., python sender.py 1000 1024) to blast messages at it.
 Again, the more cores, the worse it gets.

I get similar behavior on both OS-X (both on a quad-core MacPro and MacBook Pro)
and on Linux (8-core Amazon EC2 c1.xlarge instance).

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

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

From tracker at bugs.pypy.org  Wed Sep 28 21:09:15 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 28 Sep 2011 19:09:15 +0000
Subject: [pypy-issue] [issue886] unicode.translate behavior differs from
	CPython
In-Reply-To: <1317190817.8.0.900454615392.issue886@bugs.pypy.org>
Message-ID: <1317236955.91.0.958525534165.issue886@bugs.pypy.org>


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

applied in f1491c2aa43b, thanks a lot!

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

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

From tracker at bugs.pypy.org  Thu Sep 29 04:40:50 2011
From: tracker at bugs.pypy.org (Nam Nguyen)
Date: Thu, 29 Sep 2011 02:40:50 +0000
Subject: [pypy-issue] [issue887] PIL image access object produces a crash
	with	NotImplementedError
In-Reply-To: <1317264050.69.0.43418639226.issue887@bugs.pypy.org>
Message-ID: <1317264050.69.0.43418639226.issue887@bugs.pypy.org>


New submission from Nam Nguyen <namn at bluemoon.com.vn>:

Python Imaging Library (PIL) recommends using an access object (returned from 
Image.load method) to set/get pixel data. This works fine in CPython. In PyPy, 
however, it produces a crash.

>>>> import Image
>>>> img = Image.new('RGB', (288, 192))
>>>> access = img.load()
>>>> access[(0, 0)] = (255, 255, 255)
RPython traceback:
  File "interpreter_gateway.c", line 1264, in 
BuiltinCodePassThroughArguments1_funcrun_obj
  File "module_cpyext_slotdefs.c", line 5065, in wrap_objobjargproc
Fatal RPython error: NotImplementedError
Aborted

The slower approach (via Image.putpixel) runs fine:

>>>> import Image
>>>> img = Image.new('RGB', (288, 192))
>>>> img.putpixel((0, 0), (255, 255, 255))
>>>> quit()

I understand that PIL is mostly C but maybe this has something to do with PyPy 
too.

----------
messages: 3213
nosy: namn, pypy-issue
priority: wish
status: unread
title: PIL image access object produces a crash with NotImplementedError

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

From tracker at bugs.pypy.org  Thu Sep 29 05:14:04 2011
From: tracker at bugs.pypy.org (Nam Nguyen)
Date: Thu, 29 Sep 2011 03:14:04 +0000
Subject: [pypy-issue] [issue887] PIL image access object produces a crash
	with	NotImplementedError
In-Reply-To: <1317264050.69.0.43418639226.issue887@bugs.pypy.org>
Message-ID: <1317266044.92.0.805225205128.issue887@bugs.pypy.org>


Nam Nguyen <namn at bluemoon.com.vn> added the comment:

This is indeed a problem in PyPy.

wrap_objobjargproc is not implemented for __setitem__ slot.

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

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

From tracker at bugs.pypy.org  Thu Sep 29 10:13:59 2011
From: tracker at bugs.pypy.org (ayanamist)
Date: Thu, 29 Sep 2011 08:13:59 +0000
Subject: [pypy-issue] [issue888] json module in pypy is much more lower than
	cpython
In-Reply-To: <1317284039.94.0.390923902277.issue888@bugs.pypy.org>
Message-ID: <1317284039.94.0.390923902277.issue888@bugs.pypy.org>


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

You can see more detail here: https://gist.github.com/1250244
I just use and modify the benchmark.py from ujson, running it in my virtual 
machine.
File "environment" tells my machine.
File "benchmark.py" is the one i modified from ujson
File "result-pypy" and "result-python" are the results.
It's much slower.
I hope you guys can speed up.

----------
messages: 3215
nosy: ayanamist, pypy-issue
priority: wish
status: unread
title: json module in pypy is much more lower than cpython

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

From tracker at bugs.pypy.org  Thu Sep 29 12:35:17 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 29 Sep 2011 10:35:17 +0000
Subject: [pypy-issue] [issue884] Diabolical Multicore Thread Performance
In-Reply-To: <1317176061.39.0.582537402848.issue884@bugs.pypy.org>
Message-ID: <1317292517.78.0.121659924282.issue884@bugs.pypy.org>


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

I played with improving the GIL and found that (at least on pthread) the
following solution gives the best result:

https://bitbucket.org/arigo/arigo/raw/default/hack/stm/misc/howto-gil.c

It is also extremely simple, unlike CPython that is struggling with making its
GIL more and more complicated.  Needs to be tested in PyPy first though.

The goal was that every 'checkinterval' steps we yield in such a way that it
will force another thread to run; as opposed to when releasing/acquiring the GIL
around an external call, where we yield in such a way that preferably the same
thread will re-acquire the GIL immediately.  So far, the solution implemented in
PyPy uses the second kind of yields for every case, which means that a
CPU-intensive thread will tend to keep the GIL for long periods of time.

The result of the above experimental program is that with one or several threads
consuming CPU time and one or several thread doing I/O, the CPU-intensive
threads tend to round-robin every 'checkinterval' step, interleaved with bursts
of uninterrupted I/O code from the same thread.

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

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

From tracker at bugs.pypy.org  Thu Sep 29 13:02:33 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 29 Sep 2011 11:02:33 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1317294153.79.0.292987521691.issue866@bugs.pypy.org>


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

I'm closing this. Faster-isinstance branch brought 0.2s (on tannit), which is 
still not as good as CPython, but it's not much slower. Feel free to reopen if 
you have more ideas how to improve

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

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

From tracker at bugs.pypy.org  Thu Sep 29 13:04:04 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 29 Sep 2011 11:04:04 +0000
Subject: [pypy-issue] [issue885] Lack of libffi5 on Ubuntu 11.10 stops PyPy
	running
In-Reply-To: <1317176080.11.0.207082241886.issue885@bugs.pypy.org>
Message-ID: <1317294244.66.0.861862814519.issue885@bugs.pypy.org>


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

I fear this is not-a-bug. We can't ship all combinations of binary builds for 
each platform, binary compatibility on linux is hard. Ideally ubuntu should ship 
it's own pypy that works. Closing as won't fix, sorry :/

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

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

From tracker at bugs.pypy.org  Thu Sep 29 13:14:42 2011
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Thu, 29 Sep 2011 11:14:42 +0000
Subject: [pypy-issue] [issue866] [PATCH] join is slow about 2x slower than
	Python
In-Reply-To: <1315461531.27.0.58792221009.issue866@bugs.pypy.org>
Message-ID: <1317294882.84.0.120349672588.issue866@bugs.pypy.org>


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

A nice way to improve str.join is possible on the list-strategies branch: The
list argument of join is typically a list of strings, which you then don't need
to unwrap if you add a new objspace interface listview_str or something.

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

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

From tracker at bugs.pypy.org  Thu Sep 29 13:14:52 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 29 Sep 2011 11:14:52 +0000
Subject: [pypy-issue] [issue885] Lack of libffi5 on Ubuntu 11.10 stops PyPy
	running
In-Reply-To: <1317176080.11.0.207082241886.issue885@bugs.pypy.org>
Message-ID: <1317294892.24.0.160921482748.issue885@bugs.pypy.org>


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

Actually for libffi there is already a solution used on some platforms (but not
all): compile the necessary code into pypy with libffi.a, instead of relying on
libffi.so.N.  I think it was disabled on Linux because there you typically don't
have a libffi.a at all even in libffi-dev packages.  What we could do is make
sure that libffi.a is present on our own Linux development machines, and during
translation always prefer libffi.a over libffi.so if present...

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

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

From tracker at bugs.pypy.org  Thu Sep 29 19:58:38 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 29 Sep 2011 17:58:38 +0000
Subject: [pypy-issue] [issue887] PIL image access object produces a crash
	with	NotImplementedError
In-Reply-To: <1317264050.69.0.43418639226.issue887@bugs.pypy.org>
Message-ID: <1317319118.6.0.61891611013.issue887@bugs.pypy.org>


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

The attached diff fixes the problem, but I'm not sure how to add a test for this. 
Do we need more tests dealing with buffers?

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

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

From tracker at bugs.pypy.org  Fri Sep 30 17:12:21 2011
From: tracker at bugs.pypy.org (Jean-Paul Calderone)
Date: Fri, 30 Sep 2011 15:12:21 +0000
Subject: [pypy-issue] [issue889] Windows binary distribution is missing
	cpyext header files
In-Reply-To: <1317395541.31.0.735873324924.issue889@bugs.pypy.org>
Message-ID: <1317395541.31.0.735873324924.issue889@bugs.pypy.org>


New submission from Jean-Paul Calderone <exarkun at twistedmatrix.com>:

Without the cpyext header files, extension modules can't be built.

----------
messages: 3222
nosy: calderone, pypy-issue
priority: bug
status: unread
title: Windows binary distribution is missing cpyext header files

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

From tracker at bugs.pypy.org  Fri Sep 30 18:23:15 2011
From: tracker at bugs.pypy.org (Jean-Paul Calderone)
Date: Fri, 30 Sep 2011 16:23:15 +0000
Subject: [pypy-issue] [issue889] Windows binary distribution is missing
	cpyext header files
In-Reply-To: <1317395541.31.0.735873324924.issue889@bugs.pypy.org>
Message-ID: <1317399795.9.0.224442749084.issue889@bugs.pypy.org>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

This seems to affect binary distributions on other platforms as well.

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

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