If you're interested in being a mentor, add your name here.
- Maciej Fijałkowski (firstname.lastname@example.org)
- Alex Gaynor (email@example.com)
- David Edelsohn (firstname.lastname@example.org)
- Amaury Forgeot d'Arc (email@example.com)
- Armin Rigo (firstname.lastname@example.org)
The best way to have a successful GSOC is to get involved early! If you're interested in one of these ideas, have your own idea, or just want to chat you can write to our mailing list or join us in #pypy on freenode IRC.
The list of ideas here is definitely only informative. Feel free to suggest your own ideas, as long as they have anything to do with PyPy.
Making PyPy buildbot infrastructure great
Complexity: Open ended
There is tons of work that can be done on making PyPy's continuous integration kick ass. It's a very open ended proposal, but examples include: sharing builds among various buildbots, having a fixed revision for a set of runs, more life feedback from runs, improving test parallelization.
Transparent py.test distributed testing support
py.test has running of tests on multiple cores, but this can be drastically improved upon to be more transparent. Right now it does not correctly support C-c or -x or fair distribution of tests.
Pauseless garbage collector
Write an incremental garbage collector. This is very important for e.g. games. There are well known papers on it and PyPy's GC infrastructure is pluggable, so it's possible to have multiple different ones, selectable at compile time.
ARM v6 Support
Note: This turned out to be easier than we thought and is already done. However, it's still a good example.
Currently there is an ARM backend for the JIT, however it only supports ARM v7 and up. This project would add v6 support, so that devices like the Raspberry Pi can use the JIT. Update: ARM v6 seems actually close enough to ARM v7; porting has already been more or less done. The project is changed to include a large part on the general ARM backend: finish to fix it for ARMv6 as well as for the new jitframe-in-heap branch, and then e.g. find and implement improvements to the code generation (there is a lot of sub-efficient code generated so far).
New JitViewer infrastructure
The JITviewer is a visualization tool to understand how Python code is optimized by the JIT, however the code base isn't very good and there are many limitations. This project would be to improve the source code and add new features. Note that this does not require knowledge about compilers or any experience with PyPy itself.
There currently is a mostly-complete and functioning PPC64 backend for the JIT, prior to some recent reorganizations. One, simpler phase of the project would convert the PPC64 backend to the current JIT infrastructure with the previous level of functionality. Another phase of the project would investigate and resolve the remaining GC issues in the port to achieve full functionality.
Generate wxPython Bindings for
The upcoming version of wxPython: Phoenix, uses a new code generator that parses Doxygen files to produce extension modules. The goal of the project is to customize the generator to emit cffi code instead, adapt the helper functions, and finally make wxPython work with PyPy.
Flexible unicode representation
Currently unicode strings on PyPy are always a sequence of 4-byte characters. In many cases however, all the characters in a string have a 1- or 2-byte representation that could be used. This project is to implement something similar to PEP 393 (http://www.python.org/dev/peps/pep-0393/) for PyPy.
There are of course more things that we're working on (STM, NumPy, Py3k, etc.). Some of them might also contain good GSoC projects but some others not really. For example, I (Armin Rigo) would not take a student applying for an STM-related project unless it was someone that was already sufficiently involved in STM previously --- the issue being that, yes, there is an open-ended amount of work to do, but I'm not sure which one. "Trying out various stuff on PyPy using STM" is not really a convincing GSoC proposal.