GSOC 2015 Ideas

From D Wiki
Revision as of 19:10, 27 December 2014 by CraigDillabaugh (talk | contribs)
Jump to: navigation, search

This is the D Google Summer of Code page for 2015 - 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 2015 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 2015 has now been posted here.

Ideas

Plenty of challenging and important projects exist in the D worlds. 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 task(s):

  • 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).

Proposed Project Mentor: Amaury Sechet

Amaury, or Deadalinx as he is now in the D community is an Engineer with Facebook.

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).

Proposed Project Mentor: Iain Buclaw

Lead developer, project coordinator and the principal force behind the development of the GNU D Compiler from as far back as 2009, where he was responsible for the migration over from D1 to D2, as well as from GCC 3.x to GCC 4.x. Iain works on for a Cloud Services/Hosting company as a Technical Engineer, and unofficially uses D on a frequent basis to develop interpreters, and various plug-ins to work within the company infrastructure. You can watch Iain's recent DConf talk here.

DDT

There are plans to make the semantic engine of DDT available as a command-line semantic daemon (like DCD) - so work on that could be a potential idea. Or integration with other, non-Eclipse, IDEs.

Proposed Project Mentor: Bruno Medeiros

QML Bindings

This proposal is to create a way of communicating between D codes and QML engines via signals and slots. The model here is the Go/QML system. It works very well, but isn't D.


Proposed Project Mentor: Russel Winder

D ARM Support / Bare Metal D

  • ARM Support: The ARM architecture is predominant on mobile devices. Enabling D developement on those requires support from the compiler, from druntime and phobos and documentation on toolchain setup. There are existing approaches for GDC/LDC. The goal of this project would be to take up the existing work and get GDC/LDC to pass their testsuites on Linux and Android. Building a cross-compiler for these targets should become a simple and documented process. Additional time could be spent on exploring bare-metal targets or Windows support.
  • Bare Metal D: This is a project that goes hand in hand with ARM support in D but focuses on getting bare metal cross-compiler and 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 are cheap, have 32bit CPUs and plenty of RAM/ROM 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 wtih 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 look alike library in D for a select family of popular chips (and consequently a range of boards). Alternativly instead of blindly copying a popular API is to design your own hardware abstraction library. 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 e.g. this project (some D working on STM32 boards): https://bitbucket.org/timosi/minlibd

Proposed Project Mentor: Martin Nowak

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)

Proposed Project Mentor: Andrei Alexandrescu, Jens Mueller, Jacob Ovrum, Russel Winder

GSoC idea pages from past years:

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 2015 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_2015_Ideas&oldid=5272"