Hi, since pypy is in Debian for some time, I sometimes test it with our project SymPy[1], written in pure Python 2.4 and newer. Generally, it works out of the box and it's very nice and quite fast. You did an awesome job! However, sometimes, it fails, because of the bug[2], that we reported two months ago. Do you think you could please apply the patch provided in there, or just fix it somehow? Also another question - what is your plan with your RPython to javascript converter - are you planning to create something like the Google Web Toolkit, or just leave it as is, if someone becomes interested? I think it would be a very cool feature to have something like this in Python, just a little more documented and officially released. Thanks a lot, Ondrej Certik [1] http://code.google.com/p/sympy/ [2] https://codespeak.net/issue/pypy-dev/issue316
Hi Ondrej, Ondrej Certik wrote:
Thanks for doing that! It's nice to hear that it's mostly working. Indeed at one point we could probably consider to use SymPy as some sort of benchmark for PyPy – it's not easy to find nice pure-Python programs that are computationally bound.
Thanks for reporting it. Our problem with it is that we don't quite know how to fix it properly. Potentially, int_w itself should be calling __int__, but we are not sure whether this is good for all use-cases of int_w.
I think the PyPy team cannot put much more effort into this than what we did already. So we would need somebody interested who would work mostly exclusively on the JavaScript backend to make it live up to its full potential. Cheers, Carl Friedrich
Hi Carl,
We are actually optimizing sympy to by fast on top of a normal CPython, for example instantiating python classes is very expensive. But I guess it should be very similar in pypy as well. There is another problem actually: $ py.test --exec=pypy * opening PopenGateway: /usr/bin/pypy MASTER: initiated slave terminal session -> MASTER: send start info, topdir=/home/ondra/sympy Traceback (most recent call last): File "?", line 32, in run_toplevel File "?", line 265, in run_it File "<string>", line 1, in <module> File "<string>", line 40, in <module> ImportError: No module named thread Traceback (most recent call last): File "/usr/bin/py.test", line 4, in ? py.test.cmdline.main() File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 15, in main failures = session.main() File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", line 82, in main failures = self.run_remote_session(failures) File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", line 111, in run_remote_session return channel.receive() File "/usr/lib/python2.4/site-packages/py/execnet/channel.py", line 175, in receive raise self._getremoteerror() or EOFError() EOFError There is not module thread in there. So I cannot test the whole sympy using pypy, because we have all our tests made using py.test. Feel free to put this into the issues.
Right, but do you agree, that this should be working in python 2.4? So there must be some way to do it.
So what is your priority now with pypy? I think it has such an enormous potential, but currently for me it's just a playground. Do you plan to apply pypy in some area, where people will use it as the best technology available in there? Or do you plan more to have pypy just as a means of testing new JIT ideas? Ondrej
I forgot to add - I am using the versions from Debian unstable. I don't have time to test everything from svn, however, if you want, I can make new versions of pypy/py.test available in Debian when you release them, but I think the current maintainer will do also do it - Alexandre Fayolle is the maintainer of those packages - should I report bugs in them to Debian BTS, or here? I think the way to go is just users report problems against the packages in their distributions, like Debian, it is forwarded here, you fix it in svn, release a new version, it gets to Debian, etc. Ondrej
Hi Ondrej, On Mon, Sep 17, 2007 at 04:32:13PM +0200, Ondrej Certik wrote:
$ pypy `which py.test` ImportError: No module named py
That's obviously because the python path of pypy doesn't allow it to find the 'py' module. You don't have this problem if you don't use the globally-installed py.test, but the one from a PyPy checkout instead: pypy .../pypy-dist/py/bin/py.test args... or equivalently pypy .../pypy-dist/pypy/test_all.py args... A bientot, Armin.
Hi Armin,
I tried: ondra@fuji:~/sympy$ PYTHONPATH="/usr/lib/python2.4/site-packages/" pypy `which py.test` and got many errors, but I think all are the same: def __init__(self, targetfd, tmpfile=None): self.targetfd = targetfd if tmpfile is None:
tmpfile = self.maketmpfile()
[/usr/lib/python2.4/site-packages/py/io/fdcapture.py:12] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ def maketmpfile(self): """ create a temporary file """ E f = os.tmpfile()
AttributeError: 'module' object has no attribute 'tmpfile'
[/usr/lib/python2.4/site-packages/py/io/fdcapture.py:44] _______________________________________________________________________________ ================= tests finished: 21 failed in 11.93 seconds ================== So, I think it's the problem in py lib in debian, that it doesn't work with pypy? Then I tried as you suggested now: in /tmp: $ svn co http://codespeak.net/svn/pypy/dist pypy-dist in ~/sympy: $ pypy /tmp/pypy-dist/py/bin/py.test But the exact same problem as above: def maketmpfile(self): """ create a temporary file """ E f = os.tmpfile()
AttributeError: 'module' object has no attribute 'tmpfile'
[/tmp/pypy-dist/py/io/fdcapture.py:44] _______________________________________________________________________________ ================== tests finished: 21 failed in 1.80 seconds ================== then I tried: $ pypy /tmp/pypy-dist/pypy/test_all.py and again the same problem. Maybe just the pypy in Debian is old? In this case maybe it's time for a new release. :) If you tell me what to fix, I'll send a patch to the debian maintainer to fix it in Debian. Ondrej
Hi Ondrej, On Wed, Sep 19, 2007 at 02:22:38PM +0200, Ondrej Certik wrote:
Yes, os.tmpfile() was added in the meantime. I personally don't see much the point of making Debian packages of PyPy at the moment, given that we're in a state where you are almost always better off if you start from our Subversion repository instead of from a release a few months old. We're not "user-ready" and this situation will not change before some more months, maybe 1 year. I'd really recommend starting from our 'getting-started' document on the web site instead of the Debian packages. A bientot, Armin.
Hi Armin,
Thanks for the explanation. I know how to use it from svn, I was compiling pypy from svn from the first version, that translated itself, just for fun. But I thought that since you released the 1.0 version, I could simply start using the Debian package. Ondrej
Hi Ondrej, Ondrej Certik wrote:
Thanks for doing that! It's nice to hear that it's mostly working. Indeed at one point we could probably consider to use SymPy as some sort of benchmark for PyPy – it's not easy to find nice pure-Python programs that are computationally bound.
Thanks for reporting it. Our problem with it is that we don't quite know how to fix it properly. Potentially, int_w itself should be calling __int__, but we are not sure whether this is good for all use-cases of int_w.
I think the PyPy team cannot put much more effort into this than what we did already. So we would need somebody interested who would work mostly exclusively on the JavaScript backend to make it live up to its full potential. Cheers, Carl Friedrich
Hi Carl,
We are actually optimizing sympy to by fast on top of a normal CPython, for example instantiating python classes is very expensive. But I guess it should be very similar in pypy as well. There is another problem actually: $ py.test --exec=pypy * opening PopenGateway: /usr/bin/pypy MASTER: initiated slave terminal session -> MASTER: send start info, topdir=/home/ondra/sympy Traceback (most recent call last): File "?", line 32, in run_toplevel File "?", line 265, in run_it File "<string>", line 1, in <module> File "<string>", line 40, in <module> ImportError: No module named thread Traceback (most recent call last): File "/usr/bin/py.test", line 4, in ? py.test.cmdline.main() File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 15, in main failures = session.main() File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", line 82, in main failures = self.run_remote_session(failures) File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", line 111, in run_remote_session return channel.receive() File "/usr/lib/python2.4/site-packages/py/execnet/channel.py", line 175, in receive raise self._getremoteerror() or EOFError() EOFError There is not module thread in there. So I cannot test the whole sympy using pypy, because we have all our tests made using py.test. Feel free to put this into the issues.
Right, but do you agree, that this should be working in python 2.4? So there must be some way to do it.
So what is your priority now with pypy? I think it has such an enormous potential, but currently for me it's just a playground. Do you plan to apply pypy in some area, where people will use it as the best technology available in there? Or do you plan more to have pypy just as a means of testing new JIT ideas? Ondrej
I forgot to add - I am using the versions from Debian unstable. I don't have time to test everything from svn, however, if you want, I can make new versions of pypy/py.test available in Debian when you release them, but I think the current maintainer will do also do it - Alexandre Fayolle is the maintainer of those packages - should I report bugs in them to Debian BTS, or here? I think the way to go is just users report problems against the packages in their distributions, like Debian, it is forwarded here, you fix it in svn, release a new version, it gets to Debian, etc. Ondrej
Hi Ondrej, On Mon, Sep 17, 2007 at 04:32:13PM +0200, Ondrej Certik wrote:
$ pypy `which py.test` ImportError: No module named py
That's obviously because the python path of pypy doesn't allow it to find the 'py' module. You don't have this problem if you don't use the globally-installed py.test, but the one from a PyPy checkout instead: pypy .../pypy-dist/py/bin/py.test args... or equivalently pypy .../pypy-dist/pypy/test_all.py args... A bientot, Armin.
Hi Armin,
I tried: ondra@fuji:~/sympy$ PYTHONPATH="/usr/lib/python2.4/site-packages/" pypy `which py.test` and got many errors, but I think all are the same: def __init__(self, targetfd, tmpfile=None): self.targetfd = targetfd if tmpfile is None:
tmpfile = self.maketmpfile()
[/usr/lib/python2.4/site-packages/py/io/fdcapture.py:12] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ def maketmpfile(self): """ create a temporary file """ E f = os.tmpfile()
AttributeError: 'module' object has no attribute 'tmpfile'
[/usr/lib/python2.4/site-packages/py/io/fdcapture.py:44] _______________________________________________________________________________ ================= tests finished: 21 failed in 11.93 seconds ================== So, I think it's the problem in py lib in debian, that it doesn't work with pypy? Then I tried as you suggested now: in /tmp: $ svn co http://codespeak.net/svn/pypy/dist pypy-dist in ~/sympy: $ pypy /tmp/pypy-dist/py/bin/py.test But the exact same problem as above: def maketmpfile(self): """ create a temporary file """ E f = os.tmpfile()
AttributeError: 'module' object has no attribute 'tmpfile'
[/tmp/pypy-dist/py/io/fdcapture.py:44] _______________________________________________________________________________ ================== tests finished: 21 failed in 1.80 seconds ================== then I tried: $ pypy /tmp/pypy-dist/pypy/test_all.py and again the same problem. Maybe just the pypy in Debian is old? In this case maybe it's time for a new release. :) If you tell me what to fix, I'll send a patch to the debian maintainer to fix it in Debian. Ondrej
Hi Ondrej, On Wed, Sep 19, 2007 at 02:22:38PM +0200, Ondrej Certik wrote:
Yes, os.tmpfile() was added in the meantime. I personally don't see much the point of making Debian packages of PyPy at the moment, given that we're in a state where you are almost always better off if you start from our Subversion repository instead of from a release a few months old. We're not "user-ready" and this situation will not change before some more months, maybe 1 year. I'd really recommend starting from our 'getting-started' document on the web site instead of the Debian packages. A bientot, Armin.
Hi Armin,
Thanks for the explanation. I know how to use it from svn, I was compiling pypy from svn from the first version, that translated itself, just for fun. But I thought that since you released the 1.0 version, I could simply start using the Debian package. Ondrej
participants (3)
-
Armin Rigo -
Carl Friedrich Bolz -
Ondrej Certik