Summer of Code projects for GNU

This page has the project suggestions for GNU's participation in Google Summer of Code 2014. (Project proposals for 2006, 2007, 2008, 2009, 2010, 2011, 2012 and 2013 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 (list info here).

Please note that you are not bound to use these ideas, you can propose a new project. It is a good idea to find a mentor and discuss the idea before submit it.

Project suggestions

GNU is a large and complex project, and thus is subdivided into packages, which are relatively independent projetcts. In Summer of Code, GNU acts as an umbrella organization for its packages. The ideas here are grouped by package. Many packages have more than one suggestion, or even their own ideas page.

GNU C Library| GDB| GNU Lilypond| GNU Smalltalk| CLISP| Emacs| Gnucap| Kawa| GNUnet| GNU Guix| GNU Libffcall| Hurd| LibreDWG| Mediagoblin| Octave| Recutils| Wget| GNU Zile| GNU Bison| Dr. Geo

GNU C Library

Any Unix-like operating system needs a C library: the library which defines the "system calls" and other basic facilities such as fopen, malloc, printf, exit etc. The GNU C Library is used as *the* C library in the GNU systems and most systems with the Linux kernel.

The GNU C Library is primarily designed to be a portable and high performance C library. It follows all relevant standards including ISO C11 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known.

Note that the glibc people maintains a website with their GSOC ideas at https://sourceware.org/glibc/wiki/GSoC. We try to keep the list on this page up to date, but please take a look the sourceware page just in case.

Dynamic Documentation

The GNU C library presently has a large monolithic manual that contains documentation for much of the implemented interfaces in the libray. The problem with the manual is that it is monolithic. We would like a someone to explore an implementation of a dynamic documentation system that allows for inline documentation with code. Such a system could then be used to generate documentation directly from the source markup. Such a system could then be integrated with the existing texi documentation to be included in the final monolithic manual for compatibility. At the end of the day we wish our documentation to become easier to maintain and to be more closely integrated with the source.

ISO C11 threads

The GNU C library implements the canonical POSIX Threading (pthrad) implementation (NPTL) used on most Linux systems. In the recent ISO C11 standard a set of threading functions were defined that could easily be implemented with the existing glibc pthread functions. We would like someone to work on implementing the ISO C11 thread functions on top of pthreads and to be integrated into libpthread.so to provide these interfaces to programs wishing to use ISO C11 features. The work itself involves writing the header for the functions, implementing the functions on top of pthreads, and documenting the functions in the manual. The work can stop at any time with preference given to completing one function at a time before moving forward to the next.

Math Testing

The GNU C library implements the system math library "libm" following the relevant standards. Testing of the math functions is a difficult task and the present set of testing points is not sufficient to cover all of the different ranges for each of the defined functions. We would like someone to review, function by function, the math library routines, determine internal ranges for a functions implemetnation, and then add points to the testsuite to cover those ranges. This will also require using higher precision libraries like GMP and MPFR to validate the accuracy of the answer for the new test point. The goal being to have at least one test point per range of a given function for all functions. This work can stop at any point and we will have made progress against testing the current implementation.

Implement Missing Interfaces for GNU Hurd

In glibc's Linux kernel port, most simple POSIX interfaces are in fact just forwarded to (implemented by) Linux kernel system calls. In contrast, in the GNU Hurd port, the POSIX (and other) interfaces are actually implemented in glibc on top of the Hurd RPC protocols. A few examples: getuid, open, rmdir, setresuid, socketpair.

When new interfaces are added to glibc (new editions of POSIX and similar standards, support for new editions of C/C++ standards, new GNU-specific extensions), generally ENOSYS stubs are added, which are then used as long as there is no real implementation, and often these real implementations are only done for the Linux kernel port, but not GNU Hurd. (This is because most of the contributors are primarily interested in using glibc on Linux-based systems.) Also, there is quite a backlog of missing implementations for GNU Hurd.

