From tracker at bugs.pypy.org  Fri Jun  1 13:02:10 2012
From: tracker at bugs.pypy.org (Robert Hoelzl)
Date: Fri, 01 Jun 2012 11:02:10 +0000
Subject: [pypy-issue] [issue1157] PyPy crashes when translating itself with
	-O2 on win32
In-Reply-To: <1338548530.37.0.863109180447.issue1157@bugs.pypy.org>
Message-ID: <1338548530.37.0.863109180447.issue1157@bugs.pypy.org>


New submission from Robert Hoelzl <robert.hoelzl at gmx.de>:

I downloaded the source tarball of PyPy 1.8. Then I installed the official win32 
binary of PyPy 1.8 to translate 
the source tarball.

But when I try to translate the source tarball with "translate.py -O2" using the 
PyPy binary I get a windows 
segmnentation fault. It seems that the crash happens not always in the same stage 
(sometimes it happens after 
30min of translation and sometimes after 50min).

I tested and reproduced the problem on two Different systems:
 * Windows 7 SP1 64 bit (with 8 GByte Memory) + Visual C++ Express 2008 SP1
 * Windows 7 SP1 32 bit (with 4 GByte Memory) + Visual C++ Express 2008 SP1

When running "translate.py -Ojit" everything is fine.
When running "translate.py -O2" with CPython 2.7 (32bit) everyrhing is fine, too.

----------
messages: 4355
nosy: mrh1997, pypy-issue
priority: bug
release: 1.8
status: unread
title: PyPy crashes when translating itself with -O2 on win32

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

From tracker at bugs.pypy.org  Fri Jun  1 15:40:16 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 01 Jun 2012 13:40:16 +0000
Subject: [pypy-issue] [issue1151] numpypy: bug with array.dtype != object
In-Reply-To: <1337945774.95.0.713160069656.issue1151@bugs.pypy.org>
Message-ID: <1338558016.54.0.406728001971.issue1151@bugs.pypy.org>


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

This is a wontfix. We're not planning to implement object dtype and equality is 
implemented by converting the right hand argument first. You cannot just randomly 
compare it.

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

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

From tracker at bugs.pypy.org  Fri Jun  1 20:43:09 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Fri, 01 Jun 2012 18:43:09 +0000
Subject: [pypy-issue] [issue1154] IndexError in jitviewer
In-Reply-To: <1338227179.23.0.410269267737.issue1154@bugs.pypy.org>
Message-ID: <1338576189.66.0.102173017776.issue1154@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

Maybe it is a super stupid question, cause I am quite new to hg, but where can I 
get jitviewer trunk? 
I verified that if I use "release-1.8.x" branch of pypy repo, everything works. 
But I see only one branch in https://bitbucket.org/pypy/jitviewer - which I use, 
and its setup.py says it is version 0.1

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

From tracker at bugs.pypy.org  Sat Jun  2 20:53:40 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 02 Jun 2012 18:53:40 +0000
Subject: [pypy-issue] [issue1154] IndexError in jitviewer
In-Reply-To: <1338227179.23.0.410269267737.issue1154@bugs.pypy.org>
Message-ID: <1338663220.51.0.0166342555567.issue1154@bugs.pypy.org>


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

There is a release-0.1 tag. hg tags will display them to you. hg up <tagname> 
also works. Hg is made out of strange things, I'm also still learning.

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

From tracker at bugs.pypy.org  Sat Jun  2 22:09:14 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 02 Jun 2012 20:09:14 +0000
Subject: [pypy-issue] [issue1154] IndexError in jitviewer
In-Reply-To: <1338227179.23.0.410269267737.issue1154@bugs.pypy.org>
Message-ID: <1338667754.29.0.421468929274.issue1154@bugs.pypy.org>


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

Indeed, the README file should be updated and contain an explicit mapping of
versions --- e.g. that you need jitviewer at the release-0.1 tag to work with
PyPy 1.8.  I would also recommend to follow the version numbers of PyPy, e.g.
call the next one release-1.9 instead of release-0.2.

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

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

From tracker at bugs.pypy.org  Sun Jun  3 15:25:11 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 03 Jun 2012 13:25:11 +0000
Subject: [pypy-issue] [issue1157] PyPy crashes when translating itself with
	-O2 on win32
In-Reply-To: <1338548530.37.0.863109180447.issue1157@bugs.pypy.org>
Message-ID: <1338729911.74.0.910860618933.issue1157@bugs.pypy.org>


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

Hi Matti, can you have a look? It seems to be a bit serious

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

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

From tracker at bugs.pypy.org  Sun Jun  3 15:37:39 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 03 Jun 2012 13:37:39 +0000
Subject: [pypy-issue] [issue1051] PyPy 1.8 is 50% slower than 1.7
In-Reply-To: <1329331147.94.0.702203047702.issue1051@bugs.pypy.org>
Message-ID: <1338730659.28.0.85329236727.issue1051@bugs.pypy.org>


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

I measured now on Linux64 on tannit:

- pypy1.7: 20 seconds
- pypy1.8: 26 seconds
- trunk: 17 seconds

Of course I don't know if the particular problem was fixed, or if there is still
a factor 26/20 to be gained...  but I suppose we can say "fixed" unless someone
comes up with a different example.

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

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

From tracker at bugs.pypy.org  Sun Jun  3 16:10:48 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 03 Jun 2012 14:10:48 +0000
Subject: [pypy-issue] [issue1146] numpypy: bug with 1-d array of length 1
	.item()
In-Reply-To: <1337685931.94.0.807308630748.issue1146@bugs.pypy.org>
Message-ID: <1338732648.95.0.457788327686.issue1146@bugs.pypy.org>


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

Fixed in 244ef5a881e9

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

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

From tracker at bugs.pypy.org  Sun Jun  3 16:13:51 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 03 Jun 2012 14:13:51 +0000
Subject: [pypy-issue] [issue1012] numpypy: bug with dot
In-Reply-To: <1327143081.01.0.052194766213.issue1012@bugs.pypy.org>
Message-ID: <1338732831.34.0.911212535661.issue1012@bugs.pypy.org>


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

Works just like numpy for me. Feel free to reopen if it does not for you.

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

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

From tracker at bugs.pypy.org  Sun Jun  3 17:09:19 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 03 Jun 2012 15:09:19 +0000
Subject: [pypy-issue] [issue1148] numpypy: int64 is unhashable
In-Reply-To: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>
Message-ID: <1338736159.34.0.0552832812421.issue1148@bugs.pypy.org>


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

Fixed in 0a3cae6d204d

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

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

From tracker at bugs.pypy.org  Sun Jun  3 17:09:35 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 03 Jun 2012 15:09:35 +0000
Subject: [pypy-issue] [issue1152] numpy: int and int32 give different keys
	to dictionary
In-Reply-To: <1338074907.85.0.324002251477.issue1152@bugs.pypy.org>
Message-ID: <1338736175.33.0.248123095014.issue1152@bugs.pypy.org>


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

Fixed in 0a3cae6d204d

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

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

From tracker at bugs.pypy.org  Sun Jun  3 17:10:20 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 03 Jun 2012 15:10:20 +0000
Subject: [pypy-issue] [issue1088] numpypy array scalars do not hash nicely
In-Reply-To: <1331600712.72.0.0717696928313.issue1088@bugs.pypy.org>
Message-ID: <1338736220.94.0.114998591946.issue1088@bugs.pypy.org>


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

Fixed in 0a3cae6d204d

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

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

From tracker at bugs.pypy.org  Mon Jun  4 04:22:53 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 04 Jun 2012 02:22:53 +0000
Subject: [pypy-issue] [issue1144] numpypy: bug with np.all(True) and
	np.any(True)
In-Reply-To: <1337253656.73.0.97210490097.issue1144@bugs.pypy.org>
Message-ID: <1338776573.77.0.416145634959.issue1144@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Dupe of: https://bugs.pypy.org/issue1129  (numpypy reduce methods don't work with 
scalars)

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

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

From tracker at bugs.pypy.org  Mon Jun  4 06:37:02 2012
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 04 Jun 2012 04:37:02 +0000
Subject: [pypy-issue] [issue1157] PyPy crashes when translating itself with
	-O2 on win32
In-Reply-To: <1338548530.37.0.863109180447.issue1157@bugs.pypy.org>
Message-ID: <1338784622.74.0.0158928472419.issue1157@bugs.pypy.org>


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

I succeeded, no errors, with the command line
pypy.exe translate.py -O2 targetpypystandalone.py > build.log 2>&1
using pypy "Python 2.7.2 (30724af5224f, May 15 2012, 01:00:10)" and code base 
650162137831 so I'm closing. Feel free to reopen with more details if you can 
repeat with a more recent version. Please also follow the instructions at 
http://readthedocs.org/docs/pypy/en/latest/windows.html and attach the last 1000 
lines or so of the build.log

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

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

From tracker at bugs.pypy.org  Mon Jun  4 15:17:59 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 04 Jun 2012 13:17:59 +0000
Subject: [pypy-issue] [issue872] getpass.unix_getpass fails with "IOError:
	[Errno 29]	Illegal seek: '<fdopen>'"
In-Reply-To: <1316259307.04.0.352496531406.issue872@bugs.pypy.org>
Message-ID: <1338815879.89.0.459063697818.issue872@bugs.pypy.org>


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

Fix attempt in 865681d756a9.  The idea is that if lseek() fails in any flush*()
method, then we ignore it and don't do anything.  Wrote a test in test_posix2.py
that passes on CPython but used to fail on PyPy.

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

From tracker at bugs.pypy.org  Mon Jun  4 19:03:02 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 04 Jun 2012 17:03:02 +0000
Subject: [pypy-issue] [issue872] getpass.unix_getpass fails with "IOError:
	[Errno 29]	Illegal seek: '<fdopen>'"
In-Reply-To: <1316259307.04.0.352496531406.issue872@bugs.pypy.org>
Message-ID: <1338829382.23.0.225450326449.issue872@bugs.pypy.org>


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

seems to work, closing

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

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

From tracker at bugs.pypy.org  Mon Jun  4 23:09:55 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 04 Jun 2012 21:09:55 +0000
Subject: [pypy-issue] [issue1077] Comparison with tuples and more
In-Reply-To: <1330819950.05.0.0415056089507.issue1077@bugs.pypy.org>
Message-ID: <1338844195.47.0.0525295578318.issue1077@bugs.pypy.org>


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

Fixed in c85db2c2730e.

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

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

From tracker at bugs.pypy.org  Mon Jun  4 23:20:01 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 04 Jun 2012 21:20:01 +0000
Subject: [pypy-issue] [issue1067] Performance on Stack-Based VM machine
In-Reply-To: <1329857569.22.0.328879135116.issue1067@bugs.pypy.org>
Message-ID: <1338844801.8.0.696943460574.issue1067@bugs.pypy.org>


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

Indeed, running with the env var "PYPYLOG=jit-summary:-" shows that the JIT is
constantly trying to trace and optimize but runnng into "abort: bad loop".

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

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

From tracker at bugs.pypy.org  Thu Jun  7 06:10:16 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 07 Jun 2012 04:10:16 +0000
Subject: [pypy-issue] [issue1158] Different in custom list casting
In-Reply-To: <1339042216.14.0.354037603399.issue1158@bugs.pypy.org>
Message-ID: <1339042216.14.0.354037603399.issue1158@bugs.pypy.org>


New submission from mikefc <coolbutuseless at gmail.com>:

tos9 posted this snippeit to irc which behaves differently on pypy and cpython

==========================
class Foo(object):
    def __len__(self):
        raise Exception()
    def __iter__(self):
        return iter([])

list(Foo())
==========================

#############################################################################
# ipython2.7.2:
#############################################################################
In [1]: class Foo(object):
   ...:         def __len__(self):
   ...:                 raise Exception()
   ...:         def __iter__(self):
   ...:                 return iter([])
   ...:     

In [2]: list(Foo())
---------------------------------------------------------------------------
Exception                                 Traceback (most recent call last)
/Users/mike/<ipython-input-2-1282cd60499e> in <module>()
----> 1 list(Foo())

/Users/mike/<ipython-input-1-02f6df2fcbd9> in __len__(self)
      1 class Foo(object):
      2         def __len__(self):
----> 3                 raise Exception()
      4         def __iter__(self):
      5                 return iter([])

Exception: 

In [3]:


