From pypy-dev-issue at codespeak.net  Wed Dec  1 10:14:31 2010
From: pypy-dev-issue at codespeak.net (Dirkjan Ochtman)
Date: Wed, 01 Dec 2010 09:14:31 +0000
Subject: [PyPy-issue] [issue564] Translation fails without ncurses with a
	py.test.skip exception
Message-ID: <1291194871.39.0.763430656078.issue564@>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

(other account doesn't seem to work)

If this is the case, ncurses should maybe be listed as a non-optional
dependency? But it still seems a bit weird, because if it works with
--withoutmod-_minimal_curses, why not set that flag automatically if the Python
used to translate is found lacking in that department?

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

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


From pypy-dev-issue at codespeak.net  Wed Dec  1 13:33:35 2010
From: pypy-dev-issue at codespeak.net (Leonardo Santagada)
Date: Wed, 01 Dec 2010 12:33:35 +0000
Subject: [PyPy-issue] [issue564] Translation fails without ncurses with a
	py.test.skip exception
Message-ID: <1291206815.82.0.0650204140061.issue564@>


Leonardo Santagada <santagada at gmail.com> added the comment:

Yesterday I changed the error to an ImportError so it makes more sense. I think we need to change the 
documentation so this is more clear, but automatically turning off modules is a bad idea, because you end 
up with different pypy based on the environment. An import error during translation could trigger a more 
complete error message talking about --withoutmod also.

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


From pypy-dev-issue at codespeak.net  Wed Dec  1 17:04:42 2010
From: pypy-dev-issue at codespeak.net (Armin Ronacher)
Date: Wed, 01 Dec 2010 16:04:42 +0000
Subject: [PyPy-issue] [issue583] sqlite3 module only exposes dbapi2
Message-ID: <1291219482.23.0.798764753038.issue583@>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

In cpython the sqlite3 module directly exposes the members of the sqlite3.dbapi2
module:

    from dbapi2 import *

Many people rely on that and do imports like this:

    try:
        from pysqlite3 import dbapi2 as sqlite3
    except ImportError:
        import sqlite3

This would be a one line fix (just import * from dbapi2) and it would result in
higher compatibility with cpython.

----------
effort: easy
messages: 1909
nosy: mitsuhiko, pypy-issue
priority: feature
release: 1.4
status: unread
title: sqlite3 module only exposes dbapi2

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


From pypy-dev-issue at codespeak.net  Wed Dec  1 17:18:41 2010
From: pypy-dev-issue at codespeak.net (Armin Ronacher)
Date: Wed, 01 Dec 2010 16:18:41 +0000
Subject: [PyPy-issue] [issue584] Consider wrapping functions that that are
	not functions in CPython
Message-ID: <1291220321.29.0.426930587216.issue584@>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

A few things in Python are not functions and with that do not implement the
descriptor protocol. This has the handy side effect that they can be stored as
class attributes without becoming a method.

For instance I found that this code breaks in PyPy:

    import hashlib

    class MyClass(object):
        hash_method = hashlib.sha1

        def foo(self):
            h = self.hash_method()
            h.update(...)
            return h.hexdigest()

hashlib.sha1 is implemented as a function in PyPy and in this case automatically
becomes a function.  Instead it would probably be useful to have a wrapper that
removes the __get__ that makes a function a method.

----------
effort: medium
messages: 1910
nosy: mitsuhiko, pypy-issue
priority: wish
release: 1.4
status: unread
title: Consider wrapping functions that that are not functions in CPython

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


From pypy-dev-issue at codespeak.net  Wed Dec  1 17:20:52 2010
From: pypy-dev-issue at codespeak.net (Armin Ronacher)
Date: Wed, 01 Dec 2010 16:20:52 +0000
Subject: [PyPy-issue] [issue585] Missing euc-kr encoding
Message-ID: <1291220452.63.0.778360043449.issue585@>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Currently pypy does not support the euc-kr encoding that is commonly used in Korea.

----------
effort: ???
messages: 1911
nosy: mitsuhiko, pypy-issue
priority: feature
release: 1.4
status: unread
title: Missing euc-kr encoding

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


From pypy-dev-issue at codespeak.net  Wed Dec  1 17:27:31 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 01 Dec 2010 16:27:31 +0000
Subject: [PyPy-issue] [issue584] Consider wrapping functions that that are
	not functions in CPython
Message-ID: <1291220851.09.0.0165460125053.issue584@>


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

Already fixed. :-)

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

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


From pypy-dev-issue at codespeak.net  Wed Dec  1 17:34:25 2010
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Wed, 01 Dec 2010 16:34:25 +0000
Subject: [PyPy-issue] [issue583] sqlite3 module only exposes dbapi2
Message-ID: <1291221265.04.0.371474352955.issue583@>


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

Fixed in r79717.

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

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


From pypy-dev-issue at codespeak.net  Wed Dec  1 22:04:42 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Wed, 01 Dec 2010 21:04:42 +0000
Subject: [PyPy-issue] [issue586] Show a traceback when an exception is
	raised in a destructor
Message-ID: <1291237482.18.0.209818363796.issue586@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

When an exception is raised in a destructor, PyPy currently prints a message like this:

a destructor raised an exception, ignoring it

Other than the fact that the word ?was? seems to have been left out, this isn't terribly helpful. It doesn't say 
anything about the exception that was raised. Either printing a traceback or the destructor that failed 
would be a vast improvement. I think that's what CPython does.

I tried reproducing this with a small test script, but it actually printed the destructor that failed. However, 
this isn't what I'm seeing in one of the remaining failures in Mercurial test suite.

----------
effort: ???
messages: 1914
nosy: danchr, pypy-issue
priority: feature
release: 1.4
status: unread
title: Show a traceback when an exception is raised in a destructor

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 13:53:01 2010
From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz)
Date: Thu, 02 Dec 2010 12:53:01 +0000
Subject: [PyPy-issue] [issue586] Show a traceback when an exception is
	raised in a destructor
Message-ID: <1291294381.08.0.228200147462.issue586@>


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

This is quite likely a bug in PyPy that is just reported very
unhelpfully. Probably one of the interpreter-level destructors raised
something, e.g. files or similar. In this case writing the traceback
wouldn't help either, because there is none on the RPython level. Maybe
I can try to improve things so that at least some more information is
printed.

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

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 13:54:32 2010
From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz)
Date: Thu, 02 Dec 2010 12:54:32 +0000
Subject: [PyPy-issue] [issue586] Show a traceback when an exception is
	raised in a destructor
In-Reply-To: <1291237482.18.0.209818363796.issue586@>
Message-ID: <4CF79576.4000107@gmx.de>


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

On 12/01/2010 10:04 PM, Dan Villiom Podlaski Christiansen wrote:
>
> New submission from Dan Villiom Podlaski
> Christiansen<danchr at gmail.com>:
>
> When an exception is raised in a destructor, PyPy currently prints a
> message like this:
>
> a destructor raised an exception, ignoring it
>
> Other than the fact that the word ?was? seems to have been left out,
> this isn't terribly helpful. It doesn't say anything about the
> exception that was raised. Either printing a traceback or the
> destructor that failed would be a vast improvement. I think that's
> what CPython does.
>
> I tried reproducing this with a small test script, but it actually
> printed the destructor that failed. However, this isn't what I'm
> seeing in one of the remaining failures in Mercurial test suite.

This is quite likely a bug in PyPy that is just reported very
unhelpfully. Probably one of the interpreter-level destructors raised
something, e.g. files or similar. In this case writing the traceback
wouldn't help either, because there is none on the RPython level. Maybe
I can try to improve things so that at least some more information is
printed.

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:28:45 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Thu, 02 Dec 2010 13:28:45 +0000
Subject: [PyPy-issue] [issue587] Plain 'strip' in package.py breaks cpyext
	on Mac OS X
Message-ID: <1291296525.56.0.337357605869.issue587@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

On Mac OS X, without arguments will strip *all* symbols from the binary. The attached patch changes 
package.py to use 'strip -x' instead, which will only strip global symbols.

----------
effort: easy
files: strip-x.diff
messages: 1917
nosy: danchr, pypy-issue
priority: bug
release: 1.4
status: unread
title: Plain 'strip' in package.py breaks cpyext on Mac OS X

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue587>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strip-x.diff
Type: application/octet-stream
Size: 842 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101202/b417af4c/attachment.obj>

From pypy-dev-issue at codespeak.net  Thu Dec  2 14:31:19 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Thu, 02 Dec 2010 13:31:19 +0000
Subject: [PyPy-issue] [issue585] Missing euc-kr encoding
Message-ID: <1291296679.42.0.832673252075.issue585@>


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

does adding 

# -*- coding:utf-8 -*-
or
# -*- coding:cp949 -*-
on the top of the .py source help?
(if you can read korean, i could point you to some other resources too.)

If you can provide any code where it works on python but not on pypy that would be 
helpful too.

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

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:33:12 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Thu, 02 Dec 2010 13:33:12 +0000
Subject: [PyPy-issue] [issue521] Windows version don't work
Message-ID: <1291296792.88.0.5248655301.issue521@>


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

1.4 works for me. 
I think that if there are more cases where 1.4( or the latest version) works, than this 
should be closed.

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:33:37 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Thu, 02 Dec 2010 13:33:37 +0000
Subject: [PyPy-issue] [issue588] Use LDFLAGS when building PyPy as a library
Message-ID: <1291296817.79.0.429431652183.issue588@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

The final link command in a shared build doesn't pass LDFLAGS to the compiler. As LDFLAGS contain the 
flags to select architecture, building a non-default architecture will fail. For example, building a shared 
32-bit libary will fail on a 64-bit capable Mac running Mac OS X 10.6.

The attached patch fixes this.

----------
effort: easy
files: ldflags.diff
messages: 1920
nosy: danchr, pypy-issue
priority: bug
release: 1.4
status: unread
title: Use LDFLAGS when building PyPy as a library

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue588>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldflags.diff
Type: application/octet-stream
Size: 886 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101202/ff710046/attachment.obj>

From pypy-dev-issue at codespeak.net  Thu Dec  2 14:33:49 2010
From: pypy-dev-issue at codespeak.net (Armin Ronacher)
Date: Thu, 02 Dec 2010 13:33:49 +0000
Subject: [PyPy-issue] [issue585] Missing euc-kr encoding
Message-ID: <1291296829.23.0.0306095557876.issue585@>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

I'm not Korean, I can't speak/read Korean.  What I do have is a test case from a
user submitted bug report that uses euc-kr as encoding.

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:38:08 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Thu, 02 Dec 2010 13:38:08 +0000
Subject: [PyPy-issue] [issue585] Missing euc-kr encoding
Message-ID: <1291297088.08.0.661866729073.issue585@>


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

Do the test cases include the work arounds that i've mentioned?

also the issue is platform dependent.
I'm not an expert, but it is actually that UTF-8 is default for *nix systems including 
ubuntu(gnu/linux) and euc-kr/cp949 or the native encoding for Windows.

what is the platform under question?

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:38:12 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 02 Dec 2010 13:38:12 +0000
Subject: [PyPy-issue] [issue580] Broken pipe error during sandbox
	installation?
Message-ID: <1291297092.42.0.245264333657.issue580@>


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

Can you give us more information?  Most importantly, what line you typed to run
the command that eventually resulted in this message.  It looks like a
background process issue -- and not an important one, in the sense that apart
from this error message it should not cause any problem.  But I'm only guessing
here, more information is needed to help.

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

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:40:17 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 02 Dec 2010 13:40:17 +0000
Subject: [PyPy-issue] [issue585] Missing euc-kr encoding
Message-ID: <1291297217.57.0.446700540579.issue585@>


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

PyPy is missing euc-kr encodings. CPython supports them, hence PyPy should add 
them.

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:41:39 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 02 Dec 2010 13:41:39 +0000
Subject: [PyPy-issue] [issue585] Missing euc-kr encoding
Message-ID: <1291297299.44.0.69257863519.issue585@>


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

mitsuhiko: thanks for the missing feature report.  It should be fixed at some
point, but it's all a matter of resources and motivation :-/

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:52:19 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Thu, 02 Dec 2010 13:52:19 +0000
Subject: [PyPy-issue] [issue589] Missing cp932 encoding
Message-ID: <1291297939.99.0.330600561783.issue589@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

PyPy does not support the ?cp932? encoding. This encoding is used in the Mercurial test suite.

$ python2.5 -c 'print repr(u"\u30e9".encode("cp932"))'
'\x83\x89'
$ pypy -c 'print repr(u"\u30e9".encode("cp932"))'     
Traceback (most recent call last):
  File "app_main.py", line 33, in run_toplevel
  File "app_main.py", line 369, in run_it
  File "<string>", line 1, in <module>
LookupError: unknown encoding: cp932

----------
effort: ???
messages: 1926
nosy: danchr, pypy-issue
priority: bug
release: 1.4
status: unread
title: Missing cp932 encoding

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 14:57:30 2010
From: pypy-dev-issue at codespeak.net (Seung Soo, Ha)
Date: Thu, 02 Dec 2010 13:57:30 +0000
Subject: [PyPy-issue] [issue589] Missing cp932 encoding
Message-ID: <1291298250.83.0.995604717769.issue589@>


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

I think this is essentially a duplicate of https://codespeak.net/issue/pypy-dev/issue585