In coordination with the GNU Hurd developers, you'd work on implementing such missing interfaces.

GDB

GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

gdb maintains a list of ideas here: https://sourceware.org/gdb/wiki/SummerOfCode2014/Ideas.

GNU Lilypond

LilyPond is a music engraving program, devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. LilyPond is free software and part of the GNU Project.

Make GNU LilyPond work with guile v2

That's been postponed for years by now and is basically the main reason GNU/Linux distributions still distribute GUILEv1. The work is reasonably independent from having to deal with LilyPond's architecture to be, more or less, a task of muddling through on a reasonably well-confined task on a larger code base until one reaches the finishing line. Previous knowledge of Scheme or some other functional language definitely a good idea if one wants to stay in the time limit.

Contact: lilypond-devel@gnu.org

GNU Smalltalk

GNU Smalltalk is a Smalltalk-80 implementation with the VirtualMachine written in C and most of the kernel and additional packages written in Smalltalk itself. Smalltalk is the mother of all object orientated languages and GNU Smalltalk is a modern dynamically typed script language.

VM work

Extend the GNU Smalltalk Virtual Machine to make use of multiple cores. This should include removing global state from the VM, making the core re-entrant and grouping the execution state in a struct. The next step is making the Smalltalk execution multi-threaded by adding the classic interpreter lock as known from other VMs. As time permits the lock should be removed and more/different synchronisation methods should be provided to the Smalltalk code. The whole work should be driven by benchmarks to make sure that the single-core performance is not impacted by this work.

GNU Smalltalk is using the GNU Lightning macro assembler for the Just-In-Time Compiler. The JIT is known to work with an older version of GNU Lighting and on i386. GNU Smalltalk should be ported to support GNU Lightning 2.X and it should be verified that the result works on i386, AMD64 and ARMv5te systems.

Contact: help-smalltalk@gnu.org

Smalltalk in Smalltalk

GNU Smalltalk has a Smalltalk compiler written in C and one in Smalltalk. The Smalltalk implementation has various incompatibilities that should be worked on. The work will introduce a student to the Smalltalk syntax and the Smalltalk programming language itself. The work will be done by creating unit tests.

Contact: help-smalltalk@gnu.org

GNU CLISP

Finish the multithreading interface

Most of the work has already been done by the project developers. The only major thing left to be implemented are thread safe hash tables. Since hash tables are used internally in CLOS, it is not viable to make them lockable.

The current implementation should be replaced with lock-free open-addressing ones like described here: http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf The hardest part in this reimplementation is integration with GC because of weak relations. For more information see doc/multithread.txt in the CLISP source distribution.

Contact: clisp-devel@sf.net

Emacs

GNU Emacs is the extensible, customizable, self-documenting real-time display editor.

Emacs XWidgets

Emacs XWidgets is an experimental branch to enable embedding GTK widgets inside an Emacs window. For example, this permits Emacs to render HTML pages with WebKit.

The goal of this project is to improve the current implementation by converting C code to Elisp code and to work on the GObjectIntrospection.

Contact: emacs-devel@gnu.org

Gnucap

Gnucap is a modern post-spice circuit simulator with several advantages over Spice derivatives.

Gnucap maintains a list of ideas here: http://gnucap.org/dokuwiki/doku.php?id=gnucap:projects.

Contact:Al Davis (ad201@freeelectron.net)

Kawa

Kawa is best known as a Scheme implementation for the Java platform. It compiles Scheme to java bytecodes. It is also a general framework for implementing dynamic languages, and includes a full implementation of XQuery and the beginnings of implementations of Common Lisp and Emacs Lisp (JEmacs).

Contact: kawa@sourceware.org

Kawa maintains a list of ideas here: http://www.gnu.org/software/kawa/Ideas-and-tasks.html.

GNUnet

