From pypy-dev-issue at codespeak.net  Wed Feb  2 16:37:15 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Wed, 02 Feb 2011 15:37:15 +0000
Subject: [PyPy-issue] [issue629] "Cannot find gc roots" messages on Linux
Message-ID: <1296661035.76.0.074284554958.issue629@>


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

Should be fixed now (78912da6a09a).  At least the command-line that you gave now
passes fine.  Can you try again?  (If needed, wait for tonight's build that
should show up at http://buildbot.pypy.org/nightly/trunk/ .)

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


From pypy-dev-issue at codespeak.net  Thu Feb  3 11:35:09 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 03 Feb 2011 10:35:09 +0000
Subject: [PyPy-issue] [issue630] 1.4.1 stackless does not build on
	openSUSE11.3
Message-ID: <1296729309.04.0.551602854983.issue630@>


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

The issue is not that PyPy does not build; it built fine, and you should have a
"pypy-c" in pypy/translator/goal/.  The issue is that the openSUSE11.3 build
script, apparently, also runs tests in some way.  It's one of the tests that
locks.  I'm not sure if we care enough to understand why because it's on 1.4.1
(which is a bit old by now), Stackless (which we don't test much so far), and
with custom per-distribution build scripts (why not just run tests the
"official" way?).

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

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


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:12:19 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:12:19 +0000
Subject: [PyPy-issue] [issue44] have a doc chapter for CPython-dev'ers
Message-ID: <1296731539.88.0.726877238476.issue44@>


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

I think this is irrelevant by now, closing.

----------
nosy: +pypy-issue -arigo, cfbolz, mwh, tismer
status: chatting -> wontfix

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


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:12:59 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:12:59 +0000
Subject: [PyPy-issue] [issue111] test reports / platform sorted
Message-ID: <1296731579.38.0.853106023351.issue111@>


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

We have buildbot, closing.

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

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


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:13:53 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:13:53 +0000
Subject: [PyPy-issue] [issue131] cleanup of import dependencies
Message-ID: <1296731633.38.0.181807767471.issue131@>


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

This is either "resolved" or "wontfix", can't make up my mind :)

----------
nosy: +pypy-issue -arigo, cfbolz, pedronis, tismer
status: unread -> wontfix

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


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:15:01 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:15:01 +0000
Subject: [PyPy-issue] [issue265] optimize functions returning tuples
Message-ID: <1296731701.56.0.399569989259.issue265@>


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

We fixed that by a combination of inlining and JIT. does not matter any more

----------
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/issue265>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:16:35 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:16:35 +0000
Subject: [PyPy-issue] [issue286] emulate Cpython's __module__ behaviour
Message-ID: <1296731795.78.0.534234014146.issue286@>


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

Fixed? At least I don't see __module__ assignment any more.

----------
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/issue286>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:18:14 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:18:14 +0000
Subject: [PyPy-issue] [issue335] lots of tests fail when run with py.test
	--boxed
Message-ID: <1296731894.74.0.178682815423.issue335@>


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

For what is worth, py.test doesn't have this option any more. we run tests in 
separate dirs in separate processes in nightly run and it works somehow.

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

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


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:43:10 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:43:10 +0000
Subject: [PyPy-issue] [issue365] compiler package for CPython
Message-ID: <1296733390.53.0.426449044578.issue365@>


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

CPython's compiler package is dead.

----------
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/issue365>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:51:20 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:51:20 +0000
Subject: [PyPy-issue] [issue366] asmgcc not cooperating nice with callbacks
Message-ID: <1296733880.6.0.988922433463.issue366@>


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

fixed

----------
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/issue366>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Feb  3 12:54:52 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Feb 2011 11:54:52 +0000
Subject: [PyPy-issue] [issue382] ctypes fails to find libc in certain
	environments
Message-ID: <1296734092.1.0.39909280543.issue382@>


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

Fixed as we updated to 2.7

----------
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/issue382>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Thu Feb  3 13:18:20 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 03 Feb 2011 12:18:20 +0000
Subject: [PyPy-issue] [issue286] emulate Cpython's __module__ behaviour
Message-ID: <1296735500.65.0.179330580612.issue286@>


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

Really? I can see almost 50 assignment to __module__ in our various interplevel 
modules, see module/itertools/interp_itertools.py for example.

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

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


From fijall at gmail.com  Thu Feb  3 13:51:39 2011
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 3 Feb 2011 14:51:39 +0200
Subject: [PyPy-issue] [issue286] emulate Cpython's __module__ behaviour
In-Reply-To: <1579458091022725937@unknownmsgid>
References: <1579458091022725937@unknownmsgid>
Message-ID: <AANLkTinPG7UMR5ys2=e7pvdP1D3n1yRVKX48vLHGzPbD@mail.gmail.com>

Then maybe we should apply patch or decide why not.

On Thu, Feb 3, 2011 at 2:18 PM, Amaury Forgeot d Arc
<pypy-dev-issue at codespeak.net> wrote:
>
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
>
> Really? I can see almost 50 assignment to __module__ in our various interplevel
> modules, see module/itertools/interp_itertools.py for example.
>
> ----------
> status: resolved -> chatting
>
> _______________________________________________________
> PyPy development tracker <pypy-dev-issue at codespeak.net>
> <https://codespeak.net/issue/pypy-dev/issue286>
> _______________________________________________________
> _______________________________________________
> PyPy-issue mailing list
> PyPy-issue at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-issue
>


From pypy-dev-issue at codespeak.net  Fri Feb  4 08:53:05 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 04 Feb 2011 07:53:05 +0000
Subject: [PyPy-issue] [issue393] Create a workaround for os.fork exploding
	because of lack of virtual memory
Message-ID: <1296805985.54.0.696504249724.issue393@>


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

This is done

----------
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/issue393>
_______________________________________________________


From pypy-dev-issue at codespeak.net  Fri Feb  4 11:45:31 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 04 Feb 2011 10:45:31 +0000
Subject: [PyPy-issue] [issue399] segfault in resize_buffer in low memory
	conditions
Message-ID: <1296816331.89.0.0843620232883.issue399@>


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

I could provide the source but I didn't. That's a very bad issue, I suppose 
someone should provide a better one when we run into it. Closing for now

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

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


From pypy-dev-issue at codespeak.net  Fri Feb  4 11:57:02 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 04 Feb 2011 10:57:02 +0000
Subject: [PyPy-issue] [issue389] move towards "easy_install <*pypy*>"
	schemes?
Message-ID: <1296817022.82.0.89112941418.issue389@>


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

We should still remove pylib in PyPy, but that's a separate issue. I suggest we 
don't go for easy-installable PyPy, since it's really not a Python package.

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

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


From pypy-dev-issue at codespeak.net  Sat Feb  5 02:04:53 2011
From: pypy-dev-issue at codespeak.net (Victor)
Date: Sat, 05 Feb 2011 01:04:53 +0000
Subject: [PyPy-issue] [issue629] "Cannot find gc roots" messages on Linux
Message-ID: <1296867893.61.0.730520265693.issue629@>


Victor <victorgarcianet at gmail.com> added the comment:

Works without issues using the 41609-b6fef6d2d210 nightly.

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

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


From pypy-dev-issue at codespeak.net  Sat Feb  5 02:08:20 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Sat, 05 Feb 2011 01:08:20 +0000
Subject: [PyPy-issue] [issue621] pythonapi seg fault in fast-forward branch
Message-ID: <1296868100.43.0.808294075907.issue621@>


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

Doesn't segfault anymore (its now an AttributeError).  Closing this ticket as we
now have a buildbot failure for this test.

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

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


From pypy-dev-issue at codespeak.net  Sun Feb  6 05:07:54 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Sun, 06 Feb 2011 04:07:54 +0000
Subject: [PyPy-issue] [issue631] sys.path different following changes to
	nanos
Message-ID: <1296965274.39.0.349168694299.issue631@>


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

Following the recent changes to nanos sys.path is a little different:

http://paste.pocoo.org/show/332874/

----------
effort: ???
messages: 2112
nosy: agaynor, pypy-issue
priority: bug
release: ???
status: unread
title: sys.path different following changes to nanos

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


From pypy-dev-issue at codespeak.net  Sun Feb  6 12:49:03 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sun, 06 Feb 2011 11:49:03 +0000
Subject: [PyPy-issue] [issue631] sys.path different following changes to
	nanos
Message-ID: <1296992943.09.0.644012932946.issue631@>


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

Bah, CPython contains tons and tons of code, using such C functions as
realpath() just for the first entry, etc.  Do we really want to care?  I fear
that the answer is Yes, but I'm not convinced still that there is a problem with
the current situation.

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

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


From pypy-dev-issue at codespeak.net  Sun Feb  6 18:19:58 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Sun, 06 Feb 2011 17:19:58 +0000
Subject: [PyPy-issue] [issue631] sys.path different following changes to
	nanos
Message-ID: <1297012798.01.0.844201876967.issue631@>


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

I filed the bug since this broke Django tests for me, we could decide this
relies on a CPython specific thing, and I can fix Django, but I fear other
people will have the same issue.

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


From pypy-dev-issue at codespeak.net  Sun Feb  6 18:53:36 2011
From: pypy-dev-issue at codespeak.net (Jean-Paul Calderone)
Date: Sun, 06 Feb 2011 17:53:36 +0000
Subject: [PyPy-issue] [issue631] sys.path different following changes to
	nanos
Message-ID: <1297014816.96.0.792014992589.issue631@>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

It would be nice to at least document what goal PyPy aims for wrt sys.path[0] 
(doubly so if it isn't going to be the same as CPython).

sys.path is intensely confusing for a large number of Python developers (sadly).  
This kind of incompatibility is likely to be disproportionately upsetting to 
them.

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


From pypy-dev-issue at codespeak.net  Sun Feb  6 19:06:59 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sun, 06 Feb 2011 18:06:59 +0000
Subject: [PyPy-issue] [issue631] sys.path different following changes to
	nanos
Message-ID: <1297015619.27.0.0205437494414.issue631@>


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

Fixed, I think (2ea70f35cc0e).

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

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


From pypy-dev-issue at codespeak.net  Mon Feb  7 02:17:36 2011
From: pypy-dev-issue at codespeak.net (Justin)
Date: Mon, 07 Feb 2011 01:17:36 +0000
Subject: [PyPy-issue] [issue633] Unable to build in Windows
Message-ID: <1297041456.64.0.214607312916.issue633@>


New submission from Justin <justinnoah at gmail.com>:

Buildlog: http://i.imgur.com/UjbRA.png

----------
assignedto: brutal_chaos
effort: easy
messages: 2117
nosy: brutal_chaos, pypy-issue
priority: critical
release: ???
status: unread
title: Unable to build in Windows

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


From pypy-dev-issue at codespeak.net  Mon Feb  7 02:18:57 2011
From: pypy-dev-issue at codespeak.net (Justin)
Date: Mon, 07 Feb 2011 01:18:57 +0000
Subject: [PyPy-issue] [issue633] Unable to build in Windows
Message-ID: <1297041537.05.0.405740818749.issue633@>


Justin <justinnoah at gmail.com> added the comment:

Attached is the diff for the fix.

----------
assignedto: brutal_chaos -> 
status: unread -> chatting

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

From pypy-dev-issue at codespeak.net  Mon Feb  7 08:57:08 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Mon, 07 Feb 2011 07:57:08 +0000
Subject: [PyPy-issue] [issue633] Unable to build in Windows
Message-ID: <1297065428.78.0.0896451877172.issue633@>


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

Fixed with 4b9129d84a5f. Thanks for reporting the issue!

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

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


From pypy-dev-issue at codespeak.net  Tue Feb  8 16:25:24 2011
From: pypy-dev-issue at codespeak.net (Jongsoo Lee)
Date: Tue, 08 Feb 2011 15:25:24 +0000
Subject: [PyPy-issue] [issue634] build error at msvc
Message-ID: <1297178724.43.0.906900903784.issue634@>


New submission from Jongsoo Lee <leejongsoo.club at gmail.com>:

compile error (C2065, undeclared identifier) during translation processing on 
windows7 & msvc 2008
ssize_t(signals.h) is not defined. (SSIZE_T is defined BaseTsd.h)

At cpython, following code are used. (pyconfig.h)

/* Define like size_t, omitting the "unsigned" */

#ifdef MS_WIN64

typedef __int64 ssize_t;

#else

typedef _W64 int ssize_t;

#endif

#define HAVE_SSIZE_T 1

----------
effort: easy
messages: 2120
nosy: everyevery, pypy-issue
priority: bug
release: ???
status: unread
title: build error at msvc

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


From pypy-dev-issue at codespeak.net  Tue Feb  8 16:34:46 2011
From: pypy-dev-issue at codespeak.net (Jongsoo Lee)
Date: Tue, 08 Feb 2011 15:34:46 +0000
Subject: [PyPy-issue] [issue635] build error with msvc(korean version)
Message-ID: <1297179286.45.0.639046474421.issue635@>


New submission from Jongsoo Lee <leejongsoo.club at gmail.com>:

build error with msvc(korean version).
pypy identify the msvc version using following regular expression.

 translator/platform/windows.py
 r = re.search('[Vv]ersion\W([0-9]+)\.([0-9]+)', stderr)

In korean VC, cl message user '??'(korean word of 'version') than 'version'
So this regular expression can't know the version number of msvc.

below code resolve this problem.
r = re.search(?Microsoft.+C/C\+\+.+\s([0-9]+)\.([0-9]+).*?, stderr)

----------
effort: easy
messages: 2121
nosy: everyevery, pypy-issue
priority: bug
release: ???
status: unread
title: build error with msvc(korean version)

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


From pypy-dev-issue at codespeak.net  Tue Feb  8 17:57:04 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 08 Feb 2011 16:57:04 +0000
Subject: [PyPy-issue] [issue634] build error at msvc
Message-ID: <1297184224.02.0.746909241274.issue634@>


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

This was fixed a few days ago:
   Changeset: r41602:3a51b7723c9c
   Date: 2011-02-04 11:56 +0100
Thanks for the report, though!

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

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


From pypy-dev-issue at codespeak.net  Tue Feb  8 18:30:50 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 08 Feb 2011 17:30:50 +0000
Subject: [PyPy-issue] [issue635] build error with msvc(korean version)
Message-ID: <1297186250.12.0.90447185405.issue635@>


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

Applied in changeset 3ce31c149e51.
I changed it a bit, to use re.match instead of re.search.
Thanks for the correction!

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

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


From pypy-dev-issue at codespeak.net  Tue Feb 15 22:26:58 2011
From: pypy-dev-issue at codespeak.net (Dan Stromberg)
Date: Tue, 15 Feb 2011 21:26:58 +0000
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
Message-ID: <1297805218.49.0.752239740105.issue608@>


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

I have some more available time now.

I'm still sometimes getting gibberish in my gdbm data (gdbm via ctypes) when using pypy 
- whether pypy 1.4.1 or a pypy trunk build from 2011-02-13.

If one does an "svn checkout http://stromberg.dnsalias.org/svn/backshift/trunk", it is 
my belief that one should get the various dependencies required, including readline0, 
treap and rolling_checksum_py_mod, though the latter two will only be built if you run 
"make treap.py rolling_checksum_py_mod.py" (or the default rule, but that does a LOT of 
stuff).  Oh, and readline0.py will likely need to be copied to ~/lib/. .

After that, there's a directory trunk/tests/70-pypy-gibberish, in which the default 
make rule should demonstrate the problem.

If there's (else) anything I can get you to facilitate solving this problem, please 
don't hesitate to let me know.

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


From pypy-dev-issue at codespeak.net  Tue Feb 15 23:09:29 2011
From: pypy-dev-issue at codespeak.net (Dan Stromberg)
Date: Tue, 15 Feb 2011 22:09:29 +0000
Subject: [PyPy-issue] [issue605] Complete the 'os' module
Message-ID: <1297807769.08.0.672137213147.issue605@>


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

Happily, I'm getting os.major and os.minor now with a pypy trunk from 2011-02-13.

Thanks folks.

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


From pypy-dev-issue at codespeak.net  Wed Feb 16 14:32:04 2011
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Wed, 16 Feb 2011 13:32:04 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1297863124.24.0.757798506162.issue604@>


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

just to clarify: I reported this bug in the virtualenv issue tracker:
https://bitbucket.org/ianb/virtualenv/issue/75/pypy-and-virtualenv-with-distribute-on-mac

however, it has not fixed upstream so far. In the meantime, people can use my
virtualenv-pypy fork:
https://bitbucket.org/antocuni/virtualenv-pypy

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

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


From pypy-dev-issue at codespeak.net  Wed Feb 16 15:26:31 2011
From: pypy-dev-issue at codespeak.net (Michael Foord)
Date: Wed, 16 Feb 2011 14:26:31 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1297866391.39.0.94703880052.issue604@>


Michael Foord <michael at voidspace.org.uk> added the comment:

Why not distribute your version of virtualenv *with* pypy?

For what it is worth Ian Bicking is looking for a maintainer for virtualenv (implying that it is mostly 
unmaintained at the moment):

http://www.google.com/buzz/104537541227697934010/aQg878yjRmT/I-have-several-packages-
that-Id-like-to-find

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


From pypy-dev-issue at codespeak.net  Wed Feb 16 15:30:32 2011
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Wed, 16 Feb 2011 14:30:32 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1297866632.36.0.975180259735.issue604@>


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

we just did it :-)
Now our fork of virtualenv is distributed together with pypy inside
contrib/virtualenv-pypy

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

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


From pypy-dev-issue at codespeak.net  Wed Feb 16 17:18:23 2011
From: pypy-dev-issue at codespeak.net (Holger Krekel)
Date: Wed, 16 Feb 2011 16:18:23 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1297873103.51.0.516994714542.issue604@>


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

Sorry Anto, but I really don't see it as a good idea to include virtualenv in
pypy. It just increases overall confusion and will suddenly break if people do
"virtualenv -p pypy" whereas "pypy path-to-virtualenv" works.  It's much cleaner
to release a "virtualenv_p" or so which anyone can install and which is
distinguishable.  If you insist on shipping it with pypy, is it then at least
possible to install a newer virtualenv version?

I also don't get the argument that with an included virtualenv you can now write
tests.  Why not include the tests in the fork?

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

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


From pypy-dev-issue at codespeak.net  Wed Feb 16 17:50:23 2011
From: pypy-dev-issue at codespeak.net (Michael Foord)
Date: Wed, 16 Feb 2011 16:50:23 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1297875023.42.0.668811302424.issue604@>


Michael Foord <michael at voidspace.org.uk> added the comment:

Given that the standard virtualenv *doesn't* work with pypy distributing a working virtualenv with pypy 
seems eminently sensible.

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


From pypy-dev-issue at codespeak.net  Wed Feb 16 18:41:07 2011
From: pypy-dev-issue at codespeak.net (Michael Foord)
Date: Wed, 16 Feb 2011 17:41:07 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1297878067.73.0.418600425881.issue604@>


Michael Foord <michael at voidspace.org.uk> added the comment:

a) No but I *would* say it for IronPython or Jython.
b) It is about virtualenv working with pypy on Mac OS X, not sure why whether or not you categorise it 
as configuration is relevant
c) they get a working version of virtualenv with pypy... Without this they are *likely* to use the default 
one which doesn't work. This gives a very bad impression of pypy.

