From pypy-dev-issue at codespeak.net  Tue Mar  1 01:25:01 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Tue, 01 Mar 2011 00:25:01 +0000
Subject: [PyPy-issue] [issue652] Fix bugs in pyparser/future.py
Message-ID: <1298939101.63.0.533426082908.issue652@>


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

Hello,

I have a patch series that fix bugs in future imports handling:
* Add lineno & col_offset assertions
* Fix mac-style line counting
* Handle continuation lines

Please review / pull
The series is currently in the translation phase, I'll post updates here later.

changesets 42313 to 42317 in
https://vincentlegoll at bitbucket.org/vincentlegoll/pypy-for-upstream-vincent-legoll

----------
assignedto: vincele
effort: easy
messages: 2205
nosy: pypy-issue, vincele
priority: bug
release: 1.4
status: in-progress
title: Fix bugs in pyparser/future.py

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 01:48:31 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Tue, 01 Mar 2011 00:48:31 +0000
Subject: [PyPy-issue] [issue652] Fix bugs in pyparser/future.py
Message-ID: <1298940511.74.0.22015568688.issue652@>


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

Translation: OK
Test: OK

$ pypy/test_all.py pypy/interpreter/pyparser/test/test_futureautomaton.py
-pypy=./pypy-c
=== test session starts ===
platform linux2 -- Python 2.6.6 -- pytest-1.3.1
test object 1: pypy/interpreter/pyparser/test/test_futureautomaton.py

pypy/interpreter/pyparser/test/test_futureautomaton.py .........................

=== 25 passed in 0.08 seconds ===

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 02:34:21 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 01 Mar 2011 01:34:21 +0000
Subject: [PyPy-issue] [issue619] Easier tuning/configuration of GC
Message-ID: <1298943261.33.0.84312498937.issue619@>


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

fijal: may I ask why you are ignoring my question?  If it's because I didn't
understand the original problem at all, fine, but please at least say so.

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 02:44:54 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Tue, 01 Mar 2011 01:44:54 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298943894.69.0.899682533157.issue641@>


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

Re-opening.  I don't agree that we should close a performance bug report as
"won't fix" for some internal reason like "nobody wants to rewrite _csv to
RPython".  That's against the point of asking people to report performance issues.

I think it's better to keep such issues as opened, even if they stay around
opened for a long time.  (For all I know, maybe it will stay around for long
enough that eventually the pure Python version gets JITted so well that
rewriting to RPython doesn't make sense any more.  *Then* we can close it.)

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 05:03:15 2011
From: pypy-dev-issue at codespeak.net (Benjamin Peterson)
Date: Tue, 01 Mar 2011 04:03:15 +0000
Subject: [PyPy-issue] [issue652] Fix bugs in pyparser/future.py
Message-ID: <1298952195.42.0.900817983719.issue652@>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks, now merged with a few changes. You should probably report that test to
the Cpython tracker.

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 08:11:40 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 01 Mar 2011 07:11:40 +0000
Subject: [PyPy-issue] [issue619] Easier tuning/configuration of GC
Message-ID: <1298963500.61.0.896928659891.issue619@>


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

@arigo I don't remember details now but I vaguely remember lots of objects with 
__del__s referencing each other (via weak dicts). Anyway, without being able to 
reproduce the problem we can't do much can we? (we don't have the code).

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 08:14:05 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 01 Mar 2011 07:14:05 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298963645.91.0.304314635537.issue641@>


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

Ok fine. I don't think it's interesting to keep such issues, but if you think it 
is let's keep it.

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 09:18:16 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 01 Mar 2011 08:18:16 +0000
Subject: [PyPy-issue] [issue651] [PATCH] Support for
	PyUnicode_AsEncodedObject
Message-ID: <1298967496.8.0.698777340848.issue651@>


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

Hi.

Can you also come up with a simple test together with this patch?

Cheers,
fijal

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 09:37:26 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 01 Mar 2011 08:37:26 +0000
Subject: [PyPy-issue] [issue442] range call is much slower when using 2args
Message-ID: <1298968646.58.0.325904640437.issue442@>


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

This is not true any more, JIT optimizes it away. Closing

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 09:38:47 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Tue, 01 Mar 2011 08:38:47 +0000
Subject: [PyPy-issue] [issue442] range call is much slower when using 2args
Message-ID: <1298968727.16.0.964145557202.issue442@>


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

Are you sure?  At least for one arg call there's still fun nonsense with defs_w.

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 09:54:36 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Tue, 01 Mar 2011 08:54:36 +0000
Subject: [PyPy-issue] [issue442] range call is much slower when using 2args
Message-ID: <1298969676.08.0.0320434729299.issue442@>


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

fijal and I discussed, I was confusing issues :)

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 10:23:34 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Tue, 01 Mar 2011 09:23:34 +0000
Subject: [PyPy-issue] [issue652] Fix bugs in pyparser/future.py
Message-ID: <1298971414.56.0.442610249941.issue652@>


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

Thanks for the merge, and the additional cleanups. I'll have more patches
building up on that which hopefully fix a 2.7.0/test/test_runpy failure...

I'll have a look at cpython tests for those issues too.

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 10:31:16 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Tue, 01 Mar 2011 09:31:16 +0000
Subject: [PyPy-issue] [issue652] Fix bugs in pyparser/future.py
Message-ID: <1298971876.68.0.165892839214.issue652@>


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

Looks like test_explicit_relative_import & test_main_relative_import from
test_runpy, still have errors, but not the "SyntaxError: __future__ statements
must appear at beginning of file"...

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 10:35:16 2011
From: pypy-dev-issue at codespeak.net (Janos)
Date: Tue, 01 Mar 2011 09:35:16 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298972116.15.0.0468072368962.issue641@>


Janos <mjanos5 at gmail.com> added the comment:

I'm just wondering if you guys find out what the cause of slowness, maybe you
find such a problem which fix also could make other non-CSV codes faster. I
think, CSV parsing requires lots of string and tuple/list creation and manipulation.

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 10:37:44 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 01 Mar 2011 09:37:44 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298972264.29.0.237136163226.issue641@>


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

It's really python version vs C version. Also I would expect (although it's just 
an informed guess since I didn't look) that python version is not nearly as 
optimized as C version. That's true for JSON for example.

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 10:50:42 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 01 Mar 2011 09:50:42 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298973042.15.0.640400587419.issue641@>


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

With the difference that pypy's _csv.py was written without any concern for 
performance.
An easy change is to make Reader and Writer new-style classes.

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 11:21:45 2011
From: pypy-dev-issue at codespeak.net (Janos)
Date: Tue, 01 Mar 2011 10:21:45 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298974905.41.0.11684106226.issue641@>


Janos <mjanos5 at gmail.com> added the comment:

It seems to me that not the csv module causes the performance difference. I
created a different version of the test.

There are 2 files in the attached tar.gz:

1. csvparsingtest_create_test_file.py: run it once, this creates the test data file.

2. csvparsingtest_read.py: this is the real test of the issue. This time, it
doesn't use the csv module. Reads the lines from the test file, split them at
commas, then convert the fields to floats. It still about 5x slower with pypy
than with cpython.

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

real	0m0.450s
user	0m0.416s
sys	0m0.036s

user at localhost:~/temp/pypytest$ time ~/usr/pypy-1.4.1-linux/bin/pypy
csvparsingtest_read.py 

real	0m2.410s
user	0m2.288s
sys	0m0.060s

_______________________________________________________
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.tar.gz
Type: application/gzip
Size: 434 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110301/1f29fcb6/attachment.bin>

From pypy-dev-issue at codespeak.net  Tue Mar  1 11:39:07 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 01 Mar 2011 10:39:07 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298975947.39.0.567502452861.issue641@>


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

float("0.395963681409") seems 14 times slower with pypy...

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 11:51:23 2011
From: pypy-dev-issue at codespeak.net (Janos)
Date: Tue, 01 Mar 2011 10:51:23 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298976683.02.0.169430201748.issue641@>


Janos <mjanos5 at gmail.com> added the comment:

Float conversion is really much slower (test attached).


for _ in xrange(1, 1000000):
	float("0.395963681409")


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

real	0m0.889s
user	0m0.880s
sys	0m0.008s

user at localhost:~/temp$ time ~/usr/pypy-1.4.1-linux/bin/pypy float_test.py 

real	0m8.136s
user	0m7.764s
sys	0m0.024s

_______________________________________________________
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: float_test.py
Type: text/x-python
Size: 55 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110301/54ddae01/attachment.py>

From pypy-dev-issue at codespeak.net  Tue Mar  1 12:01:11 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 01 Mar 2011 11:01:11 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298977271.03.0.582621964756.issue641@>


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

Actually the results are much better, and depend on the versions of CPython and pypy.
With the simple script: 

def f():
    for a in range(10000):
        float("0.395963681409")

I run 'python -m timeit -s "from script import f" f()'
on Windows:
CPython2.5: 100 loops, best of 3: 15.2 msec per loop
CPython2.6: 100 loops, best of 3: 8.43 msec per loop
CPython2.7: 100 loops, best of 3: 3.28 msec per loop
CPython3.2: 100 loops, best of 3: 4.34 msec per loop
pypy-1.4.1: 10 loops, best of 3: 46.4 msec per loop   (your version)
pypy-nojit: 100 loops, best of 3: 6.26 msec per loop  (recent build)
pypy-jit  : 100 loops, best of 3: 1.89 msec per loop  (default branch, built 1 month ago)

The improvements are certainly due to the new dtoa functions (David Gay's floating point 
routines). Now csvparsingtest_read.py runs a bit faster than with python2.7.

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 12:25:17 2011
From: pypy-dev-issue at codespeak.net (Janos)
Date: Tue, 01 Mar 2011 11:25:17 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298978717.73.0.182306313648.issue641@>


Janos <mjanos5 at gmail.com> added the comment:

Nice work guys, thank you. I did not know David's workuntil now, just tried the
latest release.

I just now tried the latest build,
pypy-c-nojit-42363-36c913eb1084-linux.tar.bz2, and it is really fast:

user at localhost:~/temp/pypytest$ time
~/usr/pypy-c-jit-42353-28258c92cb25-linux/bin/pypy float_test.py 

real	0m0.319s
user	0m0.300s
sys	0m0.016s

user at localhost:~/temp/pypytest$ time
~/usr/pypy-c-jit-42353-28258c92cb25-linux/bin/pypy csvparsingtest_read.py 

real	0m0.444s
user	0m0.380s
sys	0m0.052s

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 12:36:30 2011
From: pypy-dev-issue at codespeak.net (Janos)
Date: Tue, 01 Mar 2011 11:36:30 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1298979390.79.0.688229628401.issue641@>


Janos <mjanos5 at gmail.com> added the comment:

Cpython is still faster in the original test csvparsingtest.py, but I think
fijal have right and it's only because of C implementation of the csv module.
Pypy will beat that too sometime in the future :)

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

real	0m1.090s
user	0m0.988s
sys	0m0.076s

user at localhost:~/temp/pypytest$ time
~/usr/pypy-c-jit-42353-28258c92cb25-linux/bin/pypy csvparsingtest.py

real	0m3.284s
user	0m3.172s
sys	0m0.048s

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 17:33:24 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Tue, 01 Mar 2011 16:33:24 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1298997204.59.0.724697529998.issue653@>


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

Here's a fix for
ERROR: test_absolute_import_without_future (test.test_import.RelativeImportTests)

Translation check in progress

----------
assignedto: vincele
effort: easy
files: fix-test_absolute_import_without_future.diff
messages: 2227
nosy: pypy-issue, vincele
priority: bug
release: 1.4
status: testing
title: fix for test_absolute_import_without_future

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

From pypy-dev-issue at codespeak.net  Tue Mar  1 17:34:42 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Tue, 01 Mar 2011 16:34:42 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1298997282.79.0.508606245922.issue653@>


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

