From tracker at bugs.pypy.org  Fri Feb  1 01:15:34 2013
From: tracker at bugs.pypy.org (klankschap)
Date: Fri, 01 Feb 2013 00:15:34 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1359666673.77.0.254018393148.issue1381@bugs.pypy.org>
Message-ID: <6317B124-0315-4CEE-B763-8E29A952CE18@klankschap.nl>


klankschap <vm at klankschap.nl> added the comment:

On 31 Jan 2013, at 22:11, Amaury Forgeot d Arc wrote:

> 
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
> 
> Fixed with 0ec3d77645a2: jumpahead() won't generate numbers above 1.0.
> 
> Precise numbers will differ from CPython though.

It seems to work correctly now indeed.
(thanks!)

.F

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

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

From tracker at bugs.pypy.org  Fri Feb  1 13:29:34 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 01 Feb 2013 12:29:34 +0000
Subject: [pypy-issue] [issue1384] Multiprocessing on Windows
In-Reply-To: <1359476860.93.0.0495306481652.issue1384@bugs.pypy.org>
Message-ID: <1359721774.01.0.637047688286.issue1384@bugs.pypy.org>


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

Wow this code is so broken. I don't see a good reason why we should not commit 
this fix though.

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

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

From tracker at bugs.pypy.org  Fri Feb  1 16:02:09 2013
From: tracker at bugs.pypy.org (Philip Thiem)
Date: Fri, 01 Feb 2013 15:02:09 +0000
Subject: [pypy-issue] [issue1384] Multiprocessing on Windows
In-Reply-To: <1359476860.93.0.0495306481652.issue1384@bugs.pypy.org>
Message-ID: <1359730929.37.0.105434509543.issue1384@bugs.pypy.org>


Philip Thiem <ptthiem at gmail.com> added the comment:

lol, thx that made my day.

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

From tracker at bugs.pypy.org  Fri Feb  1 16:14:02 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 01 Feb 2013 15:14:02 +0000
Subject: [pypy-issue] [issue1384] Multiprocessing on Windows
In-Reply-To: <1359476860.93.0.0495306481652.issue1384@bugs.pypy.org>
Message-ID: <1359731642.86.0.659159254551.issue1384@bugs.pypy.org>


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

I strongly suggest to commit this change to CPython 2.7 first.

----------
nosy: +amaury

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

From tracker at bugs.pypy.org  Fri Feb  1 18:01:23 2013
From: tracker at bugs.pypy.org (Philip Thiem)
Date: Fri, 01 Feb 2013 17:01:23 +0000
Subject: [pypy-issue] [issue1384] Multiprocessing on Windows
In-Reply-To: <1359476860.93.0.0495306481652.issue1384@bugs.pypy.org>
Message-ID: <1359738083.36.0.657401279681.issue1384@bugs.pypy.org>


Philip Thiem <ptthiem at gmail.com> added the comment:

Ahh seems like I was reading the 2.6 page regarding security only fixes, I went
ahead and submitted a bug also on python.org against the 2.X series.  But yeah
completely understandable to remain bug for bug compatible.

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

From tracker at bugs.pypy.org  Sat Feb  2 00:33:56 2013
From: tracker at bugs.pypy.org (mike bayer)
Date: Fri, 01 Feb 2013 23:33:56 +0000
Subject: [pypy-issue] [issue1298] performance w/ sqlalchemy test suite
In-Reply-To: <1350776912.86.0.0398129877721.issue1298@bugs.pypy.org>
Message-ID: <1359761636.17.0.464849009472.issue1298@bugs.pypy.org>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

it seems this issue is due to having the --coverage flag enabled for the test
suite.   taking this flag off reduces the total time down to 38 minutes, still a
bit slower than cPython but pretty much not an issue.   Probably can close this.

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

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

From tracker at bugs.pypy.org  Sat Feb  2 23:50:54 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 02 Feb 2013 22:50:54 +0000
Subject: [pypy-issue] [issue1298] performance w/ sqlalchemy test suite
In-Reply-To: <1350776912.86.0.0398129877721.issue1298@bugs.pypy.org>
Message-ID: <1359845454.54.0.344383857725.issue1298@bugs.pypy.org>


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

Let's not close this, if anything we need to understand why coverage is so bloody 
slow. I'm thinking it's because the trace function disables the JIT.

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

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

From tracker at bugs.pypy.org  Sun Feb  3 09:42:39 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 03 Feb 2013 08:42:39 +0000
Subject: [pypy-issue] [issue1386] OrderedDict patch from rhettinger
In-Reply-To: <1359880959.6.0.0728602665243.issue1386@bugs.pypy.org>
Message-ID: <1359880959.6.0.0728602665243.issue1386@bugs.pypy.org>


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

http://pastebin.com/yc56WPJE so I don't forget

----------
messages: 5246
nosy: fijal, pypy-issue
priority: wish
status: unread
title: OrderedDict patch from rhettinger

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

From tracker at bugs.pypy.org  Sun Feb  3 18:43:59 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 03 Feb 2013 17:43:59 +0000
Subject: [pypy-issue] [issue1386] OrderedDict patch from rhettinger
In-Reply-To: <1359880959.6.0.0728602665243.issue1386@bugs.pypy.org>
Message-ID: <1359913439.3.0.596615888655.issue1386@bugs.pypy.org>


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

Was this code ever tested?  I suspect no, seeing "dict.setitem" in it (should be
"dict.__setitem__").

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

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

From tracker at bugs.pypy.org  Sun Feb  3 19:12:04 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 03 Feb 2013 18:12:04 +0000
Subject: [pypy-issue] [issue1386] OrderedDict patch from rhettinger
In-Reply-To: <1359880959.6.0.0728602665243.issue1386@bugs.pypy.org>
Message-ID: <1359915124.79.0.941091907626.issue1386@bugs.pypy.org>


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

Also, please let's use module level constants for NEXT, PREV, etc. those are free 
on pypy and much more readable.

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

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

From tracker at bugs.pypy.org  Mon Feb  4 04:19:19 2013
From: tracker at bugs.pypy.org (yongjie)
Date: Mon, 04 Feb 2013 03:19:19 +0000
Subject: [pypy-issue] [issue1387] imp module no attribute IMP_HOOK type
In-Reply-To: <1359947959.29.0.092649840501.issue1387@bugs.pypy.org>
Message-ID: <1359947959.29.0.092649840501.issue1387@bugs.pypy.org>


New submission from yongjie <yongjie989 at gmail.com>:

>>>> from py2exe.mf import ModuleFinder
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "E:\pypy-2.0-beta1\site-packages\py2exe\mf.py", line 801, in <module>
    imp.IMP_HOOK: "IMP_HOOK",
AttributeError: 'module' object has no attribute 'IMP_HOOK'

Confirm python2.7.3:
>>>> import imp
>>>> help(imp)
DATA
    C_BUILTIN = 6
    C_EXTENSION = 3
    IMP_HOOK = 9      <-- here!
    PKG_DIRECTORY = 5
    PY_CODERESOURCE = 8
    PY_COMPILED = 2
    PY_FROZEN = 7
    PY_RESOURCE = 4
    PY_SOURCE = 1
    SEARCH_ERROR = 0
    
Confirmed pypy here not see IMP_HOOK
>>>> import imp
>>>> help(imp)
Help on built-in module imp:
...
DATA
    C_BUILTIN = 6
    C_EXTENSION = 3
    PKG_DIRECTORY = 5
    PY_COMPILED = 2
    PY_FROZEN = 7
    PY_SOURCE = 1

    
In Python-2.7 source code importdl.h can see IMP_HOOK declared:
enum filetype {
    SEARCH_ERROR,
    PY_SOURCE,
    PY_COMPILED,
    C_EXTENSION,
    PY_RESOURCE, /* Mac only */
    PKG_DIRECTORY,
    C_BUILTIN,
    PY_FROZEN,
    PY_CODERESOURCE, /* Mac only */
    IMP_HOOK
};

----------
messages: 5249
nosy: pypy-issue
priority: bug
release: 2.0
status: unread
title: imp module no attribute IMP_HOOK type

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

From tracker at bugs.pypy.org  Mon Feb  4 07:48:28 2013
From: tracker at bugs.pypy.org (Yong Jie Huang)
Date: Mon, 04 Feb 2013 06:48:28 +0000
Subject: [pypy-issue] [issue1385] nt._isdir is not implemented
In-Reply-To: <1359483031.58.0.249870410222.issue1385@bugs.pypy.org>
Message-ID: <1359960508.26.0.554539696758.issue1385@bugs.pypy.org>


Yong Jie Huang <yongjie989 at gmail.com> added the comment:

In my computer(win32), no raise any error, can you talk about the detail? 
>>>> os.path.isdir('c:\\test')
True
>>>> nt = os.path
>>>> nt.isdir('c:\\test')
True

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

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

From tracker at bugs.pypy.org  Mon Feb  4 11:33:05 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 04 Feb 2013 10:33:05 +0000
Subject: [pypy-issue] [issue1385] nt._isdir is not implemented
In-Reply-To: <1359483031.58.0.249870410222.issue1385@bugs.pypy.org>
Message-ID: <1359973985.73.0.461037569045.issue1385@bugs.pypy.org>


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

>>> import nt
>>> nt._isdir('c:\\test')

'nt' is the win32 name of the 'posix' module...

nt._isdir() is supposed to be faster than genericpath.isdir(), because os.stat does multiple system 
calls on Windows.
It was added in 2.7.3: http://bugs.python.org/issue11583

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

From tracker at bugs.pypy.org  Mon Feb  4 13:47:26 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 04 Feb 2013 12:47:26 +0000
Subject: [pypy-issue] [issue1387] imp module no attribute IMP_HOOK type
In-Reply-To: <1359947959.29.0.092649840501.issue1387@bugs.pypy.org>
Message-ID: <1359982046.98.0.175527909244.issue1387@bugs.pypy.org>


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

IMP_HOOK is (internally) supported by pypy, see module/imp/importing.py
It's just a matter of exporting it in module/imp/__init__.py
(SEARCH_ERROR as well)

tag:easy

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

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

From tracker at bugs.pypy.org  Thu Feb  7 00:06:53 2013
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 06 Feb 2013 23:06:53 +0000
Subject: [pypy-issue] [issue1387] imp module no attribute IMP_HOOK type
In-Reply-To: <1359947959.29.0.092649840501.issue1387@bugs.pypy.org>
Message-ID: <1360192013.14.0.750504415592.issue1387@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in 1721aeaf522f

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

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

From tracker at bugs.pypy.org  Thu Feb  7 00:12:22 2013
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 06 Feb 2013 23:12:22 +0000
Subject: [pypy-issue] [issue1369] strftime behaviour on OS X
In-Reply-To: <1358374767.35.0.373906499742.issue1369@bugs.pypy.org>
Message-ID: <1360192342.41.0.773403950092.issue1369@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in b59c8e831df0

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

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

From tracker at bugs.pypy.org  Thu Feb  7 00:14:04 2013
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 06 Feb 2013 23:14:04 +0000
Subject: [pypy-issue] [issue1370] signal test on OS X
In-Reply-To: <1358377525.1.0.494324709824.issue1370@bugs.pypy.org>
Message-ID: <1360192444.08.0.566963841766.issue1370@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in b59c8e831df0

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

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

From tracker at bugs.pypy.org  Thu Feb  7 14:34:24 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Feb 2013 13:34:24 +0000
Subject: [pypy-issue] [issue1388] zipimport bug on .pyc-only archives
In-Reply-To: <1360244064.32.0.707710182691.issue1388@bugs.pypy.org>
Message-ID: <1360244064.32.0.707710182691.issue1388@bugs.pypy.org>


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

Zipimport is subtly buggy when importing .pyc files from .zips: there are cases
that work on CPython but fail on PyPy.  I *think* the cases are related to the
mtime of the pyc's, both as stored inside, and as specified in the zip; if they
are close enough (as done by the tests) it works, and if they are not it doesn't.

----------
messages: 5256
nosy: arigo, pypy-issue
priority: bug
status: unread
title: zipimport bug on .pyc-only archives

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

From tracker at bugs.pypy.org  Thu Feb  7 14:39:51 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Feb 2013 13:39:51 +0000
Subject: [pypy-issue] [issue1388] zipimport bug on .pyc-only archives
In-Reply-To: <1360244064.32.0.707710182691.issue1388@bugs.pypy.org>
Message-ID: <1360244391.66.0.164975557337.issue1388@bugs.pypy.org>


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

Yes, that's it.  With this change to the tests it fails:

http://bpaste.net/show/75701/

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

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

From tracker at bugs.pypy.org  Thu Feb  7 14:40:22 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 07 Feb 2013 13:40:22 +0000
Subject: [pypy-issue] [issue1388] zipimport bug on .pyc-only archives
In-Reply-To: <1360244064.32.0.707710182691.issue1388@bugs.pypy.org>
Message-ID: <1360244422.87.0.90846204171.issue1388@bugs.pypy.org>


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

Sorry:

http://bpaste.net/show/75703/

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

From tracker at bugs.pypy.org  Fri Feb  8 04:54:22 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 03:54:22 +0000
Subject: [pypy-issue] [issue1349] input+thread+readline = signal crash
In-Reply-To: <1355683506.59.0.0292293424519.issue1349@bugs.pypy.org>
Message-ID: <1360295662.93.0.785748251645.issue1349@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