Currently virtualenv is not really maintained (see previous messages) so chances of required changes 
being merged upstream soon are not good.

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


From pypy-dev-issue at codespeak.net  Thu Feb 17 10:52:44 2011
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Thu, 17 Feb 2011 09:52:44 +0000
Subject: [PyPy-issue] [issue604] pypy and virtualenv with distribute on Mac
	OS X
Message-ID: <1297936364.04.0.593052354981.issue604@>


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

ok, let's try to clarify things.

1) I'm trying to go for the least-effort route; there are tons of things that
could be done better, but require time which I prefer to spend on IMHO more
important tasks

2) maintaining an easy-installable version of virtualenv_pypy costs some time.
If there is anyone willing to do it, fine, but I don't want to be that one :-)

3) anyway, I don't think that releasing our own virtualenv_p is less confusing
than the current situation; then people would have to remind to type
virtualenv_p -p pypy instead of /path/to/virtualenv-pypy/virtualenv.py -p pypy.
It might be more convenient, not less confusing

4) for tests: you need a pypy binary for running virtualenv tests. The easiest
way is to have virtualenv inside the pypy tree; the alternative would be to
setup a new buildslave, which either compiles its own pypy-c or download it from
somewhere, etc. etc.

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


From pypy-dev-issue at codespeak.net  Fri Feb 18 02:29:47 2011
From: pypy-dev-issue at codespeak.net (Bob Ziuchkovski)
Date: Fri, 18 Feb 2011 01:29:47 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1297992587.68.0.925907636539.issue636@>


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

