www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - debug = x overrides command line

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
Currently, if you write something like this:

debug = x;

It's like you passed -debug=x on the command line. However, this seems 
quite scary. It means that you are debugging ALL THE TIME, with any 
debug(x) statements.

Does this make sense? Note that debug disables pure checking, which can 
be dangerous. I'm kind of uneasy that if I don't pass any debug 
arguments to the compiler, it can still violate purity in the name of 
debugging with such statements.

I would have expected debug = x to only be enabled when -debug is passed 
to the compiler. Does this make sense to anyone?

Note, there is no way to simply enable the same thing as -debug does in 
code.

-Steve
Oct 21 2014
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 21 October 2014 at 15:45:55 UTC, Steven Schveighoffer 
wrote:

 Currently, if you write something like this:

 debug = x;


In code? Like this:

void main()
{
     debug = x;

     // now in debug mode even though not specified on the CLI?
}

If that's true, that's pretty scary. What if it's hidden in a 
module somewhere?
Oct 21 2014
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/21/14 12:02 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 15:45:55 UTC, Steven Schveighoffer wrote:

 Currently, if you write something like this:

 debug = x;


 In code? Like this:

 void main()
 {
      debug = x;

      // now in debug mode even though not specified on the CLI?
 }


Yes, but only for debug(x) statements. debug statements without a symbol 
aren't enabled. But for those statements, purity is jettisoned. e.g.:

import std.stdio;
int a;

void foonotpure() { a = 5; writeln("yep, not pure");}

debug = x; // note this is only allowed at module scope.
void main() pure
{
    debug(x) foonotpure();
}

dmd -run foonotpure.d
yep, not pure


 If that's true, that's pretty scary. What if it's hidden in a module
 somewhere?


Yep, you can just turn off purity when it gets in the way.

-Steve
Oct 21 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer 
wrote:

 On 10/21/14 12:02 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 15:45:55 UTC, Steven 
 Schveighoffer wrote:

 Currently, if you write something like this:

 debug = x;


 In code? Like this:

 void main()
 {
     debug = x;

     // now in debug mode even though not specified on the CLI?
 }


 Yes, but only for debug(x) statements. debug statements without 
 a symbol aren't enabled. But for those statements, purity is 
 jettisoned. e.g.:

 import std.stdio;
 int a;

 void foonotpure() { a = 5; writeln("yep, not pure");}

 debug = x; // note this is only allowed at module scope.
 void main() pure
 {
    debug(x) foonotpure();
 }

 dmd -run foonotpure.d
 yep, not pure


 If that's true, that's pretty scary. What if it's hidden in a 
 module
 somewhere?


 Yep, you can just turn off purity when it gets in the way.

 -Steve


Wow!
Oct 21 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
wrote:

 Yep, you can just turn off purity when it gets in the way.

 -Steve


Please raise a ticket for this.
Oct 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/21/2014 12:15 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
 wrote:

 Yep, you can just turn off purity when it gets in the way.

 -Steve


 Please raise a ticket for this.


That was done deliberately - it's a feature. It enables things like debugging 
printf's to be inserted into pure functions.
Oct 21 2014
next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 21 October 2014 at 19:24:03 UTC, Walter Bright wrote:

 On 10/21/2014 12:15 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven 
 Schveighoffer
 wrote:

 Yep, you can just turn off purity when it gets in the way.

 -Steve


 Please raise a ticket for this.


 That was done deliberately - it's a feature. It enables things 
 like debugging printf's to be inserted into pure functions.


Ah, where's the documentation for this?
Oct 21 2014
parent reply "anonymous" <anonymous example.com> writes:
On Tuesday, 21 October 2014 at 19:51:34 UTC, Gary Willoughby
wrote:

 Ah, where's the documentation for this?


http://dlang.org/function.html#pure-functions


 As a concession to practicality, a pure function can:


[...]

 perform impure operations in statements that are in a 
 ConditionalStatement controlled by a DebugCondition.
Oct 21 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 21 October 2014 at 19:58:40 UTC, anonymous wrote:

 On Tuesday, 21 October 2014 at 19:51:34 UTC, Gary Willoughby
 wrote:

 Ah, where's the documentation for this?


 http://dlang.org/function.html#pure-functions


 As a concession to practicality, a pure function can:


 [...]

 perform impure operations in statements that are in a 
 ConditionalStatement controlled by a DebugCondition.




