From tracker at bugs.pypy.org  Mon Aug  1 12:37:24 2011
From: tracker at bugs.pypy.org (yanolab)
Date: Mon, 01 Aug 2011 10:37:24 +0000
Subject: [pypy-issue] [issue817] Different GC collecting specification to
	CPython
In-Reply-To: <1312195044.7.0.932180556135.issue817@bugs.pypy.org>
Message-ID: <1312195044.7.0.932180556135.issue817@bugs.pypy.org>


New submission from yanolab <kenji.yano at gmail.com>:

Pypy has a different GC specification to CPython.

quote from pypy-dev at ml:
The difference with CPython is that CPython destroys the object as soon as it 
forgets the last reference to the object (and thus it is deterministic), while 
on PyPy the objects are destroyed only the the GC runs (which is not 
deterministic).

----------
messages: 2896
nosy: pypy-issue, yanolab
priority: wish
status: chatting
title: Different GC collecting specification to CPython

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

From tracker at bugs.pypy.org  Mon Aug  1 12:38:37 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 01 Aug 2011 10:38:37 +0000
Subject: [pypy-issue] [issue817] Different GC collecting specification to
	CPython
In-Reply-To: <1312195044.7.0.932180556135.issue817@bugs.pypy.org>
Message-ID: <1312195117.36.0.726378403572.issue817@bugs.pypy.org>


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

I don't understand why a bug was filed?  This isn't a bug, this is life, 
deterministic collection is *not* a feature of the Python language.

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

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

From tracker at bugs.pypy.org  Mon Aug  1 12:44:24 2011
From: tracker at bugs.pypy.org (yanolab)
Date: Mon, 01 Aug 2011 10:44:24 +0000
Subject: [pypy-issue] [issue817] Different GC collecting specification to
	CPython
In-Reply-To: <1312195044.7.0.932180556135.issue817@bugs.pypy.org>
Message-ID: <1312195464.2.0.0751458262623.issue817@bugs.pypy.org>


yanolab <kenji.yano at gmail.com> added the comment:

yes, I think this is not bug, too.
but, there is compatibility problem.
if this is no problem, remove this issue.

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

From tracker at bugs.pypy.org  Mon Aug  1 12:51:36 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 01 Aug 2011 10:51:36 +0000
Subject: [pypy-issue] [issue817] Different GC collecting specification to
	CPython
In-Reply-To: <1312195044.7.0.932180556135.issue817@bugs.pypy.org>
Message-ID: <1312195896.51.0.787253157993.issue817@bugs.pypy.org>


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

http://doc.pypy.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies

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

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

From tracker at bugs.pypy.org  Mon Aug  1 13:02:58 2011
From: tracker at bugs.pypy.org (yanolab)
Date: Mon, 01 Aug 2011 11:02:58 +0000
Subject: [pypy-issue] [issue817] Different GC collecting specification to
	CPython
In-Reply-To: <1312195044.7.0.932180556135.issue817@bugs.pypy.org>
Message-ID: <1312196578.31.0.144321038007.issue817@bugs.pypy.org>


yanolab <kenji.yano at gmail.com> added the comment:

thanks agaynor,arigo

I think this ticket close.

----------
status: wontfix -> invalid

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

From tracker at bugs.pypy.org  Wed Aug  3 07:22:05 2011
From: tracker at bugs.pypy.org (Didip Kerabat)
Date: Wed, 03 Aug 2011 05:22:05 +0000
Subject: [pypy-issue] [issue818] MySQLdb-python 1.2.3 segmentation fault on
	PyPy 1.5 OSX	64bit
In-Reply-To: <1312348925.51.0.409461052367.issue818@bugs.pypy.org>
Message-ID: <1312348925.51.0.409461052367.issue818@bugs.pypy.org>


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

I'm not sure if this would help, but I documented the crash report here:
https://gist.github.com/1120902

----------
messages: 2901
nosy: didip, pypy-issue
priority: bug
status: unread
title: MySQLdb-python 1.2.3 segmentation fault on PyPy 1.5 OSX 64bit

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

From tracker at bugs.pypy.org  Wed Aug  3 14:07:13 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 03 Aug 2011 12:07:13 +0000
Subject: [pypy-issue] [issue775] bm_mako got slower
In-Reply-To: <1309679036.24.0.307631636135.issue775@bugs.pypy.org>
Message-ID: <1312373233.04.0.134871715419.issue775@bugs.pypy.org>


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

Closing as noise

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

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

From tracker at bugs.pypy.org  Wed Aug  3 14:07:24 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 03 Aug 2011 12:07:24 +0000
Subject: [pypy-issue] [issue814] Appending string is slower than cpython
In-Reply-To: <1311891825.05.0.98767349744.issue814@bugs.pypy.org>
Message-ID: <1312373244.51.0.677458038364.issue814@bugs.pypy.org>


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

Closing, not a bug

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

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

From tracker at bugs.pypy.org  Thu Aug  4 22:10:34 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 04 Aug 2011 20:10:34 +0000
Subject: [pypy-issue] [issue813] Random is slower than cpython
In-Reply-To: <1311891404.35.0.986785735677.issue813@bugs.pypy.org>
Message-ID: <1312488634.18.0.487544265289.issue813@bugs.pypy.org>


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

Closing this, as JP points out, it's a case of "everythign is a bit slow until 
the JIT happens".

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

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

From tracker at bugs.pypy.org  Fri Aug  5 03:25:50 2011
From: tracker at bugs.pypy.org (anon)
Date: Fri, 05 Aug 2011 01:25:50 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>


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

For instance computing n=3**4000000 takes 1.9s with PyPy but only 1.2s with
CPython. PyPy is slower than CPython in similar ratios for large multiplications.

----------
messages: 2905
nosy: anon, pypy-issue
priority: bug
status: unread
title: Arithmetic is slower than CPython in extreme cases

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

From tracker at bugs.pypy.org  Mon Aug  8 04:04:48 2011
From: tracker at bugs.pypy.org (npforce)
Date: Mon, 08 Aug 2011 02:04:48 +0000
Subject: [pypy-issue] [issue820] ctypes structure._fields_ should accept 3
	tuple
In-Reply-To: <1312769088.62.0.30600658481.issue820@bugs.pypy.org>
Message-ID: <1312769088.62.0.30600658481.issue820@bugs.pypy.org>


New submission from npforce <lesterz at gmail.com>:

The ctypes documentation says that ctypes.Structure._fields_ must be "a sequence 
defining the structure fields. The items must be 2-tuples or 3-tuples."  However, 
the current implementation of ctypes in pypy 1.5 only accepts a 2-tuple.  See 
lib_pypy/_ctypes/structure.py line 92.

----------
messages: 2906
nosy: npforce, pypy-issue
priority: bug
status: unread
title: ctypes structure._fields_ should accept 3 tuple

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

From tracker at bugs.pypy.org  Mon Aug  8 11:59:02 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 08 Aug 2011 09:59:02 +0000
Subject: [pypy-issue] [issue820] ctypes structure._fields_ should accept 3
	tuple
In-Reply-To: <1312769088.62.0.30600658481.issue820@bugs.pypy.org>
Message-ID: <1312797542.45.0.350213354451.issue820@bugs.pypy.org>


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

could you please attach a failing test?

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

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

From tracker at bugs.pypy.org  Mon Aug  8 16:33:00 2011
From: tracker at bugs.pypy.org (npforce)
Date: Mon, 08 Aug 2011 14:33:00 +0000
Subject: [pypy-issue] [issue820] ctypes structure._fields_ should accept 3
	tuple
In-Reply-To: <1312769088.62.0.30600658481.issue820@bugs.pypy.org>
Message-ID: <1312813980.48.0.252554898745.issue820@bugs.pypy.org>


npforce <lesterz at gmail.com> added the comment:

This script works in CPython but not in pypy 1.5. Error message:
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "test.py", line 6, in <module>
    ("normal_int", c_int)]
  File "/usr/local/pypy/lib_pypy/_ctypes/structure.py", line 92, in 
struct_setattr
    if self in [v for k, v in value]:
ValueError: expected length 2, got 3

Obviously, k,v expects a 2-tuple.  For a 3-tuple, it fails.  Note that if the 
_fields_ is defined inside the class, there's no problem.  The problem occurs 
only when _fields_ is added outside class definition.

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

From tracker at bugs.pypy.org  Tue Aug  9 14:51:56 2011
From: tracker at bugs.pypy.org (dag)
Date: Tue, 09 Aug 2011 12:51:56 +0000
Subject: [pypy-issue] [issue821] __debug__ is always True
In-Reply-To: <1312894316.8.0.232369941601.issue821@bugs.pypy.org>
Message-ID: <1312894316.8.0.232369941601.issue821@bugs.pypy.org>


