Re: @ctfeonly
On Thursday, 7 December 2017 at 01:18:04 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing? Urgh, this was meant for general. I'll post it there. Please ignore this.
@ctfeonly
I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?
Re: Interfacing D with C: Getting Started
On Wednesday, 6 December 2017 at 08:20:25 UTC, Johan Engelen wrote: Overall I find that it'd be much nicer if you focus on C-D interaction only. Currently you've added a lot of things that people really would already know before reading the text: I think preknowledge should be how to create programs in C and in D (including compilers, etc.). Especially on a second read, it's a lot of scrolling back and forth to find the good nuggets of info. Thanks for the feedback! I'm taking the bits about structure and layout and leaving the bits about content :-) While combining D and C is the focus of the series, the motivation for this specific post is entirely to make sure everyone knows how to generate object files using all the different C compilers. I really want them to compile things themselves as they go along. The bit about c_ulong at the end was something I threw in as an example of what's to come. While I would love to assume that everyone reading will already know how to work with the C command line tools, experience has shown me that is a misplaced assumption. We've got a lot of people coming to D who have never touched C or the command line, or if they have it's been in an IDE and their command line experience is limited. So my intent is to keep the command line minimal and take nothing for granted. FYI, this started as one post that I wrote a few weeks back about C and D strings. But a series of comments here on the forums reminded me of all the issues people keep having with getting D set up on Windows (something that still baffles me, but it is what it is). Then one idea led to another and here we are, with a beginner-level tutorial as the fist post in a series. The next few posts will focus exclusively on the details (arrays, strings, exception handling, calling conventions) and refer those who need it back to this post. I also plan to cover calling D from C, and segue in to a couple about betterC and how the absence of the runtime affects things.
Re: GtkD 3.7.0 released, GTK+ with D.
On Tuesday, 5 December 2017 at 18:38:06 UTC, aberba wrote: On Saturday, 2 December 2017 at 08:17:24 UTC, helxi wrote: [...] I wanted to do this using some examples I have whilst learning it. Its at the bottom of my list of things I love to do. its not difficult though. It's quite close to the C# and Vala bindings If you are doing so, may I suggest you like to publish it in ways that others can help you by contributing to the tutorial? Something like gitbook. It would be great for the community.
Re: Interfacing D with C: Getting Started
On Tuesday, 5 December 2017 at 16:06:19 UTC, Mike Parker wrote: This is the first post in a new tutorial series I'm doing on the blog. Hi Mike, Nice. It's always much easier to comment than to write an article from scratch. So take all this with a grain of salt: Overall I find that it'd be much nicer if you focus on C-D interaction only. Currently you've added a lot of things that people really would already know before reading the text: I think preknowledge should be how to create programs in C and in D (including compilers, etc.). Especially on a second read, it's a lot of scrolling back and forth to find the good nuggets of info. - I would make it clearer that you are discussing calling C code from a D application. If you are going to discuss the other way around too, always make it super clear in which language the "main" part of the program is. Perhaps explain the differences in how to setup a "hello world" (e.g. druntime initialization). - I would remove all related to DMC, it's needless extra complication. - Add a sentence that all should work identically for GDC and LDC, except for the `-m32mscoff` (I think `-m32` or `-m64` is superfluous for LDC). - The text about "both files have the same name" is also needless, I think. You are writing a text about how to call C-code from D-code, using the commandline no less! ;-) Instead, I would add the output filename explicitly on the cmdlines. It's short, and more clearly shows which files are created when. - Commandline invocation and installation of compilers is mixed now; pull it apart for clarity. Fit the installation of compilers in one or two sentences (D and C). - typo: "offical" --> "official" - The code fragments don't need to be packed tight. Perhaps add comments inside them, to beef them up a bit and make them stick out more. (you could add comments about "forward declaration", "definition", ...) - Separate the hello world example into its own section: "see how easy it is?" :-) Ideas: - Idea for future texts: how to set this up using dub, and other build mechanisms like cmake, makefile, IDEs, ... - Perhaps an example of why one might want this, external libraries is what I am thinking. Forward reference to future blog article? (dstep?) Cheers, Johan