With current trunk, pypy's JIT produces different behavior between linux32 and 
linux64 builds for the attached sample code.  The attached sample code from 
main.py calls a function with the same input args 10 times.

If run under linux32 JIT, the loop from main.py will produce the same results 
each run through the loop.  If run under linux64 JIT, after several iterations 
of the loop, the results are different.  However, if the JIT is disabled on 
linux64 (--jit trace_limit=-1), the 10 iterations of the loop do produce the 
correct result.  Hence it looks like the sample code triggers a bug that is 
specifically tied to 64bit JIT.

----------
effort: ???
files: pypy_jit_64bit_failure.tar.gz
messages: 2135
nosy: bobbyz, pypy-issue
priority: bug
release: ???
status: unread
title: 64bit JIT Failure on trunk

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue636>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy_jit_64bit_failure.tar.gz
Type: application/x-gzip
Size: 27934 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110218/ad9207c2/attachment.bin>

From pypy-dev-issue at codespeak.net  Fri Feb 18 05:10:47 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 18 Feb 2011 04:10:47 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298002247.23.0.987405453169.issue636@>


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

Confirmed obvious nonsense

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

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


From pypy-dev-issue at codespeak.net  Fri Feb 18 05:32:59 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 18 Feb 2011 04:32:59 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298003579.34.0.433078944582.issue636@>


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

Reduced the example a bit

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue636>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.py
Type: text/x-python
Size: 424 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110218/b1c05c9a/attachment.py>

From pypy-dev-issue at codespeak.net  Fri Feb 18 16:52:23 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 18 Feb 2011 15:52:23 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298044343.83.0.872819042384.issue636@>


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

Confirmed bobbyz's results too.  However, the reduced example.py from fijal
works just fine for me.

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


From pypy-dev-issue at codespeak.net  Fri Feb 18 20:35:56 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Fri, 18 Feb 2011 19:35:56 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298057756.24.0.369710025523.issue636@>


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

Armin: works just fine as in produces the same output for CPython and pypy-c? It 
definitely doesn't for me (and I did rerun and download from here).

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


From pypy-dev-issue at codespeak.net  Fri Feb 18 20:55:56 2011
From: pypy-dev-issue at codespeak.net (Jean-Paul Calderone)
Date: Fri, 18 Feb 2011 19:55:56 +0000
Subject: [PyPy-issue] [issue637]
	twisted.conch.test.test_recvline.RecvlineLoopbackTelnet.testLeftArrow
	fails after 29 iterations
Message-ID: <1298058956.26.0.633404800223.issue637@>


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

