dmd -betterC
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.
Re: dmd -betterC
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/qcbicxrtmjmwiljsy...@forum.dlang.org
Re: dmd -betterC
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!
Re: dmd -betterC
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.
Re: dmd -betterC
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/qcbicxrtmjmwiljsy...@forum.dlang.org Convenience is everything!
Re: dmd -betterC
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?
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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?
Re: dmd -betterC
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
Re: dmd -betterC
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
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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
Re: dmd -betterC
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
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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)
Re: dmd -betterC
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.)
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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
Re: dmd -betterC
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/
Re: dmd -betterC
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.
Re: dmd -betterC
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!"
Re: dmd -betterC
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
Re: dmd -betterC
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
Re: dmd -betterC
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.
Re: dmd -betterC
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/
Re: dmd -betterC
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.
Re: dmd -betterC
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?
Re: dmd -betterC
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.digitalmar...@puremagic.com [2] http://fluentasserts.szabobogdan.com/ [3] http://forum.dlang.org/post/mailman.3511.1497981037.31550.digitalmar...@puremagic.com
Re: dmd -betterC
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.
Re: dmd -betterC
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".
Re: dmd -betterC
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?
Re: dmd -betterC
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/vgxvdpqcjobngmzrv...@forum.dlang.org
Re: dmd -betterC
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
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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.
Re: dmd -betterC
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 (0x7ffe4b3fc000)
libpthread.so.0 => /lib64/libpthread.so.0
(0x7fabb78f6000)
libm.so.6 => /lib64/libm.so.6 (0x7fabb75f3000)
librt.so.1 => /lib64/librt.so.1 (0x7fabb73ea000)
libdl.so.2 => /lib64/libdl.so.2 (0x7fabb71e6000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1
(0x7fabb6fd)
libc.so.6 => /lib64/libc.so.6 (0x7fabb6c04000)
/lib64/ld-linux-x86-64.so.2 (0x5595dec5f000)
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.
Re: dmd -betterC
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)...
Re: dmd -betterC
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
Re: dmd -betterC
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
