From tracker at bugs.pypy.org  Mon Oct  1 01:03:04 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 30 Sep 2012 23:03:04 +0000
Subject: [pypy-issue] [issue1274] continue inside of other frame blocks
	causes JIT not to	be invoked
In-Reply-To: <1349046184.04.0.81427985675.issue1274@bugs.pypy.org>
Message-ID: <1349046184.04.0.81427985675.issue1274@bugs.pypy.org>


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

Alexs-MacBook-Pro-2:tmp alex_gaynor$ PYPYLOG=jit-summary:- pypy -S t.py 
Alexs-MacBook-Pro-2:tmp alex_gaynor$ time python t.py 

real	0m1.519s
user	0m1.505s
sys	0m0.011s
Alexs-MacBook-Pro-2:tmp alex_gaynor$ time pypy t.py 

real	0m2.839s
user	0m2.815s
sys	0m0.020s
Alexs-MacBook-Pro-2:tmp alex_gaynor$ cat t.py 
def f(n):
    for i in xrange(n):
        try:
            continue
        finally:
            pass


f(25000000)

----------
messages: 4793
nosy: agaynor, pypy-issue
priority: performance bug
status: unread
title: continue inside of other frame blocks causes JIT not to be invoked

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

From tracker at bugs.pypy.org  Mon Oct  1 09:05:26 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 01 Oct 2012 07:05:26 +0000
Subject: [pypy-issue] [issue1274] continue inside of other frame blocks
	causes JIT not to	be invoked
In-Reply-To: <1349046184.04.0.81427985675.issue1274@bugs.pypy.org>
Message-ID: <1349075126.72.0.503405468574.issue1274@bugs.pypy.org>


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

This is a corner case in which the loop never hits a JUMP_ABSOLUTE opcode.  We
need to put a different can_enter_jit() somewhere else.  I suggest
LoopBlock.handle(), in the case where it re-pushes the loop block after a
SContinueLoop.  Note that SContinueLoop comes from CONTINUE_LOOP opcodes, which
themselves are produced by "continue" statements only if they are enclosed in a
try:.

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

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

From tracker at bugs.pypy.org  Mon Oct  1 10:25:21 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 01 Oct 2012 08:25:21 +0000
Subject: [pypy-issue] [issue1274] continue inside of other frame blocks
	causes JIT not to	be invoked
In-Reply-To: <1349046184.04.0.81427985675.issue1274@bugs.pypy.org>
Message-ID: <1349079921.52.0.231462909346.issue1274@bugs.pypy.org>


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

Fixed (166c5a450114, da03bb5bb6fc).

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

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

From tracker at bugs.pypy.org  Tue Oct  2 10:39:34 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 08:39:34 +0000
Subject: [pypy-issue] [issue918] implement numpy.matrix in micronumpy
In-Reply-To: <1319321974.08.0.127911146223.issue918@bugs.pypy.org>
Message-ID: <1349167174.62.0.592942813288.issue918@bugs.pypy.org>


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

Note, that the prerequisite Issue 919 is done a year ago.
fijal, you may want to update "Release" field.

----------
assignedto:  -> fijal
nosy: +fijal, vak

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

From tracker at bugs.pypy.org  Tue Oct  2 10:45:41 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 08:45:41 +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: <1349167541.57.0.266661359387.issue1000@bugs.pypy.org>


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

fijal, the following works fine:

>>>> np.array([1,np.nan,3], dtype=np.float32)
array([ 1.        ,         nan,  3.        ], dtype=float32)

perhaps it means, that a fix should probably be quite easy

----------
assignedto:  -> fijal
nosy: +vak

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

From tracker at bugs.pypy.org  Tue Oct  2 10:50:56 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 08:50:56 +0000
Subject: [pypy-issue] [issue1118] numpypy: indexing of 2D arrays with 1-D
	boolean arrays is	broken
In-Reply-To: <1333938459.17.0.362001926516.issue1118@bugs.pypy.org>
Message-ID: <1349167856.75.0.940275477408.issue1118@bugs.pypy.org>


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

update: the following doesn't throw exception any more, however result is wrong:

>>>> a[c]
array([1, 3])

fijal: you may want to add the corresponding assert to the tests

----------
assignedto:  -> fijal
nosy: +fijal, vak
release:  -> ???

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

From tracker at bugs.pypy.org  Tue Oct  2 10:56:01 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 08:56:01 +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: <1349168161.71.0.834895644809.issue1130@bugs.pypy.org>


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

all three asserts are doing well now:

>>>> np.array([10,11,12,13])[[1,2]] 
array([11, 12])

>>>> np.arange(6).reshape((2,3))[[0,1]]
array([[0, 1, 2],
       [3, 4, 5]])

>>>> np.arange(6).reshape((2,3))[(0,1)]
1

fijal: you may want to add them to the tests though (for this tiny reason only i am changing status to "testing", 
not to "resolved")

----------
assignedto:  -> fijal
nosy: +vak
release:  -> 2.0
status: chatting -> testing

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

From tracker at bugs.pypy.org  Tue Oct  2 10:57:45 2012
From: tracker at bugs.pypy.org (Ralf Schmitt)
Date: Tue, 02 Oct 2012 08:57:45 +0000
Subject: [pypy-issue] [issue1248] please build with older GNU libc on
	Linux/amd64
In-Reply-To: <1346476259.72.0.54490436525.issue1248@bugs.pypy.org>
Message-ID: <1349168265.58.0.111626180679.issue1248@bugs.pypy.org>


Ralf Schmitt <ralf at systemexit.de> added the comment:

AFAICT, glibc 2.7 or up is required (at least for the 64 bit version)

~/ % readelf -s pypy-1.9/bin/pypy |tr " " "\n" |tr "@" "\n" |grep GLIBC |sort |uniq
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.7

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

From tracker at bugs.pypy.org  Tue Oct  2 11:00:31 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:00:31 +0000
Subject: [pypy-issue] [issue1138] in numpypy,
	strings fundamentally don't work
In-Reply-To: <1335567444.04.0.107953871149.issue1138@bugs.pypy.org>
Message-ID: <1349168431.38.0.221402481122.issue1138@bugs.pypy.org>


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

update regarding np.array("f") as of the current numpypy state:

>>>> np.array("f")
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ValueError: invalid literal for float(): 'f'

----------
nosy: +vak

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

From tracker at bugs.pypy.org  Tue Oct  2 11:11:53 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:11:53 +0000
Subject: [pypy-issue] [issue1143] numpypy: bug in array_equal
In-Reply-To: <1337195357.97.0.624497287196.issue1143@bugs.pypy.org>
Message-ID: <1349169113.95.0.123394711297.issue1143@bugs.pypy.org>


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

it could be perhaps easy fixed, because the reason is that npp.bool8 and/or 
npp.bool_ indeed have no method all() yet.

in numpy:
>>> import numpy as np
>>> np.bool8(True).all()
True

whereas in numpypy:

>>>> import numpypy as npp
>>>> npp.bool8(True).all()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'bool_' object has no attribute 'all'

----------
assignedto:  -> fijal
nosy: +fijal, vak
release:  -> ???
status: unread -> chatting

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

From tracker at bugs.pypy.org  Tue Oct  2 11:26:05 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:26:05 +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: <1349169965.08.0.81879336883.issue1160@bugs.pypy.org>


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

fijal, np.integer (and its alias np.int) could probably be easy set to the 
corresponding "platform integer" int32 or int64

"intp" is not even described here:
http://docs.scipy.org/doc/numpy/user/basics.types.html

----------
assignedto:  -> fijal
nosy: +fijal, vak
status: unread -> chatting

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

From tracker at bugs.pypy.org  Tue Oct  2 11:36:30 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:36:30 +0000
Subject: [pypy-issue] [issue1010] numpypy: commit the code for array_equal
In-Reply-To: <1326920433.89.0.563181336651.issue1010@bugs.pypy.org>
Message-ID: <1349170590.37.0.910266090018.issue1010@bugs.pypy.org>


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

oh, even asarray is implemented now and array_equal is relying on it now. Closing 
the issue.

Dmitrey, my personal "+1" to your point regarding functional coverage :)

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

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

From tracker at bugs.pypy.org  Tue Oct  2 11:43:15 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:43:15 +0000
Subject: [pypy-issue] [issue1008] numpypy: commit the code for empty_like,
	zeros_like, ones_like
In-Reply-To: <1326903282.11.0.305182879123.issue1008@bugs.pypy.org>
Message-ID: <1349170995.29.0.18934005621.issue1008@bugs.pypy.org>


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

fijal, in fact doc-style tests are in the pastebin and seem to be easy taken from 
there. You may want to commit it no your own or give Dmitrey a "go".

----------
assignedto:  -> fijal
nosy: +vak

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

From tracker at bugs.pypy.org  Tue Oct  2 11:47:14 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:47:14 +0000
Subject: [pypy-issue] [issue1028] Putting numpypy arrays to
	(multiprocessing) queue fails
In-Reply-To: <1327835011.23.0.769244311514.issue1028@bugs.pypy.org>
Message-ID: <1349171234.72.0.349577429497.issue1028@bugs.pypy.org>


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

fijal, who could be assigned to this?

Details: still not implemented, current error & stack trace looks like this:

$ pypy test.py 
Traceback (most recent call last):
  File "/home/vak/pkg/pypy/lib-python/2.7/multiprocessing/queues.py", line 266, in 
_feed
    send(obj)
  File "/home/vak/pkg/pypy/lib-python/2.7/pickle.py", line 1417, in dumps
    Pickler(file, protocol).dump(obj)
  File "/home/vak/pkg/pypy/lib-python/2.7/pickle.py", line 224, in dump
    self.save(obj)
  File "/home/vak/pkg/pypy/lib-python/2.7/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/home/vak/pkg/pypy/lib-python/2.7/pickle.py", line 396, in save_reduce
    save(cls)
  File "/home/vak/pkg/pypy/lib-python/2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/home/vak/pkg/pypy/lib-python/2.7/pickle.py", line 792, in save_global
    (obj, module, name))
PicklingError: Can't pickle <type 'ndarray'>: it's not found as __builtin__.ndarray

----------
assignedto:  -> fijal
nosy: +fijal, vak

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

From tracker at bugs.pypy.org  Tue Oct  2 11:53:10 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:53:10 +0000
Subject: [pypy-issue] [issue913] Reduce-like *functions* for micronumpy
	missing, e.g. numpy.dot
In-Reply-To: <1318946612.94.0.137292123198.issue913@bugs.pypy.org>
Message-ID: <1349171590.22.0.278799853297.issue913@bugs.pypy.org>


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

only "vdot" remains not implemented now (see below). Should be an easy fix. Also, it is 
funny that reference numpy calls showed the error for np.max() and np.min()  ;-)

>>>> np.vdot(np.ones(5), np.ones(5))
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'module' object has no attribute 'vdot'

----------
assignedto:  -> fijal
nosy: +fijal, vak
release: 1.6 -> 2.0

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

From tracker at bugs.pypy.org  Tue Oct  2 11:58:10 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:58:10 +0000
Subject: [pypy-issue] [issue915] implement numpy.linalg in micronumpy
In-Reply-To: <1318948298.71.0.561740137124.issue915@bugs.pypy.org>
Message-ID: <1349171890.27.0.634574181307.issue915@bugs.pypy.org>


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

fijal, who could be assigned for this? linalg is a very serious part that will 
considerably increase the impact of numpypy (and pypy in general)

----------
assignedto:  -> fijal
nosy: +vak
release: 1.6 -> ???

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

From tracker at bugs.pypy.org  Tue Oct  2 11:59:45 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 09:59:45 +0000
Subject: [pypy-issue] [issue1129] numpypy reduce methods don't work with
	scalars
In-Reply-To: <1334405539.73.0.195200817589.issue1129@bugs.pypy.org>
Message-ID: <1349171985.61.0.771911756592.issue1129@bugs.pypy.org>


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

Done.

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

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

From tracker at bugs.pypy.org  Tue Oct  2 12:04:12 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 10:04:12 +0000
Subject: [pypy-issue] [issue1193] numpy ufuncs break if used in-place
In-Reply-To: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>
Message-ID: <1349172252.11.0.681016376103.issue1193@bugs.pypy.org>


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

apendleton, I can't reproduce the issue and am changing status to "invalid". If 
you have instruction on how to reproduce the bug, please supply them here and 
change status to 'chatting'. Thank you.

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

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

From tracker at bugs.pypy.org  Tue Oct  2 12:24:48 2012
From: tracker at bugs.pypy.org (Andrew Pendleton)
Date: Tue, 02 Oct 2012 10:24:48 +0000
Subject: [pypy-issue] [issue1193] numpy ufuncs break if used in-place
In-Reply-To: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>
Message-ID: <1349173488.45.0.174294439622.issue1193@bugs.pypy.org>


Andrew Pendleton <abpend at gmail.com> added the comment:

Status should probably be "resolved" and rather than "invalid."  I just tested
with both 1.9 and the nightly build, and it definitely still occurs in 1.9 but
doesn't anymore in the nightly build.  Thanks for (inadvertently?) fixing it! 
For the record, here's the whole interaction on 1.9:

andrew at josquin:~$ pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``and now for something completely
different''
>>>> import numpypy as numpy
>>>> arr = numpy.zeros(10)
>>>> numpy.maximum(arr, 1, arr)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded

and here's the nightly, which behaves as expected:

andrew at josquin:~/Temp/pypy-c-jit-57707-7f6d5c878b90-osx64$ ./bin/pypy 
Python 2.7.3 (7f6d5c878b90, Oct 02 2012, 01:00:21)
[PyPy 1.9.1-dev0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``<arigato> fijal: I'm sure there
is tons of unspecified context information that I should ideally also be aware
of''
>>>> import numpypy as numpy
>>>> arr = numpy.zeros(10)
>>>> numpy.maximum(arr, 1, arr)
array([ 1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.,  1.])

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

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

From tracker at bugs.pypy.org  Tue Oct  2 12:36:39 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 02 Oct 2012 10:36:39 +0000
Subject: [pypy-issue] [issue1193] numpy ufuncs break if used in-place
In-Reply-To: <1340657010.81.0.192638117067.issue1193@bugs.pypy.org>
Message-ID: <1349174199.35.0.0446816969742.issue1193@bugs.pypy.org>


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

cool, perhaps fijal has fixed this.

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

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

From tracker at bugs.pypy.org  Wed Oct  3 08:13:50 2012
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 03 Oct 2012 06:13:50 +0000
Subject: [pypy-issue] [issue1275] uncaught exception crashes interpreter
In-Reply-To: <1349244830.29.0.622119811477.issue1275@bugs.pypy.org>
Message-ID: <1349244830.29.0.622119811477.issue1275@bugs.pypy.org>


New submission from mattip <matti.picus at gmail.com>:

running "complex(float('inf'), 0.0) ** complex(10., 3.)" crashes the interpreter
rpython throws a ValueError which is not caught anywhere
Is pow__Complex_Complex_ANY in pypy/objspace/std/complexobject.py the correct 
place? I couldn't figure out where to write a test for it...

----------
messages: 4813
nosy: mattip, pypy-issue
priority: bug
status: unread
title: uncaught exception crashes interpreter

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

From tracker at bugs.pypy.org  Wed Oct  3 08:49:09 2012
From: tracker at bugs.pypy.org (Valery)
Date: Wed, 03 Oct 2012 06:49:09 +0000
Subject: [pypy-issue] [issue1161] numpypy.bool missing (numpy boolean dtype)
In-Reply-To: <1339278757.75.0.360606329263.issue1161@bugs.pypy.org>
Message-ID: <1349246949.01.0.96760783306.issue1161@bugs.pypy.org>


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

agaynor, as for numpy.bool and numpy.int -- I confirm your statement. 
Could you commit the corresponding export line(s), please?

(BTW, the situation is different, e.g. for numpy.int_ or for numpy.integer)

----------
assignedto:  -> agaynor
nosy: +vak

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

From tracker at bugs.pypy.org  Wed Oct  3 08:55:06 2012
From: tracker at bugs.pypy.org (Valery)
Date: Wed, 03 Oct 2012 06:55:06 +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: <1349247306.78.0.930345781594.issue1160@bugs.pypy.org>


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

Update: np.integer is *not* an alias of np.int. Proof in CPython 2.7.1 / numpy 1.6.1:

  >>> set(dir(np.int))==set(dir(np.integer))
  False

In fact np.integer is an abstract class 
(http://docs.scipy.org/doc/numpy/reference/arrays.scalars.html)

Sadly, http://docs.scipy.org/doc/numpy/user/basics.types.html also states ambiguously:

  "int	-- Platform integer (normally either int32 or int64)"

However at least as for numpy 1.6.1 it is neither numpy.int32 nor numpy.int64. They rather 
just meant the number of bits in __builtin__.int in this fancy ambiguous way.

Facts:

  >>> np.int == __builtin__.int
  True

  >>> np.int
  <type 'int'>


  >>> np.bool == __builtin__.bool
  True

  >>> np.bool
  <type 'bool'>

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

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

From tracker at bugs.pypy.org  Wed Oct  3 16:40:34 2012
From: tracker at bugs.pypy.org (Lisandro Dalcin)
Date: Wed, 03 Oct 2012 14:40:34 +0000
Subject: [pypy-issue] [issue1276] PyBuffer_FillInfo() and readonly parameter
In-Reply-To: <1349275234.91.0.0590907439669.issue1276@bugs.pypy.org>
Message-ID: <1349275234.91.0.0590907439669.issue1276@bugs.pypy.org>


New submission from Lisandro Dalcin <dalcinl at gmail.com>:

I understand the implementation of PyBuffer_FillInfo() is incomplete, but at 
least it is enough to pass back and forth raw buffers in C code. However, there 
is an issue with the handling of the "readonly" parameter: PyPy ignores 
"readonly" parameter and set view.readonly depening on PyBUF_WRITABLE bitfield 
in "flags" parameter.

The correct behavior is to generate an error if readonly=1 and 
flags&PyBUF_WRITABLE, and set view.readonly = readonly. 
http://hg.python.org/cpython/file/v2.7.3/Objects/abstract.c#l680

I was able to workaround this issue with a bit of C monkeypatching: 
https://code.google.com/p/mpi4py/source/browse/src/atimport.h#336

PS: http://mail.python.org/pipermail/cython-devel/2012-October/003177.html

----------
messages: 4816
nosy: dalcinl, pypy-issue
priority: bug
status: unread
title: PyBuffer_FillInfo() and readonly parameter

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

From tracker at bugs.pypy.org  Wed Oct  3 23:12:10 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 03 Oct 2012 21:12:10 +0000
Subject: [pypy-issue] [issue1276] PyBuffer_FillInfo() and readonly parameter
In-Reply-To: <1349275234.91.0.0590907439669.issue1276@bugs.pypy.org>
Message-ID: <1349298730.5.0.890548354953.issue1276@bugs.pypy.org>


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

Done in 624f21864eba. Thanks a lot for the fix!

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

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

From tracker at bugs.pypy.org  Thu Oct  4 03:47:24 2012
From: tracker at bugs.pypy.org (Lisandro Dalcin)
Date: Thu, 04 Oct 2012 01:47:24 +0000
Subject: [pypy-issue] [issue1277] PyCode_GetNumFree() should accept
	PyCodeObject*
In-Reply-To: <1349315244.49.0.0906976810657.issue1277@bugs.pypy.org>
Message-ID: <1349315244.49.0.0906976810657.issue1277@bugs.pypy.org>


New submission from Lisandro Dalcin <dalcinl at gmail.com>:

In Python 2.x C/API, PyCode_GetNumFree() is a macro that should be called with a 
PyCodeObject* pointer, and returns the lenght of a tuple: 
http://hg.python.org/cpython/file/v2.7.3/Include/code.h#l68 . However, PyPy 
exposes this call as "int PyCode_GetNumFree(PyObject*)". The return type and 
parameter type should change to "Py_ssize_t PyCode_GetNumFree(PyCodeObject*)"

----------
messages: 4818
nosy: dalcinl, pypy-issue
priority: bug
status: unread
title: PyCode_GetNumFree() should accept PyCodeObject*

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

From tracker at bugs.pypy.org  Thu Oct  4 17:31:41 2012
From: tracker at bugs.pypy.org (Steven James)
Date: Thu, 04 Oct 2012 15:31:41 +0000
Subject: [pypy-issue] [issue1278] Cannot import dbm module
In-Reply-To: <1349364701.54.0.540197826062.issue1278@bugs.pypy.org>
Message-ID: <1349364701.54.0.540197826062.issue1278@bugs.pypy.org>


New submission from Steven James <steven.james at gmail.com>:

1) Download pypy 1.9
2) bin/pypy
3) import dbm
4) fails with:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/sjames/pypy-1.9/lib_pypy/dbm.py", line 131, in <module>
    raise ImportError("Cannot find dbm library")
ImportError: Cannot find dbm library

reproduced by fijal on linux

----------
messages: 4819
nosy: pypy-issue, soundstripe
priority: bug
status: unread
title: Cannot import dbm module

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

From tracker at bugs.pypy.org  Thu Oct  4 21:03:39 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 04 Oct 2012 19:03:39 +0000
Subject: [pypy-issue] [issue1277] PyCode_GetNumFree() should accept
	PyCodeObject*
In-Reply-To: <1349315244.49.0.0906976810657.issue1277@bugs.pypy.org>
Message-ID: <1349377419.49.0.77837666704.issue1277@bugs.pypy.org>


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

Done with bdee7a1c7e4c, thanks!
I fail to see how it can be an issue though. A compilation warning maybe?

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

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

From tracker at bugs.pypy.org  Fri Oct  5 16:06:24 2012
From: tracker at bugs.pypy.org (Lisandro Dalcin)
Date: Fri, 05 Oct 2012 14:06:24 +0000
Subject: [pypy-issue] [issue1277] PyCode_GetNumFree() should accept
	PyCodeObject*
In-Reply-To: <1349315244.49.0.0906976810657.issue1277@bugs.pypy.org>
Message-ID: <1349445984.0.0.0973202265727.issue1277@bugs.pypy.org>


Lisandro Dalcin <dalcinl at gmail.com> added the comment:

A C++ compiler will certainly error. Thanks for the fix!

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

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

From tracker at bugs.pypy.org  Sat Oct  6 19:00:05 2012
From: tracker at bugs.pypy.org (Jorge)
Date: Sat, 06 Oct 2012 17:00:05 +0000
Subject: [pypy-issue] [issue1279] Numerical code for list of floats 3x
	slower than for list	of ints.
In-Reply-To: <1349542805.66.0.465019817253.issue1279@bugs.pypy.org>
Message-ID: <1349542805.66.0.465019817253.issue1279@bugs.pypy.org>


New submission from Jorge <jorgecanardo at gmail.com>:

The attached file is an extract of a very simple matrix class in Python.

I'm comparing its performance to a similar class in C++ by multiplying 500x500 
matrices. Timings were similar when the python matrices had only ints (C++ -O1 
0.9 s; PyPy 1.9.0 1.5 s) but using floats in the python side turned the 
multiplication over 3 times slower (!), much slower than even -O0. Does this 
make sense?

(As a workaround, I'm using array.array('d', ...), which is actually slightly 
faster than the int-only list (1.3 s).)

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

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

From tracker at bugs.pypy.org  Sun Oct  7 20:04:51 2012
From: tracker at bugs.pypy.org (Jeremy Thurgood)
Date: Sun, 07 Oct 2012 18:04:51 +0000
Subject: [pypy-issue] [issue1280] Bad "getting-started" link in architecture
	doc
In-Reply-To: <1349633091.57.0.165593654857.issue1280@bugs.pypy.org>
Message-ID: <1349633091.57.0.165593654857.issue1280@bugs.pypy.org>


New submission from Jeremy Thurgood <firxen at gmail.com>:

In the "Further reading" section in the "architecture" doc, there's a link to 
"getting-started.html". Based on the description, this should probably be 
"getting-started-dev.html".

----------
files: architecture-link-fix.patch
messages: 4823
nosy: jerith, pypy-issue
priority: wish
status: unread
title: Bad "getting-started" link in architecture doc

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

From tracker at bugs.pypy.org  Sun Oct  7 20:46:46 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Sun, 07 Oct 2012 18:46:46 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1349635606.9.0.912523365191.issue920@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

Gah, Can't find my old test cases. Only the one attached. So let's cause it closed.

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

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

From tracker at bugs.pypy.org  Mon Oct  8 13:26:02 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 08 Oct 2012 11:26:02 +0000
Subject: [pypy-issue] [issue1278] Cannot import dbm module
In-Reply-To: <1349364701.54.0.540197826062.issue1278@bugs.pypy.org>
Message-ID: <1349695562.43.0.510950982664.issue1278@bugs.pypy.org>


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

"Fixed" in 35840dd84c57.

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

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

From tracker at bugs.pypy.org  Mon Oct  8 13:54:11 2012
From: tracker at bugs.pypy.org (Valery)
Date: Mon, 08 Oct 2012 11:54:11 +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: <1349697251.05.0.0330366935338.issue1281@bugs.pypy.org>


New submission from Valery <khamenya at gmail.com>:

import numpypy as np
np.array(np.zeros(2, np.float32), dtype=np.float32) # ==> NotImplementedError: 
copying over different dtypes unsupported

----------
assignedto: fijal
messages: 4826
nosy: fijal, pypy-issue, vak
priority: bug
status: unread
title: numpypy: "copying over different dtypes" is wrongly reported

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

From tracker at bugs.pypy.org  Mon Oct  8 14:04:26 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 08 Oct 2012 12:04:26 +0000
Subject: [pypy-issue] [issue1275] uncaught exception crashes interpreter
In-Reply-To: <1349244830.29.0.622119811477.issue1275@bugs.pypy.org>
Message-ID: <1349697866.33.0.725702876803.issue1275@bugs.pypy.org>


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

Fixed in 3378cc2fde22 on branch numpypy-complex2.  Will be fixed when we merge
the branch.

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

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

From tracker at bugs.pypy.org  Mon Oct  8 14:17:42 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 08 Oct 2012 12:17:42 +0000
Subject: [pypy-issue] [issue1275] uncaught exception crashes interpreter
In-Reply-To: <1349244830.29.0.622119811477.issue1275@bugs.pypy.org>
Message-ID: <1349698662.15.0.609822087023.issue1275@bugs.pypy.org>


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

