From tracker at bugs.pypy.org  Thu Aug  1 15:26:24 2013
From: tracker at bugs.pypy.org (Renaud Blanch)
Date: Thu, 01 Aug 2013 13:26:24 +0000
Subject: [pypy-issue] [issue1572] py3k: import site-packages at startup
In-Reply-To: <1375363584.87.0.338493414024.issue1572@bugs.pypy.org>
Message-ID: <1375363584.87.0.338493414024.issue1572@bugs.pypy.org>


New submission from Renaud Blanch <rndblnch at gmail.com>:

pypy3 does not import packages installed into site-packages on Mac?OS?X 10.8 (presumably due to a 
misconfigured site.USER_SITE):

    [esperluet:~] blanch% ../Shared/src/pypy3-2.1-beta1-osx64/bin/pypy 
    Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:48)
    [PyPy 2.1.0-beta1 with GCC 4.2.1 Compatible Clang Compiler] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    And now for something completely different: ``pypy is a race between the
    industry trying to build machines with more and more resources, and the pypy
    developers trying to eat all of them. So far, the winner is still unclear''
    >>>> import sys
    >>>> assert any(path.endswith("site-packages") for path in sys.path)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AssertionError
    >>>> sys.path
    ['', '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib_pypy/__extensions__', '/Users/Shared/src/pypy3-
2.1-beta1-osx64/lib_pypy', '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3', 
'/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3/lib-tk', '/Users/Shared/src/pypy3-2.1-beta1-
osx64/lib-python/3/plat-darwin', '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3/plat-mac', 
'/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3/plat-mac/lib-scriptpackages']
    >>>> import site
    >>>> site.USER_SITE
    '/Users/blanch/.local/lib/python3.2/site-packages'
    >>>> import os
    >>>> os.path.exists(site.USER_SITE)
    False

----------
messages: 6019
nosy: pypy-issue, rndblnch
priority: bug
status: unread
title: py3k: import site-packages at startup

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

From tracker at bugs.pypy.org  Thu Aug  1 15:44:52 2013
From: tracker at bugs.pypy.org (Renaud Blanch)
Date: Thu, 01 Aug 2013 13:44:52 +0000
Subject: [pypy-issue] [issue1572] py3k: import site-packages at startup
In-Reply-To: <1375363584.87.0.338493414024.issue1572@bugs.pypy.org>
Message-ID: <1375364692.2.0.634453426583.issue1572@bugs.pypy.org>


Renaud Blanch <rndblnch at gmail.com> added the comment:

in fact the fact that site.USER_SITE does not exist does not seem to be the problem.
with cpython and pypy2 I get:


    [esperluet:~] blanch% pypy -m site
    sys.path = [
        '/Users/blanch',
        '/Users/Shared/src/pypy-2.0.1/lib_pypy/__extensions__',
        '/Users/Shared/src/pypy-2.0.1/lib_pypy',
        '/Users/Shared/src/pypy-2.0.1/lib-python/2.7',
        '/Users/Shared/src/pypy-2.0.1/lib-python/2.7/lib-tk',
        '/Users/Shared/src/pypy-2.0.1/lib-python/2.7/plat-darwin',
        '/Users/Shared/src/pypy-2.0.1/lib-python/2.7/plat-mac',
        '/Users/Shared/src/pypy-2.0.1/lib-python/2.7/plat-mac/lib-scriptpackages',
        '/Users/Shared/src/pypy-2.0.1/site-packages',
    ]
    USER_BASE: '/Users/blanch/.local' (doesn't exist)
    USER_SITE: '/Users/blanch/.local/lib/python2.7/site-packages' (doesn't exist)
    ENABLE_USER_SITE: True

and with pypy3:


    [esperluet:~] blanch% pypy3 -m site
    sys.path = [
        '/Users/blanch',
        '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib_pypy/__extensions__',
        '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib_pypy',
        '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3',
        '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3/lib-tk',
        '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3/plat-darwin',
        '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3/plat-mac',
        '/Users/Shared/src/pypy3-2.1-beta1-osx64/lib-python/3/plat-mac/lib-scriptpackages',
    ]
    USER_BASE: '/Users/blanch/.local' (doesn't exist)
    USER_SITE: '/Users/blanch/.local/lib/python3.2/site-packages' (doesn't exist)
    ENABLE_USER_SITE: True

so the only difference is in site-pacakges being not included in sys.path...

i guess the pypy specific logic that has been removed from site.py in pypy3 (see below) has something to do with this regression:


    [esperluet:/Users/Shared/src] blanch% diff -ru pypy-2.0.1/lib-python/2.7/site.py pypy3-2.1-beta1-osx64/lib-python/3/site.py 
    --- pypy-2.0.1/lib-python/2.7/site.py	2013-04-21 20:25:13.000000000 +0200
    +++ pypy3-2.1-beta1-osx64/lib-python/3/site.py	2013-07-30 09:02:26.000000000 +0200

    [skipped]

    @@ -292,7 +274,6 @@
         will find its `site-packages` subdirectory depending on the system
         environment, and will return a list of full paths.
         """
    -    is_pypy = '__pypy__' in sys.builtin_module_names
         sitepackages = []
         seen = set()
     
    @@ -303,10 +284,6 @@
     
             if sys.platform in ('os2emx', 'riscos'):
                 sitepackages.append(os.path.join(prefix, "Lib", "site-packages"))
    -        elif is_pypy:
    -            from distutils.sysconfig import get_python_lib
    -            sitedir = get_python_lib(standard_lib=False, prefix=prefix)
    -            sitepackages.append(sitedir)
             elif os.sep == '/':
                 sitepackages.append(os.path.join(prefix, "lib",
                                             "python" + sys.version[:3],

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

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

From tracker at bugs.pypy.org  Fri Aug  2 02:11:07 2013
From: tracker at bugs.pypy.org (mike bayer)
Date: Fri, 02 Aug 2013 00:11:07 +0000
Subject: [pypy-issue] [issue1573] sqlite3 encoding of cursor.description
	column seems to	have changed
In-Reply-To: <1375402267.21.0.573896415985.issue1573@bugs.pypy.org>
Message-ID: <1375402267.21.0.573896415985.issue1573@bugs.pypy.org>


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

the strings in cursor.description, for better or worse, are encoded as strings
in cPython and also in pypy1.9.  In pypy2.1 (I'm testing beta2 still) they now
seem to come back as full blown unicode objects, which is nice (and certainly
what Python 3 will do), but not compatible with what cPython2.x does:

#!coding: utf-8

import sqlite3

conn = sqlite3.connect(":memory:")

cursor = conn.cursor()
cursor.execute(u"select 'x' as m?il")

assert cursor.description[0][0] == u"m?il".encode('utf-8')


will pass in cPython and pypy1.9, but on pypy2.1beta2 it fails.

----------
messages: 6021
nosy: pypy-issue, zzzeek
priority: bug
release: 2.1
status: unread
title: sqlite3 encoding of cursor.description column seems to have changed

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

From tracker at bugs.pypy.org  Fri Aug  2 06:47:35 2013
From: tracker at bugs.pypy.org (w31rd0)
Date: Fri, 02 Aug 2013 04:47:35 +0000
Subject: [pypy-issue] [issue1539] numpypy inplace operations
In-Reply-To: <1373949496.73.0.722969368634.issue1539@bugs.pypy.org>
Message-ID: <1375418855.75.0.172968682979.issue1539@bugs.pypy.org>


w31rd0 <ru.w31rd0 at gmail.com> added the comment:

https://bitbucket.org/pypy/pypy/pull-request/177

----------
nosy: +w31rd0
status: unread -> in-progress

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

From tracker at bugs.pypy.org  Fri Aug  2 12:54:51 2013
From: tracker at bugs.pypy.org (Star Brilliant)
Date: Fri, 02 Aug 2013 10:54:51 +0000
Subject: [pypy-issue] [issue1574] [PyPy3] Typing Unicode characters in
	interactive	interpreter causes crash
In-Reply-To: <1375440891.89.0.515282151313.issue1574@bugs.pypy.org>
Message-ID: <1375440891.89.0.515282151313.issue1574@bugs.pypy.org>


New submission from Star Brilliant <m13253 at hotmail.com>:

When I type the following code into the interactive interpreter, PyPy3 crashes.

>>>> import math
>>>> print('?=%.15f' % math.pi)
Traceback (most recent call last):
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/_pypy_interact.py", line 44, in 
interactive_console
    run_multiline_interactive_console(mainmodule)
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/simple_interact.py", line 62, 
in run_multiline_interactive_console
    returns_unicode=True)
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/readline.py", line 216, in 
multiline_input
    return reader.readline(returns_unicode=returns_unicode)
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 605, in 
readline
    self.handle1()
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 588, in 
handle1
    self.do_cmd(cmd)
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 540, in 
do_cmd
    self.refresh()
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 521, in 
refresh
    screen = self.calc_screen()
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/completing_reader.py", line 
230, in calc_screen
    screen = super(CompletingReader, self).calc_screen()
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 292, in 
calc_screen
    l, l2 = disp_str(line)
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 78, in 
disp_str
    s = [uc(x) for x in buffer]
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 78, in 
<listcomp>
    s = [uc(x) for x in buffer]
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 61, in 
_my_unctrl
    return uc(ord(c))
  File "/home/brilliant/pypy3-2.1-beta1-linux64/lib_pypy/pyrepl/reader.py", line 53, in 
_my_unctrl
    if unicodedata.category(c).startswith('C'):
TypeError: argument 1 must be unicode

Note:
1. print('Caf?') will not crash.
2. Putting the code into a file and executing it with PyPy3 will not crash.

----------
messages: 6023
nosy: m13253, pypy-issue
priority: bug
release: 2.1
status: unread
title: [PyPy3] Typing Unicode characters in interactive interpreter causes crash

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

From tracker at bugs.pypy.org  Fri Aug  2 16:47:24 2013
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Fri, 02 Aug 2013 14:47:24 +0000
Subject: [pypy-issue] [issue1575] Can not create virtualenv with pypy3 on OS
	X
In-Reply-To: <1375454844.56.0.430104730619.issue1575@bugs.pypy.org>
Message-ID: <1375454844.56.0.430104730619.issue1575@bugs.pypy.org>


New submission from kostia.lopuhin <kostia.lopuhin at gmail.com>:

$ virtualenv pypy3 -p ~/opt/pypy3-2.1-beta1-osx64/bin/pypy 
Running virtualenv with interpreter /Users/kostia/opt/pypy3-2.1-beta1-osx64/bin/pypy
New pypy executable in pypy3/bin/pypy
Installing distribute..........
  Complete output from command /Users/kostia/progra...2cffi/pypy3/bin/pypy -c
"#!python
\"\"\"Bootstra... main(sys.argv[1:])
" --always-copy -U distribute:
  Traceback (most recent call last):
  File "<string>", line 21, in <module>
  File "/Users/kostia/programming/psycopg2cffi/pypy3/lib-python/3/tempfile.py",
line 37, in <module>
    from random import Random as _Random
  File "/Users/kostia/programming/psycopg2cffi/pypy3/lib-python/3/random.py",
line 45, in <module>
    from hashlib import sha512 as _sha512
ImportError: No module named hashlib
----------------------------------------
...Installing distribute...done.
Traceback (most recent call last):
  File
"/Library/Python/2.7/site-packages/virtualenv-1.8.2-py2.7.egg/virtualenv.py",
line 2471, in <module>
    main()
  File
"/Library/Python/2.7/site-packages/virtualenv-1.8.2-py2.7.egg/virtualenv.py",
line 942, in main
    never_download=options.never_download)
  File
"/Library/Python/2.7/site-packages/virtualenv-1.8.2-py2.7.egg/virtualenv.py",
line 1049, in create_environment
    search_dirs=search_dirs, never_download=never_download)
  File
"/Library/Python/2.7/site-packages/virtualenv-1.8.2-py2.7.egg/virtualenv.py",
line 604, in install_distribute
    search_dirs=search_dirs, never_download=never_download)
  File
"/Library/Python/2.7/site-packages/virtualenv-1.8.2-py2.7.egg/virtualenv.py",
line 571, in _install_req
    cwd=cwd)
  File
"/Library/Python/2.7/site-packages/virtualenv-1.8.2-py2.7.egg/virtualenv.py",
line 1020, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command /Users/kostia/progra...2cffi/pypy3/bin/pypy -c "#!python
\"\"\"Bootstra... main(sys.argv[1:])
" --always-copy -U distribute failed with error code 1

$ virtualenv --version
1.8.2

$ ~/opt/pypy3-2.1-beta1-osx64/bin/pypy 
Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:48)
[PyPy 2.1.0-beta1 with GCC 4.2.1 Compatible Clang Compiler] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``snow! snow! (ter)''
>>>> import tempfile

----------
messages: 6024
nosy: kostia.lopuhin, pypy-issue
priority: bug
release: 2.1
status: unread
title: Can not create virtualenv with pypy3 on OS X

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

From tracker at bugs.pypy.org  Fri Aug  2 20:10:09 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Fri, 02 Aug 2013 18:10:09 +0000
Subject: [pypy-issue] [issue1575] Can not create virtualenv with pypy3 on OS
	X
In-Reply-To: <1375454844.56.0.430104730619.issue1575@bugs.pypy.org>
Message-ID: <1375467009.99.0.489438006972.issue1575@bugs.pypy.org>


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

You'll need the latest virtualenv (1.10) for PyPy3.

Let us know if there's a problem with that version, otherwise I've closed this 
issue

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

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

From tracker at bugs.pypy.org  Fri Aug  2 20:12:55 2013
From: tracker at bugs.pypy.org (Alex Stewart)
Date: Fri, 02 Aug 2013 18:12:55 +0000
Subject: [pypy-issue] [issue1576] cppyy: Need newer genreflex
In-Reply-To: <1375467175.53.0.951294195228.issue1576@bugs.pypy.org>
Message-ID: <1375467175.53.0.951294195228.issue1576@bugs.pypy.org>


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

The version of reflex distributed as http://cern.ch/wlav/reflex-2013-04-
23.tar.bz2 (referenced from http://doc.pypy.org/en/latest/cppyy.html) has a bug 
in genreflex which does not correctly generate cpp files when classes contain 
union members.

This bug appears to have been fixed in the Reflex found as part of the latest 
ROOT distribution (5.34/09), so it is possible to use genreflex from the full 
ROOT package instead, however:

1) Downloading and building ROOT properly (with Reflex enabled) is more 
complicated, and it doesn't appear to be designed to be installed anywhere other 
than in its own source directory (i.e. 'make install' does not put things in the 
right places to actually run)

2) The ROOT version does not build libcppyy_backend, so it is necessary to 
download and build both reflex-2013-04-23.tar.bz2 and ROOT, and then use an ugly 
combination of both to get things to both build and run on the same host.

The workaround I have currently come up with is to build/install reflex-2013-04-
23.tar.bz2 (in /usr/local), build ROOT (in its own $ROOTSYS dir), and then:

rm -rf /usr/local/lib/python2.7/dist-packages/Reflex
cp -a $ROOTSYS/lib/python/genreflex/ /usr/local/lib/python2.7/dist-
packages/Reflex

(This is obviously an ugly hack, however, and I'm a little bit uneasy about 
generating source with a version of genreflex which is different than the 
version of libReflex it's designed to link against (though it seems to work so 
far)..)

It's unclear how the current standalone reflex .tar.bz2 was generated, but would 
it be possible to create a new one based off of the ROOT 5.34 version to fix 
this issue?

----------
messages: 6026
nosy: Foogod, pypy-issue
priority: bug
release: 2.0
status: unread
title: cppyy: Need newer genreflex

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

From tracker at bugs.pypy.org  Fri Aug  2 21:09:11 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Fri, 02 Aug 2013 19:09:11 +0000
Subject: [pypy-issue] [issue1572] py3k: import site-packages at startup
In-Reply-To: <1375363584.87.0.338493414024.issue1572@bugs.pypy.org>
Message-ID: <1375470551.38.0.383241097447.issue1572@bugs.pypy.org>


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

fixed in 0ad8f5229df1, thanks for the report

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

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

From tracker at bugs.pypy.org  Fri Aug  2 21:10:48 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Fri, 02 Aug 2013 19:10:48 +0000
Subject: [pypy-issue] [issue1573] sqlite3 encoding of cursor.description
	column seems to	have changed
In-Reply-To: <1375402267.21.0.573896415985.issue1573@bugs.pypy.org>
Message-ID: <1375470648.73.0.327609908876.issue1573@bugs.pypy.org>


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

fixed in 56e444747761, thanks Mike

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

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

From tracker at bugs.pypy.org  Sat Aug  3 16:26:24 2013
From: tracker at bugs.pypy.org (Wim Lavrijsen)
Date: Sat, 03 Aug 2013 14:26:24 +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: <1375539984.6.0.522111789468.issue1563@bugs.pypy.org>


Wim Lavrijsen <WLavrijsen at lbl.gov> added the comment:

Thanks for reporting and again sorry for the late response, but I'm traveling.

I've turned it into a ReferenceError. I tried AttributeError, but it just does
not jibe (as that's not really it; the attribute is there, just not usable
without an instance). However, both are fine for hasattr().

----------
assignedto:  -> wlav
nosy: +wlav
release: 2.0 -> 2.1
status: unread -> resolved

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

From tracker at bugs.pypy.org  Sat Aug  3 16:26:39 2013
From: tracker at bugs.pypy.org (Wim Lavrijsen)
Date: Sat, 03 Aug 2013 14:26:39 +0000
Subject: [pypy-issue] [issue1561] cppyy error binding enums
In-Reply-To: <1374881285.26.0.582336783705.issue1561@bugs.pypy.org>
Message-ID: <1375539999.94.0.279042577436.issue1561@bugs.pypy.org>


Wim Lavrijsen <WLavrijsen at lbl.gov> added the comment:

Thanks for reporting and sorry for the late response, but I'm traveling. This
was actually a 'TODO' item (and will be more with C++11).

Now fixed.

----------
assignedto:  -> wlav
nosy: +wlav
release:  -> 2.1
status: unread -> resolved

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

From tracker at bugs.pypy.org  Sun Aug  4 00:12:26 2013
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Sat, 03 Aug 2013 22:12:26 +0000
Subject: [pypy-issue] [issue1575] Can not create virtualenv with pypy3 on OS
	X
In-Reply-To: <1375454844.56.0.430104730619.issue1575@bugs.pypy.org>
Message-ID: <1375567946.1.0.695998943531.issue1575@bugs.pypy.org>


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

With virtualenv 1.10 all works fine, thank you!

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

From tracker at bugs.pypy.org  Sun Aug  4 09:27:56 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 04 Aug 2013 07:27:56 +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: <1375601276.56.0.449579392368.issue1568@bugs.pypy.org>


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

>From an IRC communication from Alex:

   the issue is that type(self._sock) != realsocket in socketfile,
   so you never decref.  so a connection close is never sent

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

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

From tracker at bugs.pypy.org  Sun Aug  4 09:37:04 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 04 Aug 2013 07:37:04 +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: <1375601824.13.0.241193789179.issue1568@bugs.pypy.org>


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

One solution might be to change socket.py to remove the lines "if type(s) is
_realsocket".  It would cleanly break any library that attempts to monkey-patch
sockets in non-official way, and point them to the direction of solving it for
pypy: they need to implement a reference counter and methods _drop() and
_reuse() on the class they're passing to _socketobject() or _fileobject().  This
can be made explicit with comments.

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

From tracker at bugs.pypy.org  Sun Aug  4 18:41:43 2013
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Sun, 04 Aug 2013 16:41:43 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>


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

In pypy 2.1 (but not the pypy3 beta), SSLSocket.close() no longer closes the 
underlying socket.  In the attached test programs, the client should print "read 
from client socket: 'abc'" and "empty read; connection was closed" and then 
exit.  When the server is run with pypy 2.1 (both the final release and the 
first beta), it hangs after the first message.  The test works as expected in 
pypy 2.0, pypy3 2.1b1, and cpython.

I suspect the problem is the refcounting introduced in 
https://bitbucket.org/pypy/pypy/commits/d439d104a6051cdcc5e366b7ea329cc14d304d9e
, and specifically the call to _reuse in the socket constructor.  
ssl.wrap_socket should transfer the reference from the original plaintext socket 
to the ssl one instead of leaving a reference in both objects.

----------
files: test_server.py
messages: 6034
nosy: bdarnell, pypy-issue
priority: bug
status: unread
title: SSLSocket.close() doesn't work

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

From tracker at bugs.pypy.org  Mon Aug  5 08:59:46 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 05 Aug 2013 06:59:46 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1375685986.32.0.807450214265.issue1577@bugs.pypy.org>


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

See https://bugs.pypy.org/issue1568 : the same solution might apply.

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

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

From tracker at bugs.pypy.org  Mon Aug  5 17:27:35 2013
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Mon, 05 Aug 2013 15:27:35 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1375716455.07.0.521641626792.issue1577@bugs.pypy.org>


Ben Darnell <ben at bendarnell.com> added the comment:

I don't think it's the same issue - in this case the type is still _realsocket.  

The problem is that after wrap_socket, the _realsocket has a refcount of 2.  The 
original socket is rendered unusable by the wrapping, so it should no longer 
retain a reference.  (cpython didn't actually guarantee this prior to 3.2; you'd 
have a similar leak in cpython 2.7 if the wrapped and unwrapped sockets had 
different names)

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

From tracker at bugs.pypy.org  Tue Aug  6 09:09:18 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Aug 2013 07:09:18 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1375772958.67.0.0648732531499.issue1577@bugs.pypy.org>


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

Ok, I see.  Would it be a fix to simply call sock.close() in
SSLSocket.__init__()?  This would decrement again the reference counter, after
the SSLSocket object incremented it.

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

From tracker at bugs.pypy.org  Tue Aug  6 09:11:33 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Aug 2013 07:11:33 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1375773093.48.0.609671150255.issue1577@bugs.pypy.org>


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

Could you provide the files test.key and test.crt too?  That would be useful to
run the tests.

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

From tracker at bugs.pypy.org  Tue Aug  6 09:27:06 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Aug 2013 07:27:06 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1375774026.05.0.360019713504.issue1577@bugs.pypy.org>


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

...yes, seems to work.  Checked in as d8124d5c9c00 (which only changes ssl.py).
 Can you test it too?

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

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

From tracker at bugs.pypy.org  Tue Aug  6 11:33:05 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Aug 2013 09:33:05 +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: <1375781585.09.0.788438285244.issue1568@bugs.pypy.org>


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

agaynor: additionally, it seems that your example leaks a socket anyway: in
send_raw(), c.close() is never called.

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

From tracker at bugs.pypy.org  Tue Aug  6 11:35:16 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Aug 2013 09:35:16 +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: <1375781716.2.0.621291123407.issue1568@bugs.pypy.org>


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

The example passes now with two changes:

- added c.close()

- tweaked the method GreenSocket.makefile() in eventlet to not call dup() (which
leaks) and to pass an object that is a raw socket (as opposed to a
_socketobject).  The tweaked is here:

    def makefile(self, *args, **kw):
        return _fileobject(self.fd._sock, *args, **kw)

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

From tracker at bugs.pypy.org  Tue Aug  6 15:00:42 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 06 Aug 2013 13:00:42 +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: <1375794042.78.0.809461553669.issue1568@bugs.pypy.org>


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

Bogus!  We must call _fileobject(self) or maybe _fileobject(self.dup()),
otherwise we don't get the GreenSocket functionality.  So I guess it's a matter
of add two methods:

    def _reuse(self): self.fd._sock._reuse()
    def _drop(self):  self.fd._sock._drop()

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

From tracker at bugs.pypy.org  Wed Aug  7 23:49:01 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 07 Aug 2013 21:49:01 +0000
Subject: [pypy-issue] [issue1539] numpypy inplace operations
In-Reply-To: <1373949496.73.0.722969368634.issue1539@bugs.pypy.org>
Message-ID: <1375912141.66.0.124883491187.issue1539@bugs.pypy.org>


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

merged

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

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

From tracker at bugs.pypy.org  Fri Aug  9 17:18:37 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 09 Aug 2013 15:18:37 +0000
Subject: [pypy-issue] [issue1578] Signed/unsigned confusion in the JIT
	tracer(?)
In-Reply-To: <1376061517.55.0.25650421373.issue1578@bugs.pypy.org>
Message-ID: <1376061517.55.0.25650421373.issue1578@bugs.pypy.org>


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

This fails, apparently when the JIT traces the loop (but not before, and not
after when running the generated piece of assembler, as shown by replacing the
"assert" with "print n").  The assert fails with "n == -2", which is the signed
version of the byte "254".

import numpypy as np
while 1:
    tree = np.empty(12, np.uint8)
    tree[2] = 254
    n = int(tree[2])
    assert n == 254, n

----------
messages: 6044
nosy: arigo, pypy-issue
priority: bug
status: unread
title: Signed/unsigned confusion in the JIT tracer(?)

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

From tracker at bugs.pypy.org  Fri Aug  9 17:44:34 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 09 Aug 2013 15:44:34 +0000
Subject: [pypy-issue] [issue1578] Signed/unsigned confusion in the JIT
	tracer(?)
In-Reply-To: <1376061517.55.0.25650421373.issue1578@bugs.pypy.org>
Message-ID: <1376063074.07.0.374390933684.issue1578@bugs.pypy.org>


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

Minimal example:

import numpypy as np

tree = np.empty(12, np.uint8)
tree[2] = 254

while 1:
    assert tree[2] == 254

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

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

From tracker at bugs.pypy.org  Fri Aug  9 18:54:29 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 09 Aug 2013 16:54:29 +0000
Subject: [pypy-issue] [issue1578] Signed/unsigned confusion in the JIT
	tracer(?)
In-Reply-To: <1376061517.55.0.25650421373.issue1578@bugs.pypy.org>
Message-ID: <1376067269.94.0.932745185623.issue1578@bugs.pypy.org>


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

Fixed in 06f78c70c495.

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

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

From tracker at bugs.pypy.org  Fri Aug  9 20:35:47 2013
From: tracker at bugs.pypy.org (lesshaste)
Date: Fri, 09 Aug 2013 18:35:47 +0000
Subject: [pypy-issue] [issue1579] Potential speedup reading large file into
	a dict
In-Reply-To: <1376073347.07.0.871534548552.issue1579@bugs.pypy.org>
Message-ID: <1376073347.07.0.871534548552.issue1579@bugs.pypy.org>


New submission from lesshaste <drraph at gmail.com>:

paste <(seq 20000000) <(seq 2 20000001)  > largefile.txt

Then run the attached read.py. It takes about 1 minute on my system and simply 
makes one large dict.

However the attached C code takes less than 10 seconds (code taken from public 
forums on the web.)

Is there potential to be competitive with the C code?

----------
files: test.c
messages: 6047
nosy: lesshaste, pypy-issue
priority: performance bug
release: 2.0
status: unread
title: Potential speedup reading large file into a dict

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

From tracker at bugs.pypy.org  Fri Aug  9 20:43:52 2013
From: tracker at bugs.pypy.org (lesshaste)
Date: Fri, 09 Aug 2013 18:43:52 +0000
Subject: [pypy-issue] [issue1579] Potential speedup reading large file into
	a dict
In-Reply-To: <1376073347.07.0.871534548552.issue1579@bugs.pypy.org>
Message-ID: <1376073832.99.0.0839060863627.issue1579@bugs.pypy.org>


lesshaste <drraph at gmail.com> added the comment:

My fake data isn't very good as it gives you one value per key. Here is a 
slightly better attempt.

perl -E 'say int rand 1e7, $", int rand 1e4 for 1 .. 1e7' > largefile.txt

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

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

From tracker at bugs.pypy.org  Fri Aug  9 20:49:36 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 09 Aug 2013 18:49:36 +0000
Subject: [pypy-issue] [issue1579] Potential speedup reading large file into
	a dict
In-Reply-To: <1376073347.07.0.871534548552.issue1579@bugs.pypy.org>
Message-ID: <1376074176.92.0.532948536194.issue1579@bugs.pypy.org>


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

As an attempt to compare apples with apples, here is another version of the
Python code (read2.py).  The factor is now around 3.7x.  This is more acceptable
I believe...

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

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

From tracker at bugs.pypy.org  Fri Aug  9 20:50:11 2013
From: tracker at bugs.pypy.org (lesshaste)
Date: Fri, 09 Aug 2013 18:50:11 +0000
Subject: [pypy-issue] [issue1579] Potential speedup reading large file into
	a dict
In-Reply-To: <1376073832.99.0.0839060863627.issue1579@bugs.pypy.org>
Message-ID: <1376074211.25.0.957339291058.issue1579@bugs.pypy.org>


lesshaste <drraph at gmail.com> added the comment:

paste <(seq 20000000) <(seq 2 20000001)  > largefile.txt

Then run the attached read.py. It takes about 40 seconds on my system and simply 
makes one large dict.

However the attached C code takes less than 10 seconds (code taken from public 
forums on the web.)

Is there potential to be competitive with the C code?

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

From tracker at bugs.pypy.org  Fri Aug  9 20:57:34 2013
From: tracker at bugs.pypy.org (lesshaste)
Date: Fri, 09 Aug 2013 18:57:34 +0000
Subject: [pypy-issue] [issue1579] Potential speedup reading large file into
	a dict
In-Reply-To: <1376073832.99.0.0839060863627.issue1579@bugs.pypy.org>
Message-ID: <1376074654.3.0.4951200641.issue1579@bugs.pypy.org>


lesshaste <drraph at gmail.com> added the comment:

pypy uses about 2GB of RAM (on my 32 bit system) where the C code using around 
750MB I think.

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

From tracker at bugs.pypy.org  Sat Aug 10 10:27:09 2013
From: tracker at bugs.pypy.org (alex_dolby)
Date: Sat, 10 Aug 2013 08:27:09 +0000
Subject: [pypy-issue] [issue1580] whatprovides filename in pip
In-Reply-To: <1376123229.19.0.185875886876.issue1580@bugs.pypy.org>
Message-ID: <1376123229.19.0.185875886876.issue1580@bugs.pypy.org>


New submission from alex_dolby <novel.kumar at gmail.com>:

There is no method to find which pypi package provides a particular file. yum has 
it.
yum whatprovides *filename.

Can we have something equivalent to it in pip

----------
messages: 6052
nosy: alex_dolby, pypy-issue
priority: feature
status: unread
title: whatprovides filename in pip

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

From tracker at bugs.pypy.org  Sat Aug 10 10:35:23 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 10 Aug 2013 08:35:23 +0000
Subject: [pypy-issue] [issue1580] whatprovides filename in pip
In-Reply-To: <1376123229.19.0.185875886876.issue1580@bugs.pypy.org>
Message-ID: <1376123723.94.0.978299763368.issue1580@bugs.pypy.org>


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

This is the bug tracker of PyPy, not pip's or pypi's.

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

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

From tracker at bugs.pypy.org  Sat Aug 10 20:00:23 2013
From: tracker at bugs.pypy.org (Wouter van Heyst)
Date: Sat, 10 Aug 2013 18:00:23 +0000
Subject: [pypy-issue] [issue1581] strptime does not like string_
In-Reply-To: <1376157623.52.0.570103140202.issue1581@bugs.pypy.org>
Message-ID: <1376157623.52.0.570103140202.issue1581@bugs.pypy.org>


New submission from Wouter van Heyst <wouter.pypy at richtlijn.be>:

The attached code works with cpython but fails with pypy b9699dee6f10.

Traceback (most recent call last):
  File "app_main.py", line 72, in run_toplevel
  File "/tmp/bug.py", line 8, in <module>
    datetime.strptime(a[0], '%Y-%m-%d')
  File "/home/larstiq/src/pypy/lib_pypy/datetime.py", line 1701, in strptime
    struct, micros = _strptime(date_string, format)
  File "/home/larstiq/src/pypy/lib-python/2.7/_strptime.py", line 322, in _strptime
    found = format_regex.match(data_string)
TypeError: unsupported operand type for buffer: 'string_'

----------
messages: 6054
nosy: larstiq, pypy-issue
priority: bug
status: unread
title: strptime does not like string_

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

From tracker at bugs.pypy.org  Tue Aug 13 00:04:32 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 12 Aug 2013 22:04:32 +0000
Subject: [pypy-issue] [issue1582] file.tell() has wrong position after
	failed seek with	SEEK_CUR
In-Reply-To: <1376345072.81.0.668742432464.issue1582@bugs.pypy.org>
Message-ID: <1376345072.81.0.668742432464.issue1582@bugs.pypy.org>


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

Alexanders-MacBook-Pro:openstack-swift alex_gaynor$ cat t.py
import os
from tempfile import TemporaryFile


with TemporaryFile('r+w') as f:
    f.write('123456789x12345678><123456789\n')
    f.write('1234><234\n')
    f.write('123456789x123456789\n')

    f.seek(0, os.SEEK_END)
    f.seek(-25, os.SEEK_CUR)
    f.read(25)
    f.seek(-25, os.SEEK_CUR)
    f.tell()
    f.seek(-25, os.SEEK_CUR)
    f.read(25)
    f.seek(-25, os.SEEK_CUR)
    f.tell()
    try:
        f.seek(-25, os.SEEK_CUR)
    except IOError:
        pass
    print f.tell()
Alexanders-MacBook-Pro:openstack-swift alex_gaynor$ python t.py
10
Alexanders-MacBook-Pro:openstack-swift alex_gaynor$ pypy t.py
60

----------
messages: 6055
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: file.tell() has wrong position after failed seek with SEEK_CUR

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

From tracker at bugs.pypy.org  Tue Aug 13 00:08:42 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 12 Aug 2013 22:08:42 +0000
Subject: [pypy-issue] [issue1582] file.tell() has wrong position after
	failed seek with	SEEK_CUR
In-Reply-To: <1376345072.81.0.668742432464.issue1582@bugs.pypy.org>
Message-ID: <1376345322.43.0.959321413099.issue1582@bugs.pypy.org>


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

Very slightly more reduced:


import os
from tempfile import TemporaryFile


CHUNK_SIZE = 25

with TemporaryFile('r+w') as f:
    f.write('123456789x12345678><123456789\n')

    f.seek(0, os.SEEK_END)
    f.seek(-CHUNK_SIZE, os.SEEK_CUR)
    f.read(CHUNK_SIZE)
    f.seek(-CHUNK_SIZE, os.SEEK_CUR)
    f.tell()
    try:
        f.seek(-CHUNK_SIZE, os.SEEK_CUR)
    except IOError:
        pass
    else:
        raise AssertionError("Didn't raise IOError")
    print f.tell()

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

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

From tracker at bugs.pypy.org  Tue Aug 13 00:09:58 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 12 Aug 2013 22:09:58 +0000
Subject: [pypy-issue] [issue1582] file.tell() has wrong position after
	failed seek with	SEEK_CUR
In-Reply-To: <1376345072.81.0.668742432464.issue1582@bugs.pypy.org>
Message-ID: <1376345398.18.0.783555898919.issue1582@bugs.pypy.org>


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

Even more!

import os
from tempfile import TemporaryFile


CHUNK_SIZE = 25

with TemporaryFile('r+w') as f:
    f.write('123456789x12345678><123456789\n')

    f.seek(0, os.SEEK_END)
    f.seek(-CHUNK_SIZE, os.SEEK_CUR)
    f.read(CHUNK_SIZE)
    f.seek(-CHUNK_SIZE, os.SEEK_CUR)
    try:
        f.seek(-CHUNK_SIZE, os.SEEK_CUR)
    except IOError:
        pass
    else:
        raise AssertionError("Didn't raise IOError")
    print f.tell()

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

From tracker at bugs.pypy.org  Tue Aug 13 00:42:46 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 12 Aug 2013 22:42:46 +0000
Subject: [pypy-issue] [issue1582] file.tell() has wrong position after
	failed seek with	SEEK_CUR
In-Reply-To: <1376345072.81.0.668742432464.issue1582@bugs.pypy.org>
Message-ID: <1376347366.33.0.854659820824.issue1582@bugs.pypy.org>


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

Resolved in b134074e011c

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

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

From tracker at bugs.pypy.org  Tue Aug 13 21:56:13 2013
From: tracker at bugs.pypy.org (lesshaste)
Date: Tue, 13 Aug 2013 19:56:13 +0000
Subject: [pypy-issue] [issue1579] Potential speedup reading large file into
	a dict
In-Reply-To: <1376073832.99.0.0839060863627.issue1579@bugs.pypy.org>
Message-ID: <1376423773.9.0.866734295862.issue1579@bugs.pypy.org>


lesshaste <drraph at gmail.com> added the comment:

Added C code to make a hash of arrays of strings to make it more apples and 
apples with my original python code submission.

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

From tracker at bugs.pypy.org  Wed Aug 14 02:24:39 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Wed, 14 Aug 2013 00:24:39 +0000
Subject: [pypy-issue] [issue1573] sqlite3 encoding of cursor.description
	column seems to	have changed
In-Reply-To: <1375402267.21.0.573896415985.issue1573@bugs.pypy.org>
Message-ID: <1376439879.72.0.687744821525.issue1573@bugs.pypy.org>


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

Also applied to the 2.1.x release branch in e4405b750715, so this will definitely 
be in the next release

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

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

From tracker at bugs.pypy.org  Wed Aug 14 08:31:20 2013
From: tracker at bugs.pypy.org (Wim Lavrijsen)
Date: Wed, 14 Aug 2013 06:31:20 +0000
Subject: [pypy-issue] [issue1576] cppyy: Need newer genreflex
In-Reply-To: <1375467175.53.0.951294195228.issue1576@bugs.pypy.org>
Message-ID: <1376461880.29.0.583728846831.issue1576@bugs.pypy.org>


Wim Lavrijsen <WLavrijsen at lbl.gov> added the comment:

Hi,

sorry I'm still traveling and missed this one. Please try out:

  http://cern.ch/wlav/reflex-2013-08-14.tar.bz2

(These are build by hand for now. Lots of history here. :) )

Note that taking genreflex from ROOT makes you miss out on one feature: the
ability to hand function pointers to the JIT. Makes a world of difference in
terms of performance. Since this is a pypy-only feature, it's not part of ROOT.

I'll be updating the documentation shortly.

Thanks for reporting!

Cheers,
Wim

----------
assignedto:  -> wlav
nosy: +wlav
status: unread -> testing

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

From tracker at bugs.pypy.org  Wed Aug 14 08:49:08 2013
From: tracker at bugs.pypy.org (Wim Lavrijsen)
Date: Wed, 14 Aug 2013 06:49:08 +0000
Subject: [pypy-issue] [issue1576] cppyy: Need newer genreflex
In-Reply-To: <1375467175.53.0.951294195228.issue1576@bugs.pypy.org>
Message-ID: <1376462948.28.0.954814608938.issue1576@bugs.pypy.org>


Wim Lavrijsen <WLavrijsen at lbl.gov> added the comment:

Hi,

docs have been updated. That should do it.

Thanks,
Wim

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

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

From tracker at bugs.pypy.org  Wed Aug 14 13:12:17 2013
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Wed, 14 Aug 2013 11:12:17 +0000
Subject: [pypy-issue] [issue1583] segfault in
	pypy_g__base_do_getfield_i__int and others
In-Reply-To: <1376478737.59.0.294138362943.issue1583@bugs.pypy.org>
Message-ID: <1376478737.59.0.294138362943.issue1583@bugs.pypy.org>


New submission from Laurence Tratt <laurie at tratt.net>:

If you checkout and build the Converge RPython VM 
<https://github.com/ltratt/converge> 
and then run the richards benchmark you get a segfault on larger runs:

  $ PYPY_SRC=<location of PyPy> ./configure
  ...
  $ make
  ...
  $ cd examples/benchmarks
  $ ../../vm/converge richards.cv 10
  Richards benchmark (Converge) starting... [entry_point] finished.
  Total time for 10 iterations: 1.210496 secs
  Average time per iteration: 121.049644 ms
  $ ../../vm/converge richards.cv 100
  Richards benchmark (Converge) starting... [entry_point]
  zsh: segmentation fault (core dumped)  converge richards 100

This happens on Linux and OpenBSD. There is something non-deterministic going on 
here as 
I get different segfaults on different runs. Here's 1 backtrace:

  #0  0x00001503e775f727 in pypy_g__base_do_getfield_i__int ()
     from /home/ltratt/src/converge/vm/converge
  #1  0x00001503e781bff2 in pypy_g_handler_getfield_raw_i_pure_1 ()
     from /home/ltratt/src/converge/vm/converge
  #2  0x00001503e78258f9 in pypy_g_dispatch_loop ()
     from /home/ltratt/src/converge/vm/converge
  #3  0x00001503e78298e0 in pypy_g_BlackholeInterpreter_run ()
     from /home/ltratt/src/converge/vm/converge
  #4  0x00001503e7829c06 in pypy_g_BlackholeInterpreter__resume_mainloop ()
     from /home/ltratt/src/converge/vm/converge
  #5  0x00001503e782a046 in pypy_g__run_forever ()
     from /home/ltratt/src/converge/vm/converge
  #6  0x00001503e782a3e0 in pypy_g_resume_in_blackhole ()
     from /home/ltratt/src/converge/vm/converge
  #7  0x00001503e783aa0f in pypy_g_ResumeGuardDescr_handle_fail ()
     from /home/ltratt/src/converge/vm/converge
  #8  0x00001503e792c51c in pypy_g_execute_assembler__star_2 ()
     from /home/ltratt/src/converge/vm/converge
  #9  0x00001503e792d4a8 in pypy_g_maybe_compile_and_run__star_6 ()
     from /home/ltratt/src/converge/vm/converge
  #10 0x00001503e772e83e in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #11 0x00001503e792abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM---Type 
<return> to continue, or q <return> to quit---
  _ () from /home/ltratt/src/converge/vm/converge
  #12 0x00001503e7723c75 in pypy_g_VM__instr_apply ()
     from /home/ltratt/src/converge/vm/converge
  #13 0x00001503e772da37 in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #14 0x00001503e792abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM_ () 
from /home/ltratt/src/converge/vm/converge
  #15 0x00001503e7723c75 in pypy_g_VM__instr_apply ()
     from /home/ltratt/src/converge/vm/converge
  #16 0x00001503e772da37 in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #17 0x00001503e792abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM_ () 
from /home/ltratt/src/converge/vm/converge
  #18 0x00001503e7723c75 in pypy_g_VM__instr_apply ()
     from /home/ltratt/src/converge/vm/converge
  #19 0x00001503e772da37 in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #20 0x00001503e792abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM_ () 
from /home/ltratt/src/converge/vm/converge
  #21 0x00001503e76de1cc in pypy_g_VM_apply_closure ()
     from /home/ltratt/src/converge/vm/converge
  #22 0x00001503e76f231d in pypy_g_entry_point ()
     from /home/ltratt/src/converge/vm/converge
  ---Type <return> to continue, or q <return> to quit---
  #23 0x00001503e7982a78 in pypy_main_function ()
     from /home/ltratt/src/converge/vm/converge
  #24 0x00001503e769eec1 in ___start ()
     from /home/ltratt/src/converge/vm/converge
  #25 0x0000000000000003 in ?? ()
  #26 0x00007f7ffffd8790 in ?? ()
  #27 0x00007f7ffffd87b6 in ?? ()
  #28 0x00007f7ffffd87c2 in ?? ()
  #29 0x0000000000000000 in ?? ()

and another:

  #0  0x000003fadf13567a in pypy_g_MiniMarkGC_major_collection ()
     from /home/ltratt/src/converge/vm/converge
  #1  0x000003fadf136332 in pypy_g_MiniMarkGC_collect_and_reserve ()
     from /home/ltratt/src/converge/vm/converge
  #2  0x000003fadf13677b in pypy_g_MiniMarkGC_malloc_fixedsize_clear ()
     from /home/ltratt/src/converge/vm/converge
  #3  0x000003fcee6b4ba6 in ?? ()
  #4  0x000003fce7bece30 in ?? ()
  #5  0x000003fcee6ebfbe in ?? ()
  #6  0x000003fcee6eb710 in ?? ()
  #7  0x000003fadf3e24c8 in pypy_g_typeinfo ()
     from /home/ltratt/src/converge/vm/converge
  #8  0x000003fadf3cf2a0 in pypy_g_rpython_memory_support_FreeList ()
     from /home/ltratt/src/converge/vm/converge
  #9  0x000003fadf3d5b00 in 
pypy_g_rpython_memory_gctransform_shadowstack_ShadowSta () 
from /home/ltratt/src/converge/vm/converge
  #10 0x000003fce0dafda0 in ?? ()
  #11 0x000003fadf3d5b00 in 
pypy_g_rpython_memory_gctransform_shadowstack_ShadowSta () 
from /home/ltratt/src/converge/vm/converge
  #12 0x000003fadf3ce6a0 in pypy_g_rpy_string_3299 ()
     from /home/ltratt/src/converge/vm/converge
  #13 0x000003fce0db13b0 in ?? ()
  #14 0x000003fce7c0b790 in ?? ()
  ---Type <return> to continue, or q <return> to quit---
  #15 0x000003fadef61029 in pypy_g_execute_token__star_2 ()
     from /home/ltratt/src/converge/vm/converge
  #16 0x000003fadf12c3c8 in pypy_g_execute_assembler__star_2 ()
     from /home/ltratt/src/converge/vm/converge
  #17 0x000003fadf12d4a8 in pypy_g_maybe_compile_and_run__star_6 ()
     from /home/ltratt/src/converge/vm/converge
  #18 0x000003fadef2e83e in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #19 0x000003fadf12abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM_ () 
from /home/ltratt/src/converge/vm/converge
  #20 0x000003fadef23c75 in pypy_g_VM__instr_apply ()
     from /home/ltratt/src/converge/vm/converge
  #21 0x000003fadef2da37 in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #22 0x000003fadf12abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM_ () 
from /home/ltratt/src/converge/vm/converge
  #23 0x000003fadef23c75 in pypy_g_VM__instr_apply ()
     from /home/ltratt/src/converge/vm/converge
  #24 0x000003fadef2da37 in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #25 0x000003fadf12abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM_ () 
from /home/ltratt/src/converge/vm/converge
  #26 0x000003fadef23c75 in pypy_g_VM__instr_apply ()
  ---Type <return> to continue, or q <return> to quit---
     from /home/ltratt/src/converge/vm/converge
  #27 0x000003fadef2da37 in pypy_g_portal ()
     from /home/ltratt/src/converge/vm/converge
  #28 0x000003fadf12abf0 in 
pypy_g_ll_portal_runner__Signed_arrayPtr_Core_PCPtr_VM_ () 
from /home/ltratt/src/converge/vm/converge
  #29 0x000003fadeede1cc in pypy_g_VM_apply_closure ()
     from /home/ltratt/src/converge/vm/converge
  #30 0x000003fadeef231d in pypy_g_entry_point ()
     from /home/ltratt/src/converge/vm/converge
  #31 0x000003fadf182a78 in pypy_main_function ()
     from /home/ltratt/src/converge/vm/converge
  #32 0x000003fadee9eec1 in ___start ()
     from /home/ltratt/src/converge/vm/converge
  #33 0x0000000000000003 in ?? ()
  #34 0x00007f7ffffe4490 in ?? ()
  #35 0x00007f7ffffe44b6 in ?? ()
  #36 0x00007f7ffffe44c2 in ?? ()
  #37 0x0000000000000000 in ?? ()

This used to work correctly, and I'm a bit mystified as to a) why it crashes now 
b) why 
it only crashes on certain run lengths. It might be a bug in the Converge VM or 
in 
RPython.

----------
messages: 6063
nosy: ltratt, pypy-issue
priority: critical
status: unread
title: segfault in pypy_g__base_do_getfield_i__int and others

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

From tracker at bugs.pypy.org  Wed Aug 14 20:29:21 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 14 Aug 2013 18:29:21 +0000
Subject: [pypy-issue] [issue1583] segfault in
	pypy_g__base_do_getfield_i__int and others
In-Reply-To: <1376478737.59.0.294138362943.issue1583@bugs.pypy.org>
Message-ID: <1376504961.51.0.567716601085.issue1583@bugs.pypy.org>


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

I did the following on linux64:

    hg clone https://github.com/ltratt/converge
    cd converge
    PYPY_SRC=<location of PyPy trunk> ./configure
    make

and it seems to translate fine but then crashes with:

    ...
    converge: Warning: Can't find Stdlib.cvl.
    converge: Warning: Can't find Compiler.cvl.
    converge: Warning: Can't find Stdlib.cvl.
    converge: Warning: Can't find Stdlib.cvl.
    converge: Warning: Can't find Compiler.cvl.
    converge: Warning: Can't find Compiler.cvl.
    Error: Module 'tannit:/home/arigo/git/converge/compiler/Compiler/Core.cv'
    referenced in 'tannit:/home/arigo/git/converge/compiler/convergel.cv' not
    found.

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

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

From tracker at bugs.pypy.org  Wed Aug 14 20:47:29 2013
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Wed, 14 Aug 2013 18:47:29 +0000
Subject: [pypy-issue] [issue1583] segfault in
	pypy_g__base_do_getfield_i__int and others
In-Reply-To: <1376478737.59.0.294138362943.issue1583@bugs.pypy.org>
Message-ID: <1376506049.79.0.566098796659.issue1583@bugs.pypy.org>


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

Armin,

Thanks for looking (and I need to replicate the bug you saw when building!).

It turns out that I was seeing is a long-dormant bug where there was a write past 
allocated memory in the Converge RPython VM. Some recent change to PyPy has just made 
it pop out. I've fixed it, I'm reasonably sure. Sorry for the noise, and I'm marking 
this one as invalid!


Laurie

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

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

From tracker at bugs.pypy.org  Thu Aug 15 03:14:36 2013
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Thu, 15 Aug 2013 01:14:36 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1376529276.74.0.748026075771.issue1577@bugs.pypy.org>


Ben Darnell <ben at bendarnell.com> added the comment:

(sorry for the delay, the bugtracker's notification emails got caught in a spam 
filter).

I think closing the original socket in SSLSocket.__init__ would work.  I haven't 
been able to translate pypy successfully (probably a lack of ram on my laptop).  
Can I test this without translating?

The test certs I used are from 
https://github.com/facebook/tornado/tree/master/tornado/test

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

From tracker at bugs.pypy.org  Thu Aug 15 08:43:05 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 15 Aug 2013 06:43:05 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1376548985.56.0.423412142854.issue1577@bugs.pypy.org>


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

Yes, you can test this without retranslating: just replace the file ssl.py with
the new version in the stdlib of your installed pypy (lib-python/2.7/ssl.py).

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

From tracker at bugs.pypy.org  Thu Aug 15 17:33:59 2013
From: tracker at bugs.pypy.org (Romain Guillebert)
Date: Thu, 15 Aug 2013 15:33:59 +0000
Subject: [pypy-issue] [issue1544] numpypy: complex(complex128)
In-Reply-To: <1374050447.06.0.0816702513482.issue1544@bugs.pypy.org>
Message-ID: <1376580839.76.0.790146147212.issue1544@bugs.pypy.org>


Romain Guillebert <romain.py at gmail.com> added the comment:

216         # no '__complex__' method, so we assume it is a float,
217         # unless it is an instance of some subclass of complex.
218         if isinstance(w_complex, W_ComplexObject):
219             return (w_complex.realval, w_complex.imagval)

This is the place that should handle the complex128 box, but it doesn't because 
complex128 is an instance of complex at applevel and not at interplevel.

----------
assignedto:  -> rguillebert

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

From tracker at bugs.pypy.org  Thu Aug 15 19:07:38 2013
From: tracker at bugs.pypy.org (Romain Guillebert)
Date: Thu, 15 Aug 2013 17:07:38 +0000
Subject: [pypy-issue] [issue1544] numpypy: complex(complex128)
In-Reply-To: <1374050447.06.0.0816702513482.issue1544@bugs.pypy.org>
Message-ID: <1376586458.94.0.0257584621515.issue1544@bugs.pypy.org>


Romain Guillebert <romain.py at gmail.com> added the comment:

Fixed by ce1c1b2ad027

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

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

From tracker at bugs.pypy.org  Fri Aug 16 02:58:04 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 16 Aug 2013 00:58:04 +0000
Subject: [pypy-issue] [issue1584] Pathological case in bridges
In-Reply-To: <1376614684.27.0.0779493117721.issue1584@bugs.pypy.org>
Message-ID: <1376614684.27.0.0779493117721.issue1584@bugs.pypy.org>


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

Not sure what causes this yet, playing with the number of iterations PyPy is 
consistenly slower than CPython, I think it's because of the super high number of 
bridges compiled:

Alexanders-MacBook-Pro:tmp alex_gaynor$ PYPYLOG=jit-summary:- pypy 
decision_tree.py
[ac4ea2fa4a5] {jit-summary
Tracing:      	3553	19.518618
Backend:      	3552	2.996290
TOTAL:      		51.207841
ops:             	5654103
recorded ops:    	2932390
  calls:         	95188
guards:          	663823
opt ops:         	599629
opt guards:      	176790
forcings:        	3622
abort: trace too long:	1
abort: compiling:	0
abort: vable escape:	0
abort: bad loop: 	0
abort: force quasi-immut:	0
nvirtuals:       	3885619
nvholes:         	518637
nvreused:        	2282863
Total # of loops:	21
Total # of bridges:	3533
Freed # of loops:	7
Freed # of bridges:	3
[ac4ea6187bd] jit-summary}
Alexanders-MacBook-Pro:tmp alex_gaynor$ cat decision_tree.py
import random

class Node(object):
    def __init__(self, idx, thresh, left, right):
      self.idx = idx
      self.thresh = thresh
      self.left = left
      self.right = right

    def predict(self, x):
      if x[self.idx] < self.thresh:
          return self.left.predict(x)
      else:
          return self.right.predict(x)

    def __eq__(self, other):
        return other.__class__ is Node and \
               self.idx == other.idx and \
               self.thresh == other.thresh and \
               self.left == other.left and \
               self.right == other.right

class Leaf(object):
    def __init__(self, value):
        self.value = value

    def predict(self, x):
        return self.value

    def __eq__(self, other):
        return other.__class__ is Leaf and \
               other.value == self.value


def gen_random_tree(n_features, depth):
  #print "n_features = %d, depth = %d" % (n_features, depth)
  if depth == 0:
      return Leaf(random.random())
  else:
    feature_idx = random.randint(0, n_features-1)
    threshold = random.random()
    left = gen_random_tree(n_features, depth - 1)
    right = gen_random_tree(n_features, depth - 1)
    return Node(feature_idx, threshold, left, right)


def predict_labels(feature_list, tree):
  return [tree.predict(v) for v in feature_list]

def gen_random_tuples(n_items, n_features):
  return [tuple([random.random() for _ in range(n_features)])
          for _ in range(n_items)]


if __name__ == '__main__':
  n_samples = 25000
  n_features = 10
  for i in xrange(100):
    tree = gen_random_tree(n_features, depth = 12)
    features = gen_random_tuples(n_samples, n_features)
    predict_labels(features, tree)

----------
messages: 6070
nosy: agaynor, pypy-issue
priority: performance bug
status: unread
title: Pathological case in bridges

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

From tracker at bugs.pypy.org  Fri Aug 16 03:29:57 2013
From: tracker at bugs.pypy.org (Ben Darnell)
Date: Fri, 16 Aug 2013 01:29:57 +0000
Subject: [pypy-issue] [issue1577] SSLSocket.close() doesn't work
In-Reply-To: <1375634503.89.0.643646166226.issue1577@bugs.pypy.org>
Message-ID: <1376616597.31.0.205520641439.issue1577@bugs.pypy.org>


Ben Darnell <ben at bendarnell.com> added the comment:

Ah yes, of course.  With the updated ssl.py all my tests are passing too.

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

From tracker at bugs.pypy.org  Fri Aug 16 09:20:12 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 16 Aug 2013 07:20:12 +0000
Subject: [pypy-issue] [issue1584] Pathological case in bridges
In-Reply-To: <1376614684.27.0.0779493117721.issue1584@bugs.pypy.org>
Message-ID: <1376637612.53.0.56303504926.issue1584@bugs.pypy.org>


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

Another similar case attached.

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

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

From tracker at bugs.pypy.org  Sun Aug 18 16:38:10 2013
From: tracker at bugs.pypy.org (Ram Rachum)
Date: Sun, 18 Aug 2013 14:38:10 +0000
Subject: [pypy-issue] [issue1585] `type.__dict__['__dict__'].__objclass__`
	doesn't exist
In-Reply-To: <1376836690.4.0.878202754152.issue1585@bugs.pypy.org>
Message-ID: <1376836690.4.0.878202754152.issue1585@bugs.pypy.org>


New submission from Ram Rachum <ram at rachum.com>:

This happens on PyPy:

    Python 2.7.3 (480845e6b1dd, Jul 31 2013, 09:10:30)
    [PyPy 2.1.0 with MSC v.1500 32 bit] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    And now for something completely different: ``not incredibly elegant, but 
could
    work''
    >>>> type.__dict__['__dict__'].__objclass__
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: generic property has no __objclass__

While this happens on Python 2.7:

    Python 2.7.4 (default, Apr  6 2013, 19:55:15) [MSC v.1500 64 bit (AMD64)] on 
win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> type.__dict__['__dict__'].__objclass__
    <type 'type'>

----------
messages: 6073
nosy: cool-RR, pypy-issue
priority: bug
release: 2.1
status: unread
title: `type.__dict__['__dict__'].__objclass__` doesn't exist

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

From tracker at bugs.pypy.org  Tue Aug 20 01:47:02 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 19 Aug 2013 23:47:02 +0000
Subject: [pypy-issue] [issue1586] gc.collect doesn't take an argument
In-Reply-To: <1376956022.26.0.0231749135883.issue1586@bugs.pypy.org>
Message-ID: <1376956022.26.0.0231749135883.issue1586@bugs.pypy.org>


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

It should take a single "generation" argument" 
http://docs.python.org/2/library/gc.html#gc.collect not sure what we should do 
with it though

----------
messages: 6074
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: gc.collect doesn't take an argument

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

From tracker at bugs.pypy.org  Tue Aug 20 08:43:05 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 20 Aug 2013 06:43:05 +0000
Subject: [pypy-issue] [issue1586] gc.collect doesn't take an argument
In-Reply-To: <1376956022.26.0.0231749135883.issue1586@bugs.pypy.org>
Message-ID: <1376980985.61.0.0113878118115.issue1586@bugs.pypy.org>


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

We also have a "generation" argument that we can pass to the RPython
rgc.collect(), with roughly the same meaning, but the range of values that makes
sense is different.  Should we anyway just pass the number down and be happy?

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

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

From tracker at bugs.pypy.org  Wed Aug 21 09:54:01 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 21 Aug 2013 07:54:01 +0000
Subject: [pypy-issue] [issue1587] pypy 2.0.2 -
	[translation:ERROR]	__main__.UnrecognizedOperation: pmovzxbw
In-Reply-To: <1377021998.98.0.432657627431.issue1587@bugs.pypy.org>
Message-ID: <1377071641.55.0.0136179647624.issue1587@bugs.pypy.org>


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

Thank you for the report!  As you have attached a file that is so big, it didn't
pass the limits of our mailing list, so I'm resuming what you said here and
asking people to come see the full report on-line:

trackgcroot.py crashes because:
__main__.UnrecognizedOperation: pmovzxbw

(The fix is probably easy.)

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

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

From tracker at bugs.pypy.org  Wed Aug 21 10:00:30 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 21 Aug 2013 08:00:30 +0000
Subject: [pypy-issue] [issue1587] pypy 2.0.2 -
	[translation:ERROR]	__main__.UnrecognizedOperation: pmovzxbw
In-Reply-To: <1377021998.98.0.432657627431.issue1587@bugs.pypy.org>
Message-ID: <1377072030.76.0.400902990693.issue1587@bugs.pypy.org>


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

The PMOVZX instruction is new to SSE 4.  This means you are running the compiler
using the non-standard option of supporting SSE 4.  The simplest fix is: don't :-)

If you want to help anyway, the fix is like the one I just did for PMOVXZ:
first, check in the Intel docs that this instruction can really not produce a
pointer as output data (in this case, it produces data into an XMM register, so
no).  Then edit rpython/translator/c/gcc/trackgcroot.py as I have done in
8de0c4e1a787.  I added PMOVZX and PMOVSX; my guess is that you'll run into a few
other SSE4 instructions too.

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

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

From tracker at bugs.pypy.org  Thu Aug 22 17:05:41 2013
From: tracker at bugs.pypy.org (Romain Guillebert)
Date: Thu, 22 Aug 2013 15:05:41 +0000
Subject: [pypy-issue] [issue1546] numpy.array(..., numpy.character) fails
In-Reply-To: <1374060501.91.0.057432681295.issue1546@bugs.pypy.org>
Message-ID: <1377183941.93.0.351944313867.issue1546@bugs.pypy.org>


Romain Guillebert <romain.py at gmail.com> added the comment:

Hi Peter

It's fixed by revision 36f863c1be94

Romain

----------
status: in-progress -> resolved

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

From tracker at bugs.pypy.org  Thu Aug 22 23:04:29 2013
From: tracker at bugs.pypy.org (Ram Rachum)
Date: Thu, 22 Aug 2013 21:04:29 +0000
Subject: [pypy-issue] [issue1585] `type.__dict__['__dict__'].__objclass__`
	doesn't exist
In-Reply-To: <1376836690.4.0.878202754152.issue1585@bugs.pypy.org>
Message-ID: <1377205469.64.0.953816029316.issue1585@bugs.pypy.org>


Ram Rachum <ram at rachum.com> added the comment:

Hi everyone,

I'm noticing that this bug isn't getting any attention... Anything wrong with 
the report? Any more data that you need?


Thanks,
Ram.

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

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

From tracker at bugs.pypy.org  Thu Aug 22 23:51:41 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 22 Aug 2013 21:51:41 +0000
Subject: [pypy-issue] [issue1585] `type.__dict__['__dict__'].__objclass__`
	doesn't exist
In-Reply-To: <1376836690.4.0.878202754152.issue1585@bugs.pypy.org>
Message-ID: <1377208301.12.0.943372196302.issue1585@bugs.pypy.org>


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

It will likely be closed as "won't fix", with a note added to
http://pypy.readthedocs.org/en/latest/cpython_differences.html .  The issue is
that CPython has a forest of 4 very internal types, and PyPy has only 2, I
think.  "type.__dict__['__dict__']" is one of these.  We still try to emulate
CPython by providing the union of their strange attributes, but in some cases
(like here) we just give up.

In this case the issue is that "type.__dict__['__dict__']" is, on PyPy, just a
usual property that can be used to read or write the __dict__ of anything (as
long as it has a dict, of course).  In particular, there is only one such
property object; it is not attached to a particular class.  It could be changed,
but we need to decide if it's worth it.

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

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

From tracker at bugs.pypy.org  Fri Aug 23 00:32:42 2013
From: tracker at bugs.pypy.org (Ram Rachum)
Date: Thu, 22 Aug 2013 22:32:42 +0000
Subject: [pypy-issue] [issue1585] `type.__dict__['__dict__'].__objclass__`
	doesn't exist
In-Reply-To: <1376836690.4.0.878202754152.issue1585@bugs.pypy.org>
Message-ID: <1377210762.78.0.560179050233.issue1585@bugs.pypy.org>


Ram Rachum <ram at rachum.com> added the comment:

Thanks for the info Armin.

The reason I care about this is that I'm using code from Python's `inspect` 
module, specifically the `getattr_static` function, and it's using the 
`_shadowed_dict` function which, in turn, uses 
`type.__dict__['__dict__'].__objclass__`. So perhaps a Pypy-specific 
implementation of `getattr_static` is in order?

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

From tracker at bugs.pypy.org  Fri Aug 23 08:31:06 2013
From: tracker at bugs.pypy.org (Hardy.li)
Date: Fri, 23 Aug 2013 06:31:06 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>


New submission from Hardy.li <410187271 at qq.com>:

RPython traceback:
  File "rpython_jit_metainterp_pyjitpl.c", line 16375, in MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl.c", line 38092, in 
handler_goto_if_not_ptr_nonzero
  File "rpython_jit_metainterp_pyjitpl_1.c", line 6285, in 
MIFrame__establish_nullity
  File "rpython_jit_metainterp_pyjitpl.c", line 65158, in MIFrame_generate_guard

  File "rpython_jit_metainterp_resoperation.c", line 242, in ResOperation
  File "rpython_jit_metainterp_resoperation.c", line 872, in 
UnaryGuardResOp_initarglist

----------
messages: 6083
nosy: pypy-issue, yelang
priority: bug
status: unread
title: Fatal RPython error: AssertionError  pypy-2.1

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

From tracker at bugs.pypy.org  Fri Aug 23 09:11:13 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 23 Aug 2013 07:11:13 +0000
Subject: [pypy-issue] [issue1585] py3k:
	`type.__dict__['__dict__'].__objclass__` doesn't	exist
In-Reply-To: <1376836690.4.0.878202754152.issue1585@bugs.pypy.org>
Message-ID: <1377241873.83.0.574441702928.issue1585@bugs.pypy.org>


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

Yes, likely.  This function exists only in Python 3; tagged the bug report in
consequence.

----------
title: `type.__dict__['__dict__'].__objclass__` doesn't exist -> py3k: `type.__dict__['__dict__'].__objclass__` doesn't exist

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

From tracker at bugs.pypy.org  Fri Aug 23 09:13:38 2013
From: tracker at bugs.pypy.org (Hardy.li)
Date: Fri, 23 Aug 2013 07:13:38 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377242018.83.0.255659462862.issue1588@bugs.pypy.org>


Hardy.li <410187271 at qq.com> added the comment:

This bug happen on ctypes  exports the  windll

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

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

From tracker at bugs.pypy.org  Fri Aug 23 09:17:10 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 23 Aug 2013 07:17:10 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377242230.3.0.305663969048.issue1588@bugs.pypy.org>


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

Thanks for the bug report!  However, you need to be more precise.  It is
unlikely that *any* usage of ctypes.windll crashes like this.  Please include a
small example of code that crashes like this, so that we can reproduce it.

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

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

From tracker at bugs.pypy.org  Fri Aug 23 09:43:48 2013
From: tracker at bugs.pypy.org (Hardy.li)
Date: Fri, 23 Aug 2013 07:43:48 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377243828.03.0.713708958153.issue1588@bugs.pypy.org>


Hardy.li <410187271 at qq.com> added the comment:

Thanks for the reply!

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

From tracker at bugs.pypy.org  Fri Aug 23 10:10:48 2013
From: tracker at bugs.pypy.org (Hardy.li)
Date: Fri, 23 Aug 2013 08:10:48 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377245448.55.0.736925151552.issue1588@bugs.pypy.org>


Hardy.li <410187271 at qq.com> added the comment:

Thanks for the reply! Where the source code of rpython_jit_metainterp_pyjitpl.c,I 
can find.So I can  provide accurate information.

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

From tracker at bugs.pypy.org  Fri Aug 23 13:19:41 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 23 Aug 2013 11:19:41 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377256781.18.0.828942962866.issue1588@bugs.pypy.org>


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

The accurate information would be the minimal program that causes such a crash.

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

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

From tracker at bugs.pypy.org  Sat Aug 24 04:41:02 2013
From: tracker at bugs.pypy.org (Philip Jenvey)
Date: Sat, 24 Aug 2013 02:41:02 +0000
Subject: [pypy-issue] [issue1585] py3k:
	`type.__dict__['__dict__'].__objclass__` doesn't	exist
In-Reply-To: <1376836690.4.0.878202754152.issue1585@bugs.pypy.org>
Message-ID: <1377312062.79.0.362909789023.issue1585@bugs.pypy.org>


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

The py3k branch already has a workaround: 
https://bitbucket.org/pypy/pypy/commits/8ca54fddd153

Since it sounds like you're borrowing the implementation, I'm closing this 
ticket. Otherwise if there's a problem with how the py3k workaround handles 
things, let us know

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

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

From tracker at bugs.pypy.org  Sat Aug 24 04:59:49 2013
From: tracker at bugs.pypy.org (Isaac Freeman)
Date: Sat, 24 Aug 2013 02:59:49 +0000
Subject: [pypy-issue] [issue1589] numpy: Structured arrays give odd behavior
In-Reply-To: <1377313189.98.0.193986333307.issue1589@bugs.pypy.org>
Message-ID: <1377313189.98.0.193986333307.issue1589@bugs.pypy.org>


New submission from Isaac Freeman <memotype at gmail.com>:

I'm running the latest nightly as of last night. Trying to construct structured
arrays from a list gives add characters and values in the resulting array:

numpypy:

In [76]: c = numpy.array([[(1,2,'a'),(3,4,'b')],[(5,6,'c'),(7,8,'d')]],
dtype=[('bg', 'i8'), ('fg', 'i8'), ('char', 'S1')] )

In [77]: c
Out[77]: 
'), (3, 4, '')],
       [(5, 6, ''), (7, 8, '')]], 
      dtype=void136)

(There are some non-printable characters in the output.)

Compared to numpy in cpython:

>>> c = numpy.array([[(1,2,'a'),(3,4,'b')],[(5,6,'c'),(7,8,'d')]], dtype=[('bg',
'i8'), ('fg', 'i8'), ('char', 'S1')])
>>> c
array([[(1, 2, 'a'), (3, 4, 'b')],
       [(5, 6, 'c'), (7, 8, 'd')]], 
      dtype=[('bg', '<i8'), ('fg', '<i8'), ('char', 'S1')])

This also affects array assignment. In numpypy:

In [83]: c = numpy.zeros((2,2,2), dtype=[('bg', 'i8'), ('fg', 'i8'), ('char', '\
S1')])

In [84]: c
Out[84]: 
array([[[(0, 0, ''), (0, 0, '')],
        [(0, 0, ''), (0, 0, '')]],

       [[(0, 0, ''), (0, 0, '')],
        [(0, 0, ''), (0, 0, '')]]], 
      dtype=void136)

In [85]: c[0,0] = (1, 2, 'a')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-85-158a9c3d29f8> in <module>()
----> 1 c[0,0] = (1, 2, 'a')

ValueError: invalid literal for int() with base 10: 'a'

In [86]: 

And in numpy/cpython:

>>> c = numpy.zeros((2,2,2), dtype=[('bg', 'i8'), ('fg', 'i8'), ('char', '\
... S1')])
>>> c
array([[[(0, 0, ''), (0, 0, '')],
        [(0, 0, ''), (0, 0, '')]],

       [[(0, 0, ''), (0, 0, '')],
        [(0, 0, ''), (0, 0, '')]]], 
      dtype=[('bg', '<i8'), ('fg', '<i8'), ('char', 'S1')])
>>> c[0,0] = (1, 2, 'a')
>>> c[0,0]
array([(1, 2, 'a'), (1, 2, 'a')], 
      dtype=[('bg', '<i8'), ('fg', '<i8'), ('char', 'S1')])
>>>

----------
messages: 6091
nosy: memotype, pypy-issue
priority: bug
status: unread
title: numpy: Structured arrays give odd behavior

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

From tracker at bugs.pypy.org  Sat Aug 24 08:58:29 2013
From: tracker at bugs.pypy.org (Isaac Freeman)
Date: Sat, 24 Aug 2013 06:58:29 +0000
Subject: [pypy-issue] [issue1589] numpy: Structured arrays give odd behavior
In-Reply-To: <1377313189.98.0.193986333307.issue1589@bugs.pypy.org>
Message-ID: <1377327509.95.0.0168115016902.issue1589@bugs.pypy.org>


Isaac Freeman <memotype at gmail.com> added the comment:

In fact, the problem might just be with characters/strings in general? Not sure
if this is related, but:

$ ./pypy
Python 2.7.3 (83074dd846cf, Aug 22 2013, 22:00:27)
[PyPy 2.2.0-alpha0 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``exarkun: "the part that I thought
was going to be hard was trivial, so now I just have this part that I didn't
even think of that is hard"''
>>>> import numpypy
>>>> import numpy
>>>> a = numpy.empty((10,10), dtype='S1')
>>>> a.fill(' ')
[1]    3825 segmentation fault (core dumped)  ./pypy

$ ./pypy
Python 2.7.3 (83074dd846cf, Aug 22 2013, 22:00:27)
[PyPy 2.2.0-alpha0 with GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy 1.7 released''
>>>> import numpypy
>>>> import numpy
>>>> a = numpy.empty((10,10), dtype='c1')
>>>> a.fill(' ')
[1]    3840 segmentation fault (core dumped)  ./pypy

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

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

From tracker at bugs.pypy.org  Sat Aug 24 15:24:19 2013
From: tracker at bugs.pypy.org (Tom Wijsman)
Date: Sat, 24 Aug 2013 13:24:19 +0000
Subject: [pypy-issue] [issue1587] pypy 2.0.2 -
	[translation:ERROR]	__main__.UnrecognizedOperation: pmovzxbw
In-Reply-To: <1377021998.98.0.432657627431.issue1587@bugs.pypy.org>
Message-ID: <1377350659.02.0.658181014179.issue1587@bugs.pypy.org>


Tom Wijsman <TomWij at gentoo.org> added the comment:

I want to help if it doesn't involve hours of time; so, I was wondering if there 
is an easy way to just replicate the error without having to rebuild pypy every 
time. Switching from -march=native (picks corei7) to -march=x86-64 made it 
build; per the suggestion from someone else, but it would be nice to have it 
build in a native way to avoid people in the future from experiencing this 
again.

So, what is a minimal test case to find more of such instructions?

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

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

From tracker at bugs.pypy.org  Sat Aug 24 16:38:00 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 24 Aug 2013 14:38:00 +0000
Subject: [pypy-issue] [issue1587] pypy 2.0.2 -
	[translation:ERROR]	__main__.UnrecognizedOperation: pmovzxbw
In-Reply-To: <1377021998.98.0.432657627431.issue1587@bugs.pypy.org>
Message-ID: <1377355080.64.0.773520397084.issue1587@bugs.pypy.org>


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

It's only about the very last step.  Run a translation, then "cd
/tmp/usession-YOURNAME/testing_1".  There, "make".  If it finds more
instructions missing, add them to trackgcroot.py like I did in hg revision
8de0c4e1a787 (https://bitbucket.org/pypy/pypy/commits/8de0c4e1a787), and then
"make" again.

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

From tracker at bugs.pypy.org  Sat Aug 24 16:51:05 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 24 Aug 2013 14:51:05 +0000
Subject: [pypy-issue] [issue1587] pypy 2.0.2 -
	[translation:ERROR]	__main__.UnrecognizedOperation: pmovzxbw
In-Reply-To: <1377021998.98.0.432657627431.issue1587@bugs.pypy.org>
Message-ID: <1377355865.46.0.326698238291.issue1587@bugs.pypy.org>


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

I added "pblend*" in 3e8d338192e8; it is enough to build now with
"-march=native", at least in my experiment; maybe you'll still hit a couple
extra instructions.

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

From tracker at bugs.pypy.org  Mon Aug 26 10:11:16 2013
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Mon, 26 Aug 2013 08:11:16 +0000
Subject: [pypy-issue] [issue1590] NaN valued numpypy.float64 can be
	converted to int
In-Reply-To: <1377504676.46.0.56280241899.issue1590@bugs.pypy.org>
Message-ID: <1377504676.46.0.56280241899.issue1590@bugs.pypy.org>


New submission from Hakan Ardo <hakan at debian.org>:

$ pypy -c 'import numpypy as np; print int(np.array([np.nan])[0])'
-9223372036854775808

on cpython this raises ValueError:

$ python -c 'import numpy as np; print int(np.array([np.nan])[0])'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: cannot convert float NaN to integer

----------
messages: 6097
nosy: hakanardo, pypy-issue
priority: bug
status: unread
title: NaN valued numpypy.float64 can be converted to int

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

From tracker at bugs.pypy.org  Mon Aug 26 10:18:46 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 26 Aug 2013 08:18:46 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377505126.48.0.0661781040714.issue1588@bugs.pypy.org>


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

Thank you for the attachment!  (This is a warning for others: the attachment is
too large and so wasn't sent to the mailing list.  See the bug tracker directly.)

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

From tracker at bugs.pypy.org  Mon Aug 26 15:11:50 2013
From: tracker at bugs.pypy.org (Romain Guillebert)
Date: Mon, 26 Aug 2013 13:11:50 +0000
Subject: [pypy-issue] [issue1589] numpy: Structured arrays give odd behavior
In-Reply-To: <1377313189.98.0.193986333307.issue1589@bugs.pypy.org>
Message-ID: <1377522710.78.0.447444521946.issue1589@bugs.pypy.org>


Romain Guillebert <romain.py at gmail.com> added the comment:

It's 2 different bugs, I'm going to fix the last one first

----------
status: chatting -> in-progress

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

From tracker at bugs.pypy.org  Mon Aug 26 16:55:38 2013
From: tracker at bugs.pypy.org (colossaltask52)
Date: Mon, 26 Aug 2013 14:55:38 +0000
Subject: [pypy-issue] [issue826] NewInterface
In-Reply-To: <1313104769.61.0.228154928937.issue826@bugs.pypy.org>
Message-ID: <1377528938.52.0.193698326602.issue826@bugs.pypy.org>


colossaltask52 <jaredcornwall83 at gmail.com> added the comment:

NewInterface

----------
nosy: +colossaltask52
title: Decimal seems slower on pypy than cpython -> NewInterface

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

From tracker at bugs.pypy.org  Mon Aug 26 22:23:26 2013
From: tracker at bugs.pypy.org (lvella)
Date: Mon, 26 Aug 2013 20:23:26 +0000
Subject: [pypy-issue] [issue1591] py3k: Django's "syncdb" fails when using
	sqlite3
In-Reply-To: <1377548606.81.0.393546958559.issue1591@bugs.pypy.org>
Message-ID: <1377548606.81.0.393546958559.issue1591@bugs.pypy.org>


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

Command:
$ pypy manage.py syncdb

Fails with the following message (without stack trace):
AttributeError: 'str' object has no attribute 'decode'

Digging a little deeper, I managed to find this line on SQLite3 backend
(django/db/backends/sqlite3/base.py):

if Database.version_info >= (2, 4, 1):
    # Starting in 2.4.1, the str type is not accepted anymore, therefore,
    # we convert all str objects to Unicode
    # As registering a adapter for a primitive type causes a small
    # slow-down, this adapter is only registered for sqlite3 versions
    # needing it (Python 2.6 and up).
    Database.register_adapter(str, lambda s: s.decode('utf-8'))
    Database.register_adapter(SafeBytes, lambda s: s.decode('utf-8'))

and that lambda registered with "str" type is throwing the exception. This code
itself seems to be wrong, because it doesn't take into account Python 3 changes
(Django's support for py3k is experimental), but what is really intriguing is
that it actually works on CPython.

I patched that code and replaced the lambda with a function that tries to
intercept the AttributeError exception, just to see if the exception was
occurring with CPython 3, too. The exception is raised, but somewhere in the
stack it is swallowed, what allows the execution to resume. The same is not true
on Pypy, and the exception manages to reach top-level and terminates the process
(without a stack trace).

To reproduce, install Django 1.5.2 on a PyPy3 2.1 beta 1 virtualenv, create a
project:
$ django-admin.py startproject test

modify "test/test/settings.py" to use sqlite3:
...
        'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2',
'mysql', 'sqlite3' or 'oracle'.
        'NAME': '/tmp/db',  # Or path to database file if using sqlite3.
...

and run syncdb inside project directory:
$ cd test
$ pypy ./manage.py syncdb

The error occurs after creating all the tables for the authentication
application (used by default), when calling the post-sync callbacks. By patching
"django/core/management/sql.py" with a traceback print:
...
        try:
            models.signals.post_syncdb.send(sender=app, app=app,
                created_models=created_models, verbosity=verbosity,
                interactive=interactive, db=db)
        except:
            traceback.print_exc()
            raise
...

I managed to get this traceback from pypy:
$ ./manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_groups
Creating table auth_user_user_permissions
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Traceback (most recent call last):
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/contrib/contenttypes/models.py",
line 39, in get_for_model
    ct = self._get_from_cache(opts)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/contrib/contenttypes/models.py",
line 29, in _get_from_cache
    return self.__class__._cache[self.db][key]
KeyError: 'default'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/core/management/sql.py",
line 197, in emit_post_sync_signal
    interactive=interactive, db=db)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/dispatch/dispatcher.py",
line 170, in send
    response = receiver(signal=self, sender=sender, **named)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/contrib/auth/management/__init__.py",
line 77, in create_permissions
    ctype = ContentType.objects.db_manager(db).get_for_model(klass)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/contrib/contenttypes/models.py",
line 47, in get_for_model
    defaults = {'name': smart_text(opts.verbose_name_raw)},
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/models/manager.py",
line 146, in get_or_create
    return self.get_query_set().get_or_create(**kwargs)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/models/query.py",
line 484, in get_or_create
    return self.get(**lookup), False
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/models/query.py",
line 398, in get
    num = len(clone)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/models/query.py",
line 106, in __len__
    self._result_cache = list(self.iterator())
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/models/query.py",
line 317, in iterator
    for row in compiler.results_iter():
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/models/sql/compiler.py",
line 775, in results_iter
    for rows in self.execute_sql(MULTI):
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/models/sql/compiler.py",
line 840, in execute_sql
    cursor.execute(sql, params)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/backends/util.py",
line 41, in execute
    return self.cursor.execute(sql, params)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/backends/sqlite3/base.py",
line 362, in execute
    return Database.Cursor.execute(self, query, params)
  File "/home/vella/progs/pypy3-2.1-beta1-linux64/lib_pypy/_sqlite3.py", line
887, in wrapper
    return func(self, *args, **kwargs)
  File "/home/vella/progs/pypy3-2.1-beta1-linux64/lib_pypy/_sqlite3.py", line
1046, in execute
    return self.__execute(False, sql, [params])
  File "/home/vella/progs/pypy3-2.1-beta1-linux64/lib_pypy/_sqlite3.py", line
1009, in __execute
    self.__statement._set_params(params)
  File "/home/vella/progs/pypy3-2.1-beta1-linux64/lib_pypy/_sqlite3.py", line
1288, in _set_params
    rc = self.__set_param(i + 1, params[i])
  File "/home/vella/progs/pypy3-2.1-beta1-linux64/lib_pypy/_sqlite3.py", line
1244, in __set_param
    param = adapt(param)
  File "/home/vella/progs/pypy3-2.1-beta1-linux64/lib_pypy/_sqlite3.py", line
1502, in adapt
    return adapter(val)
  File
"/home/vella/projetos/chroni9/venv/site-packages/django/db/backends/sqlite3/base.py",
line 82, in <lambda>
    Database.register_adapter(str, lambda s: s.decode('utf-8'))
AttributeError: 'str' object has no attribute 'decode'
AttributeError: 'str' object has no attribute 'decode'

----------
messages: 6101
nosy: lvella, pypy-issue
priority: bug
release: 2.1
status: unread
title: py3k: Django's "syncdb" fails when using sqlite3

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

From tracker at bugs.pypy.org  Mon Aug 26 23:29:30 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc)
Date: Mon, 26 Aug 2013 21:29:30 +0000
Subject: [pypy-issue] [issue1591] py3k: Django's "syncdb" fails when using
	sqlite3
In-Reply-To: <1377548606.81.0.393546958559.issue1591@bugs.pypy.org>
Message-ID: <1377552570.95.0.359737742115.issue1591@bugs.pypy.org>


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

Indeed, in http://hg.python.org/cpython/file/v2.7.5/Modules/_sqlite/statement.c#l258
The error in adapt() is swallowed and the original value is retained.

Fixed with 6181c1116a92, thanks for the report!

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

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

From tracker at bugs.pypy.org  Tue Aug 27 17:07:15 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 27 Aug 2013 15:07:15 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377616035.06.0.380505795956.issue1588@bugs.pypy.org>


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

Please include the original source code of your program (the .py files).

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

From tracker at bugs.pypy.org  Tue Aug 27 17:21:21 2013
From: tracker at bugs.pypy.org (Ronan Lamy)
Date: Tue, 27 Aug 2013 15:21:21 +0000
Subject: [pypy-issue] [issue1592] np.unicode support
In-Reply-To: <1377616881.71.0.957917515149.issue1592@bugs.pypy.org>
Message-ID: <1377616881.71.0.957917515149.issue1592@bugs.pypy.org>


New submission from Ronan Lamy <ronan.lamy at gmail.com>:

trying to create np.unicode_ objects segfaults:

>>>> import numpypy as np
>>>> np.unicode_(u'123')

----------
messages: 6104
nosy: pypy-issue, rguillebert, rlamy
priority: bug
status: chatting
title: np.unicode support

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

From tracker at bugs.pypy.org  Tue Aug 27 17:22:14 2013
From: tracker at bugs.pypy.org (Ronan Lamy)
Date: Tue, 27 Aug 2013 15:22:14 +0000
Subject: [pypy-issue] [issue1592] np.unicode support
In-Reply-To: <1377616881.71.0.957917515149.issue1592@bugs.pypy.org>
Message-ID: <1377616934.05.0.967069629181.issue1592@bugs.pypy.org>


Ronan Lamy <ronan.lamy at gmail.com> added the comment:

trying to create np.unicode_ objects segfaults:

>>>> import numpypy as np
>>>> np.unicode_(u'123')
Segmentation fault (core dumped)

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

From tracker at bugs.pypy.org  Thu Aug 29 04:07:25 2013
From: tracker at bugs.pypy.org (Hardy.li)
Date: Thu, 29 Aug 2013 02:07:25 +0000
Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError
	pypy-2.1
In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org>
Message-ID: <1377742045.07.0.943573335063.issue1588@bugs.pypy.org>


Hardy.li <410187271 at qq.com> added the comment:

The original source code of my program is in attachment,there have parts of .py 
files.And, If necessary, I will try to provide DLL files.

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