It definitely translates (once you get familiar with RPython it's not really
needed to actually run a full translation for small things like this.  It does
however need a test for our suite.

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


From pypy-dev-issue at codespeak.net  Tue Mar  1 18:35:43 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Tue, 01 Mar 2011 17:35:43 +0000
Subject: [PyPy-issue] [issue641] reading CSV files with csv module is much
	slower than CPython 2.6.6
Message-ID: <1299000943.05.0.111579940875.issue641@>


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

Amaury and I (mostly Amaury) did some work on CSV, much closer now:

alex at alex-laptop:/tmp$ time python test.py 

real	0m0.830s
user	0m0.792s
sys	0m0.032s
alex at alex-laptop:/tmp$ time ~/projects/pypy/pypy-c test.py 

real	0m1.324s
user	0m1.244s
sys	0m0.056s

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


From pypy-dev-issue at codespeak.net  Wed Mar  2 01:34:27 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Wed, 02 Mar 2011 00:34:27 +0000
Subject: [PyPy-issue] [issue654] Fix for test_incorrect_code_name
Message-ID: <1299026067.74.0.246955785893.issue654@>


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

Fix for FAIL: test_incorrect_code_name (test.test_import.PycRewritingTests)

Pypy lacks cpython's import.c update_code_filenames() logic.
Implement and make the test pass.

----------
assignedto: vincele
effort: medium
files: fix-test_incorrect_code_name.diff
messages: 2230
nosy: pypy-issue, vincele
priority: bug
release: 1.4
status: testing
title: Fix for test_incorrect_code_name

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

From pypy-dev-issue at codespeak.net  Wed Mar  2 10:08:50 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Wed, 02 Mar 2011 09:08:50 +0000
Subject: [PyPy-issue] [issue654] Fix for test_incorrect_code_name
Message-ID: <1299056930.72.0.926420138365.issue654@>


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

This should also come with a test

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


From pypy-dev-issue at codespeak.net  Wed Mar  2 14:43:03 2011
From: pypy-dev-issue at codespeak.net (Jean-Paul Calderone)
Date: Wed, 02 Mar 2011 13:43:03 +0000
Subject: [PyPy-issue] [issue637]
	twisted.conch.test.test_recvline.RecvlineLoopbackTelnet.testLeftArrow
	fails after 29 iterations
Message-ID: <1299073383.45.0.371771199467.issue637@>


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

Adding `--jit threshold=N` changes the behavior.  For some N, like 100, it fails 
faster.  For others, like 50, it appears to work reliably.

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


From pypy-dev-issue at codespeak.net  Wed Mar  2 21:38:32 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Wed, 02 Mar 2011 20:38:32 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1299098312.5.0.33506740782.issue653@>


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

Fix is at commit 42322:a665609d9078
Test is at commit 42323:9d4bb868efe7

in https://bitbucket.org/vincentlegoll/pypy-for-upstream-vincent-legoll

please cherry-pick as there are unrelated changes in this repository

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


From pypy-dev-issue at codespeak.net  Wed Mar  2 21:43:21 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Wed, 02 Mar 2011 20:43:21 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1299098601.69.0.692793838401.issue653@>


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

And at commit 42324:3b43d0a7ef92
there is a fix for the other tests that are now failing due to the fix...

please review and also cherry-pick if OK

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 00:02:57 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Wed, 02 Mar 2011 23:02:57 +0000
Subject: [PyPy-issue] [issue655] Fix get/setpgrp() platcheck platform errors
Message-ID: <1299106977.28.0.500326917916.issue655@>


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

The changeset commit 42327:4748aeae3281
https://bitbucket.org/vincentlegoll/pypy-for-upstream-vincent-legoll

Fixes:

[platform:Error] platcheck_7.c: In function ?main?:
[platform:Error] platcheck_7.c:31: error: too many arguments to function ?getpgrp?
[platform:Error] platcheck_8.c: In function ?main?:
[platform:Error] platcheck_8.c:31: error: too many arguments to function ?setpgrp?

on linux x86-64

Please review, and cherry-pick if OK

----------
assignedto: vincele
effort: easy
messages: 2235
nosy: pypy-issue, vincele
priority: bug
release: 1.4
status: testing
title: Fix get/setpgrp() platcheck platform errors

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 00:05:08 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Wed, 02 Mar 2011 23:05:08 +0000
Subject: [PyPy-issue] [issue655] Fix get/setpgrp() platcheck platform errors
Message-ID: <1299107108.31.0.906160117683.issue655@>


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

please disregard this changeset, it has some wrong hunks in it.

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 00:38:13 2011
From: pypy-dev-issue at codespeak.net (Brett Cannon)
Date: Wed, 02 Mar 2011 23:38:13 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1299109093.9.0.170573761299.issue653@>


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

Just to follow up on the discusson on #pypy, this is the wrong fix; an ImportError is expected as the 
``from .os import sep`` is trying to import test.os which does not exist.

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 00:45:54 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Wed, 02 Mar 2011 23:45:54 +0000
Subject: [PyPy-issue] [issue655] Fix get/setpgrp() platcheck platform errors
Message-ID: <1299109554.3.0.387258798982.issue655@>


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

but... this is not an error, only a "checkcompiles" that returns False (getgrp() 
takes no argument on your platform).
What we could do instead is somehow suppress the red lines and print by a more 
neutral message instead ("check whether getgrp() takes an argument... no")

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 08:06:37 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Thu, 03 Mar 2011 07:06:37 +0000
Subject: [PyPy-issue] [issue655] Fix get/setpgrp() platcheck platform errors
Message-ID: <1299135997.42.0.586686856023.issue655@>


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

This particular check is to see how many arguments setpgrp accepts. It's 
different on Linux and OS/X. Hiding this red info (this is not an error, just 
check) would be a much better fix.

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 09:18:31 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Thu, 03 Mar 2011 08:18:31 +0000
Subject: [PyPy-issue] [issue650] pypy_decl.h uses incorrect types for
	arguments
Message-ID: <1299140311.33.0.12117681852.issue650@>


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

It surprised me that cpyext didn't use real C types everywhere at the interface,
anything less seems weird. Of course the wrapper can convert whatever it likes.

There doesn't seem to be any provision for typedefs at the rffi level (size_t is
simply declared as integer type) so if something is going to be cleaned up, this
should probably be included.

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 09:46:10 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 03 Mar 2011 08:46:10 +0000
Subject: [PyPy-issue] [issue650] pypy_decl.h uses incorrect types for
	arguments
Message-ID: <1299141970.74.0.330938389681.issue650@>


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

Work is in progress in branch real-rffi.INT

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

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 10:00:19 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Thu, 03 Mar 2011 09:00:19 +0000
Subject: [PyPy-issue] [issue655] Fix get/setpgrp() platcheck platform errors
Message-ID: <1299142819.63.0.42677036026.issue655@>


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

I think linux can accept both the BSD or POSIX/SYSV variants depending on flags.

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 13:30:07 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Thu, 03 Mar 2011 12:30:07 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1299155407.0.0.575558765004.issue653@>


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

And now for something even stranger, the following does *NOT* reproduce the bug:

$ mkdir tmpmodule
$ touch tmpmodule/__init__.py
$ echo "from .os import sep" > tmpmodule/tmpreproduce.py
$ python2.7 tmpmodule/tmpreproduce.py
Traceback (most recent call last):
  File "tmpmodule/tmpreproduce.py", line 1, in <module>
    from .os import sep
ValueError: Attempted relative import in non-package
$ python2.7 -c 'import tmpmodule;import tmpmodule.tmpreproduce'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "tmpmodule/tmpreproduce.py", line 1, in <module>
    from .os import sep
ImportError: No module named os
$ pypy tmpmodule/tmpreproduce.py
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "tmpmodule/tmpreproduce.py", line 1, in <module>
    from .os import sep
ValueError: Attempted relative import in non-package
$ pypy -c 'import tmpmodule;import tmpmodule.tmpreproduce'
Traceback (most recent call last):
  File "app_main.py", line 53, in run_toplevel
  File "app_main.py", line 506, in run_it
  File "<string>", line 1, in <module>
  File "tmpmodule/tmpreproduce.py", line 1, in <module>
    from .os import sep
ImportError: No module named tmpmodule.os

Isn't this what the test is doing ?

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 13:44:57 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 03 Mar 2011 12:44:57 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1299156297.14.0.089401830078.issue653@>


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

I suggest to fix this difference first (python2.7 prints 'test'):
$ pypy-c -c "from test import test_import; print test_import.__package__"
None

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


From pypy-dev-issue at codespeak.net  Thu Mar  3 13:49:08 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Thu, 03 Mar 2011 12:49:08 +0000
Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future
Message-ID: <1299156548.42.0.905673232893.issue653@>


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

afa: That may be exactly the root cause for the bug, pypy thinks it's not in a
package and so reports the other exception...

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


From pypy-dev-issue at codespeak.net  Sat Mar  5 16:54:41 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Sat, 05 Mar 2011 15:54:41 +0000
Subject: [PyPy-issue] [issue656] Python code 20x slower than C++
Message-ID: <1299340481.96.0.252626731735.issue656@>


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

Changing min(a, b, c) to min(a, min(b, c)) brings this down to a reasonable 4x
slower (by removing all 5 allocations from the inner loop).

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

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


From pypy-dev-issue at codespeak.net  Sat Mar  5 16:59:18 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 05 Mar 2011 15:59:18 +0000
Subject: [PyPy-issue] [issue656] Python code 20x slower than C++
Message-ID: <1299340758.89.0.0870431131169.issue656@>


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

Ah.  I remember indeed that I added special-casing code for min(a,b).  A bit
unclear what to do; we can extend the special case to min(a,b,c), which is still
ok, but we shouldn't use it in general for min(a,b,c,d,...,y,z) because it
creates a series of many guards, each of which can fail.

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


From pypy-dev-issue at codespeak.net  Sat Mar  5 17:07:09 2011
From: pypy-dev-issue at codespeak.net (Laura Creighton)
Date: Sat, 05 Mar 2011 16:07:09 +0000
Subject: [PyPy-issue] [issue659] real-ffii : arrange for externals to always
	return real ints
Message-ID: <1299341229.98.0.145500351175.issue659@>


New submission from Laura Creighton <lac at openend.se>:

kleptog had a good idea.  I'll bet it applies to a lot of code not just the
code he is working on now.  Pasted in here so we don't lose it, and besides
it may make a good sprint topic for the people we meet at noisebridge
today.

<kleptog> I'm following the real-rffi branch and there seem to be a lot of
commits just to convert the results of external using intmask(). Surely it would
be more useful to arrange for externals to always return real ints (rather than
rffi). ISTM you rarely need the rffi return value...

<arigato> kleptog: I agree -- even if for some reason you really need the
rffi.INT result, you can cast it back

----------
effort: ???
messages: 2261
nosy: kleptog, lac, pypy-issue
priority: wish
release: ???
status: chatting
title: real-ffii : arrange for externals to always return real ints

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


From pypy-dev-issue at codespeak.net  Sun Mar  6 08:44:18 2011
From: pypy-dev-issue at codespeak.net (Ezio Melotti)
Date: Sun, 06 Mar 2011 07:44:18 +0000
Subject: [PyPy-issue] [issue660] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2/6.0
Message-ID: <1299397458.9.0.217869227612.issue660@>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch fixes a corner case in the utf8 decoder with some invalid 3-
or 4-bytes sequences when the error handler is "replace".
A more detailed explanation can be found in the CPython issue #8271[0] starting
from the message number 109155[1] (the previous part is already fixed in pypy).
The patch includes extensive tests.

Benchmarks with patch:
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from timeit import Timer
>>> setup_nonascii = 'from pypy.rlib.runicode import str_decode_utf_8; text =
open("test.txt").read(); l = len(text)'
>>> setup_ascii = 'from pypy.rlib.runicode import str_decode_utf_8; from string
import letters; text = letters*10000; l = len(text)'
>>> Timer('str_decode_utf_8(text, l, "strict")', setup_nonascii).timeit(10)
7.4703819751739502
>>> Timer('str_decode_utf_8(text, l, "ignore")', setup_nonascii).timeit(10)
7.4956531524658203
>>> Timer('str_decode_utf_8(text, l, "replace")', setup_nonascii).timeit(10)
8.0847411155700684
>>> Timer('str_decode_utf_8(text, l, "strict")', setup_ascii).timeit(10)
15.456485033035278
>>> Timer('str_decode_utf_8(text, l, "ignore")', setup_ascii).timeit(10)
14.893633127212524
>>> Timer('str_decode_utf_8(text, l, "replace")', setup_ascii).timeit(10)
15.023200035095215

Benchmarks without patch:
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from timeit import Timer
>>> setup_nonascii = 'from pypy.rlib.runicode import str_decode_utf_8; text =
open("test.txt").read(); l = len(text)'
>>> setup_ascii = 'from pypy.rlib.runicode import str_decode_utf_8; from string
import letters; text = letters*10000; l = len(text)'
>>> Timer('str_decode_utf_8(text, l, "strict")', setup_nonascii).timeit(10)
27.644415855407715
>>> Timer('str_decode_utf_8(text, l, "ignore")', setup_nonascii).timeit(10)
28.048332929611206
>>> Timer('str_decode_utf_8(text, l, "replace")', setup_nonascii).timeit(10)
28.484920978546143
>>> Timer('str_decode_utf_8(text, l, "strict")', setup_ascii).timeit(10)
15.727217197418213
>>> Timer('str_decode_utf_8(text, l, "ignore")', setup_ascii).timeit(10)
15.779711008071899
>>> Timer('str_decode_utf_8(text, l, "replace")', setup_ascii).timeit(10)
15.517917156219482


A few comments:
* This is not yet fixed in CPython, I started working on it but then figured  it
would have been easier to work on a Python version first;
* The speedup in the patched version is most likely because I removed the use of
pypy.rlib.bitmanipulation.splitter (regular bitwise operations looked simpler
and faster to me, so I used those);
* I moved all the utf-8-related tests in a new class;
* My editor stripped a few trailing spaces here and there that are unrelated to
the patch;
* The patch includes comments, but they are fairly specific. I could write a
more general comment to explain what the decoder and the tests do;
* In the decoder there is some code duplication where the error handler is
called. I can factor out the error message, but that won't make the things much
better;
* Even if this specific corner case is covered only by Unicode 6.0.0, the
general algorithm is described already in Unicode 5.2.0, therefore it should be
fixed even if Python don't use 6.0.0 yet.

[0]: http://bugs.python.org/issue8271
[1]: http://bugs.python.org/issue8271#msg109155

----------
effort: ???
files: issue8271.diff
messages: 2263
nosy: amaury, ezio.melotti, pypy-issue
priority: bug
release: ???
status: unread
title: str.decode('utf8', 'replace') -- conformance with Unicode 5.2/6.0

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue660>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: issue8271.diff
Type: text/x-diff
Size: 41871 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110306/b23e8e3a/attachment.diff>

From pypy-dev-issue at codespeak.net  Sun Mar  6 14:21:17 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sun, 06 Mar 2011 13:21:17 +0000
Subject: [PyPy-issue] [issue660] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2/6.0
Message-ID: <1299417677.74.0.988593457836.issue660@>


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

Just a general comment: benchmarking at this level is not relevant --- in
particular, using bitmanipulation.py has a big performance impact in
non-translated code, but none after translation.  (Of course if you judge that
using it here also makes the code more obscure, it is probably better to leave
it out.)

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

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


From pypy-dev-issue at codespeak.net  Sun Mar  6 18:09:01 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sun, 06 Mar 2011 17:09:01 +0000
Subject: [PyPy-issue] [issue651] [PATCH] Support for
	PyUnicode_AsEncodedObject
Message-ID: <1299431341.8.0.779216692544.issue651@>


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

Here is an update patch with a test. In principle the code was tested given that
all the existing code went through the new function.

What isn't possible to test is the failure case given there is no built-in codec
that returns anything other than a string. It would be in principle possible to
register a test codec but that seemed a lot of work for a test.  However, if
there's an easy way to do that, then the test is easily done.

_______________________________________________________
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: 3090 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110306/ca9f46e4/attachment.patch>

From pypy-dev-issue at codespeak.net  Sun Mar  6 18:14:54 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sun, 06 Mar 2011 17:14:54 +0000
Subject: [PyPy-issue] [issue661] [PATCH] Support for PyOS_[gs]etsig
Message-ID: <1299431694.62.0.950787260453.issue661@>


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

Support for the PyOS_[gs]etsig functions.

It may seem odd that these functions do not interact with the rest of the system
(i.e. their effects are not visible in the signal module) but this is apparently
intentional, CPython works the same way.  The signal handlers defined in the
signal module apparently define what happens if the normal Python signal handler
is called.

I chose to put the functions into a new file pysignals but it could easily be
added to another file, such as pythonrun, instead.

The actual C code for PyOS_[gs]etsig was copied from the Python codebase. I
don't believe this is a problem, but it might be.

----------
effort: ???
files: PyOS_signals.patch
messages: 2266
nosy: kleptog, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Support for PyOS_[gs]etsig

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

From pypy-dev-issue at codespeak.net  Sun Mar  6 18:33:59 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Sun, 06 Mar 2011 17:33:59 +0000
Subject: [PyPy-issue] [issue662] get_config_vars has nothing for CC,
	while expected internally
Message-ID: <1299432839.34.0.219138682981.issue662@>


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

Currently distutils.sysconfig.get_config_vars() has no value for CC. This means
that when you try to build a C extension using distutils it breaks, because
distutils internally uses get_config_vars() to determine the compiler
(distutils/ccompiler.py).

Attached is a patch that works for me, with this C extensions build normally
(excluding cpyext problems). But this may be a layering violation, so I'll leave
it to you guys to determine the correct fix. In any case it's an improvement
which improves compatibility.

----------
effort: ???
files: distutils.patch
messages: 2267
nosy: kleptog, pypy-issue
priority: feature
release: ???
status: unread
title: get_config_vars has nothing for CC, while expected internally

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

From pypy-dev-issue at codespeak.net  Sun Mar  6 20:16:18 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Sun, 06 Mar 2011 19:16:18 +0000
Subject: [PyPy-issue] [issue654] Fix for test_incorrect_code_name
Message-ID: <1299438978.55.0.666225356968.issue654@>


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

Here is a port of cpython's test that is also failing without the fix.

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

From pypy-dev-issue at codespeak.net  Mon Mar  7 09:02:26 2011
From: pypy-dev-issue at codespeak.net (Bob Ziuchkovski)
Date: Mon, 07 Mar 2011 08:02:26 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1299484946.86.0.792148317306.issue636@>


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

I have done a final bit of testing and it seems this error is specifically tied 
to unrolling a loop that contains a floating point variable as input.  
Furthermore, it appears the floating point value of the variable is lost and 
something very close to the 64bit minimum positive double value is used instead.  
The result of the attached floating_point_unroll_error.py is that after 
unrolling with the following arithmetic results occur:

# below, floatvar stores 2.0
1 * floatvar returns 6.92386558364043e-310
1 + floatvar returns 1.0
1 - floatvar returns 1.0

_______________________________________________________
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: floating_point_unroll_error.py
Type: text/x-python
Size: 301 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110307/915e01bf/attachment.py>

From pypy-dev-issue at codespeak.net  Mon Mar  7 19:12:10 2011
From: pypy-dev-issue at codespeak.net (David Edelsohn)
Date: Mon, 07 Mar 2011 18:12:10 +0000
Subject: [PyPy-issue] [issue663] [PATCH] Avoid XCHG
Message-ID: <1299521530.21.0.19754068063.issue663@>


New submission from David Edelsohn <dje.gcc at gmail.com>:

Convert use of XCHG to pairs of MOV because atomic semantics add extra expense
and don't pair well for dispatch.

----------
assignedto: edelsohn
effort: easy
files: assembler.patch
messages: 2270
nosy: edelsohn, pypy-issue
priority: feature
release: ???
status: testing
title: [PATCH] Avoid XCHG

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue663>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assembler.patch
Type: text/x-patch
Size: 1610 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110307/0b395bef/attachment.bin>

From pypy-dev-issue at codespeak.net  Mon Mar  7 19:33:57 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Mon, 07 Mar 2011 18:33:57 +0000
Subject: [PyPy-issue] [issue663] [PATCH] Avoid XCHG
Message-ID: <1299522837.34.0.75516110548.issue663@>


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

Thanks for the patch!  I tried to apply it, and also comment out the declaration
of XCHG in rx86.py and regloc.py with a comment that explains why using XCHG is
a bad idea.  However I found out that you didn't run any test.  There are issues
like using 0 instead of imm0.  Moreover test_basic segfaults, for reasons that
are probably easy to find and fix.  Can you try to provide an updated patch that
passes all tests as run by "python test_all.py jit/backend/x86/"?  Thank you :-)

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


From pypy-dev-issue at codespeak.net  Mon Mar  7 19:48:50 2011
From: pypy-dev-issue at codespeak.net (David Edelsohn)
Date: Mon, 07 Mar 2011 18:48:50 +0000
Subject: [PyPy-issue] [issue663] [PATCH] Avoid XCHG
Message-ID: <1299523730.84.0.745587317216.issue663@>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Revised patch commenting out XCHG in regloc.py and rx86.py.  Comment moved to
regloc.py.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue663>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xchg.patch
Type: text/x-patch
Size: 3230 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110307/80712575/attachment.bin>

From pypy-dev-issue at codespeak.net  Mon Mar  7 20:11:34 2011
From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz)
Date: Mon, 07 Mar 2011 19:11:34 +0000
Subject: [PyPy-issue] [issue663] [PATCH] Avoid XCHG
Message-ID: <1299525094.82.0.350990725631.issue663@>


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

there's still a mistake (leading to segfaults): one of the paths used
fail_boxes_ptr, one uses fail_boxes_int. The patch breaks this.

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


From pypy-dev-issue at codespeak.net  Mon Mar  7 21:07:35 2011
From: pypy-dev-issue at codespeak.net (David Edelsohn)
Date: Mon, 07 Mar 2011 20:07:35 +0000
Subject: [PyPy-issue] [issue663] [PATCH] Avoid XCHG
Message-ID: <1299528455.51.0.392928958299.issue663@>


David Edelsohn <dje.gcc at gmail.com> added the comment:

I mis-read the original code and thought two fields were the same and could be
hoisted.  Fixed now.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue663>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xchg.patch
Type: text/x-patch
Size: 3002 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110307/7b6a03ba/attachment.bin>

From pypy-dev-issue at codespeak.net  Mon Mar  7 21:55:20 2011
From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz)
Date: Mon, 07 Mar 2011 20:55:20 +0000
Subject: [PyPy-issue] [issue663] [PATCH] Avoid XCHG
Message-ID: <1299531320.07.0.360301561735.issue663@>


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

committed in 6599d8ca8be1. Thanks a lot for the patch, David!

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

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


From pypy-dev-issue at codespeak.net  Tue Mar  8 23:52:07 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Tue, 08 Mar 2011 22:52:07 +0000
Subject: [PyPy-issue] [issue664] [PATCH] Extend readline emulation to
	support colour code and ansi escapes
Message-ID: <1299624727.56.0.253008210735.issue664@>


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

Currently IPython breaks on terminal input because it uses readline features not
in PyPy, namely:

- Use of \x01 and \x02 to bracket ANSI escape codes to exclude them from length
calculations.
- Use of newlines in prompts.
- ANSI codes weren't handled in unix_console.

For the first there's a new function to calculate the length of the prompt. For
the second the prompt is split on newlines and output separately, which produces
the desired effect. For the last I added a bit of code that, if ANSI codes were
used, moves the cursor to a known position.

----------
effort: ???
files: readline-prompt.patch
messages: 2276
nosy: kleptog, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Extend readline emulation to support colour code and ansi escapes

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue664>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readline-prompt.patch
Type: text/x-patch
Size: 2892 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110308/f9a8e686/attachment.bin>

From pypy-dev-issue at codespeak.net  Wed Mar  9 17:58:30 2011
From: pypy-dev-issue at codespeak.net (David Edelsohn)
Date: Wed, 09 Mar 2011 16:58:30 +0000
Subject: [PyPy-issue] [issue665] Efficient zeroing of heap locations
Message-ID: <1299689910.58.0.539201979096.issue665@>


New submission from David Edelsohn <dje.gcc at gmail.com>:

_assemble_bootstrap_code zeros heap addresses individually, but could be
performed with fewer instructions and more efficiently with RPython code to zero
a block of memory.

----------
effort: medium
messages: 2277
nosy: edelsohn, pypy-issue
priority: feature
release: ???
status: unread
title: Efficient zeroing of heap locations

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