Branch merged :-)

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

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

From tracker at bugs.pypy.org  Tue Oct  9 12:02:24 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 09 Oct 2012 10:02:24 +0000
Subject: [pypy-issue] [issue1282] Too much memory consumed
In-Reply-To: <1349776944.1.0.58301608413.issue1282@bugs.pypy.org>
Message-ID: <1349776944.1.0.58301608413.issue1282@bugs.pypy.org>


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

This program apparently takes 700MB to run on PyPy, but less than 20MB on
CPython (zipfile):

https://github.com/adrianN/edge-connectivity/zipball/v2

----------
messages: 4829
nosy: arigo, pypy-issue
priority: bug
status: unread
title: Too much memory consumed

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

From tracker at bugs.pypy.org  Tue Oct  9 12:06:55 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 09 Oct 2012 10:06:55 +0000
Subject: [pypy-issue] [issue1282] Too much memory consumed
In-Reply-To: <1349776944.1.0.58301608413.issue1282@bugs.pypy.org>
Message-ID: <1349777215.86.0.360449621999.issue1282@bugs.pypy.org>


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

run tests.py

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

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

From tracker at bugs.pypy.org  Tue Oct  9 13:36:51 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 09 Oct 2012 11:36:51 +0000
Subject: [pypy-issue] [issue1282] Too much memory consumed
In-Reply-To: <1349776944.1.0.58301608413.issue1282@bugs.pypy.org>
Message-ID: <1349782611.71.0.313900073088.issue1282@bugs.pypy.org>


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

I can confirm the issue on amd64.

Python 2.7.3 (7f6d5c878b90, Oct 02 2012, 04:34:44)
[PyPy 1.9.1-dev0 with GCC 4.7.0] on linux2

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

From tracker at bugs.pypy.org  Tue Oct  9 13:52:16 2012
From: tracker at bugs.pypy.org (Jan Kaliszewski)
Date: Tue, 09 Oct 2012 11:52:16 +0000
Subject: [pypy-issue] [issue1283] A waiting stdin.read() in a thread +
	stdin.close() in	another thread = the latter freezes
In-Reply-To: <1349783536.48.0.877074876712.issue1283@bugs.pypy.org>
Message-ID: <1349783536.48.0.877074876712.issue1283@bugs.pypy.org>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

I encountered this behaviour when tried using multiprocessing.Process() when there was 
a waiting stdin.read() in some thread.

A simple example -- which worked well under CPython 2.7, but freezes under PyPy 1.9 -- 
follows:

from multiprocessing import Process
from threading import Thread
import sys

def f():
    while True:
        sys.stdin.read()

def g():
    print 'Process ok'

t = Thread(target=f)
t.daemon = True
t.start()

p = Process(target=g)
p.start()
p.join()

The problem is caused by sys.stdint.close() in multiprocessing.Process._bootstrap 
(file 'lib-python/2.7/multiprocessing/process.py, line #249).

But then I realized that it is not multiprocessing/fork-specific issue.

Simply any waiting stdin.read() + stdin.close() in another thread causes that thread 
to freeze (under PyPy, not under CPython), e.g.:


import sys
from threading import Thread

def f():
    while True:
        try:
            sys.stdin.read()
        except:
            return

def f2():
    sys.stdin.close()
    print 'All right'

t = Thread(target=f)
t.daemon = True
t.start()

t2 = Thread(target=f2)
t2.start()

t2.join()

----------
messages: 4832
nosy: pypy-issue, zuo
priority: bug
release: 1.9
status: unread
title: A waiting stdin.read() in a thread + stdin.close() in another thread = the latter freezes

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

From tracker at bugs.pypy.org  Tue Oct  9 22:20:19 2012
From: tracker at bugs.pypy.org (Simon Cross)
Date: Tue, 09 Oct 2012 20:20:19 +0000
Subject: [pypy-issue] [issue1280] Bad "getting-started" link in architecture
	doc
In-Reply-To: <1349633091.57.0.165593654857.issue1280@bugs.pypy.org>
Message-ID: <1349814019.16.0.962626213085.issue1280@bugs.pypy.org>


Simon Cross <hodgestar at gmail.com> added the comment:

Thanks for the patch! Applied.

----------
assignedto:  -> hodgestar
nosy: +hodgestar
status: unread -> resolved

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

From tracker at bugs.pypy.org  Wed Oct 10 21:51:40 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Wed, 10 Oct 2012 19:51:40 +0000
Subject: [pypy-issue] [issue1284] segfault with pypy 1.9, pyopenssl 0.13
In-Reply-To: <1349898700.08.0.761989216783.issue1284@bugs.pypy.org>
Message-ID: <1349898700.08.0.761989216783.issue1284@bugs.pypy.org>


New submission from Jon Oberheide <jonojono at umich.edu>:

getting an easily reproducible segfault with pypy and pyopenssl:

pypy -c 'import OpenSSL; conn = 
OpenSSL.SSL.Connection(OpenSSL.SSL.Context(OpenSSL.SSL.TLSv1_METHOD), None)'

environment: pypy 1.9 on 32-bit centos 6.3 with pyopenssl 0.13.

maybe be related to issue 1245?

----------
messages: 4834
nosy: jonojono, pypy-issue
priority: bug
status: unread
title: segfault with pypy 1.9, pyopenssl 0.13

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

From tracker at bugs.pypy.org  Wed Oct 10 22:46:17 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Wed, 10 Oct 2012 20:46:17 +0000
Subject: [pypy-issue] [issue1284] segfault with pypy 1.9, pyopenssl 0.13
In-Reply-To: <1349898700.08.0.761989216783.issue1284@bugs.pypy.org>
Message-ID: <1349901977.57.0.0646187797637.issue1284@bugs.pypy.org>


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

fyi, after fighting through a few more issues on the nightly build (oct 10), the 
issue is still reproducible.

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

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

From tracker at bugs.pypy.org  Wed Oct 10 22:58:22 2012
From: tracker at bugs.pypy.org (Jon Oberheide)
Date: Wed, 10 Oct 2012 20:58:22 +0000
Subject: [pypy-issue] [issue1285] compileall fails on unicode
In-Reply-To: <1349902702.47.0.0322304667023.issue1285@bugs.pypy.org>
Message-ID: <1349902702.47.0.0322304667023.issue1285@bugs.pypy.org>


New submission from Jon Oberheide <jonojono at umich.edu>:

unicode exceptions thrown when doing a compileall on files with certain unicode:

# pypy -m compileall foo.py
Compiling foo.py ...
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "/lib-python/2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/lib-python/2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/lib-python/2.7/compileall.py", line 226, in <module>
    exit_status = int(not main())
  File "/lib-python/2.7/compileall.py", line 216, in main
    if not compile_file(arg, ddir, force, rx, quiet):
  File "/lib-python/2.7/compileall.py", line 99, in compile_file
    ok = py_compile.compile(fullname, None, dfile, True)
  File "/lib-python/2.7/py_compile.py", line 126, in compile
    marshal.dump(codeobject, fc)
UnicodeEncodeError: 'utf-8' codec can't encode character u'\udf42' in position 0: surrogates not 
allowed
# cat foo.py
foo = u'\udf42'

works fine on python 2.7.3:

$ python -m compileall foo.py 
Compiling foo.py ...
$ cat foo.py
foo = u'\udf42'

----------
messages: 4836
nosy: jonojono, pypy-issue
priority: bug
status: unread
title: compileall fails on unicode

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

From tracker at bugs.pypy.org  Thu Oct 11 00:52:30 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 10 Oct 2012 22:52:30 +0000
Subject: [pypy-issue] [issue1285] compileall fails on unicode
In-Reply-To: <1349902702.47.0.0322304667023.issue1285@bugs.pypy.org>
Message-ID: <1349909550.12.0.620864483924.issue1285@bugs.pypy.org>


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

u'\udf42' is a lone surrogate.
The error also happens with normal imports: the error is swallowed and the .pyc 
file is not created.

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

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

From tracker at bugs.pypy.org  Thu Oct 11 00:53:41 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 10 Oct 2012 22:53:41 +0000
Subject: [pypy-issue] [issue1285] compileall fails on unicode
In-Reply-To: <1349902702.47.0.0322304667023.issue1285@bugs.pypy.org>
Message-ID: <1349909621.55.0.300316841906.issue1285@bugs.pypy.org>


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

Fixed with ce4e0ff9862b, thanks for the report!

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

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

From tracker at bugs.pypy.org  Fri Oct 12 17:40:40 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Fri, 12 Oct 2012 15:40:40 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>


New submission from Gabriel <g2p.code+pypy at gmail.com>:

Test and fix are attached, apply with hg mimport.

----------
files: mbox
messages: 4839
nosy: pypy-issue
priority: bug
status: unread
title: ioctl fails on int arguments

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

From tracker at bugs.pypy.org  Fri Oct 12 18:14:43 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 12 Oct 2012 16:14:43 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350058483.26.0.53005326434.issue1286@bugs.pypy.org>


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

Patch should also test for error values::
        if rv < 0:
            raise _get_error(space, "ioctl")

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

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

From tracker at bugs.pypy.org  Fri Oct 12 19:35:38 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Fri, 12 Oct 2012 17:35:38 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350063338.09.0.95231552306.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

Thanks, I've updated the patch.

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

From tracker at bugs.pypy.org  Sat Oct 13 16:46:31 2012
From: tracker at bugs.pypy.org (Valery)
Date: Sat, 13 Oct 2012 14:46:31 +0000
Subject: [pypy-issue] [issue1287] tiny bug in numpypy fancy indexing
	(arr[[]]=1 throws	error)
In-Reply-To: <1350139591.89.0.651654904046.issue1287@bugs.pypy.org>
Message-ID: <1350139591.89.0.651654904046.issue1287@bugs.pypy.org>


New submission from Valery <khamenya at gmail.com>:

import numpypy as np
z = np.zeros(0, dtype=np.int32)
z[z]=0 # IndexError: wrong index
z[[]]=0 # IndexError: wrong index

----------
assignedto: fijal
messages: 4842
nosy: fijal, pypy-issue, vak
priority: bug
status: unread
title: tiny bug in numpypy fancy indexing (arr[[]]=1 throws error)

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

From tracker at bugs.pypy.org  Sun Oct 14 10:34:39 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Oct 2012 08:34:39 +0000
Subject: [pypy-issue] [issue1279] Numerical code for list of floats 3x
	slower than for list	of ints.
In-Reply-To: <1349542805.66.0.465019817253.issue1279@bugs.pypy.org>
Message-ID: <1350203679.79.0.212018818736.issue1279@bugs.pypy.org>


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

It's an issue of a list of ints-or-floats: if you change the example to use
floats everywhere --- in the creation of A, in the creation of B, and in the
creation of result --- then the result is again fast, slightly faster than with
ints.

I would recommend that we look at implementing the notion of list of
32-bit-int-or-float, by using invalid float representation (NaNs) to mean "it's
really an int".

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

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

From tracker at bugs.pypy.org  Sun Oct 14 11:23:49 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Oct 2012 09:23:49 +0000
Subject: [pypy-issue] [issue1288] CPython executes code significantly faster
In-Reply-To: <1350143013.15.0.0415390287387.issue1288@bugs.pypy.org>
Message-ID: <1350206629.55.0.112741128846.issue1288@bugs.pypy.org>


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

Your example shows timings of 0.005725 seconds versus 0.002292 seconds.  That's
far too little to give the JIT compiler even a chance to fire.  Does the same
ratio remain if the program is made to run for several seconds?

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

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

From tracker at bugs.pypy.org  Sun Oct 14 11:27:01 2012
From: tracker at bugs.pypy.org (andenix)
Date: Sun, 14 Oct 2012 09:27:01 +0000
Subject: [pypy-issue] [issue1288] CPython executes code significantly faster
In-Reply-To: <1350206629.55.0.112741128846.issue1288@bugs.pypy.org>
Message-ID: <507A851F.80408@gmail.com>


andenix <andenixa at gmail.com> added the comment:

Hello Armin Rigo,

Yes as I indicated in the notes the same ratio sales for more 
complicated tasks.
That's how I stumbled upon the issue in the first place. We have 
thousands of
files for my script to crawl and the difference are seconds in that case.

Artem.

On 10/14/2012 13:23, Armin Rigo wrote:
> Armin Rigo <armin.rigo at gmail.com> added the comment:
>
> Your example shows timings of 0.005725 seconds versus 0.002292 seconds.  That's
> far too little to give the JIT compiler even a chance to fire.  Does the same
> ratio remain if the program is made to run for several seconds?
>
> ----------
> nosy: +arigo
> status: unread -> chatting
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1288>
> ________________________________________
>

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

From tracker at bugs.pypy.org  Sun Oct 14 12:19:43 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Oct 2012 10:19:43 +0000
Subject: [pypy-issue] [issue1282] Too much memory consumed (looks like
	severe memory leak)
In-Reply-To: <1349776944.1.0.58301608413.issue1282@bugs.pypy.org>
Message-ID: <1350209983.26.0.964009448359.issue1282@bugs.pypy.org>


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

Reproduced with a minimal example: the issue is generators that use "yield"
inside a "try:except:" or "try:finally:".  The attached test2.py consumes large
amounts of memory on PyPy and nothing on CPython.  With the three commented-out
lines enabled, it's even worse (s/large/huge amounts).

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

From tracker at bugs.pypy.org  Mon Oct 15 11:30:40 2012
From: tracker at bugs.pypy.org (Valery)
Date: Mon, 15 Oct 2012 09:30:40 +0000
Subject: [pypy-issue] [issue1282] Too much memory consumed (looks like
	severe memory leak)
In-Reply-To: <1349776944.1.0.58301608413.issue1282@bugs.pypy.org>
Message-ID: <1350293439.97.0.223970977576.issue1282@bugs.pypy.org>


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

arigo, really cool drill-down! 
Do you have ideas already why it is so in pypy?

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

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

From tracker at bugs.pypy.org  Mon Oct 15 18:18:21 2012
From: tracker at bugs.pypy.org (Alexey Kryuchkov)
Date: Mon, 15 Oct 2012 16:18:21 +0000
Subject: [pypy-issue] [issue1289] multiprocessing Pool + maxtasksperchild +
	signal =	ValueError
In-Reply-To: <1350317901.63.0.635751910168.issue1289@bugs.pypy.org>
Message-ID: <1350317901.63.0.635751910168.issue1289@bugs.pypy.org>


New submission from Alexey Kryuchkov <alexey.kruchkov at gmail.com>:

The following program runs correctly under CPython 2.7, but produces errors under PyPy:

# ---- bad.py ---------------------------------------------------
from multiprocessing import Pool
from signal import signal, SIGINT, SIG_DFL

def worker_init():
    # actual parameters of 'signal' have no influence on the outcome
    signal(SIGINT, SIG_DFL)

def worker_body(arg):
    print 'processing %s' % arg

def main():
    # 1) note the 'maxtasksperchild' parameter. The idea is that
    #    worker processes restart after every processed task.
    # 2) actual number of processes has no influence on the outcome
    pool = Pool(processes=1, maxtasksperchild=1, initializer=worker_init)
    sequence = [1, 2, 3, 4]
    pool.map(worker_body, sequence, chunksize=1)

if __name__ == '__main__':
    main()
# ---- end of bad.py ----------------------------------------------------

Expected output (which is also actual output under CPython 2.7) is:

    ~$ python bad.py
    processing 1
    processing 2
    processing 3
    processing 4
    ~$

Actual output under PyPy 1.9 is:

    ~$ pypy bad.py
    processing 1
    Process PoolWorker-2:
    Traceback (most recent call last):
      File "/opt/pypy-1.9/lib-python/2.7/multiprocessing/process.py", line 258, in _bootstrap
        self.run()
      File "/opt/pypy-1.9/lib-python/2.7/multiprocessing/process.py", line 114, in run
        self._target(*self._args, **self._kwargs)
      File "/opt/pypy-1.9/lib-python/2.7/multiprocessing/pool.py", line 80, in worker
        initializer(*initargs)
      File "badpypy.py", line 5, in worker_init
        signal(SIGINT, SIG_DFL)
    ValueError: signal() must be called from the main thread
    Process PoolWorker-3:
    Traceback (most recent call last):
      File "/opt/pypy-1.9/lib-python/2.7/multiprocessing/process.py", line 258, in _bootstrap
        self.run()
      File "/opt/pypy-1.9/lib-python/2.7/multiprocessing/process.py", line 114, in run
        self._target(*self._args, **self._kwargs)
      File "/opt/pypy-1.9/lib-python/2.7/multiprocessing/pool.py", line 80, in worker
        initializer(*initargs)
      File "badpypy.py", line 5, in worker_init
        signal(SIGINT, SIG_DFL)
    ValueError: signal() must be called from the main thread
    Process PoolWorker-4:
    (...and so on, until the process is killed manually)

Same program without 'maxtasksperchild' parameter executes correctly under PyPy:

# ---- good.py --------------------------------------
from multiprocessing import Pool
from signal import signal, SIGINT, SIG_DFL

def worker_init():
    signal(SIGINT, SIG_DFL)

def worker_body(arg):
    print 'processing %s' % arg

def main():
    # removed 'maxtasksperchild' parameter
    pool = Pool(processes=1, initializer=worker_init)
    sequence = [1, 2, 3, 4]
    pool.map(worker_body, sequence, chunksize=1)

if __name__ == '__main__':
    main()
# ---- end of good.py ---------------------------------

Its output under both PyPy and CPython is the same as CPython's output for bad.py.

My environment:

~$ pypy --version
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:38:48)
[PyPy 1.9.0 with GCC 4.4.3]
~$ python --version
Python 2.7.1+
~$ uname -a
Linux ALEXU31S 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:17:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
~$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.04
DISTRIB_CODENAME=natty
DISTRIB_DESCRIPTION="Ubuntu 11.04"

