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 2008. Project proposals for 2006 and 2007 are archived separately.

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.

- AutoGen - bashdb/emacs - Classpath - CLISP - DotGNU - GNOWSYS - GNUNet - Grub - IceCat - libcdio - phpGroupWare - Smalltalk - Wget -

AutoGen

AutoOpts has the ability to produce a variety of program documentation, including man pages, html, .texi, and .txt.

Right now, AutoOpts puts "plain text" into its output formats. We'd like to have a framework where we can at least begin to support some sort of "tags" where we can put information into different fonts (like using ntpd when documenting the ntpd command, perhaps "declaring" that we are using a mandoc style and using .Nm whenever we want to see ntpd). We'd also like the ability to document configuration keywords, and perhaps some support for simple tables.

If the "source" for the documentation is used to produce a man page, the output would be a decent-looking man page. If this same source is used to produce .texi page, the resulting .info page should also look good (and perhaps contain appropriate cross-indexes).

Requirements: C, possibly Guile. More info and links. (As you might guess from the above, the first user for this feature would be the excellent NTP free software program.)

bashdb, 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.

Classpath

GNU Classpath is a GNU project to create a Free clean room implementation of the core class libraries for use with virtual machines and compilers for the java programming language. In addition to the ideas presented here, you may also find some more on this wiki page.

Support the Java Attach API
This is needed to run JConsole locally (which would be the end goal of this project). Having it as part of our VM interface has general usefulness as VMs will need this for OpenJDK too.
- PR classpath/34583
BrandWeg
BrandWeg is our attempt to integrate parts of OpenJDK into Classpath to provide some of the missing functionality to VMs using the Classpath interface. This is actually capable of spawning a number of sub-projects depending on student interest:
- Using OpenJDK's java.util.Scanner
- Using OpenJDK's Swing HTML implementation
- Using OpenJDK's native ZIP implementation
- Using JAXWS from OpenJDK
Support JBoss
JBoss should run well on GNU Classpath. There are a number of open bugs for this:
Support TomCat
Likewise, TomCat should run.
- PR classpath/35482
- PR classpath/35487
Support Batik
See Classpath should be able to run Batik.
Glib as the native layer
We could simplify the portability glue code by using glib underneath. We're using glib implicitly in the GTK peers already, and it would let us delegate the responsibility for portability wrappers out of classpath, while at the same time making the native code work transparently on win32.
Rewrite Qt peers using Jambi
Our Qt peers are rotting away, and that means it's time for someone to come in and rewrite them. Qt Jambi are the official bindings for Qt for Java code, so it could be both fun and useful to rewrite our Qt based AWT peers in pure Java.
Update GJDoc to support the 1.5 language constructs
Within the GNU Classpath Free Java stack, there remains one component that can not yet fully handle the 1.5 language constructs such as generics, enumerations and annotations. A development process of approximately two years ensured that the main code base and VMs supported these extensions, but our documentation generator has so far simply being patched so that it can at least generate documentation for the current codebase. The documentation for our latest release illustrates some of the problems, notably in classes like java.lang.Enum. GJDoc really needs a new parser to handle the 1.5 constructs and then appropriate adaptation to render them correctly in the HTML doclet.
- PR classpath/33956
Add file output support for the sound API
Last year's Google Summer of Code saw a successful proposal to add support for reading and playing sound files using a GStreamer implementation of javax.sound. Support for writing sound files is still missing however.
Implement java.util.Scanner
A skeleton implementation is available from Tom Tromey. This has been a long-suffering hole in GNU Classpath.

CLISP

Complete the CLISP multithreading interface; see design spec and partial implementation. Essentially, one would have to have a good knowledge of Lisp, C, and threading and to: abstract some memory management code to be reusable by thread creation functions; implement the lisp interface to thread creation and management; audit clisp code base for thread safety.
Make CLISP embeddable.
Convert CLISP build infrastructure to Automake.

DotGNU

