www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd -betterC

reply Walter Bright <newshound2 digitalmars.com> writes:
Is getting a whole lot better:

https://github.com/dlang/dmd/pull/6918

You can now build D executables that do not link in anything from Phobos - only 
from the standard C library.
Jun 19 2017
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:

 Is getting a whole lot better:

 https://github.com/dlang/dmd/pull/6918

 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


To be fair, this is not new, just more convenient :)

http://forum.dlang.org/post/qcbicxrtmjmwiljsyhdf forum.dlang.org
Jun 19 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/19/2017 6:53 PM, Vladimir Panteleev wrote:

 To be fair, this is not new, just more convenient :)
 
 http://forum.dlang.org/post/qcbicxrtmjmwiljsyhdf forum.dlang.org


Convenience is everything!
Jun 19 2017
prev sibling next sibling parent 9il <ilyayaroshenko gmail.com> writes:
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:

 Is getting a whole lot better:

 https://github.com/dlang/dmd/pull/6918

 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


Thanks!
Jun 19 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:

 Is getting a whole lot better:


It looks to me that this patch does two things:

1) -betterC now implies -defaultlib=
2) -betterC omits the call to _d_dso_registry


And I see a previous patch is also in there that uses C's 
`assert` instead of D's with -betterC. (frankly, I like the C one 
better anyway!)


So these are baby steps toward making -betterC actually useful, 
but just baby steps.

To all, I'd hold off on posting this to external forums until 
more of the open bugzilla issues are changed (I saw Walter 
tagging them earlier today, so I know they are on his radar).

Importantly, at a minimum, structs need to just work with 
`-betterC` before I'd announce it to the outside world. Once that 
happens, then I think we have something to talk about.... so 
getting closer, but not quite to the point where I'm excited yet.
Jun 19 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/19/2017 7:55 PM, Adam D. Ruppe wrote:

 To all, I'd hold off on posting this to external forums until more of the open 
 bugzilla issues are changed (I saw Walter tagging them earlier today, so I
know 
 they are on his radar).


https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=betterc&keywords_type=allwords&list_id=215478&query_format=advanced



 Importantly, at a minimum, structs need to just work with `-betterC` before
I'd 
 announce it to the outside world.


Which issue is that?
Jun 19 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 June 2017 at 03:54:13 UTC, Walter Bright wrote:

 Which issue is that?


There isn't a specific bugzilla entry, but the very first one on 
your list mentions it:
https://issues.dlang.org/show_bug.cgi?id=11881

and it is caused by typeinfo:
https://issues.dlang.org/show_bug.cgi?id=14758


I wrote about it in more depth in TWID:
http://arsdnet.net/this-week-in-d/2016-oct-09.html

We're about half way to my minimum win condition described there.
Jun 19 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/19/2017 9:08 PM, Adam D. Ruppe wrote:

 On Tuesday, 20 June 2017 at 03:54:13 UTC, Walter Bright wrote:

 Which issue is that?


 
 There isn't a specific bugzilla entry, but the very first one on your list 
 mentions it:
 https://issues.dlang.org/show_bug.cgi?id=11881


There's a lot mentioned there. Can you be more specific? 11881 is all over the 
map and should be closed, with any remaining problems posted as individual 
actionable bugzilla issues. Can you do this?


 and it is caused by typeinfo:
 https://issues.dlang.org/show_bug.cgi?id=14758
 
 
 I wrote about it in more depth in TWID:
 http://arsdnet.net/this-week-in-d/2016-oct-09.html


Please file bugzilla issues for remaining problems.
Jun 19 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 June 2017 at 04:45:21 UTC, Walter Bright wrote:

 Please file bugzilla issues for remaining problems.


I'll do you one better: https://github.com/dlang/dmd/pull/6922

It is a trivial patch to hack fix the big issue I have. Then the 
real fix is what Lucia is working on, based on her dconf talk. 
But since betterC is a hack fix in the first place, I say pull 
that in with your PR and together, we have a *working* "better C".

Then, the last thing from my complaint list (which I wrote in 
TWID and emailed to you back October) is that struct destructors 
don't work....
Jun 21 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 21 June 2017 at 15:37:03 UTC, Adam D. Ruppe wrote:

 Then, the last thing from my complaint list (which I wrote in 
 TWID and emailed to you back October) is that struct 
 destructors don't work....


https://github.com/dlang/dmd/pull/6923


If you want bugzilla entries you can make them yourself from the 
patches. But these two follow up fix the issues I laid out in 
that first one you linked to earlier.
Jun 21 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2017 9:24 AM, Adam D. Ruppe wrote:

 If you want bugzilla entries


