I agree about the general debugging experience on Windows. It's improving (at least with Mago), but still not where it should be. Partially this would be easy to remedy, such as in case of omitted stack frames in Phobos, as mentioned in Vladimir's recent thread that I just skimmed through.

Just quickly commenting on the vibe.d specific issues. If you have filed any recent bug reports and I didn't respond, this is because I way barely able to work on a computer at all during the past weeks. I'll try to start catching up a little bit now.

Am 14.12.2014 09:37, schrieb Manu via Digitalmars-d:
We were trying to use vibe.d, and we encountered bugs.

We were unable to build Win64 code (vibe.d doesn't support Win64 it
seems), and the 32bit compiler produces useless OMF output. We
couldn't link against any of our existing code which was a serious
inconvenience, but they were understanding and we worked around it.

It does, either by using the "win32" configuration instead of "libevent", or by manually providing a pre-compiled version of libevent for Win64 (I'd be happy to accept a PR, too). I didn't build it for a while though, so it may be that something is broken.


The real trouble hit when vibe.d's WebSocket support didn't work as
advertised; it crashed in various circumstances, and debugging was
impossible.
vibe.d uses exceptions everywhere, which caused an office full of
C/C++ programmers to explode with terror, and Visual Studio completely
craps itself when there are exceptions being thrown.

If you set a breakpoint at __dthrow_c, at least you get a proper call stack. It still doesn't enable accessing the exception internals, but usually those are less important.

Regarding exceptions themselves, it looks like the mindset of those C++ programmers is quite fixed, not the best premise for embracing D (but yeah, changing this usually requires some time/effort). Coming from a C and C++ without exceptions/RTTI background myself, I understand very well where that reaction comes from. However, IMO exceptions as a mechanism are very well suited for server environments especially because they cannot be (accidentally) ignored, and they often help a lot to make the code more readable. In a language that has them as a mandatory feature and uses them extensively in its standard library, I simply saw no reason to carry the no-exception rule over to D.

Of course they must be used accordingly (only for exceptional situations) and the debugger has to properly support them to make the debugging experience bearable. Having said that, a call stack + error message dumped to stderr is usually all that is needed, so the last point is more of a convenience factor when running from within VS.

Lastly, when judging all these things, please always try to remember that almost all the work that goes into D (and vibe.d) is non-profit and everyone usually only contributes what (s)he is missing. If I would get payed through a support contract for my work on vibe.d, I could adjust my priorities to suit the requirements of others more, but like this I still have to somehow make sure to be able to pay my bills and can't just work full time to help other (commercial) projects (although I always try to help as far as possible).

Sönke

Reply via email to