New submission from dag <dag.odenhall at gmail.com>:

Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:34)
[PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2
>>>> sys.flags.optimize, __debug__
(1, True)

----------
messages: 2909
nosy: dag, pypy-issue
priority: bug
release: 1.5
status: unread
title: __debug__ is always True

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

From tracker at bugs.pypy.org  Wed Aug 10 02:30:40 2011
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Wed, 10 Aug 2011 00:30:40 +0000
Subject: [pypy-issue] [issue820] ctypes structure._fields_ should accept 3
	tuple
In-Reply-To: <1312769088.62.0.30600658481.issue820@bugs.pypy.org>
Message-ID: <1312936240.44.0.0266488417203.issue820@bugs.pypy.org>


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

fixed in https://bitbucket.org/pypy/pypy/changeset/420c6c4b14b8

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

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

From tracker at bugs.pypy.org  Wed Aug 10 15:33:30 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Wed, 10 Aug 2011 13:33:30 +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: <1312983210.86.0.828588560028.issue822@bugs.pypy.org>


New submission from Piotr Skamruk <piotr.skamruk at gmail.com>:

head version of pypy does not translate with openssl 1.0.0 in system (debian 
experimental, ubuntu 11.10, probably also others).
openssl has SSLv2 deprecated.
with patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613369 as base i 
did some example solution for pypy, attached there.

----------
files: pypy-ossl.patch
messages: 2911
nosy: jell, pypy-issue
priority: bug
status: unread
title: translation issues with openssl >= 1.0.0

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

From tracker at bugs.pypy.org  Wed Aug 10 16:41:58 2011
From: tracker at bugs.pypy.org (npforce)
Date: Wed, 10 Aug 2011 14:41:58 +0000
Subject: [pypy-issue] [issue823] osx nightly build is not 'nightly'
In-Reply-To: <1312987318.58.0.491767277226.issue823@bugs.pypy.org>
Message-ID: <1312987318.58.0.491767277226.issue823@bugs.pypy.org>


New submission from npforce <lesterz at gmail.com>:

The latest jit build for osx listed on http://buildbot.pypy.org/nightly/trunk/ is:
pypy-c-jit-latest-osx64.tar.bz2	13M	2011-07-12

Linux builds are up to date.  I wish to try out the latest osx build and save the 
time of compiling from source.

----------
messages: 2912
nosy: npforce, pypy-issue
priority: bug
status: unread
title: osx nightly build is not 'nightly'

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

From tracker at bugs.pypy.org  Wed Aug 10 20:08:02 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Wed, 10 Aug 2011 18:08:02 +0000
Subject: [pypy-issue] [issue824] Memory usage in time of pytest.py running
	under pypy
In-Reply-To: <1312999682.79.0.0434436051096.issue824@bugs.pypy.org>
Message-ID: <1312999682.79.0.0434436051096.issue824@bugs.pypy.org>


New submission from Piotr Skamruk <piotr.skamruk at gmail.com>:

pypy-c (jit version) translated around 2011-08-02
machine with 4G ram, with ubuntu oneiric onboard

python2.7 pytest.py pypy/module/_ssl/test
  after less than minute - done
  max ram usage around 700M

pypy pytest.py pypy/module/_ssl/test
  after several minutes pypy eated whole ram, and kswapd goes crazy

----------
messages: 2913
nosy: jell, pypy-issue
priority: bug
status: unread
title: Memory usage in time of pytest.py running under pypy

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

From tracker at bugs.pypy.org  Thu Aug 11 18:00:18 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Thu, 11 Aug 2011 16:00:18 +0000
Subject: [pypy-issue] [issue825] StackOverflow when importing zope.interface
In-Reply-To: <1313078418.54.0.0278813025117.issue825@bugs.pypy.org>
Message-ID: <1313078418.54.0.0278813025117.issue825@bugs.pypy.org>


New submission from Piotr Skamruk <piotr.skamruk at gmail.com>:

http://paste.pocoo.org/show/456551/

----------
messages: 2914
nosy: jell, pypy-issue
priority: bug
status: unread
title: StackOverflow when importing zope.interface

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

From tracker at bugs.pypy.org  Thu Aug 11 20:08:16 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 11 Aug 2011 18:08:16 +0000
Subject: [pypy-issue] [issue825] StackOverflow when importing zope.interface
In-Reply-To: <1313078418.54.0.0278813025117.issue825@bugs.pypy.org>
Message-ID: <1313086096.06.0.721740187573.issue825@bugs.pypy.org>


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

This is in a way not-a-bug. Remove the C extension, it's buggy. A newer version 
of zope interface should disable building C  extension on pypy.

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

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

From tracker at bugs.pypy.org  Thu Aug 11 21:50:13 2011
From: tracker at bugs.pypy.org (Chris McDonough)
Date: Thu, 11 Aug 2011 19:50:13 +0000
Subject: [pypy-issue] [issue825] StackOverflow when importing zope.interface
In-Reply-To: <1313078418.54.0.0278813025117.issue825@bugs.pypy.org>
Message-ID: <1313092213.22.0.464103691395.issue825@bugs.pypy.org>


Chris McDonough <chrism at plope.com> added the comment:

This bug report is my fault; I didn't remember the symptom correctly.  The 
zope.interface trunk does not build a C extension when it detects its running 
under PyPy now; this feature will be in zope.interface 3.6.5.

----------
nosy: +mcdonc

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

From tracker at bugs.pypy.org  Thu Aug 11 21:58:47 2011
From: tracker at bugs.pypy.org (Chris McDonough)
Date: Thu, 11 Aug 2011 19:58:47 +0000
Subject: [pypy-issue] [issue825] StackOverflow when importing zope.interface
In-Reply-To: <1313078418.54.0.0278813025117.issue825@bugs.pypy.org>
Message-ID: <1313092727.76.0.0817813356749.issue825@bugs.pypy.org>


Chris McDonough <chrism at plope.com> added the comment:

aaaand it's released:

http://pypi.python.org/pypi/zope.interface/3.6.5

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

From tracker at bugs.pypy.org  Thu Aug 11 22:12:59 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 11 Aug 2011 20:12:59 +0000
Subject: [pypy-issue] [issue825] StackOverflow when importing zope.interface
In-Reply-To: <1313078418.54.0.0278813025117.issue825@bugs.pypy.org>
Message-ID: <1313093579.42.0.392789012892.issue825@bugs.pypy.org>


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

It's actually a bug in the cpyext layer:

- All the types defined by the pypy interpreter share the same tp_new pointer. The code of this C 
function evaluates the Python expression cls.__new__(*args, **kw).

- When an extension type fills the tp_new slot, cpyext add to the type's dictionary a __new__ function 
that calls this tp_new.

- Now, zope.interface sets MyType.tp_new=PyBaseObject_Type.tp_new.  So the Python expression MyType() 
calls MyType.tp_new which evaluates MyType.__new__()... and you crash with a StackOverflow.

The fix would be to have different tp_new functions for each type defined in the pypy interpreter 
(=one C function for every Typedef.__new__), so that for example PyDict_Type.tp_new would call 
dict.__new__() instead of cls.__new__().
This has been implemented for tp_setattro, and should be extended to all slots.  I fear the code 
bloat, though.

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

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

From tracker at bugs.pypy.org  Fri Aug 12 01:19:29 2011
From: tracker at bugs.pypy.org (Guillaume Bouchard)
Date: Thu, 11 Aug 2011 23:19:29 +0000
Subject: [pypy-issue] [issue826] Decimal seems slower on pypy than cpython
In-Reply-To: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>
Message-ID: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>


New submission from Guillaume Bouchard <guillaume.bouchard at liris.cnrs.fr>:

The attached code runs slower on pypy than on cpython.

Times on an i7 950, ~28s for python2.7, more than 1 minute and 10 secondes for
pypy1-6nightly
$ pypy1.6nightly --version
Python 2.7.1 (82bf0efcfe7d, Aug 11 2011, 02:06:34)
[PyPy 1.6.0-dev1 with GCC 4.4.3]

>From IRC, Alex_Gaynor guess that it may comes from the support of "long type"
which is slower on pypy than cpython.

----------
files: tirage.py
messages: 2919
nosy: guibou, pypy-issue
priority: bug
status: unread
title: Decimal seems slower on pypy than cpython

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

From tracker at bugs.pypy.org  Fri Aug 12 04:07:56 2011
From: tracker at bugs.pypy.org (Josh Ayers)
Date: Fri, 12 Aug 2011 02:07:56 +0000
Subject: [pypy-issue] [issue827] import xml.etree.cElementTree fails
In-Reply-To: <1313114876.32.0.380028080401.issue827@bugs.pypy.org>
Message-ID: <1313114876.32.0.380028080401.issue827@bugs.pypy.org>


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

import xml.etree.cElementTree fails on PyPy 1.5 (on Windows).

It attempts to import from _elementtree.pyd, which is located in Python27\DLLs
in the CPython distribution, but is not present in PyPy.

A simple fix is to modify pypy\lib-python\2.7\xml\etree\cElementTree.py.

Replace the line:
from _elementtree import *
  with 
from ElementTree import *

That will use the pure-Python version of ElementTree.  Based on some very
limited testing, performance under PyPy is not bad.

----------
messages: 2920
nosy: jayers2003, pypy-issue
priority: bug
release: 1.5
status: unread
title: import xml.etree.cElementTree fails

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

From tracker at bugs.pypy.org  Fri Aug 12 04:29:51 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 12 Aug 2011 02:29:51 +0000
Subject: [pypy-issue] [issue826] Decimal seems slower on pypy than cpython
In-Reply-To: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>
Message-ID: <1313116191.22.0.583084134883.issue826@bugs.pypy.org>


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

According to callgrind, *50%* of the time in this program is spent in 
rbigint.str(), apparently decimal.py is based on converting things to strs 
internally?

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

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

From benjamin at python.org  Fri Aug 12 04:36:39 2011
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 11 Aug 2011 21:36:39 -0500
Subject: [pypy-issue] [issue826] Decimal seems slower on pypy than
	cpython
In-Reply-To: <1313116191.22.0.583084134883.issue826@bugs.pypy.org>
References: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>
	<1313116191.22.0.583084134883.issue826@bugs.pypy.org>
Message-ID: <CAPZV6o-9yRrtEYn931sgpUYVyV2+xC66poK8MM+gN=XhAYNQnA@mail.gmail.com>

2011/8/11 Alex Gaynor <tracker at bugs.pypy.org>:
>
> Alex Gaynor <alex.gaynor at gmail.com> added the comment:
>
> According to callgrind, *50%* of the time in this program is spent in
> rbigint.str(), apparently decimal.py is based on converting things to strs
> internally?

Yes, that's the way it achieves a fixed point precision.



-- 
Regards,
Benjamin

From tracker at bugs.pypy.org  Fri Aug 12 11:24:44 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 09:24:44 +0000
Subject: [pypy-issue] [issue812] gc problem when dealing with numpy's
	virtual arrays
In-Reply-To: <1311824320.16.0.143442799401.issue812@bugs.pypy.org>
Message-ID: <1313141084.28.0.964337320996.issue812@bugs.pypy.org>


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

Fixed in 8549d0ab37a5

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

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

From tracker at bugs.pypy.org  Fri Aug 12 12:03:25 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 10:03:25 +0000
Subject: [pypy-issue] [issue746] "Fatal RPython error: BogusPureField" OSX,
	latest available nightly (44082)
In-Reply-To: <1307706610.73.0.207584496932.issue746@bugs.pypy.org>
Message-ID: <1313143405.47.0.85748440713.issue746@bugs.pypy.org>


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

This is fixed in 869b4929ad06

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

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

From tracker at bugs.pypy.org  Fri Aug 12 12:08:33 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 10:08:33 +0000
Subject: [pypy-issue] [issue744] try/finally in not fully consumed generator
In-Reply-To: <1307657152.57.0.0663906266149.issue744@bugs.pypy.org>
Message-ID: <1313143713.84.0.606114536098.issue744@bugs.pypy.org>


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

Closing.

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

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

From tracker at bugs.pypy.org  Fri Aug 12 12:11:56 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 10:11:56 +0000
Subject: [pypy-issue] [issue811] sys.excepthook not used by interactive
	interpreter
In-Reply-To: <1311765089.88.0.304830795357.issue811@bugs.pypy.org>
Message-ID: <1313143916.14.0.512430784961.issue811@bugs.pypy.org>


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

Closing, reported upstream.

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

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

From tracker at bugs.pypy.org  Fri Aug 12 12:15:38 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 10:15:38 +0000
Subject: [pypy-issue] [issue803] Crash with os.popen pipe
In-Reply-To: <1311258831.03.0.58176251219.issue803@bugs.pypy.org>
Message-ID: <1313144138.3.0.34505306078.issue803@bugs.pypy.org>


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

This is fixed.

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

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

From tracker at bugs.pypy.org  Fri Aug 12 12:17:37 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 10:17:37 +0000
Subject: [pypy-issue] [issue575] Support for Python 2.7
In-Reply-To: <1290934345.84.0.392637049718.issue575@>
Message-ID: <1313144257.29.0.296775549164.issue575@bugs.pypy.org>


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

This is done.

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

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

From tracker at bugs.pypy.org  Fri Aug 12 12:23:16 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 12 Aug 2011 10:23:16 +0000
Subject: [pypy-issue] [issue716] Crashes in hashlib on Windows
In-Reply-To: <1304768621.71.0.0122636956595.issue716@>
Message-ID: <1313144596.95.0.921820122613.issue716@bugs.pypy.org>


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

It seems to have been resolved indirectly; it no longer crashes.  I suspect it
was caused by the same problem as the one solved in 40a36ea9ae0d.

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

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

From tracker at bugs.pypy.org  Fri Aug 12 16:58:55 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 12 Aug 2011 14:58:55 +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: <1313161135.23.0.734496881301.issue822@bugs.pypy.org>


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

Your patch is different from http://hg.python.org/cpython/rev/3c87a13980be
It's important because pypy will certainly grab the latest CPython 2.7 library 
some day.

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

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

From tracker at bugs.pypy.org  Fri Aug 12 17:38:25 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Fri, 12 Aug 2011 15:38:25 +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: <1313163505.11.0.298814113406.issue822@bugs.pypy.org>


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

Ok. Modified patch http://paste.pocoo.org/show/457266/

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

From tracker at bugs.pypy.org  Fri Aug 12 19:13:48 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 17:13:48 +0000
Subject: [pypy-issue] [issue509] __float__ method not called in cmath
In-Reply-To: <1268590033.36.0.630631573109.issue509@>
Message-ID: <1313169228.74.0.965991096175.issue509@bugs.pypy.org>


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

Works these days (CPython and PyPy behaves the same).

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

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

From tracker at bugs.pypy.org  Fri Aug 12 19:15:48 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 17:15:48 +0000
Subject: [pypy-issue] [issue413] zipfile.py bugs in 2.5.1/2.5.2
In-Reply-To: <1225294472.14.0.716906700906.issue413@>
Message-ID: <1313169348.36.0.291993306578.issue413@bugs.pypy.org>


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

Fixed in 2.7

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

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

From tracker at bugs.pypy.org  Fri Aug 12 19:16:26 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 17:16:26 +0000
Subject: [pypy-issue] [issue538] pypy-c doesn't build under FreeBSD 7
In-Reply-To: <1274191795.27.0.812046771338.issue538@>
Message-ID: <1313169386.65.0.0511549466437.issue538@bugs.pypy.org>


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

Can someone confirm/deny if this is still an issue?

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

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

From tracker at bugs.pypy.org  Sat Aug 13 01:06:48 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Fri, 12 Aug 2011 23:06:48 +0000
Subject: [pypy-issue] [issue826] Decimal seems slower on pypy than cpython
In-Reply-To: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>
Message-ID: <1313190408.46.0.471709159113.issue826@bugs.pypy.org>


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

Maybe this is beside the point, but the code isn't especially efficient. The 
largest problem IMO is that in the C(binomial coefficient) function, there is no 
need to convert to the Decimal class before doing the division. The reason that 
guibou was having problems with floating point overflow is because he imported 
division from __future__. If // is used instead of / and we don't use Decimal in 
C() - or only after the bigint math, we don't have this problem anymore. 
Binomial coefficients are always integers by the way. Making this change speeds 
up the code quite a lot for both pypy and cpython and even puts pypy a little 
bit ahead of cpython on my computer. There are other speed-ups that could be 
done with the code, but I won't bother.

This shouldn't take away from the fact that we might need to speed up Decimal. 
It appears from my experiments that the bigint to string conversion needed when 
creating a Decimal from a long or int is what is really slowing things down 
rather than the division of the Decimals.

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

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

From tracker at bugs.pypy.org  Sat Aug 13 01:08:51 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 12 Aug 2011 23:08:51 +0000
Subject: [pypy-issue] [issue826] Decimal seems slower on pypy than cpython
In-Reply-To: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>
Message-ID: <1313190531.98.0.410904426076.issue826@bugs.pypy.org>


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

FWIW Nick Coghlan (CPython core dev) tweeted at me about this, apparently the 
string based representation is some sort of insane (as in crazy, not necessary signification) optimization on CPython.

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

From tracker at bugs.pypy.org  Fri Aug 12 19:12:52 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 12 Aug 2011 17:12:52 +0000
Subject: [pypy-issue] [issue484] review listview()
In-Reply-To: <1258976630.77.0.968264842598.issue484@>
Message-ID: <1313169172.62.0.0369542286795.issue484@bugs.pypy.org>


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

What can actually break if listview is used and applevel code modifies it?

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

From tracker at bugs.pypy.org  Sat Aug 13 14:21:13 2011
From: tracker at bugs.pypy.org (ita)
Date: Sat, 13 Aug 2011 12:21:13 +0000
Subject: [pypy-issue] [issue828] subprocess on nightly builds, linux 64
In-Reply-To: <1313238073.53.0.371378815064.issue828@bugs.pypy.org>
Message-ID: <1313238073.53.0.371378815064.issue828@bugs.pypy.org>


New submission from ita <tnagy1024 at gmail.com>:

I have tried several nightly builds, and it seems they have been broken for a 
while. At least, I cannot get the behaviour of cPython with the testcase 
attached.

The testcase can also serve as a benchmarking tool as it represents a fairly 
complete real-world build.

For testing, just run:
   python ./waf configure clean build -p -j5

cPython will complete normally while Pypy will stop
after a few files are compiled (both jit and no-jit on linux64)

----------
files: pypy-test.tar.bz2
messages: 2941
nosy: ita, pypy-issue
priority: bug
status: unread
title: subprocess on nightly builds, linux 64

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

From tracker at bugs.pypy.org  Sat Aug 13 14:33:25 2011
From: tracker at bugs.pypy.org (Guillaume Bouchard)
Date: Sat, 13 Aug 2011 12:33:25 +0000
Subject: [pypy-issue] [issue826] Decimal seems slower on pypy than cpython
In-Reply-To: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>
Message-ID: <1313238805.58.0.668308857299.issue826@bugs.pypy.org>


Guillaume Bouchard <guillaume.bouchard at liris.cnrs.fr> added the comment:

justin: your are right about the fact that this code should be write
differently. When I had the float overflow in this function, I do not thought it
may comes from the unjustified float division for this specific function.

Letting the C(n,k) function in pure bigint still force use to use some Decimal()
in the P function, because the return of C(n,k) can be really big, multiplied by
the p ** n which can be really small.

Using the same code and writing  C and P like that:

def C(n, k):
    return factorial(n) // (factorial(k) * factorial(n-k))

def P(n, k, p):
    return Decimal(C(n, k)) * Decimal(p) ** k * Decimal(1 - p) ** (n - k)

I'm getting 8.7 seconds for pypy1.6nightly and 8.2 seconds for python2.7, so
pypy is still slower (but not by a big amount). Perhaps you get different
results with some other local optimizations, but the conclusion is still that
Decimal appears slow on pypy.

Just for the science, if you want to get this really quick, the P function can
be rewrites as:

def P(n, k, p):
    ln = math.log
    lnf = lambda x: ln(factorial(x))
    return math.exp(lnf(n) - lnf(k) - lnf(n - k) + k * ln(p) + (n - k) * ln(1 - p))

In this case, pypy works well with *small* calculus, with:

    print(optimise_max(1, 0.0005, 0.999))

I get:

python2.7 0.77s
pypy1.6nightly 0.45s

But with:
    print(optimise_max(1, 0.0002, 0.999))

I get:
python2.7 4.7s
pypy1.6nightly 5.2s

(But it may be for another bug report)

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

From tracker at bugs.pypy.org  Sat Aug 13 16:07:28 2011
From: tracker at bugs.pypy.org (Da_Blitz)
Date: Sat, 13 Aug 2011 14:07:28 +0000
Subject: [pypy-issue] [issue828] subprocess on nightly builds, linux 64
In-Reply-To: <1313238073.53.0.371378815064.issue828@bugs.pypy.org>
Message-ID: <1313244448.14.0.545680358553.issue828@bugs.pypy.org>


Da_Blitz <pypy at pocketnix.org> added the comment:

Subprocess appears to leak FD's if stdin, stdout or stderr are opened with
subprocess.PIPE (Popen("dsa", stdin=PIPE))

waf uses subprocess in the above manner,
http://code.google.com/p/waf/source/browse/trunk/waflib/Context.py line 331

to replicate run the code below, note i have caught the exception so you can cd
/proc/<printed pid>/fd and have a look at the file descriptors

from subprocess import Popen, PIPE
from time import sleep

try:
    for i in range(10000):
        Popen(["ls"], stdin=PIPE, stdout=PIPE, stderr=PIPE)
except:
    print os.getpid()
    sleep(3600)
------------------------------------------

ethier you manually have to close the pipes (perhaps introduce a .close to
subprocess) or run the gc to cause the FD's to be garbage collected. 


TL;DR: subprocesess relies on refcounting to clean up open files in a timly manner

perhaps wait could be extended to close FD's when done and advise that all
programs should be waited on, to me this is simmilar to "you should be closing
files" for open files - good practice but no one is doing it on python until
they try out pypy

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

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

From tracker at bugs.pypy.org  Sat Aug 13 16:08:14 2011
From: tracker at bugs.pypy.org (npforce)
Date: Sat, 13 Aug 2011 14:08:14 +0000
Subject: [pypy-issue] [issue823] osx nightly build is not 'nightly'
In-Reply-To: <1313244494.21.0.570155915678.issue823@bugs.pypy.org>
Message-ID: <1313244494.21.0.570155915678.issue823@bugs.pypy.org>


New submission from npforce <lesterz at gmail.com>:

I see that the build is up to date now.

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

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

From tracker at bugs.pypy.org  Sat Aug 13 17:31:29 2011
From: tracker at bugs.pypy.org (ita)
Date: Sat, 13 Aug 2011 15:31:29 +0000
Subject: [pypy-issue] [issue828] subprocess on nightly builds, linux 64
In-Reply-To: <1313238073.53.0.371378815064.issue828@bugs.pypy.org>
Message-ID: <1313249489.73.0.155500884432.issue828@bugs.pypy.org>


ita <tnagy1024 at gmail.com> added the comment:

Search no more: the problem was aggravated by a real file descriptor leak, the 
subprocess problem is not going to show up in practice

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

From tracker at bugs.pypy.org  Sat Aug 13 17:59:45 2011
From: tracker at bugs.pypy.org (Da_Blitz)
Date: Sat, 13 Aug 2011 15:59:45 +0000
Subject: [pypy-issue] [issue828] subprocess on nightly builds, linux 64
In-Reply-To: <1313238073.53.0.371378815064.issue828@bugs.pypy.org>
Message-ID: <1313251185.98.0.997480494872.issue828@bugs.pypy.org>


Da_Blitz <pypy at pocketnix.org> added the comment:

Attached is a quick patch to add my close on wait idea, .communicate and some of
the other functions call self.wait and so this should handle those cases
transparently

sending signals (terminate, kill and send_signal) do not invoke wait and i have
not touched them. i believe this is the correct thing to do.

note: this wont fix the reported issue, think of it more as a module improvment

patch: process_close.patch

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

From tracker at bugs.pypy.org  Sat Aug 13 22:32:56 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 13 Aug 2011 20:32:56 +0000
Subject: [pypy-issue] [issue821] __debug__ is always True
In-Reply-To: <1312894316.8.0.232369941601.issue821@bugs.pypy.org>
Message-ID: <1313267576.2.0.920595642651.issue821@bugs.pypy.org>


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

pypy ignores the -O option.  We decided it was ok a long time ago.  Maybe we
should reconsider now?  (It seems that -O has the effect of setting
sys.flags.optimize to 1, since we ported pypy to Python 2.7, but that's it)

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

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

From tracker at bugs.pypy.org  Sat Aug 13 22:50:14 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 13 Aug 2011 20:50:14 +0000
Subject: [pypy-issue] [issue585] Missing euc-kr encoding
In-Reply-To: <1291220452.63.0.778360043449.issue585@>
Message-ID: <1313268614.97.0.782318879778.issue585@bugs.pypy.org>


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

Fixed I think.

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

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

From tracker at bugs.pypy.org  Sat Aug 13 22:53:33 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 13 Aug 2011 20:53:33 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1313268813.75.0.51317643783.issue819@bugs.pypy.org>


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

It's known; it's within the "1.5x the time of CPython" factor of general
slowness of PyPy.  Of course the JIT cannot help this at all.  It's unlikely to
be fixed.

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

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

From tracker at bugs.pypy.org  Sun Aug 14 19:32:12 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Aug 2011 17:32:12 +0000
Subject: [pypy-issue] [issue799] Strange exception with threads
In-Reply-To: <1311099755.31.0.9334660034.issue799@bugs.pypy.org>
Message-ID: <1313343132.2.0.529338449048.issue799@bugs.pypy.org>


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

Fixed (took me the day).  It was caused by the lock's interp-level destructor
releasing the GIL, which is now fixed and checked not to occur (I had to fix a
number of other __del__s too).

For reference:

- thread 2 calls gc.collect() at a completely random point
- it calls the destructors
- it releases the GIL
- thread 1 run
- thread 1 sees a random state and crashes

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

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

From tracker at bugs.pypy.org  Mon Aug 15 22:36:02 2011
From: tracker at bugs.pypy.org (Jonas H.)
Date: Mon, 15 Aug 2011 20:36:02 +0000
Subject: [pypy-issue] [issue733] bz2 decompression is very slow
In-Reply-To: <1306785194.2.0.717331507866.issue733@bugs.pypy.org>
Message-ID: <1313440562.3.0.693619687393.issue733@bugs.pypy.org>


Jonas H. <jonas at lophus.org> added the comment:

Still, `pip install http://bitbucket.org/wkornewald/django-
nonrel/get/tip.tar.bz2` takes forever on PyPy (today's nightly: > 10min) while 
CPython 2.7 takes ~ 15 seconds.

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

From tracker at bugs.pypy.org  Tue Aug 16 06:54:44 2011
From: tracker at bugs.pypy.org (Winston Ewert)
Date: Tue, 16 Aug 2011 04:54:44 +0000
Subject: [pypy-issue] [issue829] found an operation that always raises
	AttributeError:	generated by a constant operation: getattr
In-Reply-To: <1313470484.66.0.441517028987.issue829@bugs.pypy.org>
Message-ID: <1313470484.66.0.441517028987.issue829@bugs.pypy.org>


New submission from Winston Ewert <winstonewert at gmail.com>:

Code inside pypy.rlib.parsing in a couple of places make use of the attached
idiom. However, PyPy now refuses to compile it, I'm pretty sure it worked last
time I played with PyPy.

----------
files: sample.py
messages: 2952
nosy: pypy-issue, winstonewert
priority: bug
status: unread
title: found an operation that always raises AttributeError: generated by a constant operation:  getattr

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

From tracker at bugs.pypy.org  Tue Aug 16 13:28:04 2011
From: tracker at bugs.pypy.org (Arni Mar)
Date: Tue, 16 Aug 2011 11:28:04 +0000
Subject: [pypy-issue] [issue830] sys.exit() not printing newline
In-Reply-To: <1313494084.75.0.0859677595127.issue830@bugs.pypy.org>
Message-ID: <1313494084.75.0.0859677595127.issue830@bugs.pypy.org>


New submission from Arni Mar <arnimarj at gmail.com>:

when running "sys.exit(string)" under Python 2.7 the string is output along with
a trailing newline, before exiting the program. pypy does not print the newline.
see:

arni at morrow:~/py-leveldb$ cat hello.py
import sys

sys.exit('hello world')
arni at morrow:~/py-leveldb$ python hello.py
hello world
arni at morrow:~/py-leveldb$
./versions/pypy-c-jit-43780-b590cf6de419-linux64/bin/pypy hello.py

----------
messages: 2953
nosy: arnimar, pypy-issue
priority: bug
release: 1.5
status: unread
title: sys.exit() not printing newline

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

From tracker at bugs.pypy.org  Tue Aug 16 13:48:37 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 11:48:37 +0000
Subject: [pypy-issue] [issue830] sys.exit() not printing newline
In-Reply-To: <1313494084.75.0.0859677595127.issue830@bugs.pypy.org>
Message-ID: <1313495317.64.0.941011041978.issue830@bugs.pypy.org>


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

This has been fixed very recently.

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

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

From tracker at bugs.pypy.org  Tue Aug 16 14:03:04 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 12:03:04 +0000
Subject: [pypy-issue] [issue829] found an operation that always raises
	AttributeError:	generated by a constant operation: getattr
In-Reply-To: <1313470484.66.0.441517028987.issue829@bugs.pypy.org>
Message-ID: <1313496184.7.0.502100206296.issue829@bugs.pypy.org>


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

This prompted me to move the special-casing of the we_are_translated() function
earlier, in the flow space already.  A benefit is that the False path is not
going to be flown at all; it's also simpler, actually.  Done in 80bde0482a01.

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

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

From tracker at bugs.pypy.org  Tue Aug 16 14:09:07 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 12:09:07 +0000
Subject: [pypy-issue] [issue809] Iterating sqlite cursor after executing a
	CREATE TABLE	statement fails
In-Reply-To: <1311633215.94.0.0379391444019.issue809@bugs.pypy.org>
Message-ID: <1313496547.98.0.80157510114.issue809@bugs.pypy.org>


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

Thanks!

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

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

From tracker at bugs.pypy.org  Tue Aug 16 14:19:02 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 12:19:02 +0000
Subject: [pypy-issue] [issue808] Pypy throws exception when typecasting
	array whereas	CPython doesn't
In-Reply-To: <1311619855.35.0.981990502118.issue808@bugs.pypy.org>
Message-ID: <1313497142.41.0.189186258651.issue808@bugs.pypy.org>


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

A bit obscure, as on CPython you get the exception "can only extend with array
of same kind" if you are trying "a.extend(b)".  Fixed in f277de1c5fcd.

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

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

From tracker at bugs.pypy.org  Tue Aug 16 14:22:12 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 12:22:12 +0000
Subject: [pypy-issue] [issue786] Module re,
	\d with re.U option does not work the same way as with CPython
In-Reply-To: <1310096290.69.0.649047120907.issue786@bugs.pypy.org>
Message-ID: <1313497332.2.0.873802284421.issue786@bugs.pypy.org>


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

Indeed, PyPy has what looks like a bug, but CPython has it too starting from
2.7...  Marking it as "wontfix" for now.

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

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

From tracker at bugs.pypy.org  Tue Aug 16 14:44:59 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 12:44:59 +0000
Subject: [pypy-issue] [issue759] Support for PYTHONDONTWRITEBYTECODE
In-Reply-To: <1308714242.93.0.904795431305.issue759@bugs.pypy.org>
Message-ID: <1313498699.19.0.801197170259.issue759@bugs.pypy.org>


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

Fixed in 6dff8ba8be76.

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

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

From tracker at bugs.pypy.org  Tue Aug 16 14:55:42 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 12:55:42 +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: <1313499342.99.0.9720229961.issue768@bugs.pypy.org>


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

Added a warning paragraph in cpython_differences.html.  I'm unsure if we need to
fix something or not.  The situation is obscure because it depends on CPython on
the list of modules that you have chosen to compile built-in or as extension
modules...

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

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

From tracker at bugs.pypy.org  Tue Aug 16 15:03:22 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Aug 2011 13:03:22 +0000
Subject: [pypy-issue] [issue769] Hard crash when trying to pip install
	packages with recent	nightly builds on OSX
In-Reply-To: <1309343840.41.0.910777346081.issue769@bugs.pypy.org>
Message-ID: <1313499802.38.0.692903071095.issue769@bugs.pypy.org>


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

Is this issue still open?  It's hard for us to know or to debug this kind of
OS/X-only issues because we don't have anyone from the core team on OS/X...

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

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

From tracker at bugs.pypy.org  Tue Aug 16 15:23:26 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Tue, 16 Aug 2011 13:23:26 +0000
Subject: [pypy-issue] [issue769] Hard crash when trying to pip install
	packages with recent	nightly builds on OSX
In-Reply-To: <1309343840.41.0.910777346081.issue769@bugs.pypy.org>
Message-ID: <1313501006.11.0.367666630512.issue769@bugs.pypy.org>


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

the pypy buildbot seems down, so I can't fetch a new binary to test it again.

As soon as it's back up (?), I'll get the most recent OSX nightly and check.

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

From tracker at bugs.pypy.org  Tue Aug 16 15:24:05 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Tue, 16 Aug 2011 13:24:05 +0000
Subject: [pypy-issue] [issue769] Hard crash when trying to pip install
	packages with recent	nightly builds on OSX
In-Reply-To: <1309343840.41.0.910777346081.issue769@bugs.pypy.org>
Message-ID: <1313501045.51.0.853418601671.issue769@bugs.pypy.org>


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

and it came back as I was sending the message...

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

From tracker at bugs.pypy.org  Tue Aug 16 15:30:45 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Tue, 16 Aug 2011 13:30:45 +0000
Subject: [pypy-issue] [issue769] Hard crash when trying to pip install
	packages with recent	nightly builds on OSX
In-Reply-To: <1309343840.41.0.910777346081.issue769@bugs.pypy.org>
Message-ID: <1313501445.58.0.920002917549.issue769@bugs.pypy.org>


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

I'm happy to report there was no problem installing any of the packages I listed
(pytz, simplejson babel cherrypy python-dateutil werkzeug) using pip in a
virtualenv created with the latest pypy-c-jit nightly build for OSX
(c8b1c5a0f1f9, Aug 16 2011, 01:04:05).

Marking the bug as resolved.

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

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

From tracker at bugs.pypy.org  Tue Aug 16 19:19:32 2011
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Tue, 16 Aug 2011 17:19:32 +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: <1313515172.05.0.933055217929.issue831@bugs.pypy.org>


New submission from Vetoshkin Nikita <nikita.vetoshkin at gmail.com>:

=== env description ===
version: pypy-c-jit-46516-af690ea765e2-linux64
os: ubuntu 11.04 x64
terminal app: gnome-terminal
env: LANG=en_US.UTF-8 LANGUAGE=en_US:en

error: when I type in interpreter REPL with russian layout I get "\202?
\201\202" instead of "????".

----------
messages: 2965
nosy: nekto0n, pypy-issue
priority: bug
status: unread
title: Codes instead of cyrillic letters in terminal

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

From tracker at bugs.pypy.org  Tue Aug 16 20:21:35 2011
From: tracker at bugs.pypy.org (David Edelsohn)
Date: Tue, 16 Aug 2011 18:21:35 +0000
Subject: [pypy-issue] [issue832] Linux 3.0 kernel fallout
In-Reply-To: <1313518895.9.0.36699993779.issue832@bugs.pypy.org>
Message-ID: <1313518895.9.0.36699993779.issue832@bugs.pypy.org>


New submission from David Edelsohn <dje.gcc at gmail.com>:

PyPy follows CPython 2.7, which does not recognize the new 3.0 Linux kernel
series.  Code expects sys.platform == 'linux2'

----------
messages: 2966
nosy: edelsohn, pypy-issue
priority: bug
status: unread
title: Linux 3.0 kernel fallout

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

From tracker at bugs.pypy.org  Tue Aug 16 20:45:58 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Tue, 16 Aug 2011 18:45:58 +0000
Subject: [pypy-issue] [issue832] Linux 3.0 kernel fallout
In-Reply-To: <1313518895.9.0.36699993779.issue832@bugs.pypy.org>
Message-ID: <1313520358.08.0.0924764049888.issue832@bugs.pypy.org>


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

And what You have in pypy?
I have:

./pypy
Python 2.7.1 (82bf0efcfe7d+, Aug 11 2011, 06:39:45)
[PyPy 1.6.0-dev1 with GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``I'm sorry, could you please not
agree with the cat as well?''
>>>> import sys
>>>> sys.platform
'linux2'

so it's expected value.
Which tests are broken by this issue?

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

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

From tracker at bugs.pypy.org  Tue Aug 16 22:26:29 2011
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Tue, 16 Aug 2011 20:26:29 +0000
Subject: [pypy-issue] [issue783] subprocess cannot handle unicode args
In-Reply-To: <1309962687.3.0.947652570439.issue783@bugs.pypy.org>
Message-ID: <1313526389.22.0.270227997827.issue783@bugs.pypy.org>


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

cpython uses filesystemencoding to decode unicode 
http://hg.python.org/cpython/file/80ac94ad381e/Modules/posixmodule.c#l2979

I think pypy should do something like this: http://pastebin.com/mhZubiyE

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

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

From tracker at bugs.pypy.org  Tue Aug 16 22:35:43 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 16 Aug 2011 20:35:43 +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: <1313526943.99.0.604905200877.issue822@bugs.pypy.org>


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

hum, this is certainly wrong: 
    HAS_SSL2 = not rffi_platform.Defined("OPENSSL_NO_SSL2")
because this only builds an instance of "class Defined", and it certainly needs 
to specify an "#include openssl.h" somewhere!

This object should be in a CConfig class, the one in rlib/ropenssl.py is for 
you.

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

From tracker at bugs.pypy.org  Tue Aug 16 22:43:31 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 16 Aug 2011 20:43:31 +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: <1313527411.75.0.818321445017.issue831@bugs.pypy.org>


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

Same here: when I type the key "?" on my french keyboard I see a strange question 
mark: ?

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

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

From tracker at bugs.pypy.org  Tue Aug 16 22:56:59 2011
From: tracker at bugs.pypy.org (dag)
Date: Tue, 16 Aug 2011 20:56:59 +0000
Subject: [pypy-issue] [issue821] __debug__ is always True
In-Reply-To: <1312894316.8.0.232369941601.issue821@bugs.pypy.org>
Message-ID: <1313528219.04.0.334855893041.issue821@bugs.pypy.org>


dag <dag.odenhall at gmail.com> added the comment:

I would argue it should at least set __debug__ = True even if it doesn't do the
bytecode stripping, so that "if __debug__" code works as expected.

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

From tracker at bugs.pypy.org  Wed Aug 17 00:19:57 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Tue, 16 Aug 2011 22:19:57 +0000
Subject: [pypy-issue] [issue733] bz2 decompression is very slow
In-Reply-To: <1306785194.2.0.717331507866.issue733@bugs.pypy.org>
Message-ID: <1313533197.86.0.460256559.issue733@bugs.pypy.org>


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

I also did that pip install and it only took about 4x longer for me on pypy. This 
matches up with my experiments of just untarring (and bunzipping) the file (using 
the same code that pip does it with, namely employing the tarfile module) taking 
3x-6x longer in pypy as compared to python.

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

From tracker at bugs.pypy.org  Wed Aug 17 01:34:44 2011
From: tracker at bugs.pypy.org (David Edelsohn)
Date: Tue, 16 Aug 2011 23:34:44 +0000
Subject: [pypy-issue] [issue832] Linux 3.0 kernel fallout
In-Reply-To: <1313518895.9.0.36699993779.issue832@bugs.pypy.org>
Message-ID: <1313537684.98.0.279976126072.issue832@bugs.pypy.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Did you translate PyPy on a Linux kernel 3.0 system?  Was the translator Python
built on a Linux kernel 3.0 system?  I am not sure where PyPy picks up its
sys.platform name, but running tests with a CPython built on a Linux kernel 3.0
system failed.

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

From tracker at bugs.pypy.org  Wed Aug 17 01:52:51 2011
From: tracker at bugs.pypy.org (Piotr Skamruk)
Date: Tue, 16 Aug 2011 23:52:51 +0000
Subject: [pypy-issue] [issue832] Linux 3.0 kernel fallout
In-Reply-To: <1313518895.9.0.36699993779.issue832@bugs.pypy.org>
Message-ID: <1313538771.2.0.187812985886.issue832@bugs.pypy.org>


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

pypy was translatet on linux kernel 3.0 system.
translator python was pypy 1.5 from pypy.org site, so probably it was built on 
system with veeery old kernel (idk what tannit has as kernel).

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

From tracker at bugs.pypy.org  Thu Aug 18 20:20:38 2011
From: tracker at bugs.pypy.org (teepark)
Date: Thu, 18 Aug 2011 18:20:38 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>


New submission from teepark <travis.parker at gmail.com>:

I ran into this when I needed os.fchmod, but there are quite a few names not 
present in pypy's os module (I'm on x86_64 linux, and I'm sure many of these aren't 
guaranteed to be there for any platform, but pypy on x86_64 linux should probably 
include them):

- getlogin
- confstr
- getresgid
- tcsetpgrp
- statvfs
- setresgid
- initgroups
- fstatvfs
- getresuid
- fchmod
- setresuid
- tcgetpgrp
- confstr_names
- setgroups
- pathconf
- fchown
- openpty
- ctermid
- statvfs_result

Please change the priority if "feature" isn't appropriate - it doesn't feel right 
but I don't know that cpython compatibility issues are being treated as bugs.

----------
messages: 2975
nosy: pypy-issue, teepark
priority: feature
status: unread
title: missing functions in the os module

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

From tracker at bugs.pypy.org  Thu Aug 18 20:23:03 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Aug 2011 18:23:03 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1313691783.14.0.865266446535.issue833@bugs.pypy.org>


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

It's a duplicate of https://bugs.pypy.org/issue605 , but it's nice to have an
updated list.  I will close the other bug report as the duplicate one.

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

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

From tracker at bugs.pypy.org  Thu Aug 18 20:23:40 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Aug 2011 18:23:40 +0000
Subject: [pypy-issue] [issue605] Complete the 'os' module
In-Reply-To: <1291913971.03.0.430866975316.issue605@>
Message-ID: <1313691820.53.0.568125315792.issue605@bugs.pypy.org>


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

Closing as a duplicate of the up-to-date one in: https://bugs.pypy.org/issue833

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

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

From tracker at bugs.pypy.org  Thu Aug 18 20:25:51 2011
From: tracker at bugs.pypy.org (Kyle Johnson)
Date: Thu, 18 Aug 2011 18:25:51 +0000
Subject: [pypy-issue] [issue827] import xml.etree.cElementTree fails
In-Reply-To: <1313114876.32.0.380028080401.issue827@bugs.pypy.org>
Message-ID: <1313691951.16.0.145763898503.issue827@bugs.pypy.org>


Kyle Johnson <osmaker at gmail.com> added the comment:

Still an issue in 1.6

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

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

From tracker at bugs.pypy.org  Thu Aug 18 20:27:30 2011
From: tracker at bugs.pypy.org (teepark)
Date: Thu, 18 Aug 2011 18:27:30 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1313692050.8.0.146428939026.issue833@bugs.pypy.org>


teepark <travis.parker at gmail.com> added the comment:

ah thank you, I searched for fchmod before posting but that wasn't in the other 
bug. this list was generated by pasting in dir(os) from cpython 2.7.1 to pypy 1.6 
and doing the set difference, so should be up to date :)

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

From tracker at bugs.pypy.org  Thu Aug 18 20:27:44 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Aug 2011 18:27:44 +0000
Subject: [pypy-issue] [issue827] import xml.etree.cElementTree fails
In-Reply-To: <1313114876.32.0.380028080401.issue827@bugs.pypy.org>
Message-ID: <1313692064.8.0.425401293592.issue827@bugs.pypy.org>


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

An issue is that, if I remember correctly, ElementTree and cElementTree are not
providing fully interchangeable APIs.  We need someone to care for the
difference, e.g. by modifying the pure Python ElementTree to make it an exact
replacement of cElementTree.

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

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

From tracker at bugs.pypy.org  Thu Aug 18 20:29:46 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Aug 2011 18:29:46 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1313692186.17.0.320440039376.issue833@bugs.pypy.org>


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

Yes, thank you :-)  I think the previous list was a comparison of PyPy in a
release that supported Python 2.5, and CPython 2.5 itself.  There is indeed no
os.fchmod() in CPython 2.5 either.

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

From tracker at bugs.pypy.org  Thu Aug 18 20:43:25 2011
From: tracker at bugs.pypy.org (Winston Ewert)
Date: Thu, 18 Aug 2011 18:43:25 +0000
Subject: [pypy-issue] [issue834] pypy.rlib.parsing gives unhelpful parse
	errors
In-Reply-To: <1313693005.52.0.152525044926.issue834@bugs.pypy.org>
Message-ID: <1313693005.52.0.152525044926.issue834@bugs.pypy.org>


New submission from Winston Ewert <winstonewert at gmail.com>:

Steps to Reproduce:

Run the attached script through a python interpreter making sure it imports
pypy.rlib.parsing.

Actual Output:

  File <unknown>, line 0
abaa
  ^
ParseError: expected EOF

Desired Output:

  File <unknown>, line 0
abaa
   ^
ParseError: expected "b"

The rules for this grammar:

program: pair* EOF;
pair: "b" | "a" "b";

Cause:

The parser tries to match: "abaa" against [pair][pair], but the second [pair]
doesn't match. The parser then decides to accept a single [pair] as a valid
[pair*] and throws away the error that prevented pair from being matched. The
EOF at the end of program then fails to match producing the error seen above.

Solution:

The simple solution is to also pass the error information along even if the node
parses correctly. Then the logic of always reporting the error that occoured
furthest into the list of tokens will take care of reporting the appropriate
error. I've done a quick hack job of this in my copy, and it works. However, a
much cleaner solution would remove the error information from the tuple and just
store it on the Table object. 

Code:

I'm happy to prepare a patch to fix this issue. However, I'd like to know from
the people responsible for this code whether my solution is acceptable and
whether there is anything I should be watching for. (I'm only beginning to
figure out what all the parsing stuff is doing.)

----------
files: bug_case.py
messages: 2982
nosy: pypy-issue, winstonewert
priority: feature
status: unread
title: pypy.rlib.parsing gives unhelpful parse errors

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

From tracker at bugs.pypy.org  Thu Aug 18 23:25:57 2011
From: tracker at bugs.pypy.org (shhong)
Date: Thu, 18 Aug 2011 21:25:57 +0000
Subject: [pypy-issue] [issue835] Different behaviors of 'is' and '==' than
	cpython
In-Reply-To: <1313702757.07.0.40024374232.issue835@bugs.pypy.org>
Message-ID: <1313702757.07.0.40024374232.issue835@bugs.pypy.org>


New submission from shhong <shhong at oist.jp>:

Using 'is' and '==' give different answers in list comprehension as follows 
while cPython gives the same.

>>> z = [0,1,0]
>>> u = [i for i in range(3) if z[i] is 0]
>>> u
[]
>>> u = [i for i in range(3) if z[i] == 0]
>>> u
[0, 2]

----------
messages: 2983
nosy: pypy-issue, shhong
priority: bug
status: unread
title: Different behaviors of 'is' and '==' than cpython

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

From tracker at bugs.pypy.org  Thu Aug 18 23:44:57 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 18 Aug 2011 21:44:57 +0000
Subject: [pypy-issue] [issue835] Different behaviors of 'is' and '==' than
	cpython
In-Reply-To: <1313702757.07.0.40024374232.issue835@bugs.pypy.org>
Message-ID: <1313703897.55.0.896392174269.issue835@bugs.pypy.org>


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

Even with CPython, comparing integers with 'is' is frowned upon.
This code relies on CPython sharing integer objects for small values, and can 
have different results on different versions of CPython.  An implementation 
detail, really.

pypy can even choose to *not* allocate an integer object at all!

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

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

From tracker at bugs.pypy.org  Fri Aug 19 01:34:09 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Aug 2011 23:34:09 +0000
Subject: [pypy-issue] [issue835] Different behaviors of 'is' and '==' than
	cpython
In-Reply-To: <1313702757.07.0.40024374232.issue835@bugs.pypy.org>
Message-ID: <1313710449.54.0.957654704791.issue835@bugs.pypy.org>


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

Added to the doc:

+* Do not compare immutable objects with ``is``.  For example on CPython
+  it is true that ``x is 0`` works, i.e. does the same as ``type(x) is
+  int and x == 0``, but it is so by accident.  If you do instead
+  ``x is 1000``, then it stops working, because 1000 is too large and
+  doesn't come from the internal cache.  In PyPy it fails to work in
+  both cases, because we have no need for a cache at all.

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

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

From tracker at bugs.pypy.org  Fri Aug 19 10:51:16 2011
From: tracker at bugs.pypy.org (lucian)
Date: Fri, 19 Aug 2011 08:51:16 +0000
Subject: [pypy-issue] [issue836] Django 1.3 failing runserver
In-Reply-To: <1313743876.97.0.429602327359.issue836@bugs.pypy.org>
Message-ID: <1313743876.97.0.429602327359.issue836@bugs.pypy.org>


New submission from lucian <lucian.branescu at gmail.com>:

When I try 'pypy manage.py runserver', I get this error about a missing 
os.spawnve.

This happens on win32.

----------
messages: 2986
nosy: lucian, pypy-issue
priority: bug
release: 1.5
status: unread
title: Django 1.3 failing runserver

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

From tracker at bugs.pypy.org  Fri Aug 19 11:35:16 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 19 Aug 2011 09:35:16 +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: <1313746516.18.0.388815834078.issue831@bugs.pypy.org>


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

If I start gnome-terminal on my Linux laptop, any non-ascii character I type --
either at the bash prompt or at the pypy prompt -- end up as a "?" character,
both in display and in behavior.  I failed to figure out what I need to
configure to make this change (nothing in the configuration dialog boxes, and
setting the environment before has no effect, either).  Can you give more
information on how to reproduce?  Thanks!

GNOME Terminal 2.32.0

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

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

From tracker at bugs.pypy.org  Fri Aug 19 13:50:13 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 19 Aug 2011 11:50:13 +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: <1313754613.6.0.246275170714.issue831@bugs.pypy.org>


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

Should be fixed, probably.  Can you try?  The fix is just to edit
lib_pypy/pyrepl/readline.py so that it starts with

ENCODING = sys.getfilesystemencoding() or 'latin1'

instead of just

ENCODING = 'latin1'
.

----------
status: chatting -> testing

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

From tracker at bugs.pypy.org  Fri Aug 19 14:08:45 2011
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Fri, 19 Aug 2011 12:08:45 +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: <1313755725.3.0.240417160742.issue831@bugs.pypy.org>


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

Confirming. Fix helps!

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

From tracker at bugs.pypy.org  Sat Aug 20 01:46:14 2011
From: tracker at bugs.pypy.org (Vetoshkin Nikita)
Date: Fri, 19 Aug 2011 23:46:14 +0000
Subject: [pypy-issue] [issue783] subprocess cannot handle unicode args
In-Reply-To: <1309962687.3.0.947652570439.issue783@bugs.pypy.org>
Message-ID: <1313797574.11.0.515482314918.issue783@bugs.pypy.org>


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

Tried stuff as in patch. But I get strange results: unicode strings get doubly 
encoded to filesystemencoding (utf-8).

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

From tracker at bugs.pypy.org  Sat Aug 20 17:33:13 2011
From: tracker at bugs.pypy.org (Winston Ewert)
Date: Sat, 20 Aug 2011 15:33:13 +0000
Subject: [pypy-issue] [issue837] Behavior Differs Between Interpreter and JIT
In-Reply-To: <1313854393.08.0.060546386432.issue837@bugs.pypy.org>
Message-ID: <1313854393.08.0.060546386432.issue837@bugs.pypy.org>


New submission from Winston Ewert <winstonewert at gmail.com>:

The attached interpreter doesn't do the same thing when interpreted as with the jit.

$ pypy strip.py
(no output)
$ pypy ../pypy/pypy/translate/goal/translate.py --opt=jit strip.py
(...)
$ ./strip-c
Not found: 2
RPython traceback:
  File "jit_metainterp_blackhole.c", line 6526, in handler_inline_call_ir_r_1
  File "implement.c", line 3468, in call_stub_6
  File "implement.c", line 1596, in Frame_load
Fatal RPython error: AssertionError
Aborted

It appears to have something to do with my use of virtualizables.

----------
messages: 2991
nosy: pypy-issue, winstonewert
priority: bug
status: unread
title: Behavior Differs Between Interpreter and JIT

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

From tracker at bugs.pypy.org  Sat Aug 20 17:37:30 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 20 Aug 2011 15:37:30 +0000
Subject: [pypy-issue] [issue837] Behavior Differs Between Interpreter and JIT
In-Reply-To: <1313854393.08.0.060546386432.issue837@bugs.pypy.org>
Message-ID: <1313854650.8.0.224809788351.issue837@bugs.pypy.org>


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

You forgot to attach it.

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

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

From tracker at bugs.pypy.org  Sat Aug 20 18:02:46 2011
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Sat, 20 Aug 2011 16:02:46 +0000
Subject: [pypy-issue] [issue832] Linux 3.0 kernel fallout
In-Reply-To: <1313518895.9.0.36699993779.issue832@bugs.pypy.org>
Message-ID: <1313856166.23.0.667778682242.issue832@bugs.pypy.org>


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

Corresponding bug/discussion about this in CPython's tracker: 
http://bugs.python.org/issue12326

----------
nosy: +dmalcolm

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

From tracker at bugs.pypy.org  Sat Aug 20 19:15:35 2011
From: tracker at bugs.pypy.org (Winston Ewert)
Date: Sat, 20 Aug 2011 17:15:35 +0000
Subject: [pypy-issue] [issue837] [custom interpreter] Behavior Differs
	Between Interpreter	and JIT
In-Reply-To: <1313854393.08.0.060546386432.issue837@bugs.pypy.org>
Message-ID: <1313860535.19.0.360962628855.issue837@bugs.pypy.org>


Winston Ewert <winstonewert at gmail.com> added the comment:

Forgot to attach

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

From tracker at bugs.pypy.org  Sat Aug 20 23:15:08 2011
From: tracker at bugs.pypy.org (vad)
Date: Sat, 20 Aug 2011 21:15:08 +0000
Subject: [pypy-issue] [issue838] PIL on OSX
In-Reply-To: <1313874908.78.0.721237065333.issue838@bugs.pypy.org>
Message-ID: <1313874908.78.0.721237065333.issue838@bugs.pypy.org>


New submission from vad <davide.setti at gmail.com>:

On OSX (Snow Leopard), PyPy 1.6, i tried to install PIL. When i do "setup.py 
build" i get:

Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "setup.py", line 486, in <module>
    version=VERSION,
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/command/build.py", line 127, in run
    self.run_command(cmd_name)
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "setup.py", line 232, in build_extensions
    if find_library_file(self, "z"):
  File "setup.py", line 108, in find_library_file
    return self.compiler.find_library_file(self.compiler.library_dirs, library)
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/distutils/unixccompiler.py", line 329, in find_library_file
    m = re.search(r'-isysroot\s+(\S+)', cflags)
  File "/Users/vad/Source/Envs/pil-pypy16/lib-python/2.7/re.py", line 142, in 
search
    return _compile(pattern, flags).search(string)
TypeError: unsupported operand type for unary buffer: 'NoneType'

If i patch pypy-1.6/lib-python/modified-2.7/distutils/unixccompiler.py:328 
adding:

if cflags is None:
  cflags = ''

everything works.

----------
messages: 2995
nosy: pypy-issue, vad
priority: bug
status: unread
title: PIL on OSX

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

From tracker at bugs.pypy.org  Sun Aug 21 10:12:05 2011
From: tracker at bugs.pypy.org (dave b)
Date: Sun, 21 Aug 2011 08:12:05 +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: <1313914325.02.0.19991212695.issue839@bugs.pypy.org>


New submission from dave b <db.pub.mail+pypy at gmail.com>:

So I decided to download and see what all the "fuss" was about the awesome! pypy.
I was disappoint :( 
Unfortunately, in pypy 1.6 on an amd64 machine there is a bunch of slowness one
hits when running code that does "a fair amount" of sqlite insertion (even when
using executemany). 

Here is some cprofile output --> 

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
  1697987    4.790    0.000    8.634    0.000
/home/user/pypy/pypy-1.6/lib_pypy/_ctypes/function.py:350(_call_funcptr)
  1018764    3.154    0.000    3.966    0.000
/home/user/pypy/pypy-1.6/lib_pypy/_sqlite3.py:936(_check_decodable)
  1018764    1.225    0.000   11.250    0.000
/home/user/pypy/pypy-1.6/lib_pypy/_sqlite3.py:947(set_param)
  1697985    1.016    0.000    1.830    0.000
/home/user/pypy/pypy-1.6/lib_pypy/_ctypes/function.py:592(_build_result)



I am not sure what the point of the "_check_decodable" method is :P so I just
made it return true :P (nothing broke ^ ^  but I didn't run any tests either ;) ).
The total 4.790 seconds spent in _call_funcptr is _way_ to much.

Cpython is taking pypy for a walk around the block (many times :P ) ... in my
use case.

----------
messages: 2996
nosy: daveb, pypy-issue
priority: bug
status: unread
title: Sqlite in pypy 1.6 on amd64 is very slow :)

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

From tracker at bugs.pypy.org  Sun Aug 21 17:34:17 2011
From: tracker at bugs.pypy.org (dave b)
Date: Sun, 21 Aug 2011 15:34:17 +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: <1313940857.55.0.627604195967.issue839@bugs.pypy.org>


dave b <db.pub.mail+pypy at gmail.com> added the comment:

https://code.djangoproject.com/ticket/7921 --> might be of relevance

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

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

From tracker at bugs.pypy.org  Sun Aug 21 23:56:56 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 21 Aug 2011 21:56:56 +0000
Subject: [pypy-issue] [issue840] string-escape encoding should escape single
	quotes
In-Reply-To: <1313963816.06.0.158902991143.issue840@bugs.pypy.org>
Message-ID: <1313963816.06.0.158902991143.issue840@bugs.pypy.org>


New submission from Amaury Forgeot d Arc <amauryfa at gmail.com>:

With CPython:
   "'".encode('string-escape') == "\\'"
but pypy returns "'".

----------
messages: 2998
nosy: afa, pypy-issue
priority: bug
status: unread
title: string-escape encoding should escape single quotes

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

From tracker at bugs.pypy.org  Mon Aug 22 13:51:00 2011
From: tracker at bugs.pypy.org (Mitchell Hashimoto)
Date: Mon, 22 Aug 2011 11:51:00 +0000
Subject: [pypy-issue] [issue841] [PATCH] Implement 'os.getlogin'
In-Reply-To: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>
Message-ID: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>


New submission from Mitchell Hashimoto <mitchell.hashimoto at gmail.com>:

I've added the 'getlogin' method to the 'os' module. Tests are included for every 
part.

----------
assignedto: mitchellh
files: os-getlogin.patch
messages: 2999
nosy: mitchellh, pypy-issue
priority: feature
status: unread
title: [PATCH] Implement 'os.getlogin'

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

From tracker at bugs.pypy.org  Mon Aug 22 13:54:18 2011
From: tracker at bugs.pypy.org (Mitchell Hashimoto)
Date: Mon, 22 Aug 2011 11:54:18 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1314014058.32.0.590337348846.issue833@bugs.pypy.org>


Mitchell Hashimoto <mitchell.hashimoto at gmail.com> added the comment:

I've added os.getlogin(), patch available at issue #841 

https://bugs.pypy.org/issue841

----------
nosy: +mitchellh

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

From tracker at bugs.pypy.org  Mon Aug 22 14:02:18 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 22 Aug 2011 12:02:18 +0000
Subject: [pypy-issue] [issue841] [PATCH] Implement 'os.getlogin'
In-Reply-To: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>
Message-ID: <1314014538.53.0.183130967155.issue841@bugs.pypy.org>


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

Thanks! some remarks:
- http://docs.python.org/library/os.html#os.getlogin says that the value is often 
equal to os.environ['LOGNAME']
- It also says that the function is not implemented at all on Windows!

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

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

From tracker at bugs.pypy.org  Mon Aug 22 15:57:25 2011
From: tracker at bugs.pypy.org (jayqhacker)
Date: Mon, 22 Aug 2011 13:57:25 +0000
Subject: [pypy-issue] [issue791] Simple wordcount is significantly slower
	and fatter than	CPython
In-Reply-To: <1310485078.56.0.855118946444.issue791@bugs.pypy.org>
Message-ID: <1314021445.31.0.911137446781.issue791@bugs.pypy.org>


jayqhacker <jayqhacker at gmail.com> added the comment:

As of PyPy 1.6, memory usage is on par with CPython and execution time is
getting close:

CPython 2.7.1 : 41s   1400 MB
PyPy 1.6      : 61s   1400 MB

Impressive improvement.

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

From tracker at bugs.pypy.org  Mon Aug 22 20:57:08 2011
From: tracker at bugs.pypy.org (Mitchell Hashimoto)
Date: Mon, 22 Aug 2011 18:57:08 +0000
Subject: [pypy-issue] [issue841] [PATCH] Implement 'os.getlogin'
In-Reply-To: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>
Message-ID: <1314039428.81.0.339767464393.issue841@bugs.pypy.org>


Mitchell Hashimoto <mitchell.hashimoto at gmail.com> added the comment:

Ah, you're right, I was accidentally porting getlogin from the 3.2 branch, which 
does implement it for Windows. I've started tracking 2.7 now.

I've attached a new patch (os-getlogin2.patch) which makes it available for 
posix only.

As for the "LOGNAME" environ, the CPython source doesn't use this. Instead, I 
think the documentation is merely hinting that that is another option.

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

From tracker at bugs.pypy.org  Mon Aug 22 23:03:26 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 22 Aug 2011 21:03:26 +0000
Subject: [pypy-issue] [issue842] reload(sys) should not reset sys.path
In-Reply-To: <1314047006.02.0.344342022672.issue842@bugs.pypy.org>
Message-ID: <1314047006.02.0.344342022672.issue842@bugs.pypy.org>


New submission from Amaury Forgeot d Arc <amauryfa at gmail.com>:

The following script fails with pypy.  In CPython, builtin modules save their 
dict, (sys does it 
*before* sys.path has been created) and this saved dict is used to update the 
current module.

import sys
sys.path = ['foo'] + sys.path
reload(sys)
assert sys.path[0] == 'foo'

----------
messages: 3004
nosy: afa, pypy-issue
priority: bug
status: unread
title: reload(sys) should not reset sys.path

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

From tracker at bugs.pypy.org  Wed Aug 24 08:30:47 2011
From: tracker at bugs.pypy.org (Alex Krusz)
Date: Wed, 24 Aug 2011 06:30:47 +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: <1314167447.35.0.774659658214.issue843@bugs.pypy.org>


New submission from Alex Krusz <harfatum at gmail.com>:

Input/Output:
D:\Python>python athena_16.py 48 10
[2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3] set([3318]) [[3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2]
]
806844323190414
Total time was 6.473 seconds.

D:\Python>pypy athena_16.py 48 10
[2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3] set([3318]) [[3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2]
]
806844323190414
Total time was 10.525 seconds.
============================
This code was written to satisfy the following problem:

Your niece was given a set of blocks for her birthday, and she has decided to
build a panel using 
3?????1??? and 4.5?????1" blocks. For structural integrity, the spaces between the
blocks must not line up 
in adjacent rows. For example, the 13.5?????3??? panel below is unacceptable, because
some of the 
spaces between the blocks in the first two rows line up (as indicated by the
dotted line). 
 
There are 2 ways in which to build a 7.5?????1??? panel, 2 ways to build a 7.5?????2???
panel, 4 ways to 
build a 12?????3??? panel, and 7958 ways to build a 27?????5??? panel. How many different
ways are there 
for your niece to build a 48?????10??? panel? The answer will fit in a 64-bit
integer. Write a program to 
calculate the answer.  
 
The program should be non-interactive and run as a single-line command which
takes two 
command-line arguments, width and height, in that order. Given any width between
3 and 48 that 
is a multiple of 0.5, inclusive, and any height that is an integer between 1 and
10, inclusive, your 
program should calculate the number of valid ways there are to build a wall of
those dimensions. 
Your program???s output should simply be the solution as a number, with no
line-breaks or white 
spaces.

----------
files: athena_16.py
messages: 3005
nosy: Harfatum, pypy-issue
priority: bug
status: unread
title: PyPy slower than CPython with puzzle problem

________________________________________
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

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 range(n/3 + 1):
		for bits in combinations(range(n-i), 2*i + width_parity):
			s = [2] * (n-i)
			for bit in bits:
				s[bit] = 3
			result.append(s)
	return result
	
def running_total(list):
	total = 0
	total_list = set([])
	for item_num in range(len(list)-1): #-1 because the last items in the running totals will always be identical
		total += list[item_num]
		total_list.add(total)
	return total_list

def find_compatibility(single_rows):
	length = len(single_rows)
	compatibility = [set([]) for x in range(length)]
	running_totals = [set([]) for x in range(length)]
	
	for i in range(length):
		running_totals[i] = running_total(single_rows[i])
	
	for i in range(length):
		for j in range(i+1, length): #listing all compatibility sets
			#compare the ith row with the remaining rows to check if creases don't line up (i.e. compatible rows)
			if not running_totals[i] & running_totals[j]:
				compatibility[i].add(j)
				compatibility[j].add(i)
	
	return compatibility

def find_total_walls(compatibility, rows_left):
	length = len(compatibility)
	previous_row = [1 for x in range(length)]
	
	for row in range(rows_left - 1):
		next_row_possibilities = [0 for x in range(length)]
		for compat_index in range(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 should be faster. blocks of width 3 and 4.5 are at a 2:3 ratio

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

print single_rows[-1], compatibility[-1], [single_rows[x] for x in compatibility[-1]]

print total_walls

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

From tracker at bugs.pypy.org  Wed Aug 24 08:33:51 2011
From: tracker at bugs.pypy.org (Alex Krusz)
Date: Wed, 24 Aug 2011 06:33:51 +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: <1314167631.89.0.592798119465.issue843@bugs.pypy.org>


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

This is on a 64-Bit Windows 7 dual-core, with CPython 2.7 and PyPy 1.5.

Submitted by request:
http://www.reddit.com/r/Python/comments/js68e/pypy_vs_cpython_26_my_pure_python_fft_example/c2epva1

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

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

From tracker at bugs.pypy.org  Wed Aug 24 12:06:46 2011
From: tracker at bugs.pypy.org (Reza Lotun)
Date: Wed, 24 Aug 2011 10:06:46 +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: <1314180406.47.0.618087248096.issue843@bugs.pypy.org>


Reza Lotun <rlotun at gmail.com> added the comment:

I can confirm this on Mac OS X 10.6.8 on a 2.7 GHz i7 MBP running pypy 1.6 
(dcae7aed462b, Aug 17 2011, 09:46:15). PyPy about 1.5 times slower than the 
corresponding python 2.6.1 default installed version.

----------
nosy: +rlotun

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

From tracker at bugs.pypy.org  Wed Aug 24 18:15:10 2011
From: tracker at bugs.pypy.org (Mitchell Hashimoto)
Date: Wed, 24 Aug 2011 16:15:10 +0000
Subject: [pypy-issue] [issue841] [PATCH] Implement 'os.getlogin'
In-Reply-To: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>
Message-ID: <1314202510.02.0.721655328561.issue841@bugs.pypy.org>


Mitchell Hashimoto <mitchell.hashimoto at gmail.com> added the comment:

Sorry to ping, but any word on getting this in? Thanks!

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

From tracker at bugs.pypy.org  Thu Aug 25 00:26:42 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 24 Aug 2011 22:26:42 +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: <1314224802.1.0.0138293034638.issue843@bugs.pypy.org>


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

It looks like the slowness is coming from set.__and__, no idea why yet, all the 
traces look great, I'll continue looking.

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

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

From tracker at bugs.pypy.org  Thu Aug 25 08:50:09 2011
From: tracker at bugs.pypy.org (vad)
Date: Thu, 25 Aug 2011 06:50:09 +0000
Subject: [pypy-issue] [issue838] CFLAGS on OSX (pypy 1.6)
In-Reply-To: <1313874908.78.0.721237065333.issue838@bugs.pypy.org>
Message-ID: <1314255009.63.0.718383088916.issue838@bugs.pypy.org>


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

Looks like pypy 1.6 is not able to recognize cflags on OSX. This is pip install 
simplejson with cpython:

  Running setup.py install for simplejson
    building 'simplejson._speedups' extension
    /usr/bin/cc -fno-strict-aliasing -O3 -march=core2 -msse4.1 -w -pipe -DNDEBUG 
-g -fwrapv -O3 -Wall -Wstrict-prototypes -
I/usr/local/Cellar/python/2.7.1/include/python2.7 -c simplejson/_speedups.c -o 
build/temp.macosx-10.4-x86_64-2.7/simplejson/_speedups.o
    /usr/bin/cc -L/usr/local/Cellar/readline/6.1/lib -bundle -undefined 
dynamic_lookup -L/usr/local/Cellar/readline/6.1/lib build/temp.macosx-10.4-
x86_64-2.7/simplejson/_speedups.o -o build/lib.macosx-10.4-x86_64-
2.7/simplejson/_speedups.so

The same with pypy:

  Running setup.py install for simplejson
    building 'simplejson._speedups' extension
    cc -arch x86_64 -fPIC -Wimplicit -I/Users/vad/Source/Envs/djangobench-
pypy16/include -c simplejson/_speedups.c -o build/temp.macosx-10.6-x86_64-
2.7/simplejson/_speedups.o
    simplejson/_speedups.c: In function ?encoder_encode_float?:
    simplejson/_speedups.c:2055: warning: implicit declaration of function 
?Py_IS_INFINITY?
    simplejson/_speedups.c:2055: warning: implicit declaration of function 
?Py_IS_NAN?
    cc -shared -undefined dynamic_lookup -arch x86_64 build/temp.macosx-10.6-
x86_64-2.7/simplejson/_speedups.o -o build/lib.macosx-10.6-x86_64-
2.7/simplejson/_speedups.pypy-16.so

I don't have CFLAGS (or other *FLAGS) in my shell environment.

----------
status: unread -> chatting
title: PIL on OSX -> CFLAGS on OSX (pypy 1.6)

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

From tracker at bugs.pypy.org  Thu Aug 25 09:03:33 2011
From: tracker at bugs.pypy.org (mvt)
Date: Thu, 25 Aug 2011 07:03:33 +0000
Subject: [pypy-issue] [issue838] CFLAGS on OSX (pypy 1.6)
In-Reply-To: <1313874908.78.0.721237065333.issue838@bugs.pypy.org>
Message-ID: <1314255813.41.0.568714544075.issue838@bugs.pypy.org>


mvt <michaelvantellingen at gmail.com> added the comment:

This should already be fixed in pypy trunk. See 
https://bitbucket.org/pypy/pypy/changeset/9cc9fd4f2b14
Although i'm still not sure if this is the most clean fix.

----------
nosy: +mvt

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

From tracker at bugs.pypy.org  Thu Aug 25 09:14:56 2011
From: tracker at bugs.pypy.org (vad)
Date: Thu, 25 Aug 2011 07:14:56 +0000
Subject: [pypy-issue] [issue838] CFLAGS on OSX (pypy 1.6)
In-Reply-To: <1313874908.78.0.721237065333.issue838@bugs.pypy.org>
Message-ID: <1314256496.04.0.112233381084.issue838@bugs.pypy.org>


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

Hi Michael, nice to see you here :)

that fixes the crash, thank you. However it would be also good to have the flags 
that cpython uses compiling simplejson.

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

From tracker at bugs.pypy.org  Thu Aug 25 19:23:23 2011
From: tracker at bugs.pypy.org (vad)
Date: Thu, 25 Aug 2011 17:23:23 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>


New submission from vad <davide.setti at gmail.com>:

i'm trying to run djangobench on Pypy 1.6 and OsX Snow Leopard and i get this 
circular import:

$ 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 11, in 
<module>
    from ctypes.util import find_library
  File "/Users/vad/Software/pypy/pypy-1.6/lib-python/modified-
2.7/ctypes/util.py", line 75, in <module>
    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'))
AttributeError: 'module' object has no attribute 'util'

----------
messages: 3013
nosy: pypy-issue, vad
priority: bug
status: unread
title: Circular import in ctypes.util

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

From tracker at bugs.pypy.org  Thu Aug 25 20:31:18 2011
From: tracker at bugs.pypy.org (Jose Antonio Martin H.)
Date: Thu, 25 Aug 2011 18:31:18 +0000
Subject: [pypy-issue] [issue845] ImportError: No module named cPickle
In-Reply-To: <1314297078.97.0.0821748628055.issue845@bugs.pypy.org>
Message-ID: <1314297078.97.0.0821748628055.issue845@bugs.pypy.org>


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

Python 2.7.1 (080f42d5c4b4, Aug 23 2011, 11:41:11)
[PyPy 1.6.0 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy 1.1.0beta released:
http://codespeak.net/pypy/dist/pypy/doc/release-1.1.0.html''
>>>> import cPickle
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ImportError: No module named cPickle
>>>>

----------
messages: 3014
nosy: jamartinh, pypy-issue
priority: bug
status: unread
title: ImportError: No module named cPickle

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

From tracker at bugs.pypy.org  Thu Aug 25 20:56:37 2011
From: tracker at bugs.pypy.org (Janno)
Date: Thu, 25 Aug 2011 18:56:37 +0000
Subject: [pypy-issue] [issue846] TypeError: type 'basestring' is not an
	acceptable base	class
In-Reply-To: <1314298597.06.0.673686395864.issue846@bugs.pypy.org>
Message-ID: <1314298597.06.0.673686395864.issue846@bugs.pypy.org>


New submission from Janno <mail at janno-kaiser.de>:

I just noticed this while trying to install nltk with pypy1.6:

# pypy --version
Python 2.7.1 (d8ac7d23d3ec, Aug 17 2011, 11:51:18)
[PyPy 1.6.0 with GCC 4.4.3]
# pypy -c 'class A(basestring): pass'
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "app_main.py", line 533, in run_it
  File "<string>", line 1, in <module>
TypeError: type 'basestring' is not an acceptable base class


# python2.7 --version
Python 2.7.1
# python2.7 -c 'class A(basestring): pass'

(no output, as expected)

----------
messages: 3015
nosy: Janno, pypy-issue
priority: bug
status: unread
title: TypeError: type 'basestring' is not an acceptable base class

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

From tracker at bugs.pypy.org  Thu Aug 25 21:56:29 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 25 Aug 2011 19:56:29 +0000
Subject: [pypy-issue] [issue845] ImportError: No module named cPickle
In-Reply-To: <1314297078.97.0.0821748628055.issue845@bugs.pypy.org>
Message-ID: <1314302189.35.0.11120565248.issue845@bugs.pypy.org>


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

It happens that the zip file available for download contains a file named pypy-
1.6/lib_pypy/cpickle.py with a lowercase 'p'.

----------
assignedto:  -> arigo
nosy: +afa, arigo
status: unread -> chatting

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

From tracker at bugs.pypy.org  Thu Aug 25 21:57:13 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 25 Aug 2011 19:57:13 +0000
Subject: [pypy-issue] [issue845] ImportError: No module named cPickle
In-Reply-To: <1314297078.97.0.0821748628055.issue845@bugs.pypy.org>
Message-ID: <1314302233.93.0.482798021089.issue845@bugs.pypy.org>


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

jamartinh, can you try to rename this file to cPickle.py?

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

From tracker at bugs.pypy.org  Fri Aug 26 00:16:49 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Thu, 25 Aug 2011 22:16:49 +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: <1314310609.73.0.580271599105.issue843@bugs.pypy.org>


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

I suggest changing the line

if not running_totals[i] & running_totals[j]:

to

if running_totals[i].isdisjoint(running_totals[j]):

With this change, both CPython and Pypy are a lot faster, but Pypy is now about 
twice as fast as CPython on my computer. However, we should definitely look at 
why the Pypy's set intersection method is slower in Pypy than CPython's method. 
One possible cause is that Pypy's set is really just an RPython dict where the 
values of the keys are set to None while CPython has a slightly different 
implementation for the set as opposed to the dict which doesn't have any values 
being set for the keys. It might be good to have a separate set object in 
RPython.

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

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

From tracker at bugs.pypy.org  Fri Aug 26 00:18:13 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 25 Aug 2011 22:18:13 +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: <1314310693.65.0.988822278945.issue843@bugs.pypy.org>


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

set being represented as a dict isn't an issue, the translator is super smart and 
for a dict with values known to always be None it'll remove that field.

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

From tracker at bugs.pypy.org  Fri Aug 26 11:24:33 2011
From: tracker at bugs.pypy.org (Henry Ludemann)
Date: Fri, 26 Aug 2011 09:24:33 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>


New submission from Henry Ludemann <misc at hl.id.au>:

Old style classes ask the right hand side of '==' for the '__equals__' method
before the left hand side. This is different from cPython.

----------
files: test.py
messages: 3020
nosy: henryl, pypy-issue
priority: bug
status: unread
title: Old style class equality test failure

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

From tracker at bugs.pypy.org  Fri Aug 26 11:25:07 2011
From: tracker at bugs.pypy.org (Henry Ludemann)
Date: Fri, 26 Aug 2011 09:25:07 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314350707.66.0.73490503281.issue847@bugs.pypy.org>


Henry Ludemann <misc at hl.id.au> added the comment:

Note that this works correctly for new style classes (ie: deriving 'A' and 'B'
from 'object' will cause the test to pass).

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

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

From tracker at bugs.pypy.org  Fri Aug 26 11:27:15 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 26 Aug 2011 09:27:15 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314350835.87.0.00370516595853.issue847@bugs.pypy.org>


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

Oooops.

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

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

From tracker at bugs.pypy.org  Fri Aug 26 11:27:58 2011
From: tracker at bugs.pypy.org (Henry Ludemann)
Date: Fri, 26 Aug 2011 09:27:58 +0000
Subject: [pypy-issue] [issue848] When calling 'dir',
	KeyError is incorrectly propagated
In-Reply-To: <1314350878.44.0.780263323483.issue848@bugs.pypy.org>
Message-ID: <1314350878.44.0.780263323483.issue848@bugs.pypy.org>


New submission from Henry Ludemann <misc at hl.id.au>:

In cPython, when calling 'dir' on an object that raises 'KeyError' from
'__getattr__, the exception is not propagated to client code. In pypy the
exception must be handled by client code.

----------
files: test2.py
messages: 3023
nosy: henryl, pypy-issue
priority: bug
status: unread
title: When calling 'dir', KeyError is incorrectly propagated

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

From tracker at bugs.pypy.org  Fri Aug 26 11:33:51 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 26 Aug 2011 09:33:51 +0000
Subject: [pypy-issue] [issue848] When calling 'dir',
	KeyError is incorrectly propagated
In-Reply-To: <1314350878.44.0.780263323483.issue848@bugs.pypy.org>
Message-ID: <1314351231.33.0.850217877946.issue848@bugs.pypy.org>


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

This random eating of exceptions is generally an implementation detail:
http://doc.pypy.org/en/latest/cpython_differences.html#ignored-exceptions .

It may be the case that dir() explicitly eats exceptions for a reason.  If you
can point out some CPython doc that says so, then we'd change our mind and copy
this behavior.

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

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

From tracker at bugs.pypy.org  Fri Aug 26 12:30:20 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 26 Aug 2011 10:30:20 +0000
Subject: [pypy-issue] [issue848] When calling 'dir',
	KeyError is incorrectly propagated
In-Reply-To: <1314350878.44.0.780263323483.issue848@bugs.pypy.org>
Message-ID: <1314354620.39.0.663425571618.issue848@bugs.pypy.org>


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

Did you try with CPython 2.7.2?
It's NEWS file says: 
"""
Correct lookup of __dir__ on objects. This allows old-style classes to have
__dir__. It also causes errors besides AttributeError found on lookup to be
propagated.
"""

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

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

From tracker at bugs.pypy.org  Fri Aug 26 14:16:43 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 26 Aug 2011 12:16:43 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314361003.61.0.542896376893.issue847@bugs.pypy.org>


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

I think we will classify this as a "wontfix".  I tried and failed to fix it, and
more importantly, it behaves differently if you have new-style classes instead
of old-style.  See https://bugs.pypy.org/issue412 for the kind of hassle that
"fixing" this would be.  It would really be an anti-fix, adding even more
special-cases in descroperation.py...

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

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

From tracker at bugs.pypy.org  Fri Aug 26 14:30:39 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 26 Aug 2011 12:30:39 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314361839.3.0.02100958152.issue847@bugs.pypy.org>


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

What about this patch? I found similar code in binop_impl, for example.

--- a/pypy/objspace/descroperation.py	Sun Aug 21 11:31:11 2011 +0200
+++ b/pypy/objspace/descroperation.py	Fri Aug 26 14:29:33 2011 +0200
@@ -731,6 +731,9 @@
             w_right_src, w_right_impl = space.lookup_in_type_where(w_typ2, right)
             # XXX see binop_impl
             if space.is_true(space.issubtype(w_typ2, w_typ1)):
+              if (w_left_src and w_right_src and
+                  not space.abstract_issubclass_w(w_left_src, w_right_src) and
+                  not space.abstract_issubclass_w(w_typ1, w_right_src)):
                 w_obj1, w_obj2 = w_obj2, w_obj1
                 w_left_impl, w_right_impl = w_right_impl, w_left_impl

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

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

From tracker at bugs.pypy.org  Fri Aug 26 14:40:16 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 26 Aug 2011 12:40:16 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314362416.18.0.210331386006.issue847@bugs.pypy.org>


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

Naive :-)  It fails some tests.  I'm still trying to build a working patch, even
though I said it would be invalid...

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

From tracker at bugs.pypy.org  Fri Aug 26 15:11:52 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 26 Aug 2011 13:11:52 +0000
Subject: [pypy-issue] [issue847] Old style class equality test failure
In-Reply-To: <1314350673.64.0.458538220583.issue847@bugs.pypy.org>
Message-ID: <1314364312.78.0.894165767547.issue847@bugs.pypy.org>


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

One problem is that the comparison operators behave subtly differently than the
other operations; that's why these three lines don't work for them.

For example, if class Base defines __eq__, and class Sub(Base) doesn't, then
Base() == Sub() will still be called first with the arguments switched; this is
different from e.g. __add__.

And of course this rule applies only to new-style classes, not to old-style
classes.  For old-style classes, instead, we have a 3rd version of the rule,
which is that the order to try both operations is never reversed by subclassing
relationships between operands.

I checked in something that seems to make my hopefully exhaustive tests happy...

----------
status: chatting -> testing

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

From tracker at bugs.pypy.org  Fri Aug 26 22:17:08 2011
From: tracker at bugs.pypy.org (Jonas H.)
Date: Fri, 26 Aug 2011 20:17:08 +0000
Subject: [pypy-issue] [issue733] bz2 decompression is very slow
In-Reply-To: <1306785194.2.0.717331507866.issue733@bugs.pypy.org>
Message-ID: <1314389828.89.0.123228671291.issue733@bugs.pypy.org>


Jonas H. <jonas at lophus.org> added the comment:

Here are some cProfile stats using PyPy and this benchmark script

    import os, tarfile, tempfile
    tarfile.open("x.tar.gz").extractall(tempfile.mkdtemp())

where "x.tar.gz" is created using

    apack x.tar.gz /opt/pypy/lib_pypy/

CPython 2.7.2 takes 0.8 seconds to decompress this whereas PyPy 1.6 takes 4 seconds.


$ pypy -m cProfile -s time bench.py
         498680 function calls (495247 primitive calls) in 4.027 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      2/1    0.698    0.349    3.666    3.666 tarfile.py:2025(extractall)
     2436    0.315    0.000    1.341    0.001 shutil.py:45(copyfileobj)
     6003    0.224    0.000    0.963    0.000 tarfile.py:798(read)
     2436    0.218    0.000    1.559    0.001 tarfile.py:259(copyfileobj)
    10207    0.206    0.000    0.206    0.000 {struct.unpack}
    22213    0.203    0.000    0.685    0.000 gzip.py:232(read)
     4311    0.200    0.000    0.200    0.000 {method 'decompress' of 'Decompress' objects}

  [...snip...]


Could we get this issue fixed sooner if I contributed a benchmark case for speed.pypy.org?

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

From tracker at bugs.pypy.org  Sat Aug 27 05:37:16 2011
From: tracker at bugs.pypy.org (Josh Ayers)
Date: Sat, 27 Aug 2011 03:37:16 +0000
Subject: [pypy-issue] [issue827] import xml.etree.cElementTree fails
In-Reply-To: <1313114876.32.0.380028080401.issue827@bugs.pypy.org>
Message-ID: <1314416236.09.0.150441321816.issue827@bugs.pypy.org>


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

I think the two APIs are identical.  The unit tests for cElementTree use the
same tests as the Python version.  Also, in the CPython documentation, there is
no separate documentation for the Python and C versions like there is for
StringIO and Pickle.  The latter two packages have some differences between the
C and Python versions, and it's noted in the docs.

Currently under PyPy, the tests for cElementTree fail because of the import
error noted below.  The test file is lib-python\2.7\test\test_xml_etree_c.py.  

Getting the tests to run is a little more difficult than I indicated in my
original post.  Several methods that aren't included in ElementTree's __all__
attribute need to be imported.  Importing everything manually allows the tests
to pass.  See the attached file, which would replace cElementTree.py.

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

From tracker at bugs.pypy.org  Sat Aug 27 13:00:55 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 27 Aug 2011 11:00:55 +0000
Subject: [pypy-issue] [issue841] [PATCH] Implement 'os.getlogin'
In-Reply-To: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>
Message-ID: <1314442855.72.0.304592567708.issue841@bugs.pypy.org>


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

"""if result is None:"""

This line is wrong.  'result' is a CCHARP here, so the line should check if it's
null instead.  That's done just by saying """if not result:"""

This small error very probably makes "translate.py" choke.  That's why you also
need to write a test in pypy/translator/c/test/test_extfunc.py.  It's important
enough that it's actually enough to rewrite a test in test_extfunc instead of in
test_ll_os.py.

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

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

From tracker at bugs.pypy.org  Sat Aug 27 22:03:01 2011
From: tracker at bugs.pypy.org (Mitchell Hashimoto)
Date: Sat, 27 Aug 2011 20:03:01 +0000
Subject: [pypy-issue] [issue841] [PATCH] Implement 'os.getlogin'
In-Reply-To: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>
Message-ID: <1314475381.83.0.878035365305.issue841@bugs.pypy.org>


Mitchell Hashimoto <mitchell.hashimoto at gmail.com> added the comment:

Armin,

I've taken your feedback into account and have attached a new patch (os-
getlogin3.patch) which has a test in test_extfunc and changes the NULL check to 
"if not result"

Note that I'm not sure how to properly test a failing case for getlogin(3), 
since it requires some fairly exceptional events to manifest, and I didn't see 
any examples for mocking/stubbing C APIs in the tests. 

Please let me know what else I can do to get this merged :)

