Do not use 2.041
On Mon, 08 Mar 2010 01:54:12 -0500, Walter Bright newshou...@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=diffnew=262old=260new_path=trunkold_path=trunk Sorry for this, I hope a new release will come soon. -Steve
Re: Do not use 2.041
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=diffnew=262old=260new_path=trunkold_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
Re: Do not use 2.041
On Thu, 11 Mar 2010 15:20:38 -0500, bearophile bearophileh...@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=diffnew=262old=260new_path=trunkold_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
Re: Do not use 2.041
On Thu, 11 Mar 2010 15:28:36 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: On Thu, 11 Mar 2010 15:20:38 -0500, bearophile bearophileh...@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=diffnew=262old=260new_path=trunkold_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
Re: Do not use 2.041
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
Re: Do not use 2.041
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
Re: Do not use 2.041
On Thu, 11 Mar 2010 16:05:51 -0500, bearophile bearophileh...@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
Re: Do not use 2.041
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?
Re: Do not use 2.041
On Thu, 11 Mar 2010 16:14:36 -0500, grauzone n...@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
Re: Do not use 2.041
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?
Re: Do not use 2.041
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.
Re: Do not use 2.041
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.
Re: Do not use 2.041
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.
Re: Do not use 2.041
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.
Announcing bugzilla for dmdscript
Both C++ and D versions: http://bugzilla.digitalmars.com/issues/
Re: Do not use 2.041
On 11-mar-10, at 22:09, Steven Schveighoffer wrote: On Thu, 11 Mar 2010 16:05:51 -0500, bearophile bearophileh...@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 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: - separate function to trace addresses from the ones to resolve them - separate functions to find symbolic information, and those that demangle it) from those that print it out - try to avoid allocation (often the program is in a delicate spot when a stacktrace is requested, one should try to avoid making the position worse, and allocation in any case should be avoided when possible). I am willing to give the code I wrote in whatever license is needed, but I have used parts of code by h3r3tic, wm4 (winterwar), and Thomas Kühne, so if you want to use that code you should check also with them. Fawzi