----------
messages: 4849
nosy: babazka, pypy-issue
priority: bug
release: 1.9
status: unread
title: multiprocessing Pool + maxtasksperchild + signal = ValueError

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

From tracker at bugs.pypy.org  Mon Oct 15 21:37:11 2012
From: tracker at bugs.pypy.org (Sergey Kozyr)
Date: Mon, 15 Oct 2012 19:37:11 +0000
Subject: [pypy-issue] [issue1290] Port API for error handling under Windows
In-Reply-To: <1350329831.93.0.492727342867.issue1290@bugs.pypy.org>
Message-ID: <1350329831.93.0.492727342867.issue1290@bugs.pypy.org>


New submission from Sergey Kozyr <s.trump at gmail.com>:

CPython has a number of functions to raise exceptions after Windows API error 
ocures. See pyerrors.h:
PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErrWithFilenameObject(int, const 
char *);
PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErrWithFilename(int, const char *);
PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErrWithUnicodeFilename(int, const 
Py_UNICODE *);
PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErr(int);
PyAPI_FUNC(PyObject *) PyErr_SetExcFromWindowsErrWithFilenameObject(PyObject 
*,int, PyObject *);
PyAPI_FUNC(PyObject *) PyErr_SetExcFromWindowsErrWithFilename(PyObject *,int, 
const char *);
PyAPI_FUNC(PyObject *) PyErr_SetExcFromWindowsErrWithUnicodeFilename(PyObject 
*,int, const Py_UNICODE *);
PyAPI_FUNC(PyObject *) PyErr_SetExcFromWindowsErr(PyObject *, int);

These functions are needed to build Mercurial under Windows.

----------
messages: 4850
nosy: pypy-issue, skozyr
priority: bug
status: unread
title: Port API for error handling under Windows

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

From tracker at bugs.pypy.org  Tue Oct 16 00:23:53 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 15 Oct 2012 22:23:53 +0000
Subject: [pypy-issue] [issue1289] multiprocessing Pool + maxtasksperchild +
	signal =	ValueError
In-Reply-To: <1350317901.63.0.635751910168.issue1289@bugs.pypy.org>
Message-ID: <1350339833.3.0.745119496831.issue1289@bugs.pypy.org>


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

- Why "maxtasksperchild"?  Because Pool.__init__ will spawn the first worker process, and this 
one works, but after the worker process exits, additional workers are spawned from a separate 
thread (see the call to pool._maintain_pool() in multiprocessing/pool.py)

- So the problem is that fork() from a thread does not reinitialize the interpreter correctly. 
in our case, the idea of "main thread" of the signal module must be reset; also, threadlocal 
values should be discarded.

Here is a patch with tests. Armin, could you please review it?

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

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

From tracker at bugs.pypy.org  Tue Oct 16 00:32:00 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 15 Oct 2012 22:32:00 +0000
Subject: [pypy-issue] [issue1290] Port API for error handling under Windows
In-Reply-To: <1350329831.93.0.492727342867.issue1290@bugs.pypy.org>
Message-ID: <1350340320.12.0.281137376297.issue1290@bugs.pypy.org>


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

Note that mercurial has "pure" versions of all extension modules:
http://mercurial.selenic.com/wiki/WindowsInstall#Building_pure_Python_alternative
In PyPy C Extensions are very slow, and the Python version is likely to be faster.

I let the issue open though, in case someone wants to implement these functions; it's an easy task for a 
newcomer.

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

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

From tracker at bugs.pypy.org  Wed Oct 17 01:56:33 2012
From: tracker at bugs.pypy.org (montag451)
Date: Tue, 16 Oct 2012 23:56:33 +0000
Subject: [pypy-issue] [issue1090] Can't bind packet socket
In-Reply-To: <1331821189.63.0.719460787992.issue1090@bugs.pypy.org>
Message-ID: <1350431793.61.0.312432177557.issue1090@bugs.pypy.org>


montag451 <montag451 at laposte.net> added the comment:

I finally found some time to work on this "unimplemented feature" :) I provide
you with a patch that allows bind() to work with packet socket. I tested it with
py.py and with a translated interpreter and it seems to work.

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

From tracker at bugs.pypy.org  Wed Oct 17 12:48:16 2012
From: tracker at bugs.pypy.org (iElectric)
Date: Wed, 17 Oct 2012 10:48:16 +0000
Subject: [pypy-issue] [issue1291] flake8 segfaults
In-Reply-To: <1350470896.01.0.743441876634.issue1291@bugs.pypy.org>
Message-ID: <1350470896.01.0.743441876634.issue1291@bugs.pypy.org>


New submission from iElectric <domen at dev.si>:

See last line of https://travis-ci.org/#!/iElectric/mr.bob/jobs/2823396

Flake8 is pep8+pyflakes checker: https://bitbucket.org/tarek/flake8

Steps to reproduce in travis-ci logs.

----------
messages: 4854
nosy: iElectric, pypy-issue
priority: bug
status: unread
title: flake8 segfaults

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

From tracker at bugs.pypy.org  Wed Oct 17 15:51:01 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 17 Oct 2012 13:51:01 +0000
Subject: [pypy-issue] [issue1090] Can't bind packet socket
In-Reply-To: <1331821189.63.0.719460787992.issue1090@bugs.pypy.org>
Message-ID: <1350481861.54.0.40080334978.issue1090@bugs.pypy.org>


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

Hi montag. Thank you for your contributions! However, in order to incorporate 
this to code, it requires to come with tests. See the current tests in 
test/test_rsocket.py. I also suggest looking up py.test, the tool we use for 
running those tests, it's really great.

Cheers,
fijal

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

From tracker at bugs.pypy.org  Wed Oct 17 22:20:15 2012
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 17 Oct 2012 20:20:15 +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: <1350505215.62.0.353253094913.issue1160@bugs.pypy.org>


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

so np.int() returns a python int, and np.bool() returns a python bool.
these seem like needless interfaces, is there an actual use case for them?

what is the use case for np.integer - why should we implement this abstract class?

----------
nosy: +mattip

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

From tracker at bugs.pypy.org  Wed Oct 17 22:33:28 2012
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 17 Oct 2012 20:33:28 +0000
Subject: [pypy-issue] [issue1143] numpypy: bug in array_equal
In-Reply-To: <1337195357.97.0.624497287196.issue1143@bugs.pypy.org>
Message-ID: <1350506008.92.0.576423695463.issue1143@bugs.pypy.org>


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

this works fine 
np.array_equal([4],[4])
what is the use case for using numpy for non-array-like comparisons?

----------
nosy: +mattip

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

From tracker at bugs.pypy.org  Thu Oct 18 00:21:00 2012
From: tracker at bugs.pypy.org (PJ Eby)
Date: Wed, 17 Oct 2012 22:21:00 +0000
Subject: [pypy-issue] [issue1292] repr() of type created in non-module code
	varies from	CPython
In-Reply-To: <1350512460.82.0.614785304877.issue1292@bugs.pypy.org>
Message-ID: <1350512460.82.0.614785304877.issue1292@bugs.pypy.org>


New submission from PJ Eby <pje at telecommunity.com>:

If you create a new-style class in a namespace which is
not a module (i.e. it lacks a __name__, as in e.g. a
doctest file), PyPy assumes it is a built-in type, and
produces a repr accordingly.  However, CPython still
considers the type a user-defined class, and displays
its repr accordingly:

$ py27
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> del __name__
>>> class x(int): pass
...
>>> x
<class 'x'>

$ pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:43:00)
[PyPy 1.9.0 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``first they laugh at you, then
they ignore you, then they fight you, then you win''
>>>> del __name__
>>>> class x(int): pass
>>>> x
<type 'x'>

This causes doctests that display a type defined in that
doctest to break, relative to the same doctest on CPython,
making it challenging to support PyPy in such a test suite.

----------
messages: 4858
nosy: pje, pypy-issue
priority: bug
status: unread
title: repr() of type created in non-module code varies from CPython

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

From tracker at bugs.pypy.org  Thu Oct 18 01:04:34 2012
From: tracker at bugs.pypy.org (PJ Eby)
Date: Wed, 17 Oct 2012 23:04:34 +0000
Subject: [pypy-issue] [issue1293] Assigning to func_code changes function
	docstring
In-Reply-To: <1350515074.35.0.446346865626.issue1293@bugs.pypy.org>
Message-ID: <1350515074.35.0.446346865626.issue1293@bugs.pypy.org>


New submission from PJ Eby <pje at telecommunity.com>:

In CPython, assigning to func_code does not change the
function's docstring:

$ py27
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def f1(x,*y,**z): "f1"
...
>>> def f2(x,*y,**z): "f2"
...
>>> f2.func_code = f1.func_code
>>> print f2.__doc__
f2

But in PyPy, it does:

$ pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:43:00)
[PyPy 1.9.0 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``Python 2.x is not dead''
>>>> def f1(x,*y,**z): "f1"
>>>> def f2(x,*y,**z): "f2"
>>>> f2.func_code = f1.func_code
>>>> print f2.__doc__
f1

This appears to be due to an optimization where function
objects' doc slot is lazily initialized; assigning to
func_code should ensure this initialization occurs before
actually changing the code.  (Probably just by calling
the fget_func_doc() method.)

----------
messages: 4859
nosy: pje, pypy-issue
priority: bug
status: unread
title: Assigning to func_code changes function docstring

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

From tracker at bugs.pypy.org  Thu Oct 18 09:01:16 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 18 Oct 2012 07:01:16 +0000
Subject: [pypy-issue] [issue1143] numpypy: bug in array_equal
In-Reply-To: <1337195357.97.0.624497287196.issue1143@bugs.pypy.org>
Message-ID: <1350543676.59.0.640440061496.issue1143@bugs.pypy.org>


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

as for my purposes it is used in comparison of data returned by user; sometimes
it can be array-like, sometimes number (e.g. objective function or nonlinear
constraint for numerical optimization). Using asarray() each time will slow down
computations in the deeply nested cycles, and in any way numpypy declares full
compatibility with numpy, at least for cases like this one.

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

From tracker at bugs.pypy.org  Thu Oct 18 10:46:15 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 08:46:15 +0000
Subject: [pypy-issue] [issue1294] revive test_memmgr.py
In-Reply-To: <1350549975.06.0.311009980089.issue1294@bugs.pypy.org>
Message-ID: <1350549975.06.0.311009980089.issue1294@bugs.pypy.org>


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

On cleanup-llgraph-backend branch we disabled test_memmgr. We should revive it at 
some point, preferably after merging result-in-resops

----------
messages: 4861
nosy: fijal, pypy-issue
priority: bug
status: unread
title: revive test_memmgr.py

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

From tracker at bugs.pypy.org  Thu Oct 18 11:11:27 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 09:11:27 +0000
Subject: [pypy-issue] [issue551] Support for freebsd8+
In-Reply-To: <1277927775.84.0.874227943024.issue551@>
Message-ID: <1350551487.43.0.905253361295.issue551@bugs.pypy.org>


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

asmgcroot is disabled on non-linux platforms, closing

----------
nosy: +fijal
status: in-progress -> resolved

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

From tracker at bugs.pypy.org  Thu Oct 18 11:18:11 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Oct 2012 09:18:11 +0000
Subject: [pypy-issue] [issue1293] Assigning to func_code changes function
	docstring
In-Reply-To: <1350515074.35.0.446346865626.issue1293@bugs.pypy.org>
Message-ID: <1350551891.48.0.17138617958.issue1293@bugs.pypy.org>


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

Fixed (5b2403f92a1e).

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

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

From tracker at bugs.pypy.org  Thu Oct 18 11:20:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 09:20:00 +0000
Subject: [pypy-issue] [issue402] codecs are broken in pypy-c
In-Reply-To: <1222123593.51.0.759600860461.issue402@>
Message-ID: <1350552000.5.0.0373275903819.issue402@bugs.pypy.org>


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

Closing as wontfix for now. It seems both behaviors are acceptable to me.

----------
nosy: +fijal
status: in-progress -> wontfix

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

From tracker at bugs.pypy.org  Thu Oct 18 11:23:23 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 09:23:23 +0000
Subject: [pypy-issue] [issue703] Pypy runs slower that cpython in a function
	call cache
In-Reply-To: <1304196890.39.0.215602888065.issue703@>
Message-ID: <1350552203.85.0.662074052993.issue703@bugs.pypy.org>


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

This runs by now with very similar speed. I have some optimizations in mind that 
would run it faster, but they don't belong to this issue. Marking as "resolved" 
(although it should run faster)

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

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

From tracker at bugs.pypy.org  Thu Oct 18 11:28:45 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Oct 2012 09:28:45 +0000
Subject: [pypy-issue] [issue1292] repr() of type created in non-module code
	varies from	CPython
In-Reply-To: <1350512460.82.0.614785304877.issue1292@bugs.pypy.org>
Message-ID: <1350552525.0.0.00218459758237.issue1292@bugs.pypy.org>


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

testing (273ee4e3a74c)

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

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

From tracker at bugs.pypy.org  Thu Oct 18 11:31:27 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 09:31:27 +0000
Subject: [pypy-issue] [issue765] Fields get written on frame that is about
	to be dead
In-Reply-To: <1309031767.75.0.0268190716619.issue765@bugs.pypy.org>
Message-ID: <1350552687.33.0.0154299174026.issue765@bugs.pypy.org>


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

Working on it on continuelet-jit-3 branch, will close this issue.

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

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

From tracker at bugs.pypy.org  Thu Oct 18 11:44:27 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 09:44:27 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350553467.64.0.190843677198.issue1286@bugs.pypy.org>


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

Hi. Hardcoding the values is a very bad idea, please import them from termios 
and pass the correct usemodules to gettestobjspace.

Please submit patches as a normal diff or a pull request, I know different 
people have different work styles, but for us it's much easier to work with 
diffs and pull requests.

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

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

From tracker at bugs.pypy.org  Thu Oct 18 11:45:08 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 09:45:08 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350553508.55.0.960615523077.issue1286@bugs.pypy.org>


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

Ah another issues - those tests should not be skipped. Make a subprocess or 
something that does work when stdin is not a tty. Otherwise we never test it in 
the nightly build which defeats the point.

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

From tracker at bugs.pypy.org  Thu Oct 18 12:16:00 2012
From: tracker at bugs.pypy.org (Valery)
Date: Thu, 18 Oct 2012 10:16:00 +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: <1350555360.82.0.673471095788.issue1160@bugs.pypy.org>


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

hi mattip

  > why should we implement this abstract class?

it rather exists already in pypy:

>>>> np.integer
<type 'numpypy.integer'>

>>>> isinstance(np.int32(1), np.integer)
True

>>>> isinstance(np.int64(1), np.integer)
True

as to this question and the previous one:

  > these seem like needless interfaces, is there an actual use case for them?


the intent was like that: one could make it more compatible with original numpy, if it is a 
*few* lines of patching, of course.

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

From tracker at bugs.pypy.org  Thu Oct 18 13:07:09 2012
From: tracker at bugs.pypy.org (dremon)
Date: Thu, 18 Oct 2012 11:07:09 +0000
Subject: [pypy-issue] [issue1295] Missing os.setgroups function on Linux
In-Reply-To: <1350558429.33.0.271811847.issue1295@bugs.pypy.org>
Message-ID: <1350558429.33.0.271811847.issue1295@bugs.pypy.org>


New submission from dremon <dmitry at pankratov.net>:

The setgroups function is missing from the os package under Unix platforms.

----------
messages: 4872
nosy: dremon, pypy-issue
priority: feature
status: unread
title: Missing os.setgroups function on Linux

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

From tracker at bugs.pypy.org  Thu Oct 18 14:03:38 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Thu, 18 Oct 2012 12:03:38 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350561818.45.0.252490631578.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

I didn't know about gettestobjspace, I'll use it. I'll have to think of a way to
make the test work with a pty.

I just checked, it turns out you can `hg import mbox` which is probably the
usual way you apply patches. The first rosetta stone I used[1] told me to use
mimport, but that's not necessary; [2] has better help.

[1] http://mercurial.selenic.com/wiki/GitConcepts
[2] https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone

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

From tracker at bugs.pypy.org  Thu Oct 18 14:10:58 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Thu, 18 Oct 2012 12:10:58 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350562258.71.0.408275474578.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

test roundup email

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

From tracker at bugs.pypy.org  Thu Oct 18 14:48:19 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Thu, 18 Oct 2012 12:48:19 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350564499.93.0.448833374541.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

No objection if I fix the other tests that hardcode TIOC* constants in the same
file?

Is it normal that I don't get any email from roundup?

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

From tracker at bugs.pypy.org  Thu Oct 18 15:23:39 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Thu, 18 Oct 2012 13:23:39 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350566619.78.0.857671767087.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

Patch updated, all ioctl tests now use termios constants and ptys.

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

From tracker at bugs.pypy.org  Thu Oct 18 15:26:59 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 13:26:59 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350566819.98.0.601703670477.issue1286@bugs.pypy.org>


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

The problem with hg import etc. is that I cannot easily see a diff. that's why we 
prefer hg diff > somefile and send this file.

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

From tracker at bugs.pypy.org  Thu Oct 18 15:27:48 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 13:27:48 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350566868.6.0.731779175561.issue1286@bugs.pypy.org>


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

ok, I'm a moron, hg diff -r works fine.

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

From tracker at bugs.pypy.org  Thu Oct 18 15:28:15 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 18 Oct 2012 13:28:15 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350566895.12.0.121165061761.issue1286@bugs.pypy.org>


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

applied and merged, thanks for your patch!

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

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

From tracker at bugs.pypy.org  Thu Oct 18 16:33:53 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 18 Oct 2012 14:33:53 +0000
Subject: [pypy-issue] [issue1295] Missing os.setgroups function on Linux
In-Reply-To: <1350558429.33.0.271811847.issue1295@bugs.pypy.org>
Message-ID: <1350570833.93.0.532026187133.issue1295@bugs.pypy.org>


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

Duplicate of https://bugs.pypy.org/issue833

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

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

From tracker at bugs.pypy.org  Fri Oct 19 00:36:11 2012
From: tracker at bugs.pypy.org (Steve Clift)
Date: Thu, 18 Oct 2012 22:36:11 +0000
Subject: [pypy-issue] [issue1296] Complete your registration to PyPy bug
	tracker --	keyLHxQwd7mb3nQXuJ1pHd4FeHd7EOu3Olb
In-Reply-To: <20121018223036.8519BAD90031@hq.merlinux.eu>
Message-ID: <BCFD49492570364F9493CCE8D65B1AB3049310D9@mir.Datron.L-3Com.com>


New submission from Steve Clift <Steve.Clift at L-3Com.com>:

-----Original Message-----
From: PyPy bug tracker [mailto:tracker at bugs.pypy.org] 
Sent: Thursday, October 18, 2012 3:31 PM
To: Clift, Steve @ MWG - Datron
Subject: Complete your registration to PyPy bug tracker -- keyLHxQwd7mb3nQXuJ1pHd4FeHd7EOu3Olb

To complete your registration of the user "sclift" with PyPy bug tracker, please do one of the following:

- send a reply to tracker at bugs.pypy.org and maintain the subject line as is (the reply's additional "Re:" is ok),

- or visit the following URL:

https://bugs.pypy.org/?@action=confrego&otk=LHxQwd7mb3nQXuJ1pHd4FeHd7EOu3Olb

----------
messages: 4881
nosy: pypy-issue, sclift
status: unread
title: Complete your registration to PyPy bug tracker -- keyLHxQwd7mb3nQXuJ1pHd4FeHd7EOu3Olb

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

From tracker at bugs.pypy.org  Fri Oct 19 01:01:00 2012
From: tracker at bugs.pypy.org (Steve Clift)
Date: Thu, 18 Oct 2012 23:01:00 +0000
Subject: [pypy-issue] [issue1297] performance regression from 1.7 to 1.8/1.9
In-Reply-To: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>
Message-ID: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>


New submission from Steve Clift <Steve.Clift at L-3Com.com>:

I'm seeing a strange performance regression with 1.8/1.9. The Python program 
does a lot of bit fiddling, unpacking inconveniently formatted binary data from 
a file. Timing, using Ubuntu 8.04 on a Dell Latitude E6400:

python-2.5.2:                              6.7 secs
pypy-1.7:                                  1.7
pypy-1.9:                                 13.0 (same with 1.8 IIRC)
pypy-1.9 --jit off:                        9.0
pypy-1.9 running program through cProfile: 7.0!

Has anyone else seen anything like this, or do I need to explore further to try 
to isolate the problem?

----------
messages: 4882
nosy: pypy-issue, sclift
priority: bug
status: unread
title: performance regression from 1.7 to 1.8/1.9

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

From tracker at bugs.pypy.org  Fri Oct 19 12:43:50 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 19 Oct 2012 10:43:50 +0000
Subject: [pypy-issue] [issue1297] performance regression from 1.7 to 1.8/1.9
In-Reply-To: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>
Message-ID: <1350643430.04.0.506256378016.issue1297@bugs.pypy.org>


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

Hi

This sounds very strange an unexpected. We probably have to see the program 
though.

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

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

From tracker at bugs.pypy.org  Sun Oct 21 01:48:32 2012
From: tracker at bugs.pypy.org (mike bayer)
Date: Sat, 20 Oct 2012 23:48:32 +0000
Subject: [pypy-issue] [issue1298] performance w/ sqlalchemy test suite
In-Reply-To: <1350776912.86.0.0398129877721.issue1298@bugs.pypy.org>
Message-ID: <1350776912.86.0.0398129877721.issue1298@bugs.pypy.org>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

per this HN thread: https://news.ycombinator.com/item?id=4648758 Fijal asked
that I report over here the slowness I'm seeing when running SQLAlchemy's very
large test suite with pypy.   Our tests are normally run on Amazon EC2 small
instances, where SQLA's suite takes about 2 hours 17 minutes to run with pypy +
sqlite - the equivalent suite on cPython takes 17 minutes on that platform, and
runs many more tests that are already skipped on the pypy platform (such as
profiling tests).   

Running a vanilla set of SQLA tests is pretty easy, dependencies are only sqlite
+ nose.    From a checkout here:

    hg clone http://hg.sqlalchemy.org/sqlalchemy

the full set of 4000+ tests can be run like:

    python ./sqla_nose.py -v 

a smaller segment of the tests that can be compared more expediently can be run
like this:

    python ./sqla_nose.py -v -w sql

Results I have running these on both my MacBook as well as on the EC2 instance:

    all tests, OSX:    760 sec (Pypy) vs 211 sec (cPython)  3.6x slower

    -w sql tests, OSX:  24 sec (Pypy) vs 4.5 sec (cPython)  5.3x slower

    EC2 small, all tests:   2 hr 17 minutes (Pypy) vs 17 minutes (cPython)  8x
slower

on my end I can only make fairly ignorant guesses as to why this is, the very
large size of the SQLAlchemy test suite and the large number of new codepaths it
produces I'd imagine gives pypy a lot of work in running the JIT, but other than
that I don't have much insight.  Memory usage remains stable with Pypy, it does
use 99% CPU all the way through as much as it can, however.

----------
messages: 4884
nosy: pypy-issue, zzzeek
priority: performance bug
status: unread
title: performance w/ sqlalchemy test suite

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

From tracker at bugs.pypy.org  Sun Oct 21 17:58:13 2012
From: tracker at bugs.pypy.org (Nadeem Vawda)
Date: Sun, 21 Oct 2012 15:58:13 +0000
Subject: [pypy-issue] [issue1299] BZ2Decompressor.decompress('') does not
	raise EOFError at	end-of-stream
In-Reply-To: <1350835093.79.0.154298635484.issue1299@bugs.pypy.org>
Message-ID: <1350835093.79.0.154298635484.issue1299@bugs.pypy.org>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

In CPython, the BZ2Decompressor.decompress method raises EOFError if the end of 
the compressed stream has been reached. This can be useful, as it allows the 
caller to determine whether end-of-stream has been reached without affecting the 
decompressor's internal state. However, in PyPy 1.9, no exception is raised if 
the input data is of length 0, so this trick cannot be used.

The attached patch changes PyPy's behavior in this case to match CPython.

----------
files: bz2-decompress-eof.diff
messages: 4885
nosy: nadeem.vawda, pypy-issue
priority: bug
release: 2.0
status: unread
title: BZ2Decompressor.decompress('') does not raise EOFError at end-of-stream

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

From tracker at bugs.pypy.org  Mon Oct 22 12:08:52 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 22 Oct 2012 10:08:52 +0000
Subject: [pypy-issue] [issue1299] BZ2Decompressor.decompress('') does not
	raise EOFError at	end-of-stream
In-Reply-To: <1350835093.79.0.154298635484.issue1299@bugs.pypy.org>
Message-ID: <1350900531.94.0.616767278596.issue1299@bugs.pypy.org>


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

Hi Nadeem.

Can you update your patch to include tests?

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

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

From tracker at bugs.pypy.org  Mon Oct 22 21:06:31 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 22 Oct 2012 19:06:31 +0000
Subject: [pypy-issue] [issue1299] BZ2Decompressor.decompress('') does not
	raise EOFError at	end-of-stream
In-Reply-To: <1350835093.79.0.154298635484.issue1299@bugs.pypy.org>
Message-ID: <1350932791.99.0.594463007218.issue1299@bugs.pypy.org>


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

The change to test_bz2.py should be pushed to CPython repository.
Otherwise pypy will lose it on next stdlib upgrade.

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

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

From tracker at bugs.pypy.org  Mon Oct 22 22:15:12 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 22 Oct 2012 20:15:12 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1350936912.96.0.184600830687.issue1206@bugs.pypy.org>


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

This should be fixed now.

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

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

From tracker at bugs.pypy.org  Mon Oct 22 23:55:49 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Mon, 22 Oct 2012 21:55:49 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350942949.56.0.48694872113.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

Looks like the other test I changed to work with ptys doesn't pass on the
buildbot:
http://buildbot.pypy.org/summary/longrepr?testname=AppTestFcntl.%28%29.test_ioctl&builder=pypy-c-jit-linux-x86-64&build=1081&mod=module.fcntl.test.test_fcntl

Since the test changed without a matching change in the implementation, I'm
fairly certain the problem comes from pty.fork(). I'll see how PyPy implements it.

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

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

From tracker at bugs.pypy.org  Mon Oct 22 23:59:27 2012
From: tracker at bugs.pypy.org (Nadeem Vawda)
Date: Mon, 22 Oct 2012 21:59:27 +0000
Subject: [pypy-issue] [issue1299] BZ2Decompressor.decompress('') does not
	raise EOFError at	end-of-stream
In-Reply-To: <1350835093.79.0.154298635484.issue1299@bugs.pypy.org>
Message-ID: <1350943167.36.0.73115420794.issue1299@bugs.pypy.org>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

@fijal: The patch already includes a test that decompress('') raises EOFError.

@afa: OK, will do.

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

From tracker at bugs.pypy.org  Tue Oct 23 00:54:11 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Mon, 22 Oct 2012 22:54:11 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350946451.26.0.672978817099.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

I can't reproduce the test fail even when closing the three standard streams,
and the implementation of pty.fork() (from lib-python) seems solid enough.
pty.fork() also works well under pypy here, because the test didn't work when I
simply used openpty. ioctl doesn't seem broken, my own program exercices it
quite a lot with all supported kinds of arguments. This test didn't run on the
buildbot before, so the other option is that the test is broken in some way that
only appears on the buildbot. Appart from the attached tweak?????I've got nothing.

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

From tracker at bugs.pypy.org  Tue Oct 23 01:03:15 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Mon, 22 Oct 2012 23:03:15 +0000
Subject: [pypy-issue] [issue1286] ioctl fails on int arguments
In-Reply-To: <1350056440.78.0.186892215993.issue1286@bugs.pypy.org>
Message-ID: <1350946995.68.0.610007889477.issue1286@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

Removed the tweak, the idea was just that 'h' should ideally be replaced by
uint32_t, but there's no simple way to do that with the array module.

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

From tracker at bugs.pypy.org  Tue Oct 23 21:03:54 2012
From: tracker at bugs.pypy.org (Steve Clift)
Date: Tue, 23 Oct 2012 19:03:54 +0000
Subject: [pypy-issue] [issue1297] performance regression from 1.7 to 1.8/1.9
In-Reply-To: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>
Message-ID: <1351019034.59.0.381730082036.issue1297@bugs.pypy.org>


Steve Clift <Steve.Clift at L-3Com.com> added the comment:

OK, I isolated the problem. Test program attached. This takes about 0.2 seconds
with pypy-1.7, about 0.5 seconds with python 2.7 and about 25 seconds with pypy-1.9.

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

From tracker at bugs.pypy.org  Wed Oct 24 15:55:35 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 24 Oct 2012 13:55:35 +0000
Subject: [pypy-issue] [issue1297] performance regression from 1.7 to 1.8/1.9
In-Reply-To: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>
Message-ID: <1351086935.89.0.0472142826795.issue1297@bugs.pypy.org>


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

This thing aborts with BAD LOOP a lot. Hakan, can you have a look?

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

From tracker at bugs.pypy.org  Wed Oct 24 16:32:28 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 24 Oct 2012 14:32:28 +0000
Subject: [pypy-issue] [issue1294] revive test_memmgr.py
In-Reply-To: <1350549975.06.0.311009980089.issue1294@bugs.pypy.org>
Message-ID: <1351089148.06.0.41210483663.issue1294@bugs.pypy.org>


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

Resolved a few days ago.

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

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

From tracker at bugs.pypy.org  Wed Oct 24 16:36:46 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 24 Oct 2012 14:36:46 +0000
Subject: [pypy-issue] [issue1300] list slice out of bound raise rpython error
In-Reply-To: <1350932297.27.0.76193832469.issue1300@bugs.pypy.org>
Message-ID: <1351089406.06.0.710658635008.issue1300@bugs.pypy.org>


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

No, that's wrong: RPython assumes that some slice indices are not out-of-bounds.
 You get a MemoryError because it's trying to allocate a list of -1 elements. 
For the exact rules see *slicing* in pypy/doc/coding-guide.rst.

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

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

From tracker at bugs.pypy.org  Wed Oct 24 16:38:30 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 24 Oct 2012 14:38:30 +0000
Subject: [pypy-issue] [issue1292] repr() of type created in non-module code
	varies from	CPython
In-Reply-To: <1350512460.82.0.614785304877.issue1292@bugs.pypy.org>
Message-ID: <1351089510.02.0.247631533399.issue1292@bugs.pypy.org>


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

Found no regression test that crashes because of this change, so closing the
report.  Feel free to reopen if an issue shows up later.

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

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

From tracker at bugs.pypy.org  Wed Oct 24 16:51:29 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 24 Oct 2012 14:51:29 +0000
Subject: [pypy-issue] [issue1299] BZ2Decompressor.decompress('') does not
	raise EOFError at	end-of-stream
In-Reply-To: <1350835093.79.0.154298635484.issue1299@bugs.pypy.org>
Message-ID: <1351090289.4.0.249553486024.issue1299@bugs.pypy.org>


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

You can indeed try to push the test to CPython's repository.  For now writing a
test in pypy's own test suite is enough.  Added this test together with your
patch in 469ecc21fa11. Thanks!

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

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

From tracker at bugs.pypy.org  Wed Oct 24 17:23:27 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 24 Oct 2012 15:23:27 +0000
Subject: [pypy-issue] [issue1253] compile => RuntimeError: maximum recursion
	depth exceeded
In-Reply-To: <1347011043.22.0.852237039186.issue1253@bugs.pypy.org>
Message-ID: <1351092207.34.0.0913380588963.issue1253@bugs.pypy.org>


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

Closing then

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

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

From tracker at bugs.pypy.org  Wed Oct 24 19:17:05 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 24 Oct 2012 17:17:05 +0000
Subject: [pypy-issue] [issue1240] PyPy's evaluation of generator on
	list.extend() method	seems different from CPython
In-Reply-To: <1345466398.44.0.295959271189.issue1240@bugs.pypy.org>
Message-ID: <1351099025.36.0.78866912634.issue1240@bugs.pypy.org>


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

Closing as wontfix. You should not rely on such details

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

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

From tracker at bugs.pypy.org  Wed Oct 24 19:18:23 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 24 Oct 2012 17:18:23 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1351099103.64.0.240815986609.issue1145@bugs.pypy.org>


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

lazy evaluation got removed for now. Closing. If we ever reintroduce it (very 
likely), I'll make sure that does not happen again.

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

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

From tracker at bugs.pypy.org  Wed Oct 24 19:23:57 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 24 Oct 2012 17:23:57 +0000
Subject: [pypy-issue] [issue1215] /pypy/config/support.py missing close()
In-Reply-To: <1342092121.65.0.768763903265.issue1215@bugs.pypy.org>
Message-ID: <1351099437.04.0.541539965236.issue1215@bugs.pypy.org>


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

This is really not an issue. This file is not open for writing and it's only one. 
It's very unlikely this will cause fd leaks or something (the default mechanism 
seems to be good enough for *this* particular issue)

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

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

From tracker at bugs.pypy.org  Wed Oct 24 21:38:10 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 24 Oct 2012 19:38:10 +0000
Subject: [pypy-issue] [issue1301] virtualize copystrcontent
In-Reply-To: <1351107490.91.0.0875111291136.issue1301@bugs.pypy.org>
Message-ID: <1351107490.91.0.0875111291136.issue1301@bugs.pypy.org>


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

this is an example of non-virtualized copystrcontent: (note p408 is not used 
anywhere else) http://paste.pound-python.org/show/27092/

----------
messages: 4904
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: virtualize copystrcontent

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

From tracker at bugs.pypy.org  Thu Oct 25 02:54:49 2012
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Thu, 25 Oct 2012 00:54:49 +0000
Subject: [pypy-issue] [issue1240] PyPy's evaluation of generator on
	list.extend() method	seems different from CPython
In-Reply-To: <1345466398.44.0.295959271189.issue1240@bugs.pypy.org>
Message-ID: <1351126489.06.0.906744231981.issue1240@bugs.pypy.org>


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

Indeed an implementation detail, though I'll note that the length-hint branch will 
fix this to work like CPython

----------
nosy: +pjenvey

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

From tracker at bugs.pypy.org  Thu Oct 25 03:46:52 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 25 Oct 2012 01:46:52 +0000
Subject: [pypy-issue] [issue1301] virtualize copystrcontent
In-Reply-To: <1351107490.91.0.0875111291136.issue1301@bugs.pypy.org>
Message-ID: <1351129612.39.0.360948569049.issue1301@bugs.pypy.org>


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

fixed in 15b5a4bb248a

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

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

From tracker at bugs.pypy.org  Thu Oct 25 06:34:36 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 25 Oct 2012 04:34:36 +0000
Subject: [pypy-issue] [issue1302] numpypy arange difference from numpy
In-Reply-To: <1351139676.76.0.708328504456.issue1302@bugs.pypy.org>
Message-ID: <1351139676.76.0.708328504456.issue1302@bugs.pypy.org>


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

I was looking at the equivalent python benchmark for the julia language: 
https://raw.github.com/JuliaLang/julia/master/test/perf/perf.py 

The mandelperf() benchmark (runnable snippet attached) returns slightly different 
results, because, ultimately, there's a slight difference in the "almost 0" values 
returned by numpy.arange()  i.e. 6.38378239e-16 != 1.77635684e-15

Should we expect these "almost zero" values to be the same?  

-------------------------------
pypy (latest nightly)
-------------------------------
>>>> numpy.arange(-2, 0.5, 0.1, dtype='f8')
array([ -2.00000000e+00,  -1.90000000e+00,  -1.80000000e+00,
        -1.70000000e+00,  -1.60000000e+00,  -1.50000000e+00,
        -1.40000000e+00,  -1.30000000e+00,  -1.20000000e+00,
        -1.10000000e+00,  -1.00000000e+00,  -9.00000000e-01,
        -8.00000000e-01,  -7.00000000e-01,  -6.00000000e-01,
        -5.00000000e-01,  -4.00000000e-01,  -3.00000000e-01,
        -2.00000000e-01,  -1.00000000e-01,   6.38378239e-16,
         1.00000000e-01,   2.00000000e-01,   3.00000000e-01,
         4.00000000e-01])


numpy v1.6
-------------------------------
>>> numpy.arange(-2, 0.5, 0.1, dtype='f8')
array([ -2.00000000e+00,  -1.90000000e+00,  -1.80000000e+00,
        -1.70000000e+00,  -1.60000000e+00,  -1.50000000e+00,
        -1.40000000e+00,  -1.30000000e+00,  -1.20000000e+00,
        -1.10000000e+00,  -1.00000000e+00,  -9.00000000e-01,
        -8.00000000e-01,  -7.00000000e-01,  -6.00000000e-01,
        -5.00000000e-01,  -4.00000000e-01,  -3.00000000e-01,
        -2.00000000e-01,  -1.00000000e-01,   1.77635684e-15,
         1.00000000e-01,   2.00000000e-01,   3.00000000e-01,
         4.00000000e-01])

----------
files: mandelperf.py
messages: 4907
nosy: mikefc, pypy-issue
priority: bug
status: unread
title: numpypy arange difference from numpy

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

From tracker at bugs.pypy.org  Thu Oct 25 07:27:15 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 25 Oct 2012 05:27:15 +0000
Subject: [pypy-issue] [issue915] implement numpy.linalg in micronumpy
In-Reply-To: <1318948298.71.0.561740137124.issue915@bugs.pypy.org>
Message-ID: <1351142835.55.0.61791198904.issue915@bugs.pypy.org>


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

numpy includes its own lite C version of lapack/blas (and fftpack).

Anyone have any thoughts on how best to wrap this C code for numpypy?  cffi?

----------
nosy: +mattip, mikefc

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

From tracker at bugs.pypy.org  Thu Oct 25 14:28:37 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 25 Oct 2012 12:28:37 +0000
Subject: [pypy-issue] [issue1302] numpypy arange difference from numpy
In-Reply-To: <1351139676.76.0.708328504456.issue1302@bugs.pypy.org>
Message-ID: <1351168117.31.0.721558365957.issue1302@bugs.pypy.org>


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

If you care about details, you should use numpy.linspace or others that have a 
well defined behavior. arange is intentionally not very well defined. Closing as 
wontfix (although "implement linspace" sounds like a good issue, except a 
different one)

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

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

From fijall at gmail.com  Thu Oct 25 15:00:08 2012
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 25 Oct 2012 15:00:08 +0200
Subject: [pypy-issue] [issue915] implement numpy.linalg in micronumpy
In-Reply-To: <1351142835.55.0.61791198904.issue915@bugs.pypy.org>
References: <1318948298.71.0.561740137124.issue915@bugs.pypy.org>
	<1351142835.55.0.61791198904.issue915@bugs.pypy.org>
Message-ID: <CAK5idxRXySU6Nr-ai5ZFBrkn0O+2e7i-pP7orkCvsjXzOWVuag@mail.gmail.com>

On Thu, Oct 25, 2012 at 7:27 AM, mikefc <tracker at bugs.pypy.org> wrote:
>
> mikefc <coolbutuseless at gmail.com> added the comment:
>
> numpy includes its own lite C version of lapack/blas (and fftpack).
>
> Anyone have any thoughts on how best to wrap this C code for numpypy?  cffi?

yes, cffi

From tracker at bugs.pypy.org  Fri Oct 26 17:35:21 2012
From: tracker at bugs.pypy.org (Paul)
Date: Fri, 26 Oct 2012 15:35:21 +0000
Subject: [pypy-issue] [issue1303] fatal error in cpyext
In-Reply-To: <1351265721.48.0.8808185022.issue1303@bugs.pypy.org>
Message-ID: <1351265721.48.0.8808185022.issue1303@bugs.pypy.org>


New submission from Paul <poalman at gmail.com>:

Hey, I'm really new to pypy and got this exception, I don't know how useful just 
this traceback is- I can provide more information if needed

Fatal error in cpyext, CPython compatibility layer, calling PyEval_SaveThread
Either report a bug or consider not using this particular extension
<SystemError object at 0x19e0328>
RPython traceback:
  File "module_cpyext_api_3.c", line 46842, in PyEval_SaveThread
  File "module_cpyext_pystate.c", line 468, in PyEval_SaveThread
  File "module_cpyext_pyobject.c", line 4517, in 
RefcountState_swap_borrow_container
  File "rpython_lltypesystem_rdict.c", line 3539, in 
ll_dictnext__NoneConst_dictiterPtr

----------
messages: 4911
nosy: gp89, pypy-issue
priority: bug
release: 1.9
status: unread
title: fatal error in cpyext

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

From tracker at bugs.pypy.org  Fri Oct 26 18:35:05 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 26 Oct 2012 16:35:05 +0000
Subject: [pypy-issue] [issue1303] fatal error in cpyext
In-Reply-To: <1351265721.48.0.8808185022.issue1303@bugs.pypy.org>
Message-ID: <1351269305.0.0.417861720212.issue1303@bugs.pypy.org>


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

This function was modified recently.  Which version of pypy are you running? 
Could you try a recent version (try downloading a nightly build)

Otherwise, it would be useful to know which extension module is used.

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

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

From tracker at bugs.pypy.org  Fri Oct 26 18:54:56 2012
From: tracker at bugs.pypy.org (Paul)
Date: Fri, 26 Oct 2012 16:54:56 +0000
Subject: [pypy-issue] [issue1303] fatal error in cpyext
In-Reply-To: <1351265721.48.0.8808185022.issue1303@bugs.pypy.org>
Message-ID: <1351270496.08.0.162531045787.issue1303@bugs.pypy.org>


Paul <poalman at gmail.com> added the comment:

I'm running PyPy 1.9.0

I'll try using a more recent version.

How can I tell which extension module caused the error (it was mainly running 
Twisted and PIL)

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

From tracker at bugs.pypy.org  Fri Oct 26 20:15:02 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 26 Oct 2012 18:15:02 +0000
Subject: [pypy-issue] [issue1303] fatal error in cpyext
In-Reply-To: <1351265721.48.0.8808185022.issue1303@bugs.pypy.org>
Message-ID: <1351275302.8.0.97557536039.issue1303@bugs.pypy.org>


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

The easiest way is to attach a debugger, and look at the C stack. The extension 
module name should be 4 or 5 frames below.

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

From tracker at bugs.pypy.org  Sun Oct 28 15:26:02 2012
From: tracker at bugs.pypy.org (Nadeem Vawda)
Date: Sun, 28 Oct 2012 14:26:02 +0000
Subject: [pypy-issue] [issue1299] BZ2Decompressor.decompress('') does not
	raise EOFError at	end-of-stream
In-Reply-To: <1350835093.79.0.154298635484.issue1299@bugs.pypy.org>
Message-ID: <1351434362.91.0.694946733197.issue1299@bugs.pypy.org>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Cool. I've cross-ported the test to CPython in changesets e57e9fb3843b,
2e52536a91a3, 0a33422fb0d9 and 3bc1784be9aa.

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

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

From tracker at bugs.pypy.org  Mon Oct 29 11:28:17 2012
From: tracker at bugs.pypy.org (dktc)
Date: Mon, 29 Oct 2012 10:28:17 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>


New submission from dktc <dkruglyak at gmail.com>:

I am trying to migrate a performance-critical Django application to PyPy and running into some weird crashes. After some 
effort I was able to isolate the issues to something easy to reproduce from Django command line.

PyPy was translated on my own CentOS 5.8 system. I've confirmed via command line that MySQLdb works fine and this looks 
like a Django ORM problem. I have no idea how to debug this further. Any thoughts / recommendations?

(pypy-1.9)[root at localhost]# python /home/myapp/manage.py shell --settings=myapp
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Oct 27 2012, 02:45:53)
[PyPy 1.9.0 with GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.contrib.auth.models import User
>>> u = User.objects.get(id=1)
Fatal error in cpyext, CPython compatibility layer, calling PyTuple_SetItem
Either report a bug or consider not using this particular extension
<OpErrFmt object at 0x2ada72c1f288>
RPython traceback:
  File "module_cpyext_api_1.c", line 39377, in PyTuple_SetItem
  File "module_cpyext_pyobject.c", line 1071, in BaseCpyTypedescr_realize
  File "objspace_std_objspace.c", line 3394, in allocate_instance__W_ObjectObject
  File "objspace_std_typeobject.c", line 2977, in W_TypeObject_check_user_subclass
Segmentation fault

----------
messages: 4916
nosy: dktc, pypy-issue
priority: critical
release: 1.9
status: unread
title: Django 1.4.2 ORM segfaults with PyPy 1.9

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

From tracker at bugs.pypy.org  Mon Oct 29 11:54:26 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Mon, 29 Oct 2012 10:54:26 +0000
Subject: [pypy-issue] [issue1305] [CFFI] Clarify ownership of nested structs
In-Reply-To: <1351508066.04.0.643677098131.issue1305@bugs.pypy.org>
Message-ID: <1351508066.04.0.643677098131.issue1305@bugs.pypy.org>


New submission from Gabriel <g2p.code+pypy at gmail.com>:

When a struct contains nested structs (not through pointers, embedded directly
inside), it appears that references to the inner struct can become invalid,
probably because they depend on the outer struct but don't prevent it from being
garbage collected.

Here is a test case; smaller test cases don't seem to trigger the memory error:
https://travis-ci.org/g2p/bedup/builds/2972522

----------
messages: 4917
nosy: pypy-issue
priority: critical
status: unread
title: [CFFI] Clarify ownership of nested structs

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

From tracker at bugs.pypy.org  Mon Oct 29 14:09:36 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 29 Oct 2012 13:09:36 +0000
Subject: [pypy-issue] [issue1306] ll_listeq(x,
	x) should be constant folded in the JIT
In-Reply-To: <1351516176.74.0.837408220941.issue1306@bugs.pypy.org>
Message-ID: <1351516176.74.0.837408220941.issue1306@bugs.pypy.org>


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

so I don't forget

----------
messages: 4918
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: ll_listeq(x, x) should be constant folded in the JIT

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

From tracker at bugs.pypy.org  Mon Oct 29 14:11:37 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 29 Oct 2012 13:11:37 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351516297.01.0.406648946215.issue1304@bugs.pypy.org>


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

Can you try newer PyPy, like a nightly from buildbot.pypy.org/nightly/trunk ?

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

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

From tracker at bugs.pypy.org  Mon Oct 29 15:11:22 2012
From: tracker at bugs.pypy.org (Allen Short)
Date: Mon, 29 Oct 2012 14:11:22 +0000
Subject: [pypy-issue] [issue1307] pyprof2calltree depends on CPython
	internals not provided	by PyPy
In-Reply-To: <1351519882.58.0.574183751488.issue1307@bugs.pypy.org>
Message-ID: <1351519882.58.0.574183751488.issue1307@bugs.pypy.org>


New submission from Allen Short <washort42 at gmail.com>:

There's a few failure modes to this.

Code to reproduce:

import cProfile
import pyprof2calltree

p = cProfile.Profile()
p.runctx("1 + 1", globals(), globals())
pyprof2calltree.convert(p, "foo.kgrind")

Error:


Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "eparse.py", line 15, in <module>
    pyprof2calltree.convert(pf, "foo.kgrind")
  File "/home/washort/pypy-1.9/site-packages/pyprof2calltree.py", line 274, in
convert
    converter.output(f)
  File "/home/washort/pypy-1.9/site-packages/pyprof2calltree.py", line 104, in
output
    self._print_summary()
  File "/home/washort/pypy-1.9/site-packages/pyprof2calltree.py", line 133, in
_print_summary
    for entry in self.entries:
TypeError: 'Profile' object is not iterable


Using 'profile' instead of 'cProfile' gives "Iteration over non-sequence".

----------
messages: 4920
nosy: pypy-issue, washort
priority: bug
status: chatting
title: pyprof2calltree depends on CPython internals not provided by PyPy

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

From tracker at bugs.pypy.org  Mon Oct 29 17:28:15 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Mon, 29 Oct 2012 16:28:15 +0000
Subject: [pypy-issue] [issue1305] [CFFI] Clarify ownership of nested structs
In-Reply-To: <1351508066.04.0.643677098131.issue1305@bugs.pypy.org>
Message-ID: <1351528095.89.0.954379990869.issue1305@bugs.pypy.org>


Gabriel <g2p.code+pypy at gmail.com> added the comment:

Here's a better test.

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

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

From tracker at bugs.pypy.org  Mon Oct 29 19:27:13 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Mon, 29 Oct 2012 18:27:13 +0000
Subject: [pypy-issue] [issue1308] [CFFI] compatibility fixes
In-Reply-To: <1351535233.14.0.582663753967.issue1308@bugs.pypy.org>
Message-ID: <1351535233.14.0.582663753967.issue1308@bugs.pypy.org>


New submission from Gabriel <g2p.code+pypy at gmail.com>:

Adds PY3 cases for the buffer interface, and incomplete FILE* functionality.

----------
files: mbox
messages: 4922
nosy: pypy-issue
priority: bug
status: unread
title: [CFFI] compatibility fixes

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

From tracker at bugs.pypy.org  Mon Oct 29 19:46:25 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 29 Oct 2012 18:46:25 +0000
Subject: [pypy-issue] [issue1305] [CFFI] Clarify ownership of nested structs
In-Reply-To: <1351508066.04.0.643677098131.issue1305@bugs.pypy.org>
Message-ID: <1351536385.18.0.181810335974.issue1305@bugs.pypy.org>


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

This is expected and documented.  I'm closing it as invalid; if you want to
discuss it more (e.g. argue for this), please do so in
https://bitbucket.org/cffi/cffi/issues .

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

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

From tracker at bugs.pypy.org  Mon Oct 29 20:01:34 2012
From: tracker at bugs.pypy.org (dktc)
Date: Mon, 29 Oct 2012 19:01:34 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351537294.66.0.340893831174.issue1304@bugs.pypy.org>


dktc <dkruglyak at gmail.com> added the comment:

I could but it would take hours to build it and in any case I'd like to get some idea of how to best debug these 
RPython tracebacks. There is not much to go on in this output.

Could you test this out too? This test case has been reduced to what is available in stock Django.

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

From tracker at bugs.pypy.org  Mon Oct 29 21:10:43 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 29 Oct 2012 20:10:43 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351541443.99.0.88921678902.issue1304@bugs.pypy.org>


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

The nightlies I linked to are binaries. For older linuxes you have some here: 
http://baroquesoftware.com/nightlies/

The crash is in CPyExt, the CPython API compatibility wrapper. There has been 
many improvements since the 1.9 release. Sure, I'll try it out (and I'm sorry 
2.0 is not out yet)

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

