From tracker at bugs.pypy.org  Mon Jul  1 20:49:37 2013
From: tracker at bugs.pypy.org (Grom PE)
Date: Mon, 01 Jul 2013 18:49:37 +0000
Subject: [pypy-issue] [issue1523] youtube-dl stuck at the end of HTTPS stream
In-Reply-To: <1372704577.14.0.951785051161.issue1523@bugs.pypy.org>
Message-ID: <1372704577.14.0.951785051161.issue1523@bugs.pypy.org>


New submission from Grom PE <i at grompe.org.ru>:

youtube-dl version 2013.05.05 up to newest 2013.06.34.4
when run with pypy 2.0.2 gets stuck at the end of HTTPS stream, which can be seen in the console as:

$ pypy youtube-dl 7-tNUur2YoU
[youtube] Setting language
[youtube] 7-tNUur2YoU: Downloading video webpage

Changing the line 413 in file "youtube_dl/extractor/youtube.py" to have http link instead makes the stream 
read correctly:

        url = 'http://www.youtube.com/watch?v=%s&gl=US&hl=en&has_verified=1' % video_id

If left as https, it gets stuck at the line 416:

            video_webpage_bytes = compat_urllib_request.urlopen(request).read()

While using Python 2.7 and 3.3 youtube-dl has no such problem.
Other HTTPS streams seem to be read normally.

Correct behavior:

$ pypy youtube-dl 7-tNUur2YoU
[youtube] Setting language
[youtube] 7-tNUur2YoU: Downloading video webpage
[youtube] 7-tNUur2YoU: Downloading video info webpage
[youtube] 7-tNUur2YoU: Extracting video information
[download] Destination: Goldfish - We Come Together (OFFICIAL)-7-tNUur2YoU.mp4
[download]   0.2% of 66.60MiB at 172.09KiB/s ETA 06:35


youtube-dl: http://rg3.github.io/youtube-dl/download.html

----------
messages: 5888
nosy: Grom PE, pypy-issue
priority: bug
release: 2.0
status: unread
title: youtube-dl stuck at the end of HTTPS stream

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

From tracker at bugs.pypy.org  Mon Jul  1 21:52:33 2013
From: tracker at bugs.pypy.org (Grom PE)
Date: Mon, 01 Jul 2013 19:52:33 +0000
Subject: [pypy-issue] [issue1523] read() stuck at the end of HTTPS stream
In-Reply-To: <1372704577.14.0.951785051161.issue1523@bugs.pypy.org>
Message-ID: <1372708353.2.0.123324141422.issue1523@bugs.pypy.org>


Grom PE <i at grompe.org.ru> added the comment:

Minimal test program:

import urllib2
import socket

# Commenting the following line out removes the bug
socket.setdefaulttimeout(300)
        
# Changing the following to http:// link removes the bug
request = urllib2.Request('https://www.youtube.com/')

print "Reading"
urllib2.urlopen(request).read()
print "Done reading"

----------
status: unread -> chatting
title: youtube-dl stuck at the end of HTTPS stream -> read() stuck at the end of HTTPS stream

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

From tracker at bugs.pypy.org  Mon Jul  1 23:12:14 2013
From: tracker at bugs.pypy.org (Grom PE)
Date: Mon, 01 Jul 2013 21:12:14 +0000
Subject: [pypy-issue] [issue1523] read() stuck at the end of HTTPS stream
In-Reply-To: <1372704577.14.0.951785051161.issue1523@bugs.pypy.org>
Message-ID: <1372713134.05.0.430699349165.issue1523@bugs.pypy.org>


Grom PE <i at grompe.org.ru> added the comment:

Further testing and info, with help from IRC:

test fails on 64-bit Win7 and 32-bit WinXP.
works on 64-bit x86 Linux.

- changing URL to most other https sites makes it work, Google sites won't 
work, some other sites (https://webxcope.com/) won't work
- changing URL to http makes it work
- removing default socket timeout makes it work
- running it with CPython 2.7 makes it work

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

From tracker at bugs.pypy.org  Tue Jul  2 12:38:17 2013
From: tracker at bugs.pypy.org (Jesse)
Date: Tue, 02 Jul 2013 10:38:17 +0000
Subject: [pypy-issue] [issue1524] program traslated by rpython cannot
	startup on windows
In-Reply-To: <1372761497.09.0.669501178761.issue1524@bugs.pypy.org>
Message-ID: <1372761497.09.0.669501178761.issue1524@bugs.pypy.org>


New submission from Jesse <boytm at 163.com>:

The program translated by rpython cannot startup with popup a message 
window: "Rutime Error! R6034 An application has made an attempt to load the C 
runtime library incorrectly. Please contact the application's support team for 
more information".

It seems the lack of manifest. 
MsvcPlatform::gen_makefile should generate the step for linking manifest, but 
the vc version is 0 incorrectly.

See below, should use search instead of match to parse vc version.
file rpython\translator\platform\windows.py:

   def __init__(self, cc=None, x64=False):
        self.x64 = x64
        msvc_compiler_environ = find_msvc_env(x64)
        Platform.__init__(self, 'cl.exe')
        if msvc_compiler_environ:
            self.c_environ = os.environ.copy()
            self.c_environ.update(msvc_compiler_environ)
            # XXX passing an environment to subprocess is not enough. Why?
            os.environ.update(msvc_compiler_environ)

        # detect version of current compiler
        returncode, stdout, stderr = _run_subprocess(self.cc, '',
                                                     env=self.c_environ)
        r = re.match(r'Microsoft.+C/C\+\+.+\s([0-9]+)\.([0-9]+).*', stderr)
        if r is not None:
            self.version = int(''.join(r.groups())) / 10 - 60
        else:

----------
messages: 5891
nosy: boytm, pypy-issue
priority: bug
release: 2.0
status: unread
title: program traslated by rpython cannot startup on windows

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

From tracker at bugs.pypy.org  Tue Jul  2 13:30:08 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 02 Jul 2013 11:30:08 +0000
Subject: [pypy-issue] [issue1524] program traslated by rpython cannot
	startup on windows
In-Reply-To: <1372761497.09.0.669501178761.issue1524@bugs.pypy.org>
Message-ID: <1372764608.28.0.87132704229.issue1524@bugs.pypy.org>


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

Can you paste the output of the "cl.exe" command?
The startup logo used to always start with "Microsoft C/C++", maybe this changed. 
Is it a new version?

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

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

From tracker at bugs.pypy.org  Tue Jul  2 15:03:51 2013
From: tracker at bugs.pypy.org (Jesse)
Date: Tue, 02 Jul 2013 13:03:51 +0000
Subject: [pypy-issue] [issue1524] program traslated by rpython cannot
	startup on windows
In-Reply-To: <1372761497.09.0.669501178761.issue1524@bugs.pypy.org>
Message-ID: <1372770231.53.0.396330135486.issue1524@bugs.pypy.org>


Jesse <boytm at 163.com> added the comment:

Chinese simple VC2008 output:

    ?? 80x86 ? Microsoft (R) 32 ? C/C++ ????? 15.00.30729.01 ?
    ????(C) Microsoft Corporation????????
     
    ??: cl [ ??... ] ???... [ /link ????... ]

English VC2010 output:

    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
    Copyright (C) Microsoft Corporation.  All rights reserved.

    usage: cl [ option... ] filename... [ /link linkoption... ]

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

From tracker at bugs.pypy.org  Tue Jul  2 15:13:16 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 02 Jul 2013 13:13:16 +0000
Subject: [pypy-issue] [issue1524] program traslated by rpython cannot
	startup on windows
In-Reply-To: <1372761497.09.0.669501178761.issue1524@bugs.pypy.org>
Message-ID: <1372770796.13.0.688173062936.issue1524@bugs.pypy.org>


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

Ah, indeed.  I don't want to know how subprocess encodes Chinese characters :-)
Yes, re.match() should fix it.

Committed with 140db204a130, thanks for the report!

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

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

From tracker at bugs.pypy.org  Wed Jul  3 04:29:01 2013
From: tracker at bugs.pypy.org (YAMAMOTO Takashi)
Date: Wed, 03 Jul 2013 02:29:01 +0000
Subject: [pypy-issue] [issue1514] module behaviour incompatibility which
	makes eventlet fail
In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org>
Message-ID: <1372818541.25.0.115123343532.issue1514@bugs.pypy.org>


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

unfortunately it's difficult (well, at least for me) to workaround by
copying modules in the case of eventlet because the library and application
both freely does import.  ie. there's no single entity to control import.

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

From tracker at bugs.pypy.org  Wed Jul  3 10:06:00 2013
From: tracker at bugs.pypy.org (secwineman)
Date: Wed, 03 Jul 2013 08:06:00 +0000
Subject: [pypy-issue] [issue1525] "unknown address family" when sending a
	packet with Scapy
In-Reply-To: <1372838760.2.0.788681486532.issue1525@bugs.pypy.org>
Message-ID: <1372838760.2.0.788681486532.issue1525@bugs.pypy.org>


New submission from secwineman <nicolasbd at hotmail.fr>:

Hello,
I'm using pypy 2.0.2 (downloaded here :
http://people.debian.org/~stefanor/pypy/wheezy/ ) on Kali Linux 1.0.3(based on
Debian Wheezy).

I installed the scapy module with the following command : pypy setup.py install.
No error has been returned.

Then I tried to send a simple packet using Scapy with the pypy interpretor. I
got the following error message : 

">>> send(IP(dst="192.168.1.1"))
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/local/lib/pypy2.7/dist-packages/scapy/sendrecv.py", line 251, in send
    __gen_send(conf.L3socket(*args, **kargs), x, inter=inter, loop=loop,
count=count,verbose=verbose, realtime=realtime)
  File "/usr/local/lib/pypy2.7/dist-packages/scapy/sendrecv.py", line 234, in
__gen_send
    s.send(p)
  File "/usr/local/lib/pypy2.7/dist-packages/scapy/arch/linux.py", line 379, in send
    self.outs.bind(sdto)
  File "<string>", line 1, in bind
error: unknown address family" 

This same scapy command works fine with the standard Python interpretor.

----------
messages: 5896
nosy: pypy-issue, secwineman
priority: bug
release: 2.0
status: unread
title: "unknown address family" when sending a packet with Scapy

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

From tracker at bugs.pypy.org  Wed Jul  3 14:17:08 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 03 Jul 2013 12:17:08 +0000
Subject: [pypy-issue] [issue1525] "unknown address family" when sending a
	packet with Scapy
In-Reply-To: <1372838760.2.0.788681486532.issue1525@bugs.pypy.org>
Message-ID: <1372853828.46.0.433596289634.issue1525@bugs.pypy.org>


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

"pip install scapy" fails.  Can you provide a link to which version of scapy you
installed?

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

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

From tracker at bugs.pypy.org  Wed Jul  3 14:48:07 2013
From: tracker at bugs.pypy.org (secwineman)
Date: Wed, 03 Jul 2013 12:48:07 +0000
Subject: [pypy-issue] [issue1525] "unknown address family" when sending a
	packet with Scapy
In-Reply-To: <1372838760.2.0.788681486532.issue1525@bugs.pypy.org>
Message-ID: <1372855687.05.0.605077986297.issue1525@bugs.pypy.org>


secwineman <nicolasbd at hotmail.fr> added the comment:

Sure. http://hg.secdev.org/scapy/archive/74274bb47d3c.tar.gz

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

From tracker at bugs.pypy.org  Thu Jul  4 01:59:23 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 03 Jul 2013 23:59:23 +0000
Subject: [pypy-issue] [issue1526] Faster cffi/numpypy array data pointer
	casting	(ndarray.ctypes?)
In-Reply-To: <1372895963.18.0.0420052532686.issue1526@bugs.pypy.org>
Message-ID: <1372895963.18.0.0420052532686.issue1526@bugs.pypy.org>


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

When calling out to functions in C (using cffi) to operate on numpypy arrays, 
the current method to get a pointer is to do:

a_ptr   = ffi.cast("double *",   a.__array_interface__['data'][0])

For small functions, the overhead of this fetch-and-casting of the data address 
is quite significant.

I've included some code that compares a simple dot product of a vector (length = 
4), using numpypy's dot function, a python implementation, and 2 c 
implementations called via CFFI.  One does the cast every time the function is 
called, and one does the cast outside the timing loop to demonstrate how much 
time the lookup-and-cast is taking:

The results are:

                     numpypy dot 0.797430430847 0:00:03.590898
                      python dot 0.797430430847 0:00:01.130100
 c dotproduct (cast to double *) 0.797430430847 0:00:02.245106
       c dotproduct (no casting) 0.797430430847 0:00:00.352964


Questions:
* Is there currently a faster way to do this cffi cast and function call?
* Might implementing ndarray.ctypes in numpypy make this faster?

----------
files: numpypy_cffi.zip
messages: 5899
nosy: mikefc, pypy-issue
priority: wish
status: unread
title: Faster cffi/numpypy array data pointer casting (ndarray.ctypes?)

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

From tracker at bugs.pypy.org  Thu Jul  4 08:18:13 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 04 Jul 2013 06:18:13 +0000
Subject: [pypy-issue] [issue1526] Faster cffi/numpypy array data pointer
	casting	(ndarray.ctypes?)
In-Reply-To: <1372895963.18.0.0420052532686.issue1526@bugs.pypy.org>
Message-ID: <1372918693.38.0.342215192104.issue1526@bugs.pypy.org>


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

numpy arrays support buffer().  We should fix cffi to really have a way to
accept buffer objects, and then fix some of the built-in PyPy types (like
ndarray) to expose such "raw buffers".

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

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

From tracker at bugs.pypy.org  Thu Jul  4 08:51:55 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 04 Jul 2013 06:51:55 +0000
Subject: [pypy-issue] [issue1525] "unknown address family" when sending a
	packet with Scapy
In-Reply-To: <1372838760.2.0.788681486532.issue1525@bugs.pypy.org>
Message-ID: <1372920715.15.0.488634870032.issue1525@bugs.pypy.org>


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

For completeness (writing it here as it took me 10 minutes to figure out): the
imports needed are

