Please give me some feedback on this:

Summary: Develop a debugger for D.

Choices:

 1) Jump in with D: Develop using D,
with limited debugger support. I like
coding in D, but I like to use a
debugger to examine code carefully
during runtime. This is where I have
started, but it's slow going without
a fully supportive debugger.

 2) C++ bootstrap: Develop using C++,
using existing C++ code as foundation.
Use this debugger to support rewriting
the debugger in D.

 3) C# bootstrap: Same as 2. C# might
allow for more rapid development, but
may have serious limitations for low
level programming.

I'm interested in developing a debugger
for D, and ultimately I intend for it to
be written in D. However the current state
of using debuggers with D is not optimal,
although I have had good success with MS's
SDK debugger and the debugger that is in
MS's Visual Studio.

I have a lot of code that I have developed
in C++ which could easily serve as the
foundation for writing the debugger, and
the advantage there would be that I would
be working with a lot of code that I am
very familiar with and that I have refined
over some length of time. There would also
be no problem doing low level programming.

I could also use C# for the initial version,
and that would to some extent allow me to
work quickly, as C# is very easy to use
and the MS framework allows for rapid
application development. It is very possible
that C# would get in the way of getting
close to the system when writing a debugger.
(P.S. I am using the OSS ShartDevelop
.NET IDE and MS's free SDK.) I can't say
I am wild about using C# because of the VM
it uses, and the need for others to install
.NET to use this C# version of the debugger.

Great idea I look forward to the debugger!

>   2) C++ bootstrap: Develop using C++,
> using existing C++ code as foundation.
> Use this debugger to support rewriting
> the debugger in D.

I vote this option, if you already have a large code base which you can use, then defintly this route, give time for D to mature a bit and then a rewrite if you like.

Charles


"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgrteh$1lpf$1@digitaldaemon.com...
> Please give me some feedback on this:
>
> Summary: Develop a debugger for D.
>
> Choices:
>
>   1) Jump in with D: Develop using D,
> with limited debugger support. I like
> coding in D, but I like to use a
> debugger to examine code carefully
> during runtime. This is where I have
> started, but it's slow going without
> a fully supportive debugger.
>
>   2) C++ bootstrap: Develop using C++,
> using existing C++ code as foundation.
> Use this debugger to support rewriting
> the debugger in D.
>
>   3) C# bootstrap: Same as 2. C# might
> allow for more rapid development, but
> may have serious limitations for low
> level programming.
>
> I'm interested in developing a debugger
> for D, and ultimately I intend for it to
> be written in D. However the current state
> of using debuggers with D is not optimal,
> although I have had good success with MS's
> SDK debugger and the debugger that is in
> MS's Visual Studio.
>
> I have a lot of code that I have developed
> in C++ which could easily serve as the
> foundation for writing the debugger, and
> the advantage there would be that I would
> be working with a lot of code that I am
> very familiar with and that I have refined
> over some length of time. There would also
> be no problem doing low level programming.
>
> I could also use C# for the initial version,
> and that would to some extent allow me to
> work quickly, as C# is very easy to use
> and the MS framework allows for rapid
> application development. It is very possible
> that C# would get in the way of getting
> close to the system when writing a debugger.
> (P.S. I am using the OSS ShartDevelop
> .NET IDE and MS's free SDK.) I can't say
> I am wild about using C# because of the VM
> it uses, and the need for others to install
> .NET to use this C# version of the debugger.
>
>

My 2 pence-worth:

1. The debugger that is released with D 1.0 must be able to debug D *and* the C/C++ that some D calls will make into C-interface libraries. This is essential. To my mind this cannot succeed without some debugging expertise (such as yourself, maybe) and Walter working in concert. I know there's been a debate on the validity of debuggers as a software development tool on one of the other NGs, but I cannot see how D will be taken seriously unless it has a very competent debugger. Since we will inevitably (and quite right too) get some complex and one might say obfuscated code once the templates and the other libraries get going, a debugger may be an essential learning tool as well.

2. The debugger should be preferentially written in D, with the odd C-library call thrown in for good measure. It should *not* be written in any .NET or Java, as that will lead to a bit fat f**ker of a thing, that people will be (rightly) prejudiced against: if it's in C# then how is it going to port to other architectures, if it's written in Java it'll run like a dead pig. In either case, people will have to install VMs, and have gargantuan disks, blah blah. Not the D way at all.

3. The debugger infrastructure *must* be modularisable (sic.), such that it
can be plugged into DMC++'s IDDE, DIDE, VS.NET (once we've worked out how to
do that), CodeWarrior, and the various other popular IDDEs. This will have
to include COM (and I'll gladly help here), but also an open non-OS-specific
interface. (The COM would probably be just a simple layer over that for
Win32 versions)



"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgrteh$1lpf$1@digitaldaemon.com...
> Please give me some feedback on this:
>
> Summary: Develop a debugger for D.
>
> Choices:
>
>   1) Jump in with D: Develop using D,
> with limited debugger support. I like
> coding in D, but I like to use a
> debugger to examine code carefully
> during runtime. This is where I have
> started, but it's slow going without
> a fully supportive debugger.
>
>   2) C++ bootstrap: Develop using C++,
> using existing C++ code as foundation.
> Use this debugger to support rewriting
> the debugger in D.
>
>   3) C# bootstrap: Same as 2. C# might
> allow for more rapid development, but
> may have serious limitations for low
> level programming.
>
> I'm interested in developing a debugger
> for D, and ultimately I intend for it to
> be written in D. However the current state
> of using debuggers with D is not optimal,
> although I have had good success with MS's
> SDK debugger and the debugger that is in
> MS's Visual Studio.
>
> I have a lot of code that I have developed
> in C++ which could easily serve as the
> foundation for writing the debugger, and
> the advantage there would be that I would
> be working with a lot of code that I am
> very familiar with and that I have refined
> over some length of time. There would also
> be no problem doing low level programming.
>
> I could also use C# for the initial version,
> and that would to some extent allow me to
> work quickly, as C# is very easy to use
> and the MS framework allows for rapid
> application development. It is very possible
> that C# would get in the way of getting
> close to the system when writing a debugger.
> (P.S. I am using the OSS ShartDevelop
> .NET IDE and MS's free SDK.) I can't say
> I am wild about using C# because of the VM
> it uses, and the need for others to install
> .NET to use this C# version of the debugger.
>
>

Thanks. After some work getting started
in D I began to think about how much more
I would want good debugging support as the
project became more complex. Visual Studio
has good debugging support for C++.

Charles Sanders wrote:
> Great idea I look forward to the debugger!
> 
> 
>>  2) C++ bootstrap: Develop using C++,
>>using existing C++ code as foundation.
>>Use this debugger to support rewriting
>>the debugger in D.
> 
> 
> I vote this option, if you already have a large code base which you can use,
> then defintly this route, give time for D to mature a bit and then a rewrite
> if you like.
> 
> Charles
> 

