Difference between revisions of "GSOC 2017 Ideas"

From D Wiki
Jump to: navigation, search
m (Fixes a spelling mistake)
(Undo revision 8680 by Greenify (talk))
 
(44 intermediate revisions by 6 users not shown)
Line 3: Line 3:
  
 
== Timeline ==
 
== Timeline ==
−
The timeline for GSoC for 2016 can be found [https://developers.google.com/open-source/gsoc/ here], the 2017 timeline has not yet been posted.
+
The timeline for GSoC 2017 can be found [https://summerofcode.withgoogle.com/ here].
  
 
== Ideas ==
 
== Ideas ==
Line 9: Line 9:
 
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 ([http://dlang.org/phobos/index.html Phobos]), working on its compilers ([[Compilers]]), shaping GUI libraries for D, integrating D with other languages and more.
 
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 ([http://dlang.org/phobos/index.html Phobos]), working on its compilers ([[Compilers]]), shaping GUI libraries for D, integrating D with other languages and more.
  
−
=== Sample GSoC Idea ===
+
=== Mir Project ===
 
----
 
----
−
Give a brief description of your project idea.
 
  
−
* Detailed ideas are best.
+
==== Project Description ====
−
* If possible give an example of exactly what tasks would be involved.
+
The Mir project is developing numerical libraries for the upcoming numeric packages of
−
* Nevertheless, students may decide to come up with their own ideas.
+
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.
 +
* [http://docs.algorithm.dlang.io/latest/mir_ndslice.html ndslice]>-<[http://julialang.org Julia] integration
 +
* [http://docs.algorithm.dlang.io/latest/mir_ndslice.html ndslice]>-<[http://www.numpy.org NumPy] integration
 +
* General purpose BetterC libraries
 +
** I/O betterC Dlang library
 +
** Async betterC Dlang library
 +
** String and format betterC library
 +
* mir-random
 +
** Port mir-random uniform floating point implementation to clang and g++. You will code C++, our longterm goal is C++ standard.
 +
* mir-cpuid
 +
** ARM support
 +
** Advanced OS specific support
 +
* mir-glas
 +
** BLAS Level 1 subprograms
 +
** 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. We know how to do it.
 +
** Multithreading support for BLAS Level 2
 +
** Multithreading support for BLAS Level 3
 +
 
 +
You can get more details on projects related to Mir [https://github.com/libmir/mir/wiki/GSoC-2017 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 Mentors: [http://wiki.dlang.org/GSOC_mentors#Ilya_Yaroshenko Ilya Yaroshenko] [http://wiki.dlang.org/GSOC_mentors#Sebastian_Wilzbach Sebastian Wilzbach]  Joseph Rushton Wakeling (mir.random) ====
 +
 
 +
=== SDC Project - D Compiler as a Library ===
 +
----
 +
 
 +
==== Project Description  ====
 +
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.
 +
* Integrate LLVM's new JIT infrastructure in SDC, the On-Request Compilation JIT (ORCJit) API.  This would simplify the implementation of certain D features such as Compile Time Function Evaluation (CTFE) for SDC.
  
 
==== Its Good To Know ====
 
==== Its Good To Know ====
 +
* Please watch Amaury's DConf [http://dconf.org/2014/talks/sechet.html 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: [http://wiki.dlang.org/GSOC_mentors#Amaury_Sechet Amaury Sechet] ====
 +
 +
 +
=== FlatBuffers Support and/or Improved Protocol Buffer Support ===
 +
----
 +
 +
==== Project Description  ====
 +
[http://google.github.io/flatbuffers/ FlatBuffers] is an efficient cross platform serialization library for C++, C#, C, Go, Java, JavaScript, PHP, and Python. It was originally created at Google for game development and other performance-critical applications.
 +
 +
Currently there is no support for D, so this project would involve building FlatBuffers support from scratch. The goal of the project is to contribute the D support to the upstream repository.
 +
 +
Regarding Protocol Buffers, [https://github.com/dcarp/protobuf/tree/dlang_support existing work] has been done to provide support for D, however, there are a number of areas that can be improved including:
 +
* comments and deprecated fields handling
 +
* generate interfaces for protobuf services
 +
* upstream repo CI integration
 +
* define the native D representation of all "well known" types
 +
* optimization of non-recursive messages
 +
* benchmarking
 +
 +
==== Available version ====
 +
* from HuntLabs github repo [https://github.com/huntlabs/google-flatbuffers huntlabs/google-flatbuffers].
 +
 +
==== Its Good To Know ====
 +
It would be worthwhile to have experience working with either Protocol Buffers or FlatBuffers in another language, but such experience is hardly a necessity. 
 +
 +
==== Proposed Project Mentors: [http://wiki.dlang.org/GSOC_mentors#Dragos_Carp Dragos Carp] ====
 +
 +
=== Lowerer ===
 +
----
 +
 +
==== Project Description  ====
 +
This tool would "translate" compilable D code to compilable D code. See initial idea discussed in [https://issues.dlang.org/show_bug.cgi?id=5051 Issue 5051]. It would offer a variety of lowering services for purposes of tooling, debugging, and project management:
 +
 +
* do not output function bodies, <tt>.di</tt> style
 +
* write deduced attributes for functions (useful when function bodies are not written)
 +
* expand all possible mixins in the code
 +
* execute lookup on all symbols and write the full symbol, e.g. <tt>writeln</tt> becomes <tt>.std.stdio.writeln</tt>
 +
* explicitate all user-defined operators, e.g. <tt>a + b</tt> becomes <tt>a.opBinary!"+"(b)</tt>
 +
* replace all wholesale <tt>import</tt>s with detailed <tt>import</tt>s that specify the symbols needed
 +
* write specialized versions for all templates used within the module (this is likely to be tricky)
 +
* lower all <tt>scope</tt> statements into <tt>try</tt> statements
 +
* lower all <tt>foreach</tt> statements into <tt>for</tt> statements
 +
* specify the exact symbols needed for each import statement (which means: if no symbols, the import is redundant - easy to mark as a warning by a subsequent tool)
 +
* evaluate all <tt>static if</tt>s possible
 +
* lower code using <tt>version()</tt>, i.e. make the unused branch disappear
 +
* make all comments disappear
 +
* make only non-documentation comments disappear
 +
* evaluate all possible CTFEs (tricky)
 +
* introduce named values instead of temporaries wherever order of evaluations is defined.
 +
 +
==== Proposed Project Mentors: [http://wiki.dlang.org/GSOC_mentors#  TBD] ====
 +
 +
=== <tt>fork()</tt>-based Garbage Collector ===
 +
----
 +
 +
==== Project Description  ====
 +
Gustavo Rodriguez-Rivera and Vincent Russo authored a [https://www.cs.purdue.edu/homes/grr/snapshot-gc.pdf paper] on an interesting take on a garbage collector: leverage efficient <tt>fork()</tt> implementations, which in many Unix systems take advantage of hardware-provided copy-on-write semantics for duplicated memory pages across processes.
 +
 +
This idea is already leveraged in the high-performance garbage collector for D implemented and used by Sociomantic. (A lingering issue is <tt>fork()</tt> and <tt>malloc()</tt> share a lock, which is [http://www.dsource.org/projects/tango/ticket/2087 problematic].) Leandro Lucarella, the engineer who wrote the implementation, has open sourced it [https://git.llucax.com.ar/w/software/dgc/cdgc.git here], but that is a bitrotten version that has fallen on the wayside.
 +
 +
Leandro would be glad to assist with questions by a motivated implementer. Gustavo has quite a few ideas for improvements, including a possible Windows implementation, and may be able to even coauthor a paper.
 +
 +
==== Proposed Project Mentors: [http://wiki.dlang.org/GSOC_mentors#  TBD] ====
 +
 +
=== Linux debugger ===
 +
----
  
−
In this section please point prospective students to any resources that could help them get up to speed on the project topic. These might include:
+
==== Project Description  ====
 +
[https://zerobugs.codeplex.com/ ZeroBUGS] is a high-quality, source-level debugger for Linux implemented from first principles in C++ by Cristian Vlasceanu. The author got busy with work and the project has since bitrotten, as did a [https://github.com/syntheticpp/zerobugs fork] of it by a different engineer.
  
−
* related project GitHub pages.
+
ZeroBUGS presents amazing opportunities for D/Linux debugging, and Cristian is willing to guide a motivated implementer.
−
* DConf talks or other videos relevant to the project.
 
−
* Suggested reading material, such as books, blogs, etc.  
 
  
−
==== Proposed Project Mentors: Your Name Here! ====
+
=== Who's (Using) Who? ===
 +
----
  
 +
==== Project Description ====
  
 +
It happens often that executables include code that seems unused (e.g. a typical "hello world" links in functions that are not easily explained). A tool that shows dependency chains would be a great helper in understanding what dependencies are at work, and would give insight into how to reduce them.
  
 +
The tool would output for each function all symbols it uses. The tool's output would be in one (or more) popular format of stock tools for graph drawing, such as [https://en.wikipedia.org/wiki/DOT_(graph_description_language) DOT], [http://www.graphviz.org Graphviz], [http://www.sagemath.org Sage], [https://www.ctan.org/pkg/pgf?lang=en PGF/TikZ], [http://www.mi.sanu.ac.rs/newgraph/ newGRAPH], etc.
  
−
=== Additional Project Ideas ===
+
This can be done using Valgrind's plugin, Callgrind, as explained [[Other_Dev_Tools#Valgrind helper | here]].
 +
 
 +
 
 +
==== Proposed Project Mentors: [http://wiki.dlang.org/GSOC_mentors#Stefan_Rohe  Stefan Rohe] ====
 +
 
 +
=== Phobos: D Standard Library ===
 
----
 
----
  
−
We will include a section for more poorly defined projects that some adventurous student might be interested in.
+
There are tonnes of opportunities to contribute to improving D's standard library,
 +
Phobos. Here we list some modules that might make good projects:
 +
 
 +
==== 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 [https://github.com/dlang/phobos/pull/4965 here] would be nice.
 +
* Existing work: [https://github.com/dlang/phobos/pull/794 here], and [https://github.com/dlang/phobos/pull/3695 here], and [https://github.com/atilaneves/unit-threaded/tree/master/source/unit_threaded/randomized here (QuickText-like testing)].
 +
 
 +
==== std.i18n ====
 +
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 [https://www.gnu.org/software/gettext/ 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.
 +
 
 +
==== std.parallelism ====
 +
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.units ====
 +
Unit conversion library
 +
 
 +
==== std.serialization ====
 +
A flexible (de)serialization framework that can be used as a standardized building block for various serialization related things: std.json, std.csv, Protocol Buffers, Cap'n Proto, vibe.d... 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. A good starting point is would be to work with the [https://github.com/jacob-carlborg/orange Orange framework].
 +
 
 +
==== std.container ====
 +
* support for custom allocator (aka no GC)
 +
* thread-safe
 +
* performance
 +
* existing work: [https://github.com/economicmodeling/containers here] and [https://github.com/vibe-d/vibe-core/tree/master/source/vibe/internal here].
 +
* Additionally lock-free data structures (e.g. based on Martin Nowak's [https://github.com/MartinNowak/lock-free work] would be a huge benefit.
 +
 
 +
==== std.database ====
 +
* Provide a general database interface for D
 +
* Replace etc.c.sqlite with a native implementation
 +
* Existing work: [https://github.com/huntlabs/database here], [https://github.com/cruisercoder/dstddb here], and [https://github.com/buggins/ddbc here]
 +
* See also the following DConf [http://dconf.org/2016/talks/smith.html talk] and [http://www.slideshare.net/cruisercoder/dconf-2016-stddatabase-61743444 this one] and [http://dconf.org/2016/talks/nowak.html this one].
 +
 
 +
==== std.decimal ====
 +
A general decimal math library for fixed point arithmetic.
 +
* Existing work [https://github.com/andersonpd/eris here] and [https://github.com/jaypha/fixed here].
 +
 
 +
==== std.encoding ====
 +
std.encoding needs a complete overhaul. Other encoding packages as ascii, base64, utf8 could be included and a common API should unite them.
 +
 
 +
==== std.eventloop ====
 +
High-performance native event loop abstraction for D.
 +
 
 +
Existing work:
 +
* [https://github.com/vibe-d/eventcore eventcore]
 +
* [https://github.com/etcimon/libasync libasync]
 +
* [https://github.com/Devisualization/spew SPEW]
 +
 
 +
Phobos inclusion will require that the event loop abstraction is not baked into a specific purpose as that comes later.
 +
The specific events, sources and consumers must be configurable and high performant. Existing solution that is well tested in this manner is [https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html glib's] event loop. The closest to this design in D would be SPEW.
 +
 
 +
For this work to succeed the following things must be in Phobos:
 +
* The abstraction
 +
* An example implementation of the event loop
 +
 
 +
Available in the community:
 +
* Sockets support
 +
* Windowing support
 +
 
 +
To simplify matters only Windows support needs to be included for the example sources and consumers of events.
 +
 
 +
This work would allow D to have a high performance (and correctly performing) windowing, timers and sockets libraries that can integrate should the sources be cross supported.
 +
 
 +
The biggest domain limitation to this work would be threading. The event loop library should be aware that some sources and consumers may be required to be thread only, global only, or both.
 +
 
 +
==== std.graph ====
 +
Graphs are used in all sorts of contexts - from low-level network communication to high-level data science.
 +
At the moment there is only one unmaintained D [https://github.com/WebDrake/Dgraph library], but
 +
[http://www.boost.org/doc/libs/1_63_0/libs/graph/doc/ Boost::graph] would be a good direction.
 +
 
 +
==== Proposed Project Mentors: [http://wiki.dlang.org/GSOC_mentors#  TBD] ====
 +
 
 +
=== DUB: D's package manager ===
 +
----
 +
 
 +
==== Project Description  ====
 +
 
 +
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:
 +
 
 +
* [https://github.com/dlang/dub/wiki/DEP2 separate compilation and caching]
 +
* [https://github.com/dlang/dub/wiki/DEP3 extensibility through DUB]
 +
* [https://github.com/dlang/dub/wiki/DEP4 control flow directives]
 +
* [https://github.com/dlang/dub/wiki/DEP5 build system support for C/C++]
 +
* [https://github.com/dlang/dub/wiki/DEP6 git support]
 +
* support dub install for distributions
 +
* support building a {snap, Debian, Arch, ...} package out of DUB package
 +
 
 +
==== Proposed Project Mentors: [http://wiki.dlang.org/GSOC_mentors#  TBD] ====
 +
 
 +
=== Propose your own project ===
 +
----
 +
 
 +
==== Project Description  ====
 +
 
 +
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 ([https://wiki.dlang.org/GSOC_mentors#Craig_Dillabaugh Craig]) and potential mentors for your project.
 +
 
 +
If you are searching for inspiration, you might want to have a look at the [[DIPs| list of D Improvement Proposals (DIPs)]], the [[Vision/2017H1|high-level vision for this semester]] or the [[Wish_list|wish list]].
  
 
== Ideas From Previous Years ==
 
== Ideas From Previous Years ==

Latest revision as of 18:07, 5 December 2017

This is the D Google Summer of Code page for 2017 - it is currently under construction. If you are interested in participating in the 2017 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 2017 can be found 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), shaping GUI libraries for D, integrating D with other languages and more.

Mir Project

Project Description

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-random
    • Port mir-random uniform floating point implementation to clang and g++. You will code C++, our longterm goal is C++ standard.
  • mir-cpuid
    • ARM support
    • Advanced OS specific support
  • mir-glas
    • BLAS Level 1 subprograms
    • 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. We know how to do it.
    • 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 Mentors: Ilya Yaroshenko Sebastian Wilzbach Joseph Rushton Wakeling (mir.random)

SDC Project - D Compiler as a Library

Project Description

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.
  • Integrate LLVM's new JIT infrastructure in SDC, the On-Request Compilation JIT (ORCJit) API. This would simplify the implementation of certain D features such as Compile Time Function Evaluation (CTFE) for SDC.

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

FlatBuffers Support and/or Improved Protocol Buffer Support

Project Description

FlatBuffers is an efficient cross platform serialization library for C++, C#, C, Go, Java, JavaScript, PHP, and Python. It was originally created at Google for game development and other performance-critical applications.

Currently there is no support for D, so this project would involve building FlatBuffers support from scratch. The goal of the project is to contribute the D support to the upstream repository.

Regarding Protocol Buffers, existing work has been done to provide support for D, however, there are a number of areas that can be improved including:

  • comments and deprecated fields handling
  • generate interfaces for protobuf services
  • upstream repo CI integration
  • define the native D representation of all "well known" types
  • optimization of non-recursive messages
  • benchmarking

Available version

Its Good To Know

It would be worthwhile to have experience working with either Protocol Buffers or FlatBuffers in another language, but such experience is hardly a necessity.

Proposed Project Mentors: Dragos Carp

Lowerer

Project Description

This tool would "translate" compilable D code to compilable D code. See initial idea discussed in Issue 5051. It would offer a variety of lowering services for purposes of tooling, debugging, and project management:

  • do not output function bodies, .di style
  • write deduced attributes for functions (useful when function bodies are not written)
  • expand all possible mixins in the code
  • execute lookup on all symbols and write the full symbol, e.g. writeln becomes .std.stdio.writeln
  • explicitate all user-defined operators, e.g. a + b becomes a.opBinary!"+"(b)
  • replace all wholesale imports with detailed imports that specify the symbols needed
  • write specialized versions for all templates used within the module (this is likely to be tricky)
  • lower all scope statements into try statements
  • lower all foreach statements into for statements
  • specify the exact symbols needed for each import statement (which means: if no symbols, the import is redundant - easy to mark as a warning by a subsequent tool)
  • evaluate all static ifs possible
  • lower code using version(), i.e. make the unused branch disappear
  • make all comments disappear
  • make only non-documentation comments disappear
  • evaluate all possible CTFEs (tricky)
  • introduce named values instead of temporaries wherever order of evaluations is defined.

Proposed Project Mentors: TBD

fork()-based Garbage Collector

Project Description

Gustavo Rodriguez-Rivera and Vincent Russo authored a paper on an interesting take on a garbage collector: leverage efficient fork() implementations, which in many Unix systems take advantage of hardware-provided copy-on-write semantics for duplicated memory pages across processes.

This idea is already leveraged in the high-performance garbage collector for D implemented and used by Sociomantic. (A lingering issue is fork() and malloc() share a lock, which is problematic.) Leandro Lucarella, the engineer who wrote the implementation, has open sourced it here, but that is a bitrotten version that has fallen on the wayside.

Leandro would be glad to assist with questions by a motivated implementer. Gustavo has quite a few ideas for improvements, including a possible Windows implementation, and may be able to even coauthor a paper.

Proposed Project Mentors: TBD

Linux debugger

Project Description

ZeroBUGS is a high-quality, source-level debugger for Linux implemented from first principles in C++ by Cristian Vlasceanu. The author got busy with work and the project has since bitrotten, as did a fork of it by a different engineer.

ZeroBUGS presents amazing opportunities for D/Linux debugging, and Cristian is willing to guide a motivated implementer.

Who's (Using) Who?

Project Description

It happens often that executables include code that seems unused (e.g. a typical "hello world" links in functions that are not easily explained). A tool that shows dependency chains would be a great helper in understanding what dependencies are at work, and would give insight into how to reduce them.

The tool would output for each function all symbols it uses. The tool's output would be in one (or more) popular format of stock tools for graph drawing, such as DOT, Graphviz, Sage, PGF/TikZ, newGRAPH, etc.

This can be done using Valgrind's plugin, Callgrind, as explained here.


Proposed Project Mentors: Stefan Rohe

Phobos: D Standard Library

There are tonnes of opportunities to contribute to improving D's standard library, Phobos. Here we list some modules that might make good projects:

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.

std.i18n

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

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

Unit conversion library

std.serialization

A flexible (de)serialization framework that can be used as a standardized building block for various serialization related things: std.json, std.csv, Protocol Buffers, Cap'n Proto, vibe.d... 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. A good starting point is would be to work with the Orange framework.

std.container

  • support for custom allocator (aka no GC)
  • thread-safe
  • performance
  • existing work: here and here.
  • Additionally lock-free data structures (e.g. based on Martin Nowak's work would be a huge benefit.

std.database

  • Provide a general database interface for D
  • Replace etc.c.sqlite with a native implementation
  • Existing work: here, here, and here
  • See also the following DConf talk and this one and this one.

std.decimal

A general decimal math library for fixed point arithmetic.

std.encoding

std.encoding needs a complete overhaul. Other encoding packages as ascii, base64, utf8 could be included and a common API should unite them.

std.eventloop

High-performance native event loop abstraction for D.

Existing work:

Phobos inclusion will require that the event loop abstraction is not baked into a specific purpose as that comes later. The specific events, sources and consumers must be configurable and high performant. Existing solution that is well tested in this manner is glib's event loop. The closest to this design in D would be SPEW.

For this work to succeed the following things must be in Phobos:

  • The abstraction
  • An example implementation of the event loop

Available in the community:

  • Sockets support
  • Windowing support

To simplify matters only Windows support needs to be included for the example sources and consumers of events.

This work would allow D to have a high performance (and correctly performing) windowing, timers and sockets libraries that can integrate should the sources be cross supported.

The biggest domain limitation to this work would be threading. The event loop library should be aware that some sources and consumers may be required to be thread only, global only, or both.

std.graph

Graphs are used in all sorts of contexts - from low-level network communication to high-level data science. At the moment there is only one unmaintained D library, but Boost::graph would be a good direction.

Proposed Project Mentors: TBD

DUB: D's package manager

Project Description

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:

Proposed Project Mentors: TBD

Propose your own project

Project Description

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 (Craig) 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

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

Retrieved from "https://wiki.dlang.org/?title=GSOC_2017_Ideas&oldid=8681"