Summer of Code project suggestions for GNU

Summer of Code projects for GNU

This page has the project suggestions for GNU's participation in Google Summer of Code 2009. (Project proposals for 2006, 2007, and 2008 are archived.)

STUDENTS - BEFORE YOU SUBMIT YOUR PROJECT PROPOSAL:

Please read the GNU Project's guidelines for Summer of Code projects.

Most importantly, please make sure you include all the information requested. If you have questions, please ask summer-of-code@gnu.org.

Project suggestions

The ideas here are listed in alphabetical order by project. Many projects have more than one suggestion.

- classpath - clisp - dotgnu - gdb - gdb-mi/emacs - gnowsys - gnucap - gnunet - hurd - libcdio - myserver - screen - shell debuggers/emacs -

Classpath

Please see this separate page for GNU Classpath.

CLISP embedding

GNU CLISP can used as an embedded system. If you would like to work on adding it to another program, the GNU CLISP maintainers are happy to help mentor that. You should also talk to the maintainers of the target package, of course. Whether they or GNU would be the principal mentors and which organization the project would be run under will depend on the details. On the GNU side, please contact Sam Steingold (CLISP maintainer) via our general mailing list summer-of-code@gnu.org.

DotGNU: Portable.NET Just-In-Time compiler and libJIT

Start with MIPS, SPARC or Itanium code generation in libJIT (complexity: easy to medium).
You can also try to develop support of any other CPU you love, for example, Elbrus-PF or even add additional intermediate code level for supporting arch specific opcodes.
Start with DWARF3 or SEH exception handling support (complexity: medium to difficult).
Complete ELF writer and loader of object code (complexity: medium).
You can also develop support of any other storage/container format. For example, PECOFF, but ELF support has already parts of code in libJIT.
Build a report how well latest Mono/Microsoft.NET libraries work with Portable.NET (complexity: easy to medium).
For example, you could work on reporting bugs; build new regression tests for Portable.NET. Or try to add simple new features to PNET that you fill up to build this summer. (Note: we have generics support).
Start with extension methods or lambda/anonymous methods support in Portable.NET (complexity: medium to difficult).
Work on building code snippets, documentation of libJIT and Portable.NET (complexity: easy to difficult).
Work on building code snippets, documentation and translation of this documentation to your native language. To work on this task you need to give evidence that you hold a good education both in mathematics and in linguistics.
Build or start with a more efficient support of OpenGL for MacOS Leopard (complexity: easy to medium).
The target of this work is to build an objective report about how libJIT compares with current engine.
Porting Application (complexity: medium).
There are a number of Free applications using .NET which currently do not run under DotGNU. Pick any non-trivial Free application and propose a Summer-of-Code project to make it work under DotGNU. The CodeProject contains many software projects that are interesting, but they are likely small. Ports should aim to create a helper class library to assist in the porting. Basically, every time a P/Invoke is found in one of these applications or a dependency exists on a third-party control or library, some stubs or primitive implementation should be exposed in this "helper" library. This includes Windows.Forms, XML, and Internet applications.
Enhance Windows.Forms (complexity: medium)
The Portable .NET Windows.Froms library implements much of .NET 1.1, but many are still missing. None of the .NET 2.0 specific Windows.Forms is implemented yet. This project would significantly enhance the completeness of implementation of at .NET 1.1 or .NET 2.0.
Start with replacing Common Intermediate Language with native code (complexity: medium to high).
DotGNU contains a code generator that can be used for Just-in-Time compilation at runtime. Code can also be compiled ahead of time to produce native code before it's needed. JIT compilation is more commonly used, but for some systems where memory is restricted or where startup time is important, pre-compiling the code can be a significant win. The goal is to modify the runtime and compilation so that the bytecodes can be safely removed from a program and a single image is shipped containing both metadata and native code.
Implement any unsupported C# 2.0, 3.0 feature in the CSCC compiler (complexity: medium)
The Portable .NET C#/C/Java compiler is based on the tree compiler-compiler tool.

GDB

Please see GDB's separate page for project suggestions and mentors.

GDB/MI and Emacs