Right, that's all well and good but where does it say that you 
can assign a value to the debug keyword (in code) and it executes 
as if you had specified debug on the command line?
Oct 21 2014
parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 21 October 2014 at 20:57:03 UTC, Gary Willoughby 
wrote:

 On Tuesday, 21 October 2014 at 19:58:40 UTC, anonymous wrote:

 On Tuesday, 21 October 2014 at 19:51:34 UTC, Gary Willoughby
 wrote:

 Ah, where's the documentation for this?


 http://dlang.org/function.html#pure-functions


 As a concession to practicality, a pure function can:


 [...]

 perform impure operations in statements that are in a 
 ConditionalStatement controlled by a DebugCondition.




 Right, that's all well and good but where does it say that you 
 can assign a value to the debug keyword (in code) and it 
 executes as if you had specified debug on the command line?


Aha http://dlang.org/version.html#DebugCondition
Oct 21 2014
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/21/14 3:24 PM, Walter Bright wrote:

 On 10/21/2014 12:15 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
 wrote:

 Yep, you can just turn off purity when it gets in the way.

 -Steve


 Please raise a ticket for this.


 That was done deliberately - it's a feature. It enables things like
 debugging printf's to be inserted into pure functions.


Right. But my understanding was that was only when you were actually 
compiling with debug enabled. I didn't expect it to be a feature to be 
able to do this without debug enabled, as it currently is.

-Steve
Oct 21 2014
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 21 Oct 2014 22:33:02 -0400
schrieb Steven Schveighoffer <schveiguy yahoo.com>:


 On 10/21/14 3:24 PM, Walter Bright wrote:

 On 10/21/2014 12:15 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
 wrote:

 Yep, you can just turn off purity when it gets in the way.

 -Steve


 Please raise a ticket for this.


 That was done deliberately - it's a feature. It enables things like
 debugging printf's to be inserted into pure functions.


=20
 Right. But my understanding was that was only when you were actually=20
 compiling with debug enabled. I didn't expect it to be a feature to be=20
 able to do this without debug enabled, as it currently is.
=20
 -Steve


You might be surprised that -debug doesn't enable anything
special. It is just a shortcut for setting the debug level to
1 (a shortcut for -debug=3D1). Likewise debug statements are a
shortcut for debug(1) {=E2=80=A6}. This is also analogous to -version.

--=20
Marco
Oct 22 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 22 October 2014 at 11:13:35 UTC, Marco Leise wrote:

 You might be surprised that -debug doesn't enable anything
 special. It is just a shortcut for setting the debug level to
 1 (a shortcut for -debug=1). Likewise debug statements are a
 shortcut for debug(1) {…}. This is also analogous to -version.


On a related note, how do you provide multiple execution paths 
based on cpuid without making the code dirty?

In C I guess a trick would simply be to recompile the compilation 
unit twice with different settings and a macro definition on the 
command line to change the function name.

This is relevant for code where you want to provide a single 
binary for various CPU generations (AVX512, SSE, MMX)…
Oct 22 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/22/2014 4:30 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On a related note, how do you provide multiple execution paths based on cpuid
 without making the code dirty?


https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arrayfloat.d
Oct 22 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 22 October 2014 at 19:24:54 UTC, Walter Bright 
wrote:

 On 10/22/2014 4:30 AM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On a related note, how do you provide multiple execution paths 
 based on cpuid
 without making the code dirty?


 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arrayfloat.d


Hmm… that looks a bit complicated. I was thinking about compiling 
the same function with different backend settings, so you get 
myfunc_AVX() and myfunc_SSE() from the same function body.
Oct 22 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/22/2014 12:44 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Wednesday, 22 October 2014 at 19:24:54 UTC, Walter Bright wrote:

 On 10/22/2014 4:30 AM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On a related note, how do you provide multiple execution paths based on cpuid
 without making the code dirty?


 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arrayfloat.d


 Hmm… that looks a bit complicated. I was thinking about compiling the same
 function with different backend settings, so you get myfunc_AVX() and
 myfunc_SSE() from the same function body.


