Difference between revisions of "GSOC 2019 Ideas"

From D Wiki
Jump to: navigation, search
m (Changed contact address)
m (Updated contact information)
Line 1: Line 1:
 
This is the D Language Foundation's Google Summer of Code 2019 page.
 
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, as either a student or mentor, please contact the GSoC admins at [mailto:gsoc@dlang.rocks?subject=[GSoC%202019] gsoc@dlang.rocks. Include "GSoC 2019" in the email subject line.
+
If you are interested in working on a D project as part of GSoC 2019, please feel free to ask questions on the [https://forum.dlang.org/group/general D Newsgroup].
 +
For more specific questions or for mentors, please contact the GSoC admins at [mailto:gsoc@dlang.rocks?subject=%5BGSoC%202019%5D gsoc@dlang.rocks].
  
  

Revision as of 09:57, 7 March 2019

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 or for mentors, 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:

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++-fist-with-a-D-binding to work the other way.

Starting points:

Proposed Project Mentor: Andrei Alexandrescu

Language Server Protocol for D

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 only 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). 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 idea behind the Language Server Protocol (LSP) is to standardize the protocol for how such servers and development tools communicate. This way, 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:

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)

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:

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:

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.

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 https://blog.jupyter.org/interactive-workflows-for-c-with-jupyter-fe9b54227d92] and Go with gophernotes. 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.

Proposed Project Mentor: Sebastian Wilzbach

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:

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

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:

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:

Proposed Project Mentor: Jacob Carlborg

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:

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.

Retrieved from "https://wiki.dlang.org/?title=GSOC_2019_Ideas&oldid=9584"