Migrate the GDB graphical interface in Emacs to completely use GDB/MI (GDB's Machine Interface).

Currently the underlying Lisp package, gdb-ui.el, uses a mixture of annotations and GDB/MI to interact with GDB. Annotations are being deprecated and GDB/MI provides a more robust interface, as well as supporting the new features of GDB. There is currently a package called gdb-mi available from the Emacs Lisp Package Archive that fully uses GDB/MI but does not have all the features of gdb-ui.el. It could be used as a starting point and, if the project is successful, it is anticipated that the resulting code would replace gdb-ui.el after the release of Emacs 23.1. See http://users.snap.net.nz/~nickrob/ or post to emacs-devel@gnu.org for more information.

GNOWSYS

For all these projects, the candidate should know Python and XMLRPC.

Exporting the knowledge networks in GNOWSYS into other free document formats, such as RSS Feeds, OWL, XTM, LaTeX, DocBook, and ODF. (prerequisites: good knowledge of XML and text parsing)
Creating GNOWSYS-mode for GNU Emacs. This might make use of Org-Mode, for example. (prerequisites: Emacs Lisp)
Collaborative authoring and organization of knowledge networks with a pyGTK based gnowser, and porting it to Sugar. (prerequisites: good knowledge of GUI toolkits)
P2P communication between a network of GNOWSYS servers for agregation and broadcasting services.

Contact: <Nagarjuna G.>.

Gnucap

Please see the Gnucap project's separate page for project suggestions and mentors.

GNUnet and GNU libextractor

GNUnet is GNU's P2P system. It is designed as a framework and does not use any centralized or otherwise trusted services. A first service implemented on top of the networking layer allows anonymous censorship-resistant file-sharing. All link-to-link messages in the network are confidential and authenticated. The framework provides a transport abstraction layer and can currently encapsulate the peer-to-peer traffic in UDP, TCP, HTTP or SMTP messages.

GNU libextractor is a library used to extract meta-data from files of arbitrary type. The goal is to provide developers of file-sharing networks or WWW-indexing bots with a universal library to obtain simple keywords to match against queries.

The team would like to receive students' own ideas on how to improve both projects (including of course the subprojects gnunet-gtk and gnunet-qt). Talk to us! You can find us on the IRC channel #gnunet and on the gnunet-developers mailing list.

GNU Hurd

Please see the GNU Hurd project's separate page for project suggestions and mentors.

libcdio

Add UDF support in libcdio, which has been asked for a number of times. Blu Ray for example uses a UDF filesystem.
Add support for CD/DVD recording. More info.

You can find us on the libcdio-devel mailing list.

MyServer

MyServer is a powerful and easy to configure web server. If you would like to add WebDAV support or develop a GUI application that can be used to easily manage the server, please contact us on the general mailing list bug-myserver@gnu.org.

screen - embedded scripting support

GNU Screen currently does not support any kind of scripting. However, with the wide array of tasks that it is used for, some scripting support will help users to use screen in a much more effective and efficient manner. For example:

Define custom arbitrary actions, e.g. in a split layout, jump to the region containing the mail-reader, or create it and display in the current region if it doesn't exist.
Define event callbacks, e.g. send a signal to an app inside the screen window when the user switches to/from it, or not allow killing/closing a window, etc.
Specify new/custom handlers for escapes in caption/hardstatus strings (e.g., an escape to show the list of windows that have the bell/monitor/log etc. flags set, or show only titles/numbers for %w).

Some rudimentary proof-of-concept implementation for scripting support has been done. We are looking for interested students to complete this task. The student will need to design the interface between screen and the scripting module(s), and implement at least one module for a scripting language of the student's choice (e.g. guile, lua, python, perl etc.).

Interested students are welcome to discuss this, or other interesting ideas for GNU Screen on the screen-users mailing list.

shell and script debuggers and Emacs

In the last couple of years, a large number of Integrated Development Environments (IDE's) has emerged. So far, none has come close to the editing capabilities of Emacs, but on the debugger side, Emacs has been surpassed.

As many people still use Emacs as their preferred editor, an ideal situation would be that Emacs also would be used as a debugger front-end with windows for, say, the call stack, local variables, and breakpoints.

Some work in this area has been done, most notably gdb-ui.el, which provides a multi-window debugging environment for C and C++ and gdb. In addition, the ruby-debug project is doing similar work for Ruby.

This project would:

define guidelines for the look and feel for multi-window debugger Emacs environments.
refactor and unify the existing code base (gdb-ui and rdebug), to make it easier to implement support for other debuggers.
Analyze the underlying Emacs layers [1], and maybe restructure parts. Especially, the gud.el layer is a candidate for this.
Implement support for other languages and/or debuggers, for example Bash and Python.

For more information, contact R. Bernstein and Anders Lindgren.

Submitting ideas to this page

If you are an eligible student and have an idea that is not listed here, you should propose it normally through the Google Summer of Code web site (after applications are open). Please discuss it with the package maintainers.
If you are a GNU package developer, have an idea for a Summer of Code project for your own package, and can mentor it yourself, please email the idea at summer-of-code@gnu.org and one of the administrators will add it. (Simple HTML fragment in plain text preferred.) Please also recruit a backup mentor and tell us who that will be. Make sure that the description of your idea contains enough information (perhaps in the form of pointers to other information or mailing lists) for students to research the feasibility of them implementing your idea. More info.
In all other cases (e.g., you are a developer with an idea for another package), please contact the maintainer for the package. If you can find a mentor for the project (or, hopefully, can mentor it yourself), then we will add it if it is feasible. The project must meet the Summer of Code criteria; see the guidelines.