www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bug or plain misunderstanding?

reply "Bob W" <nospam aol.com> writes:
Hi,

after a couple of months of absence from D and
this forum, I am officially still busy reducing
the backlog of work I was accumulating due to
some unforeseen events. So please don't tell
anybody I was here!

D seems to be thriving and is probably right on
track - my old programs still compile with 0.145.

However, I have noticed one little dmd behaviour,
which I was not expecting:

When warnings are enabled with '-w' and if
the program contains unreachable code (e.g.
due to a casual insertion of a return statement
for debugging purposes), the compiler will
issue the proper warning but it will not
generate any code (i.e. exe file).

Should I understand the compiler usage info
"-w ... enable warnings" as
"-w ... enable warnings and treat them as errors"
or is this compiler behaviour unintentional?


For further clarification I have included this
little demo program:



///////////////////////////////////////////////////////////
//
// Possible bug in dmd 0.145:
//
// When attempting to disable a portion of code with an
// early return statement, dmd properly issues a warning
// if the program is compiled with '-w'.
// But it apparently treats the warning as an error, so
// it does not generate any code. If '-w' is omitted,
// everything works as expected.
//
///////////////////////////////////////////////////////////


import std.stdio;


int main() {
  writefln();
  writefln("Sample program demonstrating '-w' bug:");
  writefln();

/*
  // Uncomment this section and compile program with '-w'
  // to experience warning without code generation.
  // (You might want to erase an eventually existing old
  // .exe file first in order to verify this.)

  writefln("Attempt to stop program after this message.");
  return(0);  // <<<< stop the nonsense here!
*/

  writefln();
  transfertoSCO();
  installMSDOS();
  emailCongrats();
  return(0);
}


void transfertoSCO() {
  writefln("    Donating $100 000 to SCO Group Inc ...");
  /* sophisticated code goes here */
  writefln("... debiting Mr. Torvalds' bank account ...");
  /* sophisticated code goes here */
  writefln("... transaction successfully completed.");
  writefln();  writefln();
}

void installMSDOS() {
  writefln("    Erasing Windows XP and/or Linux ...");
  /* sophisticated code goes here */
  writefln("... installing MSDOS 2.01 ...");
  /* sophisticated code goes here */
  writefln("... MSDOS successfully installed.");
  writefln();  writefln();
}

void emailCongrats() {
  writefln("    Preparing email to GWB ...");
  /* sophisticated code goes here */
  writefln("... 'congrats to success finding WMD' ...");
  /* sophisticated code goes here */
  writefln("... attempting to send email ...");
  writefln("... reply from operating system:");
  writefln("    what is 'email' ???");
  writefln("    Abort, Retry, Fail?");
  writefln();  writefln();
}
Feb 05 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 06 Feb 2006 06:38:50 +1100, Bob W <nospam aol.com> wrote:

 Hi,

 after a couple of months of absence from D and
 this forum, I am officially still busy reducing
 the backlog of work I was accumulating due to
 some unforeseen events. So please don't tell
 anybody I was here!

 D seems to be thriving and is probably right on
 track - my old programs still compile with 0.145.

 However, I have noticed one little dmd behaviour,
 which I was not expecting:

 When warnings are enabled with '-w' and if
 the program contains unreachable code (e.g.
 due to a casual insertion of a return statement
 for debugging purposes), the compiler will
 issue the proper warning but it will not
 generate any code (i.e. exe file).

 Should I understand the compiler usage info
 "-w ... enable warnings" as
 "-w ... enable warnings and treat them as errors"
 or is this compiler behaviour unintentional?

As far as Walter is concerned, a 'warning' is really an error too. So yes, DMD will display warnings but treat them as errors such that the compiler doesn't generate code. -- Derek Parnell Melbourne, Australia
Feb 05 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s4imylg86b8z09 ginger.vic.bigpond.net.au...
 As far as Walter is concerned, a 'warning' is really an error too. So yes, 
 DMD will display warnings but treat them as errors such that the compiler 
 doesn't generate code.

That's right. If the programmer cares about warnings, he'll want them to be treated as errors. Otherwise, the warning message could scroll up and all too easilly be overlooked.
Feb 05 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 06 Feb 2006 07:34:37 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s4imylg86b8z09 ginger.vic.bigpond.net.au...
 As far as Walter is concerned, a 'warning' is really an error too. So  
 yes,
 DMD will display warnings but treat them as errors such that the  
 compiler
 doesn't generate code.

That's right. If the programmer cares about warnings, he'll want them to be treated as errors. Otherwise, the warning message could scroll up and all too easilly be overlooked.

However, not everyone thinks like Walter. I, for example, regard a warning as different from an error. A warning tells me about a issue that the compiler has had to make an assumption in order to generate code. An error tells me about an issue that the compiler has decided that there are no assumptions that can be made and thus it can't generate valid code. A warning alerts me to the fact that the compiler has made an assumption on my behalf and thus I might want to do something to avoid a 'wrong' compiler assumption. These assumptions are not, per se, errors. Thus if "-w" is not used the compiler generates code and so I can't see why the compiler still can't generate code when "-w" is used. All I want to know is where the compiler has assumed things I didn't actually intend. -- Derek Parnell Melbourne, Australia
Feb 05 2006
next sibling parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:op.s4iq6vrk6b8z09 ginger.vic.bigpond.net.au...
 On Mon, 06 Feb 2006 07:34:37 +1100, Walter Bright
 <newshound digitalmars.com> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s4imylg86b8z09 ginger.vic.bigpond.net.au...
 As far as Walter is concerned, a 'warning' is really an error too. So
 yes,
 DMD will display warnings but treat them as errors such that the
 compiler
 doesn't generate code.

That's right. If the programmer cares about warnings, he'll want them to be treated as errors. Otherwise, the warning message could scroll up and


 too easilly be overlooked.

However, not everyone thinks like Walter. I, for example, regard a warning as different from an error. A warning tells me about a issue that the compiler has had to make an assumption in order to generate code. An error tells me about an issue that the compiler has decided that there are no assumptions that can be made and thus it can't generate valid code. A warning alerts me to the fact that the compiler has made an assumption on my behalf and thus I might want to do something to avoid a 'wrong' compiler assumption. These assumptions are not, per se, errors. Thus if "-w" is not used the compiler generates code and so I can't see why the compiler still can't generate code when "-w" is used. All I want to know is where the compiler has assumed things I didn't actually intend.

Pretty much agree. There should be a complementary "warnings as errors" flag as well. Walter's sentiments are agreeable when one is dealing with production builds, under which only a fool would not invoke "warnings as errors", but when experimenting, or working on something new, or inserting returns for debugging (something Walter strongly advocates, btw), or myriad other "messing around" purposes, it's going to be more hindrance than help. Sorry to start off the week with an insult, but this is another instance where Walter's personal prejudices impact negatively on the "sensibleness" of the language/compiler.
Feb 05 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

 Walter's sentiments are agreeable when one is dealing with production
 builds, under which only a fool would not invoke "warnings as errors", but
 when experimenting, or working on something new, or inserting returns for
 debugging (something Walter strongly advocates, btw), or myriad other
 "messing around" purposes, it's going to be more hindrance than help.

Phobos doesn't use warnings, though ? (i.e. doesn't compile with -w) I used to ship some of my libraries with a CFLAGS of "-Wall -Werror", but it only seemed to trip on the *system* headers on the client end and made the library less portable in the end. So I changed to -Wall. --anders
Feb 06 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Anders F BjŲrklund" <afb algonet.se> wrote in message
news:ds7mir$30tk$1 digitaldaemon.com...
 Matthew wrote:

 Walter's sentiments are agreeable when one is dealing with production
 builds, under which only a fool would not invoke "warnings as errors",


 when experimenting, or working on something new, or inserting returns


 debugging (something Walter strongly advocates, btw), or myriad other
 "messing around" purposes, it's going to be more hindrance than help.

Phobos doesn't use warnings, though ? (i.e. doesn't compile with -w)

LOL! I didn't know that. I'm still waiting for Walter to explain the paradox between the bug-finding activities that he recommends to just about everyone that ever raises a compiler problem and not being able to generate code and link with something that emits a warning. (I may be waiting some time ...)
Feb 06 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:ds8jkh$qf8$1 digitaldaemon.com...
 I'm still waiting for Walter to explain the paradox between the 
 bug-finding
 activities that he recommends to just about everyone that ever raises a
 compiler problem and not being able to generate code and link with 
 something
 that emits a warning. (I may be waiting some time ...)

If you can show an example where being able to execute code that generates a warning will make the cause of the warning less mysterious, I'd be very interested.
Feb 06 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:ds8lvv$s2k$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds8jkh$qf8$1 digitaldaemon.com...
 I'm still waiting for Walter to explain the paradox between the
 bug-finding
 activities that he recommends to just about everyone that ever raises a
 compiler problem and not being able to generate code and link with
 something
 that emits a warning. (I may be waiting some time ...)

If you can show an example where being able to execute code that generates

 warning will make the cause of the warning less mysterious, I'd be very
 interested.

Are you affecting obtuseness as a means of stimulating debate for the people reading but not participating? (Not rhetoric. I'm genuinely confused.) Anway, here's the situation as I see it, as I can most plainly express it: 1. You recommend that people chop down code in order to isolate bugs. Such bugs can include compile-time and runtime bugs. 2. You offer a compiler that does not allow a user to generate code while observing warnings. These two are in obvious conflict. Anyone with any problem compiling any compiled-language will, in following your stipulation to the chop-and-test approach, have to remove code. Those with a version control system, a huge Undo buffer and perfect faith in their IDDE not to crash may genuinely _remove_ code. Those more careful/careworn might instead put in an early return statement here and there. Since the last thing one wants to do when debugging is to introduce new bugs, such users might sensibly wish to continue to be informed of potential problems by having their compiler emit as many warnings as it can. This is so obvious to anyone that's ever even touched the hem of a debugger that no example should be necessary. I'm left grasping for a credible explanation as to why you suggest one is necessary, other than perhaps to try and wear me down in fatuous effort. Please point out the flaw in my reasoning of your paradox, and, further, explain to me how, in following this technique in many circumstances where debugging has been necessitated in C/C++/D/Ruby/Java/.NET, I have gone so astray in my practice. What should I have been doing instead? This is not rhetoric for the sake of it: please do elucidate. If you cannot, please explain how DMD's current contradiction of 1 and 2 is not an arbitrary shackle to its users, one based solely on your own work practices and prejudices that, I hope, you would have to concede may not map to those of all other developers.
Feb 06 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
I'm not sure I see the problem.  Since the warnings mode is optional, 
what's to stop you from building with warnings until you fix everything 
it flags that you care about then turn the option off and build to test?

My only issue is that with "warnings as errors" as the only 
warnings-enabled option, there must be a code-level way to fix anything 
the compiler warns about.  Otherwise, shops that build with warnings 
enabled as the release mode would be SOL if the compiler warns about 
something intended.

This is typically how I do things with VC++: require no messages at WL:4 
and preprocessor directives to situationally disable any warnings about 
utterly stupid things (like the "standard function is deprecated" 
business in VC 2005).  Things like implicit narrowing conversions are 
flagged by the compiler and casts are added where appropriate, etc.  To 
me, fixing warnings is mostly a matter of either fixing the bug or 
telling the compiler "yes, I meant to do that."  I can't think of a 
situation where I'd want to ship with some warning messages still 
displaying, assuming I cared enough to enable them.


Sean
Feb 06 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:ds927o$156u$1 digitaldaemon.com...
 I'm not sure I see the problem.  Since the warnings mode is optional,
 what's to stop you from building with warnings until you fix everything
 it flags that you care about then turn the option off and build to test?

 My only issue is that with "warnings as errors" as the only
 warnings-enabled option, there must be a code-level way to fix anything
 the compiler warns about.  Otherwise, shops that build with warnings
 enabled as the release mode would be SOL if the compiler warns about
 something intended.

 This is typically how I do things with VC++: require no messages at WL:4
 and preprocessor directives to situationally disable any warnings about
 utterly stupid things (like the "standard function is deprecated"
 business in VC 2005).  Things like implicit narrowing conversions are
 flagged by the compiler and casts are added where appropriate, etc.  To
 me, fixing warnings is mostly a matter of either fixing the bug or
 telling the compiler "yes, I meant to do that."  I can't think of a
 situation where I'd want to ship with some warning messages still
 displaying, assuming I cared enough to enable them.

You're replied on my last post, but none of this seems to address anything I raised. Did you reply on the wrong part? If this is a reply to my post, then I'm stumped. I cannot express my point - that seems to me to be one of the most obvious things ever discussed on this NG - any more clearly. Maybe I just have to assume I'm mad. (Not entirely without potential, as a hypothesis.) For the record, I'm not talking about shipping with warnings still firing. That's madness to do, and I suspect my opinion on that, and practice in not doing so, to be identical to your own. (Interestingly, regarding the reluctance to allow compiler flags for warning suppression: the only warnings I ever get, and which I am dangerously forced to ignore wholesale, are from linkers, since there seems to be no mechanism to advise them to selectively shut up. I know that's only real world C and C++ experience, and therefore of little consequence to the Decision-making process, but I think it makes its point pretty clearly.) Anyway, my entire point is tightly focused on the contradiction between Walter's stock technique for debugging, which he advises all comers to adopt whenever they report a problem, and the restrictions imposed by the DMD compiler that directly defeat that advice. I await that point being addressed, rather than some deflectory digression, with exteme patience. :-)
Feb 06 2006
parent Sean Kelly <sean f4.ca> writes:
Matthew wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
 news:ds927o$156u$1 digitaldaemon.com...
 I'm not sure I see the problem.  Since the warnings mode is optional,
 what's to stop you from building with warnings until you fix everything
 it flags that you care about then turn the option off and build to test?

 My only issue is that with "warnings as errors" as the only
 warnings-enabled option, there must be a code-level way to fix anything
 the compiler warns about.  Otherwise, shops that build with warnings
 enabled as the release mode would be SOL if the compiler warns about
 something intended.

 This is typically how I do things with VC++: require no messages at WL:4
 and preprocessor directives to situationally disable any warnings about
 utterly stupid things (like the "standard function is deprecated"
 business in VC 2005).  Things like implicit narrowing conversions are
 flagged by the compiler and casts are added where appropriate, etc.  To
 me, fixing warnings is mostly a matter of either fixing the bug or
 telling the compiler "yes, I meant to do that."  I can't think of a
 situation where I'd want to ship with some warning messages still
 displaying, assuming I cared enough to enable them.

You're replied on my last post, but none of this seems to address anything I raised. Did you reply on the wrong part?

No, but perhaps this was somewhat of a tangent. I was mostly suggesting that you compile with warnings on to ensure no new errors are introduced, and if you still can't produce a linkable object for some reason then turn warnings off and make sure the run-time bug still exists. Warnings are optional, after all.
 For the record, I'm not talking about shipping with warnings still firing.
 That's madness to do, and I suspect my opinion on that, and practice in not
 doing so, to be identical to your own.