Thanks!
Mitchell

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

From tracker at bugs.pypy.org  Sat Aug 27 22:52:05 2011
From: tracker at bugs.pypy.org (Mitchell Hashimoto)
Date: Sat, 27 Aug 2011 20:52:05 +0000
Subject: [pypy-issue] [issue841] [PATCH] Implement 'os.getlogin'
In-Reply-To: <1314013860.79.0.730409975023.issue841@bugs.pypy.org>
Message-ID: <1314478325.6.0.727116214583.issue841@bugs.pypy.org>


Mitchell Hashimoto <mitchell.hashimoto at gmail.com> added the comment:

Merged here:

https://bitbucket.org/pypy/pypy/changeset/9337dc94fb03

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

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

From tracker at bugs.pypy.org  Sun Aug 28 14:07:36 2011
From: tracker at bugs.pypy.org (Riaan Booysen)
Date: Sun, 28 Aug 2011 12:07:36 +0000
Subject: [pypy-issue] [issue849] pypy 1.6, pyglet crash on win32
In-Reply-To: <1314533256.76.0.0673329127649.issue849@bugs.pypy.org>
Message-ID: <1314533256.76.0.0673329127649.issue849@bugs.pypy.org>


New submission from Riaan Booysen <riaan at e.co.za>:

Every pyglet example immediately crashes pypyp 1.6 on win32, it worked ok under 
1.5 even tho it gave tons of warnings like RuntimeWarning: C function without 
declared return type called and RuntimeWarning: C function without declared return 
type called. (These warnings don't occur with cpython)

----------
messages: 3035
nosy: pypy-issue, riaan
priority: bug
status: unread
title: pypy 1.6, pyglet crash on win32

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

From tracker at bugs.pypy.org  Sun Aug 28 14:40:41 2011
From: tracker at bugs.pypy.org (matpow2)
Date: Sun, 28 Aug 2011 12:40:41 +0000
Subject: [pypy-issue] [issue849] pypy 1.6, pyglet crash on win32
In-Reply-To: <1314533256.76.0.0673329127649.issue849@bugs.pypy.org>
Message-ID: <1314535241.3.0.370497130564.issue849@bugs.pypy.org>


matpow2 <matpow2 at gmail.com> added the comment:

I'm having the same problems under win32 with pypy 1.6, where it segfaults every
time I import pyglet.gl. I've isolated the crash to cdll.getfunc, but if I make
a small example with the crashing cdll.getfunc('_glGetSeparableFilter at 36', [],
_ffi.types.slong) call, it doesn't happen.

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

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

From tracker at bugs.pypy.org  Sun Aug 28 20:58:45 2011
From: tracker at bugs.pypy.org (viblo)
Date: Sun, 28 Aug 2011 18:58:45 +0000
Subject: [pypy-issue] [issue850] ctypes: c struct in callback gives exception
In-Reply-To: <1314557925.51.0.561077027082.issue850@bugs.pypy.org>
Message-ID: <1314557925.51.0.561077027082.issue850@bugs.pypy.org>


New submission from viblo <pypy at viblo.se>:

When running the attached code in pypy-1.6, it fails with this exception:

ubuntu at ubuntu-desktop:/media/sf_progr/pypy_callbacktest$
~/pypy/pypy-1.6/bin/pypy callback_fail.py
  File "/home/ubuntu/pypy/pypy-1.6/lib_pypy/_ctypes/function.py", line 274, in f
    for argtype, arg in zip(argtypes, args)]
  File "/home/ubuntu/pypy/pypy-1.6/lib_pypy/_ctypes/structure.py", line 140, in
