www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Do not use 2.041

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Mar 11 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Mar 11 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Mar 11 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Mar 11 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Mar 11 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Mar 11 2010
next sibling parent Trass3r <un known.com> writes:
 stacktrace printout, there is a need for such things.  But I think  
 exception tracing is coming, I think Tango already has it.


Tango has it since a long time. Makes me wonder why it hasn't been ported  
to druntime, I thought the runtimes are quite similar.
Mar 11 2010
prev sibling parent reply Fawzi Mohamed <fawzi gmx.ch> writes:
On 11-mar-10, at 22:09, Steven Schveighoffer wrote:


 On Thu, 11 Mar 2010 16:05:51 -0500, bearophile =


<bearophileHUGS lycos.com=20

 wrote:



 Steven Schveighoffer:

 Also if we get exception stack trace support, then you can =20
 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 =20
 stacktrace printout, there is a need for such things.  But I think =20
 exception tracing is coming, I think Tango already has it.

 -Steve


Yes tango has it, there are a couple of things that are a bit clumsy, =20=

due to backward compatibility to previous implementations, but I think =20=

that the basic approach is sound:

- separate function to trace addresses from the ones to resolve them

- separate functions to find symbolic information, and those that =20
demangle it) from those that print it out

- try to avoid allocation (often the program is in a delicate spot =20
when a stacktrace is requested, one should try to avoid making the =20
position worse, and allocation in any case should be avoided when =20
possible).

  I am willing to give the code I wrote in whatever license is needed, =20=

but I have used parts of code by h3r3tic, wm4 (winterwar), and Thomas =20=

K=FChne, so if you want to use that code you should check also with =
them.

Fawzi=
Mar 11 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Fawzi Mohamed:

 Yes tango has it, there are a couple of things that are a bit clumsy,  
 due to backward compatibility to previous implementations, but I think  
 that the basic approach is sound:


A nice stack trace is a quite significant improvement when I program in D. It
helps solve problems in quite less time.
And I think in D2 backward compatibility can be broken, if you think it gives
some advantages.

Thank you,
bye,
bearophile
Mar 12 2010
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hnd8hr$1q6r$1 digitalmars.com...

 Fawzi Mohamed:

 Yes tango has it, there are a couple of things that are a bit clumsy,
 due to backward compatibility to previous implementations, but I think
 that the basic approach is sound:


 A nice stack trace is a quite significant improvement when I program in D. 
 It helps solve problems in quite less time.


Yup. Between recently discovering tango's stack-tracing for exceptions, and
the template instantition backtrace that was added to DMD not long ago, I'm
one very happy D camper :)
Mar 12 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Mar 11 2010
prev sibling next sibling parent reply grauzone <none example.net> writes:
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?
Mar 11 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Mar 11 2010
parent Trass3r <un known.com> writes:
 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?
Mar 11 2010
prev sibling next sibling parent Trass3r <un known.com> writes:
 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.


On Windows cv2pdb + Visual Studio works pretty damn well for me. Can't  
compare it to gdb though, since I haven't used that yet.
Mar 11 2010
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 11/03/10 20:28, 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.

 -Steve


I've never had a problem with GDB, it's always worked fine for me, for 
everything I've used (including arrays, templates etc). Admittedly, I've 
only ever used a patched version of gdb with the D patches from 
http://dsource.org/projects/gdb-patches/, so it's far better equipped 
than a default gdb install. I've mainly used it with ldc/tango, I don't 
know how well dmd works with it though. I'm also guessing a lot of the 
D2 features aren't handled, I don't know though.
Mar 11 2010
prev sibling parent Trass3r <un known.com> writes:
 Note to everyone, dmd 2.041 array allocation is broken (inadvertently by  
 my array append patch).  You should not use this release.


Another big problem of the release is operator overloading.
Mar 11 2010