From tracker at bugs.pypy.org  Sun Jul  1 12:39:35 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sun, 01 Jul 2012 10:39:35 +0000
Subject: [pypy-issue] [issue1197] eol after line cont is syntax error in
	pypy, but not in cpython
In-Reply-To: <1341139175.42.0.881601785705.issue1197@bugs.pypy.org>
Message-ID: <1341139175.42.0.881601785705.issue1197@bugs.pypy.org>


New submission from Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>:

% python -c "print 1\\"
1

% pypy-bin -c "print 1\\" 
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "app_main.py", line 540, in run_it
  File "<string>", line 2
    
   ^
SyntaxError: EOF in multi-line statement

----------
messages: 4520
nosy: pypy-issue, ronny
priority: bug
status: unread
title: eol after line cont is syntax error in pypy, but not in cpython

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

From tracker at bugs.pypy.org  Sun Jul  1 15:06:06 2012
From: tracker at bugs.pypy.org (wbrana)
Date: Sun, 01 Jul 2012 13:06:06 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>


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

build fails see
https://bugs.gentoo.org/show_bug.cgi?id=424365

----------
messages: 4521
nosy: pypy-issue, wbrana
priority: critical
release: 1.9
status: unread
title: AssertionError: must come from an argument to the function, got <-88;esp>

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

From tracker at bugs.pypy.org  Sun Jul  1 16:19:34 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 01 Jul 2012 14:19:34 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1341152374.99.0.0726120837832.issue1198@bugs.pypy.org>


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

Translation command is:
python2.7 ./pypy/translator/goal/translate.py --batch -Ojit --sandbox --make-jobs=2 
./pypy/translator/goal/targetpypystandalone.py --withmod-bz2 --withmod-_minimal_curses --withmod-_ssl

And of course, this is a trackgcroot issue.

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

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

From tracker at bugs.pypy.org  Sun Jul  1 19:26:37 2012
From: tracker at bugs.pypy.org (Choongmin Lee)
Date: Sun, 01 Jul 2012 17:26:37 +0000
Subject: [pypy-issue] [issue1199] psycopg2ct 2.4.4 segmentation fault on
	Ubuntu 12.04 64-bit
In-Reply-To: <1341163597.62.0.605992819875.issue1199@bugs.pypy.org>
Message-ID: <1341163597.62.0.605992819875.issue1199@bugs.pypy.org>


New submission from Choongmin Lee <choongmin at me.com>:

On PyPy 1.8:

$ /opt/pypy-1.8/bin/pypy
Python 2.7.2 (0e28b379d8b3, Feb 09 2012, 19:41:03)
[PyPy 1.8.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``When your hammer is C++,
everything begins to look like a thumb.''
>>>> import psycopg2ct
>>>> conn = psycopg2ct.connect(...)
>>>>

On PyPy 1.9:

$ /opt/pypy-1.9/bin/pypy
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:38:48)
[PyPy 1.9.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``it seems to me that once you
settle on an execution / object model and / or bytecode format, you've already
decided what languages (where the 's' seems superfluous) support is going to be
first class for''
>>>> import psycopg2ct
>>>> conn = psycopg2ct.connect(...)
Segmentation fault (core dumped)
$

----------
messages: 4523
nosy: choongmin, pypy-issue
priority: bug
release: 1.9
status: unread
title: psycopg2ct 2.4.4 segmentation fault on Ubuntu 12.04 64-bit

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

From tracker at bugs.pypy.org  Mon Jul  2 02:21:54 2012
From: tracker at bugs.pypy.org (janrie)
Date: Mon, 02 Jul 2012 00:21:54 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>


New submission from janrie <janpeterr at freenet.de>:

Using Pypy 1.9 and latest version of the mongodb driver "pymongo", I receive an
error when trying to run a script.
"Fatal Python error: PyThreadState_Get: no current thread"

Only pymongo is imported in the particular script, no other 3rd party modules.

----------
messages: 4524
nosy: janrie, pypy-issue
priority: wish
release: 1.9
status: unread
title: Pypy 1.9 and mongodb-driver "pymongo" raise " Fatal error: PyThreadState_Get: no current thread"

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

From tracker at bugs.pypy.org  Mon Jul  2 13:40:15 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 02 Jul 2012 11:40:15 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341229215.15.0.873625575742.issue1200@bugs.pypy.org>


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

This error message does not exist in PyPy.  Did you compile pymongo for pypy?

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

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

From tracker at bugs.pypy.org  Mon Jul  2 13:57:02 2012
From: tracker at bugs.pypy.org (janrie)
Date: Mon, 02 Jul 2012 11:57:02 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341230222.34.0.421748474223.issue1200@bugs.pypy.org>


janrie <janpeterr at freenet.de> added the comment:

Im not sure if you mean by compiling the way of install, but I used the easy
install way using "pypy bin\easy_install-script.py pymongo" and got the egg
version "pymongo-2.2-py2.7-win32". I use Windows 7 without any compiler.

I have to note that I use a virtualenv environment, if this matters with
"--distribute" instead of setuptools.

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

From tracker at bugs.pypy.org  Mon Jul  2 14:00:32 2012
From: tracker at bugs.pypy.org (janrie)
Date: Mon, 02 Jul 2012 12:00:32 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341230432.76.0.268013278789.issue1200@bugs.pypy.org>


janrie <janpeterr at freenet.de> added the comment:

I just tested, and it also happens without virtualenv, I recceive the same error:
"D:\pypy-1.9>pypy d:\project\db.py
Fatal Python error: PyThreadState_Get: no current thread

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

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

From tracker at bugs.pypy.org  Mon Jul  2 14:04:03 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 02 Jul 2012 12:04:03 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341230643.14.0.296744144111.issue1200@bugs.pypy.org>


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

Modules compiled for CPython cannot work with PyPy.  I don't know how the .pyd 
got imported in the first place (PyPy imports modules like "foo.pypy-19.pyd")
Are there some .pyd files in site-package?  What are the file names?

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

From tracker at bugs.pypy.org  Mon Jul  2 15:30:16 2012
From: tracker at bugs.pypy.org (janrie)
Date: Mon, 02 Jul 2012 13:30:16 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341235816.49.0.640652962684.issue1200@bugs.pypy.org>


janrie <janpeterr at freenet.de> added the comment:

Im afraid there are no .pyd-files in site-packages itself, only the mongo egg
folder contains one:

D:\pypy-1.9\site-packages\pymongo-2.2-py2.7-win32.egg\pymongo:
_cmessage.pyd

Im not sure that I can help you troubleshoot that, as I dont know how to compile
myself from inside windows.

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

From tracker at bugs.pypy.org  Mon Jul  2 15:37:11 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 02 Jul 2012 13:37:11 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341236231.25.0.0998902213602.issue1200@bugs.pypy.org>


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

I understand now: eggs will use imp.load_dynamic('_cmessage', '_cmessage.pyd')
which bypasses PyPy protection against CPython modules.

I'm afraid you cannot use easy_install-script.py with PyPy; you have to install pymongo from source; one 
way is to download pymongo-2.2.tar.gz, unpack it somewhere and run "d:\pypy-1.9\pypy setup.py install"
You'll need a compiler for this, of course.

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

From tracker at bugs.pypy.org  Mon Jul  2 18:16:48 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 02 Jul 2012 16:16:48 +0000
Subject: [pypy-issue] [issue1200] Pypy 1.9 and mongodb-driver "pymongo"
	raise " Fatal	error: PyThreadState_Get: no current thread"
In-Reply-To: <1341188514.3.0.887044395565.issue1200@bugs.pypy.org>
Message-ID: <1341245808.12.0.540960552233.issue1200@bugs.pypy.org>


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

Closing as invalid. Not really a pypy issue although I wish we could fix it.

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

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

From tracker at bugs.pypy.org  Mon Jul  2 19:39:18 2012
From: tracker at bugs.pypy.org (Jonas Obrist)
Date: Mon, 02 Jul 2012 17:39:18 +0000
Subject: [pypy-issue] [issue1201] Pymaging is 20x slower on PyPy than CPython
In-Reply-To: <1341250758.21.0.521862100946.issue1201@bugs.pypy.org>
Message-ID: <1341250758.21.0.521862100946.issue1201@bugs.pypy.org>


New submission from Jonas Obrist <jonas.obrist at divio.ch>:

When running https://github.com/ojii/pymaging-benchmark (see README.rst) on 
CPython 2.7.3 and PyPy 1.9 the Pymaging branch runs 20x slower on PyPy on my 
machine.

My results are:

CPython 2.7.3:


Results:
  Load/Save a PNG file
    PIL:      0.02361 / 0.03325 / 0.02254 (212)
    Pymaging: 0.32133 / 0.34429 / 0.30806 (100)

  Resizes a PNG file
    PIL:      0.00512 / 0.00772 / 0.00483 (977)
    Pymaging: 0.31286 / 0.33596 / 0.30357 (100)

PyPy 1.9:


Results:
  Load/Save a PNG file
    PIL:      0.04393 / 0.09822 / 0.03935 (114)
    Pymaging: 5.70319 / 6.40662 / 5.39525 (100)

  Resizes a PNG file
    PIL:      0.01173 / 0.03488 / 0.01048 (427)
    Pymaging: 6.18902 / 6.62564 / 5.81771 (100)

----------
messages: 4532
nosy: ojii, pypy-issue
priority: performance bug
status: unread
title: Pymaging is 20x slower on PyPy than CPython

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

From tracker at bugs.pypy.org  Mon Jul  2 19:41:36 2012
From: tracker at bugs.pypy.org (Jonas Obrist)
Date: Mon, 02 Jul 2012 17:41:36 +0000
Subject: [pypy-issue] [issue1201] Pymaging is 20x slower on PyPy than CPython
In-Reply-To: <1341250758.21.0.521862100946.issue1201@bugs.pypy.org>
Message-ID: <1341250896.93.0.917903831186.issue1201@bugs.pypy.org>


Jonas Obrist <jonas.obrist at divio.ch> added the comment:

Forgot to mention: If you need any more information on the code, feel free to 
talk to ojii on freenode (usually available between noon and midnight GMT)

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

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

From tracker at bugs.pypy.org  Mon Jul  2 21:21:37 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 02 Jul 2012 19:21:37 +0000
Subject: [pypy-issue] [issue1201] Pymaging is 20x slower on PyPy than CPython
In-Reply-To: <1341250758.21.0.521862100946.issue1201@bugs.pypy.org>
Message-ID: <1341256897.05.0.278794698504.issue1201@bugs.pypy.org>


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

Are numbers between parentheses the number of iterations?
Note that the PyPy jit starts after 1000 iterations of a loop.
Could you increase min_iterations to 5000 and try again?

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

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

From tracker at bugs.pypy.org  Wed Jul  4 15:06:38 2012
From: tracker at bugs.pypy.org (anon)
Date: Wed, 04 Jul 2012 13:06:38 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341407198.7.0.913873036467.issue819@bugs.pypy.org>


anon <b10419697 at klzlk.com> added the comment:

Is there any way I can test PyPy with this? I don't have enough memory to build
PyPy but it sounds nice.

What optimizations did you apply? Does it handle cases such as (-1)<<n and
(-2)**n with similar optimizations?

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

From amauryfa at gmail.com  Wed Jul  4 15:34:59 2012
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Wed, 4 Jul 2012 15:34:59 +0200
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
 extreme cases
In-Reply-To: <1341407198.7.0.913873036467.issue819@bugs.pypy.org>
References: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
	<1341407198.7.0.913873036467.issue819@bugs.pypy.org>
Message-ID: <CAGmFidY42_3hjrceHNA9YhHyuyUq1oRbpgm48TGLQeCShfPPLw@mail.gmail.com>

2012/7/4 anon <tracker at bugs.pypy.org>:
> Is there any way I can test PyPy with this? I don't have enough memory to build
> PyPy but it sounds nice.

There is no need to translate a full PyPy interpreter.
just build a small RPython program that uses the module pypy.rlib.rbigint,
translate it, and see how fast it goes.

-- 
Amaury Forgeot d'Arc

From tracker at bugs.pypy.org  Wed Jul  4 16:27:12 2012
From: tracker at bugs.pypy.org (anon)
Date: Wed, 04 Jul 2012 14:27:12 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341412032.89.0.976158644917.issue819@bugs.pypy.org>


anon <b10419697 at klzlk.com> added the comment:

I have non-trivial Python code I'd like to benchmark. Also I don't know any RPython.

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

From tracker at bugs.pypy.org  Wed Jul  4 18:01:38 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Wed, 04 Jul 2012 16:01:38 +0000
Subject: [pypy-issue] [issue1202] sys.settrace affect only current thread
In-Reply-To: <1341417698.44.0.463614366857.issue1202@bugs.pypy.org>
Message-ID: <1341417698.44.0.463614366857.issue1202@bugs.pypy.org>


New submission from Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>:

in cpython it seems to affect all threads (or at least all threads created by
the affected thread)

this causes coverage.py to misreports on pypy when threads are involved

----------
messages: 4538
nosy: pypy-issue, ronny
priority: bug
status: unread
title: sys.settrace affect only current thread

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

From tracker at bugs.pypy.org  Thu Jul  5 08:55:02 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Thu, 05 Jul 2012 06:55:02 +0000
Subject: [pypy-issue] [issue1202] sys.settrace affect only current thread
In-Reply-To: <1341417698.44.0.463614366857.issue1202@bugs.pypy.org>
Message-ID: <1341471302.58.0.112958565799.issue1202@bugs.pypy.org>


Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

missunderstanding on my side

----------
status: unread -> invalid

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

From tracker at bugs.pypy.org  Thu Jul  5 09:03:31 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Thu, 05 Jul 2012 07:03:31 +0000
Subject: [pypy-issue] [issue1203] threading module timing issue seems to
	confuse coverage
In-Reply-To: <1341471811.44.0.906463675229.issue1203@bugs.pypy.org>
Message-ID: <1341471811.44.0.906463675229.issue1203@bugs.pypy.org>


New submission from Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>:

coverage uses threading.settrace to set a global tracing function for new threads

on pypy it seems to slightly misbehave

the behavior can be observed when running
the ThreadingTest of coverage's test.test_oddball

the repo is https://bitbucket.org/ned/coveragepy/

the test can be invoked with pypy -m unittest test.test_oddball.ThreadingTest

for debug output apply the patch

----------
files: testability.patch
messages: 4540
nosy: pypy-issue, ronny
priority: bug
status: unread
title: threading module timing issue seems to confuse coverage

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

From tracker at bugs.pypy.org  Thu Jul  5 10:24:15 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 05 Jul 2012 08:24:15 +0000
Subject: [pypy-issue] [issue1203] threading module timing issue seems to
	confuse coverage
In-Reply-To: <1341471811.44.0.906463675229.issue1203@bugs.pypy.org>
Message-ID: <1341476655.41.0.3487349578.issue1203@bugs.pypy.org>


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

I found something suspect in interpreter/executioncontext.py (PyPy's version of PyThreadState).
space.frame_trace_action.fire() needs to be called regularly for tracing to work, but this is an interpreter-wide 
action, whereas conditions to run it depends on the current thread.

It seems that a thread without a trace function (or currently running its trace function) can "eat" the fire() 
message that was actually intended for the another thread.
See for example the first lines of FrameTraceAction.perform(): they may skip the fire() call at the end of the 
function, and rely on the leave() method to call it again.  But what about other threads running in-between?


Here is a short script that shows similar behavior. Note that the thread is started before the sys.settrace() is 
used:


import sys, threading, time
def slow():
  for x in range(100):
    time.sleep(.01)
def trace(frame, event, arg):
  print frame.f_code.co_filename, frame.f_lineno
  return trace
def main():
  t = threading.Thread(target=slow)
  t.start()
  # Start tracing now
  sys.settrace(trace)
  slow()
main()

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

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

From tracker at bugs.pypy.org  Thu Jul  5 19:24:59 2012
From: tracker at bugs.pypy.org (Stian Andreassen)
Date: Thu, 05 Jul 2012 17:24:59 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341509099.53.0.768802653007.issue819@bugs.pypy.org>


Stian Andreassen <stian at tech1.org> added the comment:

If you upload the script, I can run it for you, or I could upload my own
translation (64bit only, I don't have access to any 32bit machines).

More test code means better results.

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

From tracker at bugs.pypy.org  Thu Jul  5 21:28:25 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 05 Jul 2012 19:28:25 +0000
Subject: [pypy-issue] [issue1204] gdb hooks for debugging PyPy
In-Reply-To: <1341516505.7.0.34697750612.issue1204@bugs.pypy.org>
Message-ID: <1341516505.7.0.34697750612.issue1204@bugs.pypy.org>


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

gdb 7 onwards is scriptable using an embedded CPython 2.*, giving the ability to write fragments of Python to add new 
commands, and to tell gdb how to pretty-print data, etc.  (A couple of years ago I wrote such code to make it easier to 
debug CPython; see http://fedoraproject.org/wiki/Features/EasierPythonDebugging )

I'm attaching a script I've written to help debug PyPy.  It's a work in progress so far, but it's able to print RPython 
strings, and some PyPy frame information.

For example, if I run
  $ gdb --eval-command="break pypy_g_PyFrame_run" --eval-command="run" --args pypy
I get this output when the breakpoint is hit:
  Breakpoint 1, pypy_g_PyFrame_run (l_self_11960=Frame for app_main.py:run_toplevel:42) at interpreter_pyframe.c:48

Note how the frame object has been pretty-printed as "Frame for app_main.py:run_toplevel:42"

I'm attaching what a full backtrace looks like with these hooks for a pypy process waiting at the interactive prompt 
(full-backtrace.txt): numerous frames are visible.  Unfortunately, many values are optimized out, though.

Of course this code is specific to the C backend, and it's probably sensitive to translation options - but my feeling is 
that every little helps when debugging the generated C code.

FWIW I've been developing this on a Fedora 17 x86_64 box, using the pypy rpms (which have slightly non-standard 
translation options; see http://pkgs.fedoraproject.org/gitweb/?p=pypy.git;a=blob;f=pypy.spec ).

I copy the file to:
   /usr/lib/debug/usr/lib64/pypy-1.9/pypy.debug-gdb.py
alongside the DWARF data (where I've been editing it in place).

gdb will load this on startup when debugging /usr/lib64/pypy-1.9/pypy (aka /usr/bin/pypy).  My plan is to package this 
file within my rpms so that it's within the debuginfo rpm (I do something similar for CPython on Fedora/RHEL).

Presumably this file should live somewhere in the pypy source tree (where?)  Should I create a branch on bitbucket, and 
hack on it there?

----------
files: pypy.debug-gdb.py
messages: 4543
nosy: dmalcolm, pypy-issue
priority: feature
status: unread
title: gdb hooks for debugging PyPy

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

From tracker at bugs.pypy.org  Thu Jul  5 21:32:27 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 05 Jul 2012 19:32:27 +0000
Subject: [pypy-issue] [issue1204] gdb hooks for debugging PyPy
In-Reply-To: <1341516505.7.0.34697750612.issue1204@bugs.pypy.org>
Message-ID: <1341516747.3.0.305103508185.issue1204@bugs.pypy.org>


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

The exact path for the script will vary depending on where pypy is; run
   strace gdb pypy
to see where gdb looks for "-gdb.py" scripts on startup

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

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

From tracker at bugs.pypy.org  Thu Jul  5 21:43:58 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 05 Jul 2012 19:43:58 +0000
Subject: [pypy-issue] [issue1204] gdb hooks for debugging PyPy
In-Reply-To: <1341516505.7.0.34697750612.issue1204@bugs.pypy.org>
Message-ID: <1341517438.81.0.467557387452.issue1204@bugs.pypy.org>


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

Motivation: although PyPy's generated C code may be perfect, as soon as you link 3rd-party code into the 
process (e.g. via extension modules, ctypes, or some other FFI), the process runs the risk of crashes 
induced by bugs in that 3rd party code.  Hence it's useful to have some way of debugging the process and 
figuring out e.g. what thread is doing what.  (For example: pointers getting freed by 3rd party code that 
shouldn't have freed them, refcounting bugs in extension modules, random pointer corruption, etc etc)

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

From tracker at bugs.pypy.org  Thu Jul  5 22:02:19 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 05 Jul 2012 20:02:19 +0000
Subject: [pypy-issue] [issue1204] gdb hooks for debugging PyPy
In-Reply-To: <1341516505.7.0.34697750612.issue1204@bugs.pypy.org>
Message-ID: <1341518539.86.0.994579661721.issue1204@bugs.pypy.org>


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

Alex Gaynor pointed me at:
  https://bitbucket.org/pypy/pypy/src/default/pypy/tool/gdb_pypy.py
Looks like my work overlaps that functionality somewhat; I'll try to come up with 
a way of patching my stuff into that.

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

From tracker at bugs.pypy.org  Thu Jul  5 22:31:33 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 05 Jul 2012 20:31:33 +0000
Subject: [pypy-issue] [issue1205] PyPy issue 349 is unreadable (due to leap
	second?)
In-Reply-To: <1341520293.09.0.922151103393.issue1205@bugs.pypy.org>
Message-ID: <1341520293.09.0.922151103393.issue1205@bugs.pypy.org>


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

(This is a metabug, filing here for now)

Attempting to view https://bugs.pypy.org/issue349 gives a traceback:

A problem occurred in your template "issue.item.html".
Full traceback:
Traceback (most recent call last):
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/client.py", line 1007, in renderContext
    result = pt.render(self, None, None, **args)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/templating.py", line 343, in render
    getEngine().getContext(c), output, tal=1, strictinsert=0)()
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 192, in 
__call__
    self.interpret(self.program)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in 
interpret
    handlers[opcode](self, args)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 666, in 
do_useMacro
    self.interpret(macro)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in 
interpret
    handlers[opcode](self, args)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 411, in 
do_optTag_tal
    self.do_optTag(stuff)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 396, in 
do_optTag
    return self.no_tag(start, program)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 391, in no_tag
    self.interpret(program)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in 
interpret
    handlers[opcode](self, args)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 689, in 
do_defineSlot
    self.interpret(slot)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in 
interpret
    handlers[opcode](self, args)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 632, in 
do_condition
    self.interpret(block)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in 
interpret
    handlers[opcode](self, args)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 632, in 
do_condition
    self.interpret(block)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in 
interpret
    handlers[opcode](self, args)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/TAL/TALInterpreter.py", line 564, in 
do_insertStructure_tal
    structure = self.engine.evaluateStructure(expr)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/PageTemplates/TALES.py", line 227, in 
evaluate
    return expression(self)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/PageTemplates/Expressions.py", line 195, in 
__call__
    return self._eval(econtext)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/PageTemplates/Expressions.py", line 190, in 
_eval
    return render(ob, econtext.vars)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/PageTemplates/Expressions.py", line 96, in 
render
    ob = ob()
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/templating.py", line 892, in submit
    self.input(type="hidden", name="@action", value=action) + '\n' + \
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/templating.py", line 446, in input_html4
    return '<input %s>'%cgi_escape_attrs(**attrs)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/templating.py", line 441, in 
cgi_escape_attrs
    for k,v in attrs.items()])
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/templating.py", line 1272, in __str__
    return self.plain()
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/cgi/templating.py", line 1655, in plain
    return str(self._value.local(offset))
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/date.py", line 527, in local
    self.hour, self.minute, self.second, offset)
  File "/home/pypy/venv/lib/python2.6/site-packages/roundup/date.py", line 151, in _utc_to_local
    dt = datetime.datetime(y, m, d, H, M, int(S), tzinfo=UTC)
ValueError: second must be in 0..59

My guess is that something within the data for that bug happened on a leap second, making the page 
unreadable (though that's a guess).

----------
messages: 4547
nosy: dmalcolm, pypy-issue
priority: bug
status: unread
title: PyPy issue 349 is unreadable (due to leap second?)

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

From tracker at bugs.pypy.org  Thu Jul  5 23:03:14 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 05 Jul 2012 21:03:14 +0000
Subject: [pypy-issue] [issue1205] PyPy issue 349 is unreadable (due to leap
	second?)
In-Reply-To: <1341520293.09.0.922151103393.issue1205@bugs.pypy.org>
Message-ID: <1341522194.14.0.136331806788.issue1205@bugs.pypy.org>


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

Similar report here:
https://bugs.launchpad.net/ubuntu/+source/roundup/+bug/673677

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

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

From tracker at bugs.pypy.org  Fri Jul  6 14:20:02 2012
From: tracker at bugs.pypy.org (Pigmej)
Date: Fri, 06 Jul 2012 12:20:02 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>


New submission from Pigmej <jedrzej.nowak at codernity.com>:

See Attached code.

Script outputs:

- pypy 1.9:
root at ci:/tmp# pypy builder.py 
time 1715.36743188
process size 168648 kb

- cpython 2.7.3:
root at ci:/tmp# python builder.py 
time 0.507338047028
process size 31668 kb

Also pypy used 100% cpu during whole process.


As I can understand slow pypy with strings, following behaviour is really weird for me.

That part of code is from bigger context, so it might look a bit weird.

----------
files: pypy_bug.py
messages: 4549
nosy: pigmej, pypy-issue
priority: performance bug
release: 1.9
status: unread
title: Extreme slowdown of code part (array.array) operations

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

From fijall at gmail.com  Fri Jul  6 14:28:29 2012
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 6 Jul 2012 14:28:29 +0200
Subject: [pypy-issue] [issue1204] gdb hooks for debugging PyPy
In-Reply-To: <1341518539.86.0.994579661721.issue1204@bugs.pypy.org>
References: <1341516505.7.0.34697750612.issue1204@bugs.pypy.org>
	<1341518539.86.0.994579661721.issue1204@bugs.pypy.org>
Message-ID: <CAK5idxRB60dPrfVpjZqOZoSnQRfJ-vU=7spQnjvf7t006AcMsQ@mail.gmail.com>

As far as i remenber gdb-pypy does not let you use it once you segfault
because it invokes python. improcements are welcome

On Thursday, July 5, 2012, Dave Malcolm <tracker at bugs.pypy.org> wrote:
>
> Dave Malcolm <dmalcolm at redhat.com> added the comment:
>
> Alex Gaynor pointed me at:
>   https://bitbucket.org/pypy/pypy/src/default/pypy/tool/gdb_pypy.py
> Looks like my work overlaps that functionality somewhat; I'll try to come
up with
> a way of patching my stuff into that.
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1204>
> ________________________________________
> _______________________________________________
> pypy-issue mailing list
> pypy-issue at python.org
> http://mail.python.org/mailman/listinfo/pypy-issue
>

From tracker at bugs.pypy.org  Fri Jul  6 14:30:14 2012
From: tracker at bugs.pypy.org (Stefan Behnel)
Date: Fri, 06 Jul 2012 12:30:14 +0000
Subject: [pypy-issue] [issue1121] [cpyext] speed up some macros
In-Reply-To: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>
Message-ID: <1341577814.46.0.622657231879.issue1121@bugs.pypy.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

bump - it's just one character that needs to be deleted in
pypy/module/cpyext/include/object.h.

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

From tracker at bugs.pypy.org  Fri Jul  6 19:02:54 2012
From: tracker at bugs.pypy.org (anon)
Date: Fri, 06 Jul 2012 17:02:54 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341594174.22.0.0605311347856.issue819@bugs.pypy.org>


anon <b10419697 at klzlk.com> added the comment:

Sadly the code is part of proprietary software and I cannot provide source. If
you have a Linux 64 build of PyPy with such modifications I can test using that.

To anyone interested in implementing Toom-Cook multiplication, a good
description and pseudo-code is provided in Modern Computer Arithmetic which is
available freely. See http://arxiv.org/abs/1004.4710/, section 1.3.3.

To get best results one would need a fast algorithm for computing division by 3
which can be used with a right-shift to provide an exact division by 6 on line 8.

I'd expect an optimal cutoff parameter n_1 to be about 150 bits but it will need
tuning depending on the implementation.

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

From tracker at bugs.pypy.org  Fri Jul  6 22:54:12 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 06 Jul 2012 20:54:12 +0000
Subject: [pypy-issue] [issue1121] [cpyext] speed up some macros
In-Reply-To: <1334090463.15.0.92342877767.issue1121@bugs.pypy.org>
Message-ID: <1341608052.51.0.104539146416.issue1121@bugs.pypy.org>


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

Done. Thanks your reminding.

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

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

From tracker at bugs.pypy.org  Sat Jul  7 01:04:23 2012
From: tracker at bugs.pypy.org (Stian Andreassen)
Date: Fri, 06 Jul 2012 23:04:23 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341615863.87.0.00518130100087.issue819@bugs.pypy.org>


Stian Andreassen <stian at tech1.org> added the comment:

The branch actually have a Toom-Cook-3 implantation. But it's worse than
Karatsuba, even for huge digits (2000+). Feel free to improve on it.

Using multiply + rshift and you get too low precision, but even with inaccuracy
of just doing rshift by 2 (div by 8), the function is STILL slower.

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

From tracker at bugs.pypy.org  Sat Jul  7 04:18:52 2012
From: tracker at bugs.pypy.org (anon)
Date: Sat, 07 Jul 2012 02:18:52 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341627532.22.0.682030776853.issue819@bugs.pypy.org>


anon <b10419697 at klzlk.com> added the comment:

I can see commits that relate to Toom-Cook code but when I view the source of
/pypy/rlib/rbigint.py I cannot see any Toom-Cook changes. Could you provide me a
link?

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

From tracker at bugs.pypy.org  Sat Jul  7 05:31:38 2012
From: tracker at bugs.pypy.org (Stian Andreassen)
Date: Sat, 07 Jul 2012 03:31:38 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341631898.81.0.103675437922.issue819@bugs.pypy.org>


Stian Andreassen <stian at tech1.org> added the comment:

Here:
https://bitbucket.org/_stian/pypy-improvebigint/src/62831f97a2c7/pypy/rlib/rbigint.py#cl-1135

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

From tracker at bugs.pypy.org  Sat Jul  7 14:52:03 2012
From: tracker at bugs.pypy.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 12:52:03 +0000
Subject: [pypy-issue] [issue1207] latest Pypy *with JIT* fails with weird
	error running	pep8.py testsuite
In-Reply-To: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>
Message-ID: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

I'm the maintainer of the library "pep8.py".

It runs fine on all versions of Python (2.5 to 3.2) and with Pypy *--jit off*.

However, it fails with a strange error with Pypy JIT.


$ pypy --version
Python 2.7.2 (20258fbf10d0, Jul 03 2012, 01:00:23)
[PyPy 1.9.1-dev0 with GCC 4.2.1]


$ pypy --jit off pep8.py --testsuite testsuite
1247 lines tested: 27 files, 184 test cases.
Test passed.


$ pypy pep8.py --testsuite testsuite

Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "pep8.py", line 1934, in <module>
    _main()
  File "pep8.py", line 1920, in _main
    report = pep8style.check_files()
  File "pep8.py", line 1589, in check_files
    self.input_dir(path)
  File "pep8.py", line 1622, in input_dir
    runner(os.path.join(root, filename))
  File "pep8.py", line 1692, in run_tests
    line_offset=line_offset)
  File "pep8.py", line 1600, in input_file
    return fchecker.check_all(expected=expected, line_offset=line_offset)
  File "pep8.py", line 1343, in check_all
    self.check_logical()
  File "pep8.py", line 1283, in check_logical
    for result in self.run_check(check, argument_names):
  File "pep8.py", line 421, in indentation
    if indent_char == ' ' and indent_level % 4:
TypeError: not all arguments converted during string formatting


You can repeat this with any recent version of pep8.py here:
https://github.com/jcrocholl/pep8

----------
messages: 4557
nosy: flox, pypy-issue
priority: bug
release: 1.9
status: unread
title: latest Pypy *with JIT* fails with weird error running pep8.py testsuite

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

From tracker at bugs.pypy.org  Sat Jul  7 14:53:22 2012
From: tracker at bugs.pypy.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 12:53:22 +0000
Subject: [pypy-issue] [issue1207] latest Pypy *with JIT* fails with weird
	error running	pep8.py testsuite
In-Reply-To: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>
Message-ID: <1341665602.2.0.707906040572.issue1207@bugs.pypy.org>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I'm not a regular user of Pypy.
I've first seen this error while running Travis-CI builder:
https://secure.travis-ci.org/#!/jcrocholl/pep8

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

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

From tracker at bugs.pypy.org  Sat Jul  7 15:26:22 2012
From: tracker at bugs.pypy.org (Ariel Ben-Yehuda)
Date: Sat, 07 Jul 2012 13:26:22 +0000
Subject: [pypy-issue] [issue1208] test format_locale fails
In-Reply-To: <1341667582.68.0.909610719781.issue1208@bugs.pypy.org>
Message-ID: <1341667582.68.0.909610719781.issue1208@bugs.pypy.org>


New submission from Ariel Ben-Yehuda <arielb1 at mail.tau.ac.il>:

Test format_locale fails because of a bug in newformat._group_digits (it looks
for a null-terminator but python strings lack one so it falls of the end of the
string).

Also, I added some more locale tests.

----------
files: fix-_group_digits.patch
messages: 4559
nosy: arielby, pypy-issue
priority: bug
status: unread
title: test format_locale fails

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

From tracker at bugs.pypy.org  Sat Jul  7 17:46:48 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 07 Jul 2012 15:46:48 +0000
Subject: [pypy-issue] [issue1207] latest Pypy *with JIT* fails with weird
	error running	pep8.py testsuite
In-Reply-To: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>
Message-ID: <1341676008.64.0.754864844277.issue1207@bugs.pypy.org>


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

'indent_level' suddenly turns into a string, and it's a segfault if you try to 
print it...

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

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

From tracker at bugs.pypy.org  Sat Jul  7 18:33:46 2012
From: tracker at bugs.pypy.org (Ariel Ben-Yehuda)
Date: Sat, 07 Jul 2012 16:33:46 +0000
Subject: [pypy-issue] [issue1209] unicode format does not work with a
	unicode thousands	separator
In-Reply-To: <1341678826.35.0.78374950006.issue1209@bugs.pypy.org>
Message-ID: <1341678826.35.0.78374950006.issue1209@bugs.pypy.org>


New submission from Ariel Ben-Yehuda <arielb1 at mail.tau.ac.il>:

pypy 1.9 has the same bug as CPython issue 15276
(http://bugs.python.org/issue15276) - but in pypy3k formats default to unicode
so the issue is a little more visible.

Patch Attached
Note that the patch fixes an issue in a test written in #1208 (we need to change
LC_CTYPE because we cannot be sure it is the same encoding LC_NUMERIC uses - I
set LC_ALL).

----------
files: fix-_getlocale.patch
messages: 4561
nosy: arielby, pypy-issue
priority: bug
status: unread
title: unicode format does not work with a unicode thousands separator

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

From tracker at bugs.pypy.org  Sat Jul  7 19:09:23 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 07 Jul 2012 17:09:23 +0000
Subject: [pypy-issue] [issue1209] unicode format does not work with a
	unicode thousands	separator
In-Reply-To: <1341678826.35.0.78374950006.issue1209@bugs.pypy.org>
Message-ID: <1341680963.47.0.94258250617.issue1209@bugs.pypy.org>


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

Could you fix the patch in #1208 as well? it's better to have independent issues.

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

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

From tracker at bugs.pypy.org  Sat Jul  7 20:05:56 2012
From: tracker at bugs.pypy.org (Ariel Ben-Yehuda)
Date: Sat, 07 Jul 2012 18:05:56 +0000
Subject: [pypy-issue] [issue1209] unicode format does not work with a
	unicode thousands	separator
In-Reply-To: <1341678826.35.0.78374950006.issue1209@bugs.pypy.org>
Message-ID: <1341684356.48.0.325209839662.issue1209@bugs.pypy.org>


Ariel Ben-Yehuda <arielb1 at mail.tau.ac.il> added the comment:

The test that needs the fix (test_locale_european) needs #1209 anyway. The other
tests work fine without the fix (unless you are using a utf-16 locale or
something, in which case they don't).

Or are you proposing that I will add a separate issue for the test fixes?

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

From tracker at bugs.pypy.org  Mon Jul  9 06:15:56 2012
From: tracker at bugs.pypy.org (anon)
Date: Mon, 09 Jul 2012 04:15:56 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1341807356.3.0.329728105466.issue819@bugs.pypy.org>


anon <b10419697 at klzlk.com> added the comment:

Thanks!

That implementation seems to be equivalent to the one in Modern Computer
Algebra. I coded a straight implementation in Python and found that it's slower
than inbuilt multiplication for less than around 20,000-bit numbers.

I think one difference between this implementation and libgmp's one is the
evaluation points we use. This implementation uses -1, 0, 1, 2 and infinity
while libgmp uses the points 0, 0.5, 1, 2 and infinity. A faster version of the
-1, 0, 1, 2 infinity version can be seen on line 229 of:

http://code.google.com/p/bignumberslibrary/source/browse/trunk/src/ru/kirilchuk/bigint/BigInteger.java

I implemented my own version of it in Python:

http://paste.ubuntu.com/1082209/

Additionally it appears _tcmul_split(n, size) essentially makes a copy of n
instead of referencing its bits.

I'd first find out what part of _tc_mul is actually taking so long. When I was
testing my all-Python version above I prematurely returned an obviously wrong
answer at different points inside the toomcook function to see where the bulk of
the computation takes place.

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

From tracker at bugs.pypy.org  Sun Jul  8 11:34:40 2012
From: tracker at bugs.pypy.org (Soares Chen)
Date: Sun, 08 Jul 2012 09:34:40 +0000
Subject: [pypy-issue] [issue1210] asmgcc AssertionError: must come from an
	argument to the	function, got '%rax'
In-Reply-To: <1341740080.61.0.75335055666.issue1210@bugs.pypy.org>
Message-ID: <1341740080.61.0.75335055666.issue1210@bugs.pypy.org>


New submission from Soares Chen <soares.chen at gmail.com>:

There is this obscure asmgcc bug that I came across while trying to compile the py3k branch 
on Ubuntu using GCC 4.6.1 with opt=jit.

The involved generated assembly code, interpreter_pyopcode.s, is attached and the bug can be 
reproduced by running:

pypy/translator/c/gcc/trackgcroot.py -t interpreter_pyopcode.s > interpreter_pyopcode.gctmp

The current workaround is to use the flag --gcrootfinder=shadowstack on translate.py

Following is the last few lines of output before the error:

 104  Label(.L1051, 578) --- set(['%r14', '%rbp', '%r12', '%rax'])
 104  Label(.L1012, 579) --- set(['%r14', '%rbp', '%r12', '%rax'])
 104  InsnCopyLocal(%rax, %rdx) --- set(['%r14', '%rbp', '%r12'])
   ?  InsnStop(jump) --- None
 104  Label(.L1057, 582) --- None
 104  Label(.L998, 583) --- None
 104  InsnCondJump(.L991) --- None
 104  Label(.L999, 586) --- None
 104  InsnCopyLocal(%rbx, %rdi) --- None
 104  InsnCopyLocal(%rbp, %rdx) --- None
 104  InsnCopyLocal(%r12, %rsi) --- None
 104  InsnCall(590, pypy_g_call_args_and_c_profile__AccessDirect_None, {}) --- None
 104  InsnSetLocal(%rax, []) --- None
 104  InsnGCROOT(%rbx) --- None
 104  InsnCondJump(.L1047) --- None
 104  Label(.L1000, 598) --- None
 104  InsnSetLocal(%rdx, ['pypydtcount(%rip)']) --- None
   ?  InsnStop(jump) --- None
Traceback (most recent call last):
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/trackgcroot.py", line 2023, in <module>
    tracker.process(f, g, filename=fn)
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1916, in process
    tracker = parser.process_function(lines, filename)
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1431, in 
process_function
    table = tracker.computegcmaptable(self.verbose)
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/trackgcroot.py", line 60, in 
computegcmaptable
    self.trackgcroots()
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/trackgcroot.py", line 335, in trackgcroots
    self.walk_instructions_backwards(walker, insn, loc)
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/trackgcroot.py", line 354, in 
walk_instructions_backwards
    for prevstate in walker(insn, state):
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/trackgcroot.py", line 327, in walker
    source = insn.source_of(loc, tag)
  File "/home/crf/dev/pypy/pypy/translator/c/gcc/instruction.py", line 134, in source_of
    (localvar,))
AssertionError: must come from an argument to the function, got '%rax'

----------
files: interpreter_pyopcode.s
messages: 4564
nosy: pypy-issue, soareschen
priority: bug
status: unread
title: asmgcc AssertionError: must come from an argument to the function, got '%rax'

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

From tracker at bugs.pypy.org  Mon Jul  9 21:57:29 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Mon, 09 Jul 2012 19:57:29 +0000
Subject: [pypy-issue] [issue1211] Implementation of
	PyInt_AsUnsignedLongLongMask
In-Reply-To: <1341863849.75.0.990035868631.issue1211@bugs.pypy.org>
Message-ID: <1341863849.75.0.990035868631.issue1211@bugs.pypy.org>


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

I'm attaching a patch which (I hope) implements PyInt_AsUnsignedLongLongMask (c.f.
  http://docs.python.org/c-api/int.html#PyInt_AsUnsignedLongLongMask ), which is used by an extension 
module I'm 
trying to get running with PyPy (specifically, the python bindings to rpm)

Caveat: not yet translated, and I'm somewhat blindly copying what the rest of that file is doing.  
Tests seem to 
pass though.

----------
files: add-PyInt_AsUnsignedLongLongMask.patch
messages: 4566
nosy: dmalcolm, pypy-issue
priority: feature
status: unread
title: Implementation of PyInt_AsUnsignedLongLongMask

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

From tracker at bugs.pypy.org  Mon Jul  9 22:19:35 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Mon, 09 Jul 2012 20:19:35 +0000
Subject: [pypy-issue] [issue1211] Implementation of
	PyInt_AsUnsignedLongLongMask
In-Reply-To: <1341863849.75.0.990035868631.issue1211@bugs.pypy.org>
Message-ID: <1341865175.28.0.640601130278.issue1211@bugs.pypy.org>


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

Reviewed by ronny and Alex_Gaynor on IRC; committed as 542d481517d3

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

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

From tracker at bugs.pypy.org  Tue Jul 10 17:33:16 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 10 Jul 2012 15:33:16 +0000
Subject: [pypy-issue] [issue1212] call to type() fails tests (2) in mocker
	test suite.
In-Reply-To: <1341934396.43.0.0849708967923.issue1212@bugs.pypy.org>
Message-ID: <1341934396.43.0.0849708967923.issue1212@bugs.pypy.org>


New submission from Ian Delaney <della5 at iinet.com.au>:

Let's start the ball rolling here.  Going on previous attempts, this will likely
be one for the mocker maintainers.

 * Testing of dev-python/mocker-1.1.1 with PyPy 1.9 (Python 2.7)...
........................................................................................................................................................................................................................................................................................................................................................................................................F............................................F...........
======================================================================
FAIL: test_install_on_object (__main__.ProxyReplacerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 4063, in test_install_on_object
    self.assertEquals(type(obj.calendar), Mock)
AssertionError: <type 'module'> != <class 'mocker.Mock'>

======================================================================
FAIL: test_unsupported_object_for_getargspec (__main__.SpecCheckerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 3883, in test_unsupported_object_for_getargspec
    self.assertRaises(TypeError, inspect.getargspec, adler32)
AssertionError: TypeError not raised


from test.py

    def test_install_on_object(self):
        class C(object):
            def __init__(self):
                import calendar
                self.calendar = calendar
        obj = C()
        self.task.replay()
        self.assertEquals(type(obj.calendar), Mock)      line 4063.
        self.assertTrue(obj.calendar is self.mock)


    def test_unsupported_object_for_getargspec(self):
        from zlib import adler32
        # If that fails, this test has to change because either adler32 has
        # changed, or the implementation of getargspec has changed.
        self.assertRaises(TypeError, inspect.getargspec, adler32)   [line 3883]
        try:
            task = SpecChecker(adler32)
            task.run(self.path("asd"))
        except TypeError, e:
            self.fail("TypeError: %s" % str(e))


package is mocker-1.1.1.  I don't think a whole log will help really.
One I filed before had a problem with mock types or such

----------
messages: 4568
nosy: idella5, pypy-issue
priority: bug
release: 0.9
status: chatting
title: call to type() fails tests (2) in mocker test suite.

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

From tracker at bugs.pypy.org  Tue Jul 10 19:56:03 2012
From: tracker at bugs.pypy.org (Justin Blanchard)
Date: Tue, 10 Jul 2012 17:56:03 +0000
Subject: [pypy-issue] [issue1213] Inheriting from ctypes.BigEndianStructure
	doesn't work as	expected
In-Reply-To: <1341942963.66.0.528674364039.issue1213@bugs.pypy.org>
Message-ID: <1341942963.66.0.528674364039.issue1213@bugs.pypy.org>


New submission from Justin Blanchard <UncombedCoconut at gmail.com>:

I have attached a test script (which, if named "endian-test.py", tries to read 
the first 8 bytes of itself as an integer in a Structure, BigEndianStructure, 
and LittleEndianStructure) to show the problem. Under pypy, all 3 of these read 
the data in native byte order. (I tested on an x86_64 machine.)

I can see by tracing that the _swapped_meta metaclass (from lib-
python/2.7/ctypes/_endian.py) never intercepts the assignment _fields_ = [ 
('value', c_uint64) ], so it never changes it to [ ('value', c_ulong_be) ].
But I don't understand Python's OO magic well enough to diagnose the problem 
further, let alone fix it.

----------
files: endian-test.py
messages: 4569
nosy: UncombedCoconut, pypy-issue
priority: bug
release: 1.9
status: unread
title: Inheriting from ctypes.BigEndianStructure doesn't work as expected

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

From tracker at bugs.pypy.org  Tue Jul 10 20:25:24 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 10 Jul 2012 18:25:24 +0000
Subject: [pypy-issue] [issue1213] Inheriting from ctypes.BigEndianStructure
	doesn't work as	expected
In-Reply-To: <1341942963.66.0.528674364039.issue1213@bugs.pypy.org>
Message-ID: <1341944724.79.0.300318159422.issue1213@bugs.pypy.org>


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

I had a look, but the missing feature is deeper: we don't support the
reverse-endian types (e.g. c_int.__ctype_be__).

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

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

From tracker at bugs.pypy.org  Tue Jul 10 20:26:58 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 10 Jul 2012 18:26:58 +0000
Subject: [pypy-issue] [issue1212] call to type() fails tests (2) in mocker
	test suite.
In-Reply-To: <1341934396.43.0.0849708967923.issue1212@bugs.pypy.org>
Message-ID: <1341944818.61.0.529476248984.issue1212@bugs.pypy.org>


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

- test_unsupported_object_for_getargspec is not really a failure.  Its code starts with::
        # If that fails, this test has to change because either adler32 has
        # changed, or the implementation of getargspec has changed.
Which is the case here: with pypy, inspect.getargspec also works for builtin functions!  The "assertRaises" 
line should be skipped IMO; the next call actually succeeds, but of course there is no point to test for 
unsupported functions.

- test_install_on_object fails because the function global_replace() only replace in dictionaries, but not all 
objects have a __dict__!
The test also fails with CPython if you add a __slots__ = ('calendar',) to the class; PyPy actually behaves as 
if __slots__ was added to the class (see http://morepypy.blogspot.ch/2010/11/efficiently-implementing-python-
objects.html )

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

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

From tracker at bugs.pypy.org  Tue Jul 10 21:04:22 2012
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 10 Jul 2012 19:04:22 +0000
Subject: [pypy-issue] [issue1212] call to type() fails tests (2) in mocker
	test suite.
In-Reply-To: <1341934396.43.0.0849708967923.issue1212@bugs.pypy.org>
Message-ID: <1341947062.26.0.416916316836.issue1212@bugs.pypy.org>


Ian Delaney <della5 at iinet.com.au> added the comment:

afa thanks.  I shall read the link and digest it as best I can.
Rule of thumb it appears that both could be justifiably skipped on the basis of
incompatibility,
the mocker maintainers are those who need adjust the tests to accommodate pypy.

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

From tracker at bugs.pypy.org  Thu Jul 12 12:55:01 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 12 Jul 2012 10:55:01 +0000
Subject: [pypy-issue] [issue1204] gdb hooks for debugging PyPy
In-Reply-To: <1341516505.7.0.34697750612.issue1204@bugs.pypy.org>
Message-ID: <1342090501.36.0.518938372589.issue1204@bugs.pypy.org>


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

So, what should we do with it? Put it somewhere in the pypy repo (like tool/)?

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

From tracker at bugs.pypy.org  Thu Jul 12 12:56:22 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 12 Jul 2012 10:56:22 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1342090582.02.0.213447828409.issue1198@bugs.pypy.org>


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

We need the assembler file, otherwise it's impossible to reproduce. Also - did 
you massage gcc flags or did it use the default?

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

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

From tracker at bugs.pypy.org  Thu Jul 12 12:57:02 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 12 Jul 2012 10:57:02 +0000
Subject: [pypy-issue] [issue1177] The empty string is a new object every time
In-Reply-To: <1339634869.45.0.714341308907.issue1177@bugs.pypy.org>
Message-ID: <1342090622.19.0.728231501785.issue1177@bugs.pypy.org>


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

Closing as won't fix. It's not even true on cpython

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

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

From tracker at bugs.pypy.org  Thu Jul 12 13:01:02 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Thu, 12 Jul 2012 11:01:02 +0000
Subject: [pypy-issue] [issue1214] stdlib test granularity
In-Reply-To: <1342090862.14.0.942323090469.issue1214@bugs.pypy.org>
Message-ID: <1342090862.14.0.942323090469.issue1214@bugs.pypy.org>


New submission from Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>:

steps:

1. classify tests as script,
   needing test_support.run_unittest/test_main and directly collectable
2. create a collector that collects test items in a py.py/pypy-bin subprocess
   and reports them (could be a py.py -m pytest --collectonly -q)
3. create a runner that can run selected tests of a single file in a
py.py/pypy-bin subprocess (could be based on xdist dsession or just starting
py.py -m pytest <itemid> every time)
4. create a mechanism to cache per file collected items - since the collector
will be a extra process it seems sensible to avoid having it
(putting a json with the rough structure of { filename: {"content-sha1": sha1,
"nodes": [nodeids, ...]}} seems sensible

----------
messages: 4576
nosy: pypy-issue, ronny
priority: feature
status: unread
title: stdlib test granularity

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

From tracker at bugs.pypy.org  Thu Jul 12 13:16:13 2012
From: tracker at bugs.pypy.org (wbrana)
Date: Thu, 12 Jul 2012 11:16:13 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1342091773.79.0.27471992879.issue1198@bugs.pypy.org>


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

Which exactly file do you need?
I'm was probably using -O3 -g0 -march=core2 -mtune=core2 -fomit-frame-
pointer -funroll-loops -finline-limit=128 --param max-unrolled-insns=64 -fno-
tree-pre

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

From tracker at bugs.pypy.org  Thu Jul 12 13:20:01 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 12 Jul 2012 11:20:01 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1342092001.26.0.991408588187.issue1198@bugs.pypy.org>


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

Can you see if it works with options that we provide?

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

From tracker at bugs.pypy.org  Thu Jul 12 13:22:01 2012
From: tracker at bugs.pypy.org (3TATUK)
Date: Thu, 12 Jul 2012 11:22:01 +0000
Subject: [pypy-issue] [issue1215] /pypy/config/support.py missing close()
In-Reply-To: <1342092121.65.0.768763903265.issue1215@bugs.pypy.org>
Message-ID: <1342092121.65.0.768763903265.issue1215@bugs.pypy.org>


New submission from 3TATUK <ztatik.light at gmail.com>:

Wouldn't be surprised if there were more like this in pypy ... A simple grep
would probably take care of it.

----------
assignedto: fijal
messages: 4579
nosy: 3TATUK, fijal, pypy-issue
priority: bug
release: 2.0
status: resolved
title: /pypy/config/support.py missing close()

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

From tracker at bugs.pypy.org  Thu Jul 12 13:24:34 2012
From: tracker at bugs.pypy.org (3TATUK)
Date: Thu, 12 Jul 2012 11:24:34 +0000
Subject: [pypy-issue] [issue1215] /pypy/config/support.py missing close()
In-Reply-To: <1342092121.65.0.768763903265.issue1215@bugs.pypy.org>
Message-ID: <1342092274.61.0.756855679376.issue1215@bugs.pypy.org>


3TATUK <ztatik.light at gmail.com> added the comment:

[patch attached]

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

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

From tracker at bugs.pypy.org  Thu Jul 12 15:36:17 2012
From: tracker at bugs.pypy.org (wbrana)
Date: Thu, 12 Jul 2012 13:36:17 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1342100177.31.0.692819591803.issue1198@bugs.pypy.org>


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

On Gentoo system flags are probably used, which now means -O3 -pipe 
-march=core2 on my PC.
Which assembler file do you need?
I have used GCC 4.5.4 instead of 4.4.7, but it failed with different error:
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "./pypy/translator/goal/translate.py", line 308, in 
main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/driver.py", line 791, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = 
self._maybe_skip())
[translation:ERROR]    File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/tool/taskengine.py", line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/driver.py", line 285, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/driver.py", line 575, in task_compile_c
[translation:ERROR]     cbuilder.compile(**kwds)
[translation:ERROR]    File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/genc.py", line 509, in compile
[translation:ERROR]     extra_opts)
[translation:ERROR]    File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/platform/posix.py", line 192, in 
execute_makefile
[translation:ERROR]     self._handle_error(returncode, stdout, stderr, 
path.join('make'))
[translation:ERROR]    File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/platform/__init__.py", line 138, in 
_handle_error
[translation:ERROR]     raise CompilationError(stdout, stderr)
[translation:ERROR]  CompilationError: CompilationError(err="""
[translation:ERROR] 	Traceback (most recent call last):
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py", line 2023, in 
<module>
[translation:ERROR] 	    tracker.process(f, g, filename=fn)
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py", line 1916, in 
process
[translation:ERROR] 	    tracker = parser.process_function(lines, 
filename)
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py", line 1431, in 
process_function
[translation:ERROR] 	    table = tracker.computegcmaptable(self.verbose)
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py", line 60, in 
computegcmaptable
[translation:ERROR] 	    self.trackgcroots()
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py", line 335, in 
trackgcroots
[translation:ERROR] 	    self.walk_instructions_backwards(walker, insn, 
loc)
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py", line 354, in 
walk_instructions_backwards
[translation:ERROR] 	    for prevstate in walker(insn, state):
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/trackgcroot.py", line 327, in walker
[translation:ERROR] 	    source = insn.source_of(loc, tag)
[translation:ERROR] 	  File "/mnt/md3/cache/portage/dev-python/pypy-1.9-
r1/work/pypy-1.9/pypy/translator/c/gcc/instruction.py", line 134, in 
source_of
[translation:ERROR] 	    (localvar,))
[translation:ERROR] 	AssertionError: must come from an argument to 
the function, got <-112;esp>
[translation:ERROR] 	make: *** [jit_backend_llsupport_rewrite.gcmap] 
Error 1
[translation:ERROR] 	""")

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

From tracker at bugs.pypy.org  Thu Jul 12 15:46:01 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 12 Jul 2012 13:46:01 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1342100761.35.0.431195145396.issue1198@bugs.pypy.org>


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

jit_backend_llsupport_rewrite.S and jit_backend_llsupport_rewrite.c please

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

From tracker at bugs.pypy.org  Thu Jul 12 15:46:22 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Thu, 12 Jul 2012 13:46:22 +0000
Subject: [pypy-issue] [issue1198] AssertionError: must come from an argument
	to the	function, got <-88; esp>
In-Reply-To: <1341147966.42.0.760059580074.issue1198@bugs.pypy.org>
Message-ID: <1342100782.78.0.410115555196.issue1198@bugs.pypy.org>


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

or however they're called, jit_backend_llsupport_rewrite.*

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

From tracker at bugs.pypy.org  Thu Jul 12 19:36:39 2012
From: tracker at bugs.pypy.org (Stian Andreassen)
Date: Thu, 12 Jul 2012 17:36:39 +0000
Subject: [pypy-issue] [issue819] Arithmetic is slower than CPython in
	extreme cases
In-Reply-To: <1312507550.8.0.20029796381.issue819@bugs.pypy.org>
Message-ID: <1342114599.58.0.591380359069.issue819@bugs.pypy.org>


Stian Andreassen <stian at tech1.org> added the comment:

I think the problem is all those extra operations, because even if mul gets
faster, we also have to compute several more things. Even with 10 million digits
karatsuba proved to be faster. I tried my points, your points, gmp's points, and
even those on wikipedia.

FFT will likely be faster, but for our current structure, toom-cook will likely
never be.

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

From tracker at bugs.pypy.org  Sat Jul 14 03:07:10 2012
From: tracker at bugs.pypy.org (Antimony)
Date: Sat, 14 Jul 2012 01:07:10 +0000
Subject: [pypy-issue] [issue1216] Range objects don't support getslice
In-Reply-To: <1342228030.65.0.121077206037.issue1216@bugs.pypy.org>
Message-ID: <1342228030.65.0.121077206037.issue1216@bugs.pypy.org>


New submission from Antimony <n210241048576 at gmail.com>:

When translating RPython, slicing is not supported on range objects, which I
find very strange. To reproduce, just try to translate a simple program like

def main(argv):
    print range(99)[1:-1]
    return 0

def target(driver, args):
    return main, None

----------
messages: 4585
nosy: Antimony, pypy-issue
priority: feature
release: 1.9
status: unread
title: Range objects don't support getslice

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

From tracker at bugs.pypy.org  Sat Jul 14 20:20:49 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 14 Jul 2012 18:20:49 +0000
Subject: [pypy-issue] [issue1216] Range objects don't support getslice
In-Reply-To: <1342228030.65.0.121077206037.issue1216@bugs.pypy.org>
Message-ID: <1342290049.35.0.550575469568.issue1216@bugs.pypy.org>


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

This is really a wontfix, unless you provide a patch. Not all kinds of slicing 
are supported.

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

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

From tracker at bugs.pypy.org  Sun Jul 15 06:24:08 2012
From: tracker at bugs.pypy.org (Antimony)
Date: Sun, 15 Jul 2012 04:24:08 +0000
Subject: [pypy-issue] [issue1216] Range objects don't support getslice
In-Reply-To: <1342290049.35.0.550575469568.issue1216@bugs.pypy.org>
Message-ID: <CALJjGisEHF_uoxkSeLAEacvqONBJwBH3TSxBMOMsP8f_tdC6Aw@mail.gmail.com>


Antimony <n210241048576 at gmail.com> added the comment:

How do I create and submit a patch?

On Sat, Jul 14, 2012 at 2:20 PM, Fijal <tracker at bugs.pypy.org> wrote:

>
> Fijal <fijall at gmail.com> added the comment:
>
> This is really a wontfix, unless you provide a patch. Not all kinds of
> slicing
> are supported.
>
> ----------
> nosy: +fijal
> status: unread -> chatting
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1216>
> ________________________________________
>

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

From tracker at bugs.pypy.org  Sun Jul 15 12:44:44 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sun, 15 Jul 2012 10:44:44 +0000
Subject: [pypy-issue] [issue1217] thread.atomic rename/split
In-Reply-To: <1342349084.25.0.862465385881.issue1217@bugs.pypy.org>
Message-ID: <1342349084.25.0.862465385881.issue1217@bugs.pypy.org>


New submission from Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>:

as discussed on irc the error potential of thread.atomic
requires 2 explicitly named primitives instead

* one for composable sections for use in datastructures for example
* one for noncomposable sections that are used
  to control parallelism/conflict potential
  and to generally avoid nesting things
  that shouldn't be nested

the preliminary names we came up with
are thread.composable_atomic and thread.explicit_atomic

----------
assignedto: arigo
messages: 4588
nosy: arigo, pypy-issue, ronny
priority: critical
status: unread
title: thread.atomic rename/split

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

From tracker at bugs.pypy.org  Sun Jul 15 14:56:02 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 15 Jul 2012 12:56:02 +0000
Subject: [pypy-issue] [issue901] *** glibc detected *** pypy: corrupted
	double-linked list:	0x000000000bd76de0 ***
In-Reply-To: <1318270602.56.0.17883229495.issue901@bugs.pypy.org>
Message-ID: <1342356962.76.0.577662691625.issue901@bugs.pypy.org>


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

Hi. It's impossible to say whether 2 releases later the code still works. Feel 
free to open a new bug if it does not, closing right now.

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

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

From tracker at bugs.pypy.org  Sun Jul 15 15:16:34 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 15 Jul 2012 13:16:34 +0000
Subject: [pypy-issue] [issue1207] latest Pypy *with JIT* fails with weird
	error running	pep8.py testsuite
In-Reply-To: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>
Message-ID: <1342358194.55.0.693891881482.issue1207@bugs.pypy.org>


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

Looks like a bug in unrolling and string ops. Eh.

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

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

From tracker at bugs.pypy.org  Mon Jul 16 16:18:34 2012
From: tracker at bugs.pypy.org (Vukasin Toroman)
Date: Mon, 16 Jul 2012 14:18:34 +0000
Subject: [pypy-issue] [issue1218] isodate is not able to parse iso format
	from	datetime.datetime's isoformat
In-Reply-To: <1342448314.11.0.272294494578.issue1218@bugs.pypy.org>
Message-ID: <1342448314.11.0.272294494578.issue1218@bugs.pypy.org>


New submission from Vukasin Toroman <vukasin at toroman.name>:

Output from datetime's isoformat function cannot be parsed using isodate. This is 
working when using cpython.


Output from CPython 2.7

Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import isodate
>>> import datetime
>>> s = datetime.datetime.utcnow().isoformat
>>> s = datetime.datetime.utcnow().isoformat()
>>> s
'2012-07-16T14:11:10.870930'
>>> isodate.parse_time(s)
datetime.time(20, 12, tzinfo=<FixedOffset '-07'>)
>>> isodate.parse_datetime(s)
datetime.datetime(2012, 7, 16, 14, 11, 10, 870930)
>>> 

Output from PyPy 1.9

Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``just another item (1.333...) on
our real-numbered todo list''
>>>> import datetime
>>>> datetime.datetime
<class 'datetime.datetime'>
>>>> datetime.datetime.now()
datetime.datetime(2012, 7, 16, 16, 9, 51, 418976)
>>>> datetime.datetime.utcnow()
datetime.datetime(2012, 7, 16, 14, 9, 57, 370114)
>>>> datetime.datetime.utcnow().isoformat()
'2012-07-16T14:10:05.114975'
>>>> s = datetime.datetime.utcnow().isoformat()
>>>> import isodate
>>>> isodate.parse_time(s)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Users/vukasin/Downloads/pypy-1.9/site-packages/isodate-0.4.8-
py2.7.egg/isodate/isotime.py", line 137, in parse_time
    microsecond.to_integral(), tzinfo)
  File "/Users/vukasin/Downloads/pypy-1.9/lib_pypy/datetime.py", line 1159, in 
__new__
    _check_time_fields(hour, minute, second, microsecond)
  File "/Users/vukasin/Downloads/pypy-1.9/lib_pypy/datetime.py", line 288, in 
_check_time_fields
    raise TypeError('int expected')
TypeError: int expected
>>>> isodate.parse_datetime(s)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Users/vukasin/Downloads/pypy-1.9/site-packages/isodate-0.4.8-
py2.7.egg/isodate/isodatetime.py", line 50, in parse_datetime
    tmptime = parse_time(timestring)
  File "/Users/vukasin/Downloads/pypy-1.9/site-packages/isodate-0.4.8-
py2.7.egg/isodate/isotime.py", line 131, in parse_time
    int(second), microsecond.to_integral(), tzinfo)
  File "/Users/vukasin/Downloads/pypy-1.9/lib_pypy/datetime.py", line 1159, in 
__new__
    _check_time_fields(hour, minute, second, microsecond)
  File "/Users/vukasin/Downloads/pypy-1.9/lib_pypy/datetime.py", line 288, in 
_check_time_fields
    raise TypeError('int expected')
TypeError: int expected

----------
messages: 4591
nosy: pypy-issue, vukasin
priority: bug
release: 1.9
status: unread
title: isodate is not able to parse iso format from datetime.datetime's isoformat

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

From tracker at bugs.pypy.org  Mon Jul 16 16:27:25 2012
From: tracker at bugs.pypy.org (Vukasin Toroman)
Date: Mon, 16 Jul 2012 14:27:25 +0000
Subject: [pypy-issue] [issue1218] isodate is not able to parse iso format
	from	datetime.datetime's isoformat
In-Reply-To: <1342448314.11.0.272294494578.issue1218@bugs.pypy.org>
Message-ID: <1342448845.52.0.995674606172.issue1218@bugs.pypy.org>


Vukasin Toroman <vukasin at toroman.name> added the comment:

Adding decimal.Decimal to the list of allowed types seems to fix it


 285 def _check_time_fields(hour, minute, second, microsecond):
 286     for value in [hour, minute, second, microsecond]:
 287         if not isinstance(value, (int, long, decimal.Decimal)):
 288             raise TypeError('int expected')
 289     if not 0 <= hour <= 23:

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

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

From tracker at bugs.pypy.org  Mon Jul 16 20:36:27 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Mon, 16 Jul 2012 18:36:27 +0000
Subject: [pypy-issue] [issue1207] latest Pypy *with JIT* fails with weird
	error running	pep8.py testsuite
In-Reply-To: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>
Message-ID: <1342463787.57.0.80463297473.issue1207@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

I digged a bit. It is the loop in run_check that messes up the arguments list. It 
might be some combination of list strategies and unrolling that's the cause. The 
issue does not show up in pypy-1.7 which is the latest release without list 
strategies. Minor changes to run_check hides the issue...

----------
nosy: +hakanardo

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

From tracker at bugs.pypy.org  Tue Jul 17 12:23:05 2012
From: tracker at bugs.pypy.org (Valery)
Date: Tue, 17 Jul 2012 10:23:05 +0000
Subject: [pypy-issue] [issue912] ZipFile.read() leaks file handles
In-Reply-To: <1318930736.76.0.381437213231.issue912@bugs.pypy.org>
Message-ID: <1342520585.54.0.369656765669.issue912@bugs.pypy.org>


Valery <khamenya at gmail.com> added the comment:

I've been successfully using the patch I'm attaching right now for more than 
half a year (http://bugs.python.org/issue13133). Unfortunately it seems to be 
lost since then (http://www.tismer.com/pypy/irc-logs/pypy/pypy.2011-10-
09.log.html). Anyway, you might want to use it in pypy/lib-python/2.7/zipfile.py

For example, this patch makes possible to successfully run things like 
"easy_install cython" that will fail on out-of-the-box pypy-1.9 without this 
patch.

----------
nosy: +vak

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

From tracker at bugs.pypy.org  Wed Jul 18 11:36:51 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 18 Jul 2012 09:36:51 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342604211.31.0.333303394102.issue1206@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

If you change "del self.__arr[:self.expected]" to "self.__arr = self.__arr[self.expected:]" 
then the code is only a factor 20x slower (instead of 1715x)

After making the above change I got these times:

time ~/pypy-latest/bin/pypy pypy_bug.py 
process size 2511188 kb
real	0m17.942s
user	0m14.875s
sys	0m3.064s

time python pypy_bug.py 
process size 2441100 kb
real	0m1.019s
user	0m0.998s
sys	0m0.018s

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

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

From tracker at bugs.pypy.org  Wed Jul 18 11:39:49 2012
From: tracker at bugs.pypy.org (Pigmej)
Date: Wed, 18 Jul 2012 09:39:49 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342604389.29.0.847647373817.issue1206@bugs.pypy.org>


Pigmej <jedrzej.nowak at codernity.com> added the comment:

Yeah sure, except that cpython version with that changes is also 2x times slower 
that that one with del instead of 'new object'.

Btw. I'm not sure if "20x" is "only"... (also please notice that the original 
slowdown isn't 1715x but 1715 x 2 => ~3400x)

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

From tracker at bugs.pypy.org  Wed Jul 18 17:05:35 2012
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Wed, 18 Jul 2012 15:05:35 +0000
Subject: [pypy-issue] [issue1219] float(bytearray('10.4')) fails
In-Reply-To: <1342623935.21.0.507709518402.issue1219@bugs.pypy.org>
Message-ID: <1342623935.21.0.507709518402.issue1219@bugs.pypy.org>


New submission from Antonio Cuni <anto.cuni at gmail.com>:

the following test fails on PyPy but works on CPython:

    def test_float(self):
        assert float(bytearray(b'10.4')) == 10.4

----------
messages: 4597
nosy: pypy-issue
priority: bug
status: unread
title: float(bytearray('10.4')) fails

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

From tracker at bugs.pypy.org  Thu Jul 19 03:25:20 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 19 Jul 2012 01:25:20 +0000
Subject: [pypy-issue] [issue1220] Improving readability of generated .c code
In-Reply-To: <1342661120.38.0.668326316485.issue1220@bugs.pypy.org>
Message-ID: <1342661120.38.0.668326316485.issue1220@bugs.pypy.org>


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

I'm attaching a patch which I believe significantly improves the readability of 
the C code that the translator emits.

Specifically, the patch:
  * adds comments to the generated C showing the corresponding RPython source 
code, *including* that of inlined functions.
  * attempts to reduce the spaghetti-like gotos of the blocks in a function by 
replaceing "goto" to a block with no 
predecessors with the block itself.  Doing so constructs a pleasing hierarchical 
structure that more closely resembles 
human-written sources.

This is a followup to an old mailing list post:
  http://codespeak.net/pipermail/pypy-dev/2010q4/006532.html
which covered showing the RPython sources in the generated C.
I've carried a similar patch to the one given there within my Fedora/EPEL PyPy 
rpms (see [1]), in which I tried to 
implement the source code for inlining by trying to capture a "source code 
location" for an operation as a stack of actual 
source locations (corresponding to inlining).
[1] http://pkgs.fedoraproject.org/gitweb/?p=pypy.git;a=blob;f=more-readable-c-
code.patch;h=92d340f69bdfb4837fce6c9cd7ab722bf9bdb9b9;hb=HEAD

However it never worked well, and not all operations are actually associated 
with source code e.g.:
  * "same_as" no-ops (see 
pypy/translator/backendopt/constfold.py:constant_diffuse)
  * gencapicall() within rtyper.py (e.g. generated "PyInt_AsLong()" call to get 
at a boxed int)
  * operations added by gctransform (e.g. reference counting, by 
pypy.rpython.memory.gctransform.refcounting.RefcountingGCTransformer)
  * exceptions added for handling exceptions 
(pypy.translator.exceptiontransform.LLTypeExceptionTransformer)

The alternative approach I came up with is to add a new kind of operation: 
OP_COMMENT/"comment", a no-op, added when we 
build the graph, and which gets turned into a comment in the generated source, 
which copes with inlining nicely (However, 
need to be careful not to thwart optimizations - for example, an earlier version 
of this patch defeated the switch-building 
detection in merge_if_blocks due to the extra ops).

My initial aim was to add one each time we change source line in the simple 
case, but to also add them for other 
transformations as appropriate.

I tried a few different places in which to inject the comment ops:
  * pypy.objspace.flow.flowcontext.BlockRecorder.bytecode_trace()
  * pypy.objspace.flow.flowcontext.FlowExecutionContext.bytecode_trace()
  * pypy.objspace.flow.objspace.FlowObjSpace.do_operation()
Doing it within one of the bytecode_trace() methods leads to very large numbers 
of comments (one per bytecode, whereas most 
bytecodes don't seem to directly generate SpaceOperations).  I tried reducing 
the number of comments by only emitting a 
comment when the line number changes, but I couldn't find a good place to store 
the current line: if I'm reading things 
correctly the flow objspace creates large numbers of small blocks which then get 
merged.

Adding them within do_operation() means that we only get one comment per 
"actual" SpaceOperation, so I went with this 
approach.

However, it means that we get non-equal results between the Recorder and 
Replayer classes, but I fixed this by filtering 
out comment ops when comparing the ops seen by Recorder and Replayer.

I added a new pass to simplify.py, to prune the comments per-block after the 
flowgraph is built, at the point where 
something resembling the final block structure has been reached - see the 
comment in the new pass.

Caveat: I haven't yet run the full test suite; doing that now

----------
files: more-readable-c-code-2012-07-18-001.patch
messages: 4598
nosy: dmalcolm, pypy-issue
priority: feature
status: unread
title: Improving readability of generated .c code

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

From tracker at bugs.pypy.org  Thu Jul 19 03:29:24 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 19 Jul 2012 01:29:24 +0000
Subject: [pypy-issue] [issue1220] Improving readability of generated .c code
In-Reply-To: <1342661120.38.0.668326316485.issue1220@bugs.pypy.org>
Message-ID: <1342661364.88.0.384175143268.issue1220@bugs.pypy.org>


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

I'm attaching an example of the generated source.  Notice how the C source 
contains embedded comments with the RPython source, showing inlined functions in-
place, and how the block structure uses some nesting (rather than a flat list of 
blocks that goto each other).

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

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

From tracker at bugs.pypy.org  Thu Jul 19 03:36:27 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 19 Jul 2012 01:36:27 +0000
Subject: [pypy-issue] [issue1220] Improving readability of generated .c code
In-Reply-To: <1342661120.38.0.668326316485.issue1220@bugs.pypy.org>
Message-ID: <1342661787.85.0.182382886848.issue1220@bugs.pypy.org>


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

[Note to self: I was tracking this downstream as 
https://bugzilla.redhat.com/show_bug.cgi?id=666963 ]

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

From tracker at bugs.pypy.org  Thu Jul 19 08:01:02 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Thu, 19 Jul 2012 06:01:02 +0000
Subject: [pypy-issue] [issue1207] latest Pypy *with JIT* fails with weird
	error running	pep8.py testsuite
In-Reply-To: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>
Message-ID: <1342677662.6.0.403678304979.issue1207@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

I believe this was fixed by 5fcf9d1c9713. Latest nightly build runs the pep8 
tests just fine. It turned out to be neither unrolling, list strategies nor 
string optimization. Instead it was a corner case treated badly by our guard 
strengthening optimization.

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

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

From tracker at bugs.pypy.org  Thu Jul 19 09:48:35 2012
From: tracker at bugs.pypy.org (Florent Xicluna)
Date: Thu, 19 Jul 2012 07:48:35 +0000
Subject: [pypy-issue] [issue1207] latest Pypy *with JIT* fails with weird
	error running	pep8.py testsuite
In-Reply-To: <1341665523.6.0.395495042293.issue1207@bugs.pypy.org>
Message-ID: <1342684115.0.0.532209436547.issue1207@bugs.pypy.org>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It seems OK. Thanks.

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

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

From tracker at bugs.pypy.org  Thu Jul 19 17:18:46 2012
From: tracker at bugs.pypy.org (Dave Malcolm)
Date: Thu, 19 Jul 2012 15:18:46 +0000
Subject: [pypy-issue] [issue1221] raw_input() returns unicode, not str
In-Reply-To: <1342711126.0.0.255155578889.issue1221@bugs.pypy.org>
Message-ID: <1342711126.0.0.255155578889.issue1221@bugs.pypy.org>


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

For a translated build of PyPy 1.9, raw_input() is returning a unicode, and on IRC people confirmed that this was 
also seen with nightly.

However, with untranslated (56219:c8cdf66b371a) it returns a str, which is what CPython returns.

This breaks the commands within help(), e.g. "modules", making it show help on the unicode type, rather than a list 
of modules, due to this conditional in lib-python/2.7/pydoc.py:Helper.help failing:
   if type(request) is type(''):

[reported downstream as https://bugzilla.redhat.com/show_bug.cgi?id=841546]

----------
messages: 4603
nosy: dmalcolm, pypy-issue
priority: bug
status: unread
title: raw_input() returns unicode, not str

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

From tracker at bugs.pypy.org  Fri Jul 20 11:33:28 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Fri, 20 Jul 2012 09:33:28 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342776808.72.0.665618885613.issue1206@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

After chatting with fijal on irc, it appears that the array implementation of 
delitem is a bit of a hack i.e. the array is converted to a list, then an item is 
deleted from the list, and then the list is turned back into an array.

See pypy/module/array/interp_array.py delitem__Array_ANY() which starts with the 
comment "# XXX this is a giant slow hack"

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

From tracker at bugs.pypy.org  Fri Jul 20 14:34:59 2012
From: tracker at bugs.pypy.org (serge_sans_paille)
Date: Fri, 20 Jul 2012 12:34:59 +0000
Subject: [pypy-issue] [issue1222] Performance issue
In-Reply-To: <1342787699.76.0.562283880321.issue1222@bugs.pypy.org>
Message-ID: <1342787699.76.0.562283880321.issue1222@bugs.pypy.org>


New submission from serge_sans_paille <serge.guelton at telecom-bretagne.eu>:

Attached file runs slightly slower under pypy than under python. That's not a
critical performance difference, but the code is rather simple too.

----------
files: extrema.py
messages: 4605
nosy: pypy-issue, serge_sans_paille
priority: performance bug
status: unread
title: Performance issue

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

From tracker at bugs.pypy.org  Fri Jul 20 16:34:17 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 20 Jul 2012 14:34:17 +0000
Subject: [pypy-issue] [issue1222] Performance issue
In-Reply-To: <1342787699.76.0.562283880321.issue1222@bugs.pypy.org>
Message-ID: <1342794857.68.0.325903296699.issue1222@bugs.pypy.org>


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

So, this is slow because you end up with tons of small loops.  If you replace 
`zip` with `itertools.izip` it gets way faster (on CPython as well, but not by as 
much).  Changing it to http://bpaste.net/show/uiOOJr5SrPSIX80PtyI7/ gives you 
another 2x speedup.  It's a giant hack though, I'm still trying to figure out 
if/how we can improve

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

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

From tracker at bugs.pypy.org  Fri Jul 20 17:24:15 2012
From: tracker at bugs.pypy.org (serge_sans_paille)
Date: Fri, 20 Jul 2012 15:24:15 +0000
Subject: [pypy-issue] [issue1222] Performance issue
In-Reply-To: <1342787699.76.0.562283880321.issue1222@bugs.pypy.org>
Message-ID: <1342797855.03.0.0698014280646.issue1222@bugs.pypy.org>


serge_sans_paille <serge.guelton at telecom-bretagne.eu> added the comment:

Right. It seems to me that pypy could detect that this zip yields a temporary
value and could be replaced by a izip. The same applies to map as well.

What do you think of it?

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

From tracker at bugs.pypy.org  Fri Jul 20 18:25:56 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Fri, 20 Jul 2012 16:25:56 +0000
Subject: [pypy-issue] [issue1222] Performance issue
In-Reply-To: <1342787699.76.0.562283880321.issue1222@bugs.pypy.org>
Message-ID: <1342801556.22.0.53676613891.issue1222@bugs.pypy.org>


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

Unfortunately that's not very likely to happen. The JIT has no idea that the 
result of zip() won't be used at the time it sees that it's creating a list.

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

From tracker at bugs.pypy.org  Sat Jul 21 07:18:17 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Sat, 21 Jul 2012 05:18:17 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342847897.04.0.564841916193.issue1206@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

I implemented delitem and delslice on array without delegating to list "array-
delitem" branch here https://bitbucket.org/kostialopuhin/pypy - will add more 
tests and try to translate pypy to test performance on Monday.

----------
nosy: +kostia.lopuhin

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

From tracker at bugs.pypy.org  Sat Jul 21 12:53:08 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 21 Jul 2012 10:53:08 +0000
Subject: [pypy-issue] [issue1221] raw_input() returns unicode, not str
In-Reply-To: <1342711126.0.0.255155578889.issue1221@bugs.pypy.org>
Message-ID: <1342867988.89.0.365486938763.issue1221@bugs.pypy.org>


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

Fixed in pyrepl repo (e123d5cc94ce) and pypy (87df70952d8e). Thanks for the 
report!

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

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

From tracker at bugs.pypy.org  Sat Jul 21 14:25:15 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 21 Jul 2012 12:25:15 +0000
Subject: [pypy-issue] [issue1220] Improving readability of generated .c code
In-Reply-To: <1342661120.38.0.668326316485.issue1220@bugs.pypy.org>
Message-ID: <1342873515.41.0.346665446979.issue1220@bugs.pypy.org>


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

In general, +100.
Can you create a branch and commit your patch there?

I have some remarks already, but nothing crucial:
- I'm a bit concerned by the increased memory usage. Those 'comment' operations could be controlled by a 
translation option.
- Generated C source code is more indented than before. That's an improvement of course, but maybe the tabs 
should be replaced by 4 spaces.
- RPython source lines in comments have too much spaces on the left.
- RPython source file name should be relative (to pypy root dir). I'm not sure I want to show the directory 
structure of my local machine.

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

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

From tracker at bugs.pypy.org  Sat Jul 21 14:30:39 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 21 Jul 2012 12:30:39 +0000
Subject: [pypy-issue] [issue1222] Performance issue
In-Reply-To: <1342787699.76.0.562283880321.issue1222@bugs.pypy.org>
Message-ID: <1342873839.68.0.400456551594.issue1222@bugs.pypy.org>


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

What can however be done is unrolling of small loops. That would help quite a 
bit.

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

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

From tracker at bugs.pypy.org  Sat Jul 21 14:33:12 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 21 Jul 2012 12:33:12 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342873992.12.0.685358645344.issue1206@bugs.pypy.org>


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

Hi Kostia. This requires at least tons of new tests - look how convoluted is the 
logic for deleting all cases from a list - objspace/std/listobject.py

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

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

From tracker at bugs.pypy.org  Sat Jul 21 17:16:29 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 21 Jul 2012 15:16:29 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342883789.38.0.816473279808.issue1206@bugs.pypy.org>


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

Maybe it's a lot of work, but could the array module be based on lists 
internally?  How different is an array(typecode='i') from a list with a 
IntegerListStrategy?  The overallocation strategy?

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

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

From tracker at bugs.pypy.org  Sat Jul 21 20:31:46 2012
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sat, 21 Jul 2012 18:31:46 +0000
Subject: [pypy-issue] [issue1175] PyThread_{get, set,
	delete}_key_value should work without the GIL held
In-Reply-To: <1339600555.37.0.297373234943.issue1175@bugs.pypy.org>
Message-ID: <1342895506.01.0.296477111494.issue1175@bugs.pypy.org>


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

Makes sense indeed, the RPython functions were only wrappers around the RPy 
primitives.
Patch applied with 531f677554ee, after minor formatting changes.
Thanks a lot for your contribution!

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

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

From tracker at bugs.pypy.org  Sun Jul 22 17:05:08 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Sun, 22 Jul 2012 15:05:08 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342969508.54.0.905625269674.issue1206@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

Hi Fijal! It seems to me that all the actual work of deleting elements from the 
list is done in AbstractUnwrappedStrategy.delslice method, starting at line 885 
in objspace/std/listobject.py. And I basically copied the logic from here - I 
hope it will be possible to share it between lists and arrays. And I hope it 
will be possible to reuse tests too, for now I just added some that seemed to 
make sense. By tests you mean just testing all different slice cases, and 
checking that the result has the proper value, or something more complex?

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

From tracker at bugs.pypy.org  Sun Jul 22 17:06:36 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 22 Jul 2012 15:06:36 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342969596.84.0.331324983539.issue1206@bugs.pypy.org>


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

Yes, by tests I mean that. Copy is bad, maybe we can look into reusing code more 
(like abstract a helper somewhere or something).

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

From tracker at bugs.pypy.org  Sun Jul 22 17:17:10 2012
From: tracker at bugs.pypy.org (Carl Friedrich Bolz)
Date: Sun, 22 Jul 2012 15:17:10 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1342970230.49.0.992173929669.issue1206@bugs.pypy.org>


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

Amaury: Yes, ideally the two could share almost all code. An array with type i
is just a list with int strategy where you're not allowed to change the
strategy. Would be some work, though.

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

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

From tracker at bugs.pypy.org  Mon Jul 23 19:21:31 2012
From: tracker at bugs.pypy.org (teepark)
Date: Mon, 23 Jul 2012 17:21:31 +0000
Subject: [pypy-issue] [issue1223] throwing GreenletExit into a running
	greenlet doesn't	kill it
In-Reply-To: <1343064091.98.0.0389921329381.issue1223@bugs.pypy.org>
Message-ID: <1343064091.98.0.0389921329381.issue1223@bugs.pypy.org>


New submission from teepark <travis.parker at gmail.com>:

greenlet_instance.throw(GreenletExit()) is not causing the target greenlet to 
exit, rather it is essentially an equivalent to greenlet_instance.switch().

it does the right thing if the greenlet_instance has not yet been switch()ed to.

----------
files: pypy_greenlet_repro.py
messages: 4619
nosy: pypy-issue, teepark
priority: bug
status: unread
title: throwing GreenletExit into a running greenlet doesn't kill it

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

From tracker at bugs.pypy.org  Mon Jul 23 22:29:08 2012
From: tracker at bugs.pypy.org (teepark)
Date: Mon, 23 Jul 2012 20:29:08 +0000
Subject: [pypy-issue] [issue833] missing functions in the os module
In-Reply-To: <1313691639.0.0.0533098212019.issue833@bugs.pypy.org>
Message-ID: <1343075348.58.0.714030832397.issue833@bugs.pypy.org>


teepark <travis.parker at gmail.com> added the comment:

another update to this list, from cpython 2.7.3 and pypy 1.9:
'setresgid',
'confstr',
'getresgid',
'tcsetpgrp',
'statvfs',
'pathconf',
'initgroups',
'fchown',
'getresuid',
'fchmod',
'setresuid',
'confstr_names',
'setgroups',
'tcgetpgrp',
'fstatvfs',
'ctermid',
'statvfs_result'

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

From tracker at bugs.pypy.org  Tue Jul 24 09:36:23 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Tue, 24 Jul 2012 07:36:23 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1343115383.08.0.710758081788.issue1206@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

pypy translated with --opt=2 from array-delitem branch 
https://bitbucket.org/kostialopuhin/pypy/src/8c30ee44beab is still 10x slower 
than CPython 2.7 on unmodified pypy_bug.py. I removed code duplication of slice 
deletion, will also remove code duplication from tests, but I wont be able to 
unite array and list in foreseeable future)

I can't figure out how to make a small standalone target to test array module 
translated, is it possible?

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

From tracker at bugs.pypy.org  Tue Jul 24 10:50:58 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 24 Jul 2012 08:50:58 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1343119858.84.0.0499364381566.issue1206@bugs.pypy.org>


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

-O2 will be slower than cpython. Not sure if 10x is the right figure though. I'll 
have a look. You cannot translate just the array module, the next best is --no-
allworkingmodules --withmod-array (will give you just array from modules). Don't 
worry about code duplication in tests btw.

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

From tracker at bugs.pypy.org  Tue Jul 24 11:00:26 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 24 Jul 2012 09:00:26 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1343120426.07.0.873339528963.issue1206@bugs.pypy.org>


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

I agree that reusing IntegerListStrategy (and creating tons of extra strategies
for the other sizes) would seem like a good idea.

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

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

From tracker at bugs.pypy.org  Tue Jul 24 12:26:12 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 24 Jul 2012 10:26:12 +0000
Subject: [pypy-issue] [issue1224] "x**2" for longs
In-Reply-To: <1343125572.43.0.130914485528.issue1224@bugs.pypy.org>
Message-ID: <1343125572.43.0.130914485528.issue1224@bugs.pypy.org>


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

We already special-case "x**2" for ints and (I think) for floats, but not for
longs.  Replacing the expression "x**2" with "x*x" yields huge performance
improvements so far.

----------
messages: 4624
nosy: arigo, pypy-issue
priority: performance bug
status: unread
title: "x**2" for longs

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

From tracker at bugs.pypy.org  Tue Jul 24 12:32:26 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 24 Jul 2012 10:32:26 +0000
Subject: [pypy-issue] [issue1224] "x**2" for longs
In-Reply-To: <1343125572.43.0.130914485528.issue1224@bugs.pypy.org>
Message-ID: <1343125946.46.0.890957202216.issue1224@bugs.pypy.org>


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

This is already done in improve-rbiging, closing as duplicate

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

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

From tracker at bugs.pypy.org  Wed Jul 25 10:43:19 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Wed, 25 Jul 2012 08:43:19 +0000
Subject: [pypy-issue] [issue1206] Extreme slowdown of code part
	(array.array) operations
In-Reply-To: <1341577202.74.0.370893172329.issue1206@bugs.pypy.org>
Message-ID: <1343205799.06.0.860402871445.issue1206@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

After using memmove to move array items (instead of moving them in a loop) pypy 
translated with --opt=jit is on par with CPython (the difference is below 
variation). So now I only want to find out what is meant by *huge* number of 
elements here 
https://bitbucket.org/pypy/pypy/src/606d6a6c708f/pypy/rpython/lltypesystem/rffi.
py#cl-1109

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

From tracker at bugs.pypy.org  Sat Jul 28 11:13:20 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 28 Jul 2012 09:13:20 +0000
Subject: [pypy-issue] [issue1162] Abort with OpenSSL and threads
In-Reply-To: <1339346582.88.0.843743823045.issue1162@bugs.pypy.org>
Message-ID: <1343466800.33.0.867051536989.issue1162@bugs.pypy.org>


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

It seems to always work with the patch from issue 1175 applied, which is now in
trunk.  Can we close this as resolved?

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

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

From tracker at bugs.pypy.org  Sat Jul 28 11:46:07 2012
From: tracker at bugs.pypy.org (Tobias Oberstein)
Date: Sat, 28 Jul 2012 09:46:07 +0000
Subject: [pypy-issue] [issue1162] Abort with OpenSSL and threads
In-Reply-To: <1339346582.88.0.843743823045.issue1162@bugs.pypy.org>
Message-ID: <1343468767.67.0.0187345388119.issue1162@bugs.pypy.org>


Tobias Oberstein <tobias.oberstein at gmail.com> added the comment:

Yep. The patch from 1175 resolved this.

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

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

From tracker at bugs.pypy.org  Mon Jul 30 22:40:17 2012
From: tracker at bugs.pypy.org (ita)
Date: Mon, 30 Jul 2012 20:40:17 +0000
Subject: [pypy-issue] [issue1225] simple deadlock with subprocess and threads
In-Reply-To: <1343680817.39.0.473179498819.issue1225@bugs.pypy.org>
Message-ID: <1343680817.39.0.473179498819.issue1225@bugs.pypy.org>


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

The testcase will hang on Linux 64 with pypy 1.9 or nightly and with or without jit.

Run the script a few times, pypy will not reply to CTRL+C and zombies will be
present in the process table:
www      19418  2.6  0.6 444564 20740 pts/2    Sl+  22:37   0:01
/home/d/pypy-c-jit-56501-6bb09a17e2aa-linux64/bin/pypy hh.py
www      19789  0.0  0.0      0     0 pts/2    Z+   22:37   0:00 [sh] <defunct>
www      19790  0.0  0.4 444564 13836 pts/2    S+   22:37   0:00
/home/d/pypy-c-jit-56501-6bb09a17e2aa-linux64/bin/pypy hh.py

----------
messages: 4629
nosy: ita, pypy-issue
priority: bug
status: unread
title: simple deadlock with subprocess and threads

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

From tracker at bugs.pypy.org  Mon Jul 30 23:11:58 2012
From: tracker at bugs.pypy.org (David Ripton)
Date: Mon, 30 Jul 2012 21:11:58 +0000
Subject: [pypy-issue] [issue1225] simple deadlock with subprocess and threads
In-Reply-To: <1343680817.39.0.473179498819.issue1225@bugs.pypy.org>
Message-ID: <1343682718.76.0.0324764550796.issue1225@bugs.pypy.org>


David Ripton <d+pypy at ripton.net> added the comment:

I could not get it to hang on Ubuntu 12.04 64-bit with PyPy 1.9.

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

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

From tracker at bugs.pypy.org  Mon Jul 30 23:16:43 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 30 Jul 2012 21:16:43 +0000
Subject: [pypy-issue] [issue1225] simple deadlock with subprocess and threads
In-Reply-To: <1343680817.39.0.473179498819.issue1225@bugs.pypy.org>
Message-ID: <1343683003.15.0.804117675185.issue1225@bugs.pypy.org>


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

This also deadlocks on CPython 2.7.2 for me. I suppose subprocess might be doing 
something funky somehow? Closing as invalid.

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

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

From tracker at bugs.pypy.org  Mon Jul 30 23:19:57 2012
From: tracker at bugs.pypy.org (ita)
Date: Mon, 30 Jul 2012 21:19:57 +0000
Subject: [pypy-issue] [issue1225] simple deadlock with subprocess and threads
In-Reply-To: <1343680817.39.0.473179498819.issue1225@bugs.pypy.org>
Message-ID: <1343683197.81.0.449718037282.issue1225@bugs.pypy.org>


ita <tnagy1024 at gmail.com> added the comment:

Closing too fast, cpython 2.7.2 has another unrelated bug
http://bugs.python.org/issue13156

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

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