GNUnet is a framework for secure peer-to-peer networking that 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. Anonymity is provided by making messages originating from a peer indistinguishable from messages that the peer is routing. All peers act as routers and use link-encrypted connections with stable bandwidth utilization to communicate with each other. GNUnet uses a simple, excess-based economic model to allocate resources. Peers in GNUnet monitor each others behavior with respect to resource usage; peers that contribute to the network are rewarded with better service. GNUnet is part of the GNU project.

GNUnet maintains a list of ideas here: https://gnunet.org/gsoc2014.

GNU Guix

GNU Guix is a purely functional package manager for the GNU system, and a distribution thereof.

Supporting binary package distribution through GNUnet

GNU Guix provides a transparent binary/source deployment model. A server can claim: “hey, I have the binary for /nix/store/v9zic07iar8w90zcy398r745w78a7lqs-emacs-24.3!”, where the base32 string uniquely identifies a build process. If you trust that server to provide genuine binaries, then you can grab them instead of building Emacs locally.

The “traditional model” has been to have a build farm build and serve binary packages. In that model, users trust the build farm to provide authentic binaries.

The project aims to provide a practical decentralization distribution mechanism for binary packages, using GNUnet’s file sharing service. In that model, users would be able to automatically share binaries they have built locally, and to install binaries built by other users. This is part of a broader goal of disintermediation among users, and between users and upstream software developers.

Problems to be solved include the authentication of binary packages, user privacy, and the development of a user interface that makes it trivial to contribute package build results.

Mentor: Ludovic Courtès

Package management from Emacs

The goal of this project is to write a complete package management user interface for use in GNU Emacs. The UI would provide the same functionality as the guix package command, but using an interface similar to that of package.el.

Mentor: Ludovic Courtès

Porting Guix to GNU/Hurd

GNU Guix currently supports building packages for GNU/Linux only. The goal of this project would be to allow it to cross-build and build packages for GNU/Hurd, and to provide a virtual machine image that boots into such a system.

This would involve packaging Mach/Hurd/MiG/libc, adjusting allowing cross-compilation to GNU/Hurd, cross-compiling the “bootstrap binaries” for GNU/Hurd, and then working towards support for GNU/Hurd in the (gnu system) Guix modules. This last point would allow a VM image of the complete system to be built.

Mentor: Ludovic Courtès

GNU Libffcall

GNU Libffcall is a collection of four libraries which can be used to build foreign function call interfaces in embedded interpreters.

Avcall and Callback Cleanup

Libffcall has a avcall and callback library that is to be refactored and its code is to be cleaned up for proper maintainability according to GNU standards. These projects help to reduce the complexity and hence make things better. This project entitles identifying common patterns of duplication throughout the code. Once identified, the code must be carefully refactored into new routines, common functionality, library code etc.

Testing is required to make sure refactoring was correct and functionality was not changed. Test-driven development would be helpful here.

References:

Requirements:

Level: High

Priority: High

Mentor: Avneet Kaur

Contact: libffcall@gnu.org

Trampoline and Vacall Cleanup

Trampoline and Vacall libraries needs refactoring, testing and optimization rework according to GNU standards. Improving maintainability is an active requirement which includes identifying code duplication and refactoring accordingly. This project entitles basic source code cleanup, validation and verification. Test-driven development is a must here.

References:

Requirements:

Level: High

Priority: High

Mentor: Mandeep Kaur

Contact: libffcall@gnu.org

Debug the Bugs

Libffcall is a large code base with four different libraries. That means there are guaranteed to be bugs so fixing them is always a priority. Our current BUGS file is included in every distribution which lists more than 15 major bugs.

Your project proposal should identify several specific bugs that you intend to fix

You're welcome to include testing procedures and infrastructure set up (such as automated builds) if it will help you fix bugs faster.

References:

Requirements:

Level: Medium

Priority: High

Mentor: Hardeep Rai

Contact: libffcall@gnu.org

Platform Independent and Technical Documentation