confirmed the problem and fix, applied in c17aa572ce36. don't have write access to 
pyrepl repo but someone should apply there too, potentially with a test 
(unix_console prepare/restore in main followed by in a thread should be enough).

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

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

From tracker at bugs.pypy.org  Fri Feb  8 05:08:27 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 04:08:27 +0000
Subject: [pypy-issue] [issue1246] pypy-c-jit-x-linux64 nightly tarball size
	jumped
In-Reply-To: <1346263327.85.0.6108374575.issue1246@bugs.pypy.org>
Message-ID: <1360296507.98.0.0527827008158.issue1246@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

size has jumped back to 13M between

pypy-c-jit-60924-78a4037ea447-linux64.tar.bz2	18M	2013-02-07
pypy-c-jit-60949-a06da7965b64-linux64.tar.bz2	13M	2013-02-08

maybe it was fixed by 65047c26392cc? and originally triggered by a gcc/lib 
upgrade that exported a bunch of unused symbols? calling this resolved.

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

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

From tracker at bugs.pypy.org  Fri Feb  8 08:47:43 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 07:47:43 +0000
Subject: [pypy-issue] [issue1386] OrderedDict patch from rhettinger
In-Reply-To: <1359880959.6.0.0728602665243.issue1386@bugs.pypy.org>
Message-ID: <1360309663.51.0.552947070454.issue1386@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

tested/applied the parts of this patch that were applied upstream in 
ec577d173019.

left out the untested pypy-specific modifications (dict_setitem/dict_delitem) for 
more careful review.

----------
nosy: +bdk

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

From tracker at bugs.pypy.org  Fri Feb  8 09:08:23 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 08 Feb 2013 08:08:23 +0000
Subject: [pypy-issue] [issue1388] zipimport bug on .pyc-only archives
In-Reply-To: <1360244064.32.0.707710182691.issue1388@bugs.pypy.org>
Message-ID: <1360310903.81.0.110675570147.issue1388@bugs.pypy.org>


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

May be fixed in 35ab7f14c707: imports from zip files containing .pyc only no
longer fail because of mismatches between timestamps.

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

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

From tracker at bugs.pypy.org  Fri Feb  8 10:43:48 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 09:43:48 +0000
Subject: [pypy-issue] [issue1314] expat parser should read file by chunks
In-Reply-To: <1351962898.59.0.456401197968.issue1314@bugs.pypy.org>
Message-ID: <1360316628.71.0.408333906236.issue1314@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

improved the patch and applied in 8894a48bfcf2 to fix this issue. thanks!

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

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

From tracker at bugs.pypy.org  Fri Feb  8 17:19:49 2013
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Fri, 08 Feb 2013 16:19:49 +0000
Subject: [pypy-issue] [issue1389] "copying over different dtypes
	unsupported", but the dtype is the same
In-Reply-To: <1360340389.05.0.93382592622.issue1389@bugs.pypy.org>
Message-ID: <1360340389.05.0.93382592622.issue1389@bugs.pypy.org>


New submission from Antonio Cuni <anto.cuni at gmail.com>:

>>>> import numpypy
>>>> x = numpypy.array([1.0, 2.0])
>>>> x.dtype
dtype('float64')
>>>> y = numpypy.array(x, 'd')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
NotImplementedError: copying over different dtypes unsupported
>>>> y = numpypy.array(x, numpypy.dtype('d'))

The problem seems to be at line 718 of interp_numarray.py:
            w_object.get_dtype() is not w_dtype

----------
messages: 5264
nosy: pypy-issue
priority: bug
status: unread
title: "copying over different dtypes unsupported", but the dtype is the same

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

From tracker at bugs.pypy.org  Fri Feb  8 21:40:47 2013
From: tracker at bugs.pypy.org (Andrew McNabb)
Date: Fri, 08 Feb 2013 20:40:47 +0000
Subject: [pypy-issue] [issue1390] pickle creates invalid output on numpypy
	ndarray objects	instead of crashing
In-Reply-To: <1360356047.79.0.282067975417.issue1390@bugs.pypy.org>
Message-ID: <1360356047.79.0.282067975417.issue1390@bugs.pypy.org>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

Ordinarily, pickling a numpypy ndarray object fails because this isn't implemented 
yet, which makes perfect sense:

>>>> pickle.dumps(A)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/lib64/pypy-1.9/lib-python/2.7/pickle.py", line 1417, in dumps
    Pickler(file, protocol).dump(obj)
  File "/usr/lib64/pypy-1.9/lib-python/2.7/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/lib64/pypy-1.9/lib-python/2.7/pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "/usr/lib64/pypy-1.9/lib-python/2.7/copy_reg.py", line 70, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle ndarray objects
>>>>

However, pickling with protocol version -1 looks like it succeeds:

>>>> pickle.dumps(A, -1)
'\x80\x02cnumpypy\nndarray\nq\x00)\x81q\x01.'
>>>>

However, the output of this is basically gibberish and can't be loaded with loads. It 
might be better for dumps to crash than to give an invalid output.

----------
messages: 5265
nosy: amcnabb, pypy-issue
priority: bug
status: unread
title: pickle creates invalid output on numpypy ndarray objects instead of crashing

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

From tracker at bugs.pypy.org  Fri Feb  8 22:48:39 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 21:48:39 +0000
Subject: [pypy-issue] [issue985] jit bug
In-Reply-To: <1325961536.04.0.318710394403.issue985@bugs.pypy.org>
Message-ID: <1360360119.21.0.325695873464.issue985@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

did this become a permanent workaround? was another one applied and the temporary 
one kept in place when it shouldn't have been?

----------
nosy: +bdk

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

From tracker at bugs.pypy.org  Fri Feb  8 22:50:39 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 21:50:39 +0000
Subject: [pypy-issue] [issue995] jit bug with threads
In-Reply-To: <1326197980.33.0.665170552495.issue995@bugs.pypy.org>
Message-ID: <1360360239.15.0.365507657199.issue995@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

these pastes don't exist any more, can't test this bug, marking invalid

----------
nosy: +bdk

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

From tracker at bugs.pypy.org  Fri Feb  8 22:52:35 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 21:52:35 +0000
Subject: [pypy-issue] [issue1018] ones(shape, 'int') and zeros(shape,
	'int') doesn't work
In-Reply-To: <1327421958.09.0.643487914668.issue1018@bugs.pypy.org>
Message-ID: <1360360355.04.0.187626260688.issue1018@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

tested that this is fixed in nightly, marking resolved

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

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

From tracker at bugs.pypy.org  Fri Feb  8 23:52:20 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 22:52:20 +0000
Subject: [pypy-issue] [issue1040] Crash on Ubuntu with threads and
	gethostbyname_ex
In-Reply-To: <1328931804.55.0.443019312541.issue1040@bugs.pypy.org>
Message-ID: <1360363940.97.0.0405821842344.issue1040@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

can't reproduce this with latest nightly, probably one of the many threaading bugs 
fixed in the past year, marking resolved. reopen if you manage to reproduce.

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

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

From tracker at bugs.pypy.org  Sat Feb  9 00:27:17 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 23:27:17 +0000
Subject: [pypy-issue] [issue573] get_python_lib unconditionally fails when
	passing	standard_lib
In-Reply-To: <1290889131.9.0.781821510487.issue573@>
Message-ID: <1360366037.47.0.69857318008.issue573@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

get_python_lib(standard_lib=1) works fine now, marking resolved

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

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

From tracker at bugs.pypy.org  Sat Feb  9 00:48:31 2013
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 08 Feb 2013 23:48:31 +0000
Subject: [pypy-issue] [issue748] Failure in sqlite3 fetchall
In-Reply-To: <1307874387.72.0.702167811825.issue748@bugs.pypy.org>
Message-ID: <1360367311.58.0.807142919375.issue748@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

tested latest nightly, fixed

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

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

From tracker at bugs.pypy.org  Sat Feb  9 01:57:10 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 00:57:10 +0000
Subject: [pypy-issue] [issue1218] isodate is not able to parse iso format
	from	datetime.datetime's isoformat
In-Reply-To: <1342448314.11.0.272294494578.issue1218@bugs.pypy.org>
Message-ID: <1360371430.8.0.141212365276.issue1218@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in 72e79a8305c7

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

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

From tracker at bugs.pypy.org  Sat Feb  9 03:23:42 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 02:23:42 +0000
Subject: [pypy-issue] [issue1130] numpypy indexing of arrays with lists
	doesn't match numpy
In-Reply-To: <1334411129.8.0.658879495202.issue1130@bugs.pypy.org>
Message-ID: <1360376622.85.0.552165175134.issue1130@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

added them to tests in 5691aa9f6d83+a8d47219e78c.

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

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

From tracker at bugs.pypy.org  Sat Feb  9 04:10:27 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 03:10:27 +0000
Subject: [pypy-issue] [issue1161] numpypy.bool missing (numpy boolean dtype)
In-Reply-To: <1339278757.75.0.360606329263.issue1161@bugs.pypy.org>
Message-ID: <1360379427.07.0.886984267914.issue1161@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

added in 481f9cde9e3e.

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

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

From tracker at bugs.pypy.org  Sat Feb  9 04:13:51 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 03:13:51 +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: <1360379631.12.0.347211649309.issue1160@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

np.int/bool aliases were added in 481f9cde9e3e.

np.zeros([4,4], np.integer) still fails.

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

From tracker at bugs.pypy.org  Sat Feb  9 05:55:45 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 04:55:45 +0000
Subject: [pypy-issue] [issue1289] multiprocessing Pool + maxtasksperchild +
	signal =	ValueError
In-Reply-To: <1350317901.63.0.635751910168.issue1289@bugs.pypy.org>
Message-ID: <1360385745.96.0.336830731671.issue1289@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

