From tracker at bugs.pypy.org  Tue Jan  1 17:37:21 2013
From: tracker at bugs.pypy.org (Simon Sapin)
Date: Tue, 01 Jan 2013 16:37:21 +0000
Subject: [pypy-issue] [issue1357] lxml not returning the same proxy object.
In-Reply-To: <1357058241.79.0.786347102061.issue1357@bugs.pypy.org>
Message-ID: <1357058241.79.0.786347102061.issue1357@bugs.pypy.org>


New submission from Simon Sapin <simon.sapin at kozea.fr>:

(Reported here because I?ve never seen this bug on CPython.)
WeasyPrint uses lxml with some code that, much simplified, looks like this:

    style_by_element = {}
    for element in tree.iter():
        parent_style = style_by_element[element.getparent()]
        style_by_element[element] = compute_style(element, parent_style)

This code relies on a guarantee documented in lxml:

http://lxml.de/element_classes.html#element-initialization

> There is one important guarantee regarding Element proxies. Once a proxy has
been instantiated, it will keep alive as long as there is a Python reference to
it, and any access to the XML element in the tree will return this very instance.

However, this is not always the case with lxml on PyPy 2.0.0-beta1.
Semi-randomly, the code above will raise a KeyError. Apparently,
element.getparent() sometimes does not return the same Python proxy object that
was previously yielded by tree.iter() for the parent node.

Very small documents (as in the test suite) will render without issues. Bigger
documents will reliably fail, but not always on the same element.
`len(style_by_element)` on failure goes from dozens to low hundreds.

Unfortunately I?m not sure how to make a smaller test case that "try the cffi
branch of WeasyPrint" https://github.com/Kozea/WeasyPrint/tree/cffi

----------
messages: 5118
nosy: SimonSapin, pypy-issue
priority: bug
status: unread
title: lxml not returning the same proxy object.

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

From tracker at bugs.pypy.org  Wed Jan  2 12:04:26 2013
From: tracker at bugs.pypy.org (Simon Sapin)
Date: Wed, 02 Jan 2013 11:04:26 +0000
Subject: [pypy-issue] [issue1357] lxml not returning the same proxy object.
In-Reply-To: <1357058241.79.0.786347102061.issue1357@bugs.pypy.org>
Message-ID: <1357124666.8.0.308886384174.issue1357@bugs.pypy.org>


Simon Sapin <simon.sapin at kozea.fr> added the comment:

Might be relevant:
https://github.com/lxml/lxml/blob/e01a81740c77/src/lxml/proxy.pxi#L7

# In PyPy, we store weak references instead of borrowed back-pointer
# references as borrowed references cannot be long-lived in its
# compatibility layer cpyext. Since we can't know when the object dies
# (and even the weak-ref callback won't tell us that), we double check
# on access that the object really is still alive and delete the
# weak-ref if it isn't.

Also: http://www.mail-archive.com/pypy-dev at python.org/msg02019.html

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

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

From tracker at bugs.pypy.org  Thu Jan  3 10:13:58 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Thu, 03 Jan 2013 09:13:58 +0000
Subject: [pypy-issue] [issue1358] test failure x2 of sphinx's test_autodoc.py
In-Reply-To: <1357204438.8.0.21537229791.issue1358@bugs.pypy.org>
Message-ID: <1357204438.8.0.21537229791.issue1358@bugs.pypy.org>


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

2 minor failures isn't bad here.

 * Testing of dev-python/sphinx-1.1.3-r3 with PyPy 1.9 (Python 2.7)...
PYTHONPATH=lib nosetests --verbosity=1
....F...F............................................................................................................................................................................................SS......................
======================================================================
FAIL: test_autodoc.test_format_signature
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/pypy1.9/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File
"/mnt/gen2/TmpDir/portage/dev-python/sphinx-1.1.3-r3/work/Sphinx-1.1.3/build-2.7-pypy-1.9/tests/test_autodoc.py",
line 158, in test_format_signature
    assert formatsig('class', 'D', C, None, None) == ''
AssertionError

======================================================================
FAIL: test_autodoc.test_generate
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/pypy1.9/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File
"/mnt/gen2/TmpDir/portage/dev-python/sphinx-1.1.3-r3/work/Sphinx-1.1.3/build-2.7-pypy-1.9/tests/test_autodoc.py",
line 472, in test_generate
    all_members=True)
  File
"/mnt/gen2/TmpDir/portage/dev-python/sphinx-1.1.3-r3/work/Sphinx-1.1.3/build-2.7-pypy-1.9/tests/test_autodoc.py",
line 360, in assert_result_contains
    assert item in directive.result
AssertionError

----------------------------------------------------------------------
Ran 221 tests in 161.875s

FAILED (SKIP=2, failures=2)
 * ERROR: dev-python/sphinx-1.1.3-r3 failed (test phase):
 *   Testing failed with PyPy 1.9 (Python 2.7) in testing() function
 * 

sphinx version is 1.1.3 cited already in output above.
Do you require a full build log?

----------
assignedto: fijal
messages: 5120
nosy: fijal, idella5, pypy-issue
priority: bug
release: 1.9
status: chatting
title: test failure x2 of sphinx's test_autodoc.py

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

From tracker at bugs.pypy.org  Thu Jan  3 17:41:13 2013
From: tracker at bugs.pypy.org (Joe Hillenbrand)
Date: Thu, 03 Jan 2013 16:41:13 +0000
Subject: [pypy-issue] [issue1359] SEGFAULT when running Scrapy tests.
In-Reply-To: <1357231273.48.0.879121182669.issue1359@bugs.pypy.org>
Message-ID: <1357231273.48.0.879121182669.issue1359@bugs.pypy.org>


New submission from Joe Hillenbrand <joehillen at gmail.com>:

This happens with the latest 2.0beta1 release and the current tip of the hg repo
(29b8abf6816b)

To reproduce, run:

$ git clone git://github.com/scrapy/scrapy.git
$ cd scrapy
$ /opt/pypy-dev/bin/pypy setup.py install
$ /opt/pypy-dev/bin/trial scrapy/tests/test_http_request.py
scrapy.tests.test_http_request
  FormRequestTest
    test_ajax_url ...                                                      [OK]
    test_body ...                                                          [OK]
    test_copy ...                                                          [OK]
    test_copy_inherited_classes ...                                        [OK]
    test_custom_encoding ...                                               [OK]
    test_default_encoding ...                                              [OK]
    test_empty_formdata ...                                                [OK]
    test_eq ...                                                            [OK]
    test_from_response_ambiguous_clickdata ... Segmentation fault (core dumped)

----------
messages: 5121
nosy: joehillen, pypy-issue
priority: bug
release: 2.0
status: unread
title: SEGFAULT when running Scrapy tests.

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

From tracker at bugs.pypy.org  Sat Jan  5 20:59:33 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 05 Jan 2013 19:59:33 +0000
Subject: [pypy-issue] [issue1359] SEGFAULT when running Scrapy tests.
In-Reply-To: <1357231273.48.0.879121182669.issue1359@bugs.pypy.org>
Message-ID: <1357415973.75.0.465092738451.issue1359@bugs.pypy.org>


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

Hi.

We fixed some JIT bugs in XML processing. Can you try with tomorrow nightly?

Cheers,
fijal

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

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

From tracker at bugs.pypy.org  Sun Jan  6 02:39:46 2013
From: tracker at bugs.pypy.org (Aaron Iles)
Date: Sun, 06 Jan 2013 01:39:46 +0000
Subject: [pypy-issue] [issue1360] type.__new__ is not a builtin function or
	method
In-Reply-To: <1357436386.19.0.942054735241.issue1360@bugs.pypy.org>
Message-ID: <1357436386.19.0.942054735241.issue1360@bugs.pypy.org>


New submission from Aaron Iles <aaron.iles+pypy at gmail.com>:

The type of the type object's __new__ method differs between Python2 and PyPy. 
This causes the unit tests for Python3.3's function signatures tools to fail if 
backported to 2.7.

