View source for GSOC 2013 Ideas

Refer to [http://dlang.org/gsoc2013.html our GSoC 2013 page] for details about this project.

GSoC idea pages from past years ([http://www.prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas GSoC 2012] and 
[http://www.prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas GSoC 2011]).

==LDC==

LDC is based on LLVM, so this suggests several small project ideas, like porting some of the LLVM tools/features designed for C/C++ to the D-LDC world. Things like:

* Perform more static analysis, like abstract compilation or linting (Clang does both);
* Develop a simple way to compile D for the browser with Emscripten to "asm.js" (this is a very small project);
* Perform other run-time tests as done by Clang;
* Use some of the D semantics to improve D code optimization (Walter talks about this all the time);
* Implement better high level optimizations for D code that uses array ops.

==PyD==

Once remaining issues with shared libraries are resolved, it becomes feasible to use D code from dynamic languages. Clearly it's vital to provide easy path for calling it from Python, as it's used by many scientists, amongst others. Although there's [http://bitbucket.org/ariovistus/pyd/ PyD], the last few years saw rising interest in [http://pypy.org PyPy] because it shows much better performance than CPython. For PyPy, the way to go seems to be generating <tt>extern(C)</tt> wrappers for classes/functions/etc. + [http://cffi.readthedocs.org CFFI bindings] for that C code. First part of this can be reused for producing C++ wrapping code -- this is similar in goals to [http://d.puremagic.com/issues/show_bug.cgi?id=9285 dtoh] but here entities to be wrapped should be explicitly mentioned. Extra benefit of producing C++ bindings is ability to call SWIG on them to support other languages. So, perhaps, C++ is the number one target in this respect.

==SDC==

SDC is a work in progress in order to implement a D frontend in D. The lexing/parsing/semantic part is available as a lib in order to allow other tools to be built on top of it. The long term goal is to improve the tooling around D in general.

If SDC is to handle the most advanced features of D (CTFE, templates, static ifs, mixin), many things remain to do. They include:
* Full support of D's OOP capabilities.
* Context pointers creation (closures and delegate passed by alias).
* pure, @safe
* shared/synchronized.
* and much more!

A lot of work, but the project has a solid base to build upon.

SDC is leveraging LLVM in order to do JIT CTFE and for codegen. It is probably possible to mutually work around LLVM with LDC (for instance Emscripten and asm.js ).

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

==iPhone support==

This should also exist alongside the Android support. The needs and objectives are probably similar, though less discussed.

==Objective-C support==

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 [http://michelf.ca/projects/d-objc/ project] for this but it needs to be finished, updated with the latest compiler changes and merged back into the mainline.

==GUI library==

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: [http://dsource.org/projects/qtd QtD], [http://dsource.org/projects/gtkd GtkD], [https://github.com/d-widget-toolkit/dwt DWT], [http://wxd.sourceforge.net/ 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

==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 [http://arduino.cc/ 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 [http://wiring.org.co/reference/ 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.

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

[[Category:GSOC]]