Platform independence means run code with little or no modification on multiple platforms. Technical documentation is the generic term for documentation with regard to a project. Programmer mainly associate the term with the documents and information that are passed on to by the developer:

References:

Requirements:

Level: Medium

Priority: Medium

Mentor: Avneet Kaur

Contact: libffcall@gnu.org

Hurd

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux).

Contact: bug-hurd@gnu.org (to subscribe, see the list-info page).

Please see this separate page for our project ideas, as well as on this page glibc: Implement Missing Interfaces for GNU Hurd and Porting Guix to GNU/Hurd, and also our student application form.

Libre DWG

GNU LibreDWG is a free C library to handle DWG files. It aims to be a free replacement for the OpenDWG libraries. DWG is the native file format of AutoCAD.

Automated test suite

Build an automatet test suite for LibreDWG. The test suite should have alive tests and also unity tests (test read and write for each object), compare test outputs with expected values, ecc.

Contact: libredwg@gnu.org

3D Solid decoding support

Currently LibreDWG is only able to decode 3D solids partially. The solids in DWG are encoded into the SAT and SAB formats, used by the ACIS 3D modeling kernel. There are not free implementations of this kernel, which means that the SAT and SAB streams that we are able to extract are useless if not parsed. Once parsed, the solids must be converted to other openly documented formats, and properly rendered and worked within free software tools. It is yet not clear if converting belongs to the scope of this idea, since there aren't any known {sat,sab}2something free software converters. Anyway, if your application somehow gives a light in addressing this issue, either implementing or not the converter, that would be a plus.

Contact: libredwg@gnu.org

DWG write support

LibreDWG currently supports DWG versions R13, R14, R2000 and R2004 (R2007 is on the way) but only for reading. Some write operations for entities and objects are already written, and there is a very basic write framework. Although, headers and the whole file structure are not written. Write support is almost evil, but still needed, since there is not a well stablished free CAD format, and we don't want people to leave free CAD applications because they can't send their work back to DWG-only-CAD users.

Contact: libredwg@gnu.org

mediagoblin

GNU Mediagoblin is a free software media publishing software that everyone can use.

The SoC ideas for Mediagoblin can be found in the followin webpage: http://wiki.mediagoblin.org/GSOC_2014

Contact:devel@mediagoblin.org (please subscribe to the mailing list in advance)

octave

[Note to Google: Octave also applied as a mentoring organization. Thus these ideas will be developed under the GNU umbrella only if Octave is not accepted as an org this year.]

GNU Octave is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments. It also provides extensive graphics capabilities for data visualization and manipulation. Octave is normally used through its interactive command line interface, but it can also be used to write non-interactive programs. The Octave language is quite similar to Matlab so that most programs are easily portable.

The SoC ideas for Octave can be found in the following webpage: http://wiki.octave.org/Summer_of_Code_Project_Ideas

Contact:maintainers@octave.org

Recutils

GNU Recutils is a set of tools and libraries to access human-editable, plain text databases called recfiles. The data is stored as a sequence of records, each record containing an arbitrary number of named fields.

Adding more importers and exporters to recutils

The recutils suite can currently export/import to/from CSV files, and also import MDB files. The goal of this project is to support exporting and importing rec data to and from more external formats. For this purpose the student will have to assess the implementation of the current importers/exporters and figure out what changes would be needed to facilitate the support of more formats. Then a list of formats to support will be decided and the student will code importers and exporters for them.

Contact: bug-recutils@gnu.org (to subscribe, see the list-info page).
Mentors: Jose E. Marchesi

Wget

GNU Wget is a free software package for retrieving files using HTTP, HTTPS and FTP, the most widely-used Internet protocols. It is a non-interactive commandline tool, so it may easily be called from scripts, cron jobs, terminals without X-Windows support, etc.

Extend concurrency support in Wget