Thanks for the feedback and insights, and your offer
of help with COM.

Matthew Wilson wrote:
> My 2 pence-worth:
> 
> 1. The debugger that is released with D 1.0 must be able to debug D *and*
> the C/C++ that some D calls will make into C-interface libraries. This is
> essential.  To my mind this cannot succeed without some debugging expertise
> (such as yourself, maybe) and Walter working in concert. I know there's been
> a debate on the validity of debuggers as a software development tool on one
> of the other NGs, but I cannot see how D will be taken seriously unless it
> has a very competent debugger. Since we will inevitably (and quite right
> too) get some complex and one might say obfuscated code once the templates
> and the other libraries get going, a debugger may be an essential learning
> tool as well.

I can't imagine who wouldn't want to take a close look at code and
data while a program is running. It's just another level or layer
of inspection (on top of careful design and coding.) To me, not
examining everything carefully with a debugger is reckless.

> 1. The debugger that is released with D 1.0 must be able to debug
> D *and* the C/C++ that some D calls will make into C-interface
> libraries.

That's a good point.

> 
> 2. The debugger should be preferentially written in D, with the odd
> C-library call thrown in for good measure. It should *not* be written in any
> .NET or Java, as that will lead to a bit fat f**ker of a thing, that people
> will be (rightly) prejudiced against: if it's in C# then how is it going to
> port to other architectures, if it's written in Java it'll run like a dead
> pig. In either case, people will have to install VMs, and have gargantuan
> disks, blah blah. Not the D way at all.

I'd _like_ to have a fully supportive debugger if I'm writing a
debugger. Otherwise it would be too much work and go too slow. That's
what got me thinking about falling back on using C++ as a bootstrap
project for a D version. Of course I would enjoy coding D more than
C++.

> It should *not* be written in any
> .NET or Java, as that will lead to a bit fat f**ker of a thing

I was disappointed that MS went the route of using a VM. C# is
really nice to use, but a full featured app that I had written in
C++ has a memory footprint of about 175K. Just the start of a
rewrite of that app in C# has a memory footprint more that 100
times larger at 21,000K.

> 3. The debugger infrastructure *must* be modularisable (sic.), such that it
> can be plugged into DMC++'s IDDE, DIDE, VS.NET (once we've worked out how to
> do that), CodeWarrior, and the various other popular IDDEs. This will have
> to include COM (and I'll gladly help here), but also an open non-OS-specific
> interface. (The COM would probably be just a simple layer over that for
> Win32 versions)

I've been thinking that way in general, especially as others are
working on their own IDEs.

> 
> 
> "Frank Wills" <fdwills@sandarh.com> wrote in message
> news:bgrteh$1lpf$1@digitaldaemon.com...
> 
>>Please give me some feedback on this:
>>
>>Summary: Develop a debugger for D.
>>
>>Choices:
>>
>>  1) Jump in with D: Develop using D,
>>with limited debugger support. I like
>>coding in D, but I like to use a
>>debugger to examine code carefully
>>during runtime. This is where I have
>>started, but it's slow going without
>>a fully supportive debugger.
>>
>>  2) C++ bootstrap: Develop using C++,
>>using existing C++ code as foundation.
>>Use this debugger to support rewriting
>>the debugger in D.
>>
>>  3) C# bootstrap: Same as 2. C# might
>>allow for more rapid development, but
>>may have serious limitations for low
>>level programming.
>>

