From tracker at bugs.pypy.org  Tue Nov  1 02:28:12 2011
From: tracker at bugs.pypy.org (Garen Parham)
Date: Tue, 01 Nov 2011 01:28:12 +0000
Subject: [pypy-issue] [issue691] pypy-head does not compile under Windows
In-Reply-To: <1303737570.22.0.620331113708.issue691@>
Message-ID: <1320110892.76.0.16887862644.issue691@bugs.pypy.org>


Garen Parham <garen.p at gmail.com> added the comment:

FWIW, after completely uninstalling VS 2010, it no longer selects the wrong 
linker at the end, and translations (with pypy 1.5 or cpython _only_) started to 
succeed.  However, this recent commit (according to a hg bisect run) causes a 
new translation error:

Changeset 48462:fc37961a668f: bad
The first bad revision is:
changeset:   48462:fc37961a668f
parent:      48459:89631bbf04fe
user:        Maciej Fijalkowski <fijall at gmail.com>
date:        Tue Oct 25 23:17:59 2011 +0200
summary:     look into mmap


The translation error text is as follows:

[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "translate.py", line 308, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\translator\driver.py", line 809, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = 
self._maybe_skip())
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\translator\tool\taskengine.py", line 116, in 
_execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\translator\driver.py", line 286, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\translator\driver.py", line 397, in 
task_pyjitpl_lltype
[translation:ERROR]     backend_name=self.config.translation.jit_backend, 
inline=True)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\metainterp\warmspot.py", line 43, in 
apply_jit
[translation:ERROR]     **kwds)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\metainterp\warmspot.py", line 210, in 
__init__
[translation:ERROR]     self.codewriter.make_jitcodes(verbose=verbose)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\codewriter.py", line 72, in 
make_jitcodes
[translation:ERROR]     self.transform_graph_to_jitcode(graph, jitcode, verbose)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\codewriter.py", line 41, in 
transform_graph_to_jitcode
[translation:ERROR]     transform_graph(graph, self.cpu, self.callcontrol, 
portal_jd)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\jtransform.py", line 24, in 
transform_graph
[translation:ERROR]     t.transform(graph)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\jtransform.py", line 43, in 
transform
[translation:ERROR]     self.optimize_block(block)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\jtransform.py", line 67, in 
optimize_block
[translation:ERROR]     oplist = self.rewrite_operation(op)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\jtransform.py", line 202, in 
rewrite_operation
[translation:ERROR]     return rewrite(self, op)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\jtransform.py", line 279, in 
rewrite_op_direct_call
[translation:ERROR]     return getattr(self, 'handle_%s_call' % kind)(op)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\jtransform.py", line 327, in 
handle_residual_call
[translation:ERROR]     calldescr = self.callcontrol.getcalldescr(op)
[translation:ERROR]    File 
"U:\vcs\hg\bitbucket_pypy\pypy\jit\codewriter\call.py", line 208, in 
getcalldescr
[translation:ERROR]     assert NON_VOID_ARGS == [T for T in ARGS if T is not 
lltype.Void]
[translation:ERROR]  AssertionError

----------
release: 1.6 -> 1.7

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

From tracker at bugs.pypy.org  Tue Nov  1 08:39:51 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 07:39:51 +0000
Subject: [pypy-issue] [issue922] 1.6 crashes with time.sleep(negative_number)
In-Reply-To: <1319584373.54.0.90788508105.issue922@bugs.pypy.org>
Message-ID: <1320133191.61.0.218535202362.issue922@bugs.pypy.org>


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

Seems fixed, thank you.

----------
nosy: +arigo
status: testing -> resolved

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

From tracker at bugs.pypy.org  Tue Nov  1 09:30:16 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 08:30:16 +0000
Subject: [pypy-issue] [issue896] Bad quotation?
In-Reply-To: <1318009967.57.0.315391021514.issue896@bugs.pypy.org>
Message-ID: <1320136216.45.0.224902396689.issue896@bugs.pypy.org>


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

I regenerated an up-to-date list and dropped the topic that you point out (and
another very similar one).

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

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

From tracker at bugs.pypy.org  Tue Nov  1 09:36:09 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 08:36:09 +0000
Subject: [pypy-issue] [issue894] Undefined symbol in PIL 1.7 on pypy 1.6
In-Reply-To: <1317936434.53.0.308160585553.issue894@bugs.pypy.org>
Message-ID: <1320136569.65.0.7118935453.issue894@bugs.pypy.org>


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

Works for me on Linux.  Is it a OS/X-only issue?  Does it occur with any
extension module, or only with PIL?

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

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

From tracker at bugs.pypy.org  Tue Nov  1 17:47:37 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 16:47:37 +0000
Subject: [pypy-issue] [issue828] subprocess on nightly builds, linux 64
In-Reply-To: <1313238073.53.0.371378815064.issue828@bugs.pypy.org>
Message-ID: <1320166057.38.0.999257123426.issue828@bugs.pypy.org>


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

The patch should at least check if self.{stdin,stdout,stderr} are None, and not
call close() on None.

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

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

From tracker at bugs.pypy.org  Tue Nov  1 17:59:40 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 16:59:40 +0000
Subject: [pypy-issue] [issue906] CTRL-leftarrow and CTRL-rightarrow don't
	work in PyPy	console
In-Reply-To: <1318429405.87.0.821520990977.issue906@bugs.pypy.org>
Message-ID: <1320166780.63.0.183621832106.issue906@bugs.pypy.org>


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

mwh: can you implement this in pyrepl?  Or would you prefer that we do it
ourselves?  I suspect that it's a matter of listing the most common key
combinations from /etc/inputrc into some file of pyrepl, and not actually
reading /etc/inputrc at run-time, as that seems more messy than it's worth (e.g.
handling $if...$endif).

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

From tracker at bugs.pypy.org  Tue Nov  1 18:04:00 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 17:04:00 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1320167040.64.0.621227311638.issue920@bugs.pypy.org>


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

Hi Stefanor,

Do you still work on your fix?  Or should we take it from there and finish it?

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

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

From tracker at bugs.pypy.org  Tue Nov  1 18:11:54 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 17:11:54 +0000
Subject: [pypy-issue] [issue921] _structseq is a slow mess
In-Reply-To: <1319565628.25.0.385940441591.issue921@bugs.pypy.org>
Message-ID: <1320167514.43.0.20401597392.issue921@bugs.pypy.org>


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

Doesn't seem to be particularly the fault of os.stat_result.  Rewriting the
benchmark with afa's command in it gets us a +25% speed improvement over
CPython.  The os.stat() itself is indeed slower on PyPy (by 38%, not 2x for me,
and that's counting only user time, not system time that is the same in both
cases).  So I think I'll close this bug report unless fijal has more precise
information for us to look at.

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

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

From tracker at bugs.pypy.org  Tue Nov  1 18:16:25 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 17:16:25 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1320167785.48.0.838111977868.issue900@bugs.pypy.org>


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

Note that I think a possible cause for this is that cProfile, together with the
JIT, uses as timestamp the very fast single-assembler instruction RDTSM.  On
multi-CPU machines, this can run into the issue that when the process moves
between different CPUs it can give inconsistent results.  We have attempted to
fix it on Linux by pinning the process to one CPU.  Can you point me to the
place of the Windows API that would do the same?

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

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

From tracker at bugs.pypy.org  Tue Nov  1 19:06:17 2011
From: tracker at bugs.pypy.org (Stefano Rivera)
Date: Tue, 01 Nov 2011 18:06:17 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1320170777.64.0.32297715968.issue920@bugs.pypy.org>


Stefano Rivera <pypy at rivera.za.net> added the comment:

Working on it, but very intermittently (I'm at the Ubuntu Developer Summit this
week).
I started looking at the io module. I think it mostly handles this fine. I saw 4
loops where it might have the same bug, but I haven't managed to prove that yet.
BufferedMixin._read_all
W_IOBase.w_readline
W_IOBase.w_readlines_w
W_RawIOBase.w_readall_w

There are also likely to be similar problems in write() methods, I haven't looked.

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

From tracker at bugs.pypy.org  Tue Nov  1 19:21:35 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 01 Nov 2011 18:21:35 +0000
Subject: [pypy-issue] [issue905] ZipFile.extractall is very slow compared to
	CPython 2.6
In-Reply-To: <1318374087.9.0.996755989845.issue905@bugs.pypy.org>
Message-ID: <1320171695.68.0.860291857165.issue905@bugs.pypy.org>


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

Fwiw it's spending 25% of the total time in computing the crc32, which if maybe
not the main issue is still far too much :-/

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

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

From tracker at bugs.pypy.org  Tue Nov  1 20:49:57 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 01 Nov 2011 19:49:57 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1320176997.79.0.433922598315.issue900@bugs.pypy.org>


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

On Windows you could use::
    DWORD mask = 1; // pin to processor #0
    SetProcessAffinityMask(GetCurrentProcess(), &mask);

----------
nosy: +afa

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

From tracker at bugs.pypy.org  Tue Nov  1 20:51:56 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Tue, 01 Nov 2011 19:51:56 +0000
Subject: [pypy-issue] [issue905] ZipFile.extractall is very slow compared to
	CPython 2.6
In-Reply-To: <1318374087.9.0.996755989845.issue905@bugs.pypy.org>
Message-ID: <1320177116.26.0.944231461397.issue905@bugs.pypy.org>


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

It looks like that time is likely from the memcpy-ish loop we have in 
get_nonmoving buffer.  That's likely much much slower than it needs to be because 
GCC doesn't vectorize our loops: http://gcc.gnu.org/bugzilla/show_bug.cgi?
id=50693

----------
nosy: +agaynor

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

From tracker at bugs.pypy.org  Wed Nov  2 13:21:25 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 02 Nov 2011 12:21:25 +0000
Subject: [pypy-issue] [issue895] Continulets + JIT
In-Reply-To: <1317981953.45.0.228294129679.issue895@bugs.pypy.org>
Message-ID: <1320236485.18.0.414600235417.issue895@bugs.pypy.org>


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

Anyone on Windows cares to either fix or explain in a detailed way how to build
pypy with the Windows-only assembler file from src/stacklet/switch_x86_msvc.asm?
 That's the reason Windows builds don't include _continuation so far.

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

From tracker at bugs.pypy.org  Wed Nov  2 15:14:24 2011
From: tracker at bugs.pypy.org (Josh Ayers)
Date: Wed, 02 Nov 2011 14:14:24 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1320243264.36.0.837708479922.issue900@bugs.pypy.org>


Josh Ayers <josh.ayers at gmail.com> added the comment:

I just tested both of the attached files on an old single core Pentium 4 machine
(running Win XP).  There were negative or very large positive times in both cases.

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

From tracker at bugs.pypy.org  Wed Nov  2 15:17:09 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 02 Nov 2011 14:17:09 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1320243429.4.0.124526801779.issue900@bugs.pypy.org>


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

Can you also run the same tests with "pypy --jit off"?  This would let us know
if the issue is somehow related to the JIT.  Right now, on trunk, the JIT seems
to misbehave badly on Windows (only), which may be related if "pypy --jit off"
shows no strange numbers.

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

From tracker at bugs.pypy.org  Wed Nov  2 15:32:18 2011
From: tracker at bugs.pypy.org (Josh Ayers)
Date: Wed, 02 Nov 2011 14:32:18 +0000
Subject: [pypy-issue] [issue900] Using cProfile on Windows generates
	negative tottime values
In-Reply-To: <1318148955.37.0.118875417908.issue900@bugs.pypy.org>
Message-ID: <1320244338.74.0.928270983214.issue900@bugs.pypy.org>


Josh Ayers <josh.ayers at gmail.com> added the comment:

Yes, that fixes the problem.

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