It isn't a question of me "wanting" bugzilla entries or me "liking" bugzilla
(as 
another member recently put it). It's our process so that issues can be logged, 
tracked, changelogs compiled, etc. Please follow our process.



 you can make them yourself from the patches.


I can do everything. But that doesn't scale at all, and progress on D would 
grind to a virtual halt if I tried.
Jun 21 2017
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 21 June 2017 at 15:37:03 UTC, Adam D. Ruppe wrote:

 we have a *working* "better C".



I applied my two PRs along with Walter's patch and now have 
runtimeless D actually working.


Take a look at this:

----
// dmd still assumes these are present
// and they are in the C lib, but no without it
extern(C) void _Unwind_Resume() { asm { int 3; } }
extern(C) void __assert(bool c, in char* msg) {}


struct Foo {
	int x;
	char y;
	Foo* next;

	~this() {
     		printf("goodbye world %d\n", x);
	}
}

enum Test {
	a, b
}

extern (C) int main(char** argv, int argc) {
	scope(exit) printf("cruel world\n");
	try {
		Foo foo;
		foo.x = 10;

		int[6] buffer;
		int[] bar = buffer[1 .. 4];

		printf("hello world %d\n", foo.x);
	} finally {
		printf("sweet\n");
	}
	//assert(argc > 4, "foo");
	return 0;
}

void printf(T...)(string a, T t) {
	write(a);
	char[16] buffer;
	foreach(arg; t)
		write(intToString(arg, buffer[]));
}


char[] intToString(int i, char[] buffer) {
	int pos = cast(int) buffer.length - 1;

	if(i == 0) {
		buffer[pos] = '0';
		pos--;
	}

	while(pos > 0 && i) {
		buffer[pos] = (i % 10) + '0';
		pos--;
		i /= 10;
	}

	return buffer[pos + 1 .. $];
}


void write(in char[] a) {
	auto sptr = a.ptr;
	auto slen = a.length;
	size_t fd = 1;
	version(D_InlineAsm_X86)
	asm {
		mov ECX, sptr;
		mov EDX, slen;
		mov EBX, fd;
		mov EAX, 4; // sys_write
		int 0x80;
	}
	else version(D_InlineAsm_X86_64)
	asm {
		mov RSI, sptr;
		mov RDX, slen;
		mov RDI, fd;
		mov RAX, 1; // sys_write
		syscall;
	}
}

extern(C) void _start() {
	size_t code = main(null, 0);

	version(D_InlineAsm_X86)
	asm {
		mov EAX, 1; // sys_exit
		mov EBX, code;
		int 0x80;
	}
	else version(D_InlineAsm_X86_64)
	asm {
		mov RAX, 60; // sys_exit
		mov RDI, code;
		syscall;
	}
}
----





src/dmd hello.d -I../druntime/import -betterC -release -c
ld hello.o -nostdlib
$ ls -lh a.out
-rwxr-xr-x 1 me users 2.5K Jun 21 22:13 a.out
$ ldd a.out
         not a dynamic executable



Wow. If you remember my old minimal.d, it took about 15 lines of 
stub runtime to even get it to compile.... and was still 3.3 K in 
my best attempt.

Now it works - including structs with dtors (if you have my two 
PRs merged) - and makes a tiny 2.5 K exe (on Linux here), with 
zero dependencies. This could run on bare metal. I've done that 
before, but never this simple.

* * *

What about using the C library?

---
import core.stdc.stdio;

struct Test {
	int x;
	int y;

	this(int x, int y) {
		this.x = y;
		this.y = y;
		printf("Constructed\n");
		foo();
	}

	~this() {
		printf("Destructed\n");
		foo();
	}

	void foo() {
		printf("Values are: %d, %d\n", x, y);
	}
}

extern(C) int main() {
	printf("Hello!\n");
	scope(exit) printf("Bye!\n");

	Test test = Test(10, 20);
	test.x += 45;
	test.foo();

	return 0;
}
---


Look at that - looks like a reasonably useful program, with 
structs, printing, members, even a destructor. How hard was it to 
build?


$ src/dmd hello2.d -betterC  -I../druntime/import
$ ./hello2
Hello!
Constructed
Values are: 20, 20
Values are: 65, 20
Destructed
Values are: 65, 20
Bye!

$ ls -lh hello2
-rwxr-xr-x 1 me users 11K Jun 21 22:18 hello2
$ ldd hello2
         linux-vdso.so.1 (0x00007ffe4b3fc000)
         libpthread.so.0 => /lib64/libpthread.so.0 
