"Sean Kelly"  wrote in message news:tngnltzwxprebpbcdkgm@forum.dlang.org...

> Druntime uses contracts and asserts in places. Which are of course removed because we ship only a "release" build.  Once again, the worst naming for a compiler switch ever. What I really want is a way to ship release and non-release builds (ie. checked and unchecked) and have the proper one chosen at link time based on build flags. Basically toss the -defaultlib and -debuglib and replace it with -checkedlib and -uncheckedlib.

While shipping a debug version of druntime would be useful, I think the real problem is that checking preconditions is disabled by the callee!  If preconditions are violated, the error is in the caller, and checking should be enabled based on the application's flags. 

Am 01.08.2014 18:47, schrieb Daniel Murphy:
> "Daniel Gibson"  wrote in message news:lrgcei$211u$1@digitalmars.com...
>
>> I'm a bit surprised that back then your reaction was not "well, that's
>> a neat idea, but people must know about it, so let's make it explicit
>> in the documentation".
>
> Haha, I think back then there were much more serious issues with D, like
> abundant segfaults and a development team of ~2.

It's not like adding two sentences describing this would take forever.

>
>> If assert() would have been documented or even advertised as "can be
>> used for optimizations by compilers in release mode" from day one,
>> this discussion wouldn't have started or at least would have been over
>> very soon.
>
> I expect that even if it had been documented, people would have
> completely ignored it, and would still be arguing for the exact same
> positions.

They could be told "look, it's written in the language spec (and has been for a long time), deal with it".
Maybe there still would be /some/ discussion, but certainly not as much as we're currently seeing - and it could be ignored of a good reason.

Cheers,
Daniel

If assertions are disabled in release builds, and you specifically instruct the compiler to build one, are you not assuming that the assertions will hold?

Then what is wrong with extending those assumptions to the optimizer?

Unless the assertions trigger in debug build, you will not end up with bugs in the release.

On 8/1/14, 2:19 PM, Sebastiaan Koppe wrote:
> If assertions are disabled in release builds, and you specifically
> instruct the compiler to build one, are you not assuming that the
> assertions will hold?
>
> Then what is wrong with extending those assumptions to the optimizer?
>
> Unless the assertions trigger in debug build, you will not end up with
> bugs in the release.

If assertions don't trigger in debug build then assertions don't trigger in release.

That's false.

On 8/1/14, 9:25 AM, Timon Gehr wrote:
> Even then, such a semantics is non-standard and almost nobody else knew.

This notion of "standard" has been occasionally mentioned in this discussion. I agree that D's assert is different from traditional C and C++ assert, and I also agree that might surprise some, but I think the meaning of D's assert is well within the intent of the larger notion.

> Why break 'assert' now, now that it actually behaves as I and many
> others expect (even some of those who argued for the (apparently, even
> inofficially) new and opposite design)?

I don't see any breakage of "assert", more like realizing more of its latent potential. Clearly the documentation could be better, which is something we should focus on.

I do agree there's stuff that some may find unexpected, such as:

assert(x > 42);
if (x <= 42) {
  // let me also handle this conservatively
  ...
} else {
  // all good, proceed
  ...
}

The D optimizer might actually deem the entire "then" path unreachable in the future, and only compile in the "else" path. Some may find that surprising. For my money I never write code like this, and I consider it incorrect if I review it. You either assert something, or you check it dynamically.

I don't remember having to ding anyone in a code review at Facebook for something like that in almost five years of tenure, and we use assert all over the place.

