On Sun, 16 Mar 2008 22:51:04 +0000, Moritz Warning wrote:
> I tried ZeroBugs without much debugger knowledge; but I have impression that it works quite nice. It showed the source code along with the error line along with the thread trace (for the correct thread, afaik).
stack trace

Moritz Warning Wrote:

> On Sun, 16 Mar 2008 21:23:09 +0000, BCS wrote:
> 
> 
> > 4. “What is the current stability of dmd 2.0?” -a. I said alpha. Please correct me if I’m wrong.
> I think alpha is pretty much correct.
> 
> > 5. “What is the estimated “ship date” of dmd 2.0?”
> I think to remember Walter mentioned autumn in some post on the NG. But I can't find the post in question to verify that statement.
> 
> > 
> > 3. Same for debuggers. I know ddbg works on windows and for Linux there
> > is a GDB patch and ZeroBugs. However I haven’t seen much recent work on
> > any of these.
> > 
> 
> I tried ZeroBugs without much debugger knowledge;
> but I have impression that it works quite nice.
> It showed the source code along with the error line along with the thread
> trace (for the correct thread, afaik).

I would argue for IDA Pro, but it doesn't obfuscate all the stuffing put in with compiled D programs.  Most debuggers don't.

D wraps your main with something like this:

gc_init()
module_ctor()
*your main*
module_dtor()
gc_term()

and seemingly includes the entire Phobos library every time it compiles, regardless of what you actually need in your program.  This means [println("hello world");] comes out at 80kb and tends to clutter things up.

I prefer SciTE for coding in D.  It's got excellent rectangle-selection support, vast multi-language syntax highlighting, and doesn't change what you type (a HUGE peeve of mine)

I recommend using the latest DMD 1.0xx or the latest GDC.  GDC gets less love than DMD, but it's built to GCC backend, so it can actually target more systems than the obsolete x86-32.

Good luck.

BCS wrote:
> Reply to Bill,
> 
>> BCS wrote:
>>
>>> 4. Direct question to Walter (and the developers of the other tools)
>>> If we were to use D and run into a blocking issue, can we effect your
>>> properties with regards to resolving it? (This assumes that the issue
>>> is not a language design issue.)
>>>
>> You mean "can we affect your priorities"?
> 
> http://xkcd.com/326/

http://www.m-w.com -- effect[2, transitive verb]
"""
The more common /affect/ denotes having an effect or influence <the weather affected everyone's mood>. The verb /effect/ goes beyond mere influence; it refers to actual achievement of a final result <the new administration hopes to effect a peace settlement>.
"""

A peace settlement is a final achievement.  "your priorities" are not a final achievement.  If that's the version of "effect" you meant then you should have said something more along the lines of:
"can we effect /a change in/ your priorities"  ;-)

(In any case, I don't think you meant to say "properties" which was the main thing I was trying to verify.)

>> Are you thinking cash here?
> 
> Um, that /might/ be on the list... way at the end... in really small amounts... a long way after thank you notes, begging, promises of citations in the appreciation notes and appealing to your vanity, duty and anything else we can including an offer of lunch "if you ever happen to be in this neck of the woods".
> 
> Now I'm not talking bribes here or anything. More like: "this is a bug, everyone says it's a bug, could we please get a fix to it soon?"

Ok, just curious.  If a company is asking for someone to change their priorities just for them, then it often involves money, at least in the form of paying for a support contract, or per-incident support.

If you're *not* talking money, then I doubt you'll be able to get any promises from anyone about prioritizing your company's particular bug fixes over any others.  Maybe you can get a "sure we'll do what we can" but that's meaningless, really.

--bb

On Sun, 16 Mar 2008 21:23:09 +0000 (UTC), BCS wrote:

> 4. Direct question to Walter (and the developers of the other tools) If we were to use D and run into a blocking issue, can we effect your properties with regards to resolving it? (This assumes that the issue is not a language design issue.)

Certainly. If a tool of mine needs an urgent bug fix then that is of benefit to the whole community. Be aware though that real life does impose itself from time to time ;-)


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
17/03/2008 12:19:11 PM

Robert Fraser escribió:
> BCS Wrote:
>> 1. What is the state of the art in IDE’s for D? Code::Blocks? Eclipse+Decent?
>>
>> 2. What stage are these in? Stable, approaching stability, active development, in development but not very active? 
> 
> I can only answer with regards to Descent. As of Descent 0.5.1, it should be considered "stable" as in it will not hang or crash, but "alpha" in terms of functionality. Any functionality that requires semantic resolution (in particular, auto-complete and go-to-definition) may not work properly for all input (but should work fine for most :-)!). Semantic errors should be turned off for large projects, as there are significant problems with these. However, even if certain features do not work all the time, Eclipse will not crash, and the text editing capabilities and syntax error marking will always remain usable.
> 
> The supported features in Descent can be seen here:
> http://www.dsource.org/projects/descent
> 
> It was designed from the ground-up for D support, so supports many more D-specific features than Code::Blocks does, and properly handles templates (to some degree). On the other hand it's written in Java, based on Eclipse and may be too "bloated" for people used to text editors or even Code::Blocks (it takes about 150MB worth of downloads to get it all up and running if you include the Java runtime).
> 
> Ary can probably answer further, especially on his plans for Descent's future. I'm hoping to have project building and unit testing support integrated in Descent by the next release, but it may be pushed back further.

