On 8/4/2015 8:26 PM, deadalnix wrote:
On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
Would you be of the opinion that assert should be a statement rather than an
expression ? unreadability in the middle of expressions, especially when
evaluation order is not well defined, is close
On Wednesday, 5 August 2015 at 05:51:32 UTC, Ola Fosheim Grøstad
wrote:
specification to the code for validation/documentation purposes.
Err... Verification, usually not validation.
On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer
wrote:
At the very least, assert(0, message) should be a compiler
error, the message is unused information.
Only if you compile in -release mode. Without wanting to get
into a bikeshedding debate, I think that flag name may be
On Wednesday, 5 August 2015 at 08:09:49 UTC, Joseph Rushton
Wakeling wrote:
On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer
wrote:
At the very least, assert(0, message) should be a compiler
error, the message is unused information.
Only if you compile in -release mode. Without
On Wednesday, 5 August 2015 at 06:37:21 UTC, Walter Bright wrote:
On 8/4/2015 8:26 PM, deadalnix wrote:
On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
Would you be of the opinion that assert should be a statement
rather than an
expression ? unreadability in the middle of
On 4 August 2015 at 00:54, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/3/2015 8:50 AM, Steven Schveighoffer wrote:
1. They aren't removed, they are replaced with a nearly useless segfault.
Not useless at all:
1. The program does not continue running after it
On Wednesday, 5 August 2015 at 10:31:40 UTC, Iain Buclaw wrote:
I think as a guideline, there are really only be two places
where using an assert makes sense in druntime/phobos.
1. Internal modules, such as rt and core.internal.
2. Inside contracts (in, out, invariant) or unittests.
On 8/5/15 12:46 PM, Jonathan M Davis wrote:
Well, then please comment on the PR:
https://github.com/D-Programming-Language/druntime/pull/1337
It seems to me that the whole point of abort is to work around the fact
that Walter doesn't want assert(0) to print messages before the HLT
instruction
On 8/3/15 9:11 PM, Walter Bright wrote:
enforce(), etc., are for CHECKING FOR INPUT ERRORS. Environmental errors
are input errors, not programming bugs.
enforce isn't available in druntime. In this case, we don't want to
throw an exception anyways, or we would have to remove nothrow from
On 8/3/15 9:13 PM, Walter Bright wrote:
On 8/3/2015 5:25 PM, Ali Çehreli wrote:
On 08/03/2015 04:57 PM, Steven Schveighoffer wrote:
At the very least, assert(0, message) should be a compiler error,
the
message is unused information.
Agreed.
No.
1. If you want the message, do not use
On 08/03/2015 11:59 AM, Dicebot wrote:
General advice - simply don't ever use -release unless you are _very_
sure about program correctness (to the point of 100% test coverage and
previous successful debug runs)
This is very true. I never disable asserts or bounds checking for
exactly that
On Tuesday, 4 August 2015 at 14:40:16 UTC, Nick Sabalausky wrote:
On 08/03/2015 11:59 AM, Dicebot wrote:
General advice - simply don't ever use -release unless you
are _very_
sure about program correctness (to the point of 100% test
coverage and
previous successful debug runs)
This is very
On Tuesday, 4 August 2015 at 23:06:44 UTC, John Colvin wrote:
I'm 90% on Walter's side here as he's right for the majority of
common cases, but on the other hand there are plenty of
situations where the boundary between code error and
environment error get blurred.
Well, the principled
On 8/4/15 7:33 PM, Walter Bright wrote:
On 8/4/2015 2:07 PM, Steven Schveighoffer wrote:
With druntime it's difficult to actually print the message
fprintf(stderr, You left the headlights on.);
assert(0);
Going under the assumption that the program isn't fully with it, I
don't
On Wednesday, 5 August 2015 at 02:52:40 UTC, Jonathan M Davis
wrote:
On Tuesday, 4 August 2015 at 22:13:40 UTC, Steven Schveighoffer
wrote:
On 8/4/15 5:39 PM, Jonathan M Davis wrote:
I'm certainly not opposed to have a message be printed before
the HLT
instruction with assert(0), but I don't
On Tuesday, 4 August 2015 at 22:13:40 UTC, Steven Schveighoffer
wrote:
On 8/4/15 5:39 PM, Jonathan M Davis wrote:
I'm certainly not opposed to have a message be printed before
the HLT
instruction with assert(0), but I don't at all agree that the
fact that
the message is not seen in -release
On Tuesday, 4 August 2015 at 20:21:24 UTC, Walter Bright wrote:
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
The input/environment/code distinction does not work very well.
Sure it does. If your user ever sees an assert failure message,
On Tuesday, 4 August 2015 at 22:06:06 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 4 August 2015 at 20:21:24 UTC, Walter Bright wrote:
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
The input/environment/code distinction does not work very
On 8/4/2015 1:56 PM, Jonathan M Davis wrote:
I can definitely see an argument that we should be
printing out something before the HLT instruction in -release mode,
writeln(Somebody forgot to turn off the water.);
assert(0);
On Tuesday, 4 August 2015 at 23:33:17 UTC, Walter Bright wrote:
On 8/4/2015 2:07 PM, Steven Schveighoffer wrote:
With druntime it's difficult to actually print the message
fprintf(stderr, You left the headlights on.);
assert(0);
It seems that on american car, you bip as annoyingly
On 8/4/15 4:56 PM, Jonathan M Davis wrote:
On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven Schveighoffer wrote:
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is possible to
trigger in release mode is an error. If you can ensure it's
On 8/4/2015 3:13 PM, Steven Schveighoffer wrote:
For instance:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/time.d#L2283
This makes it seem like a message will be printed in the case where
ticksPerSecond was 0. but in reality it simply throws a segfault.
That's a
On 8/4/2015 4:37 PM, Walter Bright wrote:
On 8/4/2015 3:13 PM, Steven Schveighoffer wrote:
For instance:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/time.d#L2283
This makes it seem like a message will be printed in the case where
ticksPerSecond was 0. but in
On 8/4/15 5:39 PM, Jonathan M Davis wrote:
I'm certainly not opposed to have a message be printed before the HLT
instruction with assert(0), but I don't at all agree that the fact that
the message is not seen in -release is a reason not to have a message.
For instance:
On 8/4/15 7:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is an error.
It's compiled in release mode.
I'll look through and find them, and rework them.
First stab: https://github.com/D-Programming-Language/druntime/pull/1337
-Steve
On Tuesday, 4 August 2015 at 20:23:53 UTC, Walter Bright wrote:
On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is
an error. It's
compiled in release mode.
When you're debugging phobos, you aren't compiling in release
mode.
But
On 8/4/15 4:23 PM, Walter Bright wrote:
On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is an
error. It's
compiled in release mode.
When you're debugging phobos, you aren't compiling in release mode.
Unless you aren't debugging it,
On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
Any assert(0) in druntime or phobos with a message printed is an error. It's
compiled in release mode.
When you're debugging phobos, you aren't compiling in release mode.
But I've also been of the opinion, not widely shared, that any programmer
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
The input/environment/code distinction does not work very well.
Sure it does. If your user ever sees an assert failure message, your program has
a bug in it. Keep that in mind when designing
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is possible to
trigger in release mode is an error. If you can ensure it's only
possible to trigger when compiled in debug mode (or for unit tests),
then assert(0, msg) is fine.
In that vein,
On 8/4/2015 4:58 AM, Steven Schveighoffer wrote:
The only answer I can think of is to write a message to stderr, and then
assert(0) as meta suggested.
Print an error message and exit via abort() or whatever. No need to generate a
halt - the program hasn't entered an unknown state.
On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven Schveighoffer
wrote:
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is
possible to
trigger in release mode is an error. If you can ensure it's
only
possible to trigger when compiled in
On 8/4/2015 8:04 AM, Dicebot wrote:
Recently we had quite a lengthy discussion at work regarding possible guidelines
for using asserts, contracts and enforce (we have similar own implementation)
that would actually allow using -release flag for release builds. And got to
certain principles that
On 8/4/2015 4:56 PM, deadalnix wrote:
It seems that on american car, you bip as annoyingly as possible instead of
announcing what's wrong. Preferably for anything and its reverse.
It turns out you can make quite understandable speech simply by connecting an
on/off I/O port to a speaker. So
On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
Would you be of the opinion that assert should be a statement
rather than an expression ? unreadability in the middle of
expressions, especially when evaluation order is not well
defined, is close to impossible to get right.
Ping ?
On Tuesday, 4 August 2015 at 21:07:20 UTC, Steven Schveighoffer
wrote:
On 8/4/15 4:56 PM, Jonathan M Davis wrote:
On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven
Schveighoffer wrote:
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
I should say, any assert(0) with a message printed that is
On 8/4/2015 2:07 PM, Steven Schveighoffer wrote:
With druntime it's difficult to actually print the message
fprintf(stderr, You left the headlights on.);
assert(0);
On 8/3/15 11:18 AM, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer wrote:
Why do we do this?
Because all asserts must be completely removed in -release
1. They aren't removed, they are replaced with a nearly useless segfault.
2. If we are going to put
On Monday, 3 August 2015 at 15:50:56 UTC, Steven Schveighoffer
wrote:
On 8/3/15 11:18 AM, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer
wrote:
Why do we do this?
Because all asserts must be completely removed in -release
1. They aren't removed, they are
General advice - simply don't ever use -release unless you are
_very_ sure about program correctness (to the point of 100% test
coverage and previous successful debug runs)
If you compile and run the following code, what happens?
void main()
{
assert(0, error message);
}
answer: it depends. On OSX, if you compile this like so:
dmd testassert.d
./testassert
You get this message + stack trace:
core.exception.AssertError@testassert.d(3): error message
Not bad.
On 8/3/15 11:57 AM, Dicebot wrote:
On Monday, 3 August 2015 at 15:50:56 UTC, Steven Schveighoffer wrote:
On 8/3/15 11:18 AM, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer wrote:
Why do we do this?
Because all asserts must be completely removed in -release
On 8/3/15 11:59 AM, Dicebot wrote:
General advice - simply don't ever use -release unless you are _very_
sure about program correctness (to the point of 100% test coverage and
previous successful debug runs)
So in other words, only release code that has no bugs. Got it ;)
-Steve
On 8/3/2015 8:50 AM, Steven Schveighoffer wrote:
1. They aren't removed, they are replaced with a nearly useless segfault.
Not useless at all:
1. The program does not continue running after it has failed. (Please, let's not
restart that debate.
2. Running it under a debugger, the location
On 08/03/2015 04:57 PM, Steven Schveighoffer wrote:
At the very least, assert(0, message) should be a compiler error, the
message is unused information.
Agreed.
How about dumping the message to stderr as a best effort if the message
is a literal? Hm... On the other hand, undefined behavior
On 8/3/15 6:54 PM, Walter Bright wrote:
On 8/3/2015 8:50 AM, Steven Schveighoffer wrote:
1. They aren't removed, they are replaced with a nearly useless segfault.
Not useless at all:
1. The program does not continue running after it has failed. (Please,
let's not restart that debate.
You
On 8/3/2015 4:57 PM, Steven Schveighoffer wrote:
OK, this brings up another debate. The thing that triggered all this is an issue
with core.time, see issue https://issues.dlang.org/show_bug.cgi?id=14863
Essentially, we wrote code to get all the clock information at startup on a
posix system
On 8/3/2015 5:25 PM, Ali Çehreli wrote:
On 08/03/2015 04:57 PM, Steven Schveighoffer wrote:
At the very least, assert(0, message) should be a compiler error, the
message is unused information.
Agreed.
No.
1. If you want the message, do not use -release.
2. Do not use asserts to issue
On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer
wrote:
OK, this brings up another debate. The thing that triggered all
this is an issue with core.time, see issue
https://issues.dlang.org/show_bug.cgi?id=14863
[...]
Why not just stderr.writeln(errMsg); assert(0);?
On Tuesday, 4 August 2015 at 02:37:00 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 3 August 2015 at 15:18:12 UTC, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer
wrote:
Why do we do this?
Because all asserts must be completely removed in -release
Yet assert(0)
On Tuesday, 4 August 2015 at 03:04:14 UTC, Dicebot wrote:
indeed. I remember Iain complaining about presence of HLT (and
saying he won't do that for gdc) for exactly this reason.
Yes. I think a lot of this confusion could have been avoided by
using halt() instead of assert(0) and
On Monday, 3 August 2015 at 15:18:12 UTC, Dicebot wrote:
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer
wrote:
Why do we do this?
Because all asserts must be completely removed in -release
Yet assert(0) effectively mean unreachable code (it is
actually defined that way in
On Monday, 3 August 2015 at 14:34:52 UTC, Steven Schveighoffer
wrote:
Why do we do this?
Because all asserts must be completely removed in -release
Yet assert(0) effectively mean unreachable code (it is actually
defined that way in spec) and thus it is possible to ensure extra
free bit of
53 matches
Mail list logo