From tracker at bugs.pypy.org  Mon Oct 29 21:15:32 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 29 Oct 2012 20:15:32 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351541732.29.0.692570391407.issue1304@bugs.pypy.org>


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

Ah and btw - assuming everyone knows how to install and configure a django app is 
a bit of a stretch. I have no idea what to install or how to do it (a link to 
documentation to follow is fine)

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

From tracker at bugs.pypy.org  Mon Oct 29 21:17:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 29 Oct 2012 20:17:00 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351541820.88.0.102405318606.issue1304@bugs.pypy.org>


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

Also, one more crucial thing - if you're using cpyext, there are high chances 
your application will be slower under PyPy than under CPython. Consider using 
some other DB bindings (like pg8000 or something ctypes-based).

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

From tracker at bugs.pypy.org  Mon Oct 29 21:24:01 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 29 Oct 2012 20:24:01 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351542241.3.0.12927799921.issue1304@bugs.pypy.org>


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

Ok, reproduced on trunk indeed.

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

From tracker at bugs.pypy.org  Mon Oct 29 22:21:41 2012
From: tracker at bugs.pypy.org (dktc)
Date: Mon, 29 Oct 2012 21:21:41 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351545701.21.0.612158332397.issue1304@bugs.pypy.org>


dktc <dkruglyak at gmail.com> added the comment:

Thanks for validating this error. Does it look reasonably easily fixable?

So if this is a problem in cpyext could it be fixed by just replacing a DB driver? I really have no idea 
whether any other MySQL drivers for Django are available. Would be great to just fix the issue "as is", 
our application bottleneck is not DB access, but Python code that generates large data structures.

Thanks for the source link. Just to be sure, is it the same as "default" branch from here 
(https://bitbucket.org/pypy/pypy/downloads)? What are the other branches?

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

From tracker at bugs.pypy.org  Mon Oct 29 22:42:33 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 29 Oct 2012 21:42:33 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351546953.5.0.112998287726.issue1304@bugs.pypy.org>


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

There is a patch for Mysql in the cpyext directory: 
https://bitbucket.org/pypy/pypy/src/default/pypy/module/cpyext/patches/mysqldb.pa
tch

Can you try to apply it, rebuild the extension and try again?

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

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

From tracker at bugs.pypy.org  Mon Oct 29 22:49:08 2012
From: tracker at bugs.pypy.org (dktc)
Date: Mon, 29 Oct 2012 21:49:08 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351547348.44.0.0193412971502.issue1304@bugs.pypy.org>


dktc <dkruglyak at gmail.com> added the comment:

So is this strictly a MySQLdb module issue? Would applying this patch work for both 1.9 and trunk?

If so this should probably be documented in a somewhat more prominent place.

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

From tracker at bugs.pypy.org  Mon Oct 29 22:55:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 29 Oct 2012 21:55:00 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351547700.65.0.830604142501.issue1304@bugs.pypy.org>


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

I'm sure it's mentioned somewhere. For the record - which places you looked at 
and you expected to find it there?

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

From tracker at bugs.pypy.org  Tue Oct 30 10:38:28 2012
From: tracker at bugs.pypy.org (dktc)
Date: Tue, 30 Oct 2012 09:38:28 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351589907.45.0.468265176107.issue1304@bugs.pypy.org>


dktc <dkruglyak at gmail.com> added the comment:

OK, I applied the patch and this fixed the problem on 1.9

I am new to PyPy and on initial pass simply went through the install docs (for translation) and the compatibility page. 
Nowhere did I see the note that Django would fail without this patch.
https://bitbucket.org/pypy/compatibility/wiki/Home#!db-adaptors

So definitely it would be helpful to make the need for this patch clear everywhere in the docs, especially compatibility 
pages for Django and MySQLdb

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

From fijall at gmail.com  Tue Oct 30 10:39:13 2012
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 30 Oct 2012 11:39:13 +0200
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy
	1.9
In-Reply-To: <1351589907.45.0.468265176107.issue1304@bugs.pypy.org>
References: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
	<1351589907.45.0.468265176107.issue1304@bugs.pypy.org>
Message-ID: <CAK5idxSYmUkk4j_MpxTqAZru9ifJ1vhuH9Qb4g3j7TydLSuNAw@mail.gmail.com>

On Tue, Oct 30, 2012 at 11:38 AM, dktc <tracker at bugs.pypy.org> wrote:
>
> dktc <dkruglyak at gmail.com> added the comment:
>
> OK, I applied the patch and this fixed the problem on 1.9
>
> I am new to PyPy and on initial pass simply went through the install docs (for translation) and the compatibility page.
> Nowhere did I see the note that Django would fail without this patch.
> https://bitbucket.org/pypy/compatibility/wiki/Home#!db-adaptors
>
> So definitely it would be helpful to make the need for this patch clear everywhere in the docs, especially compatibility
> pages for Django and MySQLdb

Good point. Feel like submitting a patch for the docs? (wiki is
publically editable I think, if not issue a pull request)

From tracker at bugs.pypy.org  Tue Oct 30 15:22:44 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 30 Oct 2012 14:22:44 +0000
Subject: [pypy-issue] [issue1307] pyprof2calltree depends on CPython
	internals not provided	by PyPy
In-Reply-To: <1351519882.58.0.574183751488.issue1307@bugs.pypy.org>
Message-ID: <1351606964.75.0.690664145549.issue1307@bugs.pypy.org>


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

Running the same code over Python 2.7.3 fails in the same way for me...

So far it looks like a bug in pyprof2calltree.py, at least the version that
comes with "pip install pyprof2calltree".

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

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

From tracker at bugs.pypy.org  Tue Oct 30 15:31:01 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 30 Oct 2012 14:31:01 +0000
Subject: [pypy-issue] [issue1297] performance regression from 1.7 to 1.8/1.9
In-Reply-To: <1350601260.38.0.876674225282.issue1297@bugs.pypy.org>
Message-ID: <1351607461.53.0.2124775856.issue1297@bugs.pypy.org>


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

I fixed some time ago an issue that is probably related to that.  PyPy trunk is
very fast again.  Please check the original program on PyPy trunk too.

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

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

From tracker at bugs.pypy.org  Tue Oct 30 16:27:39 2012
From: tracker at bugs.pypy.org (Allen Short)
Date: Tue, 30 Oct 2012 15:27:39 +0000
Subject: [pypy-issue] [issue1307] pyprof2calltree depends on CPython
	internals not provided	by PyPy
In-Reply-To: <1351519882.58.0.574183751488.issue1307@bugs.pypy.org>
Message-ID: <1351610859.6.0.698899296173.issue1307@bugs.pypy.org>


Allen Short <washort42 at gmail.com> added the comment:

Haha, OK. I foolishly believed that it had been kept up to date. :) Sorry for
the noise.

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

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

