Hi all, there was some discussion about possible Summer of Code topics on the #pypy channel today. We had several project ideas: - work on the JIT assembler backends. There are several possible projects here, like writing a much simpler i386 backend and adding float support to that; or writing a x64 backend; or writing a new i386 backend that uses the more modern bits of the processor for arithmetic (like SSE and friends). - support ctypes on more backends. right now ctypes is supported only when compiling PyPy to C. A nice project would be to support it when compiling to .NET. That's not too hard, the only thing needed is to port a small module that does the actual invocation of external libraries (a related project would be to port this module to Jython or IronPython to get support for ctypes there). - support some of the more recent features of CPython. A nice project would be to support all of the remaining CPython 2.5 features and port over the changes to the standard library (which includes re-writing some of the C-coded modules in RPython or pure Python). Another possibility would be to even start looking into the 2.6 features. - Anto proposed to make the javascript backendopt more useful by turning it into something more frameworkish. I am sceptical of the viability of the task, it would need a very clever student and probably a lot of work too. What do you all think of these ideas? Are there other ideas around? I know that Jakub posted something a while ago (haven't looked in detail yet, though). In my opinion we should try to avoid "yet another incomplete interpreter implentation" for this year. The timeplan is to collect some more ideas, then write a better description of them and make a blog post about it (say around Thursday). Sounds like a plan? Cheers, Carl Friedrich
Carl Friedrich Bolz wrote:
What do you all think of these ideas? Are there other ideas around?
maybe another possible task could be to port an existing external library to pypy, either by writing a mixed module or by using ctypes; possible choices are pygtk, postgresql/mysql DB API, pygame, etc. I don't know whether they are small enough to fit into SoC, though. ciao Anto
"Carl Friedrich Bolz" <cfbolz@gmx.de> wrote in message news:47DE9B1B.3070104@gmx.de... || Another possibility would be to even start looking into the 2.6 | features. As near as I can tell, 2.6 is pretty much the union of 2.5 and 3.0. Most of the new features that do not change old code have been backported. Many (most?) of the changes that do will be available as future imports. So a feature-complete 3.0 might be easier than a feature-complete 2.6. tjr
On 17/03/2008, at 13:23, Carl Friedrich Bolz wrote:
What do you all think of these ideas? Are there other ideas around? I know that Jakub posted something a while ago (haven't looked in detail yet, though). In my opinion we should try to avoid "yet another incomplete interpreter implentation" for this year.
- Threads using the new gc seems pretty important - Numeric on pypy - the scientific comunity could use pypy because they don't need many extensions, mostly scipy wich numeric is the center - Porting ZODB to pypy - this might show a lot of bugs of pypy as it is a really complex extension. []'s -- Leonardo Santagada
Leonardo Santagada wrote:
On 17/03/2008, at 13:23, Carl Friedrich Bolz wrote:
What do you all think of these ideas? Are there other ideas around? I know that Jakub posted something a while ago (haven't looked in detail yet, though). In my opinion we should try to avoid "yet another incomplete interpreter implentation" for this year.
- Threads using the new gc seems pretty important
That's true, but I fear that this is a very hard (probably too hard) task.
- Numeric on pypy - the scientific comunity could use pypy because they don't need many extensions, mostly scipy wich numeric is the center - Porting ZODB to pypy - this might show a lot of bugs of pypy as it is a really complex extension.
Both of these are potentially very annoying. Either you write a PyPy-specific extension module (using rffi), then you have tons of fun because we don't have separate compilation yet. Or you do this with ctypes, which probably has way too much overhead for computation-bound applications, especially with our slow implementation. I guess rewriting big projects in ctypes should only be done for projects where it seems likely that the original authors of the project will later care for the ctypes rewrite. Otherwise you get the effect that now happens for pygame: the ctypes rewrite of it is more or less abandoned. Cheers, Carl Friedrich
Hi Carl, On Tue, Mar 18, 2008 at 10:53:46AM +0100, Carl Friedrich Bolz wrote:
- Threads using the new gc seems pretty important
That's true, but I fear that this is a very hard (probably too hard) task.
No, the basic task is only to ensure that threads and our new GCs can be used in the same pypy-c. This doesn't mean that the GCs should be multithreaded or even thread-safe, if we take care of only allocating objects when the GIL is held (Global Interpreter Lock). A fully multithreaded GC is step two. It would be good for RPython programs that are more freely multithreaded, like Alexander's attempt to just remove the GIL from pypy-c and not care about crashes (using explicit locks at application-level to prevent them). Getting there is more work indeed. Any student with JikesRVM MMTk experience around? :-) A bientot, Armin.
Am Montag, 17. März 2008 17:23:55 schrieb Carl Friedrich Bolz: [...]
What do you all think of these ideas? Are there other ideas around? I know that Jakub posted something a while ago (haven't looked in detail yet, though). In my opinion we should try to avoid "yet another incomplete interpreter implentation" for this year.
Maybe Jakub could be persuaded to implement his ideas as a python extension. Just my 2c Stephan
What do you all think of these ideas? Are there other ideas around? I know that Jakub posted something a while ago (haven't looked in detail yet, though). In my opinion we should try to avoid "yet another incomplete interpreter implentation" for this year.
I fully agree. Still, what I proposed was not attempt to create another one, but keep existing one alive. It is bothering me, that scheme interpreter is incomplete, but the problem is, i could not find a use case for it (except of Thousand Parsecs internal scripting language - if none other - faster - scheme implementation available). So if PyPy is such a nice platform to experiment, let's do it, and play with different approaches to implement parallel paradigms, or whatsoever. There is no need for yet another scheme interpreter (even complete) if it doesn't have any interesting features. That's my 3 cents for now. Cheers, Jakub Gustak
participants (7)
-
Antonio Cuni -
Armin Rigo -
Carl Friedrich Bolz -
Jakub Gustak -
Leonardo Santagada -
Stephan Diehl -
Terry Reedy