(0x00007fabb78f6000)
         libm.so.6 => /lib64/libm.so.6 (0x00007fabb75f3000)
         librt.so.1 => /lib64/librt.so.1 (0x00007fabb73ea000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00007fabb71e6000)
         libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 
(0x00007fabb6fd0000)
         libc.so.6 => /lib64/libc.so.6 (0x00007fabb6c04000)
         /lib64/ld-linux-x86-64.so.2 (0x00005595dec5f000)


11K executable, linking in standard C stuff.


With my PRs combined with Walter's, we actually have something 
useful here.

Note that I used -release on the top program because otherwise 
there's linker errors for array bounds checks. I am 100% happy 
with this behavior.
Jun 21 2017
prev sibling next sibling parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:

 Is getting a whole lot better:

 https://github.com/dlang/dmd/pull/6918

 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


While it's encouraging to see some attation given to this 
feature, I think the fundamental premise motivating -betterC is 
misguided.

Rather than requiring a switch that bluntly disables certain 
features of the language, the compiler and/or linker should 
simply not require implementations that aren't explicitly or 
implicitly used.  For example, if one is not doing any dynamic 
casting or other runtime inspection, the toolchain should not 
throw any errors about a missing TypeInfo implementation, and the 
toolchain certainly shouldn't add automatically generated 
TypeInfo implementations to the binary that have no hope of every 
being referenced or executed.

As I understand it, this requires some cooperation between the 
compiler and the linker.  For example, the compiler may not be 
able to determine whether or not a certain language feature or 
implementation is required, so it will include a link to it 
anyway in the intermediate object file, but the linker will be 
able to see that there is no possible logic path to that code in 
the final binary, and can strip it out rather than generate an 
unresolved symbol error.  GCC's 
-ffunction-sections/-fdata-sections and ld's --gc-sections do 
this quite well, though better implementations may also be 
possible with LTO features.