$ python2.7
Python 2.7.3 (default, Sep 18 2012, 21:28:33) 
[GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> type(type.__new__)
<type 'builtin_function_or_method'>
>>>

$ pypy
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: ``happy PyPy's year 2010!''
>>> type(type.__new__)
<type 'function'>
>>>

----------
messages: 5123
nosy: aliles, pypy-issue
priority: bug
status: unread
title: type.__new__ is not a builtin function or method

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

From tracker at bugs.pypy.org  Sun Jan  6 11:03:09 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sun, 06 Jan 2013 10:03:09 +0000
Subject: [pypy-issue] [issue1360] type.__new__ is not a builtin function or
	method
In-Reply-To: <1357436386.19.0.942054735241.issue1360@bugs.pypy.org>
Message-ID: <1357466589.88.0.27073657529.issue1360@bugs.pypy.org>


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

This is a documented difference between pypy and cpython - we have less of a zoo 
of builtin functions vs normal functions. I suggest you fix it some other way.

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

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

From tracker at bugs.pypy.org  Sun Jan  6 11:13:13 2013
From: tracker at bugs.pypy.org (Aaron Iles)
Date: Sun, 06 Jan 2013 10:13:13 +0000
Subject: [pypy-issue] [issue1360] type.__new__ is not a builtin function or
	method
In-Reply-To: <1357436386.19.0.942054735241.issue1360@bugs.pypy.org>
Message-ID: <1357467193.06.0.236610878682.issue1360@bugs.pypy.org>


Aaron Iles <aaron.iles+pypy at gmail.com> added the comment:

Is this documented in the 'Differences between PyPy and CPython' section of the 
official docs? I wasn't able to spot it. Regardless, if it's a documented 
difference this issue can be closed.

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

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

From tracker at bugs.pypy.org  Mon Jan  7 11:16:05 2013
From: tracker at bugs.pypy.org (Alexander Raud)
Date: Mon, 07 Jan 2013 10:16:05 +0000
Subject: [pypy-issue] [issue1361] pypy.rlib.entrypoint doesn't make function
	exported on	Windows
In-Reply-To: <1357553765.06.0.407417738168.issue1361@bugs.pypy.org>
Message-ID: <1357553765.06.0.407417738168.issue1361@bugs.pypy.org>


New submission from Alexander Raud <araud at mail.ru>:

Hi!

To reproduce, please translate on _Windows_ attached file with command: "--
shared --entrypoints=API my_lang.py"

Function with decorator @entrypoint("API", [], c_name='test_function') is 
created, but not exported as secondary entry point.

(In Windows symbols are not exported by default, like in Linux)

Please contact me if it takes more details.

With respect, Alexander.

----------
files: my_lang.py
messages: 5126
nosy: araud, pypy-issue
priority: bug
status: unread
title: pypy.rlib.entrypoint doesn't make function exported on Windows

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1361>
________________________________________
-------------- next part --------------
import sys
from pypy.rlib.entrypoint import entrypoint

def entry_point(argv):
    print "hello!"
    return 0

def target(*args):
    return entry_point, None

@entrypoint("API", [], c_name='test_function')
def test_function():
    return 1

if __name__ == "__main__":
    entry_point(sys.argv)

From tracker at bugs.pypy.org  Mon Jan  7 16:46:04 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 15:46:04 +0000
Subject: [pypy-issue] [issue1361] pypy.rlib.entrypoint doesn't make function
	exported on	Windows
In-Reply-To: <1357553765.06.0.407417738168.issue1361@bugs.pypy.org>
Message-ID: <1357573564.32.0.132790147631.issue1361@bugs.pypy.org>


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

entrypoint() doesn't indeed create any eci with 'export_symbols'.  In cpyext it
is done independently.  Should we make entrypoint() also produce an eci?  And
should we then go and remove it from cpyext, or just declare that it will be
redundant but not harmful?

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

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

From tracker at bugs.pypy.org  Mon Jan  7 16:50:27 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 15:50:27 +0000
Subject: [pypy-issue] [issue1356] Casting a str into a ctype pointer fails
In-Reply-To: <1356992181.13.0.18696778854.issue1356@bugs.pypy.org>
Message-ID: <1357573827.99.0.0874986584853.issue1356@bugs.pypy.org>


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

Uh, I had no clue you could do that.  I can think of no way to make it work in
PyPy, sorry.  How about you special-case that code for CPython versus PyPy?  We
could make it work on PyPy using a pile of slow hacks, but I guess slowness is
precisely what the code is trying to avoid.  On PyPy just use pure Python, e.g.
a for loop grabbing character pairs and doing some arithmetic on the ord's.

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

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

From tracker at bugs.pypy.org  Mon Jan  7 17:17:26 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 16:17:26 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1357575446.67.0.565539200346.issue1236@bugs.pypy.org>


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

Tried with the latest trunk (pypy-c-jit-59828-4d436d0b7748-linux, Linux 32-bit).
 It works for me, even when I connect the web browser to it and reload the page
continously.

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

From tracker at bugs.pypy.org  Mon Jan  7 17:18:15 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 16:18:15 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1357575495.03.0.0539516252346.issue1236@bugs.pypy.org>


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

Note that the branch 'remove-globals-in-jit' was merged into trunk a few days
ago, so my test includes it.

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

From tracker at bugs.pypy.org  Mon Jan  7 17:19:43 2013
From: tracker at bugs.pypy.org (bloodmage)
Date: Mon, 07 Jan 2013 16:19:43 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1357575583.25.0.0473443965365.issue1236@bugs.pypy.org>


bloodmage <zhouyisu at gmail.com> added the comment:

It will work once or two.
I'm trying to use apache benchmark tool to do a massive connection benchmark, 
and then error occurs.

Try following command several times:

ab -n 1000 -c 10 http://localhost:8090/

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

From tracker at bugs.pypy.org  Mon Jan  7 17:20:11 2013
From: tracker at bugs.pypy.org (bloodmage)
Date: Mon, 07 Jan 2013 16:20:11 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1357575611.35.0.909768854538.issue1236@bugs.pypy.org>


bloodmage <zhouyisu at gmail.com> added the comment:

OK I will try it.

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

From tracker at bugs.pypy.org  Mon Jan  7 17:49:58 2013
From: tracker at bugs.pypy.org (bloodmage)
Date: Mon, 07 Jan 2013 16:49:58 +0000
Subject: [pypy-issue] [issue1236] Pypy eventlet crash
In-Reply-To: <1345308975.75.0.362732851791.issue1236@bugs.pypy.org>
Message-ID: <1357577398.54.0.495867767294.issue1236@bugs.pypy.org>


bloodmage <zhouyisu at gmail.com> added the comment:

I tried to use this version:
http://buildbot.pypy.org/nightly/remove-globals-in-jit/pypy-c-jit-59482-
d8bdb7ec0050-linux64.tar.bz2

This is the output of "ab" command I used:

zys at gpuserver:~$ ab -n 1000 -c 10 http://localhost:8090/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:
Server Hostname:        localhost
Server Port:            8090

Document Path:          /
Document Length:        27 bytes

Concurrency Level:      10
Time taken for tests:   1.177 seconds
Complete requests:      1000
Failed requests:        177
   (Connect: 0, Receive: 0, Length: 177, Exceptions: 0)
Write errors:           0
Total transferred:      162004 bytes
HTML transferred:       27004 bytes
Requests per second:    849.82 [#/sec] (mean)
Time per request:       11.767 [ms] (mean)
Time per request:       1.177 [ms] (mean, across all concurrent requests)
Transfer rate:          134.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     6   12   4.0     11      35
Waiting:        6   12   4.0     11      35
Total:          6   12   4.0     11      35

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     11
  75%     12
  80%     13
  90%     15
  95%     20
  98%     27
  99%     34
 100%     35 (longest request)
zys at gpuserver:~$ ab -n 1000 -c 10 http://localhost:8090/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:
Server Hostname:        localhost
Server Port:            8090

Document Path:          /
Document Length:        27 bytes

Concurrency Level:      10
Time taken for tests:   0.896 seconds
Complete requests:      1000
Failed requests:        185
   (Connect: 0, Receive: 0, Length: 185, Exceptions: 0)
Write errors:           0
Total transferred:      161998 bytes
HTML transferred:       26998 bytes
Requests per second:    1116.56 [#/sec] (mean)
Time per request:       8.956 [ms] (mean)
Time per request:       0.896 [ms] (mean, across all concurrent requests)
Transfer rate:          176.64 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       1
Processing:     4    9   5.2      7      40
Waiting:        4    9   5.1      7      40
Total:          5    9   5.2      7      40

Percentage of the requests served within a certain time (ms)
  50%      7
  66%      8
  75%      9
  80%      9
  90%     14
  95%     17
  98%     32
  99%     39
 100%     40 (longest request)
zys at gpuserver:~$ ab -n 1000 -c 10 http://localhost:8090/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:
Server Hostname:        localhost
Server Port:            8090

Document Path:          /
Document Length:        27 bytes

Concurrency Level:      10
Time taken for tests:   0.725 seconds
Complete requests:      1000
Failed requests:        173
   (Connect: 0, Receive: 0, Length: 173, Exceptions: 0)
Write errors:           0
Total transferred:      161989 bytes
HTML transferred:       26989 bytes
Requests per second:    1378.47 [#/sec] (mean)
Time per request:       7.254 [ms] (mean)
Time per request:       0.725 [ms] (mean, across all concurrent requests)
Transfer rate:          218.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     3    7   4.1      6      39
Waiting:        3    7   4.1      6      39
Total:          3    7   4.1      6      39

Percentage of the requests served within a certain time (ms)
  50%      6
  66%      6
  75%      7
  80%      7
  90%     11
  95%     14
  98%     17
  99%     39
 100%     39 (longest request)
zys at gpuserver:~$ ab -n 1000 -c 10 http://localhost:8090/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:
Server Hostname:        localhost
Server Port:            8090

Document Path:          /
Document Length:        27 bytes

Concurrency Level:      10
Time taken for tests:   0.751 seconds
Complete requests:      1000
Failed requests:        146
   (Connect: 0, Receive: 0, Length: 146, Exceptions: 0)
Write errors:           0
Total transferred:      161995 bytes
HTML transferred:       26995 bytes
Requests per second:    1332.12 [#/sec] (mean)
Time per request:       7.507 [ms] (mean)
Time per request:       0.751 [ms] (mean, across all concurrent requests)
Transfer rate:          210.74 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     2    7   5.4      5      36
Waiting:        2    7   5.4      5      36
Total:          3    7   5.4      5      36

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      6
  75%      6
  80%      8
  90%     15
  95%     18
  98%     29
  99%     35
 100%     36 (longest request)
zys at gpuserver:~$ ab -n 10000 -c 10 http://localhost:8090/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
apr_socket_recv: Connection reset by peer (104)
Total of 1 requests completed
zys at gpuserver:~$

And this is how the pypyflaskmongo.py crashes:

zys at gpuserver:~/pypytest/pypy-c-jit-59482-d8bdb7ec0050-linux64/bin$ ./pypy 
pypyflaskmongo.py
Segmentation fault (core dumped)
zys at gpuserver:~/pypytest/pypy-c-jit-59482-d8bdb7ec0050-linux64/bin$

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

From tracker at bugs.pypy.org  Mon Jan  7 19:09:07 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 07 Jan 2013 18:09:07 +0000
Subject: [pypy-issue] [issue1361] pypy.rlib.entrypoint doesn't make function
	exported on	Windows
In-Reply-To: <1357553765.06.0.407417738168.issue1361@bugs.pypy.org>
Message-ID: <1357582147.28.0.356854437695.issue1361@bugs.pypy.org>


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

I claim we should create eci in entrypoints and remove one from cpyext

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

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

From tracker at bugs.pypy.org  Mon Jan  7 21:25:31 2013
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Mon, 07 Jan 2013 20:25:31 +0000
Subject: [pypy-issue] [issue1356] Casting a str into a ctype pointer fails
In-Reply-To: <1356992181.13.0.18696778854.issue1356@bugs.pypy.org>
Message-ID: <1357590331.28.0.981644669156.issue1356@bugs.pypy.org>


Vincent Pelletier <plr.vincent at gmail.com> added the comment:

I special-cased for PyPy. I needed the special case for big-endian anyway, so I reused that code path. Result (total script, not 
just this part) is 5~6 times faster with PyPy than CPython with the hack, so I can do without the 10%-ish the hack gains on 
CPython. STand-alone CPython benchmark:

$ python -mtimeit -s "from struct import unpack; from cStringIO import StringIO; data = '\x23\x01' * 1000" "read = 
StringIO(data).read" "for _ in xrange(len(data) / 2): unpack('<H', read(2))"
1000 loops, best of 3: 255 usec per loop
$ python -mtimeit -s "from ctypes import cast, c_ushort, POINTER; c_ushort_p = POINTER(c_ushort); from cStringIO import StringIO; 
data = '\x23\x01' * 1000" "read = StringIO(data).read" "cast(data, c_ushort_p)"
1000000 loops, best of 3: 1.34 usec per loop

StringIO() call preserved in the latter to offset both result equally - alone it costs 0.136 usec per loop here.

I guess this report can be closed "wontfix".

Side note: I noticed a logical inversion in my original report: the byte swap must be done when on big-endian machines, not on 
little-endian. IE, I read little-endian short ints from file.

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

From tracker at bugs.pypy.org  Mon Jan  7 21:32:42 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 07 Jan 2013 20:32:42 +0000
Subject: [pypy-issue] [issue1356] Casting a str into a ctype pointer fails
In-Reply-To: <1356992181.13.0.18696778854.issue1356@bugs.pypy.org>
Message-ID: <1357590762.88.0.100549393923.issue1356@bugs.pypy.org>


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

as per the OP wish :)

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

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

From tracker at bugs.pypy.org  Mon Jan  7 21:50:55 2013
From: tracker at bugs.pypy.org (Vincent Pelletier)
Date: Mon, 07 Jan 2013 20:50:55 +0000
Subject: [pypy-issue] [issue1356] Casting a str into a ctype pointer fails
In-Reply-To: <1356992181.13.0.18696778854.issue1356@bugs.pypy.org>
Message-ID: <1357591855.03.0.140761434241.issue1356@bugs.pypy.org>


Vincent Pelletier <plr.vincent at gmail.com> added the comment:

...and I forgot to include pypy bench results for unpack-based code:

$ ~/hg/pypy/pypy/translator/goal/pypy-c -mtimeit -s "from ctypes import cast, c_ushort, POINTER; c_ushort_p = 
POINTER(c_ushort); from struct import unpack; from cStringIO import StringIO; data = '\x23\x01' * 1000" "read = 
StringIO(data).read" "for _ in xrange(len(data) / 2): unpack('<H', read(2))"
1000000 loops, best of 3: 1.94 usec per loop

"read = StringIO(data).read" accounting for 0.00114 usec per loop

I ran this on ~2 days ago hg, "default" branch. I'm rebuilding latest (?) and will re-post if results differ.
I'm not used to hg, is this the proper way to tell which commit is the top of current branch (this is what I'm building) 
?
$ hg log -r .
changeset:   59850:832cba6f5385
user:        mattip <matti.picus at gmail.com>
date:        Sun Dec 30 16:42:36 2012 +0200
summary:     move call to make_cmdline_overview so that readthedocs can find it

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

From tracker at bugs.pypy.org  Mon Jan  7 22:18:04 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 21:18:04 +0000
Subject: [pypy-issue] [issue1353] Weakrefs to builtin types sometimes don't
	work
In-Reply-To: <1356438277.83.0.776926306279.issue1353@bugs.pypy.org>
Message-ID: <1357593484.59.0.985800125672.issue1353@bugs.pypy.org>


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

By compiling different versions, I checked that the fault is not 66ca6d9f3739,
but the following checkin, 3ef72b75102b.  However I still have no clue about why...

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

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

From tracker at bugs.pypy.org  Mon Jan  7 22:50:07 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 21:50:07 +0000
Subject: [pypy-issue] [issue1353] Weakrefs to builtin types sometimes don't
	work
In-Reply-To: <1356438277.83.0.776926306279.issue1353@bugs.pypy.org>
Message-ID: <1357595407.44.0.974596195407.issue1353@bugs.pypy.org>


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

It's a GC bug: a weakref to a prebuilt object will become dead at the next major
collection if it points to an object that has never been modified.  It's
probably possible to expose the bug with other types of objects than 'type', but
for 'type', it is revealed by 3ef72b75102b because we no longer store a value
dynamically on built-in types --- and so types like 'list' are no longer
modified.  Argh.

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

From tracker at bugs.pypy.org  Mon Jan  7 23:09:51 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 22:09:51 +0000
Subject: [pypy-issue] [issue1353] Weakrefs to builtin types sometimes don't
	work
In-Reply-To: <1356438277.83.0.776926306279.issue1353@bugs.pypy.org>
Message-ID: <1357596591.03.0.191197810264.issue1353@bugs.pypy.org>


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

Test and fix in efb9453c7e81 and 50c910edeafa.

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

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

From tracker at bugs.pypy.org  Tue Jan  8 00:10:32 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 07 Jan 2013 23:10:32 +0000
Subject: [pypy-issue] [issue1337] __file__ is not defined in PYTHONSTARTUP
	script
In-Reply-To: <1353753726.47.0.0331016078434.issue1337@bugs.pypy.org>
Message-ID: <1357600232.67.0.546428591896.issue1337@bugs.pypy.org>


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

Fixed in b90d91783d29.  Thanks!

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

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

From tracker at bugs.pypy.org  Tue Jan  8 20:22:18 2013
From: tracker at bugs.pypy.org (Joe Hillenbrand)
Date: Tue, 08 Jan 2013 19:22:18 +0000
Subject: [pypy-issue] [issue1359] SEGFAULT when running Scrapy tests.
In-Reply-To: <1357231273.48.0.879121182669.issue1359@bugs.pypy.org>
Message-ID: <1357672938.84.0.553056179796.issue1359@bugs.pypy.org>


Joe Hillenbrand <joehillen at gmail.com> added the comment:

I just tested it with a984a9dda83d. No change.

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

From tracker at bugs.pypy.org  Tue Jan  8 21:25:14 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 08 Jan 2013 20:25:14 +0000
Subject: [pypy-issue] [issue1359] SEGFAULT when running Scrapy tests.
In-Reply-To: <1357231273.48.0.879121182669.issue1359@bugs.pypy.org>
Message-ID: <1357676714.43.0.250407953257.issue1359@bugs.pypy.org>


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

Hi.

Scrapy uses pyopenssl and lxml. Those are both C extension modules and PyPy 
support for C extension modules is in alpha. I suppose there must be a bug 
somewhere there (also, note that there are subtle refcounting differencies, 
where CPython would work and PyPy won't).

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

From tracker at bugs.pypy.org  Fri Jan 11 08:59:00 2013
From: tracker at bugs.pypy.org (Jeff Wu)
Date: Fri, 11 Jan 2013 07:59:00 +0000
Subject: [pypy-issue] [issue1362] assert error (happens on one machine but
	not another??)
In-Reply-To: <1357891140.44.0.431137834046.issue1362@bugs.pypy.org>
Message-ID: <1357891140.44.0.431137834046.issue1362@bugs.pypy.org>


New submission from Jeff Wu <jeffwu at mit.edu>:

Hi guys.  I'm using the translator toolchain on an interpreter I built.  It works 
great on my computer (OS X 10.8, Python 2.7.3) but won't work on the EC2 instance 
(Ubuntu, tried both Python 2.7.2, the default, and 2.7.3).  Instead, it gives the 
error below.  Where is the discrepancy likely to be coming from?  What does the 
error mean?  Sorry for the noobishness, and any help is appreciated! 
                                             
(The beginning has been omitted)
...
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_17.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_17
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-release-2.0-beta-1-12/platcheck_18.c -o /tmp/usession-release-2.0-
beta-1-12/platcheck_18.o
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_18.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_18
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-release-2.0-beta-1-12/platcheck_19.c -o /tmp/usession-release-2.0-
beta-1-12/platcheck_19.o
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_19.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_19
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-release-2.0-beta-1-12/platcheck_20.c -o /tmp/usession-release-2.0-
beta-1-12/platcheck_20.o
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_20.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_20
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-release-2.0-beta-1-12/platcheck_21.c -o /tmp/usession-release-2.0-
beta-1-12/platcheck_21.o
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_21.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_21
.+++++++++++++++************************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%####
###################################
[annrpython:WARNING] <FunctionGraph of (engine.traces:210)EvalNode.unevaluate at 
0x992b46c> block at 233 op=3/ no precise annotation supplied for 
iter(SomePBC(can_be_None=True, const=None, subset_of=None),)
.+++++++++++++++************************%
[annrpython:WARNING] <FunctionGraph of (engine.xrp:171)categorical_XRP.prob at 
0x99e128c> block at 0 op=1/ no precise annotation supplied for 
iter(SomePBC(can_be_None=True, const=None, subset_of=None),)
.+++++++++++++++*******************
[annrpython:WARNING] <FunctionGraph of (engine.xrp:171)categorical_XRP.prob at 
0x99e128c> block at 0 op=1/ no precise annotation supplied for 
iter(SomePBC(can_be_None=True, const=None, subset_of=None),)
.+++++++++++++++************************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%####
###################################################################%#%%%**********
***
[translation:info] RTyping...
.+++++++++++++++************************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%####
###################################################################%#%%%**********
****
++++++++++++++********************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[rtyper] specializing: 200 / 3231 blocks   (6%)
++++++++++++++********************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%####
####################################################################%%%%%%%*******
****
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###%%%%####
################################################################
[rtyper] specializing: 600 / 4864 blocks   (12%)
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###%%%%
[rtyper] specializing: 900 / 5255 blocks   (17%)
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###%%%%####
########
[rtyper] specializing: 1300 / 5580 blocks   (23%)
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[rtyper] specializing: 1700 / 5858 blocks   (29%)
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###%%%%####
######################################################
[rtyper] specializing: 2200 / 6397 blocks   (34%)
+++++
[rtyper] specializing: 2300 / 6413 blocks   (35%)
[rtyper] specializing: 2600 / 6413 blocks   (40%)
+
[rtyper] specializing: 2900 / 6413 blocks   (45%)
++++++
[rtyper] specializing: 3300 / 6439 blocks   (51%)
[rtyper] specializing: 3700 / 6439 blocks   (57%)
[rtyper] specializing: 4000 / 6439 blocks   (62%)
++
[rtyper] specializing: 4400 / 6447 blocks   (68%)
[rtyper] specializing: 4800 / 6447 blocks   (74%)
+
[rtyper] specializing: 5100 / 6452 blocks   (79%)
[rtyper] specializing: 5500 / 6452 blocks   (85%)
++
[rtyper] specializing: 5900 / 6463 blocks   (91%)
[rtyper] specializing: 6300 / 6463 blocks   (97%)
[rtyper] -=- specialized 6463 blocks -=-
+++++++++++*************
[rtyper] specializing: 6500 / 6689 blocks   (97%)
[rtyper] -=- specialized 226 more blocks -=-
[rtyper] -=- specialized 2 more blocks -=-
+++
[rtyper] -=- specialized 7 more blocks -=-
[translation:info] lltype back-end optimisations...
[backendopt:inlining] phase with threshold factor: 32.4
[backendopt:inlining] heuristic: 
pypy.translator.backendopt.inline.inlining_heuristic
+++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%###%%%%####
##################################################################%%%%%%%%%%%%****
****
+++++++++*****************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#############
################################################################%%%%%%%%%%%%%%%%%*
****
+++++++****************%%%%##%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%##########
##################################################################%%%%%%%%%%%%%%%%
%***
+++++****************%%%%%%##%%%%%%%%%%%%%%%##%%%%%%%%%%%%%%%%%%%%%#%#############
#######################################################################%#%%%%%%%%%
%%%*
++++***************%%%%%%%%%%#%###%%%%%%%%%%%#####################################
#######################################################################%#%%%%%%%%%
%%%%
+++**************%%%%
[backendopt:inlining] inlined 3229 callsites.
[backendopt:malloc] starting malloc removal
+++**************%%%%%%%%%%%%%%%##################################################
#####################################################################%%%%%%%%%%%%%
%%%%
++*************%%%%%%%%%%%%%%%%###################################################
######################################################################%%#%%%%%%%%%
%%%%
+*************%%%%%%
[backendopt:malloc] removed 1214 simple mallocs in total
[backendopt:mergeifblocks] starting to merge if blocks
+*
[translation:info] inserting stack checks...
+*
[rtyper] specializing: 6700 / 6705 blocks   (99%)
[rtyper] -=- specialized 7 more blocks -=-
[translation:info] inserted 45 stack checks.
[translation:info] Creating database for generating c source...
+**********
[rtyper] -=- specialized 25 more blocks -=-
+*************%%%%%%%%%%%%%%%%####################################################
########################################################################%%%%%%%%%%
%%%%
*************%%%%%%%%%%###########################################################
####################################################
[rtyper] specializing: 6800 / 8176 blocks   (83%)
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gctypelayout.GCData object 
at 0xaf0238c> has no attribute 'root_stack_top'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gctypelayout.GCData object 
at 0xaf0238c> has no attribute 'root_stack_base'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'young_objects_with_light_finalizers'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'young_rawmalloced_objects'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'rawmalloced_total_size'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'next_major_collection_initial'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'old_objects_with_light_finalizers'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_debug_pending'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_list_rpy'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'tmpstack'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_callback2_arg4'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_debug_seen'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'finalizer_lock_count'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_callback2_arg3'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'nursery_objects_shadows'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'young_objects_with_weakrefs'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'old_objects_with_weakrefs'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'next_major_collection_threshold'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'old_rawmalloced_objects'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'objects_to_trace'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'objects_with_finalizers'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_count_rpy'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_callback2_arg0'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_callback2_arg1'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute '_callback2_arg2'
[rtyper:WARNING] prebuilt instance <pypy.rpython.memory.gc.minimark.MiniMarkGC 
object at 0xaf02e8c> has no attribute 'run_finalizers'
*************%%%%%%%%%%############################
[rtyper] specializing: 7300 / 8282 blocks   (88%)
*************%%%%
[rtyper] specializing: 7800 / 8291 blocks   (94%)
*************%%%
[rtyper] specializing: 8200 / 8310 blocks   (98%)
[rtyper] -=- specialized 1580 more blocks -=-
**********
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-release-2.0-beta-1-12/platcheck_22.c -o /tmp/usession-release-2.0-
beta-1-12/platcheck_22.o
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_22.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_22
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-release-2.0-beta-1-12/platcheck_23.c -o /tmp/usession-release-2.0-
beta-1-12/platcheck_23.o
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_23.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_23
[platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -Wall -Wno-unused 
/tmp/usession-release-2.0-beta-1-12/platcheck_24.c -o /tmp/usession-release-2.0-
beta-1-12/platcheck_24.o
[platform:execute] gcc /tmp/usession-release-2.0-beta-1-12/platcheck_24.o -pthread 
-lrt -o /tmp/usession-release-2.0-beta-1-12/platcheck_24
*****
[Timer] Timings:
[Timer] annotate                       --- 17.6 s
[Timer] rtype_lltype                   --- 41.0 s
[Timer] backendopt_lltype              --- 23.6 s
[Timer] stackcheckinsertion_lltype     ---  0.3 s
[Timer] database_c                     --- 15.2 s
[Timer] =========================================
[Timer] Total:                         --- 97.8 s
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/goal/translate.py", line 303, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/driver.py", line 771, in proceed
[translation:ERROR]     return self._execute(goals, task_skip = 
self._maybe_skip())
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/tool/taskengine.py", line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/driver.py", line 283, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/driver.py", line 486, in task_database_c
[translation:ERROR]     database = cbuilder.build_database()
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/c/genc.py", line 150, in build_database
[translation:ERROR]     sandbox=self.config.translation.sandbox)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/c/database.py", line 62, in __init__
[translation:ERROR]     self.gctransformer = self.gcpolicy.gettransformer()
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/translator/c/gc.py", line 436, in gettransformer
[translation:ERROR]     return 
shadowstack.ShadowStackFrameworkGCTransformer(self.db.translator)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/rpython/memory/gctransform/framework.py", line 480, in __init__
[translation:ERROR]     annhelper.finish()   # at this point, annotate all mix-
level helpers
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/rpython/annlowlevel.py", line 240, in finish
[translation:ERROR]     self.finish_rtype()
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/rpython/annlowlevel.py", line 290, in finish_rtype
[translation:ERROR]     rtyper.specialize_more_blocks()
[translation:ERROR]    File "/root/pypy-pypy-07e08e9c885c/pypy/rpython/rtyper.py", 
line 281, in specialize_more_blocks
[translation:ERROR]     annmixlevel.finish()
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/rpython/annlowlevel.py", line 239, in finish
[translation:ERROR]     self.finish_annotate()
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/rpython/annlowlevel.py", line 258, in finish_annotate
[translation:ERROR]     ann.complete_helpers(self.policy)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py", line 124, in complete_helpers
[translation:ERROR]     self.complete()
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py", line 195, in complete
[translation:ERROR]     self.processblock(graph, block)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py", line 340, in processblock
[translation:ERROR]     self.flowin(graph, block)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py", line 399, in flowin
[translation:ERROR]     self.consider_op(block, i)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py", line 593, in consider_op
[translation:ERROR]     resultcell = consider_meth(*argcells)
[translation:ERROR]    File "<91-codegen /root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py:633>", line 3, in 
consider_op_simple_call
[translation:ERROR]     return arg.simple_call(*args)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/unaryop.py", line 164, in simple_call
[translation:ERROR]     return obj.call(getbookkeeper().build_args("simple_call", 
args_s))
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/unaryop.py", line 717, in call
[translation:ERROR]     return bookkeeper.pbc_call(pbc, args)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/bookkeeper.py", line 664, in pbc_call
[translation:ERROR]     results.append(desc.pycall(schedule, args, 
s_previous_result, op))
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/description.py", line 299, in pycall
[translation:ERROR]     result = schedule(graph, inputcells)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/bookkeeper.py", line 660, in schedule
[translation:ERROR]     return self.annotator.recursivecall(graph, whence, 
inputcells)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py", line 286, in recursivecall
[translation:ERROR]     self.addpendingblock(graph, graph.startblock, inputcells)
[translation:ERROR]    File "/root/pypy-pypy-
07e08e9c885c/pypy/annotation/annrpython.py", line 178, in addpendingblock
[translation:ERROR]     assert annmodel.unionof(s_oldarg, s_newarg) == s_oldarg
[translation:ERROR]  AssertionError: <
[translation:ERROR] Occurred processing the following simple_call:
[translation:ERROR]       (KeyError getting at the binding!)
[translation:ERROR]  v826 = simple_call((function str_from_buffer), raw_buf_0, 
gc_buf_0, v824, v825)
[translation:ERROR] In <FunctionGraph of 
(pypy.rpython.module.ll_os:890)os_read_llimpl at 0xb0340ac>:
[translation:ERROR] Happened at file /root/pypy-pypy-
07e08e9c885c/pypy/rpython/module/ll_os.py line 900
[translation:ERROR]
[translation:ERROR] ==>                 return rffi.str_from_buffer(raw_buf, 
gc_buf, count, got)
[translation:ERROR]
[translation:ERROR] Known variable annotations:
[translation:ERROR]  raw_buf_0 = SomePtr(ll_ptrtype=<* Array of Char >)
[translation:ERROR]  gc_buf_0 = SomePtr(const=<* None>, ll_ptrtype=<* GcStruct 
rpy_string { hash, chars }>)
[translation:ERROR]  v824 = SomeInteger(knowntype=int, nonneg=True, 
unsigned=False)
[translation:ERROR]  v825 = SomeInteger(knowntype=int, nonneg=True, 
unsigned=False)>
[translation:ERROR] Processing block:
[translation:ERROR]  block at 178 is a <class 
'pypy.objspace.flow.flowcontext.SpamBlock'>
[translation:ERROR]  in (pypy.rpython.module.ll_os:890)os_read_llimpl
[translation:ERROR]  containing the following operations:
[translation:ERROR]        v826 = simple_call((function str_from_buffer), 
raw_buf_0, gc_buf_0, v824, v825)
[translation:ERROR]  --end--
[translation] start debugger...
> /root/pypy-pypy-07e08e9c885c/pypy/annotation/annrpython.py(178)addpendingblock()
-> assert annmodel.unionof(s_oldarg, s_newarg) == s_oldarg
(Pdb+)

----------
messages: 5144
nosy: pypy-issue, wuthefwasthat
priority: bug
status: unread
title: assert error (happens on one machine but not another??)

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

From tracker at bugs.pypy.org  Fri Jan 11 13:01:31 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 11 Jan 2013 12:01:31 +0000
Subject: [pypy-issue] [issue1362] assert error (happens on one machine but
	not another??)
In-Reply-To: <1357891140.44.0.431137834046.issue1362@bugs.pypy.org>
Message-ID: <1357905691.59.0.446992668919.issue1362@bugs.pypy.org>


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

can you find out on the pdb prompt what's s_oldarg and s_newarg?

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

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

From tracker at bugs.pypy.org  Sat Jan 12 01:06:24 2013
From: tracker at bugs.pypy.org (Jeff Wu)
Date: Sat, 12 Jan 2013 00:06:24 +0000
Subject: [pypy-issue] [issue1362] assert error (happens on one machine but
	not another??)
In-Reply-To: <1357891140.44.0.431137834046.issue1362@bugs.pypy.org>
Message-ID: <1357949184.31.0.715007939127.issue1362@bugs.pypy.org>


Jeff Wu <jeffwu at mit.edu> added the comment:

The log: 
[translation:ERROR]  --end--
[translation] start debugger...
> /root/pypy-pypy-07e08e9c885c/pypy/annotation/annrpython.py(178)addpendingblock()
-> assert annmodel.unionof(s_oldarg, s_newarg) == s_oldarg
(Pdb+) p s_oldarg
SomeInteger(const=1048576, knowntype=int, nonneg=True, unsigned=False)
(Pdb+) p s_newarg
SomeInteger(knowntype=int, nonneg=True, unsigned=False)
(Pdb+)

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

From tracker at bugs.pypy.org  Sat Jan 12 11:50:22 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 12 Jan 2013 10:50:22 +0000
Subject: [pypy-issue] [issue1330] fib(47) vs fib(48)
In-Reply-To: <1353581406.51.0.351260032684.issue1330@bugs.pypy.org>
Message-ID: <1357987822.01.0.882467895126.issue1330@bugs.pypy.org>


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

It's not related to getting ints vs longs.  I see for example that fib(27) is
slower than fib(28) as well.  The cause is, roughly speaking, nondeterminism in
the order in which loops and bridges are compiled.  Looking at the code
generated for fib(47) vs fib(48), then fib(47) has the expected kind of code,
but the faster fib(48) optimizes it better --- it ends up with code that looks
like this:

def f(n):
    guard n >= 2
    guard n <= 2
    return 1   # == f(1) + f(0)

with of course additional bridges if the guards fail.  The point is that this is
particularly efficient for f(2), containing the inlined copy of f(1) and f(0)
and constant-folding the addition.  This makes a difference because whenever we
reach f(2), we can just return 1 (and we reach f(2) a huge number of times,
certainly more than sys.maxint).

The fib(47) version contains the more expected special cases for f(n<2) only.

Unsure if or how to fix that.

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

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

From tracker at bugs.pypy.org  Sat Jan 12 14:00:33 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Sat, 12 Jan 2013 13:00:33 +0000
Subject: [pypy-issue] [issue1358] test failure x2 of sphinx's test_autodoc.py
In-Reply-To: <1357204438.8.0.21537229791.issue1358@bugs.pypy.org>
Message-ID: <1357995633.87.0.978584294238.issue1358@bugs.pypy.org>


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

File
"/var/tmp/portage/portage/dev-python/sphinx-1.1.3-r3/work/Sphinx-1.1.3/build-2.7-pypy-2.0/tests/test_autodoc.py",
line 158, in test_format_signature
    assert formatsig('class', 'D', C, None, None) == ''
AssertionError

  File
"/var/tmp/portage/portage/dev-python/sphinx-1.1.3-r3/work/Sphinx-1.1.3/build-2.7-pypy-2.0/tests/test_autodoc.py",
line 360, in assert_result_contains
    assert item in directive.result
AssertionError

also beta 2.0

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

From tracker at bugs.pypy.org  Sat Jan 12 14:53:00 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 12 Jan 2013 13:53:00 +0000
Subject: [pypy-issue] [issue1358] test failure x2 of sphinx's test_autodoc.py
In-Reply-To: <1357204438.8.0.21537229791.issue1358@bugs.pypy.org>
Message-ID: <1357998780.2.0.894068303026.issue1358@bugs.pypy.org>


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

This might be related to the fact that pypy builtin and not builtin functions are 
not that different from each other. I agree we should document it.

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

From tracker at bugs.pypy.org  Sat Jan 12 22:22:17 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 12 Jan 2013 21:22:17 +0000
Subject: [pypy-issue] [issue1363] pip install pytest-xdist segfaults
In-Reply-To: <1358025737.66.0.673522879786.issue1363@bugs.pypy.org>
Message-ID: <1358025737.66.0.673522879786.issue1363@bugs.pypy.org>


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

Reproduces consistantly with the latest pypy, only on OS X so far though.

----------
messages: 5150
nosy: agaynor, pypy-issue
priority: bug
status: unread
title: pip install pytest-xdist segfaults

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

From tracker at bugs.pypy.org  Sun Jan 13 00:24:13 2013
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sat, 12 Jan 2013 23:24:13 +0000
Subject: [pypy-issue] [issue1363] Threads segfault on OS X
In-Reply-To: <1358025737.66.0.673522879786.issue1363@bugs.pypy.org>
Message-ID: <1358033053.37.0.496327399866.issue1363@bugs.pypy.org>


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

Turns out it's even simpler to reproduce: pypy -c "import threading; 
threading.Thread(target=lambda: None).start()"

----------
status: unread -> chatting
title: pip install pytest-xdist segfaults -> Threads segfault on OS X

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

From tracker at bugs.pypy.org  Sun Jan 13 16:37:10 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 13 Jan 2013 15:37:10 +0000
Subject: [pypy-issue] [issue1363] Threads segfault on OS X
In-Reply-To: <1358025737.66.0.673522879786.issue1363@bugs.pypy.org>
Message-ID: <1358091430.82.0.828883892976.issue1363@bugs.pypy.org>


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

Fixed by ad1b2b6d8ced.

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

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

From tracker at bugs.pypy.org  Mon Jan 14 02:43:43 2013
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 14 Jan 2013 01:43:43 +0000
Subject: [pypy-issue] [issue1365] thread join crash on windows
In-Reply-To: <1358127823.63.0.324696778884.issue1365@bugs.pypy.org>
Message-ID: <1358127823.63.0.324696778884.issue1365@bugs.pypy.org>


New submission from mattip <matti.picus at gmail.com>:

after translation this one liner will crash windows pypy-c.exe hard - it opens a 
dialog box "check for a solution"
pypy\pypy\translator\goal\pypy-c -c "import 
subprocess;popen=subprocess.Popen('dir', stdout=subprocess.PIPE, 
stderr=subprocess.PIPE);stdout,stderr=popen.communicate();print stdout"

The bug will only occur when using two PIPEs. In tracking this down, I got a 
crash consistently at the stdout_thread.join() line in lib-
python/2.7/subprocess.py

Did something change in threads from version c838e03a8079 which is the last 
known good version?

----------
messages: 5156
nosy: mattip, pypy-issue
priority: critical
status: unread
title: thread join crash on windows

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

From tracker at bugs.pypy.org  Mon Jan 14 03:58:47 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Mon, 14 Jan 2013 02:58:47 +0000
Subject: [pypy-issue] [issue1366] Djblets-0.6.22 single test failure under
	pypy{1.9.2.0}
In-Reply-To: <1358132327.84.0.668082834822.issue1366@bugs.pypy.org>
Message-ID: <1358132327.84.0.668082834822.issue1366@bugs.pypy.org>


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

Adding pypy support in Djblets-0.6.22 and running the test suite yields

Testing indent filter ... ok
Testing WebAPIResource with GET and vendor-specific mimetypes ... ERROR
Testing WebAPIResource with vendor-specific mimetypes ... ok
Testing WebAPIResource with vendor-specific and custom mimetypes ... ok

======================================================================
ERROR: Testing WebAPIResource with GET and vendor-specific mimetypes
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/Djblets-0.6.22/work/Djblets-0.6.22/djblets/webapi/tests.py",
line 122, in test_get_with_vendor_mimetype
    'application/vnd.djblets.testresources+xml')
  File
"/mnt/gen2/TmpDir/portage/dev-python/Djblets-0.6.22/work/Djblets-0.6.22/djblets/webapi/tests.py",
line 149, in _test_mimetype_responses
    **kwargs)
  File
"/mnt/gen2/TmpDir/portage/dev-python/Djblets-0.6.22/work/Djblets-0.6.22/djblets/webapi/tests.py",
line 170, in _test_mimetype_response
    print response
  File "/usr/lib64/pypy1.9/site-packages/django/http/__init__.py", line 592, in
__str__
    + '\n\n' + self.content
  File
"/mnt/gen2/TmpDir/portage/dev-python/Djblets-0.6.22/work/Djblets-0.6.22/djblets/webapi/core.py",
line 281, in _get_content
    content = adapter.encode(self.api_data, request=self.request)
  File
"/mnt/gen2/TmpDir/portage/dev-python/Djblets-0.6.22/work/Djblets-0.6.22/djblets/webapi/core.py",
line 88, in encode
    return super(JSONEncoderAdapter, self).encode(o)
  File "/usr/lib64/pypy1.9/lib-python/2.7/json/encoder.py", line 196, in encode
    self._encode(o, markers, builder, 0)
  File "/usr/lib64/pypy1.9/lib-python/2.7/json/encoder.py", line 239, in _encode
    self._encode_dict(o, markers, builder, _current_indent_level)
  File "/usr/lib64/pypy1.9/lib-python/2.7/json/encoder.py", line 299, in
_encode_dict
    builder.append(self.encoder(key))
TypeError: 'MultiEncoder' object is not callable

Name                                       Stmts   Miss  Cover   Missing
------------------------------------------------------------------------
djblets                                       23     23     0%   34-72
djblets.auth                                   0      0   100%   
djblets.auth.forms                            47     25    47%   48-49, 52-56,
59-77, 88-92
djblets.auth.util                             39     28    28%   44-50, 53-56,
59-74, 77-78, 81-83
djblets.auth.views                            63     52    17%   50-80, 89-121,
128-139, 142-153
djblets.datagrid                               0      0   100%   
djblets.datagrid.grids                       338     57    83%   107-108,
228-241, 259-262, 272, 297-304, 309, 332-333, 336, 470-475, 479-480, 500-502,
515, 557, 563-573, 619, 631, 635-636, 657, 746-759, 768
djblets.datagrid.templatetags                  0      0   100%   
djblets.datagrid.templatetags.datagrid         6      0   100%   
djblets.feedview                               0      0   100%   

So it's actually done pretty well here too.
MultiEncoder is a class defined within djblets/webapi/core.py.

Do you require a full build log?  Just ask if you do, I think this will likely
suffice

----------
messages: 5157
nosy: idella5, pypy-issue
priority: bug
release: 1.9
status: chatting
title: Djblets-0.6.22 single test failure under pypy{1.9.2.0}

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

From tracker at bugs.pypy.org  Mon Jan 14 07:54:14 2013
From: tracker at bugs.pypy.org (mattip)
Date: Mon, 14 Jan 2013 06:54:14 +0000
Subject: [pypy-issue] [issue1365] thread join crash on windows
In-Reply-To: <1358127823.63.0.324696778884.issue1365@bugs.pypy.org>
Message-ID: <1358146454.15.0.859660884122.issue1365@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

the problem is present in translated version 3705ab3e421a from 5 Jan

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

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

From tracker at bugs.pypy.org  Mon Jan 14 09:47:06 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 14 Jan 2013 08:47:06 +0000
Subject: [pypy-issue] [issue1365] thread join crash on windows
In-Reply-To: <1358127823.63.0.324696778884.issue1365@bugs.pypy.org>
Message-ID: <1358153226.96.0.0341190907856.issue1365@bugs.pypy.org>


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

I think it was fixed yesterday by armin.

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

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

From tracker at bugs.pypy.org  Mon Jan 14 10:46:11 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 14 Jan 2013 09:46:11 +0000
Subject: [pypy-issue] [issue1366] Djblets-0.6.22 single test failure under
	pypy{1.9, 2.0}
In-Reply-To: <1358132327.84.0.668082834822.issue1366@bugs.pypy.org>
Message-ID: <1358156771.77.0.0204159452827.issue1366@bugs.pypy.org>


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

Looks like an attribute name clash :-(
PyPy's specific version of JSONEncoder has a .encoder member, and djblets's 
JSONEncoderAdapter uses the same attribute for something else.

https://bitbucket.org/pypy/pypy/src/tip/lib-python/2.7/json/encoder.py?at=default#cl-141
https://github.com/djblets/djblets/blob/master/djblets/webapi/core.py#L83

----------
nosy: +afa, fijal

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

From tracker at bugs.pypy.org  Mon Jan 14 10:59:07 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 14 Jan 2013 09:59:07 +0000
Subject: [pypy-issue] [issue1366] Djblets-0.6.22 single test failure under
	pypy{1.9, 2.0}
In-Reply-To: <1358132327.84.0.668082834822.issue1366@bugs.pypy.org>
Message-ID: <1358157547.13.0.129602264336.issue1366@bugs.pypy.org>


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

we should make our names private maybe?

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

From tracker at bugs.pypy.org  Mon Jan 14 15:26:53 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Mon, 14 Jan 2013 14:26:53 +0000
Subject: [pypy-issue] [issue1367] ctypes: c_bool argtype only takes bool type
In-Reply-To: <1358173613.1.0.319692448715.issue1367@bugs.pypy.org>
Message-ID: <1358173613.1.0.319692448715.issue1367@bugs.pypy.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

Raises ArgumentError in PyPy but works in CPython.

import ctypes

lib = ctypes.CDLL("libc.so.6")
func = lib.abs
func.argtypes = [ctypes.c_bool]

func([])

----------
messages: 5162
nosy: lazka, pypy-issue
priority: bug
status: unread
title: ctypes: c_bool argtype only takes bool type

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

From tracker at bugs.pypy.org  Mon Jan 14 15:38:21 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 14 Jan 2013 14:38:21 +0000
Subject: [pypy-issue] [issue1367] ctypes: c_bool argtype only takes bool type
In-Reply-To: <1358173613.1.0.319692448715.issue1367@bugs.pypy.org>
Message-ID: <1358174301.08.0.234598537548.issue1367@bugs.pypy.org>


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

It's probably a good thing, OTOH compatibility with CPython is more important.

tag:easy

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

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

From tracker at bugs.pypy.org  Tue Jan 15 10:17:27 2013
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 15 Jan 2013 09:17:27 +0000
Subject: [pypy-issue] [issue1365] thread join crash on windows
In-Reply-To: <1358127823.63.0.324696778884.issue1365@bugs.pypy.org>
Message-ID: <1358241447.72.0.359316502608.issue1365@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

confirmed fixed in 73c6c33284b7

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

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

From tracker at bugs.pypy.org  Tue Jan 15 19:58:17 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 15 Jan 2013 18:58:17 +0000
Subject: [pypy-issue] [issue1368] pypy ctypes is buggy
In-Reply-To: <1358276297.69.0.107573334079.issue1368@bugs.pypy.org>
Message-ID: <1358276297.69.0.107573334079.issue1368@bugs.pypy.org>


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

running test_zll_stress on top of pypy crashes one in two times roughly. it works 
on cpython. (it can be either random corruption, double free or a segfault)

----------
messages: 5165
nosy: fijal, pypy-issue
priority: bug
status: unread
title: pypy ctypes is buggy

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

From tracker at bugs.pypy.org  Wed Jan 16 13:26:40 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Wed, 16 Jan 2013 12:26:40 +0000
Subject: [pypy-issue] [issue1367] ctypes: c_bool argtype only takes bool type
In-Reply-To: <1358173613.1.0.319692448715.issue1367@bugs.pypy.org>
Message-ID: <1358339200.06.0.441575551316.issue1367@bugs.pypy.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

Just checked with the nightly and it works there.

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

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

From tracker at bugs.pypy.org  Wed Jan 16 23:19:27 2013
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Wed, 16 Jan 2013 22:19:27 +0000
Subject: [pypy-issue] [issue1369] strftime behaviour on OS X
In-Reply-To: <1358374767.35.0.373906499742.issue1369@bugs.pypy.org>
Message-ID: <1358374767.35.0.373906499742.issue1369@bugs.pypy.org>


New submission from Kenny Levinsen <kennylevinsen at gmail.com>:

OS X fails the strftime test:

import time as rctime
...
>           assert rctime.strftime('%f') == '%f'
E           assert 'f' == '%f'
E             - f
E             + %f
module/rctime/test/test_rctime.py:235: AssertionError

I have tested on CPython, and behaviour is the same - time.strftime('%f') returns 
'f' (and some goes 
for all other "invalid" input, such as %Q returning Q). (I was too lazy to compile 
a time.h test, 
though)

Assuming we're okay with OS X's behaviour, we'll need to add a simple darwin check 
in the test:

import time as rctime
import sys
...
if sys.platform == 'darwin':
    assert rctime.strftime('%f') == 'f'
else:
    assert rctime.strftime('%f') == '%f'

----------
messages: 5167
nosy: joushou, pypy-issue
priority: bug
status: unread
title: strftime behaviour on OS X

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

From tracker at bugs.pypy.org  Thu Jan 17 00:05:25 2013
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Wed, 16 Jan 2013 23:05:25 +0000
Subject: [pypy-issue] [issue1370] signal test on OS X
In-Reply-To: <1358377525.1.0.494324709824.issue1370@bugs.pypy.org>
Message-ID: <1358377525.1.0.494324709824.issue1370@bugs.pypy.org>


New submission from Kenny Levinsen <kennylevinsen at gmail.com>:

>           signal(42, lambda *args: None)
E           ValueError: signal number out of range

module/signal/test/test_signal.py:161: ValueError

I checked the man-pages, I could only find 1-31 on OS X, meaning that signalling 
42 (Real-time signal on 
Linux) is rather pointless.

We could either test a signal <=31 on OS X, or simply ignore the test on the 
platform.

----------
messages: 5168
nosy: joushou, pypy-issue
priority: bug
status: unread
title: signal test on OS X

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

From tracker at bugs.pypy.org  Thu Jan 17 13:39:10 2013
From: tracker at bugs.pypy.org (Christoph Reiter)
Date: Thu, 17 Jan 2013 12:39:10 +0000
Subject: [pypy-issue] [issue466] ctypes: False -> c_char_p argument
In-Reply-To: <1255109020.26.0.183413724954.issue466@>
Message-ID: <1358426350.79.0.908016784078.issue466@bugs.pypy.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

standalone466.py segfaults again with 1.9 and nightly

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

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

From tracker at bugs.pypy.org  Thu Jan 17 19:17:13 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Thu, 17 Jan 2013 18:17:13 +0000
Subject: [pypy-issue] [issue1371] test failure x2 of logbook's
	test_regular.py
In-Reply-To: <1358446633.61.0.172015194015.issue1371@bugs.pypy.org>
Message-ID: <1358446633.61.0.172015194015.issue1371@bugs.pypy.org>


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

invoke tests via setup.py test

 * Testing of dev-python/logbook-0.4.1 with PyPy 1.9 (Python 2.7)... {OR 2.0}
PYTHONPATH=build-2.7-pypy-1.9/lib pypy-c1.9 setup.py build -b build-2.7-pypy-1.9
test
------------------------------------------------------------

======================================================================
FAIL: test_formatting_exception (logbook.testsuite.test_regular.BasicAPITestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4.1/work/Logbook-0.4.1/logbook/testsuite/test_regular.py",
line 143, in test_formatting_exception
    'Invalid conversion specification' in errormsg)
AssertionError: False is not true

======================================================================
FAIL: test_formatting_exception
(logbook.testsuite.test_contextmanager.BasicAPITestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4.1/work/Logbook-0.4.1/logbook/testsuite/test_contextmanager.py",
line 121, in test_formatting_exception
    'Invalid conversion specification' in errormsg)
AssertionError: False is not true

----------------------------------------------------------------------
Ran 107 tests in 3.241s

FAILED (failures=2)

Logbook-0.4.1, pypy 1.9, 2.0

do you wish for a full build log?

----------
messages: 5170
nosy: idella5, pypy-issue
priority: bug
release: 2.0
status: chatting
title: test failure x2 of logbook's test_regular.py

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

From tracker at bugs.pypy.org  Fri Jan 18 10:58:48 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Fri, 18 Jan 2013 09:58:48 +0000
Subject: [pypy-issue] [issue1372] test fails in testsuite/loader.py of jinja
	jinja-2.6
In-Reply-To: <1358503128.13.0.241710894753.issue1372@bugs.pypy.org>
Message-ID: <1358503128.13.0.241710894753.issue1372@bugs.pypy.org>


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

via setup.py test


Doctest: jinja2.ext.extract_from_ast ... ok
compile_expression (jinja2.environment.Environment)
Doctest: jinja2.environment.Environment.compile_expression ... ok
Template (jinja2.environment)
Doctest: jinja2.environment.Template ... ok
module (jinja2.environment.Template)
Doctest: jinja2.environment.Template.module ... ok
FileSystemBytecodeCache (jinja2.bccache)
Doctest: jinja2.bccache.FileSystemBytecodeCache ... ok

======================================================================
ERROR: test_byte_compilation (jinja2.testsuite.loader.ModuleLoaderTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6-r1/work/Jinja2-2.6/jinja2/testsuite/loader.py",
line 180, in test_byte_compilation
    tmpl1 = self.mod_env.get_template('a/test.html')
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6-r1/work/Jinja2-2.6/jinja2/environment.py",
line 719, in get_template
    return self._load_template(name, self.make_globals(globals))
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6-r1/work/Jinja2-2.6/jinja2/environment.py",
line 693, in _load_template
    template = self.loader.load(self, name, globals)
  File
"/mnt/gen2/TmpDir/portage/dev-python/jinja-2.6-r1/work/Jinja2-2.6/jinja2/loaders.py",
line 443, in load
    raise TemplateNotFound(name)
TemplateNotFound: a/test.html

----------------------------------------------------------------------
Ran 277 tests in 4.148s

FAILED (errors=1)
 * ERROR: dev-python/jinja-2.6-r1 failed (test phase):

----------
assignedto: afa
messages: 5171
nosy: afa, idella5, pypy-issue
priority: bug
release: 2.0
status: chatting
title: test fails in testsuite/loader.py of jinja jinja-2.6

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

From tracker at bugs.pypy.org  Fri Jan 18 11:23:02 2013
From: tracker at bugs.pypy.org (Antonio Cuni)
Date: Fri, 18 Jan 2013 10:23:02 +0000
Subject: [pypy-issue] [issue1371] test failure x2 of logbook's
	test_regular.py
In-Reply-To: <1358446633.61.0.172015194015.issue1371@bugs.pypy.org>
Message-ID: <50F9227E.2040409@gmail.com>


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

it would be useful to know what is the actual exception message. It might be a 
fault of the testsuite to rely on the exact CPython's error messages

On 17/01/13 18:17, Ian Delaney wrote:
>
> New submission from Ian Delaney <della5 at iinet.com.au>:
>
> invoke tests via setup.py test
>
>   * Testing of dev-python/logbook-0.4.1 with PyPy 1.9 (Python 2.7)... {OR 2.0}
> PYTHONPATH=build-2.7-pypy-1.9/lib pypy-c1.9 setup.py build -b build-2.7-pypy-1.9
> test
> ------------------------------------------------------------
>
> ======================================================================
> FAIL: test_formatting_exception (logbook.testsuite.test_regular.BasicAPITestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File
> "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4.1/work/Logbook-0.4.1/logbook/testsuite/test_regular.py",
> line 143, in test_formatting_exception
>      'Invalid conversion specification' in errormsg)
> AssertionError: False is not true
>
> ======================================================================
> FAIL: test_formatting_exception
> (logbook.testsuite.test_contextmanager.BasicAPITestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File
> "/mnt/gen2/TmpDir/portage/dev-python/logbook-0.4.1/work/Logbook-0.4.1/logbook/testsuite/test_contextmanager.py",
> line 121, in test_formatting_exception
>      'Invalid conversion specification' in errormsg)
> AssertionError: False is not true
>
> ----------------------------------------------------------------------
> Ran 107 tests in 3.241s
>
> FAILED (failures=2)
>
> Logbook-0.4.1, pypy 1.9, 2.0
>
> do you wish for a full build log?
>
> ----------
> messages: 5170
> nosy: idella5, pypy-issue
> priority: bug
> release: 2.0
> status: chatting
> title: test failure x2 of logbook's test_regular.py
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1371>
> ________________________________________
> _______________________________________________
> pypy-issue mailing list
> pypy-issue at python.org
> http://mail.python.org/mailman/listinfo/pypy-issue
>

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

From tracker at bugs.pypy.org  Fri Jan 18 12:10:12 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Fri, 18 Jan 2013 11:10:12 +0000
Subject: [pypy-issue] [issue1371] test failure x2 of logbook's
	test_regular.py
In-Reply-To: <1358446633.61.0.172015194015.issue1371@bugs.pypy.org>
Message-ID: <1358507412.69.0.0394895674727.issue1371@bugs.pypy.org>


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

I take it you mean;



    def test_formatting_exception(self):
        def make_record():
            return logbook.LogRecord('Test Logger', logbook.WARNING,
                                     'Hello {foo:invalid}',
                                     kwargs={'foo': 42},
                                     frame=sys._getframe())
        record = make_record()
        try:
            record.message
        except TypeError, e:
            errormsg = str(e)
        else:
            self.assertFalse('Expected exception')

        self.assert_('Could not format message with provided arguments: '
                     'Invalid conversion specification' in errormsg)

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

From tracker at bugs.pypy.org  Fri Jan 18 13:09:58 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 18 Jan 2013 12:09:58 +0000
Subject: [pypy-issue] [issue1371] test failure x2 of logbook's
	test_regular.py
In-Reply-To: <1358446633.61.0.172015194015.issue1371@bugs.pypy.org>
Message-ID: <1358510998.72.0.20096571685.issue1371@bugs.pypy.org>


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

IMO the test relies too much on the exception message.

The difference is probably this one:   '{:invalid}'.format(None)   
raises a "ValueError: Invalid conversion specification" on CPython, but 
"ValueError: invalid format spec" with PyPy.

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

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

From tracker at bugs.pypy.org  Fri Jan 18 15:10:37 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Fri, 18 Jan 2013 14:10:37 +0000
Subject: [pypy-issue] [issue1371] test failure x2 of logbook's
	test_regular.py
In-Reply-To: <1358446633.61.0.172015194015.issue1371@bugs.pypy.org>
Message-ID: <1358518237.41.0.116182608839.issue1371@bugs.pypy.org>


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

right;

'Hello {foo:invalid}',

are you suggesting to substitute with

'{:invalid}'.format(None),

taking out both Hello and foo?

I follow that the test is consequent to the error msg.

'Invalid conversion specification' in errormsg)

is the line it trips over.  

""ValueError: invalid format spec" with PyPy"

I take it you mean 

""ValueError: invalid conversion spec" with PyPy." ?

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

From tracker at bugs.pypy.org  Fri Jan 18 19:54:34 2013
From: tracker at bugs.pypy.org (Keith Yao)
Date: Fri, 18 Jan 2013 18:54:34 +0000
Subject: [pypy-issue] [issue1373] error when build gevent on macosx
In-Reply-To: <1358535274.91.0.581812776575.issue1373@bugs.pypy.org>
Message-ID: <1358535274.91.0.581812776575.issue1373@bugs.pypy.org>


New submission from Keith Yao <i at yaofur.com>:

I have make some modify in `include/pystate.h` the `_ts` struct and build 
successed

have no idea whether this simple modify will cause problems. 

```
typedef struct _ts {
  // PyInterpreterState *interp;
  // PyObject *dict;  /* Stores per-thread state */

  /* See Python/ceval.c for comments explaining most fields */

  struct _ts *next;
  PyInterpreterState *interp;

  struct _frame *frame;
  int recursion_depth;
  char overflowed; /* The stack has overflowed. Allow 50 more calls
                      to handle the runtime error. */
  char recursion_critical; /* The current calls must not cause
                              a stack overflow. */
  /* 'tracing' keeps track of the execution depth when tracing/profiling.
     This is to prevent the actual trace/profile code from being recorded in
     the trace/profile. */
  int tracing;
  int use_tracing;

  //Py_tracefunc c_profilefunc;
  //Py_tracefunc c_tracefunc;
  PyObject *c_profileobj;
  PyObject *c_traceobj;

  PyObject *curexc_type;
  PyObject *curexc_value;
  PyObject *curexc_traceback;

  PyObject *exc_type;
  PyObject *exc_value;
  PyObject *exc_traceback;

  PyObject *dict;  /* Stores per-thread state */

  /* XXX doesn't mean anything anymore (the comment below is obsolete)
     => deprecate or remove? */
  /* tick_counter is incremented whenever the check_interval ticker
     104      * reaches zero. The purpose is to give a useful measure of the 
number
   * of interpreted bytecode instructions in a given thread.  This
   * extremely lightweight statistic collector may be of interest to
   * profilers (like psyco.jit()), although nothing in the core uses it.
   */
  int tick_counter;

  int gilstate_counter;

  PyObject *async_exc; /* Asynchronous exception to raise */
  long thread_id; /* Thread id where this tstate was created */

  /* XXX signal handlers should also be here */


} PyThreadState;
```

----------
messages: 5176
nosy: kebot, pypy-issue
priority: bug
status: unread
title: error when build gevent on macosx

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

From tracker at bugs.pypy.org  Sat Jan 19 20:35:43 2013
From: tracker at bugs.pypy.org (George Sakkis)
Date: Sat, 19 Jan 2013 19:35:43 +0000
Subject: [pypy-issue] [issue1374] AES encryption/decryption slower than
	cPython
In-Reply-To: <1358624143.54.0.571511013863.issue1374@bugs.pypy.org>
Message-ID: <1358624143.54.0.571511013863.issue1374@bugs.pypy.org>


New submission from George Sakkis <george.sakkis at gmail.com>:

I'm in the middle of porting some existing crypto code from M2Crypto to pycrypto
so that it can run on PyPy. Unfortunately it looks like that at least on my
benchmark script (see attached) the pycrypto performance on PyPy is worse than
the respective on cPython and almost 3x slower than M2Crypto:

$ python --version
Python 2.7.3

$ python aes.py
pycrypto: 10.25s
M2Crypto: 6.09s

$ pypy --version
Python 2.7.3 (7e4f0faa3d51, Nov 16 2012, 15:53:25)
[PyPy 2.0.0-beta1 with GCC 4.6.3]

$ pypy aes.py
pycrypto: 16.54s

Is it a known limitation or am I doing something wrong?

----------
files: aes.py
messages: 5177
nosy: gsakkis, pypy-issue
priority: performance bug
status: unread
title: AES encryption/decryption slower than cPython

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

From tracker at bugs.pypy.org  Sun Jan 20 10:53:02 2013
From: tracker at bugs.pypy.org (Kenny Levinsen)
Date: Sun, 20 Jan 2013 09:53:02 +0000
Subject: [pypy-issue] [issue1373] error when build gevent on macosx
In-Reply-To: <1358535274.91.0.581812776575.issue1373@bugs.pypy.org>
Message-ID: <1358675582.37.0.454057435451.issue1373@bugs.pypy.org>


Kenny Levinsen <kennylevinsen at gmail.com> added the comment:

Could you mark the specific changes you've made in the struct? It makes reading 
the issue faster (as opposed to having to translate in order to diff the two)

What version of OS X were you on? What compiler did you use? What errors were 
thrown before you made the modification? What changeset were you trying to build 
from?

Some more details would be nice. :)

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

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

From tracker at bugs.pypy.org  Sun Jan 20 11:03:42 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 20 Jan 2013 10:03:42 +0000
Subject: [pypy-issue] [issue1364] Weird list syntax leaves item in stack
In-Reply-To: <1358054321.49.0.309947753644.issue1364@bugs.pypy.org>
Message-ID: <1358676222.02.0.963120060375.issue1364@bugs.pypy.org>


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

Easy fix, done in 8a7426025407 and 0bbf95bbb3b1.  Thanks!

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

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

From tracker at bugs.pypy.org  Sun Jan 20 11:06:07 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 20 Jan 2013 10:06:07 +0000
Subject: [pypy-issue] [issue1373] error when build gevent on macosx
In-Reply-To: <1358535274.91.0.581812776575.issue1373@bugs.pypy.org>
Message-ID: <1358676367.59.0.642600552744.issue1373@bugs.pypy.org>


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

Yes, build succeeds... but pypy will never use of fill these new fields, and 
gevent won't work correctly.
What was the error in the first place?

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

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

From tracker at bugs.pypy.org  Sun Jan 20 11:14:19 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 20 Jan 2013 10:14:19 +0000
Subject: [pypy-issue] [issue1312] Strict aliasing violations
	in	"pypy/translator/c/src/thread_pthread.h"
In-Reply-To: <1351876008.04.0.210556132846.issue1312@bugs.pypy.org>
Message-ID: <1358676859.45.0.283137985046.issue1312@bugs.pypy.org>


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

Update: this is now about thread_pthread.c:66 and :127.

This error may mean that pthread_t is larger than a long on Solaris.  This is
not really supported by the rest of the code, but then, neither is it on
CPython, from where these two strange lines code from.

The only difference with CPython is that CPython uses #if whereas we use a
regular if.  Can you check on Solaris whether sizeof(pthread_t) is really
greater than sizeof(long), or whether it's just gcc complaining about a dead
code path?

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

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

From tracker at bugs.pypy.org  Sun Jan 20 11:15:34 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 20 Jan 2013 10:15:34 +0000
Subject: [pypy-issue] [issue1374] AES encryption/decryption slower than
	cPython
In-Reply-To: <1358624143.54.0.571511013863.issue1374@bugs.pypy.org>
Message-ID: <1358676934.2.0.958260567471.issue1374@bugs.pypy.org>


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

pycrypto is a C extension module, which performance are usually bad on PyPy.

By the way, what is the problem with M2Crypto? It's written with SWIG, but should 
work on PyPy.

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

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

From tracker at bugs.pypy.org  Sun Jan 20 11:22:43 2013
From: tracker at bugs.pypy.org (Keith Yao)
Date: Sun, 20 Jan 2013 10:22:43 +0000
Subject: [pypy-issue] [issue1373] error when build gevent on macosx
In-Reply-To: <1358676367.59.0.642600552744.issue1373@bugs.pypy.org>
Message-ID: <CAOquNru0LcDxb3JXXR6Tc6WuZn-_=1G_+UDWezEYc_XJJp3_2A@mail.gmail.com>


Keith Yao <i at yaofur.com> added the comment:

The error is it can't found some field in the `_ts` struct when building. I
have no idea whether I can report the issue to gevent or to pypy to make
this work.

I need gevent-Socket.IO to develop my application. Now I switch back to
cpython to continue my develop.

On Sun, Jan 20, 2013 at 6:06 PM, Amaury Forgeot d Arc <tracker at bugs.pypy.org
> wrote:

>
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
>
> Yes, build succeeds... but pypy will never use of fill these new fields,
> and
> gevent won't work correctly.
> What was the error in the first place?
>
> ----------
> nosy: +afa
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1373>
> ________________________________________
>

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

From tracker at bugs.pypy.org  Sun Jan 20 11:25:48 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sun, 20 Jan 2013 10:25:48 +0000
Subject: [pypy-issue] [issue1368] pypy ctypes is buggy
In-Reply-To: <1358276297.69.0.107573334079.issue1368@bugs.pypy.org>
Message-ID: <1358677548.4.0.199163107279.issue1368@bugs.pypy.org>


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

Occurs on Linux 64 but not Linux 32.

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

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

From tracker at bugs.pypy.org  Sun Jan 20 11:46:17 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 20 Jan 2013 10:46:17 +0000
Subject: [pypy-issue] [issue1373] error when build gevent on macosx
In-Reply-To: <1358535274.91.0.581812776575.issue1373@bugs.pypy.org>
Message-ID: <1358678777.84.0.170985972167.issue1373@bugs.pypy.org>


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

We need the name of this "some field". Then we'll see if it's possible to support 
it on PyPy.

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

From tracker at bugs.pypy.org  Sun Jan 20 12:02:59 2013
From: tracker at bugs.pypy.org (Keith Yao)
Date: Sun, 20 Jan 2013 11:02:59 +0000
Subject: [pypy-issue] [issue1373] error when build gevent on macosx
In-Reply-To: <1358678777.84.0.170985972167.issue1373@bugs.pypy.org>
Message-ID: <CAOquNrtP0=tregnzF5a4CJ3Ebr17EAcspfYWrrAjKtVnXtN_rg@mail.gmail.com>


Keith Yao <i at yaofur.com> added the comment:

the error message when building gevent is here:
https://gist.github.com/4577855

I just copy the cpython's include/pystate.h to pypy's include/pystate.h ,
the diff is here:
https://gist.github.com/4577897

On Sun, Jan 20, 2013 at 6:46 PM, Amaury Forgeot d Arc <tracker at bugs.pypy.org
> wrote:

>
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
>
> We need the name of this "some field". Then we'll see if it's possible to
> support
> it on PyPy.
>
> ________________________________________
> PyPy bug tracker <tracker at bugs.pypy.org>
> <https://bugs.pypy.org/issue1373>
> ________________________________________
>

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

From tracker at bugs.pypy.org  Sun Jan 20 14:01:50 2013
From: tracker at bugs.pypy.org (George Sakkis)
Date: Sun, 20 Jan 2013 13:01:50 +0000
Subject: [pypy-issue] [issue1374] AES encryption/decryption slower than
	cPython
In-Reply-To: <1358624143.54.0.571511013863.issue1374@bugs.pypy.org>
Message-ID: <1358686910.8.0.344918874224.issue1374@bugs.pypy.org>


George Sakkis <george.sakkis at gmail.com> added the comment:

Ah I had the impression pycrypto is pure python.

Trying to instal M2Crypto fails with:
SWIG/_m2crypto_wrap.c:3288:19: fatal error: ceval.h: No such file or directory

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

From tracker at bugs.pypy.org  Sun Jan 20 17:45:47 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 20 Jan 2013 16:45:47 +0000
Subject: [pypy-issue] [issue1374] AES encryption/decryption slower than
	cPython
In-Reply-To: <1358624143.54.0.571511013863.issue1374@bugs.pypy.org>
Message-ID: <1358700347.77.0.0800586537926.issue1374@bugs.pypy.org>


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

The changes below fix M2Crypto for me, the module imports and I could run a few demos.

(I also had to drop the declaration of SSLv2_method(), but this is a different issue for M2Crypto:
https://code.google.com/p/grr/wiki/M2CryptoFromSource#Undefined_symbol:_SSLv2_method
)

PyPy could have an empty ceval.h and an implementation for PyInstance_New, though.


--- a/M2Crypto-0.21.1/SWIG/_lib.i~	2011-01-15 20:10:06.000000000 +0100
+++ b/M2Crypto-0.21.1/SWIG/_lib.i	2013-01-20 17:31:29.724931457 +0100
@@ -8,7 +8,6 @@
 #include <openssl/rsa.h>
 #include <openssl/ssl.h>
 #include <openssl/x509.h>
-#include <ceval.h>
 
 /* Blob interface. Deprecated. */
 
@@ -132,7 +131,7 @@
     
         _x509_store_ctx_swigptr = SWIG_NewPointerObj((void *)ctx, SWIGTYPE_p_X509_STORE_CTX, 0);
         _x509_store_ctx_obj = Py_BuildValue("(Oi)", _x509_store_ctx_swigptr, 0);
-        _x509_store_ctx_inst = PyInstance_New(_klass, _x509_store_ctx_obj, NULL);
+        _x509_store_ctx_inst = PyEval_CallObject(_klass, _x509_store_ctx_obj);
         argv = Py_BuildValue("(iO)", ok, _x509_store_ctx_inst);
     } else {
         if (PyErr_Warn(PyExc_DeprecationWarning, "Old style callback, use cb_func(ok, store) instead")) {

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

From tracker at bugs.pypy.org  Sun Jan 20 18:38:19 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Sun, 20 Jan 2013 17:38:19 +0000
Subject: [pypy-issue] [issue1373] error when build gevent on macosx
In-Reply-To: <1358535274.91.0.581812776575.issue1373@bugs.pypy.org>
Message-ID: <1358703499.96.0.565825596814.issue1373@bugs.pypy.org>


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

You should use a recent version of Cython, which will have better support for 
PyPy.
tstate->exc_type cannot be directly supported by PyPy.

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

From tracker at bugs.pypy.org  Mon Jan 21 15:50:16 2013
From: tracker at bugs.pypy.org (Tim Felgentreff)
Date: Mon, 21 Jan 2013 14:50:16 +0000
Subject: [pypy-issue] [issue1375] Checkin renaming tool for rpython split
In-Reply-To: <1358779816.37.0.202532161917.issue1375@bugs.pypy.org>
Message-ID: <1358779816.37.0.202532161917.issue1375@bugs.pypy.org>


New submission from Tim Felgentreff <timfelgentreff+pypybugs at gmail.com>:

This would be useful for the lang-* projects

----------
assignedto: fijal
messages: 5190
nosy: fijal, pypy-issue, timfel
priority: bug
status: unread
title: Checkin renaming tool for rpython split

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

From tracker at bugs.pypy.org  Mon Jan 21 19:02:08 2013
From: tracker at bugs.pypy.org (George Sakkis)
Date: Mon, 21 Jan 2013 18:02:08 +0000
Subject: [pypy-issue] [issue1374] AES encryption/decryption slower than
	cPython
In-Reply-To: <1358624143.54.0.571511013863.issue1374@bugs.pypy.org>
Message-ID: <1358791328.9.0.804735760086.issue1374@bugs.pypy.org>


George Sakkis <george.sakkis at gmail.com> added the comment:

Thanks for the patch; too bad I didn't ask a week ago, would have saved me the
porting effort :) At least performance on PyPy seems to be almost the same
between M2Crypto and pycrypto.

Feel free to close the ticket and thanks again.

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

From tracker at bugs.pypy.org  Mon Jan 21 21:17:44 2013
From: tracker at bugs.pypy.org (Glyph)
Date: Mon, 21 Jan 2013 20:17:44 +0000
Subject: [pypy-issue] [issue997] PyCrypto fails to build with pypy/cpyext
In-Reply-To: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>
Message-ID: <1358799464.19.0.376662457922.issue997@bugs.pypy.org>


Glyph <glyph at twistedmatrix.com> added the comment:

Just today I did 'pip install PyCrypto' on PyPy 1.9 and it seemed to work.  Should 
this be marked as fixed?

----------
nosy: +glyph

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

From tracker at bugs.pypy.org  Mon Jan 21 22:25:09 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 21 Jan 2013 21:25:09 +0000
Subject: [pypy-issue] [issue997] PyCrypto fails to build with pypy/cpyext
In-Reply-To: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>
Message-ID: <1358803509.82.0.833778236036.issue997@bugs.pypy.org>


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

Glyph, I guess you don't have LIBGMP installed:
"warning: GMP or MPIR library not found; Not building 
Crypto.PublicKey._fastmath."

After installing libgmp-dev, _fastmath.c cannot compile.

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

From tracker at bugs.pypy.org  Mon Jan 21 22:53:55 2013
From: tracker at bugs.pypy.org (Glyph)
Date: Mon, 21 Jan 2013 21:53:55 +0000
Subject: [pypy-issue] [issue997] PyCrypto fails to build with pypy/cpyext
In-Reply-To: <1326223434.41.0.93637834694.issue997@bugs.pypy.org>
Message-ID: <1358805235.99.0.617767347373.issue997@bugs.pypy.org>


Glyph <glyph at twistedmatrix.com> added the comment:

Aah. Indeed I don't have that.

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

From tracker at bugs.pypy.org  Mon Jan 21 23:16:51 2013
From: tracker at bugs.pypy.org (Bas Westerbaan)
Date: Mon, 21 Jan 2013 22:16:51 +0000
Subject: [pypy-issue] [issue1376] [ARM] generates invalid CFLAGS
In-Reply-To: <1358806611.04.0.332529809983.issue1376@bugs.pypy.org>
Message-ID: <1358806611.04.0.332529809983.issue1376@bugs.pypy.org>


New submission from Bas Westerbaan <bas at westerbaan.name>:

When cross-translating for ARM, non-ARM CFLAGS are generated, which leads to the 
following error.

$ pypy translate.py -Ojit --platform=arm

(...)

[platform:execute] sb2 -t ARM make -j 3 in /tmp/usession-release-2.0-beta-1-
4/testing_1
[platform:Error] arm-linux-gnueabihf-gcc: error: unrecognized command line option 
?-msse2?
[platform:Error] arm-linux-gnueabihf-gcc: error: unrecognized command line option 
?-mfpmath=sse?
[platform:Error] arm-linux-gnueabihf-gcc: error: unrecognized command line option 
?-msse2?
[platform:Error] arm-linux-gnueabihf-gcc: error: unrecognized command line option 
?-mfpmath=sse?
[platform:Error] make: *** [testing_1.s] Error 1
[platform:Error] make: *** Waiting for unfinished jobs....
[platform:Error] arm-linux-gnueabihf-gcc: error: unrecognized command line option 
?-msse2?
[platform:Error] arm-linux-gnueabihf-gcc: error: unrecognized command line option 
?-mfpmath=sse?
[platform:Error] make: *** [structimpl.s] Error 1
[platform:Error] make: *** [data_pypy_module_cpyext_unicodeobject.s] Error 1

----------
messages: 5195
nosy: bas, pypy-issue
priority: critical
release: 2.0
status: unread
title: [ARM] generates invalid CFLAGS

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

From tracker at bugs.pypy.org  Mon Jan 21 23:36:05 2013
From: tracker at bugs.pypy.org (Bas Westerbaan)
Date: Mon, 21 Jan 2013 22:36:05 +0000
Subject: [pypy-issue] [issue1377] [ARM] problem with trackgcroot.py
In-Reply-To: <1358807765.7.0.796115431702.issue1377@bugs.pypy.org>
Message-ID: <1358807765.7.0.796115431702.issue1377@bugs.pypy.org>


New submission from Bas Westerbaan <bas at westerbaan.name>:

Crosstranslating for ARM errors on trackgcroot.py.

python /root/pypy/pypy/translator/c/gcc/trackgcroot.py -t testing_1.s > 
testing_1.gctmp
Traceback (most recent call last):
  File "/root/pypy/pypy/translator/c/gcc/trackgcroot.py", line 2023, in <module>
    tracker.process(f, g, filename=fn)
  File "/root/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1914, in process
    for in_function, lines in parser.find_functions(iterlines):
  File "/root/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1459, in 
find_functions
    "missed the start of the current function")
AssertionError: missed the start of the current function
make: *** [testing_1.gcmap] Error 1

----------
messages: 5196
nosy: bas, pypy-issue
priority: critical
release: 2.0
status: unread
title: [ARM] problem with trackgcroot.py

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

From tracker at bugs.pypy.org  Mon Jan 21 23:44:07 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 21 Jan 2013 22:44:07 +0000
Subject: [pypy-issue] [issue1374] AES encryption/decryption slower than
	cPython
In-Reply-To: <1358624143.54.0.571511013863.issue1374@bugs.pypy.org>
Message-ID: <1358808247.98.0.833156339221.issue1374@bugs.pypy.org>


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

The patch won't be needed in next version: b901441252e9 adds an empty ceval.h and 
implements PyInstance_New.

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

From tracker at bugs.pypy.org  Tue Jan 22 00:31:05 2013
From: tracker at bugs.pypy.org (Bas Westerbaan)
Date: Mon, 21 Jan 2013 23:31:05 +0000
Subject: [pypy-issue] [issue1378] [ARM] version problem with glib
In-Reply-To: <1358811065.03.0.38769167838.issue1378@bugs.pypy.org>
Message-ID: <1358811065.03.0.38769167838.issue1378@bugs.pypy.org>


New submission from Bas Westerbaan <bas at westerbaan.name>:

I followed pypy/doc/arm.rst.  Translating its test program

# --- start ---
def main(args):
    print "Hello World"
    return 0

def target(*args):
    return main, None
# --- end ---

works fine with pypy ../path/to/translate.py -O2 --platform=arm target.py

However, translating pypy itself with

  ../path/to/translate.py -Ojit --platform=arm --gcrootfinder=shadowstack

creates a binary which when executed complains:

  ./pypy-c: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found 
(required by ./pypy-c)

Comparing:

(rpi) root at bishop:/# ldd pypy-c 
./pypy-c: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found 
(required by ./pypy-c)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x4082e000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x40839000)
        libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x408aa000)
        libssl.so.1.0.0 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 
