Mailman 3 September 2010 - pypy-dev

Re: [pypy-dev] External RPython mailing list
by Hart's Antler Sept. 16, 2010

Sept. 16, 2010

Porting ShedSkin to use the PyPy translation toolchain on the surface sounds like a good idea, but its not if we look at the details. The first issue is legal, PyPy is MIT licensed, which works very well when integrated by commerical software. But Shedskin uses the GNU GPL3, so importing any of its code (or code that imports GPL code, etc) into the user's compiled program also binds it to the GPL - which is no good for commerical software. Shedskin within the PyPy toolchain may taint the … [View More]users program with GPL code because some RPython programs will import from rlib (which may in someway depend on Mark's GPL code). The second issue is technical, not much is gained for the likely great amount of effort it would take to merge ShedSkin. Lets look at what is gained: 1. muteable globals 2. None and (int,float) are intermixable as attributes on an instance because ShedSkin has some limited support for dynamic-sub-types. (PyPy can not mix None with int and float) 3. operator overloading (except for __iter__ and __call__), PyPy only allows overloading __init__ and __del__ #1, would be nice to have but its an easy workaround to use singleton instances. #2, no big advantage. #3, this is a big advantage, i wish i could at least overload __getattr__ in PyPy Rpy. ShedSkin is behind PyPy Rpy in the following areas: 1. no getattr, hasattr etc. 2. *args (Mark says he can bring it back but only for homogenous types (PyPy supports *args with non-homogenous types)) 3. passing method references 4. no interface to C 5. mixed-type tuples are limited to length two (PyPy allows for any length) 6. multiple inheritance The ShedSkin readme itself states that " the type inference techniques employed by Shed Skin currently do not scale very well beyond several hundred lines of code" and recommends ShedSkin only for small programs. Not having the 6 items above are additional reasons why ShedSkin is not ideal for writting large programs, these are serious limitations for a large program, especially #4 - not having a easy way to interface with C is a huge show-stopper; PyPy Rpy has an amazingly simple way to interface with C (rffi). The other dissadvantages of ShedSkin are: slow object allocation (Phil Hassey did a test showing ShedSkin 30% slower than RPython), and it only translates to C++ while PyPy can translate to C, Java, and #C. There are simple ways to improve PyPy Rpy that will benifit both the PyPy project and those who strictly want to use the translation toolchain. I've been following the progress of this years Google Summer of Code projects, and i see a big stumbling block for everybody was RPython. PyPy today would have a better 64bit JIT, faster ctypes, and better numpy support if RPython was itself better. RPython Wishlist: . documentation . iteration over tuples of any length (with any mixed types) . overloading __getattr__, __setattr__ . pickle support, if its limited thats ok. . rstruct is incomplete . llvm backend, what happened to llvm support? . not having to define dummy functions on the base class to prevent 'demotion' . not having to use the hack `assert isinstance(a,MySubClass)` to call methods with incompatible signatures. . we already have the decorator: @specialize.argtype(1), why can't we have @specialize.argtype(*) so that all arguments can have flexible types? . methods stored in a list for easy dispatch can not have mismatched signatures. I aggree with Fijal, CPython module extension should be a low priority. There is a big speed overhead when passing data back and forth from CPython, and speed is the whole point of going through the trouble of writting in RPython. Those who are less concerned with speed and want CPython module extensions can use Cython, which is well tested. Those who are interested in RPython and want a simple way to get started can use ShedSkin to make an extension module, and then migrate their module to a standalone app with PyPy if they choose. -hart [View Less]

4 4

PyPy to generate C/C++ code
by Saravanan Shanmugham Sept. 15, 2010

Sept. 15, 2010

To be very clear this is not a question on PyPY RPython itself. :-)) But I had another thought and wanted to run it by PyPy team. As I understand it PyPy is foremost a language development framework. It is about implementing the python interpreter in RPython, plus additional hints to assist in JIT generation. If the Python language implementation in RPython has enough information to create a python interpreter and do JIT compilation. I am thinking it should have enough information to … [View More]

5 5