from scapy.layers.inet import IP
from scapy.sendrecv import send

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

From tracker at bugs.pypy.org  Thu Jul  4 08:56:40 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 04 Jul 2013 06:56:40 +0000
Subject: [pypy-issue] [issue1525] "unknown address family" when sending a
	packet with Scapy
In-Reply-To: <1372838760.2.0.788681486532.issue1525@bugs.pypy.org>
Message-ID: <1372921000.36.0.826273437731.issue1525@bugs.pypy.org>


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

Scapy is trying to open a socket with family=AF_PACKET.  It is a known issue
that PyPy's socket module only supports the common families, and not the many
others.  Thanks for the report anyway: it shows that there is still some
interest in some of these other families.  If you or anyone else feels like
implementing AF_PACKET, he is welcome!

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

From tracker at bugs.pypy.org  Thu Jul  4 11:50:47 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 04 Jul 2013 09:50:47 +0000
Subject: [pypy-issue] [issue1525] "unknown address family" when sending a
	packet with Scapy
In-Reply-To: <1372838760.2.0.788681486532.issue1525@bugs.pypy.org>
Message-ID: <1372931447.27.0.0630608792162.issue1525@bugs.pypy.org>


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

AF_PACKET is already half-supported: C bindings are here, addr_as_object is already implemented, 
but not addr_from_object().

This is an easy task for a newcomer.
tag:easy

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

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

From tracker at bugs.pypy.org  Thu Jul  4 12:07:43 2013
From: tracker at bugs.pypy.org (Lefteris Stamatogiannakis)
Date: Thu, 04 Jul 2013 10:07:43 +0000
Subject: [pypy-issue] [issue1527] Universal Newlines in pypy are extremely
	slow
In-Reply-To: <1372932463.72.0.731216907786.issue1527@bugs.pypy.org>
Message-ID: <1372932463.72.0.731216907786.issue1527@bugs.pypy.org>


New submission from Lefteris Stamatogiannakis <estama at gmail.com>:

When reading a text file with the universal newline option in open, pypy can be up to ~200 
times slower than CPython.

Test code:

f=open('textfile.txt', 'rU')

totalLen = 0
for l in f:
    totalLen += len(l)
print(totalLen)

----------
messages: 5904
nosy: estama, pypy-issue
priority: performance bug
status: unread
title: Universal Newlines in pypy are extremely slow

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

From tracker at bugs.pypy.org  Thu Jul  4 12:16:25 2013
From: tracker at bugs.pypy.org (Lefteris Stamatogiannakis)
Date: Thu, 04 Jul 2013 10:16:25 +0000
Subject: [pypy-issue] [issue1528] I/O in pypy is up to 2x slower than CPython
In-Reply-To: <1372932985.73.0.729755020573.issue1528@bugs.pypy.org>
Message-ID: <1372932985.73.0.729755020573.issue1528@bugs.pypy.org>


New submission from Lefteris Stamatogiannakis <estama at gmail.com>:

Reading a file in pypy can be up to ~2x slower than CPython.

Antonio Cuni mentioned that it may be a problem with the low level implementation of pypy:

On 4/7/2013 9:12 am, Antonio Cuni wrote:
"Few days ago I discovered that there is an easy optimization for this. If you look at how 
str2charp & friends are implemented, you see that we do an RPython loop and copy char by 
char.
By contrast, things like string concatenation are implemented using memcpy and are much 
faster (like 3-4 times, iirc)."

Example code:

f=open("text.txt", "w+b")
s="qwerty" * 10 + '\n'

for i in xrange(100000):
    f.write(s)

----------
messages: 5905
nosy: estama, pypy-issue
priority: performance bug
status: unread
title: I/O in pypy is up to 2x slower than CPython

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

From tracker at bugs.pypy.org  Thu Jul  4 18:40:35 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 04 Jul 2013 16:40:35 +0000
Subject: [pypy-issue] [issue1522] In some cases,
	`set(itertools.ifilter(...` takes more memory than in CPython
In-Reply-To: <1372613329.04.0.947040665165.issue1522@bugs.pypy.org>
Message-ID: <1372956035.66.0.00102864689234.issue1522@bugs.pypy.org>


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

Found the reason: it's because set(iterable) first converts the iterable into a
list.  But the problem here is that the list is very long (5000*5000/2 items
roughly), but contains a lot of duplicate items, so that the final set is only
5001 items long.

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

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

From tracker at bugs.pypy.org  Thu Jul  4 18:41:59 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 04 Jul 2013 16:41:59 +0000
Subject: [pypy-issue] [issue1522] In some cases,
	`set(itertools.ifilter(...` takes more memory than in CPython
In-Reply-To: <1372613329.04.0.947040665165.issue1522@bugs.pypy.org>
Message-ID: <1372956119.73.0.668954473872.issue1522@bugs.pypy.org>


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

Minimal test case:

def f():
    for i in xrange(100000000):
        yield 42
set(f())

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

From tracker at bugs.pypy.org  Thu Jul  4 18:46:23 2013
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Thu, 04 Jul 2013 16:46:23 +0000
Subject: [pypy-issue] [issue1522] In some cases,
	`set(itertools.ifilter(...` takes more memory than in CPython
In-Reply-To: <1372613329.04.0.947040665165.issue1522@bugs.pypy.org>
Message-ID: <1372956383.57.0.328097695099.issue1522@bugs.pypy.org>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

Assigning to me, will to this soonish.

----------
assignedto:  -> cfbolz
nosy: +cfbolz

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

From tracker at bugs.pypy.org  Fri Jul  5 04:38:00 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Fri, 05 Jul 2013 02:38:00 +0000
Subject: [pypy-issue] [issue1526] Faster cffi/numpypy array data pointer
	casting	(ndarray.ctypes?)
In-Reply-To: <1372895963.18.0.0420052532686.issue1526@bugs.pypy.org>
Message-ID: <1372991880.83.0.449808615563.issue1526@bugs.pypy.org>


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

I should have pointed out that this is for 10million function calls each.

Note that in PyPy, the pure python dotproduct is 3x faster than the numpypy one.  

I guess the overhead in setting up iterators/whatever in numpypy for these short (length=4) vectors makes it more 
expensive than just the manual unrolling of the pure python version.

##############################
#  CPython 
##############################
As an extra example, I looked at running this under CPython2.7.  Even the fastest version under CPython is slower 
than the slowest pypy code.

And I've just found out that the ndarray.ctypes attribute is probably being created at call time, so no wonder it's 
slower than casting the __array_attribute__.


                     numpypy dot 0.797430430847 0:00:11.081040
                      python dot 0.797430430847 0:00:30.281586
 c dotproduct (cast to double *) 0.797430430847 0:01:21.851521
     c dot. casting a.ctype.data 0.797430430847 0:02:14.366188
c dotproduct (cast outside loop) 0.797430430847 0:00:05.795226

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

From tracker at bugs.pypy.org  Sat Jul  6 11:58:09 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Sat, 06 Jul 2013 09:58:09 +0000
Subject: [pypy-issue] [issue1529] C queue datastructure accessed via CFFI
	slower than	Python counterpart
In-Reply-To: <1373104689.39.0.674999736356.issue1529@bugs.pypy.org>
Message-ID: <1373104689.39.0.674999736356.issue1529@bugs.pypy.org>


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

My timings with a recentish pypy nightly and cpython 2.7.4:

Interpreter | Queue Implementation | time
------------|----------------------|---------
pypy        | python               |  1.372s
pypy        | cpp                  |  5.027s
cpython     | python               | 18.046s
cpython     | cpp                  | 35.330s


So calling into the cpp implementation with CFFI is a ~4x penalty for pypy and about a 
~2x penalty for cpython.

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

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

From tracker at bugs.pypy.org  Mon Jul  8 13:10:29 2013
From: tracker at bugs.pypy.org (Edd Barrett)
Date: Mon, 08 Jul 2013 11:10:29 +0000
Subject: [pypy-issue] [issue1531] Add OpenBSD specific paths to tkinter
	module.
In-Reply-To: <1373281829.97.0.396025486941.issue1531@bugs.pypy.org>
Message-ID: <1373281829.97.0.396025486941.issue1531@bugs.pypy.org>


New submission from Edd Barrett <vext01 at gmail.com>:

The following diff allows the recent Tk work to run on OpenBSD. Note that you 
need a threaded version of tcl for the pypy tk binding to function (is this 
intended? Cpython does not require a threaded version of tcl).

I have left some XXX comments as questions to the devs. I am not sure if there 
is a better way to locate tk...

Cheers

----------
files: pypy-tk.diff
messages: 5912
nosy: pypy-issue, vext01
priority: wish
status: unread
title: Add OpenBSD specific paths to tkinter module.

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

From tracker at bugs.pypy.org  Tue Jul  9 18:55:46 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 09 Jul 2013 16:55:46 +0000
Subject: [pypy-issue] [issue1530] cx_Oracle 5.1.x doesn't work with pypy
In-Reply-To: <1373115221.33.0.813421642246.issue1530@bugs.pypy.org>
Message-ID: <1373388946.96.0.694651712185.issue1530@bugs.pypy.org>


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

This is not a cx_Oracle version issue, but more probably a feature not correctly supported by the pypy implementation (and not 
correctly tested by cx_Oracle at the time...).