#############################################################################
# PyPy
#############################################################################
Python 2.7.2 (c6d48bfb9d2f, May 30 2012, 03:00:21)
[PyPy 1.9.1-dev0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``in pypy you are always at the
wrong level, in one way or the other''
>>>> class Foo(object):
....     def __len__(self):
....         raise Exception()
....     def __iter__(self):
....         return iter([])
.... 
>>>> list(Foo())
[]
>>>>

----------
messages: 4373
nosy: mikefc, pypy-issue
priority: bug
status: unread
title: Different in custom list casting

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

From tracker at bugs.pypy.org  Thu Jun  7 10:23:56 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Jun 2012 08:23:56 +0000
Subject: [pypy-issue] [issue1158] Different in custom list casting
In-Reply-To: <1339042216.14.0.354037603399.issue1158@bugs.pypy.org>
Message-ID: <1339057436.18.0.12956965635.issue1158@bugs.pypy.org>


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

That's a detail of CPython's implementation.  For example, if instead of raising
Exception you would raise AttributeError or TypeError, then CPython would eat it
and thus would behave the same as PyPy.  It is called by _PyObject_LengthHint().
 In case of PyPy, __len__() is not called at all.

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

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

From tracker at bugs.pypy.org  Thu Jun  7 10:51:51 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Jun 2012 08:51:51 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1339059111.32.0.507701884892.issue1139@bugs.pypy.org>


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

For me, the release candidate misbehaves as reported, but not "python
pypy/translator/goal/app_main.py".

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

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

From tracker at bugs.pypy.org  Thu Jun  7 11:11:46 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Jun 2012 09:11:46 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1339060306.52.0.415278145006.issue1139@bugs.pypy.org>


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

Attempted fix in 131735f133b5: don't call set_io_encoding() with
sys.getfilesystemencoding() on Windows.

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

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

From tracker at bugs.pypy.org  Thu Jun  7 11:20:55 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Jun 2012 09:20:55 +0000
Subject: [pypy-issue] [issue1158] Different in custom list casting
In-Reply-To: <1339042216.14.0.354037603399.issue1158@bugs.pypy.org>
Message-ID: <1339060855.34.0.468707384698.issue1158@bugs.pypy.org>


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

Resolved, by documenting it in pypy/doc/cpython_differences.rst (5c7fa43f9bb6).

----------
status: wontfix -> resolved

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

From tracker at bugs.pypy.org  Thu Jun  7 11:30:46 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 07 Jun 2012 09:30:46 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1339061446.22.0.886893043359.issue1139@bugs.pypy.org>


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

on Windows, GetConsoleCP() and GetConsoleOutputCP() should be used to get the 
proper encoding of the terminal.

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

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

From tracker at bugs.pypy.org  Thu Jun  7 11:56:02 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Jun 2012 09:56:02 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1339062962.09.0.77861022984.issue1139@bugs.pypy.org>


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

Indeed, I see it in the CPython 2.7 sources, but as it's not present in the
CPython 2.5 sources I thought that it was at least a good enough quick fix
before the release.

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

From tracker at bugs.pypy.org  Thu Jun  7 14:25:38 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Jun 2012 12:25:38 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1339071938.81.0.149589328655.issue1139@bugs.pypy.org>


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

It is still present in CPython 2.5, just somewhere else.

Fixed in 8d567513d04d, which will also be part of the upcoming release 1.9.

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

From tracker at bugs.pypy.org  Thu Jun  7 21:08:07 2012
From: tracker at bugs.pypy.org (mattip)
Date: Thu, 07 Jun 2012 19:08:07 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1339096087.6.0.912976819521.issue1139@bugs.pypy.org>


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

confirmed fixed in translated pypy

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

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

From tracker at bugs.pypy.org  Fri Jun  8 02:15:18 2012
From: tracker at bugs.pypy.org (mattip)
Date: Fri, 08 Jun 2012 00:15:18 +0000
Subject: [pypy-issue] [issue741] nightly build  for windows
In-Reply-To: <1307466265.62.0.905331161874.issue741@bugs.pypy.org>
Message-ID: <1339114518.94.0.474857816653.issue741@bugs.pypy.org>


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

Fixed, stale issue

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

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

From tracker at bugs.pypy.org  Fri Jun  8 14:21:51 2012
From: tracker at bugs.pypy.org (Guillaume Bouchard)
Date: Fri, 08 Jun 2012 12:21:51 +0000
Subject: [pypy-issue] [issue932] Python 1.7 slower on home made path tracing
	than 1.6
In-Reply-To: <1321885098.48.0.0523238945198.issue932@bugs.pypy.org>
Message-ID: <1339158111.53.0.139901316514.issue932@bugs.pypy.org>


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

1.9 is better now than what was 1.6 by a small amount.

% 14:17 guillaume at guillaume-desktop /tmp time ~/src/pypy/pypy-1.6/bin/pypy
smallpt.py 640 480 4
Rendering (4 spp) 99.84%~/src/pypy/pypy-1.6/bin/pypy smallpt.py 640 480 4 
42.09s user 0.14s system 95% cpu 44.015 total
% 14:18 guillaume at guillaume-desktop /tmp time ~/src/pypy/pypy-1.7/bin/pypy
smallpt.py 640 480 4
Rendering (4 spp) 99.84%~/src/pypy/pypy-1.7/bin/pypy smallpt.py 640 480 4 
58.52s user 0.11s system 97% cpu 1:00.28 total
% 14:19 guillaume at guillaume-desktop /tmp time ~/src/pypy/pypy-1.8/bin/pypy
smallpt.py 640 480 4
Rendering (4 spp) 99.84%~/src/pypy/pypy-1.8/bin/pypy smallpt.py 640 480 4 
49.30s user 0.14s system 96% cpu 51.201 total
% 14:20 guillaume at guillaume-desktop /tmp time ~/src/pypy/pypy-1.9/bin/pypy
smallpt.py 640 480 4
Rendering (4 spp) 99.84%~/src/pypy/pypy-1.9/bin/pypy smallpt.py 640 480 4 
43.72s user 0.08s system 99% cpu 43.854 total

----------
title: Python 1.7 slower on home maid path tracing than 1.6 -> Python 1.7 slower on home made path tracing than 1.6

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

From tracker at bugs.pypy.org  Fri Jun  8 14:36:53 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 08 Jun 2012 12:36:53 +0000
Subject: [pypy-issue] [issue932] Python 1.7 slower on home made path tracing
	than 1.6
In-Reply-To: <1321885098.48.0.0523238945198.issue932@bugs.pypy.org>
Message-ID: <1339159013.71.0.357372492437.issue932@bugs.pypy.org>


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

Closing then?

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

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

From tracker at bugs.pypy.org  Fri Jun  8 16:05:06 2012
From: tracker at bugs.pypy.org (Guillaume Bouchard)
Date: Fri, 08 Jun 2012 14:05:06 +0000
Subject: [pypy-issue] [issue932] Python 1.7 slower on home made path tracing
	than 1.6
In-Reply-To: <1321885098.48.0.0523238945198.issue932@bugs.pypy.org>
Message-ID: <1339164306.94.0.113379777748.issue932@bugs.pypy.org>


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

I'm wondering if the new time value is because the regression was corrected or
if the regression is still here but because pypy improves on many other points,
we may be able to make this code run far more quickly by fixing the regression.

But, yes, in some points, it make be closed.

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

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

From tracker at bugs.pypy.org  Fri Jun  8 16:08:11 2012
From: tracker at bugs.pypy.org (Dirkjan Ochtman)
Date: Fri, 08 Jun 2012 14:08:11 +0000
Subject: [pypy-issue] [issue1043] Failures when testing PyPy 1.8
In-Reply-To: <1329079915.12.0.549087979411.issue1043@bugs.pypy.org>
Message-ID: <1339164491.23.0.26760141303.issue1043@bugs.pypy.org>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Maybe it could get fixed, then? It still happens in 1.9.

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

From tracker at bugs.pypy.org  Fri Jun  8 16:18:59 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 08 Jun 2012 14:18:59 +0000
Subject: [pypy-issue] [issue1043] Failures when testing PyPy 1.8
In-Reply-To: <1329079915.12.0.549087979411.issue1043@bugs.pypy.org>
Message-ID: <1339165139.07.0.521348388943.issue1043@bugs.pypy.org>


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

Fixed the 3rd issue.  Ignoring the first two issues as a bug in the test that
comes straight from CPython.

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

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

From tracker at bugs.pypy.org  Fri Jun  8 17:35:38 2012
From: tracker at bugs.pypy.org (Dirkjan Ochtman)
Date: Fri, 08 Jun 2012 15:35:38 +0000
Subject: [pypy-issue] [issue1043] Failures when testing PyPy 1.8
In-Reply-To: <1329079915.12.0.549087979411.issue1043@bugs.pypy.org>
Message-ID: <1339169738.2.0.256533250079.issue1043@bugs.pypy.org>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

In 4151f9c406b6, for those keeping track.

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

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

From tracker at bugs.pypy.org  Sat Jun  9 04:36:05 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 09 Jun 2012 02:36:05 +0000
Subject: [pypy-issue] [issue1140] numpypy: slower than CPython NumPy on the
	vectorized code
In-Reply-To: <1336479741.43.0.520723870573.issue1140@bugs.pypy.org>
Message-ID: <1339209365.12.0.766177065702.issue1140@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Dmitrey, any chance you could get a more standalone example to include with this 
bug report?

Your link to DerApproximator.py is broken, and its unclear which function or 
functions is the cause of the slowdown?

If your bug can't easily be replicated, it's going to be very hard to fix.

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

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

From tracker at bugs.pypy.org  Sat Jun  9 08:01:54 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Sat, 09 Jun 2012 06:01:54 +0000
Subject: [pypy-issue] [issue1140] numpypy: slower than CPython NumPy on the
	vectorized code
In-Reply-To: <1336479741.43.0.520723870573.issue1140@bugs.pypy.org>
Message-ID: <1339221714.79.0.00209801643663.issue1140@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

the link is not broken, you should exclude "." from the end of it.
the cause of slowdown seems to be the vectorized func
vectorized_1 = lambda x: (x**2).sum()
(either pow or sum or both)

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

From tracker at bugs.pypy.org  Sat Jun  9 12:19:55 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 09 Jun 2012 10:19:55 +0000
Subject: [pypy-issue] [issue1087] Race condition when calling getattr
In-Reply-To: <1331583275.77.0.620668848256.issue1087@bugs.pypy.org>
Message-ID: <1339237195.53.0.17986271302.issue1087@bugs.pypy.org>


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

Checked in 4024e9cc54c6: fix it by just checking the status of the lock to know
if we can follow the fast path or not. With the GIL, there should be no race
conditions.  Wrote a test that passes on CPython and fails on PyPy.

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

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

From tracker at bugs.pypy.org  Sat Jun  9 17:53:00 2012
From: tracker at bugs.pypy.org (wilk)
Date: Sat, 09 Jun 2012 15:53:00 +0000
Subject: [pypy-issue] [issue1159] pypy-1.9 arguments during string formating
In-Reply-To: <1339257180.49.0.76338854545.issue1159@bugs.pypy.org>
Message-ID: <1339257180.49.0.76338854545.issue1159@bugs.pypy.org>


New submission from wilk <wilk at flibuste.net>:

Litle bug since 1.9 (tested with 1.7 1.8 cpython2.6 on linux 64bits)

# -*- encoding: utf8 -*-
'%d ? %%\r' % ( 1,)

TypeError: not all arguments converted during string formatting

----------
messages: 4392
nosy: pypy-issue, wilk
priority: bug
status: unread
title: pypy-1.9 arguments during string formating

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

From tracker at bugs.pypy.org  Sat Jun  9 17:58:42 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 09 Jun 2012 15:58:42 +0000
Subject: [pypy-issue] [issue1159] pypy-1.9 arguments during string formating
In-Reply-To: <1339257180.49.0.76338854545.issue1159@bugs.pypy.org>
Message-ID: <1339257522.06.0.0375832946558.issue1159@bugs.pypy.org>


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

# -*- encoding: utf8 -*-
print repr('%d ?? \n')

This should print '%d \xc3\xa0 \n', but with pypy 1.9 it prints '\xc3\xa0 \n'. 
No clue why so far...

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

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

From tracker at bugs.pypy.org  Sat Jun  9 23:46:50 2012
From: tracker at bugs.pypy.org (Peter)
Date: Sat, 09 Jun 2012 21:46:50 +0000
Subject: [pypy-issue] [issue1160] numpypy.int missing and numpy.integer
	doesn't work
In-Reply-To: <1339278410.23.0.627848163896.issue1160@bugs.pypy.org>
Message-ID: <1339278410.23.0.627848163896.issue1160@bugs.pypy.org>


New submission from Peter <p.j.a.cock at googlemail.com>:

Consider the following in C Python 2.6, running on 64 bit Max OS X, where I use several 
different aliases to create an array of 64 bit integers:

$ python
Python 2.7.1 (r271:86832, Jun 25 2011, 05:09:01) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__version__
'1.5.1'
>>> np.zeros([4,4], np.int)
array([[0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0]])
>>> np.zeros([4,4], np.int).dtype
dtype('int64')
>>> np.zeros([4,4], np.integer)
array([[0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0]])
>>> np.zeros([4,4], np.integer).dtype
dtype('int64')
>>> np.zeros([4,4], np.intp)
array([[0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0]])
>>> np.zeros([4,4], np.intp).dtype
dtype('int64')
>>> np.zeros([4,4], np.int64)
array([[0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0]])
>>> np.zeros([4,4], np.int64).dtype
dtype('int64')


All for datatypes work and (on this machine) give int64. Now using PyPy 1.9,

$ ~/Downloads/pypy-1.9/bin/pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``Python 2.x est presque mort, vive
Python!''
>>>> import numpypy
>>>> import numpy as np
>>>> np.zeros([4,4], np.int)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'module' object has no attribute 'int'

Try using integer:

>>>> np.zeros([4,4], np.integer)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: data type not understood


However the following do work:


>>>> np.zeros([4,4], np.intp)
array([[0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0]])
>>>> np.zeros([4,4], np.intp).dtype
dtype('int64')
>>>> np.zeros([4,4], np.int64)
array([[0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0]])
>>>> np.zeros([4,4], np.int64).dtype
dtype('int64')



Possibly related to issue 1023

----------
messages: 4394
nosy: peterjc, pypy-issue
priority: bug
release: 1.9
status: unread
title: numpypy.int missing and numpy.integer doesn't work

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

From tracker at bugs.pypy.org  Sat Jun  9 23:52:37 2012
From: tracker at bugs.pypy.org (Peter)
Date: Sat, 09 Jun 2012 21:52:37 +0000
Subject: [pypy-issue] [issue1161] numpypy.bool missing (numpy boolean dtype)
In-Reply-To: <1339278757.75.0.360606329263.issue1161@bugs.pypy.org>
Message-ID: <1339278757.75.0.360606329263.issue1161@bugs.pypy.org>


New submission from Peter <p.j.a.cock at googlemail.com>:

Here I am creating an array of booleans in NumPy,

$ python
Python 2.7.1 (r271:86832, Jun 25 2011, 05:09:01) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__version__
'1.5.1'
>>> np.zeros([4,4], np.bool)
array([[False, False, False, False],
       [False, False, False, False],
       [False, False, False, False],
       [False, False, False, False]], dtype=bool)
>>> np.zeros([4,4], np.bool).dtype
dtype('bool')


Under numpypy, the boolean datatype is missing:

$ ~/Downloads/pypy-1.9/bin/pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``pypy is a better kind of
foolishness - lac''
>>>> import numpypy
>>>> import numpy as np
>>>> np.zeros([4,4], np.bool)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'module' object has no attribute 'bool'



See also numpypy.int missing on issue 1160

----------
messages: 4395
nosy: peterjc, pypy-issue
priority: bug
status: unread
title: numpypy.bool missing (numpy boolean dtype)

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

From tracker at bugs.pypy.org  Sun Jun 10 00:31:08 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 09 Jun 2012 22:31:08 +0000
Subject: [pypy-issue] [issue1161] numpypy.bool missing (numpy boolean dtype)
In-Reply-To: <1339278757.75.0.360606329263.issue1161@bugs.pypy.org>
Message-ID: <1339281068.55.0.729576866992.issue1161@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

There is a "bool_" and an "int_" type, which do what you want. 

I don't know why they're named differently:

>>>> np.zeros([4,4], np.bool_)
array([[False, False, False, False],
       [False, False, False, False],
       [False, False, False, False],
       [False, False, False, False]], dtype=bool)


>>>> np.zeros([4,4], np.int_)
array([[0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0],
       [0, 0, 0, 0]])

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

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

From tracker at bugs.pypy.org  Sun Jun 10 01:03:41 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 09 Jun 2012 23:03:41 +0000
Subject: [pypy-issue] [issue1161] numpypy.bool missing (numpy boolean dtype)
In-Reply-To: <1339278757.75.0.360606329263.issue1161@bugs.pypy.org>
Message-ID: <1339283021.28.0.737330467147.issue1161@bugs.pypy.org>


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

AFAIK numpy.bool and numpy.int are the same as __builtin__.{bool,int}, we just 
need to re-export the names.

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

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

From tracker at bugs.pypy.org  Sun Jun 10 18:43:02 2012
From: tracker at bugs.pypy.org (Tobias Oberstein)
Date: Sun, 10 Jun 2012 16:43:02 +0000
Subject: [pypy-issue] [issue1162] Abort with OpenSSL and threads
In-Reply-To: <1339346582.88.0.843743823045.issue1162@bugs.pypy.org>
Message-ID: <1339346582.88.0.843743823045.issue1162@bugs.pypy.org>


New submission from Tobias Oberstein <tobias.oberstein at gmail.com>:

In a Twisted 12.1 server running under PyPy (trunk, as of June, 10th), which is
also using threads, the server aborts when accepting on a SSL socket:

Fatal error: pthread_mutex_lock(&mutex_gil)
Abort trap: 6

I have a stripped down 20 lines example which doesn't even involve Twisted:

https://github.com/oberstet/scratchbox/blob/master/python/twisted/pypybug1/testcase4.py

This example will behave as follows:

[autobahn at autobahnws ~/scm/scratchbox/python/twisted/pypybug1]$
~/python273/bin/python testcase4.py
foo() begin
import and create SSL begin
import and create SSL end
foo() end
[autobahn at autobahnws ~/scm/scratchbox/python/twisted/pypybug1]$ pypy testcase4.py
foo() begin
import and create SSL begin
Fatal error: pthread_mutex_lock(&mutex_gil)
Abort trap: 6
[autobahn at autobahnws ~/scm/scratchbox/python/twisted/pypybug1]$
~/python273/bin/python -V
Python 2.7.3
[autobahn at autobahnws ~/scm/scratchbox/python/twisted/pypybug1]$ pypy -V
Python 2.7.2 (12c1f0538f76, Jun 10 2012, 07:56:58)
[PyPy 1.9.1-dev0 with GCC 4.2.1]
[autobahn at autobahnws ~/scm/scratchbox/python/twisted/pypybug1]$ uname -a
FreeBSD autobahnws 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:15:25 UTC
2012     root at obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
[autobahn at autobahnws ~/scm/scratchbox/python/twisted/pypybug1]$


==

I _think_ this reproduces my actual problem I have when running under Twisted.

The issue involves the interaction between PyOpenSSL and PyPy .. not sure who is
guilty, but the issue does definitely not arise with CPython.

There was some discussion on IRC a couple of weeks ago where I raised the issue
.. I did more testing/experimenting .. but got nowhere.

My ultimate goal is to be able to run Twisted/kqueue on FreeBSD while using SSL
and threads. I need to use threads with Twisted since database access is done
from a thread pool (not the networking of course).

----------
messages: 4398
nosy: oberstet, pypy-issue
priority: bug
status: unread
title: Abort with OpenSSL and threads

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

From tracker at bugs.pypy.org  Sun Jun 10 21:56:59 2012
From: tracker at bugs.pypy.org (Tobias Oberstein)
Date: Sun, 10 Jun 2012 19:56:59 +0000
Subject: [pypy-issue] [issue1162] Abort with OpenSSL and threads
In-Reply-To: <1339346582.88.0.843743823045.issue1162@bugs.pypy.org>
Message-ID: <1339358219.21.0.667784425606.issue1162@bugs.pypy.org>


Tobias Oberstein <tobias.oberstein at gmail.com> added the comment:

Few more notes:

 - testcase4.py will abort on FreeBSD, and deadlock on Linux (using PyPy 1.9
Release)

 - testcase4.py can be made work by doing either of the following

    a) add a "_ssl.py" file with contents "raise ImportError"
    b) add a "import socket" line as the very first line

 - testcase.py will NOT work, even with the the a) and/or b) tricks

https://github.com/oberstet/scratchbox/blob/master/python/twisted/pypybug1/testcase.py

Hence, testcase.py should be considered.

testcase.py depends on Twisted. To install, get the following 2 and do a regular
"pypy setup.py install":

   
http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.8.0.tar.gz

    http://pypi.python.org/packages/source/T/Twisted/Twisted-12.1.0.tar.bz2

Then run

    pypy testcase.py pool ssl

and point your browser to 

    https://<IP>:8090

On Linux, this will deadlock, on FreeBSD abort.

If you leave out either "pool" or "ssl" from the command line, it will work.

"pool" will start a thread pool under the hood.

"ssl" will run HTTPS instead of HTTP, and thus involve OpenSSL.

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

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

From tracker at bugs.pypy.org  Mon Jun 11 00:55:29 2012
From: tracker at bugs.pypy.org (Mike Auty)
Date: Sun, 10 Jun 2012 22:55:29 +0000
Subject: [pypy-issue] [issue1163] __main__.UnrecognizedOperation: roundsd on
	amd64
In-Reply-To: <1339368929.12.0.927047530622.issue1163@bugs.pypy.org>
Message-ID: <1339368929.12.0.927047530622.issue1163@bugs.pypy.org>


New submission from Mike Auty <mike.auty at gmail.com>:

Hi there,

Just a quick note to say there's a build error on amd64 systems with an
UnrecognizedOperation: roundsd...