From tracker at bugs.pypy.org  Wed Nov  2 15:32:54 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Wed, 02 Nov 2011 14:32:54 +0000
Subject: [pypy-issue] [issue921] _structseq is a slow mess
In-Reply-To: <1319565628.25.0.385940441591.issue921@bugs.pypy.org>
Message-ID: <1320244374.95.0.429900380071.issue921@bugs.pypy.org>


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

Reopening. To elaborate a bit - I suppose some details depend on the system, but 
_structseq creation popped up very high on traces of running dulwich (a almost-
pure python git implementation) and the assembler was not looking very pretty. 
Probably also affects bzr and hg.

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

From tracker at bugs.pypy.org  Fri Nov  4 12:25:28 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 04 Nov 2011 11:25:28 +0000
Subject: [pypy-issue] [issue920] Lost data with async I/O
In-Reply-To: <1319482159.83.0.0983179975147.issue920@bugs.pypy.org>
Message-ID: <1320405928.6.0.146045580364.issue920@bugs.pypy.org>


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

I have made some comments on irc and asked fijal to post them here, but he
didn't, so please look here:
http://www.tismer.com/pypy/irc-logs/pypy/pypy.2011-11-03.log.html (grep for
EAGAIN).  In particular I mentioned that CPython seems to lose characters in
most of the same cases too; it seems to special-case EAGAIN only in the read()
method.

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

From tracker at bugs.pypy.org  Sun Nov  6 14:27:49 2011
From: tracker at bugs.pypy.org (hruske)
Date: Sun, 06 Nov 2011 13:27:49 +0000
Subject: [pypy-issue] [issue926] pyparsing: PyPy takes much more time than
	CPython
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>


New submission from hruske <zejn at kiberpipa.org>:

I implemented a parser in pyparsing, which has absymal performance in PyPy.
Using the parser on smaller dataset results in PyPy being ~10x slower (14.9s)
than CPython (1.5s) and failing to complete on a large dataset, where CPython
takes 17s.

Script and dataset can be found at http://www.kiberpipa.org/~hruske/stuff/pypy/

----------
messages: 3414
nosy: hruske, pypy-issue
priority: performance bug
status: unread
title: pyparsing: PyPy takes much more time than CPython

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

From tracker at bugs.pypy.org  Sun Nov  6 15:39:09 2011
From: tracker at bugs.pypy.org (hruske)
Date: Sun, 06 Nov 2011 14:39:09 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320590349.25.0.699562401881.issue926@bugs.pypy.org>


hruske <zejn at kiberpipa.org> added the comment:

After more debugging I found out this is a string concatenation issue, which was
done by adding strings together. This apparently kills PyPy.

Above is my modified version, below is original, of pyparsing.py:

# pyparsing.py, class ParseResults, line 446
    def __str__( self ):
        out = []
        for i in self.__toklist:
            if isinstance(i, ParseResults):
                out.append(_ustr(i))
            else:
                out.append(repr(i))
        return '[' + ', '.join(out) + ']'

        """
        out = "["
        sep = ""
        for i in self.__toklist:
            if isinstance(i, ParseResults):
                out += sep + _ustr(i)
            else:
                out += sep + repr(i)
            sep = ", "
        out += "]"
        return out
        #"""

----------
status: unread -> chatting
title: pyparsing: PyPy takes much more time than CPython -> string concatenation using + kills PyPy

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

From tracker at bugs.pypy.org  Sun Nov  6 18:41:31 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 06 Nov 2011 17:41:31 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320601291.85.0.821216837574.issue926@bugs.pypy.org>


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

Yes, string concatenation is known to copy strings. Can we close it as won't fix 
then or is there more in pyparsing that makes it slow?

Cheers,
fijal

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

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

From tracker at bugs.pypy.org  Sun Nov  6 19:00:43 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 06 Nov 2011 18:00:43 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320602443.82.0.703399655394.issue926@bugs.pypy.org>


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

To be precise - strings are immutable in Python. CPython has a hack that avoids 
doing a copy on string concatenation when refcount is 1. This isn't the case on 
pypy, where it's hard to check if refcount is 1 or not (there is no refcounting) 
and we don't implement this optimization. Hence, this is a wontfix.

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

From tracker at bugs.pypy.org  Sun Nov  6 21:36:10 2011
From: tracker at bugs.pypy.org (hruske)
Date: Sun, 06 Nov 2011 20:36:10 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320611770.81.0.182760320903.issue926@bugs.pypy.org>


hruske <zejn at kiberpipa.org> added the comment:

Is there a possibility, that a warning would be issued if a str + str is
detected in a loop?

Going from 30s to more than 30 minutes+ without an obvious reason is pretty bad.

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

From tracker at bugs.pypy.org  Mon Nov  7 10:22:40 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 07 Nov 2011 09:22:40 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320657760.0.0.854701602503.issue926@bugs.pypy.org>


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

It's not a time comparison - algorithm goes from linear to quadratic, it can go 
arbitrarily bad, depending on the size of the problem.

It's seriously obscure to emit a warning - the reason why people use this is 
precisely because CPython has an obscure hack there to optimize when refcount is 
one. If you have another reference to the same string, it becomes quadratic. 
Personally, I think linear-vs-quadratic difference based on refcount being one 
is a very obscure optimization to have.

Maybe we can introduce some special mode that will show you what went wrong in 
your program, however emitting warning by default is not good.

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

From tracker at bugs.pypy.org  Mon Nov  7 10:53:16 2011
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Mon, 07 Nov 2011 09:53:16 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320659596.07.0.234934376619.issue926@bugs.pypy.org>


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

We *can* solve this in PyPy, and even have the code for it. It's just not
enabled by default, because we never found real-life code that is made fast by
it. What we need is a decision whether we want to support this code pattern (or
fight against it every time somebody has the problem).

@Hruske: if you want to experiment you could translate with this commandline and
see whether things improve:

translate.py -Ojit targetpypystandalone.py --objspace-std-withstrbuf

----------
nosy: +cfbolz

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

From tracker at bugs.pypy.org  Mon Nov  7 14:30:55 2011
From: tracker at bugs.pypy.org (hruske)
Date: Mon, 07 Nov 2011 13:30:55 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320672655.79.0.0664001337827.issue926@bugs.pypy.org>


hruske <zejn at kiberpipa.org> added the comment:

Success!

PyPy now takes ~ 13.5s, where CPython takes ~ 12.7s.

However, seems something is broken as the PyPy binary only works in about 1/10
runs, otherwise just segfaults.

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

From tracker at bugs.pypy.org  Mon Nov  7 18:22:30 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 07 Nov 2011 17:22:30 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1320686550.44.0.0395555618735.issue926@bugs.pypy.org>


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

FWIW I think it's solvable at the JIT level, I may spend some time playing with 
this idea.

----------
nosy: +agaynor

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

From tracker at bugs.pypy.org  Thu Nov 10 19:44:48 2011
From: tracker at bugs.pypy.org (Zira)
Date: Thu, 10 Nov 2011 18:44:48 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than CYthon
	2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>


New submission from Zira <NeruYume at hotmail.com>:

from itertools import combinations
import time
string = "ABCDEFGHIJKLMNOPQRSTUWXYZ"
string = string.lower()

minlen = 3
substrlen = 12
#Find combinations available letters can be arranged in
at = time.clock()
lookup = set()
for i in range(minlen, substrlen+1):
    for comb in combinations(string, i):
        lookup.add("".join(sorted(comb)))

lookup = list(lookup)
lookup.sort(key=len, reverse=True)
print time.clock()-at

###
#This takes more time on pypy-c-jit-49069-62bc56457861-win32 than on CPython 
2.7 (64 bit) 

Took 90 seconds on pypy-c-jit-49069-62bc56457861-win32 and 45 seconds on 
CPython 2.7

----------
messages: 3423
nosy: Zira, pypy-issue
priority: performance bug
status: unread
title: Task takes more time on nightly than CYthon 2.7

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

From tracker at bugs.pypy.org  Thu Nov 10 19:46:11 2011
From: tracker at bugs.pypy.org (Zira)
Date: Thu, 10 Nov 2011 18:46:11 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than
	CPython 2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1320950771.18.0.670704263057.issue927@bugs.pypy.org>


Zira <NeruYume at hotmail.com> added the comment:

OS: Windows 7 64 bit

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

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

From tracker at bugs.pypy.org  Thu Nov 10 19:47:26 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 10 Nov 2011 18:47:26 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than
	CPython 2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1320950846.59.0.282367296289.issue927@bugs.pypy.org>


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

I can reproduce it on my linux (64bit) vs CPython 2.6. PyPy is slower and the 
offending call is lookup.add (replacing with a dict does not help). A bit no clue

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

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

From tracker at bugs.pypy.org  Thu Nov 10 20:00:26 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 10 Nov 2011 19:00:26 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than
	CPython 2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1320951626.9.0.262911274408.issue927@bugs.pypy.org>


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

Carl pushed a ton of set-strategies stuff, we should investigate if that helps at 
all.

----------
nosy: +agaynor

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

From tracker at bugs.pypy.org  Sat Nov 12 16:48:10 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sat, 12 Nov 2011 15:48:10 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than
	CPython 2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1321112890.73.0.932498930156.issue927@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

This looks like the same gc performance problem that we have with making large 
dicts. Minimark uses card refs at the front of arrays to determine if objects 
need to be examined and possibly moved out of the nursery. Each bit represents 
whether anything was changed in a range of objects in the array behind the 
structure. I believe the size is a little over a hundred. Anyway, it works well 
for appending objects to lists, but when adding items to dicts and sets, objects 
are added in pseudo-randomly. When creating huge dicts/sets, basically the whole 
low level array behind the dict/set is checked for every minor collection.

----------
nosy: +justinpeel

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

From tracker at bugs.pypy.org  Mon Nov 14 19:51:23 2011
From: tracker at bugs.pypy.org (matpow2)
Date: Mon, 14 Nov 2011 18:51:23 +0000
Subject: [pypy-issue] [issue849] pypy 1.6, pyglet crash on win32
In-Reply-To: <1314533256.76.0.0673329127649.issue849@bugs.pypy.org>
Message-ID: <1321296683.22.0.00997416141138.issue849@bugs.pypy.org>


matpow2 <matpow2 at gmail.com> added the comment:

The segfault seems to have been fixed in PyPy trunk. Now I get exceptions and
warnings like this, though: http://paste.pocoo.org/show/rPNQr4baBysnbQR0jOTr/

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

From tracker at bugs.pypy.org  Wed Nov 16 11:09:31 2011
From: tracker at bugs.pypy.org (alex huang)
Date: Wed, 16 Nov 2011 10:09:31 +0000
Subject: [pypy-issue] [issue928] syslog.openlog behavior different from
	CPython
In-Reply-To: <1321438171.98.0.746704634584.issue928@bugs.pypy.org>
Message-ID: <1321438171.98.0.746704634584.issue928@bugs.pypy.org>


New submission from alex huang <alexhuang1984 at gmail.com>:

hi, I use syslog.openlog in pypy 1.6.
it result that, TypeError Exception Value openlog() takes exactly 3 arguments (1 
given)
but it seems from the Cpython doc, that the args only optional.
could I get this compatibility or need I change my legacy codes?

----------
messages: 3429
nosy: alexband, pypy-issue
priority: wish
status: unread
title: syslog.openlog behavior different from CPython

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

From tracker at bugs.pypy.org  Wed Nov 16 11:29:04 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 16 Nov 2011 10:29:04 +0000
Subject: [pypy-issue] [issue928] syslog.openlog behavior different from
	CPython
In-Reply-To: <1321438171.98.0.746704634584.issue928@bugs.pypy.org>
Message-ID: <1321439344.5.0.434522967816.issue928@bugs.pypy.org>


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

Yes, pypy should be updated. Fortunately you can do it in your local copy.

in lib_pypy/syslog.py, the function header:
    def openlog(ident, option, facility):