Brief Explanation: There are two types of concurrency. The first is to download the same resource from multiple mirrors, the other is to download multiple resources simultaneously. Some work for adding such concurrency has already been implemented, however much more remains.
Metalink is used to allow downloading the same resource from different locations. However, these still exist some implementation bugs that need to be fixed.
Allow the user to submit a mirror-list and download the file from ‘n’ servers simultaneously.
Support for downloading multiple files simultaneously during recursive downloads has been added. Extend this to support downloading multiple files in parallel, generally.

Details about the work that has already been done can be found on the parallel-wget branch in our git repository. Expected Results: At the end of the project, the following objectives should be met:
1 Metalink support is completely implemented and functional.
2 Concurrent downloads in recursive mode is complete and functional
3 Simultaneous downloads through a mirror list
4 Concurrent downloads of multiple files
We expect to merge these contributions into the master branch as soon as possible. Knowledge Prerequisite: This project requires students who have a good grasp over C. Specifically, we need students who know how to work in multi-threaded environments and understand the various pitfalls in developing concurrent code.

Python3 based FTP Server for Test Suite

Brief Explanation: As part of GSoC ’13, we implemented a new Python3 based Test Suite to replace the old one written in Perl. A HTTP Server for the same was implemented. However, we nor require to port our FTP tests to the new test suite and hence require a programmatically configurable FTP Server implementation in Python that is fully RFC 959 compliant.

Expected Results: By the end of the project, a fully functioning Python3-based FTP Server should be available which can be configured in the same style as the existing HTTP Server in the Test Suite. The new Python3- based Test Suite can be found in the parallel-wget branch.

Knowledge Prerequisite: The student should know their way around Python3. Network programming concepts would be a plus.

Refactor Wget’s invokation mechanism

Brief Explanation: Wget’s invokation mechanism, especially the way in which it handles command line switches has been hacked into place over years of development. As a result, the code is highly sub-optimal and also adds a lot of undue restrictions on the developers trying to extend the functionality of Wget. Hence, refactor Wget’s invokation mechanism so that it is much more cleaner. Some ideas about what can be done may be found here.

Expected Results: The expected result is a much more cleaner invokation code for Wget which is just as stable as the previous code.

Knowledge Prerequisites: Since this project requires hacking only on Wget’s source, it is entirely centered around C. Having a good understanding of C and different data structures will help.

Ensure Standards Compliance for Wget

Brief Explanation: Wget is a very popular command-line tool for downloading resources from remote places. As a result, Wget is used in a variety of places by a huge number of people. We must ensure that as a HTTP and FTP client, Wget confirms to the IETF standards as best as possible. The best way to do so would be to have a bunch of tests, each testing for a compliance to a certain rule in the IETF standards documentation. There are multiple standards available, for e.g. RFC 2616 for HTTP/1.1, RFC 6265 for Cookies, RFC 6266 for the Content-Disposition Header and so on.

Expected Results: At the end of GSoC project, we wish to have a full set of tests for HTTP/1.0 and HTTP/1.1 and all the features that have currently been implemented (HTTP Only), and when possible, the appropriate fix in Wget when a standards test fails.

Knowledge Prerequisite: Good comprehension skills in English are foremost required to ensure that the standards documents are correctly read and interpreted. A working knowledge of Python is a plus since it’ll be easier to write the tests in that case. A decent grasp over C is highly recommended, since it will make debugging and finding faults much easier.

Contact: bug-wget@gnu.org (to subscribe, see the list-info page).
Mentors: Giuseppe Scrivano, Darshit Shah

GNU Zile

GNU Zile (short for "Zile Implements Lua Editors") is a toolkit for building editors. Zile has all of Emacs's basic editing features: it is 8-bit clean (though it currently lacks Unicode support), and the number of editing buffers and windows is only limited by available memory and screen space respectively. Syntax coloring, registers, minibuffer completion and auto-fill are available. Function and variable names are identical with Emacs's.

