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
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
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
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
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
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
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
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
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
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
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
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; } } ---- # Note that the -I is not necessary if your compiler is # actually installed; I just need it here since it is a # hacked up compiler 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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