Here you'll find a couple of ideas for Google Summer of Code projects. This list is not exhaustive and you may propose any “crazy” idea you may have.
Before you submit your proposal, you are encouraged to contact the possible mentors for the project you are applying. If the project hasn't any mentor assigned or if you are submiting an off-list project, please contact one of our mailing lists to discuss the proposal before submiting it.
Priority will be given to proposals that are directly related to the PHP Project, this includes PECL. PEAR has it's own ideas page over here. If we have any spare slots then we will consider non PHP Project proposals.
If your project is to be written in PHP, please make sure you read the PEAR Coding Standards when applying.
If you are applying for a project in the PHP code itself (in C), you may find useful the PHP hackers guide, which also includes our C coding standards (TBD).
Your proposal should match our Ideas Template, if you are a student and submitting an idea of your own then you should also include:
Feel free to add your own ideas..
Possible mentor: Nuno Lopes
The PHP API has a couple of functions that are error prone and may easily cause segfaults in PHP, especially on less used platforms. The list of such functions include zend_parse_parameters*(), zend_error() and a few others. Our current check script is made in PHP and is regex based. It is available in CVS. This script is difficult to maintain and generates way too many false-positives. The work would involve creating a LLVM clang analysis tool to perform some data-flow static analysis and output error messages for the problems found. A sample output of the script mentioned is available at: http://gcov.php.net. The work can be based on previous efforts.
Possible mentor: Nuno Lopes
Make a tool to convert Zend bytecode into LLVM bitcode. Some work has alreay been done last year. A basic JIT engine already works. Features missing include: stabilization, code sharing between Apache/FastCGI processes, further optimizations, generate self-executable applications (without the PHP sources at all), etc.. (VMKit might be a good source for inspiration)
Possible mentor: Sebastian Bergmann
Implement a parser for gcov data files (#1, #2) in PHP. This would be helpful for developers that write both C-level and PHP-level code for their PHP applications and are interested in an integrated code coverage report.
Possible mentors: Zoe Slattery Stefan Priebsch
The current version of run-tests.php is a PHP 4 scripts which has grown over the years. We currently have about 8000 tests in PHP and running them sequentially using the existing script is beginning to take an unacceptably long time, the problem will only get worse as we add more tests. We prototyped parallel test execution a while ago and found that it could be done but it was impossibly difficult to do using the existing run-tests.php script. There are other improvements that we'd like to add to run-tests (for example XML output) which we thought would also be easier if the existing run-tests.php script was re-engineered. Over the past few months we have been working on this and have a prototype OO version of run-tests that is currently able to run most of the tests in ex/standard/tests. The code is designed so that adding parallel running will be easy, we'd like to propose that a student takes on (at least) this part of the work - it's interesting and quite difficult PHP coding. A good student could extend beyond this and implement other new features (XML, reporting).
Possible mentors: Nuno Lopes, Paul Biggar
Work on replacing the current bench.php benchmarking script with something better. Ideas and discussion in: RFC: Better benchmarks for PHP
Possible mentors: Elizabeth M Smith
This would be a two part project. Part one would involve a web interface to allow developers to choose extensions (either static or shared) and options for test builds of PHP with error checking. The front end should spawn configure lines (for Windows or Linux) and queue them.
The back end should attempt to build the resulting configurations, push any binaries/log files to a server and email the requester with the location/status of the finished build product.
PHP-GTK's docs should be moved to the new PhD rendering system, but it is a fairly large job.
Would involve
Possible mentors: Elizabeth M Smith
PHP-GTK does not implement all functions for the latest versions of GTK+. This project primarily involves writing overrides for functions whose implementation is not automatically created by the generator. At the end of the project, all functions defined up to the latest version of GTK+ will be expected to work. This will include not only the GTK symbols but the latest version of ATK, Pango, and Gdk.
Possible mentors: Dmitry Stogov
php-cgi is not useful in production environment without additional “crutches” (e.g. spawn-fcgi from lighttpd distribution or php-fpm patch). This project assumes integration of such “crutches” and extending php-cgi to support for different protocols.
Possible mentors: Hannes Magnusson
phd is the tool that renders the DocBook based documentation for both the PHP Manual and PEAR Manual. It uses XMLReader to read the XML, so it has many obvious drawbacks but XMLReader is also the reason why it's so blazing fast.
Today PhD is PHP.net centric, meaning it contains several “rules” and “workarounds” that are only applicable to PHP.net. The project goals:
For questions and thoughts please join the #php.doc IRC channel on EFnet and/or write the PHP Documentation list at phpdoc@lists.php.net
Possible mentors: Derick Rethans, Sebastian Bergmann
Xdebug is a tool for debugging, analyzing and profiling PHP applications. One of its features is analyzing which code has been executed in a function. At the moment this only happens with a line-based resolution. This project is about extending this to analyze which code *paths* are being covered in functions and methods. This project idea requires C-skills, and you will get very intimate with the PHP internals. Feel free to drop by in either #php.pecl or #xdebug on Freenode (and look for Derick) if you have any questions.
Possible mentors: Derick Rethans
Xdebug is a tool for debugging, analyzing and profiling PHP applications. As part of its remote debugging features it allows you to see variables contents change when they're modified in the code. What is currently not supported is setting breakpoints on variables so that the debugging process interrupts when one of the “watched” variables are changed. This project idea is for implementing this specific feature. Implementing this would requires C-skills, and you will get very intimate with the PHP internals. Feel free to drop by in either #php.pecl or #xdebug on EFnet (and look for Derick) if you have any questions.
Possible mentors: Pierre A. Joye, Alejandro Leiva
Cmake is a cross platform make system that would generate native makefiles for developers and has a much simpler syntax to that of m4. Kitware, the company behind cmake is helping us to migrate and to improve cmake to fit our needs.
Mainly this taks for GSoC should be:
For questions and thoughts please join the #php.cmake IRC channel on EFnet also you can check the wiki page of php-cmake.
Possible mentors: Philip Olson
PHP has a bug tracker, and it needs improvements. Possible tasks include:
Resources of interest:
Possible mentors: Yannick Torres, Philip Olson
Work has started on an online editor for the PHP Manual. The student would help get this tool up and running for live use at php.net. The tool performs the following actions:
Resources of interest:
Possible mentors: Philip Olson
This idea is simple, as it involves scouring the PHP bugs database and fixing bugs. The procedure:
There are several people and maintainers who would be involved with this idea, such as Tony, Jani, and Johannes. Priority should be given to PHP 5.3 bugs.
Possible mentor: Brian Shire, Andrei Zmievski
Currently, PHP extensions that have dependencies on other extensions use compile-time configure checks to verify availability. This has several problems:
/* expose API to other extensions * we'll be exposing a fetch() function and a store() function * from our extension. This could be any calls we want to expose. * extension_api_t is a custom structure for this extension with * function pointers defining this extension's API. */ struct extension_api_t api; api.version = 1; api.fetch = my_fetch; api.store = my_store; php_register_api(&api)
/* fetch external extension API */ int rval; int version = 2; struct extension_api_t *api; rval = php_get_api('myextension', version, &api); if (rval == PHP_EXT_UNAVAIL) { zend_error(E_WARNING, "myextension is not loaded or available, disabling feature"); return NULL; } else if (rval == PHP_EXT_NOVERSION) { zend_error(E_WARNING, "myextension version %d is required, disabling feature", version); return NULL; } else { return api->fetch(key); }
Possible mentor: Paul Biggar, Other interested mentors please add your names
Currently, the structure of PHP extensions requires a very tight coupling with the Zend Engine. This restricts the reimplementation of the Zend engine, and prevents PHP from becoming significantly faster in the long term.
The problem statement, and design for a solution are presented in Remove Zend API.
As part of the GSOC, the student should complete the first two goals in Remove Zend API to a high standard, and the third to a reasonably advanced prototype. The goal of converting the entire set of extensions is, of course, not part of the project. To be considered a success, a good prototyping of 5 or 6 extensions should be achieved.
As well as the code, a short report should be produced, discussing the viability of the approach for the entire set of standard extensions. It should describe what challenges remain to be solved to make it possible, and whether or not the student finds this realistic. This is a very important part of the project, as it will not otherwise be easy to gauge the potential success of this approach over the entire PHP project. This report is not the same as that which is required by Google as part of the GSOC program.