On Sun, 16 Dec 2012 03:21:26 GMT, punkUser wrote:

I've been writing a game server using D2 for a little while as a project in my spare time and just recently stumbled across Vibe.d. The awesome thing is that the design you guys have done with fibering and events is almost exactly what I use as well in my current implementation! Definitely "the only" good way to write async code IMHO.

Nice! I fully agree, this combination D+async I/O+fibers was something I've missed for quite some time until finally deciding to give it a go and make it a reality (I think the trigger was being forced to use the callback based API of node.js, which really turned me off). But some people for some reason think, that an evented programming is actually the advantage of asynchronous I/O - probably because they have never used both models.

Thus I was thrilled to find Vibe.d and plug it into my implementation, reduce my application code, and get access to some of Vibe's fancier features. While I don't need to serve HTTP at the moment for instance, I do need to make HTTP requests (currently through CURL), and it might be handy in the future to do both.

Porting my code took <1hr since it was already very similar in structure to how vibe works. That said when I went to run it, I discovered that there seems to be a bunch of missing functionality on Win32 at the moment, which I'm using as my primary development platform currently. In the release version requestTcp hit some assert(false)'s and while that now works once I updated to the top of tree, listenTcp (really my only other required feature in the short term) does not.

Thus I wanted to ask about the plans and timeframe for finishing up some of these features in the Win32 implementation. I'm excited to switch to using Vibe.d instead of my current, less feature-ful implementation and thus I'm curious when might be a good time to check back :)

Did you dig in far enough to explicitly enable the win32 back end or did you use the VisualD project? I'm asking because if the server is supposed to be command line only, the default libevent back end should work fine on Windows (for the VisualD project this would require removing the VibeWin32Driver version in the Compiler/General section).

The win32 back end is currently developed in parallel to a larger project that needs it because it offers Windows event loop integration and a directory watcher. This is why it currently only has the features needed by that project. However, I wanted to get it completed for the next release (it would still be "beta" in that case regarding possible bugs and high-throughput performance). So if everything goes as desired, that would mean around the end of this month.

Thanks for all your hard work! It's also great to see the system design validated by a full-fledged project :)

Yes, it was also really nice for me/us to see how well the idea turned out in reality!