I think all features of D have their place even in bare metal and 
resource constrained microcontroller programming.  For example, 
despite the disdain from others, I use C++ exceptions in much of 
my microcontroller programming because it makes the "happy path" 
a little bit faster at the expense of making the "unhappy path" 
(whose performance doesn't matter) much slower.  It also makes my 
code much easier to reason about, and escape out of when 
something goes wrong.

Similarly, I can also see TypeInfo and ModuleInfo being useful 
for certain applications.  For example, ModuleInfo and module 
constructors may be a good way to initialize peripherals before 
calling main().  However, the toolchain shouldn't require 
TypeInfo and ModuleInfo to always be there just to get a build 
when they have no chance of ever being referenced or executed in 
the final binary.

If one wanted to avoid certain druntime dependencies, they should 
be able to simply avoid those features of D in their source code 
for which there is no runtime implementation (e.g. exceptions, 
classes, AAs, etc...) or provide their own implementation 
embedded in their code that overrides the druntime implementation.

On a system with a full desktop-like operating system it would be 
convenient to automatically link in druntime and maybe Phobos, 
but that should be done on a platform-by-platform basis in either 
a dmd.conf, linker script, or some other similar configuration 
file that is distributed with the toolchain's package.

I think it would be better to refactor the DMD and druntime 
implementations to reduce their coupling and improve their 
cooperation with the linker and LTO features.  In doing so, a 
-betterC switch would be rendered redundant and ultimately 
needless.

Mike
Jun 19 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/19/2017 11:28 PM, Mike wrote:

 As I understand it, this requires some cooperation between the compiler and
the 
 linker.


We don't control the linker. We could do a lot if we did, but we don't.
Jun 20 2017
next sibling parent reply Mike <none none.com> writes:
On Tuesday, 20 June 2017 at 08:31:30 UTC, Walter Bright wrote:

 On 6/19/2017 11:28 PM, Mike wrote:

 As I understand it, this requires some cooperation between the 
 compiler and the linker.


 We don't control the linker. We could do a lot if we did, but 
 we don't.


I know, but you do know what linker features exists and how the 
linker works, and could generate better intermediate code that 
could allow the linker to more effectively identify and remove 
dead code.
Jun 20 2017
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 20 June 2017 at 08:36:38 UTC, Mike wrote:

 I know, but you do know what linker features exists and how the 
 linker works, and could generate better intermediate code that 
 could allow the linker to more effectively identify and remove 
 dead code.


You can write a linker wrapper that will do the analysis you 
want, remove unneeded sections, stub symbols etc, see basic 
technique at 
https://theartofmachinery.com/2016/12/18/d_without_runtime.html
Jun 20 2017
parent sarn <sarn theartofmachinery.com> writes:
On Tuesday, 20 June 2017 at 17:30:43 UTC, Kagamin wrote:

 You can write a linker wrapper that will do the analysis you 
 want, remove unneeded sections, stub symbols etc, see basic 
 technique at 
 https://theartofmachinery.com/2016/12/18/d_without_runtime.html


I keep meaning to write an update to that post because there have 
been a lot of improvements to the ecosystem since then.  (I've 
been kind of busy the past few months.)
Jun 20 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2017 1:31 AM, Walter Bright wrote:

 On 6/19/2017 11:28 PM, Mike wrote:

 As I understand it, this requires some cooperation between the compiler and 
 the linker.


 
 We don't control the linker. We could do a lot if we did, but we don't.


To clarify, I have experience writing and working with linkers. Doing one is a 
full time job for a team of one alpha programmer + a couple regular ones. You 
might think a linker is easy, and conceptually it is. The trouble comes from
all 
the undocumented behaviors it is expected to do exhibit. Worse, these 
expectations change constantly without warning.

And lastly, we support lots of platforms. Multiply the above by the number of 
platforms.

It's not practical for us.
Jun 20 2017
prev sibling next sibling parent reply ixid <adamsibson gmail.com> writes:
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:

 Is getting a whole lot better:

 https://github.com/dlang/dmd/pull/6918

 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


How far away from a purely additive, pay for what we use 
situation are we? It would seem like D should be BetterC out of 
the box, without needing any switches and as you add and use 
specific features and libraries it builds from that.
Jun 20 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2017 2:00 AM, ixid wrote:

 How far away from a purely additive, pay for what we use situation are we? It 
 would seem like D should be BetterC out of the box, without needing any
switches 
 and as you add and use specific features and libraries it builds from that.


As long as the compiler supports separate compilation, it has to emit certain 
information that may or may not be used by other modules.

For example, the list of imported modules, which is used by the startup code to 
determine the order of static construction. The compiler cannot know which of 
those will have static constructors and which won't.
Jun 20 2017
parent ixid <adamsibson gmail.com> writes:
On Tuesday, 20 June 2017 at 09:21:05 UTC, Walter Bright wrote:

 On 6/20/2017 2:00 AM, ixid wrote:

 How far away from a purely additive, pay for what we use 
 situation are we? It would seem like D should be BetterC out 
 of the box, without needing any switches and as you add and 
 use specific features and libraries it builds from that.


 As long as the compiler supports separate compilation, it has 
 to emit certain information that may or may not be used by 
 other modules.

 For example, the list of imported modules, which is used by the 
 startup code to determine the order of static construction. The 
 compiler cannot know which of those will have static 
 constructors and which won't.


How much of that could be made lazy?
Jun 20 2017
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-20 03:51, Walter Bright wrote:

 Is getting a whole lot better:
 
 https://github.com/dlang/dmd/pull/6918
 
 You can now build D executables that do not link in anything from Phobos 
 - only from the standard C library.


BTW, how are asserts handled? Isn't assert usually a macro in C?

-- 
/Jacob Carlborg
Jun 20 2017
next sibling parent Meta <jared771 gmail.com> writes:
On Tuesday, 20 June 2017 at 11:52:56 UTC, Jacob Carlborg wrote:

 On 2017-06-20 03:51, Walter Bright wrote:

 Is getting a whole lot better:
 
 https://github.com/dlang/dmd/pull/6918
 
 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


 BTW, how are asserts handled? Isn't assert usually a macro in C?


I was curious about this as well when I saw the PR.

Great to see that -betterC is getting some attention as well.
Jun 20 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2017 4:52 AM, Jacob Carlborg wrote:

 BTW, how are asserts handled? Isn't assert usually a macro in C?


https://github.com/dlang/dmd/pull/6901
Jun 20 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 June 2017 at 20:50:14 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/6901


We should generate the default string from the expression for D 
too. (at a minimum, I'd actually like to see every variable 
printed out too, but this is already written)
Jun 20 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2017 3:07 PM, Adam D. Ruppe wrote:

 On Tuesday, 20 June 2017 at 20:50:14 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/6901


 
 We should generate the default string from the expression for D too. (at a 
 minimum, I'd actually like to see every variable printed out too, but this is 
 already written)


Those strings eat up space and are of pretty marginal utility. Don't want to 
make assert's so bloatsome that people are discouraged from using them.
Jun 20 2017
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Walter Bright wrote:


 On 6/20/2017 3:07 PM, Adam D. Ruppe wrote:

 On Tuesday, 20 June 2017 at 20:50:14 UTC, Walter Bright wrote:

 https://github.com/dlang/dmd/pull/6901


 We should generate the default string from the expression for D too. (at 
 a minimum, I'd actually like to see every variable printed out too, but 
 this is already written)


 Those strings eat up space and are of pretty marginal utility. Don't want 
 to make assert's so bloatsome that people are discouraged from using them.


nope, they aren't. but they are immediately helpful. i integrated such 
patch to my dmd ages ago, and i'm not speaking out of nothing -- they *are*
helful.

and i can't see how *adding* *useful* *info* to assertion will discourage 
people from using 'em.

"bloatsome"? i don't think so. those generated messages is small (usually 
20-30 bytes), and nothing comparing to druntime/phobos size.
Jun 20 2017
parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Wednesday, 21 June 2017 at 03:57:46 UTC, ketmar wrote:

 "bloatsome"? i don't think so. those generated messages is 
 small (usually 20-30 bytes), and nothing comparing to 
 druntime/phobos size.