Fwd: PyPy to generate C/C++ code
by Benjamin Peterson Sept. 15, 2010

Sept. 15, 2010

---------- Forwarded message ---------- From: Benjamin Peterson <benjamin(a)python.org> Date: 2010/9/14 Subject: Re: [pypy-dev] PyPy to generate C/C++ code To: Saravanan Shanmugham <sarvi(a)yahoo.com> 2010/9/14 Saravanan Shanmugham <sarvi(a)yahoo.com>: > I don't expect this python compiler to be for full python but just a Restricted > statically typed subset of python as defined by Shedskin. So how is that any different than the existing RPython? -- Regards, … [View More]

2 1

External RPython mailing list
by Armin Rigo Sept. 14, 2010

Sept. 14, 2010

Hi, To anyone interested, Sarvi(?) created an RPython mailing list (Thanks Bea for spotting this): http://pyppet.blogspot.com/2010/09/rpython-mailing-list.html The following paragraph should have been posted as a comment to that blog post, but it doesn't record my post no matter how much I try, so I'll put it here: """ Ah, sorry about the money issue. I didn't realize that you already sent it to us; I misunderstood that you would not send it at all after we told you that we don't have … [View More]

7 14

Re: [pypy-dev] PyPy JIT & C extensions, greenlet
by Andy Sept. 13, 2010

Sept. 13, 2010

--- On Fri, 9/10/10, Armin Rigo <arigo(a)tunes.org> wrote: > On Thu, Sep 9, 2010 at 8:04 PM, Andy <angelflow(a)yahoo.com> > wrote: > > Is there any plan to make PyPy JIT work with greenlet > and C extensions? > > If so when may that be available? > > As far as I can tell it works already. Just download > (http://buildbot.pypy.org/nightly/trunk/) > or build yourself a > stackless version of PyPy; it should contain "cpyext", > which means … [View More]

4 5

PyPy JIT and Django
by Andy Sept. 9, 2010

Sept. 9, 2010

I'd like to run Django on PyPy JIT. Could you give me some instructions on how to do that? I couldn't really find any documentation in that area. Thanks. Andy

5 7

PyPy JIT & C extensions, greenlet
by Andy Sept. 9, 2010

Sept. 9, 2010

Hi, I'm interested in using PyPy JIT with async greenlet-based frameworks such as gevent or meinheld. Is there any plan to make PyPy JIT work with greenlet and C extensions? If so when may that be available? Thanks. Andy

1 0

Loop invaraints
by Hakan Ardo Sept. 7, 2010

Sept. 7, 2010

Hi, some time ago, there were some discussion about loop invaraints, but no conclusion. What do you think about the following approach: - Let optimize_loop mark the arguments in loop.inputargs as invariant if they appear at the same position in the jump instruction at the end before calling propagate_formward - Let the optimize_... methods emit operations that only uses invariant arguments to some preamble instead of emitting them to self.newoperations whenever that is safe. Also, the result … [View More]

6 12

Re: [pypy-dev] Question on the future of RPython
by Hart's Antler Sept. 5, 2010

Sept. 5, 2010

RPython is a nice language even right now, its very useful, i'm using it all the time. Too many people downplay its potentials saying its too hard or complex. I like the error messages, they help you understand how it all works; however it would be nice to see an official FAQ where the common errors are explained in plain english. RPython is only lacking a version number. -brett

2 1

Registration for S3 - A Workshop on Self-Sustaining Systems is now open.
by Carl Friedrich Bolz Sept. 1, 2010

Sept. 1, 2010

Registration for S3 - A Workshop on Self-Sustaining Systems is now open. http://www.hpi.uni-potsdam.de/hirschfeld/s3/s3-10/ We hope you will join us on September 27-28 in Tokyo. Invited speakers: • Takashi Ikegami: Sustainable Autonomy and Designing Mind Time (The University of Tokyo) • Yukihiro Matsumoto: From Lisp to Ruby to Rubinius (Rakuten Institute of Technology) • Vishal Sikka: On Sustainable Business Solutions (SAP) You can find the workshop at: http://www.hpi.… [View More]

1 0