Make 3 modules:

1. myfunc() as a template function
2. avx.d that imports myfunc() and instantiates it with avx backend settings.
3. sse.d that imports myfunc() and instantiates it with sse backend settings.
Oct 22 2014
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/22/14 7:23 AM, Marco Leise wrote:

 Am Tue, 21 Oct 2014 22:33:02 -0400
 schrieb Steven Schveighoffer <schveiguy yahoo.com>:


 On 10/21/14 3:24 PM, Walter Bright wrote:

 On 10/21/2014 12:15 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
 wrote:

 Yep, you can just turn off purity when it gets in the way.

 -Steve


 Please raise a ticket for this.


 That was done deliberately - it's a feature. It enables things like
 debugging printf's to be inserted into pure functions.


 Right. But my understanding was that was only when you were actually
 compiling with debug enabled. I didn't expect it to be a feature to be
 able to do this without debug enabled, as it currently is.


 You might be surprised that -debug doesn't enable anything
 special. It is just a shortcut for setting the debug level to
 1 (a shortcut for -debug=1). Likewise debug statements are a
 shortcut for debug(1) {…}. This is also analogous to -version.


I am surprised. So you can actually enable all debug code permanently.

I think debug=... statement should be made illegal.

-Steve
Oct 22 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 22 October 2014 at 13:58:44 UTC, Steven 
Schveighoffer wrote:

 I am surprised. So you can actually enable all debug code 
 permanently.

 I think debug=... statement should be made illegal.

 -Steve


I'd agree with that to be honest. It seems odd to allow this in 
code. I can understand the rationale for doing unpure things in a 
pure function in debug mode but that mode should be specified on 
the command line, not in code. Like you say, you can enable debug 
mode permanently in code.
Oct 22 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 22 Oct 2014 17:04:41 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Wednesday, 22 October 2014 at 13:58:44 UTC, Steven=20
 Schveighoffer wrote:

 I am surprised. So you can actually enable all debug code=20
 permanently.

 I think debug=3D... statement should be made illegal.

 -Steve


=20
 I'd agree with that to be honest. It seems odd to allow this in=20
 code. I can understand the rationale for doing unpure things in a=20
 pure function in debug mode but that mode should be specified on=20
 the command line, not in code. Like you say, you can enable debug=20
 mode permanently in code.


i think that compiler should emit warning on such code. it can be handy
to do such things, but let compiler warn us that "debug=3D" is not very
safe thing to do.
Oct 22 2014
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 21, 2014 22:33:02 Steven Schveighoffer via 
Digitalmars-d
wrote:

 On 10/21/14 3:24 PM, Walter Bright wrote:

 On 10/21/2014 12:15 PM, Gary Willoughby wrote:

 On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven 
 Schveighoffer

 wrote:

 Yep, you can just turn off purity when it gets in the way.

 -Steve


 Please raise a ticket for this.


 That was done deliberately - it's a feature. It enables 
 things like
 debugging printf's to be inserted into pure functions.


 Right. But my understanding was that was only when you were 
 actually
 compiling with debug enabled. I didn't expect it to be a 
 feature to be
 able to do this without debug enabled, as it currently is.


Yeah, being able to just enable the debug blocks from within the 
code like
that seems questionable to me and has nothing to do with debug 
blocks
disabling pure functions. It just makes for a nastier side effect 
when debug
blocks are enabled within the code rather than via the 
command-line.

- Jonathan M Davis
Oct 22 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/22/2014 1:04 PM, Jonathan M Davis wrote:

 Yeah, being able to just enable the debug blocks from within the code like
 that seems questionable to me and has nothing to do with debug blocks
 disabling pure functions. It just makes for a nastier side effect when debug
 blocks are enabled within the code rather than via the command-line.


Lots of people (like me, though I'm often told I'm a unique snowflake and
nobody 
programs like me) debug code by editting the source code to enable/disable
debug 
code rather than messing with the makefile.

Take a look at about any source file in dmd, for example, with the commented
out 
printf's, and template.c, with the file scope #define LOG 0.

