GSOC 2019 Ideas

This is the D Language Foundation's Google Summer of Code 2019 page.

If you are interested in working on a D project as part of GSoC 2019, please feel free to ask questions on the D Newsgroup. For more specific questions, please contact the GSoC admins at gsoc@dlang.rocks.

Timeline

The timeline for GSoC 2019 can be found here.

Ideas

The D ecosystem is always in need of improvement through the revision of existing projects and the creation of new ones. The core projects like the(standard library) and the compilers (Compilers) are always in need of attention. Other important areas include GUI support, integration with other languages, improving and enhancing the tooling, IDE and editor support, and more.

Please add your project ideas to the list below, being as descriptive as you can in the summaries. Students interested in participating can use the ideas listed here as jumping off points, so the more information you provide, the easier it will be for them to get started. If your idea is particularly complex or nuanced, consider leaving contact information so that interested parties may follow up.

DUB: D's package manager

---

DUB - D's package manager - is one of the central infrastructure tools in the D world as a convenient build and package management tool for the D community. With D gaining more and more popularity, it's also a key tool to guarantee D's further adoption. Thus there are many great ideas to improve DUB:

• git support
• separate compilation and caching
• extensibility through DUB
• control flow directives
• build system support for C/C++
• support dub install for distributions
• support building a {snap, Debian, Arch, ...} package out of DUB package

Any of these listed DUB Enhancement Proposals (DEPs) could form the basis of a GSoC Project.

Update: A very detailed list of ideas for improving Dub can be found in this Forum thread.

Proposed Project Mentors: Sönke Ludwig, Sebastian Wilzbach

Header generation for C/C++

---

With the ever-improving integration between DMD and C/C++, quite a bit of tooling has been developed to generate D header files from C or C++ projects (e.g. DStep or DPP). However, for many projects the majority of the source code is now written in D and the reverse step is needed: an automatic way to generate C and C++ headers from a D project. This would be very valuable for D as it could motivate inter-language projects that typically go C++-first-with-a-D-binding to work the other way.

Starting points:

• NG-Thread: "Make DMD emit C++ .h files same as .di files"
• Existing specialized work for the DMD codebase
• Existing WIP work for generating C headers
• Existing WIP work for generating C++ headers, using DMD as a library

Proposed Project Mentor: Andrei Alexandrescu, Nicholas Wilson

Language Server Protocol for D

---

A Language Server is meant to provide the language-specific smarts and communicate with development tools over a protocol that enables inter-process communication. The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc.

Adding features like auto complete, go to definition, or documentation on hover for a programming language takes significant effort. Traditionally this work had to be repeated for each development tool, as each tool provides different APIs for implementing the same feature (see the list of Editors and IDEs). Additionally as the existing tools use `libdparse` (used in DLS and DCD), they lack the ability to perform semantic analysis on the AST and can't evaluate `mixin`'s nor D's very powerful Compile-Time Function Evaluation (CTFE).

The idea behind the Language Server Protocol (LSP) is to standardize the protocol for how such servers and development tools communicate. This way, a single D Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort.

Recent development in the DMD compiler made it available as a DUB library. This mean that the compiler itself can be re-used and third-party tools don't have to re-implement e.g. D's complex CTFE. This project is about using the DMD compiler as a library to implement a Language Server for D.

Proposed Project Mentors: Jacob Carlborg, Sebastian Wilzbach

How to start:

• Simple example of using DMD as a library
• More complex use cases

Mir Project

---

The Mir project is developing numerical libraries for the upcoming numeric packages of the Dlang standard library. The are numerous projects an interested student could pursue:

• University project. Your GSoC project can be combined with your scientific research.
• ndslice>-<Julia integration
• ndslice>-<NumPy integration
• General purpose BetterC libraries
  • I/O betterC Dlang library
  • Async betterC Dlang library
  • String and format betterC library
• mir-cpuid
  • ARM support
  • Advanced OS specific support
• mir-glas
  • BLAS Level 2 subprograms
  • One BLAS Level 3 subprogram. It is OK to do only one! But it must be faster then OpenBLAS, and not slower then Intel MKL.
  • Multithreading support for BLAS Level 2
  • Multithreading support for BLAS Level 3

You can get more details on projects related to Mir here.

Its Good To Know:

To work on the Mir you should be proficient with one of:

• C
• C++
• LLVM
• Fortran
• Experience with D is not essential.

To work on the Mir project requires a responsible and self-motivated student.