From tracker at bugs.pypy.org  Wed Oct 31 04:35:34 2012
From: tracker at bugs.pypy.org (dktc)
Date: Wed, 31 Oct 2012 03:35:34 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351654534.41.0.221510034186.issue1304@bugs.pypy.org>


dktc <dkruglyak at gmail.com> added the comment:

Removed the last message - please do not share plain-text email addresses publicly...

> Good point. Feel like submitting a patch for the docs? (wiki is
> publically editable I think, if not issue a pull request)

Which wiki do you suggest for editing and how? In any case I am not sure it needs a full-blown patch from me. 
Whoever is maintaining wiki(s) could just add one line about this issue and mysqldb.patch ...

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

From tracker at bugs.pypy.org  Wed Oct 31 14:27:24 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 31 Oct 2012 13:27:24 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351690044.52.0.138662505179.issue1304@bugs.pypy.org>


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

it says so if you click on the mysqldb link. is it not good enough? then why we 
have links in the first place?

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

From tracker at bugs.pypy.org  Wed Oct 31 15:11:21 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 31 Oct 2012 14:11:21 +0000
Subject: [pypy-issue] [issue1138] in numpypy,
	strings fundamentally don't work
In-Reply-To: <1335567444.04.0.107953871149.issue1138@bugs.pypy.org>
Message-ID: <1351692681.13.0.99543174971.issue1138@bugs.pypy.org>


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

This is no longer true as it stands. You can use those strings as strings. If 
you're missing some details, please report.

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

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

From tracker at bugs.pypy.org  Wed Oct 31 15:11:56 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 31 Oct 2012 14:11:56 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351692716.54.0.852635398431.issue1304@bugs.pypy.org>


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

Added a comment there. Closing this issue.

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

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

From tracker at bugs.pypy.org  Wed Oct 31 21:26:55 2012
From: tracker at bugs.pypy.org (dktc)
Date: Wed, 31 Oct 2012 20:26:55 +0000
Subject: [pypy-issue] [issue1304] Django 1.4.2 ORM segfaults with PyPy 1.9
In-Reply-To: <1351506497.19.0.460720605361.issue1304@bugs.pypy.org>
Message-ID: <1351715215.82.0.103879818548.issue1304@bugs.pypy.org>


dktc <dkruglyak+pypy at gmail.com> added the comment:

Sorry, my bad. I think I missed the note in MySQLdb section because I was only looking at Django.

Perhaps it would be good to have a section "Packages That Require Patching" at the top of the compatibility page. 
Right now (from searching for the word "patch") only looks like MySQLdb requires it but I suppose this issue should 
come up with other packages at some point.

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

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

From tracker at bugs.pypy.org  Wed Oct 31 22:18:44 2012
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Wed, 31 Oct 2012 21:18:44 +0000
Subject: [pypy-issue] [issue1309] rbigint support for from/tobytes
In-Reply-To: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>
Message-ID: <1351718324.47.0.13116180349.issue1309@bugs.pypy.org>


New submission from Kenny Levinsen <kennylevinsen at gmail.com>:

rbigint lacks from/to byte methods, which are needed for W_LongObject to provide 
from_bytes/to_bytes functionality needed in the py3k branch.

The py3k branch currently implements a buggy frombytes method that does not 
support endian_swap or handling of signed input.

----------
assignedto: joushou
messages: 4943
nosy: joushou, pypy-issue
priority: feature
release: ???
status: in-progress
title: rbigint support for from/tobytes

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