From tracker at bugs.pypy.org  Sun Apr  1 08:42:53 2012
From: tracker at bugs.pypy.org (papaeye)
Date: Sun, 01 Apr 2012 06:42:53 +0000
Subject: [pypy-issue] [issue1101] Can't use unicode string as key in
	__dict__ attribute
In-Reply-To: <1333181922.06.0.897522719468.issue1101@bugs.pypy.org>
Message-ID: <1333262573.38.0.923845879547.issue1101@bugs.pypy.org>


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

Nightly build works.
Thank you for the quick fix.

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

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

From tracker at bugs.pypy.org  Sun Apr  1 17:44:09 2012
From: tracker at bugs.pypy.org (Danilo Araujo de Freitas)
Date: Sun, 01 Apr 2012 15:44:09 +0000
Subject: [pypy-issue] [issue1100] Dict iterators can return deleted entries
In-Reply-To: <1332768538.31.0.460128219214.issue1100@bugs.pypy.org>
Message-ID: <1333295049.29.0.955944774592.issue1100@bugs.pypy.org>


Danilo Araujo de Freitas <dsurviver at gmail.com> added the comment:

I'm trying to fix it, but my patch is still not good enough:

--- a/pypy/objspace/std/dictmultiobject.py      Thu Mar 29 11:31:34 2012 -0400
+++ b/pypy/objspace/std/dictmultiobject.py      Sun Apr 01 12:31:37 2012 -0300
@@ -277,13 +277,13 @@
             raise OperationError(self.space.w_RuntimeError,
                      self.space.wrap("dictionary changed size during 
iteration"))
         # look for the next entry
-        if self.pos < self.len:
-            result = self.next_entry()
-            self.pos += 1
-            return result
+        #if self.pos < self.len:
+        result = self.next_entry()
+        self.pos += 1
+        return result
         # no more entries
-        self.dictimplementation = None
-        return None, None
+        #self.dictimplementation = None
+        #return None, None
 
     def next_entry(self):
         """ Purely abstract method
@@ -491,11 +491,20 @@
     def __init__(self, space, strategy, dictimplementation):
         IteratorImplementation.__init__(self, space, dictimplementation)
         self.iterator = 
strategy.unerase(dictimplementation.dstorage).iteritems()
+        self.strategy = strategy
 
     def next_entry(self):
+        if self.strategy != self.dictimplementation.strategy:
+            self.strategy = self.dictimplementation.strategy
+            storage = self.strategy.unerase(self.dictimplementation.dstorage)
+            iterator = storage.iteritems()
+            self.iterator = iterator
         # note that this 'for' loop only runs once, at most
         for key, w_value in self.iterator:
-            return self.space.wrap(key), w_value
+            try:
+                return self.space.wrap(key), w_value
+            except TypeError:
+                return key, w_value
         else:
             return None, None
 
diff -r 285ff15e1498 pypy/objspace/std/test/test_dictmultiobject.py
--- a/pypy/objspace/std/test/test_dictmultiobject.py    Thu Mar 29 11:31:34 2012 
-0400
+++ b/pypy/objspace/std/test/test_dictmultiobject.py    Sun Apr 01 12:31:37 2012 
-0300
@@ -1006,6 +1006,65 @@
         assert items == zip([self.string, self.string2], [1000, 2000])
         self.check_not_devolved()
 
+    def test_iter_dict_change(self):
+        d = {1: 2, 3: 4, 5: 6}
+        it = d.iteritems()
+        items = []
+        items.append(it.next())
+        items.append(it.next())
+        d['foo'] = 'bar'
+        del d[1]
+        items.append(it.next())
+        items.append(it.next())
+        assert set(items) == set([(1, 2), (3, 4), (5, 6), ('foo', 'bar')])
+        
+        items = []
+        d = {1: 1, 2: 2, 3: 3}
+        it = d.iteritems()
+        items.append(it.next())
+        d[4] = 4
+        del d[1]
+        items.append(it.next())
+        items.append(it.next())
+        items.append(it.next())
+        assert set(items) == set([(1, 1), (2, 2), (3, 3), (4, 4)])
+        
+        items = []
+        d = {1: 1, 2: 2, 3: 3}
+        it = d.iteritems()
+        d['foo'] = 'bar'
+        del d[2]
+        d['bar'] = 'foo'
+        del d[3]
+        items.append(it.next())
+        items.append(it.next())
+        items.append(it.next())
+        assert set(items) == set([(1, 1), ('bar', 'foo'), ('foo', 'bar')])
+
+        items = []
+        d = {'foo': 'bar', 'bar': 'foo'}
+        it = d.iteritems()
+        del d['foo']
+        d[1] = 2
+        items.append(it.next())
+        items.append(it.next())
+        assert set(items) == set([(1, 2), ('bar', 'foo')])
+        
+        items = []
+        d = {1: 1, 2: 2, 3: 3, 4: 4}
+        it = d.iteritems()
+        d['foo'] = 'bar'
+        del d[2]
+        items.append(it.next())
+        items.append(it.next())
+        d['bar'] = 'foo'
+        del d[3]
+        items.append(it.next())
+        items.append(it.next())
+        items.append(it.next())
+        assert set(items) == set([(1, 1), (3, 3), (4, 4), ('bar', 'foo'), 
('foo', 'bar')])
+        
+        
     def test_devolve(self):
         impl = self.impl
         for x in xrange(100):
diff -r 285ff15e1498 pypy/rlib/objectmodel.py
--- a/pypy/rlib/objectmodel.py  Thu Mar 29 11:31:34 2012 -0400
+++ b/pypy/rlib/objectmodel.py  Sun Apr 01 12:31:37 2012 -0300
@@ -590,7 +590,7 @@
         return self._dict.itervalues()
 
     def iteritems(self):
-        for dk, value in self._dict.items():
+        for dk, value in self._dict.iteritems():
             yield dk.key, value
 
     def clear(self):

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

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

From tracker at bugs.pypy.org  Sun Apr  1 18:05:00 2012
From: tracker at bugs.pypy.org (Danilo Araujo de Freitas)
Date: Sun, 01 Apr 2012 16:05:00 +0000
Subject: [pypy-issue] [issue1100] Dict iterators can return deleted entries
In-Reply-To: <1332768538.31.0.460128219214.issue1100@bugs.pypy.org>
Message-ID: <1333296300.18.0.387023404413.issue1100@bugs.pypy.org>


Danilo Araujo de Freitas <dsurviver at gmail.com> added the comment:

I'm trying to fix it, but my patch is still not good enough: 
http://paste.pocoo.org/show/574527/

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

From tracker at bugs.pypy.org  Sun Apr  1 18:57:20 2012
From: tracker at bugs.pypy.org (Richard Barrell)
Date: Sun, 01 Apr 2012 16:57:20 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>


New submission from Richard Barrell <rchrd at brrll.co.uk>:

I'm using the Linux 64-bit binary PyPy 1.8 from here: 
https://bitbucket.org/pypy/pypy/downloads/pypy-
1.8-linux64.tar.bz2
and Python 2.6.5 from the repositories on Ubuntu 10.04. The machine that I'm 
running on is a Core 2 Duo 
laptop with 4GB of RAM, running at 2.10GHz.

The program (workhorse.py) is attached. 

With CPython 2.6.5:

richyb at figgy:~$ time python workhorse.py 
start
end
5.36431598663

real    0m5.386s
user    0m5.350s
sys     0m0.020s

with PyPy 1.8:


richyb at figgy:~$ time pypy workhorse.py 
start
end
9.53850102425

real    0m9.597s
user    0m9.480s
sys     0m0.080s

----------
files: workhorse.py
messages: 4155
nosy: RichyB, pypy-issue
priority: performance bug
status: unread
title: This program takes longer to run under pypy-1.8 than under CPython 2.6.5

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

From tracker at bugs.pypy.org  Sun Apr  1 19:06:13 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sun, 01 Apr 2012 17:06:13 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333299973.95.0.859045951078.issue1102@bugs.pypy.org>


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

try nightly, its completed 3 times faster than cpython for me

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

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

From tracker at bugs.pypy.org  Sun Apr  1 19:14:07 2012
From: tracker at bugs.pypy.org (Richard Barrell)
Date: Sun, 01 Apr 2012 17:14:07 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333300447.11.0.823046017412.issue1102@bugs.pypy.org>


Richard Barrell <rchrd at brrll.co.uk> added the comment:

Differing machines/architectures perhaps? I've got:

richyb at figgy:~/Downloads/pypy-c-jit-54107-5b9f7aa356a0-linux64$ time bin/pypy 
~/workhorse.py 
start
end
9.39560317993

real    0m9.447s
user    0m9.270s
sys     0m0.130s

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

From tracker at bugs.pypy.org  Sun Apr  1 19:25:02 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 01 Apr 2012 17:25:02 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333301102.32.0.588034278407.issue1102@bugs.pypy.org>


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

Yeah, I would blame the architecture. On my z390, pypy is 10x slower.

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

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

From tracker at bugs.pypy.org  Sun Apr  1 19:32:56 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sun, 01 Apr 2012 17:32:56 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333301576.51.0.729963968342.issue1102@bugs.pypy.org>


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

interesting discovery, the fast run seems to be a one in many as it seems

i have no idea why it ran in 1.9 seconds before,
now it runs in 9.3 as well, i'm rather puzzled

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

From tracker at bugs.pypy.org  Sun Apr  1 19:47:32 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sun, 01 Apr 2012 17:47:32 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333302452.3.0.838139515654.issue1102@bugs.pypy.org>


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

you hit a interesting special case in the jit, if you use 

time pypy-bin --jit threshold=7331337,function_threshold=7331337 /tmp/workhorse.py

it ends up being faster than cpython

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

From tracker at bugs.pypy.org  Sun Apr  1 23:04:34 2012
From: tracker at bugs.pypy.org (Federico)
Date: Sun, 01 Apr 2012 21:04:34 +0000
Subject: [pypy-issue] [issue1103] NumPyPy using broadcasting gives
	numerically incorrect	results
In-Reply-To: <1333314274.07.0.640158434268.issue1103@bugs.pypy.org>
Message-ID: <1333314274.07.0.640158434268.issue1103@bugs.pypy.org>


New submission from Federico <vaggi.federico at gmail.com>:

arc_distance_broadcast_numpy gives a different answer to arc_distance_list in
pypy but not in CPython

----------
files: numpy_arc_distance.py
messages: 4161
nosy: iFed, pypy-issue
priority: critical
status: unread
title: NumPyPy using broadcasting gives numerically incorrect results

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

From tracker at bugs.pypy.org  Sun Apr  1 23:47:27 2012
From: tracker at bugs.pypy.org (Danilo Araujo de Freitas)
Date: Sun, 01 Apr 2012 21:47:27 +0000
Subject: [pypy-issue] [issue1100] Dict iterators can return deleted entries
In-Reply-To: <1332768538.31.0.460128219214.issue1100@bugs.pypy.org>
Message-ID: <1333316847.42.0.835098644938.issue1100@bugs.pypy.org>


Danilo Araujo de Freitas <dsurviver at gmail.com> added the comment:

I made this patch, but I don't know why the test is not working (running the same 
test code works!) http://paste.pocoo.org/show/574719/

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

From tracker at bugs.pypy.org  Mon Apr  2 07:07:02 2012
From: tracker at bugs.pypy.org (reportmp)
Date: Mon, 02 Apr 2012 05:07:02 +0000
Subject: [pypy-issue] [issue1104] ssl._sslobj.peer_certificate broken in
	pypy 1.8
In-Reply-To: <1333343222.51.0.662902662295.issue1104@bugs.pypy.org>
Message-ID: <1333343222.51.0.662902662295.issue1104@bugs.pypy.org>


New submission from reportmp <f232684 at rppkn.com>:

I'm using pypy 1.8 from epel in centos 6.2,
and I found peer_certificate are broken, just run this code.

import socket

fd = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
fd.connect(("pypy.org", 443))
ssl = socket.ssl(fd)
print ssl.server()
print ssl.peer_certificate(True).encode("hex")

with python 2.6.6
/C=eu/ST=lower sachsony/L=hildesheim/O=merlinux
GmbH/OU=infrastructure/CN=merlinux/emailAddress=holger at merlinux.eu
3082037b308202e4a003020102020900f702aab5e6951152300d06092a864886f70d01010505003081a2310b3009060355040613026575311730150603550408130e6c6f7765722073616368736f6e79311330110603550407130a68696c6465736865696d31163014060355040a130d6d65726c696e757820476d624831173015060355040b130e696e6672617374727563747572653111300f060355040313086d65726c696e75783121301f06092a864886f70d0109011612686f6c676572406d65726c696e75782e6575301e170d3131303531363132333134305a170d3134303230393132333134305a3081a2310b3009060355040613026575311730150603550408130e6c6f7765722073616368736f6e79311330110603550407130a68696c6465736865696d31163014060355040a130d6d65726c696e757820476d624831173015060355040b130e696e6672617374727563747572653111300f060355040313086d65726c696e75783121301f06092a864886f70d0109011612686f6c676572406d65726c696e75782e657530819f300d06092a864886f70d010101050003818d0030818902818100c7d39f2b7b3de98f54b208334308d0ea9eb677d67df1aea4b835446928f4213a065fc9467cc2c426ce70da186aa92b7d1834b58e6867e19adcaeabdfb4b6684652db2386d246407fbc1e8257f983a056353c071ecf7d73fb0bb75534b8b193dba3ab91fa4be8fe66c5a539bca4ce8d172dd7897ea9c6dff08dcb39c0976642e30203010001a381b63081b3301106096086480186f8420101040403020640300b0603551d0f0404030205e030130603551d25040c300a06082b06010505070301301d0603551d0e0416041479047a06f8a6779b6480be8f676ed242f6cfa10f301f0603551d2304183016801479047a06f8a6779b6480be8f676ed242f6cfa10f303c0603551d1104353033820b6d65726c696e75782e6575820d627567732e707970792e6f72678208707970792e6f7267820b7465737472756e2e6f7267300d06092a864886f70d01010505000381810042ab5eaf8a36b9aa18af9c0d5b478fab8a0c599ba8cbe697e3c99bb3e07228e93ce449a1443feb030ff3e7a7ce80fdf17e96ba4b13fafc4e95edbda387272f63d457443316b96a5eaa60d51112187bd81cf25797507fb9011c00abf1ab0db3d1982ae7398424c1fda069307bc43e2661817b6ed17617d5724e6577fbf01d52b4

with pypy 1.8
/C=eu/ST=lower sachsony/L=hildesheim/O=merlinux
GmbH/OU=infrastructure/CN=merlinux/emailAddress=holger at merlinux.eu
3082037b308202e4a0030201020209

Can any guy tell me why and how to fix it ? thanks.
I need check certificate from the ssl server.

----------
messages: 4163
nosy: pypy-issue, reportmp
priority: bug
status: unread
title: ssl._sslobj.peer_certificate broken in pypy 1.8

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

From tracker at bugs.pypy.org  Mon Apr  2 07:39:28 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 02 Apr 2012 05:39:28 +0000
Subject: [pypy-issue] [issue1105] spitfire got slower with merge of
	list-strategies
In-Reply-To: <1333345168.78.0.18240500407.issue1105@bugs.pypy.org>
Message-ID: <1333345168.78.0.18240500407.issue1105@bugs.pypy.org>


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

This is a distilled code that shows the problem:



class L(list):
    pass

def f():
    l = L()
    for i in range(10000):
        l.append(str(i))
    "".join(l)

for k in range(1000):
    f()

----------
messages: 4164
nosy: fijal, pypy-issue
priority: performance bug
status: unread
title: spitfire got slower with merge of list-strategies

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

From tracker at bugs.pypy.org  Mon Apr  2 07:51:54 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 02 Apr 2012 05:51:54 +0000
Subject: [pypy-issue] [issue1104] ssl._sslobj.peer_certificate broken in
	pypy 1.8
In-Reply-To: <1333343222.51.0.662902662295.issue1104@bugs.pypy.org>
Message-ID: <1333345914.35.0.885878899767.issue1104@bugs.pypy.org>


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

Thanks for the report, should be fixed in 5bfd8e84f0f2, either compile pypy 
yourself, or just wait for the next nightly.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 08:08:03 2012
From: tracker at bugs.pypy.org (Federico)
Date: Mon, 02 Apr 2012 06:08:03 +0000
Subject: [pypy-issue] [issue1103] NumPyPy using broadcasting gives
	numerically incorrect	results
In-Reply-To: <1333314274.07.0.640158434268.issue1103@bugs.pypy.org>
Message-ID: <1333346883.61.0.142049586086.issue1103@bugs.pypy.org>


Federico <vaggi.federico at gmail.com> added the comment:

Checkout the code from here:

https://bitbucket.org/FedericoV/numpy-tip-complex-modeling/src/991905172527/src/simulations

Run pypy pypy_benchmark.py
Run python pypy_benchmark.py

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

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

From tracker at bugs.pypy.org  Mon Apr  2 09:23:09 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 07:23:09 +0000
Subject: [pypy-issue] [issue1106] [cpyext] reassignments to tp_dict items
	don't have an	effect
In-Reply-To: <1333351389.24.0.00182077627071.issue1106@bugs.pypy.org>
Message-ID: <1333351389.24.0.00182077627071.issue1106@bugs.pypy.org>


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

Cython's "exttypebody" test fails. It tries to reassign values to the type dict
as follows:

cdef class Spam:
    a = 1
    b = a + 2 # 3
    a = b - 1 # 2
    c = 3     # 3
    b = c + a # 5

But only the values that were assign first prevail (i.e. a==1, b==3).

The C code is basically as follows:

  /* a */
  if (PyDict_SetItem((PyObject *)__pyx_ptype_12extclassbody_Spam->tp_dict,
__pyx_n_s__a, __pyx_int_1) < 0) {...}
  PyType_Modified(__pyx_ptype_12extclassbody_Spam);

  /* a */
  __pyx_t_1 = __Pyx_GetName((PyObject *)__pyx_ptype_12extclassbody_Spam,
__pyx_n_s__a); if (unlikely(!__pyx_t_1)) {...}
  __pyx_t_2 = PyNumber_Add(__pyx_t_1, __pyx_int_2); if (unlikely(!__pyx_t_2)) {...}
  __Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;
  if (PyDict_SetItem((PyObject *)__pyx_ptype_12extclassbody_Spam->tp_dict,
__pyx_n_s__b, __pyx_t_2) < 0) {...}
  __Pyx_DECREF(__pyx_t_2); __pyx_t_2 = 0;
  PyType_Modified(__pyx_ptype_12extclassbody_Spam);

  /* a */
  __pyx_t_2 = __Pyx_GetName((PyObject *)__pyx_ptype_12extclassbody_Spam,
__pyx_n_s__b); if (unlikely(!__pyx_t_2)) {...}
  __pyx_t_1 = PyNumber_Subtract(__pyx_t_2, __pyx_int_1); if
(unlikely(!__pyx_t_1)) {...}
  __Pyx_DECREF(__pyx_t_2); __pyx_t_2 = 0;
  if (PyDict_SetItem((PyObject *)__pyx_ptype_12extclassbody_Spam->tp_dict,
__pyx_n_s__a, __pyx_t_1) < 0) {...}
  __Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;
  PyType_Modified(__pyx_ptype_12extclassbody_Spam);

(__pyx_n_* and __pyx_int_* are Python object constants with the obvious value)

----------
messages: 4167
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] reassignments to tp_dict items don't have an effect

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

From tracker at bugs.pypy.org  Mon Apr  2 09:25:33 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 07:25:33 +0000
Subject: [pypy-issue] [issue1106] [cpyext] reassignments to tp_dict items
	don't have an	effect
In-Reply-To: <1333351389.24.0.00182077627071.issue1106@bugs.pypy.org>
Message-ID: <1333351533.18.0.300815780867.issue1106@bugs.pypy.org>


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

Sorry, the second "/* a */" comment was supposed to be a "/* b */"...

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

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

From tracker at bugs.pypy.org  Mon Apr  2 09:40:24 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 07:40:24 +0000
Subject: [pypy-issue] [issue1107] [cpyext] sq_contains slot allows returning
	non-bool value
In-Reply-To: <1333352424.23.0.828267866384.issue1107@bugs.pypy.org>
Message-ID: <1333352424.23.0.828267866384.issue1107@bugs.pypy.org>


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

Cython's tests "bishop2" and "kostyrka" fail. They return the values 1 and 42
respectively from the sq_contains function of an extension type. CPython
converts them to the corresponding boolean value (i.e. True for non-0), PyPy
returns the value unchanged, i.e. a test like "99 in obj" returns 42 instead of
True.

----------
messages: 4169
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] sq_contains slot allows returning non-bool value

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

From tracker at bugs.pypy.org  Mon Apr  2 09:43:17 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 07:43:17 +0000
Subject: [pypy-issue] [issue1108] [cpyext] TypeError instead of
	AttributeError when	assigning to read-only fields of extension types
In-Reply-To: <1333352597.0.0.984597426043.issue1108@bugs.pypy.org>
Message-ID: <1333352597.0.0.984597426043.issue1108@bugs.pypy.org>


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

Cython's "cdef_members_T517" test fails. It tests that the assignment to the
read-only attribute of an extension type raises an AttributeError (as in
CPython), but it raises a TypeError in PyPy.

----------
messages: 4170
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] TypeError instead of AttributeError when assigning to read-only fields of extension types

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

From tracker at bugs.pypy.org  Mon Apr  2 09:46:20 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 07:46:20 +0000
Subject: [pypy-issue] [issue1084] Implement PyErr_GetExcInfo() and
	PyErr_SetExcInfo() in	cpyext
In-Reply-To: <1331460743.68.0.269550106582.issue1084@bugs.pypy.org>
Message-ID: <1333352780.92.0.317997254967.issue1084@bugs.pypy.org>


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

Implemented here:

https://bitbucket.org/pypy/pypy/changeset/623bcea85df3

https://bitbucket.org/pypy/pypy/changeset/ee1a3b5094b8

Works for me now. Thanks!

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

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

From tracker at bugs.pypy.org  Mon Apr  2 09:58:33 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 07:58:33 +0000
Subject: [pypy-issue] [issue1109] list.pop() reports wrong number of
	expected arguments
In-Reply-To: <1333353513.11.0.525131851713.issue1109@bugs.pypy.org>
Message-ID: <1333353513.11.0.525131851713.issue1109@bugs.pypy.org>


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

In CPython:

>>> L=[1,2,3]
>>> L.pop(1,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: pop() takes at most 1 argument (2 given)

In PyPy:

>>>> L=[1,2,3]
>>>> L.pop(1,2)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: pop() takes at most 2 arguments (3 given)
>>>> help(L.pop)
Help on method pop:

pop(_1, _2=None) method of __builtin__.list instance
    L.pop([index]) -> item -- remove and return item at index (default last)

----------
messages: 4172
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: list.pop() reports wrong number of expected arguments

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

From tracker at bugs.pypy.org  Mon Apr  2 10:10:45 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 08:10:45 +0000
Subject: [pypy-issue] [issue1110] [cpyext] doc string of extension type does
	not show up in	TheType.__doc__
In-Reply-To: <1333354245.53.0.986425559347.issue1110@bugs.pypy.org>
Message-ID: <1333354245.53.0.986425559347.issue1110@bugs.pypy.org>


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

Cython's "r_docstrings" test fails. Apparently, a char* docstring value in the
tp_doc slot of an extension type does not show up in the type's "__doc__" attribute.

----------
messages: 4173
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] doc string of extension type does not show up in TheType.__doc__

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

From tracker at bugs.pypy.org  Mon Apr  2 10:18:29 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 08:18:29 +0000
Subject: [pypy-issue] [issue1111] [cpyext] mp_ass_subscript() slot function
	returns a value	as __setitem__()
In-Reply-To: <1333354709.38.0.972275510543.issue1111@bugs.pypy.org>
Message-ID: <1333354709.38.0.972275510543.issue1111@bugs.pypy.org>


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

Cython's "special_methods_T561" test fails. When a slot function is defined for
"mp_ass_subscript()" and it is being called as __setitem__() special method, it
returns the C-level integer result as value, i.e. it returns 0 instead of None
in the success case.

----------
messages: 4174
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] mp_ass_subscript() slot function returns a value as __setitem__()

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

From tracker at bugs.pypy.org  Mon Apr  2 10:27:08 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 08:27:08 +0000
Subject: [pypy-issue] [issue1110] [cpyext] doc string of extension type does
	not show up in	TheType.__doc__
In-Reply-To: <1333354245.53.0.986425559347.issue1110@bugs.pypy.org>
Message-ID: <1333355228.53.0.18620758742.issue1110@bugs.pypy.org>


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

Thanks, fixed in 171b149844d2.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 10:33:46 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 08:33:46 +0000
Subject: [pypy-issue] [issue1111] [cpyext] mp_ass_subscript() slot function
	returns a value	as __setitem__()
In-Reply-To: <1333354709.38.0.972275510543.issue1111@bugs.pypy.org>
Message-ID: <1333355626.51.0.522777757118.issue1111@bugs.pypy.org>


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

Thanks, fixed in 7da597d3c86d.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 10:37:02 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 08:37:02 +0000
Subject: [pypy-issue] [issue1109] list.pop() reports wrong number of
	expected arguments
In-Reply-To: <1333353513.11.0.525131851713.issue1109@bugs.pypy.org>
Message-ID: <1333355822.62.0.347850694609.issue1109@bugs.pypy.org>


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

This one is probably not going to be resolved.  Try this on CPython:

>>> class A(object):
...   def pop(self, x):
...     pass
... 
>>> A().pop(1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: pop() takes exactly 2 arguments (3 given)

So for the same reason, the built-in method pop() reports the same message. 
Actually in PyPy, pop() is a regular method object; we don't have "built-in
method" objects.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 10:41:03 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 08:41:03 +0000
Subject: [pypy-issue] [issue1108] [cpyext] TypeError instead of
	AttributeError when	assigning to read-only fields of extension types
In-Reply-To: <1333352597.0.0.984597426043.issue1108@bugs.pypy.org>
Message-ID: <1333356063.83.0.786325145816.issue1108@bugs.pypy.org>


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

TypeError vs AttributeError is a common problem where CPython is not consistent
at all.  If we find a clear place that raises the TypeError in PyPy just for
this case, then we can fix it.  But I rather think that it's done by generic
code (a quick look through cpyext's w_TypeError makes me think so).  We usually
"fix" it by changing the tests to accept (AttributeError, TypeError) instead of
only one of them.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 10:49:13 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 08:49:13 +0000
Subject: [pypy-issue] [issue1107] [cpyext] sq_contains slot allows returning
	non-bool value
In-Reply-To: <1333352424.23.0.828267866384.issue1107@bugs.pypy.org>
Message-ID: <1333356553.13.0.377156349599.issue1107@bugs.pypy.org>


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

Thanks, fixed in 849cc68d148d.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 11:01:33 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 09:01:33 +0000
Subject: [pypy-issue] [issue1109] list.pop() reports wrong number of
	expected arguments
In-Reply-To: <1333353513.11.0.525131851713.issue1109@bugs.pypy.org>
Message-ID: <1333357293.02.0.220478784888.issue1109@bugs.pypy.org>


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

Ok, makes sense. Fixed the test.

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

From tracker at bugs.pypy.org  Mon Apr  2 11:02:13 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 09:02:13 +0000
Subject: [pypy-issue] [issue1108] [cpyext] TypeError instead of
	AttributeError when	assigning to read-only fields of extension types
In-Reply-To: <1333352597.0.0.984597426043.issue1108@bugs.pypy.org>
Message-ID: <1333357333.06.0.96755592414.issue1108@bugs.pypy.org>


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

Ok, no problem. I fixed the test on our side.

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

From tracker at bugs.pypy.org  Mon Apr  2 11:21:46 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 09:21:46 +0000
Subject: [pypy-issue] [issue1105] spitfire got slower with merge of
	list-strategies
In-Reply-To: <1333345168.78.0.18240500407.issue1105@bugs.pypy.org>
Message-ID: <1333358506.99.0.814996844946.issue1105@bugs.pypy.org>


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

Might be fixed in 4767e4614bfa.  Needs testing on the real case.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 11:35:17 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 02 Apr 2012 09:35:17 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333359317.15.0.713549707998.issue1102@bugs.pypy.org>


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

Closing the april fool's joke

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

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

From tracker at bugs.pypy.org  Mon Apr  2 12:16:42 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 02 Apr 2012 10:16:42 +0000
Subject: [pypy-issue] [issue1107] [cpyext] sq_contains slot allows returning
	non-bool value
In-Reply-To: <1333352424.23.0.828267866384.issue1107@bugs.pypy.org>
Message-ID: <1333361802.68.0.22831387936.issue1107@bugs.pypy.org>


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

Fails on translation:

[translation:ERROR]  TyperError: arithmetic not supported on <INT>, it's size is
too small
[translation:ERROR] .. (pypy.module.cpyext.slotdefs:171)wrap_objobjproc

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

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

From tracker at bugs.pypy.org  Mon Apr  2 12:19:18 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 10:19:18 +0000
Subject: [pypy-issue] [issue1107] [cpyext] sq_contains slot allows returning
	non-bool value
In-Reply-To: <1333352424.23.0.828267866384.issue1107@bugs.pypy.org>
Message-ID: <1333361958.18.0.00735583943619.issue1107@bugs.pypy.org>


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

Should be fixed by 53c5958727e6.

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

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

From tracker at bugs.pypy.org  Mon Apr  2 17:00:33 2012
From: tracker at bugs.pypy.org (Richard Barrell)
Date: Mon, 02 Apr 2012 15:00:33 +0000
Subject: [pypy-issue] [issue1102] This program takes longer to run under
	pypy-1.8 than	under CPython 2.6.5
In-Reply-To: <1333299440.22.0.777063989332.issue1102@bugs.pypy.org>
Message-ID: <1333378833.64.0.711173568869.issue1102@bugs.pypy.org>


Richard Barrell <rchrd at brrll.co.uk> added the comment:

Good on you for getting that and thank you for not shooting me. ;)

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

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

From tracker at bugs.pypy.org  Mon Apr  2 17:34:24 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 02 Apr 2012 15:34:24 +0000
Subject: [pypy-issue] [issue1100] Dict iterators can return deleted entries
In-Reply-To: <1332768538.31.0.460128219214.issue1100@bugs.pypy.org>
Message-ID: <1333380864.99.0.533812826478.issue1100@bugs.pypy.org>


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

Fixed in ae4a7ab99a76, by starting from your patch (thanks!).  The issue was
that you placed the test in a class that contains tests run with and without
dict strategies.  Of course the test fails to raise if we don't have dict
strategies.

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

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

From tracker at bugs.pypy.org  Tue Apr  3 00:03:36 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 02 Apr 2012 22:03:36 +0000
Subject: [pypy-issue] [issue1112] numpypy swapaxes patch
In-Reply-To: <1333404216.35.0.0841527968611.issue1112@bugs.pypy.org>
Message-ID: <1333404216.35.0.0841527968611.issue1112@bugs.pypy.org>


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

patch to add swapaxes() to numarray.  

Ideally this should return a view where possible (according to numpy docs), but at 
the moment (like transpose and reshape), this calls get_concrete().

----------
files: swapaxes.patch
messages: 4188
nosy: mikefc, pypy-issue
priority: feature
status: unread
title: numpypy swapaxes patch

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

From tracker at bugs.pypy.org  Tue Apr  3 06:01:46 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Tue, 03 Apr 2012 04:01:46 +0000
Subject: [pypy-issue] [issue1026] numpypy: incorrect shape of array with
	zero-shape coords
In-Reply-To: <1327613472.02.0.951420920979.issue1026@bugs.pypy.org>
Message-ID: <1333425706.22.0.122448289413.issue1026@bugs.pypy.org>


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

Definitely fixed.

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

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

From tracker at bugs.pypy.org  Tue Apr  3 06:37:59 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Tue, 03 Apr 2012 04:37:59 +0000
Subject: [pypy-issue] [issue1113] osx64 buildbot hasn't been seen in 2 weeks.
In-Reply-To: <1333427879.65.0.633856211754.issue1113@bugs.pypy.org>
Message-ID: <1333427879.65.0.633856211754.issue1113@bugs.pypy.org>


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

The osx64 buildbot seems to have fallen off the radar about 2 weeks ago  (if i'm 
reading the buildbot website correctly).

Anyone know what's going on with it?

----------
messages: 4190
nosy: mikefc, pypy-issue
priority: bug
status: unread
title: osx64 buildbot hasn't been seen in 2 weeks.

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

From tracker at bugs.pypy.org  Tue Apr  3 06:44:20 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Tue, 03 Apr 2012 04:44:20 +0000
Subject: [pypy-issue] [issue1064] NumPy Contribution
In-Reply-To: <1329790715.38.0.905612431591.issue1064@bugs.pypy.org>
Message-ID: <1333428260.44.0.355629788833.issue1064@bugs.pypy.org>


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

Jperla, Should there have been a patch attached to this?

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

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

From tracker at bugs.pypy.org  Tue Apr  3 21:16:42 2012
From: tracker at bugs.pypy.org (Kibeom Kim)
Date: Tue, 03 Apr 2012 19:16:42 +0000
Subject: [pypy-issue] [issue1114] sandboxing to be embedded on c programs
In-Reply-To: <1333480602.04.0.261291285835.issue1114@bugs.pypy.org>
Message-ID: <1333480602.04.0.261291285835.issue1114@bugs.pypy.org>


New submission from Kibeom Kim <kk1674 at nyu.edu>:

for user scripting on c programs, lua, javascript, and python seems to be arguably the three common choices.

and frequently, the c program cannot trust user script and so it has to be embedded safely. I hope pypy's sandboxing can be used 
in this scenario.

There are two problems I see:

1. the c program and embedded, sandboxed pypy will be separated by process boundary, which prevents memory sharing and makes 
communication inefficient.

2. proper c-api to control the embedded sandboxed pypy from the c program.

----------
messages: 4192
nosy: kkb110, pypy-issue
priority: wish
status: unread
title: sandboxing to be embedded on c programs

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

From tracker at bugs.pypy.org  Wed Apr  4 13:23:10 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 04 Apr 2012 11:23:10 +0000
Subject: [pypy-issue] [issue1105] spitfire got slower with merge of
	list-strategies
In-Reply-To: <1333345168.78.0.18240500407.issue1105@bugs.pypy.org>
Message-ID: <1333538590.66.0.06489483089.issue1105@bugs.pypy.org>


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

Fixed

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

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

From tracker at bugs.pypy.org  Wed Apr  4 16:27:46 2012
From: tracker at bugs.pypy.org (reportmp)
Date: Wed, 04 Apr 2012 14:27:46 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>


New submission from reportmp <f232684 at rppkn.com>:

I'm trying to build pypy in centos 6.2,  if I use these options, build will
failed on 32bit but not on 64bit.
    --translation-taggedpointers \
    --translation-rweakref \
    --gcremovetypeptr targetpypystandalone --objspace-std-withmapdict \
    --objspace-std-withsmallint --no-objspace-std-withsmalllong \
    --objspace-std-withsmalltuple --no-objspace-std-withprebuiltint \
    --objspace-std-getattributeshortcut --objspace-std-withmethodcache

----------
messages: 4194
nosy: pypy-issue, reportmp
priority: bug
status: unread
title: build error with some options

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

From tracker at bugs.pypy.org  Wed Apr  4 16:34:16 2012
From: tracker at bugs.pypy.org (reportmp)
Date: Wed, 04 Apr 2012 14:34:16 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1333550056.35.0.221070913582.issue1115@bugs.pypy.org>


reportmp <f232684 at rppkn.com> added the comment:

Sorry I click submit uncareful.
Pypy version is cc56984630fc and i build through rpmbuild.
If i dont' use these options, It will success on 32bit and 64bit so I think the
problem are in pypy.
Other files: http://dl.fedoraproject.org/pub/epel/6/SRPMS/pypy-1.8-2.el6.src.rpm

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

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

From tracker at bugs.pypy.org  Wed Apr  4 17:03:38 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 04 Apr 2012 15:03:38 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1333551818.22.0.514240632821.issue1115@bugs.pypy.org>


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

Here is an extract of the 32bit build output:

[translation:info] Compiling c source...
[platform:execute] make -j 4 in /root/rpmbuild/BUILD/pypy-pypy-cc56984630fc/pypy/translator/goal/usession-pypy-0/testing_1
[platform:Error] In file included from structimpl.c:7:
[platform:Error] forwarddecl.h:5308: error: size of array 'group_pypy_g_typeinfo_is_too_large' is negative

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

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

From tracker at bugs.pypy.org  Wed Apr  4 17:13:52 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 04 Apr 2012 15:13:52 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1333552432.77.0.773930210401.issue1115@bugs.pypy.org>


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

amaury: Ah, if that's the error, then I think we will ignore it as long as it
doesn't show up in "normal" builds.  (It means there are too many classes on
32-bit, and is directly caused by --gcremovetypeptr.  On 64-bit the limit is
much higher.)

reportmp: There is little point in specifying tons of options, because the ones
enabled in a default "-Ojit" build should give you the fastest result.  You may
want to enable additional options only if you know what you are doing and why. 
I know for sure that at least half the options you give definitely make things
worse, and the other half is unneeded because enabled by default; only a couple
of options have a not-so-clear effect on speed.

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

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

From tracker at bugs.pypy.org  Wed Apr  4 17:36:05 2012
From: tracker at bugs.pypy.org (reportmp)
Date: Wed, 04 Apr 2012 15:36:05 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1333553765.51.0.823154086055.issue1115@bugs.pypy.org>


reportmp <f232684 at rppkn.com> added the comment:

arigo:
Thanks for reply.
I want pypy use less memory so I add gcremovetypeptr withmapdict and
withsmallint, other are requirements.
Why I add so many unneeded options because once build will cost 4 hours on I7 I
don't want to try again and again ...
Pypy memory use more than CPython 200 ~ 300% in my machine make the server down
when memory exhaust.
If you know the way can make things better, please tell me, thanks ...

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

From tracker at bugs.pypy.org  Wed Apr  4 17:53:13 2012
From: tracker at bugs.pypy.org (reportmp)
Date: Wed, 04 Apr 2012 15:53:13 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1333554793.99.0.57507191486.issue1115@bugs.pypy.org>


reportmp <f232684 at rppkn.com> added the comment:

And I add these options because I read the blog on pypy.org :

Memory usage: large, memory-hungry Python programs might end up taking less
space than they do in CPython.

less space -> http://morepypy.blogspot.com/2009/10/gc-improvements.html

"the two optimizations together save 32 MB of RAM (i.e. 8 bytes per object). The
version of PyPy we measured this with was built as follows:

./translate.py --gcremovetypeptr targetpypystandalone
--objspace-std-withsharingdict"

"This nicely shows that our GCs are much faster at allocating objects, and that
our objects can be much smaller than CPython's."

But they can only be used in 2009 ? Or I should not use jit with these options ?

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

From tracker at bugs.pypy.org  Sat Apr  7 15:05:11 2012
From: tracker at bugs.pypy.org (Kostya Rybnikov)
Date: Sat, 07 Apr 2012 13:05:11 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>


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

Running tests on django is broken http://paste.pocoo.org/show/577454/

----------
messages: 4200
nosy: k_bx, pypy-issue
priority: bug
status: unread
title: AttributeError: 'GzipFile' object has no attribute 'fileobj' with Django

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

From tracker at bugs.pypy.org  Sat Apr  7 17:18:13 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 07 Apr 2012 15:18:13 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1333811893.07.0.567378039252.issue1116@bugs.pypy.org>


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

It looks like some complicated weakref issue.  If I add the following line at
the end of manage.py the error goes away:

    import gc; gc.collect(); gc.collect()

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

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

From tracker at bugs.pypy.org  Sun Apr  8 19:14:49 2012
From: tracker at bugs.pypy.org (Gabriel)
Date: Sun, 08 Apr 2012 17:14:49 +0000
Subject: [pypy-issue] [issue1117] Can't find library path from PATH
In-Reply-To: <1333905289.15.0.416209681715.issue1117@bugs.pypy.org>
Message-ID: <1333905289.15.0.416209681715.issue1117@bugs.pypy.org>


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

This issue prevents pypy from starting in some cases.

sys.executable is set to an empty string when the interpreter can't find argv[0]
in the PATH environment variable. This is a bit too strict when the
interpreter's command search logic doesn't match the shell's (my shell resolves
~/bin when searching PATH, Python doesn't), or when argv[0] has some unrelated
value, but the strict behaviour matches CPython (after CPython issue 7774 was
closed). There are more reliable ways of getting the current executable, but
it's a bit ambiguous if argv[0] should be preferred to /proc/self/exe, so doing
like CPython and leaving it empty is an acceptable choice.

When looking up the library search path, I'd prefer if PyPy used the more
reliable /proc/self/exe method though; the alternative is that PyPy fails to
start. Here is a patch that adds that method as a fallback in get_library_path.

----------
messages: 4202
nosy: pypy-issue
priority: critical
status: unread
title: Can't find library path from PATH

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

From tracker at bugs.pypy.org  Mon Apr  9 04:27:39 2012
From: tracker at bugs.pypy.org (Alan Derk)
Date: Mon, 09 Apr 2012 02:27:39 +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: <1333938459.17.0.362001926516.issue1118@bugs.pypy.org>


New submission from Alan Derk <streblo at gmail.com>:

Indexing of 1D arrays using boolean arrays works the same as CPython/numpy, but the analogue for 2D arrays is broken (as 
compared to CPython/numpy). The output of both is shown below. Thank you very much developers!!!

Python 2.7.2 (0e28b379d8b3, Feb 09 2012, 18:31:47)
[PyPy 1.8.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''
>>>> import numpypy as np
>>>> a = np.array([[1,2,3],[4,5,6],[7,8,9]],int)
>>>> b = np.array([7,8,9],int)
>>>> c = np.array([True,False,True],bool)
>>>> b[c]
array([7, 9])
>>>> a[c]
Traceback (most recent call last):
  File "<console>", line 1, in <module>
IndexError: invalid index


Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> a = np.array([[1,2,3],[4,5,6],[7,8,9]],int)
>>> b = np.array([7,8,9],int)
>>> c = np.array([True,False,True],bool)
>>> b[c]
array([7, 9])
>>> a[c]
array([[1, 2, 3],
       [7, 8, 9]])

----------
messages: 4203
nosy: pypy-issue, streblo
priority: bug
status: unread
title: numpypy: indexing of 2D arrays with 1-D boolean arrays is broken

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

From tracker at bugs.pypy.org  Mon Apr  9 05:31:18 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 09 Apr 2012 03:31:18 +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: <1333942278.68.0.312099074051.issue1118@bugs.pypy.org>


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

I can confirm that this still happens on latest OSX nightly.
==========
Python 2.7.2 (df6b4266c2e9, Apr 08 2012, 01:00:14)
[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: ``PyPy is not a real VM: no
segfault handlers to do the rare cases''
>>>> import numpypy as np
>>>> a = np.array([[1,2,3],[4,5,6],[7,8,9]],int)
>>>> b = np.array([7,8,9],int)
>>>> c = np.array([True,False,True],bool)
>>>> b[c]
array([7, 9])
>>>> a[c]
Traceback (most recent call last):
  File "<console>", line 1, in <module>
IndexError: invalid index
>>>>

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

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

From tracker at bugs.pypy.org  Mon Apr  9 06:47:01 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Mon, 09 Apr 2012 04:47:01 +0000
Subject: [pypy-issue] [issue1113] osx64 buildbot hasn't been seen in 2 weeks.
In-Reply-To: <1333427879.65.0.633856211754.issue1113@bugs.pypy.org>
Message-ID: <1333946821.21.0.707867526264.issue1113@bugs.pypy.org>


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

It appears to be back now. Thanks for fixing.

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

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

From tracker at bugs.pypy.org  Tue Apr 10 14:12:39 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 10 Apr 2012 12:12:39 +0000
Subject: [pypy-issue] [issue1112] numpypy swapaxes patch
In-Reply-To: <1333404216.35.0.0841527968611.issue1112@bugs.pypy.org>
Message-ID: <1334059959.76.0.442025961677.issue1112@bugs.pypy.org>


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

Hey mike, a couple pieces of feedback:

* Can you add tests for doing this on slices and virtual arrays?
* You don't need a loop in there, strides = concrete.strides[:] (etc.) should be 
enough.
* Can you bring in numpy.swapaxes into lib_pypy/numpypy/, should just be a copy-
paste from upstream numpy?

Thanks!

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

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

From tracker at bugs.pypy.org  Tue Apr 10 14:16:42 2012
From: tracker at bugs.pypy.org (passy)
Date: Tue, 10 Apr 2012 12:16:42 +0000
Subject: [pypy-issue] [issue1119] Py_GetArgcArgv not exposed
In-Reply-To: <1334060202.49.0.639652474444.issue1119@bugs.pypy.org>
Message-ID: <1334060202.49.0.639652474444.issue1119@bugs.pypy.org>


New submission from passy <phartig at rdrei.net>:

Py_GetArgcArgv appears to be a private CPython API, but there are packages relying on it, 
like procname[0]. Compiling against PyPy works fine, but importing the module fails:

>>>> import procname
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ImportError: unable to load extension module '/home/.../virtualenv/site-
packages/procname.pypy-18.so': /home/.../virtualenv/site-packages/procname.pypy-18.so: 
undefined symbol: Py_GetArgcArgv

Is this possible to implement in PyPy or is there a different way to obtain the original 
arguments the process was started that is compatible with PyPy?

[0] https://github.com/lericson/procname/blob/master/procnamemodule.c

----------
messages: 4207
nosy: passy, pypy-issue
priority: wish
status: unread
title: Py_GetArgcArgv not exposed

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

From tracker at bugs.pypy.org  Tue Apr 10 17:40:23 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 10 Apr 2012 15:40:23 +0000
Subject: [pypy-issue] [issue1039] PyPy 1.8 slower on tree generating code
In-Reply-To: <1328915000.83.0.608855367052.issue1039@bugs.pypy.org>
Message-ID: <1334072423.8.0.126958230561.issue1039@bugs.pypy.org>


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

just as a fact, we are still slower than pypy 1.7 on this:

viper tmp $ ./pypy-1.7/bin/pypy bug001.py 
total time:       6.5888 sec
viper tmp $ ./pypy-1.8/bin/pypy bug001.py 
total time:       8.7977 sec
viper tmp $ ./pypy-c-jit-54273-124c48df1aab-linux64/bin/pypy bug001.py 
total time:       8.0648 sec

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

From tracker at bugs.pypy.org  Tue Apr 10 17:48:04 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 10 Apr 2012 15:48:04 +0000
Subject: [pypy-issue] [issue1036] libffi.a search path is incomplete
In-Reply-To: <1328782362.48.0.699732160944.issue1036@bugs.pypy.org>
Message-ID: <1334072884.02.0.710696298961.issue1036@bugs.pypy.org>


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

what are the extra dirs we should look libffi.a in?
We should list them in pypy/translator/platform/linux.py, method
library_dirs_for_libffi.a.

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

From tracker at bugs.pypy.org  Tue Apr 10 18:03:33 2012
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Tue, 10 Apr 2012 16:03:33 +0000
Subject: [pypy-issue] [issue1036] libffi.a search path is incomplete
In-Reply-To: <1328782362.48.0.699732160944.issue1036@bugs.pypy.org>
Message-ID: <1334073813.92.0.00250383187188.issue1036@bugs.pypy.org>


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

> what are the extra dirs we should look libffi.a in?

On Debian, /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`. That's hardly
portable, though.

A more portable option is to parse the output of gcc -print-search-dirs.

I'd like a way to force linking dynamically, for Debian.

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

From tracker at bugs.pypy.org  Tue Apr 10 18:11:33 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Tue, 10 Apr 2012 16:11:33 +0000
Subject: [pypy-issue] [issue1039] PyPy 1.8 slower on tree generating code
In-Reply-To: <1328915000.83.0.608855367052.issue1039@bugs.pypy.org>
Message-ID: <1334074293.38.0.851993319065.issue1039@bugs.pypy.org>


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

it might make sense to remove the random usage,
it accounts for more than 1/4 of the runtime and
i think its not directly interesting to the problem

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

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

From tracker at bugs.pypy.org  Tue Apr 10 18:17:02 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 10 Apr 2012 16:17:02 +0000
Subject: [pypy-issue] [issue1049] Source releases should be pypy-<v> not
	pypy-pypy-<hash>
In-Reply-To: <1329324245.08.0.0479236005649.issue1049@bugs.pypy.org>
Message-ID: <1334074622.25.0.822629026713.issue1049@bugs.pypy.org>


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

"fixed" in 658930dda580 (by addind a reminder in how-to-release.txt)

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

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

From tracker at bugs.pypy.org  Tue Apr 10 18:22:26 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 10 Apr 2012 16:22:26 +0000
Subject: [pypy-issue] [issue1063] numpypy Segmentation fault
In-Reply-To: <1329745396.57.0.717360098013.issue1063@bugs.pypy.org>
Message-ID: <1334074946.16.0.897135393053.issue1063@bugs.pypy.org>


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

this still segfaults on at revision 124c48df1aab.
do we have any clue?

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

From tracker at bugs.pypy.org  Tue Apr 10 19:28:19 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 10 Apr 2012 17:28:19 +0000
Subject: [pypy-issue] [issue1087] Race condition when calling getattr
In-Reply-To: <1331583275.77.0.620668848256.issue1087@bugs.pypy.org>
Message-ID: <1334078899.42.0.572612385918.issue1087@bugs.pypy.org>


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

boomboom.py still occasionally crashes for me at revision 124c48df1aab.
I tried to run boomboom.py 1000 times, I got 153 LookupErrors with pypy-1.8, and
356 with pypy-124c48df1aab,

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

From tracker at bugs.pypy.org  Tue Apr 10 21:37:50 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Tue, 10 Apr 2012 19:37:50 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count()
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>


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

The C-API function PyUnicode_Count(ustring, substring, start_index, end_index)
is unimplemented (has a stub in stubs.py). It should be rather straight forward,
given that there is an equivalent ustring.count(substring, start_index,
end_index) method.

Something like this might do the trick:

@cpython_api([PyObject, PyObject, Py_ssize_t, Py_ssize_t], Py_ssize_t, error=-1)
def PyUnicode_Count(space, w_str, w_substr, start, end):
    """Return the number of non-overlapping occurrences of substr in
    str[start:end].  Return -1 if an error occurred.

    This function returned an int type and used an int
    type for start and end. This might require changes in your code for
    properly supporting 64-bit systems.
    """

    return space.call_method(w_str, "count", w_substr,
                             space.wrap(start), space.wrap(end))

----------
messages: 4215
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] missing PyUnicode_Count()

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

From tracker at bugs.pypy.org  Tue Apr 10 21:47:14 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Tue, 10 Apr 2012 19:47:14 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count()
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334087234.02.0.489909880934.issue1120@bugs.pypy.org>


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

The same applies to PyUnicode_Find(), which looks like it would want to become this:

@cpython_api([PyObject, PyObject, Py_ssize_t, Py_ssize_t, rffi.INT_real],
Py_ssize_t, error=-2)
def PyUnicode_Find(space, w_str, w_substr, start, end, direction):
    """Return the first position of substr in str*[*start:end] using the given
    direction (direction == 1 means to do a forward search, direction == -1 a
    backward search).  The return value is the index of the first match; a value of
    -1 indicates that no match was found, and -2 indicates that an error
    occurred and an exception has been set.

    This function used an int type for start and end. This
    might require changes in your code for properly supporting 64-bit
    systems.
    """
    if direction > 0:
        return space.call_method(w_str, "find", w_substr,
                                 space.wrap(start), space.wrap(end))
    else:
        return space.call_method(w_str, "rfind", w_substr,
                                 space.wrap(start), space.wrap(end))

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

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

From tracker at bugs.pypy.org  Tue Apr 10 21:51:49 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Tue, 10 Apr 2012 19:51:49 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334087509.39.0.451725431209.issue1120@bugs.pypy.org>


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

PyUnicode_Split() is like this:

@cpython_api([PyObject, PyObject, Py_ssize_t], PyObject)
def PyUnicode_Split(space, w_str, w_sep, maxsplit):
    """Split a string giving a list of Unicode strings.  If sep is NULL, splitting
    will be done at all whitespace substrings.  Otherwise, splits occur at the given
    separator.  At most maxsplit splits will be done.  If negative, no limit is
    set.  Separators are not included in the resulting list.

    This function used an int type for maxsplit. This might require
    changes in your code for properly supporting 64-bit systems.
    """

    return space.call_method(w_str, "split", w_sep, space.wrap(maxsplit))

(assuming that a NULL value for w_sep turns into a None object value)

----------
title: [cpyext] missing PyUnicode_Count() -> [cpyext] missing PyUnicode_Count() and other PyUnicode_*() functions

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

From tracker at bugs.pypy.org  Tue Apr 10 21:54:45 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 10 Apr 2012 19:54:45 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1334087685.82.0.287315153081.issue1080@bugs.pypy.org>


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

I confirm that both bugs are still there at revision 124c48df1aab.
inifite_loop.py really looks like an unroll bug.

str_instead_of_token is weird. If I run it with pypy 1.7, I get a Fatal RPython
error: BytecodeCorruption even with --jit off

with pypy 1.8 and trunk, I get the applevel exception the user reported; if I
disable unrolling, I get this:
$ pypy-c --jit enable_opts=intbounds:rewrite:virtualize:string:heap
str_instead_of_token.py
RPython traceback:
  File "jit_metainterp_optimizeopt___init__.c", line 271, in optimize_trace
  File "jit_metainterp_optimizeopt_optimizer.c", line 3596, in
Optimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_heap.c", line 3694, in OptHeap_emit_operation
  File "jit_metainterp_optimizeopt_heap.c", line 4131, in OptHeap_emitting_operation
Fatal RPython error: AssertionError
Aborted

so it's possible that it's not an unroll fault, but that unroll simply gets a
list of operations which is "buggy".

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

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

From tracker at bugs.pypy.org  Tue Apr 10 21:57:14 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Tue, 10 Apr 2012 19:57:14 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334087834.61.0.927996470053.issue1120@bugs.pypy.org>


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

And another straight forward one is PyUnicode_Splitlines(), which goes like this:

@cpython_api([PyObject, rffi.INT_real], PyObject)
def PyUnicode_Splitlines(space, w_str, keepend):
    """Split a Unicode string at line breaks, returning a list of Unicode strings.
    CRLF is considered to be one line break.  If keepend is 0, the Line break
    characters are not included in the resulting strings.
    """

    return space.call_method(w_str, "splitlines", space.wrap(bool(keepend)))

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

From tracker at bugs.pypy.org  Tue Apr 10 22:41:03 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Tue, 10 Apr 2012 20:41:03 +0000
Subject: [pypy-issue] [issue1121] [cpyext] speed up some macros
In-Reply-To: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>
Message-ID: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>


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

Inlining a fast path into a macro can avoid the call into cpyext and greatly
speed up the macro. Here are some proposed improvements:

// include/object.h

#define Py_INCREF(ob)  ((((PyObject *)ob)->ob_refcnt > 0) ? \
     ((PyObject *)ob)->ob_refcnt++ : (Py_IncRef((PyObject *)ob)))

#define Py_DECREF(ob)  ((((PyObject *)ob)->ob_refcnt > 1) ? \
     ((PyObject *)ob)->ob_refcnt-- : (Py_DecRef((PyObject *)ob)))

#define Py_XINCREF(op) do { if ((op) == NULL) ; else Py_INCREF(op); \
                          } while (0)

#define Py_XDECREF(op) do { if ((op) == NULL) ; else Py_DECREF(op); \
                          } while (0)

// unicodeobject.h (with a the slight pessimisation by calling
PyUnicode_AsUnicode() instead of the other way round - but if we have to call
it, we already know that we have to allocate the buffer, so that won't hurt much)

#define PyUnicode_AS_UNICODE(obj) (((PyUnicodeObject *)(obj))->c_buffer ? \
     (((PyUnicodeObject *)(obj))->c_buffer : PyUnicode_AsUnicode(obj))

#define PyUnicode_AS_DATA(obj) ((char*)PyUnicode_AS_UNICODE(obj))

// stringobject.h

#define PyString_AS_STRING(obj) (((PyStringObject *)(obj))->c_buffer ? \
     (((PyStringObject *)(obj))->c_buffer : PyString_AsString(obj))

----------
messages: 4220
nosy: pypy-issue, sbehnel
priority: performance bug
status: unread
title: [cpyext] speed up some macros

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

From tracker at bugs.pypy.org  Tue Apr 10 22:50:51 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Tue, 10 Apr 2012 20:50:51 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>


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

I wonder why the definition of PyTupleObject and friends use PyObject_HEAD
instead of PyObject_VAR_HEAD - how is Py_SIZE(atuple) supposed to work?
Py_SIZE() is currently defined like this:

       #define Py_SIZE(ob)             (((PyVarObject*)(ob))->ob_size)

i.e. it actually requires a PyVarObject struct. That macro works with quite a
number of builtin types in CPython, but it can't work for them in PyPy.

Personally, I wouldn't mind adding the ob_size field to at least the constant
sequence types as a duplication of the object length value, because it would
allow for a similar optimisation of the couple of Py(Tuple|Bytes|Unicode|maybe
others)_GET_SIZE() macros as for the ones in issue1121, by simply aliasing them
to Py_SIZE(). C extensions commonly expect these macros to be fast.

----------
messages: 4221
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] PyVarObject builtins and definition of Py_SIZE()

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

From tracker at bugs.pypy.org  Tue Apr 10 23:12:08 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 10 Apr 2012 21:12:08 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334092328.16.0.188891683333.issue1122@bugs.pypy.org>


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

Duplicating the size field would work for immutable (or non-resizeable) objects, but not for lists or dicts: 
the storage is maintained outside the C structure.

A possible fix is to use tp_itemsize to determine if the object has an ob_size:
#define Py_SIZE(obj) \
   (obj)->ob_type->tp_itemsize ? ((PyVarObject*)(obj))->ob_size : PyObject_Size(obj)
And then, turn tuple and strings into PyVarObjects.

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

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

From tracker at bugs.pypy.org  Tue Apr 10 23:26:23 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 10 Apr 2012 21:26:23 +0000
Subject: [pypy-issue] [issue1049] Source releases should be pypy-<v> not
	pypy-pypy-<hash>
In-Reply-To: <1329324245.08.0.0479236005649.issue1049@bugs.pypy.org>
Message-ID: <1334093183.68.0.398856331188.issue1049@bugs.pypy.org>


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

Not fixed, because we don't want to package source by hand. It's done by 
bitbucket right now, if you want to do it by hand, please automate.

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

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

From tracker at bugs.pypy.org  Tue Apr 10 23:28:57 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 10 Apr 2012 21:28:57 +0000
Subject: [pypy-issue] [issue1087] Race condition when calling getattr
In-Reply-To: <1331583275.77.0.620668848256.issue1087@bugs.pypy.org>
Message-ID: <1334093337.68.0.647898013961.issue1087@bugs.pypy.org>


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

we have an open pull request about that. Feel free to go and submit it, provided 
you run buildbot/benchmarks after that

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

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

From tracker at bugs.pypy.org  Tue Apr 10 23:31:13 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 10 Apr 2012 21:31:13 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334093473.94.0.896368403409.issue1120@bugs.pypy.org>


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

Hi Stefan.

For all of this it would be much easier if it comes as a patch with a test :) 
Either that or a pull request can be fulfilled with no questions asked, however 
if I have to write a test it'll have to take a little bit more.

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

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

From tracker at bugs.pypy.org  Tue Apr 10 23:55:49 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 10 Apr 2012 21:55:49 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334094949.06.0.501815720731.issue1120@bugs.pypy.org>


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

With 859f1579f2bd, all these functions are implemented.

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

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

From tracker at bugs.pypy.org  Wed Apr 11 07:39:53 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Wed, 11 Apr 2012 05:39:53 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334122793.15.0.311563681825.issue1122@bugs.pypy.org>


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

> Duplicating the size field would work for immutable (or non-resizeable) objects,
> but not for lists or dicts: the storage is maintained outside the C structure.

Sure, sorry if I wasn't clear here.

> A possible fix is to use tp_itemsize to determine if the object has an ob_size:
> #define Py_SIZE(obj) \
>    (obj)->ob_type->tp_itemsize ? ((PyVarObject*)(obj))->ob_size :
PyObject_Size(obj)
> And then, turn tuple and strings into PyVarObjects.

Py_SIZE() doesn't do any error checking in CPython, but I think the above
would be reasonable way to work around the fact that it (by design) works
for more objects in CPython than it can in PyPy. I don't think it matters
if it works for more objects in PyPy than in CPython. All that really
counts is that it works for exactly the objects it supports in CPython.

One difference, if Py_SIZE() is incorrectly used on an object that doesn't
support it, the above will silently return -1 with an exception set. Well,
maybe not worse than undefined behaviour or returning an arbitrary value
that happens to reside on the heap, as CPython would. We should get away
with just ignoring that case. It's a macro...

The same reasoning applies to user provided types, IMHO - it's really the
users fault if Py_SIZE() is used on something other than a PyVarObject.

Also, Cython doesn't use Py_SIZE() directly anymore when compiling in PyPy,
so it's not a problem on that front either.

So, the only cases I can see where Py_SIZE() really needs to differ in
cpyext are mutable builtin types like list (dict is not a PyVarObject). In
Py3k:

$ fgrep PyObject_VAR_HEAD Include/*.h
Include/bytearrayobject.h:    PyObject_VAR_HEAD
Include/bytesobject.h:    PyObject_VAR_HEAD
Include/frameobject.h:    PyObject_VAR_HEAD
Include/listobject.h:    PyObject_VAR_HEAD
Include/longintrepr.h:  PyObject_VAR_HEAD
Include/memoryobject.h:    PyObject_VAR_HEAD
Include/object.h:/* PyObject_VAR_HEAD defines the initial segment of all
variable-size
Include/object.h:#define PyObject_VAR_HEAD      PyVarObject ob_base;
Include/object.h:    PyObject_VAR_HEAD
Include/tupleobject.h:    PyObject_VAR_HEAD

Py2.7 doesn't have memoryviews but adds PyStructSequence to that list.

Tuple and bytes objects can be fixed by making them PyVarObjects, but not
bytearray and listobject. They have their own Py*_GET_SIZE() macros,
however. We could require portable code to use those instead of Py_SIZE().
Not a big deal, IMHO.

Having frameobject not working is fine with me. Anyone using that directly
should expect portability problems.

The long object keeps its sign as the sign of its size, so that might be a
problem for some code. But that should be easy to fix by making it a
PyVarObject in cpyext and setting the size to 1 or -1 based on the sign of
its constant value.

Memoryviews are also constant after creation (IMHO), so they could become
PyVarObjects as well. The same applies to PyStructSequence, which is meant to be
mostly like a tuple.

So, I propose to keep the macro as it is now and to change the object
implementations instead.

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

From tracker at bugs.pypy.org  Wed Apr 11 09:51:17 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Wed, 11 Apr 2012 07:51:17 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334130677.77.0.677449693747.issue1120@bugs.pypy.org>


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

Cool, thanks!

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

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

From tracker at bugs.pypy.org  Wed Apr 11 10:19:21 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 11 Apr 2012 08:19:21 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334132361.27.0.954452401982.issue1122@bugs.pypy.org>


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

> Py_SIZE() doesn't do any error checking in CPython, but I think the above
> would be reasonable way to work around the fact that it (by design) works
> for more objects in CPython than it can in PyPy. I don't think it matters
> if it works for more objects in PyPy than in CPython. All that really
> counts is that it works for exactly the objects it supports in CPython.

Yes. in PyPy even type-specialized functions use the abstract interface,
for example PyString_Format also works with numbers...

> it's really the
> users fault if Py_SIZE() is used on something other than a PyVarObject.

> Tuple and bytes objects can be fixed by making them PyVarObjects, but not
> bytearray and listobject. They have their own Py*_GET_SIZE() macros,
> however. We could require portable code to use those instead of Py_SIZE().
> Not a big deal, IMHO.

This seems to contradict what you said earlier: Py_SIZE() should work
for all types it supports in CPython.
Py_SIZE() should use ob_size when there is one, and fall back to
PyObject_Size() in other cases.

Support for longs can come later -- this type has more issues, like direct access
to underlying storage.

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

From tracker at bugs.pypy.org  Wed Apr 11 10:28:00 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Wed, 11 Apr 2012 08:28:00 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334132880.3.0.462942331142.issue1120@bugs.pypy.org>


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

One issue though, the "sep" argument to PyUnicode_Split() can be NULL, the
equivalent of passing None in Python. Would this work?


diff -r 859f1579f2bd pypy/module/cpyext/test/test_unicodeobject.py
--- a/pypy/module/cpyext/test/test_unicodeobject.py     Tue Apr 10 23:19:41 2012
+0200
+++ b/pypy/module/cpyext/test/test_unicodeobject.py     Wed Apr 11 10:24:10 2012
+0200
@@ -474,11 +474,13 @@
         assert api.PyUnicode_Find(w_str, space.wrap(u"z"), 0, 4, -1) == -1
 
     def test_split(self, space, api):
-        w_str = space.wrap(u"a\nb\nc\nd")
-        assert "[u'a', u'b', u'c', u'd']" == space.unwrap(space.repr(
+        w_str = space.wrap(u"a\nb\nc\nd e")
+        assert "[u'a', u'b', u'c', u'd e']" == space.unwrap(space.repr(
                 api.PyUnicode_Split(w_str, space.wrap('\n'), -1)))
-        assert r"[u'a', u'b', u'c\nd']" == space.unwrap(space.repr(
+        assert r"[u'a', u'b', u'c\nd e']" == space.unwrap(space.repr(
                 api.PyUnicode_Split(w_str, space.wrap('\n'), 2)))
+        assert r"[u'a', u'b', u'c', u'd', u'e']" == space.unwrap(space.repr(
+                api.PyUnicode_Split(w_str, lltype.nullptr(PyObject.TO), -1)))
         assert "[u'a', u'b', u'c', u'd']" == space.unwrap(space.repr(
                 api.PyUnicode_Splitlines(w_str, 0)))
         assert r"[u'a\n', u'b\n', u'c\n', u'd']" == space.unwrap(space.repr(
diff -r 859f1579f2bd pypy/module/cpyext/unicodeobject.py
--- a/pypy/module/cpyext/unicodeobject.py       Tue Apr 10 23:19:41 2012 +0200
+++ b/pypy/module/cpyext/unicodeobject.py       Wed Apr 11 10:24:10 2012 +0200
@@ -630,6 +630,8 @@
     Otherwise, splits occur at the given separator.  At most maxsplit
     splits will be done.  If negative, no limit is set.  Separators
     are not included in the resulting list."""
+    if w_sep == lltype.nullptr(PyObject.TO):
+        w_sep = None
     return space.call_method(w_str, "split", w_sep, space.wrap(maxsplit))
 
 @cpython_api([PyObject, rffi.INT_real], PyObject)

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

From tracker at bugs.pypy.org  Wed Apr 11 10:47:36 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 11 Apr 2012 08:47:36 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1334134056.66.0.341089988021.issue1120@bugs.pypy.org>


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

> the "sep" argument to PyUnicode_Split() can be NULL

Oops, I overlooked this!
I'll try to fix it tonight.

> w_sep == lltype.nullptr(PyObject.TO)
This won't work: a w_obj is not a PyObject!
The NULL pointer is already converted to RPython None (which the C translator will write 
as a (pypy_object0*)NULL value...)
Maybe something like this will work:
    if w_sep is None:
        w_sep = space.w_None

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

From tracker at bugs.pypy.org  Wed Apr 11 10:52:31 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Wed, 11 Apr 2012 08:52:31 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334134351.66.0.542671623839.issue1122@bugs.pypy.org>


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

No, not meant as a contradiction. I think it's rather rare that user code would
call Py_SIZE() on builtin types that have their well and much more prominently
documented dedicated macros (Py_SIZE() is a rather new addition in comparison).
I find it more important that user code that implements PyVarObjects and calls
Py_SIZE() on them works as expected, regardless of the value in tp_itemsize.

I'm not strictly objecting, but I see it as an indirect condition that may not
work for all user code, so there is a certain risk that it makes the behaviour
of the macro less predictable, both by making it work substantially different in
some cases (in CPython, it never calls __len__(), which may execute arbitrary
code and fail) and by posing it on the assumption that all PyVarObjects have a
non-zero tp_itemsize, which will usually be the case, but is not a strict
requirement, e.g. for constant objects of length 0.

My intuition is that it's easier to control builtins than to know what
assumptions user code makes.

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

From tracker at bugs.pypy.org  Wed Apr 11 10:57:46 2012
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Wed, 11 Apr 2012 08:57:46 +0000
Subject: [pypy-issue] [issue1049] Source releases should be pypy-<v> not
	pypy-pypy-<hash>
In-Reply-To: <1329324245.08.0.0479236005649.issue1049@bugs.pypy.org>
Message-ID: <1334134666.03.0.591628496592.issue1049@bugs.pypy.org>


Laurence Tratt <laurie at tratt.net> added the comment:

It's only possible for someone inside the PyPy group to do this. I would have
thought something like the following shell commands should do the trick:

  export V=1.8
  t=`mktemp -d`
  cd $t
  wget https://bitbucket.org/pypy/pypy/get/release-${V}.tar.bz2
  bunzip2 -c - release-${V}.tar.bz2 | tar xfp -
  mv pypy-* pypy-${V}
  tar cf pypy-${V}.tar pypy-${V}
  bzip2 pypy-${V}.tar
  <upload to https://bitbucket.org/pypy/pypy/downloads/>

That's all tested (except the last line!). It might be
that you want to call the file created pypy-src-${V} - that's a pretty easy
change.

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

From tracker at bugs.pypy.org  Wed Apr 11 11:03:59 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 11 Apr 2012 09:03:59 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334135039.07.0.0813622423727.issue1122@bugs.pypy.org>


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

Are you suggesting to not change anything then?

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

From tracker at bugs.pypy.org  Wed Apr 11 11:20:28 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Wed, 11 Apr 2012 09:20:28 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334136028.33.0.209116032188.issue1122@bugs.pypy.org>


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

I would prefer changing the builtin types instead of the macro. Especially since
changing the immutable types has the side effect of making access to their size
fast for C code.

Remember that a lot of CPython C-API code will never work unchanged in PyPy -
switching from Py_SIZE() to PyList_GET_SIZE() is really no big deal compared to
e.g. fixing up the usage of borrowed references.

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

From tracker at bugs.pypy.org  Wed Apr 11 11:36:39 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 11 Apr 2012 09:36:39 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334136999.4.0.538629647191.issue1122@bugs.pypy.org>


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

> I would prefer changing the builtin types instead of the macro.
But why?  since Py_SIZE() usage is discouraged for builtin type, which code 
would benefit of a mirrored ob_size?

Anyway, is there code that expects Py_SIZE() to be fast and allow 
PyList_GET_ITEM to be very expensive?

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

From tracker at bugs.pypy.org  Wed Apr 11 12:10:19 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Wed, 11 Apr 2012 10:10:19 +0000
Subject: [pypy-issue] [issue1122] [cpyext] PyVarObject builtins and
	definition of Py_SIZE()
In-Reply-To: <1334091051.32.0.97229251386.issue1122@bugs.pypy.org>
Message-ID: <1334139019.67.0.830598581027.issue1122@bugs.pypy.org>


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

> since Py_SIZE() usage is discouraged for builtin type, which code 
> would benefit of a mirrored ob_size?

Code that uses PyTuple_GET_SIZE(), for example, once that macro translates into
((PyTupleObject*)obj)->ob_size

> Anyway, is there code that expects Py_SIZE() to be fast and allow 
> PyList_GET_ITEM to be very expensive?

I agree that quickly accessing the size is dwarfed by the comparison to
accessing the items - I consider it a nice side effect, not the ultimate
performance booster.

The real problem I see is the potential change in behaviour for non-builtins.

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

From tracker at bugs.pypy.org  Wed Apr 11 14:05:39 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 11 Apr 2012 12:05:39 +0000
Subject: [pypy-issue] [issue1112] numpypy swapaxes patch
In-Reply-To: <1333404216.35.0.0841527968611.issue1112@bugs.pypy.org>
Message-ID: <1334145939.6.0.686544054207.issue1112@bugs.pypy.org>


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

New patch attached

>> * Can you add tests for doing this on slices and virtual arrays?
I'm not entirely certain how to do this, so I added what I think are tests to cover 
these. Can someone check?

>> * You don't need a loop in there, strides = concrete.strides[:] (etc.) should be 
enough.
Fixed.

>> * Can you bring in numpy.swapaxes into lib_pypy/numpypy/, should just be a copy-
paste from upstream numpy?
Added.  The numpy code does this:
    try:
        swapaxes = a.swapaxes
    except AttributeError:
        return _wrapit(a, 'swapaxes', axis1, axis2)
    return swapaxes(axis1, axis2)

Since numpypy works a bit differently, I don't think we have/need the _wrapit(), so I 
just did the following so it looks similar.
  swapaxes = a.swapaxes
  return swapaxes(axis1, axis2)

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

From tracker at bugs.pypy.org  Wed Apr 11 17:39:34 2012
From: tracker at bugs.pypy.org (Robert Zaremba)
Date: Wed, 11 Apr 2012 15:39:34 +0000
Subject: [pypy-issue] [issue1123] PyPy 1.8 15 times slower than cPython2.7
In-Reply-To: <1334158774.02.0.572258203308.issue1123@bugs.pypy.org>
Message-ID: <1334158774.02.0.572258203308.issue1123@bugs.pypy.org>


New submission from Robert Zaremba <robert.marek.zaremba at wp.eu>:

I've tested hash function for performance.
The results are as follows:
md5 (stdlib)
~   ~   ~   ~   python  3.495
~   ~   ~   ~   pypy~   3.621
mmh3
~   ~   ~   ~   python  0.433
~   ~   ~   ~   pypy    6.186
smhasher
~   ~   ~   ~   python  0.441
~   ~   ~   ~   pypy~   5.877
lookup3
~   ~   ~   ~   python  1.693
~   ~   ~   ~   pypy ~  7.963
pyhash
~   ~   ~   ~   python  0.00022
~   ~   ~   ~   pypy~   -- unsupported


every library goes as an interface to c++ code.
Why the problem is with 3-part-packages, and md5 goes well?
In attachment the file witch performs tests. It requires some file (In my case 
the average file I want to hash in production will be 200KB) from witch to read 
data to hash

----------
files: run.py
messages: 4239
nosy: pypy-issue, yahazee
priority: performance bug
status: unread
title: PyPy 1.8   15 times slower than cPython2.7

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

From tracker at bugs.pypy.org  Wed Apr 11 18:01:29 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 11 Apr 2012 16:01:29 +0000
Subject: [pypy-issue] [issue1123] PyPy 1.8 15 times slower than cPython2.7
In-Reply-To: <1334158774.02.0.572258203308.issue1123@bugs.pypy.org>
Message-ID: <1334160089.47.0.311354011938.issue1123@bugs.pypy.org>


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

PyPy supports the Python C API for extension modules, but it is known to be *very* slow.

Just to give an idea why, pypy objects are movable, so the usual PyObject* pointer is an 
emulation and a dictionary lookup is needed each time the pypy/C border is crossed.

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

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

From tracker at bugs.pypy.org  Wed Apr 11 22:36:39 2012
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 11 Apr 2012 20:36:39 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1334176599.86.0.237487210865.issue1116@bugs.pypy.org>


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

sounds like i ran into the same bug. this script highlights the problem. it
produces an exception on pypy default head, not on python 2.7.2

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

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

From tracker at bugs.pypy.org  Wed Apr 11 23:00:26 2012
From: tracker at bugs.pypy.org (bdk)
Date: Wed, 11 Apr 2012 21:00:26 +0000
Subject: [pypy-issue] [issue747] fcntl.lockf() is broken with (fcntl.LOCK_EX
	|	fcntl.LOCK_NB)
In-Reply-To: <1307775802.38.0.717100903574.issue747@bugs.pypy.org>
Message-ID: <1334178026.05.0.0868416001445.issue747@bugs.pypy.org>


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

still broken in nightly

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

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

From tracker at bugs.pypy.org  Wed Apr 11 23:02:15 2012
From: tracker at bugs.pypy.org (Lateef Jackson)
Date: Wed, 11 Apr 2012 21:02:15 +0000
Subject: [pypy-issue] [issue1124] Memory usage parsing JSON
In-Reply-To: <1334178135.45.0.45818048329.issue1124@bugs.pypy.org>
Message-ID: <1334178135.45.0.45818048329.issue1124@bugs.pypy.org>


New submission from Lateef Jackson <lateef.jackson at gmail.com>:

There are 3 files that are Python in bitbucket: 
https://bitbucket.org/lateefj/dart_compare/src/9192e74713ca/json
Basically I was just kicking the tires comparing Dart, Go, Python and PyPy. After 
generating a file with 10K json documents in it I then compared the runtime and 
memory of each language. PyPy memory seemed really high compared to the other 
languages. The previous comparions 
(https://bitbucket.org/lateefj/dart_compare/src/9192e74713ca/fib) PyPy performed 
awesomely. Just trying to do the right thing by reporting it.

----------
messages: 4243
nosy: lateefj, pypy-issue
priority: wish
status: unread
title: Memory usage parsing JSON

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

From tracker at bugs.pypy.org  Thu Apr 12 02:16:25 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 12 Apr 2012 00:16:25 +0000
Subject: [pypy-issue] [issue1125] numpypy much slower than list
	implementation
In-Reply-To: <1334189785.11.0.964947359383.issue1125@bugs.pypy.org>
Message-ID: <1334189785.11.0.964947359383.issue1125@bugs.pypy.org>


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

On the Numba mailing list, I came across a test case where numpypy was much slower 
than a list implementation, and I thought this might a useful benchmark.


http://librelist.com/browser//numba/2012/3/29/numba-numpy-optimization/

The function is "pairwise distance function to calculate the
Haversin distance between all points in two vectors"

https://bitbucket.org/FedericoV/numpy-tip-complex-
modeling/src/d83acacabda1/src/simulations

List Implementation: 2.00559
C-List Implementation: 0.28070
Numpy Implementation: 0.29622
Cython Implementation: 0.19165
Numexpr Implementation: 0.09320

Using PyPy:
List Implementation: 0.27367
Numpy Implementation: 4.48617

----------
messages: 4244
nosy: mikefc, pypy-issue
priority: performance bug
status: unread
title: numpypy much slower than list implementation

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

From tracker at bugs.pypy.org  Thu Apr 12 04:15:19 2012
From: tracker at bugs.pypy.org (Hong Minhee)
Date: Thu, 12 Apr 2012 02:15:19 +0000
Subject: [pypy-issue] [issue1126] __exit__ is not called when an exception
	raised inside of	generator
In-Reply-To: <1334196919.83.0.370220431937.issue1126@bugs.pypy.org>
Message-ID: <1334196919.83.0.370220431937.issue1126@bugs.pypy.org>


New submission from Hong Minhee <minhee at dahlia.kr>:

It seems that PyPy does not call __exit__ of context used inside generator when an 
exception raised.

Complicated to explain, so I attached a code that reproduces this bug.  It works 
correctly on CPython 2.7 but not on PyPy 1.8.

    $ python2.7 reprod.py 
    2.7.3 (default, Apr 10 2012, 12:29:04) 
    [GCC 4.6.3]
    inner: (<type 'exceptions.GeneratorExit'>, GeneratorExit(), <traceback object at 
0xc0dfc8>)
    outer: (<type 'exceptions.Exception'>, Exception(), <traceback object at 
0xc0dfc8>)
    dirty = False

    $ pypy reprod.py 
    2.7.2 (1.8+dfsg-2, Feb 19 2012, 19:18:08)
    [PyPy 1.8.0 with GCC 4.6.2]
    outer: (<type 'exceptions.Exception'>, Exception(), <traceback object at 
0x00007f4ca70c6b20>)
    dirty = True

Thanks.

----------
files: reprod.py
messages: 4245
nosy: pypy-issue
priority: bug
status: unread
title: __exit__ is not called when an exception raised inside of generator

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

From tracker at bugs.pypy.org  Thu Apr 12 04:34:08 2012
From: tracker at bugs.pypy.org (Benjamin Peterson)
Date: Thu, 12 Apr 2012 02:34:08 +0000
Subject: [pypy-issue] [issue1126] __exit__ is not called when an exception
	raised inside of	generator
In-Reply-To: <1334196919.83.0.370220431937.issue1126@bugs.pypy.org>
Message-ID: <1334198048.74.0.176136396433.issue1126@bugs.pypy.org>


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

You need to either wait for or explicitly run the gc.

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

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

From tracker at bugs.pypy.org  Thu Apr 12 04:43:18 2012
From: tracker at bugs.pypy.org (Hong Minhee)
Date: Thu, 12 Apr 2012 02:43:18 +0000
Subject: [pypy-issue] [issue1126] __exit__ is not called when an exception
	raised inside of	generator
In-Reply-To: <1334196919.83.0.370220431937.issue1126@bugs.pypy.org>
Message-ID: <1334198598.02.0.964979281909.issue1126@bugs.pypy.org>


Hong Minhee <minhee at dahlia.kr> added the comment:

Sorry but I did not understand well.  Should not __exit__ be called before an 
exception is caught or a program terminates at least?  The code I attached never 
calls __exit__ even the program has terminated.

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

From tracker at bugs.pypy.org  Thu Apr 12 05:29:11 2012
From: tracker at bugs.pypy.org (Benjamin Peterson)
Date: Thu, 12 Apr 2012 03:29:11 +0000
Subject: [pypy-issue] [issue1126] __exit__ is not called when an exception
	raised inside of	generator
In-Reply-To: <1334196919.83.0.370220431937.issue1126@bugs.pypy.org>
Message-ID: <1334201351.47.0.751681262688.issue1126@bugs.pypy.org>


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

This is what I mean.

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

From tracker at bugs.pypy.org  Thu Apr 12 09:49:16 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 12 Apr 2012 07:49:16 +0000
Subject: [pypy-issue] [issue1126] __exit__ is not called when an exception
	raised inside of	generator
In-Reply-To: <1334196919.83.0.370220431937.issue1126@bugs.pypy.org>
Message-ID: <1334216956.32.0.898916825835.issue1126@bugs.pypy.org>


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

The issue is the "yield" inside the "with".  Allowing this as valid syntax is
IMHO a broken decision from CPython.  This "with" block will terminate only when
next() is called (never here) or when the complete generator is
gargabe-collected (which means "at some point in the future probably" if you
don't have reference counting).

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

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

From tracker at bugs.pypy.org  Thu Apr 12 10:26:40 2012
From: tracker at bugs.pypy.org (Robert Zaremba)
Date: Thu, 12 Apr 2012 08:26:40 +0000
Subject: [pypy-issue] [issue1123] PyPy 1.8 15 times slower than cPython2.7
In-Reply-To: <1334158774.02.0.572258203308.issue1123@bugs.pypy.org>
Message-ID: <1334219200.26.0.641675057607.issue1123@bugs.pypy.org>


Robert Zaremba <robert.marek.zaremba at wp.eu> added the comment:

Thanks for comment.
I'm curious, how md5 from stdlib is comparable fast? PyPy rewrites it to pure 
python?

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

From tracker at bugs.pypy.org  Thu Apr 12 11:17:05 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Thu, 12 Apr 2012 09:17:05 +0000
Subject: [pypy-issue] [issue1127] [cpyext] PyUnicode_Tailmatch()
	misinterprets direction	flag
In-Reply-To: <1334222225.0.0.309233673416.issue1127@bugs.pypy.org>
Message-ID: <1334222225.0.0.309233673416.issue1127@bugs.pypy.org>


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

The (not very straight forward) interpretation of the "direction" flag in
PyUnicode_Tailmatch() is that -1 denotes a prefix match and 1 a suffix match.
cpyext currently does it the other way round.

http://docs.python.org/c-api/unicode.html#PyUnicode_Tailmatch

Untested patch (also for the test cases) is attached.

----------
files: tailmatch.patch
messages: 4251
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] PyUnicode_Tailmatch() misinterprets direction flag

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

From tracker at bugs.pypy.org  Thu Apr 12 13:33:25 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 12 Apr 2012 11:33:25 +0000
Subject: [pypy-issue] [issue1123] PyPy 1.8 15 times slower than cPython2.7
In-Reply-To: <1334158774.02.0.572258203308.issue1123@bugs.pypy.org>
Message-ID: <1334230405.39.0.74383193664.issue1123@bugs.pypy.org>


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

It's written in RPython (PyPy's implementation lanaguage). I'll close this 
issue,
but not because we're not interested, I just suppose a better way to discuss 
this more would be on the mailing list?

Feel free to reopen if you feel otherwise.

Cheers,
fijal

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

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

From tracker at bugs.pypy.org  Fri Apr 13 12:05:50 2012
From: tracker at bugs.pypy.org (reportmp)
Date: Fri, 13 Apr 2012 10:05:50 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1334311550.81.0.0456940911305.issue1115@bugs.pypy.org>


reportmp <f232684 at rppkn.com> added the comment:

Ok, this is a s*it project just for cpu benchmark m*sturbation.
The sh*t code write from a group of mentally handicapped fool will cost many
memory and very unstable.
Bye, idiots !

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

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

From tracker at bugs.pypy.org  Fri Apr 13 12:20:03 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 13 Apr 2012 10:20:03 +0000
Subject: [pypy-issue] [issue1115] build error with some options
In-Reply-To: <1333549666.91.0.701667442323.issue1115@bugs.pypy.org>
Message-ID: <1334312403.42.0.278442599299.issue1115@bugs.pypy.org>


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

Uh, are you annoyed that we didn't answer you in 9 days?  Sorry, I don't follow
each issue every day...

I'm just saying that even on total memory usage, I fear that you cannot have big
wins by specifying any extra option.  Nowadays, the default options for
PyPy-with-JIT are the same as the options that tend to reduce memory usage. 
There are probably small wins to have but no big win.

Even the --gcremovetypeptr option goes into the "small-to-medium" category; it's
not as good as the other optimization we talk about in
http://morepypy.blogspot.com/2009/10/gc-improvements.html --- and that one is on
by default.

Sorry if your program still ends up much bigger on PyPy than on CPython.  This
is the case e.g. if you program is mainly simple var-sized objects like strings,
lists, dicts, and so on --- as opposed to mainly being instances.  You can get
better wins by playing with the GC environment variables, which give at run-time
trade-offs of speed versus memory. 
https://bitbucket.org/pypy/pypy/raw/default/pypy/rpython/memory/gc/minimark.py

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

From tracker at bugs.pypy.org  Fri Apr 13 16:52:00 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Fri, 13 Apr 2012 14:52:00 +0000
Subject: [pypy-issue] [issue1124] Memory usage parsing JSON
In-Reply-To: <1334178135.45.0.45818048329.issue1124@bugs.pypy.org>
Message-ID: <1334328720.37.0.266589051829.issue1124@bugs.pypy.org>


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

you might want to do a gc.collect() to check if the memory usage is just caused
by not yet having run a major collection

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

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

From tracker at bugs.pypy.org  Fri Apr 13 17:20:50 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 13 Apr 2012 15:20:50 +0000
Subject: [pypy-issue] [issue1124] Memory usage parsing JSON
In-Reply-To: <1334178135.45.0.45818048329.issue1124@bugs.pypy.org>
Message-ID: <1334330450.33.0.277366112052.issue1124@bugs.pypy.org>


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

Hi. We have to look at the performance of pypy's json parser. it seems it creates 
lots of garbage, hence being slow and consuming lots of memory. It is on my todo 
list, together with other things though :

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

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

From tracker at bugs.pypy.org  Fri Apr 13 19:27:47 2012
From: tracker at bugs.pypy.org (bdk)
Date: Fri, 13 Apr 2012 17:27:47 +0000
Subject: [pypy-issue] [issue1116] AttributeError: 'GzipFile' object has no
	attribute	'fileobj' with Django
In-Reply-To: <1333803911.78.0.097570550756.issue1116@bugs.pypy.org>
Message-ID: <1334338067.95.0.831127774537.issue1116@bugs.pypy.org>


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

and as a note, adding gc collect to the end of test_gzip.py doesn't solve the
AttributeError on exit

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

From tracker at bugs.pypy.org  Fri Apr 13 20:24:47 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Fri, 13 Apr 2012 18:24:47 +0000
Subject: [pypy-issue] [issue1128] add the possibility to search on the
	release field on	roundup
In-Reply-To: <1334341487.64.0.694725686163.issue1128@bugs.pypy.org>
Message-ID: <1334341487.64.0.694725686163.issue1128@bugs.pypy.org>


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

there should be a way to display all the issues which belongs to a specific release

----------
assignedto: ronny
messages: 4258
nosy: pypy-issue, ronny
priority: feature
status: unread
title: add the possibility to search on the release field on roundup

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

From tracker at bugs.pypy.org  Sat Apr 14 12:06:24 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 14 Apr 2012 10:06:24 +0000
Subject: [pypy-issue] [issue1112] numpypy swapaxes patch
In-Reply-To: <1333404216.35.0.0841527968611.issue1112@bugs.pypy.org>
Message-ID: <1334397984.19.0.852967622858.issue1112@bugs.pypy.org>


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

committed after talking with fijal on irc.

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

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

From tracker at bugs.pypy.org  Sat Apr 14 14:12:19 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 14 Apr 2012 12:12:19 +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: <1334405539.73.0.195200817589.issue1129@bugs.pypy.org>


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

Found this bug while looking at numpy/lib/financial.py definition of rate() method.

It seems that the reduce_ufunc_impls in numpypy (any, all, min, max etc) don't work with 
scalars, but they do in numpy.


=================================
python
Python 2.7.2 (default, Feb  2 2012, 22:10:10) 
[GCC 4.2.1 Compatible Apple Clang 3.0 (tags/Apple/clang-211.12)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.all(1)
True
>>> np.any(1)
True
>>> np.min(1)
1
>>> np.sum(1)
1


===============================
~/pypy-latest/bin/pypy 
Python 2.7.2 (1da1c1632353, Apr 13 2012, 01:00:24)
[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: ``The migration to mercurial is
completed! http://bitbucket.org/pypy/pypy''
>>>> import numpypy as np
>>>> np.all(1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Users/mike/pypy-latest/lib_pypy/numpypy/core/fromnumeric.py", line 1545, in all
    return a.all()
TypeError: cannot reduce on a scalar
>>>> np.any(1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Users/mike/pypy-latest/lib_pypy/numpypy/core/fromnumeric.py", line 1481, in any
    return a.any()
TypeError: cannot reduce on a scalar
>>>> np.min(1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: cannot reduce on a scalar
>>>> np.sum(1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Users/mike/pypy-latest/lib_pypy/numpypy/core/fromnumeric.py", line 1365, in sum
    return a.sum(axis=axis)
TypeError: cannot reduce on a scalar

----------
messages: 4260
nosy: mikefc, pypy-issue
priority: bug
status: unread
title: numpypy reduce methods don't work with scalars

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

From tracker at bugs.pypy.org  Sat Apr 14 15:45:29 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 14 Apr 2012 13:45:29 +0000
Subject: [pypy-issue] [issue1130] numpypy indexing of 1d arrays doesn't
	match numpy
In-Reply-To: <1334411129.8.0.658879495202.issue1130@bugs.pypy.org>
Message-ID: <1334411129.8.0.658879495202.issue1130@bugs.pypy.org>


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

Indexing of 1d arrays appears to be a special case that numpypy doesn't handle the same as 
numpy.

================================
python
>>> import numpy as np
>>> np.array([10,11,12,13])[[1,2]] 
array([11, 12])

===============================
Python 2.7.2 (1da1c1632353, Apr 13 2012, 01:00:24)
[PyPy 1.9.1-dev0 with GCC 4.2.1] on darwin
>>>> import numpypy as np
>>>> np.array([10,11,12,13])[[1,2]]
Traceback (most recent call last):
  File "<console>", line 1, in <module>
IndexError: invalid index

----------
messages: 4261
nosy: mikefc, pypy-issue
priority: bug
status: unread
title: numpypy indexing of 1d arrays doesn't match numpy

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

From tracker at bugs.pypy.org  Sun Apr 15 01:09:51 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 14 Apr 2012 23:09:51 +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: <1334444991.44.0.734335293612.issue1130@bugs.pypy.org>


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

Found something else amiss with indexing where lists and tuples should be treated 
differently.

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


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

----------
status: unread -> chatting
title: numpypy indexing of 1d arrays doesn't match numpy -> numpypy indexing of arrays with lists doesn't match numpy

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

From tracker at bugs.pypy.org  Sun Apr 15 08:58:16 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 15 Apr 2012 06:58:16 +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: <1334473096.89.0.67302116722.issue1130@bugs.pypy.org>


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

Hi

This is a part of "fancy indexing with int arrays" that's not implemented yet. 
Let's keep this ticket open though

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

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

From tracker at bugs.pypy.org  Tue Apr 17 00:15:59 2012
From: tracker at bugs.pypy.org (Thomas Waldmann)
Date: Mon, 16 Apr 2012 22:15:59 +0000
Subject: [pypy-issue] [issue1131] in operator: return value of __contains__
	is not coerced	to bool
In-Reply-To: <1334614559.88.0.564019203044.issue1131@bugs.pypy.org>
Message-ID: <1334614559.88.0.564019203044.issue1131@bugs.pypy.org>


New submission from Thomas Waldmann <tw-public at gmx.de>:

cpython 2.7 applies a bool() conversion to the return value of __contains__.

pypy 1.8 does not. if one returns an integer, the result of the "in" operator is
that integer.

(I noticed this with a failing unit test in whoosh, it only fails for pypy.)

----------
messages: 4264
nosy: ThomasWaldmann, pypy-issue
priority: bug
release: 1.8
status: unread
title: in operator: return value of __contains__ is not coerced to bool

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

From tracker at bugs.pypy.org  Tue Apr 17 11:12:13 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 17 Apr 2012 09:12:13 +0000
Subject: [pypy-issue] [issue1131] in operator: return value of __contains__
	is not coerced	to bool
In-Reply-To: <1334614559.88.0.564019203044.issue1131@bugs.pypy.org>
Message-ID: <1334653933.4.0.568125113667.issue1131@bugs.pypy.org>


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

fixed in 3efbde36c6ed

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

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

From tracker at bugs.pypy.org  Tue Apr 17 11:25:50 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Tue, 17 Apr 2012 09:25:50 +0000
Subject: [pypy-issue] [issue1131] in operator: return value of __contains__
	is not coerced	to bool
In-Reply-To: <1334614559.88.0.564019203044.issue1131@bugs.pypy.org>
Message-ID: <1334654750.23.0.0662289357033.issue1131@bugs.pypy.org>


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

even more fixed by cf29881e5624 :-) (hopefully)

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

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

From tracker at bugs.pypy.org  Tue Apr 17 16:33:56 2012
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Tue, 17 Apr 2012 14:33:56 +0000
Subject: [pypy-issue] [issue1132] Bugs in Unicode data
In-Reply-To: <1334673236.4.0.147004791222.issue1132@bugs.pypy.org>
Message-ID: <1334673236.4.0.147004791222.issue1132@bugs.pypy.org>


New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:

PyPy seems to have a bug in the unicodedata names:


Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.name(40900)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: must be unicode, not int
>>> unicodedata.name(unichr(40900))
'CJK UNIFIED IDEOGRAPH-9FC4'
>>> 
david at Yate ~/Code/pypy/pypy/module/unicodedata % pypy
Python 2.7.2 (0f03693b05ac, Feb 18 2012, 15:27:02)
[PyPy 1.8.1-dev0] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "app_main.py", line 576, in run_it
  File "/Users/david/.pystartup", line 21, in <module>
    import fancycompleter
ImportError: No module named fancycompleter
And now for something completely different: ``"All problems in PyPy can be
solved by another level of interpretation"''
>>>> import unicodedata
>>>> unicodedata.name(unichr(40900))
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ValueError: no such name
>>>> 


There's even a test that would have caught this, but it's skipped on Python2.6
(which the tannit buildbot is using):

pypy/module/unicodedata/test/test_unicodedata.py test_random_charnames

----------
messages: 4267
nosy: cfbolz, pypy-issue
priority: bug
status: unread
title: Bugs in Unicode data

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

From tracker at bugs.pypy.org  Tue Apr 17 18:01:50 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 17 Apr 2012 16:01:50 +0000
Subject: [pypy-issue] [issue1132] Bugs in Unicode data
In-Reply-To: <1334673236.4.0.147004791222.issue1132@bugs.pypy.org>
Message-ID: <1334678510.64.0.740466381183.issue1132@bugs.pypy.org>


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

9FC4 is just above 9FBB which was the last CJK character with Unicode 4.1.
This constant should be updated!

+keyword:easy

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

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

From tracker at bugs.pypy.org  Tue Apr 17 22:43:28 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 17 Apr 2012 20:43:28 +0000
Subject: [pypy-issue] [issue1127] [cpyext] PyUnicode_Tailmatch()
	misinterprets direction	flag
In-Reply-To: <1334222225.0.0.309233673416.issue1127@bugs.pypy.org>
Message-ID: <1334695408.27.0.263816920297.issue1127@bugs.pypy.org>


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

Indeed, PyUnicode_Tailmatch "direction" is straight backwards... fixed with 
11d96d5e877f.

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

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

From tracker at bugs.pypy.org  Tue Apr 17 23:29:52 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Tue, 17 Apr 2012 21:29:52 +0000
Subject: [pypy-issue] [issue1117] Can't find library path from PATH
In-Reply-To: <1333905289.15.0.416209681715.issue1117@bugs.pypy.org>
Message-ID: <1334698192.63.0.962645386146.issue1117@bugs.pypy.org>


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

any ideas for writing a test for this one?

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

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

From tracker at bugs.pypy.org  Wed Apr 18 09:48:37 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Wed, 18 Apr 2012 07:48:37 +0000
Subject: [pypy-issue] [issue1127] [cpyext] PyUnicode_Tailmatch()
	misinterprets direction	flag
In-Reply-To: <1334222225.0.0.309233673416.issue1127@bugs.pypy.org>
Message-ID: <1334735317.54.0.992903658772.issue1127@bugs.pypy.org>


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

Thanks.

Note that I had added some more tests in my patch. I don't think it
hurts to have them in.

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

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

From tracker at bugs.pypy.org  Wed Apr 18 10:08:12 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 18 Apr 2012 08:08:12 +0000
Subject: [pypy-issue] [issue1127] [cpyext] PyUnicode_Tailmatch()
	misinterprets direction	flag
In-Reply-To: <1334222225.0.0.309233673416.issue1127@bugs.pypy.org>
Message-ID: <1334736492.66.0.638624530856.issue1127@bugs.pypy.org>


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

Oh sorry, I did not see your patch :(
(they are not included in tracker notification emails, unlike bugs.python.org)
I will include your tests.

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

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

From tracker at bugs.pypy.org  Wed Apr 18 20:36:40 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 18 Apr 2012 18:36:40 +0000
Subject: [pypy-issue] [issue1127] [cpyext] PyUnicode_Tailmatch()
	misinterprets direction	flag
In-Reply-To: <1334222225.0.0.309233673416.issue1127@bugs.pypy.org>
Message-ID: <1334774200.48.0.481998280005.issue1127@bugs.pypy.org>


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

Tests updated with b58494d41466, thanks!

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

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

From tracker at bugs.pypy.org  Wed Apr 18 22:55:58 2012
From: tracker at bugs.pypy.org (mattip)
Date: Wed, 18 Apr 2012 20:55:58 +0000
Subject: [pypy-issue] [issue1133] changeset 79034a42a195 broke os.access
In-Reply-To: <1334782558.13.0.849966432641.issue1133@bugs.pypy.org>
Message-ID: <1334782558.13.0.849966432641.issue1133@bugs.pypy.org>


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

The changeset removed steemingly needless imports of ll_time and ll_os in
traslator/c/extfunc.py. 
It caused "pytest.py rpython/module/test/test_ll_os.py -k test_access to fail.

----------
messages: 4274
nosy: mattip, pypy-issue
priority: bug
status: unread
title: changeset 79034a42a195 broke os.access

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

From tracker at bugs.pypy.org  Thu Apr 19 20:25:47 2012
From: tracker at bugs.pypy.org (mattip)
Date: Thu, 19 Apr 2012 18:25:47 +0000
Subject: [pypy-issue] [issue1133] changeset 79034a42a195 broke os.access
In-Reply-To: <1334782558.13.0.849966432641.issue1133@bugs.pypy.org>
Message-ID: <1334859947.91.0.869149350559.issue1133@bugs.pypy.org>


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

adding import to test in changeset 3afde514d040 fixes this.

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

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

From tracker at bugs.pypy.org  Fri Apr 20 10:10:18 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 20 Apr 2012 08:10:18 +0000
Subject: [pypy-issue] [issue1064] NumPy Contribution
In-Reply-To: <1329790715.38.0.905612431591.issue1064@bugs.pypy.org>
Message-ID: <1334909417.97.0.362040299197.issue1064@bugs.pypy.org>


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

I think I'll close that one. please reopen when there is a patch

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

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

From tracker at bugs.pypy.org  Fri Apr 20 21:34:47 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Fri, 20 Apr 2012 19:34:47 +0000
Subject: [pypy-issue] [issue1121] [cpyext] speed up some macros
In-Reply-To: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>
Message-ID: <1334950487.07.0.579917395358.issue1121@bugs.pypy.org>


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

For the ref-counting macros, here is a "stupid micro benchmark" in Cython:

def bench(x):
    cdef int i
    for i in xrange(10000):
        a = x
        b = x
        c = x
        d = x
        e = x
        f = x
        g = x

When always calling into Py_IncRef() and Py_DecRef(), I get this

$ pypy -m timeit -s 'from refcountbench import bench' 'bench(10)'
1000 loops, best of 3: 683 usec per loop

With the new macros for Py_INCREF() and Py_DECREF(), I get this:

$ pypy -m timeit -s 'from refcountbench import bench' 'bench(10)'
1000 loops, best of 3: 385 usec per loop

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

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

From tracker at bugs.pypy.org  Sat Apr 21 19:09:33 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Sat, 21 Apr 2012 17:09:33 +0000
Subject: [pypy-issue] [issue1134] [cpyext] wrap_inquirypred not implemented
In-Reply-To: <1335028173.51.0.145444562763.issue1134@bugs.pypy.org>
Message-ID: <1335028173.51.0.145444562763.issue1134@bugs.pypy.org>


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

I'm getting a crash trying to port lxml:

RPython traceback:
  File "interpreter_gateway.c", line 1396, in
BuiltinCodePassThroughArguments1_funcrun_obj
  File "module_cpyext_slotdefs.c", line 2858, in wrap_inquirypred
Fatal RPython error: NotImplementedError

This happens while calling PyObject_IsTrue() on an extension type instance that
implements the __nonzero__ slot. The only reference to "wrap_inquirypred" that I
can find in the sources is in pypy/module/cpyext/slotdefs.py, where it is being
used to configure the slot:

UNSLOT("__nonzero__", nb_nonzero, slot_nb_nonzero, wrap_inquirypred,
       "x != 0"),

but the actual implementation is missing. CPython implements it like this:

static PyObject *
wrap_inquirypred(PyObject *self, PyObject *args, void *wrapped)
{
    inquiry func = (inquiry)wrapped;
    int res;

    if (!check_num_args(args, 0))
        return NULL;
    res = (*func)(self);
    if (res == -1 && PyErr_Occurred())
        return NULL;
    return PyBool_FromLong((long)res);
}

where inquiry is defined like this:

typedef int (*inquiry)(PyObject *);

----------
messages: 4278
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] wrap_inquirypred not implemented

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

From tracker at bugs.pypy.org  Sat Apr 21 19:58:21 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Sat, 21 Apr 2012 17:58:21 +0000
Subject: [pypy-issue] [issue1135] [cpyext] PyObject_CallMethod() does not
	handle format ==	NULL
In-Reply-To: <1335031101.46.0.00411917682173.issue1135@bugs.pypy.org>
Message-ID: <1335031101.46.0.00411917682173.issue1135@bugs.pypy.org>


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

In CPython, PyObject_CallMethod(obj, "method", NULL) is a shortcut for calling
the method without arguments. This case is not handled in cpyext, which passes
the format straight into Py_VaBuildValue().

----------
messages: 4279
nosy: pypy-issue, sbehnel
priority: bug
status: unread
title: [cpyext] PyObject_CallMethod() does not handle format == NULL

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

From tracker at bugs.pypy.org  Sat Apr 21 20:03:28 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Sat, 21 Apr 2012 18:03:28 +0000
Subject: [pypy-issue] [issue1135] [cpyext] PyObject_CallMethod() does not
	handle format ==	NULL
In-Reply-To: <1335031101.46.0.00411917682173.issue1135@bugs.pypy.org>
Message-ID: <1335031408.36.0.917338884864.issue1135@bugs.pypy.org>


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

Actually, also the case of an empty format string is not handled. In that case,
 Py_VaBuildValue() returns None instead of an empty tuple, as required for the
arguments.

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

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

From tracker at bugs.pypy.org  Sat Apr 21 20:14:05 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Sat, 21 Apr 2012 18:14:05 +0000
Subject: [pypy-issue] [issue1135] [cpyext] PyObject_CallMethod() does not
	handle format ==	NULL
In-Reply-To: <1335031101.46.0.00411917682173.issue1135@bugs.pypy.org>
Message-ID: <1335032045.45.0.622596031447.issue1135@bugs.pypy.org>


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

Argh - sorry, I looked in the wrong spot: this applies to PyEval_CallMethod()
instead of PyObject_CallMethod(), and surprisingly enough, CPython also doesn't
handle the format == NULL case for the PyEval function. Weird...

Closing this bug as "works as designed".

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

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

From tracker at bugs.pypy.org  Sat Apr 21 23:47:37 2012
From: tracker at bugs.pypy.org (timo)
Date: Sat, 21 Apr 2012 21:47:37 +0000
Subject: [pypy-issue] [issue1136] "list index must be integer, not int64"
In-Reply-To: <1335044857.21.0.688675278158.issue1136@bugs.pypy.org>
Message-ID: <1335044857.21.0.688675278158.issue1136@bugs.pypy.org>


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

In this line of code, palette is a list and line is a numpy array:

    newline = "".join(self.PALETTE[value] for value in line)

the error is "list index must be integer, not int64".

----------
messages: 4282
nosy: pypy-issue, timo
priority: bug
status: unread
title: "list index must be integer, not int64"

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

From tracker at bugs.pypy.org  Sat Apr 21 23:50:27 2012
From: tracker at bugs.pypy.org (timo)
Date: Sat, 21 Apr 2012 21:50:27 +0000
Subject: [pypy-issue] [issue1137] "TypeError: 'int32' has no length"
In-Reply-To: <1335045027.45.0.646991371551.issue1137@bugs.pypy.org>
Message-ID: <1335045027.45.0.646991371551.issue1137@bugs.pypy.org>


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

>>>> import numpypy as np
>>>> a = np.zeros((10,), "int32")
>>>> b = np.ones((5,), "int32")
>>>> for num in b: a[num] += 1
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: 'int32' has no length

----------
messages: 4283
nosy: pypy-issue, timo
priority: bug
status: unread
title: "TypeError: 'int32' has no length"

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

From tracker at bugs.pypy.org  Sun Apr 22 18:18:56 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 22 Apr 2012 16:18:56 +0000
Subject: [pypy-issue] [issue1134] [cpyext] wrap_inquirypred not implemented
In-Reply-To: <1335028173.51.0.145444562763.issue1134@bugs.pypy.org>
Message-ID: <1335111536.23.0.730333784535.issue1134@bugs.pypy.org>


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

Implemented with 4e5b2e1949ae.

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

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

From tracker at bugs.pypy.org  Mon Apr 23 12:18:38 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 23 Apr 2012 10:18:38 +0000
Subject: [pypy-issue] [issue674] Need a functional distutils.sysconfig for
	installing	packages in pypy
In-Reply-To: <1300142311.94.0.420488012853.issue674@>
Message-ID: <1335176318.29.0.680147937639.issue674@bugs.pypy.org>


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

issue 1057 is related as well. Agreed that this is worth fixing.

----------
nosy: +sbehnel

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

From tracker at bugs.pypy.org  Mon Apr 23 13:00:52 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Mon, 23 Apr 2012 11:00:52 +0000
Subject: [pypy-issue] [issue1120] [cpyext] missing PyUnicode_Count() and
	other	PyUnicode_*() functions
In-Reply-To: <1334086670.09.0.519663291691.issue1120@bugs.pypy.org>
Message-ID: <1335178852.27.0.687349249917.issue1120@bugs.pypy.org>


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

I've seens that you fixed this. Thanks!

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

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

From tracker at bugs.pypy.org  Mon Apr 23 23:58:59 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 23 Apr 2012 21:58:59 +0000
Subject: [pypy-issue] [issue1121] [cpyext] speed up some macros
In-Reply-To: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>
Message-ID: <1335218339.42.0.237037079163.issue1121@bugs.pypy.org>


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

Done with 0feb5408579b.
I kept the old implementations (#define PYPY_DEBUG_REFCOUNT to use them) because 
they may be useful;  I'll try to enable them for tests.

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

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

From tracker at bugs.pypy.org  Tue Apr 24 07:58:52 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Tue, 24 Apr 2012 05:58:52 +0000
Subject: [pypy-issue] [issue1121] [cpyext] speed up some macros
In-Reply-To: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>
Message-ID: <1335247132.42.0.400336536566.issue1121@bugs.pypy.org>


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

Thanks.

What do you think about the string macro related changes? At least the
PyString_AS_STRING() implementation should be uncontroversial, wouldn't you say?

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

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

From tracker at bugs.pypy.org  Thu Apr 26 08:50:36 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Thu, 26 Apr 2012 06:50:36 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1335423036.12.0.561269811705.issue1080@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

Hi,
I've digged a bit regarding inifite_loop (no conclution yet). It is the loop in
trampoline.trampoline that becomes infinitie, always calling
parser.token.base.label.ceval on the same object. The example can be somewhat
simplified by killing trampoline.Bounce.i and trampoline.Bounce.c and still
triggers the bug. A change of the threshold circumvents the bug.

There is:

+688: p71 = getfield_gc(p69, descr=<FieldP
pypy.interpreter.function.Function.inst_code 24>)
+692: guard_value(p71, ConstPtr(ptr72), descr=<Guard154>) [p1, p0, p10, p46,
p71, p67, p69, p2, p5, p62, p63, None, None, i48, p47]

in the preamble that is optimized out of the peeled loop. Dont know why or if
it's just another symptom.

----------
nosy: +hakanardo

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

From tracker at bugs.pypy.org  Fri Apr 27 21:37:30 2012
From: tracker at bugs.pypy.org (timo)
Date: Fri, 27 Apr 2012 19:37:30 +0000
Subject: [pypy-issue] [issue1136] "list index must be integer, not int64"
In-Reply-To: <1335044857.21.0.688675278158.issue1136@bugs.pypy.org>
Message-ID: <1335555449.38.0.625519416451.issue1136@bugs.pypy.org>


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

oopsie. this is already fixed in the latest version.

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

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

From tracker at bugs.pypy.org  Fri Apr 27 23:19:08 2012
From: tracker at bugs.pypy.org (timo)
Date: Fri, 27 Apr 2012 21:19:08 +0000
Subject: [pypy-issue] [issue1137] "TypeError: 'int32' has no length"
In-Reply-To: <1335045027.45.0.646991371551.issue1137@bugs.pypy.org>
Message-ID: <1335561548.53.0.144514853681.issue1137@bugs.pypy.org>


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

this was related to numpypy not trying the __index__ method on objects used as
indexes, nor trying the __int__ slot for non-integer objects. fixed in
6459d00ebd48, which is to be reviewed and merged. tests pass and translation works.

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

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

From tracker at bugs.pypy.org  Sat Apr 28 00:57:24 2012
From: tracker at bugs.pypy.org (timo)
Date: Fri, 27 Apr 2012 22:57:24 +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: <1335567444.04.0.107953871149.issue1138@bugs.pypy.org>


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

npp.array("foo") or even npp.array("f") will enter an infinite loop.

npp.str_("test") will succeed, but the result is not printable and string
methods don't work on it.

amaury says there's a fundamental problem with pypy about multiple inheritance
not being possible for npp.str_

----------
messages: 4292
nosy: pypy-issue, timo
priority: bug
status: unread
title: in numpypy, strings fundamentally don't work

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

From tracker at bugs.pypy.org  Sat Apr 28 10:10:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 28 Apr 2012 08:10:00 +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: <1335600600.62.0.939485754598.issue1138@bugs.pypy.org>


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

The problem really is slightly deeper - numpy string shares string methods by 
having the same memory layout. We can't do that, but we can try to do something 
else, like reuse string methods. This requires refactoring of the string stuff, 
because it's a mess.

The reason why npp.array("foo") is an infinite loop is that s[0][0][0][0][0]... 
will always be iterable. Not sure what to do, we should probably "just" 
specialcase string and unicode

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

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

From tracker at bugs.pypy.org  Sat Apr 28 13:44:23 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Sat, 28 Apr 2012 11:44:23 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1335613463.43.0.584031811995.issue1080@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

Here is a small example triggering the infinite loop.

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

From tracker at bugs.pypy.org  Sun Apr 29 09:57:27 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Sun, 29 Apr 2012 07:57:27 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1335686247.68.0.905404337616.issue1080@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

Not the stopping condition actually, but the lookup of self.func (or the 
internal representation of its code to be precise)in Bounce.__call__, which is 
inlined into the loop in trampoline(). The result is that the same code 
representing self.func is executed every iteration and thus its misbehaving. 
Never reaching the stopping criteria is one of the results of that misbehavior. 

I've checked in a few failing tests yesterday. The one explaining the issue best 
is probably jit.metainterp.test.test_quasiimmut.test_issue1080

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

From tracker at bugs.pypy.org  Sun Apr 29 15:31:15 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Sun, 29 Apr 2012 13:31:15 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1335706275.31.0.348780054901.issue1080@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

Hi,
the infinite_loop bug is hopefully fixed by 1ba8cd8dfd89, but it needs 
verification on tomorrows nightly.

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

From tracker at bugs.pypy.org  Mon Apr 30 08:59:58 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Mon, 30 Apr 2012 06:59:58 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1335769198.86.0.726443453108.issue1080@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

Hi,
these now seem to work:

  /tmp/pypy-c-jit-54811-cc436eb0a04b-linux64/bin/pypy infinite_loop.py
  /tmp/pypy-c-jit-54811-cc436eb0a04b-linux64/bin/pypy str_instead_of_token.py
  /tmp/pypy-c-jit-54811-cc436eb0a04b-linux64/bin/pypy inf.py

However I still get the rpython assertion error when disabling optimizations:

$ /tmp/pypy-c-jit-54811-cc436eb0a04b-linux64/bin/pypy --jit 
enable_opts=intbounds:rewrite:virtualize:string:heap:unroll infinite_loop.py 
RPython traceback:
  File "jit_metainterp_optimizeopt___init__.c", line 364, in optimize_trace
  File "jit_metainterp_optimizeopt_unroll.c", line 2031, in 
UnrollOptimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_optimizer.c", line 3594, in 
Optimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_heap.c", line 3679, in OptHeap_emit_operation
  File "jit_metainterp_optimizeopt_heap.c", line 4116, in 
OptHeap_emitting_operation
Fatal RPython error: AssertionError

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

From tracker at bugs.pypy.org  Mon Apr 30 09:55:36 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Mon, 30 Apr 2012 07:55:36 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1335772536.46.0.19833501749.issue1080@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

Hi,
the rpython crash seems to be due to the heap optimizer assuming that the pure 
optimizer is enabled. But it seems to be easily fixed...

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