From pypy-dev-issue at codespeak.net  Sat Nov 13 22:36:55 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sat, 13 Nov 2010 21:36:55 +0000
Subject: [PyPy-issue] [issue561] debug log got messed up sometimes
Message-ID: <1289684215.1.0.635838856776.issue561@>


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

No clue how, but seeing some race conditions. Example:
http://paste.pocoo.org/show/290994/

----------
effort: ???
messages: 1842
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: debug log got messed up sometimes

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue561>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 23 17:42:48 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 23 Nov 2010 16:42:48 +0000
Subject: [PyPy-issue] [issue561] debug log got messed up sometimes
Message-ID: <1290530568.36.0.0315515333669.issue561@>


Armin Rigo <arigo+pypyissues at codespeak.net> added the comment:

Probably fixed by not passing PYPYLOG to children processes.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue561>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Wed Nov 24 10:32:29 2010
From: pypy-dev-issue at codespeak.net (Aaron DeVore)
Date: Wed, 24 Nov 2010 09:32:29 +0000
Subject: [PyPy-issue] [issue562] Shebangs do not specify a python version
Message-ID: <1290591149.03.0.570194590979.issue562@>


New submission from Aaron DeVore <aaron.devore at gmail.com>:

The shebangs on scripts use the generic python executable instead of explicitly
asking for Python 2 via the python2 executable. This is currently an issue on
Arch Linux, which has switched /usr/bin/python to Python 3. I usually attach a
patch, but my find-and-replace tool isn't handling some non-English characters
very well. Basically just replace

#!/usr/bin/env python

with

#!/usr/bin/env python2

----------
effort: ???
messages: 1844
nosy: aaron.devore, pypy-issue
priority: bug
release: ???
status: unread
title: Shebangs do not specify a python version

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue562>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Wed Nov 24 10:34:52 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Wed, 24 Nov 2010 09:34:52 +0000
Subject: [PyPy-issue] [issue562] Shebangs do not specify a python version
Message-ID: <1290591292.96.0.762467199143.issue562@>


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

Honestly, this is an arch python problem. Because:

* python2 is not anywhere (just on arch)\

* python3 won't run this scripts anyway, so there is no point

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue562>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Wed Nov 24 11:17:07 2010
From: pypy-dev-issue at codespeak.net (Aaron DeVore)
Date: Wed, 24 Nov 2010 10:17:07 +0000
Subject: [PyPy-issue] [issue562] Shebangs do not specify a python version
Message-ID: <1290593827.8.0.634082339913.issue562@>


Aaron DeVore <aaron.devore at gmail.com> added the comment:

I talked to #pypy about this. Changing to:

#!/usr/bin/env python2

only works when the python2 symlink is available. Arch has the python2 symlink
to facilitate Arch's move to Python 3 as the default /usr/bin/python. Other
distros do not. Executables are often named according to their version (e.g.
/usr/bin/python2.6), but without a python2 symlink. Arch users should simply run
Python scripts using:

python2 path/to/script.py

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue562>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Wed Nov 24 16:51:15 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 24 Nov 2010 15:51:15 +0000
Subject: [PyPy-issue] [issue563] SyntaxError issue
Message-ID: <1290613875.45.0.86159757722.issue563@>


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

We are worse than CPython at reporting SyntaxError in this case:

    def f():
        foo(      # missing closing parenthesis
    def bar():
        pass

We report the error with a line number that is the end of the file, making it
impossible to find where the missing closing parenthesis actually is.

----------
effort: ???
messages: 1847
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: SyntaxError issue

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue563>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Nov 26 21:38:35 2010
From: pypy-dev-issue at codespeak.net (Leonardo Santagada)
Date: Fri, 26 Nov 2010 20:38:35 +0000
Subject: [PyPy-issue] [issue564] Translation fails without ncurses with a
	py.test.skip exception
Message-ID: <1290803915.6.0.17025687371.issue564@>


New submission from Leonardo Santagada <santagada at gmail.com>:

Djc on irc reported this bug, while trying to translate pypy without ncurses he got the 
stack trace below:


[platform:execute] gcc /var/tmp/portage/dev-python/pypy-1.4/temp/usession-0/platcheck_0.o 
-pthread -lrt -o /var/tmp/portage/dev-python/pypy-1.4/temp/usession-0/platcheck_0
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "translate.py", line 268, in main
[translation:ERROR]     default_goal='compile')
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/translator/driver.py", line 831, in from_targetspec
[translation:ERROR]     spec = target(driver, args)
[translation:ERROR]    File "targetpypystandalone.py", line 157, in target
[translation:ERROR]     enable_allworkingmodules(config)
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/config/pypyoption.py", line 386, in enable_allworkingmodules
[translation:ERROR]     config.objspace.usemodules.suggest(**dict.fromkeys(modules, 
True))
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/config/config.py", line 112, in suggest
[translation:ERROR]     self.suggestoption(name, value)
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/config/config.py", line 116, in suggestoption
[translation:ERROR]     self.setoption(name, value, "suggested")
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/config/config.py", line 107, in setoption
[translation:ERROR]     child.setoption(self, value, who)
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/config/config.py", line 305, in setoption
[translation:ERROR]     self._validator(toplevel)
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/config/pypyoption.py", line 101, in validator
[translation:ERROR]     __import__(name)
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/pypy/module/_minimal_curses/__init__.py", line 7, in <module>
[translation:ERROR]     import py; py.test.skip("no _curses module")    # no _curses at 
all
[translation:ERROR]    File "/var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/py/_plugin/pytest_runner.py", line 336, in skip
[translation:ERROR]     raise Skipped(msg=msg)
[translation:ERROR]  Skipped: 'no _curses module'
[translation] start debugger...
> /var/tmp/portage/dev-python/pypy-1.4/work/pypy-
1.4/py/_plugin/pytest_runner.py(336)skip()
-> raise Skipped(msg=msg)

----------
effort: ???
messages: 1848
nosy: pypy-issue, santagada
priority: bug
release: ???
status: unread
title: Translation fails without ncurses with a py.test.skip exception

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue564>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Nov 26 21:41:20 2010
From: pypy-dev-issue at codespeak.net (Leonardo Santagada)
Date: Fri, 26 Nov 2010 20:41:20 +0000
Subject: [PyPy-issue] [issue565] There is no 1.4 release on the issue tracker
Message-ID: <1290804079.99.0.621818692502.issue565@>


New submission from Leonardo Santagada <santagada at gmail.com>:

releases only goes to 1.1, maybe there should be a trunk/branches also.

----------
effort: ???
messages: 1849
nosy: pypy-issue, santagada
priority: bug
release: ???
status: unread
title: There is no 1.4 release on the issue tracker

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue565>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Nov 26 21:50:14 2010
From: pypy-dev-issue at codespeak.net (Leonardo Santagada)
Date: Fri, 26 Nov 2010 20:50:14 +0000
Subject: [PyPy-issue] [issue566] New accounts can't create issues
Message-ID: <1290804614.29.0.666364240898.issue566@>


New submission from Leonardo Santagada <santagada at gmail.com>:

For example djc created his account but couldn't create new issues.

----------
effort: ???
messages: 1850
nosy: djc, pypy-issue, santagada
priority: bug
release: ???
status: unread
title: New accounts can't create issues

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue566>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Nov 26 22:02:51 2010
From: pypy-dev-issue at codespeak.net (Leonardo Santagada)
Date: Fri, 26 Nov 2010 21:02:51 +0000
Subject: [PyPy-issue] [issue567] Silence annrpython warnings for 1.5
Message-ID: <1290805371.33.0.180103059748.issue567@>