> I was disappointed that MS went the route of using a VM. C# is
> really nice to use, but a full featured app that I had written in
> C++ has a memory footprint of about 175K. Just the start of a
> rewrite of that app in C# has a memory footprint more that 100
> times larger at 21,000K.
> 

Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the app ends up that big?  I can hardly imagine people supporting and using such a technology!

I had no idea...

Later,

John

"John Reimer" <jjreimer@telus.net> wrote in message news:3F31CB6A.4000406@telus.net...
>
> > I was disappointed that MS went the route of using a VM. C# is really nice to use, but a full featured app that I had written in C++ has a memory footprint of about 175K. Just the start of a rewrite of that app in C# has a memory footprint more that 100 times larger at 21,000K.
> >
>
> Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the app ends up that big?  I can hardly imagine people supporting and using such a technology!

For all that I find such bloat inexcusable (not to say risible!), it is not the case that the memory sizes are integral multiples of each other, more likely (though not absolutely) that it represents a fixed overhead, ie.

C++          C#
175K        20MB
2MB         23MB
4MB          26MB

and such. (Of course, I just invented thos figures ...)

Something isn't it? I'm glad Walter
is developing D.

John Reimer wrote:
> 
>> I was disappointed that MS went the route of using a VM. C# is
>> really nice to use, but a full featured app that I had written in
>> C++ has a memory footprint of about 175K. Just the start of a
>> rewrite of that app in C# has a memory footprint more that 100
>> times larger at 21,000K.
>>
> 
> Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the app ends up that big?  I can hardly imagine people supporting and using such a technology!
> 
> I had no idea...
> 
> Later,
> 
> John
> 

Matthew Wilson wrote:
> "John Reimer" <jjreimer@telus.net> wrote in message
> news:3F31CB6A.4000406@telus.net...
> 
>>>I was disappointed that MS went the route of using a VM. C# is
>>>really nice to use, but a full featured app that I had written in
>>>C++ has a memory footprint of about 175K. Just the start of a
>>>rewrite of that app in C# has a memory footprint more that 100
>>>times larger at 21,000K.
>>>
>>
>>Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the
>>app ends up that big?  I can hardly imagine people supporting and using
>>such a technology!
> 
> 
> For all that I find such bloat inexcusable (not to say risible!), it is not
> the case that the memory sizes are integral multiples of each other, more
> likely (though not absolutely) that it represents a fixed overhead, ie.
> 
> C++          C#
> 175K        20MB
> 2MB         23MB
> 4MB          26MB
> 
> and such. (Of course, I just invented thos figures ...)
> 

Well, I guess that shows what happens when
you invent figures! ;) Actually I would have
expected that same thing myself, but alas
it is not so.

The C++ app is all C++, so there is little
overhead, and it's memory usage per copy is
linear.

The 20MB C# app can only run one copy, but
a second C# app that I just started uses
8,000K (8MB), and each additional copy uses
another 8MB. It's memory usage is also linear.
Ten copies of this start of a C# app uses
10 x 8MB = 80MB.

That's not really what I was suggesting.

I'm saying that if a (single instance of a) C++ app had a footprint of 2MB,
it's likely that an
equivalent C# one would be 23MB, rather than 400MB.

I would have a *very* hard time swallowing the latter, and frankly .NET would not be viable if that were the case.


"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgskt3$2bd8$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > "John Reimer" <jjreimer@telus.net> wrote in message news:3F31CB6A.4000406@telus.net...
> >
> >>>I was disappointed that MS went the route of using a VM. C# is really nice to use, but a full featured app that I had written in C++ has a memory footprint of about 175K. Just the start of a rewrite of that app in C# has a memory footprint more that 100 times larger at 21,000K.
> >>>
> >>
> >>Excuse me?! You mean almost 20 MB? Woah! Who would want to use C# if the app ends up that big?  I can hardly imagine people supporting and using such a technology!
> >
> >
> > For all that I find such bloat inexcusable (not to say risible!), it is
not
> > the case that the memory sizes are integral multiples of each other,
more
> > likely (though not absolutely) that it represents a fixed overhead, ie.
> >
> > C++          C#
> > 175K        20MB
> > 2MB         23MB
> > 4MB          26MB
> >
> > and such. (Of course, I just invented thos figures ...)
> >
>
> Well, I guess that shows what happens when
> you invent figures! ;) Actually I would have
> expected that same thing myself, but alas
> it is not so.
>
> The C++ app is all C++, so there is little
> overhead, and it's memory usage per copy is
> linear.
>
> The 20MB C# app can only run one copy, but
> a second C# app that I just started uses
> 8,000K (8MB), and each additional copy uses
> another 8MB. It's memory usage is also linear.
> Ten copies of this start of a C# app uses
> 10 x 8MB = 80MB.
>