Yesterday I changed a bunch of "assert" in hhvm (https://github.com/facebook/hhvm) with "BSSERT" having the following definition:

#ifdef NDEBUG
#define BSSERT(e) do { if (e) {} else __builtin_unreachable(); } while (0)
#else
#define BSSERT(e) do { assert(e); } while (0)
#endif

That's a >2MLOC project. I was hoping I'd measure a slight improvement based on the hints to gcc's optimizer. Tests passed but alas there was an 1.4% CPU time increase (which at our scale we consider a large performance regression); not sure what's causing it (it does sometimes happen that certain gcc optimization end up generating larger code which spills the I-Cache more often, something gcc's optimizer is not very good at controlling).

Better, clearer language definition and documentation is the real cure for this particular matter. Sure enough we need to introduce any future optimizations with due care and diligence; that's a given. We also have a bunch of issues very important and very urgent to tend to, starting with finalizing the new release. Getting into this holier-than-thou contest, dinging people for using "exponential" casually, or discouraging them to express approval with the language leader is not only a waste of time, it's a net negative for everyone involved. It makes us look bad among ourselves and also to the larger community.


Andrei

On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
> If assertions are disabled in release builds, and you specifically
> instruct the compiler to build one, are you not assuming that the
> assertions will hold?
> ...

It would often be foolish to simply assume so, and disabling of the assertions can be motivated differently (and not all motivations are valid; _they don't need to be_.)

> Then what is wrong with extending those assumptions to the optimizer?
> ...

To appreciate this better, simply imagine you are the guy who needs to track down the bug (which you don't reproduce locally, there can be many reasons for that) but who is not responsible for it.

> Unless the assertions trigger in debug build, you will not end up with
> bugs in the release.

The debug and the release build may be subjected to different input and hence traverse different traces of abstract states. It is not valid to say that an assertion will never fail just because it hasn't failed yet.

On 08/01/2014 07:39 PM, Andrei Alexandrescu wrote:
>...
>

I did what I though was right. Do what you like. I'm off.

On Fri, Aug 01, 2014 at 06:58:16PM +0200, Daniel Gibson via Digitalmars-d wrote:
> Lines: 29
> 
> Am 01.08.2014 18:47, schrieb Daniel Murphy:
> >"Daniel Gibson"  wrote in message news:lrgcei$211u$1@digitalmars.com...
> >
> >>I'm a bit surprised that back then your reaction was not "well, that's a neat idea, but people must know about it, so let's make it explicit in the documentation".
> >
> >Haha, I think back then there were much more serious issues with D, like abundant segfaults and a development team of ~2.
> 
> It's not like adding two sentences describing this would take forever.

Seriously, this thread has gone on wayyyyy too long with no real work being done. So I decided to actually do something about it.

	https://github.com/D-Programming-Language/dlang.org/pull/624

There, now the deed is done. Now let the destruction proceed. :-P


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater learning.

On Fri, Aug 01, 2014 at 10:39:44AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 8/1/14, 9:25 AM, Timon Gehr wrote:
> >Even then, such a semantics is non-standard and almost nobody else knew.
> 
> This notion of "standard" has been occasionally mentioned in this discussion. I agree that D's assert is different from traditional C and C++ assert, and I also agree that might surprise some, but I think the meaning of D's assert is well within the intent of the larger notion.
> 
> >Why break 'assert' now, now that it actually behaves as I and many
> >others expect (even some of those who argued for the (apparently,
> >even inofficially) new and opposite design)?
> 
> I don't see any breakage of "assert", more like realizing more of its latent potential. Clearly the documentation could be better, which is something we should focus on.

And to help with said focus, here's where y'all may direct your energy:

	https://github.com/D-Programming-Language/dlang.org/pull/624

;-)


> I do agree there's stuff that some may find unexpected, such as:
> 
> assert(x > 42);
> if (x <= 42) {
>   // let me also handle this conservatively
>   ...
> } else {
>   // all good, proceed
>   ...
> }
> 
> The D optimizer might actually deem the entire "then" path unreachable in the future, and only compile in the "else" path. Some may find that surprising. For my money I never write code like this, and I consider it incorrect if I review it. You either assert something, or you check it dynamically.

Exactly.


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win are idiots.

On Fri, Aug 01, 2014 at 11:18:47AM -0400, Assaf Gordon via Digitalmars-d wrote:
> Sorry to hijack the thread, but:
> 
> On 07/31/2014 09:27 PM, Walter Bright via Digitalmars-d wrote:
> >
> >If you're brave and want to have some fun, fill up your hard disk so it is nearly full. Now run your favorite programs that read and write files. Sit back and watch the crazy results (far too many programs assume that writes succeed). Operating systems also behave erratically in this scenario, hence the 'brave' suggestion.
> >
> 
> If anyone is interested in simulating I/O errors and nearly-full file
> system on Linux, I can suggest the following scripts:
>  http://git.savannah.gnu.org/cgit/datamash.git/tree/build-aux/create_corrupted_file_system.sh
>  http://git.savannah.gnu.org/cgit/datamash.git/tree/build-aux/create_small_file_system.sh
> 
> The scripts create two ext3 images which can be mounted, and simulate
> I/O errors.
> One simulate file system with corrupted files (so "open" and the first
> "read" will succeed, but later "read" will fail with EIO),
> and the other simulate a tiny filesystem, so that the first few
> "writes" will succeed, but "write" of >40KB will fail with ENOSPC.
> 
> The scripts themselves don't require root, but you'll need root to mount the images.
> 
> As Walter said, it's alarming how many programs fail to handle such cases (though D is pretty solid in that regard).
[...]

Very nice! Thanks for sharing. I will keep this in mind next time when I want to stress-test my program. :-)


T

-- 
Век живи - век учись. А дураком помрёшь.