I've been loosely following the D forums for a while as a lurker. Perhaps this post is more appropriate for the main D forums but I'm really still a beginner so I'll post here.



Is is possible to debug with Visual Studio 2005? I use VS2005 regularly with C++ and to some small extent C#. It would be nice to be able to use this IDE. My beginning attempt to debug the sample D code with it didn't work.



This kind of brings up a point. I realize that the D language is considered to increase your productivity by 30% or so, based on line count. But I think that productivity results from multiple factors, only one of which is the language. When I try to evaluate which language would be a good choice for my application, I think of the whole development experience. Have you ever tried C# within VS2005? I can get going rather quickly. No environment variables to set up; no INI files to configure. You can start a project from a template and immediately compile and run it. If you want a GUI control, just plop it onto the dialog and it generates the code. All this is due to the IDE, not the language.



I don't mean to sound like an advertisement for VS2005 and C#. My point is that by comparison, even though the D language is productive, some of that is negated by the whole development experience. When I look at the big picture and think which total package is going to make my life easier, it's probably going to be C++ or C# on VS2005. True, D is a better language than C++. And I have a couple of dislikes about C#, namely the questionable support for the RAII paradigm, that I'll require users to install the .NET Framework, and that it's not cross-platform (is MONO a serious option?). Of course, MS has many more resources than the D community. All I'm saying is that I think D would have a better chance of success if the entire development experience is improved, not just the language itself.



I recently came across Harmonia, and I downloaded it and preceded to build it. The documentation is somewhat lacking. I was a bit puzzled at first by what was supposed to happen. I guess I was assuming a .LIB file would be built but I didn't see one and I didn't see any instructions describing what was going on. What exactly was it building, and where is it? Of course I discovered that it builds just the OBJ files, that you link your application with these, and you need to set up a path to the Harmonia source code since D doesn't have header files. No doubt, the Harmonia regulars know all of this unconsciously at this point, and so documentation isn't needed for them. But to the new guy who has just happened across it for the first time, it not so obvious right away how to piece it all together.



Hey, I'm getting to be a relatively old fart and did my time in the 80's doing everything on the command line. However, I'm not a proponent of the "real manly programmers use the command line and build everything with make" philosophy. I'll become a programming wimp if it means a nicer environment. I love Intellisense.



Sorry if this is a rant; I didn't mean it to be. I guess I just wanted to mention---and I know that everyone does understand this---that to make D a realistic and practical choice, there are plenty of things to worry about besides the language itself.



Jim

Jim Hewes wrote:
> I've been loosely following the D forums for a while as a lurker. Perhaps this post is more appropriate for the main D forums but I'm really still a beginner so I'll post here.

> Is is possible to debug with Visual Studio 2005? I use VS2005 regularly with C++ and to some small extent C#. It would be nice to be able to use this IDE. My beginning attempt to debug the sample D code with it didn't work.

Howdy.  I tried it recently with VS 2003.  Using "Attach to process" you can step through the code set breakpoints etc, but VS apparently doesn't know what to do with D's variables, so you can't actually do much of anything.   I have no idea if it's possible to make some kind plugin for Visual Studio that would make it possible to view variables, but if so it would be fantastic.  I have a friend who worked on the debugger at Microsoft, so maybe I'll drop him a line about that.

> This kind of brings up a point. I realize that the D language is considered to increase your productivity by 30% or so, based on line count. But I think that productivity results from multiple factors, only one of which is the language. When I try to evaluate which language would be a good choice for my application, I think of the whole development experience. Have you ever tried C# within VS2005? I can get going rather quickly. No environment variables to set up; no INI files to configure. You can start a project from a template and immediately compile and run it. If you want a GUI control, just plop it onto the dialog and it generates the code. All this is due to the IDE, not the language.

Agreed.  C++ with a good IDE can still beat the pants off D for productivity.  Even though C++ as a language may not be as productive.

> I don't mean to sound like an advertisement for VS2005 and C#. My point is that by comparison, even though the D language is productive, some of that is negated by the whole development experience. 

I think most people would agree with you here.  Just someone has to write it.  There's some momentum picking up recently on an Eclipse plugin, but even that's aiming more for the Intellisense side, with no plans for debugging support just yet.

If you'd like to get involved in that project I'm sure they'd welcome a seasoned command-line hacker from the 80's.  :-)  Particularly if you've got expertise in writing debuggers. :-D

--bb

Bill Baxter escribió:
> Jim Hewes wrote:
> I think most people would agree with you here.  Just someone has to write it.  There's some momentum picking up recently on an Eclipse plugin, but even that's aiming more for the Intellisense side, with no plans for debugging support just yet.

Just because I don't want to say "the plugin will support a, b, c, ..., z". Seeing such a list scares me and I think "I'll never make it". Besides, I have no experience with debuggers at all. But I think debugging is not the most important thing.

If you do test-driven programming (I've been using it since a while and now I can't go back... it just feels not right doing it some other way) the thing you'll use most is refactoring, and if to refactor you have to manually verify, compile, find errors, correct them, etc., you'll quickly get tired. I plan to support refactoring.

> If you'd like to get involved in that project I'm sure they'd welcome a seasoned command-line hacker from the 80's.  :-)  Particularly if you've got expertise in writing debuggers. :-D

You are totally right. :-)

Jim Hewes escribió:
> Sorry if this is a rant; I didn't mean it to be. I guess I just wanted to mention---and I know that everyone does understand this---that to make D a realistic and practical choice, there are plenty of things to worry about besides the language itself.

I believe this too. After the 1.0 realease it would be a great decision if a lot of people (including Walter) push hard to make a powerful IDE working. The only problem is that Walter dosen't find IDEs useful, although he do realizes that for others (like you and me) they are. An IDE saves a lot of time writing code, boilerplate code, and transforming it (refactoring).

