On Wednesday, 5 August 2015 at 09:03:47 UTC, John Colvin wrote:
On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:
Unfortunately I'm regrettably having to reconsider my decision
to start a game project (or any project requiring significant
time investment) in D. Not because of the language or
compiler, but rather because of the lack maturity in the
supporting tools; specifically, a debugger. I should say
upfront that this seems to be more gravely affecting OSX than
other platforms, but scouring forums and wikis has made it
apparent that no platform is completely devoid of obstacles
when it comes to functionally debugging D programs. To a
certain extent, one can alternatively diagnose and fix bugs
with verbose logging, assertions, and exceptions; but memory
related bugs become exponentially more difficult to work
through without being able to properly breakpoint, step
through execution, and observe all variables in the current
scope.
gdb works fine on OS X and has D support.
Can you enlighten me as to what configuration you've confirmed
this on? I'm on
OSX: 10.9.5 (Mavericks)
GDB: GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (building
newer from source tends to fail to compile)
DMD: DMD64 D Compiler v2.067
GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM
3.5svn)
At best, I can _sometimes_ hit breakpoints when using Mono-D,
it's inconsistent. Even when a breakpoint is hit however, GDB
only recognizes the current 'this' value; it doesn't recognize
any frame / local variables other than 'this', global variables,
etc., though it does recognize the call-stack at least. When
using GDB directly from a terminal, the only D source file it
recognizes for the purpose of setting breakpoints or listing
source code is app.d (which contains the main() entry-point).
Also have tried compiling with all combinations of -g, -gc,
-debug, -gs, and -cov. None seem to improve the situation.