(0x408c8000)
        libcrypto.so.1.0.0 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 
(0x40917000)
        libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0x40a7b000)
        libbz2.so.1.0 => /lib/arm-linux-gnueabihf/libbz2.so.1.0 (0x40aa5000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x40abe000)
        libffi.so.5 => /usr/lib/arm-linux-gnueabihf/libffi.so.5 (0x40acd000)
        libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1 (0x40ae1000)
        libcrypt.so.1 => /lib/arm-linux-gnueabihf/libcrypt.so.1 (0x40aed000)
        libtinfo.so.5 => /lib/arm-linux-gnueabihf/libtinfo.so.5 (0x40b24000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x40b48000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x40b70000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x40b8f000)
        /lib/ld-linux-armhf.so.3 (0x40000000)
(rpi) root at bishop:/# ldd target-c 
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x4082e000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x4083d000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x4085c000)
        /lib/ld-linux-armhf.so.3 (0x40000000)

----------
messages: 5198
nosy: bas, pypy-issue
priority: critical
release: 2.0
status: unread
title: [ARM] version problem with glib

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

From tracker at bugs.pypy.org  Tue Jan 22 01:13:55 2013
From: tracker at bugs.pypy.org (Bas Westerbaan)
Date: Tue, 22 Jan 2013 00:13:55 +0000
Subject: [pypy-issue] [issue1376] [ARM] generates invalid CFLAGS
In-Reply-To: <1358806611.04.0.332529809983.issue1376@bugs.pypy.org>
Message-ID: <1358813635.08.0.837559564635.issue1376@bugs.pypy.org>


