On Nov 9, 2012, at 11:38 PM, Walter Bright <walter@digitalmars.com> wrote:

> 
> On 11/9/2012 10:10 PM, David Held wrote:
>> Relying on the debugger to tell you where something went wrong is pretty ghetto, IMO.  For instance, the debugger makes all of the commented-out printfs() in the code also redundant, and yet I see thousands of these.  So which is it...should the compiler give you diagnostic information, or should you rely on the debugger?  Since we're on this topic, let's then switch it to the nature of diagnostics in dmd.
> 
> I'll often use printf because although the debugger knows types, it rarely shows the values in a form I particularly need to track down a problem, which tends to be different every time. And besides, throwing in a few printfs is fast and easy, whereas setting break points and stepping through a program is an awfully tedious process. Or maybe I never learned to use debugger properly, which is possible since I've been forced to debug systems where no debugger whatsoever was available - I've even debugged programs using an oscilloscope, making clicks on a speaker, blinking an LED, whatever is available.

The only issue with printf debugging is that it requires a new build, and possible more builds as printfs are tweaked to narrow down the problem, and this is not always feasible.  Also, a debugger can attach to a running process, so reproducibility within a dev setup isn't always required, which can be a bonus.  But I've fixed plenty of bugs using log output alone.  It depends on the situation.

>> One of my TODO items was to take the commented-out printfs and turn them into a first-class logging solution with configurable log levels/modules/etc. (so you can turn on logging in just one subsystem if you want).  If the reigning philosophy is instead to lean on the debugger, then that would be a waste of time.  What do y'all think?
> 
> I've tried that (see the LOG macros in template.c). It doesn't work very well, because the logging data tends to be far too voluminous. I like to tailor it to each specific problem. It's faster for me, and works.

grep is a wonderful thing :-)
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Nov 11, 2012, at 4:41 AM, Leandro Lucarella <luca@llucax.com.ar> wrote:

> David Held, el  9 de November a las 22:41 me escribiste:
>> 
>> Finally, what the debugger cannot do is provide you with a history of what happened, except insofar as you are willing to manually capture the state change of various memory locations as you step through the program.
> 
> Well, then I guess you don't know gdb's reverse debugging :D http://sourceware.org/gdb/news/reversible.html

The first demo I saw of this was the Asymetrix C++ debugger back in the mid 90s.  A pretty cool idea, though I've never actually felt I needed it.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Nov 11, 2012, at 11:50 AM, Walter Bright <walter@digitalmars.com> wrote:
> 
> I object to the following pattern:
> 
>     assert(p != NULL);
>     *p = ...;
> 
> i.e. dereferencing p shortly after checking it for null. This, to me, is utterly pointless in dmd. If, however,
> 
>    assert(p != NULL);
>    s->field = p;
> 
> and no dereference is done, then that has merit.

It may not be a big deal in DMD because it's historically been an app with one contributor.  But once multiple people are involved, well, I'm sure I don't have to sell you on contract programming since it's a feature in D.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Nov 27, 2012, at 4:54 PM, Sean Kelly <sean@invisibleduck.org> wrote:

> On Nov 11, 2012, at 4:41 AM, Leandro Lucarella <luca@llucax.com.ar> wrote:
> 
>> David Held, el  9 de November a las 22:41 me escribiste:
>>> 
>>> Finally, what the debugger cannot do is provide you with a history of what happened, except insofar as you are willing to manually capture the state change of various memory locations as you step through the program.
>> 
>> Well, then I guess you don't know gdb's reverse debugging :D http://sourceware.org/gdb/news/reversible.html
> 
> The first demo I saw of this was the Asymetrix C++ debugger back in the mid 90s.  A pretty cool idea, though I've never actually felt I needed it.

I've done a lot of monte carlo based stuff where an it could take an hour to reproduce a problem. I've wanted to go backwards once I captured a bug, but have never had the luxury of being able to do that.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals