How You Can Help: OpenD Project List

Looking to contribute to OpenD but now sure how? Here's some ideas we'd like to see happen:

Libraries

Objective-C bindings: We have `core.sys.windows`, with a good base of the Windows APIs available. We'd love to have something similar for Apple platforms. I suggest `core.sys.apple`, so for example, `core.sys.apple.Cocoa.Cocoa` relates to `#import <Cocoa/Cocoa.h>`. This should use `extern(Objective-C)` to define the bindings. You might do this by hand, by using dstep, or by doing your own tool (optionally built on ImportC in the compiler, or independently, what matters are the output files moreso than the method).
Containers and algorithms: OpenD inherited the Phobos library from old D. We'd like to revisit the interfaces in some places and expand it in other places, adding things currently missing.
Plot library: We'd like something for displaying and interacting with plots. Important thing is getting a usable interface; if the implementation just piped out to gnuplot or Excel or something that'd be a decent first draft. Whatever you do should be compatible with `arsd.minigui`.
Port arsd libs to cocoa, ios, and webassembly-emscripten: This is one I'm probably going to prioritize myself, but would be nice for these to all have pretty close to full support.

Tutorials: More tutorials for more tasks and from more perspectives is always good.
Examples: The front page could use more and better examples to rotate through. Each one should probably link to a page with details talking about them.
Documentation cleanup: Parts of the website are hard to find, parts are incomplete. We should rethink the navigation, cross-link, homepage, etc., to make everything easy to find.

druntime/src/core/internal/elf/dl.d has a hack for data segment size and position: I made this basically work for me, but it is a hacky, imprecise implementation. Should fix it so it knows the ACTUAL thing that needs GC scanning. If emscripten implements `dl_iterate_phdr` I think that will obsolete this whole hack and project. Other possible solution is to bracket the data via linker section layouts.
Thread and fiber support: The current implementation assumes no threads are possible and does not support fibers at all. This can be changed.
Generally speaking, any `version (WebAssembly)` or `version (Emscripten)` blocks should be audited.: These are all subject to change since it is kinda hacky and unverified in many cases.

Scannable vs unscannable static data: I believe all global mutable data is currently scanned by the GC. Immutable data segments need not be scanned I think because by definition, they can only point to other compile time constant addresses. Mutable global data need only be scanned if it can contain pointers. We know this at compile time too, but I'm unsure if this info is forwarded to runtime. We should prove it is or isn't, and if it isn't, we can then try to adjust this. My suggestion would be to put data that may contain pointers in a different linker section.