I actually do release builds with warnings enabled for shipping applications, but the warnings I'm used to are compile-time ones. If D has run-time warnings, that's new to me (I've never actually used "-w" in D--shame on me). To me, the benefit of warnings is to point out potential coding mistakes that are syntactically valid--implicit narrowing conversions being the big one IMO--and to do so at compile-time.
 Anyway, my entire point is tightly focused on the contradiction between
 Walter's stock technique for debugging, which he advises all comers to adopt
 whenever they report a problem, and the restrictions imposed by the DMD
 compiler that directly defeat that advice. I await that point being
 addressed, rather than some deflectory digression, with exteme patience.

I apologize. I think I'm simply missing the point. Sean
Feb 07 2006
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 7 Feb 2006 13:32:40 +1100, Matthew <matthew hat.stlsoft.dot.org>  
wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:ds8lvv$s2k$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds8jkh$qf8$1 digitaldaemon.com...
 I'm still waiting for Walter to explain the paradox between the
 bug-finding
 activities that he recommends to just about everyone that ever raises  

 compiler problem and not being able to generate code and link with
 something
 that emits a warning. (I may be waiting some time ...)

If you can show an example where being able to execute code that generates a warning will make the cause of the warning less mysterious, I'd be very interested.

Are you affecting obtuseness as a means of stimulating debate for the people reading but not participating? (Not rhetoric. I'm genuinely confused.) Anway, here's the situation as I see it, as I can most plainly express it: 1. You recommend that people chop down code in order to isolate bugs. Such bugs can include compile-time and runtime bugs. 2. You offer a compiler that does not allow a user to generate code while observing warnings. These two are in obvious conflict. Anyone with any problem compiling any compiled-language will, in following your stipulation to the chop-and-test approach, have to remove code. Those with a version control system, a huge Undo buffer and perfect faith in their IDDE not to crash may genuinely _remove_ code.

Or copy the file(s) involved and chop the cop(y|ies).
 Those more careful/careworn might instead put in an early
 return statement here and there. Since the last thing one wants to do  
 when
 debugging is to introduce new bugs, such users might sensibly wish to
 continue to be informed of potential problems by having their compiler  
 emit as many warnings as it can.

True, but not strictly required to produce a test case. Regan
Feb 06 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
 Anway, here's the situation as I see it, as I can most plainly express
 it:

 1. You recommend that people chop down code in order to isolate bugs.
 Such bugs can include compile-time and runtime bugs.

 2. You offer a compiler that does not allow a user to generate code


 observing warnings.

 These two are in obvious conflict. Anyone with any problem compiling any
 compiled-language will, in following your stipulation to the
 chop-and-test
 approach, have to remove code. Those with a version control system, a
 huge Undo buffer and perfect faith in their IDDE not to crash may
 genuinely
 _remove_ code.

Or copy the file(s) involved and chop the cop(y|ies).

Indeed. But I think you'd agree that that adds considerable overhead on to what is usually a very chop intensive activity. chop-and-test is itself a horrible arduous task. To have to be making potentially 10s or even 100s of copies of a given file, and keeping track of what changes go where, is going to turn it into a really time-consuming and horrible arduous task. I don't want to always be coming across as this nasty sarcastic English cynic, who just refuses to buy into the Dream, but D is, for one thing, touted as being superior in productivity to C/C++. And then Walter imposes restrictions on the dominant (and largely defining) compiler based on two things: his needs/wants/experience as a compiler writer, and his experience/practices as a C/C++ coder. While I have huge respect for his achievements in both these fields, they do not represent *all* knowledge/experience/practice (nor even the best, perhaps). _In this particular case_, Walter's ideas/prejudices/whatever are a complete contradiction of the claims of D, hindering rather than helpful. As my mother always said (and continues to say) to me: "Watch that hubris".
 Those more careful/careworn might instead put in an early
 return statement here and there. Since the last thing one wants to do
 when
 debugging is to introduce new bugs, such users might sensibly wish to
 continue to be informed of potential problems by having their compiler
 emit as many warnings as it can.

True, but not strictly required to produce a test case.

Not at all. There are many ways. But why proscribe a more productive one for less productive ones in the name of one person's practice. And, before anyone says it, Yes, I know it's Walter's language, and he can do what he likes. My radical hypothesis is that by facilitating the (different) practices of other developers, more developers are likely to be attracted to the language.
Feb 06 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:ds9b89$1bq2$1 digitaldaemon.com...
 Or copy the file(s) involved and chop the cop(y|ies).

what is usually a very chop intensive activity. chop-and-test is itself a horrible arduous task.

??
 To have to be making potentially 10s or even 100s of
 copies of a given file,

No need for more than two. I have to wonder what you are doing.
 and keeping track of what changes go where,

No need for that. It's a binary thing - does this chop make the problem disappear or the problem stay? If it stays, forget about the previous changes. If it goes away, copy the previous version back and chop something else. No need to keep a 'stack' of more than one change.
 is going to turn it into a really time-consuming and horrible arduous 
 task.

If it is, you're going about it inefficiently. I use an editor that automatically makes a backup copy when I save an editted file. Then, if the edit is unsuccessful, I just copy the backup copy back over the editted copy. Nothing arduous.
Feb 06 2006
next sibling parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:ds9dn9$1ddr$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds9b89$1bq2$1 digitaldaemon.com...
 Or copy the file(s) involved and chop the cop(y|ies).



 what is usually a very chop intensive activity. chop-and-test is itself


 horrible arduous task.

??
 To have to be making potentially 10s or even 100s of
 copies of a given file,

No need for more than two. I have to wonder what you are doing.
 and keeping track of what changes go where,

No need for that. It's a binary thing - does this chop make the problem disappear or the problem stay? If it stays, forget about the previous changes. If it goes away, copy the previous version back and chop

 else. No need to keep a 'stack' of more than one change.

 is going to turn it into a really time-consuming and horrible arduous
 task.

If it is, you're going about it inefficiently. I use an editor that automatically makes a backup copy when I save an editted file. Then, if the edit is unsuccessful, I just copy the backup

 back over the editted copy. Nothing arduous.

I'd love to be able to poo-poo your statements as laughable fantasy, but I have no doubt that you believe what you're saying and that you're speaking the truth about your own experiences. What continues to sadden me is the apparent narrow-mindedness in that you project a certain belief that your experiences are enough of a sample to make pronouncements and direct tool strategy for everyone else. I can tell you that there are plenty of times when a binary approach such as you describe has not proved enough for me, perhaps as a consequence of my working with non-trivial C++ code (templates, etc.). There are often instances where a combinatorial effect on the compiler cannot be reduced in the manner you describe, and many more where the effort involved to bring everything in one file is far more than necessary compared with modifying several in parallel. I know you don't believe me about that, but that doesn't make it not so. Perhaps the answer is that I should not have the temerity to stretch the language to it's limits? But I think not. I continue to support DMC++ and D and you personally, and I want all to prosper highly, but you do seem to live in a world that does not relate to me and my experiences, and I am not yet sufficiently deluded to believe that I'm unique. Common sense therefore compels me to think that you have an overly narrow and prescriptive view of software engineering, and that that influences the progress of D to its detriment. Matthew btw, I use chop-and-test, and recognise it's value without reservation. But the same applies for flossing one's teeth. Doesn't stop either from being a vile activity. None of which has much if anything to do with my specific point, to which I continue to await any response.
Feb 07 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:ds9tq1$1r8n$1 digitaldaemon.com...
 I'd love to be able to poo-poo your statements as laughable fantasy, but I
 have no doubt that you believe what you're saying and that you're speaking
 the truth about your own experiences. What continues to sadden me is the
 apparent narrow-mindedness in that you project a certain belief that your
 experiences are enough of a sample to make pronouncements and direct tool
 strategy for everyone else.

 I can tell you that there are plenty of times when a binary approach such 
 as
 you describe has not proved enough for me, perhaps as a consequence of my
 working with non-trivial C++ code (templates, etc.). There are often
 instances where a combinatorial effect on the compiler cannot be reduced 
 in
 the manner you describe, and many more where the effort involved to bring
 everything in one file is far more than necessary compared with modifying
 several in parallel.
 I know you don't believe me about that, but that
 doesn't make it not so.

I know that you find this to not work, and you've often sent me those cases. None of them resisted reduction to a few lines. I've been working on solving template related bugs for 10 years :-(. At the end of the process, each and every one of the minimal examples goes into the DMC++ test suite, so I have quite an extensive test suite (maybe a thousand examples just for templates). Every one was reduced using the process I described, and they are all just a few lines of code. And, as a pretty general rule, none of the problems made any sense until they were so reduced, and they often did start out as incomprehensibly complex templates. There is a very solid factual basis for what I said works in isolating problems. The proof is not only in the DMC++ (and DMD) test suite, but in the irreducible cases you sent me that I reduced and sent back. If you want to dismiss such a successful track record, including success on your cases, as laughable fantasy, what can I say? P.S. I might uselessly add that none of this was aided or hindered by -w.
Feb 07 2006
parent "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsancf$2k92$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds9tq1$1r8n$1 digitaldaemon.com...
 I'd love to be able to poo-poo your statements as laughable fantasy, but


 have no doubt that you believe what you're saying and that you're


 the truth about your own experiences. What continues to sadden me is the
 apparent narrow-mindedness in that you project a certain belief that


 experiences are enough of a sample to make pronouncements and direct


 strategy for everyone else.

 I can tell you that there are plenty of times when a binary approach


 as
 you describe has not proved enough for me, perhaps as a consequence of


 working with non-trivial C++ code (templates, etc.). There are often
 instances where a combinatorial effect on the compiler cannot be reduced
 in
 the manner you describe, and many more where the effort involved to


 everything in one file is far more than necessary compared with


 several in parallel.
 I know you don't believe me about that, but that
 doesn't make it not so.

I know that you find this to not work, and you've often sent me those

 None of them resisted reduction to a few lines.

More assumption: that I've needed to consult you on all the cases that I've found, and that I've done so in all cases. Neither of these is true.
 I've been working on solving template related bugs for 10 years :-(. At

 end of the process, each and every one of the minimal examples goes into

 DMC++ test suite, so I have quite an extensive test suite (maybe a

 examples just for templates). Every one was reduced using the process I
 described, and they are all just a few lines of code.

None of that has the slightest relation to my point.
 And, as a pretty general rule, none of the problems made any sense until
 they were so reduced, and they often did start out as incomprehensibly
 complex templates.

 There is a very solid factual basis for what I said works in isolating
 problems. The proof is not only in the DMC++ (and DMD) test suite, but in
 the irreducible cases you sent me that I reduced and sent back. If you

 to dismiss such a successful track record, including success on your

 as laughable fantasy, what can I say?

Another furphy again. I don't poo-poo your track record. I point out that your software engineering is not monotonic, corresponding to only your experiences/opinions/practices, and that this detracts from D's general appeal and raises several manifest contradictions with your stated aims for D. Seems that several others are pointing that out now, so I'll leave it before it degenerates any further.
Feb 08 2006
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 6 Feb 2006 21:55:56 -0800, Walter Bright wrote:

 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
 news:ds9b89$1bq2$1 digitaldaemon.com...
 Or copy the file(s) involved and chop the cop(y|ies).

what is usually a very chop intensive activity. chop-and-test is itself a horrible arduous task.

??
 To have to be making potentially 10s or even 100s of
 copies of a given file,

No need for more than two. I have to wonder what you are doing.
 and keeping track of what changes go where,

No need for that. It's a binary thing - does this chop make the problem disappear or the problem stay? If it stays, forget about the previous changes. If it goes away, copy the previous version back and chop something else. No need to keep a 'stack' of more than one change.
 is going to turn it into a really time-consuming and horrible arduous 
 task.

If it is, you're going about it inefficiently. I use an editor that automatically makes a backup copy when I save an editted file. Then, if the edit is unsuccessful, I just copy the backup copy back over the editted copy. Nothing arduous.

I'm backing Walter's case here. Although doing the chop-retest can be boring to do, there is no need to make it hard to do and it always seems to give you a small code example of the bug. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 8/02/2006 11:56:49 AM
Feb 07 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:ds90n7$1411$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:ds8lvv$s2k$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds8jkh$qf8$1 digitaldaemon.com...
 I'm still waiting for Walter to explain the paradox between the
 bug-finding
 activities that he recommends to just about everyone that ever raises a
 compiler problem and not being able to generate code and link with
 something
 that emits a warning. (I may be waiting some time ...)

generates a warning will make the cause of the warning less mysterious, I'd be very interested.

people reading but not participating? (Not rhetoric. I'm genuinely confused.)

I genuinely have no idea what the problem is you're talking about.
 Anway, here's the situation as I see it, as I can most plainly express it:
 1. You recommend that people chop down code in order to isolate bugs. Such
 bugs can include compile-time and runtime bugs.
 2. You offer a compiler that does not allow a user to generate code while
 observing warnings.

 These two are in obvious conflict.

No, they aren't. If the person doesn't understand why the warning is being generated, executing the code won't help in the slightest. If it isn't about the warning, just turn off warnings. Turning off the warnings isn't any more work than turning on "warn but keep going".
 Anyone with any problem compiling any
 compiled-language will, in following your stipulation to the chop-and-test
 approach, have to remove code.

You write as if there's something wrong with the chop and test approach, or that it's something unique. It's not unique (it's taught at better universities). It's a generally and widely used problem solving technique, also known as divide-and-conquer. And it's the only one that has a reasonable chance of success with a complex system. I've spent 30 years in engineering, and those people who do not know how to reduce the problem domain spent hours, days, *months* futzing about chasing phantoms, wasting time, trying things essentially at random, and never figuring out what's going wrong.
 Those with a version control system, a huge
 Undo buffer and perfect faith in their IDDE not to crash may genuinely
 _remove_ code. Those more careful/careworn might instead put in an early
 return statement here and there. Since the last thing one wants to do when
 debugging is to introduce new bugs, such users might sensibly wish to
 continue to be informed of potential problems by having their compiler 
 emit
 as many warnings as it can.

The way to do chop-and-test is to make a copy of your project, and work from the copy. Or at least make a full backup first. If you do not make a copy first, you are nearly guaranteed to screw up your source code, whether or not you are using CVS or have undo buffers. Warnings aren't going to help in the slightest. There's no reason whatsoever to worry about introducing new bugs doing this. If you are in a position where you are somehow unable to back up your project or work from a copy of it, then for whatever reason you've completely lost control over the project and have much bigger problems than warnings.
 Please point out the flaw in my reasoning of your paradox, and, further,
 explain to me how, in following this technique in many circumstances where
 debugging has been necessitated in C/C++/D/Ruby/Java/.NET, I have gone so
 astray in my practice. What should I have been doing instead?

Make a full copy of your project, and work from that.
 This is not
 rhetoric for the sake of it: please do elucidate. If you cannot, please
 explain how DMD's current contradiction of 1 and 2 is not an
 arbitrary shackle to its users,

You're worried about screwing up your project by applying divide-and-conquer, so you want warnings to continue. That is a misunderstanding of how to go about it. Make a copy of your project. Then hack and slash the copy until you've isolated the problem. Turn off the warnings. Stop worrying about introducing a bug - it's a sacrificial copy, not the original.
 one based solely on your own work practices and prejudices that,
 I hope, you would have to concede may not map to those of all other 
 developers.

Trying to use warnings as a substitute for making a backup is like a carpenter trying to hammer a nail with a screwdriver. It's the wrong answer, and trying to make a screwdriver that can be used as a hammer is also the wrong answer.
Feb 06 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:ds9a6g$1b2m$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds90n7$1411$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:ds8lvv$s2k$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds8jkh$qf8$1 digitaldaemon.com...
 I'm still waiting for Walter to explain the paradox between the
 bug-finding
 activities that he recommends to just about everyone that ever raises




 compiler problem and not being able to generate code and link with
 something
 that emits a warning. (I may be waiting some time ...)

generates a warning will make the cause of the warning less mysterious, I'd be very interested.

people reading but not participating? (Not rhetoric. I'm genuinely confused.)

I genuinely have no idea what the problem is you're talking about.
 Anway, here's the situation as I see it, as I can most plainly express


 1. You recommend that people chop down code in order to isolate bugs.


 bugs can include compile-time and runtime bugs.
 2. You offer a compiler that does not allow a user to generate code


 observing warnings.

 These two are in obvious conflict.

No, they aren't. If the person doesn't understand why the warning is being generated, executing the code won't help in the slightest. If it isn't

 the warning, just turn off warnings. Turning off the warnings isn't any

 work than turning on "warn but keep going".

 Anyone with any problem compiling any
 compiled-language will, in following your stipulation to the


 approach, have to remove code.

You write as if there's something wrong with the chop and test approach,

 that it's something unique. It's not unique (it's taught at better
 universities). It's a generally and widely used problem solving technique,
 also known as divide-and-conquer. And it's the only one that has a
 reasonable chance of success with a complex system. I've spent 30 years in
 engineering, and those people who do not know how to reduce the problem
 domain spent hours, days, *months* futzing about chasing phantoms, wasting
 time, trying things essentially at random, and never figuring out what's
 going wrong.

 Those with a version control system, a huge
 Undo buffer and perfect faith in their IDDE not to crash may genuinely
 _remove_ code. Those more careful/careworn might instead put in an early
 return statement here and there. Since the last thing one wants to do


 debugging is to introduce new bugs, such users might sensibly wish to
 continue to be informed of potential problems by having their compiler
 emit
 as many warnings as it can.

The way to do chop-and-test is to make a copy of your project, and work

 the copy. Or at least make a full backup first. If you do not make a copy
 first, you are nearly guaranteed to screw up your source code, whether or
 not you are using CVS or have undo buffers. Warnings aren't going to help

 the slightest.

 There's no reason whatsoever to worry about introducing new bugs doing

 If you are in a position where you are somehow unable to back up your
 project or work from a copy of it, then for whatever reason you've
 completely lost control over the project and have much bigger problems

 warnings.


 Please point out the flaw in my reasoning of your paradox, and, further,
 explain to me how, in following this technique in many circumstances


 debugging has been necessitated in C/C++/D/Ruby/Java/.NET, I have gone


 astray in my practice. What should I have been doing instead?

Make a full copy of your project, and work from that.
 This is not
 rhetoric for the sake of it: please do elucidate. If you cannot, please
 explain how DMD's current contradiction of 1 and 2 is not an
 arbitrary shackle to its users,

You're worried about screwing up your project by applying divide-and-conquer, so you want warnings to continue. That is a misunderstanding of how to go about it. Make a copy of your project. Then hack and slash the copy until you've isolated the problem. Turn off the warnings. Stop worrying about introducing a bug - it's a sacrificial copy, not the original.
 one based solely on your own work practices and prejudices that,
 I hope, you would have to concede may not map to those of all other
 developers.

Trying to use warnings as a substitute for making a backup is like a carpenter trying to hammer a nail with a screwdriver. It's the wrong

 and trying to make a screwdriver that can be used as a hammer is also the
 wrong answer.

I get all of the above - some of which does _not_ address my point, and rather lights little adjacent campfires for us to worry about without addressing the point (what's new?) - but that's all from the position of _your own experience_. It does not accord with mine. If I'm unique, and uniquely wrong, then don't worry about it. But if I'm not, then you're making life harder than necessary for some potential users. Since life using D's hard enough already I think it's a bad strategy for getting wider acceptance of D. I don't expect you to change your mind now anymore than I did when I posted my original response on this thread, since you so rarely do. I just have the unfortunate personality trait of being unable to resist bursting bubbles. One of the things you claim is that D helps people work faster. This is an example where that claim is invalid.
Feb 06 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message
news:ds9bs7$1c6t$1 digitaldaemon.com...
 I get all of the above - some of which does _not_ address my point,

I have no idea what your point was, then. Your point sounded like you were worried about introducing bugs during chop-and-test. I recommended making a copy first, then no bugs can be introduced.
 One of the things you claim is that D helps people work faster. This is an
 example where that claim is invalid.

I expect that whatever you're doing that results in 100's of copies of a single file is going to be slow going in any language, but that is nothing I ever recommended. Chop-and-test requires at most 2 copies.
Feb 07 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:ds9o1o$1ml8$2 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:ds9bs7$1c6t$1 digitaldaemon.com...
 I get all of the above - some of which does _not_ address my point,

I have no idea what your point was, then. Your point sounded like you were worried about introducing bugs during chop-and-test. I recommended making

 copy first, then no bugs can be introduced.

I made the point quite clearly.
 One of the things you claim is that D helps people work faster. This is


 example where that claim is invalid.

I expect that whatever you're doing that results in 100's of copies of a single file is going to be slow going in any language, but that is nothing

 ever recommended. Chop-and-test requires at most 2 copies.

Feb 07 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Matthew wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:ds9o1o$1ml8$2 digitaldaemon.com...
 
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message
news:ds9bs7$1c6t$1 digitaldaemon.com...

I get all of the above - some of which does _not_ address my point,

I have no idea what your point was, then. Your point sounded like you were worried about introducing bugs during chop-and-test. I recommended making

a
copy first, then no bugs can be introduced.

I made the point quite clearly.

It's not very clear to me. Was the point actually made by Derek's post? (your first post seemed to assume that the point had already been made), That is, you enable warnings so that you can see what assumptions the compiler is making. You add an early return statement in order to quickly simplify the situation, with minimal side-effects. When you do this, you want to see how the compiler's assumptions have changed. But unfortunately, the warnings-as-errors makes this impossible to do. Right? Or have I misunderstood, too? BTW, something that I've never seen anyone mention is the value of the -cov option for debugging. Absolutely fantastic for debugging, being able to see a 'snail trail' of where the program went. I'll never single-step through code again.
 
 
One of the things you claim is that D helps people work faster. This is


an
example where that claim is invalid.

I expect that whatever you're doing that results in 100's of copies of a single file is going to be slow going in any language, but that is nothing

I
ever recommended. Chop-and-test requires at most 2 copies.


Feb 07 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Don Clugston" <dac nospam.com.au> wrote in message
news:dsa2t0$1vhn$1 digitaldaemon.com...
 Matthew wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:ds9o1o$1ml8$2 digitaldaemon.com...

"Matthew" <matthew hat.stlsoft.dot.org> wrote in message
news:ds9bs7$1c6t$1 digitaldaemon.com...

I get all of the above - some of which does _not_ address my point,

I have no idea what your point was, then. Your point sounded like you



worried about introducing bugs during chop-and-test. I recommended



 a

copy first, then no bugs can be introduced.

I made the point quite clearly.

It's not very clear to me. Was the point actually made by Derek's post? (your first post seemed to assume that the point had already been made),

I said "1. You recommend that people chop down code in order to isolate bugs. Such bugs can include compile-time and runtime bugs. 2. You offer a compiler that does not allow a user to generate code while observing warnings. These two are in obvious conflict. Anyone with any problem compiling any compiled-language will, in following your stipulation to the chop-and-test approach, have to remove code. Those with a version control system, a huge Undo buffer and perfect faith in their IDDE not to crash may genuinely _remove_ code. Those more careful/careworn might instead put in an early return statement here and there. Since the last thing one wants to do when debugging is to introduce new bugs, such users might sensibly wish to continue to be informed of potential problems by having their compiler emit as many warnings as it can. "
 That is, you enable warnings so that you can see what assumptions the
 compiler is making. You add an early return statement in order to
 quickly simplify the situation, with minimal side-effects. When you do
 this, you want to see how the compiler's assumptions have changed.
 But unfortunately, the warnings-as-errors makes this impossible to do.

 Right?

Pretty much. Walter's point includes "No, they aren't. If the person doesn't understand why the warning is being generated, executing the code won't help in the slightest. If it isn't about the warning, just turn off warnings. Turning off the warnings isn't any more work than turning on "warn but keep going"." Since I know he's very smart, I sigh when I read this, as I don't know whether he's trying to quench debate before he has to actually address my point, or that he really can't see it. Either way it's sighworthy. It ignores the clear and very important issue that one might want to continue to have warnings emitted, in order to keep the "mental picture" of the compilation output consistent, in order to ensure that any changes to try and stop the compiler from its ICEs, e.g. reordering seemingly unrelated statements, have not done anything that's a _new_ problem, in order to see if a commented out block highlights a new warning, and so on and so forth. Of course, Walter can counter that each and every change should be atomic, but it's not living in the real world, or at least not in my real world. I want to work how I work best, not how Walter works best. And anyway, that only answers one of these three that I've just tossed up. Blah blah blah blah. I could go on, but this is all soooo obvious and so peurile, it blows my stack that we even have to discuss it. D continues to have a foot firmly in each of the two idiotic camps of "the compiler knows better than the user" (so you can't choose to generate object code with something containg warnings however much you know you need/want to, and so on) and "the language knows better than the user" (so there aren't even any warnings of any kind for implicit numeric conversions). Like making someone at medical school do thought experiments for 7 years, and then making them do unassisted brain surgery as soon as they graduate. That we continue to have to debate this crap year on year when far more interesting and important issues remain unresolved, is a bad joke.
Feb 07 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Matthew wrote:
 "Don Clugston" <dac nospam.com.au> wrote in message
 news:dsa2t0$1vhn$1 digitaldaemon.com...
 
 That is, you enable warnings so that you can see what assumptions the
 compiler is making. You add an early return statement in order to
 quickly simplify the situation, with minimal side-effects. When you do
 this, you want to see how the compiler's assumptions have changed.
 But unfortunately, the warnings-as-errors makes this impossible to do.

 Right?

Pretty much.

Oh I see. I wasn't aware of the dead code warning. Your complaint makes a lot more sense now.
 D continues to have a foot firmly in each of the two idiotic camps of "the
 compiler knows better than the user" (so you can't choose to generate object
 code with something containg warnings however much you know you need/want
 to, and so on)

I agree that it should be possible to disable the aforementioned warning, as I occasionally do the same thing. Still, there's nothing to stop you from disabling warnings altogether if those are the only ones you're seeing. Sean
Feb 07 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote in message 
news:dsabfk$282a$1 digitaldaemon.com...

Walter wrote:
 Your point sounded like you were
worried about introducing bugs during chop-and-test. I recommended
 making a copy first, then no bugs can be introduced.


continue to have warnings emitted, in order to keep the "mental picture" of the compilation output consistent, in order to ensure that any changes to try and stop the compiler from its ICEs, e.g. reordering seemingly unrelated statements, have not done anything that's a _new_ problem, in order to see if a commented out block highlights a new warning, and so on and so forth.

So I summed up your point accurately.
 Of course, Walter can counter that each and every change should be atomic,

Nope. The only goal with the chop is "does the problem I am trying to isolate remain, or does it go away?" It's binary, yes or no. If you're introducing all kinds of other considerations, that's likely why you find chop-and-test to be so unusably arduous.
 but it's not living in the real world, or at least not in my real world. I
 want to work how I work best, not how Walter works best.

You often send me very large bug reports with a comment that you've been unable to chop it down further and that you've no idea what's going wrong. Every one of them I've reduced, using chop-and-test, to 10 lines or so after a few minutes. None of them hinged on -w in any way or required more than 2 of copies of any file. Your way isn't working (in the sense that it isn't finding the cause of the problem), why is it best? This would be probably helped a lot if I could look over your shoulder while you're doing chop-and-test, so I could show you how to do it.
Feb 07 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsaljv$2ikm$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:dsabfk$282a$1 digitaldaemon.com...

Walter wrote:
 Your point sounded like you were
worried about introducing bugs during chop-and-test. I recommended
 making a copy first, then no bugs can be introduced.


continue to have warnings emitted, in order to keep the "mental picture" of the compilation output consistent, in order to ensure that any changes


 try and stop the compiler from its ICEs, e.g. reordering seemingly
 unrelated
 statements, have not done anything that's a _new_ problem, in order to


 if a commented out block highlights a new warning, and so on and so


 So I summed up your point accurately.

 Of course, Walter can counter that each and every change should be


 Nope. The only goal with the chop is "does the problem I am trying to
 isolate remain, or does it go away?" It's binary, yes or no. If you're
 introducing all kinds of other considerations, that's likely why you find
 chop-and-test to be so unusably arduous.

 but it's not living in the real world, or at least not in my real world.


 want to work how I work best, not how Walter works best.

You often send me very large bug reports with a comment that you've been unable to chop it down further and that you've no idea what's going wrong. Every one of them I've reduced, using chop-and-test, to 10 lines or so

 a few minutes. None of them hinged on -w in any way or required more than

 of copies of any file. Your way isn't working (in the sense that it isn't
 finding the cause of the problem), why is it best?

 This would be probably helped a lot if I could look over your shoulder

 you're doing chop-and-test, so I could show you how to do it.

Good one. At junior debating college they taught us that when your opponent starts to play the man not the ball you know you have him on the ropes.
Feb 08 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 8 Feb 2006 22:16:24 +1100, Matthew <matthew hat.stlsoft.dot.org>  
wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:dsaljv$2ikm$1 digitaldaemon.com...
 "Matthew" <matthew hat.stlsoft.dot.org> wrote in message
 news:dsabfk$282a$1 digitaldaemon.com...

Walter wrote:
 Your point sounded like you were
worried about introducing bugs during chop-and-test. I recommended
 making a copy first, then no bugs can be introduced.


continue to have warnings emitted, in order to keep the "mental

 of
 the compilation output consistent, in order to ensure that any changes


 try and stop the compiler from its ICEs, e.g. reordering seemingly
 unrelated
 statements, have not done anything that's a _new_ problem, in order to


 if a commented out block highlights a new warning, and so on and so


 So I summed up your point accurately.

 Of course, Walter can counter that each and every change should be


 Nope. The only goal with the chop is "does the problem I am trying to
 isolate remain, or does it go away?" It's binary, yes or no. If you're
 introducing all kinds of other considerations, that's likely why you  
 find
 chop-and-test to be so unusably arduous.

 but it's not living in the real world, or at least not in my real  


 want to work how I work best, not how Walter works best.

You often send me very large bug reports with a comment that you've been unable to chop it down further and that you've no idea what's going wrong. Every one of them I've reduced, using chop-and-test, to 10 lines or so

 a few minutes. None of them hinged on -w in any way or required more  
 than

 of copies of any file. Your way isn't working (in the sense that it  
 isn't
 finding the cause of the problem), why is it best?

 This would be probably helped a lot if I could look over your shoulder

 you're doing chop-and-test, so I could show you how to do it.

Good one. At junior debating college they taught us that when your opponent starts to play the man not the ball you know you have him on the ropes.

It is called "Attacking the person": http://www.datanation.com/fallacies/attack.htm But I don't agree that Walter is guilty of it here. Regan
Feb 08 2006
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s4iq6vrk6b8z09 ginger.vic.bigpond.net.au...
 On Mon, 06 Feb 2006 07:34:37 +1100, Walter Bright 
 <newshound digitalmars.com> wrote:
 That's right. If the programmer cares about warnings, he'll want them to 
 be
 treated as errors. Otherwise, the warning message could scroll up and all
 too easilly be overlooked.

However, not everyone thinks like Walter. I, for example, regard a warning as different from an error. A warning tells me about a issue that the compiler has had to make an assumption in order to generate code. An error tells me about an issue that the compiler has decided that there are no assumptions that can be made and thus it can't generate valid code. A warning alerts me to the fact that the compiler has made an assumption on my behalf and thus I might want to do something to avoid a 'wrong' compiler assumption. These assumptions are not, per se, errors. Thus if "-w" is not used the compiler generates code and so I can't see why the compiler still can't generate code when "-w" is used. All I want to know is where the compiler has assumed things I didn't actually intend.

The assumption is that people who enable warnings by throwing "-w" care about any generated warnings and want to fix them before proceeding. If the warnings are irrelevant to them, they can just not throw "-w" and the code will compile successfully. I don't see a practical reason for deliberately throwing "-w" but not wanting to deal with the results. I know this isn't how C++ compilers deal with warnings by default, but my experience is that people who care about warnings from their C++ compiler also throw the switch "treat warnings as errors" for the express purpose of not missing them. Think of them as "optional errors" instead of warnings <g>.
Feb 05 2006
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 5 Feb 2006 13:51:55 -0800, Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:op.s4iq6vrk6b8z09 ginger.vic.bigpond.net.au...
 On Mon, 06 Feb 2006 07:34:37 +1100, Walter Bright 
 <newshound digitalmars.com> wrote:
 That's right. If the programmer cares about warnings, he'll want them to 
 be
 treated as errors. Otherwise, the warning message could scroll up and all
 too easilly be overlooked.

However, not everyone thinks like Walter. I, for example, regard a warning as different from an error. A warning tells me about a issue that the compiler has had to make an assumption in order to generate code. An error tells me about an issue that the compiler has decided that there are no assumptions that can be made and thus it can't generate valid code. A warning alerts me to the fact that the compiler has made an assumption on my behalf and thus I might want to do something to avoid a 'wrong' compiler assumption. These assumptions are not, per se, errors. Thus if "-w" is not used the compiler generates code and so I can't see why the compiler still can't generate code when "-w" is used. All I want to know is where the compiler has assumed things I didn't actually intend.

The assumption is that people who enable warnings by throwing "-w" care about any generated warnings and want to fix them before proceeding. If the warnings are irrelevant to them, they can just not throw "-w" and the code will compile successfully.

I really do understand your point of view here. The current dmd behaviour is not a problem for me as I use the "-w" switch to highlight the areas I want to remove the compiler's assumptions, *prior* to running tests of the executable. However, I can also see that some other people might really want to do both - see where the assumptions are *and* allow the compiler to make those assumptions.
 I don't see a practical reason for deliberately throwing "-w" but not 
 wanting to deal with the results. 

That maybe the case, but the fact that you "don't see a practical reason" does not necessarily rule out the possibility that other people might truly see a valid reason. One has to accept that some other people's thinking is valid, though thoroughly weird when seen from one's own point of view.
 I know this isn't how C++ compilers deal 
 with warnings by default, but my experience is that people who care about 
 warnings from their C++ compiler also throw the switch "treat warnings as 
 errors" for the express purpose of not missing them.

I quite sure that other people can also quote from their C++ experience with instances to the contrary - so what does that prove? Only that not everyone thinks the same as you do.
 Think of them as "optional errors" instead of warnings <g>.

Like I say, the current behaviour is not a problem for me. For example, given the example of the OP, I would do this instead ... int main() { writefln(); writefln("Sample program demonstrating '-w' bug:"); writefln(); debug { writefln("Attempt to stop program after this message."); return(0); } else { writefln(); transfertoSCO(); installMSDOS(); emailCongrats(); return(0); } } -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 6/02/2006 10:04:16 AM
Feb 05 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:t4q17cntutnl$.1tpdi4h6n15md$.dlg 40tude.net...
 That maybe the case, but the fact that you "don't see a practical reason"
 does not necessarily rule out the possibility that other people might 
 truly
 see a valid reason. One has to accept that some other people's thinking is
 valid, though thoroughly weird when seen from one's own point of view.

I have many years of experience with warnings, and none of it finds any use for warnings that do not stop the compiler. If someone believes there is a valid reason, they need to present a very convincing case. Just because C compilers do it that way by default is not a compelling reason, since a lot of C compiler defaults are that way in order to not break existing makefiles rather than them being a good idea.
 I quite sure that other people can also quote from their C++ experience
 with instances to the contrary -

If there's a compelling case to be made, bring it on <g>.
 so what does that prove? Only that not everyone thinks the same as you do.

Of course. But at the end of the day I have to make some decisions about how D will and will not work.
Feb 05 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:t4q17cntutnl$.1tpdi4h6n15md$.dlg 40tude.net...
 That maybe the case, but the fact that you "don't see a practical reason"
 does not necessarily rule out the possibility that other people might 
 truly
 see a valid reason. One has to accept that some other people's thinking is
 valid, though thoroughly weird when seen from one's own point of view.

I have many years of experience with warnings, and none of it finds any use for warnings that do not stop the compiler. If someone believes there is a valid reason, they need to present a very convincing case.

So long as the warnings can be disabled, I'm fine with this behavior. I may not consider all warnings important (Visual C++ tends to warn about a handful of things that have nothing to do with code correctness), but for those I do, I typically want to fix them before proceeding. Sean
Feb 05 2006
prev sibling parent reply John Demme <me teqdruid.com> writes:
Walter Bright wrote:
 I have many years of experience with warnings, and none of it finds any
 use for warnings that do not stop the compiler. If someone believes there
 is a valid reason, they need to present a very convincing case.

How does one ignore just one specific warning or one type of warning while still compiling with -w? It'd be nice if there was some way to tell the compiler that a specific line or area of code is indeed correct and to not spit out a warning (or, more importantly, halt on it). ~John Demme
Feb 05 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:ds6ioh$227b$1 digitaldaemon.com...
 Walter Bright wrote:
 I have many years of experience with warnings, and none of it finds any
 use for warnings that do not stop the compiler. If someone believes there
 is a valid reason, they need to present a very convincing case.

How does one ignore just one specific warning or one type of warning while still compiling with -w? It'd be nice if there was some way to tell the compiler that a specific line or area of code is indeed correct and to not spit out a warning (or, more importantly, halt on it).

Each warning has an associated source code modification that will get rid of it.
Feb 05 2006
parent reply John Demme <me teqdruid.com> writes:
Walter Bright wrote:

 
 "John Demme" <me teqdruid.com> wrote in message
 news:ds6ioh$227b$1 digitaldaemon.com...
 Walter Bright wrote:
 I have many years of experience with warnings, and none of it finds any
 use for warnings that do not stop the compiler. If someone believes
 there is a valid reason, they need to present a very convincing case.

How does one ignore just one specific warning or one type of warning while still compiling with -w? It'd be nice if there was some way to tell the compiler that a specific line or area of code is indeed correct and to not spit out a warning (or, more importantly, halt on it).

Each warning has an associated source code modification that will get rid of it.

I assume you mean the user's source code- but what if the user's code is right? Or more importantly, not right- but how they want it. The compiler's not always right... if it was always right and the warnings always pointed out code that was wrong, then they'd be errors. ~John
Feb 07 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"John Demme" <me teqdruid.com> wrote in message 
news:dsaaab$26tt$1 digitaldaemon.com...
 Walter Bright wrote:
 Each warning has an associated source code modification that will get rid
 of it.

right? Or more importantly, not right- but how they want it. The compiler's not always right... if it was always right and the warnings always pointed out code that was wrong, then they'd be errors.

This goes back to why having warnings at all is a bad idea, as it implies a wishy-washy language specification. Is code legal or is it not?
Feb 07 2006
next sibling parent reply "Bob W" <nospam aol.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsapis$2mfo$1 digitaldaemon.com...

 This goes back to why having warnings at all is a bad idea, as it implies 
 a wishy-washy language specification. Is code legal or is it not?

Are you talking about a real-world PL which is evolving over time and where eventual syntax changes are deemed desirable or even necessary? Or are you talking about a perfect and therefore fictional language which is released as V1.0 and stays there and shines forever? - Then I'd have less troubles to agree. The second scenario does not apply to D because it seems to be more the evolving type - and I am glad for it. So you might consider to keep issuing warnings for several reasons. I give you 2 examples: 1) Let us - just theoreticaly - assume that at one stage you want to disallow the optional C-like syntax of declaring arrays. If such a major move is going to happen in the not so near future you would be well advised to introduce warnings in several compiler releases instead of moving radically and forcing even newbies to search for an "allow deprecated features" switch to get their job done. 2) One feature, which usually prevents otherwise unnecessary debugging sessions, is, to offer a warning to the less-than-perfect user about declared but otherwise unused variables. They might be here in error or are intentionally inserted to serve a future purpose. Your compiler has no way to know but it could politely issue a warning, which would be far better than ignoring this fact or refusing to compile alltogether.
Feb 07 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Bob W" <nospam aol.com> wrote in message 
news:dsb8qr$5r8$1 digitaldaemon.com...
 1) Let us - just theoreticaly - assume that at one stage
 you want to disallow the optional C-like syntax of declaring
 arrays. If such a major move is going to happen in the not
 so near future you would be well advised to introduce
 warnings in several compiler releases instead of moving
 radically and forcing even newbies to search for an
 "allow deprecated features" switch to get their job done.