from_address
    instance.__dict__['_buffer'] = self._ffistruct.fromaddress(address)
TypeError: unsupported operand type for int(): 'StructureInstance'

----------
files: callback_fail.py
messages: 3037
nosy: pypy-issue, viblo
priority: bug
status: unread
title: ctypes: c struct in callback gives exception

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue850>
________________________________________
-------------- next part --------------
import ctypes
import os.path

path = os.path.dirname(os.path.abspath(__file__))
path = os.path.join(path, 'callback_fail.so') #insert c library here
lib = ctypes.cdll.LoadLibrary(path)
        
class vec1(ctypes.Structure):
    pass
vec1._fields_ = [('x', ctypes.c_float)]
callbackFunc = ctypes.CFUNCTYPE(None, ctypes.c_int, vec1)

doTest = lib.doTest
doTest.restype = None
doTest.argtypes = [callbackFunc]

def f(self, i,x):
    print "hello #" + str(i)
    print "x:" + str(x),x.x
    
class C:
    def doTest(self,f):
        def _impl(x,y):
            return f(self,x,y)
    
        doTest(callbackFunc(_impl))

c = C()
c.doTest(f)

From tracker at bugs.pypy.org  Sun Aug 28 21:00:38 2011
From: tracker at bugs.pypy.org (viblo)
Date: Sun, 28 Aug 2011 19:00:38 +0000
Subject: [pypy-issue] [issue850] ctypes: c struct in callback gives exception
In-Reply-To: <1314557925.51.0.561077027082.issue850@bugs.pypy.org>
Message-ID: <1314558038.43.0.228789788329.issue850@bugs.pypy.org>


viblo <pypy at viblo.se> added the comment:

Attached is the corresponding c library file. I should also add that the code
works fine on cpython.

(this bug stops pymunk from running on pypy)

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

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

From tracker at bugs.pypy.org  Mon Aug 29 02:17:57 2011
From: tracker at bugs.pypy.org (droid)
Date: Mon, 29 Aug 2011 00:17:57 +0000
Subject: [pypy-issue] [issue849] pypy 1.6, pyglet crash on win32
In-Reply-To: <1314533256.76.0.0673329127649.issue849@bugs.pypy.org>
Message-ID: <1314577077.31.0.845329899322.issue849@bugs.pypy.org>


droid <d.factorial at gmail.com> added the comment:

I also have had problems with pyglet. Many of the pyglet.* modules crash on 
load. Here are all the ones I found.

#failure 2:
>>>> import pyglet #ok
>>>> dir(pyglet) #ok
>>>> dir(pyglet.gl) #crash
>>>> dir(pyglet.app) #crash
>>>> dir(pyglet.font) #crash
>>>> dir(pyglet.graphics) #crash
>>>> dir(pyglet.image) #crash
>>>> dir(pyglet.media) #crash
>>>> dir(pyglet.sprite) #crash
>>>> dir(pyglet.text) #crash
>>>> dir(pyglet.window) #crash





I could get numpy building on my machine and start searching for the changeset 
that triggered it.

----------
nosy: +droid

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

From tracker at bugs.pypy.org  Mon Aug 29 05:03:46 2011
From: tracker at bugs.pypy.org (Henry Ludemann)
Date: Mon, 29 Aug 2011 03:03:46 +0000
Subject: [pypy-issue] [issue848] When calling 'dir',
	KeyError is incorrectly propagated
In-Reply-To: <1314350878.44.0.780263323483.issue848@bugs.pypy.org>
Message-ID: <1314587026.65.0.144362416772.issue848@bugs.pypy.org>


Henry Ludemann <misc at hl.id.au> added the comment:

Yep, I can confirm that the functionality on Python 2.7.2 has changed to
propagate the KeyError exception (matching the pypy functionality). I'll fix my
code; thanks for you help.

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

From tracker at bugs.pypy.org  Mon Aug 29 06:19:41 2011
From: tracker at bugs.pypy.org (anon)
Date: Mon, 29 Aug 2011 04:19:41 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1314591581.76.0.806634024115.issue819@bugs.pypy.org>


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

If you use an more efficient algorithm, such as Toom-Cook multiplication, it is
possible to be at least as fast as CPython.

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

From tracker at bugs.pypy.org  Mon Aug 29 06:26:00 2011
From: tracker at bugs.pypy.org (anon)
Date: Mon, 29 Aug 2011 04:26:00 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1314591960.26.0.59135185245.issue819@bugs.pypy.org>


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