D needs to support this style of debugging, and the 'debug' conditional with
how 
it is set is just the ticket. The feature works as designed and intended.
Oct 22 2014
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 22 October 2014 at 20:15:57 UTC, Walter Bright 
wrote:

 On 10/22/2014 1:04 PM, Jonathan M Davis wrote:

 Yeah, being able to just enable the debug blocks from within 
 the code like
 that seems questionable to me and has nothing to do with debug 
 blocks
 disabling pure functions. It just makes for a nastier side 
 effect when debug
 blocks are enabled within the code rather than via the 
 command-line.


 Lots of people (like me, though I'm often told I'm a unique 
 snowflake and nobody programs like me) debug code by editting 
 the source code to enable/disable debug code rather than 
 messing with the makefile.

 Take a look at about any source file in dmd, for example, with 
 the commented out printf's, and template.c, with the file scope 
 #define LOG 0.

 D needs to support this style of debugging, and the 'debug' 
 conditional with how it is set is just the ticket. The feature 
 works as designed and intended.


I can understand that, but it does seem a bit risky in this case. 
The suggestion of creating a warning for it seems like a good 
one, since it allows you to debug like that but needles you to 
not leave it that way.

- Jonathan M Davis
Oct 22 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/22/2014 1:28 PM, Jonathan M Davis wrote:

 I can understand that, but it does seem a bit risky in this case. The
suggestion
 of creating a warning for it seems like a good one, since it allows you to
debug
 like that but needles you to not leave it that way.


I don't want deliberately written debug code to produce needling warnings. The 
Boy Who Cried Wolf comes to mind. The feature provides for a valid use case,
one 
that is pretty hard to do any other way.

Such warnings should go into a separate linting tool.
Oct 22 2014
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 22, 2014 14:10:02 Walter Bright via 
Digitalmars-d wrote:

 On 10/22/2014 1:28 PM, Jonathan M Davis wrote:

 I can understand that, but it does seem a bit risky in this 
 case. The
 suggestion of creating a warning for it seems like a good 
 one, since it
 allows you to debug like that but needles you to not leave it 
 that way.


 I don't want deliberately written debug code to produce 
 needling warnings.
 The Boy Who Cried Wolf comes to mind. The feature provides for 
 a valid use
 case, one that is pretty hard to do any other way.

 Such warnings should go into a separate linting tool.


That's actually one of the few cases where I would have said that 
actually having a warning made sense as opposed to making it an 
error or leaving it to a lint tool. Since no one should be 
leaving warnings in their code, it seems to me that having a 
warning for something that's temporarily okay to do but not okay 
to leave in your code is just about the only valid use case for 
warnings (particularly if deprecation-related stuff is separate 
like it is in D). So, I'd definitely be in favor of having a 
warning in this case, but I don't care enough to fight for it 
either, particularly since I almost never use debug blocks 
(though their ability to bypass pure will probably make it so 
that I use them at least periodically).

- Jonathan M Davis
Oct 22 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 22 October 2014 at 21:10:06 UTC, Walter Bright 
wrote:

 I don't want deliberately written debug code to produce 
 needling warnings.


You should have an overriding option on the command line to turn 
off all debugging. Having debug statements in release code is a 
no-go.


 The Boy Who Cried Wolf comes to mind. The feature provides for 
 a valid use case, one that is pretty hard to do any other way.

 Such warnings should go into a separate linting tool.


I think warnings built into the compiler is a good feature for 
catching common mistakes. I use it often and find it much more 
attractive than lint, which I would only use if stuck on a bug.

It is also GREAT for NEW USERS to have a "-pedantic", "-Wall" and 
even an "-idiomatic" option built into the compiler.

Arguments against two binaries:

- Newbies will never user lint and they NEED heavy-duty warnings.

- There is zero advantage to having two binaries for the end user.

- Having two binaries means that IDEs will only bother to support 
the compiler.

- It is slower. Having two binaries means that you have to make 
two passes, first lint then compiler.

- A linting tool cannot keep pace with the compiler. If devs 
report a feature as a bug, it is candidate for builtin warning.

- Not providing helpful warning options makes the compiler look 
unfinished and of low quality. Without developers will blame the 
compiler devs for lost time, not themselves.


Arguments for two binaries:

- It is easier for the implementor.