should be changed to:
    def openlog(ident=None, option=0, facility=LOG_USER):

Can you try and see if it fixes your issue?

Careful though, this function still has a bug: "man openlog" says:
The argument ident in the call of openlog() is probably stored as-is. Thus, if the 
string it points to is changed, syslog() may start prepending the changed string, and 
if the string it points to ceases to exist, the results are undefined. Most portable 
is to use a string constant.
CPython keeps a global reference to the string, pypy should probably store the 
ctypes.c_char_p buffer instead.

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

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

From tracker at bugs.pypy.org  Thu Nov 17 20:59:42 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 17 Nov 2011 19:59:42 +0000
Subject: [pypy-issue] [issue887] PIL image access object produces a crash
	with	NotImplementedError
In-Reply-To: <1317264050.69.0.43418639226.issue887@bugs.pypy.org>
Message-ID: <1321559982.73.0.146067220292.issue887@bugs.pypy.org>


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

Fixed in f46e309f89bd, thanks for the patch!

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

From tracker at bugs.pypy.org  Fri Nov 18 10:06:04 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 18 Nov 2011 09:06:04 +0000
Subject: [pypy-issue] [issue928] syslog.openlog behavior different from
	CPython
In-Reply-To: <1321438171.98.0.746704634584.issue928@bugs.pypy.org>
Message-ID: <1321607164.5.0.969731768327.issue928@bugs.pypy.org>


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

Fixed in b6585727903b, where I followed the source of CPython more closely. 
Unfortunately it seems that there are no tests for syslog.  Alexband: can you
test that the changes work with your application?  (You can just grab the
updated lib_pypy/syslog.py, or in doubt download the whole nightly build of PyPy
at http://buildbot.pypy.org/nightly/trunk/ (Windows version coming later today)).

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

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

From tracker at bugs.pypy.org  Fri Nov 18 10:44:37 2011
From: tracker at bugs.pypy.org (alex huang)
Date: Fri, 18 Nov 2011 09:44:37 +0000
Subject: [pypy-issue] [issue928] syslog.openlog behavior different from
	CPython
In-Reply-To: <1321438171.98.0.746704634584.issue928@bugs.pypy.org>
Message-ID: <1321609477.3.0.339392018813.issue928@bugs.pypy.org>


alex huang <alexhuang1984 at gmail.com> added the comment:

It seems work with me. I just run my application and I haven't seen exception with 
syslog appear again.

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

From tracker at bugs.pypy.org  Fri Nov 18 10:45:01 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 18 Nov 2011 09:45:01 +0000
Subject: [pypy-issue] [issue928] syslog.openlog behavior different from
	CPython
In-Reply-To: <1321438171.98.0.746704634584.issue928@bugs.pypy.org>
Message-ID: <1321609501.75.0.534873860965.issue928@bugs.pypy.org>


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

Thanks :-)

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

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

From tracker at bugs.pypy.org  Fri Nov 18 15:25:32 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 18 Nov 2011 14:25:32 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than
	CPython 2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1321626332.06.0.868903616163.issue927@bugs.pypy.org>


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

Maybe it makes sense to use in this case a much smaller card ref size?

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

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

From tracker at bugs.pypy.org  Fri Nov 18 17:42:38 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Fri, 18 Nov 2011 16:42:38 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1321634558.21.0.0457379892413.issue926@bugs.pypy.org>


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

hruske: I think I have fixed the segfault (5269f0ee1ed2).  Can you try again?

The main point is that we have to decide if we would like strbuf to be enabled
by default.  It makes some sense, because it helps in similar cases than the
ones in CPython, giving "unexpectedly" linear complexity.  The differences are:

- there are cases where it works even though CPython would give up, notably if
the string is stored on some instance and we do "instance.string += ..."

- conversely, there are cases were we give up but CPython would not.  Most
importantly, it is the case if we try to do almost anything else with the string
every iteration of the loop.  For example, the loop that contains "s += ..." may
also contain "if s.endswith(..):".

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

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

From tracker at bugs.pypy.org  Sat Nov 19 09:34:10 2011
From: tracker at bugs.pypy.org (hruske)
Date: Sat, 19 Nov 2011 08:34:10 +0000
Subject: [pypy-issue] [issue926] string concatenation using + kills PyPy
In-Reply-To: <1320586069.62.0.710791528311.issue926@bugs.pypy.org>
Message-ID: <1321691650.08.0.571563726347.issue926@bugs.pypy.org>


hruske <zejn at kiberpipa.org> added the comment:

Works okay without segfaults now, in about the same time (13s-14s).

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

From tracker at bugs.pypy.org  Sun Nov 20 19:33:58 2011
From: tracker at bugs.pypy.org (David Naylor)
Date: Sun, 20 Nov 2011 18:33:58 +0000
Subject: [pypy-issue] [issue929] Improve platform support for FreeBSD
In-Reply-To: <1321814038.7.0.494588194942.issue929@bugs.pypy.org>
Message-ID: <1321814038.7.0.494588194942.issue929@bugs.pypy.org>


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

Fix a bug where a custom CFLAGS/LDFLAGS could result in a linker error.  

On FreeBSD `-pthreads' needs to be passed to the linker so ensure the flags 
always contains `-pthreads'.  While here fully implement the get_env_vector() 
function.  

I've notices the other BSDs have copied the freebsd.py platform file, perhaps 
this patch is relevant for them as well (I, however, have no way to verify 
this).

----------
files: patch-pypy::translator::platform::freebsd.py
messages: 3441
nosy: DragonSA, pypy-issue
priority: bug
status: unread
title: Improve platform support for FreeBSD

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

From tracker at bugs.pypy.org  Mon Nov 21 04:44:51 2011
From: tracker at bugs.pypy.org (qbproger)
Date: Mon, 21 Nov 2011 03:44:51 +0000
Subject: [pypy-issue] [issue930] Recursion with cache slower on pypy than
	CPython 2.6
In-Reply-To: <1321847091.92.0.562256609996.issue930@bugs.pypy.org>
Message-ID: <1321847091.92.0.562256609996.issue930@bugs.pypy.org>


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

This runs slower on Pypy 1.6 (and trunk) than CPython 2.6.5.  CPython 2.7 runs
this even faster

OR_VAL = [0] * 10
FINAL_CHECK = 0
for i in xrange(0, 10):
    OR_VAL[i] = 1 << i
    FINAL_CHECK |= OR_VAL[i]

def place_numbers(last_num, check, left, cache):
    if left == 0:
        if check == FINAL_CHECK:
            return 1
        return 0
    
    if (check, left, last_num) in cache:
        return cache[(check, left, last_num)]
    
    output = 0
    for n in (last_num - 1, last_num + 1):
        if n < 10 and n > -1:
            flip = False
            if (check & OR_VAL[n]) == 0:
                flip = True
                check = check | OR_VAL[n]
            output += place_numbers(n, check, left-1, cache)
            if flip:
                check = check & (~OR_VAL[n])
    
    cache[(check, left, last_num)] = output
    
    return output

def main():
    cache = {}
    check = 0
    ans = 0
    for size in xrange(10, 41):
        for first_number in xrange(1, 10):
            check |= OR_VAL[first_number]
            ans += place_numbers(first_number, check, size-1, cache)
            check &= ~OR_VAL[first_number]
    print ans
main()

----------
messages: 3443
nosy: pypy-issue, qbproger
priority: performance bug
status: unread
title: Recursion with cache slower on pypy than CPython 2.6

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

From tracker at bugs.pypy.org  Mon Nov 21 07:25:20 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 21 Nov 2011 06:25:20 +0000
Subject: [pypy-issue] [issue930] Recursion with cache slower on pypy than
	CPython 2.6
In-Reply-To: <1321847091.92.0.562256609996.issue930@bugs.pypy.org>
Message-ID: <1321856720.9.0.75138629543.issue930@bugs.pypy.org>


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

This program finishes in 0.05s for me. This is definitely not enough for the JIT 
to warm up.

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

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

From tracker at bugs.pypy.org  Mon Nov 21 07:59:54 2011
From: tracker at bugs.pypy.org (qbproger)
Date: Mon, 21 Nov 2011 06:59:54 +0000
Subject: [pypy-issue] [issue930] Recursion with cache slower on pypy than
	CPython 2.6
In-Reply-To: <1321847091.92.0.562256609996.issue930@bugs.pypy.org>
Message-ID: <1321858794.76.0.930593559724.issue930@bugs.pypy.org>


qbproger <qbproger at gmail.com> added the comment:

This was on windows 7 64

I put a for loop around main to run it 100 times
python 2.6:
$ time python 178.py

real    0m3.234s
user    0m3.088s
sys     0m0.092s

pypy 1.6:
$ time pypy 178.py

real    0m4.459s
user    0m0.015s
sys     0m0.015s

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

From tracker at bugs.pypy.org  Mon Nov 21 12:58:46 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 21 Nov 2011 11:58:46 +0000
Subject: [pypy-issue] [issue931] web site bugs
In-Reply-To: <1321876726.07.0.898293402867.issue931@bugs.pypy.org>
Message-ID: <1321876726.07.0.898293402867.issue931@bugs.pypy.org>


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

On the web site http://pypy.org:

home page -> click "donate to py3k" -> click "read proposal"

it ends up selecting "donate to numpy" again, which is confusing.

Also the text "This donation will go towards supporting NumPy in PyPy Read
proposal" would be more readable with a dot or a line break.

----------
messages: 3447
nosy: arigo, pypy-issue
priority: bug
status: unread
title: web site bugs

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

From tracker at bugs.pypy.org  Mon Nov 21 13:02:57 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 21 Nov 2011 12:02:57 +0000
Subject: [pypy-issue] [issue930] Recursion with cache slower on pypy than
	CPython 2.6
In-Reply-To: <1321847091.92.0.562256609996.issue930@bugs.pypy.org>
Message-ID: <1321876977.57.0.693455818777.issue930@bugs.pypy.org>


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

I agree that we have to look at it, but I just want to note that (for me)
running 500 iterations ends up being faster with pypy, while 100 iterations are
not enough.

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

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

From tracker at bugs.pypy.org  Mon Nov 21 15:04:19 2011
From: tracker at bugs.pypy.org (Peter)
Date: Mon, 21 Nov 2011 14:04:19 +0000
Subject: [pypy-issue] [issue919] implement multi-dimension arrays in
	micronumpy
In-Reply-To: <1319322811.27.0.133989194674.issue919@bugs.pypy.org>
Message-ID: <1321884259.66.0.138153952822.issue919@bugs.pypy.org>


Peter <p.j.a.cock at googlemail.com> added the comment:

Fixed typo in title.

Note PyPy 1.7 release notes suggest this is being worked on,
http://morepypy.blogspot.com/2011/11/pypy-17-widening-sweet-spot.html

----------
status: unread -> chatting
title: implement multi-dimention arrays in micronumpy -> implement multi-dimension arrays in micronumpy

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

From tracker at bugs.pypy.org  Mon Nov 21 15:18:18 2011
From: tracker at bugs.pypy.org (Guillaume Bouchard)
Date: Mon, 21 Nov 2011 14:18:18 +0000
Subject: [pypy-issue] [issue932] Python 1.7 slower on home maid path tracing
	than 1.6
In-Reply-To: <1321885098.48.0.0523238945198.issue932@bugs.pypy.org>
Message-ID: <1321885098.48.0.0523238945198.issue932@bugs.pypy.org>


New submission from Guillaume Bouchard <guillaume.bouchard at liris.cnrs.fr>:

I just tested pypy 1.7 on very poor implementation of path tracing I wrote for
fun. (it is mainly a copy/paste/rewrite version of the C smallpt)

pypy1.7 runs slower than 1.6:

$ time pypy1.6 smallpt.py 640 480 4   
Rendering (4 spp) 99.84%~/src/pypy/pypy-1.6/bin/pypy smallpt.py 640 480 4 
36.56s user 0.07s system 99% cpu 36.771 total
$ time pypy1.7 smallpt.py 640 480 4
Rendering (4 spp) 99.84%~/src/pypy/pypy-1.7/bin/pypy smallpt.py 640 480 4 
53.31s user 0.14s system 99% cpu 53.768 total


$ pypy1.7 -V
Python 2.7.1 (7773f8fc4223, Nov 18 2011, 18:47:11)
[PyPy 1.7.0 with GCC 4.4.3]
$ pypy1.6 -V
Python 2.7.1 (d8ac7d23d3ec, Aug 17 2011, 11:51:19)
[PyPy 1.6.0 with GCC 4.4.3]

----------
files: smallpt.py
messages: 3450
nosy: guibou, pypy-issue
priority: performance bug
status: unread
title: Python 1.7 slower on home maid path tracing than 1.6

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

From tracker at bugs.pypy.org  Mon Nov 21 15:33:10 2011
From: tracker at bugs.pypy.org (Peter)
Date: Mon, 21 Nov 2011 14:33:10 +0000
Subject: [pypy-issue] [issue933] AttributeError: 'pyexpat.XMLParserType'
	object has no	attribute 'StartElementHandler'
In-Reply-To: <1321885990.73.0.293647559366.issue933@bugs.pypy.org>
Message-ID: <1321885990.73.0.293647559366.issue933@bugs.pypy.org>


New submission from Peter <p.j.a.cock at googlemail.com>:

I didn't report this earlier as our code was blocked by Issue 914, which is now
fixed in PyPy 1.7.

Expected behaviour to match C Python:


$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
>>> p = expat.ParserCreate(namespace_separator=" ")
>>> p.StartElementHandler
>>> p.StartElementHandler is None
True
>>> quit()

Actual behaviour of PyPy 1.6 (same as PyPy 1.7):

$ pypy1.6
Python 2.7.1 (dcae7aed462b, Aug 17 2011, 09:46:15)
[PyPy 1.6.0 with GCC 4.0.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``Bureaucrats build academic
empires which churn out meaningless solutions to irrelevant problems.''
>>>> from xml.parsers import expat
>>>> p = expat.ParserCreate(namespace_separator=" ")
>>>> p.StartElementHandler is None
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'pyexpat.XMLParserType' object has no attribute
'StartElementHandler'
>>>> quit()

Actual behaviour of PyPy 1.6 (same as PyPy 1.6):


$ pypy1.7
Python 2.7.1 (7773f8fc4223, Nov 18 2011, 22:15:49)
[PyPy 1.7.0 with GCC 4.0.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``"there are days on which you look
around and nothing should have ever worked" (fijal)''
>>>> from xml.parsers import expat
>>>> p = expat.ParserCreate(namespace_separator=" ")
>>>> p.StartElementHandler is None
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'pyexpat.XMLParserType' object has no attribute
'StartElementHandler'
>>>> quit()


See also: http://docs.python.org/library/pyexpat.html

Note the short example given there works fine under PyPy 1.6 and 1.7, namely:

import xml.parsers.expat
# 3 handler functions
def start_element(name, attrs):
    print 'Start element:', name, attrs
def end_element(name):
    print 'End element:', name
def char_data(data):
    print 'Character data:', repr(data)
p = xml.parsers.expat.ParserCreate()
p.StartElementHandler = start_element
p.EndElementHandler = end_element
p.CharacterDataHandler = char_data
p.Parse("""<?xml version="1.0"?>
<parent id="top"><child1 name="paul">Text goes here</child1>
<child2 name="fred">More text</child2>
</parent>""", 1)

It would appear that this is a simple initialisation issue (C Python creates the
attribute and sets it to None, PyPy does not).

----------
messages: 3451
nosy: peterjc, pypy-issue
priority: bug
release: 1.7
status: unread
title: AttributeError: 'pyexpat.XMLParserType' object has no attribute 'StartElementHandler'

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

From tracker at bugs.pypy.org  Mon Nov 21 19:16:39 2011
From: tracker at bugs.pypy.org (ita)
Date: Mon, 21 Nov 2011 18:16:39 +0000
Subject: [pypy-issue] [issue934] subprocess hangs in 1.7 (but not in 1.6 or
	1.5)
In-Reply-To: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>
Message-ID: <1321899399.17.0.478342410189.issue934@bugs.pypy.org>


New submission from ita <tnagy1024 at gmail.com>:

The problem is new in 1.7, after launching processes pypy can just hang. Try the
testcase in attachment

It is probably unrelated but it reminds me of the following in 2.7.2:
http://bugs.python.org/issue13156

----------
files: hang-pypy-17.tar.bz2
messages: 3452
nosy: ita, pypy-issue
priority: bug
status: unread
title: subprocess hangs in 1.7 (but not in 1.6 or 1.5)

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

From tracker at bugs.pypy.org  Mon Nov 21 20:10:16 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 21 Nov 2011 19:10:16 +0000
Subject: [pypy-issue] [issue933] AttributeError: 'pyexpat.XMLParserType'
	object has no	attribute 'StartElementHandler'
In-Reply-To: <1321885990.73.0.293647559366.issue933@bugs.pypy.org>
Message-ID: <1321902616.11.0.566813124163.issue933@bugs.pypy.org>


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

Ah, it seems to be that W_XMLParserType has a __setattr__ method but no
__getattr__, which would mean that you can set attributes like
StartElementHandler but never read them (even after setting it to a non-None value).

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

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

From tracker at bugs.pypy.org  Mon Nov 21 20:23:04 2011
From: tracker at bugs.pypy.org (Joshua Root)
Date: Mon, 21 Nov 2011 19:23:04 +0000
Subject: [pypy-issue] [issue935] Possible typing error in micronumpy
In-Reply-To: <1321903384.62.0.998136571406.issue935@bugs.pypy.org>
Message-ID: <1321903384.62.0.998136571406.issue935@bugs.pypy.org>


New submission from Joshua Root <jmr at macports.org>:

Platform: OS X 10.6.8 x86_64, Xcode 3.2.6

See attached traceback that occurred during translation. I was going to chalk 
this up to gcc-4.2 still being unsupported, but I was advised by arigato on IRC 
that it doesn't look like a gcc version issue and I should file a bug. It did 
work when I tried again using gcc-4.0.

----------
files: pypy-traceback.txt
messages: 3454
nosy: jmr, pypy-issue
priority: bug
release: 1.7
status: unread
title: Possible typing error in micronumpy

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue935>
________________________________________
-------------- next part --------------
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "translate.py", line 308, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/translator/driver.py", line 809, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = self._maybe_skip())
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/translator/tool/taskengine.py", line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/translator/driver.py", line 286, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/translator/driver.py", line 323, in task_annotate
[translation:ERROR]     s = annotator.build_types(self.entry_point, self.inputtypes)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py", line 103, in build_types
[translation:ERROR]     return self.build_graph_types(flowgraph, inputcells, complete_now=complete_now)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py", line 194, in build_graph_types
[translation:ERROR]     self.complete()
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py", line 250, in complete
[translation:ERROR]     self.processblock(graph, block)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py", line 448, in processblock
[translation:ERROR]     self.flowin(graph, block)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py", line 508, in flowin
[translation:ERROR]     self.consider_op(block.operations[i])
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py", line 710, in consider_op
[translation:ERROR]     raise_nicer_exception(op, str(graph))
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py", line 707, in consider_op
[translation:ERROR]     resultcell = consider_meth(*argcells)
[translation:ERROR]    File "<4186-codegen /opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/annrpython.py:745>", line 3, in consider_op_simple_call
[translation:ERROR]     return arg.simple_call(*args)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/unaryop.py", line 175, in simple_call
[translation:ERROR]     return obj.call(getbookkeeper().build_args("simple_call", args_s))
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/unaryop.py", line 696, in call
[translation:ERROR]     return bookkeeper.pbc_call(pbc, args)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/bookkeeper.py", line 667, in pbc_call
[translation:ERROR]     results.append(desc.pycall(schedule, args, s_previous_result, op))
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/description.py", line 798, in pycall
[translation:ERROR]     return self.funcdesc.pycall(schedule, args, s_previous_result, op)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/description.py", line 283, in pycall
[translation:ERROR]     result = self.specialize(inputcells, op)
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/description.py", line 275, in specialize
[translation:ERROR]     enforceargs(self, inputcells) # can modify inputcells in-place
[translation:ERROR]    File "/opt/local/var/macports/build/_Users_josh_Coding_dports-dev_svn_dports_lang_pypy/pypy/work/pypy-pypy-release-1.7/pypy/annotation/signature.py", line 135, in __call__
[translation:ERROR]     s_input))
[translation:ERROR]  Exception': <FunctionDesc for <function box at 0x15ac91410>> argument 2:
[translation:ERROR] expected SomeInteger(knowntype=r_uint, nonneg=True, unsigned=True),
[translation:ERROR]      got SomeFloat()
[translation:ERROR] 	.. v120 = simple_call(v118, v119)
[translation:ERROR] 	.. '(pypy.module.micronumpy.interp_support:10)fromstring'
[translation:ERROR] Processing block:
[translation:ERROR]  block at 169 is a <class 'pypy.objspace.flow.flowcontext.SpamBlock'>
[translation:ERROR]  in (pypy.module.micronumpy.interp_support:10)fromstring
[translation:ERROR]  containing the following operations:
[translation:ERROR]        v121 = getslice(s_0, start_0, end_0)
[translation:ERROR]        v122 = getattr(a_0, ('dtype'))
[translation:ERROR]        v123 = getattr(v122, ('setitem'))
[translation:ERROR]        v124 = getattr(a_0, ('storage'))
[translation:ERROR]        v118 = getattr(dtype_0, ('box'))
[translation:ERROR]        v119 = simple_call((function runpack), ('d'), v121)
[translation:ERROR]        v120 = simple_call(v118, v119)
[translation:ERROR]        v125 = simple_call(v123, v124, i_0, v120)
[translation:ERROR]        v126 = inplace_add(i_0, (1))
[translation:ERROR]        v127 = inplace_add(start_0, (8))
[translation:ERROR]        v128 = inplace_add(end_0, (8))
[translation:ERROR]  --end--
[translation] batch mode, not calling interactive helpers

From tracker at bugs.pypy.org  Mon Nov 21 20:42:18 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 21 Nov 2011 19:42:18 +0000
Subject: [pypy-issue] [issue933] AttributeError: 'pyexpat.XMLParserType'
	object has no	attribute 'StartElementHandler'
In-Reply-To: <1321885990.73.0.293647559366.issue933@bugs.pypy.org>
Message-ID: <1321904538.07.0.852661049028.issue933@bugs.pypy.org>


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

Fixed in ddbc82ef4d8f.

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

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

From tracker at bugs.pypy.org  Tue Nov 22 05:48:11 2011
From: tracker at bugs.pypy.org (Justin Peel)
Date: Tue, 22 Nov 2011 04:48:11 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than
	CPython 2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1321937291.82.0.980539919007.issue927@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

I think that a small card ref size for sets/dicts would help (I'll just talk 
about dicts from now on, but it applies to sets). However, I also discovered 
something that may be really slowing this down. Currently, whenever anything is 
put into a dict, the object is considered to be young without checking whether 
it is. There is code to do the checking, but there is a note saying that it was 
slower which is why it isn't used. Please correct me if I am wrong here.

Considering all inserted objects as young is fine for the example in this issue 
until the dict needs to be resized. When a dict is resized, every item from the 
old array is inserted into the new, larger array and considered to be young for 
the purpose of card marking. Since the card ref size is currently 128 and there 
should the array will have 1/3 of its items filled after resizing, all of the 
card refs will be set when a resizing is done.

I think actually checking if items are young when reinserting during the 
resizing process combined with a smaller card ref size could help a lot here.