D has already done this a couple times in the past. It'll issue an error about a "deprecated" feature, suggesting the corrected approach. The -d will allow it to continue to compile (I'm not sure why -d would be hard to find for newbies, dmd doesn't have many switches). After a while, it becomes a hard error that can't be overridden with -d, though the fix is still suggested. Eventually, even that is removed and it's just invalid syntax. I think this approach has worked well as long as plenty of time accompanies each stage; at least nobody has complained about it <g>.
Feb 13 2006
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 7 Feb 2006 10:04:54 -0800, Walter Bright wrote:

 "John Demme" <me teqdruid.com> wrote in message 
 news:dsaaab$26tt$1 digitaldaemon.com...
 Walter Bright wrote:
 Each warning has an associated source code modification that will get rid
 of it.

right? Or more importantly, not right- but how they want it. The compiler's not always right... if it was always right and the warnings always pointed out code that was wrong, then they'd be errors.

This goes back to why having warnings at all is a bad idea, as it implies a wishy-washy language specification. Is code legal or is it not?

NO NO NO! May I be so bold as to reword John's paragraph according to how I see the issues. " I assume you mean the user's source code- but what if the user's code is what the coder intended? Or more importantly, not want the really coder intended. The compiler's assumptions are not always the same as the coder's intentions... if it was always the same and the warnings always pointed that out, then they'd be useless. " The "-w" switch is useful to seeing where my understanding of what the code says and what the compiler thinks it says, is different. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 8/02/2006 12:20:01 PM
Feb 07 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:
 On Mon, 06 Feb 2006 07:34:37 +1100, Walter Bright 
 <newshound digitalmars.com> wrote:
 
 "Derek Parnell" <derek psych.ward> wrote in message
 news:op.s4imylg86b8z09 ginger.vic.bigpond.net.au...
 As far as Walter is concerned, a 'warning' is really an error too. So 
 yes,
 DMD will display warnings but treat them as errors such that the 
 compiler
 doesn't generate code.