- Too early to add warnings to dmd since the language will change 
a lot.
Oct 23 2014
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/22/14 4:15 PM, Walter Bright wrote:

 On 10/22/2014 1:04 PM, Jonathan M Davis wrote:

 Yeah, being able to just enable the debug blocks from within the code
 like
 that seems questionable to me and has nothing to do with debug blocks
 disabling pure functions. It just makes for a nastier side effect when
 debug
 blocks are enabled within the code rather than via the command-line.


 Lots of people (like me, though I'm often told I'm a unique snowflake
 and nobody programs like me) debug code by editting the source code to
 enable/disable debug code rather than messing with the makefile.


This is a good point. Enabling debug on a specific feature/module in a 
complex build system is not easy. For someone simply typing dmd *.d, 
this is trivial, but not if you have to go edit a makefile, or try to 
figure out how to pass arguments to it (I need to look that up every time).


 Take a look at about any source file in dmd, for example, with the
 commented out printf's, and template.c, with the file scope #define LOG 0.

 D needs to support this style of debugging, and the 'debug' conditional
 with how it is set is just the ticket. The feature works as designed and
 intended.


I think there is a problem though. What if you leave your debug in by 
accident? Now your pure code isn't so pure, and you have no idea.

As we all know from "const-by-convention" C++, if there is an easy way 
to "get around" something that the compiler makes difficult, people will 
exploit it. I would hate to see someone using this "feature" to simply 
make something impure pure so they can get it to compile.

I propose a compromise. By default, the compiler emits warnings when 
debug=x is executed, AS LONG AS it's not inside a debug block already 
enabled by a command line debug directive. However, if the compiler has 
any of the following switches, then then warnings are suppressed:

-unittest
-g
-gc
-debug

The theory being, you are testing the code with these switches, not 
releasing it. This way, you can add your debug=x enablers when doing 
make debug or make unittest, but once you go to make release, you get 
the warning.

Optionally, we could have a dedicated switch to suppress these warnings.

Does this sound reasonable?

-Steve
Oct 23 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message 
news:m2avtc$15e3$1 digitalmars.com...


 This is a good point. Enabling debug on a specific feature/module in a 
 complex build system is not easy. For someone simply typing dmd *.d, this 
 is trivial, but not if you have to go edit a makefile, or try to figure 
 out how to pass arguments to it (I need to look that up every time).


Exactly.


 I think there is a problem though. What if you leave your debug in by 
 accident? Now your pure code isn't so pure, and you have no idea.


What if you leave any other form of debug code enabled by accident?  The 
answer is to use version control, and make a quick pass over changes before 
you commit.
Oct 23 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2014 11:40 AM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message news:m2avtc$15e3$1 digitalmars.com...

 I think there is a problem though. What if you leave your debug in by
 accident? Now your pure code isn't so pure, and you have no idea.


 What if you leave any other form of debug code enabled by accident?  The answer
 is to use version control, and make a quick pass over changes before you
commit.


Version control has been successful at eliminating such mistakes in my 
experience with github.
Oct 23 2014
next sibling parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10/23/2014 12:31 PM, Walter Bright via Digitalmars-d wrote:

 Version control has been successful at eliminating such mistakes in my
 experience with github.


Not eliminating, but with many eyes watching the flow of changes, at 
least relatively easy to catch.
Oct 23 2014
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/23/14 3:31 PM, Walter Bright wrote:

 On 10/23/2014 11:40 AM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message
 news:m2avtc$15e3$1 digitalmars.com...

 I think there is a problem though. What if you leave your debug in by
 accident? Now your pure code isn't so pure, and you have no idea.


 What if you leave any other form of debug code enabled by accident?
 The answer
 is to use version control, and make a quick pass over changes before
 you commit.


 Version control has been successful at eliminating such mistakes in my
 experience with github.


On your own 1-person projects, or just with 2+ reviewers for every commit?

In my experience, source control does not stop me from committing debug 
code by accident.

Seriously, the idea of "just avoid committing mistakes" or "just use x 
version control system" is not a very palatable answer.