Zile currently currently comes with two editors: Zmacs, which as the name suggests emulates Emacs, and Zz, which does not support any form of Lisp, and is Emacs-inspired rather than a strict clone.

In approximate order of increasing difficulty, here are some projects that would help improve Zile:

Add Unicode support

For Zile to be useful for building serious editors, it needs Unicode support. Emacs's interface to encoding systems could be used as a model. There are already a few unicode helper libraries for Lua, which should serve as the basis for a unicode support module for Zile.

Contact: bug-zile@gnu.org

BDD/TDD

Zile has a legacy test suite for Emacs lisp compatibility, and a new infrastructure for a more comprehensive Behaviour Driven Development suite. The legacy tests need to be moved to the new infrastructure, and then the existing modules should be formally specified with new BDD examples. This is a great opportunity to get some practice working with TDD tools in a real project.

Contact: bug-zile@gnu.org

Idiomatic Lua

Lua Zile is still mostly a line-by-line translation of the earlier C Zile implementation, and as such fails to make the most of what the Lua language offers to simplify and shorten high level code, while being too liberal with the global namespace and not keeping proper cohesion and coupling between the potentially self-contained parts of the code. Refactoring is already well underway, but there's a lot of scope for re-engineering and refactoring the rest of the code base to support easier reuse

Contact: bug-zile@gnu.org

Syntax Highlighting

An earlier fork of Lua Zile provides the proof of concept for a barely-fast-enough restartable syntax parser and highlighting engine based on regexps and a state-machine. The new combined multi-editor tree needs to be refactored to allow merging the syntax highlighting module. If time allows, the restartable regexp parser would benefit hugely by being rewritten as using LPEG (Parsed Expression Grammars), and parsers for languages other than Lua and C added.

Contact: bug-zile@gnu.org

Nested Buffers

The syntax highlighting proof of concept is engineered to allow different parts of a buffer to be highlighted separately, for instance an HTML file with embedded PHP, CSS and javascript. This concept should be expanded to allow different keycaps to be active for certain parts of a buffer, for instance a shell interaction buffer that recognizes compiler error messages and in that part of the buffer treats an ENTER keypress as jumping to the file and line of the error message. If time allows, this feature could be improved to display of parts of other buffers inside the current buffer, highlighted appropriately, in this case injecting the text of the just the function surrounding the error message directly into the current buffer, highlighting it correctly according to the language it is written in, and then saving it back correctly to the appropriate file and removing the injected text from the current buffer.

Contact: bug-zile@gnu.org

Splay Ropes Buffers

Right now, Zile provides only a single buffer-gap based buffer implementation - as used by GNU Emacs. A more comprehensive Editor Building Toolkit really needs some alternative data-structures for editor builders to select, such as a Splay Ropes data structure. Other sensible data-structures as alternatives or additions to buffer-gap would also be welcome.

Contact: bug-zile@gnu.org

Zile Lisp

The Lisp engine used to simulate a tiny subset of zmacs' elisp emulation has seen dramatic improvements in recent months, and already supports many features not available in the earlier C Zile project, such as macros, eval/apply, a REPL; as well as better elisp compatibility to provide minimal features for the BDD specs. There is a huge amount of scope for improving the Lisp engine itself, adding a faster Cons/List implementation and the like, and also for adding better elisp compatibility to facilitate porting more of the zmacs implementation itself to lisp.

Contact: bug-zile@gnu.org

Zz

Zz, the other editor currently shipped with Zile, aims to leverage the already existing and well proven UNIX tools, as compared to Zmacs which wants to be a Lisp shell and IDE in the vein of Emacs. The current implementation has only gone so far in that direction as to replace Lisp with Lua. Much more work is required to replace remaining Emacs-like features with implementations that leverage the system tools. Much inspiration can be gained from Sam and ACME on Plan 9; Wily on Linux; and TextMate on Mac OS X... all of which integrate with the operating system userspace rather than reimplement equivalent features in the editor itself.

