On Mon, 08 Mar 2010 01:54:12 -0500, Walter Bright <newshound1@digitalmars.com> wrote:

> Lots of meat and potatoes here, and a cookie! (spelling checker for error messages)
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.057.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.041.zip
>
> Thanks to the many people who contributed to this update!

Note to everyone, dmd 2.041 array allocation is broken (inadvertently by my array append patch).  You should not use this release.

See this bug: http://d.puremagic.com/issues/show_bug.cgi?id=3930

If you want to use the new release without the bugs, please apply this patch to druntime:

http://www.dsource.org/projects/druntime/changeset?format=diff&new=262&old=260&new_path=trunk&old_path=trunk

Sorry for this, I hope a new release will come soon.

-Steve

Steven Schveighoffer:
> If you want to use the new release without the bugs, please apply this patch to druntime:
> 
> http://www.dsource.org/projects/druntime/changeset?format=diff&new=262&old=260&new_path=trunk&old_path=trunk

I have just added a small bug report, I don't know if this can interest you: http://d.puremagic.com/issues/show_bug.cgi?id=3933

Bye,
bearophile

On Thu, 11 Mar 2010 15:20:38 -0500, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>> If you want to use the new release without the bugs, please apply this
>> patch to druntime:
>>
>> http://www.dsource.org/projects/druntime/changeset?format=diff&new=262&old=260&new_path=trunk&old_path=trunk
>
> I have just added a small bug report, I don't know if this can interest you:
> http://d.puremagic.com/issues/show_bug.cgi?id=3933

The runtime cannot determine the location.  It's at runtime, not compile-time, so no file/line number info is available.  The compiler would have to instrument all allocations/calls to the runtime functions with line number arguments.

If a good debugger existed for dmd, you could determine the location, but I don't know of any good ones.  gdb doesn't do a very good job with D.

-Steve

On Thu, 11 Mar 2010 15:28:36 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Thu, 11 Mar 2010 15:20:38 -0500, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> Steven Schveighoffer:
>>> If you want to use the new release without the bugs, please apply this
>>> patch to druntime:
>>>
>>> http://www.dsource.org/projects/druntime/changeset?format=diff&new=262&old=260&new_path=trunk&old_path=trunk
>>
>> I have just added a small bug report, I don't know if this can interest you:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3933
>
> The runtime cannot determine the location.  It's at runtime, not compile-time, so no file/line number info is available.  The compiler would have to instrument all allocations/calls to the runtime functions with line number arguments.
>
> If a good debugger existed for dmd, you could determine the location, but I don't know of any good ones.  gdb doesn't do a very good job with D.

Also if we get exception stack trace support, then you can immediately see everything.  It's probably better to focus on that.

-Steve

Steven Schveighoffer:
> The compiler would have to instrument all allocations/calls to the runtime functions with line number arguments.

Do you suggest me to mark my bug report as Invalid then?

There's another similar bug report: http://d.puremagic.com/issues/show_bug.cgi?id=3851

Debuggers are useful, but is D designed to require a debugger during normal programming? If the answer is negative then I think having such error messages (and instrumentation) can be useful in non-release mode.

Having such error information only for the most common situations (like removing too many items from a dynamic array) is better than never have it.

Bye,
bearophile

Steven Schveighoffer:
> Also if we get exception stack trace support, then you can immediately see everything.  It's probably better to focus on that.

OK.
Do you want me to remove those two bug reports then?

Bye,
bearophile

On Thu, 11 Mar 2010 16:05:51 -0500, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>> Also if we get exception stack trace support, then you can immediately see
>> everything.  It's probably better to focus on that.
>
> OK.
> Do you want me to remove those two bug reports then?

I think they should at least be marked as enhancements.  Without a stacktrace printout, there is a need for such things.  But I think exception tracing is coming, I think Tango already has it.

-Steve

Steven Schveighoffer wrote:
> If a good debugger existed for dmd, you could determine the location, but I don't know of any good ones.  gdb doesn't do a very good job with D.

dmd has produced debugging information that makes gdb choke up for ages. This makes gdb (and some other utilities that try to read debugging infos) useless for D.

Is this gdb's or dmd's fault?

On Thu, 11 Mar 2010 16:14:36 -0500, grauzone <none@example.net> wrote:

> Steven Schveighoffer wrote:
>> If a good debugger existed for dmd, you could determine the location, but I don't know of any good ones.  gdb doesn't do a very good job with D.
>
> dmd has produced debugging information that makes gdb choke up for ages. This makes gdb (and some other utilities that try to read debugging infos) useless for D.
>
> Is this gdb's or dmd's fault?

Partly both.  gdb was not designed to work with D files, it was designed to work with C/C++ files.  Dmd has a -gc switch that is supposed to make the debug info "look" like C, but it doesn't always work.  For example, when debugging this problem, I had to resort to printf debugging, because I couldn't get a full backtrace from gdb.

I haven't tried integration with descent or other IDEs for a while, when I did use it, ddbg worked good (but always skipped over runtime functions, which is annoying when you are developing the runtime).  I hope that this problem eventually is solved.

-Steve

> I did use it, ddbg worked good (but always skipped over runtime functions, which is annoying when you are developing the runtime).  I hope that this problem eventually is solved.
>

Isn't ddbg totally abandoned?