From pypy-dev-issue at codespeak.net  Wed Mar  9 18:58:31 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Wed, 09 Mar 2011 17:58:31 +0000
Subject: [PyPy-issue] [issue666] 'PyOS_sighandler_t' undeclared while
	compiling extension
Message-ID: <1299693511.87.0.464009946987.issue666@>


New submission from ys <ysbalt at live.com>:

I am trying to install an old version rpy2 (that installs with CPython 2.5) with
pypy-c. During the build process, it says 
error: 'PyOS_sighandler_t' undeclared 

Apparently PyOS_sighandler_t is not in Python.h, but comes from pythonrun.h, I
couldn't find it anywhere in the pypy directory.

----------
effort: ???
messages: 2278
nosy: baltcode, pypy-issue
priority: bug
release: ???
status: unread
title: 'PyOS_sighandler_t' undeclared while compiling extension

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


From pypy-dev-issue at codespeak.net  Wed Mar  9 23:44:50 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Wed, 09 Mar 2011 22:44:50 +0000
Subject: [PyPy-issue] [issue666] 'PyOS_sighandler_t' undeclared while
	compiling extension
Message-ID: <1299710690.28.0.237839100765.issue666@>


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

PyOS_sighandler_t is not enough, of course: rpy2 needs PyOS_setsig() and 
PyOS_getsig()

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

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


From pypy-dev-issue at codespeak.net  Thu Mar 10 15:30:05 2011
From: pypy-dev-issue at codespeak.net (Chris Smowton)
Date: Thu, 10 Mar 2011 14:30:05 +0000
Subject: [PyPy-issue] [issue667] Final link failure due to libtinfo
	dependency
Message-ID: <1299767405.56.0.72258074824.issue667@>


New submission from Chris Smowton <cs448 at cam.ac.uk>:

Translating pypy 1.4.1 (release) on Fedora 11 machines fails because
pypy/module/_minimal_curses/fficurses.py uses setupterm, tigetstr and tparm. 

Ordinarily, these are libncurses functions. The problem is, libncurses can be
built in a two ways: if it's configured normally, libncurses defines these
functions and everything works fine. If it's configured with "--with-termlib",
it generates a separate libtinfo that defines those functions, and users should
link with -ltinfo -lcurses.

PyPy currently doesn't test for this situation, and so the final stage link
fails at least on Fedora 11 boxes, which use the --with-termlib option in their
standard distributed libncurses.

>From libncurses 5.8 the ncurses5-config --libs program will give you the correct
linker flags; however in at least libncurses 5.7 that program doesn't mention
libtinfo. You could search for libtinfo, or check using objdump / nm whether
ncurses actually defined the needed functions?

----------
effort: easy
messages: 2280
nosy: pypy-issue, smowton
priority: bug
release: 1.4
status: unread
title: Final link failure due to libtinfo dependency

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


From pypy-dev-issue at codespeak.net  Thu Mar 10 23:28:00 2011
From: pypy-dev-issue at codespeak.net (Martijn)
Date: Thu, 10 Mar 2011 22:28:00 +0000
Subject: [PyPy-issue] [issue666] 'PyOS_sighandler_t' undeclared while
	compiling extension
Message-ID: <1299796080.83.0.408372078998.issue666@>


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

There is a patch attached to issue 661.

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


From pypy-dev-issue at codespeak.net  Thu Mar 10 23:45:02 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 10 Mar 2011 22:45:02 +0000
Subject: [PyPy-issue] [issue661] [PATCH] Support for PyOS_[gs]etsig
Message-ID: <1299797102.58.0.640622835248.issue661@>


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

Applied with 538a36110333, thanks for the excellent patch!

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

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


From pypy-dev-issue at codespeak.net  Thu Mar 10 23:53:07 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Thu, 10 Mar 2011 22:53:07 +0000
Subject: [PyPy-issue] [issue651] [PATCH] Support for
	PyUnicode_AsEncodedObject
Message-ID: <1299797587.14.0.246377037665.issue651@>


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

Committed f507f17140af, thanks for the patch!

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

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


From pypy-dev-issue at codespeak.net  Fri Mar 11 16:59:30 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 11 Mar 2011 15:59:30 +0000
Subject: [PyPy-issue] [issue667] Final link failure due to libtinfo
	dependency
Message-ID: <1299859170.54.0.153253050661.issue667@>


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

