GSOC 2016 Ideas

This is the D Google Summer of Code page for 2016 - it is currently under heavy construction, and may remain so until February, when it will be finalized. To learn more about this year's event, 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), bringing D to mobile devices, shaping GUI libraries for D, integrating D with other languages and more.

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.

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.
• Now GCC has __atomic primitives defined for the new C++ memory model. We should take advance of these and update the API in gcc.atomics which hash out the old __synchronise primitives. The new __atomic primitives having a one-to-one mapping with core.atomic being just one of the benefits of this.
• 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: (Jens and Russell)
• std.i18n: (Jens and 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.numeric.matrix (Jens)
• 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.socket: (Jens) The existing std.socket module needs an overhaul. This includes fixing existing issues and improving its API. Keeping the module backward compatible and avoiding code breaking changes is important.
• std.units (Jens)
• 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.

Cmsed

---

Cmsed is a web services framework built on Vibe D. There are a number of improvments that need to be made to this framework. You can look here to see what has been done, and what needs to be done. A few recommendations though for suitable GSOC projects:

• Adding PDF Support.
• Adding support for Barcodes and Qr codes.

Knowledge in Compile Time Function Execution/Evaluation is not a requirement for this project. But to take full advantage be ready to learn!

Its Good To Know

• See the Cmsed project on Github.
• You will definitely need to be familiar with Vibe D.

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.