Finish the implementation of libJIT support for ARM or x86-64 (Complexity: medium)
For this project, you should be familiar with compiler implementation techniques and the particulars of the target CPU's instruction set. The libJIT manual describes the steps needed to for porting libJIT to new architectures. We can provide access to ARM and x86-64 machines, and indeed machines with other CPUs too.
Finish libJIT ELF writer (Complexity: medium)
Read the libjit rationale for instruction and rationale for the DotGNU JIT Library (libJIT). The libJIT library contains routines that permit pre-compiling JIT'ed functions to an on-disk representation. This representation can be loaded at some future time, to avoid the overhead of compiling the functions at runtime. We use the ELF format for this purpose, which is a common binary format used by modern operating systems and compilers. GNU/Linux uses ELF. However, it isn't necessary for your operating system to be based on ELF natively. We use our own routines to read and write ELF binaries. We chose ELF because it has all of the features that we require, and reusing an existing format was better than inventing a completely new one.
Port libJIT to a new architecture (Complexity: medium)
You could port libJIT to a new architecture, for example OpenRISC, SPARC, MIPSEL and so on. For this project, you should be familiar with compiler implementation techniques and the particulars of the target CPU's instruction set. The libJIT manual describes the steps needed to for porting libJIT to new architectures.
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.
Replacing CIL with native code. (Complexity: very 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 C# 2.0, 3.0 feature. (Complexity: very high)
The Portable .NET C# compiler is based on the treecc tool.

GNOWSYS

Last year the GNOWSYS project participated in the GSoC project successfully and the project is moving closer to a stable release from a developer only version.

Last year's project contributed a framework for and an implementation of a version control system. This eventually led to its implementation in selfplatform.eu, where GNOWSYS is used as a distributed knowledge base.

For 2008 we suggest the following projects, and we're looking forward to mentoring students who would like to work on them.

Automated harvesting of free knowledge sources like TLDP, man pages (nroff/troff), texinfo, DocBook, ODF, wikisource, LaTeX, SCORM, IMSLD and other such structured document formats into the GNOWSYS knowledge base. (Good knowledge of XML and text parsing are prior requirements here.)
Exporting the harvested knowledge (as well as the directly authored knowledge base) into other document formats (OWL, XTM, SCORM, LaTeX, DocBook), provided that these formats are free/open document standards. (As with the previous suggestion, good knowledge of XML and text parsing are prior requirements here.)
GNU Emacs client integration. This might make use of Org-Mode, for example. (requires prior knowledge of working with Emacs and XMLRPC.)
Collaborative authoring and organization of knowledge. Also graphical representation of the GNOWSYS knowledge base, using frameworks like pyGTK or Sugar (you should have some experience of these).

More details about GNOWSYS can be obtained from http://www.gnu.org/software/gnowsys/ and http://www.gnowledge.org/gnowsys/.

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.

Grub

Grub is a part of the GNU system and is participating in the Summer of Code program as part of the GNU project. However, the Summer of Code project ideas for GRUB are listed on a separate page.

IceCat

IceCat (part of Gnuzilla) is a completely free version of Firefox, with a few additional features. More information on the Gnuzilla web page. Talk to us on the bug-gnuzilla mailing list.

Port GNU IceCat to Firefox3: update the IceCat sources to all the myriad changes in Firefox3.
Support free plugins better, making xpi files for, e.g., Gnash, Plugger. Investigate GCJ as a plugin. Look for more free plugins.
Neither of these are huge projects and should perhaps be combined; also, the plugin mechanism may need to a different implementation in Firefox3 anyway. Figuring out all those details would be part of the job.
Reimplement and extend IceCat's unique privacy features (described on the web page). For reimplementation, the idea would be to make it a configurable extension with only observers left in the code. For extending, we need to think about other ways that user privacy is invaded and handle them.

libcdio

Add UDF support in libcdio, which has been asked for a number of times. Blu Ray for example uses a UDF filesystem. You can find us on the libcdio-devel mailing list.

phpGroupWare

phpGroupWare is a fully featured, web based messaging, collaboration and enterprise management platform. It comes with over 50 applications that can be mixed and matched according to your needs.

Wget

All improvements will include accompanying unit tests

Implement a database to track metadata of fetched files; further info.
Improved international support:
- Support for IDNs (Internationalized Domain Names): RFC 3490
- Support for IRIs (Internationalized URIs): RFC 3987
- Locale-aware handling of filenames and command-line URL arguments.
Convert current scan-from-huge-buffer model to a streaming model.
HTTP/1.1 support in Wget (needs Transfer-Encoding support, If-Modified-Since).
Various opportunities for code restructuring.
Regex (instead of wildcard) accept/reject lists; generic Content-Type accept/reject support.
Pick and choose from the list of bugs and feature requests in our bug tracker!

Smalltalk

Each of the ideas for GNU Smalltalk projects includes a guideline as to how hard the project is likely to be. These guidelines assume you are already familiar with Smalltalk, though not necessarily GNU Smalltalk. You can find help and advice in the places listed in the GNU Smalltalk community page.

GnuTLS bindings, including adding to Swazoo support for serving HTTPS. Other common libraries, such as GD, GSL or Expat would be interesting. In a project application you probably want to propose a coherent set of libraries to work on, with an example of an application that would tie them together. (Easy)
Work on the GUI. You could write a Gtk or Blox back-end for OmniBrowser, or add the ability to develop in the GUI and sync the files on the file system. (easy if you have previous experience in Gtk or OmniBrowser).
Develop a system to port changesets from other Smalltalks. The idea is to have a merge-like command that takes two foreign source code files (e.g. from SqueakSource) and merges the code into a GNU Smalltalk source file. (medium)
Or, you could implement a "remote browser", i.e. something that could browse an already running system. In other words, the view/controller and the model would reside on two different instances of the VM. This requires implementing or porting some kind of distributed messaging system. The same could be done for debugging; you cou investigate possibly if the protocols that are used by Java debuggers are suitable to Smalltalk. (medium)
Work on command-line tools. You could port parts of the Refactoring Browser and make a command-line version of Smalllint for example. (hard)
Create a build tool that allows one to coordinate builds with Smalltalk scripts, like Rake or SCons (see also this for an example of what I mean). (medium)
Build a continuous integration server using Seaside, with code reports. This could have many directions: building an interface to version control systems (svn, CVS, git) that can be used from Smalltalk, analyze what problems would limit the uptime of a web application written using GNU Smalltalk and Seaside (memory leaks, etc.),... (easy if you have previous experience in Seaside)

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. 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.