The GNU Ada Translator (GNAT) isn't available for the Hurd so far. There are also a number of other Debian packages depending on GNAT, and thus not buildable on the Hurd.

The goal of this project is getting GNAT fully working in Debian GNU/Hurd. It requires implementing some explicitly system-specific stuff in GNAT, and maybe fixing a few other problems. Good knowledge of Ada is a must; some Hurd knowledge will have to be acquired while working on the project.

Designing and implementing language bindings is a follow-up project.

Possible mentors: Samuel Thibault (youpi), Thomas Schwinge (tschwinge).

Exercise: Fix one of the problems preventing GNAT from working on the Hurd.

Open Issue page. Entry in the GCC wiki.

The main idea of the Hurd design is giving users the ability to easily modify/extend the system's functionality (extensible system). This is done by creating filesystem translators and other kinds of Hurd servers.

However, in practice this is not as easy as it should, because creating translators and other servers is quite involved -- the interfaces for doing that are not exactly simple, and available only for C programs. Being able to easily create simple translators in RAD languages is highly desirable, to really be able to reap the advantages of the Hurd architecture.

Originally Lisp was meant to be the second system language besides C in the GNU system; but that doesn't mean we are bound to Lisp. Bindings for any popular high-level language, that helps quickly creating simple programs, are highly welcome.

Several approaches are possible when creating such bindings. One way is simply to provide wrappers to all the available C libraries (libtrivfs, libnetfs etc.). While this is easy (it requires relatively little consideration), it may not be the optimal solution. It is preferable to hook in at a lower level, thus being able to create interfaces that are specially adapted to make good use of the features available in the respective language.

These more specialized bindings could hook in at some of the lower level library interfaces (libports, glibc, etc.); use the MIG-provided RPC stubs directly; or even create native stubs directly from the interface definitions. The lisp bindings created by Flavio Cruz as his 2008 GSoC project mostly use the latter approach, and can serve as a good example. In his 2011 GSoC project, Jérémie Koenig designed and began implementing an object-oriented interface; see his Java status page for details.

There is another possible reason for preferring lower-level bindings: Presently, the Hurd server libraries use the cthreads threading library, which predates the pthread standard prevalent today. There is a pthread library for the Hurd as well, but it's not possible to use both cthreads and pthreads in the same executable. Thus, until porting the Hurd libraries to pthreads is finished, implementing bindings for any language that uses pthreads (in the runtime environment or the actual programs) is only possible when not using the standard Hurd server libraries at all -- i.e. when binding at MIG stub level or interface definition level.

The task is to create easy to use Hurd bindings for a language of the student's choice, and some example servers to prove that it works well in practice. This project will require gaining a very good understanding of the various Hurd interfaces. Skills in designing nice programming interfaces are a must.

Anatoly A. Kazantsev has started working on Python bindings last year -- if Python is your language of choice, you probably should take his work and complete it.

There was also some previous work on Perl bindings, which might serve as a reference if you want to work on Perl.

Possible mentors: Anatoly A. Kazantsev (anatoly) for Python