Welcome to the Google Summer of Code 2011 ideas page for the D Programming Language. This page lists potential projects of interest, each with a brief description. The best place to discuss these and related ideas is the digitalmars.D newsgroup (to which you can subscribe by using the mailing interface, NNTP, or simple HTTP browsing).
Key skills: Understanding of networking protocols and protocol APIs in other languages. Familiarity with D's standard library is a plus.
D offers socket primitives but currently lacks a standard collection of high-level libraries for networking using protocols such as HTTP, FTP, SMTP, IMAP etc. Your task would be to essentially define how D does networking from high-level design all the way to the implementation. You'd discuss ideas with the community, absorb feedback, and create a compelling proposal for adding networking support to the D standard library.
Key Skills: Understanding of XML processing APIs and parsing models; understanding of D ranges and arrays.
D has currently a standard library for XML but it is too slow and inconvenient so that library is scheduled for deprecation. Therefore, the slate is clean for a new end-to-end design and implementation.
Key Skills: Understanding of lexing and parsing theories; understanding of D's generative programming capabilities.
D has good generational capabilities, so it is possible to write a highly-integrated lexer/perser generator in D without resorting to additional tools. Such a project would be very useful to a variety of tasks, but it would likely strain D's generational capabilities to their limits requiring submitting and tracking bug reports for the compiler core.
Key Skills: Understanding of low-level timing mechanism available in Linux, Windows, and OSX operating systems. Familiarity with D's introspection mechanisms is a plus.
Defining good benchmarks is a difficult task requiring understanding of low-level, fine-grained timing mechanisms that are OS specific. (It also requires a good strategy of what to benchmark, but unfortunately that is difficult to automate.) A benchmarking framework could just require the user to define benchmark functions (e.g. starting with 'benchmark_') and would take care of timing execution, doing multiple iterations etc.
Key Skills: Understanding of infrastructure of particular IDEs; understanding of D's syntax.
A few IDEs for D already exist. However, some of these are unfinished or could use additional help.
- Flexible parser capable of parsing both D1 and D2 (potentially recognizing a superset of D, validating concrete language syntax after parsing).
- Able to preserve comments and other other syntactical and textual information relevant to IDE usage (source ranges).
- Performance minded, particularly with regards to memory usage (when relevant).
- Good error recovery.
- A good test suite for the parser
- The ability to do incremental parsing. Something more or less like, being able to quickly parse a file given only a textual change delta, and the previously generated AST (before the textual changes).
- Extend DDT project model to support inter-project dependencies. Support projects with a mix of source folders and native artifacts (object code), all with a well-defined buildpath.
- Support multiple build targets and configurations (debug/release/unittest, or user defined build configurations).
- Support a proper bundle modularization abstraction, similar to OSGi bundles. (projects become more structured entities with logical names and structured, versioned dependencies on other bundles)
- Add build support for the above in IDE. Also support build from a command line tool. Possibly integrate or base it on an existing build framework (Ant, SCons, CMake, etc.)
Key Skills: Intimate knowledge of cross-machine communication protocols.
Large-scale programming using D requires bindings to cross-machine and cross-language communication protocols. Such include Google's Protocol Buffers, Apache Thrift, and others. D's standard library currently includes no such protocol implementation. Providing such would motivate adoption of D for large-scale development.
Key Skills: Knowledge of garbage collection approaches and algorithms.
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.
Key Skills: experience in programming language parsing; familiarity with languages of the C line; knowledge of D-specific data structures and ranges is a plus.
The aim is to boost the production of fundamental tools for analysis of D source code in D: lexical, syntactic, at best first steps of semantic analysis; producing code representations as D data structures.
At term, the objective is to allow using the output of this project to produce a variety of further D tools in D: compilation, optimisation, statistics, documentation, debugging, plugins for code editors...
There are 2 existing projects along those lines, which could be used at least to explore the topic, possibly more: SDC https://github.com/bhelyer/SDC (prototype phase) and DIL http://code.google.com/p/dil/.
This project may indeed be connected to "Lexing and Parsing" above, if timing permits it.
Key Skills: Familiarity with a logging framework is a plus.
Having a simple and standard way of logging in D will help the development/debugging of D applications. The framework should be easy to use to foster its adoption by D developers. Google's Logging library for C++ can be of some inspiration.
Key Skills: Experience in metaprogramming is a plus.
This projects seeks to provide physical units as part of D's standard library. Allowing the use of units simplifies programming and helps avoiding bugs. It has been a success in F# see Units of Measure in F#. For C++ Boost.Units is well known.
Key Skills: Knowledge in data structures. Understanding of ranges in D is a plus.
D's standard library includes an implementation of a singly-linked list, an array with deterministic control of memory, a binary heap, and a red-black tree (see std.container). The aim of this project is to provide more data structures allowing them to be used with ranges.
Key Skills: Familiarity with DBMS libraries is a plus.
Having a standard way of accessing databases in D will greatly simplify the development of D database-enabled applications. The framework should be easy to use to foster its adoption by D developers. Java Database Connectivity and Python Database API Specification can be of some inspiration.
Manipulation of image files is a common programming task, which currently has absolutely no support from the D standard library. The primary goal of this project is to provide a standard interface for loading images from files (PNG, BMP, JPEG) into RGB arrays, and for creating files from such arrays. This basic functionality will make it easy to create sophisticated image processing libraries, using D's advanced metaprogramming capabilities. The project can optionally demonstrate this by implementing some basic image processing algorithms.
Recently x64 code generation has been added to dmd's backend and can already be used quite well on Linux because gcc's toolchain (along with the ELF and DWARF formats) is the de facto standard there.
Unfortunately the situation on Windows is a lot different because the toolchain is completely custom (and closed-source, excluding dmd). This has always been causing problems for many users but the rise of x64 has worsen the situation.
Contributors could concentrate on one or more of the following issues:
- object format: dmd still uses OMF - which only few tools support at all - instead of COFF. objconv can read it but conversion doesn't properly work. Unilink is the only known alternative linker which can link dmd OMF files but it's closed-source, not publicly available (you have to know the exact link to its ftp, there's no homepage whatsoever) and nobody knows details about its stability or performance. http://arsdnet.net/d-web-site/nntp/get-message?newsgroup=digitalmars.D.announce&messageId=<email@example.com>
- symbolic debug info format: CodeView? is used. Similar situation.
- 64 bit librarian: correlated with the aforementioned format issues.
- linker: OPTLINK was originally written in Assembler for performance reasons. It is gradually being ported to C behind the scenes but will still take a lot of time until a 64Bit version could be available. Moreover there have been a lot of frustating bugs caused by it in the past and a replacement is generally desirable.
- C compiler: The Digital Mars C compiler is used. It shares the backend and toolchain with dmd. Thus you can't compile 64Bit C code right now which is needed for compiling druntime and using external C libraries. Correlated with the OMF issue.
- C runtime: snn.lib is closed-source and there's no 64Bit version, furthermore it is only available as a static library. Some efforts have been made to replace it with the Visual C runtime using Unilink but it's a tough task and also requires compiler changes: http://firstname.lastname@example.org/msg50465.html. Using MinGW?'s runtime is another option but hasn't been examined yet.
It would be very nice for everyone who has D as their favorite language to be able write code for more wide range of devices than PCs - in particular Android. This could help both the Android community which will have a powerful and fast language at their disposal and it will evolve D as it will become available to more people and more devices in an area of development that gets a lot of attention.