Actually, I only program D from within VS2005!

I use the vsplugind found on dsource, but that's only needed for building right from VS. Just for debugging, you don't need anything. Compiling your program using dmd -g will add the needed symbols to the obj/exe and VS will understand them! Arrays are shown as 64-bit integers, but when seen in hex, it's obvious what part is the count and what the pointer. Alternatively, you can take the array's address and cast it to a int*.

For syntax highlighting you should add .d to the extensions list in the options dialog, and let VS treat it as C++ or C#. Missing keywords can be added using a text-file called usertype.dat with a keyword on each line. It goes in the VS "IDE" folder, if I'm not mistaken, but better google to duoble check that (no VS2005 here at home).

L.

Lionello Lunesu wrote:
> Actually, I only program D from within VS2005!
> 
> I use the vsplugind found on dsource, but that's only needed for building right from VS. Just for debugging, you don't need anything. Compiling your program using dmd -g will add the needed symbols to the obj/exe and VS will understand them! Arrays are shown as 64-bit integers, but when seen in hex, it's obvious what part is the count and what the pointer. Alternatively, you can take the array's address and cast it to a int*.
> 
> For syntax highlighting you should add .d to the extensions list in the options dialog, and let VS treat it as C++ or C#. Missing keywords can be added using a text-file called usertype.dat with a keyword on each line. It goes in the VS "IDE" folder, if I'm not mistaken, but better google to duoble check that (no VS2005 here at home).

Wow, that's excellent info.  I have VS2005, but I haven't used it much.  I'll have to give it a shot once dsource comes back.

--bb

"Bill Baxter" <wbaxter@gmail.com> wrote in message news:ej5vcn$2554$1@digitaldaemon.com...
> If you'd like to get involved in that project I'm sure they'd welcome a seasoned command-line hacker from the 80's.  :-)  Particularly if you've got expertise in writing debuggers. :-D
>
> --bb

Ah, unfortunately I don't know anything about writing debuggers. Anyway, I'd probably just use Windbg.exe before going to all that trouble.

Jim

"Lionello Lunesu" <lionello@lunesu.remove.com> wrote in message news:ej6p57$2nhe$1@digitaldaemon.com...
> Actually, I only program D from within VS2005!
>
> I use the vsplugind found on dsource, but that's only needed for building right from VS. Just for debugging, you don't need anything. Compiling your program using dmd -g will add the needed symbols to the obj/exe and VS will understand them! Arrays are shown as 64-bit integers, but when seen in hex, it's obvious what part is the count and what the pointer. Alternatively, you can take the array's address and cast it to a int*.
>
> For syntax highlighting you should add .d to the extensions list in the options dialog, and let VS treat it as C++ or C#. Missing keywords can be added using a text-file called usertype.dat with a keyword on each line. It goes in the VS "IDE" folder, if I'm not mistaken, but better google to duoble check that (no VS2005 here at home).
>
> L.
>

Thanks, I'll check out the plug-in when dsource is back.
I was able to debug the sample hello.exe app in VS2005 by doing the
following:

1. Load hello.exe into VS2005 as a project. Also, open the hello.d source
file.
2. Press F11 to take one step into the code. Source is not available, so
show disassembly.
3. In the disassembly window, enter the address as "_Dmain" and hit return.
The window will show the mixed source/assembly at _Dmain.
4. In the disassembly window, set a breakpoint at the first line of _Dmain
and hit Go.
5. In the source window, you should now see execution stop at the first line
and you can single step from there.

However, I wasn't able to set breakpoints from the source window. But I haven't had much time to play with it yet. Hopefuly I can spend more time next weekend. (Hey! I have a day job.)

Jim

Jim Hewes escribió:
> 
> Thanks, I'll check out the plug-in when dsource is back.
> I was able to debug the sample hello.exe app in VS2005 by doing the following:
> 
> 1. Load hello.exe into VS2005 as a project. Also, open the hello.d source file.
> 2. Press F11 to take one step into the code. Source is not available, so show disassembly.
> 3. In the disassembly window, enter the address as "_Dmain" and hit return. The window will show the mixed source/assembly at _Dmain.
> 4. In the disassembly window, set a breakpoint at the first line of _Dmain and hit Go.
> 5. In the source window, you should now see execution stop at the first line and you can single step from there.
> 
> However, I wasn't able to set breakpoints from the source window. But I haven't had much time to play with it yet. Hopefuly I can spend more time next weekend. (Hey! I have a day job.)
> 
> Jim
> 
> 
> 

You have to compile with -g to do so.

-- 
Carlos Santander Bernal

Arrays can be evaluated using watch expressions. For example,
  char[] a = "abc";
    a.length is the watch expression (int)a
    a.ptr is the watch expression (char*)*((int*)(&a)+1)

You can use the format suffix on the watch expression to display the whole string. For example "abc" is displayed with (char*)*((int*)(&a)+1),3



Lionello Lunesu wrote:
> Actually, I only program D from within VS2005!
> 
> I use the vsplugind found on dsource, but that's only needed for building right from VS. Just for debugging, you don't need anything. Compiling your program using dmd -g will add the needed symbols to the obj/exe and VS will understand them! Arrays are shown as 64-bit integers, but when seen in hex, it's obvious what part is the count and what the pointer. Alternatively, you can take the array's address and cast it to a int*.
> 
> For syntax highlighting you should add .d to the extensions list in the options dialog, and let VS treat it as C++ or C#. Missing keywords can be added using a text-file called usertype.dat with a keyword on each line. It goes in the VS "IDE" folder, if I'm not mistaken, but better google to duoble check that (no VS2005 here at home).
> 
> L. 
> 
>