"antonio" <antonio@abrevia.net> wrote in message news:dpn5cl$24jc$1@digitaldaemon.com...
> Walter Bright wrote:
>> "antonio" <antonio@abrevia.net> wrote in message news:dpmrjv$1tm1$1@digitaldaemon.com...
>>>   Debugger... why there is not a good standard debugger?...
>>
>> There is, it comes on the Digital Mars CD.
> For the D language? with classes inspection and so on?

Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.

Walter Bright wrote:
> "antonio" <antonio@abrevia.net> wrote in message news:dpn5cl$24jc$1@digitaldaemon.com...
> 
>>Walter Bright wrote:
>>
>>>"antonio" <antonio@abrevia.net> wrote in message news:dpmrjv$1tm1$1@digitaldaemon.com...
>>>
>>>>  Debugger... why there is not a good standard debugger?...
>>>
>>>There is, it comes on the Digital Mars CD.
>>
>>For the D language? with classes inspection and so on?
> 
> 
> Yes, you can look at class members and locals with it. It's still a C debugger, but it does work. 
> 
> 

I think that's another "commercial weakness."

"Walter Bright" <newshound@digitalmars.com> wrote ...
>> For the D language? with classes inspection and so on?
>
> Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.

That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?

Kris wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote ...
>>> For the D language? with classes inspection and so on?
>> Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.
> 
> That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly? 
> 
> 

Ahem... I have to agree with Kris.

Walter, this is a little bit of false advertising or providing a "shade" of truth.  It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features.

Providing that statement without specific qualifications isn't fair.

-JJR

John Reimer wrote:
> Kris wrote:
> 
>> "Walter Bright" <newshound@digitalmars.com> wrote ...
>>
>>>> For the D language? with classes inspection and so on?
>>>
>>> Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.
>>
>>
>> That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?
>>
> 
> Ahem... I have to agree with Kris.
> 
> Walter, this is a little bit of false advertising or providing a "shade" of truth.  It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features.
> 
> Providing that statement without specific qualifications isn't fair.
> 
> -JJR

Agreed. People are looking for a solution for D, not a hack for D pulled from your work with C/C++

Kyle Furlong wrote:
> John Reimer wrote:
>> Kris wrote:
>>
>>> "Walter Bright" <newshound@digitalmars.com> wrote ...
>>>
>>>>> For the D language? with classes inspection and so on?
>>>>
>>>> Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.
>>>
>>>
>>> That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?
>>>
>>
>> Ahem... I have to agree with Kris.
>>
>> Walter, this is a little bit of false advertising or providing a "shade" of truth.  It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features.
>>
>> Providing that statement without specific qualifications isn't fair.
>>
>> -JJR
> 
> Agreed. People are looking for a solution for D, not a hack for D pulled from your work with C/C++
I agree.
Antonio

John Reimer wrote:
> Kris wrote:
> 
>> "Walter Bright" <newshound@digitalmars.com> wrote ...
>>
>>>> For the D language? with classes inspection and so on?
>>>
>>> Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.
>>
>>
>> That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?
>>
> 
> Ahem... I have to agree with Kris.
> 
> Walter, this is a little bit of false advertising or providing a "shade" of truth.  It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features.
> 
> Providing that statement without specific qualifications isn't fair.
> 
> -JJR

Hold on there <g>

That was a question; not an assertion :)

It may be that Walter's debugger does all the right things?

kris wrote:

>> Ahem... I have to agree with Kris.
>>
>> Walter, this is a little bit of false advertising or providing a "shade" of truth.  It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features.
>>
>> Providing that statement without specific qualifications isn't fair.
>>
>> -JJR
> 
> Hold on there <g>
> 
> That was a question; not an assertion :)
> 
> It may be that Walter's debugger does all the right things?

You think so?

:)

Oh okay, maybe the querying style of getting to the root of the matter shows less aggression.  Gentle is good... if that's the true intent.

I apologize; I should have spoken for myself rather than appeared to be reinterpreting you.

-JJR

Dave wrote:

> In article <dplmt0$10c1$1@digitaldaemon.com>, Nick says...
>>
>>In article <dpcvfn$19g6$1@digitaldaemon.com>, Dave says...
>>>
>>>What else is stopping the adoption of D where you work (Kris and anyone
>>>else)?
>>>
>>>- Dave
>>>
>>
>>I currently "work" at a university (I'm taking a master degree in physics,
>>but will hopefully be a Ph.D. student by the end of this year.) The
>>situation here is probably a lot different from a "normal" workplace.
>>...
>>
>>In conclusion, I think D might have a bright (no pun intended) future in nummerical computing, it only has to become more common and accepted first. The usual chicken-and-egg situation that all new inventions face at some point.
>>
>>Nick
>>
> 
> Do you also think it would be a big help to have an easy-to-use installation package for Windows and Linux for the compiler, linker and base libs.?
> 
> I don't know if you've seen the posts on these topics or not, but some things for "version next" that may be of interest for numerical computing have been discussions on:
> 
> - Array operations. Besides the coding advantages, these should also allow
> for optimizations like out-of-order execution, vectorization and avoiding
> aliasing 'de-optimizations'.
> - Compilers (and libraries) may be able to use D first class arrays to
> better optimize code. The current compilers are based on backends
> optimized for C/++. - D GC's could perhaps be built to help provide better
> locality of reference than malloc/free for things like large arrays
> allocated on the heap. - Native machine precision for the real datatype
> (this is already part of the language but the compiler backends don't take
> advantage of it right now, optimization-wise).

While a better installer would help, it's not a major concern.  Just continue to ensure that an individual can run it within his own home directory (in case of an obstinate sysadmin).  What's needed more is a better way to import C header files.  Or a better way to link with C++ code.  Or even a better way to smoosh an assemblage of several of the above together.

It's good that people are working on native D libraries, but face it...there is a truly immense number of pre-existing libraries that will need to be linked to, and many of them depend on header files that include things like functions specified by macros, and other atrocities.  Currently the only reasonable way to handle this is to write a chunk of C code with a nice interface that you call from D and which can handle the calls, but this is often a severe impedance mismatch, and with C++ it gets even worse.  I don't know that this needs to be dealt with as a part of the language...and it clearly shouldn't happen before 1.0, but it is VERY important.

-- 
Work in progress

problems
debugging !!!
c lib reuse !!
easy gui development !!!
phobos should be developed to something like .net or java frameworks !!!!!
reuse of c++ libs !!!

those are the killer at my end, where i can only be boss and yell DO. probably that will kill me in our project using D.

rko