Yeah, but what if you're already working without runtime and 
phobos?
(some embedded systems only have 32Kb program memory, and yes 
these are up-to-date ones)

Would it help to formalize the interface between compiler 
generated code and druntime? (IIRC this is implementation 
specific at the moment).

The idea is to make it easier to only reimplement and provide the 
runtime parts that are actually needed ; and to rely on link 
errors to prevent forbidden D constructs.
Jun 20 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Sebastien Alaiwan wrote:


 On Wednesday, 21 June 2017 at 03:57:46 UTC, ketmar wrote:

 "bloatsome"? i don't think so. those generated messages is small 
 (usually 20-30 bytes), and nothing comparing to druntime/phobos size.


 Yeah, but what if you're already working without runtime and phobos?


it doesn't matter, `assert()` is impemented as `throw` anyway. and in 
"betterc" mode compiler can just omit generation of such messages, 
resorting to what it does now.


 (some embedded systems only have 32Kb program memory, and yes these are 
 up-to-date ones)


asserts on embedded systems? O_O code built without -release for embedded 
systems? O_O
Jun 20 2017
parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Wednesday, 21 June 2017 at 05:35:42 UTC, ketmar wrote:

 asserts on embedded systems? O_O code built without -release 
 for embedded systems? O_O


embedded system != production system.

You still need to debug the code, and at some point, you have to 
load it on a real microcontroller ; this is where some of your 
assumptions about how the chip works might turn out to be false.

This is where it gets tricky. Because now you need to fit the 
memory requirements, and at the same time, you want some level of 
diagnostic.

And by the way, you might want to keep boundschecking code, even 
in production. In some situations, it's preferable to crash/hang 
than outputing garbage.
Jun 20 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Sebastien Alaiwan wrote:


 On Wednesday, 21 June 2017 at 05:35:42 UTC, ketmar wrote:

 asserts on embedded systems? O_O code built without -release for 
 embedded systems? O_O


 embedded system != production system.

 You still need to debug the code, and at some point, you have to load it 
 on a real microcontroller ; this is where some of your assumptions about 
 how the chip works might turn out to be false.


as i said, in "betterc" mode compiler can omit generation of assert 
condition strings.

but refusing to generate such strings for *all* code in favor of embedded 
cases is like "let's remove classes and exceptions from D, 'cause they're 
too costly for embedded code!"
Jun 20 2017
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote:

 but refusing to generate such strings for *all* code


They are not useful enough for that, in 99% of cases location of 
assert is enough to know what's wrong, when it isn't, the string 
is not going to tell where it went wrong, so you need to debug 
it, in which case there's no difference again. Don't fluent 
asserts already do what you want? See 
http://fluentasserts.szabobogdan.com/
Jun 21 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Kagamin wrote:


 On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote:

 but refusing to generate such strings for *all* code


 They are not useful enough for that, in 99% of cases location of assert 
 is enough to know what's wrong, when it isn't, the string is not going to 
 tell where it went wrong, so you need to debug it, in which case there's 
 no difference again.