To help me debugging this (I don't have any access to Oracle nowadays, sorry), can you retrieve the result of 
self.setinputsizes() called in db/backends/oracle/base.py, and what is exactly passed to self.cursor.execute().

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

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

From tracker at bugs.pypy.org  Wed Jul 10 17:55:59 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 10 Jul 2013 15:55:59 +0000
Subject: [pypy-issue] [issue1529] C queue datastructure accessed via CFFI
	slower than	Python counterpart
In-Reply-To: <1373104689.39.0.674999736356.issue1529@bugs.pypy.org>
Message-ID: <1373471759.75.0.698820508295.issue1529@bugs.pypy.org>


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

There is some unnecessary slowness when a function returns a function pointer.

In the ffi.cdef() declarations I modified deq() to return a void*,
then I added a cast in the calling code:
    fp = q.deq()
    fp = ffi.cast("FuncPtr", fp)
    fp()
this makes the "cpp" version much faster, 3x faster than the pure python version.

----------
assignedto:  -> arigo
nosy: +amaury, arigo

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

From tracker at bugs.pypy.org  Wed Jul 10 19:05:57 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 10 Jul 2013 17:05:57 +0000
Subject: [pypy-issue] [issue1529] C queue datastructure accessed via CFFI
	slower than	Python counterpart
In-Reply-To: <1373104689.39.0.674999736356.issue1529@bugs.pypy.org>
Message-ID: <1373475958.0.0.868839585706.issue1529@bugs.pypy.org>


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

Forget my last message, the change I made was stupid, it completely breaks the 
EventQueue implementation.

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

From tracker at bugs.pypy.org  Thu Jul 11 15:44:30 2013
From: tracker at bugs.pypy.org (Dusan Smitran)
Date: Thu, 11 Jul 2013 13:44:30 +0000
Subject: [pypy-issue] [issue1532] Running ipython with pypy on windows
In-Reply-To: <1373550270.76.0.0364406526498.issue1532@bugs.pypy.org>
Message-ID: <1373550270.76.0.0364406526498.issue1532@bugs.pypy.org>


New submission from Dusan Smitran <dusan.smitran at gmail.com>:

Dont know where to put this issue im having with running ipython (ipython-0.13.2) with 
pypy 32 bit (2.0.2) on Windows 7 64bit. Is it more a pypy issue?

When running in pypy\bin: ipython.exe i get the following traceback:

C:\python\pypy\bin> ipython.exe
cffi_g85535e98x310af836.c
c:\python\pypy\lib_pypy__pycache___cffi__g85535e98x310af836.c(26) : fatal error C1083: 
Cannot open include file: 'ncurses.h': No such file or directory
Traceback (most recent call last):
File "app_main.py", line 72, in run_toplevel
File "c:\python\pypy\bin\ipython-script.py", line 9, in 
load_entry_point('ipython==0.13.2', 'console_scripts', 'ipython')()
File "build\bdist.win32\egg\pkg_resources.py", line 378, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "build\bdist.win32\egg\pkg_resources.py", line 2566, in load_entry_point
return ep.load()
File "build\bdist.win32\egg\pkg_resources.py", line 2260, in load
entry = import(self.module_name, globals(),globals(), ['__name__'])
File "c:\python\pypy\site-packages\ipython-0.13.2-py2.7.egg\IPython__init__.py", line 46, 
in ule>
from .frontend.terminal.embed import embed
File "c:\python\pypy\site-packages\ipython-0.13.2-
py2.7.egg\IPython\frontend\terminal\embed.py", l
ine 38, in 
from IPython.core.magic import Magics, magics_class, line_magic
File "c:\python\pypy\site-packages\ipython-0.13.2-py2.7.egg\IPython\core\magic.py", line 
26, in odule>
from IPython.core import oinspect
File "c:\python\pypy\site-packages\ipython-0.13.2-py2.7.egg\IPython\core\oinspect.py", 
line 33, in

from IPython.core import page
File "c:\python\pypy\site-packages\ipython-0.13.2-py2.7.egg\IPython\core\page.py", line 
39, in dule>
from IPython.utils.cursesimport import use_curses
File "c:\python\pypy\site-packages\ipython-0.13.2-
py2.7.egg\IPython\utils\cursesimport.py", line 2
3, in 
import curses
File "c:\python\pypy\lib-python\2.7\curses__init__.py", line 15, in 
from curses import *
File "c:\python\pypy\lib_pypy_curses.py", line 319, in 
""", libraries=['ncurses', 'panel'])
File "c:\python\pypy\lib_pypy\cffi\api.py", line 311, in verify
lib = self.verifier.load_library()
File "c:\python\pypy\lib_pypy\cffi\verifier.py", line 68, in load_library
self.compile_module()
File "c:\python\pypy\lib_pypy\cffi\verifier.py", line 56, in compile_module
self._compile_module()
File "c:\python\pypy\lib_pypy\cffi\verifier.py", line 142, in _compile_module
outputfilename = ffiplatform.compile(tmpdir, self.get_extension())
File "c:\python\pypy\lib_pypy\cffi\ffiplatform.py", line 25, in compile
outputfilename = _build(tmpdir, ext)
File "c:\python\pypy\lib_pypy\cffi\ffiplatform.py", line 50, in _build
raise VerificationError('%s: %s' % (e._class__.__name__, e))
VerificationError: CompileError: command 'c:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\BIN\
cl.exe' failed with exit status 2

link to issue on ipython github: https://github.com/ipython/ipython/issues/3580

----------
messages: 5916
nosy: pypy-issue, xgo
priority: wish
status: unread
title: Running ipython with pypy on windows

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

From tracker at bugs.pypy.org  Thu Jul 11 16:01:47 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 11 Jul 2013 14:01:47 +0000
Subject: [pypy-issue] [issue1532] Running ipython with pypy on windows
In-Reply-To: <1373550270.76.0.0364406526498.issue1532@bugs.pypy.org>
Message-ID: <1373551307.78.0.553575154223.issue1532@bugs.pypy.org>


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

Yes it's a pypy issue; in lib_pypy/_curses.py, the VerificationError should be 
turned into an ImportError.

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

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

From tracker at bugs.pypy.org  Thu Jul 11 20:13:21 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Thu, 11 Jul 2013 18:13:21 +0000
Subject: [pypy-issue] [issue1533] ctypes c_double: Fatal RPython error:
	OverflowError
In-Reply-To: <1373566401.36.0.993119075201.issue1533@bugs.pypy.org>
Message-ID: <1373566401.36.0.993119075201.issue1533@bugs.pypy.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

import ctypes

libc = ctypes.CDLL("libm.so.6")
fabs = libc.fabs
fabs.argtypes = [ctypes.c_double]
fabs.restype = ctypes.c_double

fabs(10**900)

############################

RPython traceback:
  File "pypy_goal_targetpypystandalone.c", line 2414, in entry_point
  File "pypy_interpreter_pyframe.c", line 1207, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1477, in
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 226, in portal_4
  File "pypy_interpreter_pyopcode.c", line 3071, in
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 8576, in
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 17091, in
call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1207, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1477, in
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 226, in portal_4
  File "pypy_interpreter_pyopcode.c", line 3071, in
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 8189, in
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 17091, in
call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1207, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1477, in
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 226, in portal_4
  File "pypy_interpreter_pyopcode.c", line 3071, in
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 9635, in
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 17091, in
call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1207, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1477, in
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 226, in portal_4
  File "pypy_interpreter_pyopcode.c", line 3071, in
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 9528, in
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 24670, in EXEC_STMT__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1207, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1477, in
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 226, in portal_4
  File "pypy_interpreter_pyopcode.c", line 3071, in
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 5707, in
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 13365, in
CALL_FUNCTION__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1207, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1477, in
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 226, in portal_4
  File "pypy_interpreter_pyopcode.c", line 3071, in
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 8189, in
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 17091, in
call_function__AccessDirect_None
  File "pypy_interpreter_pyframe.c", line 1207, in PyFrame_execute_frame
  File "rpython_jit_metainterp_warmspot.c", line 1477, in
ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "pypy_module_pypyjit_interp_jit.c", line 226, in portal_4
  File "pypy_interpreter_pyopcode.c", line 3071, in
handle_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 8189, in
dispatch_bytecode__AccessDirect_None
  File "pypy_interpreter_pyopcode.c", line 17091, in
call_function__AccessDirect_None
  File "pypy_interpreter_gateway.c", line 2893, in BuiltinCode_funcrun_obj
  File "pypy_interpreter_gateway.c", line 3228, in BuiltinCode_handle_exception
Fatal RPython error: OverflowError

----------
messages: 5918
nosy: lazka, pypy-issue
priority: bug
status: unread
title: ctypes c_double: Fatal RPython error: OverflowError

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

From tracker at bugs.pypy.org  Thu Jul 11 21:42:43 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 11 Jul 2013 19:42:43 +0000
Subject: [pypy-issue] [issue1533] ctypes c_double: Fatal RPython error:
	OverflowError
In-Reply-To: <1373566401.36.0.993119075201.issue1533@bugs.pypy.org>
Message-ID: <1373571763.77.0.252196852329.issue1533@bugs.pypy.org>


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

The issue is in space.float_w().

Another example:
    import time; time.ctime(10**900)

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

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

From tracker at bugs.pypy.org  Thu Jul 11 21:42:53 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 11 Jul 2013 19:42:53 +0000
Subject: [pypy-issue] [issue1533] ctypes c_double: Fatal RPython error:
	OverflowError
In-Reply-To: <1373566401.36.0.993119075201.issue1533@bugs.pypy.org>
Message-ID: <1373571773.19.0.594156526522.issue1533@bugs.pypy.org>


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

tag:easy

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

From tracker at bugs.pypy.org  Thu Jul 11 21:57:28 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 11 Jul 2013 19:57:28 +0000
Subject: [pypy-issue] [issue1533] ctypes c_double: Fatal RPython error:
	OverflowError
In-Reply-To: <1373566401.36.0.993119075201.issue1533@bugs.pypy.org>
Message-ID: <1373572648.82.0.83669227549.issue1533@bugs.pypy.org>


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

Thanks!  Should be fixed in 6ac45c25b393.

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

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

From tracker at bugs.pypy.org  Fri Jul 12 12:41:20 2013
From: tracker at bugs.pypy.org (Mikhail Korobov)
Date: Fri, 12 Jul 2013 10:41:20 +0000
Subject: [pypy-issue] [issue1536] custom encoding/decoding error handlers
	are not	compatible with CPython
In-Reply-To: <1373625680.25.0.969111066471.issue1536@bugs.pypy.org>
Message-ID: <1373625680.25.0.969111066471.issue1536@bugs.pypy.org>


New submission from Mikhail Korobov <kmike84 at gmail.com>:

Hi,

I think that the way PyPy implements support for custom encoding/decoding error 
handlers is not compatible 
with CPython. An example script that reproduces this is in attachements.

CPython 2.6.7 agrees with CPython 3.3.2:

$ python3.3 error_handlers.py 
\x80\xa3
UnicodeDecodeError('utf-8', b'\x80\xa3', 0, 1, 'invalid start byte')
UnicodeDecodeError('utf-8', b'\x80\xa3', 0, 1, 'invalid start byte')
!!
\xe3\xa3
UnicodeDecodeError('utf-8', b'\xe3\xa3', 0, 2, 'unexpected end of data')
UnicodeDecodeError('utf-8', b'\xe3\xa3', 0, 2, 'unexpected end of data')
!!

$ python2.6 error_handlers.py 
\x80\xa3
UnicodeDecodeError('utf8', '\x80\xa3', 0, 1, 'invalid start byte')
UnicodeDecodeError('utf8', '\x80\xa3', 0, 1, 'invalid start byte')
!!
\xe3\xa3
UnicodeDecodeError('utf8', '\xe3\xa3', 0, 2, 'unexpected end of data')
UnicodeDecodeError('utf8', '\xe3\xa3', 0, 2, 'unexpected end of data')
!!


PyPy 2.0.2 produces different results (different exceptions are raised, the output 
is also not the same):

$ pypy error_handlers.py 
\x80\xa3
UnicodeDecodeError('utf-8', '\x80\xa3', 0, 1, 'invalid start byte')
UnicodeDecodeError('utf-8', '\x80\xa3', 1, 2, 'invalid start byte')
!!
\xe3\xa3
UnicodeDecodeError('utf-8', '\xe3\xa3', 0, 2, 'unexpected end of data')
!

----------
messages: 5922
nosy: kmike, pypy-issue
priority: bug
status: unread
title: custom encoding/decoding error handlers are not compatible with CPython

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

From tracker at bugs.pypy.org  Fri Jul 12 13:12:15 2013
From: tracker at bugs.pypy.org (Mikhail Korobov)
Date: Fri, 12 Jul 2013 11:12:15 +0000
Subject: [pypy-issue] [issue846] TypeError: type 'basestring' is not an
	acceptable base	class
In-Reply-To: <1314298597.06.0.673686395864.issue846@bugs.pypy.org>
Message-ID: <1373627535.69.0.493906755776.issue846@bugs.pypy.org>


Mikhail Korobov <kmike84 at gmail.com> added the comment:

FYI: NLTK master no longer has this SourcedString class, and the repository is 
moved to github more than year ago (googlecode references are obsolete).

----------
nosy: +kmike

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

From tracker at bugs.pypy.org  Fri Jul 12 13:15:57 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 12 Jul 2013 11:15:57 +0000
Subject: [pypy-issue] [issue1536] custom encoding/decoding error handlers
	are not	compatible with CPython
In-Reply-To: <1373625680.25.0.969111066471.issue1536@bugs.pypy.org>
Message-ID: <1373627757.48.0.219810856975.issue1536@bugs.pypy.org>


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

Two different issues here:

- The difference with "\xe3\xa3" ('unexpected end of data') is probably an issue in pypy decoder, untested in python 
test suite.

- But CPython is incorrect for the first case: it displays the same range twice *when you print the exception*, but did 
you check exc.start and exc.end? See http://bugs.python.org/issue13830

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

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

From tracker at bugs.pypy.org  Sun Jul 14 12:46:43 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 14 Jul 2013 10:46:43 +0000
Subject: [pypy-issue] [issue1537] numpypy array slicing doesn't update data
	memory address
In-Reply-To: <1373798803.5.0.691099642439.issue1537@bugs.pypy.org>
Message-ID: <1373798803.5.0.691099642439.issue1537@bugs.pypy.org>


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

If a slice is taken out of a numpypy ndarray, then the array_interface['data'] value is 
not updated to point to the start of the actual memory of the slice.  Instead, it still 
points to the start of the memory of the parent array.

Code below illustrates that cpython/numpy update the array interface, whereas 
pypy/numpypy does not.

#---------------------------------------------------
# code
#---------------------------------------------------
try:
    import numpypy as np
except:
    import numpy as np
zz = np.array(range(9))
print zz.__array_interface__['data']
print zz[0:3].__array_interface__['data']
print zz[3:5].__array_interface__['data']

#---------------------------------------------------
# cpython 2.7.4
#---------------------------------------------------
(140287077459744, False) # start of zz array
(140287077459744, False) # correctly pointing to start of zz memory
(140287077459768, False) # pointing to start of third element of zz

#---------------------------------------------------
# latest nightly OSX
#---------------------------------------------------
(4340424752, False)
(4340424752, False)
(4340424752, False)  # Still pointing to start of zz array memory!

----------
messages: 5925
nosy: mikefc, pypy-issue
priority: bug
status: unread
title: numpypy array slicing doesn't update data memory address

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

From tracker at bugs.pypy.org  Sun Jul 14 18:24:32 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Jul 2013 16:24:32 +0000
Subject: [pypy-issue] [issue1534] PyPy does not handle "import SMBus" on
	RaspberryPi
In-Reply-To: <1373819072.27.0.488938624163.issue1534@bugs.pypy.org>
Message-ID: <1373819072.27.0.488938624163.issue1534@bugs.pypy.org>


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

What is the SMBus module?  Is it a RaspberryPi-only module written in C?  If so
then someone needs to port it, e.g. by rewriting a cffi version.

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

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

From tracker at bugs.pypy.org  Sun Jul 14 18:25:59 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 14 Jul 2013 16:25:59 +0000
Subject: [pypy-issue] [issue846] TypeError: type 'basestring' is not an
	acceptable base	class
In-Reply-To: <1314298597.06.0.673686395864.issue846@bugs.pypy.org>
Message-ID: <1373819159.17.0.993775548225.issue846@bugs.pypy.org>


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

Close?

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

From tracker at bugs.pypy.org  Sun Jul 14 19:04:51 2013
From: tracker at bugs.pypy.org (mattip)
Date: Sun, 14 Jul 2013 17:04:51 +0000
Subject: [pypy-issue] [issue1537] numpypy array slicing doesn't update data
	memory address
In-Reply-To: <1373798803.5.0.691099642439.issue1537@bugs.pypy.org>
Message-ID: <1373821491.78.0.694886230139.issue1537@bugs.pypy.org>


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

Fixed in changeset eafa1bb50ded, test added too.
Thanks for the report

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

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

From tracker at bugs.pypy.org  Mon Jul 15 10:34:06 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 15 Jul 2013 08:34:06 +0000
Subject: [pypy-issue] [issue1238] "bad write retry" from ssl sockets
In-Reply-To: <1345356759.53.0.254657459085.issue1238@bugs.pypy.org>
Message-ID: <1373877246.29.0.699521489235.issue1238@bugs.pypy.org>


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

Thanks, accepted your pull request #160 which solves it the same way as was done
in CPython.

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

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

From tracker at bugs.pypy.org  Mon Jul 15 10:38:10 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 15 Jul 2013 08:38:10 +0000
Subject: [pypy-issue] [issue1532] Running ipython with pypy on windows
In-Reply-To: <1373550270.76.0.0364406526498.issue1532@bugs.pypy.org>
Message-ID: <1373877490.04.0.585631256816.issue1532@bugs.pypy.org>


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

Is it a good idea to always raise ImportError from ffi.verify() directly?

What about the fact that any run of ipython.exe (for example) will dump some
errors of the C compiler to stderr?

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

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

From tracker at bugs.pypy.org  Mon Jul 15 13:53:03 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Jul 2013 11:53:03 +0000
Subject: [pypy-issue] [issue1534] PyPy does not handle "import SMBus" on
	RaspberryPi
In-Reply-To: <1373819072.27.0.488938624163.issue1534@bugs.pypy.org>
Message-ID: <1373889183.56.0.739686420883.issue1534@bugs.pypy.org>


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

It's a simple C extension:
http://www.lm-sensors.org/browser/i2c-tools/branches/i2c-tools-3.1/py-smbus/smbusmodule.c

It's probably an easy match for cffi.
Unfortunately it has absolutely no test, so someone has to come with a reasonable small 
application, and develop from there.

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

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

From tracker at bugs.pypy.org  Tue Jul 16 06:03:34 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Tue, 16 Jul 2013 04:03:34 +0000
Subject: [pypy-issue] [issue1538] multiprocessing slower than cpython
In-Reply-To: <1373947414.94.0.672572844359.issue1538@bugs.pypy.org>
Message-ID: <1373947414.94.0.672572844359.issue1538@bugs.pypy.org>


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

OSX. 4 core i5.  recent 'nightly' version of pypy

Time to run the code for cpython and pypy.

          map    multiprocessing.map
CPython   28.9          12.6
pypy      28.1          23.9

#-------------------------------------------------------
# code code code code code
#-------------------------------------------------------
import hashlib
import datetime
import multiprocessing

def f(i):
    return hashlib.md5("hello %i" % i).hexdigest()

p = multiprocessing.Pool(4)

for mapf in (map, p.map):
    start = datetime.datetime.now()
    mapf(f, xrange(2**23))
    print datetime.datetime.now() - start

----------
messages: 5932
nosy: mikefc, pypy-issue
priority: performance bug
status: unread
title: multiprocessing slower than cpython

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

From tracker at bugs.pypy.org  Tue Jul 16 06:38:16 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Tue, 16 Jul 2013 04:38:16 +0000
Subject: [pypy-issue] [issue1539] numpypy inplace operations
In-Reply-To: <1373949496.73.0.722969368634.issue1539@bugs.pypy.org>
Message-ID: <1373949496.73.0.722969368634.issue1539@bugs.pypy.org>


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

Under cpython/numpy, an inplace operation on an array uses the same memory.

Under numpypy, new memory is allocated for the result.

This seems to be the case for: += -= *= /=
#----------------------------------------------------------
# code code code code code
#----------------------------------------------------------
try:
    import numpy as np
except:
    import numpypy as np

a = np.array([1,2,3], dtype='f8')
start_address = a.__array_interface__['data'][0]
a *= 3
assert(a.__array_interface__['data'][0] == start_address)

----------
messages: 5933
nosy: mikefc, pypy-issue
priority: bug
status: unread
title: numpypy inplace operations

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

From tracker at bugs.pypy.org  Tue Jul 16 08:44:22 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 16 Jul 2013 06:44:22 +0000
Subject: [pypy-issue] [issue1538] multiprocessing slower than cpython
In-Reply-To: <1373947414.94.0.672572844359.issue1538@bugs.pypy.org>
Message-ID: <1373957062.5.0.433556758367.issue1538@bugs.pypy.org>


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

Attached a modified version with "pass" in f().  The overhead of using
multiprocessing seems huge in PyPy.

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

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

From tracker at bugs.pypy.org  Tue Jul 16 14:19:01 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Tue, 16 Jul 2013 12:19:01 +0000
Subject: [pypy-issue] [issue1538] multiprocessing slower than cpython
In-Reply-To: <1373947414.94.0.672572844359.issue1538@bugs.pypy.org>
Message-ID: <1373977141.11.0.218333276279.issue1538@bugs.pypy.org>


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

Timings for x.py on OSX. 8 core i7. recent nightly pypy. time is in seconds.

          map      multiprocessing.map
cpython   1.01          0.99
pypy      0.11          4.80

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

From tracker at bugs.pypy.org  Wed Jul 17 00:14:52 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 16 Jul 2013 22:14:52 +0000
Subject: [pypy-issue] [issue1470] Implement python3 sys.setswitchinterval()
In-Reply-To: <1367164198.61.0.86586358164.issue1470@bugs.pypy.org>
Message-ID: <1374012892.64.0.37259063818.issue1470@bugs.pypy.org>


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

I'll note for the public record that Armin had already done some work (issue 
#884) on the original GIL's problems in response to dabeaz (whom originally 
found the GIL problems on CPython/PyPy and even Ruby).

Also, it might be interesting to benchmark PyPy's GIL against Antoine Pitrou's 
ccbench, a concurrency benchmark he made for his new GIL work. Maybe it should 
even be included in the Python benchmark suite

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

From tracker at bugs.pypy.org  Wed Jul 17 00:28:12 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 16 Jul 2013 22:28:12 +0000
Subject: [pypy-issue] [issue1540] py3k: Re-enable strategies
In-Reply-To: <1374013692.43.0.673649554766.issue1540@bugs.pypy.org>
Message-ID: <1374013692.43.0.673649554766.issue1540@bugs.pypy.org>


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

The py3k branch has certain list strategies disabled, which is a performance 
regression.

I recall the dict's String strategy mysteriously breaking translation due to the 
py3 usages of space.setitem_str. The branch may benefit from a 
space.setitem_unicode

----------
assignedto: pjenvey
messages: 5937
nosy: pypy-issue
priority: performance bug
status: unread
title: py3k: Re-enable strategies

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

From tracker at bugs.pypy.org  Wed Jul 17 00:30:49 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 16 Jul 2013 22:30:49 +0000
Subject: [pypy-issue] [issue1541] py3k: Re-enable rpython int sized
	app-level int
In-Reply-To: <1374013849.16.0.768623384444.issue1541@bugs.pypy.org>
Message-ID: <1374013849.16.0.768623384444.issue1541@bugs.pypy.org>


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

This is a significant performance degradation on the py3k branch, basically 
intobject.py was disabled due to various obscure breakages.

I'm intending to kill int/long/bool's multimethods (unless someone else does 
first 
;] ) on default before mucking around with these types again

----------
assignedto: pjenvey
messages: 5938
nosy: pypy-issue
priority: performance bug
status: unread
title: py3k: Re-enable rpython int sized app-level int

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

From tracker at bugs.pypy.org  Wed Jul 17 00:31:52 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 16 Jul 2013 22:31:52 +0000
Subject: [pypy-issue] [issue1542] py3k test_memoryview test failures
In-Reply-To: <1374013912.03.0.122490729087.issue1542@bugs.pypy.org>
Message-ID: <1374013912.03.0.122490729087.issue1542@bugs.pypy.org>


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

memoryview on py3k still needs some work. Manuel Jacob has a branch (py3k-
memoryview) that has begun this work

----------
messages: 5939
nosy: mjacob, pypy-issue
priority: feature
status: unread
title: py3k test_memoryview test failures

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

From tracker at bugs.pypy.org  Wed Jul 17 00:32:33 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 16 Jul 2013 22:32:33 +0000
Subject: [pypy-issue] [issue1540] py3k: Re-enable strategies
In-Reply-To: <1374013692.43.0.673649554766.issue1540@bugs.pypy.org>
Message-ID: <1374013953.11.0.310060152292.issue1540@bugs.pypy.org>


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

Er, it's not just *list* strategies, also dict and maybe others

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

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

From tracker at bugs.pypy.org  Wed Jul 17 10:38:46 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 17 Jul 2013 08:38:46 +0000
Subject: [pypy-issue] [issue1543] numpypy: complex128.conjugate()
In-Reply-To: <1374050326.27.0.384852542188.issue1543@bugs.pypy.org>
Message-ID: <1374050326.27.0.384852542188.issue1543@bugs.pypy.org>


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

a = numpypy.array([1,2,3.4J],dtype=complex);
print type(a[2])    # <type 'numpypy.complex128'>
print a[2].conjugate()

This gives an error "unsupported operand type for conjugate: 'complex128'",
although the type complex128 is a subclass of the built-in 'complex'.  Check
also the other methods on int/long/float/complex, like is_integer().

----------
messages: 5941
nosy: arigo, pypy-issue
priority: bug
status: unread
title: numpypy: complex128.conjugate()

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

From tracker at bugs.pypy.org  Wed Jul 17 10:40:47 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 17 Jul 2013 08:40:47 +0000
Subject: [pypy-issue] [issue1544] numpypy: complex(complex128)
In-Reply-To: <1374050447.06.0.0816702513482.issue1544@bugs.pypy.org>
Message-ID: <1374050447.06.0.0816702513482.issue1544@bugs.pypy.org>


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

a = numpypy.array([1,2,3.4J],dtype=complex)
print a[2]            # 3.4j
print complex(a[2])   # 0j???

Bug.

----------
messages: 5942
nosy: arigo, pypy-issue
priority: bug
status: unread
title: numpypy: complex(complex128)

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

From tracker at bugs.pypy.org  Wed Jul 17 11:00:30 2013
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 17 Jul 2013 09:00:30 +0000
Subject: [pypy-issue] [issue1545] "from numpypy import *" doesn't yield abs,
	min, max etc
In-Reply-To: <1374051630.37.0.121725827072.issue1545@bugs.pypy.org>
Message-ID: <1374051630.37.0.121725827072.issue1545@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

Cpython:
>>> from numpy import abs
>>> abs((1, -2, 3))
array([1, 2, 3])

PyPy:
>>>> from numpypy import *
>>>> abs([1,-2,3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type for unary abs: 'list'
>>>> from numpypy import abs
>>>> abs([1,2,3])
array([1, 2, 3])

Same bug with max, min etc

----------
messages: 5943
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: "from numpypy import *" doesn't yield abs, min, max etc

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

From tracker at bugs.pypy.org  Wed Jul 17 11:05:42 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 17 Jul 2013 09:05:42 +0000
Subject: [pypy-issue] [issue1545] "from numpypy import *" doesn't yield abs,
	min, max etc
In-Reply-To: <1374051630.37.0.121725827072.issue1545@bugs.pypy.org>
Message-ID: <1374051942.17.0.972461578211.issue1545@bugs.pypy.org>


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

Closing as non-valid: the behavior seems the same to me.  Your example didn't
try "from numpy import *" in CPython, which also doesn't import abs.

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

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

From tracker at bugs.pypy.org  Wed Jul 17 13:28:21 2013
From: tracker at bugs.pypy.org (Peter)
Date: Wed, 17 Jul 2013 11:28:21 +0000
Subject: [pypy-issue] [issue1546] numpy.array(..., numpy.character) fails
In-Reply-To: <1374060501.91.0.057432681295.issue1546@bugs.pypy.org>
Message-ID: <1374060501.91.0.057432681295.issue1546@bugs.pypy.org>


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

Simple example using C Python 2.7 and NumPy 1.6.1,

$ python
Python 2.7.2 (default, Oct 11 2012, 20:14:37) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.character
<type 'numpy.character'>
>>> x = np.array([["A", "B"], ["C", "D"]], np.character)
>>> x
array([['A', 'B'],
       ['C', 'D']], 
      dtype='|S1')
>>> quit()

Attempting to repeat this on PyPy 2.0 using numpypy,

$ pypy
Python 2.7.3 (5acfe049a5b0, May 21 2013, 13:47:22)
[PyPy 2.0.2 with GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``Therefore, specific information,
I was in an ideal context, I had to realize the faith''
>>>> import numpypy
>>>> import numpy as np
>>>> np.character
<type 'numpypy.character'>
>>>> x = np.array([["A", "B"], ["C", "D"]], np.character)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: data type not understood (value of type type not expected here)
>>>> quit()

----------
messages: 5945
nosy: peterjc, pypy-issue
priority: bug
release: 2.0
status: unread
title: numpy.array(..., numpy.character) fails

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

From tracker at bugs.pypy.org  Wed Jul 17 13:57:48 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 17 Jul 2013 11:57:48 +0000
Subject: [pypy-issue] [issue1528] I/O in pypy is up to 2x slower than CPython
In-Reply-To: <1372932985.73.0.729755020573.issue1528@bugs.pypy.org>
Message-ID: <1374062268.66.0.323508167221.issue1528@bugs.pypy.org>


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

System: 8 core i7. OSX. Recent nightly.

* Changed xrange loop size to 10000000 instead of 100000. 
* real/user/sys times in seconds

               output file
          test.txt        /dev/null
CPython  6.9/4.2/0.8    4.0/4.0/0.01
pypy     7.4/2.4/0.6    2.4/2.4/0.06


Not sure that this is an actual pypy issue - maybe a filesystem dependent timing 
problem?

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

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

From tracker at bugs.pypy.org  Wed Jul 17 14:30:39 2013
From: tracker at bugs.pypy.org (Lefteris Stamatogiannakis)
Date: Wed, 17 Jul 2013 12:30:39 +0000
Subject: [pypy-issue] [issue1528] I/O in pypy is up to 2x slower than CPython
In-Reply-To: <1372932985.73.0.729755020573.issue1528@bugs.pypy.org>
Message-ID: <1374064239.25.0.256031792669.issue1528@bugs.pypy.org>


Lefteris Stamatogiannakis <estama at gmail.com> added the comment:

I've just retested with today's pypy nightly build, and Ubuntu 13.04. I've also
changed xrange to 10000000 instead of 100000 (like mikefc). Below are best of 3
runs:

Cpython:
3.28s user 0.90s system 52% cpu 7.968 total

PyPy:
1.96s user 0.94s system 37% cpu 7.771 total

So i think that this issue can be closed as resolved.

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

From tracker at bugs.pypy.org  Wed Jul 17 16:46:01 2013
From: tracker at bugs.pypy.org (Peter)
Date: Wed, 17 Jul 2013 14:46:01 +0000
Subject: [pypy-issue] [issue1546] numpy.array(..., numpy.character) fails
In-Reply-To: <1374060501.91.0.057432681295.issue1546@bugs.pypy.org>
Message-ID: <1374072361.54.0.729533128682.issue1546@bugs.pypy.org>


Peter <p.j.a.cock at googlemail.com> added the comment:

Same failure under PyPy 2.1 beta

----------
release: 2.0 -> 2.1
status: unread -> chatting

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

From tracker at bugs.pypy.org  Wed Jul 17 17:10:10 2013
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Wed, 17 Jul 2013 15:10:10 +0000
Subject: [pypy-issue] [issue1547] Speed regressions vs. CPython for project
	euler programs
In-Reply-To: <1374073810.95.0.281022374318.issue1547@bugs.pypy.org>
Message-ID: <1374073810.95.0.281022374318.issue1547@bugs.pypy.org>


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

serge_sans_paill on IRC said the following:

I have been running pypy on the benchmarks from this repo:
https://github.com/serge-sans-paille/pythran/tree/master/pythran/tests/euler
and found a few situations where pypy performs slower than cpython
for the following test cases, pypy is slower than cpython on my machine
('euler05', 27.2) 13
('euler06', 17.4) 6.89
('euler13', 12.1) 4.1
('euler15', 20.9) 5.22
('euler19', 409) 378
('euler20', 142) 85.5
('euler24', 48.8) 14.8
('euler29', 14600.0) 13900.0
('euler40', 24.3) 13.3
('euler57', 13000) 2790.0
first enrty is the test case name, second entry is pypy's timing measuer by
timeit, last entry is cpython timing I ran timeit -n 10 -r 3

----------
messages: 5949
nosy: cfbolz, pypy-issue
priority: performance bug
status: unread
title: Speed regressions vs. CPython for project euler programs

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

From tracker at bugs.pypy.org  Wed Jul 17 21:09:41 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 17 Jul 2013 19:09:41 +0000
Subject: [pypy-issue] [issue1547] Speed regressions vs. CPython for project
	euler programs
In-Reply-To: <1374073810.95.0.281022374318.issue1547@bugs.pypy.org>
Message-ID: <1374088181.4.0.386934406386.issue1547@bugs.pypy.org>


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

I find it hard to reproduce.  For example, I modified euler24.py to call 500'000
times the function solve(), and it takes 11.3 seconds on CPython 2.7 versus 1.91
seconds on PyPy 2.0.2.  Running the same function with "timeit -n 10 -r 3"
doesn't make any sense at all, because it takes no measurable time.

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

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

From tracker at bugs.pypy.org  Wed Jul 17 21:12:48 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 17 Jul 2013 19:12:48 +0000
Subject: [pypy-issue] [issue1547] Speed regressions vs. CPython for project
	euler programs
In-Reply-To: <1374073810.95.0.281022374318.issue1547@bugs.pypy.org>
Message-ID: <1374088368.1.0.541651323287.issue1547@bugs.pypy.org>


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

euler57 is about calling str() on a rather large 'long'.  See
https://bugs.pypy.org/issue1488

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

From tracker at bugs.pypy.org  Wed Jul 17 21:14:07 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 17 Jul 2013 19:14:07 +0000
Subject: [pypy-issue] [issue1547] Speed regressions vs. CPython for project
	euler programs
In-Reply-To: <1374073810.95.0.281022374318.issue1547@bugs.pypy.org>
Message-ID: <1374088447.16.0.582307943828.issue1547@bugs.pypy.org>


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

euler29 is about "a ** b" resulting in a largish 'long' integer.  The fact that
it's almost as fast in PyPy and in CPython is good enough.

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

From tracker at bugs.pypy.org  Wed Jul 17 21:16:39 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 17 Jul 2013 19:16:39 +0000
Subject: [pypy-issue] [issue1547] Speed regressions vs. CPython for project
	euler programs
In-Reply-To: <1374073810.95.0.281022374318.issue1547@bugs.pypy.org>
Message-ID: <1374088599.37.0.655302520773.issue1547@bugs.pypy.org>


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

euler19 is more than 10 times faster on PyPy if we let "timeit" figure out the
total run time.  I suspect the others to be the same, and I'll stop looking at
this point and close this as invalid.

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

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

From tracker at bugs.pypy.org  Wed Jul 17 23:32:01 2013
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Wed, 17 Jul 2013 21:32:01 +0000
Subject: [pypy-issue] [issue1488] 'str(long)' slower in PyPy
In-Reply-To: <1368775751.52.0.789251725482.issue1488@bugs.pypy.org>
Message-ID: <1374096721.54.0.50813891578.issue1488@bugs.pypy.org>


Carl Friedrich Bolz <cfbolz at gmx.de> added the comment:

Actually with my recent work on str(long) this is really just fixed. The
original script is about twice as fast as CPython with my current build (and
will get even faster when as more elements of the generator are consumed).

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

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

From tracker at bugs.pypy.org  Thu Jul 18 19:47:49 2013
From: tracker at bugs.pypy.org (Garen Parham)
Date: Thu, 18 Jul 2013 17:47:49 +0000
Subject: [pypy-issue] [issue1441] version of sqlite3.dll (and others)
In-Reply-To: <1365447553.59.0.396875761201.issue1441@bugs.pypy.org>
Message-ID: <1374169669.73.0.777047776249.issue1441@bugs.pypy.org>


Garen Parham <garen.p at gmail.com> added the comment:

FWIW:

C:\views\dev\pypy\pypy-2.0.2>.\pypy.exe
Python 2.7.3 (00a6764b871b, May 20 2013, 14:15:12)
[PyPy 2.0.2 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``it's Sunday, maybe''
>>>> import sqlite3
>>>> sqlite3.sqlite_version
'3.5.9'

C:\views\dev\pypy\pypy-2.1-beta-win32>pypy.exe
Python 2.7.3 (daf1b0412bfb, Jul 11 2013, 05:57:43)
[PyPy 2.1.0-beta1 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``samuele says that we lost a
razor. so we can't shave yaks''
>>>> import sqlite3
>>>> sqlite3.sqlite_version
'3.5.9'

garepa at swslinux1:~/dev/pypy-2.1-beta-linux64/bin$ ./pypy
Python 2.7.3 (daf1b0412bfb, Jul 10 2013, 15:23:15)
[PyPy 2.1.0-beta1 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``I am a big believer in reasons.
but the apparent kind are my favorite.''
>>>> import sqlite3
>>>> sqlite3.sqlite_version
'3.7.9'

So the win32 version of pypy is picking up an old version of sqlite (3.5.9) as 
suspected.

Note that CPython 2.7.3 and 2.7.5 reports '3.6.21':

C:\Python\x86\pyorg\2.7.3>.\python.exe
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.sqlite_version
'3.6.21'

C:\Python\x86\pyorg\2.7.5>.\python.exe
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.sqlite_version
'3.6.21'

Quite a smorgasbord of inconsistency.

----------
nosy: +Garen
release:  -> 2.1
status: unread -> chatting

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

From tracker at bugs.pypy.org  Fri Jul 19 10:59:05 2013
From: tracker at bugs.pypy.org (Dmitrey)
Date: Fri, 19 Jul 2013 08:59:05 +0000
Subject: [pypy-issue] [issue1548] numpypy ravel() bug
In-Reply-To: <1374224345.91.0.76779882319.issue1548@bugs.pypy.org>
Message-ID: <1374224345.91.0.76779882319.issue1548@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> from numpy import *
>>> ravel(float64(1))
array([ 1.])

>>>> from numpypy import *
>>>> ravel(float64(1.0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/home/dmitrey/Install/pypy-c-jit-65418-d49964ac4b2c-linux/lib_pypy/numpypy/core/fromnumeric.py",
line 1061, in ravel
    return a.ravel(order=order)
TypeError: ravel() got an unexpected keyword argument 'order'

----------
messages: 5956
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy ravel() bug

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

From tracker at bugs.pypy.org  Fri Jul 19 11:33:20 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Fri, 19 Jul 2013 09:33:20 +0000
Subject: [pypy-issue] [issue1548] numpypy ravel() bug
In-Reply-To: <1374224345.91.0.76779882319.issue1548@bugs.pypy.org>
Message-ID: <1374226400.15.0.587064596447.issue1548@bugs.pypy.org>


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

For some reason, in fromnumeric.py, ravel() implementation is different from the 
original numpy;  the latter works :-)

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

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

From tracker at bugs.pypy.org  Fri Jul 19 16:04:56 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 14:04:56 +0000
Subject: [pypy-issue] [issue1549] eventlet errors on PyPy, but not CPython
In-Reply-To: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>
Message-ID: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>


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

Code to reproduce: this is extracted from openstack-eventlet


import sys

from eventlet import GreenPool


class ContextPool(GreenPool):
    "GreenPool subclassed to kill its coros when it gets gc'ed"

    def __enter__(self):
        return self

    def __exit__(self, type, value, traceback):
        for coro in list(self.coroutines_running):
            coro.kill()


def _noop():
    pass


def main(argv):
    with ContextPool(3) as pool:
        pool.spawn(_noop)


if __name__ == "__main__":
    main(sys.argv)

----------
messages: 5958
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: eventlet errors on PyPy, but not CPython

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

From tracker at bugs.pypy.org  Fri Jul 19 18:56:50 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 16:56:50 +0000
Subject: [pypy-issue] [issue1549] eventlet errors on PyPy, but not CPython
In-Reply-To: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>
Message-ID: <1374253010.42.0.052784932369.issue1549@bugs.pypy.org>


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

I simplified a bit further:

from eventlet import GreenPool


def _noop():
    pass


def main():
    pool = GreenPool()
    coro = pool.spawn(_noop)
    coro.kill()


if __name__ == "__main__":
    main()

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

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

From tracker at bugs.pypy.org  Fri Jul 19 18:59:30 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 16:59:30 +0000
Subject: [pypy-issue] [issue1549] eventlet errors on PyPy, but not CPython
In-Reply-To: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>
Message-ID: <1374253170.26.0.466348407089.issue1549@bugs.pypy.org>


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

One final minimization:

import eventlet


def _noop():
    pass


def main():
    coro = eventlet.spawn(_noop)
    coro.kill()

if __name__ == "__main__":
    main()

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

From tracker at bugs.pypy.org  Fri Jul 19 19:25:53 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 17:25:53 +0000
Subject: [pypy-issue] [issue1549] eventlet errors on PyPy, but not CPython
In-Reply-To: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>
Message-ID: <1374254753.16.0.683985290717.issue1549@bugs.pypy.org>


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

Ok, now works without eventlet:

import greenlet


def _noop():
    pass


def main():
    coro = greenlet.greenlet(_noop)
    coro.throw(greenlet.GreenletExit)

if __name__ == "__main__":
    main()

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

From tracker at bugs.pypy.org  Fri Jul 19 19:45:36 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 17:45:36 +0000
Subject: [pypy-issue] [issue1549] eventlet errors on PyPy, but not CPython
In-Reply-To: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>
Message-ID: <1374255936.37.0.409922162999.issue1549@bugs.pypy.org>


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

As far as I can tell the issue is that there's some missing logic about 
GreenletExit (https://github.com/python-
greenlet/greenlet/blob/master/greenlet.c#L655) this is called from throw_greenlet. 
I'm not quite sure how to apply this to PyPy's greenlet.py though.

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

From tracker at bugs.pypy.org  Fri Jul 19 20:45:55 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 19 Jul 2013 18:45:55 +0000
Subject: [pypy-issue] [issue1549] eventlet errors on PyPy, but not CPython
In-Reply-To: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>
Message-ID: <1374259555.72.0.152909897678.issue1549@bugs.pypy.org>


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

Should be fixed: 694068eb90e4, e9608727658c, 32a376d76708

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

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

From tracker at bugs.pypy.org  Fri Jul 19 23:01:08 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 21:01:08 +0000
Subject: [pypy-issue] [issue1550] SQLITE: Creating function with the same
	name twice fails	when in journal_mode = MEMORY
In-Reply-To: <1374267668.26.0.714242674295.issue1550@bugs.pypy.org>
Message-ID: <1374267668.26.0.714242674295.issue1550@bugs.pypy.org>


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

This code fails on PyPy, but runs on CPython:

import sqlite3


def f():
    pass

conn = sqlite3.connect(":memory:")
conn.execute("PRAGMA journal_mode = MEMORY")
conn.create_function("func", 0, f)
conn.create_function("func", 0, f)

----------
messages: 5964
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: SQLITE: Creating function with the same name twice fails when in journal_mode = MEMORY

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

From tracker at bugs.pypy.org  Fri Jul 19 23:56:28 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 21:56:28 +0000
Subject: [pypy-issue] [issue1550] SQLITE: Creating function with the same
	name twice fails	when in journal_mode = MEMORY
In-Reply-To: <1374267668.26.0.714242674295.issue1550@bugs.pypy.org>
Message-ID: <1374270988.15.0.51234431276.issue1550@bugs.pypy.org>


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

Ended up being a gc thing. Ignore!

----------
status: unread -> invalid

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

From tracker at bugs.pypy.org  Sat Jul 20 01:26:54 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 23:26:54 +0000
Subject: [pypy-issue] [issue1549] eventlet errors on PyPy, but not CPython
In-Reply-To: <1374242696.2.0.733720932499.issue1549@bugs.pypy.org>
Message-ID: <1374276414.76.0.976997765728.issue1549@bugs.pypy.org>


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

Appears to be fixed! Awesome job.

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

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

From tracker at bugs.pypy.org  Sat Jul 20 01:28:14 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 19 Jul 2013 23:28:14 +0000
Subject: [pypy-issue] [issue1551] os.statvfs and os.fstatvfs missing
In-Reply-To: <1374276494.12.0.654662033172.issue1551@bugs.pypy.org>
Message-ID: <1374276494.12.0.654662033172.issue1551@bugs.pypy.org>


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

There's an existing issue covering "os module is incomplete", but filing this 
specifically because I need it :]

----------
messages: 5967
nosy: agaynor, pypy-issue
priority: feature
status: unread
title: os.statvfs and os.fstatvfs missing

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

From tracker at bugs.pypy.org  Sat Jul 20 10:21:51 2013
From: tracker at bugs.pypy.org (Fantix King)
Date: Sat, 20 Jul 2013 08:21:51 +0000
Subject: [pypy-issue] [issue1552] API incompatibility: GreenletExit should
	base on	BaseException
In-Reply-To: <1374308511.36.0.108790196409.issue1552@bugs.pypy.org>
Message-ID: <1374308511.36.0.108790196409.issue1552@bugs.pypy.org>


New submission from Fantix King <fantix.king at gmail.com>:

GreenletExit should inherit from BaseException according to this:

https://github.com/python-
greenlet/greenlet/commit/2f81f5de275c8dad13c5497c540ab96952a24071

But in pypy it is a subclass of Exception.

----------
messages: 5968
nosy: fantix, pypy-issue
priority: bug
status: unread
title: API incompatibility: GreenletExit should base on BaseException

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

From tracker at bugs.pypy.org  Sat Jul 20 14:02:57 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 20 Jul 2013 12:02:57 +0000
Subject: [pypy-issue] [issue1552] API incompatibility: GreenletExit should
	base on	BaseException
In-Reply-To: <1374308511.36.0.108790196409.issue1552@bugs.pypy.org>
Message-ID: <1374321777.72.0.339614530525.issue1552@bugs.pypy.org>


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

Thanks!  Fixed in 30c281188d1c.

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

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

From tracker at bugs.pypy.org  Sun Jul 21 20:37:00 2013
From: tracker at bugs.pypy.org (Ven)
Date: Sun, 21 Jul 2013 18:37:00 +0000
Subject: [pypy-issue] [issue1553] Problem in PyPy's readline module when
	using PyCharm
In-Reply-To: <1374431820.96.0.850394649765.issue1553@bugs.pypy.org>
Message-ID: <1374431820.96.0.850394649765.issue1553@bugs.pypy.org>


New submission from Ven <karri.ven at gmail.com>:

Figured that PyPy is making assumptions that PyCharm is not satisfying. Not sure 
who's fault is it at the moment:

So, apparently PyPy's readline module seems to have the problem ONLY inside 
PyCharm.

If I run the same command in the os x terminal it runs absolutely fine. So, we 
can't really blame PyPy here either. But, any help would be greatly appreciated.

----------
files: Screen Shot 2013-07-21 at 2.08.47 PM.png
messages: 5970
nosy: imperialguy, pypy-issue
priority: bug
release: 2.0
status: unread
title: Problem in PyPy's readline module when using PyCharm

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

From tracker at bugs.pypy.org  Tue Jul 23 13:57:02 2013
From: tracker at bugs.pypy.org (Jan Varho)
Date: Tue, 23 Jul 2013 11:57:02 +0000
Subject: [pypy-issue] [issue1554] Regression: getting a small slice of a
	range list	allocates the whole range list
In-Reply-To: <1374580622.05.0.328549543364.issue1554@bugs.pypy.org>
Message-ID: <1374580622.05.0.328549543364.issue1554@bugs.pypy.org>


New submission from Jan Varho <jan.varho at gmail.com>:

A change introduced in ad495c3 causes a MemoryError in code that worked fine in 
1.9. The commit undoes an optimization for getslice ona list that uses 
RangeListStrategy. The rationale cited is an overflow, but the test added 
(test_range_getslice_ovf) actually passes with the optimized code from prior to 
the commit.

A simplistic example of code that regressed is something like:
a = range(1, sys.maxint) # the natural numbers
b = a[:N] # do something with the first N

Reverting the getslice method of RangeListStrategy to the version prior to 
ad495c3 and changing test_range_getslice_ovf to assert that l2 is using 
RangeListStrategy seems to work fine.

----------
messages: 5971
nosy: otus, pypy-issue
priority: bug
release: 2.1
status: unread
title: Regression: getting a small slice of a range list allocates the whole range list

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

From tracker at bugs.pypy.org  Tue Jul 23 14:24:34 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Jul 2013 12:24:34 +0000
Subject: [pypy-issue] [issue1554] Regression: getting a small slice of a
	range list	allocates the whole range list
In-Reply-To: <1374580622.05.0.328549543364.issue1554@bugs.pypy.org>
Message-ID: <1374582274.42.0.580217999724.issue1554@bugs.pypy.org>


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

Did you try to run test_issue1266_ovf?

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

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

From tracker at bugs.pypy.org  Tue Jul 23 14:28:52 2013
From: tracker at bugs.pypy.org (Jan Varho)
Date: Tue, 23 Jul 2013 12:28:52 +0000
Subject: [pypy-issue] [issue1554] Regression: getting a small slice of a
	range list	allocates the whole range list
In-Reply-To: <1374580622.05.0.328549543364.issue1554@bugs.pypy.org>
Message-ID: <1374582532.72.0.537286886596.issue1554@bugs.pypy.org>


Jan Varho <jan.varho at gmail.com> added the comment:

Oh, I didn't see it was also relevant. Anyway, it passes as well.

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

From tracker at bugs.pypy.org  Tue Jul 23 17:19:11 2013
From: tracker at bugs.pypy.org (Manuel Ebert)
Date: Tue, 23 Jul 2013 15:19:11 +0000
Subject: [pypy-issue] [issue1555] "bug" on
	http://www.pypy.org/performance.html
In-Reply-To: <1374592751.11.0.515552527848.issue1555@bugs.pypy.org>
Message-ID: <1374592751.11.0.515552527848.issue1555@bugs.pypy.org>


New submission from Manuel Ebert <manuel at 1450.me>:

Under "String concatenation is expensive", it suggests using

    s = "%(head)s%(body)s%(maybe)s%(tail)s" % locals()

or

    s = "{head}{body}{maybe}{tail}".format(locals())

The latter should read `.format(**locals())` instead.

----------
messages: 5974
nosy: maebert, pypy-issue
priority: bug
status: unread
title: "bug" on http://www.pypy.org/performance.html

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

From tracker at bugs.pypy.org  Tue Jul 23 17:28:13 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 23 Jul 2013 15:28:13 +0000
Subject: [pypy-issue] [issue1555] "bug" on
	http://www.pypy.org/performance.html
In-Reply-To: <1374592751.11.0.515552527848.issue1555@bugs.pypy.org>
Message-ID: <1374593293.25.0.933245415772.issue1555@bugs.pypy.org>


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

Fixed. Will be deployed within 30 minutes!

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

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

From tracker at bugs.pypy.org  Tue Jul 23 22:43:39 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 23 Jul 2013 20:43:39 +0000
Subject: [pypy-issue] [issue1556] py3k: _pypyjson test failures
In-Reply-To: <1374612219.5.0.0601955996778.issue1556@bugs.pypy.org>
Message-ID: <1374612219.5.0.0601955996778.issue1556@bugs.pypy.org>


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

test__pypyjson now fully passes on the py3k branch, but when it's enabled (via 
the attached patch) it triggers a couple failures of json's stdlib test suite:

======================================================================
FAIL: test_keys_reuse (test.json_tests.test_decode.TestPyDecode)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pjenvey/Downloads/pypy-c-jit-65533-41898d5a38dd-osx64/lib-
python/3/test/json_tests/test_decode.py", line 54, in test_keys_reuse
    self.check_keys_reuse(s, self.loads)
  File "/Users/pjenvey/Downloads/pypy-c-jit-65533-41898d5a38dd-osx64/lib-
python/3/test/json_tests/test_decode.py", line 49, in check_keys_reuse
    self.assertIs(a, c)
AssertionError: 'a_key' is not 'a_key'

======================================================================
FAIL: test_failures (test.json_tests.test_fail.TestPyFail)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pjenvey/Downloads/pypy-c-jit-65533-41898d5a38dd-osx64/lib-
python/3/test/json_tests/test_fail.py", line 74, in test_failures
    self.fail("Expected failure for fail{0}.json: {1!r}".format(idx, doc))
AssertionError: Expected failure for fail25.json: '["A\x1fZ control characters 
in string"]'

----------------------------------------------------------------------
Ran 92 tests in 20.559s

FAILED (failures=2, skipped=47)


Also attached is a patch adding these 2 failing tests to test__pypyjson.

test_keys_reuse involves additional caching for the sake of performance:
http://bugs.python.org/issue7451

test_failures deals with invalid control characters:
https://code.google.com/p/simplejson/issues/detail?id=3

----------
assignedto: antocuni
files: py3k-enable-_pypyjson.diff
messages: 5976
nosy: pypy-issue
priority: bug
status: unread
title: py3k: _pypyjson test failures

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

From tracker at bugs.pypy.org  Tue Jul 23 22:55:28 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 23 Jul 2013 20:55:28 +0000
Subject: [pypy-issue] [issue1471] py3k: Re-enable strategies
In-Reply-To: <1367354487.89.0.178259207003.issue1471@bugs.pypy.org>
Message-ID: <1374612928.21.0.778200004126.issue1471@bugs.pypy.org>


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

I'll just note that this is indeed a performance regression.

Also, I recall the dict's String strategy mysteriously breaking translation due to 
the py3 usages of space.setitem_str. The branch may benefit from a 
space.setitem_unicode

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

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

From tracker at bugs.pypy.org  Tue Jul 23 22:55:55 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 23 Jul 2013 20:55:55 +0000
Subject: [pypy-issue] [issue1540] py3k: Re-enable strategies
In-Reply-To: <1374013692.43.0.673649554766.issue1540@bugs.pypy.org>
Message-ID: <1374612955.94.0.510259318169.issue1540@bugs.pypy.org>


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

Woops, forgot I logged this a while ago. dupe of #1471

----------
status: chatting -> duplicate
superseder: +py3k: Re-enable strategies

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

From tracker at bugs.pypy.org  Wed Jul 24 03:09:00 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Wed, 24 Jul 2013 01:09:00 +0000
Subject: [pypy-issue] [issue1557] py3k: cpyext's
	test_structseq.test_StructSeq fails
In-Reply-To: <1374628140.58.0.562490896829.issue1557@bugs.pypy.org>
Message-ID: <1374628140.58.0.562490896829.issue1557@bugs.pypy.org>


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

This is failing because structseqs in py3 are now subtypes of tuple which cpyext 
does not currently support.

https://bitbucket.org/pypy/pypy/commits/0eaf96f13694 added cpyext support for 
subclasses of int

I noticed https://bitbucket.org/pypy/pypy/commits/f258f6c1143a which added 
similar machinery for tuple (among other things), but this was later reverted:

https://bitbucket.org/pypy/pypy/commits/894060e8bb04

----------
messages: 5979
nosy: amaury, pypy-issue
priority: feature
status: unread
title: py3k: cpyext's test_structseq.test_StructSeq fails

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

From tracker at bugs.pypy.org  Wed Jul 24 15:52:35 2013
From: tracker at bugs.pypy.org (Anatoly)
Date: Wed, 24 Jul 2013 13:52:35 +0000
Subject: [pypy-issue] [issue1558] Pickling of connection support for Mac OSX
	and Linux
In-Reply-To: <1374673955.13.0.874083116912.issue1558@bugs.pypy.org>
Message-ID: <1374673955.13.0.874083116912.issue1558@bugs.pypy.org>


New submission from Anatoly <a.vostrjakov at gmail.com>:

There isn't pickling of connection support now. Without this functionality is 
not possible pass file descriptor (open socket actually) to another process. If 
I try to import reduce_handle or rebuild_handle from multiprocessing.reduction I 
see following:

from multiprocessing.reduction import reduce_handle, rebuild_handle
  File "/Users/avostryakov/python/pypy/lib-
python/2.7/multiprocessing/reduction.py", line 55, in <module>
    raise ImportError('pickling of connections not supported')

When I looking in multiprocessing/reduction.py I see:

if not(sys.platform == 'win32' or hasattr(_multiprocessing, 'recvfd')):
    raise ImportError('pickling of connections not supported')

So, There isn't 'recvfd' in _multiprocessing module.

----------
messages: 5980
nosy: pypy-issue, vostryakov
priority: bug
release: 2.1
status: unread
title: Pickling of connection support for Mac OSX and Linux

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

From tracker at bugs.pypy.org  Wed Jul 24 16:30:05 2013
From: tracker at bugs.pypy.org (Anatoly)
Date: Wed, 24 Jul 2013 14:30:05 +0000
Subject: [pypy-issue] [issue1553] Problem in PyPy's readline module when
	using PyCharm
In-Reply-To: <1374431820.96.0.850394649765.issue1553@bugs.pypy.org>
Message-ID: <1374676205.41.0.989948806517.issue1553@bugs.pypy.org>


Anatoly <a.vostrjakov at gmail.com> added the comment:

I'm using PyCharm 2.7.3 and can't reproduce the bug. My console log is 
following:

>>> import readline
No entry for terminal type "emacs";
using dumb terminal settings.
>>> readline.clear_history()
>>>

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

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

From tracker at bugs.pypy.org  Thu Jul 25 22:46:31 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Thu, 25 Jul 2013 20:46:31 +0000
Subject: [pypy-issue] [issue1518] setting PYTHONINSPECT during a script run
	won't start	interactive mode in pypy
In-Reply-To: <1371555381.62.0.376742745434.issue1518@bugs.pypy.org>
Message-ID: <1374785191.94.0.476230529903.issue1518@bugs.pypy.org>


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

Fixed w/

https://bitbucket.org/pypy/pypy/pull-request/168/fix-pythoninspect-behaviour/diff

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

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

From tracker at bugs.pypy.org  Thu Jul 25 23:26:48 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 25 Jul 2013 21:26:48 +0000
Subject: [pypy-issue] [issue1551] os.statvfs and os.fstatvfs missing
In-Reply-To: <1374276494.12.0.654662033172.issue1551@bugs.pypy.org>
Message-ID: <1374787608.8.0.252616993717.issue1551@bugs.pypy.org>


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

fixed :D

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

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

From tracker at bugs.pypy.org  Fri Jul 26 13:15:30 2013
From: tracker at bugs.pypy.org (Simon Sapin)
Date: Fri, 26 Jul 2013 11:15:30 +0000
Subject: [pypy-issue] [issue1560] Ambiguous grammar in install docs
In-Reply-To: <1374837330.29.0.503902263585.issue1560@bugs.pypy.org>
Message-ID: <1374837330.29.0.503902263585.issue1560@bugs.pypy.org>


New submission from Simon Sapin <simon.sapin at kozea.fr>:

The docs at http://doc.pypy.org/en/latest/getting-started-python.html say:

    possibly replacing --opt=jit with another optimization level of your choice
like --opt=2 if you do not want to include the JIT compiler, which makes the
Python interpreter much slower.

I first read this as "the JIT makes the interpreter slower" before I realize it
could also mean "not including the JIT makes the interpreter slower" ;)

----------
messages: 5984
nosy: SimonSapin, pypy-issue
priority: bug
status: unread
title: Ambiguous grammar in install docs

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

From tracker at bugs.pypy.org  Fri Jul 26 17:08:36 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 26 Jul 2013 15:08:36 +0000
Subject: [pypy-issue] [issue1560] Ambiguous grammar in install docs
In-Reply-To: <1374837330.29.0.503902263585.issue1560@bugs.pypy.org>
Message-ID: <1374851316.08.0.422791365163.issue1560@bugs.pypy.org>


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

Thanks!  Fixed in e46fd79aed8e:

    possibly replacing ``--opt=jit`` with another `optimization level`_
+   of your choice.  Typical example: ``--opt=2`` gives a good (but of
+   course slower) Python interpreter without the JIT.

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

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

From tracker at bugs.pypy.org  Fri Jul 26 23:14:15 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 26 Jul 2013 21:14:15 +0000
Subject: [pypy-issue] [issue1558] Pickling of connection support for Mac OSX
	and Linux
In-Reply-To: <1374673955.13.0.874083116912.issue1558@bugs.pypy.org>
Message-ID: <1374873255.76.0.190637893921.issue1558@bugs.pypy.org>


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

Just to know, can you point to a place in the doc that says anything about
multiprocessing.reduction.{reduce,rebuild}_handle?  (Likely, it does not matter
and we have to support it, but I'd just like some official confirmation...)

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

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

From tracker at bugs.pypy.org  Sat Jul 27 01:15:08 2013
From: tracker at bugs.pypy.org (Anatoly)
Date: Fri, 26 Jul 2013 23:15:08 +0000
Subject: [pypy-issue] [issue1558] Pickling of connection support for Mac OSX
	and Linux
In-Reply-To: <1374673955.13.0.874083116912.issue1558@bugs.pypy.org>
Message-ID: <1374880508.08.0.606160819416.issue1558@bugs.pypy.org>


Anatoly <a.vostrjakov at gmail.com> added the comment:

It looks like multiprocessing.reduction is an undocumented module in Python 2.x. 
But people use it. 

I should explain why I need it. When I'm creating a server that is listing 
TCP/IP sockets and create a separate thread for every connection the problem is 
I can't utilize all CPU cores because of Python GIL. In my case it is a real 
problem, I tested. So, I should create a pool of processes to handle connections 
and pass an opened connection to a process that I can send information to a 
client during process execution. So, I reduce socket: h = 
reduce_handle(self.request.fileno()) and pass 'h' to a process. Inside process I 
restore it: fd = rebuild_handle(h); client_socket = socket.fromfd(fd, 
socket.AF_INET, socket.SOCK_STREAM).

  I liked how it works. It is stable in production under Python 2.7.x and I 
don't know why it wasn't documented.

P.S. Some links:
Restore functionality of multiprocessing.reduction in Python 3.3:
http://bugs.python.org/issue4892

Short doc of _multiprocessing module: 
http://doc.astro-wise.org/_multiprocessing.html

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

From tracker at bugs.pypy.org  Sat Jul 27 01:28:05 2013
From: tracker at bugs.pypy.org (Alex Stewart)
Date: Fri, 26 Jul 2013 23:28:05 +0000
Subject: [pypy-issue] [issue1561] cppyy error binding enums
In-Reply-To: <1374881285.26.0.582336783705.issue1561@bugs.pypy.org>
Message-ID: <1374881285.26.0.582336783705.issue1561@bugs.pypy.org>


New submission from Alex Stewart <foogod at gmail.com>:

For C++ classes which use enum types, the bindings generated by cppyy create a 
binding for the enum type (it shows up in 'dir(cppyy.gbl)'), but attempting to 
reference it produces an error:

>>>> import cppyy
>>>> cppyy.load_reflection_info('libMyClass.so')
<CPPLibrary object at 0x00007f2b7c210730>
>>>> dir(cppyy.gbl)
['MyClass', 'MyEnum']
>>>> cppyy.gbl.MyClass
<class '__main__.MyClass'>
>>>> cppyy.gbl.MyEnum
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: <class '__main__.::'> object has no attribute 'MyEnum' (details: 
<class '__main__.::'> object has no attribute 'unsigned int' (details: '<class 
'__main__.::'>' has no attribute 'unsigned int'))

This is arguably mainly cosmetic, as enums map to ints, so it's never normally 
necessary to instantiate the enum type explicitly anyway, but it can still 
potentially cause some annoyance/confusion in some scenarios.

(For example, I discovered this because I have a sanity-check script which I run 
against any generated bindings to make sure that all the generated symbols are 
loadable, which fails on any library that references any enums currently...)

----------
files: MyClass.h
messages: 5988
nosy: Foogod, pypy-issue
priority: bug
status: unread
title: cppyy error binding enums

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

From tracker at bugs.pypy.org  Sat Jul 27 10:18:12 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 27 Jul 2013 08:18:12 +0000
Subject: [pypy-issue] [issue1558] Pickling of connection support for Mac OSX
	and Linux
In-Reply-To: <1374673955.13.0.874083116912.issue1558@bugs.pypy.org>
Message-ID: <1374913092.17.0.065197352612.issue1558@bugs.pypy.org>


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

Looks like multiprocessing_sendfd() and multiprocessing_recvfd() in
Modules/_multiprocessing/multiprocessing.c.  They are not-too-long independent
functions.  Shouldn't be too hard to add them (any volonteer?)

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

From tracker at bugs.pypy.org  Sat Jul 27 11:32:49 2013
From: tracker at bugs.pypy.org (Anatoly)
Date: Sat, 27 Jul 2013 09:32:49 +0000
Subject: [pypy-issue] [issue1558] Pickling of connection support for Mac OSX
	and Linux
In-Reply-To: <1374673955.13.0.874083116912.issue1558@bugs.pypy.org>
Message-ID: <1374917569.35.0.283284017011.issue1558@bugs.pypy.org>


Anatoly <a.vostrjakov at gmail.com> added the comment:

I hope I can be a volunteer :) So, I found a source code of multiprocessing.c 
with multiprocessing_sendfd() and multiprocessing_recvfd():
http://svn.python.org/projects/python/branches/pep-
0384/Modules/_multiprocessing/multiprocessing.c

But I can't find Modules/_multiprocessing/multiprocessing.c on 
https://bitbucket.org/pypy/pypy/src/
All I found is following:
https://bitbucket.org/pypy/pypy/src/ea4433a5cfef/pypy/module/_multiprocessing?
at=default

What I have to do the next? It likes that I have to convert some way 
multiprocessing_sendfd and multiprocessing_recvfd from multiprocessing.c to 
rpython code.

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

From tracker at bugs.pypy.org  Sat Jul 27 11:39:03 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 27 Jul 2013 09:39:03 +0000
Subject: [pypy-issue] [issue1558] Pickling of connection support for Mac OSX
	and Linux
In-Reply-To: <1374673955.13.0.874083116912.issue1558@bugs.pypy.org>
Message-ID: <1374917943.22.0.222312390782.issue1558@bugs.pypy.org>


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

Yes, that's why you won't find multiprocessing.c in PyPy.  I meant to point to
the standard CPython 2.7 branch of multiprocessing.c.

If you want to help, you're welcome!  Please come to IRC for help, it is more
suited than a bug tracker.

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

From tracker at bugs.pypy.org  Sat Jul 27 21:05:23 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 27 Jul 2013 19:05:23 +0000
Subject: [pypy-issue] [issue1562] MacOSX: "clang" and "-undefined
	dynamic_lookup"
In-Reply-To: <1374951923.06.0.788141741646.issue1562@bugs.pypy.org>
Message-ID: <1374951923.06.0.788141741646.issue1562@bugs.pypy.org>


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

translator/platform/darwin.py was changed to make "clang" the default compiler
instead of "gcc".  But the options in _args_for_shared() seem not to be accepted
by clang.  (Not that I have a more precise clue, but shared builds on OS/X don't
work any more because of that).  Look and fix.

----------
messages: 5992
nosy: arigo, pypy-issue
priority: bug
status: unread
title: MacOSX: "clang" and "-undefined dynamic_lookup"

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

From tracker at bugs.pypy.org  Sat Jul 27 21:29:25 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 27 Jul 2013 19:29:25 +0000
Subject: [pypy-issue] [issue1562] MacOSX: "clang" and "-undefined
	dynamic_lookup"
In-Reply-To: <1374951923.06.0.788141741646.issue1562@bugs.pypy.org>
Message-ID: <1374953365.77.0.301565720392.issue1562@bugs.pypy.org>


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

Seems I'm wrong about that.

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

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

From tracker at bugs.pypy.org  Sat Jul 27 23:14:09 2013
From: tracker at bugs.pypy.org (Alex Stewart)
Date: Sat, 27 Jul 2013 21:14:09 +0000
Subject: [pypy-issue] [issue1563] cppyy: segfault when referencing data
	members on classes
In-Reply-To: <1374959649.03.0.0831888500572.issue1563@bugs.pypy.org>
Message-ID: <1374959649.03.0.0831888500572.issue1563@bugs.pypy.org>


New submission from Alex Stewart <foogod at gmail.com>:

[Using pypy-2.0.2 (precompiled 64-bit Linux version from pypy.org, with reflex 
built from http://cern.ch/wlav/reflex-2013-04-23.tar.bz2]

Attempting to access any class data member via the class object (not an instance 
of the class) causes an invalid memory access:

  class MyClass {
  public:
      int m_myval;
  };

>>>> import cppyy
>>>> cppyy.load_reflection_info('libMyClass.so')
<CPPLibrary object at 0x00007ff69f4acbc0>
>>>> cppyy.gbl.MyClass().m_myval
0
>>>> cppyy.gbl.MyClass.m_myval
Segmentation fault (core dumped)

Obviously, accessing data members on the class itself does not make sense in 
C++, but attempting to do so should not segfault the whole interpreter 
(especially since this even happens when using things like hasattr to check for 
existence of the attribute, without even accessing it)..

----------
messages: 5994
nosy: Foogod, pypy-issue
priority: bug
release: 2.0
status: unread
title: cppyy: segfault when referencing data members on classes

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

From tracker at bugs.pypy.org  Sun Jul 28 09:56:19 2013
From: tracker at bugs.pypy.org (mikefc)
Date: Sun, 28 Jul 2013 07:56:19 +0000
Subject: [pypy-issue] [issue1548] numpypy ravel() bug
In-Reply-To: <1374224345.91.0.76779882319.issue1548@bugs.pypy.org>
Message-ID: <1374998179.73.0.969733663806.issue1548@bugs.pypy.org>


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

The reason for this error is that the interp_boxes implementation of ravel takes 
no arguments.

So within interp_boxes.py add an unsed w_order argument. i.e.
-    def descr_ravel(self, space):
+    def descr_ravel(self, space, w_order=None):

----------
nosy: +mikefc

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

From tracker at bugs.pypy.org  Sun Jul 28 20:41:58 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 28 Jul 2013 18:41:58 +0000
Subject: [pypy-issue] [issue1562] MacOSX: "clang" and "-undefined
	dynamic_lookup"
In-Reply-To: <1374951923.06.0.788141741646.issue1562@bugs.pypy.org>
Message-ID: <1375036918.22.0.4345564476.issue1562@bugs.pypy.org>


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

Seems resolved for now.

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

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

From tracker at bugs.pypy.org  Sun Jul 28 22:27:27 2013
From: tracker at bugs.pypy.org (mike bayer)
Date: Sun, 28 Jul 2013 20:27:27 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>


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

apologies if this is known, browsing the other sqlite3 issues they seem to apply
to previous versions and aren't the same thing I'm getting, this is on OSX
mountain lion, pypy build linked at
https://bitbucket.org/pypy/pypy/downloads/pypy-2.1-beta2-osx64.tar.bz2

classics-MacBook-Pro:src classic$ pypy-2.1-beta2-osx64/bin/pypy            
Python 2.7.3 (fde1203a425d, Jul 25 2013, 10:37:04)
[PyPy 2.1.0-beta2 with GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.1.58)] on
darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``<fijal> I love pypy''
>>>> import sqlite3
Undefined symbols for architecture x86_64:
  "_sqlite3_enable_load_extension", referenced from:
      __cffi_f_sqlite3_enable_load_extension in _cffi__g24366574x62c16045.o
     (maybe you meant: __cffi_f_sqlite3_enable_load_extension)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib-python/2.7/sqlite3/__init__.py",
line 24, in <module>
    from dbapi2 import *
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib-python/2.7/sqlite3/dbapi2.py",
line 27, in <module>
    from _sqlite3 import *
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib_pypy/_sqlite3.py", line 273, in
<module>
    """, libraries=['sqlite3']
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib_pypy/cffi/api.py", line 311, in
verify
    lib = self.verifier.load_library()
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib_pypy/cffi/verifier.py", line 68,
in load_library
    self.compile_module()
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib_pypy/cffi/verifier.py", line 56,
in compile_module
    self._compile_module()
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib_pypy/cffi/verifier.py", line
131, in _compile_module
    outputfilename = ffiplatform.compile(tmpdir, self.get_extension())
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib_pypy/cffi/ffiplatform.py", line
25, in compile
    outputfilename = _build(tmpdir, ext)
  File "/usr/local/src/pypy-2.1-beta2-osx64/lib_pypy/cffi/ffiplatform.py", line
50, in _build
    raise VerificationError('%s: %s' % (e.__class__.__name__, e))
VerificationError: LinkError: command 'gcc' failed with exit status 1

----------
messages: 5997
nosy: pypy-issue, zzzeek
priority: critical
release: 2.1
status: unread
title: sqlite3 can't import w/ OSX pypy-2.1-beta2

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

From tracker at bugs.pypy.org  Sun Jul 28 22:31:00 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 28 Jul 2013 20:31:00 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375043460.19.0.677457644339.issue1564@bugs.pypy.org>


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

Ok so On my machine if I do the same it works fine, which leads me to believe the 
issue is related to us not bundling some needed header files. For completeness, 
what version of OS X do you have?

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

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

From tracker at bugs.pypy.org  Sun Jul 28 22:34:38 2013
From: tracker at bugs.pypy.org (mike bayer)
Date: Sun, 28 Jul 2013 20:34:38 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375043678.7.0.155878150077.issue1564@bugs.pypy.org>


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

this is 10.8.4.   The base sqlite version is 3.7.12 in /usr, I also have
3.7.15.2 in /usr/local, I'm assuming it's using the /usr libs.

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

From tracker at bugs.pypy.org  Sun Jul 28 22:38:19 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 28 Jul 2013 20:38:19 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375043899.75.0.240516126026.issue1564@bugs.pypy.org>


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

It's quite likely that I've messed with my paths and installed some more stuff 
with brew. I wonder if there's any way for us to run installations against a 
simulated pristine OS X.

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

From tracker at bugs.pypy.org  Mon Jul 29 04:29:46 2013
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 29 Jul 2013 02:29:46 +0000
Subject: [pypy-issue] [issue1548] numpypy ravel() bug
In-Reply-To: <1374224345.91.0.76779882319.issue1548@bugs.pypy.org>
Message-ID: <1375064986.65.0.228329262009.issue1548@bugs.pypy.org>


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

-    def descr_ravel(self, space):
+    @unwrap_spec(order=str) 
+    def descr_ravel(self, space, order='C'):
+        if order != 'C':
+            raise OperationError(space.w_NotImplementedError ...

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

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

From tracker at bugs.pypy.org  Mon Jul 29 17:21:57 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 29 Jul 2013 15:21:57 +0000
Subject: [pypy-issue] [issue1565] Assembler: Linear search in corner cases
In-Reply-To: <1375111317.51.0.928324077991.issue1565@bugs.pypy.org>
Message-ID: <1375111317.51.0.928324077991.issue1565@bugs.pypy.org>


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

A "guard_value" where a lot of different values are seen at run-time can end up
badly as a lot of compiled paths.  We might try to have a general way to give up
in these situations.  For now, they are compiled as a linear chain of CMP/JNE,
which makes looking up the correct code path potentially very slow; a first fix
would be to improve this in x86/assembler.py.

Attached is an example: it runs 10x slower on PyPy than on CPython (and, as
expected, 5x slower than with "--jit off").

----------
files: x.py
messages: 6002
nosy: arigo, pypy-issue
priority: performance bug
status: unread
title: Assembler: Linear search in corner cases

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

From tracker at bugs.pypy.org  Mon Jul 29 22:19:18 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Mon, 29 Jul 2013 20:19:18 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375129158.8.0.0513662295071.issue1564@bugs.pypy.org>


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

I can't reproduce it on an older OS X (of course). So I'll just throw out some 
shots in the dark:

Could you try nuking the __pycache__ directory inside of lib_pypy if one exists 
and try again?

I also suggest to try removing the /usr/local version of sqlite (if it's not too 
much trouble) and see if that changes anything

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

From tracker at bugs.pypy.org  Mon Jul 29 22:22:10 2013
From: tracker at bugs.pypy.org (mike bayer)
Date: Mon, 29 Jul 2013 20:22:10 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375129330.45.0.481361932547.issue1564@bugs.pypy.org>


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

bleh, its just homebrew sqlite. works without it.   BLEH.

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

From tracker at bugs.pypy.org  Mon Jul 29 22:23:18 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 29 Jul 2013 20:23:18 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375129398.16.0.962400767464.issue1564@bugs.pypy.org>


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

I wonder if there's some way we can work around this.

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

From tracker at bugs.pypy.org  Mon Jul 29 22:28:13 2013
From: tracker at bugs.pypy.org (mike bayer)
Date: Mon, 29 Jul 2013 20:28:13 +0000
Subject: [pypy-issue] [issue1564] sqlite3 can't import w/ OSX pypy-2.1-beta2
In-Reply-To: <1375043247.36.0.985684552114.issue1564@bugs.pypy.org>
Message-ID: <1375129693.87.0.434567637963.issue1564@bugs.pypy.org>


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

so if I look at my system installed python, which successfully looks only at the
/usr/lib sqlite, i see this:

otool -L
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_sqlite3.so
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_sqlite3.so:
	/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 9.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

then the Python that I built manually, uses the homebrew one:

otool -L
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_sqlite3.so
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_sqlite3.so:
	/usr/local/opt/sqlite/lib/libsqlite3.0.8.6.dylib (compatibility version 9.0.0,
current version 9.6.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

somehow they're doing that.   shrugs

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

From tracker at bugs.pypy.org  Tue Jul 30 19:21:25 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 30 Jul 2013 17:21:25 +0000
Subject: [pypy-issue] [issue1542] py3k test_memoryview test failures
In-Reply-To: <1374013912.03.0.122490729087.issue1542@bugs.pypy.org>
Message-ID: <1375204885.38.0.857704872108.issue1542@bugs.pypy.org>


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

FYI test_memoryview's failing tests have been skipped for now (for the sake of 
green buildbots)

http://bitbucket.org/pypy/pypy/commits/7b5a337d3285

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

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

From tracker at bugs.pypy.org  Tue Jul 30 21:30:04 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 30 Jul 2013 19:30:04 +0000
Subject: [pypy-issue] [issue1566] py3k: test_multiprocessing deadlocks linux
	buildbots
In-Reply-To: <1375212604.84.0.804908158773.issue1566@bugs.pypy.org>
Message-ID: <1375212604.84.0.804908158773.issue1566@bugs.pypy.org>


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

py3k's test_multiprocessing currently deadlocks the linux32 and IIRC also the 
linux64 buildbots

The believe the offending test is:

test_pool_worker_lifetime_early_close 
(__main__.WithProcessesTestPoolWorkerLifetime)

----------
messages: 6008
nosy: pypy-issue
priority: bug
status: unread
title: py3k: test_multiprocessing deadlocks linux buildbots

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

From tracker at bugs.pypy.org  Tue Jul 30 21:31:37 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Tue, 30 Jul 2013 19:31:37 +0000
Subject: [pypy-issue] [issue1567] py3k: enable NumPyPy
In-Reply-To: <1375212697.52.0.263246981944.issue1567@bugs.pypy.org>
Message-ID: <1375212697.52.0.263246981944.issue1567@bugs.pypy.org>


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

The micronumpy module was disabled a while ago on py3k. It just needs a little 
love/adapation to py3k

----------
messages: 6009
nosy: pypy-issue
priority: feature
status: unread
title: py3k: enable NumPyPy

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

From tracker at bugs.pypy.org  Tue Jul 30 23:40:01 2013
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 30 Jul 2013 21:40:01 +0000
Subject: [pypy-issue] [issue1543] numpypy: complex128.conjugate()
In-Reply-To: <1374050326.27.0.384852542188.issue1543@bugs.pypy.org>
Message-ID: <1375220401.6.0.919795390849.issue1543@bugs.pypy.org>


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

Fixed conjugate() in a50d8cdd457e, ignoring is_integer()

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

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

From tracker at bugs.pypy.org  Tue Jul 30 23:42:39 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 30 Jul 2013 21:42:39 +0000
Subject: [pypy-issue] [issue1568] Using socket.makefile from eventlet
	results in hangs
In-Reply-To: <1375220559.4.0.822259612065.issue1568@bugs.pypy.org>
Message-ID: <1375220559.4.0.822259612065.issue1568@bugs.pypy.org>


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

This code runs easily under CPython, but under PyPy is hangs:

import eventlet
from eventlet.green import socket


def accept(sock, addr):
    sock.sendall("HTTP/1.1 201 OK\r\nContent-Length: 0\r\n\r\n")
    sock.recv(247)
    sock.recv(247)


def accept_listener(bindsock):
    sock, addr = bindsock.accept()
    return eventlet.spawn(accept, sock, addr)


def send_raw(bindsock):
    c = socket.socket()
    c.connect(bindsock.getsockname())
    c.sendall('GET / HTTP/1.1\r\n\r\n')
    f = c.makefile()
    f.close()

def main():
    bindsock = eventlet.listen(("127.0.0.1", 0))
    spawned = eventlet.spawn(accept_listener, bindsock)
    eventlet.spawn(send_raw, bindsock)
    spawned.wait().wait()



if __name__ == "__main__":
    main()

----------
messages: 6011
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: Using socket.makefile from eventlet results in hangs

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

From tracker at bugs.pypy.org  Wed Jul 31 00:09:06 2013
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 30 Jul 2013 22:09:06 +0000
Subject: [pypy-issue] [issue1544] numpypy: complex(complex128)
In-Reply-To: <1374050447.06.0.0816702513482.issue1544@bugs.pypy.org>
Message-ID: <1375222146.6.0.130576026794.issue1544@bugs.pypy.org>


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

this fails in stdobjspace w_complextype
here is the relevant traceback, how should this work properly?

<132-codegen /home/matti/pypy_stuff/pypy/rpython/tool/sourcetools.py:175>:3: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
space = StdObjSpace, w_complextype = <W_TypeObject(complex)>, w_real = 
<pypy.module.micronumpy.interp_boxes.W_Complex128Box object at 0x54ff750>, 
w_imag = None

    @unwrap_spec(w_real = WrappedDefault(0.0))
    def descr__new__(space, w_complextype, w_real, w_imag=None):
        from pypy.objspace.std.complexobject import W_ComplexObject
    
        # if w_real is already a complex number and there is no second
        # argument, return it.  Note that we cannot return w_real if
        # it is an instance of a *subclass* of complex, or if w_complextype
        # is itself a subclass of complex.
        noarg2 = w_imag is None
        if (noarg2 and space.is_w(w_complextype, space.w_complex)
                   and space.is_w(space.type(w_real), space.w_complex)):
            return w_real

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

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

From tracker at bugs.pypy.org  Wed Jul 31 06:52:22 2013
From: tracker at bugs.pypy.org (Damien Miller)
Date: Wed, 31 Jul 2013 04:52:22 +0000
Subject: [pypy-issue] [issue1569] PyArg_ParseTupleAndKeywords s# filling in
	incorrect size
In-Reply-To: <1375246342.97.0.190017593592.issue1569@bugs.pypy.org>
Message-ID: <1375246342.97.0.190017593592.issue1569@bugs.pypy.org>


New submission from Damien Miller <djm at djm.net.au>:

Hi,

I just tried pypy (today head, JIT) for the first time and noticed that it compiles my py-bcrypt 
module but produces something that fails at runtime. To recreate the failure:

PYPY=/tmp/pypy/pypy/goal/pypy-c # or whatever
hg clone https://code.google.com/p/py-bcrypt/
cd py-bcrypt
$PYPY setup.py build
env PYTHONPATH=$PWD/build/lib.linux-x86_64-2.7/ $PYPY test/test.py

It looks like "s#" arguments extracted by PyArg_ParseTupleAndKeywords() are not being filled in 
correctly. For example, in py-bcrypt/bcrypt/bcrypt_python.c:bcrypt_hashpw() with a password of 
"" the corresponding password_len ends up being set to -4294967296.

I'm using Ubuntu Precise on x86_64.

----------
messages: 6013
nosy: djm, pypy-issue
priority: bug
status: unread
title: PyArg_ParseTupleAndKeywords s# filling in incorrect size

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

From tracker at bugs.pypy.org  Wed Jul 31 07:41:24 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 31 Jul 2013 05:41:24 +0000
Subject: [pypy-issue] [issue1569] PyArg_ParseTupleAndKeywords s# filling in
	incorrect size
In-Reply-To: <1375246342.97.0.190017593592.issue1569@bugs.pypy.org>
Message-ID: <1375249284.98.0.554237180087.issue1569@bugs.pypy.org>


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

It's missing the support for PY_SSIZE_T_CLEAN and always calling the
non-size_t-versions.  Here, bcrypt_python.c starts with #define PY_SSIZE_T_CLEAN
(which is indeed the recommended thing to do).  Needs to be fixed by adding some
#ifdefs to pypy/module/cpyext/{include,src}/

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

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

From tracker at bugs.pypy.org  Wed Jul 31 08:30:32 2013
From: tracker at bugs.pypy.org (Oren Tirosh)
Date: Wed, 31 Jul 2013 06:30:32 +0000
Subject: [pypy-issue] [issue1570] list.remove chokes on numpypy types
In-Reply-To: <1375252232.36.0.144665765426.issue1570@bugs.pypy.org>
Message-ID: <1375252232.36.0.144665765426.issue1570@bugs.pypy.org>


New submission from Oren Tirosh <orent at hishome.net>:

import numpypy
l=[numpypy.int_(0)]  # or other subclasses of numpypy.number

l.remove(object())
Expected: "ValueError: list.remove(x): x not in list"
Got: "TypeError: expected float, got object object"

l.remove([])
Expected: "ValueError: list.remove(x): x not in list"
Got: No error.

----------
messages: 6015
nosy: orent, pypy-issue
priority: bug
status: unread
title: list.remove chokes on numpypy types

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

From tracker at bugs.pypy.org  Wed Jul 31 08:57:10 2013
From: tracker at bugs.pypy.org (Dusan Smitran)
Date: Wed, 31 Jul 2013 06:57:10 +0000
Subject: [pypy-issue] [issue1532] Running ipython with pypy on windows
In-Reply-To: <1373550270.76.0.0364406526498.issue1532@bugs.pypy.org>
Message-ID: <1375253830.75.0.016619975074.issue1532@bugs.pypy.org>


Dusan Smitran <dusan.smitran at gmail.com> added the comment:

If u need a tester for a possible patch please let me know.

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

From tracker at bugs.pypy.org  Wed Jul 31 20:04:16 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Wed, 31 Jul 2013 18:04:16 +0000
Subject: [pypy-issue] [issue1569] PyArg_ParseTupleAndKeywords s# filling in
	incorrect size
In-Reply-To: <1375246342.97.0.190017593592.issue1569@bugs.pypy.org>
Message-ID: <1375293856.73.0.346050056711.issue1569@bugs.pypy.org>


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

FYI py3k's _testcapimodule.c has a couple tests for PY_SSIZE_T_CLEAN (which we 
currently skip https://bitbucket.org/pypy/pypy/commits/16f053aecc5d )

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