That's right. If the programmer cares about warnings, he'll want them to be treated as errors. Otherwise, the warning message could scroll up and all too easilly be overlooked.

However, not everyone thinks like Walter. I, for example, regard a warning as different from an error. A warning tells me about a issue that the compiler has had to make an assumption in order to generate code. An error tells me about an issue that the compiler has decided that there are no assumptions that can be made and thus it can't generate valid code. A warning alerts me to the fact that the compiler has made an assumption on my behalf and thus I might want to do something to avoid a 'wrong' compiler assumption. These assumptions are not, per se, errors. Thus if "-w" is not used the compiler generates code and so I can't see why the compiler still can't generate code when "-w" is used. All I want to know is where the compiler has assumed things I didn't actually intend. --Derek Parnell Melbourne, Australia

I too agree with this view, and we have voiced these concerns before (recall news://news.digitalmars.com:119/dn5en0$a4j$1 digitaldaemon.com or http://www.digitalmars.com/d/archives/digitalmars/D/bugs/5743.html ). So let me just make some comments in light of Walter's comments. Why we want warnings: We want warnings so we can be helped with notifications of possible code segments that are incorrect. Why don't we want halt-compilation-on-warnings (as the only option available): Because during the development process it is quite expected that in a given moment, many parts of the code will be incorrect, and the program as whole will be incomplete, but we want to be able to execute it, as it is nonetheless still meaningfull to do so. There may be those certain parts of code that we *know* are incorrect, and we don't care (at the moment) about warnings that come from there, but, we care about warnings that come from *another* part of the code. Having warnings disabled does not give the warnings about the part of the code we want, and having warnings-as-errors, does not allow one to compile the program without fixing the error in the part of the code we do not care about. One example of this situation is the mentioned test-and-chop method, which I too used often. It is quite common when chopping (or perhaps just commenting, that's what I do), that a certain segment of code now has an unused variable or an invalid code path, nonetheless the whole program structure is still meaningfully executable. When I'm stubbing out a certain part AA of code for testing purposes, I don't want to have to change another part BB of code (and then later change BB back when AA is fixed or stubbed in) just because that other part BB of the code annoys the compiler, even though I know the program is meaningful with part BB unchanged. It renders the code slightly less agile (i.e., harder to change). One can say: oh but then you can disable warnings-as-errors when you're doing the test chop runs, and enable it when your doing 'non-chop' development. But that is plain idiotic. I'm not going to change my build config files every time I wanna change from on mode to another. In fact, since different parts can be under work by different people, this idea is just not considerable. I find that this situation/rationale reminds me a lot of the checked exceptions issue (although not as worse). People imagine a clean, pristine utopian world were code always compiles without warnings [the checked throwing of exceptions]. Yet the reality/practice doesn't work that way, and people are annoyed by the forcing of the pristine idea. So people either suck up with the extra agile-ness, like cleaning warnings on all compiles [writing extra try/catch/throws] or find workarounds, like disabling warnings at all [wrapping normal exceptions in unchecked exceptions]. Walter Bright wrote:
 That's right. If the programmer cares about warnings, he'll want them 

 treated as errors. Otherwise, the warning message could scroll up and 

 too easilly be overlooked.

warning reporting now. Walter Bright wrote:
 I quite sure that other people can also quote from their C++ experience
 with instances to the contrary -

If there's a compelling case to be made, bring it on <g>.

I hope I made one. And it is confirmed in my pratical coding experience, both in C++ and Java & C#. Walter Bright wrote:
 Think of them as "optional errors" instead of warnings <g>.

warnings ? Because they are not. The option could be called strict, pedantic, or something like that, just not 'warnings'. That alone would alleviate a great deal of my contention with this issue. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 07 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dsaijo$2f0r$1 digitaldaemon.com...
 One can say: oh but then you can disable warnings-as-errors when you're 
 doing the test chop runs, and enable it when your doing 'non-chop' 
 development. But that is plain idiotic. I'm not going to change my build 
 config files every time I wanna change from on mode to another.
 In fact, since different parts can be under work by different people, this 
 idea is just not considerable.

Chop-and-test is not normal development. It is done with a local copy of the project, including the makefiles, not code that you or other people are working on. The whole technique of chop-and-copy implies being able to hack and slash away at the project source with abandon. You don't worry about breaking the build, warnings, introducing bugs, or screwing up someone else's part. This is all possible because one is working with a local copy that will be deleted as soon as the problem is found and a solution identified. The solution is then folded into the real development branch.
Feb 07 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dsaijo$2f0r$1 digitaldaemon.com...
 One can say: oh but then you can disable warnings-as-errors when you're 
 doing the test chop runs, and enable it when your doing 'non-chop' 
 development. But that is plain idiotic. I'm not going to change my build 
 config files every time I wanna change from on mode to another.
 In fact, since different parts can be under work by different people, this 
 idea is just not considerable.

Chop-and-test is not normal development. It is done with a local copy of the project, including the makefiles, not code that you or other people are working on. The whole technique of chop-and-copy implies being able to hack and slash away at the project source with abandon. You don't worry about breaking the build, warnings, introducing bugs, or screwing up someone else's part. This is all possible because one is working with a local copy that will be deleted as soon as the problem is found and a solution identified. The solution is then folded into the real development branch.

I think I might have misused the term chop-and-test. I meant any kind of test run (or runs) where you removed some part of the code, either by cutting or commenting. Your definition implies a destructive and more abragent version of this, which indeed, musn't happen often. So I correct my previous statements: by chop-and-test I meant not really the proper chop-and-test, but rather one or more of any kind of *temporary short-lived* editing of the code, with the intention of running/testing the program afterwards. This editing will probably have the life span of only the most immediate task the programmer is doing. This situation, does occur often and is part of normal development. And -w annoys the hell out of it. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 08 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Bruno Medeiros wrote:
 Your definition implies a destructive and more 
 abragent version of this, which indeed, musn't happen often.

Sorry, "abrangent" doesn't exist in english. I forgot to fix it before posting. "abrangent" means something like "encompassing", "far-reaching", "wide", etc. . -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 08 2006
prev sibling parent reply "Bob W" <nospam aol.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds5p5i$1e2j$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:op.s4imylg86b8z09 ginger.vic.bigpond.net.au...
 As far as Walter is concerned, a 'warning' is really an error too. So 
 yes, DMD will display warnings but treat them as errors such that the 
 compiler doesn't generate code.

That's right. If the programmer cares about warnings, he'll want them to be treated as errors. Otherwise, the warning message could scroll up and all too easilly be overlooked.

That is cool with me. I just needed to know. However, there is a philosophical side to it: What sense does it make to allow a specific program to compile without trouble if one ever forgets to turn on warnings, if the same programs would fail to compile otherwise? If punishment for warnings is the same as that for errors, why would you still call them warnings? Correct me if I am wrong, but my perception is that "warnings in D are morally less severe errors but still inexcusable if enabled to be caught", right? Whatever - may I just suggest the following modification to the usage screen of dmd? ------------- From ---------------- Usage: dmd files.d ... { -switch } ................ -version=ident compile in version code identified by ident -w enable warnings -------------- change to ------------- Usage: dmd files.d ... { -switch } ................ -version=ident compile in version code identified by ident -w enable warnings and treat them as errors
Feb 05 2006
parent SebastiŠn E. Peyrott <as7cf yahoo.com> writes:
I think the current treatment of warnings reduces the chances of writing 
invalid code in the future, and enforces correct use of the language 
specification. It may be annoying in some cases, but I think it's a good 
tradeoff. 
On the other hand, I think Bob had a good idea and "show warnings and treat 
them as errors" should be printed in DMD's help.

--SebastiŠn.
Feb 06 2006