Am Fri, 1 Aug 2014 23:20:02 +1000
schrieb "Daniel Murphy" <yebbliesnospam@gmail.com>:

> "Johannes Pfau"  wrote in message news:lrfqqt$1jem$1@digitalmars.com...
> 
> > Which symbols are
> > actually used in the final executable is up to the linker and not
> > standardized.
> 
> Isn't it?  dmd will set it up so the definitions in the library will only get pulled in if undefined, and this will usually mean any definitions in the main object files will override the library ones. It should work this way on all platforms.

Do you know if linkers actually guarantee that behaviour? AFAICS dmd doesn't do anything special, it always emits weak symbols and just calls gcc to link. The linker usually uses the first symbol it sees, but I have not seen any guarantees for that.

Also what happens if your main application doesn't use the template, but two libraries use the same template. Then which instances are actually used? I'd guess those from the 'first' library?

> Of course, definitions in different object files will be subject to comdat folding and that is not standardized.
> 

On Friday, 1 August 2014 at 14:26:35 UTC, Dicebot wrote:
> On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
>> 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.
>
> As a consequence of this thread I think I am going to change the way DMD is packaged on Arch Linux to at least use -debuglib :) Right we don't provide even that...

Wasn't it a common practice? See e.g. http://wxwidgets.blogspot.com/2012/08/how-to-use-294-wxmsw-binaries.html

On Friday, 1 August 2014 at 15:23:03 UTC, Kagamin wrote:
> On Friday, 1 August 2014 at 14:26:35 UTC, Dicebot wrote:
>> On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
>>> 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.
>>
>> As a consequence of this thread I think I am going to change the way DMD is packaged on Arch Linux to at least use -debuglib :) Right we don't provide even that...
>
> Wasn't it a common practice? See e.g. http://wxwidgets.blogspot.com/2012/08/how-to-use-294-wxmsw-binaries.html

Right now I mostly mimic content of basic .zip distribution and it does not provide debug phobos builds.

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).

Hope this helps,
 - Assaf

Am 01.08.2014 16:58, schrieb Andrei Alexandrescu:
>
> You may dislike what Walter wanted assert to be, but really this has
> been it from the beginning. Back in the day when I joined him I
> questioned the validity of making "assert" a keyword. He explained that
> he wanted it to be magic in the same way he discusses in this thread.
>

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".

This seems to be the main problem here: people assumed that assert() behaves like in in C, where it's defined to be a noop when they're deactivated, which pretty much forbids using them for optimizations.
So they wanted an assume() that gives the compiler hints about what it can assume a variable to be. Of course it would be desirable if in debug builds assume() would imply assert() so one can find out if those assumptions are not met while testing.
With that (C style) mindset, one would not be surprised if the program behaves in an undefined way if an assume() condition is not met at runtime - but one is very much surprised about undefined behavior when a (deactivated!) assert() condition is not met.

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.

Cheers,
Daniel

On 08/01/2014 06:36 AM, Walter Bright wrote:
> On 7/31/2014 6:37 PM, H. S. Teoh via Digitalmars-d wrote:
>> But if we do that, then assume() starts to sound more and more like
>> assert()...
>
> I see that my posts are starting to work :-)
>

No, you are suffering from confirmation bias.

"Johannes Pfau"  wrote in message news:lrgar7$1vrr$1@digitalmars.com...

> Do you know if linkers actually guarantee that behaviour? AFAICS dmd
> doesn't do anything special, it always emits weak symbols and just calls
> gcc to link. The linker usually uses the first symbol it sees, but I
> have not seen any guarantees for that.

Yes, they do.  Or at least, it's the classic linker behaviour and I expect they all implement it.  It's relied upon for nofloat and a few other things. It's one of the reasons linkers are hard to parallelize.

dmd does split single d modules into multiple object modules when compiling with -lib, although I think that's fairly standard.

> Also what happens if your main application doesn't use the template,
> but two libraries use the same template. Then which instances are
> actually used? I'd guess those from the 'first' library?

Well, the first one that it encounters after getting the undefined reference.

eg
module application
{
undef x
...
}


lib1:
module a
{
undef tmpl
def a
}
module tmpl
{
def tmpl
}

lib2:
module x
{
undef tmpl
def x
}
module tmpl
{
def tmpl
}

Here nothing that the application references will cause the tmpl in lib1 to get pulled in, but when it processes lib2 it will pull in x, and then tmpl. 

On 08/01/2014 06:42 AM, Tofu Ninja wrote:
> On Friday, 1 August 2014 at 04:36:13 UTC, Walter Bright wrote:
>> On 7/31/2014 6:37 PM, H. S. Teoh via Digitalmars-d wrote:
>>> But if we do that, then assume() starts to sound more and more like
>>> assert()...
>>
>> I see that my posts are starting to work :-)
>
> I don't think we are arguing for the addition of assume, we are
> arguing about the redefinition of assert to act like assume in
> -release.

Yes, I think what he fails to appreciate is that he is arguing for the introduction of 'assume' in -release mode as a stealth operation by redefining the conventional meaning of 'assert', and that arguing against the introduction of 'assume' because it is redundant with the new 'assert' is not relevant.

On 08/01/2014 04:58 PM, Andrei Alexandrescu wrote:
>>
>> assume:
>> passes a hint to the optimizer to allow better code generation.
>> is used when the expression is proven to be true (by the programmer,
>> like @trusted).
>
> There are a few corrections needed for "assert", i.e. "is a runtime
> check of the condition in debug mode". The whole "believed true but not
> proven so" is... odd, seeing as assert takes expressions that are
> considered tautological within the design,

Maybe _somebody_ does not know what the entire design actually is, or what all its implications are.

> and sometimes provable
> automatically (e.g. after inlining).
> ...

Sometimes.

> Anyhow, if "assume" is to be taken at face value the its semantics has
> always been what Walter intended for "assert".

Even then, such a semantics is non-standard and almost nobody else knew.
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)?

> (Again "proven to be
> true" is an eyebrow raiser because when one thinks of "proof" of
> semantics of programs

I think he was using a very relaxed notion of proof, and he exemplified that by drawing an analogy to @trusted.

> one thinks of state analysis or progress and
> preservation and such.)

Progress and preservation are about soundness of the type system of the programming language, not program correctness. @safe may be seen to strive for progress and preservation conditional on it holding for @trusted functions. Your position has always been that @safe and @trusted represent a useful distinction, and this case is analogous (if different!).

"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.

> 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.