See more at the announce forum.
I spent a good chunk of last week writing a tutorial for one of my work modules and while it took a lot of time, I actually think it may end up being worth it, even if nobody actually reads the document.
See, by having to actually write up high-level user scenarios and justify the steps, rather than just the method-level ddoc of the individual pieces, it led to several improvements of the code itself too.
When I write code for myself, I usually implicitly have some high level goal in mind. But when writing for someone else, I don't necessarily have that same intimate knowledge.
By writing the tutorial, I force myself to describe how it works and think of realistic use cases... and that helps develop that knowledge to make a better api. So even if nobody reads it, the act of writing it improve the project.
I wrote a comment this week about how I think D should be marketed and developed:
simpledisplay.d's pulse timer used to be able to starve the event loop when given an exceedingly fast time and a handler that waited a while then did some drawing (like a opengl redraw timer on 1ms). On Windows, timers would back up and on Linux, X events would be loaded (by the C library) but not triggered (since the C lib wouldn't wake up the event loop). Both problems are now solved (a timer handler will only tick at most once per event loop, and X events will be caught up after the handler), so there should be no more trouble with fast timers.
Note that redrawOpenGlNow may still vsync, even if you set window vsync to false, depending on what drivers you use. The wait for vsync may put the program to sleep. You may still want a separate game update thread if you want to keep that loop busy while keeping user input events and frame redraws happening simultaneously. I may think of a better plan for this in the future.