GSOC 2016 Ideas

This is the D Google Summer of Code page for 2016 - which is now complete. To learn more about the Google Summer of Code, see the Google Summer of Code 2015 page. If you are interested in participating in the 2016 GSOC as either a student or mentor, and want to do something related to D, please feel free to contact our GSOC administrator Craig Dillabaugh (firstname dot lastname at gmail dot com).

Timeline

The timeline for GSoC for 2016 has now been posted here.

Ideas

Plenty of challenging and important projects exist in the D world. They range from writing new or improving existing modules of D's standard library (Phobos), working on its compilers (Compilers), shaping GUI libraries for D, integrating D with other languages and more.

C to D conversion tool (DStep)

---

The DStep project provides a tool to convert C headers to D modules. Since D interfaces nicely with C this allows D users to quickly connect to any C library. The DStep project can use a number of improvements:

• Getting the D code more looking like the C code. For example, the same order for the symbols as the C code has. Currently it outputs all variables first, then all types and all functions last.
• Add support for comments.
• Generated libclang bindings. These are now manually created, mostly for the above two reasons. Ideally it would be possible to generate bindings almost exactly like the manually created ones.
• Cross-platform testing environment. A single script/tool that runs the tests on all supported platforms using Docker and Vagrant/VirtualBox.
• Windows support.
• See existing todo list.

Its Good To Know

A good knowledge of compilers will be helpful, in particular some experience with clang/llvm.

FlatBuffers Support or Improved Protocol Buffer Support

---

FlatBuffers is an efficient cross platform serialization library for C++, C#, Go, Java, JavaScript, PHP, and Python (C and Ruby in progress). It was originally created at Google for game development and other performance-critical applications. Currently there is no support in D for FlatBuffers, so this project would involve building FlatBuffers support from scratch. The goal of the project is to contribute the D support to the upstream repository.

Existing work has been done to provide Protocol Buffers support for D, however, there are a number of areas that can be improved including:

• comments and deprecated fields handling
• generate interfaces for protobuf services
• upstream repo CI integration
• define the native D representation of all "well known" types
• optimization of non-recursive messages
• benchmarking

Its Good To Know

It would be worthwhile to have experience working with either Protocol Buffers of Flatbuffers in another language, but such experience is hardly a necessity.

SDC Project - D Compiler as a Library

---

Project Desription:

The SDC project (https://github.com/deadalnix/SDC) is an effort to provide a D compiler as a library. Any ideas to further the development of this project are welcome, but for a student who would like a specific project we propose the following

• Start by implementing with @property feature of D. This feature will allow a D programmer to create functions that are called using the same syntax as variable access.
• Using the @property feature the student will be able to implement the runtime support for slices and associative arrays. The operations to implement are as follows:
  • Implement arrray operations like concatenation and appending, and implement a sound memory management strategy for the underlying data.
  • Implement a generic and efficient hash table. The data structure and algorithms used must be flexibile enough to be adapted to any type of data that might be stored in the table. A concurrent version of the table is need for shared data.
• Finally, the student will implement masquerading of D syntax into calls for the runtime.
• Integrate LLVM's new JIT infrastructure in SDC, the On-Request Compilation JIT (ORCJit) API. This would simplify the implementation of certain D features such as Compile Time Function Evaluation (CTFE) for SDC.

Its Good To Know

• Please watch Amaury's DConf talk on SDC.
• SDC is developed in D (of course) so you will need to be proficient in D by the time you start coding.
• You should have taken at least one course on compilers, or at the least be willing to educate yourself in this regard. There is a decent course availabe through Coursera https://www.coursera.org/course/compilers
• You should familiarize yourself with classicial data structures for arrays and have knowledge of various schemes for table implementations, (it is worthwhile to read up on hopscotch and robin hood hashing).
• SDC uses LLVM for code generation, so some familiarity with LLVM will be required (see http://llvm.org/docs/tutorial/index.html).

GDC Project - The GNU D Compiler

---

GDC is a D compiler based on the GCC backend. There are a few outstanding issues in GDC that have ended up in the backlog of known issues to fix, as well as changes that could be beneficial to upstream and other compilers.

Compiler Improvements

• Implement support for compiling with LTO (-flto) turned on.
• There are various XBUG markers in GDC's testsuite, some haven't been looked at in a long time. There should be fewer!
• Internal Documentation. Ideally every function should have a comment describing its use and input values. As the bulk of what happens in the glue is just providing for backend members declared in the front-end. Most should be pretty trivial to work through.
• Debugging Support. Enumerals of non-scalar types currently emit no debugging information. A solution should be proposed and implemented for this.
• Improving codegen for better optimisations. Currently all shared types are marked volatile, which is a workaround for not being able to prevent shared decls from being cached into registers by other means. Improvements could also be done around parameter passing, taking advantage of D storage attributes.

Library Improvements

• Get shared library support working. The current implementation upstream in DM druntime has not been tested or merged in, and it is not clear what changes are required to support it, or whether is even going to be feasibly possible with GDC.
• GDC EH support is lacking the ability to chain multiple thrown exceptions together in its deh personality routines.
• More targets are expected to land in GDC pretty soon. In preparation for this, we should investigate an alternate layout of druntime before the long lists of version conditions becomes a problem for port maintainers (See #11666).

DDT

---

DDT is an Eclipse-based IDE for the D programming lanaguage, aiming to support rich functionality, particularly semantic functionality (code completion, find definition, find references, etc.). There are two areas which prospective students could target for improvement:

• DDT Core Engine
  • Make the DDT semantic engine available as a command-line daemon tool (similar to DCD).
  • Add support for source formatting (with formatting options).
  • Add support for semantic search in the semantic engine (search symbols by anem and type). For example, "where in my code is the function std.stdio.writeln" called?", or "which classes in my code subclass the given class?".
  • Improve semantic engine / code completion capabilities. For example, understand template instantiation, function overloads, etc.
• Eclipse Specific Enhancements
  • Improve/add UI support for DUB multiple build configurations and launch.
  • Reduce usage of DLTK code, possibly refactoring or rewriting DLTK functionality into an IDE-neutral layer (LangEclipseIDE).
  • Add support for continous build mode (build and report errors on the fly).

Some of these ideas are a bit small for a full GGoC project, so it might make sense to combine a couple of tasks into a single project.

QML Bindings

---

The DOtherSide project is an effort to develop D bindings to QML. There are a number of possible contributions that a student could contribute to. These include:

• (Easy) (Examples) Mut be put on par with those of Nim
• (Difficult) (D) Find a way for simplifiing the syntax by injecting code generated at compile time. This task implies a deep/rich knowledge of D metaprogramming features like template mixins and mixin.
• (Medium) (D) Enable the creation QObject subclasses. Right now this is limited to one level of hierarchy in the D side. We can use the same solution implemented in Nim.

Given these points there're other tasks regarding the plain C++ backend: - (Medium) Find a way to create instances of types created in D/Nim and make them instantiable in Qml.

Some projects for which there is not already a solution:

• (Medium) Right now there's no support for connecting signals and slots between object defined in the D/Nim side.
• (Difficult) Find a way to bundle the QML as resources from both D and Nim and make them available to Qml
• (Medium) Expose an API for adding a custom image provider

Bare Metal ARM Support

---

This is a project focuses on bare metal cross-compilers and an appealing eco-system to surround it. The goal is to raise the awareness of D in the open hardware community at large and prove D's systems programming lanugage title along the way. It's hard not to notice the growing momentum of the open hardware movement. Yesterday's newbies awkwardly messing with theirs first Arduinos are today's mature embedded systems hackers. The hanger for ever more powerful systems takes them en mass towards ARM development boards. These systems often lack a good open source toolchain, e.g. linker scripts, HAL, so that D certainly can be a compelling offering in this setting (compared to C/C++ in usability). The project is two-fold and can be geared towards any of the 2 major parts:

• Getting a bare-metal D runtime support on Cortex-M3/M4 with as many language features as possible. A minor victory would be having a minimal thread-less and GC-less runtime. A more ambitious plan here is creating a small-ish RTOS in D, to provide full runtime with threads, mutexes etc.
• Create a Wiring or mbed look-alike library in D for a selected family of popular chips (and consequently a range of boards). Instead of cloning a popular API you might also design your own hardware abstraction library using D to it's full extend. The challenge here is to tackle things like GPIOs, USARTs, I2C, SPIs, PWM, ADC and other peripherals commonly found in MCUs in a future-proof way.

Its Good To Know

Cool demos (including public videos) are an obligatory part of the project ;) For a starting point see this project (some D working on STM32 boards). Michael V. Franklin has done some work bare-metal ARM which is worthwhile to review:

• D Conf Talk
• ARM Cortex-M study

Phobos: D Standard Library

---

There is still signficant work to be done in order to get the D Standard Libraries into a proper state. The following libraries are good candidates for GSoC projects:

• std.benchmark: (Russell)
• std.i18n: (Russell) Design and implement a basic internationalization framework. It may be possible to implement this with pragma(msg). For proof of concept see http://arsdnet.net/dcode/i18n.d . It should provide at least the following functionality:
  • A locale part, std.i18n.locale which should detect a user's default lanaguage, select a global application lanaguage, and provide types to describe and work with locales.
  • A text translation part, std.i18n.translation, which should be gettext compatible, preferably using the gettext serialized hashtables in .mo files, and provide low level (gettext like) and high level (boost::locale like) APIs.
  • A tool to extract strings which need to be translated from D code. This should preferably be based on DScanner but alternately could use regular expressions. Optionally support for D code could be added to xgettext.
• std.parallelism (Russell) std.parallelism needs a review and some benchmarking - prior to making improvements. As part of this is would be good to have a standard benchmarking framework, hence the idea of std.benchmark. However there is no need for it to be in std (and hence Phobos) in the first instance. So the project(s) would be to create a comparative benchmarking framework that can then be used to analyse std.parallelism on a more scientific basis than has been done to date.
• std.units: unit conversion library
• std.xml The std.xml module badly needs a rewrite. For inspiration you can look at an abandoned attempt to update it here. Another bit of code you may want to check out for ideas is Adam D. Ruppe's dom.d.
• std.serialization: A flexible (de)serialization framework that can be used as a standardized building block for various serialization related things: std.json, std.csv, Protocol Buffers, Cap'n Proto, vibe.d... One important goal would be to define how a user-specified type has to work in order to make it serializable, as well as to allow the end-user (e.g. a user of std.json) to change the serialization of third-party types that cannot themselves be modified. A good starting point is would be to work with the Orange framework.

Additional Project Ideas

---

Here we list a few less fully developed ideas that, nevertheless, could be worked into cool D related projects:

• Bringing a parser generator library into phobos, either based on pegged or independent parser.
• SQL parser, binder, validator.
• Anything building on the strengths on D: introspection, compile-time stuff, DSL, etc.
• Improving the Garbage Collector, this would be challenging but would bring you great glory!

Ideas From Previous Years

GSoC idea pages from past years:

• GSoC 2015 Ideas (not accepted)
• GSoC 2014 Ideas (not accepted)
• GSoC 2013 Ideas (not accepted)
• GSoC 2012 Ideas
• GSoC 2011 Ideas

Tips for students

Daniel Pocock has written a detailed blog about initiatives students can take if they want to have a serious chance of being selected in GSoC without a focus on one specific organization.

To learn more about potential mentors check our mentor page here.

Tips for Mentors

If you are interested in mentoring, please check out the organization administrator and mentor manual for more information.