Bas Westerbaan <bas at westerbaan.name> added the comment:

When "--jit-backend=arm" is present in the commandline arguments of translate.py, 
this problem does not occur.

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

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

From tracker at bugs.pypy.org  Tue Jan 22 01:14:59 2013
From: tracker at bugs.pypy.org (Bas Westerbaan)
Date: Tue, 22 Jan 2013 00:14:59 +0000
Subject: [pypy-issue] [issue1377] [ARM] problem with trackgcroot.py
In-Reply-To: <1358807765.7.0.796115431702.issue1377@bugs.pypy.org>
Message-ID: <1358813699.18.0.813878137156.issue1377@bugs.pypy.org>


Bas Westerbaan <bas at westerbaan.name> added the comment:

When adding "--gcrootfinder=shadowstack" to the commandline of translate.py, this 
problem does not occur.

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

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

From tracker at bugs.pypy.org  Tue Jan 22 01:17:33 2013
From: tracker at bugs.pypy.org (linq)
Date: Tue, 22 Jan 2013 00:17:33 +0000
Subject: [pypy-issue] [issue1379] Certain packages are missing from
	pkgutil.iter_modules()
In-Reply-To: <1358813853.52.0.957294048629.issue1379@bugs.pypy.org>
Message-ID: <1358813853.52.0.957294048629.issue1379@bugs.pypy.org>