I should add that, although Descent won't hang or crash, some people found that autocompletion, in certain cases, takes too long (about 2 or 3 seconds). Also, autocompletion isn't accurate enough: for example, sometimes base methods of a class won't show. This also applies to "go to declaration". Also, autocompletion doesn't work inside templates. So Descent helps, but it's not "complete".

I'll fix that for the next release. But I'm feeling kind of lazy lately (and tomorrow I'll be back to unversity, and I work, so...) But I hope I can get over that. I really want there to be a smart IDE for D, because your boss is not the only one who would ask that kind of question (mine's asked that too).

Bill Baxter escribió:
> BCS wrote:
>> Reply to Bill,
>>
>>> BCS wrote:
>>>
>>>> 4. Direct question to Walter (and the developers of the other tools)
>>>> If we were to use D and run into a blocking issue, can we effect your
>>>> properties with regards to resolving it? (This assumes that the issue
>>>> is not a language design issue.)
>>>>
>>> You mean "can we affect your priorities"?
>>
>> http://xkcd.com/326/
> 
> http://www.m-w.com -- effect[2, transitive verb]
> """
> The more common /affect/ denotes having an effect or influence <the weather affected everyone's mood>. The verb /effect/ goes beyond mere influence; it refers to actual achievement of a final result <the new administration hopes to effect a peace settlement>.
> """
> 
> A peace settlement is a final achievement.  "your priorities" are not a final achievement.  If that's the version of "effect" you meant then you should have said something more along the lines of:
> "can we effect /a change in/ your priorities"  ;-)
> 
> (In any case, I don't think you meant to say "properties" which was the main thing I was trying to verify.)
> 
>>> Are you thinking cash here?
>>
>> Um, that /might/ be on the list... way at the end... in really small amounts... a long way after thank you notes, begging, promises of citations in the appreciation notes and appealing to your vanity, duty and anything else we can including an offer of lunch "if you ever happen to be in this neck of the woods".
>>
>> Now I'm not talking bribes here or anything. More like: "this is a bug, everyone says it's a bug, could we please get a fix to it soon?"
> 
> Ok, just curious.  If a company is asking for someone to change their priorities just for them, then it often involves money, at least in the form of paying for a support contract, or per-incident support.
> 
> If you're *not* talking money, then I doubt you'll be able to get any promises from anyone about prioritizing your company's particular bug fixes over any others.  Maybe you can get a "sure we'll do what we can" but that's meaningless, really.
> 
> --bb

I also think it's not just about money. Many D projects are made by people who do their tools in their free time (like Robert and me), so paying them won't make free time appear. Well... unless they are willing to quit their job just for a bug fix or enhancement.

Reply to Ary,

> I also think it's not just about money. Many D projects are made by
> people who do their tools in their free time (like Robert and me), so
> paying them won't make free time appear.

I'm glad it's not, at this point in time I don't think the D world could support the development efforts that are needed to get to the point that it can support them. (Show me a program that can parse /that/ sentence!)

> Well... unless they are
> willing to quit their job just for a bug fix or enhancement.

We're /not/ looking to /hire/ a tool chain <G> 

Reply to Derek,

> real life does impose itself from time to time ;-)
> 

Not in my life. In my life it's the other way around <G> "free time comes around from time to time".

Reply to Bill,

> (In any case, I don't think you meant to say "properties" which was
> the main thing I was trying to verify.)
> 


Err. Dang I can't type /and/ can't read!!

> Ok, just curious.  If a company is asking for someone to change their
> priorities just for them, then it often involves money, at least in
> the form of paying for a support contract, or per-incident support.
> 
> If you're *not* talking money, then I doubt you'll be able to get any
> promises from anyone about prioritizing your company's particular bug
> fixes over any others.  Maybe you can get a "sure we'll do what we
> can" but that's meaningless, really.
>

The best I was really hoping for would be something akin to "we tend to work on thing that we known are real issues for someone". (Kind of like my progress on dparse being a result of someone saying they might be using it for something.)

Derek Parnell wrote:
> On Sun, 16 Mar 2008 21:23:09 +0000 (UTC), BCS wrote:
> 
>> 4. Direct question to Walter (and the developers of the other tools) If we were to use D and run into a blocking issue, can we effect your properties with regards to resolving it? (This assumes that the issue is not a language design issue.)
> 
> Certainly. If a tool of mine needs an urgent bug fix then that is of
> benefit to the whole community. Be aware though that real life does impose
> itself from time to time ;-)

Sure. I do what I can to fix bugs that are hurting the most. I'll be the first to admit, however, that such value judgments are imperfect.