New submission from Leonardo Santagada <santagada at gmail.com>:

Silence annrpython warnings by default for pypy 1.5

----------
effort: ???
messages: 1851
nosy: pypy-issue, santagada
priority: wish
release: ???
status: unread
title: Silence annrpython warnings for 1.5

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue567>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 00:46:55 2010
From: pypy-dev-issue at codespeak.net (Holger Krekel)
Date: Fri, 26 Nov 2010 23:46:55 +0000
Subject: [PyPy-issue] [issue566] New accounts can't create issues
Message-ID: <1290815215.73.0.582874432449.issue566@>


Holger Krekel <holger at merlinux.eu> added the comment:

i think i fixed it - both djc and voidspace should be able to create issues. 
Not sure why but the default role for new users was just "anonymous" - maybe
because there was spam.  If this was indeed the problem then in the future we
may require assigning the role "User" to a new user manually, unless roundup has
better spam-protection.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue566>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 08:17:56 2010
From: pypy-dev-issue at codespeak.net (AliaK)
Date: Sat, 27 Nov 2010 07:17:56 +0000
Subject: [PyPy-issue] [issue568] __repr__ lost in translation
Message-ID: <1290842276.77.0.542602630912.issue568@>


New submission from AliaK <alia_khouri at yahoo.com>:

As of pypy-trunk revision 79591 on ubuntu maverick, the result of translating
the attached (klass.py) via "../pypy/translator/goal/translate.py klass.py"
produces an executable which incorrectly represents the class instance, by
somehow ignoring __repr__ logic.

so ./klass-c produces:

<Person object at 0xb730f038>

when it should output the correct:

Person(name='sa', age='21')

----------
effort: ???
files: klass.py
messages: 1853
nosy: alia_khouri, pypy-issue
priority: bug
release: ???
status: unread
title: __repr__ lost in translation

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue568>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: klass.py
Type: text/x-python-script
Size: 649 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101127/b0f5d4ce/attachment.bin>

From pypy-dev-issue at codespeak.net  Sat Nov 27 09:05:33 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sat, 27 Nov 2010 08:05:33 +0000
Subject: [PyPy-issue] [issue568] __repr__ lost in translation
Message-ID: <1290845133.21.0.654797531918.issue568@>


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

Hey.

You should not use translation this way (instead use target) and also you should 
not use translation at all unless you have a good reason. __repr__ is not RPython 
for example. Why don't use compiled version with JIT?

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue568>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 13:12:43 2010
From: pypy-dev-issue at codespeak.net (AliaK)
Date: Sat, 27 Nov 2010 12:12:43 +0000
Subject: [PyPy-issue] [issue568] __repr__ lost in translation
Message-ID: <1290859963.8.0.914004443767.issue568@>


AliaK <alia_khouri at yahoo.com> added the comment:

Fair enough. I didn't realize __repr__ was not allowed in RPython, so I thought
it was a bug. Thanks for the explanation.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue568>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 14:08:34 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sat, 27 Nov 2010 13:08:34 +0000
Subject: [PyPy-issue] [issue568] __repr__ lost in translation
Message-ID: <1290863314.02.0.897640553477.issue568@>


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

closing then

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue568>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 16:28:51 2010
From: pypy-dev-issue at codespeak.net (Holger Krekel)
Date: Sat, 27 Nov 2010 15:28:51 +0000
Subject: [PyPy-issue] [issue569] pty.fork() out of pty devices
Message-ID: <1290871731.32.0.617129440942.issue569@>


New submission from Holger Krekel <holger at merlinux.eu>:

On pypy-1.4 linux-64bit, for examaple tannit, "import pty ; pty.fork()" bails
out with: OSError: out of pty devices.  the 32bit version returns a correct
result it seems.

----------
effort: ???
messages: 1857
nosy: hpk, pypy-issue
priority: bug
release: 1.4
status: unread
title: pty.fork() out of pty devices

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue569>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 18:01:50 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sat, 27 Nov 2010 17:01:50 +0000
Subject: [PyPy-issue] [issue569] pty.fork() out of pty devices
Message-ID: <1290877310.18.0.625388620296.issue569@>


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

os.forkpty() was not implemented.
Done in r79599, thanks for the report!

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue569>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 20:55:39 2010
From: pypy-dev-issue at codespeak.net (Tom Burdick)
Date: Sat, 27 Nov 2010 19:55:39 +0000
Subject: [PyPy-issue] [issue570] structseq.h for cpyext
Message-ID: <1290887739.66.0.401257227178.issue570@>


New submission from Tom Burdick <thomas.burdick at gmail.com>:

structseq.h is missing from cpyext and is needed for my favorite c extension, 
pyev.

----------
effort: easy
messages: 1859
nosy: bfrog, pypy-issue
priority: feature
release: 1.4
status: unread
title: structseq.h for cpyext

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue570>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 20:57:19 2010
From: pypy-dev-issue at codespeak.net (Tom Burdick)
Date: Sat, 27 Nov 2010 19:57:19 +0000
Subject: [PyPy-issue] [issue571] pypy-c needs -E option
Message-ID: <1290887839.34.0.0903010278738.issue571@>


New submission from Tom Burdick <thomas.burdick at gmail.com>:

The venusian package requires the python interpretter have a -E flag, which 
equats to ignoring the PYTHONPATH environment variable

----------
effort: ???
messages: 1860
nosy: bfrog, pypy-issue
priority: feature
release: 1.4
status: unread
title: pypy-c needs -E option

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue571>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 21:16:21 2010
From: pypy-dev-issue at codespeak.net (Edward Cannon)
Date: Sat, 27 Nov 2010 20:16:21 +0000
Subject: [PyPy-issue] [issue572] windows build fails with missing
	msvcr100.dll error
Message-ID: <1290888981.01.0.0405418974989.issue572@>


New submission from Edward Cannon <edward at unicornschool.org>:

On windows 7 the 1.4 build fails with a an error message that msvcr100.dll is
missing and (unhelpfully) suggests reinstalling the application. Downloading and
installing the microsoft 2010 visual c++ redistributable fixes the problem.
Perhaps a note on the download page or in the documentation would alleviate new
user frustration.

----------
effort: easy
messages: 1861
nosy: ercannon, pypy-issue
priority: bug
release: 1.4
status: unread
title: windows build fails with missing msvcr100.dll error

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue572>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 21:18:51 2010
From: pypy-dev-issue at codespeak.net (Tom Burdick)
Date: Sat, 27 Nov 2010 20:18:51 +0000
Subject: [PyPy-issue] [issue573] get_python_lib unconditionally fails when
	passing standard_lib
Message-ID: <1290889131.9.0.781821510487.issue573@>


New submission from Tom Burdick <thomas.burdick at gmail.com>:

SSL module in pypi fails to install because of the error given in the title.

----------
effort: ???
messages: 1862
nosy: bfrog, pypy-issue
priority: bug
release: 1.4
status: unread
title: get_python_lib unconditionally fails when passing standard_lib

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue573>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 21:27:52 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sat, 27 Nov 2010 20:27:52 +0000
Subject: [PyPy-issue] [issue570] structseq.h for cpyext
Message-ID: <1290889672.54.0.957811222017.issue570@>


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

I cannot find a version of pyev compatible with python2.5.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue570>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 21:30:23 2010
From: pypy-dev-issue at codespeak.net (Tom Burdick)
Date: Sat, 27 Nov 2010 20:30:23 +0000
Subject: [PyPy-issue] [issue570] structseq.h for cpyext
Message-ID: <1290889823.55.0.810331008997.issue570@>