By the way, lists are fine on the resizing front from what I see because direct 
memory copies are done for everything including the card refs. The difference 
with dicts is that the items are inserted pseudo-randomly so card refs can't be 
copied.

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

From tracker at bugs.pypy.org  Wed Nov 23 14:58:00 2011
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Wed, 23 Nov 2011 13:58:00 +0000
Subject: [pypy-issue] [issue927] Task takes more time on nightly than
	CPython 2.7
In-Reply-To: <1320950688.87.0.253474601819.issue927@bugs.pypy.org>
Message-ID: <1322056680.4.0.812198207108.issue927@bugs.pypy.org>


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

FWIW, on the set-strategies branch this also becomes quite a bit faster, so
maybe in combination with the improvements to the GC infrastructure we can beat
CPython here.

----------
nosy: +cfbolz

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

From tracker at bugs.pypy.org  Wed Nov 23 20:51:07 2011
From: tracker at bugs.pypy.org (David Naylor)
Date: Wed, 23 Nov 2011 19:51:07 +0000
Subject: [pypy-issue] [issue929] Improve platform support for FreeBSD
In-Reply-To: <1321814038.7.0.494588194942.issue929@bugs.pypy.org>
Message-ID: <1322077867.24.0.175431081529.issue929@bugs.pypy.org>


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

Another FreeBSD patch.