New submission from linq <relinquish at gmail.com>:

To generate a complete list of importable packages, I run the following code:
pkg_list = [pkg[1] for pkg in pkgutil.iter_modules()]

Even though I can import the following packages, they are not listed in pkg_list:
_bisect
_hashlib
_io
_locale
_lsprof
_multibytecodec
_multiprocessing
_random
_socket
_ssl
array
binascii
bz2
cmath
crypt
fcntl
itertools
math
mmap
operator
parser
pyexpat
select
termios
time
unicodedata
zlib

In addition, I ran the same command on CPython 2.7.3 to see if there were any
packages present there but not on pypy. The packages which I found were:
_curses
_curses_panel
_heapq
_hotshot
_json
_struct
_tkinter
audioop
dl
gdbm
imageop
linuxaudiodev
nis
ossaudiodev
spwd
strop

My Platform: Linux 3.6.10 (archlinux)

----------
messages: 5201
nosy: linq, pypy-issue
priority: bug
status: unread
title: Certain packages are missing from pkgutil.iter_modules()

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

From tracker at bugs.pypy.org  Tue Jan 22 12:03:58 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 22 Jan 2013 11:03:58 +0000
Subject: [pypy-issue] [issue1379] Certain packages are missing from
	pkgutil.iter_modules()