Tom Burdick <thomas.burdick at gmail.com> added the comment:

I was under the impression pypy was moving towards 2.7 anyways?

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue570>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 23:07:16 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sat, 27 Nov 2010 22:07:16 +0000
Subject: [PyPy-issue] [issue572] windows build fails with missing
	msvcr100.dll error
Message-ID: <1290895636.53.0.813895710425.issue572@>


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

Here is the link to the Microsoft Visual C++ 2010 Redistributable Package (5MB)
http://www.microsoft.com/downloads/details.aspx?familyid=A7B7A05E-6DE6-4D3A-A423-37BF0912DB84

Or we should provide binaries compiled with vs8 or vs9, their C runtime library is probably already 
installed on all Windows in the world.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue572>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sat Nov 27 23:43:42 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sat, 27 Nov 2010 22:43:42 +0000
Subject: [PyPy-issue] [issue570] structseq.h for cpyext
Message-ID: <1290897822.17.0.0982153956485.issue570@>


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

Note that the latest version of pyev does not contain calls to structseq.

On the 2.7 branch, compiling pyev-0.5.3-3.8 gives the following missing functions:
PyErr_WriteUnraisable, PyErr_SetFromErrnoWithFilename, PyModule_AddIntMacro.

----------
assignedto:  -> afa
nosy: +afa

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue570>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 00:16:29 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sat, 27 Nov 2010 23:16:29 +0000
Subject: [PyPy-issue] [issue573] get_python_lib unconditionally fails when
	passing standard_lib
Message-ID: <1290899789.44.0.766165694436.issue573@>


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

(See traceback below)
SSL comes with an additional "test" command, which calls python regrtest.
Can you try to edit "setup.py" and remove the usage of testdir?

Traceback (most recent call last):
  File "app_main.py", line 33, in run_toplevel
  File "setup.py", line 169, in <module>
    testdir = os.path.join(get_python_lib(False, True), "test")
  File "/home/amaury/trunk/lib-python/modified-2.5.2/distutils/sysconfig_pypy.py", 
line 43, in get_python_lib
    "calls to get_python_lib(standard_lib=1) cannot succeed")
DistutilsPlatformError: calls to get_python_lib(standard_lib=1) cannot succeed

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue573>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 01:45:39 2010
From: pypy-dev-issue at codespeak.net (Tom Burdick)
Date: Sun, 28 Nov 2010 00:45:39 +0000
Subject: [PyPy-issue] [issue570] structseq.h for cpyext
Message-ID: <1290905139.16.0.826749704585.issue570@>


Tom Burdick <thomas.burdick at gmail.com> added the comment:

It does use structseq.h in svn which is the latest. Please try the svn trunk 
version.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue570>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 01:47:33 2010
From: pypy-dev-issue at codespeak.net (Tom Burdick)
Date: Sun, 28 Nov 2010 00:47:33 +0000
Subject: [PyPy-issue] [issue571] pypy-c needs -E option
Message-ID: <1290905253.68.0.918617305796.issue571@>


Tom Burdick <thomas.burdick at gmail.com> added the comment:

This doesn't seem to be a venusian thing actually, it appears to be something more 
related to easy_install and pip when trying to install a package venusian 
requires, which is nose

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue571>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 01:56:43 2010
From: pypy-dev-issue at codespeak.net (Edward Cannon)
Date: Sun, 28 Nov 2010 00:56:43 +0000
Subject: [PyPy-issue] [issue572] windows build fails with missing
	msvcr100.dll error
In-Reply-To: <-4980562479012174622@unknownmsgid>
Message-ID: <AANLkTi=j-6k1UT7=Bfd6GRkF5jfh_Cy=ZYfrCn9HiiiM@mail.gmail.com>


Edward Cannon <edward at unicornschool.org> added the comment:

I think just mentioning that it might need to be downloaded and
installed might work just as well. Most people could handle that and
it would get rid of the "oh no it doesn't work" response.

On Sat, Nov 27, 2010 at 2:07 PM, Amaury Forgeot d Arc
<pypy-dev-issue at codespeak.net> wrote:
>
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
>
> Here is the link to the Microsoft Visual C++ 2010 Redistributable Package (5MB)
> http://www.microsoft.com/downloads/details.aspx?familyid=A7B7A05E-6DE6-4D3A-A423-37BF0912DB84
>
> Or we should provide binaries compiled with vs8 or vs9, their C runtime library is probably already
> installed on all Windows in the world.
>
> ----------
> status: unread -> chatting
>
> _______________________________________________________
> PyPy development tracker <pypy-dev-issue at codespeak.net>
> <https://codespeak.net/issue/pypy-dev/issue572>
> _______________________________________________________
>

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue572>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 09:51:23 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Sun, 28 Nov 2010 08:51:23 +0000
Subject: [PyPy-issue] [issue574] Support for Python 2.6
Message-ID: <1290934283.03.0.699957528241.issue574@>


New submission from Seung Soo, Ha <sungsuha at gmail.com>:

This is generic item requesting support for the python version 2.6
I thought that it would be a good idea to have an issue tracker item to 
consolidate efforts and information regarding updated python support efforts.

If this version is to be skipped by the developers, 
please close this as 'wont fix'

----------
effort: ???
messages: 1871
nosy: pypy-issue, sungsuha
priority: wish
release: ???
status: unread
title: Support for Python 2.6

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue574>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 09:52:25 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Sun, 28 Nov 2010 08:52:25 +0000
Subject: [PyPy-issue] [issue575] Support for Python 2.7
Message-ID: <1290934345.84.0.392637049718.issue575@>


New submission from Seung Soo, Ha <sungsuha at gmail.com>:

This is generic item requesting support for the python version 2.7
I thought that it would be a good idea to have an issue tracker item to 
consolidate efforts and information regarding updated python support efforts.

If this version is to be skipped by the developers, 
please close this as 'wont fix'

----------
effort: ???
messages: 1872
nosy: pypy-issue, sungsuha
priority: wish
release: ???
status: unread
title: Support for Python 2.7

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue575>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 09:52:53 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Sun, 28 Nov 2010 08:52:53 +0000
Subject: [PyPy-issue] [issue576] Support Python 3.1
Message-ID: <1290934373.98.0.578302251302.issue576@>


New submission from Seung Soo, Ha <sungsuha at gmail.com>:

This is generic item requesting support for the python version 3.1
I thought that it would be a good idea to have an issue tracker item to 
consolidate efforts and information regarding updated python support efforts.

If this version is to be skipped by the developers, 
please close this as 'wont fix'

----------
effort: ???
messages: 1873
nosy: pypy-issue, sungsuha
priority: wish
release: ???
status: unread
title: Support Python 3.1

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue576>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 09:57:49 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Sun, 28 Nov 2010 08:57:49 +0000
Subject: [PyPy-issue] [issue572] windows build fails with missing
	msvcr100.dll error
Message-ID: <1290934669.1.0.15461794314.issue572@>


Seung Soo, Ha <sungsuha at gmail.com> added the comment:

I agree with ercannon.

>Or we should provide binaries compiled with vs8 or vs9, their C runtime library 
>is probably already installed on all Windows in the world.

Compiling with vs8 or vs9 might improve this issue, but it won't go away 
completely. There are some systems that do not have the runtimes, and it is not 
uncommon for me to have to install those runtimes on systems that I do not own.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue572>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 10:00:51 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Sun, 28 Nov 2010 09:00:51 +0000
Subject: [PyPy-issue] [issue565] There is no 1.4 release on the issue tracker
Message-ID: <1290934851.96.0.271280016312.issue565@>