Contact: bug-zile@gnu.org

Zi

Zile currently provides a Lua implementation of a micro-emacs, called Zmacs. To improve the flexibility of the new Lua Zile frameworks, the components should be refactored and assembled into an alternative modal vi like editor -- which we'll call Zi.

Contact: bug-zile@gnu.org

Graphical Toolkit

Some care was taken to maintain separation of concerns between the user interface (keyboard input and buffer redisplay) and the internals of Zile based editors, but with only a single curses user interface it's hard to be sure that the abstractions are sufficiently clean. Adding support for an alternative GUI using GTK+, Qt or even the Mac or Windows native toolkits, along with whatever refactorings are required to support that would make using Zile to implement future editors with different io requirements much easier.

Contact: bug-zile@gnu.org

More Editors

In addition to Zmacs and Zz in the current Zile release, plus Zi on the horizon, there is also a fork of the old single editor tree called Zee, a much more minimal editor, which should be merged back in as an alternative editor example in the new multi-editor tree. Further, implementations of Nano, or WordStar, or some ancient DOS editor could be added. Much of the work in adding an editor will be to refactor the code on the boundaries between the Zile objects and files and the existing editors to facilitate easily writing new editors, while keeping the existing ones working correctly.

If you're interested in portable software engineering and re-engineering, Emacs or other text editors, or traditional UNIX tools and their future incarnations, you should find a project to interest you.

Contact: bug-zile@gnu.org

GNU Bison

Bison is a general-purpose parser generator that converts an annotated context-free grammar into a deterministic LR or generalized LR (GLR) parser employing LALR(1) parser tables. As an experimental feature, Bison can also generate IELR(1) or canonical LR(1) parser tables. Once you are proficient with Bison, you can use it to develop a wide range of language parsers, from those used in simple desk calculators to complex programming languages.

Full support of GLR in C++

Bison may generate different types of parsers, for different target languages. The traditional parser types (LR, LALR, etc.) are extremely efficient, but fail to accept some tricky grammars. GLR, on the other hand, accepts any kind of context-free grammar, even ambiguous ones. It proves extremely useful to deal with grammars that exhibit "local nondeterminism".

Bison can generate parsers in C, C++, and Java. C++ has specific constraints that prevent Bison to use the traditional union to store the various semantic types. The regular LR parser in C++ is already equipped with a sane alternative: variants. However, as of today, there is no GLR generator for C++, and therefore, no support for variants in GLR.

The project aims at providing a complete implementation of GLR in C++, with support for variants. It requires ease with C++(98), and a clear understanding of what a shift-reduce parser is.

Mentor: Akim Demaille

Dr. Geo

Dr. Geo is quite old software and has not been maintained or coded since last 6 years. The code base is very old and causes errors and segmentation faults with new libraries. The plan is to write Dr. Geo from scratch. For students to be able to complete their work in GSoC period, this has been divided into two parts.

GUI part of Dr. Geo

Mentor: H.S Rai

The old code uses c++ and with that WxWidgets library to draw the windows and other geometrical objects. Goal of this project is to rewrite the GUI part of Dr. Geo project using C/Vala programming language and GTK+ widgets toolkit. This will include all the contents of the window, the frame in which user is able to draw the geometrical objects and the Console window to provide user input.

Kernel part of Dr. Geo

Mentor: Mandeep Simak

The old code is just a blob of confusions. The goal of this project is to provide a modular approach, a kernel that could be attached with the GUI part using a good API. Kernel will get input from the GUI, will send the output to GUI. All the data manipulations and data storage will be handled by the kernel.

DXF import/export

Mentor: Jasleen Kaur

DXF is a popular format for CAD data storage and support of DXF read write should be provided in Dr. Geo. Aim of project is to create a DXF Read/Write library in C/Vala to be integratable into Dr. Geo.

Submitting ideas to this page

Links