Proposed Project Mentor: Ilya Yaroshenko

LDC (LLVM-based D compiler)

---

The LDC project provides a portable D programming language compiler with modern optimization and code generation capabilities. The ever-improving feature set of LLVM opens up many opportunities with D. A few ideas for a potential GSoC project are:

• exploiting immutability of variables (notably of structs such as string slices)
• devirtualization
• improve debuginfo
• ASan with GC and multithreading
• function multiversioning

You might also want to browse the LDC's issue tracker for more ideas.

Proposed Project Mentors: TBA (LDC dev team, Nicholas Wilson)

iOS support in LDC

---

Mobile is becoming, or rather is already, the biggest software platform. While LDC already supports the Android platform there's no official support for iOS. The project would consist of adding support for the iOS platform to the LDC compiler, the D runtime library and the D standard library. The goal would be to get support for this platform upstreamed to the LDC main project.

A lot of existing work has been done but has never been completed or upstreamed: https://github.com/smolt/ldc-iphone-dev.

Proposed Project Mentors: TBA (LDC dev team)

Baremetal D runtime

---

Many features in the standard library are implemented by using the C runtime. Reusing the rock-solid work of generations of programmers makes a lot of sense as just outputting via `printf` can be very complex. However, for embedded environments a programmer often only has a tiny amount of storage available or might not even have a C runtime available for his target. The idea of this project is to implement the most basic parts of the runtime natively in D, s.t. bare metals programmers can just compile for their target. Implementing features natively in D also means that other targets like Web Assembly will automatically be able to use them too. Another advantage of implementing these basic building blocks in D is that one can take advantage of D's Compile-Time Function Evaluation (CTFE) and optimize the methods even further at compile-time.

Project focus: - Implement memcpy, memcmp and similar in D (with similar performance to C) - Implement malloc and similar in D (with similar performance to C)

Starting points:

• D for Bare Metal Programming (tutorial series
• Simple demonstration of using D to bare-metal program an STM32F29I Discovery board
• memcpyD
• Programming in D tutorial on Embedded Linux ARM devices

Proposed Project Mentors: TBA

GDC (GCC-based D compiler)

---

The GDC compiles uses GCC as a backend to utilize this powerful backend. Recently, GDC has been accepted as GCC frontend and will be part of the GCC9 release. However, GDC still has lots of tasks that the potential students could work on.

One idea would be to improve GDC's support for betterC by adding a compiler interface to allow using a modular runtime. Right now when GDC uses some feature (TypeInfo, asserts, unittests), it just emits a call to an `extern(C)` function. A much better approach would be to have a defined D API (e.g. `rt.assert.onAssertFailure(...)`). The compiler can then check if it finds `rt.assert.onFailure`. If not, the compiler can the simply disable that feature and provide nice error messages. This could be done for TypeInfo, Exceptions, Asserts, Switch errors, unit test support, etc. In the end, the vision would be to be able to ship a compiler completely without runtime. This compiler should be able to produce bare bones code without any further configuration. Then add a dependency to `drt:core` in the dub configuration to get class support, `dr:exception` for exceptions, etc. The compiler could then automatically detect availability of these features. (Of course manually adding -I paths would work in exactly the same way).

For more ideas, interested students are encouraged to browse GDC's issue list or getting in touch with the GDC development team.

Proposed Project Mentors: TBA (GDC devteam)

C++ interops

---

There are many experiments in transparently interfacing D with C++, notably:

• dpp by Atila Neves, that parses and translates headers on the fly
• Calypso by Elie Morisse that bridges the two languages at the AST level.
• DStep by Jacob Carlborg, automatically generates bindings for C and Objective-C code. The task would be to add support for C++.

There is also a lot of work in bringing STL types to the DRuntime (see https://github.com/dlang/druntime/pull/2310).

D would greatly benefit by seamlessly integrating the C++ ecosystem. There are many ways to accomplish this goal and it should be discussed with the community. Andrei already commented on the importance of a tool like Calypso in this thread: https://forum.dlang.org/post/m9s4cd$2s1v$1@digitalmars.com

Proposed Project Mentor: Andrei Alexandrescu

Persistent Data Structures

---

There is an ongoing effort to reduce the reliance of Phobos on the GC but the GC is not going anywhere given that it has many advantages over manual memory management. The community would greatly benefit from a wide range of functional programming techniques that have their roots in the usage of immutable and persistent data structures that heavily rely on the GC. Persistent Data Structures are heavily used in Scala and Clojure and they allow the programmer to reason about interactivity, sharing and parallelism.

The focus of this project would be to create a varying range of persistent data structures (sets, vectors, maps, strings, trees, lists, etc...) that respects the range interface and the semantics of Phobos.

Related Work:

• https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf
• https://www.worldcat.org/title/rrb-trees-efficient-immutable-vectors/oclc/820379112
• https://www.youtube.com/watch?v=7BFF50BHPPo
• https://www.infoq.com/presentations/Value-Values
• https://github.com/arximboldi/immer

Proposed Project Mentor: Andrei Alexandrescu

std.benchmark

---

Ideally every function in Phobos should have its own benchmark suite which is run for every PR to check for performance improvements or regressions.

• Additionally support for the new big O annotation here would be nice.
• Existing work: here, and here, and here (QuickText-like testing).

Proposed Project Mentors: Sebastian Wilzbach

Jupyter notebook D kernel

---

The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text. Uses include: data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and much more. Jupyter notebooks are extremely popular among data scientist as they allow interactive progress and exploring a solution step by step. With a bit of work, a statically compiled language can be used in an interactive notebook e.g. Cling for C++ and gophernotes for Go. Apart from being useful to data scientist, a Jupyter D kernel would allow an intuitive exploration of the language for newcomers and people starting with new libraries.

Existing works:

• drepl - simple REPL for D
• PydMagic - allows to write PyD extension in a notebook.
• jupiter-wire and jupyterd bare kernels for interfacing interpreters to

Proposed Project Mentor: Sebastian Wilzbach, Nicholas Wilson

Tabular data container (data frames)

---

Pandas, R and Julia have made data frames very popular. As D is getting more interest from data scientist (e.g. eBay or AdRoll) it would be very beneficial to use one language for the entire data analysis pipeline - especially considering that D (in contrast to popular languages like Python, R or Julia) - is compiled to native machine code and gets optimized by the sophisticated LLVM backend.

Minimum requirements:

• conversion to and from CSV
• multi-indexing
• column binary operations, e.g. `column1 * column2`
• group-by on an arbitrary number of columns
• column/group aggregations

Proposed Project Mentor: Ilya Yaroshenko

Graphics library for resource constrained embedded systems

---

Create a 2D rasterizer, rich drawing primitives, and 2D graphics library suitable for resource constrained embedded systems (e.g. ARM Cortex-M) to be used in industrial controls, home appliances, medical devices, consumer electronics, and IoT just to name a few. The end goal would be something similar to Segger's emWin. The library would be used to drive LDCs similar to https://www.adafruit.com/product/3396 Requirements:

• Hardware agnostic; should simply render to a frame buffer
• No dependencies (No Phobos, no C standard library, and no official D runtime).
• Consider using -betterC, but a custom minimal D runtime is also a viable option

Related work:

• https://github.com/TurkeyMan/color
• https://bitbucket.org/timosi/minlibd
• https://github.com/JinShil/stm32f42_discovery_demo

Proposed Project Mentors: TBA

Functional Reactive Programming

---

Functional reactive programming (FRP) is a programming paradigm for reactive programming (asynchronous dataflow programming) using the building blocks of functional programming (e.g. map, reduce, filter). The best-known FRP API is the ReactiveX API whose implementation in D this project would focus. Note that this project is closely related to the std.eventloop project.

Proposed Project Mentors: Petar Kirov

BetterC runtime

---

BetterC is a subset of D which limits the feature set of D, s.t. it's even easier to migrate from C as no Garbage Collection (GC) is used anymore. While, this feature is popular for some projects, `-betterC` today means still means a severe restriction in the amount of D features available (see the BetterC specification). This project is about making more parts of the D runtime betterC-compatible. For example, classes could be allocated with reference-counting instead of using the GC.

Proposed Project Mentors: TBA

Java Native Interface (JNI) library

---

D's features allow to write cut down the boilerplate of wrapper drastically. See the recently published excel-d for a comparison between the C++ implementation for registering a function in Excel and the D way. Similarly a solid JNI library would open up new many new use cases and allow the Java community to profit even easier from D's features.

Previous work: DJni, djvm

Proposed Project Mentor: TBA

DWT/JPort

---

DWT is a library for building applications with a graphical user interface. It's a port of the SWT Java library from Eclipse. It's a full translation of the Java code to D. No Java code, JNI or JVM remains in the DWT project. Currently Windows and Linux are the supported platforms. So far the translation has only be done manually. There's currently no support for macOS and DWT has not been updated to the latest version of SWT.

For these reason a new project has been created, JPort, to automatically translated Java code to D. It's based on JDT, the Eclipse Java compiler. The idea is that it's not required to handle translating all Java code, only what's necessary to translate SWT to D. This will hopefully reduce the scope of the project. Even with this restriction SWT is a very large code base and if JPort can successfully translate it to D it would be able to handle other projects as well.

Here's the list of goals, not all goals need to be planned for:

• Main goal : complete JPort and update DWT to the latest version of SWT
• Port DWT to macOS using JPort
• Use JPort to translate JDT to D and JPort itself to D (it's currently written in Scala)

Projects: DWT JPort SWT

Proposed Project Mentor: Jacob Carlborg

ORM mapping

---

SQLAlchemy is an object-relational mapper which provides "a full suite of well known enterprise-level persistence patterns, designed for efficient and high-performing database access, adapted into a simple and Pythonic domain language". While there has been some attempts in implementing an ORM in D - none of these got close to the simplicity and usability of SQLAlchemy (see Database Libraries). However, with D's CTFE queries could - like std.format's strings - already be checked at compile-time and optimizations could be be applied to the parser and serializer.

This project would be based on the proposed std.database abstraction and focus on creating a general-purpose ORM on top of it.

See also: Martin Nowak's DConf16 talk about Object-Relational Mapper

Existing work:

• hunt-entity

Proposed Project Mentor: TBA

std.serialization

---

D has numerous serialization frameworks. From `std.json` to `std.csv` over protobuf to Vibe.d's own serialization framework. The goal of this project is to implement a flexible (de)serialization framework that can be used as a standardized building block for various serialization related things. 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 (i.e. let them define their own policies).

Starting points:

• Vibe.d's serialization framework
• Orange framework
• hunt.serialization

Proposed Project Mentor: Jacob Carlborg

std.parallelism

---

The `std.parallelism` package has been part of Phobos for a while now, and is in production use with many people/applications. Phobos generally has evolved since `std.parallelism` was created and there has been other work on fibers and co-routines in other packages within the D milieu. It would therefore seem a good time to review the tasks system at the heart of `std.parallelism` to see if there are improvements that can be made or general refactorings that are possible. Or it may be that the tasks system just needs some tweaks to improve performance. The issue here is that n active review of `std.parallelism` is due.

Proposed Project Mentor: Russel Winder

std.interprocess

---

The goal of this project is to implement a flexible interprocess data structure, synchronization and communication library. An equivalent library in C++ is Boost Interprocess. The important goal would be to port all the features from boost.interprocess to D allowing the creation of structs/classes on shared memory, etc.

boost::interprocess offers the following features and it will be challenging & achieving to have these implemented in D in a stable, easy to use library that achieves all the aspects.

• default and custom allocators to operate on shm
• named IPC primitives: shm, semaphores, spinlock, mutex, condvar, barriers
• standard containers like vector, deque, list, string, set that operates on shm
• message queue on shm without relying on the kernel for data transfer. This is a huge win for low latency apps in the order of micro seconds
• managed shared memory
• IPC smart pointers

Get started by looking into the following:

• Boost Interprocess
• Basile's IPC library

Proposed Project Mentor: TBA

Propose your own project

---

Do you have your own vision for improving D's success? That's great! Are you convinced that your project helps to advance open source technology related to the D programming language? Then simply get in touch with D's GSoC org admin (social (at) dlang (dot) org) and potential mentors for your project.

If you are searching for inspiration, you might want to have a look at the list of D Improvement Proposals (DIPs), the high-level vision for this semester or the wish list.

Ideas From Previous Years

These GSoC idea pages from the past years which might provide more inspiration for proposing your own idea:

• GSoC 2018 Ideas (not accepted)
• GSoC 2017 Ideas (not accepted)
• GSoC 2016 Ideas (accepted, 4 slots)
• GSoC 2015 Ideas (not accepted)
• GSoC 2014 Ideas (not accepted)
• GSoC 2013 Ideas (not accepted)
• GSoC 2012 Ideas (accepted, 3 slots)
• GSoC 2011 Ideas

You may also want to have a look at the Symmetry Autumn of Code ideas page.

Tips for students

Please see the "gsoc" articles at our official blog which contain experience reports from students of previous years.

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.

Tips for Mentors

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