Seung Soo, Ha <sungsuha at gmail.com> added the comment:

may be this has changed since santagada has used the issue tracker, but I see 
releases, 1.2 and 1.4 too.

The order seems strange to me though, (1.4,1.1,1.2 in that order)
However, I think that this particular issue can be changed to 'resolved'.

As I am new here, I will refrain from doing so without any input.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue565>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 10:31:05 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sun, 28 Nov 2010 09:31:05 +0000
Subject: [PyPy-issue] [issue574] Support for Python 2.6
Message-ID: <1290936665.66.0.134574706473.issue574@>


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

2.6 is skipped, fast-forward is targetting 2.7 branch

----------
status: unread -> wontfix

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue574>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 10:47:20 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Sun, 28 Nov 2010 09:47:20 +0000
Subject: [PyPy-issue] [issue576] Support for Python 3.1
Message-ID: <1290937640.7.0.99087718723.issue576@>


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

I think this version is going to be skipped. Reasoning: we're moving to 2.7 at 
some point soon and only then will start thinking about 3.x. At this time 3.2 
should be out and we would more likely target next Python release (like 3.3) to 
sync. Closing

----------
status: unread -> wontfix

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue576>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 11:38:26 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sun, 28 Nov 2010 10:38:26 +0000
Subject: [PyPy-issue] [issue575] Support for Python 2.7
Message-ID: <1290940706.3.0.120685572816.issue575@>


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

The "fast-forward" branch is our current effort towards 2.7.

Most of the features are there (and your 2.7 application may already work) but 
there are tons of details to fix. Please join on #pypy to help us!

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue575>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 11:47:56 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sun, 28 Nov 2010 10:47:56 +0000
Subject: [PyPy-issue] [issue571] pypy-c needs -E option
Message-ID: <1290941276.78.0.274423514495.issue571@>


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

The "fast-forward" branch already has support for -E

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue571>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 11:56:14 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sun, 28 Nov 2010 10:56:14 +0000
Subject: [PyPy-issue] [issue570] structseq.h for cpyext
Message-ID: <1290941774.7.0.726898455422.issue570@>


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

OK. but since pyev-trunk won't work with python2.5, I'm removing the "1.4" tag.

----------
release: 1.4 -> 

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue570>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 12:23:12 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sun, 28 Nov 2010 11:23:12 +0000
Subject: [PyPy-issue] [issue572] windows build fails with missing
	msvcr100.dll error
Message-ID: <1290943392.24.0.374215911408.issue572@>


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

r79603, r79604: Added the link to vs2010 libraries.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue572>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Sun Nov 28 20:56:31 2010
From: pypy-dev-issue at codespeak.net (David Naylor)
Date: Sun, 28 Nov 2010 19:56:31 +0000
Subject: [PyPy-issue] [issue551] Support for freebsd8+
Message-ID: <1290974191.36.0.453821918262.issue551@>


David Naylor <naylor.b.david at gmail.com> added the comment:

I've updated the patch for pypy-1.4.  There are four errors in the checks:
 - expat.h is not found [ctypes check 1]
 - undefined reference to mremap [check 7]
 - getpgrp (to many arguments) [check 17]
 - valgrind/valgrind.h is not found [check 39]

The change to check for x86_64 is not portable (FreeBSD defines x86_64 as amd64) 
otherwise everything else should not interfere with other platforms.  

Apply the patch with:
# cd /path/to/pypy-1.4
# patch -Esp0 < /path/to/patch-pypy3.diff

I've translated pypy under FreeBSD9/amd64 with success:
# python translate.py -Ojit
[translation:info] created: /tmp/pypy-1.4/pypy/translator/goal/pypy-c
[Timer] Timings:
[Timer] annotate                       --- 1485.5 s
[Timer] rtype_lltype                   ---  822.5 s
[Timer] pyjitpl_lltype                 --- 1691.1 s
[Timer] backendopt_lltype              ---  822.3 s
[Timer] stackcheckinsertion_lltype     ---  113.0 s
[Timer] database_c                     ---  902.2 s
[Timer] source_c                       --- 1715.7 s
[Timer] compile_c                      --- 1069.6 s
[Timer] ===========================================
[Timer] Total:                         --- 8621.9 s

and used the resulting pypy to translate itself (again with success):
# ./pypy-c~ translate.py -Ojit
[translation:info] created: /tmp/pypy-1.4/pypy/translator/goal/pypy-c
[Timer] Timings:
[Timer] annotate                       ---  858.2 s
[Timer] rtype_lltype                   ---  603.4 s
[Timer] pyjitpl_lltype                 ---  613.3 s
[Timer] backendopt_lltype              ---  258.0 s
[Timer] stackcheckinsertion_lltype     ---   36.7 s
[Timer] database_c                     ---  359.1 s
[Timer] source_c                       ---  444.4 s
[Timer] compile_c                      --- 1405.6 s
[Timer] ===========================================
[Timer] Total:                         --- 4578.7 s

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue551>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-pypy3.diff
Type: text/x-patch
Size: 8480 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101128/43c81667/attachment.bin>

From pypy-dev-issue at codespeak.net  Mon Nov 29 08:48:18 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Mon, 29 Nov 2010 07:48:18 +0000
Subject: [PyPy-issue] [issue570] structseq.h for cpyext
Message-ID: <1291016898.67.0.00606371990605.issue570@>


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

Done with r79614.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue570>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Nov 29 12:23:06 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Mon, 29 Nov 2010 11:23:06 +0000
Subject: [PyPy-issue] [issue551] Support for freebsd8+
Message-ID: <1291029786.15.0.89859105426.issue551@>


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

the patch has been applied to the freebsd-compat branch, which has been merged
into trunk.

Additionally, I have modified the cpu autodetection routine so that it should
return 'x86_64' also on freebsd. However, I did not have any machine where to
check it, could you please confirm that it works so we can close the issue?

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue551>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Nov 29 12:59:25 2010
From: pypy-dev-issue at codespeak.net (Holger Krekel)
Date: Mon, 29 Nov 2010 11:59:25 +0000
Subject: [PyPy-issue] [issue577] pypy fails to be a virtualenv ouroboros
Message-ID: <1291031965.44.0.355526589382.issue577@>


New submission from Holger Krekel <holger at merlinux.eu>:

creating a virtualenv with pypy-1.4 works.  Creating a virtualenv with a
virtualenv-pypy does not work (but this self-recursion works with CPython). See
this session: http://paste.pocoo.org/show/297519/

----------
effort: ???
messages: 1885
nosy: hpk, pypy-issue
priority: bug
release: 1.4
status: unread
title: pypy fails to be a virtualenv ouroboros

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue577>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Nov 29 13:44:24 2010
From: pypy-dev-issue at codespeak.net (Simon Cross)
Date: Mon, 29 Nov 2010 12:44:24 +0000
Subject: [PyPy-issue] [issue578] expat parser incorrectly decodes data from
	expat C library
Message-ID: <1291034664.96.0.505324328763.issue578@>


New submission from Simon Cross <hodgestar at gmail.com>:

The expat parser incorrectly decodes character data passed to event handlers
using self.encoding when this data is always encoded as UTF-8.

See http://www.xml.com/pub/a/1999/09/expat/index.html: "... although expat may
accept input in various encodings, the strings that it passes to the handlers
are always encoded in UTF-8."

----------
effort: easy
files: expat-test-and-fix-r79617.diff
messages: 1886
nosy: hodgestar, pypy-issue
priority: bug
release: 1.4
status: unread
title: expat parser incorrectly decodes data from expat C library

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue578>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expat-test-and-fix-r79617.diff
Type: text/x-diff
Size: 1513 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101129/b1709abc/attachment.diff>

