Re: [pypy-dev] PyPy 1.4 released
On 27/11/10 03:09, Phyo Arkar wrote: > libmagic python fails to work on pypy (python-magic) > > it uses ctypes and easy-install try to download and instaill it , but it > fails. > > how to enable ctypes on pypy? Hi Phyo, ctypes *is* enabled on pypy by default. If python-magic does not work, it can either: 1) be a pypy bug: please report it as an issue (possibly with a simple failing test and the full traceack) 2) a python-magic issue, e.g. if it plays dirty ctypes trick that cannot really be supported by pypy due to the internal differences with CPython ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] test_all.py -A behavior
I'm having trouble running the applevel tests on a translated pypy-c (without jit). I have this problem with recent trunk and my psycopg2 compatibility branch. Translating both with: python translate.py targetpypystandalone.py --withmod-cpyext and running tests with: translator/goal/pypy-c test_all.py -A both trunk and my branch have multiple errors on module/bz2/test/test_bz2_compdecomp.py tests, one failure in module/posix/test/test_posix2.py and both hang on the 8th test on module/signal/test/test_signal.py . This wouldn't be too weird if all three of those test suites run successfully via: translator/goal/pypy-c test_all.py -A $SUITE on both my branch and trunk. I'm on Ubuntu 10.04 32 bit. I tried again with trunk just now with the same behavior. Is this a test_all.py bug? Can anyone with a pypy-c confirm this behavior? Cheers, Dan ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Fri, Nov 26, 2010 at 6:51 PM, Dan Stromberg wrote:
>
> On Fri, Nov 26, 2010 at 4:18 PM, Dan Stromberg wrote:
>
>>
>> On Fri, Nov 26, 2010 at 3:12 PM, Antonio Cuni wrote:
>>
>>> On 16/11/10 04:30, Dan Stromberg wrote:
>>>
>>> BTW, it might cause confusion down the road to call something that is
basically like cpython's bsddb (Berkeley DB) by the name "dbm" in pypy's
library. In the cpython standard library, "dbm" is an interface to ndbm
databases. These all provide the same dictionary-like interface to
Python
programs, but have somewhat different API's to C, and pretty different,
incompatible on-disk representations.
>>>
>>> Hi Dan,
>>> I played a bit (vry quickly) with dbm on both pypy and cpython, and
>>> I'm not sure I get what you mean when you say that our dbm.py is equivalent
>>> to cpython's bsddb. E.g., I can create a db on cpython and open it from
>>> pypy, so it seems that the two modules are compatible.
>>>
>>> Moreover, I checked which libraries the links to. On CPython, it links to
>>> libdb-4.8.so:
>>>
>>> viper2 ~ $ ldd /usr/lib/python2.6/lib-dynload/dbm.so
>>>linux-gate.so.1 => (0x00884000)
>>>libdb-4.8.so => /usr/lib/libdb-4.8.so (0x0011)
>>>libpthread.so.0 => /lib/libpthread.so.0 (0x003de000)
>>>libc.so.6 => /lib/libc.so.6 (0x003f8000)
>>>/lib/ld-linux.so.2 (0x002e)
>>>
>>> the pypy version first tries to open libdb.so, then libdb-4.5.so. I had
>>> to manually modify it to open version 4.8 (I agree that we should find a
>>> more general way to find it), but apart from that what I can see is that it
>>> uses the same underlying wrapper as CPython.
>>>
>>> So, to summarise: could you elaborate a bit more why we should delete
>>> dbm.py from pypy?
>>>
>>> ciao,
>>> Anto
>>>
>>
>>
>> Looks like dbm at the API level: CPython dbm, pypy dbm
>> Looks like dbm on disk: CPython dbm
>> Looks like bsddb at the API level: CPython bsddb
>> Looks like bsddb on disk: CPython bsddb, pypy dbm
>>
>> Don't let the common prefix fool you - libdb is Berkeley DB, while dbm is
>> supposed to be ndbm.
>>
>> http://docs.python.org/library/dbm.html
>>
>> That is, pypy's dbm.py is perfectly self-consistent (other than a couple
>> of likely memory leaks), but if you try to open a database from CPython
>> using pypy's dbm module (or vice-versa), I don't believe it'll work. EG:
>>
>> $ /usr/local/cpython-2.7/bin/python
>> Python 2.7 (r27:82500, Aug 2 2010, 19:15:05)
>> [GCC 4.4.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import dbm
>> >>> d = dbm.open('d', 'n')
>> >>> d['a'] = 'b'
>> >>> d.close()
>> >>>
>> benchbox-dstromberg:/tmp/dbm-test i686-pc-linux-gnu 30890 - above cmd done
>> 2010 Fri Nov 26 04:14 PM
>>
>> $ /usr/local/pypy-1.4/bin/pypy
>> Python 2.5.2 (79529, Nov 25 2010, 20:40:03)
>> [PyPy 1.4.0] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> And now for something completely different: ``casuality violations and
>> flying''
>> import dbm
>> d = dbm.open('d', 'r')
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "/usr/local/pypy-1.4/lib_pypy/dbm.py", line 172, in open
>> raise error("Could not open file %s.db" % filename)
>> error: Could not open file d.db
>>
>>
>> HTH
>>
>> Interesting. My CPython 2.7 build has:
>
> $ ldd dbm.so
> linux-gate.so.1 => (0x009ed000)
> libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x00ed5000)
> libgdbm_compat.so.3 => /usr/lib/libgdbm_compat.so.3 (0x00269000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x00df3000)
> libc.so.6 => /lib/libc.so.6 (0x00425000)
> /lib/ld-linux.so.2 (0x00b7b000)
> benchbox-dstromberg:/usr/local/cpython-2.7/lib/python2.7/lib-dynload
> i686-pc-linux-gnu 30430 - above cmd done 2010 Fri Nov 26 06:48 PM
>
> ...but http://docs.python.org/library/dbm.html plainly says it should be
> ndbm.
>
> So which is wrong? The doc, or the module that's picking gdbm or Berkeley
> DB, as it sees fit?
>
>
But then there's this at the URL above:
This module can be used with the “classic” ndbm interface, the BSD DB
compatibility interface, or the GNU GDBM compatibility interface. On Unix,
the *configure* script will attempt to locate the appropriate header file to
simplify building this module.
I suppose that means that if it can't find ndbm (which at one time was hard
due to licensing, but last I heard it'd become readily available), it's free
to pretend it has ndbm using something else.
I'd call that puzzlingly worded - it's not the interface that's changing,
but the backend implementation. But perhaps dbm.py is free to use Berkeley
DB if it prefers to pretend it can never find ndbm. And perhaps I shouldn't
have skimmed that page so quickly ^_^
CPython 2.7's configure script has:
--with-dbmliborder=db1:db2:...
order to check db backends for dbm. Valid value is
a
Re: [pypy-dev] gdbm
On Fri, Nov 26, 2010 at 4:18 PM, Dan Stromberg wrote:
>
> On Fri, Nov 26, 2010 at 3:12 PM, Antonio Cuni wrote:
>
>> On 16/11/10 04:30, Dan Stromberg wrote:
>>
>> BTW, it might cause confusion down the road to call something that is
>>> basically like cpython's bsddb (Berkeley DB) by the name "dbm" in pypy's
>>> library. In the cpython standard library, "dbm" is an interface to ndbm
>>> databases. These all provide the same dictionary-like interface to
>>> Python
>>> programs, but have somewhat different API's to C, and pretty different,
>>> incompatible on-disk representations.
>>>
>>
>> Hi Dan,
>> I played a bit (vry quickly) with dbm on both pypy and cpython, and
>> I'm not sure I get what you mean when you say that our dbm.py is equivalent
>> to cpython's bsddb. E.g., I can create a db on cpython and open it from
>> pypy, so it seems that the two modules are compatible.
>>
>> Moreover, I checked which libraries the links to. On CPython, it links to
>> libdb-4.8.so:
>>
>> viper2 ~ $ ldd /usr/lib/python2.6/lib-dynload/dbm.so
>>linux-gate.so.1 => (0x00884000)
>>libdb-4.8.so => /usr/lib/libdb-4.8.so (0x0011)
>>libpthread.so.0 => /lib/libpthread.so.0 (0x003de000)
>>libc.so.6 => /lib/libc.so.6 (0x003f8000)
>>/lib/ld-linux.so.2 (0x002e)
>>
>> the pypy version first tries to open libdb.so, then libdb-4.5.so. I had
>> to manually modify it to open version 4.8 (I agree that we should find a
>> more general way to find it), but apart from that what I can see is that it
>> uses the same underlying wrapper as CPython.
>>
>> So, to summarise: could you elaborate a bit more why we should delete
>> dbm.py from pypy?
>>
>> ciao,
>> Anto
>>
>
>
> Looks like dbm at the API level: CPython dbm, pypy dbm
> Looks like dbm on disk: CPython dbm
> Looks like bsddb at the API level: CPython bsddb
> Looks like bsddb on disk: CPython bsddb, pypy dbm
>
> Don't let the common prefix fool you - libdb is Berkeley DB, while dbm is
> supposed to be ndbm.
>
> http://docs.python.org/library/dbm.html
>
> That is, pypy's dbm.py is perfectly self-consistent (other than a couple of
> likely memory leaks), but if you try to open a database from CPython using
> pypy's dbm module (or vice-versa), I don't believe it'll work. EG:
>
> $ /usr/local/cpython-2.7/bin/python
> Python 2.7 (r27:82500, Aug 2 2010, 19:15:05)
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import dbm
> >>> d = dbm.open('d', 'n')
> >>> d['a'] = 'b'
> >>> d.close()
> >>>
> benchbox-dstromberg:/tmp/dbm-test i686-pc-linux-gnu 30890 - above cmd done
> 2010 Fri Nov 26 04:14 PM
>
> $ /usr/local/pypy-1.4/bin/pypy
> Python 2.5.2 (79529, Nov 25 2010, 20:40:03)
> [PyPy 1.4.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> And now for something completely different: ``casuality violations and
> flying''
> import dbm
> d = dbm.open('d', 'r')
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/local/pypy-1.4/lib_pypy/dbm.py", line 172, in open
> raise error("Could not open file %s.db" % filename)
> error: Could not open file d.db
>
>
> HTH
>
> Interesting. My CPython 2.7 build has:
$ ldd dbm.so
linux-gate.so.1 => (0x009ed000)
libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0x00ed5000)
libgdbm_compat.so.3 => /usr/lib/libgdbm_compat.so.3 (0x00269000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00df3000)
libc.so.6 => /lib/libc.so.6 (0x00425000)
/lib/ld-linux.so.2 (0x00b7b000)
benchbox-dstromberg:/usr/local/cpython-2.7/lib/python2.7/lib-dynload
i686-pc-linux-gnu 30430 - above cmd done 2010 Fri Nov 26 06:48 PM
...but http://docs.python.org/library/dbm.html plainly says it should be
ndbm.
So which is wrong? The doc, or the module that's picking gdbm or Berkeley
DB, as it sees fit?
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] PyPy 1.4 released
libmagic python fails to work on pypy (python-magic) it uses ctypes and easy-install try to download and instaill it , but it fails. how to enable ctypes on pypy? On 11/27/10, Leonardo Santagada wrote: > On Fri, Nov 26, 2010 at 11:12 PM, Phyo Arkar > wrote: >> I just tested a simple hello world page in web2py and i dont see speed >> improvment yet.. >> >> pages comes up in 16-18ms in normal python , and in pypy 22-25 >> >> >> I just run directly via command $pypy web2py.py >> >> am i doing something wrong? need some extra command line options? > > The pypy jit is always on, what you could do is maybe warm up the > page, like making 100 requests and then measuring the next 10 requests > would make a more interesting benchmark. > > > -- > Leonardo Santagada > ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] PyPy 1.4 released
On Fri, Nov 26, 2010 at 11:12 PM, Phyo Arkar wrote: > I just tested a simple hello world page in web2py and i dont see speed > improvment yet.. > > pages comes up in 16-18ms in normal python , and in pypy 22-25 > > > I just run directly via command $pypy web2py.py > > am i doing something wrong? need some extra command line options? The pypy jit is always on, what you could do is maybe warm up the page, like making 100 requests and then measuring the next 10 requests would make a more interesting benchmark. -- Leonardo Santagada ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] PyPy 1.4 released
I just tested a simple hello world page in web2py and i dont see speed improvment yet.. pages comes up in 16-18ms in normal python , and in pypy 22-25 I just run directly via command $pypy web2py.py am i doing something wrong? need some extra command line options? On 11/27/10, Phyo Arkar wrote: > Grats! > i am going to give web2py : http://www.web2py.com a try on pypy > > On 11/27/10, Samuele Pedroni wrote: >> On Fri, Nov 26, 2010 at 7:23 PM, Maciej Fijalkowski >> wrote: >>> === >>> PyPy 1.4: Ouroboros in practice >>> === >>> >>> We're pleased to announce the 1.4 release of PyPy. This is a major >>> breakthrough >>> in our long journey, as PyPy 1.4 is the first PyPy release that can >>> translate >>> itself faster than CPython. Starting today, we are using PyPy more for >>> our every-day development. So may you :) You can download it here: >>> >>>http://pypy.org/download.html >>> >>> What is PyPy >>> >>> >>> PyPy is a very compliant Python interpreter, almost a drop-in >>> replacement >>> for CPython. It's fast (`pypy 1.4 and cpython 2.6`_ comparison) >>> >>> Among its new features, this release includes numerous performance >>> improvements >>> (which made fast self-hosting possible), a 64-bit JIT backend, as well >>> as serious stabilization. As of now, we can consider the 32-bit and >>> 64-bit >>> linux versions of PyPy stable enough to run `in production`_. >>> >>> Numerous speed achievements are described on `our blog`_. Normalized >>> speed >>> charts comparing `pypy 1.4 and pypy 1.3`_ as well as `pypy 1.4 and >>> cpython >>> 2.6`_ >>> are available on benchmark website. For the impatient: yes, we got a lot >>> faster! >>> >> >> congratulations! >> ___ >> pypy-dev@codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev >> > ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] PyPy 1.4 released
Grats! i am going to give web2py : http://www.web2py.com a try on pypy On 11/27/10, Samuele Pedroni wrote: > On Fri, Nov 26, 2010 at 7:23 PM, Maciej Fijalkowski > wrote: >> === >> PyPy 1.4: Ouroboros in practice >> === >> >> We're pleased to announce the 1.4 release of PyPy. This is a major >> breakthrough >> in our long journey, as PyPy 1.4 is the first PyPy release that can >> translate >> itself faster than CPython. Starting today, we are using PyPy more for >> our every-day development. So may you :) You can download it here: >> >>http://pypy.org/download.html >> >> What is PyPy >> >> >> PyPy is a very compliant Python interpreter, almost a drop-in replacement >> for CPython. It's fast (`pypy 1.4 and cpython 2.6`_ comparison) >> >> Among its new features, this release includes numerous performance >> improvements >> (which made fast self-hosting possible), a 64-bit JIT backend, as well >> as serious stabilization. As of now, we can consider the 32-bit and 64-bit >> linux versions of PyPy stable enough to run `in production`_. >> >> Numerous speed achievements are described on `our blog`_. Normalized speed >> charts comparing `pypy 1.4 and pypy 1.3`_ as well as `pypy 1.4 and cpython >> 2.6`_ >> are available on benchmark website. For the impatient: yes, we got a lot >> faster! >> > > congratulations! > ___ > pypy-dev@codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Fri, Nov 26, 2010 at 3:12 PM, Antonio Cuni wrote:
> On 16/11/10 04:30, Dan Stromberg wrote:
>
> BTW, it might cause confusion down the road to call something that is
>> basically like cpython's bsddb (Berkeley DB) by the name "dbm" in pypy's
>> library. In the cpython standard library, "dbm" is an interface to ndbm
>> databases. These all provide the same dictionary-like interface to Python
>> programs, but have somewhat different API's to C, and pretty different,
>> incompatible on-disk representations.
>>
>
> Hi Dan,
> I played a bit (vry quickly) with dbm on both pypy and cpython, and I'm
> not sure I get what you mean when you say that our dbm.py is equivalent to
> cpython's bsddb. E.g., I can create a db on cpython and open it from pypy,
> so it seems that the two modules are compatible.
>
> Moreover, I checked which libraries the links to. On CPython, it links to
> libdb-4.8.so:
>
> viper2 ~ $ ldd /usr/lib/python2.6/lib-dynload/dbm.so
>linux-gate.so.1 => (0x00884000)
>libdb-4.8.so => /usr/lib/libdb-4.8.so (0x0011)
>libpthread.so.0 => /lib/libpthread.so.0 (0x003de000)
>libc.so.6 => /lib/libc.so.6 (0x003f8000)
>/lib/ld-linux.so.2 (0x002e)
>
> the pypy version first tries to open libdb.so, then libdb-4.5.so. I had to
> manually modify it to open version 4.8 (I agree that we should find a more
> general way to find it), but apart from that what I can see is that it uses
> the same underlying wrapper as CPython.
>
> So, to summarise: could you elaborate a bit more why we should delete
> dbm.py from pypy?
>
> ciao,
> Anto
>
Looks like dbm at the API level: CPython dbm, pypy dbm
Looks like dbm on disk: CPython dbm
Looks like bsddb at the API level: CPython bsddb
Looks like bsddb on disk: CPython bsddb, pypy dbm
Don't let the common prefix fool you - libdb is Berkeley DB, while dbm is
supposed to be ndbm.
http://docs.python.org/library/dbm.html
That is, pypy's dbm.py is perfectly self-consistent (other than a couple of
likely memory leaks), but if you try to open a database from CPython using
pypy's dbm module (or vice-versa), I don't believe it'll work. EG:
$ /usr/local/cpython-2.7/bin/python
Python 2.7 (r27:82500, Aug 2 2010, 19:15:05)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import dbm
>>> d = dbm.open('d', 'n')
>>> d['a'] = 'b'
>>> d.close()
>>>
benchbox-dstromberg:/tmp/dbm-test i686-pc-linux-gnu 30890 - above cmd done
2010 Fri Nov 26 04:14 PM
$ /usr/local/pypy-1.4/bin/pypy
Python 2.5.2 (79529, Nov 25 2010, 20:40:03)
[PyPy 1.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``casuality violations and
flying''
import dbm
d = dbm.open('d', 'r')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/pypy-1.4/lib_pypy/dbm.py", line 172, in open
raise error("Could not open file %s.db" % filename)
error: Could not open file d.db
HTH
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] pypy 1.4 and virtualenv 1.5.1
On 26 November 2010 23:19, holger krekel wrote:
> Hi Michael,
>
> On Fri, Nov 26, 2010 at 22:15 +, Michael Foord wrote:
> > Congratulations on the new release.
> >
> > Unfortunately it seems that virtualenv 1.5.1 and pypy 1.4 do not play
> well
> > together on Mac OS X. At least the "--distribute" option doesn't work,
> which
> > is needed by tox.
>
> It's not needed, with tox you can configure "distribute=False" in your test
> env
> and this would install setuptools.
>
> > I tried to create an issue on the PyPy issue tracker, but new registrants
> > are unable to create issues:
> >
> > Here is the output on Linux:
> >
> > $ virtualenv -p /compile/pypy-1.4/bin/pypy pypy --distribute
> > --no-site-packages
>
> Does that work for you without --distribute?
>
Yes it does. mvt on #pypy has tracked it down to plat-mac/plist.py not being
included in pypy. This error is somehow being masked when distribute is
installed:
1. ~/src/distribute-0.6.14 $ mkvirtualenv --distribute --no-site-packages
--python=/Users/mvantellingen/pypy/bin/pypy pypy-test2
2. Running virtualenv with interpreter /Users/mvantellingen/pypy/bin/pypy
3. New pypy-c executable in pypy-test2/bin/pypy
4. Not overwriting existing pypy-c script pypy-test2/bin/pypy-c (you must
use pypy-test2/bin/pypy)
5. Installing distribute...Extracting in
/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2
6. Now working in
/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14
7. Installing Distribute
8. Traceback (most recent call last):
9. File "app_main.py", line 33, in run_toplevel
10. File "setup.py", line 37, in
11. exec(open(init_path).read(), d)
12. File "", line 8, in
13. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/setuptools/__init__.py",
line 2, in
14. from setuptools.extension import Extension, Library
15. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/setuptools/extension.py",
line 2, in
16. from setuptools.dist import _get_unpatched
17. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/setuptools/dist.py",
line 6, in
18. from setuptools.command.install import install
19. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/setuptools/command/__init__.py",
line 8, in
20. from setuptools.command import install_scripts
21. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/setuptools/command/install_scripts.py",
line 3, in
22. from pkg_resources import Distribution, PathMetadata,
ensure_directory
23. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/pkg_resources.py",
line 685, in
24. class Environment(object):
25. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/pkg_resources.py",
line 688, in Environment
26. def __init__(self, search_path=None,
platform=get_supported_platform(), python=PY_MAJOR):
27. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/pkg_resources.py",
line 77, in get_supported_platform
28. plat = 'macosx-%s-%s' % ('.'.join(_macosx_vers()[:2]),
m.group(3))
29. File
"/private/var/folders/Dk/DkuwVxyEH4CIjPxKNOHaCE+++TI/-Tmp-/tmpjCepU2/distribute-0.6.14/pkg_resources.py",
line 192, in _macosx_vers
30. import plistlib
31. ImportError: No module named plistlib
32. Something went wrong during the installation.
33. See the error message above.
34. None
35. done.
36. Complete output from command /Users/mvantellingen/virtualen.../pypy
/Users/mvantellingen/virtualen...stall
/Library/Python/2.6/site-packa...ar.gz:
37. Traceback (most recent call last):
38. File "app_main.py", line 33, in run_toplevel
39. IOError: [Errno 2] No such file or directory:
'/Users/mvantellingen/virtualenvs/pypy-test2/bin/easy_install'
40.
41. Traceback (most recent call last):
42. File "app_main.py", line 33, in run_toplevel
43. File
"/Library/Python/2.6/site-packages/virtualenv-1.5.1-py2.6.egg/virtualenv.py",
line 1647, in
44. main()
45. File
"/Library/Python/2.6/site-packages/virtualenv-1.5.1-py2.6.egg/virtualenv.py",
line 558, in main
46. prompt=options.prompt)
47. File
"/Library/Python/2.6/site-packages/virtualenv-1.5.1-py2.6.egg/virtualenv.py",
line 656, in create_environment
48. install_pip(py_executable)
49. File
"/Library/Python/2.6/site-packages/virtualenv-1.5.1-py2.6.egg/virtualenv.py",
line 415, in install_pip
50. filter_stdout=_filter_setup)
51. File
"/Library/Python/2.6/
Re: [pypy-dev] pypy 1.4 and virtualenv 1.5.1
Hi Michael, On Fri, Nov 26, 2010 at 22:15 +, Michael Foord wrote: > Congratulations on the new release. > > Unfortunately it seems that virtualenv 1.5.1 and pypy 1.4 do not play well > together on Mac OS X. At least the "--distribute" option doesn't work, which > is needed by tox. It's not needed, with tox you can configure "distribute=False" in your test env and this would install setuptools. > I tried to create an issue on the PyPy issue tracker, but new registrants > are unable to create issues: > > Here is the output on Linux: > > $ virtualenv -p /compile/pypy-1.4/bin/pypy pypy --distribute > --no-site-packages Does that work for you without --distribute? holger > Running virtualenv with interpreter /compile/pypy-1.4/bin/pypy > New pypy-c executable in pypy/bin/pypy > Also creating executable in pypy/bin/pypy-c > Installing > distributedone. > > > Here is the failed output on OS X: > > $ virtualenv -p /compile/pypy-1.4-osx/bin/pypy pypy --distribute > --no-site-packages > Running virtualenv with interpreter /compile/pypy-1.4-osx/bin/pypy > New pypy-c executable in pypy/bin/pypy > Also creating executable in pypy/bin/pypy-c > Please make sure you remove any previous custom paths from your > /Volumes/Second Drive/michael/.pydistutils.cfg file. > Installing distributedone. > Complete output from command /compile/pypy/bin/pypy > /compile/pypy/bin/easy_install /Library/Frameworks/Python.fra...ar.gz: > Traceback (most recent call last): > File "app_main.py", line 33, in run_toplevel > IOError: [Errno 2] No such file or directory: '/compile/pypy/bin/easy_install' > > Traceback (most recent call last): > File "app_main.py", line 33, in run_toplevel > File > "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", > line 1647, in > main() > File > "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", > line 558, in main > prompt=options.prompt) > File > "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", > line 656, in create_environment > install_pip(py_executable) > File > "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", > line 415, in install_pip > filter_stdout=_filter_setup) > File > "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", > line 624, in call_subprocess > % (cmd_desc, proc.returncode)) > OSError: Command /compile/pypy/bin/pypy /compile/pypy/bin/easy_install > /Library/Frameworks/Python.fra...ar.gz failed with error code 1 > > > The nice thing is that for unittest2 and mock all tests pass with pypy 1.4. > Not unexpected, but still nice. > > All the best, > > Michael Foord > > -- > http://www.voidspace.org.uk > ___ > pypy-dev@codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev -- ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] PyPy-JIT memory usage compared to CPython?
Hi, Congrats on the 1.4 release! >From the benchmark results on your site, the performance looks great. I was >wondering if you have any data showing relative memory usage for the various >benchmark. I'm particularly interested in the memory usage of PyPy-JIT vs. CPython when running Django. In general would PyPy-JIT increase or decrease memory usage? Thanks Andy ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On 16/11/10 04:30, Dan Stromberg wrote: > BTW, it might cause confusion down the road to call something that is > basically like cpython's bsddb (Berkeley DB) by the name "dbm" in pypy's > library. In the cpython standard library, "dbm" is an interface to ndbm > databases. These all provide the same dictionary-like interface to Python > programs, but have somewhat different API's to C, and pretty different, > incompatible on-disk representations. Hi Dan, I played a bit (vry quickly) with dbm on both pypy and cpython, and I'm not sure I get what you mean when you say that our dbm.py is equivalent to cpython's bsddb. E.g., I can create a db on cpython and open it from pypy, so it seems that the two modules are compatible. Moreover, I checked which libraries the links to. On CPython, it links to libdb-4.8.so: viper2 ~ $ ldd /usr/lib/python2.6/lib-dynload/dbm.so linux-gate.so.1 => (0x00884000) libdb-4.8.so => /usr/lib/libdb-4.8.so (0x0011) libpthread.so.0 => /lib/libpthread.so.0 (0x003de000) libc.so.6 => /lib/libc.so.6 (0x003f8000) /lib/ld-linux.so.2 (0x002e) the pypy version first tries to open libdb.so, then libdb-4.5.so. I had to manually modify it to open version 4.8 (I agree that we should find a more general way to find it), but apart from that what I can see is that it uses the same underlying wrapper as CPython. So, to summarise: could you elaborate a bit more why we should delete dbm.py from pypy? ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] pypy 1.4 and virtualenv 1.5.1
Hello all, Congratulations on the new release. Unfortunately it seems that virtualenv 1.5.1 and pypy 1.4 do not play well together on Mac OS X. At least the "--distribute" option doesn't work, which is needed by tox. I tried to create an issue on the PyPy issue tracker, but new registrants are unable to create issues: Here is the output on Linux: $ virtualenv -p /compile/pypy-1.4/bin/pypy pypy --distribute --no-site-packages Running virtualenv with interpreter /compile/pypy-1.4/bin/pypy New pypy-c executable in pypy/bin/pypy Also creating executable in pypy/bin/pypy-c Installing distributedone. Here is the failed output on OS X: $ virtualenv -p /compile/pypy-1.4-osx/bin/pypy pypy --distribute --no-site-packages Running virtualenv with interpreter /compile/pypy-1.4-osx/bin/pypy New pypy-c executable in pypy/bin/pypy Also creating executable in pypy/bin/pypy-c Please make sure you remove any previous custom paths from your /Volumes/Second Drive/michael/.pydistutils.cfg file. Installing distributedone. Complete output from command /compile/pypy/bin/pypy /compile/pypy/bin/easy_install /Library/Frameworks/Python.fra...ar.gz: Traceback (most recent call last): File "app_main.py", line 33, in run_toplevel IOError: [Errno 2] No such file or directory: '/compile/pypy/bin/easy_install' Traceback (most recent call last): File "app_main.py", line 33, in run_toplevel File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", line 1647, in main() File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", line 558, in main prompt=options.prompt) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", line 656, in create_environment install_pip(py_executable) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", line 415, in install_pip filter_stdout=_filter_setup) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/virtualenv.py", line 624, in call_subprocess % (cmd_desc, proc.returncode)) OSError: Command /compile/pypy/bin/pypy /compile/pypy/bin/easy_install /Library/Frameworks/Python.fra...ar.gz failed with error code 1 The nice thing is that for unittest2 and mock all tests pass with pypy 1.4. Not unexpected, but still nice. All the best, Michael Foord -- http://www.voidspace.org.uk ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] cppyy performance numbers (was: ype object 'BlackholeInterpreter' has no attribute 'bhimpl_direct_ptradd')
Hi Carl, >> PyROOT: 48.6 >> PyCintex: 50.2 >> pypy-c: 5.5 >> C++: 0.05 > > pypy-c without fast path: 5.9 (my laptop seems a bit slower than yours) > pypy-c with fast path: 0.22 > C++: 0.05 in my case, with patched reflex, using the reflex-branch of pypy with the libffi changes, I get a number of 0.41 for pypy-c. So yes, that helped a lot, even when our numbers don't seem to line up, the overall direction is definitely the way we want it. :) I'll see later when moving up to trunk makes the numbers the same (on a relative basis at least). Best regards, Wim -- wlavrij...@lbl.gov--+1 (510) 486 6411--www.lavrijsen.net ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] PyPy 1.4 released
On Fri, Nov 26, 2010 at 7:23 PM, Maciej Fijalkowski wrote: > === > PyPy 1.4: Ouroboros in practice > === > > We're pleased to announce the 1.4 release of PyPy. This is a major > breakthrough > in our long journey, as PyPy 1.4 is the first PyPy release that can translate > itself faster than CPython. Starting today, we are using PyPy more for > our every-day development. So may you :) You can download it here: > > http://pypy.org/download.html > > What is PyPy > > > PyPy is a very compliant Python interpreter, almost a drop-in replacement > for CPython. It's fast (`pypy 1.4 and cpython 2.6`_ comparison) > > Among its new features, this release includes numerous performance > improvements > (which made fast self-hosting possible), a 64-bit JIT backend, as well > as serious stabilization. As of now, we can consider the 32-bit and 64-bit > linux versions of PyPy stable enough to run `in production`_. > > Numerous speed achievements are described on `our blog`_. Normalized speed > charts comparing `pypy 1.4 and pypy 1.3`_ as well as `pypy 1.4 and cpython > 2.6`_ > are available on benchmark website. For the impatient: yes, we got a lot > faster! > congratulations! ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] PyPy 1.4 released
=== PyPy 1.4: Ouroboros in practice === We're pleased to announce the 1.4 release of PyPy. This is a major breakthrough in our long journey, as PyPy 1.4 is the first PyPy release that can translate itself faster than CPython. Starting today, we are using PyPy more for our every-day development. So may you :) You can download it here: http://pypy.org/download.html What is PyPy PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython. It's fast (`pypy 1.4 and cpython 2.6`_ comparison) Among its new features, this release includes numerous performance improvements (which made fast self-hosting possible), a 64-bit JIT backend, as well as serious stabilization. As of now, we can consider the 32-bit and 64-bit linux versions of PyPy stable enough to run `in production`_. Numerous speed achievements are described on `our blog`_. Normalized speed charts comparing `pypy 1.4 and pypy 1.3`_ as well as `pypy 1.4 and cpython 2.6`_ are available on benchmark website. For the impatient: yes, we got a lot faster! More highlights === * PyPy's built-in Just-in-Time compiler is fully transparent and automatically generated; it now also has very reasonable memory requirements. The total memory used by a very complex and long-running process (translating PyPy itself) is within 1.5x to at most 2x the memory needed by CPython, for a speed-up of 2x. * More compact instances. All instances are as compact as if they had ``__slots__``. This can give programs a big gain in memory. (In the example of translation above, we already have carefully placed ``__slots__``, so there is no extra win.) * `Virtualenv support`_: now PyPy is fully compatible with virtualenv_: note that to use it, you need a recent version of virtualenv (>= 1.5). * Faster (and JITted) regular expressions - huge boost in speeding up the `re` module. * Other speed improvements, like JITted calls to functions like map(). .. _virtualenv: http://pypi.python.org/pypi/virtualenv .. _`Virtualenv support`: http://morepypy.blogspot.com/2010/08/using-virtualenv-with-pypy.html .. _`in production`: http://morepypy.blogspot.com/2010/11/running-large-radio-telescope-software.html .. _`our blog`: http://morepypy.blogspot.com .. _`pypy 1.4 and pypy 1.3`: http://speed.pypy.org/comparison/?exe=1%2B41,1%2B172&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20&env=1&hor=false&bas=1%2B41&chart=normal+bars .. _`pypy 1.4 and cpython 2.6`: http://speed.pypy.org/comparison/?exe=2%2B35,1%2B172&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20&env=1&hor=false&bas=2%2B35&chart=normal+bars Cheers, Carl Friedrich Bolz, Antonio Cuni, Maciej Fijalkowski, Amaury Forgeot d'Arc, Armin Rigo and the PyPy team ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] cppyy performance numbers (was: ype object 'BlackholeInterpreter' has no attribute 'bhimpl_direct_ptradd')
Hi Wim, hi all, On 11/25/2010 01:32 AM, wlavrij...@lbl.gov wrote: > so I'm revising my numbers after finding out that I was using a debug > version > of ROOT/Reflex ... > > PyROOT: 48.6 > PyCintex: 50.2 > pypy-c: 5.5 > C++: 0.05 I did some benchmarks with the new fast path that I just added, it gives the following numbers: pypy-c without fast path: 5.9 (my laptop seems a bit slower than yours) pypy-c with fast path: 0.22 C++: 0.05 So Anto's and my optimization helped a lot, we got another factor of 25 faster. A bit more than a factor of 4 slower than C++, and it should work for many (non-static) method and constructor calls. > > Note that although PyROOT speeds up only marginally in opt mode, pypy-c has > a huge speedup. For PyROOT, this is b/c most of the time is spent in > CPython > through API calls and that was already in opt mode. For pypy-c, this is > telling me quite clearly that I've got to work some on capi.py. ;) > > Of course, the factor 6 that I saw originally (v.s. 2 during the sprint) is > now a factor 10 almost ... Are you sure that the units are the same? Because if yes, it is a factor of 100, not 10. Cheers, Carl Friedrich P.S.: For the people missing context, see here: http://morepypy.blogspot.com/2010/07/cern-sprint-report-wrapping-c-libraries.html ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] ype object 'BlackholeInterpreter' has no attribute 'bhimpl_direct_ptradd'
On 25/11/10 17:46, wlavrij...@lbl.gov wrote: > yes, but the fast path was disabled (commented out) when updating the branch > with trunk (I needed a few casts in the JIT that were in trunk already, but > not in the branch). It should thus be in addition when it's working again. > (And to be sure, using a float argument makes no difference for the numbers.) > > Myself, I'm just working on functionality right now. A factor of almost 10 > is already good enough to start working on a functional demo of real code, > given that most of our analysis is I/O bound. wow, if you did not use the fast path, then the 10x factor it's even more impressive :-). I think that yesterday Carl Friedrich added support to cppyy for calling the function through the new JIT-friendly "rlib.libffi" module, so now you should get the "fast-path" performance for most of the calls. Carl, could you post the benchmarks you did please? ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