----------
status: unread -> duplicate

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 15:00:53 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Thu, 02 Dec 2010 14:00:53 +0000
Subject: [PyPy-issue] [issue589] Missing cp932 encoding
Message-ID: <1291298453.11.0.67001735165.issue589@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

I can't say whether it is ??that bug certainly inspired me to file this one. According to Wikipedia,[1] the 
encoding is similar to Shift-JIS, which PyPy doesn't appear to support either.

[1] http://en.wikipedia.org/wiki/CP932

----------
superseder: +Missing euc-kr encoding

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 18:40:12 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Thu, 02 Dec 2010 17:40:12 +0000
Subject: [PyPy-issue] [issue590] Add Mercurial version information to sys
	module
Message-ID: <1291311612.19.0.52758194175.issue590@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

If PyPy is built from a Mercurial checkout, it should be able to show information about where it was 
checked out. As part of the CPython migration, a patch has been posted.[1] Applying this patch yields 
these results:

$ grep HG Makefile
HGVERSION=      hg id -i $(srcdir)
HGTAG=          hg id -t $(srcdir)
HGBRANCH=       hg id -b $(srcdir)
	      -DHGVERSION="\"`LC_ALL=C $(HGVERSION)`\"" \
	      -DHGTAG="\"`LC_ALL=C $(HGTAG)`\"" \
	      -DHGBRANCH="\"`LC_ALL=C $(HGTAG)`\"" \
$ ./python.exe -c 'import sys; print(sys.subversion); print(sys._mercurial)'
('CPython', 'branches/release27-maint', '')
('CPython', 'add-hg-build-id.diff qbase qtip tip', 'a40affe1a0c3')

(HGPLAIN=1 should probably be specified in the environment as well.)

[1] <http://hg.python.org/pymigr/file/tip/build-identification/add-hg-build-id.diff>

----------
effort: ???
messages: 1929
nosy: danchr, pypy-issue
priority: feature
release: ???
status: unread
title: Add Mercurial version information to sys module

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 19:12:48 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 02 Dec 2010 18:12:48 +0000
Subject: [PyPy-issue] [issue591] Bug in optimizeopt
Message-ID: <1291313568.25.0.976807426653.issue591@>


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

This:

def g():
    pass

def f():
    global g
    i = 0
    while i < 10000:
        g = i
        i += 1

f()

is hitting fatal rpython error (assertion fails).

----------
effort: ???
messages: 1930
nosy: pypy-issue
priority: critical
release: ???
status: unread
title: Bug in optimizeopt

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


From pypy-dev-issue at codespeak.net  Thu Dec  2 19:23:44 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 02 Dec 2010 18:23:44 +0000
Subject: [PyPy-issue] [issue521] Windows version don't work
Message-ID: <1291314224.1.0.571707632874.issue521@>


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

Probably fixed since then.

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

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 12:49:05 2010
From: pypy-dev-issue at codespeak.net (Axel Gembe)
Date: Fri, 03 Dec 2010 11:49:05 +0000
Subject: [PyPy-issue] [issue592] trackgcroot.py fails with AssertionError on
	Gentoo x64
Message-ID: <1291376945.64.0.738167200947.issue592@>


New submission from Axel Gembe <ago at bastart.eu.org>:

Output is in the attachment

----------
effort: ???
files: fail.txt
messages: 1932
nosy: Ago, pypy-issue
priority: bug
release: ???
status: unread
title: trackgcroot.py fails with AssertionError on Gentoo x64

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue592>
_______________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fail.txt
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101203/50a58999/attachment.txt>

From pypy-dev-issue at codespeak.net  Fri Dec  3 12:49:10 2010
From: pypy-dev-issue at codespeak.net (David Naylor)
Date: Fri, 03 Dec 2010 11:49:10 +0000
Subject: [PyPy-issue] [issue593] ctypes.Array performance issues
Message-ID: <1291376950.6.0.045708325851.issue593@>


New submission from David Naylor <naylor.b.david at gmail.com>:

ctypes.Array performance in PyPy is substantially slower than CPython.  A 
profile shows that PyPy's Array assigns each item of the array, which is rather 
slow.  

The following (reduced) code shows the problem:

# cat ctype-array.py
from multiprocessing import Array
from time import time

data = " " * (1024 * 1024 * 10)  # 10MiB
start = time()
array = Array('c', data, lock=False)
print "%fs" % (time() - start)

# python ctypes-array.py 
4.234547s
# pypy-fast-forward ctypes-array.py
32.414674s

which shows an approximate 7.5x increase in execution time, against PyPy.

----------
effort: ???
messages: 1933
nosy: DragonSA, pypy-issue
priority: bug
release: ???
status: unread
title: ctypes.Array performance issues

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:09:06 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 03 Dec 2010 12:09:06 +0000
Subject: [PyPy-issue] [issue593] ctypes.Array performance issues
Message-ID: <1291378146.37.0.419778268656.issue593@>


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

We know that ctypes is slow.  On top of PyPy, it is written in pure Python.

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

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:11:27 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Fri, 03 Dec 2010 12:11:27 +0000
Subject: [PyPy-issue] [issue593] ctypes.Array performance issues
Message-ID: <1291378287.85.0.102801525095.issue593@>


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

btw, the issue of ctypes speed is being addressed in the jitypes2 branch, which
tries to reimplement ctypes on top of the jit-friendly _ffi module

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:26:52 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 03 Dec 2010 12:26:52 +0000
Subject: [PyPy-issue] [issue183] windows build needs superuser
Message-ID: <1291379212.64.0.815755606777.issue183@>


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

Closing this as it's either fixed or noone cares.

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

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:27:55 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 03 Dec 2010 12:27:55 +0000
Subject: [PyPy-issue] [issue367] pypy import scheme
Message-ID: <1291379275.56.0.905818204504.issue367@>


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

virtualenv done, closing

----------
nosy: +pypy-issue -ac, arigo, cfbolz, fijal, mwh, pedronis, tismer
status: chatting -> resolved

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:28:24 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 03 Dec 2010 12:28:24 +0000
Subject: [PyPy-issue] [issue234] Regular expression performance
Message-ID: <1291379304.68.0.356387005717.issue234@>


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

fixed

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

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:30:13 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Fri, 03 Dec 2010 12:30:13 +0000
Subject: [PyPy-issue] [issue593] ctypes.Array performance issues
Message-ID: <1291379413.48.0.876990755814.issue593@>


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

to clarify better: my comment was a reply to armin's "ctypes is slow", but it's
unclear that the jitypes2 will speed up the precise use case that this issue is
about

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:31:46 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 03 Dec 2010 12:31:46 +0000
Subject: [PyPy-issue] [issue328] Investigate formatting microbenchmarks.
Message-ID: <1291379506.52.0.983660600609.issue328@>


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

fixed using stringbuilder

----------
nosy: +pypy-issue -ac, arigo, cfbolz, fijal, mwh, pedronis, tismer
status: chatting -> resolved

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 13:45:03 2010
From: pypy-dev-issue at codespeak.net (David Naylor)
Date: Fri, 03 Dec 2010 12:45:03 +0000
Subject: [PyPy-issue] [issue593] ctypes.Array performance issues
Message-ID: <1291380303.19.0.430353836136.issue593@>


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

My use of multiprocessing.Array is to pass data between processes.  When testing 
fast-forward it was a significant slowdown compared to CPython (while everything 
else sped up).  

I have an acceptable workaround but I am sure some might not.

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 15:20:28 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Fri, 03 Dec 2010 14:20:28 +0000
Subject: [PyPy-issue] [issue594] [PATCH] distutils cannot build C extensions
	on Mac OS X
Message-ID: <1291386028.76.0.00886383512111.issue594@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

distutils cannot build C extensions on Mac OS X. Attached below is a patch to add the missing flags to both 
the compiler and linker.

----------
effort: ???
files: distutils-darwin.diff
messages: 1942
nosy: danchr, pypy-issue
priority: bug
release: ???
status: unread
title: [PATCH] distutils cannot build C extensions on Mac OS X

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue594>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: distutils-darwin.diff
Type: application/octet-stream
Size: 1291 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101203/806492d4/attachment.obj>

From pypy-dev-issue at codespeak.net  Fri Dec  3 21:02:00 2010
From: pypy-dev-issue at codespeak.net (Bob Ziuchkovski)
Date: Fri, 03 Dec 2010 20:02:00 +0000
Subject: [PyPy-issue] [issue595] Add Tkinter support through cpyext
Message-ID: <1291406520.74.0.0378487752424.issue595@>


New submission from Bob Ziuchkovski <bob.ziuchkovski at gmail.com>:

This is a request for adding Tkinter support to pypy.  I tested building Tkinter 
from python 2.5.2 against the pypy trunk last night (12/02) and the build fails 
with the below output.  I used the ubuntu packaging of the module's source since 
it contains only the Tkiner extension.  That archive is available at 
http://archive.ubuntu.com/ubuntu/pool/main/p/python-stdlib-extensions/python-
stdlib-extensions_2.5.2-0ubuntu2.tar.gz .  I know cpyext is considered alpha at 
this stage, so I marked this as a feature request instead of a bug.  The main 
reason I'm requesting Tkinter support is for running the Skeinforge application 
(http://fabmetheus.crsndoo.com/) with a reprap machine (reprap.org), though it 
would be nice to be able to run IDLE as well.  A direct download of skeinforge 
is available via 
http://fabmetheus.crsndoo.com/files/36_reprap_python_beanshell.zip .  I would be 
more than happy to help in testing Tkinter if needed.

Command:
bobbyz at chimera:~/tmp/python-stdlib-extensions-2.5.2/2.5$ python 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/presetup.py setup.py build

Results:
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
DPy_BUILD_CORE -I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -
I/tmp/usession-trunk-3 /tmp/usession-trunk-3/platcheck_1.c -o /tmp/usession-
trunk-3/platcheck_1.o
[platform:WARNING] In file included from /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/Python.h:112,
[platform:WARNING]                  from /tmp/usession-trunk-3/platcheck_1.c:20:
[platform:WARNING] /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/modsupport.inl: In function ?Py_InitModule4?:
[platform:WARNING] /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/modsupport.inl:21: warning: implicit 
declaration of function ?_Py_InitPyPyModule?
[platform:WARNING] /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/modsupport.inl:23: warning: return makes 
pointer from integer without a cast
[platform:execute] gcc /tmp/usession-trunk-3/platcheck_1.o -pthread -lrt -o 
/tmp/usession-trunk-3/platcheck_1
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
DPy_BUILD_CORE -I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -
I/tmp/usession-trunk-3 /tmp/usession-trunk-3/platcheck_5.c -o /tmp/usession-
trunk-3/platcheck_5.o
[platform:WARNING] In file included from /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/Python.h:112,
[platform:WARNING]                  from /tmp/usession-trunk-3/platcheck_5.c:20:
[platform:WARNING] /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/modsupport.inl: In function ?Py_InitModule4?:
[platform:WARNING] /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/modsupport.inl:21: warning: implicit 
declaration of function ?_Py_InitPyPyModule?
[platform:WARNING] /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/include/modsupport.inl:23: warning: return makes 
pointer from integer without a cast
[platform:execute] gcc /tmp/usession-trunk-3/platcheck_5.o -pthread -lrt -o 
/tmp/usession-trunk-3/platcheck_5
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-trunk-3/platcheck_7.c -o /tmp/usession-trunk-3/platcheck_7.o
[platform:Error] /tmp/usession-trunk-3/platcheck_7.c: In function ?main?:
[platform:Error] /tmp/usession-trunk-3/platcheck_7.c:32: error: too many 
arguments to function ?getpgrp?
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-trunk-3/platcheck_8.c -o /tmp/usession-trunk-3/platcheck_8.o
[platform:Error] /tmp/usession-trunk-3/platcheck_8.c: In function ?main?:
[platform:Error] /tmp/usession-trunk-3/platcheck_8.c:32: error: too many 
arguments to function ?setpgrp?
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -I/home/bobbyz/tmp/pypy-trunk/pypy/translator/c /tmp/usession-trunk-
3/module_cache/module_0.c -o /tmp/usession-trunk-3/module_cache/module_0.o
[platform:execute] gcc -shared /tmp/usession-trunk-3/module_cache/module_0.o -
pthread -lrt -Wl,--export-dynamic,--version-script=/tmp/usession-trunk-
3/dynamic-symbols-0 -o /tmp/usession-trunk-3/module_cache/externmod.so
faking <type 'module'>
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
I/home/bobbyz/tmp/pypy-trunk/pypy/translator/c /tmp/usession-trunk-
3/platcheck_15.c -o /tmp/usession-trunk-3/platcheck_15.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
I/home/bobbyz/tmp/pypy-trunk/pypy/translator/c /tmp/usession-trunk-
3/module_cache/module_1.c -o /tmp/usession-trunk-3/module_cache/module_1.o
[platform:execute] gcc /tmp/usession-trunk-3/platcheck_15.o /tmp/usession-trunk-
3/module_cache/module_1.o -pthread -lrt -Wl,--export-dynamic,--version-
script=/tmp/usession-trunk-3/dynamic-symbols-1 -o /tmp/usession-trunk-
3/platcheck_15
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/varargwrapper.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/varargwrapper.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/pyerrors.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/pyerrors.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/modsupport.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/modsupport.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/getargs.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/getargs.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/stringobject.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/stringobject.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/mysnprintf.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/mysnprintf.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/pythonrun.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/pythonrun.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/bufferobject.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/bufferobject.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/object.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/object.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/cobject.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/cobject.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/structseq.c -o 
/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/src/structseq.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/tmp/usession-trunk-3/module_cache/module_2.c -o /tmp/usession-trunk-
3/module_cache/module_2.o
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused -
fPIC -DPy_BUILD_CORE -Werror=implicit-function-declaration -
I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -I/tmp/usession-trunk-3 
/tmp/usession-trunk-3/module_cache/module_3.c -o /tmp/usession-trunk-
3/module_cache/module_3.o
[platform:execute] gcc -shared /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/varargwrapper.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/pyerrors.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/modsupport.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/getargs.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/stringobject.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/mysnprintf.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/pythonrun.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/bufferobject.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/object.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/cobject.o /home/bobbyz/tmp/pypy-
trunk/pypy/module/cpyext/src/structseq.o /tmp/usession-trunk-
3/module_cache/module_2.o /tmp/usession-trunk-3/module_cache/module_3.o -pthread 
-lrt -Wl,--export-dynamic,--version-script=/tmp/usession-trunk-3/dynamic-
symbols-2 -o /tmp/usession-trunk-3/module_cache/pypyapi.so
running build
running build_ext
building '_tkinter' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-
prototypes -fPIC -DWITH_APPINIT=1 -I/usr/include/tcl8.5 -I/usr/X11/include -I. -
I/home/bobbyz/tmp/python-stdlib-extensions-2.5.2/./Include -I. -
I/usr/local/include -I/home/bobbyz/tmp/pypy-trunk/pypy/module/cpyext/include -
I/tmp/usession-trunk-3 -c Modules/_tkinter.c -o build/temp.linux-x86_64-
2.6/Modules/_tkinter.o
Modules/_tkinter.c: In function ?var_perform?:
Modules/_tkinter.c:1527: warning: implicit declaration of function 
?PyErr_NormalizeException?
Modules/_tkinter.c: In function ?var_invoke?:
Modules/_tkinter.c:1550: warning: unused variable ?self?
Modules/_tkinter.c: In function ?Tkapp_ExprDouble?:
Modules/_tkinter.c:1851: warning: implicit declaration of function 
?PyFPE_START_PROTECT?
Modules/_tkinter.c:1851: error: expected expression before ?return?
Modules/_tkinter.c:1853: error: expected ?;? before ?retval?
Modules/_tkinter.c:1855: warning: implicit declaration of function 
?PyFPE_END_PROTECT?
Modules/_tkinter.c:1856: error: expected ?;? before ?if?
Modules/_tkinter.c:1858: error: ?else? without a previous ?if?
Modules/_tkinter.c: In function ?Tkinter_Create?:
Modules/_tkinter.c:2906: warning: implicit declaration of function 
?Py_GetProgramName?
Modules/_tkinter.c:2906: warning: passing argument 1 of ?strrchr? makes pointer 
from integer without a cast
/usr/include/string.h:260: note: expected ?const char *? but argument is of type 
?int?
Modules/_tkinter.c:2910: warning: assignment makes pointer from integer without 
a cast
Modules/_tkinter.c: In function ?EnableEventHook?:
Modules/_tkinter.c:3058: error: ?PyOS_InputHook? undeclared (first use in this 
function)
Modules/_tkinter.c:3058: error: (Each undeclared identifier is reported only 
once
Modules/_tkinter.c:3058: error: for each function it appears in.)
Modules/_tkinter.c: In function ?DisableEventHook?:
Modules/_tkinter.c:3071: error: ?PyOS_InputHook? undeclared (first use in this 
function)
Modules/_tkinter.c: In function ?init_tkinter?:
Modules/_tkinter.c:3155: warning: passing argument 1 of ?Tcl_FindExecutable? 
makes pointer from integer without a cast
/usr/include/tcl8.5/tclDecls.h:914: note: expected ?const char *? but argument 
is of type ?int?
Exception TypeError: "'NoneType' object is not callable" in <function remove at 
0x2257b90> ignored
Exception TypeError: "'NoneType' object is not callable" in <function remove at 
0x2257b90> ignored

----------
effort: ???
messages: 1943
nosy: bobbyz, pypy-issue
priority: feature
release: 1.4
status: unread
title: Add Tkinter support through cpyext

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


From pypy-dev-issue at codespeak.net  Fri Dec  3 21:05:20 2010
From: pypy-dev-issue at codespeak.net (=?utf-8?q?=C5=81ukasz_Fidosz?=)
Date: Fri, 03 Dec 2010 20:05:20 +0000
Subject: [PyPy-issue] [issue596] Adding Mako template engine benchmark to
	benchmarks.
Message-ID: <1291406720.61.0.0551152294444.issue596@>


New submission from ?ukasz Fidosz <virhilo at gmail.com>:

I written Mako template engine benchmark, it benchmarking: template 
inherences, HTML escaping, XML escaping, URL escaping, whitespace 
trimming, function defitions/calls and forloops.

Could it be added into pypy benchmarks?

----------
effort: ???
files: bm_mako.py
messages: 1944
nosy: pypy-issue, virhilo
priority: feature
release: ???
status: unread
title: Adding Mako template engine benchmark to benchmarks.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue596>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bm_mako.py
Type: text/x-python
Size: 3876 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101203/4ade8821/attachment.py>

From pypy-dev-issue at codespeak.net  Fri Dec  3 21:07:34 2010
From: pypy-dev-issue at codespeak.net (=?utf-8?q?=C5=81ukasz_Fidosz?=)
Date: Fri, 03 Dec 2010 20:07:34 +0000
Subject: [PyPy-issue] [issue597] Adding Mako template engine benchmark to
	benchmarks.
Message-ID: <1291406854.42.0.0380912804731.issue597@>


New submission from ?ukasz Fidosz <virhilo at gmail.com>:

I wrote Mako template engine benchmark, it benchmarking: template 
inherences, HTML escaping, XML escaping, URL escaping, whitespace 
trimming, function defitions/calls and forloops.

Could it be added into pypy benchmarks?

----------
effort: ???
files: bm_mako.py
messages: 1945
nosy: pypy-issue, virhilo
priority: feature
release: ???
status: unread
title: Adding Mako template engine benchmark to benchmarks.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue597>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bm_mako.py
Type: text/x-python
Size: 3876 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101203/8172a71c/attachment.py>

From pypy-dev-issue at codespeak.net  Fri Dec  3 21:14:20 2010
From: pypy-dev-issue at codespeak.net (=?utf-8?q?=C5=81ukasz_Fidosz?=)
Date: Fri, 03 Dec 2010 20:14:20 +0000
Subject: [PyPy-issue] [issue596] Adding Mako template engine benchmark to
	benchmarks.
Message-ID: <1291407260.16.0.339108474071.issue596@>


New submission from ?ukasz Fidosz <virhilo at gmail.com>:

I wrote Mako template engine benchmark, it benchmarking: template 
inherences, HTML escaping, XML escaping, URL escaping, whitespace 
trimming, function defitions/calls and forloops.

Could it be added into pypy benchmarks?

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


From pypy-dev-issue at codespeak.net  Sat Dec  4 19:28:33 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Sat, 04 Dec 2010 18:28:33 +0000
Subject: [PyPy-issue] [issue598] [PATCH] Implement
	PyErr_SetFromErrnoWithFilename()
Message-ID: <1291487313.23.0.245477939373.issue598@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

The attached patch adds an implementation of PyErr_SetFromErrnoWithFilename() for cpyext.

----------
effort: ???
files: PyErr_SetFromErrnoWithFilename.diff
messages: 1947
nosy: danchr, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Implement PyErr_SetFromErrnoWithFilename()

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue598>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PyErr_SetFromErrnoWithFilename.diff
Type: application/octet-stream
Size: 4023 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101204/994ea8c4/attachment.obj>

From pypy-dev-issue at codespeak.net  Sat Dec  4 19:29:33 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Sat, 04 Dec 2010 18:29:33 +0000
Subject: [PyPy-issue] [issue599] [PATCH] Implement PyFile_Check() &
	PyFile_CheckExact()
Message-ID: <1291487373.52.0.124181950595.issue599@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

The attached patch adds implementations of PyFile_Check() & PyFile_CheckExact() for cpyext.

----------
effort: ???
files: PyFile_Check.diff
messages: 1948
nosy: danchr, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Implement PyFile_Check() & PyFile_CheckExact()

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue599>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PyFile_Check.diff
Type: application/octet-stream
Size: 3182 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101204/2a6f3314/attachment.obj>

From pypy-dev-issue at codespeak.net  Sat Dec  4 19:30:15 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Sat, 04 Dec 2010 18:30:15 +0000
Subject: [PyPy-issue] [issue600] [PATCH] Implement PyFile_GetLine()
Message-ID: <1291487415.4.0.694619133405.issue600@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

The attached patch adds an implementation of PyFile_GetLine() for cpyext.

----------
effort: ???
files: PyFile_GetLine.diff
messages: 1949
nosy: danchr, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Implement PyFile_GetLine()

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue600>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PyFile_GetLine.diff
Type: application/octet-stream
Size: 5030 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101204/562fef86/attachment.obj>

From pypy-dev-issue at codespeak.net  Sun Dec  5 13:51:23 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Sun, 05 Dec 2010 12:51:23 +0000
Subject: [PyPy-issue] [issue601] Argument corruption with cpyext on Mac OS X?
Message-ID: <1291553482.94.0.631459868938.issue601@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

Building the attached C source as an extension module on Mac OS X will yield some surprising results:

>>>> import test
>>>> for x in xrange(3): print test.arglen1("abc")
1
1
1
>>>> for x in xrange(3): print test.arglen2("abc")
9778048
1
9778048
>>>> 

The only difference between arglen1 and arglen2 is that the latter specifies METH_KEYWORDS, 
otherwise, their implementation is the same.

----------
effort: ???
files: test.c
messages: 1950
nosy: danchr, pypy-issue
priority: bug
release: ???
status: unread
title: Argument corruption with cpyext on Mac OS X?

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue601>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: application/octet-stream
Size: 589 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101205/41a2ed00/attachment.obj>

From pypy-dev-issue at codespeak.net  Sun Dec  5 18:46:37 2010
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Sun, 05 Dec 2010 17:46:37 +0000
Subject: [PyPy-issue] [issue340] rewrite PyPy's tokenizer
Message-ID: <1291571197.37.0.727258383864.issue340@>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Any hints or further infos to interested newcomers as to what is required for
this task ?

----------
nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer
status: unread -> chatting

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


From pypy-dev-issue at codespeak.net  Mon Dec  6 07:18:08 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 06 Dec 2010 06:18:08 +0000
Subject: [PyPy-issue] [issue340] rewrite PyPy's tokenizer
Message-ID: <1291616288.55.0.641827006242.issue340@>


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

As explained below it's for example slow. Feel free to drop by on #pypy on IRC 
(we generally don't handle such large tasks over issue tracker)

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


From pypy-dev-issue at codespeak.net  Mon Dec  6 16:12:16 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 06 Dec 2010 15:12:16 +0000
Subject: [PyPy-issue] [issue591] Bug in optimizeopt
Message-ID: <1291648336.91.0.687511456562.issue591@>


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

fixed in r79847.

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

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


From pypy-dev-issue at codespeak.net  Mon Dec  6 17:32:53 2010
From: pypy-dev-issue at codespeak.net (Tom Burdick)
Date: Mon, 06 Dec 2010 16:32:53 +0000
Subject: [PyPy-issue] [issue602] structmember.h missing definitions
Message-ID: <1291653173.95.0.0797223057047.issue602@>


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

T_BOOL, T_DOUBLE, T_FLOAT, T_PYSSIZET among other definitions are missing in 
structmember.h preventing pyev from compiling. I believe this is the last 
missing piece to getting this to work.

This looks like a pretty easy fix and I tried hacking a patch together myself.
Adding the definitions to structmemberdef.py and adding the else conditions to 
structmember.py in cpyext is what I've done, though how "right" I've done it is 
questionable as I'm not familiar with rpython at all.

----------
effort: easy
files: structtypes.diff
messages: 1954
nosy: bfrog, pypy-issue
priority: bug
release: ???
status: unread
title: structmember.h missing definitions

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue602>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: structtypes.diff
Type: text/x-patch
Size: 1655 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101206/03317d9b/attachment.bin>

From pypy-dev-issue at codespeak.net  Mon Dec  6 17:36:42 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 06 Dec 2010 16:36:42 +0000
Subject: [PyPy-issue] [issue602] structmember.h missing definitions
Message-ID: <1291653402.87.0.53589237945.issue602@>


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

Thanks for the patch!  I see two issues:

* T_BOOL: it should read a single byte, and return w_True or w_False
  (e.g. something like space.wrap(result[0] != 0))

* There is the conversion in the other direction, too, that you are missing.

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

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


From pypy-dev-issue at codespeak.net  Mon Dec  6 17:40:34 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Mon, 06 Dec 2010 16:40:34 +0000
Subject: [PyPy-issue] [issue602] structmember.h missing definitions
Message-ID: <1291653634.92.0.271129298171.issue602@>


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

Except for T_PYSSIZET (which did not exist in 2.5 anyway), all these are already 
done in the fast-forward branch. And the code is a bit easier there.
(for example, your patch misses the conversion in the other direction).

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 14:25:07 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Tue, 07 Dec 2010 13:25:07 +0000
Subject: [PyPy-issue] [issue601] Argument corruption with cpyext when using
	GCC 4.2 on Mac OS X
Message-ID: <1291728307.59.0.490338575777.issue601@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

This was likely caused by using Apple GCC 4.2 for building PyPy. I don't see the problem in builds by the 
buildbots, which all use Apple GCC 4.0. I changed the default compiler on Darwin to GCC 4.0 in r79836.

----------
status: unread -> chatting
title: Argument corruption with cpyext on Mac OS X? -> Argument corruption with cpyext when using GCC 4.2 on Mac OS X

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 16:15:11 2010
From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz)
Date: Tue, 07 Dec 2010 15:15:11 +0000
Subject: [PyPy-issue] [issue586] Show a traceback when an exception is
	raised in a destructor
Message-ID: <1291734911.37.0.300764638142.issue586@>


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

r79751 introduced better error messages, can you rerun and report on them?

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 16:17:13 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Tue, 07 Dec 2010 15:17:13 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291735033.04.0.634891286588.issue603@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

The fast-forward branch fails to build on Mac OS X due to some linker warnings and errors. See 
<http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/20/steps/translate/logs/stdio> 
for details.

----------
effort: ???
messages: 1959
nosy: danchr, pypy-issue
priority: bug
release: ???
status: unread
title: fast-forward branch does not build on Mac OS X

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 16:17:53 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 07 Dec 2010 15:17:53 +0000
Subject: [PyPy-issue] [issue469] JIT without SSE2
Message-ID: <1291735073.16.0.207086995756.issue469@>


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

Fixed long ago.  We have a no-SSE2 version too, although it's not super-tested.

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

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 16:18:32 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 07 Dec 2010 15:18:32 +0000
Subject: [PyPy-issue] [issue499] 64-bit pypystandalone translation error
Message-ID: <1291735112.26.0.876950998027.issue499@>


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

64-bit builds are commonplace nowadays.

----------
nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer
status: chatting -> resolved

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 16:26:32 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 07 Dec 2010 15:26:32 +0000
Subject: [PyPy-issue] [issue404] malloc removal bug
Message-ID: <1291735592.86.0.852043324641.issue404@>


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

Works nowadays, in the sense that checking out lang/js from that date and
running today's translate.py on it works fine.

----------
nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer
status: unread -> resolved

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 16:28:06 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 07 Dec 2010 15:28:06 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291735686.39.0.958855184209.issue603@>


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

The _multiprocessing module unconditionally added the 'rt' library.
Fixed in r79867.

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

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 16:29:48 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Tue, 07 Dec 2010 15:29:48 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291735788.37.0.427644385931.issue603@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

Thanks, build started at <http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/21>.

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 17:16:38 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 07 Dec 2010 16:16:38 +0000
Subject: [PyPy-issue] [issue557] reload(sys) mess
Message-ID: <1291738598.66.0.60887493791.issue557@>


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

Probably fixed in r79868.

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

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 17:25:03 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 07 Dec 2010 16:25:03 +0000
Subject: [PyPy-issue] [issue563] SyntaxError issue
Message-ID: <1291739103.8.0.272708218498.issue563@>


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

Fixed by r79866 and r79870.

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

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 17:31:13 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Tue, 07 Dec 2010 16:31:13 +0000
Subject: [PyPy-issue] [issue586] Show a traceback when an exception is
	raised in a destructor
Message-ID: <1291739473.96.0.575600314972.issue586@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

I just reran the test suite, and I didn't see the error messages. I'll report back if I see them again in the 
future?

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 17:36:26 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Tue, 07 Dec 2010 16:36:26 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291739786.9.0.096330741595.issue603@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

The new run also failed, but with a different error:

  TypeError': <Struct timespec { c_tv_sec, c_tv_nsec }> instance field 'c_tv_nsec':
 expects <Signed>
     got <INT>
 	.. v743 = setattr(v741, ('c_tv_nsec'), v742)
 	.. '(pypy.module._multiprocessing.interp_semaphore:247)semlock_acquire'

AFAICT the definition of struct timespec on Darwin is equivalent to {long, long}.

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 18:29:11 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 07 Dec 2010 17:29:11 +0000
Subject: [PyPy-issue] [issue423] fix cProfile's representaion of methods
Message-ID: <1291742951.41.0.13397711407.issue423@>


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

Fixed in r79874.

----------
nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer
status: unread -> resolved

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 18:51:53 2010
From: pypy-dev-issue at codespeak.net (Michael Foord)
Date: Tue, 07 Dec 2010 17:51:53 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1291744313.77.0.317711131869.issue604@>


New submission from Michael Foord <michael at voidspace.org.uk>:

Using Mac OS X 10.6.5. Tried with the 1.4 release and with the nightly from
2010/12/07. pypy-c-jit-79863-osx64.tar.bz2

virtualenv version 1.5.1

The *apparent* cause is required parts of plat-mac being missing from the pypy
distribution. (Diagnosed by another user on #pypy when I first discovered the
problem.)

Attempting to use virtualenv for pypy and the --distribute option fails. This
prevents me from using tox to test with pypy. (Another user reported the same
problem on the Testing in Python mailing list. When I tried it in Ubuntu it
worked fine.)

$ virtualenv --distribute --no-site-packages -p
~/Downloads/pypy-c-jit-79863-osx64/bin/pypy pypy
Running virtualenv with interpreter /Volumes/Second
Drive/michael/Downloads/pypy-c-jit-79863-osx64/bin/pypy
New pypy-c executable in pypy/bin/pypy
Also creating executable in pypy/bin/pypy-c
Please make sure you remove any previous custom paths from your /Volumes/Second
Drive/michael/.pydistutils.cfg file.
Installing distribute................................done.
  Complete output from command "/Volumes/Second Drive/michael/.../pypy"
"/Volumes/Second Drive/michael/...stall" /Library/Frameworks/Python.fra...ar.gz:
  Traceback (most recent call last):
  File "app_main.py", line 34, in run_toplevel
IOError: [Errno 2] No such file or directory: '/Volumes/Second
Drive/michael/pypy/bin/easy_install'
----------------------------------------
Traceback (most recent call last):
  File "app_main.py", line 34, in run_toplevel
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py",
line 1647, in <module>
    main()
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py",
line 558, in main
    prompt=options.prompt)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py",
line 656, in create_environment
    install_pip(py_executable)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py",
line 415, in install_pip
    filter_stdout=_filter_setup)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py",
line 624, in call_subprocess
    % (cmd_desc, proc.returncode))
OSError: Command "/Volumes/Second Drive/michael/.../pypy" "/Volumes/Second
Drive/michael/...stall" /Library/Frameworks/Python.fra...ar.gz failed with error
code 1

----------
effort: ???
messages: 1970
nosy: pypy-issue, voidspace
priority: bug
release: 1.4
status: unread
title: pypy and virtualenv with distribute on Mac OS X

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 19:15:35 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 07 Dec 2010 18:15:35 +0000
Subject: [PyPy-issue] [issue326] investigate list_resize
Message-ID: <1291745735.52.0.305939934481.issue326@>


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

Closing this old report as no longer valid (general work has been done in-between).

----------
nosy: +pypy-issue -ac, arigo, cfbolz, fijal, mwh, pedronis, tismer
status: in-progress -> resolved

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 20:18:33 2010
From: pypy-dev-issue at codespeak.net (Leonardo Santagada)
Date: Tue, 07 Dec 2010 19:18:33 +0000
Subject: [PyPy-issue] [issue592] trackgcroot.py fails with AssertionError on
	Gentoo x64
Message-ID: <1291749513.04.0.208868526142.issue592@>


Leonardo Santagada <santagada at gmail.com> added the comment:

I think an important information missing is your compiler version (A way to get 
tons of info is by running gcc -v). Could you add this info here?

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

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


From pypy-dev-issue at codespeak.net  Tue Dec  7 20:22:25 2010
From: pypy-dev-issue at codespeak.net (Axel Gembe)
Date: Tue, 07 Dec 2010 19:22:25 +0000
Subject: [PyPy-issue] [issue592] trackgcroot.py fails with AssertionError on
	Gentoo x64
Message-ID: <1291749745.75.0.665686595295.issue592@>


Axel Gembe <ago at bastart.eu.org> added the comment:

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.1/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.5.1-r1/work/gcc-4.5.1/
configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.1 --
includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/include --datadir=/usr/share/
gcc-data/x86_64-pc-linux-gnu/4.5.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-
gnu/4.5.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1/info --
with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/include/g++-v4 --
host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --
disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --
without-included-gettext --with-system-zlib --disable-werror --enable-secureplt 
--enable-multilib --enable-libmudflap --disable-libssp --enable-esp --enable-
libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-
gnu/4.5.1/python --enable-checking=release --disable-libgcj --enable-
languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --
enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-
pkgversion='Gentoo Hardened 4.5.1-r1 p1.3, pie-0.4.5'
Thread model: posix
gcc version 4.5.1 (Gentoo Hardened 4.5.1-r1 p1.3, pie-0.4.5)

Now that I see it like that, I'm gonna try without hardened.

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


From pypy-dev-issue at codespeak.net  Wed Dec  8 03:52:44 2010
From: pypy-dev-issue at codespeak.net (Hybride)
Date: Wed, 08 Dec 2010 02:52:44 +0000
Subject: [PyPy-issue] [issue580] Broken pipe error during sandbox
	installation?
Message-ID: <1291776764.67.0.606356310867.issue580@>


Hybride <hybridephantom at hotmail.com> added the comment:

This was during the actual sandbox compiling, running this command:
./translate.py --sandbox targetpypystandalone.py

I tried compiling a sandbox version running:
python translate.py --sandbox

But that hangs indefinitely on:
 [platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused
-I/home/python/pypy-1.4/pypy/translator/c
/tmp/usession-3/testing_1/implement_2.c -o /tmp/usession-3/testing_1/implement_2.o

Am wondering if this actual server issues? I compiled an Ubuntu 10 local machine
sandbox version with no issues; am wondering if it's an OS version issue?

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


From pypy-dev-issue at codespeak.net  Wed Dec  8 14:39:19 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 08 Dec 2010 13:39:19 +0000
Subject: [PyPy-issue] [issue596] Adding Mako template engine benchmark to
	benchmarks.
Message-ID: <1291815559.29.0.382630510828.issue596@>


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

It looks like it's done in the same format as the bm_xxx.py files in
unladen_swallow/performance/.  fijal, can you confirm it and add it to the
benchmarks?

----------
assignedto:  -> fijal

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


From pypy-dev-issue at codespeak.net  Wed Dec  8 15:23:44 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Wed, 08 Dec 2010 14:23:44 +0000
Subject: [PyPy-issue] [issue596] Adding Mako template engine benchmark to
	benchmarks.
Message-ID: <1291818224.89.0.175273193087.issue596@>


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

Yes, will do that next week. At least I asked for bm_xxx format :]

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


From pypy-dev-issue at codespeak.net  Thu Dec  9 09:15:41 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Thu, 09 Dec 2010 08:15:41 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291882541.19.0.748200317887.issue603@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

A new one, on i386: Exception: don't know about <sem_t (opaque)>

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


From pypy-dev-issue at codespeak.net  Thu Dec  9 10:28:09 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 09 Dec 2010 09:28:09 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291886889.42.0.908125245301.issue603@>


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

Is the exception raised from node.py? Can you investigate why a *prebuilt* sem_t 
value would be translated?

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


From pypy-dev-issue at codespeak.net  Thu Dec  9 10:30:50 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Thu, 09 Dec 2010 09:30:50 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291887050.91.0.535114322829.issue603@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

I'm doing a new build with the attached patch applied. It turns out that sem_t is defined as an integer on 
Darwin rather than an opaque pointer.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue603>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sem_t.diff
Type: application/octet-stream
Size: 943 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101209/5f5f91d5/attachment.obj>

From pypy-dev-issue at codespeak.net  Thu Dec  9 17:59:31 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 09 Dec 2010 16:59:31 +0000
Subject: [PyPy-issue] [issue605] Complete the 'os' module
Message-ID: <1291913971.03.0.430866975316.issue605@>


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

The following are the names (on Linux) found in the 'os' module on CPython but
missing on PyPy:

< confstr
< confstr_names
< ctermid
< fchdir
< fpathconf
< fstatvfs
< getgroups
< getloadavg
< getlogin
< killpg
< lchown
< major
< makedev
< minor
< mkfifo
< mknod
< nice
< openpty
< pathconf
< pathconf_names
< setgroups
< statvfs
< statvfs_result
< tcgetpgrp
< tcsetpgrp
< tempnam
< tmpnam
< wait3
< wait4

----------
effort: ???
messages: 1980
nosy: pypy-issue
priority: feature
release: ???
status: unread
title: Complete the 'os' module

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


From pypy-dev-issue at codespeak.net  Thu Dec  9 19:30:33 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Thu, 09 Dec 2010 18:30:33 +0000
Subject: [PyPy-issue] [issue577] pypy fails to be a virtualenv ouroboros
Message-ID: <1291919433.04.0.334923355647.issue577@>


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

this was not because of a pypy bug, but because virtualenv assumed a particular
directory layout that pypy hasn't.
It has been fixed in my virtualenv-pypy fork, I'll ask to merge it upstream:
http://bitbucket.org/antocuni/virtualenv-pypy/changeset/352a9bf21c85

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

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


From pypy-dev-issue at codespeak.net  Fri Dec 10 10:38:12 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Fri, 10 Dec 2010 09:38:12 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1291973892.04.0.574494625633.issue604@>


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

this was not because of a pypy bug, but because virtualenv failed to add the
correct plat-{mac,darwin} directories to sys.path.

It has been fixed in my virtualenv-pypy fork, I'll ask to merge it upstream:
http://bitbucket.org/antocuni/virtualenv-pypy/changeset/792c971f4114

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

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


From pypy-dev-issue at codespeak.net  Fri Dec 10 16:18:43 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Fri, 10 Dec 2010 15:18:43 +0000
Subject: [PyPy-issue] [issue603] fast-forward branch does not build on Mac
	OS X
Message-ID: <1291994323.04.0.90522981806.issue603@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

Here's an updated version of the patch, but it still doesn't work. When trying to build PyPy with CPython 
2.7 on Darwin/i386, it aborts with the following stack trace:


Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   _ctypes.so                          0x0170bbe3 B_get + 19
1   _ctypes.so                          0x01705255 Array_subscript + 325
2   org.python.python                   0x000a30d3 PyEval_EvalFrameEx + 14931

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   _ctypes.so                          0x0170bbe3 B_get + 19
1   _ctypes.so                          0x01705255 Array_subscript + 325
2   org.python.python                   0x000a30d3 PyEval_EvalFrameEx + 14931

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue603>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sem_t.diff
Type: application/octet-stream
Size: 1150 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101210/086916d4/attachment.obj>

From pypy-dev-issue at codespeak.net  Fri Dec 10 18:29:19 2010
From: pypy-dev-issue at codespeak.net (Martijn Faassen)
Date: Fri, 10 Dec 2010 17:29:19 +0000
Subject: [PyPy-issue] [issue606] support for the -E option
Message-ID: <1292002159.98.0.60223067774.issue606@>


New submission from Martijn Faassen <faassen at startifact.com>:

I've tested pypi with buildout (widely used to install Python-based projects),
but something in the installation process wants to invoke the python executable
with the -E option, and pypy (1.4) doesn't support that yet.

The option apparently does the following:
 
       -E     Ignore environment variables like PYTHONPATH and 
              PYTHONHOME that modify the behavior of the interpreter.

----------
effort: ???
messages: 1984
nosy: faassen, pypy-issue
priority: feature
release: 1.4
status: unread
title: support for the -E option

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


From pypy-dev-issue at codespeak.net  Fri Dec 10 18:30:42 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 10 Dec 2010 17:30:42 +0000
Subject: [PyPy-issue] [issue606] support for the -E option
Message-ID: <1292002242.33.0.52997227239.issue606@>


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

Thanks, already fixed some days ago.

(3 minutes -- the quickest resolved issue ever? :-)

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

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


From pypy-dev-issue at codespeak.net  Fri Dec 10 18:39:40 2010
From: pypy-dev-issue at codespeak.net (Martijn Faassen)
Date: Fri, 10 Dec 2010 17:39:40 +0000
Subject: [PyPy-issue] [issue606] support for the -E option
Message-ID: <1292002780.52.0.0887247013982.issue606@>


Martijn Faassen <faassen at startifact.com> added the comment:

Thanks very much! I'll try the development version.

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

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


From pypy-dev-issue at codespeak.net  Sat Dec 11 18:10:16 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Sat, 11 Dec 2010 17:10:16 +0000
Subject: [PyPy-issue] [issue607] hashlib.sha1() is slow
Message-ID: <1292087416.2.0.952223433217.issue607@>


New submission from Dan Villiom Podlaski Christiansen <danchr at gmail.com>:

The SHA-1 implementation in PyPy is approximately three times as slow as the one in CPython:

$ python2.5 -m timeit -n 1000 -s 'import hashlib; buf = file("/dev/random").read(100000)' 
'hashlib.sha1(buf)'
1000 loops, best of 3: 360 usec per loop
$ pypy -m timeit -n 1000 -s 'import hashlib; buf = file("/dev/random").read(100000)' 
'hashlib.sha1(buf)'1000 loops, best of 3: 1.16 msec per loop

This may be part of the explanation of why 'hg verify' takes twice as long with PyPy as it does CPython. I 
used the pypy-c-jit-79964-osx64 nightly build.

----------
effort: ???
messages: 1987
nosy: danchr, pypy-issue
priority: bug
release: ???
status: unread
title: hashlib.sha1() is slow

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


From pypy-dev-issue at codespeak.net  Sat Dec 11 18:20:46 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 11 Dec 2010 17:20:46 +0000
Subject: [PyPy-issue] [issue607] hashlib.sha1() is slow
Message-ID: <1292088046.16.0.328108899471.issue607@>


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

Something might still be wrong on Mac OS X.  With pypy-c-jit-79914-linux, I get
the result "394 usec per loop" for pypy versus "262 usec per loop" for CPython 2.5.

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

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


From pypy-dev-issue at codespeak.net  Sat Dec 11 18:56:16 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Sat, 11 Dec 2010 17:56:16 +0000
Subject: [PyPy-issue] [issue607] hashlib.sha1() is slow
Message-ID: <1292090176.22.0.145181283432.issue607@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

I checked, and it's definitely using the RPython implementation ??_hashlib seems much slower. Could you 
please try a 64-bit binary? That just might be the difference?

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


From pypy-dev-issue at codespeak.net  Sat Dec 11 19:03:49 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 11 Dec 2010 18:03:49 +0000
Subject: [PyPy-issue] [issue607] hashlib.sha1() is slow
Message-ID: <1292090629.04.0.179521876535.issue607@>


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

Indeed, I get "556 usec per loop".  That's worse than on 32 bits, which needs to
be investigated.  That's however still not the factor of 3.2x you see on Mac OS X...

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


From pypy-dev-issue at codespeak.net  Sat Dec 11 20:10:16 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 11 Dec 2010 19:10:16 +0000
Subject: [PyPy-issue] [issue607] hashlib.sha1() is slow
Message-ID: <1292094616.51.0.19336324201.issue607@>


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

The slowness of 64-bit builds was probably fixed by r79997.  All that remain is
the impression that pypy is a bit slower on Mac OS X, maybe 1.4x according to
the numbers here...

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


From pypy-dev-issue at codespeak.net  Sat Dec 11 22:48:53 2010
From: pypy-dev-issue at codespeak.net (Dan Stromberg)
Date: Sat, 11 Dec 2010 21:48:53 +0000
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
Message-ID: <1292104133.95.0.141726030319.issue608@>


New submission from Dan Stromberg <strombrg at gmail.com>:

At SVN URL http://stromberg.dnsalias.org/svn/gdbm-ctypes/trunk I have a module 
that provides gdbm support via ctypes, suitable for use with pypy.

It has two tests included with it:
1) A basic functionality test
2) Something that creates object churn in the garbage collector and uses 
gc.collect(), hoping to get this bug replicated.  Unfortunately, it fails to 
replicate the problem.

Then there's SVN URL http://stromberg.dnsalias.org/svn/backshift/trunk - the 
tests/70-pypy-gibberish test of which consistently fails with some stuff that 
looks like line noise in the keys.  The values are always fine.

With regard to creating a minimal test to reproduce the issue, I'm not certain 
I'll have time anymore, but I hope to find it somewhere.  However, I'm concerned 
this may prove to be a heisenbug, and that a minimal test may be elusive.

I'm getting this with a pypy trunk from late in the day on 2010-12-10, shortly 
after the 1.4 release.  pypy 1.4 also has the problem.  Uses this gdbm ctypes 
module with cpython 2.6 or cpython 3.1 works fine though.

----------
effort: ???
messages: 1992
nosy: pypy-issue, strombrg
priority: bug
release: 1.4
status: unread
title: Gibberish from ctypes

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


From pypy-dev-issue at codespeak.net  Sun Dec 12 15:30:35 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sun, 12 Dec 2010 14:30:35 +0000
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
Message-ID: <1292164235.47.0.553961824037.issue608@>


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

May I ask you if you can make it a bit more portable, or else mention explicitly
what we need to install?  I cannot run the tests, because I have no
/usr/share/jpilot and because I have no module called "readline0".  (I didn't
try further, there might be other dependencies.)

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

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


From pypy-dev-issue at codespeak.net  Sun Dec 12 18:52:38 2010
From: pypy-dev-issue at codespeak.net (Martijn Faassen)
Date: Sun, 12 Dec 2010 17:52:38 +0000
Subject: [PyPy-issue] [issue609] different behavior for subprocess?
Message-ID: <1292176358.81.0.0543977921873.issue609@>


New submission from Martijn Faassen <faassen at startifact.com>:

I'm trying to make zc.buildout work with the PyPy trunk (1.4 release won't work
due to missing support for the -E) option. I actually made an older version,
buildout 1.4.3, work, but the most recent release, buildout 1.5.2, fails on PyPy
due to a problem with this code:

def _has_broken_dash_S(executable):
    """Detect https://bugs.launchpad.net/virtualenv/+bug/572545 ."""
    # The first attempt here was to simply have the executable attempt to import
    # ConfigParser and return the return code. That worked except for tests on
    # Windows, where the return code was wrong for the fake Python executable
    # generated by the virtualenv.txt test, apparently because setuptools' .exe
    # file does not pass the -script.py's returncode back properly, at least in
    # some circumstances. Therefore...print statements.
    stdout, stderr = subprocess.Popen(
        [executable, '-Sc',
         'try:\n'
         '    import ConfigParser\n'
         'except ImportError:\n'
         '    print 1\n'
         'else:\n'
         '    print 0\n'],
        stdout=subprocess.PIPE, stderr=subprocess.PIPE).communicate()
    return bool(int(stdout.strip()))

This fails because stdout.strip() actually gives an empty string instead of the
value expected. 

It's of course possible that this an issue in zc.buildout (missing
stdout.flush()?), but I'm reporting it here just in case it's a pypy issue.

----------
effort: ???
messages: 1994
nosy: faassen, pypy-issue
priority: bug
release: ???
status: unread
title: different behavior for subprocess?

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


From pypy-dev-issue at codespeak.net  Sun Dec 12 18:54:01 2010
From: pypy-dev-issue at codespeak.net (Martijn Faassen)
Date: Sun, 12 Dec 2010 17:54:01 +0000
Subject: [PyPy-issue] [issue609] different behavior for subprocess?
Message-ID: <1292176441.6.0.739124615309.issue609@>


Martijn Faassen <faassen at startifact.com> added the comment:

The zc.buildout bug report is here:

https://bugs.launchpad.net/zc.buildout/+bug/689344

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

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


From pypy-dev-issue at codespeak.net  Sun Dec 12 18:57:42 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sun, 12 Dec 2010 17:57:42 +0000
Subject: [PyPy-issue] [issue609] different behavior for subprocess?
Message-ID: <1292176662.8.0.922410102099.issue609@>


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

Bah, the issue is simply passing -Sc instead of -S -c.  PyPy's option parsing is
a bit less flexible than CPython's here.  If you do

    pypy -Sc 'print 42'

you see the error message: unrecognized option '-Sc'.

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


From pypy-dev-issue at codespeak.net  Sun Dec 12 19:05:12 2010
From: pypy-dev-issue at codespeak.net (Martijn Faassen)
Date: Sun, 12 Dec 2010 18:05:12 +0000
Subject: [PyPy-issue] [issue609] different behavior for subprocess?
Message-ID: <1292177112.87.0.803541886548.issue609@>


Martijn Faassen <faassen at startifact.com> added the comment:

For what it's worth, here's some info on how PyPy is doing with a project I'm
currently working on:

http://comments.gmane.org/gmane.comp.python.wsgi.fanstatic/62

(awesome job!)

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


From pypy-dev-issue at codespeak.net  Sun Dec 12 19:05:36 2010
From: pypy-dev-issue at codespeak.net (Martijn Faassen)
Date: Sun, 12 Dec 2010 18:05:36 +0000
Subject: [PyPy-issue] [issue609] different behavior for subprocess?
Message-ID: <1292177136.74.0.206228575476.issue609@>


Martijn Faassen <faassen at startifact.com> added the comment:

Ah, thanks, I'll report that back to the buildout guys.

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


From pypy-dev-issue at codespeak.net  Sun Dec 12 19:08:35 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sun, 12 Dec 2010 18:08:35 +0000
Subject: [PyPy-issue] [issue609] different behavior for subprocess?
Message-ID: <1292177315.45.0.0906490337857.issue609@>


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

Ah, no, sorry.  I meant to say: it's a bug in PyPy.  There is no reason it won't
be fixed by tomorrow morning :-)

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


From pypy-dev-issue at codespeak.net  Mon Dec 13 04:14:52 2010
From: pypy-dev-issue at codespeak.net (Dan Stromberg)
Date: Mon, 13 Dec 2010 03:14:52 +0000
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
In-Reply-To: <AANLkTimjcGsNz=Ju-APUpqD3G6hNPfWCMMXnDttrdOVN@mail.gmail.com>
Message-ID: <AANLkTinTrmd_Rv2mmwzr2KFbMEvHq14vWDTKBLoihq_7@mail.gmail.com>


Dan Stromberg <strombrg at gmail.com> added the comment:

I've attached a copy of the files fed to backshift that lead to the
gibberish from ctypes (gdbm).  I tried to check them into my SVN, but SVN is
confused by one of the filenames because it isn't valid UTF-8.

On Sun, Dec 12, 2010 at 4:29 PM, Dan Stromberg <pypy-dev-issue at codespeak.net
> wrote:

>
> Dan Stromberg <strombrg at gmail.com> added the comment:
>
> Yes, you certainly may ask.  I'll try to find time for this soon, but I'm
> starting a new contract tomorrow morning, and I have a bunch of paperwork
> to
> fill out today.
>
> I'm kind of surprised you didn't get a readline0 when you checked out
> backshift - I believe it's in there as an SVN "external reference".  Did
> you
> check it out using mercurial or git as an interface to svn, by any chance?
>  ISTR that they don't do external references.  Either way, readline0 is at
> http://stromberg.dnsalias.org/svn/readline0/trunk/ .
>
> About jpilot - I'll copy that over sometime soon.  You might be able to get
> the files by installing a jpilot deb/rpm on your Linux system.
>
> On Sun, Dec 12, 2010 at 6:30 AM, Armin Rigo <pypy-dev-issue at codespeak.net
> >wrote:
>
> >
> > Armin Rigo <armin.rigo at gmail.com> added the comment:
> >
> > May I ask you if you can make it a bit more portable, or else mention
> > explicitly
> > what we need to install?  I cannot run the tests, because I have no
> > /usr/share/jpilot and because I have no module called "readline0".  (I
> > didn't
> > try further, there might be other dependencies.)
> >
> > ----------
> > status: unread -> chatting
> >
> > _______________________________________________________
> > PyPy development tracker <pypy-dev-issue at codespeak.net>
> > <https://codespeak.net/issue/pypy-dev/issue608>
> > _______________________________________________________
> >
>
>
>
> --
> Dan Stromberg
>
> _______________________________________________________
> PyPy development tracker <pypy-dev-issue at codespeak.net>
> <https://codespeak.net/issue/pypy-dev/issue608>
> _______________________________________________________
>



-- 
Dan Stromberg

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue608>
_______________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101213/c89d8a32/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: files.tar.gz
Type: application/x-gzip
Size: 4193 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101213/c89d8a32/attachment.bin>

From pypy-dev-issue at codespeak.net  Mon Dec 13 13:44:45 2010
From: pypy-dev-issue at codespeak.net (Axel Gembe)
Date: Mon, 13 Dec 2010 12:44:45 +0000
Subject: [PyPy-issue] [issue592] trackgcroot.py fails with AssertionError on
	Gentoo x64
Message-ID: <1292244285.42.0.23125178244.issue592@>


Axel Gembe <ago at bastart.eu.org> added the comment:

Recompiling gcc and glibc with -hardened solved the issue.

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

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


From pypy-dev-issue at codespeak.net  Wed Dec 15 11:53:18 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 15 Dec 2010 10:53:18 +0000
Subject: [PyPy-issue] [issue590] Add Mercurial version information to sys
	module
Message-ID: <1292410398.79.0.0339538511075.issue590@>


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

The current situation is that we need to rewrite pypy/module/sys/version.py.  It
is still based on reading svn information.

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

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


From pypy-dev-issue at codespeak.net  Wed Dec 15 11:55:34 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Wed, 15 Dec 2010 10:55:34 +0000
Subject: [PyPy-issue] [issue590] Add Mercurial version information to sys
	module
Message-ID: <1292410534.42.0.64933975281.issue590@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

I agree. Strictly speaking, though, I'd say this bug is fixed as we now at least have the information.

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

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


From pypy-dev-issue at codespeak.net  Wed Dec 15 12:02:27 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 15 Dec 2010 11:02:27 +0000
Subject: [PyPy-issue] [issue607] hashlib.sha1() is slow
Message-ID: <1292410947.53.0.0391478691075.issue607@>


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

Closing as resolved.  The Mac OS X slowness might be another issue, if someone
thinks it is important.

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

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


From pypy-dev-issue at codespeak.net  Wed Dec 15 12:02:50 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 15 Dec 2010 11:02:50 +0000
Subject: [PyPy-issue] [issue609] different behavior for subprocess?
Message-ID: <1292410970.02.0.710947297313.issue609@>


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

Fixed.

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

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


From pypy-dev-issue at codespeak.net  Thu Dec 16 19:44:49 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Thu, 16 Dec 2010 18:44:49 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292525089.19.0.225358270157.issue610@>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

$ execstack -q ./pypy
X ./pypy

$ eu-readelf -l ./pypy | grep STACK
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8

Note that the stack is marked as "RWE", not just "RW".

>From IRC chat on #pypy earlier:
<dmalcolm> random ELF-hardening question: does a pypy-jit process' stack need to be executable for any reason?
<dmalcolm> (ideally not)
<Alex_Gaynor> The stack?  I wouldn't think so, we obviously mark some regions of the heap as executable for the machine code.
<arigato> dmalcolm: no, no reason, as long as gcc doesn't add its own (from the regular ANSI C code we produce)

If we don't need the process' stacks to be executable, they shouldn't be, preventing some kinds of buffer-overflow attacks (perhaps 
in extension modules and other libraries).


The GNU toolchain attempts to determine if a binary/shared library needs its processes' threads' stacks to be executable.

As I understand things, typically when gcc builds a binary, it goes from .c via .o files, and the compiler "knows" that the code 
doesn't need an executable stack, and thus embeds:
   .section .note.GNU-stack,"", at progbits
in every .o file built from a .c file.

This typically fails for assembler files (.s): the assembler can't determine if the resulting machine code would need an executable 
stack, and thus pessimistically omits the no-exec-stack flag.

One workaound may be to add:
   .section .note.GNU-stack,"", at progbits
to every .s file, though that may be gcc-specific.

However, the generated Makefile creates the executable ("TARGET") by passing all of the .lbl.s files to gcc, using LDFLAGS, so it may 
be fixable by ensuring that LDFLAGS contains "--no-exec-stack" (I'm currently trying a build to verify this).

Alternatively, one can simply run:
  execstack --clear-execstack PATH_TO_ELF_FILE
to remove the tainted bit from the ELF file's internal metadata.


(See also Appendix A of http://people.redhat.com/drepper/nonselsec.pdf for more info on this)

----------
effort: easy
messages: 2007
nosy: dmalcolm, pypy-issue
priority: bug
release: 1.4
status: unread
title: The generated pypy binary is unnecessarily flagged as needing an executable stack

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


From pypy-dev-issue at codespeak.net  Thu Dec 16 19:56:37 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Thu, 16 Dec 2010 18:56:37 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292525797.54.0.0673631976701.issue610@>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

The
  LDFLAGS=--no-exec-stack make pypy
approach doesn't seem to work; I still end up with a binary that requests an executable stack:
  $ eu-readelf -l ./pypy | grep STACK
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8

Simplest solution is probably to postprocess the ELF file with "execstack":
  $ execstack --clear-execstack PATH_TO_ELF_FILE
  $ eu-readelf -l ./pypy | grep STACK
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x8

(all of this is on a Fedora box, BTW; I believe the relevant tools are within the upstream GNU toolchain though)

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

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


From pypy-dev-issue at codespeak.net  Thu Dec 16 20:00:49 2010
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Thu, 16 Dec 2010 19:00:49 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292526049.79.0.412450735792.issue610@>


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

FWIW execstack is not installed by default on Ubuntu, nor is it included with
binutils and whatever else I've installed for the compiler toolchain.

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


From pypy-dev-issue at codespeak.net  Thu Dec 16 20:03:16 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Thu, 16 Dec 2010 19:03:16 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292526196.88.0.679202014924.issue610@>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

It's part of the "prelink" package on Fedora, and, by the looks of it, on Ubuntu 
also:
  https://launchpad.net/ubuntu/karmic/+package/execstack

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


From pypy-dev-issue at codespeak.net  Thu Dec 16 20:11:04 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Thu, 16 Dec 2010 19:11:04 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292526664.47.0.649967461256.issue610@>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

To be pedantic, with:
  LDFLAGS=--no-exec-stack make pypy
the option wasn't making it to the "gcc" invocation, whereas with:
  make pypy LDFLAGSEXTRA=--no-exec-stack
the option _does_ appear in gcc's invocation.

However in both cases, the ELF file is still erroneously flagged :(

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


From pypy-dev-issue at codespeak.net  Fri Dec 17 11:31:11 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 17 Dec 2010 10:31:11 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292581871.4.0.829040891385.issue610@>


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

I may be wrong, but I thought that gcc *always* goes via .s files internally. 
So I don't believe that this is what is causing the difference.

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


From pypy-dev-issue at codespeak.net  Fri Dec 17 11:34:16 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 17 Dec 2010 10:34:16 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292582056.04.0.905286110366.issue610@>


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

Ah, sorry, I realized just after I posted the previous comment that there is a
difference: we have an extra file, gcmaptable.s, that we built from scratch.  Of
course it does not contain the magic line ".section
.note.GNU-stack,"", at progbits".  This is really the issue here.

Maybe we can solve it like amaury solved it for MSVC: by instead generating a
gcmaptable.c, instead of directly the gcmaptable.s.

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


From pypy-dev-issue at codespeak.net  Fri Dec 17 14:50:02 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 17 Dec 2010 13:50:02 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292593802.93.0.0948654582655.issue610@>


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

Reading the gcc documentation, it looks like it would be a mess to write a
function in C that turns to some exact piece of assembler (with no prologue or
epilogue).  Closing as "wontfix" for now.  You are free of course to add
"execstack" to the PyPy build system on Fedora, or to propose a patch that adds
the magic line to gcmaptable.s if done carefully enough (e.g. by checking that
the same line was used in another .s file), or even maybe that compiles the .s
file not alone but #included from another .lbl.s file (obscure workaround).

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

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


From pypy-dev-issue at codespeak.net  Fri Dec 17 14:57:59 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 17 Dec 2010 13:57:59 +0000
Subject: [PyPy-issue] [issue402] codecs are broken in pypy-c
Message-ID: <1292594279.31.0.984571616485.issue402@>


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

Resolved long ago, maybe?

----------
nosy: +pypy-issue -ac, arigo, cfbolz, fijal, mwh, pedronis, tismer
status: unread -> resolved

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


From pypy-dev-issue at codespeak.net  Fri Dec 17 16:33:28 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Fri, 17 Dec 2010 15:33:28 +0000
Subject: [PyPy-issue] [issue610] The generated pypy binary is unnecessarily
	flagged as needing an executable stack
Message-ID: <1292600008.5.0.287725863838.issue610@>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks.

FWIW, in my downstream RPM packaging of pypy for Fedora[1] I've written the build so that it 
invokes the execstack workaround upon the built binary (after the translate.py is done).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=588941

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


From pypy-dev-issue at codespeak.net  Sun Dec 19 19:20:27 2010
From: pypy-dev-issue at codespeak.net (Dan Stromberg)
Date: Sun, 19 Dec 2010 18:20:27 +0000
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
In-Reply-To: <AANLkTinTrmd_Rv2mmwzr2KFbMEvHq14vWDTKBLoihq_7@mail.gmail.com>
Message-ID: <AANLkTimdLrN4eOLeaDJSmsSJ412ACWQdS-8Z_KaFMaOA@mail.gmail.com>


Dan Stromberg <strombrg at gmail.com> added the comment:

I checked the files into tests/70-pypy-gibberish/ using a modified filename
that doesn't confuse SVN.

I continue to have very little free time.

On Sun, Dec 12, 2010 at 7:14 PM, Dan Stromberg <strombrg at gmail.com> wrote:

>
> I've attached a copy of the files fed to backshift that lead to the
> gibberish from ctypes (gdbm).  I tried to check them into my SVN, but SVN is
> confused by one of the filenames because it isn't valid UTF-8.
>
> On Sun, Dec 12, 2010 at 4:29 PM, Dan Stromberg <
> pypy-dev-issue at codespeak.net> wrote:
>
>>
>> Dan Stromberg <strombrg at gmail.com> added the comment:
>>
>>
>> Yes, you certainly may ask.  I'll try to find time for this soon, but I'm
>> starting a new contract tomorrow morning, and I have a bunch of paperwork
>> to
>> fill out today.
>>
>> I'm kind of surprised you didn't get a readline0 when you checked out
>> backshift - I believe it's in there as an SVN "external reference".  Did
>> you
>> check it out using mercurial or git as an interface to svn, by any chance?
>>  ISTR that they don't do external references.  Either way, readline0 is at
>> http://stromberg.dnsalias.org/svn/readline0/trunk/ .
>>
>> About jpilot - I'll copy that over sometime soon.  You might be able to
>> get
>> the files by installing a jpilot deb/rpm on your Linux system.
>>
>> On Sun, Dec 12, 2010 at 6:30 AM, Armin Rigo <pypy-dev-issue at codespeak.net
>> >wrote:
>>
>> >
>> > Armin Rigo <armin.rigo at gmail.com> added the comment:
>> >
>> > May I ask you if you can make it a bit more portable, or else mention
>> > explicitly
>> > what we need to install?  I cannot run the tests, because I have no
>> > /usr/share/jpilot and because I have no module called "readline0".  (I
>> > didn't
>> > try further, there might be other dependencies.)
>> >
>> > ----------
>> > status: unread -> chatting
>> >
>> > _______________________________________________________
>> > PyPy development tracker <pypy-dev-issue at codespeak.net>
>> > <https://codespeak.net/issue/pypy-dev/issue608>
>> > _______________________________________________________
>> >
>>
>>
>>
>> --
>> Dan Stromberg
>>
>> _______________________________________________________
>> PyPy development tracker <pypy-dev-issue at codespeak.net>
>> <https://codespeak.net/issue/pypy-dev/issue608>
>> _______________________________________________________
>>
>
>
>
> --
> Dan Stromberg
>



-- 
Dan Stromberg

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue608>
_______________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101219/5501a1ee/attachment.html>

From pypy-dev-issue at codespeak.net  Mon Dec 20 06:31:06 2010
From: pypy-dev-issue at codespeak.net (Jean-Paul Calderone)
Date: Mon, 20 Dec 2010 05:31:06 +0000
Subject: [PyPy-issue] [issue611] StreamReader.decode does not accept `None`
	for the errors parameter
Message-ID: <1292823066.06.0.664742914328.issue611@>


New submission from Jean-Paul Calderone <exarkun at twistedmatrix.com>:

Came across this while trying out Cython on PyPy:

exarkun at boson:~$ python -c '                                     
from encodings import utf_8
from StringIO import StringIO
r = utf_8.StreamReader(StringIO("foo"))
print r.decode("bar", None)
'
(u'bar', 3)
exarkun at boson:~$ /tmp/pypy-c-jit-40134-42164a893f20-linux/bin/pypy -c '
from encodings import utf_8
from StringIO import StringIO
r = utf_8.StreamReader(StringIO("foo"))
print r.decode("bar", None)
'
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "app_main.py", line 486, in run_it
  File "<string>", line 5, in <module>
TypeError: expected string, got NoneType object
exarkun at boson:~$ 

This happens really early in Cython's compile process, preventing anything 
interesting from happening.

----------
effort: ???
messages: 2018
nosy: calderone, pypy-issue
priority: bug
release: 1.4
status: unread
title: StreamReader.decode does not accept `None` for the errors parameter

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


From pypy-dev-issue at codespeak.net  Mon Dec 20 13:25:06 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 20 Dec 2010 12:25:06 +0000
Subject: [PyPy-issue] [issue611] StreamReader.decode does not accept `None`
	for the errors parameter
Message-ID: <1292847906.39.0.559299834032.issue611@>


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

Obscure.  Looking around, it seems that all functions _codecs.decode_xxx(), but
not _codecs.decode() itself, accept None and treat it as meaning "strict".

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

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


From pypy-dev-issue at codespeak.net  Mon Dec 20 13:44:36 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 20 Dec 2010 12:44:36 +0000
Subject: [PyPy-issue] [issue611] StreamReader.decode does not accept `None`
	for the errors parameter
Message-ID: <1292849076.53.0.848409271414.issue611@>


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

Fixed by 3558359bebfa.

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

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


From pypy-dev-issue at codespeak.net  Mon Dec 20 15:34:54 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 20 Dec 2010 14:34:54 +0000
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
Message-ID: <1292855694.94.0.0535083699643.issue608@>


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

Ok, next dependency is treap: I checked out
http://stromberg.dnsalias.org/svn/treap/trunk but there is no treap.py.  It
appears to be a Cython module, but that is known not to compile with pypy.  What
should I do?

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


From pypy-dev-issue at codespeak.net  Tue Dec 21 07:46:00 2010
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 21 Dec 2010 06:46:00 +0000
Subject: [PyPy-issue] [issue596] Adding Mako template engine benchmark to
	benchmarks.
Message-ID: <1292913959.99.0.669375270638.issue596@>


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

Added in 80090. Sorry it took so long...

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

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


From pypy-dev-issue at codespeak.net  Tue Dec 21 09:16:09 2010
From: pypy-dev-issue at codespeak.net (=?utf-8?q?=C5=81ukasz_Fidosz?=)
Date: Tue, 21 Dec 2010 08:16:09 +0000
Subject: [PyPy-issue] [issue596] Adding Mako template engine benchmark to
	benchmarks.
Message-ID: <1292919369.11.0.387175582662.issue596@>


?ukasz Fidosz <virhilo at gmail.com> added the comment:

thanks

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

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


From pypy-dev-issue at codespeak.net  Tue Dec 21 14:57:02 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 21 Dec 2010 13:57:02 +0000
Subject: [PyPy-issue] [issue587] [PATCH] Plain 'strip' in package.py breaks
	cpyext on Mac OS X
Message-ID: <1292939822.04.0.622718307217.issue587@>


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

'strip -x' leaves behind a lot of symbols, making the Linux executables 10MB
bigger than they need to be --- it seems that a full 'strip' does not hurt pypy
on Linux.  So for now I will do 'strip -x' only on Mac OS X.  Does this sound
reasonable?

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

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


From pypy-dev-issue at codespeak.net  Tue Dec 21 22:56:49 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Tue, 21 Dec 2010 21:56:49 +0000
Subject: [PyPy-issue] [issue612] 1.4.1 source tarball embeds .svn directories
Message-ID: <1292968609.14.0.0586376203206.issue612@>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

FWIW, the 1.4.1 source tarball contains numerous ".svn" metadata directories.

$ md5sum ../../SOURCES/pypy-1.4.1-src.tar.bz2
ebbbb156b1eb842e9e65d909ed5f9f6d  ../../SOURCES/pypy-1.4.1-src.tar.bz2

$ tar -tvjf ../../SOURCES/pypy-1.4.1-src.tar.bz2 | grep "\.svn" | wc -l
245

By contrast, 1.4 didn't have these directories, with just:
$ tar -tvjf ../../SOURCES/pypy-1.4-src.tar.bz2 | grep "\.svn"
-rw-r--r-- fijal/fijal      45 2010-05-06 13:06 pypy-1.4/py/bin/win32/py.svnwcrevert.cmd
-rwxr-xr-x fijal/fijal      71 2010-05-06 13:06 pypy-1.4/py/bin/py.svnwcrevert

Debatable whether this is a bug or not; I'm guessing this is a minor glitch due to the svn->hg 
migration.

----------
effort: ???
messages: 2025
nosy: dmalcolm, pypy-issue
priority: bug
release: 1.4
status: unread
title: 1.4.1 source tarball embeds .svn directories

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


From pypy-dev-issue at codespeak.net  Wed Dec 22 08:09:39 2010
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Wed, 22 Dec 2010 07:09:39 +0000
Subject: [PyPy-issue] [issue613] utf_8_decode (and probably others) doesn't
	take None for errors argument
Message-ID: <1293001779.1.0.716720911037.issue613@>


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

alex at alex-laptop:~/projects/pypy$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from codecs import utf_8_decode
>>> utf_8_decode("a", '')
(u'a', 1)
>>> utf_8_decode("a", None)
(u'a', 1)
>>> 
alex at alex-laptop:~/projects/pypy$ ./pypy-c 
Python 2.5.2 (2088ce763fc2, Dec 15 2010, 20:39:16)
[PyPy 1.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``"Why do we end up in a non common
case in the common case?" (fijal)''
>>>> from codecs import utf_8_decode
>>>> utf_8_decode("a", None)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: expected string, got NoneType object

----------
effort: easy
messages: 2026
nosy: agaynor, pypy-issue
priority: bug
release: 1.4
status: unread
title: utf_8_decode (and probably others) doesn't take None for errors argument

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


From pypy-dev-issue at codespeak.net  Wed Dec 22 09:02:58 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Wed, 22 Dec 2010 08:02:58 +0000
Subject: [PyPy-issue] [issue612] 1.4.1 source tarball embeds .svn directories
Message-ID: <1293004978.61.0.763285735218.issue612@>


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

it seems that the only .svn directories left are the ones in svn externals
(testrunner, greenlet, sqlite3 and pyrepl). Armin, how was the source tarball
created?

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

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


From pypy-dev-issue at codespeak.net  Wed Dec 22 11:08:36 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 22 Dec 2010 10:08:36 +0000
Subject: [PyPy-issue] [issue613] utf_8_decode (and probably others) doesn't
	take None for errors argument
Message-ID: <1293012516.85.0.785945145039.issue613@>


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

Thanks.  Fixed in c6cbca5bad3a, I hope.  I think that the remaining places that
take an "errors" argument all require a non-None value also on CPython.  Please
re-open this issue if I *still* have forgotten some place.

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

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


From pypy-dev-issue at codespeak.net  Wed Dec 22 11:10:53 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 22 Dec 2010 10:10:53 +0000
Subject: [PyPy-issue] [issue612] 1.4.1 source tarball embeds .svn directories
Message-ID: <1293012653.67.0.234993565969.issue612@>


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

I just made a fresh hg clone and removed the .hg directory, so indeed, I forgot
the .svn in the small svn external subdirectories.  I don't think we should
care, as it's small anyway (the number 245 is probably the total number of files
in these subdirectories).

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

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


From pypy-dev-issue at codespeak.net  Wed Dec 22 11:12:03 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 22 Dec 2010 10:12:03 +0000
Subject: [PyPy-issue] [issue587] [PATCH] Plain 'strip' in package.py breaks
	cpyext on Mac OS X
Message-ID: <1293012723.24.0.527048924999.issue587@>


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

I can't test whether this is really the issue or not.  As far as I can tell,
pypy-1.4.1-osx(64).tar.bz2 were created with "strip -x", but cpyext still
segfaults completely there.

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


From pypy-dev-issue at codespeak.net  Thu Dec 23 02:54:02 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Thu, 23 Dec 2010 01:54:02 +0000
Subject: [PyPy-issue] [issue614] Packaging PyPy: installation path for
	PyPy's libraries
Message-ID: <1293069242.66.0.789471767917.issue614@>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

Short version:

I'm working on packaging PyPy in RPM form for Fedora; see:
  https://bugzilla.redhat.com/show_bug.cgi?id=588941
and ran into an issue with how the pypy binary searches for its libraries.

I'm attaching a patch I've written that fixes things, though it's not good enough 
yet to be applied to hg.

Long version:

As I understand things, PyPy's prebuilt tarballs have a directory structure 
generated by pypy/tool/release/package.py.

Looking at e.g.
  http://pypy.org/download/pypy-1.4.1-linux64.tar.bz2
everything is below:
  pypy-1.4.1-linux64/
with:
  pypy-1.4.1-linux64/lib_pypy/
  pypy-1.4.1-linux64/lib-python/
  pypy-1.4.1-linux64/lib-python/2.5.2/*.py (and subdirs)
  pypy-1.4.1-linux64/lib-python/modified-2.5.2/*.py (and subdirs)
  pypy-1.4.1-linux64/site-packages/*.py
  pypy-1.4.1-linux64/bin/pypy (the JIT binary)
  pypy-1.4.1-linux64/include/ (some header files)

(See also pypy/tool/release/test/test_package.py, which verifies this structure)

This works for a standalone distribution of PyPy.

However, eventually Linux distribution will want to ship "system" builds of PyPy, 
deployed as .rpmor .deb packages.  Those packages ideally ought to follow the layout 
recommendations of the Filesystem Hierarchy Standard:
  http://www.pathname.com/fhs/

In particular this suggests separating out programs (to /usr/bin) from libraries (to 
/usr/lib) and data (/usr/share).

Exactly where the pypy libraries should go is debatable; they're all architecture-
independent for now, but I hope we'll soon have a rich collection of extension 
modules that are stable enough to package.

So I'm attempting to split the libraries out to /usr/lib (and /usr/lib64 on 64-bit, 
which is a Fedora-ism, AIUI).

My naive attempt to do this leads to a /usr/bin/pypy which emits this message at 
startup:
$ pypy-jit
debug: WARNING: library path not found, using compiled-in sys.path
'import site' failed
Python 2.5.2 (78826, Dec 15 2010, 01:41:24)
[PyPy 1.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
debug: OperationError:
debug:  operror-type: ImportError
debug:  operror-value: No module named _pypy_interact

and has this sys.path:
$ pypy -c 'import sys; print sys.path'
debug: WARNING: library path not found, using compiled-in sys.path
'import site' failed
['', '/builddir/build/BUILD/pypy-1.4/lib_pypy',
'/builddir/build/BUILD/pypy-1.4/lib-python/modified-2.5.2',
'/builddir/build/BUILD/pypy-1.4/lib-python/2.5.2',
'/builddir/build/BUILD/pypy-1.4/lib-python/2.5.2/plat-linux2']

pypy/translator/goal/app_main.py's startup code calls into sys's state.py, which 
has:
  def getinitialpath(prefix):
which searches for the dirs, raising OSError if they're not found.  If they're all 
their, it returns them in a list.

app_main wraps this as sys.pypy_initial_path, turning OSError into a return of None.

I'm attaching a proof-of-concept patch which adds an initial search for the 
directory structure, this time within LIBRARY_INSTALLATION_PATH.

Ideally this would be an optional, configuration-supplied constant, but for now, 
this is a non-existant variable, which I pre-process within the build, using sed, 
thus:
  sed -i \
    -e 's|LIBRARY_INSTALLATION_PATH|"%{pypyprefix}"|' \
    pypy/translator/goal/app_main.py

where %{pypyprefix} is expanded by another tool, giving the string literal 
"/usr/lib64/pypy-1.4.1"

I wanted to prove the concept, and hour-long builds make for tedious experimentation 
:(

Presumably this should be something like a:
  --library-installation-path=/usr/lib
that gets passed to the translate.py

Building with this patch (with the above caveat), I obtain a binary that, when 
copied to /usr/bin/pypy, successfully finds its libraries within our downstream 
distribution's directory structure (under /usr/lib64/pypy-1.4.1 on this build):

$ pypy
Python 2.5.2 (, Dec 22 2010, 23:14:02)
[PyPy 1.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy is an exciting technology
that lets you to write fast, portable, multi-platform interpreters with less
effort''
>>>> import sys
>>>> sys.path
['', '/usr/lib64/pypy-1.4.1/lib_pypy', '/usr/lib64/pypy-1.4.1/lib-python/modified-
2.5.2', '/usr/lib64/pypy-1.4.1/lib-python/2.5.2', '/usr/lib64/pypy-1.4.1/lib-
python/2.5.2/plat-linux2', '/usr/lib64/pypy-1.4.1/site-packages']

and also successfully finds its libraries within the build tree, when run from there 
in the usual "goal" subdirectory.
>>>> import collections
>>>> collections.__file__
'/usr/lib64/pypy-1.4.1/lib_pypy/collections.pyc'

----------
effort: ???
files: pypy-1.4.1-add-LIBRARY_INSTALLATION_PATH.patch
messages: 2031
nosy: dmalcolm, pypy-issue
priority: feature
release: ???
status: unread
title: Packaging PyPy: installation path for PyPy's libraries

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue614>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy-1.4.1-add-LIBRARY_INSTALLATION_PATH.patch
Type: text/x-patch
Size: 542 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101223/f1dda35b/attachment.bin>

From pypy-dev-issue at codespeak.net  Thu Dec 23 02:56:49 2010
From: pypy-dev-issue at codespeak.net (Dave Malcolm)
Date: Thu, 23 Dec 2010 01:56:49 +0000
Subject: [PyPy-issue] [issue614] Packaging PyPy: installation path for
	PyPy's libraries
Message-ID: <1293069409.37.0.738873349629.issue614@>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Gah; the last quoted interpreter fragment is from /usr/bin/pypy

However, I'm running the built binary through most of test.regrtest as a checking 
phase in my builds, invoking it from pypy/translator/goal , so I do have test 
coverage for that.

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

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


From pypy-dev-issue at codespeak.net  Thu Dec 23 06:10:17 2010
From: pypy-dev-issue at codespeak.net (Steve Smith)
Date: Thu, 23 Dec 2010 05:10:17 +0000
Subject: [PyPy-issue] [issue615] Errors when using urllib with SSL
Message-ID: <1293081017.1.0.915631179687.issue615@>


New submission from Steve Smith <tarkasteve at gmail.com>:

urllib returns various errors when accessing SSL sites.  Example code below.

With Google it throws "sslerror: EOF occurred in violation of protocol: 8"; with
most other (e.g. https://www.atlassian.com/) it throws "sslerror: TLS/SSL
connection has been closed: 6".

Code:

import urllib
import sys

url="https://encrypted.google.com/"
if len(sys.argv) > 1:
    url = sys.argv[1]

fd = urllib.urlopen(url)

count = 0
for line in fd:
    count += 1
    print "\rLine", count,

----------
effort: ???
messages: 2033
nosy: pypy-issue, tarkasteve
priority: bug
release: ???
status: unread
title: Errors when using urllib with SSL

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


From pypy-dev-issue at codespeak.net  Thu Dec 23 10:32:41 2010
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Thu, 23 Dec 2010 09:32:41 +0000
Subject: [PyPy-issue] [issue614] Packaging PyPy: installation path for
	PyPy's libraries
Message-ID: <1293096760.99.0.00244919664385.issue614@>


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

Note that until some time ago, pypy did support the classic unix installation
scheme, so you could install it like this:
/usr/bin/pypy
/usr/lib/pypy1.4.1/lib-python/
...

However maintaining multiple installation schemes is a mess, because there are
too many places to keep in sync, including external tools like virtualenv, so it
was decided to support just the current installation scheme:
https://bitbucket.org/pypy/pypy/changeset/9ee66966dfb7

E.g., does virtualenv work with your patch?

What you could do instead is:
1) install pypy in /opt/pypy and put a symlink in /usr/bin pointing to
/opt/pypy/bin/pypy

2) alternatively, install pypy in /usr/lib/pypy and put a symlink in /usr/bin
pointing to /usr/lib/pypy/bin/pypy

Sidenote: you don't need a full translation to test this stuff: look e.g.
translator/goal/test2/test_app_main.py

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


From pypy-dev-issue at codespeak.net  Thu Dec 23 12:20:40 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 23 Dec 2010 11:20:40 +0000
Subject: [PyPy-issue] [issue614] Packaging PyPy: installation path for
	PyPy's libraries
Message-ID: <1293103240.81.0.0830283417743.issue614@>


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

I think it's still a good thing to do.  At least it would work to have an option
like --library-installation-path=/usr/lib/pypy-1.4.1 to pass to translate.py,
which would just replace the default search path -- the default search path is a
bit useless for installing pypy.

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


From pypy-dev-issue at codespeak.net  Fri Dec 24 14:48:19 2010
From: pypy-dev-issue at codespeak.net (Dan Villiom Podlaski Christiansen)
Date: Fri, 24 Dec 2010 13:48:19 +0000
Subject: [PyPy-issue] [issue586] Show a traceback when an exception is
	raised in a destructor
Message-ID: <1293198499.23.0.129755497554.issue586@>


Dan Villiom Podlaski Christiansen <danchr at gmail.com> added the comment:

Okay, I saw them again now:

a destructor of type pypy.module._file.interp_file.W_File raised an exception <OSError object at 
0x101d00078> ignoring it

This is much better, but it would be even nicer if you could print out a string representation of the 
exception too :-)

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


From pypy-dev-issue at codespeak.net  Sat Dec 25 19:47:02 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 25 Dec 2010 18:47:02 +0000
Subject: [PyPy-issue] [issue586] Show a traceback when an exception is
	raised in a destructor
Message-ID: <1293302822.54.0.715616415463.issue586@>


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

Ah.  It's likely to be because the call to close() raises an error -- like disk
full, or something else -- but this gets eaten because it occurs in the
destructor.  (Incidentally, that's one more reason for which all files should be
closed explicitly even on CPython.)  All we can do is improve this special case
to print the problem as explicitly as possible, e.g. including the errno
message.  There is not a lot more to do I'm afraid.

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


From pypy-dev-issue at codespeak.net  Mon Dec 27 09:51:52 2010
From: pypy-dev-issue at codespeak.net (Stephan Hadinger)
Date: Mon, 27 Dec 2010 08:51:52 +0000
Subject: [PyPy-issue] [issue616] ctypes: 'c_long' object is not iterable
Message-ID: <1293439912.94.0.341353404906.issue616@>


New submission from Stephan Hadinger <stephan.hadinger at orange-ftgroup.com>:

Problem when applying hexlify on c_int:

>>>> import binascii
>>>> import ctypes
>>>> i = ctypes.c_int(0x12345678)
>>>> binascii.hexlify(i)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "c:\Pypy14\lib_pypy\binascii.py", line 665, in b2a_hex
    for char in s:
TypeError: 'c_long' object is not iterable


Whereas in Python 2.5/2.6 this works:

>>> import binascii
>>> import ctypes
>>> i = ctypes.c_int(0x12345678)
>>> binascii.hexlify(i)
'78563412'
>>>

----------
effort: ???
messages: 2038
nosy: pypy-issue, shadinger
priority: bug
release: 1.4
status: unread
title: ctypes: 'c_long' object is not iterable

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


From pypy-dev-issue at codespeak.net  Mon Dec 27 10:13:52 2010
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Mon, 27 Dec 2010 09:13:52 +0000
Subject: [PyPy-issue] [issue616] ctypes: 'c_long' object is not iterable
Message-ID: <1293441232.87.0.806741368055.issue616@>


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

In CPython, binascii.c uses PyArg_ParseTuple with the "s#" format everywhere ("s*" 
since 2.7) which invokes the buffer interface.
pypy's implementation is in pure Python, and could use something like
    s = str(buffer(s))
in every public function.

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

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


From pypy-dev-issue at codespeak.net  Mon Dec 27 10:18:22 2010
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Mon, 27 Dec 2010 09:18:22 +0000
Subject: [PyPy-issue] [issue616] ctypes: 'c_long' object is not iterable
Message-ID: <1293441502.98.0.516603014709.issue616@>


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

This appears to work fine in 1.4.1 for me, can you please try that and confirm?

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


From strombrg at gmail.com  Mon Dec 13 01:29:48 2010
From: strombrg at gmail.com (Dan Stromberg)
Date: Sun, 12 Dec 2010 16:29:48 -0800
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
In-Reply-To: <6865970882050303477@unknownmsgid>
References: <6865970882050303477@unknownmsgid>
Message-ID: <AANLkTimjcGsNz=Ju-APUpqD3G6hNPfWCMMXnDttrdOVN@mail.gmail.com>

Yes, you certainly may ask.  I'll try to find time for this soon, but I'm
starting a new contract tomorrow morning, and I have a bunch of paperwork to
fill out today.

I'm kind of surprised you didn't get a readline0 when you checked out
backshift - I believe it's in there as an SVN "external reference".  Did you
check it out using mercurial or git as an interface to svn, by any chance?
 ISTR that they don't do external references.  Either way, readline0 is at
http://stromberg.dnsalias.org/svn/readline0/trunk/ .

About jpilot - I'll copy that over sometime soon.  You might be able to get
the files by installing a jpilot deb/rpm on your Linux system.

On Sun, Dec 12, 2010 at 6:30 AM, Armin Rigo <pypy-dev-issue at codespeak.net>wrote:

>
> Armin Rigo <armin.rigo at gmail.com> added the comment:
>
> May I ask you if you can make it a bit more portable, or else mention
> explicitly
> what we need to install?  I cannot run the tests, because I have no
> /usr/share/jpilot and because I have no module called "readline0".  (I
> didn't
> try further, there might be other dependencies.)
>
> ----------
> status: unread -> chatting
>
> _______________________________________________________
> PyPy development tracker <pypy-dev-issue at codespeak.net>
> <https://codespeak.net/issue/pypy-dev/issue608>
> _______________________________________________________
>



-- 
Dan Stromberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20101212/4257e7b3/attachment.html>

From stephan.hadinger at orange-ftgroup.com  Mon Dec 27 10:19:58 2010
From: stephan.hadinger at orange-ftgroup.com (stephan.hadinger at orange-ftgroup.com)
Date: Mon, 27 Dec 2010 10:19:58 +0100
Subject: [PyPy-issue] [issue616] ctypes: 'c_long' object is not iterable
In-Reply-To: <1293441502.98.0.516603014709.issue616@>
References: <1293441502.98.0.516603014709.issue616@>
Message-ID: <10893_1293441601_4D185A41_10893_311111_1_3FC65480CFB9C943B169C2502E66E86E4698FE02C4@PMEXCB1C.intranet-paris.francetelecom.fr>

Hi, you are super-fast...

There is no Windows build for 1.4.1, I can't test it right now.

Thanks
Stephan

-----Message d'origine-----
De?: Alex Gaynor [mailto:pypy-dev-issue at codespeak.net] 
Envoy??: lundi 27 d?cembre 2010 10:18
??: alex.gaynor at gmail.com; pypy-issue at codespeak.net; HADINGER Stephan OLNC/IC
Objet?: [issue616] ctypes: 'c_long' object is not iterable


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

This appears to work fine in 1.4.1 for me, can you please try that and confirm?

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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


From stephan.hadinger at orange-ftgroup.com  Tue Dec 28 15:27:43 2010
From: stephan.hadinger at orange-ftgroup.com (stephan.hadinger at orange-ftgroup.com)
Date: Tue, 28 Dec 2010 15:27:43 +0100
Subject: [PyPy-issue] [issue616] ctypes: 'c_long' object is not iterable
In-Reply-To: <1293439912.94.0.341353404906.issue616@>
References: <1293439912.94.0.341353404906.issue616@>
Message-ID: <3195_1293546467_4D19F3E3_3195_15765_1_3FC65480CFB9C943B169C2502E66E86E4698FE039E@PMEXCB1C.intranet-paris.francetelecom.fr>

I finally tested on 1.4.1 on Windows, it works.

/Closed

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


From pypy-dev-issue at codespeak.net  Wed Dec 29 12:36:09 2010
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 29 Dec 2010 11:36:09 +0000
Subject: [PyPy-issue] [issue617] range() slower than xrange()
Message-ID: <1293622569.28.0.68982879862.issue617@>


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

Investigate: why is range() slower than xrange() by ~20%?  Test case:

for i in range(200000):
    for j in range(500):
        pass

----------
effort: ???
messages: 2043
nosy: pypy-issue
priority: feature
release: ???
status: unread
title: range() slower than xrange()

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