Do not include `dl' when checking for libgc (boehm).

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

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

From tracker at bugs.pypy.org  Wed Nov 23 20:56:07 2011
From: tracker at bugs.pypy.org (David Naylor)
Date: Wed, 23 Nov 2011 19:56:07 +0000
Subject: [pypy-issue] [issue936] Properly preprocess ctypes checks
In-Reply-To: <1322078167.34.0.459524738578.issue936@bugs.pypy.org>
Message-ID: <1322078167.34.0.459524738578.issue936@bugs.pypy.org>


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

Properly preprocess the include and library directories for the ctypes checks.

This fixes detection of libexpat under FreeBSD (since libexpat is not a system 
library and resides under LOCALBASE, which is not in the compilers default search 
path).

----------
messages: 3459
nosy: DragonSA, pypy-issue
priority: bug
release: 1.7
status: unread
title: Properly preprocess ctypes checks

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

From tracker at bugs.pypy.org  Wed Nov 23 21:25:55 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 23 Nov 2011 20:25:55 +0000
Subject: [pypy-issue] [issue936] Properly preprocess ctypes checks
In-Reply-To: <1322078167.34.0.459524738578.issue936@bugs.pypy.org>
Message-ID: <1322079955.39.0.360897169023.issue936@bugs.pypy.org>


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

What do you mean by "Properly preprocess"?

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

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

From tracker at bugs.pypy.org  Wed Nov 23 21:37:58 2011
From: tracker at bugs.pypy.org (David Naylor)
Date: Wed, 23 Nov 2011 20:37:58 +0000
Subject: [pypy-issue] [issue936] Properly preprocess ctypes checks
In-Reply-To: <1322078167.34.0.459524738578.issue936@bugs.pypy.org>
Message-ID: <1322080678.77.0.496915100454.issue936@bugs.pypy.org>


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

Pass eci.include_dirs and eci.library_dirs through 
platform.preprocess_include_dirs and platform.preprocess_library_dirs 
respectively.  

It looks like my patch didn't make it.  Attaching it now, I think this bug 
report makes much more sense with it ;-)

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

From tracker at bugs.pypy.org  Wed Nov 23 21:52:26 2011
From: tracker at bugs.pypy.org (Jared Sutton)
Date: Wed, 23 Nov 2011 20:52:26 +0000
Subject: [pypy-issue] [issue937] No error if "from __future__" imports are
	not at beginning	of file
In-Reply-To: <1322081546.71.0.221743283256.issue937@bugs.pypy.org>
Message-ID: <1322081546.71.0.221743283256.issue937@bugs.pypy.org>


New submission from Jared Sutton <jpsutton at gmail.com>:

If a "from __future__ import <some_feature>" line is added somewhere other than 
the top of the file, pypy does not report this as a problem.  It also doesn't 
seem to actually do the import.

Here's a test application showing the problem:

### BEGIN TEST PROGRAM
#!/usr/bin/env python2.7

import sys
from __future__ import print_function

def stderr (someString = ""):
  print(someString, file=sys.stderr)

stderr("test")
### END TEST PROGRAM

If the test program is executed using CPython 2.7, the following is output:

[ jsutton at jsutton-t61 ~/projects ]$ python2.7 test.py 
  File "test.py", line 4
    from __future__ import print_function
SyntaxError: from __future__ imports must occur at the beginning of the file

If the test program is executed with pypy 1.7, the following is output:

[ jsutton at jsutton-t61 ~/projects ]$ pypy test.py
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "test.py", line 7
    print(someString, file=sys.stderr)
                         ^
SyntaxError: invalid syntax

----------
messages: 3462
nosy: jpsutton, pypy-issue
priority: bug
status: unread
title: No error if "from __future__" imports are not at beginning of file

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

From tracker at bugs.pypy.org  Wed Nov 23 23:27:23 2011
From: tracker at bugs.pypy.org (Benjamin Peterson)
Date: Wed, 23 Nov 2011 22:27:23 +0000
Subject: [pypy-issue] [issue937] No error if "from __future__" imports are
	not at beginning	of file
In-Reply-To: <1322081546.71.0.221743283256.issue937@bugs.pypy.org>
Message-ID: <1322087243.93.0.813253407201.issue937@bugs.pypy.org>


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

This is an implementation detail. If you remove the invalid syntax, then PyPy
will report the future import is too far down. It's simply that PyPy sees the
invalid syntax first.

----------
nosy: +benjamin
status: unread -> wontfix

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

From tracker at bugs.pypy.org  Thu Nov 24 10:51:47 2011
From: tracker at bugs.pypy.org (Jonas H.)
Date: Thu, 24 Nov 2011 09:51:47 +0000
Subject: [pypy-issue] [issue733] bz2 decompression is very slow
In-Reply-To: <1306785194.2.0.717331507866.issue733@bugs.pypy.org>
Message-ID: <1322128307.41.0.613633497603.issue733@bugs.pypy.org>


Jonas H. <jonas at lophus.org> added the comment:

Performance of GZip and BZip2 has been improved dramatically in PyPy 1.7 it seems -- 
it's now almost proportional to CPython's performance (PyPy taking twice at long).

I consider this bug fixed but maybe you may want to keep it open as a reminder for 
further optimizations?

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

From tracker at bugs.pypy.org  Thu Nov 24 17:34:32 2011
From: tracker at bugs.pypy.org (Christoph Egger)
Date: Thu, 24 Nov 2011 16:34:32 +0000
Subject: [pypy-issue] [issue938] pypy 5 times smaller than cpython in
	smallish script
In-Reply-To: <1322152472.76.0.775448873956.issue938@bugs.pypy.org>
Message-ID: <1322152472.76.0.775448873956.issue938@bugs.pypy.org>


New submission from Christoph Egger <siccegge+pypy at cs.fau.de>:

rfs2model from
git clone http://vamos.informatik.uni-erlangen.de/git/vamos/
on http://vamos.cs.fau.de/~siccegge/arm.rsf

takes here (2 * XEON E5620  @ 2.40GHz Quad Core) 5 times as long as cpython
(18sec for cpython 100 for pypy)

----------
messages: 3465
nosy: pypy-issue, siccegge
priority: performance bug
status: unread
title: pypy 5 times smaller than cpython in smallish script

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

From tracker at bugs.pypy.org  Thu Nov 24 17:56:54 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Thu, 24 Nov 2011 16:56:54 +0000
Subject: [pypy-issue] [issue938] pypy 5 times smaller than cpython in
	smallish script
In-Reply-To: <1322152472.76.0.775448873956.issue938@bugs.pypy.org>
Message-ID: <1322153814.71.0.656361593213.issue938@bugs.pypy.org>


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

The problem is you are using += to concatinate strings in a loop.  CPython has 
obscure hacks to make this efficient, but on PyPy this has O(n**2) behavior.  
This patch http://paste.pocoo.org/show/512426/ significantly speeds it up for me 
(it's 5x faster than CPython on my machine).  I'm marking this as wontfix, as 
it's not strictly speaking a bug, however I'm thinking about ways we can 
automatically do this transformation.

----------
nosy: +agaynor
status: unread -> wontfix

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

From tracker at bugs.pypy.org  Fri Nov 25 06:42:11 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 25 Nov 2011 05:42:11 +0000
Subject: [pypy-issue] [issue939] Upgrade CPython stdlib to 2.7.2
In-Reply-To: <1322199731.96.0.845881924167.issue939@bugs.pypy.org>
Message-ID: <1322199731.96.0.845881924167.issue939@bugs.pypy.org>


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

According to Raymond Hettinger 2.7.2 contains a lot of bugfixes over 2.7.1, we 
should upgrade.

----------
messages: 3467
nosy: fijal, pypy-issue
priority: feature
status: unread
title: Upgrade CPython stdlib to 2.7.2

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

From tracker at bugs.pypy.org  Fri Nov 25 17:29:24 2011
From: tracker at bugs.pypy.org (Serhat Sevki Dincer)
Date: Fri, 25 Nov 2011 16:29:24 +0000
Subject: [pypy-issue] [issue940] Comparison with native application & cpython
In-Reply-To: <1322238564.73.0.183639917325.issue940@bugs.pypy.org>
Message-ID: <1322238564.73.0.183639917325.issue940@bugs.pypy.org>


New submission from Serhat Sevki Dincer <jfcgauss at gmail.com>:

I wrote a tiny grep with multi-line match support, and compared its speed under 
pypy 1.7 with grep and CPython 2.7.1 (on ubuntu 11.04 laptop).
No special algorithm/implementation is employed; it is bare re module.

input: Plone 4.1.2 eggs directory, size 286mb, possible processed input size is 
about 75mb, processed 3958 files total

commands:

time mgrp -lcrN '\.py$' for .
takes 1.95s

time python2.7 /usr/local/bin/mgrp -lcrN '\.py$' for .
takes 1.45s

time grep -lcr --color=none --include='*.py' for .
takes 0.6s

Is the input too small to see the benefits of pypy?

----------
files: mgrp
messages: 3468
nosy: pypy-issue, serhat
priority: performance bug
release: 1.7
status: unread
title: Comparison with native application & cpython

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

From tracker at bugs.pypy.org  Sat Nov 26 11:12:34 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 26 Nov 2011 10:12:34 +0000
Subject: [pypy-issue] [issue940] Comparison with native application & cpython
In-Reply-To: <1322238564.73.0.183639917325.issue940@bugs.pypy.org>
Message-ID: <1322302354.77.0.560778017302.issue940@bugs.pypy.org>


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

Actually, yes, it seems to be the case that it is not enough time for a complete
warm-up.  If I run it on a larger collection of files, it takes 2.8 seconds
under python2.7 and 2.2 seconds under pypy (after all files have been loaded in
the cache, of course, so without any actual hard drive access time).  On an even
larger collection: 16.3s for python2.7 versus 9.6s for pypy1.7.

Your script could go in our future collection of benchmarks that are designed
more precisely to measure (and improve) the warm-up time.  As you see, we didn't
put too much effort in that so far.

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

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

From tracker at bugs.pypy.org  Sat Nov 26 12:25:28 2011
From: tracker at bugs.pypy.org (Serhat Sevki Dincer)
Date: Sat, 26 Nov 2011 11:25:28 +0000
Subject: [pypy-issue] [issue940] Comparison with native application & cpython
In-Reply-To: <1322238564.73.0.183639917325.issue940@bugs.pypy.org>
Message-ID: <1322306728.12.0.948769284404.issue940@bugs.pypy.org>


Serhat Sevki Dincer <jfcgauss at gmail.com> added the comment:

That's good news. I improved the script a little bit, and fixed a bug. Please use 
the new version in the benchmarks.
Thanks..

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

From tracker at bugs.pypy.org  Sat Nov 26 19:57:49 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 26 Nov 2011 18:57:49 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322333869.63.0.247266940646.issue941@bugs.pypy.org>


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

Oops, this is clearly a bug.

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

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

From tracker at bugs.pypy.org  Sat Nov 26 19:59:36 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 26 Nov 2011 18:59:36 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322333976.64.0.749414917146.issue941@bugs.pypy.org>


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

For what is worth (not related to the fact that this *is* a bug), probably 
executing this in a loop would yield better performance on pypy. Just saying

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

From tracker at bugs.pypy.org  Sat Nov 26 20:11:50 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 19:11:50 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322334710.62.0.654409864015.issue941@bugs.pypy.org>


Anton <litvinenkoas at rambler.ru> added the comment:

2fijal: I'd like to execute this in a loop if I knew the general "formula" for
each mz0[i][j]. But I don't know it, the formulae are generated by another piece
of code at the runtime according to the results of config parsing. Or I've
understood you wrongly? Anyway, thanks a lot!

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

From tracker at bugs.pypy.org  Sat Nov 26 20:16:50 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 26 Nov 2011 19:16:50 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322335010.2.0.790803481622.issue941@bugs.pypy.org>


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

Then what I would do is to generate (from config) an array of indexes and 
formulas and then apply those in a loop. The generated input would look like 
this: http://paste.pocoo.org/show/513272/ and the code roughly like this: 
http://paste.pocoo.org/show/513273/

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

From tracker at bugs.pypy.org  Sat Nov 26 20:25:11 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 19:25:11 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322335511.68.0.978148367721.issue941@bugs.pypy.org>


Anton <litvinenkoas at rambler.ru> added the comment:

Eval()+loop is faster then instruction set??? Surprising info.

I suppose this idea also will help me to simplify some another actions and
optimisations inside my code. Thanks a lot, I'll try it!

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

From tracker at bugs.pypy.org  Sat Nov 26 20:41:03 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 26 Nov 2011 19:41:03 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322336463.21.0.152294244264.issue941@bugs.pypy.org>


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

Looking at your case, the eval is looped only over a relatively short list of 
elements and eval is not really that much worse than normal code for the JIT. You 
can still precompile this part. However looping over the second part makes it 
much faster. Generally unrolling loops on your own is almost never a good idea in 
pypy.

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

From tracker at bugs.pypy.org  Sat Nov 26 20:45:32 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 26 Nov 2011 19:45:32 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322336732.48.0.979251310053.issue941@bugs.pypy.org>


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

Thanks!  Should be at least fixed by 299a1d66e8a2 and following clean-ups.  (But
indeed, a long non-looping piece of code run just once is never going to be
accelerated by the JIT anyway.)

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

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

From tracker at bugs.pypy.org  Sat Nov 26 20:55:40 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 19:55:40 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322337340.46.0.624400331652.issue941@bugs.pypy.org>


Anton <litvinenkoas at rambler.ru> added the comment:

fijal: should I manually look for equal formulae to prevent them from being
computed twice or more?

arigo: just started to build mercurial snapshot.

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

From tracker at bugs.pypy.org  Sat Nov 26 20:56:47 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 26 Nov 2011 19:56:47 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322337407.83.0.741331891903.issue941@bugs.pypy.org>


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

fijal: should I manually look for equal formulae to prevent them from being
computed twice or more?

sounds like a sane optimization for me :) it would save a lot either way. you 
don't have to do it manually, you can automate it.

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

From tracker at bugs.pypy.org  Sat Nov 26 21:06:34 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 20:06:34 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322337994.02.0.430554507748.issue941@bugs.pypy.org>


Anton <litvinenkoas at rambler.ru> added the comment:

It definitely is, especially taking into account the multiple code usage after
one generation. I appreciate your advices!

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

From tracker at bugs.pypy.org  Sat Nov 26 22:24:14 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 21:24:14 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322342654.94.0.466670256794.issue941@bugs.pypy.org>


Anton <litvinenkoas at rambler.ru> added the comment:

arigo: mercurial snapshot still fails.

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

From tracker at bugs.pypy.org  Sat Nov 26 23:06:20 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 26 Nov 2011 22:06:20 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322345180.56.0.286482375216.issue941@bugs.pypy.org>


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

Scriptor: works for me.

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

From tracker at bugs.pypy.org  Sat Nov 26 23:27:13 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 22:27:13 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322346433.15.0.27004984128.issue941@bugs.pypy.org>


Anton <litvinenkoas at rambler.ru> added the comment:

Do I have to use tip (17fd3198ef36) or something other?

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

From tracker at bugs.pypy.org  Sat Nov 26 23:29:00 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 26 Nov 2011 22:29:00 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322346540.1.0.654779605907.issue941@bugs.pypy.org>


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

Yes, 17fd3198ef36 is the only revision recent enough to contain the relevant
changesets (299a1d66e8a2 to 17fd3198ef36).

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

From tracker at bugs.pypy.org  Sat Nov 26 23:30:19 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 22:30:19 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322346619.32.0.959129337524.issue941@bugs.pypy.org>


Anton <litvinenkoas at rambler.ru> added the comment:

Oh, I'm sorry, I've just made a mistake while symlink creation. It works. Thanks
a lot!

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

From tracker at bugs.pypy.org  Sun Nov 27 00:27:41 2011
From: tracker at bugs.pypy.org (Michael Schurter)
Date: Sat, 26 Nov 2011 23:27:41 +0000
Subject: [pypy-issue] [issue942] CPython 2.7 faster than PyPy 1.7 in
	select/socket/ctypes	script
In-Reply-To: <1322350061.82.0.356914859849.issue942@bugs.pypy.org>
Message-ID: <1322350061.82.0.356914859849.issue942@bugs.pypy.org>


New submission from Michael Schurter <m at schmichael.com>:

(Only works in Linux... may work in OSX with the socket type changed.)

Running "punish_logd.py 1 25000000 log.sock 0" returns the following when 
running simplelogd.py with Python vs. PyPy:

CPython 2.7: Sent 2500000 messages in 38 seconds (64318.894760 per second)
PyPy 1.7:    Sent 2500000 messages in 48 seconds (51576.415662 per second)

I removed the output file between runs.

simplelogd.py requires mmstats master to be installed:

https://github.com/schmichael/mmstats/commit/7c27381c32dadf79a47a9ef20795a66e23b
0e910

With mmstats installed you can run "pollstats -p simplelogd. messages 
/tmp/mmstats-*" to get messages per second output.

----------
files: simplelogd.py
messages: 3487
nosy: pypy-issue, schmichael
priority: performance bug
release: 1.7
status: unread
title: CPython 2.7 faster than PyPy 1.7 in select/socket/ctypes script

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

From tracker at bugs.pypy.org  Sun Nov 27 00:29:14 2011
From: tracker at bugs.pypy.org (Michael Schurter)
Date: Sat, 26 Nov 2011 23:29:14 +0000
Subject: [pypy-issue] [issue942] CPython 2.7 faster than PyPy 1.7 in
	select/socket/ctypes	script
In-Reply-To: <1322350061.82.0.356914859849.issue942@bugs.pypy.org>
Message-ID: <1322350154.17.0.116198674087.issue942@bugs.pypy.org>


Michael Schurter <m at schmichael.com> added the comment:

Attach simplelogd.py's config file (pass the filename to simplelogd.py as the 
only command line argument).

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

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

From tracker at bugs.pypy.org  Sun Nov 27 00:31:39 2011
From: tracker at bugs.pypy.org (Michael Schurter)
Date: Sat, 26 Nov 2011 23:31:39 +0000
Subject: [pypy-issue] [issue942] CPython 2.7 faster than PyPy 1.7 in
	select/socket/ctypes	script
In-Reply-To: <1322350061.82.0.356914859849.issue942@bugs.pypy.org>
Message-ID: <1322350299.92.0.610740058243.issue942@bugs.pypy.org>


Michael Schurter <m at schmichael.com> added the comment:

Attach script to test simplelogd throughput. simplelogd appears to be the 
bottleneck, so I always run this with CPython 2.7 and 1 concurrency (my test 
machine only has 2 cores anyway).

Run with something like:

punish_logd.py 1 25000000 log.sock 0

(1 concurrency, 25MM messages, location of log socket, last arg is currently 
ignored)

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

From tracker at bugs.pypy.org  Mon Nov 28 07:35:51 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 28 Nov 2011 06:35:51 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322462151.93.0.974758028903.issue941@bugs.pypy.org>


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

closing then

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

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

From tracker at bugs.pypy.org  Mon Nov 28 07:37:07 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 28 Nov 2011 06:37:07 +0000
Subject: [pypy-issue] [issue935] Possible typing error in micronumpy
In-Reply-To: <1321903384.62.0.998136571406.issue935@bugs.pypy.org>
Message-ID: <1322462227.91.0.670271000983.issue935@bugs.pypy.org>


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

Hey, this should be fixed by now, can you comment?

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

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

From tracker at bugs.pypy.org  Mon Nov 28 07:37:34 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 28 Nov 2011 06:37:34 +0000
Subject: [pypy-issue] [issue919] implement multi-dimension arrays in
	micronumpy
In-Reply-To: <1319322811.27.0.133989194674.issue919@bugs.pypy.org>
Message-ID: <1322462254.54.0.393027735213.issue919@bugs.pypy.org>


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

Done :)

----------
nosy: +fijal
status: chatting -> resolved

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

From tracker at bugs.pypy.org  Mon Nov 28 07:39:40 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 28 Nov 2011 06:39:40 +0000
Subject: [pypy-issue] [issue846] TypeError: type 'basestring' is not an
	acceptable base	class
In-Reply-To: <1314298597.06.0.673686395864.issue846@bugs.pypy.org>
Message-ID: <1322462380.31.0.720299719783.issue846@bugs.pypy.org>


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

Since the upstream patch has been applied, I think it's ok to close this as 
wontfix. Anyone who feel we should support this obscure usecase, please reopen it 
and we can discuss some more.

----------
nosy: +fijal
status: chatting -> wontfix

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

From tracker at bugs.pypy.org  Mon Nov 28 07:42:15 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 28 Nov 2011 06:42:15 +0000
Subject: [pypy-issue] [issue908] Django tests failing
In-Reply-To: <1318609403.25.0.782175954517.issue908@bugs.pypy.org>
Message-ID: <1322462535.16.0.257747865091.issue908@bugs.pypy.org>


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

Apparently fixed.

----------
nosy: +fijal
status: chatting -> resolved

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

From tracker at bugs.pypy.org  Sat Nov 26 19:56:22 2011
From: tracker at bugs.pypy.org (Anton)
Date: Sat, 26 Nov 2011 18:56:22 +0000
Subject: [pypy-issue] [issue941] 15000+ matrix filling instructions kill
	pypy-c
In-Reply-To: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>
Message-ID: <1322333782.17.0.340381177512.issue941@bugs.pypy.org>


New submission from Anton <litvinenkoas at rambler.ru>:

The attached script (mostly generated by another one, but is not artificial,
such situations really occur in my program) causes pypy 1.5--1.7 (built from
release sources on Fedora 12) to die with the following error:

[anton at anton heavy]$ ~/build/pypy-1.6/pypy/translator/goal/pypy-c
pypy_large_failure.py 
RPython traceback:
  File "module_pypyjit_interp_jit.c", line 590, in jump_absolute__AccessDirect_None
  File "jit_metainterp_warmstate.c", line 602, in maybe_compile_and_run__star_5
  File "jit_metainterp_pyjitpl.c", line 2506, in
compile_and_run_once___pypy_jit_metainterp_jitdr
  File "jit_metainterp_pyjitpl.c", line 4274, in MetaInterp__compile_and_run_once
  File "jit_metainterp_pyjitpl.c", line 7042, in MetaInterp_interpret
  File "jit_metainterp_pyjitpl.c", line 9519, in MetaInterp__interpret
  File "jit_metainterp_pyjitpl.c", line 14272, in MIFrame_run_one_step
  File "jit_metainterp_pyjitpl.c", line 54706, in MIFrame_opimpl_jit_merge_point
  File "jit_metainterp_pyjitpl.c", line 79876, in MetaInterp_reached_loop_header
  File "jit_metainterp_pyjitpl.c", line 96559, in MetaInterp_compile
  File "jit_metainterp_compile.c", line 11356, in compile_new_loop
  File "jit_metainterp_optimize.c", line 140, in optimize_loop
  File "jit_metainterp_optimize.c", line 446, in _optimize_loop
  File "jit_metainterp_optimizeopt_unroll.c", line 6057, in
UnrollOptimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_optimizer.c", line 3365, in
Optimizer_propagate_all_forward
  File "jit_metainterp_optimizeopt_intbounds.c", line 279, in
OptIntBounds_optimize_GUARD_TRUE
  File "jit_metainterp_optimizeopt_rewrite.c", line 2975, in
OptRewrite_optimize_guard
  File "jit_metainterp_optimizeopt_optimizer.c", line 9643, in
Optimizer_optimize_default
  File "jit_metainterp_optimizeopt_optimizer.c", line 9383, in
Optimizer__emit_operation
  File "jit_metainterp_optimizeopt_optimizer.c", line 13006, in
Optimizer_store_final_boxes_in_guard
  File "jit_metainterp_resume.c", line 13422, in ResumeDataVirtualAdder_finish
  File "jit_metainterp_resume.c", line 14651, in ResumeDataLoopMemo_number
~~~ Crash in JIT! <ValueError object at 0x8c12d7c>
Aborted

CPython and CPython+psyco work fine. The matrices with lower size are also built
successfully.

----------
files: pypy_large_failure.py
messages: 3471
nosy: Scriptor, pypy-issue
priority: bug
status: unread
title: 15000+ matrix filling instructions kill pypy-c

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

From tracker at bugs.pypy.org  Mon Nov 28 15:51:54 2011
From: tracker at bugs.pypy.org (Liu Zhenhai)
Date: Mon, 28 Nov 2011 14:51:54 +0000
Subject: [pypy-issue] [issue943] pypy 1.7 the pow operation of numpypy's
	array is not	correct
In-Reply-To: <1322491914.28.0.433326711974.issue943@bugs.pypy.org>
Message-ID: <1322491914.28.0.433326711974.issue943@bugs.pypy.org>


New submission from Liu Zhenhai <1989lzhh at gmail.com>:

import numpypy as np
a = np.array([1, 2, 3])
print a**2  #the result is [0, 0, 0] under Windows

----------
files: test.py
messages: 3495
nosy: 1989lzhh, pypy-issue
priority: bug
status: unread
title: pypy 1.7 the pow operation of numpypy's array is not correct

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue943>
________________________________________
-------------- next part --------------
import numpypy as np
a = np.array([1, 2, 3])
print a**2  #the result is [0, 0, 0] under Windows

From tracker at bugs.pypy.org  Mon Nov 28 16:28:11 2011
From: tracker at bugs.pypy.org (Joshua Root)
Date: Mon, 28 Nov 2011 15:28:11 +0000
Subject: [pypy-issue] [issue935] Possible typing error in micronumpy
In-Reply-To: <1321903384.62.0.998136571406.issue935@bugs.pypy.org>
Message-ID: <1322494091.19.0.292578643926.issue935@bugs.pypy.org>


Joshua Root <jmr at macports.org> added the comment:

Hard to tell; translation still fails as of a21d75a378ad but with a different 
error.

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

From tracker at bugs.pypy.org  Mon Nov 28 16:31:58 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 28 Nov 2011 15:31:58 +0000
Subject: [pypy-issue] [issue935] Possible typing error in micronumpy
In-Reply-To: <1321903384.62.0.998136571406.issue935@bugs.pypy.org>
Message-ID: <1322494318.31.0.0507157961754.issue935@bugs.pypy.org>


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

I just broke it. 17ecbcddab11 should translate just fine

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

From tracker at bugs.pypy.org  Mon Nov 28 17:25:31 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 28 Nov 2011 16:25:31 +0000
Subject: [pypy-issue] [issue943] pypy 1.7 the pow operation of numpypy's
	array is not	correct
In-Reply-To: <1322491914.28.0.433326711974.issue943@bugs.pypy.org>
Message-ID: <1322497531.55.0.144452557415.issue943@bugs.pypy.org>


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

Another bug, maybe related:

>>>> numpypy.divide(numpypy.array([-10]),numpypy.array([2]))
array([9223372036854775803], dtype=int64)

This is caused by the decorator "@binop" applied to the function div() in a
mixin class, ArithmeticTypeMixin.  As decorators often do, it ends up with two
functions: impl()->div().  But when the mixin is applied (several times), we
duplicate the impl() function, but of course not the div() function...  So we
end up with only one copy of div(), which gets its arguments generalized to the
"Unsigned" type...

Bivab and me found this because in the disable_merge_different_int_types branch,
annotation cleanly fails instead.

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

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

From tracker at bugs.pypy.org  Mon Nov 28 18:21:55 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Mon, 28 Nov 2011 17:21:55 +0000
Subject: [pypy-issue] [issue943] pypy 1.7 the pow operation of numpypy's
	array is not	correct
In-Reply-To: <1322491914.28.0.433326711974.issue943@bugs.pypy.org>
Message-ID: <1322500915.38.0.217994664391.issue943@bugs.pypy.org>


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

This should be fixed by 6f6b258f307e

----------
nosy: +agaynor

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

From tracker at bugs.pypy.org  Mon Nov 28 19:47:43 2011
From: tracker at bugs.pypy.org (Joshua Root)
Date: Mon, 28 Nov 2011 18:47:43 +0000
Subject: [pypy-issue] [issue935] Possible typing error in micronumpy
In-Reply-To: <1321903384.62.0.998136571406.issue935@bugs.pypy.org>
Message-ID: <1322506063.12.0.819935250952.issue935@bugs.pypy.org>


Joshua Root <jmr at macports.org> added the comment:

Confirmed.

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

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

From tracker at bugs.pypy.org  Tue Nov 29 02:17:32 2011
From: tracker at bugs.pypy.org (Gordon Ball)
Date: Tue, 29 Nov 2011 01:17:32 +0000
Subject: [pypy-issue] [issue944] Magic method exceptions
In-Reply-To: <1322529452.38.0.192436520011.issue944@bugs.pypy.org>
Message-ID: <1322529452.38.0.192436520011.issue944@bugs.pypy.org>


New submission from Gordon Ball <chronitis at gmail.com>:

Magic methods called directly handle exceptions differently to their operator
equivalents, eg

<pypy>
l = []
l += [1] #works
l.__iadd__([1]) #works
l += None #TypeError: unsupported operand type(s) for +: 'list' and 'NoneType'
l.__iadd__(None) #NotImplemented

<cpython>
l += None #TypeError
l.__iadd__(None) #TypeError

Presumably this is happening somewhere in the objectspace when multimethods are
being set up, but I'm afraid I can't work out where. (The cpython behaviour that
both should produce identical exceptions seems correct).

----------
messages: 3501
nosy: chronitis, pypy-issue
priority: bug
release: 1.7
status: unread
title: Magic method exceptions

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

From tracker at bugs.pypy.org  Tue Nov 29 15:28:35 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 29 Nov 2011 14:28:35 +0000
Subject: [pypy-issue] [issue944] Magic method exceptions
In-Reply-To: <1322529452.38.0.192436520011.issue944@bugs.pypy.org>
Message-ID: <1322576915.37.0.042801470779.issue944@bugs.pypy.org>


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

No, Python is completely inconsistent.  For example:

<cpython>
>>> (2).__add__(None)
NotImplemented
>>> [].__add__(None)
TypeError: ...

The internal reason is that lists implement the C slot "sq_concat", whereas ints
implement the C slot "nb_add".  PyPy has no way to express that difference,
because it doesn't have internal slots that are different from the Python
methods.  It's one of the few remaining incompatibility, and has been decreed
acceptable.

Added documentation to cpython_differences.html.

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

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

From tracker at bugs.pypy.org  Tue Nov 29 15:33:00 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 29 Nov 2011 14:33:00 +0000
Subject: [pypy-issue] [issue944] Magic method exceptions
In-Reply-To: <1322529452.38.0.192436520011.issue944@bugs.pypy.org>
Message-ID: <1322577180.18.0.200756101529.issue944@bugs.pypy.org>


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

Ah, to answer your last comment more directly: "both should produce identical
exceptions": no, that's not true, because the (simplified) definition of "a +=
b" is to try first a.__iadd__(b); if that returns NotImplemented, try
"a.__add__(b)"; if that still returns NotImplemented, try "b.__radd__(a)"; and
if that still returns NotImplemented, then it raises a TypeError.  That is why
the internal magic methods are supposed to return NotImplemented rather than
raise TypeError themselves.  For example, (2).__add__(2.5) returns
NotImplemented, but (2.5).__radd__(2) returns 4.5.

It can be regarded as wrong (and certainly a CPython implementation detail) that
occasionally the __add__ method raise TypeError itself directly.

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

From tracker at bugs.pypy.org  Tue Nov 29 16:02:14 2011
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 29 Nov 2011 15:02:14 +0000
Subject: [pypy-issue] [issue943] pypy 1.7 the pow operation of numpypy's
	array is not	correct
In-Reply-To: <1322491914.28.0.433326711974.issue943@bugs.pypy.org>
Message-ID: <1322578934.17.0.802851995965.issue943@bugs.pypy.org>


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

Closing

----------
nosy: +fijal
status: chatting -> resolved

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

From tracker at bugs.pypy.org  Tue Nov 29 16:16:23 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 29 Nov 2011 15:16:23 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322579783.81.0.208997551904.issue907@bugs.pypy.org>


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

c56aac83ffe37ace4ef18aa99a3ee98a5d59ef5b is not RPython ("cannot use id() in
RPython").

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

From tracker at bugs.pypy.org  Tue Nov 29 16:20:36 2011
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Tue, 29 Nov 2011 15:20:36 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322580036.85.0.733115929172.issue907@bugs.pypy.org>


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

Yes, I noticed this was being enforced in RPython a few days back and fixed it here:

  https://github.com/ltratt/converge/commit/6c53d0173932b96d2ed77a601193a0e71bb2b7ea

It's only used to print out addresses, so you can easily remove the line during
testing, in case that patch doesn't apply to whatever branch you're working on.

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

From tracker at bugs.pypy.org  Tue Nov 29 17:11:29 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 29 Nov 2011 16:11:29 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322583089.64.0.901569427328.issue907@bugs.pypy.org>


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

Hum... it seems that "./main-c t" leaks, independently on whether I use -O1 or
-O2.  I even tried using explicitly "-O1 --gc=ref"...  If it doesn't on FreeBSD,
then that's going to be hard to debug :-(

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

From tracker at bugs.pypy.org  Tue Nov 29 17:15:31 2011
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Tue, 29 Nov 2011 16:15:31 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322583331.14.0.153319236601.issue907@bugs.pypy.org>


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

I'm just going to see what happens on a Mac (could take a little while). It used
to have the same behaviour as OpenBSD - I don't know if something's changed.

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

From tracker at bugs.pypy.org  Tue Nov 29 17:21:42 2011
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Tue, 29 Nov 2011 16:21:42 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322583702.08.0.554001719448.issue907@bugs.pypy.org>


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

Yes, you're right - it's leaking under both OS X and OpenBSD now on --opt=1. I'm
fairly sure this didn't happen when I filed the original report, so something
interesting has changed in RPython in the interim.

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

From tracker at bugs.pypy.org  Tue Nov 29 20:42:55 2011
From: tracker at bugs.pypy.org (Dirkjan Ochtman)
Date: Tue, 29 Nov 2011 19:42:55 +0000
Subject: [pypy-issue] [issue945] import shadowing module from __init__.py as
	__main__ fails
In-Reply-To: <1322595775.86.0.801378624842.issue945@bugs.pypy.org>
Message-ID: <1322595775.86.0.801378624842.issue945@bugs.pypy.org>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

I have a package x, like this:

x/__init__.py
x/symbol.py

For stupid reasons, I also use __init__.py as a script (i.e. run it with
__name__ == '__main__'). When I do so, and try to "import symbol", pypy gets me
the symbol module from the stdlib (which I didn't even know existed), whereas
cpython 2.7.2 gets me the symbol module from x.

----------
messages: 3510
nosy: djc, pypy-issue
priority: bug
status: unread
title: import shadowing module from __init__.py as __main__ fails

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

From tracker at bugs.pypy.org  Tue Nov 29 22:27:13 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 29 Nov 2011 21:27:13 +0000
Subject: [pypy-issue] [issue945] import shadowing module from __init__.py as
	__main__ fails
In-Reply-To: <1322595775.86.0.801378624842.issue945@bugs.pypy.org>
Message-ID: <1322602033.59.0.709607154921.issue945@bugs.pypy.org>


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

"symbol" is a builtin module in pypy, and a regular symbol.py file in CPython...

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

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

From tracker at bugs.pypy.org  Wed Nov 30 03:28:00 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 30 Nov 2011 02:28:00 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322620080.69.0.912360295486.issue907@bugs.pypy.org>


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

Fixed:

1) as per irc discussion, it is leaking with --opt=1 because it now (correctly)
uses reference counting instead of boehm if you enable --continuation.  This
means that the references held by a stacklet_destroy()ed piece of stack get
lost.  It's a leak that we cannot really do anything about; I added a warning in
5e4711c2e500.

2) the --opt=2 case was a leak in the shadowstack implementation of
stacklet_destroy().  Fixed in ca55b862ead9.

3) the --opt=jit segfaulted because of code that I wrote some time ago but whose
test was not complete enough.  It was *still* not setting the effectinfo of
stacklet_switch() to EF_RANDOM_EFFECTS.  This caused random bugs across switches
because the JIT assumed the calls to stacklet_switch() could only have some
predicted effects --- notably it could not depend on the content of the global
'stack' list, so it's fine to delay a setarrayitem into the list, right?  Test
added in 36e3174f324f, fixed in the subsequent checkins.

The Converge VM now seems to work, so I'm closing this issue.  Feel free to
reopen if needed.

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

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

From tracker at bugs.pypy.org  Wed Nov 30 11:46:42 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Wed, 30 Nov 2011 10:46:42 +0000
Subject: [pypy-issue] [issue946] timeit-as-CLI does not accept import
In-Reply-To: <1322650002.66.0.623055381737.issue946@bugs.pypy.org>
Message-ID: <1322650002.66.0.623055381737.issue946@bugs.pypy.org>


New submission from Xavier Morel <bugs.pypy.org at masklinn.net>:

> python2.7 --version
Python 2.7.2
> python2.7 -mtimeit -s 'import random' 'random.random()'   
10000000 loops, best of 3: 0.116 usec per loop
> pypy-c --version   
Python 2.7.1 (?, Nov 24 2011, 10:57:50)
[PyPy 1.7.0]
> pypy-c -mtimeit -s 'import random' 'random.random()'          
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "/opt/local/lib/pypy/lib-python/2.7/runpy.py", line 162, in _run_module_as_
    "__main__", fname, loader, pkg_name)
  File "/opt/local/lib/pypy/lib-python/2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/opt/local/lib/pypy/lib-python/2.7/timeit.py", line 328, in <module>
    sys.exit(main())
  File "/opt/local/lib/pypy/lib-python/2.7/timeit.py", line 292, in main
    t = Timer(stmt, setup, timer)
  File "/opt/local/lib/pypy/lib-python/2.7/timeit.py", line 136, in __init__
    code = compile(src, dummy_src_name, "exec")
  File "<timeit-src>", line 3
    import
         ^
SyntaxError: invalid syntax

This precludes the (pretty useful) use as the command-line timeit to see very
basic synthetic performance tests on various library (standard or not) code samples.

----------
messages: 3513
nosy: masklinn, pypy-issue
priority: bug
status: unread
title: timeit-as-CLI does not accept import

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

From tracker at bugs.pypy.org  Wed Nov 30 11:49:49 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 30 Nov 2011 10:49:49 +0000
Subject: [pypy-issue] [issue946] timeit-as-CLI does not accept import
In-Reply-To: <1322650002.66.0.623055381737.issue946@bugs.pypy.org>
Message-ID: <1322650189.95.0.0753799655734.issue946@bugs.pypy.org>


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

Works for me.  Can you explain more?  A priori it looks like the quoting did not
work, and the last line is interpreted as:

    pypy-c -mtimeit -s import random 'random.random()'

instead of

    pypy-c -mtimeit -s 'import random' 'random.random()'

Are you sure pypy-c isn't a script that you wrote, in which you pass all
arguments to the real pypy-c executable forgetting quoting issues?

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

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

From tracker at bugs.pypy.org  Wed Nov 30 12:11:03 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Wed, 30 Nov 2011 11:11:03 +0000
Subject: [pypy-issue] [issue946] timeit-as-CLI does not accept import
In-Reply-To: <1322650002.66.0.623055381737.issue946@bugs.pypy.org>
Message-ID: <1322651463.76.0.746895220265.issue946@bugs.pypy.org>


Xavier Morel <bugs.pypy.org at masklinn.net> added the comment:

> Are you sure pypy-c isn't a script that you wrote

It's the one provided by macports, but it does indeed seem to be a very small 
wrapper on the pypy-provided executable:

> cat $(which pypy-c)
#!/bin/sh
/opt/local/lib/pypy/pypy-c $@

calling `/opt/local/lib/pypy/pypy-c` directly *does* work correctly[0], so 
marking this bug as invalid. Sorry about that.

[0]
> /opt/local/lib/pypy/pypy-c -mtimeit -s 'import random' 'random.random()'
10000000 loops, best of 3: 0.0463 usec per loop

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

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

From tracker at bugs.pypy.org  Wed Nov 30 12:12:29 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 30 Nov 2011 11:12:29 +0000
Subject: [pypy-issue] [issue946] timeit-as-CLI does not accept import
In-Reply-To: <1322650002.66.0.623055381737.issue946@bugs.pypy.org>
Message-ID: <1322651549.17.0.360004830001.issue946@bugs.pypy.org>


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

Macports is buggy, please report it as a bug there.  It should be

    /opt/local/lib/pypy/pypy-c "$@"

or just use a symlink instead of a script.

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

From tracker at bugs.pypy.org  Wed Nov 30 12:12:44 2011
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Wed, 30 Nov 2011 11:12:44 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322651564.39.0.499370108987.issue907@bugs.pypy.org>


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

Agreed, everything now works - thanks! [Weirdly, the -OJIT version of my evil
test case takes about 6 times as long to run as the -O3 version, but that's
something else entirely, and I suppose is an odd interaction between the JIT and
stacklets.]

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

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

From tracker at bugs.pypy.org  Wed Nov 30 12:13:07 2011
From: tracker at bugs.pypy.org (Laurence Tratt)
Date: Wed, 30 Nov 2011 11:13:07 +0000
Subject: [pypy-issue] [issue907] Stacklets running out of memory on higher
	optimisation	levels
In-Reply-To: <1318523264.95.0.361208519335.issue907@bugs.pypy.org>
Message-ID: <1322651587.31.0.0490142163849.issue907@bugs.pypy.org>


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

Mark as resolved.

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

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

From tracker at bugs.pypy.org  Wed Nov 30 12:18:24 2011
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Wed, 30 Nov 2011 11:18:24 +0000
Subject: [pypy-issue] [issue945] import shadowing module from __init__.py as
	__main__ fails
In-Reply-To: <1322595775.86.0.801378624842.issue945@bugs.pypy.org>
Message-ID: <1322651904.3.0.0110101331914.issue945@bugs.pypy.org>


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

Ah, maybe I found a way around these issues of modules being built-in in pypy,
shadowing user-defined modules.  How about we rename all seldom-used built-in
modules to some strange name, and put in lib_pypy a pure Python module that just
say "from __symbol import *"?

Actually we could do this for all modules that are .so extension modules in a
"normal" CPython build, for some definition of "normal".

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

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

From tracker at bugs.pypy.org  Wed Nov 30 12:23:26 2011
From: tracker at bugs.pypy.org (Xavier Morel)
Date: Wed, 30 Nov 2011 11:23:26 +0000
Subject: [pypy-issue] [issue946] timeit-as-CLI does not accept import
In-Reply-To: <1322650002.66.0.623055381737.issue946@bugs.pypy.org>
Message-ID: <1322652206.04.0.658156420247.issue946@bugs.pypy.org>


Xavier Morel <bugs.pypy.org at masklinn.net> added the comment:

> Macports is buggy, please report it as a bug there.

Yep, that's what I'm in the process of doing right now :)

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

From tracker at bugs.pypy.org  Wed Nov 30 12:25:45 2011
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 30 Nov 2011 11:25:45 +0000
Subject: [pypy-issue] [issue945] import shadowing module from __init__.py as
	__main__ fails
In-Reply-To: <1322595775.86.0.801378624842.issue945@bugs.pypy.org>
Message-ID: <1322652345.12.0.300518172411.issue945@bugs.pypy.org>


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

For a definition of a "normal" list of builtin modules, we could use the CPython 
files Modules/Setup*

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

From tracker at bugs.pypy.org  Wed Nov 30 20:11:42 2011
From: tracker at bugs.pypy.org (jayqhacker)
Date: Wed, 30 Nov 2011 19:11:42 +0000
Subject: [pypy-issue] [issue791] Simple wordcount is significantly slower
	and fatter than	CPython
In-Reply-To: <1310485078.56.0.855118946444.issue791@bugs.pypy.org>
Message-ID: <1322680302.73.0.651437126883.issue791@bugs.pypy.org>


jayqhacker <jayqhacker at gmail.com> added the comment:

Since this is my pet issue, I will keep plugging it until it's faster than
CPython.  :)  I had high hopes for PyPy 1.7, but alas, only a moderate improvement:

CPython 2.7.2 : 41s   1400 MB
PyPy 1.7      : 56s   1400 MB

----------
release: 1.5 -> 1.7

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

From tracker at bugs.pypy.org  Wed Nov 30 21:43:03 2011
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Wed, 30 Nov 2011 20:43:03 +0000
Subject: [pypy-issue] [issue859] numpy script has corrupted memory with JIT
In-Reply-To: <1315020544.58.0.448478930163.issue859@bugs.pypy.org>
Message-ID: <1322685783.5.0.0926356587031.issue859@bugs.pypy.org>


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

Fixed in 741dd1c718ca.

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

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

From tracker at bugs.pypy.org  Wed Nov 30 17:23:01 2011
From: tracker at bugs.pypy.org (oczkers)
Date: Wed, 30 Nov 2011 16:23:01 +0000
Subject: [pypy-issue] [issue947] error in compiling
In-Reply-To: <1322670181.12.0.168844572933.issue947@bugs.pypy.org>
Message-ID: <1322670181.12.0.168844572933.issue947@bugs.pypy.org>


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

gentoo x64

I`m pretty new here so tell me if you need more info.

----------
files: build.log
messages: 3522
nosy: oczkers, pypy-issue
priority: bug
release: 1.7
status: unread
title: error in compiling

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