Project Ideas

Task List

An updated list of tasks relevant to the community is kept here.

Lowerer

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

fork()-based Garbage Collector

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.

Interfacing with C++

Walter Bright has gotten the compiler to the point where it is possible to write declarations for C++ types and functions (including certain templates) and even throw an exception from C++ and catch it in D.

The next step is to define D interfaces for the data structures and functions in the C++ standard library, which would go e.g. in core.stdcpp in druntime (modeled after core.stdc). This is a high-impact project because it would allow D code to interface easily with legacy C++ code using standard library artifacts such as std::string and std::vector.

Linux debugger

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?

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.