My hope is that someone who is already familiar with the PyPy build process and various compatibility quirks might be able to both quickly determine whether there would be build compatibility as well as, perhaps, succeeding in actually building it. When I fail to build something against PyPy, it's less obvious to me than to many of the people here whether the failure can be easily resolved by the use of cpyext or some other sophisticated, PyPy-specicific hack.
My hope and suspicion, here, is that this kind of task is one that benefits significantly from experience with the subtleties of PyPy interoperability, rather than mere cleverness or a more general familiarity with software development. I.e., that this is a challenge that might be on the one hand quite straightforward (if a little tedious) to some, while perhaps nearly impossible to many others. This just seemed like potential "low-hanging fruit" -- minimal work that might lead to greatly expanded deployment of PyPy. Leo On Wed, Apr 11, 2012 at 10:50 PM, Stefan Behnel <stefan...@behnel.de> wrote: > Leo Trottier, 11.04.2012 20:56: > > Actually, my motivation was not to get Calibre to be faster -- I use it > > only occasionally. All I knew was that Calibre was an application (1) > built > > on Python, that (2) the Python interpreter it used was baked-in to the > > distribution, and (3) it seemed to perform a number of operations > somewhat > > slowly. > > > > It seems that whenever (1) and (2) hold, there is a potential opportunity > > for the wide-scale deployment of PyPy, taking it from being used on a > > handful of servers and enthusiasts computers to instead being deployed on > > thousands or 10s of thousands of end-user applications. > > > > Perhaps PyPy *might* not immediately lead to an increase in performance > > (though one suspects that in general, it would), but the mere fact that > > it's available to the application developer could inspire new development > > paradigms that take advantage of PyPy's features. And it could serve as > a > > practical test-bed for deploying PyPy and for evaluating tweaks to it. > > Ah, ok. Then your question is somewhat backwards, though. You should start > by looking for an application that matches the above properties *and* that > runs well in PyPy or is at least not too difficult to port. Otherwise, this > discussion will stay at a rather theoretical level and the answer is "yes, > sure, whenever you find an application for which it works, it will work for > that application". > > You could start by looking through PyPy's compatibility list to see if any > of the names looks familiar and suitable. When users report problems that > are listed there, that's usually because they have an interest in making > something run in PyPy. > > Stefan > > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > http://mail.python.org/mailman/listinfo/pypy-dev >
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
