The following is a list of ideas for GSoC 2012 projects under the Digital Mars organization. However, potential projects are not limited to those listed below. We welcome applications for any project that will improve the D ecosystem, including libraries, toolchain improvmenents, etc.
Mentors: If you're interested in mentoring a project mentioned here, feel free to add yourself as a possible mentor.
Key Skills: Knowledge of garbage collection approaches and algorithms.
Possible mentors: David Simcha
D's garbage collector is rather simplistic. There are many improvements that could be added to it to the end of dramatically improving performance. This would encourage safe, simple code at the client level.
David Simcha has made substantial improvements to the garbage collector over the past year, mostly via implementation level optimizations. He would be interested in mentoring a project to make some architectural changes that are necessary. The following is a wish list of improvements. It is definitely **not** realistic to do more than a small subset of these in a summer, so feel free to pick one or two of them.
- Remove the global malloc() lock at least for small allocations. ( Discussion of the issues involved)
- Parallelize the marking and/or sweeping phases. Ideally a near-linear speedup should be possible on multicore machines.
- Allow the mutating threads to run concurrently with the collecting thread. (Leanardo Lucarella's CDGC project allows this but AFAIK it only works on Linux and is based on snapshots using fork(), which is rather inefficient. It also would need to be integrated into the current GC, which has diverged substantially.)
- Implement precise scanning, at least of the heap. I (David Simcha) have tried to do this before but it was rejected because it used template metaprogramming to generate pointer offset information. You would probably need to modify the compiler to generate this information in addition to modifying the garbage collector to use it. My old patch or several of the others that are in that bug report might serve as hints for this project.
- Implement copying/heap defragmentation. This depends on precise scanning being implemented. However, if only precise heap scanning is implemented, objects referenced from the stack or static data segment could be pinned. IIRC this is how Mono's GC works and the benefits of copying are still substantial.
Possible mentors: ??
- Integrate GDC with Android NDK.
- Modify Phobos and druntime, since Android will probably have some subtle differences and omissions when compared to other Linux machines.
- Android does not support TLS in it's runtime linker (/etc/ld.so). As D uses tls by default and gcc's emulated TLS can't work with the garbage collector, adding tls support to the runtime linker and bionic is required. I'm not sure if this is feasible for a GSOC project.
- Wrap, or otherwise make accessible, a reasonable amount of Android API functionality.
- Streamline usability. It should be possible to download an up-to-date NDK with D support and start developing immediately.
Possible mentors: ??
This should also exist alongside the Android support. The needs and objectives are probably similar, though less discussed.
Key Skills: Knowledge of compiler internals (IRs, SSA, dataflow, optimization, etc) or knowledge of garbage collection techniques.
Possible mentors: Alex Rønne Petersen, Thomas Jost (MCI developers)
The MCI (Managed Compiler Infrastructure) is a modern and intuitive compiler infrastructure written in the D programming language. It provides a simple, extensible API specialized for modern-day programming language designs. It is primarily intended for so-called "managed" languages, which usually run in a virtual machine and typically use a garbage collector for memory management.
The project has its own ideas page: https://github.com/lycus/mci/wiki/GSoC
''Key Skills: Physic, Biology, Chemical, Bioinformatics
Possible mentors: Jonathan Mercier aka bioinfornatics
The DScience Project goal is to become an international association of developers of freely available D tools for computational molecular biology. It is a distributed collaborative effort to develop D libraries and applications which address the needs of current and future work in bioinformatics.
Some popular language has already a library for this feature as:
- python : biopython
- perl : bioperl
- java : biojava
'Key Skills: Linear Algebra, Numerics.
Possible mentors: David Simcha
Last summer, Cristi Cobzarenco created a fork of Lars Kyllingstad's SciD library. The goal was to create a matrix/linear algebra library that could be integrated into Phobos. Significant progress was made but the goals weren't fully met as the project was probably too ambitious for one summer. The goals for this summer would be the following or some subset thereof:
- Fixed-size matrices/vectors
- Sparse matrices and better support for packed matrices
- Better Lapack wrappers
- Most importantly, polish, debugging and submission for review and inclusion in Phobos soon after GSoC ends.
Key Skills: Knowledge of compiler internals (backend, runtime, assembly).
Possible mentors: ??
For D, and especially DMD, to be successful it's essential that D can be used to develop applications on mobile devices and tablets. That means DMD needs to be able to target ARM, since that is the the platform used by most of todays mobile devices and tablets.
In addition to the ARM backend the runtime would also need to be adapted to the ARM platform.
This would likely be in conjunction with ARM support. Arduino and Netduino are very popular Atmel (ARM) based processors that are used for robotics, hobbyists, etc. They form the backbone of most MAKE projects in fact. Once ARM Architecture support was achieved, deploying to either the Arduino or Netduino would be awesome. There is already a MonoDevelop? plugin that allows D programming and compilation in MonoDevelop?, and there is additionally, a plug-in that allows deployment from MonoDevelop? to Netduino of .NETMF binaries. The deployment of binaries to Arduino or Netduino itself is actually well documented and source code is available for the utility. so the work here would be to extend that utility to deploy D binaries to the device, and as a plus, a MonoDevelop? add-in that would call it. There would also be some additional work to port the c-libraries for device IO to D. or simply use them from D.
Possible Mentors: Alex Rønne Petersen
Key Skills: Knowledge of compiler internals (frontend, backend) both for D and Objective-C.
For D to be usable on iOS it's basically essential to be able to easily use the Objective-C system libraries and frameworks of the platform. GUI programming on Mac OS X would also get a big boost of this. The best way to do this is to add direct support for Objective-C in the compiler. Michel Fortin has already stared a project for this but it needs to be finished, updated with the latest compiler changes and merged back into the mainline.
D really needs an official, or de facto standard, GUI library. There are already various GUI libraries available, with different pros and cons and in different states. What needs to be done varies quite much depending on which library is chosen. A few of the existing libraries are: QtD, GtkD, DWT, wxD.
Of these four libraries, only DWT and wxD use native operations to draw their widgets. Of these libraries only DWT is completely written in D. The rest of the libraries are only bindings to C/C++ libraries. There have been many discussions about which library would be best for D. My suggestion is to use DWT because it's completely written in D and it uses native operators to draw its widgets.
What can be done for DWT:
- Finish the Mac OS X port
- Port to 64bit
- Update to later versions of SWT
- Port to Qt, QtWebkit?...
- H2 Database, OrientDB?, Voldemort, Cassandra, Hadoop, Solr, Lucene, Neo4j...
- Log4j, Netbeans Platform...
Key Skills: OS interfaces, networking.
Possible mentors: Jonas Drewsen
Many of the most successful servers and applications run using an event system. Usually they fall into either the reactor or the proactor category. The D standard library does not have support for this out of the box which also limits further development of a solid networking library.