In-Reply-To: <1358813853.52.0.957294048629.issue1379@bugs.pypy.org>
Message-ID: <1358852638.17.0.930343140316.issue1379@bugs.pypy.org>


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

pkgutil cannot see built-in modules, only Python modules (*.py) and extension modules (*.so or *.pyd).
PyPy has almost no extension module; all modules are translated and linked with the main executable.
Note that you can do the same with CPython, 

For the missing modules, some of them are accelerator modules that pypy does not need (thanks to the 
JIT, a C version is not necessarily faster): _json, _struct...
The remaining one are missing, but nobody really noticed so far.

Aside from this list, is there a missing feature that you really need?

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

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

From tracker at bugs.pypy.org  Tue Jan 22 12:26:37 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 22 Jan 2013 11:26:37 +0000
Subject: [pypy-issue] [issue1371] test failure x2 of logbook's
	test_regular.py
In-Reply-To: <1358446633.61.0.172015194015.issue1371@bugs.pypy.org>
Message-ID: <1358853997.24.0.0434618269898.issue1371@bugs.pypy.org>


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

No, I was suggesting to modify a bit PyPy error message. The one given by CPython 
looks nicer.
Anyway, tests should not rely too closely on error messages. They can change even 
within a Python version.

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

From tracker at bugs.pypy.org  Tue Jan 22 14:36:08 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 22 Jan 2013 13:36:08 +0000
Subject: [pypy-issue] [issue1380] Tests come to grief under  hglib-0.3
In-Reply-To: <1358861768.7.0.3847952695.issue1380@bugs.pypy.org>
Message-ID: <1358861768.7.0.3847952695.issue1380@bugs.pypy.org>


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

run from an ebuild or from the source directly, same outcome.

python-hglib-0.3 $PYTHONPATH=. /usr/bin/pypy-c2.0 test.py

......................FF...............E................F.....................F..
======================================================================
ERROR: test_basic_file (tests.test-import.test_import)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/hglib-0.3/work/python-hglib-0.3/tests/test-import.py",
line 28, in test_basic_file
    self.client.import_(['patch'], nocommit=True)
  File
"/mnt/gen2/TmpDir/portage/dev-python/hglib-0.3/work/python-hglib-0.3/hglib/client.py",
line 853, in import_
    self.rawcommand(args, prompt=prompt, input=input)
  File
"/mnt/gen2/TmpDir/portage/dev-python/hglib-0.3/work/python-hglib-0.3/hglib/client.py",
line 175, in rawcommand
    raise error.CommandError(args, ret, out, err)
CommandError: abort: patch: no diffs found


======================================================================
FAIL: test_basic (tests.test-config.test_config)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/hglib-0.3/work/python-hglib-0.3/tests/test-config.py",
line 12, in test_basic
    self.assertTrue(('section', 'key', 'value') in self.client.config())
AssertionError: False is not true

======================================================================
FAIL: test_show_source (tests.test-config.test_config)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/hglib-0.3/work/python-hglib-0.3/tests/test-config.py",
line 25, in test_show_source
    'section', 'key', 'value') in config)
AssertionError: False is not true

======================================================================
FAIL: test_basic (tests.test-paths.test_paths)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/hglib-0.3/work/python-hglib-0.3/tests/test-paths.py",
line 11, in test_basic
    self.assertEquals(len(paths), 1)
AssertionError: 0 != 1

======================================================================
FAIL: test_merge (tests.test-update.test_update)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/mnt/gen2/TmpDir/portage/dev-python/hglib-0.3/work/python-hglib-0.3/tests/test-update.py",
line 39, in test_merge
    self.assertEquals(m, 1)
AssertionError: 0 != 1

----------------------------------------------------------------------
Ran 81 tests in 33.963s

FAILED (errors=1, failures=4)

Not sure how fair or legitimate this is on pypy per se.  Any further info required?

----------
messages: 5204
nosy: idella5, pypy-issue
priority: bug
release: 2.0
status: chatting
title: Tests come to grief under  hglib-0.3

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

From tracker at bugs.pypy.org  Tue Jan 22 14:42:15 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Tue, 22 Jan 2013 13:42:15 +0000
Subject: [pypy-issue] [issue1380] Tests come to grief under  hglib-0.3
In-Reply-To: <1358861768.7.0.3847952695.issue1380@bugs.pypy.org>
Message-ID: <1358862135.7.0.568981060106.issue1380@bugs.pypy.org>


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

oh yep, /mercurial v. 2.3.2

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

From tracker at bugs.pypy.org  Tue Jan 22 14:47:32 2013
From: tracker at bugs.pypy.org (linq)
Date: Tue, 22 Jan 2013 13:47:32 +0000
Subject: [pypy-issue] [issue1379] Certain packages are missing from
	pkgutil.iter_modules()
In-Reply-To: <1358813853.52.0.957294048629.issue1379@bugs.pypy.org>
Message-ID: <1358862452.18.0.879936106824.issue1379@bugs.pypy.org>


linq <relinquish at gmail.com> added the comment:

afa,

As you suggest, this issue is admittedly minor. I figured I'd point out the
inconsistency with CPython in case anyone relied on the list of packages in
pkgutils being more consistent with CPython. 

That being said, I am unsure of how other implementations of python tackle this;
it is very possible that they are the same or worse.

Feel free to wontfix if changing the behavior of these modules would be unwieldy.

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

From tracker at bugs.pypy.org  Tue Jan 22 15:19:52 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 22 Jan 2013 14:19:52 +0000
Subject: [pypy-issue] [issue1380] Tests come to grief under  hglib-0.3
In-Reply-To: <1358861768.7.0.3847952695.issue1380@bugs.pypy.org>
Message-ID: <1358864392.74.0.77340088962.issue1380@bugs.pypy.org>


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

All these tests contain a line like:
    open('patch', 'wb').write(patch)
which makes a big difference in PyPy: 
http://pypy.readthedocs.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-
strategies
Note that python3 would raise a ResourceWarning("unclosed file") as well, precisely for this reason.

The tests should ensure the file is correctly closed:
    with open('patch', 'wb') as f:
        f.write(patch)

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

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

From tracker at bugs.pypy.org  Tue Jan 22 17:04:51 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 22 Jan 2013 16:04:51 +0000
Subject: [pypy-issue] [issue1379] Certain packages are missing from
	pkgutil.iter_modules()
In-Reply-To: <1358813853.52.0.957294048629.issue1379@bugs.pypy.org>
Message-ID: <1358870691.54.0.636420220813.issue1379@bugs.pypy.org>


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

- Built-in vs. extension modules is definitely an implementation detail. The list 
even differ between linux and win32 (zlib module is compiled into python27.dll)

- Missing features are best tracked one by one.

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

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

From tracker at bugs.pypy.org  Tue Jan 22 18:33:21 2013
From: tracker at bugs.pypy.org (Bas Westerbaan)
Date: Tue, 22 Jan 2013 17:33:21 +0000
Subject: [pypy-issue] [issue1378] [ARM] version problem with glibc
In-Reply-To: <1358811065.03.0.38769167838.issue1378@bugs.pypy.org>
Message-ID: <1358876001.54.0.810909890586.issue1378@bugs.pypy.org>


Bas Westerbaan <bas at westerbaan.name> added the comment:

The version of libc of the cross compiler and that in the chroot did not match.  
My bad.  Marked invalid.

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

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

From tracker at bugs.pypy.org  Wed Jan 23 15:26:28 2013
From: tracker at bugs.pypy.org (Ian Delaney)
Date: Wed, 23 Jan 2013 14:26:28 +0000
Subject: [pypy-issue] [issue1380] Tests come to grief under  hglib-0.3
In-Reply-To: <1358861768.7.0.3847952695.issue1380@bugs.pypy.org>
Message-ID: <1358951188.36.0.931794609906.issue1380@bugs.pypy.org>


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

good thanks afa

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

From tracker at bugs.pypy.org  Wed Jan 23 20:11:35 2013
From: tracker at bugs.pypy.org (klankschap)
Date: Wed, 23 Jan 2013 19:11:35 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>
Message-ID: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>


New submission from klankschap <vm at klankschap.nl>:

in python 2.7.3 there is an issue with the random() generator returning result 
outside the 0.0 .. 1.0 domain.
in their bugtracker as issue 14591

the current pypy suffers from the same issue.
could it be corrected as well, as a lot of (internal) things depend on its 
correct behavior

.F

----------
messages: 5211
nosy: klankschap, pypy-issue
priority: critical
release: 2.0
status: unread
title: random() generator returning result outside the 0.0 .. 1.0 domain.

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

From tracker at bugs.pypy.org  Wed Jan 23 21:18:36 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Wed, 23 Jan 2013 20:18:36 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>
Message-ID: <1358972316.91.0.970658972506.issue1381@bugs.pypy.org>


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

Unfortunately the unit test added by CPython http://hg.python.org/cpython/rev/6df0b4ed8617
already passes with PyPy.  Did you experience this issue on PyPy?