there, of course, *IS* The difference. besides the aesthetical one (seeing 
failed condition immediately "clicks" in your head, and generic "assertion 
failed" message is only frustrating), there may be the case when source 
code changed since binary was built. here, line number gives you zero 
information, and you have to checkout that exact version, and go check the 
line. but when failed condition dumped, most of the time it allows you to 
see what is wrong even without switching to the old codebase (yes, "most of 
the time" is from RL -- it is literally *most* of the time for me, for 
example).



 Don't fluent asserts already do what you want? See 
 http://fluentasserts.szabobogdan.com/


nope. those aren't assertions at all, compiler cannot even remove 'em with 
"-release" flag (not that i'm using it much, but still no, thanks).

mind you, assertions is not only for unittesting.
Jun 21 2017
parent reply MysticZach <reachzach ggmail.com> writes:
On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:

 there, of course, *IS* The difference. besides the aesthetical 
 one (seeing failed condition immediately "clicks" in your head, 
 and generic "assertion failed" message is only frustrating), 
 there may be the case when source code changed since binary was 
 built. here, line number gives you zero information, and you 
 have to checkout that exact version, and go check the line. but 
 when failed condition dumped, most of the time it allows you to 
 see what is wrong even without switching to the old codebase 
 (yes, "most of the time" is from RL -- it is literally *most* 
 of the time for me, for example).


How would you solve this issue? By pure chance, we're debating 
this exact same issue right now in the DIP1009 thread [1].

Solutions:

  1. Make more informative asserts the compiler default. This 
threatens performance, which argues against it.

  2. Status quo. Make people use whatever asserts they want, e.g. 
fluent asserts [2]. This would mean that H.S Teoh's proposed 
syntax for DIP1009 [3] would carry less weight, and the existing 
proposal would carry more. Elegance is sacrificed for the sake of 
versatility.

  3. Allow an additional compiler flag for more informative, but 
heavier asserts, e.g. `-release=informativeAsserts`.

  4. Allow a pragma in the code, e.g. `pragma(asserts, 
none/regular/informative)` for what kinds of asserts are to be 
used at a given moment.

  5. ???

[1] 
http://forum.dlang.org/post/mailman.3531.1498022870.31550.digitalmars-d puremagic.com
[2] http://fluentasserts.szabobogdan.com/
[3] 
http://forum.dlang.org/post/mailman.3511.1497981037.31550.digitalmars-d puremagic.com
Jun 21 2017
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
MysticZach wrote:


 On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:

 there, of course, *IS* The difference. besides the aesthetical one 
 (seeing failed condition immediately "clicks" in your head, and generic 
 "assertion failed" message is only frustrating), there may be the case 
 when source code changed since binary was built. here, line number gives 
 you zero information, and you have to checkout that exact version, and 
 go check the line. but when failed condition dumped, most of the time it 
 allows you to see what is wrong even without switching to the old 
 codebase (yes, "most of the time" is from RL -- it is literally *most* 
 of the time for me, for example).


 How would you solve this issue?


i did in aliced: just added printing of `assert` condition. that's all. no 
variable dumps, no other things -- just `.toChar()` the condition, and 
print it. and you know what? it is *surprisingly* effective, eats *no* 
additional compiler resources, and solved all the problems with "dumb 
asserts" i had.

for some reason people insisting on printing every thing that is possible 
to print in `assert`. it is rarely interesting IRL, 'cause most of the time 
it will print nonsence anyway. failed assert usually means either that 
something went *very* wrong long before it, or it is almost immediately 
obvious *what* exactly is wrong, without dumping garbage variables.
Jun 21 2017
parent Kagamin <spam here.lot> writes:
On Wednesday, 21 June 2017 at 14:00:33 UTC, ketmar wrote:

 i did in aliced: just added printing of `assert` condition. 
 that's all. no variable dumps, no other things -- just 
 `.toChar()` the condition, and print it. and you know what? it 
 is *surprisingly* effective, eats *no* additional compiler 
 resources, and solved all the problems with "dumb asserts" i 
 had.


You use it to locate the assert?
Jun 21 2017
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
p.s.: `assert` is not there to debug your code, it is there to *guard* your 
code. if it is not clear what is wrong from printing ONLY failed condition 
(without variable values), then you have to debug it "for real".
Jun 21 2017
prev sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Wednesday, 21 June 2017 at 13:53:02 UTC, MysticZach wrote:

 On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:

 there, of course, *IS* The difference. besides the aesthetical 
 one (seeing failed condition immediately "clicks" in your 
 head, and generic "assertion failed" message is only 
 frustrating), there may be the case when source code changed 
 since binary was built. here, line number gives you zero 
 information, and you have to checkout that exact version, and 
 go check the line. but when failed condition dumped, most of 
 the time it allows you to see what is wrong even without 
 switching to the old codebase (yes, "most of the time" is from 
 RL -- it is literally *most* of the time for me, for example).


 How would you solve this issue? By pure chance, we're debating 
 this exact same issue right now in the DIP1009 thread [1].

 Solutions:

  1. Make more informative asserts the compiler default. This 
 threatens performance, which argues against it.

  2. Status quo. Make people use whatever asserts they want, 
 e.g. fluent asserts [2]. This would mean that H.S Teoh's 
 proposed syntax for DIP1009 [3] would carry less weight, and 
 the existing proposal would carry more. Elegance is sacrificed 
 for the sake of versatility.

 [...]


The verbose (existing) syntax already allows such versatility. I 
see little reason to make the new syntax support that as well, 
since there is (AFAIK) no proposal to drop the verbose syntax 
(and I would be against dropping it, anyway).
I would prefer this:
- Keep the verbose (already existing) syntax with assert 
statements in brace-delimited in/out blocks for people who need 
versatility over elegance
- Make the new syntax elegant for the common cases (as discussed 
in the DIP 1009 round 1 review thread), dropping explicit asserts
- Decouple the semantics of contract checking for the new syntax 
from assert's implementation and define those semantics similar 
to what I wrote here[1]
- Regarding contract conditions printed verbatim on failure: I 
would support that in the implementation sketched by [1] via a D 
version like `PrintViolatedContracts` and not couple that with 
regular asserts at all

[1] 
http://forum.dlang.org/post/vgxvdpqcjobngmzrvnml forum.dlang.org
Jun 21 2017
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 June 2017 at 23:43:47 UTC, Walter Bright wrote:

 Those strings eat up space and are of pretty marginal utility. 
 Don't want to make assert's so bloatsome that people are 
 discouraged from using them.


Ah, so that's why you exclude the strings in -betterC whose main 
reason for existing is targeting resource-limited 
microcontrollers, yet include them now in a default build, which 
is aimed at main computers with gigabytes of space. I understand 
now.


...oh wait it currently does EXACTLY THE OPPOSITE. If you are 
seriously concerned about the bytes, why include them in -betterC?
Jun 21 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2017 6:21 AM, Adam D. Ruppe wrote:

 If you are seriously 
 concerned about the bytes, why include them in -betterC?


All I did was make them do what the host C compiler does.
Jun 21 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 21 June 2017 at 20:11:25 UTC, Walter Bright wrote:

 All I did was make them do what the host C compiler does.


I propose that the reason the host C compiler does it is because 
it is a useful behavior.

If these little strings actually are too large, you can easily 
suppress it by saying `assert(condition, "");` - just pass a 
shorter / reused message in the second argument.
Jun 21 2017
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-20 03:51, Walter Bright wrote:

 Is getting a whole lot better:
 
 https://github.com/dlang/dmd/pull/6918
 
 You can now build D executables that do not link in anything from Phobos 
 - only from the standard C library.


How is TLS handled? I know at least macOS 32bit requires the 
"___tls_get_addr" druntime function. Not sure if anyone cares about 
macOS 32bit.

Does the TLS implementation depend on druntime on any other platforms?

-- 
/Jacob Carlborg
Jun 20 2017
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 20 June 2017 at 11:58:47 UTC, Jacob Carlborg wrote:

 On 2017-06-20 03:51, Walter Bright wrote:

 Is getting a whole lot better:
 
 https://github.com/dlang/dmd/pull/6918
 
 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


 How is TLS handled? I know at least macOS 32bit requires the 
 "___tls_get_addr" druntime function. Not sure if anyone cares 
 about macOS 32bit.


About macOS 32-bit. Am I the only user? Things are OK now.
The older LDCs will work targeting newer macOS 32-bit for a while 
I guess, so maybe 32-bit can be phased out (especially TLS which 
I don't use).
Not sure who else uses it.
Jun 20 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-20 14:11, Guillaume Piolat wrote:


 About macOS 32-bit. Am I the only user?


Yes :)


 Things are OK now. The older LDCs will work targeting newer macOS 32-bit for a
while I
 guess, so maybe 32-bit can be phased out (especially TLS which I don't
 use).


I would guess LDC supports it as long as LLVM does.

BTW, after the next version of macOS, High Sierra, Apple will drop the 
support for 32bit applications. You need to move to 64bit.

-- 
/Jacob Carlborg
Jun 20 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2017 12:06 PM, Jacob Carlborg wrote:

 BTW, after the next version of macOS, High Sierra, Apple will drop the support 
 for 32bit applications. You need to move to 64bit.


I won't miss it.

I don't think it'll be long before 32 bits starts disappearing from Windows and 
Linux as well.

As a pragmatic matter, the D community doesn't have the resources to support 
systems that have been abandoned by their vendors. This is why D officially 
doesn't support Windows XP anymore.
Jun 20 2017
parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 20 June 2017 at 20:48:29 UTC, Walter Bright wrote:

 On 6/20/2017 12:06 PM, Jacob Carlborg wrote:

 BTW, after the next version of macOS, High Sierra, Apple will 
 drop the support for 32bit applications. You need to move to 
 64bit.


 I won't miss it.

 I don't think it'll be long before 32 bits starts disappearing 
 from Windows and Linux as well.


For ldc users on linux, 32-bit x86 compiler downloads are 
basically a rounding error:

http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

ldc 1.1.0 was released with a native linux/ARM build also, the 
stats in that link show it was downloaded almost 30 times more 
than the linux/x86 build.
Jun 20 2017
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 20 June 2017 at 19:06:05 UTC, Jacob Carlborg wrote:

 On 2017-06-20 14:11, Guillaume Piolat wrote:


 About macOS 32-bit. Am I the only user?


 Yes :)


 Things are OK now. The older LDCs will work targeting newer 
 macOS 32-bit for a while I
 guess, so maybe 32-bit can be phased out (especially TLS which 
 I don't
 use).


 I would guess LDC supports it as long as LLVM does.

 BTW, after the next version of macOS, High Sierra, Apple will 
 drop the support for 32bit applications. You need to move to 
 64bit.


Good move from Apple.
I distribute both bitness as Universal Binaries, most probably 
this will still work.
Jun 20 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-06-20 23:30, Guillaume Piolat wrote:


 Good move from Apple.
 I distribute both bitness as Universal Binaries, most probably this will 
 still work.


Yes, as long as the tools continue to support it.

-- 
/Jacob Carlborg
Jun 20 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2017 4:58 AM, Jacob Carlborg wrote:

 How is TLS handled? I know at least macOS 32bit requires the "___tls_get_addr" 
 druntime function. Not sure if anyone cares about macOS 32bit.
 
 Does the TLS implementation depend on druntime on any other platforms?



For a C implementation that doesn't support TLS, using it in D with -betterC 
won't work.
Jun 20 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-20 22:44, Walter Bright wrote:


 For a C implementation that doesn't support TLS, using it in D with 
 -betterC won't work.


I'm thinking more of a C implementation where it *does* work. But 
perhaps you're not expected to do anything besides what you can do in C 
when it comes to TLS.

-- 
/Jacob Carlborg
Jun 20 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2017 11:54 PM, Jacob Carlborg wrote:

 On 2017-06-20 22:44, Walter Bright wrote:
 

 For a C implementation that doesn't support TLS, using it in D with -betterC 
 won't work.


 
 I'm thinking more of a C implementation where it *does* work. But perhaps
you're 
 not expected to do anything besides what you can do in C when it comes to TLS.



It does work with C on Windows, Linux, OSX, and FreeBSD, and so it works with 
-betterC, too.
Jun 21 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-21 09:28, Walter Bright wrote:


 It does work with C on Windows, Linux, OSX, and FreeBSD, and so it works 
 with -betterC, too.


For example, in C there's "__thread" and in C++ there's "thread_local". 
"__thread" doesn't work with all C++ types because it may contain a 
non-trivial default constructor. For C++ types "thread_local" needs to 
be used which I believe requires some help from the runtime.

Does D have any of the those problems? I know it doesn't support default 
constructors but are there issues with other types, i.e. that would 
require support from the D runtime and not just the C runtime?

-- 
/Jacob Carlborg
Jun 22 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/22/2017 1:21 AM, Jacob Carlborg wrote:

 On 2017-06-21 09:28, Walter Bright wrote:
 

 It does work with C on Windows, Linux, OSX, and FreeBSD, and so it works with 
 -betterC, too.


 
 For example, in C there's "__thread" and in C++ there's "thread_local". 
 "__thread" doesn't work with all C++ types because it may contain a
non-trivial 
 default constructor. For C++ types "thread_local" needs to be used which I 
 believe requires some help from the runtime.
 
 Does D have any of the those problems? I know it doesn't support default 
 constructors but are there issues with other types, i.e. that would require 
 support from the D runtime and not just the C runtime?


Static construction is done by the D runtime, and so won't work with -betterC
Jun 22 2017
prev sibling next sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:

 Is getting a whole lot better:

 https://github.com/dlang/dmd/pull/6918

 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


https://www.reddit.com/r/programming/comments/6ijwek/dlangs_dmd_now_compiles_programs_in_betterc_mode/
Jun 20 2017
prev sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:

 Is getting a whole lot better:

 https://github.com/dlang/dmd/pull/6918

 You can now build D executables that do not link in anything 
 from Phobos - only from the standard C library.


Very cool - this plus Adam's changes.

The next logical step for some might be to want to be able to use 
the bits of Phobos that don't necessarily need the runtime.  
Which might be a bad step.  But it's oh so tempting to want to 
have bits that are version(NoRuntime)...
Jun 21 2017