From pypy-dev-issue at codespeak.net  Mon Nov 29 13:55:26 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Mon, 29 Nov 2010 12:55:26 +0000
Subject: [PyPy-issue] [issue578] expat parser incorrectly decodes data from
	expat C library
Message-ID: <1291035326.06.0.718475779926.issue578@>


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

A similar fix is already present in branch/fast-forward.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue578>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Nov 29 14:17:50 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 29 Nov 2010 13:17:50 +0000
Subject: [PyPy-issue] [issue578] expat parser incorrectly decodes data from
	expat C library
Message-ID: <1291036670.1.0.866500312511.issue578@>


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

Closing, commited

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue578>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Nov 29 19:20:52 2010
From: pypy-dev-issue at codespeak.net (David Naylor)
Date: Mon, 29 Nov 2010 18:20:52 +0000
Subject: [PyPy-issue] [issue551] Support for freebsd8+
Message-ID: <1291054852.49.0.0540417261891.issue551@>


David Naylor <naylor.b.david at gmail.com> added the comment:

It looks like the last part of the patch did not apply.  The required mode is 
attached (and pypy/translator/platform/freebsd7.py can be removed).

Using the attached freebsd.py in .pypy/translator/platform/ the configuration 
phase passes.  Due to the long compilation time on my system I didn't check a 
full translate.  

# svn co http://codespeak.net/svn/pypy/trunk pypy-trunk
# cd pypy-trunk/pypy/translator/goal
# python translate.py -Ojit
[translation:info] Translating target as defined by targetpypystandalone
Traceback (most recent call last):
  File "translate.py", line 304, in <module>
    main()
  File "translate.py", line 209, in main
    targetspec_dic, translateconfig, config, args = 
parse_options_and_load_target()
  File "translate.py", line 169, in parse_options_and_load_target
    set_platform(config)
  File "/tmp/pypy-trunk/pypy/config/translationoption.py", line 395, in 
set_platform
    from pypy.translator.platform import set_platform
  File "/tmp/pypy-trunk/pypy/translator/platform/__init__.py", line 221, in 
<module>
    from pypy.translator.platform.freebsd import Freebsd, Freebsd_64
ImportError: No module named freebsdtranslation:info] Translating target as 
defined by targetpypystandalone
Traceback (most recent call last):
  File "translate.py", line 304, in <module>
    main()
  File "translate.py", line 209, in main
    targetspec_dic, translateconfig, config, args = 
parse_options_and_load_target()
  File "translate.py", line 169, in parse_options_and_load_target
    set_platform(config)
  File "/tmp/pypy-trunk/pypy/config/translationoption.py", line 395, in 
set_platform
    from pypy.translator.platform import set_platform
  File "/tmp/pypy-trunk/pypy/translator/platform/__init__.py", line 221, in 
<module>
    from pypy.translator.platform.freebsd import Freebsd, Freebsd_64
ImportError: No module named freebsd

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue551>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freebsd.py
Type: text/x-python
Size: 1523 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101129/60e26163/attachment.py>

From pypy-dev-issue at codespeak.net  Mon Nov 29 19:21:51 2010
From: pypy-dev-issue at codespeak.net (David Naylor)
Date: Mon, 29 Nov 2010 18:21:51 +0000
Subject: [PyPy-issue] [issue551] Support for freebsd8+
Message-ID: <1291054911.69.0.481152629635.issue551@>


David Naylor <naylor.b.david at gmail.com> added the comment:

It looks like the last part of the patch did not apply.  The required mode is 
attached (and pypy/translator/platform/freebsd7.py can be removed).

Using the attached freebsd.py in .pypy/translator/platform/ the configuration 
phase passes.  Due to the long compilation time on my system I didn't check a 
full translate.  

# svn co http://codespeak.net/svn/pypy/trunk pypy-trunk
# cd pypy-trunk/pypy/translator/goal
# python translate.py -Ojit
[translation:info] Translating target as defined by targetpypystandalone
Traceback (most recent call last):
  File "translate.py", line 304, in <module>
    main()
  File "translate.py", line 209, in main
    targetspec_dic, translateconfig, config, args = 
parse_options_and_load_target()
  File "translate.py", line 169, in parse_options_and_load_target
    set_platform(config)
  File "/tmp/pypy-trunk/pypy/config/translationoption.py", line 395, in 
set_platform
    from pypy.translator.platform import set_platform
  File "/tmp/pypy-trunk/pypy/translator/platform/__init__.py", line 221, in 
<module>
    from pypy.translator.platform.freebsd import Freebsd, Freebsd_64
ImportError: No module named freebsd

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue551>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Mon Nov 29 23:25:00 2010
From: pypy-dev-issue at codespeak.net (Thomas Waldmann)
Date: Mon, 29 Nov 2010 22:25:00 +0000
Subject: [PyPy-issue] [issue579] werkzeug securecookie / hmac crashes
Message-ID: <1291069500.32.0.3863952925.issue579@>


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

File "/home/tw/w/mm20dev/MoinMoin/support/flask/app.py", line 430, in open_session
    secret_key=key)
  File "/home/tw/w/mm20dev/MoinMoin/support/werkzeug/contrib/securecookie.py",
line 308, in load_cookie
    return cls.unserialize(data, secret_key)
  File "/home/tw/w/mm20dev/MoinMoin/support/werkzeug/contrib/securecookie.py",
line 255, in unserialize
    mac = hmac(secret_key, None, cls.hash_method)
  File "/home/tw/w/pypy-1.4/lib-python/2.5.2/hmac.py", line 121, in new
    return HMAC(key, msg, digestmod)
  File "/home/tw/w/pypy-1.4/lib-python/2.5.2/hmac.py", line 48, in __init__
    self.outer = self.digest_cons()
TypeError: unbound method openssl_sha1() must be called with Session instance as
first argument (got nothing instead)

got this when trying to run moin/2.0-dev with pypy 1.4, but looks generic.

----------
effort: ???
messages: 1891
nosy: ThomasWaldmann, pypy-issue
priority: bug
release: 1.4
status: unread
title: werkzeug securecookie / hmac crashes

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue579>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 00:33:33 2010
From: pypy-dev-issue at codespeak.net (Hybride)
Date: Mon, 29 Nov 2010 23:33:33 +0000
Subject: [PyPy-issue] [issue580] Broken pipe error during sandbox
	installation?
Message-ID: <1291073613.25.0.571907443112.issue580@>


New submission from Hybride <hybridephantom at hotmail.com>:

pypy at python:~/pypy-1.4/pypy/translator/goal$ Traceback (most recent call last):
  File "/home/python/pypy-1.4/pypy/tool/runsubprocess.py", line 43, in <module>
    sys.stdout.flush()
IOError: [Errno 32] Broken pipe

Am very limited in my Python programming, so not sure how to fix this. Any help
appreciated. This happens during a sandbox installation on a Ubuntu 8 VM, 1.5gb RAM.

----------
effort: ???
messages: 1892
nosy: hybride, pypy-issue
priority: bug
release: 1.4
status: unread
title: Broken pipe error during sandbox installation?

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue580>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 08:23:27 2010
From: pypy-dev-issue at codespeak.net (Malthe Borch)
Date: Tue, 30 Nov 2010 07:23:27 +0000
Subject: [PyPy-issue] [issue581] Virtualenv install throws "OverflowError:
	expected a 32-bit integer"
Message-ID: <1291101807.31.0.758917291711.issue581@>


New submission from Malthe Borch <mborch at gmail.com>:

This happens on a current trunk checkout: http://pastie.org/1334591.

