Difference between revisions of "GSOC 2015 Ideas"

From D Wiki
Jump to: navigation, search
(Phobos: D Standard Library)
(Phobos: D Standard Library)
Line 74: Line 74:
 
** 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 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 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 [ https://github.com/Hackerpilot/Dscanner DScanner] but alternately could use regular expressions.  Optionally support for D code could be added to xgettext.
+
** A tool to extract strings which need to be translated from D code.  This should preferably be based on [https://github.com/Hackerpilot/Dscanner DScanner] but alternately could use regular expressions.  Optionally support for D code could be added to xgettext.
 
* '''std.numeric.matrix''' (Jens)
 
* '''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.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.

Revision as of 18:18, 27 December 2014

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.

To learn a little more about SDC we recommend you check out the following from D Conf 2014: http://dconf.org/2014/talks/sechet.html

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


Proposed Project Mentor: Iain Buclaw

DDT


Proposed Project Mentor: Bruno Medeiros

QML Bindings


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

Design and implement a basic internationalization framework. It should provide at least the following functionality:

  • A text translation part, std.i18n.translation
    • Gettext compatible
    • Preferably using the gettext serialized hashtables in .mo files
    • Low level, gettext like API and high level, boost::locale like API
  • A tool to extract strings which need to be translated from D code

Internationalization is required in all kinds of programs, therefore std.i18n must be as portable as possible. This especially means it must work on systems without a Garbage Collector and it must be easy to adapt the 'current locale detection' code and all code accessing the filesystem.

Think 'std.i18n should be portable to a system with 4MB Ram, no GC and no usual OS (e.g. game consoles)'

Large parts of the code can be ported from boost::locale.



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.