Aldo Nunez wrote:
On Mon, 09 Aug 2010 06:33:50 -0700, awishformore
<awishform...@nospam.plz> wrote:
On 09/08/2010 06:45, Aldo Nunez wrote:
I'll be posting the D debugger I've been working on at dsource this
week. It'll
be a set of debugging libraries that you can build your own debugger
with, along
with a Debug Engine plug-in for Visual Studio.
I'll post another announcement as soon as it's available.
That sounds awesome.
Very nice, sir!
Does the plug-in work for all versions of VS? And is it supposed to
work with Visual D?
/Max
It's for D 2. From the beginning I had no intent to make it compatible
with D 1.
The Visual Studio plug-in is for 2005, 2008, and 2010. I haven't looked
into if it works for earlier versions.
.NET 2003 seems very similar. Even though you can install Visual D on
it, I've seen some quirks and did not bother to look deeper into it. I
would not expect too many users.
My understanding is that VisualD could easily be made to use this
plug-in, instead of the built-in C++ one. It should be a matter of
switching the GUID for the Debug Engine used.
Yes, should be easy to do ;-)
Part of the reason I wanted to make this debugger is that using cv2pdb,
although a great tool that helped fill a need, means:
1. Relying on the built-in C++ debugger, which means you get a C++
expression evaluator.
I was thinking of building an expression evaluator for Visual D but did
not get to it yet. Building the whole debug engine looks like a big job
to me.
2. Using undocumented interfaces.
True, that's been a lot of hassle.
3. Using Microsoft binaries that might not be redistributable (I'm not
completely sure of this).
As the pdb-output is expected to be run within Visual Studio that
includes the necessary files, that should not be a big problem. For
other debuggers, you might be right.
4. Using cv2pdb you have to live with some quirks like using '@' instead
of '.' in fully qualified symbol names. This can be confusing for beginners.
Rainer