----------
effort: ???
messages: 1893
nosy: malthe, pypy-issue
priority: bug
release: ???
status: unread
title: Virtualenv install throws "OverflowError: expected a 32-bit integer"

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue581>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 08:28:19 2010
From: pypy-dev-issue at codespeak.net (Malthe Borch)
Date: Tue, 30 Nov 2010 07:28:19 +0000
Subject: [PyPy-issue] [issue581] Virtualenv install throws "OverflowError:
	expected a 32-bit integer"
Message-ID: <1291102099.39.0.210482776708.issue581@>


Malthe Borch <mborch at gmail.com> added the comment:

64-bit linux.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue581>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 08:49:58 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Tue, 30 Nov 2010 07:49:58 +0000
Subject: [PyPy-issue] [issue551] Support for freebsd8+
Message-ID: <1291103398.84.0.821083110835.issue551@>


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

sorry, the patch did apply but I forgot to svn add the file :-)
It's in trunk now, could you please check that everything is fine?

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue551>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 10:14:24 2010
From: pypy-dev-issue at codespeak.net (Malthe Borch)
Date: Tue, 30 Nov 2010 09:14:24 +0000
Subject: [PyPy-issue] [issue582] unrecognized option '-E'
Message-ID: <1291108464.71.0.44607289255.issue582@>


New submission from Malthe Borch <mborch at gmail.com>:

mborch at wavel> ../pypy-env/bin/python setup.py test
running test
install_dir .
Checking .pth file support in .
/home/mborch/co/pypy-env/bin/python -E -c pass
unrecognized option '-E'
usage: /home/mborch/co/pypy-env/bin/python [options]
Try `/home/mborch/co/pypy-env/bin/python -h` for more information.
error: command '/home/mborch/co/pypy-env/bin/python' failed with exit status 2

----------
effort: easy
messages: 1896
nosy: malthe, pypy-issue
priority: feature
release: 1.4
status: unread
title: unrecognized option '-E'

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue582>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 11:27:23 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 10:27:23 +0000
Subject: [PyPy-issue] [issue582] unrecognized option '-E'
Message-ID: <1291112843.34.0.661855550273.issue582@>


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

Thanks!  Fixed in trunk.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue582>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 11:30:44 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 10:30:44 +0000
Subject: [PyPy-issue] [issue581] Virtualenv install throws "OverflowError:
	expected a 32-bit integer"
Message-ID: <1291113044.64.0.295526475056.issue581@>


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

I rewrote binascii two days ago, and yesterday I fixed that particular issue
showing up on 64-bit platforms.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue581>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 11:32:17 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 10:32:17 +0000
Subject: [PyPy-issue] [issue575] Support for Python 2.7
Message-ID: <1291113137.24.0.58040603875.issue575@>


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

See also:

    http://codespeak.net/svn/pypy/branch/fast-forward/lib-python/TODO

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue575>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 11:32:57 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 10:32:57 +0000
Subject: [PyPy-issue] [issue571] pypy-c needs -E option
Message-ID: <1291113177.62.0.312000854518.issue571@>


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

Fixed in trunk.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue571>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 11:35:44 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 10:35:44 +0000
Subject: [PyPy-issue] [issue564] Translation fails without ncurses with a
	py.test.skip exception
Message-ID: <1291113344.38.0.221560153749.issue564@>


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

This is a known issue.  Many modules in pypy/module/ won't compile if the host
Python doesn't also provide them.  I don't think we are anywhere close to
resolving all these, so I'm closing this report as "won't fix".  You can always
use "--withoutmod-_minimal_curses" to disable it during translation.

----------
status: unread -> wontfix

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue564>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 12:19:22 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Tue, 30 Nov 2010 11:19:22 +0000
Subject: [PyPy-issue] [issue575] Support for Python 2.7
Message-ID: <1291115962.0.0.23109185098.issue575@>


Seung Soo, Ha <sungsuha at gmail.com> added the comment:

'- some set() methods now accept a variable number of arguments  DONE'
Why is this DONE item in the TODO list? does this mean that the item needs testing?

Are these efforts limited to the x86_32 branch or do they affect x86_64 too?

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue575>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 12:37:08 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 11:37:08 +0000
Subject: [PyPy-issue] [issue579] werkzeug securecookie / hmac crashes
Message-ID: <1291117028.95.0.450188240909.issue579@>


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

Ah, it's an example of people using functions from extension modules and
assuming that they are built-in functions.  The difference shows up when storing
them as class attributes, e.g.:

    class A(object):
        mylen = len
    print A().mylen([2,3,4])

This example works both in PyPy and CPython because len is a built-in function;
however it would not work if we first said:

    _len = len
    def len(lst):
        return _len(lst)

It will be fixed I suppose.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue579>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 12:40:14 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 11:40:14 +0000
Subject: [PyPy-issue] [issue575] Support for Python 2.7
Message-ID: <1291117214.83.0.721131183947.issue575@>


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

DONE means it's done.  It's a style we got from sprints.  I can remove them too.

These efforts are independent on the translation target.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue575>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 13:35:30 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 30 Nov 2010 12:35:30 +0000
Subject: [PyPy-issue] [issue579] werkzeug securecookie / hmac crashes
Message-ID: <1291120530.37.0.245677441065.issue579@>


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

Fixed for the 'hashlib.algo' functions.  I will make a round of the lib_pypy
modules to see if there are obvious other places where it could be useful.

Note as a reminder from Amaury: some code is also confused by doing e.g. "if
type(obj).__repr__ is dict.__repr__", which does not work on PyPy, simply
because it would not work on Python either if "dict" was a user-defined class.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue579>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Tue Nov 30 13:37:21 2010
From: pypy-dev-issue at codespeak.net (David Naylor)
Date: Tue, 30 Nov 2010 12:37:21 +0000
Subject: [PyPy-issue] [issue551] Support for freebsd8+
Message-ID: <1291120641.57.0.467776347595.issue551@>


David Naylor <naylor.b.david at gmail.com> added the comment:

Translating pypy worked however using pypy to translate itself did not.  I'm not 
sure if this is a FreeBSD specific problem.  

# svn co http://codespeak.net/svn/pypy/trunk pypy-trunk
# cd pypy-trunk/pypy/translator/goal
# python translate.py -Ojit
[translation:info] created: /home/DragonSA/projects/pypy-
trunk/pypy/translator/goal/pypy-c                                                                                      
[Timer] Timings:
[Timer] annotate                       --- 1529.6 s
[Timer] rtype_lltype                   ---  833.1 s
[Timer] pyjitpl_lltype                 --- 1692.4 s
[Timer] backendopt_lltype              ---  811.9 s
[Timer] stackcheckinsertion_lltype     ---  102.7 s
[Timer] database_c                     ---  899.2 s
[Timer] source_c                       --- 1735.6 s
[Timer] compile_c                      --- 1126.9 s
[Timer] ===========================================
[Timer] Total:                         --- 8731.3 s