If you use a more efficient algorithm, such as Toom-Cook multiplication, it is
possible to be at least as fast as CPython for large multiplication and powers.
See Wikipedia for a description of the algorithm. It's straight forward to
implement and a well-optimized implementation would make PyPy asymptotically
faster than CPython.

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

From tracker at bugs.pypy.org  Mon Aug 29 06:36:06 2011
From: tracker at bugs.pypy.org (anon)
Date: Mon, 29 Aug 2011 04:36:06 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1314592566.44.0.414634959439.issue819@bugs.pypy.org>


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

Also some cases can be optimized:

m = 1<<100000000
n = 2**100000000

m is instant to compute; n takes several seconds.

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

From tracker at bugs.pypy.org  Mon Aug 29 06:41:09 2011
From: tracker at bugs.pypy.org (anon)
Date: Mon, 29 Aug 2011 04:41:09 +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: <1314592869.4.0.0613723527312.issue851@bugs.pypy.org>


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

When dividing integers by powers of two, PyPy does not optimize the division
into a binary shift.

for i in range(10**8):
    j = i//2

can be written as

for i in range(10**8):
    j = i>>1

since we know i is an integer.

----------
messages: 3044
nosy: anon, pypy-issue
priority: wish
status: unread
title: PyPy does not optimize division into shifts

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