Running this test with `trial -u` fails after a while (on the 27th iteration for 
me, consistently).  Attached is a simpler example that uses the same code and 
also misbehaves.  It starts off emitting LEFT_ARROW when it sees \x1b[D but 
eventually switches to emitting [ and D instead.

These results produced with a -Ojit build of 42168:84321e49b3c0

----------
effort: ???
files: mini.py
messages: 2140
nosy: calderone, pypy-issue
priority: bug
release: ???
status: unread
title: twisted.conch.test.test_recvline.RecvlineLoopbackTelnet.testLeftArrow fails after 29 iterations

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue637>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mini.py
Type: text/x-python
Size: 461 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110218/6158c250/attachment.py>

From pypy-dev-issue at codespeak.net  Sat Feb 19 10:02:04 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 19 Feb 2011 09:02:04 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298106124.91.0.540339259158.issue636@>


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

It doesn't produce exactly the same output on pypy-c-jit and CPython 2.6, which
I suspect is due to decimal rounding (CPython 2.6 doesn't have dtoa.c yet).  But
apart from that the output looks the same, yes.  In any case example.py is
failing to show a different output after some number of iterations.  I'm running
on tannit64, with pypy-c-r42024-jit (4df39c33ef9c, Feb 16 2011).

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


From pypy-dev-issue at codespeak.net  Sat Feb 19 13:34:58 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 19 Feb 2011 12:34:58 +0000
Subject: [PyPy-issue] [issue637]
	twisted.conch.test.test_recvline.RecvlineLoopbackTelnet.testLeftArrow
	fails after 29 iterations
Message-ID: <1298118898.76.0.522505977448.issue637@>


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

Which architecture?  64-bit Linux?

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

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


From pypy-dev-issue at codespeak.net  Sat Feb 19 15:37:43 2011
From: pypy-dev-issue at codespeak.net (Jean-Paul Calderone)
Date: Sat, 19 Feb 2011 14:37:43 +0000
Subject: [PyPy-issue] [issue637]
	twisted.conch.test.test_recvline.RecvlineLoopbackTelnet.testLeftArrow
	fails after 29 iterations
Message-ID: <1298126263.53.0.359942854619.issue637@>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

32-bit Linux

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


From pypy-dev-issue at codespeak.net  Sat Feb 19 19:52:02 2011
From: pypy-dev-issue at codespeak.net (Bob Ziuchkovski)
Date: Sat, 19 Feb 2011 18:52:02 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298141522.83.0.00616528966875.issue636@>


Bob Ziuchkovski <bob.ziuchkovski at gmail.com> added the comment:

I went back in the buildbot history and tested some of the older nightlies.  It 
looks like this sample code works on 64bit JIT through pypy-c-jit-40310-
5ea1e45c5e6e-linux64.  However, it no longer works with pypy-c-jit-40355-
e5828b4d7360-linux64.  Looking at the hg history it seems this might be related 
to the JIT loop unrolling, which was merged on Jan 3 2011.

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


From pypy-dev-issue at codespeak.net  Sat Feb 19 19:55:48 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 19 Feb 2011 18:55:48 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298141748.29.0.354037107317.issue636@>


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

Ah, thanks.  Then maybe it's related to the test that fails in trunk but is
fixed in the jit-virtual_state branch (which is not merged yet because we're
tracking another bug).  I should try in that branch (as soon as I can).

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


From pypy-dev-issue at codespeak.net  Sat Feb 19 21:50:18 2011
From: pypy-dev-issue at codespeak.net (Bob Ziuchkovski)
Date: Sat, 19 Feb 2011 20:50:18 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1298148618.91.0.661750598109.issue636@>


Bob Ziuchkovski <bob.ziuchkovski at gmail.com> added the comment:

I thought I'd give this a shot, so I just translated a 64bit version of the jit-
virtual_state branch.  It looks like this problem persists on that branch.

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


From pypy-dev-issue at codespeak.net  Sat Feb 19 23:36:10 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Sat, 19 Feb 2011 22:36:10 +0000
Subject: [PyPy-issue] [issue517] `_ast` make `lineno` and `col_offset`
	optional
Message-ID: <1298154970.75.0.189977077062.issue517@>


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

There are lib-python/2.7.0/test failures due to that bug.

Given directions on how to fix, I'll give it a try.
I don't understand why giving default values to the offending __init__
parameters does not work... (I tried that workaround, knowing it is not a real
fix, as explained by pavpanchekha)

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


From pypy-dev-issue at codespeak.net  Sun Feb 20 00:20:17 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Sat, 19 Feb 2011 23:20:17 +0000
Subject: [PyPy-issue] [issue638] Fix utf7 decoding
Message-ID: <1298157617.04.0.635941818386.issue638@>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

UTF7 decoding seems broken, try to fix it.

As seen during investigation of failure in
pypy.interpreter.astcompiler.test.test_astbuilder.TestAstBuilder.test_string

The patch adds a regression test for pypy/rlib/runicode.str_decode_utf_7()
And a fix for the failures.

Please, review

----------
assignedto: vincele
effort: easy
files: fix_utf7_decoding.diff
messages: 2148
nosy: pypy-issue, vincele
priority: bug
release: 1.4
status: unread
title: Fix utf7 decoding

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue638>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_utf7_decoding.diff
Type: text/x-patch
Size: 2661 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110219/c979d4f8/attachment.bin>

From pypy-dev-issue at codespeak.net  Sun Feb 20 00:21:51 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Sat, 19 Feb 2011 23:21:51 +0000
Subject: [PyPy-issue] [issue638] Fix utf7 decoding
Message-ID: <1298157711.59.0.696541995147.issue638@>


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

BTW this also fixes the TestAstBuilder failure...

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

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


From pypy-dev-issue at codespeak.net  Sun Feb 20 03:15:10 2011
From: pypy-dev-issue at codespeak.net (Dan Stromberg)
Date: Sun, 20 Feb 2011 02:15:10 +0000
Subject: [PyPy-issue] [issue608] Gibberish from ctypes
Message-ID: <1298168110.21.0.090253432363.issue608@>


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

BTW, about the treap dependency being cython: It is cython, but it's Also pure
python.  When I do cython, I usually use the m4 preprocessor to automatically
create both cython and pure python from the same m4 file, since cython and pure
python code tend to be very similar to one another.  So one has a choice, but in
this particular project, I've only been using the pure python version of the
treap module.

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


From pypy-dev-issue at codespeak.net  Mon Feb 21 00:06:06 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Sun, 20 Feb 2011 23:06:06 +0000
Subject: [PyPy-issue] [issue517] `_ast` make `lineno` and `col_offset`
	optional
Message-ID: <1298243166.47.0.713592291272.issue517@>


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

The ast.py generator is modified to make the
two fields optional in ast.py

This patch also fixes two ERRORs from
lib-python/2.7.0/test/test_ast.py:
* AST_Tests.test_copy_location()
* AST_Tests.test_fix_missing_locations()

Please review.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue517>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-test_ast.diff
Type: text/x-patch
Size: 77672 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110220/c3e1ceb5/attachment.bin>

From pypy-dev-issue at codespeak.net  Mon Feb 21 01:06:31 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Mon, 21 Feb 2011 00:06:31 +0000
Subject: [PyPy-issue] [issue639] ASTBuilder's handling of lineno &
	col_offset is not compliant with CPython 2.7
Message-ID: <1298246791.95.0.511121975667.issue639@>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The test AST_Tests.test_snippets from lib-python/2.7.0/test/test_ast.py is
failing because of that.

CPython changed lineno & col_offset reporting, see:
http://bugs.python.org/issue6704 (Fix Commited in r74464)

The attached patch fixes this, and it covers other cases not currently tested. A
modified test is available in the patch that add missing test snippets.

----------
assignedto: vincele
effort: easy
messages: 2152
nosy: pypy-issue, vincele
priority: bug
release: 1.4
status: in-progress
title: ASTBuilder's handling of lineno & col_offset is not compliant with CPython 2.7

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


From pypy-dev-issue at codespeak.net  Mon Feb 21 11:39:27 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Mon, 21 Feb 2011 10:39:27 +0000
Subject: [PyPy-issue] [issue517] `_ast` make `lineno` and `col_offset`
	optional
Message-ID: <1298284767.25.0.434867437097.issue517@>


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

BTW there are other places that use lineno & co. for example in
ASTBuilder.error(), should those uses be safeguarded against being undefined ?

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


From pypy-dev-issue at codespeak.net  Tue Feb 22 16:45:20 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 22 Feb 2011 15:45:20 +0000
Subject: [PyPy-issue] [issue630] 1.4.1 stackless does not build on
	openSUSE11.3
Message-ID: <1298389519.98.0.596689505807.issue630@>


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

Closing this because of issues raised by Armin.

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

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


From pypy-dev-issue at codespeak.net  Tue Feb 22 22:58:59 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Tue, 22 Feb 2011 21:58:59 +0000
Subject: [PyPy-issue] [issue640] Possible optimization in FOR_ITER on a
	constant tuple
Message-ID: <1298411939.69.0.00440583272748.issue640@>


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

Given:

for x in (1, 2, 3):
    i += x

We currently generate:

FOR_ITER to 47
guard(i5 is 1)
guard(guard_class(p7, 146344448))
p14 = ((pypy.objspace.std.iterobject.W_FastTupleIterObject)p7).inst_tupleitems
guard(guard_nonnull(p14))
i15 = ((pypy.objspace.std.iterobject.W_AbstractSeqIterObject)p7).inst_index
i16 = arraylen_gc(p14)
i17 = i15 >= i16
guard(i17 is false)
p18 = getarrayitem_gc(p14, i15)
i20 = i15 + 1


This is slightly inefficient in a few places, the getitem, for tupleitems, could
be eliminated, as could the arraylen.

----------
effort: ???
messages: 2155
nosy: agaynor, pypy-issue
priority: wish
release: ???
status: unread
title: Possible optimization in FOR_ITER on a constant tuple

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


From pypy-dev-issue at codespeak.net  Wed Feb 23 14:12:35 2011
From: pypy-dev-issue at codespeak.net (Janos)
Date: Wed, 23 Feb 2011 13:12:35 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298466755.89.0.819503203326.issue641@>


New submission from Janos <mjanos5 at gmail.com>:

Hi all,

I tested the pypy-1.4.1-linux 32bit version.

I attached a small test suite that shows the slowness, by creating a
test csv file and reading it back.

Personally I have problems only with the read speed. I also tried to use
file.readlines() and line.split(',') instead of csv.read, but that was
even slower.

I would like to use pypy for the application I created, but csv handling
seems to be the bottleneck.


user at localhost:~/temp/pypytest$ time python csvparsingtest.py

real	0m1.080s
user	0m1.040s
sys	0m0.040s
user at localhost:~/temp/pypytest$ time ~/usr/pypy-1.4.1-linux/bin/pypy
csvparsingtest.py

real	0m5.713s
user	0m5.472s
sys	0m0.040s
user at localhost:~/temp/pypytest$

----------
effort: medium
files: csvparsingtest.py
messages: 2156
nosy: janos, pypy-issue
priority: feature
release: 1.4
status: unread
title: reading CSV files with csv module is much slower than CPython 2.6.6

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue641>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csvparsingtest.py
Type: text/x-python
Size: 342 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110223/d61e2049/attachment.py>

From pypy-dev-issue at codespeak.net  Wed Feb 23 21:58:32 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Wed, 23 Feb 2011 20:58:32 +0000
Subject: [PyPy-issue] [issue639] ASTBuilder's handling of lineno &
	col_offset is not compliant with CPython 2.7
Message-ID: <1298494712.79.0.753374279389.issue639@>


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

Commited, thanks

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

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


From pypy-dev-issue at codespeak.net  Wed Feb 23 21:58:52 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Wed, 23 Feb 2011 20:58:52 +0000
Subject: [PyPy-issue] [issue638] Fix utf7 decoding
Message-ID: <1298494732.28.0.777062828905.issue638@>


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

Commited, thanks

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

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


From pypy-dev-issue at codespeak.net  Wed Feb 23 22:29:15 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Wed, 23 Feb 2011 21:29:15 +0000
Subject: [PyPy-issue] [issue4] improve doctesting of documentation
Message-ID: <1298496555.55.0.497659645198.issue4@>


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

I think this is as good as it will ever be. No point in keeping this issue open 
IMO.

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

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


From pypy-dev-issue at codespeak.net  Thu Feb 24 10:57:20 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 24 Feb 2011 09:57:20 +0000
Subject: [PyPy-issue] [issue639] ASTBuilder's handling of lineno &
	col_offset is not compliant with CPython 2.7
Message-ID: <1298541440.9.0.237861764513.issue639@>


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

Not resolved (see 745e67a1466d).

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

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


From pypy-dev-issue at codespeak.net  Thu Feb 24 13:16:06 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Thu, 24 Feb 2011 12:16:06 +0000
Subject: [PyPy-issue] [issue639] ASTBuilder's handling of lineno &
	col_offset is not compliant with CPython 2.7
Message-ID: <1298549766.87.0.115965271289.issue639@>


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

This one should fix and translate.
Please review & test that I didn't screwup again.
Sorry for the mess...

Thanks Armin for the patience explaining my mistakes

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue639>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-test_ast-test_snippets-3.diff
Type: text/x-patch
Size: 30845 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110224/e6a703b7/attachment.bin>

From pypy-dev-issue at codespeak.net  Thu Feb 24 16:28:06 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 24 Feb 2011 15:28:06 +0000
Subject: [PyPy-issue] [issue639] ASTBuilder's handling of lineno &
	col_offset is not compliant with CPython 2.7
Message-ID: <1298561286.19.0.14532895429.issue639@>


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

Looks good, checked in now.  Note that we don't usually *add* many tests to a
CPython test file; the directory 'modified-2.7.2' is meant to fix or generalize
existing tests.  Instead, we put new tests somewhere in pypy/*, but using a
different style -- which I see can be the problem in this case, as you really
just want to add more tests in the same style.  Well, it's fine I suppose, as
long as the tests also pass on CPython 2.7.

Down from 10 to 9 failures in test_ast.py :-/

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


From pypy-dev-issue at codespeak.net  Thu Feb 24 17:52:36 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Thu, 24 Feb 2011 16:52:36 +0000
Subject: [PyPy-issue] [issue639] ASTBuilder's handling of lineno &
	col_offset is not compliant with CPython 2.7
Message-ID: <1298566356.09.0.371684772424.issue639@>


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

Yes, I understand the need to have pypy's own tests, but in that case it was
really easier to add to cpython's, and I even asked them if they also want the
added tests, maybe we can remove the modified's if they take it for 2.7.2...

I may revisit pypy/interpreter/astcompiler/test directory later, but that's a
separate issue.

That was the one easy fix in test_ast.py, I'm struggling with the remaining ones...

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


From pypy-dev-issue at codespeak.net  Thu Feb 24 23:47:55 2011
From: pypy-dev-issue at codespeak.net (Janno)
Date: Thu, 24 Feb 2011 22:47:55 +0000
Subject: [PyPy-issue] [issue642] 64bit sandboxes with jit fail during startup
Message-ID: <1298587675.1.0.186117858951.issue642@>


New submission from Janno <mail at janno-kaiser.de>:

After managing to translate a sandbox with jit based on 40712-e8966331cd0d I
tried newer revisions and found out that every revision after 40745-9317ec76d9eb
I tested produce sandboxes that fail during initializiation:

/usr/src/pypy/pypy/translator/sandbox/pypy_interact.py pypy-c
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_NURSERY')
[sandlib:result] None
[sandlib:call] ll_os.ll_os_open('/proc/cpuinfo', 0L, 420L)
[sandlib:exception] OSError: [Errno 2] proc
Warning: cannot find your CPU L2 cache size in /proc/cpuinfo
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_MAJOR_COLLECT')
[sandlib:result] None
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_GROWTH')
[sandlib:result] None
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_MIN')
[sandlib:result] None
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_MAX')
[sandlib:result] None
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_MAX_DELTA')
[sandlib:result] None
[sandlib:call] ll_os.ll_os_open('/proc/meminfo', 0L, 420L)
[sandlib:exception] OSError: [Errno 2] proc
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_DEBUG')
[sandlib:result] None
Not Implemented: sandboxing for external function 'pypysig_getaddr_occurred'
Invalid RPython operation (NULL ptr or bad array index)
[Subprocess killed by SIGIOT]

Sadly, sandboxes from earlier revision suffer from issue 629 which makes them
highly unreliable. Since I'm mostly interested in the performance benefit of jit
I have not yet tried non-jit sandboxes. I'll keep you updated if I get around to
do more trials in the next few days.

----------
effort: ???
messages: 2164
nosy: Janno, pypy-issue
priority: bug
release: ???
status: unread
title: 64bit sandboxes with jit fail during startup

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


From pypy-dev-issue at codespeak.net  Fri Feb 25 00:24:01 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 24 Feb 2011 23:24:01 +0000
Subject: [PyPy-issue] [issue642] 64bit sandboxes with jit fail during startup
Message-ID: <1298589841.93.0.32533728907.issue642@>


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

The point of sandboxing is that we can guarantee people that it's safe, for some
definition of safety.  However, for now sandboxing and the JIT are really not
working together nicely -- and the result is not safe in that sense.  If there
is enough interest again for sandboxing (possibly in the form of a
one-month-of-work contract with some company), we could fix it.

More precisely: a sandbox translation is alawys compiled with some debugging
checks enabled.  The reason is that it's always possible to inject malicious
code like hand-built code objects or regexps objects (just like on CPython); but
with the debugging checks, they cannot do more harm than an assertion failure
(i.e. a sudden exit with an error).  However, the debugging checks are so far
never present in the JIT-generated assembler code.  So a sandboxed translation
with the JIT is not safe.

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

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


From pypy-dev-issue at codespeak.net  Fri Feb 25 01:36:40 2011
From: pypy-dev-issue at codespeak.net (Janno)
Date: Fri, 25 Feb 2011 00:36:40 +0000
Subject: [PyPy-issue] [issue642] 64bit sandboxes with jit fail during startup
Message-ID: <1298594200.01.0.421650919679.issue642@>


Janno <mail at janno-kaiser.de> added the comment:

I see your point. My use case does may not require any security guarantees, just
some disincentive for tampering. A pypy sandbox with the JIT seems to be a
perfect fit since it's at least twice as fast cpython.

I tried again (42255:17bd126d3fee) without JIT and I'm still unable to start the
sandbox:
/usr/src/pypy/pypy/translator/sandbox/pypy_interact.py pypy-c
[sandlib:call] ll_os.ll_os_getenv('PYPY_GENERATIONGC_NURSERY')
[sandlib:result] None
[sandlib:call] ll_os.ll_os_open('/proc/cpuinfo', 0L, 420L)
[sandlib:exception] OSError: [Errno 2] proc
Warning: cannot find your CPU L2 cache size in /proc/cpuinfo
[sandlib:call] ll_os.ll_os_getenv('PYPY_GC_DEBUG')
[sandlib:result] None
Not Implemented: sandboxing for external function 'pypysig_getaddr_occurred'
Invalid RPython operation (NULL ptr or bad array index)
[Subprocess killed by SIGIOT]

The only unusual error that I get from all those revisions is:
[platform:Error] /usr/bin/ld: cannot find -lintl
[platform:Error] collect2: ld returned 1 exit status

I don't know if my working jit sandbox generated the same error during
translation but I recall seeing it a few times during my more recent
translations (newer revision).

I've attached the build log just in case I'm missing something important.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue642>
_______________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: buildlog.txt
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110225/13abf455/attachment.txt>

From pypy-dev-issue at codespeak.net  Fri Feb 25 01:48:04 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 25 Feb 2011 00:48:04 +0000
Subject: [PyPy-issue] [issue642] 64bit sandboxes with jit fail during startup
Message-ID: <1298594884.19.0.450607109086.issue642@>


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

In that case, you might be better off building such disincentives in pure
Python; for example, you control the "import" statement by changing
__builtin__.__import__(), you try to hide __builtin__.open() and
__builtin__.file(), and so on.  I'm sure there are plenty of examples of such
code out there, and you can test it on both CPython and PyPy.  And a
pypy-sandbox, which attempts to be fully safe, will never be as fast as a
regular pypy, for the reasons I mentioned.

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


From pypy-dev-issue at codespeak.net  Fri Feb 25 01:51:14 2011
From: pypy-dev-issue at codespeak.net (Brett Cannon)
Date: Fri, 25 Feb 2011 00:51:14 +0000
Subject: [PyPy-issue] [issue643] Fix for ctypes.test.test_objects failures
	under 2.7.0
Message-ID: <1298595074.11.0.337026198212.issue643@>


New submission from Brett Cannon <brett at python.org>:

Attached are two patches to fix the failures from ctypes.test.test_objects. One patch changes 
lib_pypy/_ctypes/basics.py:CArgObject to have a __repr__ compatible with the failing test. The other patch 
changes the test in modified-2.7.0 to use the __repr__ CArgObject currently has. Since this is my first 
patch for PyPy I wasn't sure which solution was preferred.

----------
effort: easy
files: ctypes_basics.diff
messages: 2168
nosy: brett.cannon, pypy-issue
priority: bug
release: 1.4
status: unread
title: Fix for ctypes.test.test_objects failures under 2.7.0

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

From pypy-dev-issue at codespeak.net  Fri Feb 25 02:09:27 2011
From: pypy-dev-issue at codespeak.net (Dan)
Date: Fri, 25 Feb 2011 01:09:27 +0000
Subject: [PyPy-issue] [issue644] Add option parser to package.py
Message-ID: <1298596167.56.0.337983976343.issue644@>


New submission from Dan <dcolish at gmail.com>:

I've been using package.py a lot more often now and I find an option parser interface to be nice for 
command line scripts. I've written one for package.py, but I believe it will require buildbot updates since 
buildbot is calling the old interface.

----------
effort: ???
files: package.diff
messages: 2169
nosy: dcolish, pypy-issue
priority: wish
release: ???
status: in-progress
title: Add option parser to package.py

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

From pypy-dev-issue at codespeak.net  Fri Feb 25 13:11:23 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 25 Feb 2011 12:11:23 +0000
Subject: [PyPy-issue] [issue643] Fix for ctypes.test.test_objects failures
	under 2.7.0
Message-ID: <1298635883.88.0.832005907187.issue643@>


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

Bah, what is this __repr__ that just returns the repr of another object?  /me
blames ctypes...

The problem with modified_ctypes_test_objects.diff is that we try to make the
modified tests in such a way that they also pass on CPython; it's not obvious
how to do it in this case, so I guess just changing __repr__ is the way to go.

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

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


From pypy-dev-issue at codespeak.net  Fri Feb 25 13:12:50 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 25 Feb 2011 12:12:50 +0000
Subject: [PyPy-issue] [issue640] Possible optimization in FOR_ITER on a
	constant tuple
Message-ID: <1298635970.08.0.121446545763.issue640@>


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

Where does p7 come from?

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

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


From pypy-dev-issue at codespeak.net  Fri Feb 25 17:53:52 2011
From: pypy-dev-issue at codespeak.net (Jean-Paul Calderone)
Date: Fri, 25 Feb 2011 16:53:52 +0000
Subject: [PyPy-issue] [issue645]
	twisted.test.test_threadable.SynchronizationTestCase.testThreadedSynchronization
	hangs
Message-ID: <1298652832.91.0.285352073761.issue645@>


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

This test passes on pypy-c aa1abfba10e1 but fails on a revision from shortly 
later, 84321e49b3c0.

----------
effort: ???
messages: 2172
nosy: calderone, pypy-issue
priority: bug
release: ???
status: unread
title: twisted.test.test_threadable.SynchronizationTestCase.testThreadedSynchronization hangs

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


From pypy-dev-issue at codespeak.net  Fri Feb 25 18:10:06 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Fri, 25 Feb 2011 17:10:06 +0000
Subject: [PyPy-issue] [issue640] Possible optimization in FOR_ITER on a
	constant tuple
Message-ID: <1298653806.69.0.147125370449.issue640@>


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

I'm not sure I understand, p7 is the iterator object.

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


From pypy-dev-issue at codespeak.net  Fri Feb 25 20:53:17 2011
From: pypy-dev-issue at codespeak.net (Brett Cannon)
Date: Fri, 25 Feb 2011 19:53:17 +0000
Subject: [PyPy-issue] [issue643] Fix for ctypes.test.test_objects failures
	under 2.7.0
Message-ID: <1298663597.39.0.996180414118.issue643@>


Brett Cannon <brett at python.org> added the comment:

The problem is that PyPy's ctypes uses a wrapper object while CPython's ctypes has no such wrapper (e.g., 
in the doctest, array._objects in CPython is just a dict, not a CArgObject instance with a dict assigned to 
_obj. I just did what was necessary to get the test to pass. Whether it is the best solution is another matter 
as I didn't bother to inspect the wrapper to make sure it will operate as the object it is meant to wrap.

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


From pypy-dev-issue at codespeak.net  Sat Feb 26 01:19:05 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 26 Feb 2011 00:19:05 +0000
Subject: [PyPy-issue] [issue640] Possible optimization in FOR_ITER on a
	constant tuple
Message-ID: <1298679545.32.0.546740664783.issue640@>


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

I meant "where" does the iterator p7 come from, in the literal sense --- is it
an input argument of the loop?  (I guess that the answer is yes)

I'm not 100% sure, but I think that it would be enough to mark 'tupleitems' as
an immutable field.  Now of course the problem is (again this issue) that it
cannot be an immutable field right now, and it's not obvious how to fix it,
because we want the effect that at the end of the iteration we stop keeping a
reference to 'tupleitems'...

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


From pypy-dev-issue at codespeak.net  Sat Feb 26 13:09:05 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 26 Feb 2011 12:09:05 +0000
Subject: [PyPy-issue] [issue645]
	twisted.test.test_threadable.SynchronizationTestCase.testThreadedSynchronization
	hangs
Message-ID: <1298722145.56.0.564978716387.issue645@>


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

84321e49b3c0 is actually from 7 days earlier than aa1abfba10e1.  What did you mean?

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

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


From pypy-dev-issue at codespeak.net  Sat Feb 26 14:23:49 2011
From: pypy-dev-issue at codespeak.net (Jean-Paul Calderone)
Date: Sat, 26 Feb 2011 13:23:49 +0000
Subject: [PyPy-issue] [issue645]
	twisted.test.test_threadable.SynchronizationTestCase.testThreadedSynchronization
	hangs
Message-ID: <1298726629.69.0.571594748728.issue645@>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Apparently I meant the other way around (sort of hard to keep opaque hashes 
straight, sorry).

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


From pypy-dev-issue at codespeak.net  Sat Feb 26 20:58:34 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sat, 26 Feb 2011 19:58:34 +0000
Subject: [PyPy-issue] [issue646] [PATCH] Support for PySlice_GetIndices
Message-ID: <1298750314.14.0.578776336809.issue646@>


New submission from Martijn <ss at kleptog.org>:

Attached is patch for PySlice_GetIndices

----------
effort: ???
files: PySlice_GetIndices.patch
messages: 2178
nosy: kleptog, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Support for PySlice_GetIndices

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue646>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PySlice_GetIndices.patch
Type: text/x-diff
Size: 4288 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110226/aa5ef570/attachment.patch>

From pypy-dev-issue at codespeak.net  Sat Feb 26 23:28:47 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sat, 26 Feb 2011 22:28:47 +0000
Subject: [PyPy-issue] [issue646] [PATCH] Support for PySlice_GetIndices
Message-ID: <1298759327.09.0.156234499828.issue646@>


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

Applied patch in 443ddfc7ee63. Thanks for your contribution!

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

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


From pypy-dev-issue at codespeak.net  Sat Feb 26 23:47:30 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sat, 26 Feb 2011 22:47:30 +0000
Subject: [PyPy-issue] [issue647] [PATCH] Support for PyString_AsEncodedObject
Message-ID: <1298760450.25.0.443140663009.issue647@>


New submission from Martijn <ss at kleptog.org>:

Attached is a patch for PyString_AsEncodedObject

----------
effort: ???
files: PyString_AsEncodedObject.patch
messages: 2180
nosy: kleptog, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Support for PyString_AsEncodedObject

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue647>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PyString_AsEncodedObject.patch
Type: text/x-diff
Size: 3597 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110226/ed7e7905/attachment.patch>

From pypy-dev-issue at codespeak.net  Sat Feb 26 23:50:38 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Sat, 26 Feb 2011 22:50:38 +0000
Subject: [PyPy-issue] [issue647] [PATCH] Support for PyString_AsEncodedObject
Message-ID: <1298760638.02.0.773625456157.issue647@>


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

Version using proper variable naming http://paste.pocoo.org/show/345067/

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

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 00:17:24 2011
From: pypy-dev-issue at codespeak.net (selena)
Date: Sat, 26 Feb 2011 23:17:24 +0000
Subject: [PyPy-issue] [issue648] __package__ not defined on import
Message-ID: <1298762244.04.0.985758099745.issue648@>


New submission from selena <selenamarie at gmail.com>:

Tests 5-7 are not passing in test_pkg.py because __package__ is not properly defined.

The relevant PEP is: http://www.python.org/dev/peps/pep-0366/

Dan & I tracked it down to pypy/module/imp/importing.py and are working on fixing it.

----------
effort: easy
messages: 2182
nosy: pypy-issue, selenamarie
priority: bug
release: ???
status: chatting
title: __package__ not defined on import

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 00:21:42 2011
From: pypy-dev-issue at codespeak.net (selena)
Date: Sat, 26 Feb 2011 23:21:42 +0000
Subject: [PyPy-issue] [issue648] __package__ not defined on import
Message-ID: <1298762502.96.0.228947931369.issue648@>


selena <selenamarie at gmail.com> added the comment:

And this is how this is implemented in CPython: 
http://svn.python.org/view/python/trunk/Python/import.c?revision=81380&view=markup

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 00:54:42 2011
From: pypy-dev-issue at codespeak.net (selena)
Date: Sat, 26 Feb 2011 23:54:42 +0000
Subject: [PyPy-issue] [issue648] __package__ not defined on import
Message-ID: <1298764482.49.0.137421429417.issue648@>


selena <selenamarie at gmail.com> added the comment:

Relevant diff for that PEP: http://bugs.python.org/file8852/pep_366_v2.diff

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 01:46:14 2011
From: pypy-dev-issue at codespeak.net (selena)
Date: Sun, 27 Feb 2011 00:46:14 +0000
Subject: [PyPy-issue] [issue648] __package__ not defined on import
Message-ID: <1298767574.39.0.494036365235.issue648@>


selena <selenamarie at gmail.com> added the comment:

Attached is a patch that sets __package__ and causes tests to pass.

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

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

From pypy-dev-issue at codespeak.net  Sun Feb 27 04:24:32 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Sun, 27 Feb 2011 03:24:32 +0000
Subject: [PyPy-issue] [issue648] __package__ not defined on import
Message-ID: <1298777072.35.0.514729142092.issue648@>


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

test_pkg passes for me, however there are obviously untested things (e.g. `from
test import test_support; test_support.__package__` is None on PyPy and "test"
on CPython.  So we could use some additional tests for the PyPy suite before
applying this.

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 16:02:05 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sun, 27 Feb 2011 15:02:05 +0000
Subject: [PyPy-issue] [issue647] [PATCH] Support for PyString_AsEncodedObject
Message-ID: <1298818925.69.0.957678981138.issue647@>


Martijn <ss at kleptog.org> added the comment:

Updated patch with variable name changes. Thanks!

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue647>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PyString_AsEncodedObject.patch2
Type: application/octet-stream
Size: 3545 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110227/caf6a0b9/attachment.obj>

From pypy-dev-issue at codespeak.net  Sun Feb 27 19:05:40 2011
From: pypy-dev-issue at codespeak.net (Dan)
Date: Sun, 27 Feb 2011 18:05:40 +0000
Subject: [PyPy-issue] [issue648] __package__ not defined on import
Message-ID: <1298829940.74.0.0280375344078.issue648@>


Dan <dcolish at gmail.com> added the comment:

Hmm, I think this might have been a regression at one point, but running the tests today I'm not seeing 
that failure.

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 21:41:34 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sun, 27 Feb 2011 20:41:34 +0000
Subject: [PyPy-issue] [issue649] [PATCH] Support for PyErr_WriteUnraisable
Message-ID: <1298839294.81.0.162419338392.issue649@>


New submission from Martijn <ss at kleptog.org>:

Attached is patch for PyErr_WriteUnraisable

----------
effort: ???
files: PyErr_WriteUnraisable.patch
messages: 2189
nosy: kleptog, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Support for PyErr_WriteUnraisable

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue649>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PyErr_WriteUnraisable.patch
Type: text/x-diff
Size: 2902 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110227/c553c6bf/attachment.patch>

From pypy-dev-issue at codespeak.net  Sun Feb 27 22:38:19 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sun, 27 Feb 2011 21:38:19 +0000
Subject: [PyPy-issue] [issue650] pypy_decl.h uses incorrect types for
	arguments
Message-ID: <1298842699.81.0.357126593726.issue650@>


New submission from Martijn <ss at kleptog.org>:

When methods are created in cpyext they properly declare they accept Py_ssize_tP
but in pypy_decl.h it outputs long*. While for a C compiler these are the same,
a C++ compiler considers them quite different. For example:

PyAPI_FUNC(int) PyString_AsStringAndSize(PyObject *arg0, char **arg1, long *arg2);

The basic cause is because in api.py we have the line:

Py_ssize_t = lltype.Signed

Which means that the rest of the code can't distinguish the two. What you need
is a sort of typedef which means the same code is produced, but a different name
is used in the C output. I tried subclassing but that made errors relating to
metaclasses. Maybe there is another solution?

----------
effort: ???
messages: 2190
nosy: kleptog, pypy-issue
priority: bug
release: ???
status: unread
title: pypy_decl.h uses incorrect types for arguments

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 22:43:07 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sun, 27 Feb 2011 21:43:07 +0000
Subject: [PyPy-issue] [issue649] [PATCH] Support for PyErr_WriteUnraisable
Message-ID: <1298842987.11.0.545807836305.issue649@>


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

Thanks! applied with 9adf3462fae3.

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

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 22:59:54 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sun, 27 Feb 2011 21:59:54 +0000
Subject: [PyPy-issue] [issue650] pypy_decl.h uses incorrect types for
	arguments
Message-ID: <1298843994.41.0.140282624659.issue650@>


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

cpyext already uses for similar reasons rffi.INT_real (because it's rendered as a C long), 
rffi.VOIDP_real (because it's rendered as a char*).

Maybe it's time for the C backend to emit C code that corresponds better corresponds to the 
RPython type: rffi.XXX will faithfully emit the corresponding C type. OTOH, lltype.Signed 
can be any integer type with the desired size.

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

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


From pypy-dev-issue at codespeak.net  Sun Feb 27 23:38:58 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Sun, 27 Feb 2011 22:38:58 +0000
Subject: [PyPy-issue] [issue647] [PATCH] Support for PyString_AsEncodedObject
Message-ID: <1298846338.73.0.959214177729.issue647@>


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

Applied with f8db2ce04d45. Thanks!

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

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 03:28:45 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 28 Feb 2011 02:28:45 +0000
Subject: [PyPy-issue] [issue650] pypy_decl.h uses incorrect types for
	arguments
Message-ID: <1298860125.05.0.733529367858.issue650@>


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

FWIW, I agree with Amaury.  It would be a first step towards a much-awaited
clean-up.

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 07:44:51 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 28 Feb 2011 06:44:51 +0000
Subject: [PyPy-issue] [issue650] pypy_decl.h uses incorrect types for
	arguments
Message-ID: <1298875491.78.0.47519413212.issue650@>


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

Is there any reason why rffi.VOIDP emits char*? Can't we just make it emit void* 
(like VOIDP_real) and kill VOIDP_real?

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 08:25:27 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 28 Feb 2011 07:25:27 +0000
Subject: [PyPy-issue] [issue619] Easier tuning/configuration of GC
Message-ID: <1298877927.68.0.190462140796.issue619@>


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

kleptog: should we close this issue? As of now it's unreproducible

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 08:32:17 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Mon, 28 Feb 2011 07:32:17 +0000
Subject: [PyPy-issue] [issue619] Easier tuning/configuration of GC
Message-ID: <1298878337.0.0.987487216265.issue619@>


Martijn <ss at kleptog.org> added the comment:

Fine by me. I've tried to simulate the problem with test programs but without
success. So it's obviously something else. If I get a good test case I'll resubmit.

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 08:33:54 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 28 Feb 2011 07:33:54 +0000
Subject: [PyPy-issue] [issue619] Easier tuning/configuration of GC
Message-ID: <1298878434.34.0.258993810144.issue619@>


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

closing then

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

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 10:11:12 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 28 Feb 2011 09:11:12 +0000
Subject: [PyPy-issue] [issue642] 64bit sandboxes with jit fail during startup
Message-ID: <1298884272.6.0.163712296494.issue642@>


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

For what is worth I fixed that particular issue. Armin's point still stand a bit.

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

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 13:06:37 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 28 Feb 2011 12:06:37 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298894797.78.0.933662876258.issue641@>


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

Hey.

CSV module in Cpython is written in C. I don't think this can be considered a 
bug, unless someone is *really* willing to rewrite pypy's implementation to C. 
Closing as won't fix.

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

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 13:58:43 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 28 Feb 2011 12:58:43 +0000
Subject: [PyPy-issue] [issue643] Fix for ctypes.test.test_objects failures
	under 2.7.0
Message-ID: <1298897923.44.0.37439603408.issue643@>


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

My question is a bit how those tests are relevant. Do we care what exactly is in 
._objects of a ctypes thing?

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 14:02:47 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Mon, 28 Feb 2011 13:02:47 +0000
Subject: [PyPy-issue] [issue643] Fix for ctypes.test.test_objects failures
	under 2.7.0
Message-ID: <1298898167.1.0.736039762703.issue643@>


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

Yes we care. A missing item in _objects often means that the ctypes buffer will 
point to invalid memory when the underlying object is collected.

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 14:03:35 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 28 Feb 2011 13:03:35 +0000
Subject: [PyPy-issue] [issue643] Fix for ctypes.test.test_objects failures
	under 2.7.0
Message-ID: <1298898215.52.0.897741161603.issue643@>


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

I don't say we don't care whats in there. Do we care about the exact __repr__ of 
the container?

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


From pypy-dev-issue at codespeak.net  Mon Feb 28 23:51:39 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Mon, 28 Feb 2011 22:51:39 +0000
Subject: [PyPy-issue] [issue651] [PATCH] Support for
	PyUnicode_AsEncodedObject
Message-ID: <1298933499.57.0.0424330601393.issue651@>


New submission from Martijn <ss at kleptog.org>:

PyUnicode_AsEncodedObject is almost identical to PyUnicode_AsEncodedString
except that the former does not check if the result is a string or not. It is
presently undocumented (but see http://bugs.python.org/issue10435) however for
the code it is clear the only difference is that AsEncodedObject does not check
the result is a string. Hence this patch renames AsEncodedString to
AsEncodedObject and creates a new AsEncodedString which calls the other and adds
a check.

----------
effort: ???
files: PyUnicode_AsEncodedObject.patch
messages: 2204
nosy: kleptog, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Support for PyUnicode_AsEncodedObject

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue651>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PyUnicode_AsEncodedObject.patch
Type: text/x-diff
Size: 1877 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110228/5e3a315a/attachment.patch>