www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Has anyone been able to debug with VS2005?

reply "Jim Hewes" <jhewesNOSPAM ix.netcom.com> writes:
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 

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 

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.




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 


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
Nov 11 2006
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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 

 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 

 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.



 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
Nov 11 2006
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
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. :-)
Nov 11 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sat, 11 Nov 2006 23:36:08 -0300, Ary Manzana <ary esperanto.org.ar>
wrote:


I plan to support refactoring.


In that case, I hope you don't mind me throwing some general ramblings
your way.

I've been thinking about parsing recently. Not parsing for compilers,
but parsing for documentation/refactoring/whatever where you need to
make sense of incomplete and broken code.

And I've also been thinking about Google-style text searches.

To be specific, I was thinking that you could build an index based on
the tokenized source code, and then search for all points in the code
that match a certain grammar in much the same way that you would
search the index for a regular expression match in a search engine
that supported it.

The index might be a ternary tree, for instance, containing substrings
of the tokenised source from each possible start token. You could
limit those substrings to some small number of tokens to avoid needing
polynomial time to build the index, and to make incremental changes
practical. Anything that matches the first 8 (or whatever) tokens that
are kept in the index, you just refer back to the full tokenised
source to find out how far the matching continues.

Add some Tomita/backtracking/whatever trickery to get past ambiguities
and this sounds to me like a workable method for doing things like
spotting all functions or all variable declarations or whatever in an
incomplete/broken source file with limited context (library headers
etc) available.

It seems to me somehow closer to the way people read code than to
traditional parsing, in that it can basically spot landmark patterns
anywhere in the code without needing to understand the whole of the
source file.

Is this sense, or nonsense?

-- 
Remove 'wants' and 'nospam' from e-mail.
Nov 29 2006
prev sibling parent "Jim Hewes" <jhewesNOSPAM ix.netcom.com> writes:
"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
Nov 14 2006
prev sibling next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
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).
Nov 11 2006
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
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 

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.
Nov 12 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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 

 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
Nov 12 2006
prev sibling next sibling parent reply "Jim Hewes" <jhewesNOSPAM ix.netcom.com> writes:
"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 

 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
Nov 14 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
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
Nov 14 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Carlos Santander wrote:

 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.
 


Nope.  Setting breakpoints on source file lines still doesn't work even 
with -g.

But something's odd.  I'm pretty sure it _did_ work before I installed 
the VSPluginD.  I could set breakpoints, but I couldn't see variables 
before.  Now I can see variables, but I can't set breakpoints (except 
from dissasembly).  Or maybe it was only VS.NET 7.1 that was able to set 
source-level breakpoints?

I wonder if it's possible to tweak something in AutoExp.dat or in an 
EEAddIn plugin to make D strings and such show up properly, without the 
need for the "(char*)*((int*)(&str)+1)" trick.

The debugger seems to think all D arrays are of type unsigned__int64, 
though, which will probably be problematic.

--bb
Nov 17 2006
parent reply "Jim Hewes" <jhewesNOSPAM ix.netcom.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:ejman4$10b1$1 digitaldaemon.com...

 Nope.  Setting breakpoints on source file lines still doesn't work even 
 with -g.

 But something's odd.  I'm pretty sure it _did_ work before I installed the 
 VSPluginD.  I could set breakpoints, but I couldn't see variables before. 
 Now I can see variables, but I can't set breakpoints (except from 
 dissasembly).  Or maybe it was only VS.NET 7.1 that was able to set 
 source-level breakpoints?

 I wonder if it's possible to tweak something in AutoExp.dat or in an 
 EEAddIn plugin to make D strings and such show up properly, without the 
 need for the "(char*)*((int*)(&str)+1)" trick.

 The debugger seems to think all D arrays are of type unsigned__int64, 
 though, which will probably be problematic.

 --bb


I think you're correct. My memory is a bit foggy, but I think I did try out 
a D sample program briefly a while back using VS2003 (v 7.1)  and I was able 
to set breakpoints in the source window.  With CS2005, I can see variables 
but can't set breakpoints in the source window. So perhaps Microsoft changed 
the format of their debug info or something.

Jim
Nov 19 2006
parent "Jim Hewes" <jhewesNOSPAM ix.netcom.com> writes:
"Jim Hewes" <jhewesNOSPAM ix.netcom.com> wrote in message 
news:ejqgf0$2nol$1 digitaldaemon.com...

   With CS2005, I can see variables ...


Oops, typo. I meant VS2005.
Nov 19 2006
prev sibling parent Bradley Smith <digitalmars-com baysmith.com> writes:
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 

 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.
Nov 14 2006
prev sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sat, 11 Nov 2006 17:36:26 -0800, "Jim Hewes"
<jhewesNOSPAM ix.netcom.com> wrote:



that by comparison, even though the D language is productive, some of that 
is negated by the whole development experience.


D has issues, its true, but it depends what you're doing. And the

add a simple C interface using VC++, and you're ready to use that UI
from D. Not ideal, of course, but it's an option.

However my real view is that, depending on what development tools you
have available, D may simply be more for a possible future than for
the present. Perl, Python, PHP, Ruby etc have shown that there are
people out there who will develop the needed tools given a compelling
reason. I wouldn't be surprised if topics like this trigger 'just
download these Eclipse plugins' responses some time in the near
future.


it's not cross-platform (is MONO a serious option?)


Good question. The windows GUI tends to get heavy use in .NET, for
instance, yet MONO simply cannot provide it because Microsoft hasn't
included it in the open part of .NET. There are alternatives (I forget
which, but there is support for either GTK or KDE widget sets) but the
apps that use them seem to be for Linux only. You can certainly get
GTK for windows, but I'm not so sure about KDE, so maybe that has
something to do with it.

My view is that MONO is a good solid platform, on the whole, but that
Windows .NET and Linux .NET are separate platforms. The user interface
is too important to most apps to dismiss as some kind of minor detail.
After all, the UI is often the bulk of the code.

-- 
Remove 'wants' and 'nospam' from e-mail.
Nov 29 2006