# ./pypy-c-jit translate.py -Ojit
...cannot find gc roots!
(Core dump)
# gdb pypy-c-jit pypy-c-jit.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `pypy-c-jit'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /usr/lib/libssl.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssl.so.6
Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libexpat.so.6
Reading symbols from /usr/lib/libbz2.so.4...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libbz2.so.4
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done.
Loaded symbols for /lib/libutil.so.9
Reading symbols from /usr/local/lib/libffi.so.5...done.
Loaded symbols for /usr/local/lib/libffi.so.5
Reading symbols from /lib/libncurses.so.8...done.
Loaded symbols for /lib/libncurses.so.8
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /tmp/usession-trunk-0/module_cache/externmod.so...done.
Loaded symbols for /tmp/usession-trunk-0/module_cache/externmod.so
Reading symbols from /tmp/usession-trunk-0/module_cache/externmod_0.so...done.
Loaded symbols for /tmp/usession-trunk-0/module_cache/externmod_0.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000801f0f1fc in thr_kill () from /lib/libc.so.7
[New Thread 802407300 (LWP 100401)]
(gdb) bt
#0  0x0000000801f0f1fc in thr_kill () from /lib/libc.so.7
#1  0x0000000801fa6883 in abort () from /lib/libc.so.7
#2  0x00000000006bbdd0 in pypy_g_locate_caller_based_on_retaddr ()
#3  0x0000000000656086 in pypy_g_walk_to_parent_frame ()
#4  0x00000000005d4cbd in pypy_g_walk_stack_from ()
#5  0x000000000052bd29 in pypy_g__asm_callback ()
#6  0x0000000000dbc22c in pypy_asm_stackwalk ()
#7  0x0000000000fd7480 in pypy_g_exceptions_SystemError ()
#8  0x0000000000fd7480 in pypy_g_exceptions_SystemError ()
#9  0x0000000000f99fc0 in pypy_g_exceptions_NotImplementedError ()
#10 0x0000000001069ba0 in pypy_g_rpy_string_330 ()
#11 0x000000084a75cec8 in ?? ()
#16 0x00000000004b931a in pypy_g_MiniMarkGC_minor_collection ()
#17 0x00000000004b99d1 in pypy_g_MiniMarkGC_collect_and_reserve ()
#18 0x00000000005c89c2 in pypy_g_default_identity_hash ()
#19 0x00000000004ffe9c in pypy_g_BuiltinCode1_fastcall_1 ()
#20 0x00000000004c7c30 in pypy_g_funccall__star_1 ()
#21 0x000000000050837b in pypy_g_get_and_call_function__star_0 ()
#22 0x0000000000508607 in pypy_g_hash ()
#23 0x0000000000508f9b in 
pypy_g_ll_dict_setitem__dicttablePtr_pypy_interpreter_b ()
#24 0x00000000007b21a1 in pypy_g_update1 ()
#25 0x00000008164a625d in ?? ()
#26 0x0000000000fd9980 in pypy_g_exceptions_AssertionError_2 ()
#27 0x0000000000fd9980 in pypy_g_exceptions_AssertionError_2 ()
#28 0x0000000001069ba0 in pypy_g_rpy_string_330 ()
#29 0x000000084a75ccd0 in ?? ()
#30 0x0000000001069ba0 in pypy_g_rpy_string_330 ()
#31 0x00000000004fe63e in pypy_g_MiniMarkGC_identityhash ()
#32 0x00000000005c896e in pypy_g_default_identity_hash ()
#33 0x000000084a75ccd0 in ?? ()
#37 0x0000000000f9ac88 in pypy_g_typeinfo ()
#38 0x00000008025758d0 in ?? ()
#53 0x0000000000fda9c0 in 
_hash_pypy_g_pypy_objspace_std_typeobject_W_TypeObject_16 ()
#54 0x000000084a755168 in ?? ()
#95 0x0000000001088f80 in pypy_g_array_1040 ()
#96 0x0000000802561a48 in ?? ()
#99 0x00000000006bc0b2 in pypy_g_DoneWithThisFrameDescrRef_handle_fail ()
#100 0x000000000076a29a in pypy_g_maybe_compile_and_run__star_4 ()
#101 0x000000000081fafb in pypy_g_jump_absolute__AccessDirect_None ()
#102 0x000000000040dca9 in RPyThreadGetIdent ()
#103 0x00000000004d755b in pypy_g_getexecutioncontext ()
#104 0x0000000823030012 in ?? ()
#112 0x00000000011ef4c0 in pypy_g_array_5093 ()
#113 0x00000008025bb9a0 in ?? ()
#116 0x00000000011ef4c0 in pypy_g_array_5093 ()
#117 0x00000008025bb9a0 in ?? ()
#121 0x00000000011ef4c0 in pypy_g_array_5093 ()
#122 0x00000008025bb9a0 in ?? ()
#132 0x00000000011ef4c0 in pypy_g_array_5093 ()
#133 0x00000008025bb9a0 in ?? ()
#134 0x00000000011ef4c0 in pypy_g_array_5093 ()
#135 0x00000008025bb9a0 in ?? ()
#158 0x0000000000fda9c0 in 
_hash_pypy_g_pypy_objspace_std_typeobject_W_TypeObject_16 ()
#159 0x000000084a74ead8 in ?? ()
#249 0x0000000001130220 in pypy_g_rpy_string_3691 ()
#250 0x0000000802561638 in ?? ()
#254 0x0000000000fd8c50 in 
_hash_pypy_g_pypy_objspace_std_boolobject_W_BoolObject ()
#255 0x00000008025614b0 in ?? ()
#316 0x000000000076a1e2 in pypy_g_maybe_compile_and_run__star_4 ()
#317 0x000000000081fa72 in pypy_g_jump_absolute__AccessDirect_None ()
#318 0x00000000007a9747 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#319 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#320 0x00000000006ba2ef in pypy_g_portal_1 ()
#321 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#322 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#323 0x000000000050ce38 in pypy_g_PyFrame_run ()
#324 0x0000000000890b21 in pypy_g_call_valuestack__AccessDirect_None ()
#325 0x00000000008159f1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
#326 0x00000000007a9f5b in pypy_g_dispatch_bytecode__AccessDirect_None ()
#327 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#328 0x00000000006ba2ef in pypy_g_portal_1 ()
#329 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#330 0x00000008230e2edc in ?? ()
#335 0x0000000000fd8c30 in pypy_g_pypy_objspace_std_typeobject_W_TypeObject_7 ()
#336 0x000000080da98d40 in ?? ()
#362 0x0000000000fd8c30 in pypy_g_pypy_objspace_std_typeobject_W_TypeObject_7 ()
#363 0x0000000000000000 in ?? ()
#368 0x000000000051d487 in pypy_g_MiniMarkGC_id_or_identityhash ()
#369 0x000000080da98d40 in ?? ()
#380 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#381 0x000000081f35cdb0 in ?? ()
#383 0x0000000000fd8c30 in pypy_g_pypy_objspace_std_typeobject_W_TypeObject_7 ()
#384 0x0000000804075220 in ?? ()
#387 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#388 0x000000000002a66f in ?? ()
#389 0x0000000001061fc0 in pypy_g_tuple2_247 ()
#390 0x0000000802598070 in ?? ()
#391 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#392 0x000000081f35cdb0 in ?? ()
#393 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#394 0x00007fffffff97b0 in ?? ()
#401 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#402 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#403 0x0000000000000000 in ?? ()
#439 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#440 0x0000000000000000 in ?? ()
#452 0x0000000000fd8c30 in pypy_g_pypy_objspace_std_typeobject_W_TypeObject_7 ()
#453 0x0000000000fd8c50 in 
_hash_pypy_g_pypy_objspace_std_boolobject_W_BoolObject ()
#454 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#455 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#456 0x0000000847a847b0 in ?? ()
#469 0x0000000000fd8c50 in 
_hash_pypy_g_pypy_objspace_std_boolobject_W_BoolObject ()
#470 0x00007fffffff99e0 in ?? ()
#486 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#487 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#488 0x0000000000fd8c50 in 
_hash_pypy_g_pypy_objspace_std_boolobject_W_BoolObject ()
#489 0x0000000000fd8c30 in pypy_g_pypy_objspace_std_typeobject_W_TypeObject_7 ()
#490 0x0000000001007ec0 in pypy_g_rpy_string_152 ()
#491 0x0000000819dafa98 in ?? ()
#505 0x0000000000fd8c30 in pypy_g_pypy_objspace_std_typeobject_W_TypeObject_7 ()
#506 0x00000008025749f8 in ?? ()
##554 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#555 0x0000000000000000 in ?? ()
#709 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#710 0x000000084a76fb08 in ?? ()
#727 0x000000000076a1e2 in pypy_g_maybe_compile_and_run__star_4 ()
#728 0x000000000081fa72 in pypy_g_jump_absolute__AccessDirect_None ()
#729 0x00000000007a9747 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#730 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#731 0x00000000006ba2ef in pypy_g_portal_1 ()
#732 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#733 0x0000000817098b1b in ?? ()
#750 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#751 0x0000000000000000 in ?? ()
#770 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#771 0x0000000000000000 in ?? ()
#825 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#826 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#827 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#828 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#829 0x00000008024f5bb0 in ?? ()
#843 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#844 0x00000008035e59d0 in ?? ()
#845 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#846 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#847 0x00000008024fc3d8 in ?? ()
#849 0x0000000000fdf010 in pypy_g_exceptions_AssertionError_21 ()
#850 0x00000008024fc528 in ?? ()
#896 0x0000000000f9ac88 in pypy_g_typeinfo ()
#897 0x000000081dab73d0 in ?? ()
#900 0x0000000000fddb40 in 
pypy_g_pypy_interpreter_function_FunctionWithFixedCode_3 ()
#901 0x0000000818211558 in ?? ()
#938 0x0000000000f9ac88 in pypy_g_typeinfo ()
#939 0x000000000050837b in pypy_g_get_and_call_function__star_0 ()
#940 0x0000000811daddf8 in ?? ()
#942 0x00000000005703c9 in pypy_g_W_TypeObject__lookup_where_all_typeobjects ()
#943 0x00000000004f770b in 
pypy_g_W_TypeObject__pure_lookup_where_with_method_cach ()
#944 0x00000008021ec2e2 in ?? ()
#945 0x0000000001069ba0 in pypy_g_rpy_string_330 ()
#946 0x000000084792c560 in ?? ()
#947 0x0000000001069ba0 in pypy_g_rpy_string_330 ()
#948 0x00000000004fe63e in pypy_g_MiniMarkGC_identityhash ()
#949 0x00000000005c896e in pypy_g_default_identity_hash ()
#950 0x000000081067c440 in ?? ()
#1232 0x0000000000000001 in ?? ()
#1233 0x00000000011e8020 in pypy_g_pypy_interpreter_argument_Signature_780 ()
#1234 0x0000000000000000 in ?? ()
#1278 0x000000000076a1e2 in pypy_g_maybe_compile_and_run__star_4 ()
#1279 0x000000000081fa72 in pypy_g_jump_absolute__AccessDirect_None ()
#1280 0x00000000007a9747 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1281 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1282 0x00000000006ba2ef in pypy_g_portal_1 ()
#1283 0x00000000006549d3 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1284 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1285 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1286 0x0000000000890b21 in pypy_g_call_valuestack__AccessDirect_None ()
#1287 0x00000000008159f1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
#1288 0x00000000007a9f5b in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1289 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1290 0x00000000006ba2ef in pypy_g_portal_1 ()
#1291 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1292 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1293 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1294 0x00000000004c4042 in pypy_g_call_args ()
#1295 0x0000000000815d95 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
#1296 0x00000000007a9f5b in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1297 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1298 0x00000000006ba315 in pypy_g_portal_1 ()
#1299 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1300 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1301 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1302 0x0000000000890b21 in pypy_g_call_valuestack__AccessDirect_None ()
#1303 0x00000000008159f1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
#1304 0x00000000007a9f5b in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1305 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1306 0x00000000006ba315 in pypy_g_portal_1 ()
#1307 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1308 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1309 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1310 0x0000000000890b21 in pypy_g_call_valuestack__AccessDirect_None ()
#1311 0x000000000081c3ae in pypy_g_CALL_FUNCTION__AccessDirect_None ()
#1312 0x00000000007a9330 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1313 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1314 0x00000000006ba2ef in pypy_g_portal_1 ()
#1315 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1316 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1317 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1318 0x0000000000500a50 in pypy_g_Method_call_args ()
#1319 0x00000000004c416d in pypy_g_call_args ()
#1320 0x000000000081c244 in pypy_g_call_function__AccessDirect_None ()
#1321 0x00000000007a9269 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1322 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1323 0x00000000006ba315 in pypy_g_portal_1 ()
#1324 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1325 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1326 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1327 0x00000000004c4042 in pypy_g_call_args ()
#1328 0x0000000000815d95 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
#1329 0x00000000007a9f5b in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1330 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1331 0x00000000006ba2ef in pypy_g_portal_1 ()
#1332 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1333 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1334 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1335 0x0000000000890b21 in pypy_g_call_valuestack__AccessDirect_None ()
#1336 0x00000000008159f1 in pypy_g_CALL_METHOD__AccessDirect_star_1 ()
#1337 0x00000000007a9f5b in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1338 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1339 0x00000000006ba2ef in pypy_g_portal_1 ()
#1340 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1341 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1342 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1343 0x0000000000890b21 in pypy_g_call_valuestack__AccessDirect_None ()
#1344 0x000000000081c3ae in pypy_g_CALL_FUNCTION__AccessDirect_None ()
#1345 0x00000000007a9330 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1346 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1347 0x00000000006ba2ef in pypy_g_portal_1 ()
#1348 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1349 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1350 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1351 0x0000000000819c85 in pypy_g_EXEC_STMT__AccessDirect_None ()
#1352 0x00000000007aa07e in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1353 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1354 0x00000000006ba315 in pypy_g_portal_1 ()
#1355 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1356 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1357 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1358 0x00000000004c4042 in pypy_g_call_args ()
#1359 0x000000000081c244 in pypy_g_call_function__AccessDirect_None ()
#1360 0x00000000007a9269 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1361 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1362 0x00000000006ba2ef in pypy_g_portal_1 ()
#1363 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1364 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1365 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1366 0x0000000000890b21 in pypy_g_call_valuestack__AccessDirect_None ()
#1367 0x000000000081c3ae in pypy_g_CALL_FUNCTION__AccessDirect_None ()
#1368 0x00000000007a9330 in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1369 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1370 0x00000000006ba2ef in pypy_g_portal_1 ()
#1371 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1372 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1373 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1374 0x00000000004c4042 in pypy_g_call_args ()
#1375 0x000000000081c244 in pypy_g_call_function__AccessDirect_None ()
#1376 0x00000000007a91fd in pypy_g_dispatch_bytecode__AccessDirect_None ()
#1377 0x0000000000769a3b in pypy_g_handle_bytecode__AccessDirect_None ()
#1378 0x00000000006ba2ef in pypy_g_portal_1 ()
#1379 0x0000000000654bb1 in 
pypy_g_ll_portal_runner__Unsigned_pypy_interpreter_pyco ()
#1380 0x000000000052962c in pypy_g_PyFrame_execute_frame ()
#1381 0x000000000050ce38 in pypy_g_PyFrame_run ()
#1382 0x00000000004c65e5 in pypy_g_funccall__star_3 ()
#1383 0x0000000000466674 in pypy_g_call_function__star_3 ()
#1384 0x0000000000437a3c in pypy_g_entry_point ()
#1385 0x000000000040dfa1 in main ()

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue551>
_______________________________________________________