[translation:ERROR] 
/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/src/dtoa.c:132:0:
warning: "PyMem_Malloc" redefined [enabled by default]
[translation:ERROR] 
/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/module/cpyext/include/pymem.h:8:0:
note: this is the location of the previous definition
[translation:ERROR] 
/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/src/dtoa.c:133:0:
warning: "PyMem_Free" redefined [enabled by default]
[translation:ERROR] 
/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/module/cpyext/include/pymem.h:9:0:
note: this is the location of the previous definition
[translation:ERROR] 	Traceback (most recent call last):
[translation:ERROR] 	  File
"/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py",
line 2021, in <module>
[translation:ERROR] 	    tracker.process(f, g, filename=fn)
[translation:ERROR] 	  File
"/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py",
line 1914, in process
[translation:ERROR] 	    tracker = parser.process_function(lines, filename)
[translation:ERROR] 	  File
"/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py",
line 1429, in process_function
[translation:ERROR] 	    table = tracker.computegcmaptable(self.verbose)
[translation:ERROR] 	  File
"/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py",
line 52, in computegcmaptable
[translation:ERROR] 	    self.parse_instructions()
[translation:ERROR] 	  File
"/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py",
line 204, in parse_instructions
[translation:ERROR] 	    self.find_missing_visit_method(opname)
[translation:ERROR] 	  File
"/var/tmp/portage/dev-python/pypy-1.9/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py",
line 234, in find_missing_visit_method
[translation:ERROR] 	    raise UnrecognizedOperation(opname)
[translation:ERROR] 	__main__.UnrecognizedOperation: roundsd
[translation:ERROR] 	make: *** [module_micronumpy_types.gcmap] Error 1
[translation:ERROR] 	make: *** Waiting for unfinished jobs....
[translation:ERROR] 	""")

I had a similar problem with 1.8 and the vector v* functions.  I duplicated the
fix (adding roundsd to the ignored operators) and have attached the patch below.
 After the patch is applied 1.9 builds fine...

----------
files: 1.9-unknown-opcodes.patch
messages: 4400
nosy: ikelos, pypy-issue
priority: bug
release: 1.9
status: unread
title: __main__.UnrecognizedOperation: roundsd on amd64

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

From tracker at bugs.pypy.org  Mon Jun 11 10:12:58 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 11 Jun 2012 08:12:58 +0000
Subject: [pypy-issue] [issue1164] Call to get_python_lib(standard_lib=1)
	fails a test in	current rope tests
In-Reply-To: <1339402378.35.0.315363908059.issue1164@bugs.pypy.org>
Message-ID: <1339402378.35.0.315363908059.issue1164@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

This appears a pypy flaw, not a rope flaw.  On running the test suites of
rope-0.9.4, on last 3 pypy versions

ERROR: test_unknown_return_object (ropetest.builtinstest.BuiltinTypesTest)
----------------------------------------------------------------------


................................................................

  File "/usr/lib64/pypy1.8/lib-python/modified-2.7/distutils/sysconfig_pypy.py",
line 44, in get_python_lib
    "calls to get_python_lib(standard_lib=1) cannot succeed")
DistutilsPlatformError: calls to get_python_lib(standard_lib=1) cannot succeed

So; checking what occurs in a pypy interpreter;

 $ pypy-c1.8
Python 2.7.2 (2346207d99463f299f09f3e151c9d5fa9158f71b, Jun 08 2012, 16:07:25)
[PyPy 1.8.0 with GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``exarkun: "the part that I thought
was going to be hard was trivial, so now I just have this part that I didn't
even think of that is hard"''
>>>> import distutils.sysconfig as Sysc
>>>> Sysc.get_python_version()
'2.7'
>>>> Sysc.get_python_lib()
'/usr/lib64/pypy1.8/site-packages'
>>>> Sysc.get_python_lib(standard_lib=1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/lib64/pypy1.8/lib-python/modified-2.7/distutils/sysconfig_pypy.py",
line 44, in get_python_lib
    "calls to get_python_lib(standard_lib=1) cannot succeed")
DistutilsPlatformError: calls to get_python_lib(standard_lib=1) cannot succeed


So that confirms it running from the gentoo ebuild and from a pypy interpreter
itself.  The idential result also with pypy-1.9

----------
messages: 4401
nosy: idella5, pypy-issue
priority: performance bug
status: unread
title: Call to get_python_lib(standard_lib=1) fails a test in current rope tests

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

From tracker at bugs.pypy.org  Mon Jun 11 10:22:21 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 08:22:21 +0000
Subject: [pypy-issue] [issue1164] Call to get_python_lib(standard_lib=1)
	fails a test in	current rope tests
In-Reply-To: <1339402378.35.0.315363908059.issue1164@bugs.pypy.org>
Message-ID: <1339402941.65.0.925408210534.issue1164@bugs.pypy.org>


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

The message of the error tries to explain it: get_python_lib(standard_lib=1)
cannot succeed in PyPy, because there is no single directory that can be
considered as "the standard library".  So we just don't know what value to
return there.  In general it is known that not all features of distutils work on
PyPy.  It can be considered as a PyPy flaw (but we can also wonder why a normal
program would need it other than during complicated setup procedures).

It could be fixed in PyPy now that we no longer have three directories but only
two; we could just return the first of these, which still does not fully make
sense but at least more so than in PyPy <= 1.8.

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

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

From tracker at bugs.pypy.org  Mon Jun 11 10:28:40 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 08:28:40 +0000
Subject: [pypy-issue] [issue1164] Call to get_python_lib(standard_lib=1)
	fails a test in	current rope tests
In-Reply-To: <1339402378.35.0.315363908059.issue1164@bugs.pypy.org>
Message-ID: <1339403320.26.0.442079938825.issue1164@bugs.pypy.org>


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

Fixed in 04ea518e5b71.

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

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

From tracker at bugs.pypy.org  Mon Jun 11 10:34:06 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 08:34:06 +0000
Subject: [pypy-issue] [issue1163] __main__.UnrecognizedOperation: roundsd on
	amd64
In-Reply-To: <1339368929.12.0.927047530622.issue1163@bugs.pypy.org>
Message-ID: <1339403646.8.0.521041847335.issue1163@bugs.pypy.org>


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

Thanks!  'roundsd' is not even on my list of Intel ops, I guess it's a recent
addition.

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

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

From tracker at bugs.pypy.org  Mon Jun 11 11:05:17 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 09:05:17 +0000
Subject: [pypy-issue] [issue1159] pypy-1.9 arguments during string formating
In-Reply-To: <1339257180.49.0.76338854545.issue1159@bugs.pypy.org>
Message-ID: <1339405517.24.0.159667162883.issue1159@bugs.pypy.org>


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

Fixed in 287e0257dfd3, thanks.

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

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

From tracker at bugs.pypy.org  Mon Jun 11 11:21:37 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 11 Jun 2012 09:21:37 +0000
Subject: [pypy-issue] [issue1165] call to _RealGetContents from zipfile.py
	draws error in	tests
In-Reply-To: <1339406497.57.0.939869745147.issue1165@bugs.pypy.org>
Message-ID: <1339406497.57.0.939869745147.issue1165@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

I note you made an entry a couple of months ago re pypy managing zip files.
from the test suite of latest odfpy,.-0.9.4, 

--------------------------------------------------------------------------
 * Running testwrite.py ...
.E
======================================================================
ERROR: test_write (__main__.TestWrite)
document's write method
----------------------------------------------------------------------
Traceback (most recent call last):
  File "testwrite.py", line 40, in test_write
    z = zipfile.ZipFile(outfp,"r")
  File "/usr/lib64/pypy1.9/lib-python/2.7/zipfile.py", line 712, in __init__
    self._GetContents()
  File "/usr/lib64/pypy1.9/lib-python/2.7/zipfile.py", line 746, in _GetContents
    self._RealGetContents()
  File "/usr/lib64/pypy1.9/lib-python/2.7/zipfile.py", line 761, in _RealGetContents
    raise BadZipfile, "File is not a zip file"
BadZipfile: File is not a zip file

and to seal the deal, let's go to the source and do the test directly in
pypy-1.9's own interpeter;

archtester tests # pwd
/mnt/gen2/TmpDir/portage/dev-python/odfpy-0.9.4/work/odfpy-0.9.4/tests
archtester tests # PYTHONPATH=../ pypy-c1.9
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 10:32:11)
[PyPy 1.9.0 with GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``The extra blank lines that pypy
prints under windows come from distutils that does not find Visual Studio 6''
>>>> import unittest, os
>>>> import cStringIO
>>>> import zipfile
>>>> from odf.opendocument import OpenDocumentText
>>>> from odf import style, text
>>>> from odf.text import P
>>>> outfp = cStringIO.StringIO()
>>>> textdoc = OpenDocumentText()
>>>> p = P(text=u"?blegr?d")
>>>> p.addText(u' Bl?b?rgr?d')
>>>> textdoc.text.addElement(p)
>>>> textdoc.write(outfp)
>>>> outfp.seek(0)
>>>> z = zipfile.ZipFile(outfp,"r")
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/lib64/pypy1.9/lib-python/2.7/zipfile.py", line 712, in __init__
    self._GetContents()
  File "/usr/lib64/pypy1.9/lib-python/2.7/zipfile.py", line 746, in _GetContents
    self._RealGetContents()
  File "/usr/lib64/pypy1.9/lib-python/2.7/zipfile.py", line 761, in _RealGetContents
    raise BadZipfile, "File is not a zip file"
BadZipfile: File is not a zip file

Needles to say it passes fine with Cpython2..  I don't follow how the above code
results in a zip file, the files in the examples folder are files of extensions
odp && odt

----------
assignedto: amcnabb
messages: 4406
nosy: amcnabb, idella5, pypy-issue
priority: performance bug
release: 1.9
status: unread
title: call to _RealGetContents from zipfile.py draws error in tests

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

From tracker at bugs.pypy.org  Mon Jun 11 11:29:47 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 11 Jun 2012 09:29:47 +0000
Subject: [pypy-issue] [issue1164] Call to get_python_lib(standard_lib=1)
	fails a test in	current rope tests
In-Reply-To: <1339402378.35.0.315363908059.issue1164@bugs.pypy.org>
Message-ID: <1339406987.04.0.390470016675.issue1164@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

ah good thank you

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

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

From tracker at bugs.pypy.org  Mon Jun 11 11:40:16 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 09:40:16 +0000
Subject: [pypy-issue] [issue1165] call to _RealGetContents from zipfile.py
	draws error in	tests
In-Reply-To: <1339406497.57.0.939869745147.issue1165@bugs.pypy.org>
Message-ID: <1339407616.14.0.354325948975.issue1165@bugs.pypy.org>


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

This is a bug in odfpy, not in PyPy: in odf/opendocument.py line 409, in
write(), the opened ZipFile is never close()d.  It works on CPython because it
is closed automatically immediately, thanks to reference counting, and thus the
end of the zip file is written.  You don't have this effect with PyPy.  The fix
is to add "zipoutputfp.close()" in the end of the write() method.  If you can't
fix odfpy, a workaround is to do "import gc; gc.collect()" after the call to
write().

----------
nosy: +arigo
priority: performance bug -> bug
status: unread -> invalid

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

From tracker at bugs.pypy.org  Mon Jun 11 11:48:48 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 11 Jun 2012 09:48:48 +0000
Subject: [pypy-issue] [issue1165] call to _RealGetContents from zipfile.py
	draws error in	tests
In-Reply-To: <1339406497.57.0.939869745147.issue1165@bugs.pypy.org>
Message-ID: <1339408128.89.0.0147875751795.issue1165@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

ah so prompt. thank you

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

From tracker at bugs.pypy.org  Mon Jun 11 13:29:02 2012
From: tracker at bugs.pypy.org (Marien Zwart)
Date: Mon, 11 Jun 2012 11:29:02 +0000
Subject: [pypy-issue] [issue1167] signal.getsignal (check_signum)
	unnecessarily strict on	pypy versus cpython
In-Reply-To: <1339414142.54.0.24587511626.issue1167@bugs.pypy.org>
Message-ID: <1339414142.54.0.24587511626.issue1167@bugs.pypy.org>


New submission from Marien Zwart <marien.zwart at gmail.com>:

In cpython and older (<=1.8) pypy the check if a number is a valid signal number
is just a range check against 1 and NSIG. In recent (>=1.9) pypy it's a check
against a set of signal numbers that have a corresponding signal name. This
breaks the following code from Twisted 12.1.0 (_resetSignalDisposition in
process.py):

{{{
        for signalnum in range(1, signal.NSIG):
            if signal.getsignal(signalnum) == signal.SIG_IGN:
                # Reset signal handling to the default
                signal.signal(signalnum, signal.SIG_DFL)
}}}

Unless there is a reason for the check to be this strict that I am overlooking
it would be nice to revert back to the cpython-compatible check here.

----------
messages: 4411
nosy: marienz, pypy-issue
priority: bug
release: 1.9
status: unread
title: signal.getsignal (check_signum) unnecessarily strict on pypy versus cpython

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

From tracker at bugs.pypy.org  Mon Jun 11 13:59:05 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 11 Jun 2012 11:59:05 +0000
Subject: [pypy-issue] [issue1167] signal.getsignal (check_signum)
	unnecessarily strict on	pypy versus cpython
In-Reply-To: <1339414142.54.0.24587511626.issue1167@bugs.pypy.org>
Message-ID: <1339415945.84.0.000656293204225.issue1167@bugs.pypy.org>


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

On Windows, the C runtime aborts when signal() is called with an unsupported number, so a strict 
check is mandatory there.
However, this should apply only to Windows, and only to signal.signal (not signal.getsignal)

Matti, could you handle this?

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

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

From tracker at bugs.pypy.org  Mon Jun 11 15:30:45 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 11 Jun 2012 13:30:45 +0000
Subject: [pypy-issue] [issue1168] call to a_var.get_type() returns erroneous
	values in	rope's advanced_oi_test.py
In-Reply-To: <1339421445.71.0.0945925157479.issue1168@bugs.pypy.org>
Message-ID: <1339421445.71.0.0945925157479.issue1168@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

running pypy (latest 2 versions), it fails the enrire test files
advanced_oi_test.py of ropes test suite.

FAIL: test_a_function_with_different_returns
(ropetest.advanced_oi_test.DynamicOITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/rope-0.9.4/work/rope-0.9.4/ropetest/advanced_oi_test.py",
line 264, in test_a_function_with_different_returns
    self.assertEquals(c1_class, a_var.get_type())
AssertionError: <rope.base.pyobjectsdef.PyClass object at 0x00007f4a8eeda6e8> !=
<rope.base.pyobjects.PyObject object at 0x000000000496fb78>

FAIL: test_a_function_with_different_returns2
(ropetest.advanced_oi_test.DynamicOITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/rope-0.9.4/work/rope-0.9.4/ropetest/advanced_oi_test.py",
line 280, in test_a_function_with_different_returns2
    self.assertEquals(c1_class, a_var.get_type())
AssertionError: <rope.base.pyobjectsdef.PyClass object at 0x00007f4a8ee27cc8> !=
<rope.base.pyobjectsdef.PyClass object at 0x00007f4a8ee27d00>

======================================================================
FAIL: test_arguments_with_keywords (ropetest.advanced_oi_test.DynamicOITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/rope-0.9.4/work/rope-0.9.4/ropetest/advanced_oi_test.py",
line 249, in test_arguments_with_keywords
    self.assertEquals(c1_class, a_var.get_type())
AssertionError: <rope.base.pyobjectsdef.PyClass object at 0x00000000043fe838> !=
<rope.base.pyobjects.PyObject object at 0x000000000496fb78>

ad nauseum

----------
files: advanced_oi_test.py
messages: 4413
nosy: idella5, pypy-issue
priority: performance bug
release: 1.9
status: unread
title: call to a_var.get_type() returns erroneous values in rope's advanced_oi_test.py

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

From tracker at bugs.pypy.org  Mon Jun 11 15:35:58 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 13:35:58 +0000
Subject: [pypy-issue] [issue1168] call to a_var.get_type() returns erroneous
	values in	rope's advanced_oi_test.py
In-Reply-To: <1339421445.71.0.0945925157479.issue1168@bugs.pypy.org>
Message-ID: <1339421758.62.0.330490825969.issue1168@bugs.pypy.org>


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

This bug refers to the "rope-0.9.4" package.

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

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

From tracker at bugs.pypy.org  Mon Jun 11 17:31:01 2012
From: tracker at bugs.pypy.org (Zaar Hai)
Date: Mon, 11 Jun 2012 15:31:01 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1339428661.41.0.422839633443.issue1116@bugs.pypy.org>


Zaar Hai <haizaar at gmail.com> added the comment:

Just upgraded to pypy-1.9 and hit this issue as well.
Please see the log: http://pastebin.com/raw.php?i=yqUUQWGV

----------
nosy: +haizaar

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

From tracker at bugs.pypy.org  Mon Jun 11 17:41:48 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 15:41:48 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1339429308.11.0.364724169232.issue1116@bugs.pypy.org>


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

Should the autoflusher ignore all exceptions instead of just IOError and
ValueError?  (pypy/module/_io/interp_iobase.py:332)

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

From tracker at bugs.pypy.org  Mon Jun 11 17:42:35 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 11 Jun 2012 15:42:35 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1339429355.23.0.0854545295205.issue1116@bugs.pypy.org>


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

Is there any reason to use the auto-flusher, instead of just having the GC clean 
stuff up at the end of a process?

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

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

From tracker at bugs.pypy.org  Mon Jun 11 17:43:29 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 15:43:29 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1339429409.15.0.596329569888.issue1116@bugs.pypy.org>


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

alex: our GC will not automatically call __del__ at the end of a process.  We
need the auto-flusher to make sure that the written files are flushed.

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

From tracker at bugs.pypy.org  Mon Jun 11 18:06:59 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 11 Jun 2012 16:06:59 +0000
Subject: [pypy-issue] [issue1167] signal.getsignal (check_signum)
	unnecessarily strict on	pypy versus cpython
In-Reply-To: <1339414142.54.0.24587511626.issue1167@bugs.pypy.org>
Message-ID: <1339430819.44.0.559599870772.issue1167@bugs.pypy.org>


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

May be fixed in a33052b17f4e.  Can you check?

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

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

From tracker at bugs.pypy.org  Mon Jun 11 20:10:02 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 11 Jun 2012 18:10:02 +0000
Subject: [pypy-issue] [issue1169] call to callableObj from unittest/case.py
	leads to error	in httplib2 test
In-Reply-To: <1339438202.55.0.70821852335.issue1169@bugs.pypy.org>
Message-ID: <1339438202.55.0.70821852335.issue1169@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

fails in similar style in version 1.8 1.9.

package == httplib2-0.7.4.

testfile = python2/httplib2test.py

 * Testing of dev-python/httplib2-0.7.4 with CPython 2.6...
the python version == 2.6
/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4/build-2.6/lib
/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4
.......................................................................................................................
----------------------------------------------------------------------
Ran 119 tests in 93.145s

OK
 * Testing of dev-python/httplib2-0.7.4 with CPython 2.7...
the python version == 2.7
/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4/build-2.7/lib
/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4
.......................................................................................................................
----------------------------------------------------------------------
Ran 119 tests in 88.056s

OK
 * Testing of dev-python/httplib2-0.7.4 with PyPy 1.9 (Python 2.7)...
the python version == 1.9
/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4/build-2.7-pypy-1.9/lib
/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4
..............................................................................................E........................
======================================================================
ERROR: testSslCertValidation (__main__.HttpTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../../python2/httplib2test.py", line 478, in testSslCertValidation
    http.request, "https://www.google.com/", "GET")
  File "/usr/lib64/pypy1.9/lib-python/2.7/unittest/case.py", line 471, in
assertRaises
    callableObj(*args, **kwargs)
  File
"/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4/python2/httplib2/__init__.py",
line 1544, in request
    (response, content) = self._request(conn, authority, uri, request_uri,
method, body, headers, redirections, cachekey)
  File
"/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4/python2/httplib2/__init__.py",
line 1294, in _request
    (response, content) = self._conn_request(conn, request_uri, method, body,
headers)
  File
"/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4/python2/httplib2/__init__.py",
line 1230, in _conn_request
    conn.connect()
  File
"/mnt/gen2/TmpDir/portage/dev-python/httplib2-0.7.4/work/httplib2-0.7.4/python2/httplib2/__init__.py",
line 1005, in connect
    raise SSLHandshakeError(e)
SSLHandshakeError: [Errno 1] error:02001002:system library:fopen:No such file or
directory

----------------------------------------------------------------------
Ran 119 tests in 88.034s

FAILED (errors=1)

so passes with Cpythons and just 1 test it fails in the testfile which I have
included

----------
assignedto: arigo
files: httplib2test.py
messages: 4420
nosy: arigo, idella5, pypy-issue
priority: performance bug
release: 1.9
status: chatting
title: call to callableObj from unittest/case.py leads to error in httplib2 test

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

From tracker at bugs.pypy.org  Mon Jun 11 23:23:22 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 11 Jun 2012 21:23:22 +0000
Subject: [pypy-issue] [issue1169] call to callableObj from unittest/case.py
	leads to error	in httplib2 test
In-Reply-To: <1339438202.55.0.70821852335.issue1169@bugs.pypy.org>
Message-ID: <1339449802.09.0.317184199715.issue1169@bugs.pypy.org>


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

pypy was using ERR_get_error() instead of ERR_peek_last_error() for certificates 
errors. Fixed in 25d3418150d2

----------
assignedto: arigo -> afa
nosy: +afa
priority: performance bug -> bug
status: chatting -> resolved

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

From tracker at bugs.pypy.org  Tue Jun 12 08:59:58 2012
From: tracker at bugs.pypy.org (zzz654321)
Date: Tue, 12 Jun 2012 06:59:58 +0000
Subject: [pypy-issue] [issue1170] pi.py run too slow
In-Reply-To: <1339484398.92.0.706624844727.issue1170@bugs.pypy.org>
Message-ID: <1339484398.92.0.706624844727.issue1170@bugs.pypy.org>


New submission from zzz654321 <lightdarkadmin at 163.com>:

cmd line:
pypy pi.py 4000 > pi.txt

python 2.4 + psyco 7.0 sec
python 2.7 + psyco 4.7 sec
pypy 1.9 (1.8) 14.3 sec 

I don't known be at the bottom of the problem .

----------
files: pi.py
messages: 4422
nosy: pypy-issue, zzz654321
priority: performance bug
status: unread
title: pi.py run too slow

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1170>
________________________________________
-------------- next part --------------
#! /usr/bin/env python 
# -*- coding: cp936 -*- 

import sys, time 

def f(q, r, t, k ): 
	n= (3* q+ r )/ t 
	if (4* q+ r )/ t== n: 
		return (10* q, 
				10* (r- n* t ), 
				t, 
				k, 
				n ) 
	else: 
		return (q* k, 
				q* (4* k+ 2 )+ r* (2* k+ 1 ), 
				t* (2* k+ 1 ), 
				k+ 1 ) 

def pi(n = -1): 
	'???? PI, ????????????????????????????' 
	out = '' 
	if(0>= n ): 
		n= 100 
	n= n+ 1 
	r = f(1, 0, 1, 1 ) 
	while(n ): 
		if(len(r )== 5 ): 
			out= out+ str(r[4 ] ) 
			n= n- 1 
		r= f(r[0 ], r[0x01 ], r[0x02 ], r[0x03 ] ) 
	out= out[0 ]+ '.'+ out[1: ] 
	return out 

class a1: 
	aaa= 0 
	
	def __init__(self ): 
		self.bbb= () 
	def f1(self ): 
		print "[", self.aaa, "]" 
	
class b1(a1 ): 
	
	def __init__(self ): 
		a1.__init__(self ) 
		print self.aaa, self.bbb 
	def f2(self ): 
		print "[", self.bbb, "]" 

try: 
	#import psyco 
	psyco.bind(f ) 
	psyco.bind(pi ) 
except: pass 

if __name__== '__main__': 
	t01= time.time() 
	n= 2000 
	if(2<= len(sys.argv ) ): 
		n= int(sys.argv[1 ] ) 
	print pi(n ) 
	print time.time()- t01 
	#a2= b1() 
	#a2.f1() 


From tracker at bugs.pypy.org  Tue Jun 12 09:36:27 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 12 Jun 2012 07:36:27 +0000
Subject: [pypy-issue] [issue1170] pi.py run too slow
In-Reply-To: <1339484398.92.0.706624844727.issue1170@bugs.pypy.org>
Message-ID: <1339486587.44.0.472918623124.issue1170@bugs.pypy.org>


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

You use string concatenation with +. This is not known to work very well, because 
on CPython there is a trick what to do if refcount is 1. Please consider using 
some other option of string building, like cStringIO or a list and ''.join(...).

Closing as wontfix

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

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

From tracker at bugs.pypy.org  Tue Jun 12 09:47:58 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 12 Jun 2012 07:47:58 +0000
Subject: [pypy-issue] [issue1170] pi.py run too slow
In-Reply-To: <1339484398.92.0.706624844727.issue1170@bugs.pypy.org>
Message-ID: <1339487278.09.0.0987855525556.issue1170@bugs.pypy.org>


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

Actually, the string concatenation only takes 6ms...
But numbers passed to the f() function become very long, and operations on long 
type is known to be slower in pypy.

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

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

From tracker at bugs.pypy.org  Tue Jun 12 13:02:38 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 12 Jun 2012 11:02:38 +0000
Subject: [pypy-issue] [issue1170] pi.py run too slow
In-Reply-To: <1339484398.92.0.706624844727.issue1170@bugs.pypy.org>
Message-ID: <1339498958.64.0.767474612752.issue1170@bugs.pypy.org>


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

So this is instead a duplicate of issue892 ?

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

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

From tracker at bugs.pypy.org  Tue Jun 12 17:36:43 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 12 Jun 2012 15:36:43 +0000
Subject: [pypy-issue] [issue1171] call to import pypy's own
	test.test_audioop yields no can	do
In-Reply-To: <1339515403.59.0.346168630504.issue1171@bugs.pypy.org>
Message-ID: <1339515403.59.0.346168630504.issue1171@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

another one to the list.
tests in mechanize(-0.2.5) sees pypy failing to import its own module.

from mechanize-0.2.5/test/test_unittest.py;

    def test_loadTestsFromName__module_not_loaded(self):
        # We're going to try to load this module as a side-effect, so it
        # better not be loaded before we try.
        #
        # Why pick audioop? Google shows it isn't used very often, so there's
        # a good chance that it won't be imported when this test is run
        module_name = 'audioop'

        import sys


It occurs twice in 2 tests of similar names;
test_loadTestsFromName__module_not_loaded
test_loadTestsFromNames__module_not_loaded

I tried it in a pypy interpreter and was amazed to find it to import only a
handful of modules from the folder
/usr/lib64/pypy1.8/lib-python/2.7/test/

It definitely can't manage it.
from the irc:#pypy

<ronny> idella5: seems like without a working audioop module one cant import it

----------
messages: 4426
nosy: idella5, pypy-issue
priority: performance bug
release: 1.9
status: chatting
title: call to import pypy's own test.test_audioop yields no can do

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

From tracker at bugs.pypy.org  Tue Jun 12 17:50:42 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 12 Jun 2012 15:50:42 +0000
Subject: [pypy-issue] [issue1172] call to print samples in pypy's doctests
	errors in	mechanize's test_browser.doctest
In-Reply-To: <1339516242.65.0.106716495289.issue1172@bugs.pypy.org>
Message-ID: <1339516242.65.0.106716495289.issue1172@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

running pypy in mechanize(-0.2.5) tests.
A failure results in the doctest portion of the suite.

It bailed out on 3 instances of the 1 expected response.

from  test/test_browser.doctest

>>> br = TestHttpBrowser()
>>> r = br.open("http://example.com")
>>> print response_impl(r)
StringI
>>> r2 = br.open("http://example.com")
>>> print response_impl(r2)
StringI
>>> print response_impl(r)
eofresponse

So should .set_response()

>>> br.set_response(test_response())
>>> print response_impl(r2)
eofresponse


.visit_response() works very similarly to .open()

>>> br = TestHttpBrowser()
>>> r = br.open("http://example.com")
>>> r2 = test_response(url="http://example.com/2")
>>> print response_impl(r2)
StringI

when tun yields

FAIL: Doctest: test_browser.doctest
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test-tools/doctest.py", line 2178, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for test_browser.doctest
  File
"/mnt/gen2/TmpDir/portage/dev-python/mechanize-0.2.5/work/mechanize-0.2.5/test/test_browser.doctest",
line 0

----------------------------------------------------------------------
File
"/mnt/gen2/TmpDir/portage/dev-python/mechanize-0.2.5/work/mechanize-0.2.5/test/test_browser.doctest",
line 20, in test_browser.doctest
Failed example:
    print response_impl(r)
Expected:
    StringI
Got:
    cStringIO.StringI
----------------------------------------------------------------------
File
"/mnt/gen2/TmpDir/portage/dev-python/mechanize-0.2.5/work/mechanize-0.2.5/test/test_browser.doctest",
line 23, in test_browser.doctest
Failed example:
    print response_impl(r2)
Expected:
    StringI
Got:
    cStringIO.StringI
----------------------------------------------------------------------
File
"/mnt/gen2/TmpDir/portage/dev-python/mechanize-0.2.5/work/mechanize-0.2.5/test/test_browser.doctest",
line 40, in test_browser.doctest
Failed example:
    print response_impl(r2)
Expected:
    StringI
Got:
    cStringIO.StringI

and sure enough; go into an interpreter and repeat the tested samples

testuser at archtester ~ # pypy-c1.8(or 9)

>>>> import mechanize
>>>> from mechanize._response import test_response
>>>> from test.test_browser import TestBrowser2, make_mock_handler
>>>>
>>>> class TestHttpHandler(mechanize.BaseHandler):
....     def http_open(self, request):
....         return test_response(url=request.get_full_url())
>>>> class TestHttpHandler(mechanize.BaseHandler):
....     def http_open(self, request):
....         return test_response(url=request.get_full_url())
>>>> class TestHttpHandler(mechanize.BaseHandler):
....     def http_open(self, request):
....         return test_response(url=request.get_full_url())
....
>>>> class TestHttpBrowser(TestBrowser2):
....     handler_classes = TestBrowser2.handler_classes.copy()
....     handler_classes["http"] = TestHttpHandler
....     default_schemes = ["http"]
....
>>>> def response_impl(response):
....     return response.wrapped.fp.__class__.__name__
....
>>>> br = TestHttpBrowser()
>>>> r = br.open("http://example.com")
>>>> print response_impl(r)
cStringIO.StringI
>>>> r2 = br.open("http://example.com")
>>>> print response_impl(r2)
cStringIO.StringI
>>>> print response_impl(r)
eofresponse
>>>> br = TestHttpBrowser()
>>>> r = br.open("http://example.com")
>>>> r2 = test_response(url="http://example.com/2")
>>>> print response_impl(r2)
cStringIO.StringI

----------
assignedto: arigo
files: test_browser.doctest
messages: 4427
nosy: arigo, idella5, pypy-issue
priority: performance bug
release: 1.9
status: chatting
title: call to print samples in pypy's doctests errors in mechanize's test_browser.doctest

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

From tracker at bugs.pypy.org  Tue Jun 12 17:55:36 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 12 Jun 2012 15:55:36 +0000
Subject: [pypy-issue] [issue1172] call to print samples in pypy's doctests
	errors in	mechanize's test_browser.doctest
In-Reply-To: <1339516242.65.0.106716495289.issue1172@bugs.pypy.org>
Message-ID: <1339516536.88.0.841830382944.issue1172@bugs.pypy.org>


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

Should be fixed by f04cd8c5ccfb.

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

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

From tracker at bugs.pypy.org  Tue Jun 12 17:58:19 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 12 Jun 2012 15:58:19 +0000
Subject: [pypy-issue] [issue1172] call to print samples in pypy's doctests
	errors in	mechanize's test_browser.doctest
In-Reply-To: <1339516242.65.0.106716495289.issue1172@bugs.pypy.org>
Message-ID: <1339516699.97.0.496528841953.issue1172@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

thanks

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

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

From tracker at bugs.pypy.org  Tue Jun 12 18:03:12 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 12 Jun 2012 16:03:12 +0000
Subject: [pypy-issue] [issue1171] call to import pypy's own
	test.test_audioop yields no can	do
In-Reply-To: <1339515403.59.0.346168630504.issue1171@bugs.pypy.org>
Message-ID: <1339516992.67.0.0222807990289.issue1171@bugs.pypy.org>


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

Yes, the audioop module is not implemented in pypy.

> I tried it in a pypy interpreter and was amazed to find it to import
> only a handful of modules from the folder

What did you try exactly? I could import many modules:
$ ~/pypy/pypy-1.8/bin/pypy
>>>> import test.test_unicode
>>>> import test.test_socket
>>>> import test.test_os

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

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

From tracker at bugs.pypy.org  Tue Jun 12 18:24:05 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 12 Jun 2012 16:24:05 +0000
Subject: [pypy-issue] [issue1171] call to import pypy's own
	test.test_audioop yields no can	do
In-Reply-To: <1339515403.59.0.346168630504.issue1171@bugs.pypy.org>
Message-ID: <1339518245.03.0.43666344916.issue1171@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

SyntaxError: invalid syntax
>>>> import test.test_unicode
>>>> import test.test_socket
>>>> import test.test_os
>>>> import atexit
>>>> import test.atexit
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ImportError: No module named test.atexit
>>>> import test.test_bastion
>>>> import test.bigaddrspace
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ImportError: No module named test.bigaddrspace
>>>> import test.test_bigaddrspace
>>>> import test.test_bigmem
>>>> import test.test_crypt
>>>> import test.test_atexit
>>>> 

sure; some of my attempts were like import test.bigaddrspace
Seeing the import attempted import audioop 
rather than 
import test.test_audioop

It made me lean towards thinking pypy has some internal workings culling the
prefix syntax test_ and or test.test__
but no.

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

From tracker at bugs.pypy.org  Tue Jun 12 18:56:27 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 12 Jun 2012 16:56:27 +0000
Subject: [pypy-issue] [issue1171] call to import pypy's own
	test.test_audioop yields no can	do
In-Reply-To: <1339515403.59.0.346168630504.issue1171@bugs.pypy.org>
Message-ID: <1339520187.93.0.760214101052.issue1171@bugs.pypy.org>


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

But there is no module test.bigaddrspace (try with CPython). What are you trying 
to do?
Note that "import atexit" and "import test.test_atexit" import completely 
different modules.  Surely test_atexit contains unit tests for atexit, and will 
also import it.  But it does not mean that test.atexit is a module.

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

From tracker at bugs.pypy.org  Tue Jun 12 19:53:54 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 12 Jun 2012 17:53:54 +0000
Subject: [pypy-issue] [issue1173] call to get_template() in pypy's doctest
	can't find	template
In-Reply-To: <1339523634.98.0.147877273045.issue1173@bugs.pypy.org>
Message-ID: <1339523634.98.0.147877273045.issue1173@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

1 single failed test in the 277 tests of jinja's testsuite. (-2.6)
Remember I am quite the pypy novice so I can't interpret this error as yet.
I would like to offer a better insight, but am relying on devs here.

FileSystemBytecodeCache (jinja2.bccache)
Doctest: jinja2.bccache.FileSystemBytecodeCache ... ok

======================================================================
ERROR: test_byte_compilation (jinja2.testsuite.loader.ModuleLoaderTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6/work/Jinja2-2.6/jinja2/testsuite/loader.py",
line 180, in test_byte_compilation
    tmpl1 = self.mod_env.get_template('a/test.html')
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6/work/Jinja2-2.6/jinja2/environment.py",
line 719, in get_template
    return self._load_template(name, self.make_globals(globals))
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6/work/Jinja2-2.6/jinja2/environment.py",
line 693, in _load_template
    template = self.loader.load(self, name, globals)
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6/work/Jinja2-2.6/jinja2/loaders.py",
line 443, in load
    raise TemplateNotFound(name)
TemplateNotFound: a/test.html

----------------------------------------------------------------------
Ran 277 tests in 4.204s

here are located 2 test.html files.
archtester jinja # find 
/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6/work/Jinja2-2.6/jinja2/ -name
test.html
/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6/work/Jinja2-2.6/jinja2/testsuite/res/templates/foo/test.html
/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6/work/Jinja2-2.6/jinja2/testsuite/res/templates/test.html

here is the test

    def test_byte_compilation(self):
        log = self.compile_down(py_compile=True)
        assert 'Byte-compiled "a/test.html"' in log
        tmpl1 = self.mod_env.get_template('a/test.html')
        mod = self.mod_env.loader.module. \
            tmpl_3c4ddf650c1a73df961a6d3d2ce2752f1b8fd490
       assert mod.__file__.endswith('.pyc')

Now I have no idea of what a/ represents in python, but it seems it can't be a
folder a/ since there is not one of them.  line 180, in test_byte_compilation
points to 

tmpl1 = self.mod_env.get_template('a/test.html')
\
python2s pass this test no issue. The test is testing  byte_compilation but I
suppose it never gets far enough to test it not finding the template file.

Included the file Jinja2-2.6/jinja2/testsuite/loader.py which hosts the test.

thx

----------
files: loader.py
messages: 4433
nosy: idella5, pypy-issue
priority: bug
release: 1.9
status: chatting
title: call to get_template() in pypy's doctest can't find template

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

From tracker at bugs.pypy.org  Tue Jun 12 20:03:14 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 12 Jun 2012 18:03:14 +0000
Subject: [pypy-issue] [issue1171] call to import pypy's own
	test.test_audioop yields no can	do
In-Reply-To: <1339515403.59.0.346168630504.issue1171@bugs.pypy.org>
Message-ID: <1339524194.32.0.552260727124.issue1171@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

What are you trying to do?

learn some pypy basics

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

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

From tracker at bugs.pypy.org  Tue Jun 12 21:50:12 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Tue, 12 Jun 2012 19:50:12 +0000
Subject: [pypy-issue] [issue1174] better docs for the vendor/stdlib branch
In-Reply-To: <1339530612.18.0.838794372112.issue1174@bugs.pypy.org>
Message-ID: <1339530612.18.0.838794372112.issue1174@bugs.pypy.org>


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

the docs suck, we lack references, thus a core dev started the wrong way for a
stdlib upgrade

----------
assignedto: ronny
messages: 4435
nosy: pypy-issue, ronny
priority: critical
status: unread
title: better docs for the vendor/stdlib branch

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

From tracker at bugs.pypy.org  Wed Jun 13 17:15:55 2012
From: tracker at bugs.pypy.org (Marien Zwart)
Date: Wed, 13 Jun 2012 15:15:55 +0000
Subject: [pypy-issue] [issue1175] PyThread_{get, set,
	delete}_key_value should work without the GIL held
In-Reply-To: <1339600555.37.0.297373234943.issue1175@bugs.pypy.org>
Message-ID: <1339600555.37.0.297373234943.issue1175@bugs.pypy.org>


New submission from Marien Zwart <marien.zwart at gmail.com>:

pyOpenSSL uses macros that store and retrieve the Python threadstate in
thread-local storage using PyThread_{get,set}_key_value, like this:

#  define MY_BEGIN_ALLOW_THREADS                                        \
    PyThread_delete_key_value(_pyOpenSSL_tstate_key);			\
    PyThread_set_key_value(_pyOpenSSL_tstate_key, PyEval_SaveThread());

/*
 * Get the previous Python threadstate and restore it.
 */
#  define MY_END_ALLOW_THREADS                                          \
    PyEval_RestoreThread(PyThread_get_key_value(_pyOpenSSL_tstate_key));

These assume PyThread_{get,set,delete}_key_value can be called without the GIL
held. That is the case in Python (its thread.c mentions this), but currently not
in PyPy: they deadlock as long as the GIL exists before the lock/unlock macros
are hit (at least one other thread has run).

Attaching some test code that demonstrates the problem (in pypy 1.9, at least).

----------
files: threadlock.c
messages: 4436
nosy: marienz, pypy-issue
priority: bug
release: 1.9
status: unread
title: PyThread_{get,set,delete}_key_value should work without the GIL held

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

From tracker at bugs.pypy.org  Wed Jun 13 19:23:40 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Wed, 13 Jun 2012 17:23:40 +0000
Subject: [pypy-issue] [issue1087] Race condition when calling getattr
In-Reply-To: <1331583275.77.0.620668848256.issue1087@bugs.pypy.org>
Message-ID: <1339608220.76.0.748542947271.issue1087@bugs.pypy.org>


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

I tested boomboom.py in pypy-1.9 on amd64 and it fails with "LookupError:
unknown encoding: ascii" about 25% of the time.  I tested it with Armin's fix
applied and could not get it to crash in dozens of runs.  So I think we can call
this fixed.

If a pypy-1.9.1 is made, this would be a good thing to put in it.

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

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

From tracker at bugs.pypy.org  Wed Jun 13 21:29:13 2012
From: tracker at bugs.pypy.org (Mikhail Kashkin)
Date: Wed, 13 Jun 2012 19:29:13 +0000
Subject: [pypy-issue] [issue1176] ctypes segmentation fault under osx
In-Reply-To: <1339615753.99.0.662754757939.issue1176@bugs.pypy.org>
Message-ID: <1339615753.99.0.662754757939.issue1176@bugs.pypy.org>


New submission from Mikhail Kashkin <mkashkin at gmail.com>:

I'm using pypy from macports. Today I watched presentation from PyCon and some 
person asks about ctypes support. So I try to test it and found diferences with 
cpython. Here is what I've tried:

% python2.7
Python 2.7.3 (default, Apr 19 2012, 00:55:09) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> libc = ctypes.CDLL("/usr/lib/libc.dylib")
>>> libc.time()
1339614957
>>> dir(libc)
['_FuncPtr', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', 
'__getattr__', '__getattribute__', '__getitem__', '__hash__', '__init__', 
'__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', 
'__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 
'_func_flags_', '_func_restype_', '_handle', '_name', 'time']
>>> 


% pypy-c
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 14:24:11)
[PyPy 1.9.0] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``<fijal> answering a question: "no
-- for at least one possible interpretation of your sentence"''
>>>> import ctypes
>>>> libc = ctypes.CDLL("/usr/lib/libc.dylib")
>>>> libc.time()
__main__:1: RuntimeWarning: C function without declared arguments called
zsh: bus error  pypy-c

# interpreter dies here.

% pypy-c
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 14:24:11)
[PyPy 1.9.0] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``<arigato> no, normal work is so
much less tiring than vacations''
>>>> import ctypes
>>>> libc = ctypes.CDLL("/usr/lib/libc.dylib")
>>>> libc.printf("1")
__main__:1: RuntimeWarning: C function without declared arguments called
1
>>>> # this time I got warning, but the next command works
>>>> libc.time()
1339615442
>>>> dir(libc)zsh: segmentation fault  pypy-c 

This time dies again, but with segfault.

----------
messages: 4438
nosy: pypy-issue, xen
priority: bug
release: 1.9
status: unread
title: ctypes segmentation fault under osx

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

From tracker at bugs.pypy.org  Thu Jun 14 02:47:49 2012
From: tracker at bugs.pypy.org (Kevin Duffy)
Date: Thu, 14 Jun 2012 00:47:49 +0000
Subject: [pypy-issue] [issue1177] The empty string is a new object every time
In-Reply-To: <1339634869.45.0.714341308907.issue1177@bugs.pypy.org>
Message-ID: <1339634869.45.0.714341308907.issue1177@bugs.pypy.org>


New submission from Kevin Duffy <duffy151+pypy at gmail.com>:

It looks like the empty string is allocated anew every time it's used:

>uname -v
Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-
1699.26.8~1/RELEASE_X86_64
>pypy --version
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1]
>pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``we have no anti-impossible stick
that makes sure that all your programs halt''
>>>> id('')
4356814232
>>>> id('')
4356814256
>>>> id('')
4356814280
>>>> id('')
4356814304
>>>> id('')
4356814328
>


Compare that with CPython:

>python --version
Python 2.7.3
>python
Python 2.7.3 (default, Apr 13 2012, 11:23:14) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.2.41)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> id('')
4517287176
>>> id('')
4517287176
>>> id('')
4517287176
>>> id('')
4517287176
>>> id('')
4517287176
>>> 


1) Isn't this inefficient?
2) This is valid BUT it does break a CPython idiom where (x == '' and x is '') is 
True. I.e., people often write "x is ''" when 
they mean x == ''. This should at least be noted in the first page of 
compatibility notes.

----------
messages: 4439
nosy: duffy151, pypy-issue
priority: performance bug
status: unread
title: The empty string is a new object every time

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

From tracker at bugs.pypy.org  Thu Jun 14 10:47:34 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 14 Jun 2012 08:47:34 +0000
Subject: [pypy-issue] [issue1177] The empty string is a new object every time
In-Reply-To: <1339634869.45.0.714341308907.issue1177@bugs.pypy.org>
Message-ID: <1339663654.86.0.464641858282.issue1177@bugs.pypy.org>


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

This is not always true, even with CPython:
>>> x = u'\xe9'.encode('ascii', 'ignore')
>>> x == '', x is ''
(True, False)

The shared empty string is really an implementation detail, and not all functions use it.
(In this case, I found a function whose C implementation calls _PyString_Resize(&s, 0))

Now, PyPy could share the empty string for performance reasons.
We should make sure first that the *RPython* empty string is shared, otherwise gc 
pressure would be similar.
Benchmarks, always benchmarks...

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

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

From tracker at bugs.pypy.org  Thu Jun 14 10:55:55 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 14 Jun 2012 08:55:55 +0000
Subject: [pypy-issue] [issue1177] The empty string is a new object every time
In-Reply-To: <1339634869.45.0.714341308907.issue1177@bugs.pypy.org>
Message-ID: <1339664155.24.0.411711737485.issue1177@bugs.pypy.org>


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

Note that we already had to go through hoops to make "x is 0" work as it does in
CPython.  Strings and unicodes are the last missing pieces of that puzzle, I
suppose.  We could hack and pretend that all empty strings are identical, like
we do with all equal integers, floats, complexes and longs.  Of course, if we
do, then someone will post a bug report about single-character strings too (but
not single-character unicodes, because that doesn't work on CPython either).

Note that any performance characteristics with the JIT at this level is rather
nonsensical, because it depends on the context.  Indeed, a priori, we can think
that it is often *faster* to compare 'x == 0' than 'x is 0', because the latter
requires allocating the box for 'x' whereas the former not.  (This is not true
due to more advanced optimizations nowadays; the performance is the same.)

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

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

From tracker at bugs.pypy.org  Thu Jun 14 11:20:12 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 14 Jun 2012 09:20:12 +0000
Subject: [pypy-issue] [issue1170] pi.py run too slow
In-Reply-To: <1339484398.92.0.706624844727.issue1170@bugs.pypy.org>
Message-ID: <1339665612.7.0.829528399151.issue1170@bugs.pypy.org>


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

> high definition INT was slower.........
> how to fix it?

See discussions in issue892.

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

From tracker at bugs.pypy.org  Thu Jun 14 11:26:15 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 14 Jun 2012 09:26:15 +0000
Subject: [pypy-issue] [issue892] Pypy is slower on longs than it should
In-Reply-To: <1317663715.18.0.663914446646.issue892@bugs.pypy.org>
Message-ID: <1339665975.33.0.569031645723.issue892@bugs.pypy.org>


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

Volunteers welcome!
PyPy "long" operations are implemented here:
https://bitbucket.org/pypy/pypy/src/c26dc70ee340/pypy/rlib/rbigint.py#cl-741

This code is mostly independent from the rest of PyPy;
just plain (R)Rython, and lot of maths of course.

One could start with tuning the KARATSUBA_CUTOFF constant.

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

From tracker at bugs.pypy.org  Fri Jun 15 02:23:38 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Fri, 15 Jun 2012 00:23:38 +0000
Subject: [pypy-issue] [issue1176] ctypes segmentation fault under osx
In-Reply-To: <1339615753.99.0.662754757939.issue1176@bugs.pypy.org>
Message-ID: <1339719818.81.0.695333120916.issue1176@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

I get the same behaviour on the latest OSX nightly (on snow leopard)

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

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

From tracker at bugs.pypy.org  Sun Jun 17 09:04:44 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Sun, 17 Jun 2012 07:04:44 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

What do you make of this?

1. Copy descrobject.h from CPython 2.7 verbatim to pypy-1.8 headers.
2. Remove or comment out the definition of PyListObject in pypy_decl.h.
3. Copy the definition of PyListObject from CPython 2.7 to the end of descrobject.h.
4. Added #include "descrobject.h" to Python.h after #include "descrobject.h"


archtester lxml # USE_PYTHON="2.7 2.7-pypy-1.8" ebuild lxml-2.3.4.ebuild clean
install

running install_scripts
>>> Completed installing lxml-2.3.4 into
/mnt/gen2/TmpDir/portage/dev-python/lxml-2.3.4/image/

strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line
   /usr/lib64/python2.7/site-packages/lxml/etree.so
   /usr/lib64/python2.7/site-packages/lxml/objectify.so
   /usr/lib64/pypy1.8/site-packages/lxml/etree.pypy-18.so
   /usr/lib64/pypy1.8/site-packages/lxml/objectify.pypy-18.so

So; I have;

I would be very wary of runtime failures due to possible differences in the
CPython and PyPy structures.

This addition required only addition of header 1 python2.7 header file plus
PyListObject.  It required no changes to the source code of lxml's C source
code.  So it comes down to the suitability of the python2.7 data structure
structs being added verbatim to pypy headers.  Now while it appears to me to be
a reasonable match, I'm a pypy novice.

What do you make of it?  I am told upstream lxml maintainers are 'working on
it', but I managed this inside 3 days (probably because I'm a novice).  It's
fairly evident to me that making such additions have to be first valid data
structures to pypy and second not interfere or change anything else unintended.
 So perhaps the def of PyListObject need be encapsulated in a preprocessor
statement such as

#if defined PyListObject
#undef PyListObject
#endif

but then. I'm a novice.  I could not actually find this issue in lxml tracker re
adding pypy support,  but it seems there are 2 so it must be there somewhere.
Should pypy support be added in pypy itself, or is it best for the lxml
maintainers to either adjust its source code by adding the data structures to
its source code or adjusting it to accommodate pypy's already existing header
files?????

----------
messages: 4447
nosy: idella5, pypy-issue
priority: feature
release: 1.8
status: chatting
title: adding support to lxml in pypy

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

From tracker at bugs.pypy.org  Sun Jun 17 21:43:18 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 17 Jun 2012 19:43:18 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1339962198.04.0.867582002934.issue1178@bugs.pypy.org>


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

This approach is wrong: PyPy objects are very different from CPython objects (hey, they are not even 
pointers: their addresses can move!)

Normally extension modules shouldn't have to know the exact layout of objects: they call 
"PyList_GetItem(list, index)", and not for example "list->ob_item[index]"... which is good for PyPy, 
which can provide a different implementation.

For "performance reasons", lxml (and Cpython which is used to generate its C code) made use of its 
knowledge of CPython internals, and won't work with PyPy.

Many issues have been fixed with recent versions of Cython.  You should try to regenerate lxml with a 
recent Cython, or wait for a version of lxml that supports PyPy.

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

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

From tracker at bugs.pypy.org  Mon Jun 18 07:19:16 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 18 Jun 2012 05:19:16 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1339996756.4.0.218186517716.issue1178@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

afa,
well I already got the most recent cython.  But can you clarify what the souce
code goes looking for?  The source went looking for objects such as
PyObject_HEAD and PyListObject.  I gather you're saying Cpython's data
structures can't be simply added to and used in pypy which makes perfect sense.
 I don't see how another version of Cython can skirt the source code being
pointed to data structures that are unique to Cpython.

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

From tracker at bugs.pypy.org  Mon Jun 18 09:48:35 2012
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Mon, 18 Jun 2012 07:48:35 +0000
Subject: [pypy-issue] [issue1179] nonblocking read from pipe should return
	what's available
In-Reply-To: <1340005715.2.0.825750677575.issue1179@bugs.pypy.org>
Message-ID: <1340005715.2.0.825750677575.issue1179@bugs.pypy.org>


New submission from Ben Darnell <ben at bendarnell.com>:

In cpython, reading from a non-blocking pipe will return whatever is available, 
even 
if it is less than the requested number of bytes.  In pypy it raises an IOError 
(EAGAIN) unless the full request can be satisfied.  This is true for both 
read(n) 
and no-arg read().  While I suppose this is technically allowed by the vague "up 
to 
N bytes" in the spec, returning fewer bytes than requested is necessary in 
practice 
to read an unknown amount of data from a pipe without resorting to inefficient 
one-
byte reads.  The attached test case passes on cpython 2.7 and fails on pypy 1.9.

----------
files: pipetest.py
messages: 4450
nosy: bdarnell, pypy-issue
priority: bug
status: unread
title: nonblocking read from pipe should return what's available

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

From tracker at bugs.pypy.org  Mon Jun 18 09:48:38 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 18 Jun 2012 07:48:38 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1340005718.04.0.728955905329.issue1178@bugs.pypy.org>


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

> The source went looking for objects such as PyObject_HEAD and PyListObject
These are already defined by pypy. What pypy does not provide is the exact same structure as used by 
CPython, it's just not possible.

As long as lxml only uses PyListObject as opaque pointers, it does not make any difference.  But lxml 
should not use PyListObject struct members.  There are macros and functions for all usages, like 
PyList_GetItem.
lxml C code is mostly generated by Cython.  I know for sure that Cython fixed a lot of "incorrect" 
(i.e. too CPython-specific) usages of the API.

But let's be concrete: I suppose you got compilation errors? What are they?

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

From tracker at bugs.pypy.org  Mon Jun 18 10:14:02 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 18 Jun 2012 08:14:02 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1340007242.63.0.769351705019.issue1178@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

afa, 
thank you explaining, ack that I'm a pypy novice, so I just would like to get a
grasp on some pypy fundamentals.

Key point you made;
lxml C code is mostly generated by Cython.
hmm that is an important insight

ok, unwinding the changes I made to get it to compile, removing the CPython
struct PyListObject yields this;


src/lxml/lxml.etree.c:3684:16: error: ?PyListObject? has no member named ?allocated?
src/lxml/lxml.etree.c:3690:9: warning: return makes pointer from integer without
a cast
src/lxml/lxml.etree.c: In function ?__pyx_f_4lxml_5etree_moveNodeToDocument?:
src/lxml/lxml.etree.c:9482:32: warning: passing argument 3 of
?__pyx_v_doc->__pyx_vtab->_findOrBuildNodeNs? discards qualifiers from poi$
src/lxml/lxml.etree.c:9482:32: note: expected ?char *? but argument is of type
?const xmlChar *?
src/lxml/lxml.etree.c:9482:32: warning: passing argument 4 of
?__pyx_v_doc->__pyx_vtab->_findOrBuildNodeNs? discards qualifiers from poi$
src/lxml/lxml.etree.c:9482:32: note: expected ?char *? but argument is of type
?const xmlChar *?
src/lxml/lxml.etree.c: In function ?__pyx_f_4lxml_5etree_fixThreadDictNameForNode?:
src/lxml/lxml.etree.c:10165:18: warning: assignment discards qualifiers from
pointer target type
src/lxml/lxml.etree.c:10222:22: warning: assignment discards qualifiers from
pointer target type
src/lxml/lxml.etree.c: In function
?__pyx_f_4lxml_5etree_fixThreadDictContentForNode?:
src/lxml/lxml.etree.c:10285:42: warning: comparison of distinct pointer types
lacks a cast
src/lxml/lxml.etree.c:10309:31: warning: assignment discards qualifiers from
pointer target type

So at this point I have uncommented PyListObject in pypy_decl.h, removed it from
descrobject.h.  Remember it took me 3 days of experimenting to get the effective
compile, so the permutations of errors is huge.  This is just 1 sample.  This it
appears is an example of the source coded being CPython specific.  pypy_decl.h
list it with
typedef struct { PyObject_HEAD } PyListObject;
and to the lxml source code it is ill equipped.

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

From tracker at bugs.pypy.org  Mon Jun 18 10:38:09 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 18 Jun 2012 08:38:09 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1340008689.34.0.259534199452.issue1178@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

note too the proliferation of gee warnings re the data declaration types

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

From tracker at bugs.pypy.org  Mon Jun 18 11:33:38 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 18 Jun 2012 09:33:38 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1340012018.28.0.0241814695312.issue1178@bugs.pypy.org>


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

So it fails in function `__Pyx_PyObject_Pop`?
Cython has fixed this some time ago:
https://github.com/cython/cython/commit/7026837eca3c8e62e05618065f6a53eaaae90faa#L3R26
You should really use a newer Cython and use it to regenerate lxml C code.

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

From tracker at bugs.pypy.org  Mon Jun 18 11:43:18 2012
From: tracker at bugs.pypy.org (Eunchong Yu)
Date: Mon, 18 Jun 2012 09:43:18 +0000
Subject: [pypy-issue] [issue1180] Formatting a bool value is not equal to
	CPython's result
In-Reply-To: <1340012598.52.0.023161310199.issue1180@bugs.pypy.org>
Message-ID: <1340012598.52.0.023161310199.issue1180@bugs.pypy.org>


New submission from Eunchong Yu <kroisse at gmail.com>:

Formatting a `bool` value(True, False) by str.format() returned '1' or '0' on
PyPy 1.8.0, rather than 'True' or 'False' like the CPython's behavior.

Formatting that by the % operator has no problem. Here is my tries:
https://gist.github.com/2947527

I tried to explain it, and I found that CPython's bool.__format__() doesn't
override int.__format__(). However, int.__format__() formatted the boolean value
`True` into 'True'.

----------
messages: 4455
nosy: kroisse, pypy-issue
priority: bug
status: unread
title: Formatting a bool value is not equal to CPython's result

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

From tracker at bugs.pypy.org  Mon Jun 18 13:01:26 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 18 Jun 2012 11:01:26 +0000
Subject: [pypy-issue] [issue1178] adding support to lxml in pypy
In-Reply-To: <1339916684.58.0.978006014023.issue1178@bugs.pypy.org>
Message-ID: <1340017286.76.0.469428074364.issue1178@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

afa;  
ok, here we'll await cython 0.17

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

From tracker at bugs.pypy.org  Mon Jun 18 17:11:50 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 18 Jun 2012 15:11:50 +0000
Subject: [pypy-issue] [issue1176] ctypes segmentation fault under osx
In-Reply-To: <1339615753.99.0.662754757939.issue1176@bugs.pypy.org>
Message-ID: <1340032310.74.0.815903541988.issue1176@bugs.pypy.org>


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

time() has a single argument (void*). If you don't supply it, you're relying on 0 
being there somewhere on stack which might or might not be true. This is a bug in 
your usage of C, not in PyPy.

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

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

From tracker at bugs.pypy.org  Mon Jun 18 20:40:37 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 18 Jun 2012 18:40:37 +0000
Subject: [pypy-issue] [issue1181] [cpyext] PyType_Ready() doesn't make types
	inherit	tp_iternext
In-Reply-To: <1340044837.99.0.252768021519.issue1181@bugs.pypy.org>
Message-ID: <1340044837.99.0.252768021519.issue1181@bugs.pypy.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

PyType_Ready() fails to set the tp_iternext slot of a type that is supposed to
inherit it from its parent.

----------
messages: 4458
nosy: pypy-issue, sbehnel
priority: bug
release: 1.9
status: unread
title: [cpyext] PyType_Ready() doesn't make types inherit tp_iternext

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

From tracker at bugs.pypy.org  Mon Jun 18 20:42:33 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 18 Jun 2012 18:42:33 +0000
Subject: [pypy-issue] [issue1182] [cpyext] PyObject_GetIter() does not
	validate the	iterator it returns
In-Reply-To: <1340044953.75.0.644598970374.issue1182@bugs.pypy.org>
Message-ID: <1340044953.75.0.644598970374.issue1182@bugs.pypy.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

PyObject_GetIter() does not check the tp_iternext slot of the object it returns
and raises no exception if it's NULL.

I found this while trying to figure out why my extension type crashed during
iteration - PyType_Ready() had not inherited its tp_iternext slot. (filed as
issue1181)

----------
messages: 4459
nosy: pypy-issue, sbehnel
priority: bug
release: 1.9
status: unread
title: [cpyext] PyObject_GetIter() does not validate the iterator it returns

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

From tracker at bugs.pypy.org  Mon Jun 18 21:46:05 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 18 Jun 2012 19:46:05 +0000
Subject: [pypy-issue] [issue1182] [cpyext] PyObject_GetIter() does not
	validate the	iterator it returns
In-Reply-To: <1340044953.75.0.644598970374.issue1182@bugs.pypy.org>
Message-ID: <1340048765.52.0.251273515339.issue1182@bugs.pypy.org>


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

Actually, there is a validation: space.iter() checks that the returned object has 
a next() method. That's good enough for this function.
tp_iternext should indeed be filled, but this belongs to the other issue.

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

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

From tracker at bugs.pypy.org  Mon Jun 18 22:15:45 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 18 Jun 2012 20:15:45 +0000
Subject: [pypy-issue] [issue1182] [cpyext] PyObject_GetIter() does not
	validate the	iterator it returns
In-Reply-To: <1340044953.75.0.644598970374.issue1182@bugs.pypy.org>
Message-ID: <1340050545.65.0.929142641755.issue1182@bugs.pypy.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I guessed that it did that. Are you suggesting that any type that has a next()
method would (or does) also have its tp_iternext slot set in PyType_Ready() and
vice versa? That might work then, although I would hope that this also applies
to dynamic changes. I can easily add a .next() method to a Python object that is
already referenced by a C extension, thus (potentially?) bypassing the validation.

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

From tracker at bugs.pypy.org  Mon Jun 18 23:13:32 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 18 Jun 2012 21:13:32 +0000
Subject: [pypy-issue] [issue1182] [cpyext] PyObject_GetIter() does not
	validate the	iterator it returns
In-Reply-To: <1340044953.75.0.644598970374.issue1182@bugs.pypy.org>
Message-ID: <1340054012.71.0.467007728068.issue1182@bugs.pypy.org>


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

> I can easily add a .next() method to a Python object that is already
> referenced by a C extension, thus (potentially?) bypassing the validation.
Yes, type.__setattr__ correctly update slots for the type and all its known subtypes.  This is 
not yet implemented in pypy though.

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

From tracker at bugs.pypy.org  Tue Jun 19 06:56:34 2012
From: tracker at bugs.pypy.org (raptium)
Date: Tue, 19 Jun 2012 04:56:34 +0000
Subject: [pypy-issue] [issue1183] set difference operator does not return a
	new set if the	2nd operand is an empty set
In-Reply-To: <1340081794.57.0.717730992944.issue1183@bugs.pypy.org>
Message-ID: <1340081794.57.0.717730992944.issue1183@bugs.pypy.org>


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

As the title, the attached piece of code has different results under pypy 1.9 and 
python 2.7.1

----------
files: set_test.py
messages: 4463
nosy: pypy-issue, raptium
priority: bug
status: unread
title: set difference operator does not return a new set if the 2nd operand is an empty set

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1183>
________________________________________
-------------- next part --------------
a = set([1,2,3])
b = set([])
c = a - b
c.remove(2)
print a, c

From tracker at bugs.pypy.org  Tue Jun 19 13:16:59 2012
From: tracker at bugs.pypy.org (Lukas Diekmann)
Date: Tue, 19 Jun 2012 11:16:59 +0000
Subject: [pypy-issue] [issue1183] set difference operator does not return a
	new set if the	2nd operand is an empty set
In-Reply-To: <1340081794.57.0.717730992944.issue1183@bugs.pypy.org>
Message-ID: <1340104619.44.0.574888768233.issue1183@bugs.pypy.org>


Lukas Diekmann <Lukas.Diekmann at uni-duesseldorf.de> added the comment:

for sets with completely different content, set.difference returned a set that 
shared the storage of the first set. fixed.

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

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

From tracker at bugs.pypy.org  Wed Jun 20 09:48:06 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Wed, 20 Jun 2012 07:48:06 +0000
Subject: [pypy-issue] [issue1184] build warnings of significacne
In-Reply-To: <1340178486.74.0.0373760431003.issue1184@bugs.pypy.org>
Message-ID: <1340178486.74.0.0373760431003.issue1184@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

Package triggers severe warnings which indicate that it
may exhibit random runtime failures.
platform:WARNING] module_signal_interp_signal.c:381:2: warning: implicit
[declaration of function ?pypysig_reinstall?^
[platform:WARNING] rpython_lltypesystem_rffi.c:2455:2: warning: implicit
declaration of function ?wcscoll?^
[platform:WARNING] implement_15.c:25725:2: warning: implicit declaration of
function ?_PyPy_SSL_SetupThreads?^
[platform:WARNING] implement_16.c:53338:2: warning: implicit declaration of
function ?init_capsule?^
[platform:WARNING] implement_16.c:53418:2: warning: implicit declaration of
function ?init_pycobject?^
[platform:WARNING] implement_23.c:36584:2: warning: implicit declaration of
function ?forkpty?^
[platform:WARNING] implement_23.c:36857:2: warning: implicit declaration of
function ?openpty?^

Please do not file a Gentoo bug and instead report the above QA
issues directly to the upstream developers of this software.on Homepage:
http://pypy.org/

1.) pypysig_reinstall defined in /pypy/translator/c/src/signals.h:void
pypysig_reinstall(int signum)
2.) Can't find wscoll, unless this is it
archtester bash # grep -r wcscoll
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp  | grep "\.h"
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
Signed
pypy_g_wcscoll__arrayPtr_arrayPtr_star_2(wchar_t *l_stararg0_847, wchar_t
*l_stararg1_509);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-current/testing_1/forwarddecl.h:extern
Signed
pypy_g_wcscoll__arrayPtr_arrayPtr_star_2(wchar_t *l_stararg0_847, wchar_t
*l_stararg1_509);

3.) same for _PyPy_SSL_SetupThreads unless this is it
archtester bash # grep -r _PyPy_SSL_SetupThreads
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp  | grep "\.h"
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
int
pypy_g_ccall__PyPy_SSL_SetupThreads___(void);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-current/testing_1/forwarddecl.h:extern
int
pypy_g_ccall__PyPy_SSL_SetupThreads___(void);

4.) same for init_capsule
archtester bash # grep -r init_capsule
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp  | grep "\.h"
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
void pypy_g_ccall_init_capsule___(void);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-current/testing_1/forwarddecl.h:extern
void pypy_g_ccall_init_capsule___(void);

5.) similarly
archtester bash # grep -r init_pycobject
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp  | grep "\.h"
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
void pypy_g_ccall_init_pycobject___(void);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-current/testing_1/forwarddecl.h:extern
void pypy_g_ccall_init_pycobject___(void);

6.) similarly
archtester bash # grep -r forkpty
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp  | grep "\.h"
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
struct
pypy_pypy_interpreter_baseobjspace_W_Root0 *pypy_g_forkpty(void);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
struct pypy_tuple2_3
*pypy_g_ll_os_ll_os_forkpty(void);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
int
pypy_g_ccall_forkpty__arrayPtr_arrayPtr_arrayPtr_arrayP(int *l_a0_121, void
*l_a1_84, void *l_a2_38, void *l_a3_12);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-current/testing_1/forwarddecl.h:extern
struct
pypy_pypy_interpreter_baseobjspace_W_Root0 *pypy_g_forkpty(void);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-current/testing_1/forwarddecl.h:extern
struct pypy_tuple2_3
*pypy_g_ll_os_ll_os_forkpty(void);
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-current/testing_1/forwarddecl.h:extern
int
pypy_g_ccall_forkpty__arrayPtr_arrayPtr_arrayPt

7. ) and
archtester bash # grep -r openpty
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp  | grep "\.h"
/mnt/gen2/TmpDir/portage/dev-python/pypy-1.9-r2/temp/usession-release-1.9-0/testing_1/forwarddecl.h:extern
struct
pypy_pypy_interpreter_baseobjspace_W_Root0 *pypy_g_openpty(void);

----------
messages: 4465
nosy: idella5, pypy-issue
priority: bug
release: 0.9
status: testing
title: build warnings of significacne

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

From tracker at bugs.pypy.org  Wed Jun 20 11:04:35 2012
From: tracker at bugs.pypy.org (Colin Rice)
Date: Wed, 20 Jun 2012 09:04:35 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>


New submission from Colin Rice <dah4k0r at gmail.com>:

It appears that pypy doesn't define certain members namely:
exc_type, exc_value, exc_tracebacl, curexc_type, curexc_value, curexc_traceback.

See http://hg.python.org/cpython/file/d129982c063d/Include/pystate.h
Bug appeared when trying to build gevent.

----------
messages: 4466
nosy: c00w, pypy-issue
priority: bug
status: unread
title: [cpyext] Missing members in PyThreadState

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

From tracker at bugs.pypy.org  Wed Jun 20 11:24:38 2012
From: tracker at bugs.pypy.org (Zaar Hai)
Date: Wed, 20 Jun 2012 09:24:38 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1340184278.12.0.72989041534.issue1116@bugs.pypy.org>


Zaar Hai <haizaar at gmail.com> added the comment:

Guys,

Any plans to resolve/fix this?

Thanks.

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

From tracker at bugs.pypy.org  Wed Jun 20 14:13:10 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 12:13:10 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340194390.14.0.552358272951.issue1185@bugs.pypy.org>


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

Do the compilation errors happen in code generated by Cython, in functions like 
__Pyx_GetException?
If so, you should update to a newer version of Cython, which is more compatible 
with PyPy; and regenerate core.c.

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

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

From tracker at bugs.pypy.org  Wed Jun 20 14:22:03 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Wed, 20 Jun 2012 12:22:03 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340194923.86.0.681568385152.issue1185@bugs.pypy.org>


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

gevent uses cython

and i think it also uses the greenlet c apis (i.e. its impossible to build on
pypy atm)

----------
nosy: +ronny

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

From tracker at bugs.pypy.org  Wed Jun 20 15:33:13 2012
From: tracker at bugs.pypy.org (Roman Vorushin)
Date: Wed, 20 Jun 2012 13:33:13 +0000
Subject: [pypy-issue] [issue1186] threading.stack_size() doesn't work for
	big sizes of stack
In-Reply-To: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>
Message-ID: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>


New submission from Roman Vorushin <roman.vorushin at gmail.com>:

In the attached file I set threading.stack_size() to 64M and then create new 
thread with a deep recursive call. CPython works nice, but PyPy 1.9 fail 
(segmentation fault).

This is the only bug that keeps me from persuading codeforces.com guys to accept 
pypy as a substitute of CPython for judging Python-written solutions for 
programming contests.

Unfortunately, recursion of this size (roughly up to 10 ** 5) is usual for this 
kind of contests. CPython works nice with big stacks, but it's not fast enough 
for some of problems.

----------
files: bug.py
messages: 4470
nosy: pypy-issue, vorushin
priority: bug
status: unread
title: threading.stack_size() doesn't work for big sizes of stack

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

From tracker at bugs.pypy.org  Wed Jun 20 15:48:37 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Wed, 20 Jun 2012 13:48:37 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

1 single test fails out of 876 tests (pretty good really) in test suite of 
celery-2.5.5.

 * Testing of dev-python/celery-2.5.5 with PyPy 1.9 (Python 2.7)...
................................................................................................................................................................................................................SSSSSSSSSSSSSSSSSE..............................
* Tokyo Tyrant not installed. Will not execute related tests.
SSSSS.............................................S.S..........S...........SSSSSS...S...............SSSS............................SSSSSSSSSSSSSSSSSS.......................................................................................................................................................................................................................................................................................................................................................................Traceback
(most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/celery-2.5.5/work/celery-2.5.5/celery/utils/timer2.py",
line 190, in apply_entry
    entry()
  File "/usr/lib64/pypy1.9/site-packages/mock.py", line 983, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/usr/lib64/pypy1.9/site-packages/mock.py", line 1038, in _mock_call
    raise effect
ValueError
...............................................................................................................................................................................................
======================================================================
ERROR: test_cleanup (celery.tests.test_backends.test_mongodb.TestBackendMongoDb)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/pypy1.9/site-packages/mock.py", line 1224, in patched
    return func(*args, **keywargs)
  File
"/mnt/gen2/TmpDir/portage/dev-python/celery-2.5.5/work/celery-2.5.5/celery/tests/test_backends/test_mongodb.py",
line 275, in test_cleanup
    self.backend.cleanup()
  File
"/mnt/gen2/TmpDir/portage/dev-python/celery-2.5.5/work/celery-2.5.5/celery/backends/mongodb.py",
line 203, in cleanup
    "$lt": self.app.now() - self.expires,
  File "/usr/lib64/pypy1.9/lib_pypy/datetime.py", line 1859, in __sub__
    if not isinstance(other, datetime):
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types

----------------------------------------------------------------------
Ran 876 tests in 29.598s

FAILED (SKIP=54, errors=1)
 * ERROR: dev-python/celery-2.5.5 failed (test phase)

---------------------------------------------------------------
from celery-2.5.5/celery/utils/timer2.py
----------------------------------------------------------------
class Timer(Thread):
    Entry = Entry
    Schedule = Schedule

    running = False
    on_tick = None
    _timer_count = count(1).next

    def __init__(self, schedule=None, on_error=None, on_tick=None, **kwargs):
        self.schedule = schedule or self.Schedule(on_error=on_error)
        self.on_tick = on_tick or self.on_tick

        Thread.__init__(self)
        self._is_shutdown = Event()
        self._is_stopped = Event()
        self.mutex = Lock()
        self.logger = logging.getLogger("timer2.Timer")
        self.not_empty = Condition(self.mutex)
        self.setDaemon(True)
        self.setName("Timer-%s" % (self._timer_count(), ))

    def apply_entry(self, entry):
        try:
            entry()
        except Exception, exc:
           exc_info = sys.exc_info()
            try:
                if not self.schedule.handle_error(exc_info):
                    warnings.warn(TimedFunctionFailed(repr(exc))),
                    sys.stderr.write("Error in timer: %r\n" % (exc, ))
                    traceback.print_exception(exc_info[0],
                                              exc_info[1],
                                              exc_info[2],
                                              None, sys.__stderr__)
            finally:
                del(exc_info)

---------------------------------------------------------------------
from celery-2.5.5/celery/tests/test_backends/test_mongodb.py
---------------------------------------------------------------------
    @patch("celery.backends.mongodb.MongoBackend._get_database")
    def test_cleanup(self, mock_get_database):
        self.backend.mongodb_taskmeta_collection = MONGODB_COLLECTION

        mock_database = MagicMock(spec=['__getitem__', '__setitem__'])
        mock_collection = Mock()

        mock_get_database.return_value = mock_database
        mock_database.__getitem__.return_value = mock_collection

        self.backend.cleanup()

        mock_get_database.assert_called_once_with()
        mock_database.__getitem__.assert_called_once_with(
            MONGODB_COLLECTION)
        mock_collection.assert_called_once()

valid also for pypy-1.8

----------------------------------------------------------------------
Ran 876 tests in 29.527s

FAILED (SKIP=54, errors=1)
 * ERROR: dev-python/celery-2.5.5 failed (test phase):
 *   Testing failed with PyPy 1.8 (Python 2.7) in testing() function

----------
messages: 4471
nosy: idella5, pypy-issue
priority: performance bug
release: 0.9
status: chatting
title: call to isinstance(...) in __sub__(self, other) in lib_pypy/datetime.py draws error in test

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

From tracker at bugs.pypy.org  Wed Jun 20 15:56:59 2012
From: tracker at bugs.pypy.org (jayqhacker)
Date: Wed, 20 Jun 2012 13:56:59 +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: <1340200619.31.0.823176922599.issue791@bugs.pypy.org>


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

PyPy 1.9 looks to be a significant regression for this case; however, I had to
compile from source myself, as the 1.9 binaries no longer support Red Hat 5
(glibc 2.5), so perhaps the older GCC explains some of it.

CPython 2.7.3 : 41s   1400 MB
PyPy 1.9      : 65s   1600 MB

----------
release:  -> 1.9

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

From tracker at bugs.pypy.org  Wed Jun 20 16:45:01 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Wed, 20 Jun 2012 14:45:01 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340203501.56.0.0150801332422.issue1187@bugs.pypy.org>


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

I could not reproduce this bug.  Ubuntu on amd64.

I used pip to install celery, nosetests, mock, pyopenssl, and cl inside my
(post-1.9) pypy checkout.  Then I did cd ~/hg/pypy/site-packages/celery/tests;
~/hg/pypy/bin/nosetests -v .   Got "Ran 876 tests in 27.265s OK (SKIP=54)"  (The
skips were due to missing Tokyo Tyrant, missing redis, and tests that are
deliberately skipped under PyPy, indicating that the maintainers have tried
celery under PyPy before.)

I don't see anything in lib-pypy/datetime.py that would cause the problem you
saw, of datetime not being a class.

----------
nosy: +dripton
priority: performance bug -> bug
status: chatting -> invalid

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

From tracker at bugs.pypy.org  Wed Jun 20 16:46:43 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 14:46:43 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340203603.73.0.122221672665.issue1187@bugs.pypy.org>


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

Please install pymongo to enable more tests...

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

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

From tracker at bugs.pypy.org  Wed Jun 20 16:54:48 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Wed, 20 Jun 2012 14:54:48 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340204088.92.0.763248573605.issue1187@bugs.pypy.org>


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

Installing pymongo (2.2) gets me a bunch of failures to import pymongo.binary. 
That might be a separate bug, but it doesn't explain the datetime problem.

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

From tracker at bugs.pypy.org  Wed Jun 20 17:01:27 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Wed, 20 Jun 2012 15:01:27 +0000
Subject: [pypy-issue] [issue1186] threading.stack_size() doesn't work for
	big sizes of stack
In-Reply-To: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>
Message-ID: <1340204487.77.0.171208501265.issue1186@bugs.pypy.org>


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

In pypy/translator/c/src/stack.h, MAX_STACK_SIZE is set to 768 kB by default.

Have you tried increasing it before translating?

I recall similar hackery being necessary to get really deep recursion in CPython
without risking segfaults, though it sounds like they've increased the defaults
since the last time I tried.

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

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

From tracker at bugs.pypy.org  Wed Jun 20 17:03:39 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Wed, 20 Jun 2012 15:03:39 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340204619.94.0.520472025157.issue1187@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

my system here has bson.binary
no idea why but pymongo.binary appears to not be in place, substituted
pymong.binary with bson.binary
that fixes that, the datetime error is simply separate

and [U] dev-python/pymongo
 Installed versions:  2.2(18:32:15 20/06/12)(-doc -mod_wsgi -test)

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

From tracker at bugs.pypy.org  Wed Jun 20 17:07:24 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Wed, 20 Jun 2012 15:07:24 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340204844.53.0.647482424004.issue1187@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

could the cause be instead in mock??

  File "/usr/lib64/pypy1.9/site-packages/mock.py", line 983, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/usr/lib64/pypy1.9/site-packages/mock.py", line 1038, in _mock_call

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

From tracker at bugs.pypy.org  Wed Jun 20 17:17:12 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 15:17:12 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340205432.28.0.829099021147.issue1187@bugs.pypy.org>


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

well, datetime.datetime is replaced by a Mock() object which is not a type, so 
instance(other, datetime) fails.
I don't know why they did this. Tests pass just as well if datetime is not mocked 
out.

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

From tracker at bugs.pypy.org  Wed Jun 20 17:22:32 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Wed, 20 Jun 2012 15:22:32 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340205752.91.0.807239292155.issue1187@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

great thanks, but 
"I don't know why they did this."
they are the mock maintainers, the celery maintainers?
I take it pypy is in the clear in this 1?

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

From tracker at bugs.pypy.org  Wed Jun 20 17:26:45 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 15:26:45 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340206005.46.0.787449138128.issue1187@bugs.pypy.org>


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

The celery maintainers already adapted their code to support pypy.  I suppose 
they could take this one as well...
Replacing standard objects by something that does not work is never a good idea, 
unexpected parts of the interpreter may need them.

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

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

From tracker at bugs.pypy.org  Wed Jun 20 18:08:49 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 20 Jun 2012 16:08:49 +0000
Subject: [pypy-issue] [issue1188] Support -OO
In-Reply-To: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>
Message-ID: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>


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

"python-dev" discussed again the -O and -OO options to Python.  It seems that
even without -O support, it would still be useful to support -OO ("remove
doc-strings").  An easy implementation would be to strip the docstring from code
objects when they leave the compiler/.pyc writer/.pyc loader.  They would still
be present during compilation and in the written .pyc files.  This would only be
a memory saving optimization.

----------
messages: 4482
nosy: arigo, pypy-issue
priority: wish
status: unread
title: Support -OO

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

From tracker at bugs.pypy.org  Wed Jun 20 18:28:16 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 16:28:16 +0000
Subject: [pypy-issue] [issue1188] Support -OO
In-Reply-To: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>
Message-ID: <1340209696.94.0.389380948345.issue1188@bugs.pypy.org>


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

So no .pyo file at all?  Looks good.
(and an easy task for a newcomer)

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

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

From tracker at bugs.pypy.org  Wed Jun 20 19:23:44 2012
From: tracker at bugs.pypy.org (Ask Solem Hoel)
Date: Wed, 20 Jun 2012 17:23:44 +0000
Subject: [pypy-issue] [issue1187] call to isinstance(...) in __sub__(self,
	other) in lib_pypy/datetime.py draws error in test
In-Reply-To: <1340200117.81.0.588370504276.issue1187@bugs.pypy.org>
Message-ID: <1340213024.59.0.18482094298.issue1187@bugs.pypy.org>


Ask Solem Hoel <ask at celeryproject.org> added the comment:

afa is right, Celery will take this bug as we are dedicated to have our code work 
on pypy, you can create a new issue at https://github.com/celery/celery/issues

I agree that replacing standard types is a bad idea, but sometimes convenient for 
tests. Most of the code uses composite types so monkey patching is not necessary.

----------
nosy: +ask

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

From tracker at bugs.pypy.org  Wed Jun 20 19:45:36 2012
From: tracker at bugs.pypy.org (Colin Rice)
Date: Wed, 20 Jun 2012 17:45:36 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340214336.66.0.61701474695.issue1185@bugs.pypy.org>


Colin Rice <dah4k0r at gmail.com> added the comment:

I upgraded to the latest cython and built gevent from a dev release. The only 
errors which occured were issues with the pystate.h header libraries 
PyStateThread structure missing these members. This occured both in cython 
generated functions and in handwritten c functions. Unless PyStateThread is 
actually the greenlet API I don't believe gevent uses the cpython greenlet api.

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

From tracker at bugs.pypy.org  Wed Jun 20 20:02:22 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Wed, 20 Jun 2012 18:02:22 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340215342.42.0.108826466234.issue1185@bugs.pypy.org>


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

ah, i remember, this is the workaround code for the exception state bug greenlet
had some time ago,
i fixed that greenlet bug a while back 

i think the workaround code in gevent recently was moved to a separate module
please try to disable it

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

From tracker at bugs.pypy.org  Wed Jun 20 21:10:35 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 19:10:35 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340219435.02.0.0590138057942.issue1185@bugs.pypy.org>


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

Note that it won't be possible for cpyext to support these members.
Macros or functions should be used instead.

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

From tracker at bugs.pypy.org  Wed Jun 20 21:17:02 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 19:17:02 +0000
Subject: [pypy-issue] [issue1184] build warnings of significance
In-Reply-To: <1340178486.74.0.0373760431003.issue1184@bugs.pypy.org>
Message-ID: <1340219822.67.0.902131571059.issue1184@bugs.pypy.org>


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

I would not qualify these warnings as "severe", since all these functions return 
int or void.
They are fixed though, with changesets 41c5525655b1 and df1a40c0b049.

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

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

From tracker at bugs.pypy.org  Wed Jun 20 23:57:16 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 20 Jun 2012 21:57:16 +0000
Subject: [pypy-issue] [issue1180] Formatting a bool value is not equal to
	CPython's result
In-Reply-To: <1340012598.52.0.023161310199.issue1180@bugs.pypy.org>
Message-ID: <1340229436.31.0.282496162655.issue1180@bugs.pypy.org>


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

Fixed by kostia with changeset 7be473583322.
Thanks!

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

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

From tracker at bugs.pypy.org  Thu Jun 21 09:48:35 2012
From: tracker at bugs.pypy.org (Roman Vorushin)
Date: Thu, 21 Jun 2012 07:48:35 +0000
Subject: [pypy-issue] [issue1186] threading.stack_size() doesn't work for
	big sizes of stack
In-Reply-To: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>
Message-ID: <1340264915.07.0.117269081011.issue1186@bugs.pypy.org>


Roman Vorushin <roman.vorushin at gmail.com> added the comment:

I changed MAX_STACK_SIZE in stack.h to 64 MB

#ifndef MAX_STACK_SIZE
#    define MAX_STACK_SIZE (64 << 20)    /* 64 MB */
#endif

I did retranslation of pypy after it:

pypy translate.py -Ojit
python package.py ../../.. pypy64
cd <pypy64_dir>
./pypy bug.py

It fails with the same error. I tried different values for the depth limit in the 
function and discovered that both pre-built pypy and my modified version get 
'Segmentation fault: 11' on depth 19000, but work without errors on depth 18000.

It seems that changing MAX_STACK_SIZE in stack.h is not enough to fix this bug.

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

From tracker at bugs.pypy.org  Thu Jun 21 10:08:27 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Thu, 21 Jun 2012 08:08:27 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340266107.0.0.83339235148.issue1185@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

also msgpack;

for pypy-1,8;

/usr/lib64/pypy1.8/include/pypy_decl.h:131:29: note: expected ?struct
PyThreadState *? but argument is of type ?int?
error: command 'cc' failed with exit status 1
 
for pypy-1.9
cc -march=athlon64 -pipe -fomit-frame-pointer -O2 -fPIC
-I/usr/lib64/pypy1.9/include -c msgpack/_msgpack.c -o
build/temp.linux-x86_64-2.7/msgpack/_msgpack.o
msgpack/_msgpack.c: In function ?init_msgpack?:
msgpack/_msgpack.c:5492:96: error: ?PyBoolObject? undeclared (first use in this
function)
msgpack/_msgpack.c:5492:96: note: each undeclared identifier is reported only
once for each function it appears in
msgpack/_msgpack.c:5493:105: error: ?PyComplexObject? undeclared (first use in
this function)
msgpack/_msgpack.c: In function ?__Pyx_ErrRestore?:
msgpack/_msgpack.c:5731:22: error: ?PyThreadState? has no member named ?curexc_type?
msgpack/_msgpack.c:5732:23: error: ?PyThreadState? has no member named
?curexc_value?
msgpack/_msgpack.c:5733:20: error: ?PyThreadState? has no member named
?curexc_traceback?
msgpack/_msgpack.c:5734:11: error: ?PyThreadState? has no member named ?curexc_type?
msgpack/_msgpack.c:5735:11: error: ?PyThreadState? has no member named
?curexc_value?
msgpack/_msgpack.c:5736:11: error: ?PyThreadState? has no member named
?curexc_traceback?
msgpack/_msgpack.c: In function ?__Pyx_ErrFetch?:
msgpack/_msgpack.c:5744:19: error: ?PyThreadState? has no member named ?curexc_type?
msgpack/_msgpack.c:5745:20: error: ?PyThreadState? has no member named
?curexc_value?
msgpack/_msgpack.c:5746:17: error: ?PyThreadState? has no member named
?curexc_traceback?
msgpack/_msgpack.c:5748:11: error: ?PyThreadState? has no member named ?curexc_type?
msgpack/_msgpack.c:5749:11: error: ?PyThreadState? has no member named
?curexc_value?
msgpack/_msgpack.c:5750:11: error: ?PyThreadState? has no member named
?curexc_traceback?
error: command 'cc' failed with exit status 1

----------
nosy: +idella5

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

From tracker at bugs.pypy.org  Thu Jun 21 10:17:20 2012
From: tracker at bugs.pypy.org (Jez Ng)
Date: Thu, 21 Jun 2012 08:17:20 +0000
Subject: [pypy-issue] [issue1189] Get code_dump working on OS X
In-Reply-To: <1340266640.68.0.7277386637.issue1189@bugs.pypy.org>
Message-ID: <1340266640.68.0.7277386637.issue1189@bugs.pypy.org>


New submission from Jez Ng <jezreel at gmail.com>:

'objdump' on Linux is 'gobjdump' on OS X.

----------
files: objdump
messages: 4492
nosy: int3, pypy-issue
priority: bug
status: unread
title: Get code_dump working on OS X

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

From tracker at bugs.pypy.org  Thu Jun 21 10:26:44 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 21 Jun 2012 08:26:44 +0000
Subject: [pypy-issue] [issue1185] [cpyext] Missing members in PyThreadState
In-Reply-To: <1340183075.33.0.933059413836.issue1185@bugs.pypy.org>
Message-ID: <1340267204.81.0.209502274061.issue1185@bugs.pypy.org>


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

"__Pyx_ErrRestore": Please use a version of Cython that supports PyPy.

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

From tracker at bugs.pypy.org  Thu Jun 21 12:21:59 2012
From: tracker at bugs.pypy.org (Jez Ng)
Date: Thu, 21 Jun 2012 10:21:59 +0000
Subject: [pypy-issue] [issue1188] Support -OO
In-Reply-To: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>
Message-ID: <1340274119.46.0.979369993247.issue1188@bugs.pypy.org>


Jez Ng <jezreel at gmail.com> added the comment:

I'm interested in attempting this bug. Could I have some pointers as to where to 
start? As I understand, we want to strip the docstrings when loading .pyc files; 
is read_compiled_module in importing.py the correct place to do this?

----------
nosy: +int3

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

From tracker at bugs.pypy.org  Thu Jun 21 13:23:16 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Thu, 21 Jun 2012 11:23:16 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1190=5D_cannot_convert_=E2=80=98Py?=
 =?utf-8?b?U3RyaW5nT2JqZWN0KuKAmSB0byDigJhQeU9iamVjdCrigJkgaW4gcHljcnlw?=
 =?utf-8?q?topp?=
In-Reply-To: <1340277796.62.0.702840919304.issue1190@bugs.pypy.org>
Message-ID: <1340277796.62.0.702840919304.issue1190@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

It appears it has fallen at the 'final hurdle' in package pycryptopp of latest
version number that defies description.

c++ -march=athlon64 -pipe -fomit-frame-pointer -O2 -fPIC -I.
-I/usr/lib64/pypy1.9/include -c src/pycryptopp/_pycryptoppmodule.cpp -o
build-2.7-pypy-1.9/temp.linux-x86_64-2.7/src/pycryptopp/_pycryptoppmodule.o -w
c++ -march=athlon64 -pipe -fomit-frame-pointer -O2 -fPIC -I.
-I/usr/lib64/pypy1.9/include -c src/pycryptopp/publickey/rsamodule.cpp -o
build-2.7-pypy-1.9/temp.linux-x86_64-2.7/src/pycryptopp/publickey/rsamodule.o -w
src/pycryptopp/publickey/rsamodule.cpp: In function ?PyObject*
SigningKey_sign(SigningKey*, PyObject*)?:
src/pycryptopp/publickey/rsamodule.cpp:185:33: error: cannot convert
?PyStringObject*? to ?PyObject*? for argument ?1? to ?char*
PyString_AsString(PyObject*)?
error: command 'c++' failed with exit status 1
 * ERROR:
dev-python/pycryptopp-0.6.0.1206569328141510525648634803928199668821045408958
failed (compile phase):
 *   Building failed with PyPy 1.9 (Python 2.7) in distutils_building() function

the culprit function from the rsamodule.cpp

static PyObject *
SigningKey_sign(SigningKey *self, PyObject *msgobj) {
    const char *msg;
    Py_ssize_t msgsize;
    PyString_AsStringAndSize(msgobj, const_cast<char**>(&msg),
reinterpret_cast<Py_ssize_t*>(&msgsize));
    assert (msgsize >= 0);

    Py_ssize_t sigsize = self->k->SignatureLength();
    PyStringObject* result =
reinterpret_cast<PyStringObject*>(PyString_FromStringAndSize(NULL, sigsize));
    if (!result)
        return NULL;
    assert (sigsize >= 0);

    AutoSeededRandomPool randpool(false);
    Py_ssize_t siglengthwritten = self->k->SignMessage(
        randpool,
        reinterpret_cast<const byte*>(msg),
        msgsize,
        reinterpret_cast<byte*>(PyString_AS_STRING(result)));
    if (siglengthwritten < sigsize)
        fprintf(stderr, "%s: %d: %s: %s", __FILE__, __LINE__, "SigningKey_sign",
"INTERNAL ERROR: signature was shorter than expected.");
    else if (siglengthwritten > sigsize) {
        fprintf(stderr, "%s: %d: %s: %s", __FILE__, __LINE__, "SigningKey_sign",
"INTERNAL ERROR: signature was longer than expected, so invalid memory was overwr$
        abort();
    }
    assert (siglengthwritten >= 0);

    return reinterpret_cast<PyObject*>(result);
}

reinterpret_cast<byte*>(PyString_AS_STRING(result))); is where it bailed out

----------
messages: 4495
nosy: idella5, pypy-issue
priority: performance bug
release: 0.9
status: chatting
title: cannot convert ?PyStringObject*? to ?PyObject*? in pycryptopp

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

From tracker at bugs.pypy.org  Thu Jun 21 13:50:11 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 21 Jun 2012 11:50:11 +0000
Subject: [pypy-issue] [issue1188] Support -OO
In-Reply-To: <1340208529.43.0.593686088035.issue1188@bugs.pypy.org>
Message-ID: <1340279411.05.0.855471917643.issue1188@bugs.pypy.org>


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

Yes, probably.
docstrings need to be removed also when the module is imported from source 
(*after* it has been written to .pyc)

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

From tracker at bugs.pypy.org  Thu Jun 21 19:44:59 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Jun 2012 17:44:59 +0000
Subject: [pypy-issue] [issue1186] threading.stack_size() doesn't work for
	big sizes of stack
In-Reply-To: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>
Message-ID: <1340300699.15.0.156083914941.issue1186@bugs.pypy.org>


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

Linux limits the stack size to 8M or so by default. You should not change it 
above that limit.

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

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

From tracker at bugs.pypy.org  Thu Jun 21 19:49:52 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Jun 2012 17:49:52 +0000
Subject: [pypy-issue] [issue1186] threading.stack_size() doesn't work for
	big sizes of stack
In-Reply-To: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>
Message-ID: <1340300992.67.0.989812728229.issue1186@bugs.pypy.org>


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

For what is worth this particular program works for me. Can you say more about 
your environment?

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

From tracker at bugs.pypy.org  Thu Jun 21 19:52:21 2012
From: tracker at bugs.pypy.org (Roman Vorushin)
Date: Thu, 21 Jun 2012 17:52:21 +0000
Subject: [pypy-issue] [issue1186] threading.stack_size() doesn't work for
	big sizes of stack
In-Reply-To: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>
Message-ID: <1340301141.79.0.00339885215921.issue1186@bugs.pypy.org>


Roman Vorushin <roman.vorushin at gmail.com> added the comment:

My OS is Mac OS X 10.7.4 (64-bit).
PyPy 1.9.0 with GCC 4.2.1

I tried ulimit -s hard (it gives max stack size up to 64Mb), but even with this 
setting the program fails at the same recursion level.

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

From tracker at bugs.pypy.org  Thu Jun 21 19:54:56 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Jun 2012 17:54:56 +0000
Subject: [pypy-issue] [issue1186] threading.stack_size() doesn't work for
	big sizes of stack
In-Reply-To: <1340199193.85.0.971549278465.issue1186@bugs.pypy.org>
Message-ID: <1340301296.35.0.324363534278.issue1186@bugs.pypy.org>


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

Ok, so it sounds like a bug in OS X support, works fine on linux (by fine I mean 
it takes forever to trace it, but prints "Done" at least)

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

From tracker at bugs.pypy.org  Sat Jun 23 20:45:09 2012
From: tracker at bugs.pypy.org (Aric)
Date: Sat, 23 Jun 2012 18:45:09 +0000
Subject: [pypy-issue] [issue1191] behavior change in sets infix operation
In-Reply-To: <1340477109.24.0.143325849385.issue1191@bugs.pypy.org>
Message-ID: <1340477109.24.0.143325849385.issue1191@bugs.pypy.org>


New submission from Aric <aric.hagberg at gmail.com>:

I noticed this change in pypy-1.9.  The difference operator works differently 
for infix vs explicit (set.difference()).  e.g. 

# OK
s = set([0])
b = set()
d = s.difference(b)
print(d) # set([0])
n = s.pop()
print(d) # set([0])

# WRONG?
s = set([0])
b = set()
d = s - b
print(d) # set([0])
n = s.pop()
print(d) # set([])

$ pypy -v
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:38:48)
[PyPy 1.9.0 with GCC 4.4.3] on linux2

----------
messages: 4501
nosy: hagberg, pypy-issue
priority: bug
status: unread
title: behavior change in sets infix operation

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

From tracker at bugs.pypy.org  Sat Jun 23 22:00:03 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sat, 23 Jun 2012 20:00:03 +0000
Subject: [pypy-issue] [issue1191] behavior change in sets infix operation
In-Reply-To: <1340477109.24.0.143325849385.issue1191@bugs.pypy.org>
Message-ID: <1340481603.61.0.0970674564664.issue1191@bugs.pypy.org>


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

i think this is a duplicate of https://bugs.pypy.org/issue1183

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

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

From tracker at bugs.pypy.org  Sat Jun 23 22:09:38 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sat, 23 Jun 2012 20:09:38 +0000
Subject: [pypy-issue] [issue1192] check the incoming email handler of the
	issue tracker
In-Reply-To: <1340482178.04.0.57078865828.issue1192@bugs.pypy.org>
Message-ID: <1340482178.04.0.57078865828.issue1192@bugs.pypy.org>


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

it seems like there may be some things missed that go to tracker at bugs.pypy.org

----------
assignedto: ronny
messages: 4504
nosy: pypy-issue, ronny
priority: critical
status: unread
title: check the incoming email handler of the issue tracker

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

From tracker at bugs.pypy.org  Sat Jun 23 22:10:21 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sat, 23 Jun 2012 20:10:21 +0000
Subject: [pypy-issue] [issue1192] check the incoming email handler of the
	issue tracker
In-Reply-To: <1340482178.04.0.57078865828.issue1192@bugs.pypy.org>
Message-ID: <1340482221.44.0.962782398741.issue1192@bugs.pypy.org>


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

its just slow

----------
status: unread -> invalid

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

From tracker at bugs.pypy.org  Sun Jun 24 08:13:18 2012
From: tracker at bugs.pypy.org (Stian Andreassen)
Date: Sun, 24 Jun 2012 06:13:18 +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: <1340518398.93.0.303362710266.issue819@bugs.pypy.org>


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

2**num is 50 times faster using improvements available here:
https://bitbucket.org/_stian/pypy-improvebigint

It also closes the gap between cPython and pypy by about 50% when it comes to
general pow and mul operations.

----------
nosy: +stian

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

From tracker at bugs.pypy.org  Mon Jun 25 22:43:30 2012
From: tracker at bugs.pypy.org (Andrew Pendleton)
Date: Mon, 25 Jun 2012 20:43:30 +0000
Subject: [pypy-issue] [issue1193] numpy ufuncs break if used in-place
In-Reply-To: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>
Message-ID: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>


New submission from Andrew Pendleton <abpend at gmail.com>:

In numpy on CPython, ufuncs can be used in-place.  On pypy, they seem to break.  
Example:

import numpypy as numpy
arr = numpy.zeros(10)
numpy.maximum(arr, 1, arr)

This works fine on CPython, but mostly raises a recursion depth exception in 
pypy.  Within the request-response cycle of Django, I have also seen it trigger 
a complete crash of pypy, with "Bus error: 10" printed to the screen, but I 
can't reproduce this behavior outside of Django.

----------
messages: 4507
nosy: apendleton, pypy-issue
priority: bug
status: unread
title: numpy ufuncs break if used in-place

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

From tracker at bugs.pypy.org  Mon Jun 25 22:59:33 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 25 Jun 2012 20:59:33 +0000
Subject: [pypy-issue] [issue1193] numpy ufuncs break if used in-place
In-Reply-To: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>
Message-ID: <1340657973.75.0.248432587077.issue1193@bugs.pypy.org>


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

It's probably possible for this to crash in some cases (recursive compilation?). 
There is a refactoring that would fix that.

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

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

From tracker at bugs.pypy.org  Mon Jun 25 23:10:34 2012
From: tracker at bugs.pypy.org (Andrew Pendleton)
Date: Mon, 25 Jun 2012 21:10:34 +0000
Subject: [pypy-issue] [issue1193] numpy ufuncs break if used in-place
In-Reply-To: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>
Message-ID: <1340658634.43.0.196562541577.issue1193@bugs.pypy.org>


Andrew Pendleton <abpend at gmail.com> added the comment:

So the refactor would mean it would always throw the exception rather than the
bus error, or that it would actually run?

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

From tracker at bugs.pypy.org  Mon Jun 25 23:13:09 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 25 Jun 2012 21:13:09 +0000
Subject: [pypy-issue] [issue1193] numpy ufuncs break if used in-place
In-Reply-To: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>
Message-ID: <1340658789.84.0.132189256013.issue1193@bugs.pypy.org>


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

It would actually run (of course)

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

From tracker at bugs.pypy.org  Thu Jun 28 20:11:56 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 28 Jun 2012 18:11:56 +0000
Subject: [pypy-issue] [issue1194] ctypes callbacks don't respect SystemExit
In-Reply-To: <1340907116.46.0.618448739962.issue1194@bugs.pypy.org>
Message-ID: <1340907116.46.0.618448739962.issue1194@bugs.pypy.org>


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

When a ctypes callback raises an exception, CPython uses PyErr_Print(), this has 
the effect of 
terminating the interpreter with a libc exit().

Yes, it's a bit abrupt, but some code relies on this behavior, and pypy should 
do the same.
Here is an example, with CPython the callback is called only once:


from ctypes import *
libc = CDLL("libc.so.6")   
qsort = libc.qsort
qsort.restype = None
CMPFUNC = CFUNCTYPE(c_int, POINTER(c_int), POINTER(c_int))
def py_cmp_func(a, b):
    print "py_cmp_func", a, b
    raise SystemExit("exit!")
cmp_func = CMPFUNC(py_cmp_func)
ia = (c_int * 5)(5, 1, 7, 33, 99)
qsort(ia, len(ia), sizeof(c_int), cmp_func)

----------
messages: 4511
nosy: afa, pypy-issue
priority: bug
status: unread
title: ctypes callbacks don't respect SystemExit

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

From tracker at bugs.pypy.org  Thu Jun 28 21:07:32 2012
From: tracker at bugs.pypy.org (chrysn)
Date: Thu, 28 Jun 2012 19:07:32 +0000
Subject: [pypy-issue] [issue1195] sandbox interactor not trivially usable as
	a drop-in	replacement for python
In-Reply-To: <1340910452.5.0.062083560285.issue1195@bugs.pypy.org>
Message-ID: <1340910452.5.0.062083560285.issue1195@bugs.pypy.org>


New submission from chrysn <chrysn at fsfe.org>:

while exploring ways to use sandboxed pypy for ad-hoc extensions to wiki software (like 
executable wiki pages), i found some issues that could easily make pypy-sandbox more usable:

* return values are not propagated. replacing the `sandproc.interact()` line with 
`sys.exit(sandproc.interact())` would help there. conversely, the "[Subprocess exit code: %d]" & 
co error prints in SimpleIOSandboxProc.interact should only be shown if verbosity is turned on.

* the information whether stdin is a tty or not is discarded. as a result, `echo "print 40+2" | 
pypy-sandbox` does print 42, but also prints welcome messages and prompts. attempts to 
circumvent the problem like `... | pypy-sandbox /dev/stdin` failed as expected.

* pypy-sandbox runs always show the following lines in their stderr:

Not Implemented: SomeString(no_nul=True)
RuntimeError
'import site' failed

* in my opinion, an --export=/some/path option would be more useful than the --tmp= option; it 
could, for every occurrence, export a path to itself (ie /some/path would be accessible as 
/some/path inside the sandbox too), and optionally include it in the PYTHONPATH by default (eg -
-export-in-path=/some/other/dir). by the same mechanism, the first argument to pypy-sandbox (the 
script to run) could be implicitly exported, enabling `pypy-sandbox ./some_script.py`

all behaviors were observed on pypy 1.9 as packaged in debian as 1.9+dfsg-1.

----------
messages: 4512
nosy: chrysn, pypy-issue
priority: wish
status: unread
title: sandbox interactor not trivially usable as a drop-in replacement for python

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

From tracker at bugs.pypy.org  Thu Jun 28 21:26:25 2012
From: tracker at bugs.pypy.org (Allen Short)
Date: Thu, 28 Jun 2012 19:26:25 +0000
Subject: [pypy-issue] [issue1196] pyrepl does not accept multiline input
	under some	terminal settings
In-Reply-To: <1340911585.96.0.48790708008.issue1196@bugs.pypy.org>
Message-ID: <1340911585.96.0.48790708008.issue1196@bugs.pypy.org>


New submission from Allen Short <washort42 at gmail.com>:

After running 'sttyl -icrnl', pypy gives this error when receiving input that
requires a continuation line:

>>>> (1,
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "/home/washort/pypy-1.9/lib_pypy/_pypy_interact.py", line 40, in
interactive_console
    run_multiline_interactive_console(mainmodule)
  File "/home/washort/pypy-1.9/lib_pypy/pyrepl/simple_interact.py", line 62, in
run_multiline_interactive_console
    assert not more
AssertionError

----------
messages: 4513
nosy: pypy-issue, washort
priority: bug
release: 1.9
status: unread
title: pyrepl does not accept multiline input under some terminal settings

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

From tracker at bugs.pypy.org  Thu Jun 28 21:41:48 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Thu, 28 Jun 2012 19:41:48 +0000
Subject: [pypy-issue] [issue1196] pyrepl does not accept multiline input
	under some	terminal settings
In-Reply-To: <1340911585.96.0.48790708008.issue1196@bugs.pypy.org>
Message-ID: <1340912508.03.0.896202386637.issue1196@bugs.pypy.org>


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

related pyrepl issue is
https://bitbucket.org/pypy/pyrepl/issue/2/does-not-accept-multiline-input-under-some

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

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

From tracker at bugs.pypy.org  Fri Jun 29 17:23:16 2012
From: tracker at bugs.pypy.org (Marien Zwart)
Date: Fri, 29 Jun 2012 15:23:16 +0000
Subject: [pypy-issue] [issue1175] PyThread_{get, set,
	delete}_key_value should work without the GIL held
In-Reply-To: <1339600555.37.0.297373234943.issue1175@bugs.pypy.org>
Message-ID: <1340983396.71.0.433170249286.issue1175@bugs.pypy.org>


Marien Zwart <marien.zwart at gmail.com> added the comment:

The attached patch fixes this, although it's not entirely right.

It removes pypy/module/cpyext/thread.py, adding the functions defined in it to
pypy/module/cpyext/src/thread.c (and their declarations to pythread.h, like they
are in cpython). The tests of the converted functions were similarly converted.
This means the cpyext thread.c now needs to include thread.h from
pypy/translator/c. An include path was added when building the cpyext source to
make this possible.

The problem I ran into is that including thread.h without PYPY_NOT_MAIN_FILE
defined defines several threading-related functions. I had to add a #define for
this to thread.c to prevent duplicate definitions when creating pypy-c. I think
that part is actually correct, as a few other .c files have this define,
presumably for similar reasons. But for some reason the cpyext tests end up with
no definition of the threading-related functions, causing them to fail. I hacked
around that by adding an include of src/thread.h to build_bridge, but although
this gives me a working pypy-c and passing cpyext tests it is almost certainly
not sane. I do not know what the correct fix for this is: adding that include to
a more sensible location or somehow including some of ll_thread when building
cpyext, assuming a reference to ll_thread is what previously got these functions
included.

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

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

From tracker at bugs.pypy.org  Fri Jun 29 23:10:05 2012
From: tracker at bugs.pypy.org (Tobias Oberstein)
Date: Fri, 29 Jun 2012 21:10:05 +0000
Subject: [pypy-issue] [issue1162] Abort with OpenSSL and threads
In-Reply-To: <1339346582.88.0.843743823045.issue1162@bugs.pypy.org>
Message-ID: <1341004205.45.0.550133886446.issue1162@bugs.pypy.org>


Tobias Oberstein <tobias.oberstein at gmail.com> added the comment:

Tests were performed on "Ubuntu 10.04 LTS i386" with 4 different Pythons:

 * CPy 2.7.3
 * PyPy 1.9 Release
 * PyPy Trunk (pypy-c-jit-55865-f7fcfbf26301-linux)
 * PyPy Trunk (55872:26b81a6d9365) + Patch from Issue #1175

All of which with "pyOpenSSL 0.13".

SUMMARY
=======

The test cases 1, 2 and 3 will only work on PyPy Trunk + Patch (other than CPy
of course).

Test case 5 is working on PyPy Trunk, but not 1.9 Release.


RESULTS
=======

The test results seem to be reproducible each and every time run (I tried at
least a couple of times .. never saw non-deterministic behavior).


testcase5.py
============

https://github.com/oberstet/scratchbox/blob/master/python/twisted/pypybug1/testcase5.py

Command: <PYTHON> testcase5.py

Results:

CPy 2.7.3:          Success.
PyPy 1.9 Release:   Failure.
PyPy Trunk:         Success.
PyPy Trunk + Patch: Success.


testcase4.py
============

https://github.com/oberstet/scratchbox/blob/master/python/twisted/pypybug1/testcase4.py

Command: <PYTHON> testcase4.py

Results:

CPy 2.7.3:          Success.
PyPy 1.9 Release:   Success.
PyPy Trunk:         Success.
PyPy Trunk + Patch: Success.


testcase3.py
============

https://github.com/oberstet/scratchbox/blob/master/python/twisted/pypybug1/testcase3.py

Command: <PYTHON> testcase3.py threads

CPy 2.7.3:          Success.
PyPy 1.9 Release:   Failure.
PyPy Trunk:         Failure.
PyPy Trunk + Patch: Success.


testcase2.py
============

https://github.com/oberstet/scratchbox/blob/master/python/twisted/pypybug1/testcase2.py

Command: <PYTHON> testcase2.py defer ssl

CPy 2.7.3:          Success.
PyPy 1.9 Release:   Failure.
PyPy Trunk:         Failure.
PyPy Trunk + Patch: Success.


testcase.py
============

https://github.com/oberstet/scratchbox/blob/master/python/twisted/pypybug1/testcase.py

Command: <PYTHON> testcase.py pool ssl

CPy 2.7.3:          Success.
PyPy 1.9 Release:   Failure.
PyPy Trunk:         Failure.
PyPy Trunk + Patch: Success.

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

From tracker at bugs.pypy.org  Fri Jun 29 23:21:02 2012
From: tracker at bugs.pypy.org (Tobias Oberstein)
Date: Fri, 29 Jun 2012 21:21:02 +0000
Subject: [pypy-issue] [issue1175] PyThread_{get, set,
	delete}_key_value should work without the GIL held
In-Reply-To: <1339600555.37.0.297373234943.issue1175@bugs.pypy.org>
Message-ID: <1341004862.07.0.332046535873.issue1175@bugs.pypy.org>


Tobias Oberstein <tobias.oberstein at gmail.com> added the comment:

I did some tests with the patch on a bug that seems to be related #1162:
https://bugs.pypy.org/msg4516

Those were all on Linux. I'll do the same for FreeBSD. Let me know if I can help
with further testing / anything rgd. this issue ..

----------
nosy: +oberstet

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

From tracker at bugs.pypy.org  Sat Jun 30 00:36:57 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Fri, 29 Jun 2012 22:36:57 +0000
Subject: [pypy-issue] [issue1121] [cpyext] speed up some macros
In-Reply-To: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>
Message-ID: <1341009417.65.0.943343049329.issue1121@bugs.pypy.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think the preprocessor guard ended up the wrong way around. It should likely
read "#ifdef" instead of "#ifndef".

#ifndef PYPY_DEBUG_REFCOUNT
#define Py_INCREF(ob)   (Py_IncRef((PyObject *)ob))
#define Py_DECREF(ob)   (Py_DecRef((PyObject *)ob))
#define Py_XINCREF(ob)  (Py_IncRef((PyObject *)ob))
#define Py_XDECREF(ob)  (Py_DecRef((PyObject *)ob))
#else
#define Py_INCREF(ob)   (((PyObject *)ob)->ob_refcnt++)
#define Py_DECREF(ob)  ((((PyObject *)ob)->ob_refcnt > 1) ? \
                        ((PyObject *)ob)->ob_refcnt-- : (Py_DecRef((PyObject *)ob)))

#define Py_XINCREF(op) do { if ((op) == NULL) ; else Py_INCREF(op); } while (0)
#define Py_XDECREF(op) do { if ((op) == NULL) ; else Py_DECREF(op); } while (0)
#endif

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

From tracker at bugs.pypy.org  Sat Jun 30 08:33:17 2012
From: tracker at bugs.pypy.org (Tobias Oberstein)
Date: Sat, 30 Jun 2012 06:33:17 +0000
Subject: [pypy-issue] [issue1162] Abort with OpenSSL and threads
In-Reply-To: <1339346582.88.0.843743823045.issue1162@bugs.pypy.org>
Message-ID: <1341037997.72.0.431296641006.issue1162@bugs.pypy.org>


Tobias Oberstein <tobias.oberstein at gmail.com> added the comment:

Tests were now performed on "FreeBSD 9 i386 Release".

The results are the same as for Linux. In particular, the test cases which fail
for PyPy trunk work when the patch from issue #1175 is applied.

$ ~/pypy1/bin/pypy -V
Python 2.7.2 (26b81a6d9365+, Jun 30 2012, 04:31:26)
[PyPy 1.9.1-dev0 with GCC 4.2.1]

=======

CORRECTION (testcase3.py)

Command: <PYTHON> testcase3.py 8090 threads

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