-Steve
Oct 24 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 24 October 2014 at 12:45:21 UTC, Steven Schveighoffer 
wrote:

 On 10/23/14 3:31 PM, Walter Bright wrote:

 On 10/23/2014 11:40 AM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message
 news:m2avtc$15e3$1 digitalmars.com...

 I think there is a problem though. What if you leave your 
 debug in by
 accident? Now your pure code isn't so pure, and you have no 
 idea.


 What if you leave any other form of debug code enabled by 
 accident?
 The answer
 is to use version control, and make a quick pass over changes 
 before
 you commit.


 Version control has been successful at eliminating such 
 mistakes in my
 experience with github.


 On your own 1-person projects, or just with 2+ reviewers for 
 every commit?

 In my experience, source control does not stop me from 
 committing debug code by accident.

 Seriously, the idea of "just avoid committing mistakes" or 
 "just use x version control system" is not a very palatable 
 answer.


I usually use `git add -p` to review my changes before I commit 
them. But this doesn't prevent anything from slipping through by 
accident from time to time.

Maybe a hook could reject lines that contain `debug\s*=`? Or are 
you thinking about a manual review of every commit before each 
release?
Oct 24 2014
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/24/14 9:08 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 On Friday, 24 October 2014 at 12:45:21 UTC, Steven Schveighoffer wrote:

 On 10/23/14 3:31 PM, Walter Bright wrote:

 On 10/23/2014 11:40 AM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message
 news:m2avtc$15e3$1 digitalmars.com...

 I think there is a problem though. What if you leave your debug in by
 accident? Now your pure code isn't so pure, and you have no idea.


 What if you leave any other form of debug code enabled by accident?
 The answer
 is to use version control, and make a quick pass over changes before
 you commit.


 Version control has been successful at eliminating such mistakes in my
 experience with github.


 On your own 1-person projects, or just with 2+ reviewers for every
 commit?

 In my experience, source control does not stop me from committing
 debug code by accident.

 Seriously, the idea of "just avoid committing mistakes" or "just use x
 version control system" is not a very palatable answer.


 I usually use `git add -p` to review my changes before I commit them.
 But this doesn't prevent anything from slipping through by accident from
 time to time.

 Maybe a hook could reject lines that contain `debug\s*=`? Or are you
 thinking about a manual review of every commit before each release?


My proposal is to have the compiler reject such code unless one of the 
debugging switches is present on the command line. If you aren't 
debugging, don't compile code that is marked as "only compile during 
debugging." I don't think it's that complex or controversial.

-Steve
Oct 24 2014
parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 24 October 2014 at 13:15:45 UTC, Steven Schveighoffer 
wrote:

 My proposal is to have the compiler reject such code unless one 
 of the debugging switches is present on the command line. If 
 you aren't debugging, don't compile code that is marked as 
 "only compile during debugging." I don't think it's that 
 complex or controversial.

 -Steve


IMHO it should at least emit a warning. I understand how it can 
be useful from Walter's previous example but the enabling switch 
belongs on the command line, not in code.
Oct 24 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-10-23 20:40, Daniel Murphy wrote:


 What if you leave any other form of debug code enabled by accident?  The
 answer is to use version control, and make a quick pass over changes
 before you commit.


Perhaps something for a lint tool as well.

-- 
/Jacob Carlborg
Oct 23 2014
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/23/14 2:40 PM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message
 news:m2avtc$15e3$1 digitalmars.com...


 I think there is a problem though. What if you leave your debug in by
 accident? Now your pure code isn't so pure, and you have no idea.


 What if you leave any other form of debug code enabled by accident?  The
 answer is to use version control, and make a quick pass over changes
 before you commit.


This is kind of an absurd statement when you have clearly marked a line 
as being for debugging only. If only there were some automated tool that 
could detect this when you are compiling for release and flag it as an 
issue?

-Steve
Oct 24 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
I use this pattern somewhar often:

version(unittest)
{
     debug = ExtraCostlySanityChecks;
}
Oct 26 2014
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/26/14 3:15 AM, Dicebot wrote:

 I use this pattern somewhar often:

 version(unittest)
 {
      debug = ExtraCostlySanityChecks;
 }


My proposal covers this, it would still be fine:

http://forum.dlang.org/post/m2avtc$15e3$1 digitalmars.com

-Steve
Oct 27 2014