The test passes probably for a bad reason, the jumpahead implementation is slightly different on PyPy: 
compare
    for (i = N-1; i > 1; i--) {
with
    for i in range(N - 1, 0, -1):

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

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

From tracker at bugs.pypy.org  Thu Jan 24 00:42:58 2013
From: tracker at bugs.pypy.org (klankschap)
Date: Wed, 23 Jan 2013 23:42:58 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358972316.91.0.970658972506.issue1381@bugs.pypy.org>
Message-ID: <D84C0033-8124-4F01-9333-F8EAD0A40D77@klankschap.nl>


klankschap <vm at klankschap.nl> added the comment:

On 23 Jan 2013, at 21:18, Amaury Forgeot d Arc wrote:

> 
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
> 
> Unfortunately the unit test added by CPython http://hg.python.org/cpython/rev/6df0b4ed8617
> already passes with PyPy.  Did you experience this issue on PyPy?
> 
> The test passes probably for a bad reason, the jumpahead implementation is slightly different on PyPy: 
> compare
>    for (i = N-1; i > 1; i--) {
> with
>    for i in range(N - 1, 0, -1):

i do have the same issue with pypy.
Pretty annoying as you have to insert ad hoc checks for 
u = random()

But it seems related to the random.jumpahead() function.

.F

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

From tracker at bugs.pypy.org  Thu Jan 24 11:33:52 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 24 Jan 2013 10:33:52 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>
Message-ID: <1359023632.85.0.0899641999881.issue1381@bugs.pypy.org>


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

Reproduced with the attached file, picking random seeds and jumpaheads and
testing 5'000 values afterward.  It failed for me with s, j = 4043161618,
2674112291824205302.

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

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

From tracker at bugs.pypy.org  Thu Jan 24 11:37:33 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Thu, 24 Jan 2013 10:37:33 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>
Message-ID: <1359023853.2.0.0967870866551.issue1381@bugs.pypy.org>


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

amaury: by the way, isn't it another bug of pypy, the fact that we don't
generate the same sequence of random numbers?

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

From tracker at bugs.pypy.org  Thu Jan 24 22:02:09 2013
From: tracker at bugs.pypy.org (Matthew B)
Date: Thu, 24 Jan 2013 21:02:09 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>


New submission from Matthew B <mpb21 at pitt.edu>:

Hi,
I've done some searching and haven't found anything.

Has there been any progress or even plans for supporting the OpenBabel python 
package? (openbabel.org/)
>From what I understand (which isn't much) is that there is some issue with the 
SWIG bindings with the C libraries. 

Any information would be appreciated.

Thanks,
Matt

----------
messages: 5216
nosy: mpb21, pypy-issue
priority: feature
release: ???
status: unread
title: SWIG and OpenBabel

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

From tracker at bugs.pypy.org  Thu Jan 24 23:13:25 2013
From: tracker at bugs.pypy.org (Jeff Wu)
Date: Thu, 24 Jan 2013 22:13:25 +0000
Subject: [pypy-issue] [issue1362] assert error (happens on one machine but
	not another??)
In-Reply-To: <1357891140.44.0.431137834046.issue1362@bugs.pypy.org>
Message-ID: <1359065605.58.0.693058014794.issue1362@bugs.pypy.org>


Jeff Wu <jeffwu at mit.edu> added the comment:

What is the status of this issue (if any)?  Is there likely to be a quick fix that 
I can make, for now?

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

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

From tracker at bugs.pypy.org  Thu Jan 24 23:36:42 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 24 Jan 2013 22:36:42 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359067002.47.0.895329298751.issue1382@bugs.pypy.org>


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

I managed to hack openbabel to have python bindings compiled for PyPy, and it seems to work.
No wxPython and tkInter integration.

Here is what I did:

1 - Normally start with: mkdir build; cd build; cmake .. -DPYTHON_BINDINGS=ON

2 - I edited some configuration variables (with "ccmake .", or edit the CMakeCache.txt)
to change "PYTHON_EXECUTABLE" and "PYTHON_INCLUDE_DIR", to use my PyPy installation instead.

3 - I set "PYTHON_LIBRARY" to something stupid (/dev/null), and modified Scripts/CMakeLists.txt to remove the reference to 
${PYTHON_LIBRARY}.  [On Windows, you'd set it instead to the include/python27.lib provided with PyPy]

4 - I modified Scripts/CMakeLists.txt to change the library SUFFIX from .so to .pypy-19.so [modify .pyd into .pypy-19.pyd if you 
are on Windows]

5 - Then run "cmake ." again, and "make bindings_python".

6 - Fixed a stupid C++ conversion error: the swig module calls PySlice_Check() with a PySliceObject* pointer!
On CPython it's a macro so nothing happens, but on PyPy it's a function which is supposed to take a PyObject*.
I added casts everywhere.

7 - Link will fail on Linux because of the linker option "-Wl,--no-undefined" (and PyPy does not provide a libpython27.so to link 
with). I removed this option from build/scripts/CMakeFiles/bindings_python.dir/link.txt. [This step is not relevant on windows]

8 - run "make bindings_python" again, works this time.

I guess one could install it at this point. I didn't, so I run (directly from the build directory)

BABEL_DATADIR=../data BABEL_LIBDIR=lib PYTHONPATH=lib:../scripts/python ~/pypy/pypy-1.9/bin/pypy 
../doc/examples/obconversion_readstring.py

...which worked like a charm! I even added some commands ("print mol.GetExactMass()") to be sure that the object looks correct 
(58.07825032; I don't even know what it means :-)


In short, most of the issues come from CMake, which (as usual) has a very fixed view of the world.
SWIG is correctly supported. Of course more tests are needed...

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

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

From tracker at bugs.pypy.org  Fri Jan 25 00:01:22 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 24 Jan 2013 23:01:22 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>
Message-ID: <1359068482.2.0.923335056738.issue1381@bugs.pypy.org>


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

CPython uses huge numbers (150 digits) in jumpahead, when Pypy implements it (in 
rpython/rlib/) with C longs only.
I guess we could use bigint instead... But I'm not sure it's worth the trouble. 
The function has even been removed in py3k.

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

From tracker at bugs.pypy.org  Fri Jan 25 11:37:16 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 25 Jan 2013 10:37:16 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>
Message-ID: <1359110236.33.0.513986114298.issue1381@bugs.pypy.org>


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

> With the jumpahead() , setstate() and getstate() you can keep independent
> streams for each class for every unit.
> But if there is a simpler (faster) way, please hint !

Did you know you can create distinct random objects? They keep their own internal state.

gen = random.Random()
gen.seed(something)
print gen.random()

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

From tracker at bugs.pypy.org  Fri Jan 25 15:48:26 2013
From: tracker at bugs.pypy.org (Fijal)
Date: Fri, 25 Jan 2013 14:48:26 +0000
Subject: [pypy-issue] [issue1362] assert error (happens on one machine but
	not another??)
In-Reply-To: <1357891140.44.0.431137834046.issue1362@bugs.pypy.org>
Message-ID: <1359125306.29.0.367849625752.issue1362@bugs.pypy.org>


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

Sorry :/ I think I fixed it, can you try again?

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

From tracker at bugs.pypy.org  Fri Jan 25 18:50:22 2013
From: tracker at bugs.pypy.org (klankschap)
Date: Fri, 25 Jan 2013 17:50:22 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1359110236.33.0.513986114298.issue1381@bugs.pypy.org>
Message-ID: <C6A4A600-372D-4C92-8072-F15F47A8224E@klankschap.nl>


klankschap <vm at klankschap.nl> added the comment:

On 25 Jan 2013, at 11:37, Amaury Forgeot d Arc wrote:

> 
> Amaury Forgeot d Arc <amauryfa at gmail.com> added the comment:
> 
>> With the jumpahead() , setstate() and getstate() you can keep independent
>> streams for each class for every unit.
>> But if there is a simpler (faster) way, please hint !
> 
> Did you know you can create distinct random objects? They keep their own internal state.
> 
> gen = random.Random()
> gen.seed(something)
> print gen.random()

yes i do.
But if you have to create multiple millions of instances, things do severely delay...
So the idea is to create instances of the different classes, give them their own Random() generator, and then use the getstate, jumpahead, setstate
to create adhoc sub sequences.
It works, but unfortunately due to an error somewhere with the jumpahead(), the random() returns values >= 1.0

.F

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

From tracker at bugs.pypy.org  Fri Jan 25 20:17:27 2013
From: tracker at bugs.pypy.org (Matthew B)
Date: Fri, 25 Jan 2013 19:17:27 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359141447.37.0.454572731633.issue1382@bugs.pypy.org>


Matthew B <mpb21 at pitt.edu> added the comment:

Hi, 
Thank you for your response. In CMakeCache.txt, I set PYTHON_LIBRARY to 
/dev/null as you suggested, but I could not find the ${PYTHON_LIBRARY} in 
scripts/CMakeLists.txt, but I continued anyways. I followed your instructions up 
to step 7 and removed the linker option. But I got the following error:

Linking CXX shared module ../lib/_openbabel.pypy-19.so
/dev/null: file not recognized: File truncated
collect2: error: ld returned 1 exit status

I'm assuming that the error comes from trying to link the PYTHON_LIBRARY.

Do you have any suggestions?

Thanks in advance!
Matt

Additional Details:
Ubuntu 12.10
Python 2.7.2
pypy 1.9.0
Openbabel 2.3.2

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

From tracker at bugs.pypy.org  Fri Jan 25 21:25:53 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Fri, 25 Jan 2013 20:25:53 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359145553.09.0.605530828086.issue1382@bugs.pypy.org>


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

Sorry, it was ${PYTHON_LIBRARIES} to remove:
change
    target_link_libraries(bindings_python ${PYTHON_LIBRARIES} ${BABEL_LIBRARY})
to
    target_link_libraries(bindings_python ${BABEL_LIBRARY})

(If you change CMakeLists.txt, you'll need to repeat step 5 and 7)

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

From tracker at bugs.pypy.org  Fri Jan 25 21:31:27 2013
From: tracker at bugs.pypy.org (Jeff Wu)
Date: Fri, 25 Jan 2013 20:31:27 +0000
Subject: [pypy-issue] [issue1362] assert error (happens on one machine but
	not another??)
In-Reply-To: <1357891140.44.0.431137834046.issue1362@bugs.pypy.org>
Message-ID: <1359145887.51.0.697802348519.issue1362@bugs.pypy.org>


Jeff Wu <jeffwu at mit.edu> added the comment:

works now :)
thanks!

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

From tracker at bugs.pypy.org  Mon Jan 28 14:16:24 2013
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Mon, 28 Jan 2013 13:16:24 +0000
Subject: [pypy-issue] [issue1383] ''.encode(None) -> TypeError
In-Reply-To: <1359378984.53.0.557225675387.issue1383@bugs.pypy.org>
Message-ID: <1359378984.53.0.557225675387.issue1383@bugs.pypy.org>


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

CPython: ''.encode(None) -> TypeError

PyPy: ''.encode(None) -> ''

I'm putting it as a bug because I'm unsure about which other places accept an
app-level None as the encoding.  There are certainly some, because
_get_encoding_and_errors() checks for it.

----------
messages: 5227
nosy: arigo, pypy-issue
priority: bug
status: unread
title: ''.encode(None) -> TypeError

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

From tracker at bugs.pypy.org  Mon Jan 28 20:53:08 2013
From: tracker at bugs.pypy.org (Matthew B)
Date: Mon, 28 Jan 2013 19:53:08 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359402788.36.0.665781156845.issue1382@bugs.pypy.org>


Matthew B <mpb21 at pitt.edu> added the comment:

Hi,
That seemed to fix the compiling issues, but when I run the openbabel example 
script you listed below, I get an error when it tries to import openbabel into 
pypy. It throws an error in line 7 of scripts/python/openbabel.py.
    sys.setdlopenflags(sys.getdlopenflags() | dl.RTLD_GLOBAL)
AttributeError: 'module' object has no attribute 'setdlopenflags'

It comes down to the sys.getdlopenflags() call. Importing sys into the pypy 
interactive console, then calling sys.getdlopenflags(), throws the following 
error:
>>>> import sys
>>>> sys.getdlopenflags()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'module' object has no attribute 'getdlopenflags'

Any tips?

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

From tracker at bugs.pypy.org  Mon Jan 28 21:31:19 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 28 Jan 2013 20:31:19 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359405079.56.0.74896757777.issue1382@bugs.pypy.org>


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

I simply removed this part about dlopenflags; I don't know if it's really needed.

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

From tracker at bugs.pypy.org  Mon Jan 28 21:57:46 2013
From: tracker at bugs.pypy.org (Matthew B)
Date: Mon, 28 Jan 2013 20:57:46 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359406666.47.0.213053582836.issue1382@bugs.pypy.org>


Matthew B <mpb21 at pitt.edu> added the comment:

Now I get:

Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "../doc/examples/obconversion_readstring.py", line 1, in <module>
    import openbabel as ob
  File "/home/xxx/local/openbabel-2.3.2/scripts/python/openbabel.py", line 36, 
in <module>
    _openbabel = swig_import_helper()
  File "/home/xxx/local/openbabel-2.3.2/scripts/python/openbabel.py", line 28, 
in swig_import_helper
    import _openbabel
ImportError: unable to load extension module '/home/xxx/local/openbabel-
2.3.2/build/lib/_openbabel.pypy-19.so': /home/xxx/local/openbabel-
2.3.2/build/lib/_openbabel.pypy-19.so: undefined symbol: 
_ZN9OpenBabel5OBMol16SetInternalCoordESt6vectorIPNS_15OBInternalCoordESaIS3_EE

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

From tracker at bugs.pypy.org  Mon Jan 28 22:28:31 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Mon, 28 Jan 2013 21:28:31 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359408511.7.0.614777211866.issue1382@bugs.pypy.org>


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

This symbol should be resolved by lib/libopenbabel.so.
Can you check the output of "ldd lib/_openbabel.pypy-19.so" ?

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

From tracker at bugs.pypy.org  Mon Jan 28 23:32:41 2013
From: tracker at bugs.pypy.org (Matthew B)
Date: Mon, 28 Jan 2013 22:32:41 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359412361.47.0.654968967064.issue1382@bugs.pypy.org>


Matthew B <mpb21 at pitt.edu> added the comment:

Ah, I have an existing vanilla installation of openbabel already installed, and there seems to be a 
conflict with it.

Is it possible to have both installations, because I would like to be able to use it with both pypy and 
regular python. Or would does the pypy installation work for regular python?

$ ldd lib/_openbabel.pypy-19.so
	linux-vdso.so.1 =>  (0x00007fff6a3ff000)
	libopenbabel.so.4 => /usr/local/lib/libopenbabel.so.4 (0x00007fc60f41f000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc60f0ef000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc60edf2000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc60ea33000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc60e81d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc60e618000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc60e401000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc60fd5a000)

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

From tracker at bugs.pypy.org  Tue Jan 29 11:31:21 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 29 Jan 2013 10:31:21 +0000
Subject: [pypy-issue] [issue1382] SWIG and OpenBabel
In-Reply-To: <1359061329.37.0.363114983427.issue1382@bugs.pypy.org>
Message-ID: <1359455481.13.0.989467054916.issue1382@bugs.pypy.org>


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

Ideally libopenbabel.so.4 should be independent from the scripting language, python, perl, ruby or pypy, and shared by all of them.

But since the two versions of libopenbabel.so.4 you have don't expose the same symbols, be careful...
Maybe an issue with gcc version or different build options?
You should report this to the openbabel development team. They certainly know better how the whole thing should be deployed.

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

From tracker at bugs.pypy.org  Tue Jan 29 17:27:40 2013
From: tracker at bugs.pypy.org (Philip Thiem)
Date: Tue, 29 Jan 2013 16:27:40 +0000
Subject: [pypy-issue] [issue1384] Multiprocessing on Windows
In-Reply-To: <1359476860.93.0.0495306481652.issue1384@bugs.pypy.org>
Message-ID: <1359476860.93.0.0495306481652.issue1384@bugs.pypy.org>


New submission from Philip Thiem <ptthiem at gmail.com>:

Affects 1.9 and 2.0

There is an issue which affects Python2 across the board on windows it would
appear.  I was trying to run some test cases for a package, and multiprocessing
was hanging.  I understand if you guys won't fix this looks like it fix won't be
applied to stock python 2.6 and 2.7 any time soon)

http://bugs.python.org/issue10845

the python 3.2 patch (the second chuck applies to python 2 w.o any issue really.

http://bugs.python.org/file20603/issue10845_mitigation.diff

----------
messages: 5234
nosy: pthiem, pypy-issue
priority: bug
release: 1.9
status: unread
title: Multiprocessing on Windows

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

From tracker at bugs.pypy.org  Tue Jan 29 18:02:27 2013
From: tracker at bugs.pypy.org (Philip Thiem)
Date: Tue, 29 Jan 2013 17:02:27 +0000
Subject: [pypy-issue] [issue912] ZipFile.read() leaks file handles
In-Reply-To: <1318930736.76.0.381437213231.issue912@bugs.pypy.org>
Message-ID: <1359478947.65.0.165969289823.issue912@bugs.pypy.org>


Philip Thiem <ptthiem at gmail.com> added the comment:

Aah nice I was just about to report my issues with read() in 1.9 and 2.0.  And a
more complete patch than my kludge to boot!  Will check this out.

----------
nosy: +pthiem

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

From tracker at bugs.pypy.org  Tue Jan 29 19:10:31 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Tue, 29 Jan 2013 18:10:31 +0000
Subject: [pypy-issue] [issue1385] nt._isdir is not implemented
In-Reply-To: <1359483031.58.0.249870410222.issue1385@bugs.pypy.org>
Message-ID: <1359483031.58.0.249870410222.issue1385@bugs.pypy.org>


New submission from Amaury Forgeot d Arc <amauryfa at gmail.com>:

On win32, os.path.isdir delegates to nt._isdir, but PyPy does not implement it.
See also CPython Issue #17051.

tag:easy

----------
messages: 5236
nosy: amaury, pypy-issue
priority: bug
status: unread
title: nt._isdir is not implemented

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

From tracker at bugs.pypy.org  Thu Jan 31 22:08:08 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 31 Jan 2013 21:08:08 +0000
Subject: [pypy-issue] [issue912] ZipFile.read() leaks file handles
In-Reply-To: <1318930736.76.0.381437213231.issue912@bugs.pypy.org>
Message-ID: <1359666488.71.0.622695560768.issue912@bugs.pypy.org>


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

Patch finally applied with a50a5905f738.
Thanks for your patience...

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

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

From tracker at bugs.pypy.org  Thu Jan 31 22:11:13 2013
From: tracker at bugs.pypy.org (Amaury Forgeot d Arc)
Date: Thu, 31 Jan 2013 21:11:13 +0000
Subject: [pypy-issue] [issue1381] random() generator returning result
	outside the 0.0 ..	1.0 domain.
In-Reply-To: <1358968295.22.0.11205000754.issue1381@bugs.pypy.org>
Message-ID: <1359666673.77.0.254018393148.issue1381@bugs.pypy.org>


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

Fixed with 0ec3d77645a2: jumpahead() won't generate numbers above 1.0.

Precise numbers will differ from CPython though.

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

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