Summer of Code projects for GNU
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 firstname.lastname@example.org.
The ideas here are listed in alphabetical order by project. Many projects have more than one suggestion.
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).
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 , 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.
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
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.
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.
- Support Batik
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.
- 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.
- 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.
- Finish the implementation of libJIT support for ARM or x86-64
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:
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
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
The Portable .NET C# compiler is based on the treecc tool.
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).
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.Summer of Code project ideas for GRUB are listed on a separate page.
- 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.
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 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.
- New Template Engine
- Improved Database Abstraction
- Workflow Engine in the API
- Rework Setup
- Add SyncML Support to other Modules
- Improve Usability of Sitemgr CMS Module
- New wiki Module
- Improved Email Module
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!
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 email@example.com 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.