Does it work with the attached patch?  (You can test by running "python
test_all.py module/_minimal_curses/")

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue667>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch1
Type: application/octet-stream
Size: 1014 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110311/697707b9/attachment.obj>

From pypy-dev-issue at codespeak.net  Fri Mar 11 17:05:30 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 11 Mar 2011 16:05:30 +0000
Subject: [PyPy-issue] [issue665] Efficient zeroing of heap locations
Message-ID: <1299859530.61.0.0786272478885.issue665@>


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

Would it really be more efficient?  The addresses that need to be zeroed are not
contiguous, but instead form some random pattern in that array (maybe half of
the addresses in some range).  I think that generating exactly the sequence of
MOV instructions needed to clear the required locations is the most efficient
way, short of some more direct, involved interaction with the GC.  It certainly
looks more efficient than calling some external function like memset().

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

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


From pypy-dev-issue at codespeak.net  Fri Mar 11 17:24:43 2011
From: pypy-dev-issue at codespeak.net (David Edelsohn)
Date: Fri, 11 Mar 2011 16:24:43 +0000
Subject: [PyPy-issue] [issue665] Efficient zeroing of heap locations
Message-ID: <1299860683.4.0.632527527671.issue665@>


David Edelsohn <dje.gcc at gmail.com> added the comment:

For some of the Unladen benchmarks, we found long sequences of XOR/XCHG. 
Someone else mentioned that storing more zeros was safe.  If the address range
is not contiguous, then zeroing blocks of memory is not practical and the new
MOV sequences are a reasonable solution.

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


From pypy-dev-issue at codespeak.net  Fri Mar 11 18:38:44 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Fri, 11 Mar 2011 17:38:44 +0000
Subject: [PyPy-issue] [issue668] Supplying custom path for installed native
	ibraries
Message-ID: <1299865124.48.0.0344349257672.issue668@>


New submission from ys <ysbalt at live.com>:

I am trying to build pypy-c on a Mac machine using the commit 42500:dd8ead285f81
from the bitbucket repo. I have libintl stored in a custom location,
$HOME/opt/local/lib. I run (using a previously built pypy-c),
pypy-c translate.py -Ojit --ldflags=-L~/opt/local/lib --cflags=-L~/opt/local/lib

However, after about half an hour, it stalls with 
[translation:ERROR] 	ld: library not found for -lintl
[translation:ERROR] 	collect2: ld returned 1 exit status
[translation:ERROR] 	make: *** [pypy-c] Error 1
[translation:ERROR] 	""")

----------
effort: ???
messages: 2287
nosy: baltcode, pypy-issue
priority: critical
release: ???
status: unread
title: Supplying custom path for installed native ibraries

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


From pypy-dev-issue at codespeak.net  Sat Mar 12 01:29:47 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Sat, 12 Mar 2011 00:29:47 +0000
Subject: [PyPy-issue] [issue668] Supplying custom path for installed native
	libraries
Message-ID: <1299889787.23.0.809783234056.issue668@>


ys <ysbalt at live.com> added the comment:

I think the library and include dirs only come from sdl-config and the ones
hardcoded in the translator/platform/$PLATFORM.py files. There should be a way
to add to these directories on the tranlate.py command line.

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

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


From pypy-dev-issue at codespeak.net  Sat Mar 12 11:07:04 2011
From: pypy-dev-issue at codespeak.net (Bob Ippolito)
Date: Sat, 12 Mar 2011 10:07:04 +0000
Subject: [PyPy-issue] [issue669] [PATCH} Fix urllib on Mac OS X with missing
	_scproxy module
Message-ID: <1299924424.5.0.13164138469.issue669@>


New submission from Bob Ippolito <bob at redivi.com>:

In the current tip (4604f1b75a11) urllib does not work on Mac OS X due to missing _scproxy extension. I've 
written a version of this extension with ctypes, the patch is attached.

----------
effort: easy
files: scproxy-a1ba2d5db616.diff
messages: 2289
nosy: bob, pypy-issue
priority: bug
release: ???
status: unread
title: [PATCH} Fix urllib on Mac OS X with missing _scproxy module

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue669>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scproxy-a1ba2d5db616.diff
Type: application/octet-stream
Size: 5164 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110312/7c455501/attachment.obj>

From pypy-dev-issue at codespeak.net  Sun Mar 13 00:02:46 2011
From: pypy-dev-issue at codespeak.net (Bob Ippolito)
Date: Sat, 12 Mar 2011 23:02:46 +0000
Subject: [PyPy-issue] [issue669] [PATCH] Fix urllib on Mac OS X with missing
	_scproxy module
Message-ID: <1299970966.2.0.785997635709.issue669@>


Bob Ippolito <bob at redivi.com> added the comment:

In default now, https://bitbucket.org/pypy/pypy/changeset/20b985d28a76

----------
assignedto:  -> bob
status: unread -> in-progress

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


From pypy-dev-issue at codespeak.net  Sun Mar 13 20:54:19 2011
From: pypy-dev-issue at codespeak.net (Victor)
Date: Sun, 13 Mar 2011 19:54:19 +0000
Subject: [PyPy-issue] [issue668] Supplying custom path for installed native
	libraries
Message-ID: <1300046059.59.0.320721837833.issue668@>


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

tav has just answered this at http://stackoverflow.com/questions/5287050 , he's 
got the support code for setting custom paths checked in.

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

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 02:02:20 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 14 Mar 2011 01:02:20 +0000
Subject: [PyPy-issue] [issue670] on translate.py we get very long chains of
	PlainAttribute.index
Message-ID: <1300064540.94.0.762860077901.issue670@>


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

Identified on OS X, unsure about linux but seems very likely. Also they end up 
with stackcheck that somehow exits, but we seem to catch the error and go on.

----------
effort: ???
messages: 2292
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: on translate.py we get very long chains of PlainAttribute.index

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 14:12:55 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 13:12:55 +0000
Subject: [PyPy-issue] [issue671] Exception: wrong annotation while building
	pypy-c
Message-ID: <1300108375.76.0.356668547706.issue671@>


New submission from ys <ysbalt at live.com>:

In the mercurial changeset 42595:63e875c8adc8, I am trying to build pypy, using
a previously built pypy-c, so I do:

$ PYPY_LOCALBASE=/Users/#####/opt/local pypy-c translate.py -Ojit

It stalls with 
%%#%%%%
[rtyper:WARNING] Desc <FrozenDesc for <TypeDef name='Error'>> has no attribute
'$memofield__get_typedescr_1_1'
[rtyper:WARNING] Desc <FrozenDesc for <TypeDef name='Error'>> has no attribute
'$memofield_get_slot_tp_function_2883'
[rtyper:WARNING] Desc <FrozenDesc for <TypeDef name='RuntimeError'>> has no
attribute '$memofield_get_slot_tp_function_2883'
%%#%%%%#%%%%%%%%%
[rtyper] specializing: 145800 / 153391 blocks   (95%)
%%
[rtyper] specializing: 146700 / 153412 blocks   (95%)
%
[rtyper] -=- specialized 153422 blocks -=-
%%#%%%%#%%%%%%%%%****%%***********++++++++++++++++++++++#+++++++++++++++++++++++++++++++++++++++++++++*+++++++++%%%*%%+**%%%%%%%%%***+++................................
%%###%%%%%%%%%%*****#*%***********++++++++++++++++++++++++*++++++++++++++++++++++++++++++++++
[Timer] Timings:
[Timer] annotate                       --- 1281.9 s
[Timer] rtype_lltype                   ---  615.3 s
[Timer] ===========================================
[Timer] Total:                         --- 1897.3 s
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "translate.py", line 290, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/Users/#####/temp/pypy/pypy/translator/driver.py",
line 812, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:ERROR]    File
"/Users/#####/temp/pypy/pypy/translator/tool/taskengine.py", line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/Users/#####/temp/pypy/pypy/translator/driver.py",
line 288, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/Users/#####/temp/pypy/pypy/translator/driver.py",
line 373, in task_rtype_lltype
[translation:ERROR]     crash_on_first_typeerror=insist)
[translation:ERROR]    File "/Users/#####/temp/pypy/pypy/rpython/rtyper.py",
line 211, in specialize
[translation:ERROR]     self.specialize_more_blocks()
[translation:ERROR]    File "/Users/#####/temp/pypy/pypy/rpython/rtyper.py",
line 280, in specialize_more_blocks
[translation:ERROR]     annmixlevel.finish()
[translation:ERROR]    File
"/Users/#####/temp/pypy/pypy/rpython/annlowlevel.py", line 240, in finish
[translation:ERROR]     self.finish_annotate()
[translation:ERROR]    File
"/Users/#####/temp/pypy/pypy/rpython/annlowlevel.py", line 266, in finish_annotate
[translation:ERROR]     (graph, s_result, s_real_result))
[translation:ERROR]  Exception: wrong annotation for the result of
<FunctionGraph of (pypy.rpython.module.ll_os:832)os_read_llimpl at 0x1a2b23b0>:
[translation:ERROR] originally specified: SomeString(can_be_None=False)
[translation:ERROR]  found by annotating: SomeString(can_be_None=True)
[translation] start debugger...
> /Users/#####/temp/pypy/pypy/rpython/annlowlevel.py(266)finish_annotate()
-> (graph, s_result, s_real_result))
(Pdb+)


I print out the stack trace:
(Pdb+) where
  /Users/#####/temp/pypy/pypy/translator/goal/app_main.py(591)entry_point()
-> if not isinstance(importer, imp.NullImporter):
  /Users/#####/temp/pypy/pypy/translator/goal/app_main.py(539)run_command_line()
-> # executing the interactive prompt, if we're running a script we
  /Users/#####/temp/pypy/pypy/translator/goal/app_main.py(53)run_toplevel()
-> f(*fargs, **fkwds)
 
/Users/#####/opt/local/var/macports/build/_Users_#####_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_pypy/work/pypy-1.4.1-src/pypy/module/__builtin__/app_io.py(28)execfile()
  /Users/#####/temp/pypy/pypy/translator/goal/translate.py(304)<module>()
-> main()
  /Users/#####/temp/pypy/pypy/translator/goal/translate.py(296)main()
-> debug(True)
  /Users/#####/temp/pypy/pypy/translator/driver.py(812)proceed()
-> return self._execute(goals, task_skip = self._maybe_skip())
  /Users/#####/temp/pypy/pypy/translator/tool/taskengine.py(121)_execute()
-> raise
  /Users/#####/temp/pypy/pypy/translator/driver.py(303)_do()
-> pass
  /Users/#####/temp/pypy/pypy/translator/driver.py(373)task_rtype_lltype()
-> crash_on_first_typeerror=insist)
  /Users/#####/temp/pypy/pypy/rpython/rtyper.py(211)specialize()
-> self.specialize_more_blocks()
  /Users/#####/temp/pypy/pypy/rpython/rtyper.py(280)specialize_more_blocks()
-> annmixlevel.finish()
  /Users/#####/temp/pypy/pypy/rpython/annlowlevel.py(240)finish()
-> self.finish_annotate()
> /Users/#####/temp/pypy/pypy/rpython/annlowlevel.py(266)finish_annotate()
-> (graph, s_result, s_real_result))
(Pdb+)

----------
effort: ???
messages: 2293
nosy: baltcode, pypy-issue
priority: critical
release: ???
status: unread
title: Exception: wrong annotation while building pypy-c

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 18:17:04 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 17:17:04 +0000
Subject: [PyPy-issue] [issue671] Exception: wrong annotation while building
	pypy-c
Message-ID: <1300123024.83.0.624005527212.issue671@>


ys <ysbalt at live.com> added the comment:

This might have been fixed in the last few commits, but there seem to be other
errors. I am submitting another ticket.

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

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 18:18:41 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Mon, 14 Mar 2011 17:18:41 +0000
Subject: [PyPy-issue] [issue671] Exception: wrong annotation while building
	pypy-c
Message-ID: <1300123121.97.0.319142555173.issue671@>


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

Yup, this was fixed by fijal.  If tehre's a new issue please file a new ticket.

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

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 18:21:42 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 17:21:42 +0000
Subject: [PyPy-issue] [issue672] In gc/env.py: local variable 'cache'
	referenced before assignment
Message-ID: <1300123302.83.0.399527717165.issue672@>


New submission from ys <ysbalt at live.com>:

While building pypy-c on OSX, I get an error in gc/env.py. The stack trace is
copied below the error.

[rtyper] -=- specialized 4 more blocks -=-
[translation:info] inserted 855 stack checks.
[translation:info] Creating database for generating c source...
......++++++
[rtyper] -=- specialized 25 more blocks -=-
......++++++++++++++++++++++++++++++****************%%%%%%%%%%%%%%###################################%%%%%#%%#%%#%%%%%%%%%%%%%%%%%%%%%###%%%%%%%%%%%********************
...++++++++++++++++++++++++++++%+*#%**************%%
[Timer] Timings:
[Timer] annotate                       ---  966.8 s
[Timer] rtype_lltype                   ---  594.3 s
[Timer] pyjitpl_lltype                 ---  584.7 s
[Timer] backendopt_lltype              ---  235.2 s
[Timer] stackcheckinsertion_lltype     ---   39.4 s
[Timer] database_c                     ---   13.2 s
[Timer] ===========================================
[Timer] Total:                         --- 2433.5 s
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "translate.py", line 290, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/Users/######/temp/pypy/pypy/translator/driver.py",
line 812, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/translator/tool/taskengine.py", line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/Users/######/temp/pypy/pypy/translator/driver.py",
line 288, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/Users/######/temp/pypy/pypy/translator/driver.py",
line 508, in task_database_c
[translation:ERROR]     database = cbuilder.build_database()
[translation:ERROR]    File "/Users/######/temp/pypy/pypy/translator/c/genc.py",
line 157, in build_database
[translation:ERROR]     sandbox=self.config.translation.sandbox)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/translator/c/database.py", line 65, in __init__
[translation:ERROR]     self.gctransformer =
self.gcpolicy.transformerclass(translator)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/rpython/memory/gctransform/framework.py", line
494, in __init__
[translation:ERROR]     annhelper.finish()   # at this point, annotate all
mix-level helpers
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/rpython/annlowlevel.py", line 240, in finish
[translation:ERROR]     self.finish_annotate()
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/rpython/annlowlevel.py", line 259, in finish_annotate
[translation:ERROR]     ann.complete_helpers(self.policy)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/annrpython.py", line 176, in
complete_helpers
[translation:ERROR]     self.complete()
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/annrpython.py", line 250, in complete
[translation:ERROR]     self.processblock(graph, block)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/annrpython.py", line 448, in processblock
[translation:ERROR]     self.flowin(graph, block)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/annrpython.py", line 508, in flowin
[translation:ERROR]     self.consider_op(block.operations[i])
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/annrpython.py", line 710, in consider_op
[translation:ERROR]     raise_nicer_exception(op, str(graph))
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/annrpython.py", line 707, in consider_op
[translation:ERROR]     resultcell = consider_meth(*argcells)
[translation:ERROR]    File "<4585-codegen
/Users/######/temp/pypy/pypy/annotation/annrpython.py:745>", line 3, in
consider_op_simple_call
[translation:ERROR]     return arg.simple_call(*args)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/unaryop.py", line 175, in simple_call
[translation:ERROR]     return
obj.call(getbookkeeper().build_args("simple_call", args_s))
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/unaryop.py", line 691, in call
[translation:ERROR]     return bookkeeper.pbc_call(pbc, args)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/bookkeeper.py", line 662, in pbc_call
[translation:ERROR]     results.append(desc.pycall(schedule, args,
s_previous_result))
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/description.py", line 276, in pycall
[translation:ERROR]     result = self.specialize(inputcells)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/description.py", line 272, in specialize
[translation:ERROR]     return self.specializer(self, inputcells)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/rpython/annlowlevel.py", line 124, in
default_specialize
[translation:ERROR]     return AnnotatorPolicy.default_specialize(funcdesc, args_s)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/specialize.py", line 80, in
default_specialize
[translation:ERROR]     graph = funcdesc.cachedgraph(key, builder=builder)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/description.py", line 237, in cachedgraph
[translation:ERROR]     graph = self.buildgraph(alt_name, builder)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/annotation/description.py", line 200, in buildgraph
[translation:ERROR]     graph = translator.buildflowgraph(self.pyobj)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/translator/translator.py", line 77, in buildflowgraph
[translation:ERROR]     graph = space.build_flow(func)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/objspace/flow/objspace.py", line 277, in build_flow
[translation:ERROR]     ec.build_flow()
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/objspace/flow/flowcontext.py", line 264, in build_flow
[translation:ERROR]     self)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/module/pypyjit/interp_jit.py", line 77, in dispatch
[translation:ERROR]     next_instr = self.handle_bytecode(co_code, next_instr, ec)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/interpreter/pyopcode.py", line 93, in handle_bytecode
[translation:ERROR]     next_instr = self.dispatch_bytecode(co_code, next_instr, ec)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/interpreter/pyopcode.py", line 271, in
dispatch_bytecode
[translation:ERROR]     res = meth(oparg, next_instr)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/interpreter/pyopcode.py", line 334, in LOAD_FAST
[translation:ERROR]     self._load_fast_failed(varindex)
[translation:ERROR]    File
"/Users/######/temp/pypy/pypy/interpreter/pyopcode.py", line 341, in
_load_fast_failed
[translation:ERROR]     raise operationerrfmt(self.space.w_UnboundLocalError,
message, varname)
[translation:ERROR]    File "/Users/######/temp/pypy/pypy/interpreter/error.py",
line 327, in operationerrfmt
[translation:ERROR]     return OpErrFmt(w_type, strings, *args)
[translation:ERROR]    File "/Users/######/temp/pypy/pypy/interpreter/error.py",
line 300, in __init__
[translation:ERROR]     raise FlowingError(self._compute_value())
[translation:ERROR]  FlowingError':
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[translation:ERROR] local variable 'cache' referenced before assignment
[translation:ERROR] Happened at file
/Users/######/temp/pypy/pypy/rpython/memory/gc/env.py line 213
[translation:ERROR]
[translation:ERROR]                 return cache
[translation:ERROR]
[translation:ERROR]     .. v134 = simple_call((function get_darwin_cache_size),
('hw.l2cachesize'))
[translation:ERROR]     .. '(pypy.rpython.memory.gc.env:220)get_L2cache_darwin'
[translation:ERROR] Processing block:
[translation:ERROR]  block at 6 is a <class 'pypy.objspace.flow.flowcontext.SpamBlock'>
[translation:ERROR]  in (pypy.rpython.memory.gc.env:220)get_L2cache_darwin
[translation:ERROR]  containing the following operations:
[translation:ERROR]        v135 = simple_call((function debug_start),
('gc-hardware'))
[translation:ERROR]        v134 = simple_call((function get_darwin_cache_size),
('hw.l2cachesize'))
[translation:ERROR]        v136 = simple_call((function get_darwin_cache_size),
('hw.l3cachesize'))
[translation:ERROR]        v137 = simple_call((function debug_print), ('L2cache
='), v134)
[translation:ERROR]        v138 = simple_call((function debug_print), ('L3cache
='), v136)
[translation:ERROR]        v139 = simple_call((function debug_stop),
('gc-hardware'))
[translation:ERROR]        v140 = add(v134, v136)
[translation:ERROR]        v141 = gt(v140, (0))
[translation:ERROR]        v142 = is_true(v141)
[translation:ERROR]  --end--
[translation] start debugger...
> /Users/######/temp/pypy/pypy/interpreter/error.py(300)__init__()
-> raise FlowingError(self._compute_value())
(Pdb+)

Stack Trace:

(Pdb+) where
  /Users/######/temp/pypy/pypy/translator/goal/app_main.py(591)entry_point()
-> if not isinstance(importer, imp.NullImporter):
  /Users/######/temp/pypy/pypy/translator/goal/app_main.py(539)run_command_line()
-> # executing the interactive prompt, if we're running a script we
  /Users/######/temp/pypy/pypy/translator/goal/app_main.py(53)run_toplevel()
-> f(*fargs, **fkwds)
 
/Users/######/opt/local/var/macports/build/_Users_######_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_pypy/work/pypy-1.4.1-src/pypy/module/__builtin__/app_io.py(28)execfile()
  /Users/######/temp/pypy/pypy/translator/goal/translate.py(304)<module>()
-> main()
  /Users/######/temp/pypy/pypy/translator/goal/translate.py(296)main()
-> debug(True)
  /Users/######/temp/pypy/pypy/translator/driver.py(812)proceed()
-> return self._execute(goals, task_skip = self._maybe_skip())
  /Users/######/temp/pypy/pypy/translator/tool/taskengine.py(121)_execute()
-> raise
  /Users/######/temp/pypy/pypy/translator/driver.py(303)_do()
-> pass
  /Users/######/temp/pypy/pypy/translator/driver.py(508)task_database_c()
-> database = cbuilder.build_database()
  /Users/######/temp/pypy/pypy/translator/c/genc.py(157)build_database()
-> sandbox=self.config.translation.sandbox)
  /Users/######/temp/pypy/pypy/translator/c/database.py(65)__init__()
-> self.gctransformer = self.gcpolicy.transformerclass(translator)
 
/Users/######/temp/pypy/pypy/rpython/memory/gctransform/framework.py(494)__init__()
-> annhelper.finish()   # at this point, annotate all mix-level helpers
  /Users/######/temp/pypy/pypy/rpython/annlowlevel.py(240)finish()
-> self.finish_annotate()
  /Users/######/temp/pypy/pypy/rpython/annlowlevel.py(259)finish_annotate()
-> ann.complete_helpers(self.policy)
  /Users/######/temp/pypy/pypy/annotation/annrpython.py(180)complete_helpers()
-> self.policy, self.added_blocks = saved
  /Users/######/temp/pypy/pypy/annotation/annrpython.py(250)complete()
-> self.processblock(graph, block)
  /Users/######/temp/pypy/pypy/annotation/annrpython.py(456)processblock()
-> raise
  /Users/######/temp/pypy/pypy/annotation/annrpython.py(540)flowin()
-> return
  /Users/######/temp/pypy/pypy/annotation/annrpython.py(710)consider_op()
-> raise_nicer_exception(op, str(graph))
  <4585-codegen
/Users/######/temp/pypy/pypy/annotation/annrpython.py:745>(3)consider_op_simple_call()
-> return arg.simple_call(*args)
  /Users/######/temp/pypy/pypy/annotation/unaryop.py(175)simple_call()
-> return obj.call(getbookkeeper().build_args("simple_call", args_s))
  /Users/######/temp/pypy/pypy/annotation/unaryop.py(691)call()
-> return bookkeeper.pbc_call(pbc, args)
  /Users/######/temp/pypy/pypy/annotation/bookkeeper.py(662)pbc_call()
-> results.append(desc.pycall(schedule, args, s_previous_result))
  /Users/######/temp/pypy/pypy/annotation/description.py(276)pycall()
-> result = self.specialize(inputcells)
  /Users/######/temp/pypy/pypy/annotation/description.py(272)specialize()
-> return self.specializer(self, inputcells)
  /Users/######/temp/pypy/pypy/rpython/annlowlevel.py(124)default_specialize()
-> return AnnotatorPolicy.default_specialize(funcdesc, args_s)
  /Users/######/temp/pypy/pypy/annotation/specialize.py(80)default_specialize()
-> graph = funcdesc.cachedgraph(key, builder=builder)
  /Users/######/temp/pypy/pypy/annotation/description.py(237)cachedgraph()
-> graph = self.buildgraph(alt_name, builder)
  /Users/######/temp/pypy/pypy/annotation/description.py(200)buildgraph()
-> graph = translator.buildflowgraph(self.pyobj)
  /Users/######/temp/pypy/pypy/translator/translator.py(77)buildflowgraph()
-> graph = space.build_flow(func)
  /Users/######/temp/pypy/pypy/objspace/flow/objspace.py(284)build_flow()
-> raise error.FlowingError, e, tb
  /Users/######/temp/pypy/pypy/objspace/flow/flowcontext.py(300)build_flow()
-> self.mergeblock(e.block, e.currentstate)
  /Users/######/temp/pypy/pypy/module/pypyjit/interp_jit.py(79)dispatch()
-> return self.popvalue()
  /Users/######/temp/pypy/pypy/interpreter/pyopcode.py(114)handle_bytecode()
-> next_instr = self.handle_operation_error(ec, w_err)
  /Users/######/temp/pypy/pypy/interpreter/pyopcode.py(282)dispatch_bytecode()
-> raise
  /Users/######/temp/pypy/pypy/interpreter/pyopcode.py(334)LOAD_FAST()
-> self._load_fast_failed(varindex)
  /Users/######/temp/pypy/pypy/interpreter/pyopcode.py(341)_load_fast_failed()
-> raise operationerrfmt(self.space.w_UnboundLocalError, message, varname)
  /Users/######/temp/pypy/pypy/interpreter/error.py(327)operationerrfmt()
-> return OpErrFmt(w_type, strings, *args)
> /Users/######/temp/pypy/pypy/interpreter/error.py(300)__init__()
-> raise FlowingError(self._compute_value())
(Pdb+)

----------
effort: ???
messages: 2296
nosy: baltcode, pypy-issue
priority: critical
release: ???
status: unread
title: In gc/env.py:  local variable 'cache' referenced before assignment

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 18:30:55 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Mon, 14 Mar 2011 17:30:55 +0000
Subject: [PyPy-issue] [issue672] In gc/env.py: local variable 'cache'
	referenced before assignment
Message-ID: <1300123855.69.0.857018616116.issue672@>


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

Should be fixed now, I don't have OS X to actually test though.

----------
status: unread -> testing

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 19:33:34 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Mon, 14 Mar 2011 18:33:34 +0000
Subject: [PyPy-issue] [issue672] In gc/env.py: local variable 'cache'
	referenced before assignment
Message-ID: <1300127614.91.0.154409635595.issue672@>


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

fixed

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

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 19:45:49 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 18:45:49 +0000
Subject: [PyPy-issue] [issue672] In gc/env.py: local variable 'cache'
	referenced before assignment
Message-ID: <1300128349.39.0.220170544968.issue672@>


ys <ysbalt at live.com> added the comment:

gc/env.py gives another error now:

(Pdb+) where
  /Users/#####/temp/pypy/pypy/translator/goal/app_main.py(591)entry_point()
-> if not isinstance(importer, imp.NullImporter):
  /Users/#####/temp/pypy/pypy/translator/goal/app_main.py(539)run_command_line()
-> # executing the interactive prompt, if we're running a script we
  /Users/#####/temp/pypy/pypy/translator/goal/app_main.py(53)run_toplevel()
-> f(*fargs, **fkwds)
 
/Users/#####/opt/local/var/macports/build/_Users_#####_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_pypy/work/pypy-1.4.1-src/pypy/module/__builtin__/app_io.py(28)execfile()
  /Users/#####/temp/pypy/pypy/translator/goal/translate.py(304)<module>()
-> main()
  /Users/#####/temp/pypy/pypy/translator/goal/translate.py(296)main()
-> debug(True)
  /Users/#####/temp/pypy/pypy/translator/driver.py(812)proceed()
-> return self._execute(goals, task_skip = self._maybe_skip())
  /Users/#####/temp/pypy/pypy/translator/tool/taskengine.py(121)_execute()
-> raise
  /Users/#####/temp/pypy/pypy/translator/driver.py(303)_do()
-> pass
  /Users/#####/temp/pypy/pypy/translator/driver.py(399)task_pyjitpl_lltype()
-> backend_name=self.config.translation.jit_backend, inline=True)
  /Users/#####/temp/pypy/pypy/jit/metainterp/warmspot.py(46)apply_jit()
-> **kwds)
  /Users/#####/temp/pypy/pypy/jit/metainterp/warmspot.py(157)__init__()
-> self.build_cpu(CPUClass, **kwds)
  /Users/#####/temp/pypy/pypy/jit/metainterp/warmspot.py(287)build_cpu()
-> translate_support_code, gcdescr=self.gcdescr)
  /Users/#####/temp/pypy/pypy/jit/backend/x86/runner.py(156)__init__()
-> super(CPU386, self).__init__(*args, **kwargs)
  /Users/#####/temp/pypy/pypy/jit/backend/x86/runner.py(23)__init__()
-> translate_support_code, gcdescr)
  /Users/#####/temp/pypy/pypy/jit/backend/llsupport/llmodel.py(41)__init__()
-> self.gc_ll_descr = get_ll_description(gcdescr, translator, rtyper)
  /Users/#####/temp/pypy/pypy/jit/backend/llsupport/gc.py(732)get_ll_description()
-> return cls(gcdescr, translator, rtyper)
  /Users/#####/temp/pypy/pypy/jit/backend/llsupport/gc.py(447)__init__()
-> self.layoutbuilder = framework.TransformerLayoutBuilder(translator)
 
/Users/#####/temp/pypy/pypy/rpython/memory/gctransform/framework.py(1207)__init__()
-> GCClass, _ = choose_gc_from_config(translator.config)
  /Users/#####/temp/pypy/pypy/rpython/memory/gc/base.py(417)choose_gc_from_config()
-> globals(), locals(), [classname])
> /Users/#####/temp/pypy/pypy/rpython/memory/gc/minimark.py(51)<module>()
-> from pypy.rpython.memory.gc import minimarkpage, env
(Pdb+) 

Stack trace:
(Pdb+) where
  /Users/#####.g/temp/pypy/pypy/translator/goal/app_main.py(591)entry_point()
-> if not isinstance(importer, imp.NullImporter):
  /Users/#####.g/temp/pypy/pypy/translator/goal/app_main.py(539)run_command_line()
-> # executing the interactive prompt, if we're running a script we
  /Users/#####.g/temp/pypy/pypy/translator/goal/app_main.py(53)run_toplevel()
-> f(*fargs, **fkwds)
 
/Users/#####.g/opt/local/var/macports/build/_Users_yasir_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_pypy/work/pypy-1.4.1-src/pypy/module/__builtin__/app_io.py(28)execfile()
  /Users/#####.g/temp/pypy/pypy/translator/goal/translate.py(304)<module>()
-> main()
  /Users/#####.g/temp/pypy/pypy/translator/goal/translate.py(296)main()
-> debug(True)
  /Users/#####.g/temp/pypy/pypy/translator/driver.py(812)proceed()
-> return self._execute(goals, task_skip = self._maybe_skip())
  /Users/#####.g/temp/pypy/pypy/translator/tool/taskengine.py(121)_execute()
-> raise
  /Users/#####.g/temp/pypy/pypy/translator/driver.py(303)_do()
-> pass
  /Users/#####.g/temp/pypy/pypy/translator/driver.py(399)task_pyjitpl_lltype()
-> backend_name=self.config.translation.jit_backend, inline=True)
  /Users/#####.g/temp/pypy/pypy/jit/metainterp/warmspot.py(46)apply_jit()
-> **kwds)
  /Users/#####.g/temp/pypy/pypy/jit/metainterp/warmspot.py(157)__init__()
-> self.build_cpu(CPUClass, **kwds)
  /Users/#####.g/temp/pypy/pypy/jit/metainterp/warmspot.py(287)build_cpu()
-> translate_support_code, gcdescr=self.gcdescr)
  /Users/#####.g/temp/pypy/pypy/jit/backend/x86/runner.py(156)__init__()
-> super(CPU386, self).__init__(*args, **kwargs)
  /Users/#####.g/temp/pypy/pypy/jit/backend/x86/runner.py(23)__init__()
-> translate_support_code, gcdescr)
  /Users/#####.g/temp/pypy/pypy/jit/backend/llsupport/llmodel.py(41)__init__()
-> self.gc_ll_descr = get_ll_description(gcdescr, translator, rtyper)
  /Users/#####.g/temp/pypy/pypy/jit/backend/llsupport/gc.py(732)get_ll_description()
-> return cls(gcdescr, translator, rtyper)
  /Users/#####.g/temp/pypy/pypy/jit/backend/llsupport/gc.py(447)__init__()
-> self.layoutbuilder = framework.TransformerLayoutBuilder(translator)
 
/Users/#####.g/temp/pypy/pypy/rpython/memory/gctransform/framework.py(1207)__init__()
-> GCClass, _ = choose_gc_from_config(translator.config)
 
/Users/#####.g/temp/pypy/pypy/rpython/memory/gc/base.py(417)choose_gc_from_config()
-> globals(), locals(), [classname])
> /Users/#####.g/temp/pypy/pypy/rpython/memory/gc/minimark.py(51)<module>()
-> from pypy.rpython.memory.gc import minimarkpage, env
(Pdb+)

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

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 19:47:57 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Mon, 14 Mar 2011 18:47:57 +0000
Subject: [PyPy-issue] [issue672] In gc/env.py: local variable 'cache'
	referenced before assignment
Message-ID: <1300128477.92.0.561266955953.issue672@>


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

I don't actually see an error in what you pasted.

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 19:59:50 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 18:59:50 +0000
Subject: [PyPy-issue] [issue672] In gc/env.py: local variable 'cache'
	referenced before assignment
Message-ID: <1300129190.57.0.153075221746.issue672@>


ys <ysbalt at live.com> added the comment:

My mistake, the error was occurring on the with statement in gc/env.py.
migueldvb's latest commit might have fixed that. I am attempting the build right
now.

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 20:20:07 2011
From: pypy-dev-issue at codespeak.net (David Edelsohn)
Date: Mon, 14 Mar 2011 19:20:07 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300130407.54.0.711591322006.issue673@>


New submission from David Edelsohn <dje.gcc at gmail.com>:

The information returned by /proc/cpuinfo is processor-dependent.  Not all Linux
architectures return cache size in that structure.

/sys/devices/system/cpu/cpuN/cache/indexN/size

is more portable.  Although it requires a little more groveling to find a valid
cpu and the outermost index.

----------
effort: ???
messages: 2302
nosy: edelsohn, pypy-issue
priority: feature
release: ???
status: unread
title: Linux L2 cache size

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 20:59:00 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 14 Mar 2011 19:59:00 +0000
Subject: [PyPy-issue] [issue636] 64bit JIT Failure on trunk
Message-ID: <1300132740.08.0.476165095471.issue636@>


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

Fixed in cc834a32740a

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 21:13:27 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 14 Mar 2011 20:13:27 +0000
Subject: [PyPy-issue] [issue655] Fix get/setpgrp() platcheck platform errors
Message-ID: <1300133606.39.0.168331146671.issue655@>


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

Closing this issue. We can probably not display red, but that's for another 
issue.

----------
status: testing -> wontfix

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 21:23:43 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Mon, 14 Mar 2011 20:23:43 +0000
Subject: [PyPy-issue] [issue637]
	twisted.conch.test.test_recvline.RecvlineLoopbackTelnet.testLeftArrow
	fails after 29 iterations
Message-ID: <1300134223.04.0.691920461402.issue637@>


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

This one is clearly a bug in jit unrolling. If you disable loop unrolling it 
works.

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 23:26:02 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 22:26:02 +0000
Subject: [PyPy-issue] [issue672] In gc/env.py: local variable 'cache'
	referenced before assignment
Message-ID: <1300141562.9.0.523428117878.issue672@>


ys <ysbalt at live.com> added the comment:

Fixed!

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

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 23:26:41 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 22:26:41 +0000
Subject: [PyPy-issue] [issue668] Supplying custom path for installed native
	libraries
Message-ID: <1300141601.97.0.82311329044.issue668@>


ys <ysbalt at live.com> added the comment:

I confirm, fixed with PYPY_LOCALBASE.

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

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


From pypy-dev-issue at codespeak.net  Mon Mar 14 23:38:31 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Mon, 14 Mar 2011 22:38:31 +0000
Subject: [PyPy-issue] [issue674] sysconfig.get_config_var("CC")
Message-ID: <1300142311.94.0.420488012853.issue674@>


New submission from ys <ysbalt at live.com>:

I am using the near-tip version of pypy on OSX. I am trying to install other
modules in pypy. The setup file relies on
distutils.sysconfig.get_config_var("CC"), which returns None. How can this be
added to pypy. To reproduce, in pypy-c:
$ pypy-c
>>>> import distutils.sysconfig
>>>> distutils.sysconfig.get_config_var("CC")
>>>> distutils.sysconfig.get_config_var("CC") == None
True
>>>> distutils.sysconfig.get_config_vars()
{'EXE': '', 'SO': '.pypy-14.so', 'SOABI': ''}

----------
effort: ???
messages: 2308
nosy: baltcode, pypy-issue
priority: bug
release: ???
status: unread
title: sysconfig.get_config_var("CC")

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


From pypy-dev-issue at codespeak.net  Tue Mar 15 19:09:04 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Tue, 15 Mar 2011 18:09:04 +0000
Subject: [PyPy-issue] [issue674] sysconfig.get_config_var("CC")
Message-ID: <1300212544.2.0.300623121241.issue674@>


ys <ysbalt at live.com> added the comment:

This will be easier to do if, during the build, a Makefile and pyconfig.h are
written with the parameters used during the build process. These files are then
parsed by sysconfig to give these variables. People familiar with the build
process might take a crack at this. Or is there a reason why this does not happen?

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

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


From pypy-dev-issue at codespeak.net  Tue Mar 15 19:28:47 2011
From: pypy-dev-issue at codespeak.net (ys)
Date: Tue, 15 Mar 2011 18:28:47 +0000
Subject: [PyPy-issue] [issue674] sysconfig.get_config_var("CC")
Message-ID: <1300213727.93.0.151237461241.issue674@>


ys <ysbalt at live.com> added the comment:

Similar issue in issue 535. This will have to be resolved before more packages
can be used with pypy. Doing so will accelerate development and testing as users
start experimenting with other features used in different packages.

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

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


From pypy-dev-issue at codespeak.net  Wed Mar 16 21:06:12 2011
From: pypy-dev-issue at codespeak.net (Alex Gaynor)
Date: Wed, 16 Mar 2011 20:06:12 +0000
Subject: [PyPy-issue] [issue675] Running without --enable_opts rewrite leads
	to errors from the JIT backend
Message-ID: <1300305972.46.0.991364849746.issue675@>


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

Because the backend doesn't support emitting some operations with immediates, it
errors out since rewrite is responsible for constant folding them.

----------
effort: medium
messages: 2311
nosy: agaynor, pypy-issue
priority: bug
release: ???
status: unread
title: Running without --enable_opts rewrite leads to errors from the JIT backend

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


From pypy-dev-issue at codespeak.net  Fri Mar 18 02:33:27 2011
From: pypy-dev-issue at codespeak.net (Alfredo Deza)
Date: Fri, 18 Mar 2011 01:33:27 +0000
Subject: [PyPy-issue] [issue402] codecs are broken in pypy-c
Message-ID: <1300412007.58.0.828774572867.issue402@>


Alfredo Deza <alfredodeza at gmail.com> added the comment:

The ``codecs`` module in pypy is behaving differently than CPython 2.5 and 2.6. The issue comes 
when you want to register a custom encoding. PyPy raises a syntax error because it was unable to 
"translate" via the registered codec.

If it gets executed with Python, no exception is raised because the registered encoding with the search 
function is actually translating correctly.

To replicate I have uploaded a tar.gz with 2 files. One file with a custom "foobar" encoding called 
custom_encoding.py. The other file is called foobar.py and this is the file in charge of doing exec on 
custom_encoding.py

To replicate the issue:

# this doesn't raise an exception
python foobar.py

# this raises a syntax error
pypy foobar.py

I'm using pypy v 1.4.1

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

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

From pypy-dev-issue at codespeak.net  Fri Mar 18 11:04:27 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Fri, 18 Mar 2011 10:04:27 +0000
Subject: [PyPy-issue] [issue402] codecs are broken in pypy-c
Message-ID: <1300442667.76.0.109719497242.issue402@>


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

To decode a source file, pypy calls:
   unicode(text, encoding)
When CPython uses the equivalent of:
   codecs.getreader(encoding)(input_stream).readline

Note that even with CPython, your encoding is incorrect:
   compile(open(filename).read(), 'file', 'exec')
fails with a SyntaxError, because the input is now a string (instead of a file) and 
text.decode(encoding) is called on the whole content.

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


From pypy-dev-issue at codespeak.net  Fri Mar 18 14:44:22 2011
From: pypy-dev-issue at codespeak.net (Alfredo Deza)
Date: Fri, 18 Mar 2011 13:44:22 +0000
Subject: [PyPy-issue] [issue402] codecs are broken in pypy-c
Message-ID: <1300455862.48.0.53956474725.issue402@>


Alfredo Deza <alfredodeza at gmail.com> added the comment:

I want to avoid a discussion about encoding correctness as it works for the intended purpose in 
CPython (e.g. is *not* calling compile at any time).

Going back to the reported issue, this would mean that the implementation needs to change because 
PyPy does not use codecs.getreader but rather unicode(text, encoding) ? 

Is there *any* equivalent in PyPy to do the same thing I am doing in CPython?

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


From pypy-dev-issue at codespeak.net  Fri Mar 18 15:08:14 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Fri, 18 Mar 2011 14:08:14 +0000
Subject: [PyPy-issue] [issue402] codecs are broken in pypy-c
Message-ID: <1300457294.73.0.134526599872.issue402@>


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

Since PyPy does not use the streamreader to decode source files, yes, your codec should be changed and implement 
its hacks in the "decode" method, which could look like:

def decode(text, *args):
    utf8=encodings.search_function('utf8')
    decoded, consumed = utf8.decode(text, *args)
    decoded = decoded.replace('myprint ', 'print ')
    return decoded, consumed

The alternative is to fix PyPy of course.

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


From pypy-dev-issue at codespeak.net  Fri Mar 18 15:13:33 2011
From: pypy-dev-issue at codespeak.net (Alfredo Deza)
Date: Fri, 18 Mar 2011 14:13:33 +0000
Subject: [PyPy-issue] [issue402] codecs are broken in pypy-c
Message-ID: <1300457613.18.0.325726421123.issue402@>


Alfredo Deza <alfredodeza at gmail.com> added the comment:

Fair enough. I am not sure if you want to close this issue since PyPy is not "wrong" but just doing things
a bit different.

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


From pypy-dev-issue at codespeak.net  Mon Mar 21 05:30:28 2011
From: pypy-dev-issue at codespeak.net (Mitchell)
Date: Mon, 21 Mar 2011 04:30:28 +0000
Subject: [PyPy-issue] [issue676] [PATCH] Implementing PyRun_SimpleString
Message-ID: <1300681828.58.0.153922501175.issue676@>


New submission from Mitchell <mogurijin at gmail.com>:

This patch implements PyRun_SimpleString. I'm not sure if there is a better way to 
handle possible errors. I'm also not sure what "priority" I should use for 
patches, so I listed it under "feature".

----------
effort: ???
messages: 2317
nosy: Moguri, pypy-issue
priority: feature
release: ???
status: unread
title: [PATCH] Implementing PyRun_SimpleString

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


From pypy-dev-issue at codespeak.net  Mon Mar 21 08:15:53 2011
From: pypy-dev-issue at codespeak.net (Mitchell)
Date: Mon, 21 Mar 2011 07:15:53 +0000
Subject: [PyPy-issue] [issue676] [PATCH] Implementing PyRun_SimpleString
Message-ID: <1300691753.71.0.912715295833.issue676@>


Mitchell <mogurijin at gmail.com> added the comment:

Trying again to upload the patch.

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

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue676>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyrun_simplestring.patch
Type: application/octet-stream
Size: 3032 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110321/d85fb80c/attachment.obj>

From pypy-dev-issue at codespeak.net  Mon Mar 21 08:27:22 2011
From: pypy-dev-issue at codespeak.net (Mitchell)
Date: Mon, 21 Mar 2011 07:27:22 +0000
Subject: [PyPy-issue] [issue676] [PATCH] Implementing PyRun_SimpleString
Message-ID: <1300692442.21.0.124364780236.issue676@>


Mitchell <mogurijin at gmail.com> added the comment:

Uploading pyrun_simplestring2.patch, which cleans up the except and lets the 
error=-1 do it's job.

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue676>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyrun_simplestring2.patch
Type: application/octet-stream
Size: 2907 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110321/d83b6d44/attachment.obj>

From pypy-dev-issue at codespeak.net  Mon Mar 21 08:41:38 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Mon, 21 Mar 2011 07:41:38 +0000
Subject: [PyPy-issue] [issue676] [PATCH] Implementing PyRun_SimpleString
Message-ID: <1300693298.88.0.309507163622.issue676@>


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

Applied in b418623246c9. Thanks for the patch!

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


From pypy-dev-issue at codespeak.net  Tue Mar 22 13:27:41 2011
From: pypy-dev-issue at codespeak.net (Vincent Legoll)
Date: Tue, 22 Mar 2011 12:27:41 +0000
Subject: [PyPy-issue] [issue654] Fix for test_incorrect_code_name
Message-ID: <1300796861.66.0.474852042842.issue654@>


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

ping

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


From pypy-dev-issue at codespeak.net  Tue Mar 22 19:02:06 2011
From: pypy-dev-issue at codespeak.net (Vetoshkin Nikita)
Date: Tue, 22 Mar 2011 18:02:06 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300816926.33.0.45747927342.issue673@>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

import os

LEVEL2_CACHE_SIZE = 191
os.sysconf(LEVEL2_CACHE_SIZE)

maybe that would be even easier, but I'm not shure when it was defined.

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

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


From pypy-dev-issue at codespeak.net  Tue Mar 22 19:04:04 2011
From: pypy-dev-issue at codespeak.net (Fijal)
Date: Tue, 22 Mar 2011 18:04:04 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300817044.53.0.74628709625.issue673@>


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

For one constant 191 is not really that platform-independent (I would expect it 
to vary and be defined somewhere in .h file). Is this somehow exposed by Python?

Another issue is that it's undocumented. man sysconf does not reveal you actually 
can ask for the cache size.

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


From pypy-dev-issue at codespeak.net  Tue Mar 22 19:06:53 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 22 Mar 2011 18:06:53 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300817213.17.0.922380671139.issue673@>


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

and we need to find a method for the poor souls that run pypy on Windows...

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


From pypy-dev-issue at codespeak.net  Tue Mar 22 19:22:48 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 22 Mar 2011 18:22:48 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300818168.23.0.707684463382.issue673@>


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

fijal kindly pointed me to the GetLogicalProcessorInformation function of the 
win32 API:
http://msdn.microsoft.com/en-us/library/ms683194(v=vs.85).aspx

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


From pypy-dev-issue at codespeak.net  Tue Mar 22 19:38:05 2011
From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc)
Date: Tue, 22 Mar 2011 18:38:05 +0000
Subject: [PyPy-issue] [issue654] Fix for test_incorrect_code_name
Message-ID: <1300819085.85.0.0814664027996.issue654@>


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

Applied in f0ac0762752d, thanks for the patch!
only one failure left in test_import...

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

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


From pypy-dev-issue at codespeak.net  Tue Mar 22 19:40:26 2011
From: pypy-dev-issue at codespeak.net (Vetoshkin Nikita)
Date: Tue, 22 Mar 2011 18:40:26 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300819226.06.0.879627275492.issue673@>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

>I would expect it to vary and be defined somewhere in .h file
in /usr/include/bits/confname.h accessed via <unistd.h>
>Is this somehow exposed by Python?
No, os.sysconf_names doesn't have this constant. posixmodule.c doesn't even have 
an #ifdef for that value - I think it's abandoned.

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


From pypy-dev-issue at codespeak.net  Wed Mar 23 11:23:00 2011
From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz)
Date: Wed, 23 Mar 2011 10:23:00 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300875780.03.0.733116152836.issue673@>


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

FWIW, this is the /proc/cpuinfo on David's beagleboard running Ubuntu. It has no
cache info at all. It also doesn't have cache info /sys/devices/... either.
os.sysconf(191) returns 0. So we have a bit no clue. 

Processor	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 514.67
Features	: swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc08
CPU revision	: 2

Hardware	: OMAP3 Beagle Board
Revision	: 0020
Serial		: 0000000000000000

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


From pypy-dev-issue at codespeak.net  Wed Mar 23 11:58:09 2011
From: pypy-dev-issue at codespeak.net (Vetoshkin Nikita)
Date: Wed, 23 Mar 2011 10:58:09 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300877889.26.0.300885329335.issue673@>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

can he grep /boot/config-<whatever his kernel image named> for 
CONFIG_CPU_L2CACHE_DISABLE?

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


From pypy-dev-issue at codespeak.net  Wed Mar 23 12:05:49 2011
From: pypy-dev-issue at codespeak.net (Laura Creighton)
Date: Wed, 23 Mar 2011 11:05:49 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300878349.72.0.966098602103.issue673@>


Laura Creighton <lac at openend.se> added the comment:

Whenever I want to find out stuff like this on a linux system I just type
(as root) dmidecode .  I think this is avaialble on all linuxes, does anybody
know for sure?

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


From pypy-dev-issue at codespeak.net  Wed Mar 23 13:45:40 2011
From: pypy-dev-issue at codespeak.net (David)
Date: Wed, 23 Mar 2011 12:45:40 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300884340.03.0.056428343426.issue673@>


David <david.schneider at uni-duesseldorf.de> added the comment:

dmidecode seems not to be available in the default repositories fur Ubuntu 10.10 on ARM.

CONFIG_CPU_L2CACHE_DISABLE is not defined in the file, which currently is /boot/config-2.6.35-24-omap

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


From pypy-dev-issue at codespeak.net  Wed Mar 23 14:14:33 2011
From: pypy-dev-issue at codespeak.net (Vetoshkin Nikita)
Date: Wed, 23 Mar 2011 13:14:33 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300886073.83.0.95785566011.issue673@>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

bootloader u-boot has these lines:
#ifndef CONFIG_L2_OFF
		/* turn off L2 cache */
		l2cache_disable();
		/* invalidate L2 cache also */
		v7_flush_dcache_all(get_device_type());
#endif

I think we should ask someone (or google) how can we check whether L2 cache is disabled at all. I bet it 
isn't :)

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


From pypy-dev-issue at codespeak.net  Wed Mar 23 20:52:56 2011
From: pypy-dev-issue at codespeak.net (Michael Hudson)
Date: Wed, 23 Mar 2011 19:52:56 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1300909976.24.0.17286267888.issue673@>


Michael Hudson <micahel at gmail.com> added the comment:

Life is difficult on ARM:
http://www.mail-archive.com/linaro-dev at lists.linaro.org/msg01023.html

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


From pypy-dev-issue at codespeak.net  Thu Mar 24 16:12:10 2011
From: pypy-dev-issue at codespeak.net (Sven Hager)
Date: Thu, 24 Mar 2011 15:12:10 +0000
Subject: [PyPy-issue] [issue677] dtoa conversion fails on powerpc, 64 bit
Message-ID: <1300979530.2.0.741109769628.issue677@>


New submission from Sven Hager <sven.hager at uni-duesseldorf.de>:

There is a bug at converting floats to strings on a PPC machine, 64 bit, which
is due to some endianess flaw in dtoa.c.

E. g. if one tries to execute

>>>> print 3.14

the output is 4.27698109031e+86.
The problem can be solved if one substitutes the line
 
119: #define DOUBLE_IS_LITTLE_ENDIAN_IEEE754

in dtoa.c by 

#define DOUBLE_IS_BIG_ENDIAN_IEEE754
#define WORDS_BIGENDIAN

----------
effort: easy
files: dtoa.c
messages: 2334
nosy: pypy-issue, shager
priority: bug
release: 1.4
status: in-progress
title: dtoa conversion fails on powerpc, 64 bit

_______________________________________________________
PyPy development tracker <pypy-dev-issue at codespeak.net>
<https://codespeak.net/issue/pypy-dev/issue677>
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtoa.c
Type: text/x-csrc
Size: 82798 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-issue/attachments/20110324/bc21be27/attachment.c>

From pypy-dev-issue at codespeak.net  Fri Mar 25 13:07:06 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 25 Mar 2011 12:07:06 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1301054826.77.0.982277815694.issue673@>


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

On my Linux machine, on 32-bit, os.sysconf(191) returns 0, and on 64-bit,
os.sysconf(191) returns 262144.  The correct value however is 4MB, which happens
to be the size of the L3 cache here, returned (on 64-bit) by os.sysconf(194). 
So it doesn't look like the one-size-fits-all solution either.

But perhaps more importantly, on modern CPUs like tannit (8MB of L3 cache), the
size of the nursery seems to matter less.  I did not get definitive speed-ups
(at most 5%) between setting it to 1MB, 2MB, 4MB, 6MB, 9MB or 29MB...  Yes, even
if it's *larger* than the L3 cache there is no performance drop.  Go figure.  It
seems that for this kind of CPU we can as well just pick a fixed number like 1
or 2 MB and be happy with it.  Of course, on ARM I'm sure it matters more right
now, as it did 5 years ago on x86.

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


From pypy-dev-issue at codespeak.net  Fri Mar 25 13:12:02 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Fri, 25 Mar 2011 12:12:02 +0000
Subject: [PyPy-issue] [issue673] Linux L2 cache size
Message-ID: <1301055122.15.0.85014497868.issue673@>


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

lac: on my machine (in 32-bit), dmidecode returns L1 and L2 cache size but not
L3 cache size.  So it's not a one-size-fits-all solution either.  Moreover,
dmidecode needs to be run as root, so it doesn't help.

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


From pypy-dev-issue at codespeak.net  Sat Mar 26 17:06:09 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Sat, 26 Mar 2011 16:06:09 +0000
Subject: [PyPy-issue] [issue677] dtoa conversion fails on powerpc, 64 bit
Message-ID: <1301155569.15.0.340832271064.issue677@>


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

Should be fixed.  Can you try again?

----------
status: in-progress -> testing

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


From pypy-dev-issue at codespeak.net  Mon Mar 28 09:05:27 2011
From: pypy-dev-issue at codespeak.net (Sven Hager)
Date: Mon, 28 Mar 2011 07:05:27 +0000
Subject: [PyPy-issue] [issue677] dtoa conversion fails on powerpc, 64 bit
Message-ID: <1301295927.63.0.22837437483.issue677@>


Sven Hager <sven.hager at uni-duesseldorf.de> added the comment:

It does work now, tests do pass.

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

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


From pypy-dev-issue at codespeak.net  Thu Mar 31 14:51:41 2011
From: pypy-dev-issue at codespeak.net (Armin Rigo)
Date: Thu, 31 Mar 2011 12:51:41 +0000
Subject: [PyPy-issue] [issue678] stack overflow issue
Message-ID: <1301575901.04.0.601080933679.issue678@>


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

In pypy-c-jit:

>>>> def f(): f()
>>>> for i in range(10000):
....   try: f()
....   except RuntimeError: pass
....
out of memory (from JITted code)
Aborted

----------
effort: ???
messages: 2339
nosy: pypy-issue
priority: bug
release: ???
status: unread
title: stack overflow issue

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


From pypy-dev-issue at codespeak.net  Thu Mar 31 18:26:20 2011
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Thu, 31 Mar 2011 16:26:20 +0000
Subject: [PyPy-issue] [issue664] [PATCH] Extend readline emulation to
	support colour code and ansi escapes
Message-ID: <1301588780.08.0.842740624189.issue664@>


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

https://bitbucket.org/pypy/pyrepl/changeset/4d9968d3e7da
https://bitbucket.org/pypy/pypy/changeset/ed0020d371de

fixed in ed0020d371de, thank you.

For klep

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

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


From pypy-dev-issue at codespeak.net  Thu Mar 31 18:27:34 2011
From: pypy-dev-issue at codespeak.net (Antonio Cuni)
Date: Thu, 31 Mar 2011 16:27:34 +0000
Subject: [PyPy-issue] [issue664] [PATCH] Extend readline emulation to
	support colour code and ansi escapes
Message-ID: <1301588854.3.0.468594685203.issue664@>


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

bah, I pressed "submit" too early :-)

For kleptog: I didn't know about using \x01 and \x02 to delimit escape sequences
in readline: is it a documented feature?

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

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