From tracker at bugs.pypy.org  Mon Aug 29 15:04:58 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 29 Aug 2011 13:04:58 +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: <1314623098.05.0.451057382866.issue851@bugs.pypy.org>


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

What makes you think so? It seems on the contrary that it does.

In pypy/jit/metainterp/optimizeopt/pypy/jit/metainterp/optimizeopt/rewrite.py, in optimize_INT_FLOORDIV():

        if v1.intbound.known_ge(IntBound(0, 0)) and v2.is_constant():
            val = v2.box.getint()
            if val & (val - 1) == 0 and val > 0: # val == 2**shift
                op = op.copy_and_change(rop.INT_RSHIFT,
                                        args = [op.getarg(0), ConstInt(highest_bit(val))])

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

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

From tracker at bugs.pypy.org  Mon Aug 29 15:49:55 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 29 Aug 2011 13:49:55 +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: <1314625795.43.0.290421636789.issue851@bugs.pypy.org>


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

The optimization only works if you know that 'i' is not negative.  In this
example, you don't know it a priori (because you compile only the loop, not the
"range(10**8)").  That's why it is not optimized.

It's most annoying because the Python-level i//2 is always equivalent to i>>1,
even for negative integers.  Here we are hit by the levels in-between: the
Python-level i//2 is turned into more complex code based on the C-level
division, which has different rounding behavior.

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

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

From tracker at bugs.pypy.org  Mon Aug 29 15:52:42 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 29 Aug 2011 13:52:42 +0000
Subject: [pypy-issue] [issue850] ctypes: c struct in callback gives exception
In-Reply-To: <1314557925.51.0.561077027082.issue850@bugs.pypy.org>
Message-ID: <1314625962.78.0.872826252024.issue850@bugs.pypy.org>


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

fixed by 21982a430a7e

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

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

From tracker at bugs.pypy.org  Mon Aug 29 16:37:44 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 29 Aug 2011 14:37:44 +0000
Subject: [pypy-issue] [issue849] pypy 1.6, pyglet crash on win32
In-Reply-To: <1314533256.76.0.0673329127649.issue849@bugs.pypy.org>
Message-ID: <1314628664.17.0.746885701978.issue849@bugs.pypy.org>


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

pyglet seems to work fine on linux, not sure what is the problem with win32. 
What do you mean by "crash"? It just segfaults or it tells something more helpful?

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

From tracker at bugs.pypy.org  Mon Aug 29 17:18:51 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 29 Aug 2011 15:18:51 +0000
Subject: [pypy-issue] [issue849] pypy 1.6, pyglet crash on win32
In-Reply-To: <1314533256.76.0.0673329127649.issue849@bugs.pypy.org>
Message-ID: <1314631131.26.0.500494346328.issue849@bugs.pypy.org>


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

Found to be (at least) caused by the calling convention: it is not propagated
down to the CALL_RELEASE_GIL in the JIT.  As proof, it seems to work when run
with "pypy --jit=off".

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

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

From tracker at bugs.pypy.org  Mon Aug 29 20:32:21 2011
From: tracker at bugs.pypy.org (yasirs)
Date: Mon, 29 Aug 2011 18:32:21 +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: <1314642741.04.0.531257492224.issue852@bugs.pypy.org>


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

If I have a slash newline in a docstring and then do from __future__ import
division, pypy halts while cpython27 is ok with it. File attached. I know from
__future__ is not needed in 2.7, but stuff like this needs to be fixed so pypy
works with existing libraries.

----------
files: aa.py
messages: 3050
nosy: pypy-issue, yasirs
priority: critical
status: unread
title: from __future__ : trunk gives error while cpython 2.7 runs ok

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

From tracker at bugs.pypy.org  Mon Aug 29 23:03:39 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 29 Aug 2011 21:03: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: <1314651819.6.0.00192404670335.issue853@bugs.pypy.org>


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

http://paste.pocoo.org/show/466726/ is the traceback, happens almost immediately, 
tests run fine on my system.

----------
messages: 3051
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: Django crashes almost immediately on trying to run the tests

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

From tracker at bugs.pypy.org  Tue Aug 30 01:52:43 2011
From: tracker at bugs.pypy.org (Alfredo Deza)
Date: Mon, 29 Aug 2011 23:52:43 +0000
Subject: [pypy-issue] [issue854] PyPy 1.6, 1.5 slower than CPython2.7,
	2.6 with Konira
In-Reply-To: <1314661963.52.0.917820701403.issue854@bugs.pypy.org>
Message-ID: <1314661963.52.0.917820701403.issue854@bugs.pypy.org>


New submission from Alfredo Deza <alfredodeza at gmail.com>:

Konira is a Python Testing DSL that "translates" the files via a Tokenizer 
function and later with `compile` and `exec`.

I've benchmarked Konira's own testing suite (203 tests) with PyPy 1.6 and 1.5 
and CPython2.7 and 2.6 (best out of three runs):

PyPy 1.5 = konira -d  0.39s user 0.03s system 98% cpu 0.430 total
PyPy 1.6 = konira -d  0.46s user 0.04s system 99% cpu 0.503 total
CPython 2.7 = konira -d  0.14s user 0.02s system 99% cpu 0.159 total
CPython 2.6 = konira -d  0.28s user 0.03s system 99% cpu 0.320 total

Virtualenvs where created like this for PyPy:

    virtualenv --no-site-packages -p `which pypy1.5` 
    virtualenv --no-site-packages -p `which pypy1.6`

And like this for CPython:

    virtualenv --no-site-packages

Konira should be installed via PIP and the actual project live in GitHub [0]. To 
test out the benchmarking numbers, you would need to checkout the konira 
project, have konira installed (via PIP or `setup.py install`) and run konira 
against it's own tests.

The `translation` module for Konira happens in 
`konira.collector.globals_from_file` if this is of interest. Any technical 
details or questions, please do not doubt in letting me know. 

Thanks for looking into this!

[0] https://github.com/alfredodeza/konira

----------
messages: 3052
nosy: alfredodeza, pypy-issue
priority: bug
status: unread
title: PyPy 1.6,1.5 slower than CPython2.7,2.6 with Konira

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

From tracker at bugs.pypy.org  Tue Aug 30 16:49:40 2011
From: tracker at bugs.pypy.org (Alfredo Deza)
Date: Tue, 30 Aug 2011 14:49:40 +0000
Subject: [pypy-issue] [issue854] PyPy 1.6, 1.5 slower than CPython2.7,
	2.6 with Konira
In-Reply-To: <1314661963.52.0.917820701403.issue854@bugs.pypy.org>
Message-ID: <1314715780.68.0.081619306822.issue854@bugs.pypy.org>


Alfredo Deza <alfredodeza at gmail.com> added the comment:

After doing some reading about things that make PyPy go slower (like using 
settrace which Konira does) I just want to note that although the code inspects 
the frames, it does so when there is an exception only.

The benchmarks I did where not raising exceptions, hence no stacktrace usage was 
triggered.

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

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

From tracker at bugs.pypy.org  Tue Aug 30 16:51:57 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 30 Aug 2011 14:51:57 +0000
Subject: [pypy-issue] [issue854] PyPy 1.6, 1.5 slower than CPython2.7,
	2.6 with Konira
In-Reply-To: <1314661963.52.0.917820701403.issue854@bugs.pypy.org>
Message-ID: <1314715917.59.0.266128784746.issue854@bugs.pypy.org>


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

You are benchmarking a testing suite.  That's known to take longer on PyPy than
on CPython.  The reason is that the JIT is bad in that case, because every test
runs different code all the time.

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

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

From tracker at bugs.pypy.org  Tue Aug 30 17:06:31 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 30 Aug 2011 15:06:31 +0000
Subject: [pypy-issue] [issue854] PyPy 1.6, 1.5 slower than CPython2.7,
	2.6 with Konira
In-Reply-To: <1314661963.52.0.917820701403.issue854@bugs.pypy.org>
Message-ID: <1314716791.72.0.678853745552.issue854@bugs.pypy.org>


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

you could try to run the testsuite N times in a row (inside the same process),
and see whether it gets faster after a while (as we expect)

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

From tracker at bugs.pypy.org  Tue Aug 30 17:21:49 2011
From: tracker at bugs.pypy.org (Alfredo Deza)
Date: Tue, 30 Aug 2011 15:21:49 +0000
Subject: [pypy-issue] [issue854] PyPy 1.6, 1.5 slower than CPython2.7,
	2.6 with Konira
In-Reply-To: <1314661963.52.0.917820701403.issue854@bugs.pypy.org>
Message-ID: <1314717709.55.0.995905296952.issue854@bugs.pypy.org>


Alfredo Deza <alfredodeza at gmail.com> added the comment:

If benchmarking a test suite is bad, maybe a single test is OK for proper 
benchmarking?

I guess I am confused about 'every test runs different code all the time' 
statement.

@antocuni would a shell script be a good idea for this? Like looping over the 
same command over and over again for N times?

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

From tracker at bugs.pypy.org  Tue Aug 30 17:22:55 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 30 Aug 2011 15:22:55 +0000
Subject: [pypy-issue] [issue854] PyPy 1.6, 1.5 slower than CPython2.7,
	2.6 with Konira
In-Reply-To: <1314661963.52.0.917820701403.issue854@bugs.pypy.org>
Message-ID: <1314717775.36.0.259019199577.issue854@bugs.pypy.org>


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

No, it must be run in the same process.  Otherwise the JIT-generated code is
thrown away every time.

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

From tracker at bugs.pypy.org  Tue Aug 30 18:09:53 2011
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 30 Aug 2011 16:09:53 +0000
Subject: [pypy-issue] [issue844] Circular import in ctypes.util
In-Reply-To: <1314293003.39.0.0373692844034.issue844@bugs.pypy.org>
Message-ID: <1314720593.39.0.0260080735219.issue844@bugs.pypy.org>


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

It should be fixed by cf154677dac2, however I cannot test it since I don't have
access to a mac. Could you please try to apply this patch and see if it's solved?
https://bitbucket.org/pypy/pypy/changeset/cf154677dac2

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

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