I applied a reduced version in 3b06320cf630 that only resets mainthreadident to at 
least allow signal() after fork from a thread (should fix the example bad.py). 
Leaving this open for discussion about the other ThreadLocal behaviors after fork 
(couldn't replicate these parts of the test on CPython).

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

From tracker at bugs.pypy.org  Sat Feb  9 06:00:26 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 05:00:26 +0000
Subject: [pypy-issue] [issue538] pypy-c doesn't build under FreeBSD 7
In-Reply-To: <1274191795.27.0.812046771338.issue538@>
Message-ID: <1360386026.51.0.525815022503.issue538@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

freebsd7 builder is translating fine now.

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

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

From tracker at bugs.pypy.org  Sat Feb  9 09:31:57 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 08:31:57 +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: <1360398717.9.0.510978343074.issue1167@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

properly fixed in ace3ca8195f3.

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

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

From tracker at bugs.pypy.org  Sat Feb  9 09:47:10 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 08:47:10 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1360399630.3.0.223788905831.issue833@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

some of these would be present if the buildbots translated pypy using a fresh 
cpython2.7 (with proper functions in the os module) rather than using an older 
pypy (which was translated either before the function was included in pypy's os 
or before the functions were in the host os module, ie functions added to 
cpython recently).

for example, code to support fchown/fchmod was added 8275a7379d56 but will not 
be included until the translating host python has it in the os module.

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

From tracker at bugs.pypy.org  Sat Feb  9 11:09:57 2013
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Sat, 09 Feb 2013 10:09:57 +0000
Subject: [pypy-issue] [issue1391] cannot pass None values if dtype=='d'
In-Reply-To: <1360404597.41.0.296142963043.issue1391@bugs.pypy.org>
Message-ID: <1360404597.41.0.296142963043.issue1391@bugs.pypy.org>


New submission from Antonio Cuni <anto.cuni at gmail.com>:

Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
>>> import numpy
>>> numpy.array([1.0, 2.0, None], dtype='d')
array([  1.,   2.,  nan])


Python 2.7.3 (64f878febd11, Jan 26 2013, 02:00:18)
[PyPy 2.0.0-beta1 with GCC 4.6.3] on linux2
>>>> numpypy.array([1.0, 2.0, None], dtype='d')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: expected float, got NoneType object

----------
messages: 5280
nosy: pypy-issue
priority: bug
status: unread
title: cannot pass None values if dtype=='d'

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

From tracker at bugs.pypy.org  Sat Feb  9 11:11:05 2013
From: tracker at bugs.pypy.org (benoitc)
Date: Sat, 09 Feb 2013 10:11:05 +0000
Subject: [pypy-issue] [issue1392] _checkClosed method is misisng in
	io.RawIOBase
In-Reply-To: <1360404665.6.0.144734969058.issue1392@bugs.pypy.org>
Message-ID: <1360404665.6.0.144734969058.issue1392@bugs.pypy.org>


New submission from benoitc <bchesneau at gmail.com>:

io.RawIOBase class in cpython have the method _checkClosed called by some modules 
around. This one is missng in pypy.

----------
messages: 5281
nosy: benoitc, pypy-issue
priority: critical
status: unread
title: _checkClosed method is misisng in io.RawIOBase

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

From tracker at bugs.pypy.org  Sat Feb  9 11:11:35 2013
From: tracker at bugs.pypy.org (benoitc)
Date: Sat, 09 Feb 2013 10:11:35 +0000
Subject: [pypy-issue] [issue1392] _checkClosed method is misisng in
	io.RawIOBase
In-Reply-To: <1360404665.6.0.144734969058.issue1392@bugs.pypy.org>
Message-ID: <1360404695.09.0.753121884398.issue1392@bugs.pypy.org>


benoitc <bchesneau at gmail.com> added the comment:

pypy

----------
release:  -> 1.9
status: unread -> chatting

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

From tracker at bugs.pypy.org  Sat Feb  9 11:17:18 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 10:17:18 +0000
Subject: [pypy-issue] [issue1391] cannot pass None values if dtype=='d'
In-Reply-To: <1360404597.41.0.296142963043.issue1391@bugs.pypy.org>
Message-ID: <1360405038.26.0.917581592019.issue1391@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

duplicate of https://bugs.pypy.org/issue1000

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

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

From tracker at bugs.pypy.org  Sat Feb  9 11:48:46 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 09 Feb 2013 10:48:46 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1360406926.1.0.469906343978.issue833@bugs.pypy.org>


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

Using the host python is bad indeed. rffi_platform.configure() could be used 
instead to detect the presence of specific functions.

----------
nosy: +amaury

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

From tracker at bugs.pypy.org  Sat Feb  9 12:05:48 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 11:05:48 +0000
Subject: [pypy-issue] [issue755] pypy trunk fails to build/run on FreeBSD
In-Reply-To: <1308314379.97.0.0230222296775.issue755@bugs.pypy.org>
Message-ID: <1360407948.51.0.583670100468.issue755@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

freebsd7/9 buildbots are translating and running tests now, marking resolved.

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

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

From tracker at bugs.pypy.org  Sat Feb  9 12:13:13 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 11:13:13 +0000
Subject: [pypy-issue] [issue678] stack overflow issue
In-Reply-To: <1301575901.04.0.601080933679.issue678@>
Message-ID: <1360408393.26.0.00497016639626.issue678@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

tested with latest nightly. sometimes works, sometimes gives

Python 2.7.3 (3b06320cf630, Feb 09 2013, 05:01:16)
[PyPy 2.0.0-beta1 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``finally, mercurial migration is
happening!''
>>>> def f(): f()
>>>> for i in range(10000):
....  try: f()
....  except RuntimeError: pass
.... 
cannot find gc roots!
Aborted

----------
nosy: +bdk

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

From tracker at bugs.pypy.org  Sat Feb  9 15:15:42 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 09 Feb 2013 14:15:42 +0000
Subject: [pypy-issue] [issue1392] _checkClosed method is misisng in
	io.RawIOBase
In-Reply-To: <1360404665.6.0.144734969058.issue1392@bugs.pypy.org>
Message-ID: <1360419342.37.0.161139604952.issue1392@bugs.pypy.org>


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

tag:easy

----------
nosy: +amaury

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

From tracker at bugs.pypy.org  Sat Feb  9 21:36:43 2013
From: tracker at bugs.pypy.org (mattip)
Date: Sat, 09 Feb 2013 20:36:43 +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: <1360442203.47.0.674307591587.issue1160@bugs.pypy.org>


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

fixed with changeset fa8c91ae3a18

----------
release: 1.9 -> 2.0
status: chatting -> resolved

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

From tracker at bugs.pypy.org  Sun Feb 10 00:38:37 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 09 Feb 2013 23:38:37 +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: <1360453117.91.0.19174938227.issue1116@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

the distinction between fileobj and myfileobj is important -- we only want to call 
close if gzip opened the fileobj itself, not if it was passed in, so that 'fix' 
isn't correct. the one arigo applied does fix the tracebacks, marking resolved.

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

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

From tracker at bugs.pypy.org  Sun Feb 10 03:09:14 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sun, 10 Feb 2013 02:09:14 +0000
Subject: [pypy-issue] [issue1343] datetime.utcnow() slow
In-Reply-To: <1354196314.23.0.545969896857.issue1343@bugs.pypy.org>
Message-ID: <1360462154.8.0.078996207258.issue1343@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

I recently committed some improvements to datetime.py that increase speed on 
this benchmark by ~33% on my machine. relative timings look like this now:

$ python test.py
6.12707495689
$ ./pypy/goal/pypy-c test.py
8.06428718567

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

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

From tracker at bugs.pypy.org  Sun Feb 10 06:32:08 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sun, 10 Feb 2013 05:32:08 +0000
Subject: [pypy-issue] [issue1366] Djblets-0.6.22 single test failure under
	pypy{1.9, 2.0}
In-Reply-To: <1358132327.84.0.668082834822.issue1366@bugs.pypy.org>
Message-ID: <1360474328.2.0.853148906536.issue1366@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

done in 3655afd07f2f, didn't affect speed.

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

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

From tracker at bugs.pypy.org  Sun Feb 10 11:57:44 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sun, 10 Feb 2013 10:57:44 +0000
Subject: [pypy-issue] [issue1315] exec should change it's globals dict to
	CellDict
In-Reply-To: <1352226302.09.0.146503617709.issue1315@bugs.pypy.org>
Message-ID: <1360493864.94.0.630613984605.issue1315@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

added in 60b3f3d002ba

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

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

From tracker at bugs.pypy.org  Mon Feb 11 01:53:07 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 00:53:07 +0000
Subject: [pypy-issue] [issue1259] module __file__ attribute shows wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360543987.95.0.617651686706.issue1259@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

$ ./pypy/goal/pypy-c 
Python 2.7.3 (8556098ab5f0, Feb 10 2013, 04:31:21)
[PyPy 2.0.0-beta1 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``why did you guys have to make the
builtin fortune more interesting than actual work? i just catched myself
restarting pypy 20 times''
>>>> import sys; sys.__file__
'/home/pypy/module/sys'
>>>> import cPickle; cPickle.__file__
'/home/ubuntu/pypy/lib_pypy/cPickle.pyc'
>>>> import os; os.__file__
'/home/ubuntu/pypy/lib-python/2.7/os.pyc'
>>>> import time; time.__file__
'../../pypy/module/rctime'
>>>> 

these are both inconsistent and not correct. can they be fixed to give sane 
answers? docs seem to imply they should behave like this:

http://pypy.readthedocs.org/en/latest/coding-guide.html#determining-the-
location-of-a-module-implementation

>>>> import sys
>>>> sys.__file__
'/home/hpk/pypy-dist/pypy/module/sys'

>>>> import cPickle
>>>> cPickle.__file__
'/home/hpk/pypy-dist/lib_pypy/cPickle..py'

>>>> import os
>>>> os.__file__
'/home/hpk/pypy-dist/lib-python/2.7/os.py'
>>>>

----------
release:  -> 2.0

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

From tracker at bugs.pypy.org  Mon Feb 11 02:30:56 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 11 Feb 2013 01:30:56 +0000
Subject: [pypy-issue] [issue332] fix the thunk object space bug
In-Reply-To: <1196975382.76.0.494609838906.issue332@>
Message-ID: <1360546256.63.0.0451144705602.issue332@bugs.pypy.org>


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

This code no longer lives.

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

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

From tracker at bugs.pypy.org  Mon Feb 11 02:35:06 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 01:35:06 +0000
Subject: [pypy-issue] [issue1393] benchmarks are crashing
In-Reply-To: <1360546506.33.0.49464431618.issue1393@bugs.pypy.org>
Message-ID: <1360546506.33.0.49464431618.issue1393@bugs.pypy.org>


New submission from bdk <bdkearns at gmail.com>:

haven't been produced since jan 29

----------
messages: 5296
nosy: bdk, pypy-issue
priority: bug
release: 2.0
status: unread
title: benchmarks are crashing

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

From tracker at bugs.pypy.org  Mon Feb 11 02:45:45 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 01:45:45 +0000
Subject: [pypy-issue] [issue1096] dbm stops reading data at the first null
	byte
In-Reply-To: <1332598577.22.0.031408064693.issue1096@bugs.pypy.org>
Message-ID: <1360547145.42.0.205499260607.issue1096@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in 3bca589bc8bd

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

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

From tracker at bugs.pypy.org  Mon Feb 11 08:46:25 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 11 Feb 2013 07:46:25 +0000
Subject: [pypy-issue] [issue1259] module __file__ attribute shows wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360568785.82.0.326506985421.issue1259@bugs.pypy.org>


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

Please explain why they are incorrect. The only weird thing I see is the "../.." 
in time.__file__.  Otherwise they correctly reflect where the implementation 
lives.

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

From tracker at bugs.pypy.org  Mon Feb 11 09:09:22 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 11 Feb 2013 08:09:22 +0000
Subject: [pypy-issue] [issue1316] fix the namedtuple slowness
In-Reply-To: <1352285693.77.0.17840508792.issue1316@bugs.pypy.org>
Message-ID: <1360570162.6.0.1819253764.issue1316@bugs.pypy.org>


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

Resolved

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

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

From tracker at bugs.pypy.org  Mon Feb 11 09:10:51 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 08:10:51 +0000
Subject: [pypy-issue] [issue1098] sys.stdout.close() from interactive
	session crashes pypy	and messes up terminal
In-Reply-To: <1332636682.08.0.8292785494.issue1098@bugs.pypy.org>
Message-ID: <1360570251.67.0.235065778019.issue1098@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

since a sync seemed overdue, i backported this and a couple other obvious cleanups 
in 02a691b8f00d

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

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

From tracker at bugs.pypy.org  Mon Feb 11 09:12:22 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 08:12:22 +0000
Subject: [pypy-issue] [issue1259] module __file__ attribute shows wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360570342.55.0.587591434006.issue1259@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

In my case they should be
/home/ubuntu/pypy/pypy/module/sys
not
/home/pypy/module/sys

it would be as if the "hpk/pypy-dist" part of the docs example were always 
stripped.

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

From tracker at bugs.pypy.org  Mon Feb 11 10:22:30 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 11 Feb 2013 09:22:30 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360574550.01.0.882997286547.issue1259@bugs.pypy.org>


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

sys is a builtin-module, so the path is computed at translation time.
In my case I see some buildbot working directory.
Maybe we should try to not leak this information and hack something like
sys.__file__ = "pypy/module/sys"

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

From tracker at bugs.pypy.org  Mon Feb 11 10:27:32 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 09:27:32 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360574852.84.0.94771101287.issue1259@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

right, but both sys and time are builtin modules. what's going on to give them 
differing attributes? that should be fixed.

also to me, the behavior as the docs have it makes the most sense -- at least it 
matches for a self translated pypy, and for a released build it refers to a 
nonexistent path but at least parallels the external modules. it's better than 
pointing off to somewhere that's non even rooted in the pypy dir...

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

From tracker at bugs.pypy.org  Mon Feb 11 10:36:26 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 09:36:26 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360575386.22.0.0538136346842.issue1259@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

furthermore, this behavior has changed sometime in the past months:

$ ~/pypy-c-jit-57379-5c84521f68f5-linux64/bin/pypy 
imPython 2.7.3 (5c84521f68f5, Sep 19 2012, 04:35:33)
[PyPy 1.9.1-dev0 with GCC 4.7.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
pAnd now for something completely different: ``redefining yellow seems like a
better idea''
>>>> import sys
>>>> print sys.__file__
/home/buildslave/bot64/pypy-c-jit-linux-x86-64/build/pypy/module/sys

$ ~/pypy-c-jit-61025-8556098ab5f0-linux64/bin/pypy 
Python 2.7.3 (8556098ab5f0, Feb 10 2013, 04:31:21)
[PyPy 2.0.0-beta1 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``happy new year''
>>>> import sys
>>>> print sys.__file__
/home/pypy/module/sys

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

From tracker at bugs.pypy.org  Mon Feb 11 10:38:23 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 09:38:23 +0000
Subject: [pypy-issue] [issue1310] OpenIndiana (Solaris derivative) buildbot
	available
In-Reply-To: <1351728091.54.0.904682149378.issue1310@bugs.pypy.org>
Message-ID: <1360575503.1.0.579797410951.issue1310@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

can someone setup nightly builds on this? seems to be sitting idle.

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

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

From tracker at bugs.pypy.org  Mon Feb 11 10:47:38 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 11 Feb 2013 09:47:38 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360576058.06.0.926437878261.issue1259@bugs.pypy.org>


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

- The 1.9.1 version you show was built by the buildbot, and certainly downloaded from nightly builds.
- rev 61025 suggest that it's a local clone (with a different history of commits). I guess you compiled 
it locally, in /home/pypy.

The ../.. is a bug IMO, certainly related to the recent rpython split.


"The orders have not been changed, said the lamplighter. That is the tragedy." (Le Petit Prince: Chapter 
14)

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

From tracker at bugs.pypy.org  Mon Feb 11 11:11:34 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 10:11:34 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1360576058.06.0.926437878261.issue1259@bugs.pypy.org>
Message-ID: <CACw2m-ZXQND90GbOHPFPZq9ZLp62JaiQ_MVj4pMnmwv-FLBzKg@mail.gmail.com>


bdk <bdkearns at gmail.com> added the comment:

Both came from the buildbots. Additionally, I have no /home/pypy, and I
doubt the buildbot does either.

On Mon, Feb 11, 2013 at 1:47 AM, Amaury Forgeot d Arc <tracker at bugs.pypy.org
> wrote:

>
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
>
> - The 1.9.1 version you show was built by the buildbot, and certainly
> downloaded from nightly builds.
> - rev 61025 suggest that it's a local clone (with a different history of
> commits). I guess you compiled
> it locally, in /home/pypy.
>
> The ../.. is a bug IMO, certainly related to the recent rpython split.
>
>
> "The orders have not been changed, said the lamplighter. That is the
> tragedy." (Le Petit Prince: Chapter
> 14)
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1259>
> ________________________________________
>

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

From tracker at bugs.pypy.org  Mon Feb 11 11:27:25 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 11 Feb 2013 10:27:25 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360578445.66.0.601739481903.issue1259@bugs.pypy.org>


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

Ah, right. It seems that sys.__file__ uses abspath() somewhere. '/home/pypy/module/sys' is '../../pypy/module/sys', relative to the *current* pwd.

Bad bad...

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

From tracker at bugs.pypy.org  Mon Feb 11 11:34:35 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 10:34:35 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360578875.6.0.0225873057637.issue1259@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

Well, I checked several builtin modules and each I checked was like sys, time is 
an odd one out, so I'd guess it wasn't something sys was doing specifically but 
something that time is somehow avoiding.

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

From tracker at bugs.pypy.org  Mon Feb 11 13:47:02 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 12:47:02 +0000
Subject: [pypy-issue] [issue1394] numpypy concatenate segfault
In-Reply-To: <1360586822.04.0.261438755299.issue1394@bugs.pypy.org>
Message-ID: <1360586822.04.0.261438755299.issue1394@bugs.pypy.org>


New submission from bdk <bdkearns at gmail.com>:

from _numpypy import ones, concatenate
for i in range(100):
    a = ones((1,4,7))
    b = ones((1,0,7))
    concatenate((a,b), 1)

----------
messages: 5310
nosy: bdk, pypy-issue
priority: bug
release: 2.0
status: unread
title: numpypy concatenate segfault

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

From tracker at bugs.pypy.org  Mon Feb 11 14:53:29 2013
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 11 Feb 2013 13:53:29 +0000
Subject: [pypy-issue] [issue1000] creating numpypy array from list with None
	elements
In-Reply-To: <1326602103.1.0.102153689611.issue1000@bugs.pypy.org>
Message-ID: <1360590809.36.0.999653268509.issue1000@bugs.pypy.org>


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

fixed by 0805e1ac97db

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

From tracker at bugs.pypy.org  Mon Feb 11 17:34:20 2013
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 11 Feb 2013 16:34:20 +0000
Subject: [pypy-issue] [issue1281] numpypy: "copying over different dtypes"
	is wrongly	reported
In-Reply-To: <1349697251.05.0.0330366935338.issue1281@bugs.pypy.org>
Message-ID: <1360600460.61.0.0187191856505.issue1281@bugs.pypy.org>


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

fixed in 2d3671965584

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

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

From tracker at bugs.pypy.org  Mon Feb 11 17:34:44 2013
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Mon, 11 Feb 2013 16:34:44 +0000
Subject: [pypy-issue] [issue1389] "copying over different dtypes
	unsupported", but the dtype is the same
In-Reply-To: <1360340389.05.0.93382592622.issue1389@bugs.pypy.org>
Message-ID: <1360600484.09.0.395394096337.issue1389@bugs.pypy.org>


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

fixed in 2d3671965584

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

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

From tracker at bugs.pypy.org  Mon Feb 11 22:37:18 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 11 Feb 2013 21:37:18 +0000
Subject: [pypy-issue] [issue1394] numpypy concatenate segfault
In-Reply-To: <1360586822.04.0.261438755299.issue1394@bugs.pypy.org>
Message-ID: <1360618638.5.0.682012363183.issue1394@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in 5401a6758467 thanks mattip

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

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

From tracker at bugs.pypy.org  Tue Feb 12 00:04:35 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Mon, 11 Feb 2013 23:04:35 +0000
Subject: [pypy-issue] [issue1259] builtin module __file__ attribute shows
	wrong path
In-Reply-To: <1347356422.5.0.518215816362.issue1259@bugs.pypy.org>
Message-ID: <1360623875.02.0.636752674376.issue1259@bugs.pypy.org>


Philip Jenvey <pjenvey at underboss.org> added the comment:

site.py goes through sys.modules at startup and abspath's all their __file__s, it 
seems to be the cause (try it w/ -S). I agree these builtin modules shouldn't have 
a __file__, it's bound to break something

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

From tracker at bugs.pypy.org  Tue Feb 12 02:41:56 2013
From: tracker at bugs.pypy.org (Andrew McNabb)
Date: Tue, 12 Feb 2013 01:41:56 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1360633316.02.0.763128229739.issue1145@bugs.pypy.org>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

I'm seeing something similar to this with numpypy in PyPy 1.9.0. I'm basically 
seeing an explosion of memory usage, but the function seems simple enough to 
make me doubt that it's lazy evaluation. Is there an easy way to tell if the 
problem I'm seeing is caused by lazy evaluation or by something else? Is there 
an easy way to disable lazy evaluation at run-time? I don't want to open a new 
report unless I'm sure that it's different from this bug. Thanks.

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

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

From tracker at bugs.pypy.org  Tue Feb 12 07:51:08 2013
From: tracker at bugs.pypy.org (bdk)
Date: Tue, 12 Feb 2013 06:51:08 +0000
Subject: [pypy-issue] [issue1395] performance regression on
	genshi_text/genshi_xml
In-Reply-To: <1360651868.82.0.536197747008.issue1395@bugs.pypy.org>
Message-ID: <1360651868.82.0.536197747008.issue1395@bugs.pypy.org>


New submission from bdk <bdkearns at gmail.com>:

Between the benchmark runs on Jan29 and Feb10, timings on genshi_text and 
genshi_xlm jumped 100-200%. Run on Feb11 had the same results so it doesn't seem 
like noise.

----------
messages: 5317
nosy: bdk, pypy-issue
priority: performance bug
release: 2.0
status: unread
title: performance regression on genshi_text/genshi_xml

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

From tracker at bugs.pypy.org  Tue Feb 12 08:03:40 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 12 Feb 2013 07:03:40 +0000
Subject: [pypy-issue] [issue1395] performance regression on
	genshi_text/genshi_xml
In-Reply-To: <1360651868.82.0.536197747008.issue1395@bugs.pypy.org>
Message-ID: <1360652620.89.0.699979432116.issue1395@bugs.pypy.org>


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

Many changes... Some suspects:
- Convert w_globals passed to exec to celldict (60b3f3d002ba)
- various optimizations in lib_pypy/_collections.py

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

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

From tracker at bugs.pypy.org  Tue Feb 12 10:28:03 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 12 Feb 2013 09:28:03 +0000
Subject: [pypy-issue] [issue1395] performance regression on
	genshi_text/genshi_xml
In-Reply-To: <1360651868.82.0.536197747008.issue1395@bugs.pypy.org>
Message-ID: <1360661283.58.0.466337056193.issue1395@bugs.pypy.org>


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

Eh, indeed. I should check it.

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

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

From tracker at bugs.pypy.org  Tue Feb 12 16:19:43 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 12 Feb 2013 15:19:43 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1360682383.14.0.379583642208.issue1145@bugs.pypy.org>


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

Hi.

It's fixed since 1.9. Closing for now, feel free to reopen if you experience it 
in 2.0.

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

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

From tracker at bugs.pypy.org  Tue Feb 12 17:35:42 2013
From: tracker at bugs.pypy.org (Andrew McNabb)
Date: Tue, 12 Feb 2013 16:35:42 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1360686942.38.0.748328980436.issue1145@bugs.pypy.org>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

Yes, but how do I know if I'm experiencing the same bug or something else? I 
guess I'll try doing PyPy 2.0 beta, but it will probably take a while to compile 
and test.

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

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

From tracker at bugs.pypy.org  Tue Feb 12 18:56:28 2013
From: tracker at bugs.pypy.org (Andrew McNabb)
Date: Tue, 12 Feb 2013 17:56:28 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1360691788.25.0.290138025394.issue1145@bugs.pypy.org>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

Okay, I've finally been able to test with PyPy 2.0 beta, and it looks like the 
problem is fixed. Thanks.

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

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

From tracker at bugs.pypy.org  Tue Feb 12 22:24:26 2013
From: tracker at bugs.pypy.org (bdk)
Date: Tue, 12 Feb 2013 21:24:26 +0000
Subject: [pypy-issue] [issue1395] performance regression on
	genshi_text/genshi_xml
In-Reply-To: <1360651868.82.0.536197747008.issue1395@bugs.pypy.org>
Message-ID: <1360704266.4.0.793465382159.issue1395@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

hg backout on 60b3f3d002ba and benchmarks are back to previous state.

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

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

From tracker at bugs.pypy.org  Tue Feb 12 22:52:46 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 12 Feb 2013 21:52:46 +0000
Subject: [pypy-issue] [issue1396] @signature doesn't work with types.Self()
	and PBC
In-Reply-To: <1360705966.8.0.906253312241.issue1396@bugs.pypy.org>
Message-ID: <1360705966.8.0.906253312241.issue1396@bugs.pypy.org>


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

basically if self becomes a PBC then the `types.self()` thing doesn't work

----------
messages: 5324
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: @signature doesn't work with types.Self() and PBC

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

From tracker at bugs.pypy.org  Tue Feb 12 23:00:03 2013
From: tracker at bugs.pypy.org (Greg Price)
Date: Tue, 12 Feb 2013 22:00:03 +0000
Subject: [pypy-issue] [issue1396] @signature doesn't work with types.Self()
	and PBC
In-Reply-To: <1360705966.8.0.906253312241.issue1396@bugs.pypy.org>
Message-ID: <1360706403.06.0.61615405371.issue1396@bugs.pypy.org>


Greg Price <gnprice at gmail.com> added the comment:

Thanks. Can you provide a short example to make the issue clear? I think I can 
construct one from your description but it would be good to be sure we're 
discussing the same thing.

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

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

From tracker at bugs.pypy.org  Tue Feb 12 23:01:27 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 12 Feb 2013 22:01:27 +0000
Subject: [pypy-issue] [issue1396] @signature doesn't work with types.Self()
	and PBC
In-Reply-To: <1360705966.8.0.906253312241.issue1396@bugs.pypy.org>
Message-ID: <1360706487.61.0.241455330299.issue1396@bugs.pypy.org>


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

Going from memory here (sorry for all the types ;))

class X(object):
  def _freeze_(self):
    return True

  @signature(types.self())
  def method(self):
    pass

def test_foo():
  x = X()
  def f():
    return x.method()

  translate(f)

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

From tracker at bugs.pypy.org  Wed Feb 13 09:52:06 2013
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 13 Feb 2013 08:52:06 +0000
Subject: [pypy-issue] [issue1234] Poor seek set performance (compared to
	cpython 2.7)
In-Reply-To: <1344847072.2.0.452643258492.issue1234@bugs.pypy.org>
Message-ID: <1360745526.94.0.0363288216679.issue1234@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in 66d1e56f69a4

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

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

From tracker at bugs.pypy.org  Wed Feb 13 12:39:36 2013
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 13 Feb 2013 11:39:36 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>


New submission from bdk <bdkearns at gmail.com>:

The attached script produces different outputs on python and pypy.

----------
files: test_file.py
messages: 5328
nosy: bdk, pypy-issue
priority: bug
status: unread
title: file stream behavior differences from cpython

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

From tracker at bugs.pypy.org  Wed Feb 13 17:22:36 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 13 Feb 2013 16:22:36 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1360772556.63.0.276062499174.issue1397@bugs.pypy.org>


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

I think this is generally acceptable. It's well documented not to use both 
methods of reading from files at the same time.

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

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

From tracker at bugs.pypy.org  Wed Feb 13 23:31:04 2013
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 13 Feb 2013 22:31:04 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1360794664.45.0.355470080011.issue1397@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

Surely one can use it as a file stream and then afterwards as a fd? And then 
have some expectations about the interactions?

Cpython docs explicitly state "File objects are implemented using C?s stdio 
package" and other things like "This function is simply a wrapper for the 
underlying fread() C function, and will behave the same in corner cases, such as 
whether the EOF value is cached."

Surely someone might depend on these behaviors, that file objects behave as 
stdio streams with regards to interactions with low level file descriptor calls?

I don't see any note in pypy's 'differences from cpython' doc either.

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

From tracker at bugs.pypy.org  Thu Feb 14 08:31:21 2013
From: tracker at bugs.pypy.org (bdk)
Date: Thu, 14 Feb 2013 07:31:21 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1360827081.86.0.203128148381.issue1397@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

Also, maybe https://bugs.pypy.org/issue1283 is an issue stemming from the same 
underlying difference, an issue that doesn't even require one to 'abuse' it by 
using the python file object and the fd? There are probably other differences 
that might arise too, like the one the CPython docs I quoted imply. Not to 
mention the inefficiencies that exist in pypy's hand-coded/reimplemented file 
streams -- examine an strace of repeated f.tell() in cpython vs pypy, or even 
read, tell, read, tell...

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

From tracker at bugs.pypy.org  Thu Feb 14 11:03:41 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 14 Feb 2013 10:03:41 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1360836221.8.0.703881910437.issue1397@bugs.pypy.org>


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

The python docs don't state it prominently, but C docs very clearly state you 
should *never* use a combination of fread and read on the same fd. Most notably 
the behavior will differ between platforms, since the caching strategy depends on 
the libc.

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

From tracker at bugs.pypy.org  Thu Feb 14 15:10:02 2013
From: tracker at bugs.pypy.org (bdk)
Date: Thu, 14 Feb 2013 14:10:02 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1360851002.86.0.487291199353.issue1397@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

Sure, but given that the CPython docs explicitly state a file object is a 
wrapper on top of FILE*/to expect FILE* behavior in corner cases, and the PyPy 
ones "Differences that are not listed here should be considered bugs of PyPy.", 
I think this is worth mentioning in PyPy docs.

Now the real question is why doesn't PyPy simply use FILE* objects? PyPy should 
either do this or fix the remaining deficiencies in the streamio.py code (but 
this seems like a waste of time vs plugging into FILE* to me).

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

From amauryfa at gmail.com  Thu Feb 14 15:47:55 2013
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 14 Feb 2013 15:47:55 +0100
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360851002.86.0.487291199353.issue1397@bugs.pypy.org>
References: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
	<1360851002.86.0.487291199353.issue1397@bugs.pypy.org>
Message-ID: <CAGmFidZucmXe-kh67GZNo4GXxuges0ebQfQQcNiD3maiLjqfug@mail.gmail.com>

2013/2/14 bdk <tracker at bugs.pypy.org>

>
> bdk <bdkearns at gmail.com> added the comment:
>
> Sure, but given that the CPython docs explicitly state a file object is a
> wrapper on top of FILE*/to expect FILE* behavior in corner cases, and the
> PyPy
> ones "Differences that are not listed here should be considered bugs of
> PyPy.",
> I think this is worth mentioning in PyPy docs.
>
> Now the real question is why doesn't PyPy simply use FILE* objects? PyPy
> should
> either do this or fix the remaining deficiencies in the streamio.py code
> (but
> this seems like a waste of time vs plugging into FILE* to me).


It's an ooold story, but I remember that streamio.py started as a "gitft
from Guido" -- something you cannot refuse.

At the time, one of PyPy directions was to rewrite every low-level library
in Python,
so something that bypasses libc was welcome.

-- 
Amaury Forgeot d'Arc

From tracker at bugs.pypy.org  Thu Feb 14 16:12:00 2013
From: tracker at bugs.pypy.org (Erez)
Date: Thu, 14 Feb 2013 15:12:00 +0000
Subject: [pypy-issue] [issue1398] Pypy crashes under memory stress
In-Reply-To: <1360854720.34.0.816963506971.issue1398@bugs.pypy.org>
Message-ID: <1360854720.34.0.816963506971.issue1398@bugs.pypy.org>


New submission from Erez <erez27 at gmail.com>:

Pypy 2.0.0-beta1 crashed while running an intensive computation that used up the 
entire memory. A more proper response would be throw MemoryError (as it often 
does on other occasions).

Crash error:
RPython traceback:
  File "pypy_jit_metainterp_warmspot.c", line 986, in 
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_jit_metainterp_warmstate.c", line 494, in 
maybe_compile_and_run__star_5
  File "pypy_jit_metainterp_warmstate.c", line 4751, in 
execute_assembler__star_2_1
  File "pypy_jit_metainterp_compile.c", line 5410, in 
ResumeGuardForcedDescr_handle_fail
Fatal RPython error: AssertionError

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



PyPy Version:
Python 2.7.3 (7e4f0faa3d51, Nov 22 2012, 10:06:18)
[PyPy 2.0.0-beta1 with MSC v.1500 32 bit] on win32

My System:
Windows 7 64-bit, 4gb of memory

----------
messages: 5335
nosy: erez, pypy-issue
priority: bug
status: unread
title: Pypy crashes under memory stress

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

From fijall at gmail.com  Thu Feb 14 17:02:51 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 14 Feb 2013 18:02:51 +0200
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <CAGmFidZucmXe-kh67GZNo4GXxuges0ebQfQQcNiD3maiLjqfug@mail.gmail.com>
References: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
	<1360851002.86.0.487291199353.issue1397@bugs.pypy.org>
	<CAGmFidZucmXe-kh67GZNo4GXxuges0ebQfQQcNiD3maiLjqfug@mail.gmail.com>
Message-ID: <CAK5idxRwrCJK5TVn6M8w9X-kRkomO3gPGOhqX=h0xDmYQUn81Q@mail.gmail.com>

On Thu, Feb 14, 2013 at 4:47 PM, Amaury Forgeot d'Arc
<amauryfa at gmail.com> wrote:
> 2013/2/14 bdk <tracker at bugs.pypy.org>
>>
>>
>> bdk <bdkearns at gmail.com> added the comment:
>>
>> Sure, but given that the CPython docs explicitly state a file object is a
>> wrapper on top of FILE*/to expect FILE* behavior in corner cases, and the
>> PyPy
>> ones "Differences that are not listed here should be considered bugs of
>> PyPy.",
>> I think this is worth mentioning in PyPy docs.
>>
>> Now the real question is why doesn't PyPy simply use FILE* objects? PyPy
>> should
>> either do this or fix the remaining deficiencies in the streamio.py code
>> (but
>> this seems like a waste of time vs plugging into FILE* to me).
>
>
> It's an ooold story, but I remember that streamio.py started as a "gitft
> from Guido" -- something you cannot refuse.
>
> At the time, one of PyPy directions was to rewrite every low-level library
> in Python,
> so something that bypasses libc was welcome.
>
> --
> Amaury Forgeot d'Arc

Is there any reason to keep doing that btw?

From tracker at bugs.pypy.org  Sat Feb 16 10:37:46 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 16 Feb 2013 09:37:46 +0000
Subject: [pypy-issue] [issue1289] multiprocessing Pool + maxtasksperchild +
	signal =	ValueError
In-Reply-To: <1350317901.63.0.635751910168.issue1289@bugs.pypy.org>
Message-ID: <1361007466.4.0.604891882841.issue1289@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

the bug's test case works fine now, and more cleanup after fork applied in 
8f52d162f0ee, marking resolved.

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

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

From tracker at bugs.pypy.org  Sun Feb 17 05:34:33 2013
From: tracker at bugs.pypy.org (Julian Berman)
Date: Sun, 17 Feb 2013 04:34:33 +0000
Subject: [pypy-issue] [issue1399] The datetime module appears to be old (and
	has some	divergence from CPython)
In-Reply-To: <1361075673.65.0.675376784667.issue1399@bugs.pypy.org>
Message-ID: <1361075673.65.0.675376784667.issue1399@bugs.pypy.org>


New submission from Julian Berman <Julian+PyPy at GrayVines.com>:

The following code performs differently on CPython and PyPy:

import decimal, datetime
datetime.datetime(decimal.Decimal(2012), 12, 12)

PyPy dies with a TypeError. It appears it's being overzealous with a type check 
in _check_time_fields.

More broadly though, the comment in lib_pypy/datetime.py seems to suggest that 
it's probably an old version copied from 2003 (it says "This was originally 
copied from the sandbox of the CPython CVS repository.
Thanks to Tim Peters for suggesting using it.") whereas as of 
http://bugs.python.org/issue7989 it seems that CPython now has a pure-python 
datetime library that could be used / backported to 2.7.

----------
messages: 5338
nosy: Julian, pypy-issue
priority: bug
status: unread
title: The datetime module appears to be old (and has some divergence from CPython)

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

From tracker at bugs.pypy.org  Sun Feb 17 12:21:07 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sun, 17 Feb 2013 11:21:07 +0000
Subject: [pypy-issue] [issue1399] The datetime module appears to be old (and
	has some	divergence from CPython)
In-Reply-To: <1361075673.65.0.675376784667.issue1399@bugs.pypy.org>
Message-ID: <1361100067.01.0.683370631392.issue1399@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

A single comment doesn't imply the entire file is old.

Why don't you be more specific? What PyPy version 'dies' with a TypeError? 
Recent builds work fine -- I see this:

$ ./pypy/goal/pypy-c --version
Python 2.7.3 (2a03b3b62fba, Feb 14 2013, 02:00:12)
[PyPy 2.0.0-beta1 with GCC 4.6.3]
$ ./pypy/goal/pypy-c 
Python 2.7.3 (2a03b3b62fba, Feb 14 2013, 02:00:12)
[PyPy 2.0.0-beta1 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``a 10th of forever is 1h45''
>>>> import decimal, datetime
>>>> datetime.datetime(decimal.Decimal(2012), 12, 12)
datetime.datetime(2012, 12, 12, 0, 0)
>>>> 
$ ./pypy/goal/pypy-c --version
Python 2.7.3 (2a03b3b62fba, Feb 14 2013, 02:00:12)
[PyPy 2.0.0-beta1 with GCC 4.6.3]

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

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

From tracker at bugs.pypy.org  Sun Feb 17 15:39:56 2013
From: tracker at bugs.pypy.org (Julian Berman)
Date: Sun, 17 Feb 2013 14:39:56 +0000
Subject: [pypy-issue] [issue1399] The datetime module appears to be old (and
	has some	divergence from CPython)
In-Reply-To: <1361075673.65.0.675376784667.issue1399@bugs.pypy.org>
Message-ID: <1361111996.02.0.995891201738.issue1399@bugs.pypy.org>


Julian Berman <Julian+PyPy at GrayVines.com> added the comment:

... I'm not sure if you're being intentionally misleading or just forgetful :), 
but hg log appears to show you fixed this last week. So it appears this is done, 
at least for the case I encountered. The relevant version was 1.9.

And no, of course it doesn't, but combined with some quick visual inspection, a 
failing case, and a caveat for "probably", it seemed like a good first guess.

Anyways, thanks.

----------
release:  -> 1.9
status: chatting -> invalid

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

From tracker at bugs.pypy.org  Sun Feb 17 17:17:50 2013
From: tracker at bugs.pypy.org (klankschap)
Date: Sun, 17 Feb 2013 16:17:50 +0000
Subject: [pypy-issue] [issue629] "Cannot find gc roots" messages on Linux
In-Reply-To: <1296343807.1.0.373645133691.issue629@>
Message-ID: <1361117870.53.0.804539437135.issue629@bugs.pypy.org>


klankschap <vm at klankschap.nl> added the comment:

while using multiprocessing Pool i do (randomly) get this message.
'cannot find gc roots!'
The pool tasks continue, but it will fail the join()


(using 24d0ce574830 feb 12 2013 on ubuntu)

----------
nosy: +klankschap
release: ??? -> 2.0
status: resolved -> in-progress

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

From tracker at bugs.pypy.org  Mon Feb 18 03:12:24 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 18 Feb 2013 02:12:24 +0000
Subject: [pypy-issue] [issue641] reading CSV files with csv module is much
	slower than	CPython 2.6.6
In-Reply-To: <1298466755.89.0.819503203326.issue641@>
Message-ID: <1361153544.83.0.209070315427.issue641@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

Tested the modified _csv.py and it produces no measurable speedup on latest 
nightly, so I assume either the JIT has been improved and the modifications are 
no longer necessary, or the worthwhile modifications were incorporated in some 
form and not noted here.

Current relative timings to CPython 2.7.3 are as you have in "After changes to 
csv module's reader": about 1.3-1.5x CPython.

----------
nosy: +bdk
release: 1.4 -> 

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

From tracker at bugs.pypy.org  Mon Feb 18 08:34:34 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 18 Feb 2013 07:34:34 +0000
Subject: [pypy-issue] [issue1327] "x in deque" slow
In-Reply-To: <1353089889.71.0.963350944607.issue1327@bugs.pypy.org>
Message-ID: <1361172874.77.0.49665089713.issue1327@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed in 7a0d27055cb4. timings look like this now:

$ time python deque_in_bench.py
real	0m0.730s
user	0m0.720s
sys	0m0.004s

$ time ./pypy/goal/pypy-c deque_in_bench.py
real	0m0.136s
user	0m0.128s
sys	0m0.004s

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

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

From tracker at bugs.pypy.org  Mon Feb 18 08:45:22 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 18 Feb 2013 07:45:22 +0000
Subject: [pypy-issue] [issue641] reading CSV files with csv module is much
	slower than	CPython 2.6.6
In-Reply-To: <1298466755.89.0.819503203326.issue641@>
Message-ID: <1361173522.67.0.769860588557.issue641@bugs.pypy.org>


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

1.3-1.5 is not too bad given that it's pure python vs a C extension. Closing this 
issue

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

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

From tracker at bugs.pypy.org  Mon Feb 18 11:06:30 2013
From: tracker at bugs.pypy.org (David)
Date: Mon, 18 Feb 2013 10:06:30 +0000
Subject: [pypy-issue] [issue1400] Translatorshell does not generate a
	callable translated	function
In-Reply-To: <1361181990.37.0.891033289947.issue1400@bugs.pypy.org>
Message-ID: <1361181990.37.0.891033289947.issue1400@bugs.pypy.org>


New submission from David <david.schneider at uni-duesseldorf.de>:

Running the translation steps as described in the translator shell (see below) 
creates a LocalPath object instead of a callable wrapper for the translated 
version of the function.

def func(n): 
    return n+1
t = Translation(func, [int])
t.annotate()
t.rtype() 
f = t.compile_c()

----------
messages: 5345
nosy: bivab, pypy-issue
priority: bug
status: unread
title: Translatorshell does not generate a callable translated function

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

From tracker at bugs.pypy.org  Mon Feb 18 11:28:10 2013
From: tracker at bugs.pypy.org (klankschap)
Date: Mon, 18 Feb 2013 10:28:10 +0000
Subject: [pypy-issue] [issue1401] ImportError: No module named ...
In-Reply-To: <1361183290.46.0.334431454931.issue1401@bugs.pypy.org>
Message-ID: <1361183290.46.0.334431454931.issue1401@bugs.pypy.org>


New submission from klankschap <vm at klankschap.nl>:

pypy fails to recognize a module with only .pyc files in it.

try this:

mkdir module
touch module/__init__.py
touch module/one.py
python -c "from module import one"
rm module/*.py
python -c "from module import one"
python -c "import module.one"

if you replace 'python' by 'pypy', it will fail as soon as the module folder only 
has *.pyc files in it.

Do you always need the .py files in the modules for pypy to run properly?

.F

----------
messages: 5346
nosy: klankschap, pypy-issue
priority: critical
release: 2.0
status: unread
title: ImportError: No module named ...

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

From tracker at bugs.pypy.org  Mon Feb 18 11:30:49 2013
From: tracker at bugs.pypy.org (David)
Date: Mon, 18 Feb 2013 10:30:49 +0000
Subject: [pypy-issue] [issue1400] Translatorshell does not generate a
	callable translated	function
In-Reply-To: <1361181990.37.0.891033289947.issue1400@bugs.pypy.org>
Message-ID: <1361183449.92.0.170447284622.issue1400@bugs.pypy.org>


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

updated the documentation to reflect that this is the intended behavior

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

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

From tracker at bugs.pypy.org  Mon Feb 18 12:02:59 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 18 Feb 2013 11:02:59 +0000
Subject: [pypy-issue] [issue1401] ImportError: No module named ...
In-Reply-To: <1361183290.46.0.334431454931.issue1401@bugs.pypy.org>
Message-ID: <1361185379.37.0.954000922125.issue1401@bugs.pypy.org>


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

Yes, this is a deliberate feature of pypy:
http://doc.pypy.org/en/latest/config/objspace.lonepycfiles.html
"""
[importing lone .pyc files] is a common cause of issues: most typically, the x.py file is removed 
(manually or by a version control system) but the x module remains accidentally importable because 
the x.pyc file stays around.
"""

Note that this has been removed from the 3.2 version of pypy: since Python3 puts .pyc files in a 
dedicated __pycache__ directory and always checks for the presence of a .py file in the normal place, 
the argument above does not stand anymore.
In Python3, a .pyc file deliberately put in a PYTHONPATH directory cannot be confused with a compiled 
.pyc.

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

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

From tracker at bugs.pypy.org  Mon Feb 18 17:29:04 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 18 Feb 2013 16:29:04 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1361204944.84.0.778058085225.issue1397@bugs.pypy.org>


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

Fwiw Python 3 also reimplements (its own version of) streamio.py.  This doesn't
mean there would be no point in saying "too bad" now and give up at least for
"PyPy 2".  It's something I would find perfectly acceptable too; and breaking
the OO translations of PyPy until someone comes along and fix them seems
acceptable as well.

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

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

From tracker at bugs.pypy.org  Mon Feb 18 17:31:12 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 18 Feb 2013 16:31:12 +0000
Subject: [pypy-issue] [issue629] "Cannot find gc roots" messages on Linux
In-Reply-To: <1296343807.1.0.373645133691.issue629@>
Message-ID: <1361205072.54.0.526822583559.issue629@bugs.pypy.org>


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

klankschap: you need to give us more information, ideally a way to reproduce it
(e.g. the complete script you're running).

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

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

From tracker at bugs.pypy.org  Mon Feb 18 17:48:53 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 18 Feb 2013 16:48:53 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1361206134.0.0.908901247421.issue1397@bugs.pypy.org>


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

The answer to my Python 3 question is that py3k's _io module (just like the one
on pypy for Python 2) don't use streamio.py at all.  This means that the latter
has no more reason to be kept alive.  Kill kill kill!

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

From tracker at bugs.pypy.org  Mon Feb 18 18:01:21 2013
From: tracker at bugs.pypy.org (klankschap)
Date: Mon, 18 Feb 2013 17:01:21 +0000
Subject: [pypy-issue] [issue629] "Cannot find gc roots" messages on Linux
In-Reply-To: <1361205072.54.0.526822583559.issue629@bugs.pypy.org>
Message-ID: <8C99EE9F-4FF8-47FC-975D-814B859B2D41@klankschap.nl>


klankschap <vm at klankschap.nl> added the comment:

On 18 Feb 2013, at 17:31, Armin Rigo wrote:

> 
> Armin Rigo <armin.rigo at gmail.com> added the comment:
> 
> klankschap: you need to give us more information, ideally a way to reproduce it
> (e.g. the complete script you're running).

As i mentioned, it appears randomly.
No way to reproduce.
It just seems to happen when i have more tasks in the pool then i have processors.
With 4 cores (8 virtual cores) installed:

nrTask = 32

taskSeeds = [random.random() for i in range(nrTask)]
pool = multiprocessing.Pool()
for iid,s in enumerate(taskSeeds):
	arg = ( iid, s, G )
	pool.apply_async(task, args=arg, callback=log_result)
pool.close()
pool.join()

With nrTasks larger then 8 it is more likely to happen.

.F

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

From tracker at bugs.pypy.org  Mon Feb 18 18:08:46 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 18 Feb 2013 17:08:46 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1361207326.95.0.553860068587.issue1397@bugs.pypy.org>


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

Last time I looked, streamio is still used in some places; maybe the marshal 
module.

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

From fijall at gmail.com  Mon Feb 18 18:18:37 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 18 Feb 2013 19:18:37 +0200
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1361207326.95.0.553860068587.issue1397@bugs.pypy.org>
References: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
	<1361207326.95.0.553860068587.issue1397@bugs.pypy.org>
Message-ID: <CAK5idxQANgB1irk65F4D+nVqwVmT-A0gZJ77tywnMuUgSCOU_w@mail.gmail.com>

On Mon, Feb 18, 2013 at 7:08 PM, Amaury Forgeot d Arc
<tracker at bugs.pypy.org> wrote:
>
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
>
> Last time I looked, streamio is still used in some places; maybe the marshal
> module.

well, I think we can't kill streamio, but can we kill all the logic
and just make it use FILE under is the question? It should still be a
wrapper, but can be a very thin one.

From tracker at bugs.pypy.org  Tue Feb 19 04:48:59 2013
From: tracker at bugs.pypy.org (Roy Feldman)
Date: Tue, 19 Feb 2013 03:48:59 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245739.45.0.524109904826.issue1402@bugs.pypy.org>
Message-ID: <1361245739.45.0.524109904826.issue1402@bugs.pypy.org>


New submission from Roy Feldman <roy.feldman at gmail.com>:

I have installed the pypy-2.0-beta1-linux64-libc2.15 tarball and pypy seems to
be working fine. 

However,  I am unable to successfully complete the instructions at
http://doc.pypy.org/en/latest/getting-started-python.html
 
1) If I follow the "Translating the PyPy Python interpreter" instructions,
everything is fine until I get to step 4, which tells me to do the following:
cd pypy/goal
python ../../rpython/bin/rpython --opt=jit targetpypystandalone.py 

I don't see a goal sub-directory and even if I create one, I don't see anything
corresponding to rpython and I can't proceed.

2) If I follow the "Running the Python Interpreter Without Translation" section,
 I find that I don't have pyinteractive.py in my bin directory. In fact, the
only file I have in my bin directory from the tarball is pypy.

What have I missed? Is there somethings else I need to download?

----------
messages: 5355
nosy: pypy-issue
priority: bug
release: 2.0
status: unread
title: Problem with "Getting Started with PyPy?s Python Interpreter" doc

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

From tracker at bugs.pypy.org  Tue Feb 19 04:52:06 2013
From: tracker at bugs.pypy.org (Roy Feldman)
Date: Tue, 19 Feb 2013 03:52:06 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245926.54.0.546451940266.issue1402@bugs.pypy.org>
Message-ID: <1361245926.54.0.546451940266.issue1402@bugs.pypy.org>


New submission from Roy Feldman <roy.feldman at gmail.com>:

I have installed the pypy-2.0-beta1-linux64-libc2.15 tarball and pypy seems to
be working fine. 

However,  I am unable to successfully complete the instructions at
http://doc.pypy.org/en/latest/getting-started-python.html
 
1) If I follow the "Translating the PyPy Python interpreter" instructions,
everything is fine until I get to step 4, which tells me to do the following:
cd pypy/goal
python ../../rpython/bin/rpython --opt=jit targetpypystandalone.py 

I don't see a goal sub-directory and even if I create one, I don't see anything
corresponding to rpython and I can't proceed.

2) If I follow the "Running the Python Interpreter Without Translation" section,
 I find that I don't have pyinteractive.py in my bin directory. In fact, the
only file I have in my bin directory from the tarball is pypy.

What have I missed? Is there something else I need to download?

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

From tracker at bugs.pypy.org  Tue Feb 19 04:52:47 2013
From: tracker at bugs.pypy.org (Roy Feldman)
Date: Tue, 19 Feb 2013 03:52:47 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245926.54.0.546451940266.issue1402@bugs.pypy.org>
Message-ID: <1361245967.76.0.532364922931.issue1402@bugs.pypy.org>


Roy Feldman <roy.feldman at gmail.com> added the comment:

I have installed the pypy-2.0-beta1-linux64-libc2.15 tarball and pypy seems to
be working fine. 

However,  I am unable to successfully complete the instructions at
http://doc.pypy.org/en/latest/getting-started-python.html
 
1) If I follow the "Translating the PyPy Python interpreter" instructions,
everything is fine until I get to step 4, which tells me to do the following:
cd pypy/goal
python ../../rpython/bin/rpython --opt=jit targetpypystandalone.py 

I don't see a goal sub-directory and even if I create one, I don't see anything
corresponding to rpython and I can't proceed.

2) If I follow the "Running the Python Interpreter Without Translation" section,
I find that I don't have pyinteractive.py in my bin directory. In fact, the
only file I have in my bin directory from the tarball is pypy.

What have I missed? Is there something else I need to download?

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

From tracker at bugs.pypy.org  Tue Feb 19 05:33:03 2013
From: tracker at bugs.pypy.org (Sean)
Date: Tue, 19 Feb 2013 04:33:03 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245967.76.0.532364922931.issue1402@bugs.pypy.org>
Message-ID: <1361248383.19.0.184099243319.issue1402@bugs.pypy.org>


Sean <sean at coreitpro.com> added the comment:

+1 to this bug.

d526111 appears to be the offending commit

https://bitbucket.org/pypy/pypy/diff/pypy/doc/index.rst?diff2=d52661180965&at=default

----------
nosy: +sc68cal
status:  -> chatting

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

From tracker at bugs.pypy.org  Tue Feb 19 05:40:45 2013
From: tracker at bugs.pypy.org (Sean)
Date: Tue, 19 Feb 2013 04:40:45 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245967.76.0.532364922931.issue1402@bugs.pypy.org>
Message-ID: <1361248845.37.0.651507614991.issue1402@bugs.pypy.org>


Sean <sean at coreitpro.com> added the comment:

Sorry - my bug appears to be a separate issue.

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

From tracker at bugs.pypy.org  Tue Feb 19 05:42:58 2013
From: tracker at bugs.pypy.org (Sean)
Date: Tue, 19 Feb 2013 04:42:58 +0000
Subject: [pypy-issue] [issue1403] Links broken on index.rst
In-Reply-To: <1361248978.96.0.589170496052.issue1403@bugs.pypy.org>
Message-ID: <1361248978.96.0.589170496052.issue1403@bugs.pypy.org>


New submission from Sean <sean at coreitpro.com>:

Hi,

It appears that d52611809 broke the formatting of the index.rst page, and now a
significant number of links are broken in the "Documentation for the PyPy Python
Interpreter" section.

https://bitbucket.org/pypy/pypy/diff/pypy/doc/index.rst?diff2=d52661180965&

----------
messages: 5360
nosy: pypy-issue, sc68cal
priority: bug
status: unread
title: Links broken on index.rst

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

From tracker at bugs.pypy.org  Tue Feb 19 07:29:08 2013
From: tracker at bugs.pypy.org (Roy Feldman)
Date: Tue, 19 Feb 2013 06:29:08 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245967.76.0.532364922931.issue1402@bugs.pypy.org>
Message-ID: <1361255348.47.0.129010394631.issue1402@bugs.pypy.org>


Roy Feldman <roy.feldman at gmail.com> added the comment:

Is this a packaging issue with the 2.0 beta1 tarball or a documentation problem? 
In either case, how should I proceed? 

I would prefer to start with a binary package, since I need to learn a lot more
about PyPy before I even consider making changes.

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

From tracker at bugs.pypy.org  Tue Feb 19 17:32:42 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 19 Feb 2013 16:32:42 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1361291562.57.0.254271149829.issue1397@bugs.pypy.org>


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

Well, yes, streamio is used at a few places, but that's because we don't support
files in the first place.  If we make RPython some subset of the file interface,
it would just work fine without streamio, I believe.

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

From tracker at bugs.pypy.org  Tue Feb 19 19:45:06 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 19 Feb 2013 18:45:06 +0000
Subject: [pypy-issue] [issue1397] file stream behavior differences from
	cpython
In-Reply-To: <1360755576.78.0.399653732503.issue1397@bugs.pypy.org>
Message-ID: <1361299506.67.0.155302322973.issue1397@bugs.pypy.org>


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

That sounds like a good idea I think.

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

From tracker at bugs.pypy.org  Tue Feb 19 21:58:50 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 19 Feb 2013 20:58:50 +0000
Subject: [pypy-issue] [issue1404] Sync datetime optimizations from default
	to py3k?
In-Reply-To: <1361307530.86.0.35638186243.issue1404@bugs.pypy.org>
Message-ID: <1361307530.86.0.35638186243.issue1404@bugs.pypy.org>


New submission from Philip Jenvey <pjenvey at underboss.org>:

Logging this as a reminder: lib_pypy/datetime.py was deleted on the py3k branch 
because py3's stdlib includes its own, updated version

So the optimizations recently done by bdk on default (various commits, some ref 
#1343) haven't been merged over. They may or may not need to be manually carried 
over

----------
messages: 5364
nosy: bdk, pypy-issue
priority: performance bug
status: unread
title: Sync datetime optimizations from default to py3k?

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

From tracker at bugs.pypy.org  Tue Feb 19 23:16:24 2013
From: tracker at bugs.pypy.org (Roy Feldman)
Date: Tue, 19 Feb 2013 22:16:24 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245967.76.0.532364922931.issue1402@bugs.pypy.org>
Message-ID: <1361312184.8.0.0668526234795.issue1402@bugs.pypy.org>


Roy Feldman <roy.feldman at gmail.com> added the comment:

No problems now that I am working with source. This seems to be a documentation
bug on the page http://doc.pypy.org/en/latest/getting-started-python.html.

The page says "the first thing to do is to download a pre-built PyPy for your
architecture". It immediately goes on to describe steps that are only possible
if you checkout the entire project source tree, but that is never mentioned.  

The documentation needs to be updated reflect that.

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

From tracker at bugs.pypy.org  Wed Feb 20 12:05:13 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Wed, 20 Feb 2013 11:05:13 +0000
Subject: [pypy-issue] [issue1372] test fails in testsuite/loader.py of jinja
	jinja-2.6
In-Reply-To: <1358503128.13.0.241710894753.issue1372@bugs.pypy.org>
Message-ID: <1361358313.84.0.112430844713.issue1372@bugs.pypy.org>


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

bdk	set	release: 2.0 ->

eeer, please simple translate.  Perhaps The fix for this will occur in the
official release or 2.0 perhaps??  There's no listed fox, therefore this is my
best guess

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

From tracker at bugs.pypy.org  Wed Feb 20 15:41:19 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 20 Feb 2013 14:41:19 +0000
Subject: [pypy-issue] [issue1405] InteriotPtrRepr misses convert_from_to
In-Reply-To: <1361371279.14.0.708884250824.issue1405@bugs.pypy.org>
Message-ID: <1361371279.14.0.708884250824.issue1405@bugs.pypy.org>


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

Every now and then translation crashes with:

[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File 
"/home/fijal/pypy/rpython/translator/goal/translate.py", line 317, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/home/fijal/pypy/rpython/translator/driver.py", 
line 733, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = 
self._maybe_skip())
[translation:ERROR]    File 
"/home/fijal/pypy/rpython/translator/tool/taskengine.py", line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/home/fijal/pypy/rpython/translator/driver.py", 
line 284, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/home/fijal/pypy/rpython/translator/driver.py", 
line 351, in task_rtype_lltype
[translation:ERROR]     rtyper.specialize(dont_simplify_again=True)
[translation:ERROR]    File "/home/fijal/pypy/rpython/rtyper/rtyper.py", line 
210, in specialize
[translation:ERROR]     self.specialize_more_blocks()
[translation:ERROR]    File "/home/fijal/pypy/rpython/rtyper/rtyper.py", line 
253, in specialize_more_blocks
[translation:ERROR]     self.specialize_block(block)
[translation:ERROR]    File "/home/fijal/pypy/rpython/rtyper/rtyper.py", line 
441, in specialize_block
[translation:ERROR]     self.insert_link_conversions(block)
[translation:ERROR]    File "/home/fijal/pypy/rpython/rtyper/rtyper.py", line 
500, in insert_link_conversions
[translation:ERROR]     self.gottypererror(e, block, link, newops)
[translation:ERROR]    File "/home/fijal/pypy/rpython/rtyper/rtyper.py", line 
498, in insert_link_conversions
[translation:ERROR]     new_a1 = newops.convertvar(a1, r_a1, r_a2)
[translation:ERROR]    File "/home/fijal/pypy/rpython/rtyper/rtyper.py", line 
927, in convertvar
[translation:ERROR]     (r_from, r_to))
[translation:ERROR]  TyperError: don't know how to convert from <InteriorPtrRepr 
* GcStruct Interior { ptr, index }> to <InteriorPtrRepr * GcStruct Interior { 
ptr, index }>
[translation:ERROR] .. 
(rpython.rtyper.lltypesystem.rdict:462)_ll_dict_setitem_lookup_done__v3703___sim
ple_call__function_
[translation:ERROR] .. block at -1 with 1 exits
[translation:ERROR] .. link from block at -1 to block at 199
[translation] start debugger...

we should fix it one day

----------
messages: 5367
nosy: fijal, pypy-issue
priority: bug
release: 2.0
status: unread
title: InteriotPtrRepr misses convert_from_to

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

From tracker at bugs.pypy.org  Thu Feb 21 10:43:14 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Thu, 21 Feb 2013 09:43:14 +0000
Subject: [pypy-issue] [issue1406] pyopenssl-0.13 test suite trips up pypy in
	test_crypto.py	test_ssl.py
In-Reply-To: <1361439794.02.0.431110742691.issue1406@bugs.pypy.org>
Message-ID: <1361439794.02.0.431110742691.issue1406@bugs.pypy.org>


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

well pypy did pretty well again, these appear 'little things'

..............F............................................................
======================================================================
FAIL: test_onlyStringAttributes (__main__.X509NameTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_crypto.py", line 680, in test_onlyStringAttributes
    self.assertRaises(TypeError, setattr, name, evil(), "hello")
  File
"/mnt/gen2/TmpDir/portage/dev-python/pyopenssl-0.13-r1/work/pyOpenSSL-0.13-pypy2_0/lib/OpenSSL/test/util.py",
line 121, in failUnlessRaises
    exception.__name__,
AssertionError: <type 'exceptions.AttributeError'> raised instead of TypeError

----------------------------------------------------------------------
Ran 162 tests in 0.833s

FAILED (failures=1)
 * Test test_crypto.py fails with pypy-c2.0

======================================================================
ERROR: test_short_memoryview (__main__.ConnectionSendTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_ssl.py", line 1399, in test_short_memoryview
    count = server.send(memoryview(b('xy')))
TypeError: must be convertible to a buffer, not memoryview

======================================================================
ERROR: test_short_memoryview (__main__.ConnectionSendallTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_ssl.py", line 1441, in test_short_memoryview
    server.sendall(memoryview(b('x')))
TypeError: must be convertible to a buffer, not memoryview

----------------------------------------------------------------------
Ran 98 tests in 3.046s

FAILED (errors=2)
 * Test test_ssl.py fails with pypy-c2.0

Need I add more?

----------
messages: 5368
nosy: idella5, pypy-issue
priority: bug
release: 2.0
status: chatting
title: pyopenssl-0.13 test suite trips up pypy in test_crypto.py test_ssl.py

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

From tracker at bugs.pypy.org  Thu Feb 21 14:35:48 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Feb 2013 13:35:48 +0000
Subject: [pypy-issue] [issue1405] InteriotPtrRepr misses convert_from_to
In-Reply-To: <1361371279.14.0.708884250824.issue1405@bugs.pypy.org>
Message-ID: <1361453748.14.0.375380800227.issue1405@bugs.pypy.org>


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

fixed

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

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

From tracker at bugs.pypy.org  Thu Feb 21 14:43:27 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Feb 2013 13:43:27 +0000
Subject: [pypy-issue] =?utf-8?q?=5Bissue1402=5D_Problem_with_=22Getting_St?=
 =?utf-8?q?arted_with_PyPy=E2=80=99s_Python_Interpreter=22_doc?=
In-Reply-To: <1361245967.76.0.532364922931.issue1402@bugs.pypy.org>
Message-ID: <1361454207.89.0.201555716935.issue1402@bugs.pypy.org>


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

The instructions clearly state "cloning the repo", if you have any idea how to 
improve, please submit a patch and reopen the bug.

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

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

From tracker at bugs.pypy.org  Thu Feb 21 16:07:34 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Feb 2013 15:07:34 +0000
Subject: [pypy-issue] [issue1403] Links broken on index.rst
In-Reply-To: <1361248978.96.0.589170496052.issue1403@bugs.pypy.org>
Message-ID: <1361459254.03.0.114237242126.issue1403@bugs.pypy.org>


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

Fixed with pretty extraordinary effort

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

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

From tracker at bugs.pypy.org  Thu Feb 21 16:09:08 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Feb 2013 15:09:08 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1361459348.61.0.477444003892.issue1236@bugs.pypy.org>


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

This is fixed on jitframe-on-heap branch that's going to be merged really soon 
(tm). I'm closing it then

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

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

From tracker at bugs.pypy.org  Thu Feb 21 16:12:18 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Feb 2013 15:12:18 +0000
Subject: [pypy-issue] [issue706] `import pybrain` fails in 1.5 on OSX
In-Reply-To: <1304254267.44.0.60280835989.issue706@>
Message-ID: <1361459538.94.0.633377226587.issue706@bugs.pypy.org>


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

I'm closing this one as not-specific enough. Please report missing functions in 
separate tickets.

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

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

From tracker at bugs.pypy.org  Thu Feb 21 16:13:29 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 21 Feb 2013 15:13:29 +0000
Subject: [pypy-issue] [issue997] PyCrypto fails to build with pypy/cpyext
In-Reply-To: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>
Message-ID: <1361459609.76.0.779372186682.issue997@bugs.pypy.org>


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

I'm closing this as pycrypto not behaving.

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

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

From tracker at bugs.pypy.org  Thu Feb 21 22:05:23 2013
From: tracker at bugs.pypy.org (Roy Feldman)
Date: Thu, 21 Feb 2013 21:05:23 +0000
Subject: [pypy-issue] [issue1407] Getting Started docs: misleading elements
	and suggested	improvments
In-Reply-To: <1361480723.05.0.26573121658.issue1407@bugs.pypy.org>
Message-ID: <1361480723.05.0.26573121658.issue1407@bugs.pypy.org>


New submission from Roy Feldman <roy.feldman at gmail.com>:

Currently, the bulk of the Getting Started page is misleading with respect to
the "Where to go from here" section near the bottom.
http://doc.pypy.org/en/latest/getting-started.html

Getting Started both describes how to download and install a pre-built PyPy and
how to clone the repository.  These appear as equal alternatives with the caveat
in the "Clone the Repository" section: "If you prefer to compile PyPy by
yourself, or if you want to modify it, you will need to obtain a copy of the
sources."

Not that most readers who read Getting Started are not planning to immediately
start modifying the source code.

The "Clone the Repository" section is immediately followed by "Where to go from
here."

The first two activities in that section require cloning the repository, but
that is not clear to the reader. Namely, "Building and using the PyPy's Python
interpreter" and "Learning more about the Rpython toolchain and how to develop
(with) PyPy.

Adding to the readers confusion is the beginning of the description for the
first activity. On the page titled "Getting Started with PyPy?s Python
Interpreter",  the third sentence states "To actually use PyPy?s Python
interpreter, the first thing to do is to download a pre-built PyPy for your
architecture." This is very misleading in this context and should be replaced
with instructions to clone the repository.
http://doc.pypy.org/en/latest/getting-started-python.html

Note that the third activity, "Tutorial for how to write an interpreter with the
RPython toolchain and make it fast", clearly states that cloning the repository
is required.
http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html

One more suggestion. Unless there good stylistic reasons to the contrary, the
text of links in the docs should match the titles of the pages they link.

For example, on the Getting Started page:

- Building and using PyPy?s Python interpreter -> Getting Started with the
PyPy's Interpreter

- Learning more about the RPython toolchain and how to develop (with) PyPy ->
Getting Started with the Translation Toolchain and Development Process

These may seem like little things, but consistency helps avoid reader confusion
and makes the documentation look more professional.

----------
messages: 5375
nosy: pypy-issue
priority: bug
status: unread
title: Getting Started docs: misleading elements and suggested improvments

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

From tracker at bugs.pypy.org  Thu Feb 21 23:46:51 2013
From: tracker at bugs.pypy.org (Glyph)
Date: Thu, 21 Feb 2013 22:46:51 +0000
Subject: [pypy-issue] [issue997] PyCrypto fails to build with pypy/cpyext
In-Reply-To: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>
Message-ID: <1361486811.83.0.668622750595.issue997@bugs.pypy.org>


Glyph <glyph at twistedmatrix.com> added the comment:

The relevant bug against PyCrypto is here: 
https://bugs.launchpad.net/pycrypto/+bug/1131452

Thanks for filing it, fijal.

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

From tracker at bugs.pypy.org  Fri Feb 22 11:29:44 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 22 Feb 2013 10:29:44 +0000
Subject: [pypy-issue] [issue1406] pyopenssl-0.13 test suite trips up pypy in
	test_crypto.py	test_ssl.py
In-Reply-To: <1361439794.02.0.431110742691.issue1406@bugs.pypy.org>
Message-ID: <1361528984.42.0.312559351652.issue1406@bugs.pypy.org>


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

AttributeError and TypeError are interchangeable. This is very much 
"implementation detail", please fix the test.

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

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

From tracker at bugs.pypy.org  Sat Feb 23 02:17:29 2013
From: tracker at bugs.pypy.org (bdk)
Date: Sat, 23 Feb 2013 01:17:29 +0000
Subject: [pypy-issue] [issue1352] In numpypy,
	the functions min() and max() are broken
In-Reply-To: <1356154031.12.0.788167355877.issue1352@bugs.pypy.org>
Message-ID: <1361582249.0.0.996398247392.issue1352@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

fixed by mattip in 74231eb5eee9

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

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

From tracker at bugs.pypy.org  Sat Feb 23 08:06:56 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Sat, 23 Feb 2013 07:06:56 +0000
Subject: [pypy-issue] [issue1406] pyopenssl-0.13 test suite trips up pypy in
	test_crypto.py	test_ssl.py
In-Reply-To: <1361439794.02.0.431110742691.issue1406@bugs.pypy.org>
Message-ID: <1361603216.51.0.610905585204.issue1406@bugs.pypy.org>


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

ok thx fijal.  I fixed the first test inside 20 minutes by swtiching to the
Attribute Error.  The second 2 tests in test_ssl.py appear a totally different
matter.
Firstly are you suggesting the same applies here?  The file has a myriad of
entries of TypeError and despite extended efforts I couldn't find the source of
allocating the TypeError to the tests.
Secondly, the tests pass by following the prompt of the error msg. In

count = server.send(memoryview(b('xy')))
&&
server.sendall(memoryview(b('x')))

substituting memoryview with buffer in pypy sees them pass.  This to me isn't a
fix of the test, it's changing the test beyond its intent.
Do you know what a memoryview is?  In the test_ssl.py the making or defining of
memoryview loses me all together.  A buffer is a known structure, a memoryview
I've never heard of.

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

From fijall at gmail.com  Sat Feb 23 12:01:28 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 23 Feb 2013 13:01:28 +0200
Subject: [pypy-issue] [issue1406] pyopenssl-0.13 test suite trips up
 pypy in test_crypto.py test_ssl.py
In-Reply-To: <1361603216.51.0.610905585204.issue1406@bugs.pypy.org>
References: <1361439794.02.0.431110742691.issue1406@bugs.pypy.org>
	<1361603216.51.0.610905585204.issue1406@bugs.pypy.org>
Message-ID: <CAK5idxTkUK7hBtg=a9-zyf64pVbsYGtG7FDs6C3T7iS1qTuMXQ@mail.gmail.com>

On Sat, Feb 23, 2013 at 9:06 AM, Ian Delaney <tracker at bugs.pypy.org> wrote:
>
> Ian Delaney <della5 at iinet.com.au> added the comment:
>
> ok thx fijal.  I fixed the first test inside 20 minutes by swtiching to the
> Attribute Error.  The second 2 tests in test_ssl.py appear a totally different
> matter.
> Firstly are you suggesting the same applies here?  The file has a myriad of
> entries of TypeError and despite extended efforts I couldn't find the source of
> allocating the TypeError to the tests.
> Secondly, the tests pass by following the prompt of the error msg. In
>
> count = server.send(memoryview(b('xy')))
> &&
> server.sendall(memoryview(b('x')))
>
> substituting memoryview with buffer in pypy sees them pass.  This to me isn't a
> fix of the test, it's changing the test beyond its intent.
> Do you know what a memoryview is?  In the test_ssl.py the making or defining of
> memoryview loses me all together.  A buffer is a known structure, a memoryview
> I've never heard of.
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1406>
> ________________________________________

No, I didn't say that :)

I would need to investigate

From tracker at bugs.pypy.org  Sat Feb 23 16:02:44 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Sat, 23 Feb 2013 15:02:44 +0000
Subject: [pypy-issue] [issue1406] pyopenssl-0.13 test suite trips up pypy in
	test_crypto.py	test_ssl.py
In-Reply-To: <1361439794.02.0.431110742691.issue1406@bugs.pypy.org>
Message-ID: <1361631764.36.0.126499074817.issue1406@bugs.pypy.org>


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

right. feel free.  I filed it to pyopenssl at launchpad due to no joy from above.

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

From tracker at bugs.pypy.org  Mon Feb 25 10:08:08 2013
From: tracker at bugs.pypy.org (bdk)
Date: Mon, 25 Feb 2013 09:08:08 +0000
Subject: [pypy-issue] [issue1361] pypy.rlib.entrypoint + export_struct don't
	make symbols	exported
In-Reply-To: <1357553765.06.0.407417738168.issue1361@bugs.pypy.org>
Message-ID: <1361783288.75.0.390931766238.issue1361@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

some notes:
- export_struct has the same problem, and should probably get the same solution
- symbols are not exported by default on Linux now. now, the linking step properly 
uses the eci to define exported symbols like other platforms, so I assume this bug 
applies to Linux now as well.

----------
nosy: +bdk
title: pypy.rlib.entrypoint doesn't make function exported on Windows -> pypy.rlib.entrypoint + export_struct don't make symbols exported

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

From tracker at bugs.pypy.org  Mon Feb 25 12:53:06 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 25 Feb 2013 11:53:06 +0000
Subject: [pypy-issue] [issue1408] ll_1_force_jit showing up in normal traces
In-Reply-To: <1361793186.77.0.931062076772.issue1408@bugs.pypy.org>
Message-ID: <1361793186.77.0.931062076772.issue1408@bugs.pypy.org>


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

This is just to remember. An example program:

http://paste.pound-python.org/show/30717/

is kinda slow (still 4x faster than cpython though)

----------
messages: 5383
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: ll_1_force_jit showing up in normal traces

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

From tracker at bugs.pypy.org  Tue Feb 26 06:42:41 2013
From: tracker at bugs.pypy.org (YAMAMOTO Takashi)
Date: Tue, 26 Feb 2013 05:42:41 +0000
Subject: [pypy-issue] [issue1409] netbsd support
In-Reply-To: <1361857361.33.0.161819094579.issue1409@bugs.pypy.org>
Message-ID: <1361857361.33.0.161819094579.issue1409@bugs.pypy.org>


New submission from YAMAMOTO Takashi <yamt at mwd.biglobe.ne.jp>:

add netbsd support

----------
files: netbsd.diff
messages: 5384
nosy: pypy-issue, yamt
priority: wish
status: unread
title: netbsd support

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

From tracker at bugs.pypy.org  Tue Feb 26 13:21:51 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 26 Feb 2013 12:21:51 +0000
Subject: [pypy-issue] [issue1409] netbsd support
In-Reply-To: <1361857361.33.0.161819094579.issue1409@bugs.pypy.org>
Message-ID: <1361881311.3.0.956970508306.issue1409@bugs.pypy.org>


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

Hi.

This is unlikely to happen on it's own. Feel free however to provide patches 
and/or a buildbot machine, so we can support it. I can't even find python support 
for NetBSD for cpython (although I don't know).

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

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

From tracker at bugs.pypy.org  Tue Feb 26 14:19:02 2013
From: tracker at bugs.pypy.org (George Sakkis)
Date: Tue, 26 Feb 2013 13:19:02 +0000
Subject: [pypy-issue] [issue1341] fatal cpyext error with PyEval_SaveThread
In-Reply-To: <1353982155.24.0.607820578833.issue1341@bugs.pypy.org>
Message-ID: <1361884742.67.0.223876802913.issue1341@bugs.pypy.org>


George Sakkis <george.sakkis at gmail.com> added the comment:

Getting this too on some unit tests though not consistently; any way to
troubleshoot it? Using mysql-python 1.2.4 from PyPi.

----------
nosy: +gsakkis

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

From tracker at bugs.pypy.org  Tue Feb 26 15:13:05 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 26 Feb 2013 14:13:05 +0000
Subject: [pypy-issue] [issue1410] SQLAlchemy-0.7.10's test/sql/test_query.py
	trips pypy	over exception type
In-Reply-To: <1361887985.51.0.734945486725.issue1410@bugs.pypy.org>
Message-ID: <1361887985.51.0.734945486725.issue1410@bugs.pypy.org>


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

I've attempted as many substitutions of AttributeError with TypeEror as is
reasonable in the SQLAlchemy-0.7.10 source without invoking more spam errors
unnecessarily.

.......................................................
......ES..........S..................S..SSS................................................................................................................................................................SSSSSS
======================================================================
ERROR: test.sql.test_query.QueryTest.test_native_lastrowid
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/pypy2.0/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "<string>", line 1, in <lambda>
  File
"/mnt/gen2/TmpDir/portage/dev-python/sqlalchemy-0.7.10/work/SQLAlchemy-0.7.10/./test/lib/exclusions.py",
line 14, in decorate
    return fn(*args, **kw)
  File
"/mnt/gen2/TmpDir/portage/dev-python/sqlalchemy-0.7.10/work/SQLAlchemy-0.7.10/./test/sql/test_query.py",
line 847, in test_native_lastrowid
    eq_(r.lastrowid, 1)
  File
"/mnt/gen2/TmpDir/portage/dev-python/sqlalchemy-0.7.10/work/SQLAlchemy-0.7.10/./lib/sqlalchemy/engine/base.py",
line 2983, in lastrowid
    return self._saved_cursor.lastrowid
  File "/usr/lib64/pypy2.0/lib_pypy/_sqlite3.py", line 913, in _getlastrowid
    return sqlite.sqlite3_last_insert_rowid(self.connection.db)
AttributeError: 'NoneType' object has no attribute 'db'

----------------------------------------------------------------------
Ran 4033 tests in 654.941s

1 single measly test fail from 4033 over an exception type.

testuser at archtester ~/cvsPortage/gentoo-x86/dev-python/sqlalchemy $ grep Error 
/mnt/gen2/TmpDir/portage/dev-python/sqlalchemy-0.7.10/work/SQLAlchemy-0.7.10/lib/sqlalchemy/engine/base.py
|grep  Attribute
        except AttributeError:
        except AttributeError:
            except AttributeError:
            except AttributeError:
                raise AttributeError(e.args[0])
        except AttributeError:
        except AttributeError:
        except AttributeError:

testuser at archtester ~/cvsPortage/gentoo-x86/dev-python/sqlalchemy $ grep Error 
/mnt/gen2/TmpDir/portage/dev-python/sqlalchemy-0.7.10/work/SQLAlchemy-0.7.10/lib/sqlalchemy/engine/base.py
|grep  Type
            except TypeError:
            except TypeError:

What I didn't do was to start substituting TypeError for AttributeError in the
system installed pypy lib files.

testuser at archtester ~/cvsPortage/gentoo-x86/dev-python/sqlalchemy $ grep Error
/usr/lib64/pypy2.0/lib_pypy/_sqlite3.py |grep Type
                raise TypeError("parameter must be callable")
            raise TypeError
        except TypeError:
        except TypeError:

ANy further data required?

----------
assignedto: fijal
messages: 5387
nosy: fijal, idella5, pypy-issue
priority: bug
release: 2.0
status: chatting
title: SQLAlchemy-0.7.10's test/sql/test_query.py trips pypy over exception type

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

From tracker at bugs.pypy.org  Tue Feb 26 16:14:34 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 26 Feb 2013 15:14:34 +0000
Subject: [pypy-issue] [issue1341] fatal cpyext error with PyEval_SaveThread
In-Reply-To: <1353982155.24.0.607820578833.issue1341@bugs.pypy.org>
Message-ID: <1361891674.87.0.109460654368.issue1341@bugs.pypy.org>


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

There is a patch for mysql-python on compatibility wiki. There is also mysql-
ctypes. Maybe you should try one of those?

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

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

From tracker at bugs.pypy.org  Tue Feb 26 16:16:07 2013
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Tue, 26 Feb 2013 15:16:07 +0000
Subject: [pypy-issue] [issue1341] fatal cpyext error with PyEval_SaveThread
In-Reply-To: <1353982155.24.0.607820578833.issue1341@bugs.pypy.org>
Message-ID: <1361891767.04.0.793111663707.issue1341@bugs.pypy.org>


Jon Oberheide <jonojono at umich.edu> added the comment:

IIRC, those patches in the wiki were pulled in to the 1.2.4 release. So I believe 
this may be another issue...maybe. :-)

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

From tracker at bugs.pypy.org  Wed Feb 27 03:17:26 2013
From: tracker at bugs.pypy.org (YAMAMOTO Takashi)
Date: Wed, 27 Feb 2013 02:17:26 +0000
Subject: [pypy-issue] [issue1409] netbsd support
In-Reply-To: <1361857361.33.0.161819094579.issue1409@bugs.pypy.org>
Message-ID: <1361931446.51.0.415027750747.issue1409@bugs.pypy.org>


YAMAMOTO Takashi <yamt at mwd.biglobe.ne.jp> added the comment:

i've already provided a patch.
i don't think i can provide a buildbot machine.

i'm not sure what you mean by "python support" but i can run
cpython on netbsd without problems.

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

From tracker at bugs.pypy.org  Wed Feb 27 19:51:40 2013
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 27 Feb 2013 18:51:40 +0000
Subject: [pypy-issue] [issue1409] netbsd support
In-Reply-To: <1361857361.33.0.161819094579.issue1409@bugs.pypy.org>
Message-ID: <1361991100.02.0.913099698422.issue1409@bugs.pypy.org>


bdk <bdkearns at gmail.com> added the comment:

patch looks fine (at least harmless for other archs, not sure how far it gets us 
for netbsd), applied in 06373bfca341. without a buildbot, can't do much else.

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

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