Aldo Nunez wrote:
> On Mon, 09 Aug 2010 06:33:50 -0700, awishformore <awishformore@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

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.

Fantastic!  Can I attach to a running process and debug it, or will I have to set up a project to get symbols to display correctly?

On Tue, 10 Aug 2010 11:45:25 -0700, Sean Kelly <sean@invisibleduck.org> wrote:

> 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.
>
> Fantastic!  Can I attach to a running process and debug it, or will I have to set up a project to get symbols to display correctly?

I want to list all the features with the project, but I might as well start here.
With the plug-in alone (meaning not launched with a project system like VisualD), you can run an app and debug it. In that way you can have an end-to-end debugging session with most debugging features like source line stepping, breakpoints, and expression evaluation. Attaching to a running process is one feature that's planned but not supported yet.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

  09.08.2010 21:44, Aldo Nunez wrote:
> Part of the reason I wanted to make this debugger is that using cv2pdb, although a great tool that helped fill a need, means:
>
> 2. Using undocumented interfaces.
> 3. Using Microsoft binaries that might not be redistributable (I'm not
> completely sure of this).

Does this imply that the debugger will not support .pdb debug info at all?

-- 
*
*
**

== Quote from Aldo Nunez (aldoSkipallthisNunez1@gmail.com)'s article
> On Tue, 10 Aug 2010 11:45:25 -0700, Sean Kelly
<sean@invisibleduck.org>
> wrote:
> > 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.
> >
> > Fantastic!  Can I attach to a running process and debug it, or
will I
> > have to set up a project to get symbols to display correctly?
> I want to list all the features with the project, but I might as
well
> start here.
> With the plug-in alone (meaning not launched with a project system
like
> VisualD), you can run an app and debug it. In that way you can
have an
> end-to-end debugging session with most debugging features like
source line
> stepping, breakpoints, and expression evaluation. Attaching to a
running
> process is one feature that's planned but not supported yet.

Will it support gdb commands "emulation" like ddbg did? That would be very useful for calling from an external application that already supports gdb.

On Wed, 11 Aug 2010 02:43:15 -0700, F. Almeida <francisco.m.almeida@gmail.com> wrote:

> == Quote from Aldo Nunez (aldoSkipallthisNunez1@gmail.com)'s article
>> On Tue, 10 Aug 2010 11:45:25 -0700, Sean Kelly
> <sean@invisibleduck.org>
>> wrote:
>> > 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.
>> >
>> > Fantastic!  Can I attach to a running process and debug it, or
> will I
>> > have to set up a project to get symbols to display correctly?
>> I want to list all the features with the project, but I might as
> well
>> start here.
>> With the plug-in alone (meaning not launched with a project system
> like
>> VisualD), you can run an app and debug it. In that way you can
> have an
>> end-to-end debugging session with most debugging features like
> source line
>> stepping, breakpoints, and expression evaluation. Attaching to a
> running
>> process is one feature that's planned but not supported yet.
>
> Will it support gdb commands "emulation" like ddbg did? That would
> be very useful for calling from an external application that already
> supports gdb.

I agree that that would be a useful feature. I invite everyone to take a look at the code and build extensions like that.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, 11 Aug 2010 02:24:19 -0700, Stanislav Blinov <blinov@loniir.ru> wrote:

>   09.08.2010 21:44, Aldo Nunez wrote:
>> Part of the reason I wanted to make this debugger is that using
>> cv2pdb, although a great tool that helped fill a need, means:
>>
>> 2. Using undocumented interfaces.
>> 3. Using Microsoft binaries that might not be redistributable (I'm not
>> completely sure of this).
>
> Does this imply that the debugger will not support .pdb debug info at all?
>

Right now it reads CodeView information that the DMD compiler writes. There's nothing stopping one from using the Microsoft DIA API to read symbols in PDB files, for example for stepping thru C or C++ code that you link with. That is on my planned list of features.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/