www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Add ImportC compiler to dmd

reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/dlang/dmd/pull/12507

If you could add a C compiler to dmd with 3000 lines of code, so C code could
be 
imported directly? I would!
May 09
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
My original plan was to use DMC for this. But looking at the code to it 
dissuaded me. It would have been more work than just starting over again, 
particularly because only the lexer/parser were needed.

Many times people over the years have asked me to port DMC to Linux.
Ironically, 
this actually does that!
May 09
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
This will be incredible. I have a lot of use cases for it. In particular on Windows where linking to DLLs is not fun.
May 09
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 9 May 2021 at 21:50:56 UTC, bachmeier wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
This will be incredible. I have a lot of use cases for it. In particular on Windows where linking to DLLs is not fun.
Can you explain this a bit better? I recall an issue with drepl on Windows was shared library support.
May 09
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 2:50 PM, bachmeier wrote:
 This will be incredible. I have a lot of use cases for it. In particular on 
 Windows where linking to DLLs is not fun.
It never occurred to me that this might be a solution to that problem (rather than adding a bunch of wacky extensions to D). This kind of unexpected benefit is exactly why I'm doing this!
May 09
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 9 May 2021 at 22:36:29 UTC, Walter Bright wrote:
 It never occurred to me that this might be a solution to that 
 problem (rather than adding a bunch of wacky extensions to D).
This doesn't solve anything about dlls. Meanwhile though gdc and ldc will be getting significantly improved support for these cases in a matter of months.
May 09
parent reply bachmeier <no spam.net> writes:
On Sunday, 9 May 2021 at 22:41:23 UTC, Adam D. Ruppe wrote:
 On Sunday, 9 May 2021 at 22:36:29 UTC, Walter Bright wrote:
 It never occurred to me that this might be a solution to that 
 problem (rather than adding a bunch of wacky extensions to D).
This doesn't solve anything about dlls. Meanwhile though gdc and ldc will be getting significantly improved support for these cases in a matter of months.
Time constrained, so short answer: it solves the problem by eliminating the need for them. If I can trivially compile C and D code together then no need to mess around with writing a DLL for an extension. It's a massive difference to give a few files of code to someone else and tell them to compile it with DMD vs telling them to figure out import libraries and language interop and put the DLL in the right directory and use mingw, blah blah blah. If I were giving you the code, none of that would be an obstacle, but the most technical thing some of them have ever done is install Python.
May 09
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
 On Sunday, 9 May 2021 at 22:41:23 UTC, Adam D. Ruppe wrote in 
 github:
This appears completely useless to me. First, it doesn't "just 
work" since you need to run cpp over the file before you can use 
it, and since that expands macros, it must be done for each 
different target, meaning it must be part of the build system. 
This offers no advantage over the (not great) existing solutions 
and shares many of their problems including creating huge files.
Even if that just worked, C bindings tend to rely on the 
preprocessor to do common and necessary tasks like defining 
constants. Without that, you can't even reasonably use real 
world C headers. Possibly a limited processor could translate 
them, but even that data is gone after cpp goes through it, so 
there's no real hope to recover it into a usable form.
I think trying to run the cpp over a whole D file like dpp does 
is problematic... but like something must be done. dstep's 
approach actually does a reasonably good job, at the cost of 
requiring a bit of hand editing and some setting up of other 
files too.
I do think there's some potential in integrating with dmd... but 
this PR as it is looks like more harm than good. And I'm not 
sure it is worth the time sink it will take to get it to a 
positive point.
The advantage of having this built into the compiler itself is that you don't have to rely on a third party library for importing c functions into your d code. Accessibility is the key advantage here. - Alex
May 09
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 10 May 2021 at 00:47:08 UTC, 12345swordy wrote:
 The advantage of having this built into the compiler itself is 
 that you don't have to rely on a third party library for 
 importing c functions into your d code. Accessibility is the 
 key advantage here.
That could be easily done with the existing dpp approach. You could even just make dmd recognize the .dpp extension then shell out to dpp and users would never know. Or heck even if the deimos repo was bundled with the download users would never know and it would work even better for a lot of cases. Anyway, I wrote this on chat and was goinna clean up for my blog but I'll repeat it here instead: my problems with dpp: 1) it is slow and always will be. it doesn't know what actually needs to be translated, so it just takes all the C and converts it to D and dumps it out. so dpp wastes time on huge amounts of useless work, then dmd wastes huge amounts of time sifting through it. I tried to optimize this by recognizing certain filename patterns and shifting it to imports, but it still has to do tons of work because of macros which brings me to: 2) preprocessor macros are bad and should be kept far away from D code. but since C headers often define them you're thrust into this hell. dpp makes it worse though because of its translation model - it has no semantic awareness of actual need. so it ends up doing silly things like turning import core.sys.linux to import core.sys.1. These tend to be fixed with some ad-hoc #undef at the end of the translated section, or sometimes translating certain macro patterns into superior D patterns, adn enough work toward that will prolly achieve like 95% goodness. but there's still bound to be some case that got missed no matter what. 3) some C code is still slightly different than D code and even with the help of an AST you can't fix all this up - again blame macros for much of it - meaning you can still generat crap It is possible that a dmd-integrated solution can address some of this. It can just parse the C definitions and keep a table of them in memory instead of translating it to a file. It can keep a separate macro namespace and apply them in a semantically-aware fashion to avoid generating a bunch of that intermediate code. when it does apply a macro, it would take the D ast, to C String it, run the processor in a sandbox, C parse the result, then paste that into the ast, limiting the pain. But that's still not going to always work. And a lot of those things use various compiler extensions and newer language features that dmc likely doesn't implement much of. Some require annoying #defines before #include and that's ... well possible but fairly tricky too, especially if it is trying to translate the declarations into the D module structure so i think dmd integration is a better approach than dpp. but im a lil skeptical if it will actually work as opposed to being some proof of concept dumped in and abandoned. The amount of work needed to bring this from proof of concept that sometimes works to actually usable thing that covers ground that the Deimos repo doesn't already have is going to be significant and probably better spent somewhere else.
May 09
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 10 May 2021 at 00:55:34 UTC, Adam D. Ruppe wrote:
 so i think dmd integration is a better approach than dpp.
That post was the positive side. Here's what I said in the PR comment for the negative side: This appears completely useless to me. First, it doesn't "just work" since you need to run cpp over the file before you can use it, and since that expands macros, it must be done for each different target, meaning it must be part of the build system. This offers no advantage over the (not great) existing solutions and shares many of their problems including creating huge files. Even if that just worked, C bindings tend to rely on the preprocessor to do common and necessary tasks like defining constants. Without that, you can't even reasonably use real world C headers. Possibly a limited processor could translate them, but even that data is gone after cpp goes through it, so there's no real hope to recover it into a usable form. I think trying to run the cpp over a whole D file like dpp does is problematic... but like something must be done. dstep's approach actually does a reasonably good job, at the cost of requiring a bit of hand editing and some setting up of other files too. I do think there's some potential in integrating with dmd... but this PR as it is looks like more harm than good. And I'm not sure it is worth the time sink it will take to get it to a positive point. ====== Kinda the same thing: has potential but it is a lot of work to get it to actually realize that and there's other ways to get to that goal. The preprocessor problem needs a solid action plan before we merge this thing or we'll be left with a half-done thing in limbo for years, if not forever.
May 09
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/9/21 8:55 PM, Adam D. Ruppe wrote:
 2) preprocessor macros are bad and should be kept far away from D code. 
 but since C headers often define them you're thrust into this hell. dpp 
 makes it worse though because of its translation model - it has no 
 semantic awareness of actual need. so it ends up doing silly things like 
 turning import core.sys.linux to import core.sys.1. These tend to be 
 fixed with some ad-hoc #undef at the end of the translated section, or 
 sometimes translating certain macro patterns into superior D patterns, 
 adn enough work toward that will prolly achieve like 95% goodness. but 
 there's still bound to be some case that got missed no matter what.
I had this idea: what if in D code, you can access CPP macros explicitly. Like: #CMACRO(<macro expression) Which then you can use by running a specialized c preprocessor on your d code. C macros can only be defined in C header files, and if you choose to accept the above ugliness, then it properly translates that part to what the c preprocessor spits out. If the C preprocessor is not enabled (the default option), the macro call is an error. This gives you the possibility to use C headers directly, doesn't interfere with normal D code, and also encourages you to find better ways to do the macro-y things if possible to get rid of the ugliness. Another option is to allow CPP macros with a pragma scope: pragma(cmacro, on); pragma(cmacro, off); Which might hide some of the ugliness, but still is opt-in for using macros. -Steve
May 11
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/11/21 10:34 AM, Steven Schveighoffer wrote:
 I had this idea: what if in D code, you can access CPP macros 
 explicitly. Like:
 
 #CMACRO(<macro expression)
Hm... macro is still a reserved keyword, so we could use that also. -Steve
May 13
prev sibling next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
Things which can be said in C but not understood in D (like _Atomic) should probably fail to compile or compile to some core.compat.atomic type.
May 09
prev sibling next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
`inline` in the C standard (although given as an example C11 footnote 138) technically *only* has guaranteed implications other than actually inlining the function, is ignoring it valid?
May 09
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 4:27 PM, Max Haughton wrote:
 `inline` in the C standard (although given as an example C11 footnote 138) 
 technically *only* has guaranteed implications other than actually inlining
the 
 function, is ignoring it valid?
C11 6.7.4-6 says: "A function declared with an inline function specifier is an inline function. Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined." Ignoring it is not only valid, it's what modern C compilers do anyway.
May 09
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Monday, 10 May 2021 at 00:47:22 UTC, Walter Bright wrote:
 On 5/9/2021 4:27 PM, Max Haughton wrote:
 `inline` in the C standard (although given as an example C11 
 footnote 138) technically *only* has guaranteed implications 
 other than actually inlining the function, is ignoring it 
 valid?
C11 6.7.4-6 says: "A function declared with an inline function specifier is an inline function. Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined." Ignoring it is not only valid, it's what modern C compilers do anyway.
Which is why I bring up that `inline` *is* used in modern programs, but not for performance, specifically in header files for example. ``` #include <stdio.h> inline int square(int num) { return num * num; } int main() { printf("%d\n", square(3)); } ``` fails to link in C but not in C++. I don't know whether this actually breaks anything since D doesn't really have a "you have permission to emit nothing" keyword.
May 09
next sibling parent reply Brian <bcallah openbsd.org> writes:
On Monday, 10 May 2021 at 01:13:25 UTC, Max Haughton wrote:
 ```
 #include <stdio.h>
 inline int square(int num) {
     return num * num;
 }

 int main()
 {
     printf("%d\n", square(3));
 }
 ```
 fails to link in C but not in C++.
Whether or not your code links in C depends on a number of factors. It is not as simple as you make it out to be. Consider on my OpenBSD machine: ``` /home/brian/c $ gcc --version gcc (GCC) 12.0.0 20210421 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /home/brian/c $ gcc -o square square.c ld: error: undefined symbol: square
 referenced by square.c
               /tmp//cc3wDuve.o:(main)
collect2: error: ld returned 1 exit status /home/brian/c $ gcc -O2 -o square square.c /home/brian/c $ ./square 9 ``` ~Brian
May 09
parent Max Haughton <maxhaton gmail.com> writes:
On Monday, 10 May 2021 at 01:50:40 UTC, Brian wrote:
 On Monday, 10 May 2021 at 01:13:25 UTC, Max Haughton wrote:
[...]
Whether or not your code links in C depends on a number of factors. It is not as simple as you make it out to be. Consider on my OpenBSD machine: ``` /home/brian/c $ gcc --version gcc (GCC) 12.0.0 20210421 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /home/brian/c $ gcc -o square square.c ld: error: undefined symbol: square
               [...]
collect2: error: ld returned 1 exit status /home/brian/c $ gcc -O2 -o square square.c /home/brian/c $ ./square 9 ``` ~Brian
That particular case is fairly simple if you look at the outputted code. The function `square` is never emitted, but with the optimization flag it is never used (by name).
May 09
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 6:13 PM, Max Haughton wrote:
 ```
 #include <stdio.h>
 inline int square(int num) {
      return num * num;
 }
 
 int main()
 {
      printf("%d\n", square(3));
 }
 ```
 fails to link in C but not in C++.
I just tried it with gcc, it links. It does not with clang. Examination of clang's output shows it treated it as extern. I don't really understand what's going on with clang here, but that code will work with DMD.
May 09
parent reply Brian <bcallah openbsd.org> writes:
On Monday, 10 May 2021 at 01:53:26 UTC, Walter Bright wrote:
 On 5/9/2021 6:13 PM, Max Haughton wrote:
 ```
 #include <stdio.h>
 inline int square(int num) {
      return num * num;
 }
 
 int main()
 {
      printf("%d\n", square(3));
 }
 ```
 fails to link in C but not in C++.
I just tried it with gcc, it links. It does not with clang. Examination of clang's output shows it treated it as extern. I don't really understand what's going on with clang here, but that code will work with DMD.
It links on clang 11.0.1 here at -O2 or higher (including -Os and -Oz). Also links with pcc -O and even tcc!
May 09
parent Max Haughton <maxhaton gmail.com> writes:
On Monday, 10 May 2021 at 02:00:26 UTC, Brian wrote:
 On Monday, 10 May 2021 at 01:53:26 UTC, Walter Bright wrote:
 On 5/9/2021 6:13 PM, Max Haughton wrote:
 ```
 #include <stdio.h>
 inline int square(int num) {
      return num * num;
 }
 
 int main()
 {
      printf("%d\n", square(3));
 }
 ```
 fails to link in C but not in C++.
I just tried it with gcc, it links. It does not with clang. Examination of clang's output shows it treated it as extern. I don't really understand what's going on with clang here, but that code will work with DMD.
It links on clang 11.0.1 here at -O2 or higher (including -Os and -Oz). Also links with pcc -O and even tcc!
See my previous comment and think about what inlining does to the assembly.
May 10
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Monday, 10 May 2021 at 00:47:22 UTC, Walter Bright wrote:
 On 5/9/2021 4:27 PM, Max Haughton wrote:
 `inline` in the C standard (although given as an example C11 
 footnote 138) technically *only* has guaranteed implications 
 other than actually inlining the function, is ignoring it 
 valid?
C11 6.7.4-6 says: "A function declared with an inline function specifier is an inline function. Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined." Ignoring it is not only valid, it's what modern C compilers do anyway.
inline change the linker flags so that multiple definitions do not fail. That's all it does.
May 10
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/10/2021 4:01 PM, deadalnix wrote:
 inline change the linker flags so that multiple definitions do not fail.
That's 
 all it does.
They're still done with COMDATs (the equivalent in Elf, Mach, MSCoff). A COMDAT is a separate section. One COMDAT per function means they can be handled separately. The pre-1990 way was to lump everything into one section, and the different functions could not be teased out of that. Some of the more peculiar C linkage semantics are sad attempts to deal with no COMDAT support.
May 10
prev sibling next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
```C struct forward; struct forward { //impl } ``` is very common in C, D doesn't allow such a concept, therefore using the D AST seems like it could be a problem.
May 09
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 4:41 PM, Max Haughton wrote:
 is very common in C, D doesn't allow such a concept, therefore using the D AST 
 seems like it could be a problem.
I've deferred altering the D semantic code for now, as it is not necessary to demonstrate the concept of ImportC, and the PR is big enough already. I suggest this discussion be more meta in nature, rather than oriented toward the (plenty) of bugs in the implementation.
May 09
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
[A meta comment in reply to Adam]

The end goal is to be able to import a C file and it will "just work". The 
following problems need to be solved to make this happen:

a. collecting user-supplied #defines

b. running the C preprocessor

c. collecting the final set of macro definitions at the end of the preprocessor
run

d. converting the collection (C) to D equivalents, for example:

     #define ABC 3  => enum ABC = 3;

     #define f(g) ((g)+1)  =>  auto f(T)(T g) { return g + 1; }

Going further than that is likely to be intractable, Atila has spent a lot of 
time on this, he likely pushed it further.

e. Running the C compiler

==================

ImportC only addresses (e).

Does this make it useless? Frankly, I have no idea. I don't know any way of 
finding out other than making it work and seeing what happens. But there are 
some things that are knowable:

1. C changes only glacially. It's not like the 
https://www.winchestermysteryhouse.com/ constantly adding new rooms and 
different architectural styles.

2. C is a simple language. It only took a 5 days to get this far with it. DMD's 
lexer, semantics, optimizer and code gen can all be leveraged. I know how to 
write a C compiler.

3. Writing a C preprocessor is a nightmare. Fortunately, I already did that 
https://github.com/facebookarchive/warp and we can use it if we choose.

4. A builtin C compiler will be very fast, and quite small.

5. We will have complete control over it. We can adjust it so it works best for 
us. We don't need to fork or get anyone's buy-in. We control the user
experience.

6. The D code will be able to inline C code, and even CTFE it.

7. We can easily do inline assembler for it. (It's already there!)

8. There are a lot of wacky C extensions out there. We only need to implement 
currently used ones (not the 16 bit stuff), and only the stuff that appears in
C 
headers.

9. Without a C compiler, we're stuck with, wedded to, and beholden to libclang. 
I wouldn't be surprised that the eventual cost of adapting ourselves to
libclang 
will exceed the cost of doing our own C compiler.

10. By nailing (e), then (a..d) starts looking possible.

11. C++ can compile C code, which is a ginormous advantage for C++. Can we 
afford not to do that?

12. Being built-in, in the box, batteries included, rather than an add-on, has 
enormous positive implications for D. It's hard to understate it. Think how 
great it was for Ddoc and unittest being built-in.
May 09
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 10 May 2021 at 01:45:22 UTC, Walter Bright wrote:
 11. C++ can compile C code, which is a ginormous advantage for 
 C++. Can we afford not to do that?
You want to fully compile the C code, not just extract bindings to link to it? There's a lot of convenience to that - I've translated many lines of code from C to D by hand (a pretty easy process btw, just tedious, but if you sit down for a few hours and just do it, it is a result you can use for years to come) to take advantage of the convenience; being able to dmd -i is nice. But I think the binding aspect is a lot more important and without the preprocessor part you just can't do that. It is an absolute must for this to be useful. If you can get some of that #define stuff to just work, then maybe we can merge this and iterate on it from there. But I'm against merging something that's only maybe 20% done. Get up to 50% - integrated cpp with those #defines actually being available to D... and maybe we have something usable and a solid basis to estimate how much work is left (by the time you get to the point where you can do this, the work is about 1/3 done. There'd still the all the little details that need to be done and the inevitable flurry of bugs. I'd be surprised if this is legitimately usable by the end of the year. But it would prove it is realistically possible once importing a module with some defined constants works from the D side.)
May 09
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 7:12 PM, Adam D. Ruppe wrote:
 On Monday, 10 May 2021 at 01:45:22 UTC, Walter Bright wrote:
 11. C++ can compile C code, which is a ginormous advantage for C++. Can we 
 afford not to do that?
You want to fully compile the C code, not just extract bindings to link to it?
Yes. Frankly, there's no reason not to once you've done nearly all the work anyway. (For example, to evaluate static array dimensions, an expression parser is needed.)
 There's a lot of convenience to that - I've translated many lines of code from
C 
 to D by hand (a pretty easy process btw, just tedious, but if you sit down for
a 
 few hours and just do it, it is a result you can use for years to come) to
take 
 advantage of the convenience; being able to dmd -i is nice.
Yeah, I did the backend conversion from C to D. It took a couple hours per file, most of the tedium came from it being terribly written code.
 But I think the binding aspect is a lot more important and without the 
 preprocessor part you just can't do that. It is an absolute must for this to
be 
 useful.
I do have a forlorn hope that some C users will find it useful to replace many of their macros with enum, const, and inline function declarations.
 If you can get some of that #define stuff to just work, then maybe we can
merge 
 this and iterate on it from there.
 
 But I'm against merging something that's only maybe 20% done. Get up to 50% - 
 integrated cpp with those #defines actually being available to D... and maybe
we 
 have something usable and a solid basis to estimate how much work is left (by 
 the time you get to the point where you can do this, the work is about 1/3
done. 
 There'd still the all the little details that need to be done and the
inevitable 
 flurry of bugs. I'd be surprised if this is legitimately usable by the end of 
 the year. But it would prove it is realistically possible once importing a 
 module with some defined constants works from the D side.)
The trouble is making it fully functional will require tweaks all over the D semantic code. Constantly needing to rebase this large code base for a year is an unpleasant prospect. Besides, ImportC is simply not going to break any existing functionality, so people can just ignore it successfully.
May 09
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 10 May 2021 at 03:13:51 UTC, Walter Bright wrote:
 On 5/9/2021 7:12 PM, Adam D. Ruppe wrote:
 On Monday, 10 May 2021 at 01:45:22 UTC, Walter Bright wrote:
 11. C++ can compile C code, which is a ginormous advantage 
 for C++. Can we afford not to do that?
You want to fully compile the C code, not just extract bindings to link to it?
Yes. Frankly, there's no reason not to once you've done nearly all the work anyway. (For example, to evaluate static array dimensions, an expression parser is needed.)
 There's a lot of convenience to that - I've translated many 
 lines of code from C to D by hand (a pretty easy process btw, 
 just tedious, but if you sit down for a few hours and just do 
 it, it is a result you can use for years to come) to take 
 advantage of the convenience; being able to dmd -i is nice.
Yeah, I did the backend conversion from C to D. It took a couple hours per file, most of the tedium came from it being terribly written code.
 But I think the binding aspect is a lot more important and 
 without the preprocessor part you just can't do that. It is an 
 absolute must for this to be useful.
I do have a forlorn hope that some C users will find it useful to replace many of their macros with enum, const, and inline function declarations.
As a C programmer I do use already a lot of enums and inlines, but the C semantic makes it quite tricky to use. To use inlines in big C projects you have to guarantee that you emit the non inlined version of the function in exactly one module as some linkers do not like to have multiple object files with the same functions in them. You also want to have always at least one uninlined version of the fucnton so that it can be linked with modules that were compiled with -O0 or -fno-inline. Not difficult, but requires some pre-processor acrobatics that can be problematic. The issue I see is that the preprocessor is not bound by the language syntax and is sometimes used in things that cannot be translated easily to a D construct. I have, for example, a lot of functions that take a string and its length. For string literals it is annoying to count the number of characters so I have a macro to do it: `#define SnL(array) (array),LENGTH(array)` one will note that this fits two parameters The LENGTH macro is also interesting it is define as `#define LENGTH(arr) (NUM_ELEMS(arr)-1)` ok, so far it's easy, but here comes NUM_ELEMS, that I have lifted from the Linux kernel ``` #ifdef __GNUC__ /** Array size macro. Copied the Linux Kernel version which is not portable but which checks that it's a real array (not a pointer) and evaluates to a constant expression. This allows to use it to declare other array sizes. */ #define NUM_ELEMS(arr) (sizeof(struct {int :-!!(__builtin_types_compatible_p(typeof (arr), typeof (&0[arr])));})+sizeof (arr)/sizeof 0[arr]) #else /** A portable variant, but which doesn't check for array or pointer. */ #define NUM_ELEMS(arr) (sizeof (arr)/sizeof 0[arr]) #endif ``` This is the kind of macros that are all over the place in real C code.
May 09
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 11:21 PM, Patrick Schluter wrote:
 As a C programmer I do use already a lot of enums and inlines, but the C 
 semantic makes it quite tricky to use.
 To use inlines in big C projects you have to guarantee that you emit the non 
 inlined version of the function in exactly one module as some linkers do not 
 like to have multiple object files with the same functions in them.
Those linkers were obsoleted in 1990 with the advent of C++ (C++ forced the introduction of COMDAT sections to handle that). D relies on COMDATs, too, so if you're stuck on such an obsolete platform, and I know C wishes to still support them, D won't work on it anyway.
 You also 
 want to have always at least one uninlined version of the fucnton so that it
can
 be linked with modules that were compiled with -O0 or -fno-inline. Not 
 difficult, but requires some pre-processor acrobatics that can be problematic.
With COMDATs, this is not a problem.
 The issue I see is that the preprocessor is not bound by the language syntax
and 
 is sometimes used in things that cannot be translated easily to a D construct.
Yup.
 I have, for example, a lot of functions that take a string and its length. For 
 string literals it is annoying to count the number of characters so I have a 
 macro to do it:
 
 `#define SnL(array) (array),LENGTH(array)`
 
 one will note that this fits two parameters
 
 The LENGTH macro is also interesting it is define as
 
 `#define LENGTH(arr)  (NUM_ELEMS(arr)-1)` ok, so far it's easy, but here comes
 NUM_ELEMS, that I have lifted from the Linux kernel
 
      ```
      #ifdef __GNUC__
      /** Array size macro. Copied the Linux Kernel version which is not
portable 
 but
          which checks that it's a real array (not a pointer) and
evaluates to a
          constant expression. This allows to use it to declare other
array 
 sizes. */
        #define NUM_ELEMS(arr) (sizeof(struct {int 
 :-!!(__builtin_types_compatible_p(typeof (arr), typeof (&0[arr])));})+sizeof 
 (arr)/sizeof 0[arr])
      #else
      /** A portable variant, but which doesn't check for array or pointer.
*/
        #define NUM_ELEMS(arr) (sizeof (arr)/sizeof 0[arr])
      #endif
      ```
 
 This is the kind of macros that are all over the place in real C code.
I know. I used to revel in this stuff. Macros that piece together syntax are a horror show, and a big part of why D doesn't have macros. (I eventually removed all this stuff from my C code and it was much nicer as a result.) There's no way to mechanically translate this stuff to D. However, the preprocessed code can be compiled just fine by ImportC. You just won't be able to use those macros in the D code. But I'm pretty sure an equivalent can be made by hand. P.S. that unnamed bit field is, well, sheesh. It could be replaced with a template.
May 10
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 10 May 2021 at 07:21:31 UTC, Walter Bright wrote:
 On 5/9/2021 11:21 PM, Patrick Schluter wrote:
 [...]
Those linkers were obsoleted in 1990 with the advent of C++ (C++ forced the introduction of COMDAT sections to handle that). D relies on COMDATs, too, so if you're stuck on such an obsolete platform, and I know C wishes to still support them, D won't work on it anyway.
 [...]
With COMDATs, this is not a problem.
 [...]
Yup.
 [...]
I know. I used to revel in this stuff. Macros that piece together syntax are a horror show, and a big part of why D doesn't have macros. (I eventually removed all this stuff from my C code and it was much nicer as a result.) There's no way to mechanically translate this stuff to D. However, the preprocessed code can be compiled just fine by ImportC. You just won't be able to use those macros in the D code. But I'm pretty sure an equivalent can be made by hand. P.S. that unnamed bit field is, well, sheesh. It could be replaced with a template.
Yes, I just read the comment on your PR and the way chosen is indeed the only viable way to proceed. The only thing that bothers me as it is now is the fact that it doesn't support intializer list `{ intializers }`, which I suppose means that designated initializers `{ .field = ..., [3]=... }`and compound statements `(type){ initializers }` are not working either. This would be a real real problem for modern C code (C99 and superior).
May 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/10/2021 12:39 AM, Patrick Schluter wrote:
 The only thing that bothers me as it is now is the fact that it doesn't
support 
 intializer list `{ intializers }`, which I suppose means that designated 
 initializers `{ .field = ..., [3]=... }`and compound statements `(type){ 
 initializers }` are not working either. This would be a real real problem for 
 modern C code (C99 and superior).
The only issue is { initializer-list } has no direct analog in D, so I've got to add one to the D side. For the purpose of this prototype, I wished to avoid adding code that wasn't in cparse.d.
May 10
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 10 May 2021 at 09:24:39 UTC, Walter Bright wrote:
 On 5/10/2021 12:39 AM, Patrick Schluter wrote:
 The only thing that bothers me as it is now is the fact that 
 it doesn't support intializer list `{ intializers }`, which I 
 suppose means that designated initializers `{ .field = ..., 
 [3]=... }`and compound statements `(type){ initializers }` are 
 not working either. This would be a real real problem for 
 modern C code (C99 and superior).
The only issue is { initializer-list } has no direct analog in D, so I've got to add one to the D side. For the purpose of this prototype, I wished to avoid adding code that wasn't in cparse.d.
I get that but just wanted to point out that that will be a big issue (it's such a big issue that C++ had to implement it with C++20).
May 10
prev sibling next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 May 2021 at 02:12:02 UTC, Adam D. Ruppe wrote:
 If you can get some of that #define stuff to just work, then 
 maybe we can merge this and iterate on it from there.
You could add a syntax for embedding C function defs or even C expressions in D code and run only that through cpp. Then make D declarations available to C by making a C extension. However... If it takes years to fix D issues, then this whole project is likely to not be used in serious projects as it will be viewed as less reliable than just manually creating wrappers. It makes more sense to reuse clang and emit llvm IR.
May 10
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 10 May 2021 at 08:09:23 UTC, Ola Fosheim Grostad wrote:
 On Monday, 10 May 2021 at 02:12:02 UTC, Adam D. Ruppe wrote:
 ...
 It makes more sense to reuse clang and emit llvm IR.
Except that llvm IR is not understood by DMD, also llvm IR is post-semantic. So you you have to take the opposite path, i.e IR -> AST, which is quite unusual. Anyway, this is is not a bad idea, let's say for a another project.
May 10
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 May 2021 at 09:14:02 UTC, Basile B. wrote:
 On Monday, 10 May 2021 at 08:09:23 UTC, Ola Fosheim Grostad 
 wrote:
 On Monday, 10 May 2021 at 02:12:02 UTC, Adam D. Ruppe wrote:
 ...
 It makes more sense to reuse clang and emit llvm IR.
Except that llvm IR is not understood by DMD, also llvm IR is post-semantic. So you you have to take the opposite path, i.e IR -> AST, which is quite unusual. Anyway, this is is not a bad idea, let's say for a another project.
No, you take a C-expression in D, use an external tool/library to obtain the semantics of the resulting expression. Then you compile and link at IR level. Anyway, I suggested the approach Walter is taking here years ago, but at this point there are more critical issues on the table... This is a diversion from adressing the hard issues.
May 10
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 10 May 2021 at 09:31:58 UTC, Ola Fosheim Grostad wrote:
 Anyway, I suggested the approach Walter is taking here years 
 ago, but at this point there are more critical issues on the 
 table... This is a diversion from adressing the hard issues.
The changelog mentions [htod, dpp and DStep](https://github.com/dlang/dmd/pull/12507/files#diff-cdf7d0893f3c1cb898585c88423f77c6d7094b31425d18f29 91809fdb928cabR37). The solution proposed should be as good as the union of the three. There are chances that the discussion will derivate on the topic of full translation of C while the point is rather to translate headers i.e **declarations** and only that. Like if it can handle most commonly used c headers, let's say zlib, ssl, etc. it's ok. What people want is more like cairo headers, llvm headers, x11 headers, etc. to be handled.
May 10
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 May 2021 at 10:03:48 UTC, Basile B. wrote:
 There are chances that the discussion will derivate on the 
 topic of full translation of C while the point is rather to 
 translate headers i.e **declarations** and only that. Like if 
 it can handle most commonly used c headers, let's say zlib, 
 ssl, etc. it's ok. What people want is more like cairo headers, 
 llvm headers, x11 headers, etc. to be handled.
The topic presented is to translate C code to D's high level IR after cpp. My point is that you don't need to translate headers if you have an external tool that accept a set of header files and a C-expression and provide a mechanism to do reflection on that expression. What you need then is some way to translate D-constructs to C-constructs which shouldn't be too hard. But regardless, D's focus ought to be on memory management and fixing issues in the type system. Adding more source code to the compiler won't help. Basic system development strategy: Refactor first, then fix issues, then add new features.
May 10
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 10 May 2021 at 11:03:43 UTC, Ola Fosheim Grøstad wrote:
 My point is that you don't need to translate headers if you 
 have an external tool that accept a set of header files and a 
 C-expression and provide a mechanism to do reflection on that 
 expression.
To elaborate on this assume you have something like this: ```d #include "header1.h" #include "header2.h" DType1 x; DType2 y; int z = ©(FUNKYMACRO(1+*$x,*$y) ``` Where © says this is a C-expression and $ says it is a D identifier. The the compiler would collect all #includes in the D-file and create a C-function with (cachable) source looking something like this: ```c #include "header1.h" #include "header2.h" int __transpiled1234(__DType1_translated_to_C* __x, __DType2_translated_to_C* __y){ return FUNKYMACRO(1+*__x, *__y); } ``` And generate the following D code: ```d int z = __transpiled1234(&x, &y); ``` Something like that.
May 10
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/10/2021 3:03 AM, Basile B. wrote:
 There are chances that the discussion will derivate on the topic of full 
 translation of C while the point is rather to translate headers i.e 
 **declarations** and only that. Like if it can handle most commonly used c 
 headers, let's say zlib, ssl, etc. it's ok. What people want is more like
cairo 
 headers, llvm headers, x11 headers, etc. to be handled.
We *can* do a full translation of C with ImportC.
May 10
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 11 May 2021 at 04:18:23 UTC, Walter Bright wrote:
 On 5/10/2021 3:03 AM, Basile B. wrote:
 There are chances that the discussion will derivate on the 
 topic of full translation of C while the point is rather to 
 translate headers i.e **declarations** and only that. Like if 
 it can handle most commonly used c headers, let's say zlib, 
 ssl, etc. it's ok. What people want is more like cairo 
 headers, llvm headers, x11 headers, etc. to be handled.
We *can* do a full translation of C with ImportC.
That would be a game changer
May 10
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 10 May 2021 at 02:12:02 UTC, Adam D. Ruppe wrote:
 But I'm against merging something that's only maybe 20% done. 
 Get up to 50% - integrated cpp with those #defines actually 
 being available to D... and maybe we have something usable and 
 a solid basis to estimate how much work is left (by the time 
 you get to the point where you can do this, the work is about 
 1/3 done. There'd still the all the little details that need to 
 be done and the inevitable flurry of bugs. I'd be surprised if 
 this is legitimately usable by the end of the year. But it 
 would prove it is realistically possible once importing a 
 module with some defined constants works from the D side.)
+1 For example a lot of "C" headers in the wild use pragma(pack), and it seems awful to implement. No, it doesn't correspond to what align(x) does.
May 10
prev sibling next sibling parent reply Brian <bcallah openbsd.org> writes:
Hi Walter --

Though still new to D, I really like this idea. Some rather 
trivial meta comments below.

On Monday, 10 May 2021 at 01:45:22 UTC, Walter Bright wrote:
 5. We will have complete control over it. We can adjust it so 
 it works best for us. We don't need to fork or get anyone's 
 buy-in. We control the user experience.

 8. There are a lot of wacky C extensions out there. We only 
 need to implement currently used ones (not the 16 bit stuff), 
 and only the stuff that appears in C headers.

 9. Without a C compiler, we're stuck with, wedded to, and 
 beholden to libclang. I wouldn't be surprised that the eventual 
 cost of adapting ourselves to libclang will exceed the cost of 
 doing our own C compiler.
Completely agree with these 3 related points. The only thing I would add is that ANSI C11 is a start but it might be worthwhile to think sooner rather than later about what if any extensions are to be accepted and what the process would like like to incorporate those extensions. GNU C is a de facto standard. Even if that was relaxed to LLVM C, that is still a number of extensions. But I think this can be overall a tomorrow problem, so long as the initial considerations aren't too many tomorrows from now.
 11. C++ can compile C code, which is a ginormous advantage for 
 C++. Can we afford not to do that?
As a new user to D, I was legitimately surprised that D didn't already compile C with the very explicit writings about DasBetterC, going so far as to having a -betterC flag. Perhaps that was my mistake in understanding the language. I wonder how many other newcomers also experience that confusion. ~Brian
May 09
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 7:22 PM, Brian wrote:
 As a new user to D, I was legitimately surprised that D didn't already compile
C 
 with the very explicit writings about DasBetterC, going so far as to having a 
 -betterC flag. Perhaps that was my mistake in understanding the language. I 
 wonder how many other newcomers also experience that confusion.
Having both ImportC and DasBetterC is definitely a messaging issue.
May 09
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 10 May 2021 at 02:51:35 UTC, Walter Bright wrote:
 On 5/9/2021 7:22 PM, Brian wrote:
 As a new user to D, I was legitimately surprised that D didn't 
 already compile C with the very explicit writings about 
 DasBetterC, going so far as to having a -betterC flag. Perhaps 
 that was my mistake in understanding the language. I wonder 
 how many other newcomers also experience that confusion.
Having both ImportC and DasBetterC is definitely a messaging issue.
Have you tried to mix ImportC with the -betterC flag? I wonder what the error looks like if you ImportC a C main function but then also have a betterC D file with a main function.
May 11
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2021 6:42 AM, jmh530 wrote:
 Have you tried to mix ImportC with the -betterC flag?
 
 I wonder what the error looks like if you ImportC a C main function but then 
 also have a betterC D file with a main function.
-betterC is for D code, not C code, and will not affect ImportC.
May 11
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 10 May 2021 at 01:45:22 UTC, Walter Bright wrote:
 [A meta comment in reply to Adam]

 The end goal is to be able to import a C file and it will "just 
 work". The following problems need to be solved to make this 
 happen:

 [...]
+1
May 09
prev sibling parent James Lu <jamtlu gmail.com> writes:
On Monday, 10 May 2021 at 01:45:22 UTC, Walter Bright wrote:
 ImportC only addresses (e).
Great job, Walter, you made us proud.
May 10
prev sibling next sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
How does this impact gdc as part of GCC? GCC already has a C compiler, so this could be seen as some kind of duplication of features/effort from their perspective.
May 10
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/10/2021 1:53 AM, Gregor Mückl wrote:
 How does this impact gdc as part of GCC? GCC already has a C compiler, so this 
 could be seen as some kind of duplication of features/effort from their 
 perspective.
Since this is all front end work, and it translates the C code into D AST nodes, it should "just work". After all, CTFE "just worked" with ImportC. I didn't do a thing to enable it. I didn't do a thing to the glue code, optimizer, or back end (other than not generating moduleinfo).
May 10
next sibling parent reply Markk <markus.kuehni triviso.ch> writes:
On Monday, 10 May 2021 at 09:27:35 UTC, Walter Bright wrote:

 Since this is all front end work, and it translates the C code 
 into D AST nodes, it should "just work".
With that crucial information added it suddenly made perfect sense to me. Brilliant!
 After all, CTFE "just worked" with ImportC. I didn't do a thing 
 to enable it. I didn't do a thing to the glue code, optimizer, 
 or back end (other than not generating moduleinfo).
How are modules defined? I mean, how do you import and symbol-reference it from D? Assuming everything `extern` in C needs to be in the same module/namespace? _Mark
May 15
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2021 1:28 AM, Markk wrote:
 How are modules defined? I mean, how do you import and symbol-reference it
from D?
The module name is generated from the file name, and all the C symbols go into it.
May 15
prev sibling parent reply Markk <markus.kuehni triviso.ch> writes:
On Monday, 10 May 2021 at 09:27:35 UTC, Walter Bright wrote:

 Since this is all front end work, and it translates the C code 
 into D AST nodes, it should "just work".
With that crucial information added it suddenly made perfect sense to me. Brilliant!
 After all, CTFE "just worked" with ImportC. I didn't do a thing 
 to enable it. I didn't do a thing to the glue code, optimizer, 
 or back end (other than not generating moduleinfo).
How are modules defined? I mean, how do you import and symbol-reference it from D? Assuming everything `extern` in C needs to be in the same module/namespace? _Mark
May 15
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/21 4:34 AM, Markk wrote:
 On Monday, 10 May 2021 at 09:27:35 UTC, Walter Bright wrote:
 
 Since this is all front end work, and it translates the C code into D 
 AST nodes, it should "just work".
With that crucial information added it suddenly made perfect sense to me. Brilliant!
ImportC is one of the coolest hacks I've seen in many years. To think it took only 4 KLOC. I can't find my behind with a map in 4 KLOC.
May 15
parent reply Max Haughton <maxhaton gmail.com> writes:
On Saturday, 15 May 2021 at 16:03:01 UTC, Andrei Alexandrescu 
wrote:
 On 5/15/21 4:34 AM, Markk wrote:
 On Monday, 10 May 2021 at 09:27:35 UTC, Walter Bright wrote:
 
 Since this is all front end work, and it translates the C 
 code into D AST nodes, it should "just work".
With that crucial information added it suddenly made perfect sense to me. Brilliant!
ImportC is one of the coolest hacks I've seen in many years. To think it took only 4 KLOC. I can't find my behind with a map in 4 KLOC.
wrt to it being 4KLOC, I'm reserving judgement until it can compile something useful. The dmd AST is already a bit of a mess, making it compile two languages (i.e. more bitflags everywhere!) could make 4KLOC in the parser trickle down elsewhere all over the place (e.g. Struct forward decls, initializer lists etc. all have to find a home somewhere in the AST). One thing of note here is that if it can compile a given C file, the compiler doesn't do a terrible job of representing it's AST as a string so this could also be utilized as a C to D converter.
May 15
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 16/05/2021 4:09 AM, Max Haughton wrote:
 wrt to it being 4KLOC, I'm reserving judgement until it can compile 
 something useful.
Once it can compile zlib and successfully pass its test suite, then its something to be excited about!
May 15
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 10 May 2021 at 08:53:57 UTC, Gregor Mückl wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
How does this impact gdc as part of GCC? GCC already has a C compiler, so this could be seen as some kind of duplication of features/effort from their perspective.
Not really a duplication, as it is contained to the D front-end with no reliance on GCC infrastructure. Integration is another matter though, as all GCC compilers know about all languages that have been enabled, and what file extensions they handle. i.e: `gdc foo.c bar.d baz.go` will invoke the C, D and Go compilers separately in one execution step: ``` cpp foo.c -o foo.i; cc1 foo.i -o foo.o; d21 bar.d -o bar.o; go1 baz.go -o baz.o; ld foo.o bar.o baz.o -o a.out ``` While it might be wishful thinking to register C source files against the D compiler (so `gdc foo.c` calls the preprocessor and compiler in one step), that could cause a conflict with gcc and g++ calling the D compiler when they themselves handle C source files. Importing C source files into D modules is another thing (the D front-end is already compiling), and doesn't affect the above mentioned machinery.
May 12
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2021 4:24 AM, Iain Buclaw wrote:
 Integration is another matter though, as all GCC compilers know about all 
 languages that have been enabled, and what file extensions they handle.  i.e: 
 `gdc foo.c bar.d baz.go` will invoke the C, D and Go compilers separately in
one 
 execution step:
 ```
 cpp foo.c -o foo.i;
 cc1 foo.i -o foo.o;
 d21 bar.d -o bar.o;
 go1 baz.go -o baz.o;
 ld foo.o bar.o baz.o -o a.out
 ```
I don't see any conflict there, either. While dmd foo.c will compile C and generate an executable, so will gdc foo.c It'll just use a different C compiler.
May 12
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Thursday, 13 May 2021 at 01:37:55 UTC, Walter Bright wrote:
 On 5/12/2021 4:24 AM, Iain Buclaw wrote:
 Integration is another matter though, as all GCC compilers 
 know about all languages that have been enabled, and what file 
 extensions they handle.  i.e: `gdc foo.c bar.d baz.go` will 
 invoke the C, D and Go compilers separately in one execution 
 step:
 ```
 cpp foo.c -o foo.i;
 cc1 foo.i -o foo.o;
 d21 bar.d -o bar.o;
 go1 baz.go -o baz.o;
 ld foo.o bar.o baz.o -o a.out
 ```
I don't see any conflict there, either. While dmd foo.c will compile C and generate an executable, so will gdc foo.c It'll just use a different C compiler.
Well, either one of, or two things will happen: 1. People will raise bugs against dmd because `gdc foo.c` will be able to compile more code than dmd (and do preprocessing). 2. People will raise bugs against gdc because `gdc -finline foo.c bar.d` doesn't inline C functions into bar. I meant conflicts will happen if I change the current behavior so make it so the D compiler handles C sources too i.e: `d21 bar.d foo.c -o bar.o`.
May 13
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/13/2021 2:04 PM, Iain Buclaw wrote:
 Well, either one of, or two things will happen:
 
 1. People will raise bugs against dmd because `gdc foo.c` will be able to 
 compile more code than dmd (and do preprocessing).
 
 2. People will raise bugs against gdc because `gdc -finline foo.c bar.d`
doesn't 
 inline C functions into bar.
 
 I meant conflicts will happen if I change the current behavior so make it so
the 
 D compiler handles C sources too i.e: `d21 bar.d foo.c -o bar.o`.
Understood. It's pretty clear that ImportC is not going to be an exact clone of gcc. I've been looking over the __attribute__ documentation, and there doesn't even seem to be a proper grammar for it. https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax There's some wishy-washy wording: "Where an attribute specifier is applied to a parameter declared as a function or an array, it should apply to the function or array rather than the pointer to which the parameter is implicitly converted, but this is not yet correctly implemented." "In some other cases, attribute specifiers are permitted by this grammar but not yet supported by the compiler." "At present, ..." "An attribute specifier list may, in future, be permitted ..." "at present this is not implemented and they are ignored" "some laxity is allowed in the placing of attributes" which is discouraging. There are the other extensions, too. Ironically, the one gcc extension ImportC can support fully is inline assembler :-) as you've already seen to that! The plan is to do as few gcc C extensions as practical. As for the user having options, that's why we have multiple D compilers. ImportC isn't part of the D language, and so differing flavors of C support is within reason.
May 13
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
 On 5/13/2021 2:04 PM, Iain Buclaw wrote:
 Well, either one of, or two things will happen:
 
 1. People will raise bugs against dmd because `gdc foo.c` will 
 be able to compile more code than dmd (and do preprocessing).
 
 2. People will raise bugs against gdc because `gdc -finline 
 foo.c bar.d` doesn't inline C functions into bar.
 
 I meant conflicts will happen if I change the current behavior 
 so make it so the D compiler handles C sources too i.e: `d21 
 bar.d foo.c -o bar.o`.
Understood. It's pretty clear that ImportC is not going to be an exact clone of gcc. I've been looking over the __attribute__ documentation, and there doesn't even seem to be a proper grammar for it. https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax There's some wishy-washy wording: "Where an attribute specifier is applied to a parameter declared as a function or an array, it should apply to the function or array rather than the pointer to which the parameter is implicitly converted, but this is not yet correctly implemented." "In some other cases, attribute specifiers are permitted by this grammar but not yet supported by the compiler." "At present, ..." "An attribute specifier list may, in future, be permitted ..." "at present this is not implemented and they are ignored" "some laxity is allowed in the placing of attributes" which is discouraging. There are the other extensions, too. Ironically, the one gcc extension ImportC can support fully is inline assembler :-) as you've already seen to that! The plan is to do as few gcc C extensions as practical. As for the user having options, that's why we have multiple D compilers. ImportC isn't part of the D language, and so differing flavors of C support is within reason.
Recognizing the syntax and doing nothing would he enough for quite a few libraries. For GNU stdio.h to work I had to clean out a bunch of attributes, asm, and any structs, but other than that it did seem to work. The only other that I can say is that keep in mind that the blocker is using C not compiling C. I don't want dmd to be my C compiler - so you only need to understand GNU extensions that are used in header files (and don't appear in inline functions in those headers, but still).
May 13
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/13/2021 10:57 PM, Max Haughton wrote:
 The only other that I can say is that keep in mind that the blocker is using C 
 not compiling C. I don't want dmd to be my C compiler - so you only need to 
 understand GNU extensions that are used in header files (and don't appear in 
 inline functions in those headers, but still).
I know, it's just a bonus that it can be used as a standalone C compiler. It's not the point of ImportC. It does, however, make it much easier to test ImportC. And who knows what clever uses people will find for it! I'm always amazed at the things people do with D features.
May 14
parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Friday, 14 May 2021 at 23:59:27 UTC, Walter Bright wrote:
 On 5/13/2021 10:57 PM, Max Haughton wrote:
 The only other that I can say is that keep in mind that the 
 blocker is using C not compiling C. I don't want dmd to be my 
 C compiler - so you only need to understand GNU extensions 
 that are used in header files (and don't appear in inline 
 functions in those headers, but still).
I know, it's just a bonus that it can be used as a standalone C compiler. It's not the point of ImportC. It does, however, make it much easier to test ImportC. And who knows what clever uses people will find for it! I'm always amazed at the things people do with D features.
One suggestion I have is to add a test suite for the C compiler so that it is clear how conforming it is to Std C. A bunch of tests can be found at: https://github.com/vnmakarov/mir/tree/master/c-tests
May 14
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2021 6:11 PM, Dibyendu Majumdar wrote:
 One suggestion I have is to add a test suite for the C compiler so that it is 
 clear how conforming it is to Std C. A bunch of tests can be found at:
 
 https://github.com/vnmakarov/mir/tree/master/c-tests
Thank you. Those look good.
May 14
parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Saturday, 15 May 2021 at 03:59:58 UTC, Walter Bright wrote:
 On 5/14/2021 6:11 PM, Dibyendu Majumdar wrote:
 One suggestion I have is to add a test suite for the C 
 compiler so that it is clear how conforming it is to Std C. A 
 bunch of tests can be found at:
 
 https://github.com/vnmakarov/mir/tree/master/c-tests
Thank you. Those look good.
Other good tests: Single file SQLite - https://www.sqlite.org/download.html Single file Lua - https://github.com/lua/lua/blob/master/onelua.c You could then run SQLite tests and Lua tests. if they pass that would be super amazing!
May 15
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2021 3:38 AM, Dibyendu Majumdar wrote:
 Other good tests:
 
 Single file SQLite - https://www.sqlite.org/download.html
 
 Single file Lua - https://github.com/lua/lua/blob/master/onelua.c
 
 You could then run SQLite tests and Lua tests. if they pass that would be
super 
 amazing!
It sure would be amazing! On a practical note, I've found that using various 3rd party projects as a test suite tends to be more work than they're worth, because: 1. No matter how big a project is, it tends to use only a subset of the language, and once one or two of its files compile, the rest will. This makes for a lot of costly busywork (test suite time). Compiling lots of code does not necessarily translate into good test coverage, it's the same constructs tested over and over and over again. 2. To know if the project compiles properly, then you've got to run the project's test suite. This can send one rather far afield. 3. Debugging a failure in the project means understanding that project - an expensive undertaking. 4. The 3rd party project then needs to be maintained along with the compiler. The D test suite, on the other hand, is a large number of independent, minimized examples. When they fail, they're readily debuggable. They can be quickly processed. The redundancy is minimal. So, I propose that once ImportC is ready, that persons familiar with those code bases try out the SQLite and Lua projects. Failures should be reduced to minimal test cases for incorporation into the ImportC test suite.
May 15
next sibling parent reply Chris Piker <chris hoopjump.com> writes:
On Sunday, 16 May 2021 at 00:00:30 UTC, Walter Bright wrote:
 So, I propose that once ImportC is ready, that persons familiar 
 with those code bases try out the SQLite and Lua projects. 
 Failures should be reduced to minimal test cases for 
 incorporation into the ImportC test suite.
If you think it would be helpful I'll try building our in-house C libraries since I understand those and submit any cases that fail. I imagine quite a few people are going to be intrigued by this project (as a new C compiler doesn't come around every day) and will try building most of their C projects/dependencies. I'm not sure if this is applicable, but we still have some sun/ sparc machines around in case building on a big endian environment would provide you with useful data. Sparc cores are still burned into quite a few FPGAs. The test suite should build up quickly. Getting rid of duplicate tests may turn out to be an issue.
May 16
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2021 1:51 AM, Chris Piker wrote:
 If you think it would be helpful I'll try building our in-house C
 libraries since I understand those and submit any cases that fail.
 I imagine quite a few people are going to be intrigued by this
 project (as a new C compiler doesn't come around every day) and
 will try building most of their C projects/dependencies.
 
 I'm not sure if this is applicable, but we still have some sun/
 sparc machines around in case building on a big endian environment
 would provide you with useful data.  Sparc cores are still burned
 into quite a few FPGAs.
 
 The test suite should build up quickly.  Getting rid of duplicate
 tests may turn out to be an issue.
That would be welcome. But I'd suggest waiting a bit. There's plenty of known problems with it at the moment, so you'd be wasting your valuable time dealing with that. Wait until it's doing better.
May 16
prev sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Sunday, 16 May 2021 at 00:00:30 UTC, Walter Bright wrote:

 So, I propose that once ImportC is ready, that persons familiar 
 with those code bases try out the SQLite and Lua projects. 
 Failures should be reduced to minimal test cases for 
 incorporation into the ImportC test suite.
I think that if this feature is going to added, then it makes sense to ensure that a test suite is present to prove its correctness. Users should not be expected to pay for wrong implementation. Perhaps the MIR C test suite I referred to earlier can be used to validate the implementation; I think it has good coverage of standard C and the tests are also small. I am familiar with Lua but I would only consider spending any effort after I am convinced this feature has a proper testsuite. Otherwise as you mention in another thread, it just wastes time.
May 16
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2021 3:51 AM, Dibyendu Majumdar wrote:
 I think that if this feature is going to added, then it makes sense to ensure 
 that a test suite is present to prove its correctness. Users should not be 
 expected to pay for wrong implementation. Perhaps the MIR C test suite I 
 referred to earlier can be used to validate the implementation; I think it has 
 good coverage of standard C and the tests are also small.
The Mir suite does look usable and good. I'm a bit concerned about the license for it, as I'd like to install the test suite on github.
May 16
parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Sunday, 16 May 2021 at 19:12:26 UTC, Walter Bright wrote:
 On 5/16/2021 3:51 AM, Dibyendu Majumdar wrote:
 I think that if this feature is going to added, then it makes 
 sense to ensure that a test suite is present to prove its 
 correctness. Users should not be expected to pay for wrong 
 implementation. Perhaps the MIR C test suite I referred to 
 earlier can be used to validate the implementation; I think it 
 has good coverage of standard C and the tests are also small.
The Mir suite does look usable and good. I'm a bit concerned about the license for it, as I'd like to install the test suite on github.
Yes, the tests are sourced from various places, and some are GPL. I suppose it can be put into a standalone test repo so as not to contaminate D license with GPL.
May 16
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
 It's pretty clear that ImportC is not going to be an exact 
 clone of gcc. I've been looking over the __attribute__ 
 documentation, and there doesn't even seem to be a proper 
 grammar for it.
You are better off posing as Clang than GCC. You have to choose one or the other as extensions tend to be surrounded by #ifdefs Clang is also used in a new compiler from Intel, but the more challenging extensions are multiprocessing-extensions. Which will creep in over time (meaning, next decade).
May 14
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
 On 5/13/2021 2:04 PM, Iain Buclaw wrote:
 Well, either one of, or two things will happen:
 
 1. People will raise bugs against dmd because `gdc foo.c` will 
 be able to compile more code than dmd (and do preprocessing).
 
 2. People will raise bugs against gdc because `gdc -finline 
 foo.c bar.d` doesn't inline C functions into bar.
 
 I meant conflicts will happen if I change the current behavior 
 so make it so the D compiler handles C sources too i.e: `d21 
 bar.d foo.c -o bar.o`.
Understood. It's pretty clear that ImportC is not going to be an exact clone of gcc. I've been looking over the __attribute__ documentation, and there doesn't even seem to be a proper grammar for it. https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax There's some wishy-washy wording:
I guess in the D grammar, the closest approximation of an attribute-list is just a comma delimited list of call expressions. __attribute__( (fun1, fun2(2), fun3("bar"), fun4(5, 6)) ) Failing that, just accept any token, until you see the matching closing parenthesis. Parsing it can be postponed until the semantic phase, same as asm.
May 14
prev sibling parent reply matheus <matheus gmail.com> writes:
On Friday, 14 May 2021 at 05:27:27 UTC, Walter Bright wrote:
 As for the user having options, that's why we have multiple D 
 compilers. ImportC isn't part of the D language, and so 
 differing flavors of C support is within reason.
I hope this not lead to a fragmentation. Current we already have this case where if you want a faster compiling use DMD, but for production/optimization/reliability go with GDC or LDC. Matheus.
May 15
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2021 6:35 AM, matheus wrote:
 I hope this not lead to a fragmentation. Current we already have this case
where 
 if you want a faster compiling use DMD, but for 
 production/optimization/reliability  go with GDC or LDC.
Iain Buclaw, gdc's maintainer, is helping out with ImportC. Your concerns are in good hands!
May 15
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2021 1:57 PM, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507
 
 If you could add a C compiler to dmd with 3000 lines of code, so C code could
be 
 imported directly? I would!
Looks like we're on the front page of hackernews! https://news.ycombinator.com/
May 10
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/10/2021 2:11 AM, Walter Bright wrote:
 https://news.ycombinator.com/
https://news.ycombinator.com/item?id=27102584
May 10
prev sibling next sibling parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
Hi Walter This seems like a good step forward. I would recommend adding an in-built C pre-processor. Maybe port something small like this one: https://github.com/rui314/chibicc/blob/main/preprocess.c Many people write single header file C programs. With this enhancement it will be easy to use all of that code in D. Regards
May 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/10/2021 3:57 AM, Dibyendu Majumdar wrote:
 This seems like a good step forward. I would recommend adding an in-built C  
 pre-processor. Maybe port something small like this one:
 
 https://github.com/rui314/chibicc/blob/main/preprocess.c
 
 Many people write single header file C programs. With this enhancement it will 
 be easy to use all of that code in D.
Thanks for the tip! Unfortunately, the file is not a C preprocessor in all it's hideous detail, so it'll be a problem. Fortunately, we do have a C preprocessor: https://github.com/DigitalMars/dmpp
May 10
parent reply Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Tuesday, 11 May 2021 at 04:16:30 UTC, Walter Bright wrote:
 On 5/10/2021 3:57 AM, Dibyendu Majumdar wrote:
 This seems like a good step forward. I would recommend adding 
 an in-built C  pre-processor.
 Fortunately, we do have a C preprocessor:

 https://github.com/DigitalMars/dmpp
I assume that this will be added as an in-built feature - i.e. not require invoking via another process?
May 11
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar wrote:

 I assume that this will be added as an in-built feature - i.e. 
 not require invoking via another process?
 The C code must be run through a preprocessor before it can be 
 processed by ImportC. Incorporating this into your build system 
 is advisable.
https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11
May 11
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 11 May 2021 at 12:48:59 UTC, Mike Parker wrote:
 On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar 
 wrote:

 I assume that this will be added as an in-built feature - i.e. 
 not require invoking via another process?
 The C code must be run through a preprocessor before it can be 
 processed by ImportC. Incorporating this into your build 
 system is advisable.
https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11
Also:
 Some means of incorporating this may be practical. For now, use 
 cpp, warp or spp.
https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#c-preprocessor
May 11
next sibling parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Tuesday, 11 May 2021 at 12:51:07 UTC, Mike Parker wrote:
 On Tuesday, 11 May 2021 at 12:48:59 UTC, Mike Parker wrote:
 On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar 
 wrote:

 I assume that this will be added as an in-built feature - 
 i.e. not require invoking via another process?
 The C code must be run through a preprocessor before it can 
 be processed by ImportC. Incorporating this into your build 
 system is advisable.
https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11
Also:
 Some means of incorporating this may be practical. For now, 
 use cpp, warp or spp.
https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#c-preprocessor
Or import a single file CPP implementation :-)
May 11
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 11 May 2021 at 12:51:07 UTC, Mike Parker wrote:
 On Tuesday, 11 May 2021 at 12:48:59 UTC, Mike Parker wrote:
 On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar 
 wrote:

 I assume that this will be added as an in-built feature - 
 i.e. not require invoking via another process?
 The C code must be run through a preprocessor before it can 
 be processed by ImportC. Incorporating this into your build 
 system is advisable.
https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11
Also:
 Some means of incorporating this may be practical. For now, 
 use cpp, warp or spp.
https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#c-preprocessor
Am I right that Walter basically just moved the warp codebase from the Facebook archive to the Digital Mars one and renamed it dmpp (with maybe some tweaks)? Your responses don't really address the core of his point, which is whether dmpp - specifically - will be what is incorporated in the future. I assume it is.
May 11
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 11 May 2021 at 13:37:39 UTC, jmh530 wrote:

 Am I right that Walter basically just moved the warp codebase 
 from the Facebook archive to the Digital Mars one and renamed 
 it dmpp (with maybe some tweaks)?
I believe so, yes.
 Your responses don't really address the core of his point, 
 which is whether dmpp - specifically - will be what is 
 incorporated in the future. I assume it is.
Well, my first response was intended to show that no preprocessor of any kind was going to be integrated. Then I saw the future direction section after I posted it. So I'll step out and leave it to Walter to answer.
May 11
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2021 6:37 AM, jmh530 wrote:
 Am I right that Walter basically just moved the warp codebase from the
Facebook 
 archive to the Digital Mars one and renamed it dmpp (with maybe some tweaks)?
Not exactly. It was developed in parallel with the Warp repository, for the simple reason that I did not have push rights on Facebook repositories. There are likely some small differences, but I don't know what they are. Note that it's Boost licensed, so this is not a problem. Should probably put dmpp on dub.
May 11
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 11 May 2021 at 20:01:18 UTC, Walter Bright wrote:
 On 5/11/2021 6:37 AM, jmh530 wrote:
 Am I right that Walter basically just moved the warp codebase 
 from the Facebook archive to the Digital Mars one and renamed 
 it dmpp (with maybe some tweaks)?
Not exactly. It was developed in parallel with the Warp repository, for the simple reason that I did not have push rights on Facebook repositories. There are likely some small differences, but I don't know what they are. Note that it's Boost licensed, so this is not a problem. Should probably put dmpp on dub.
Thanks!
May 11
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2021 5:09 AM, Dibyendu Majumdar wrote:
 On Tuesday, 11 May 2021 at 04:16:30 UTC, Walter Bright wrote:
 On 5/10/2021 3:57 AM, Dibyendu Majumdar wrote:
 This seems like a good step forward. I would recommend adding an in-built C  
 pre-processor.
 Fortunately, we do have a C preprocessor:

 https://github.com/DigitalMars/dmpp
I assume that this will be added as an in-built feature - i.e. not require invoking via another process?
All options for dealing with the preprocessor problem will be on the table after ImportC is finished.
May 11
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
I'd say no to this. Why? Adding a C compiler into the D compiler will increase the maintenance work load and open up for new interesting bugs. This is the last D needs. Also there are several areas where D needs to improve (memory management) and add this split personally is a distraction. I also find this a bit strange coming from a person that thinks making GC pointers an own type would increase the complexity of the compiler, then suddenly wants to add a complete C compiler into the D compiler. Also the question raises what will be supported and what will not. There are a lot of header files out there that are a mix between C and C++. Adding importing C++ is difficult and the scope what is supported must be limited. This means that a lot of header files will not work directly. C++11 and beyond with templates, just forget it. I understand that importC would greatly make FFI easier but I think this is easier said than done. It is definitely not worth making the D compiler into a Frankensteins monster. I would go the conversion tool (that converts C header files to D files) route in order to decouple a foreign language to the D language.
May 11
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 11 May 2021 at 16:57:15 UTC, IGotD- wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 [...]
I'd say no to this. Why? [...]
C++ support isn't a goal here tho. And I'm not sure this would add such a big maintenance cost, Walter can do this in his sleep ⚡
May 11
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 11 May 2021 at 16:57:15 UTC, IGotD- wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
I'd say no to this. Why? Adding a C compiler into the D compiler will increase the maintenance work load and open up for new interesting bugs. This is the last D needs. Also there are several areas where D needs to improve (memory management) and add this split personally is a distraction. I also find this a bit strange coming from a person that thinks making GC pointers an own type would increase the complexity of the compiler, then suddenly wants to add a complete C compiler into the D compiler. Also the question raises what will be supported and what will not. There are a lot of header files out there that are a mix between C and C++. Adding importing C++ is difficult and the scope what is supported must be limited. This means that a lot of header files will not work directly. C++11 and beyond with templates, just forget it. I understand that importC would greatly make FFI easier but I think this is easier said than done. It is definitely not worth making the D compiler into a Frankensteins monster. I would go the conversion tool (that converts C header files to D files) route in order to decouple a foreign language to the D language.
Read the change log, there are no plans for importing C++ files. C (without the preprocessor nonsense) is a very simple programming language. There are huge number of C libraries out there. The ability to simply import them and "Just work" will be a huge boost to adoption rate when it comes the d language. -Alex
May 11
parent reply IGotD- <nise nise.com> writes:
On Tuesday, 11 May 2021 at 18:37:22 UTC, 12345swordy wrote:
 Read the change log, there are no plans for importing C++ 
 files. C (without the preprocessor nonsense) is a very simple 
 programming language. There are huge number of C libraries out 
 there. The ability to simply import them and "Just work" will 
 be a huge boost to adoption rate when it comes the d language.

 -Alex
Without the preprocessor many header files will not work. C is general littered with #ifdef. Commonplace is the #ifdef __cplusplus and without the preprocessor the C++ will collide with the C part. The importC that will "just work", will not be the reality. It's not worth it in my opinion.
May 11
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 11 May 2021 at 18:46:26 UTC, IGotD- wrote:
 On Tuesday, 11 May 2021 at 18:37:22 UTC, 12345swordy wrote:
 Read the change log, there are no plans for importing C++ 
 files. C (without the preprocessor nonsense) is a very simple 
 programming language. There are huge number of C libraries out 
 there. The ability to simply import them and "Just work" will 
 be a huge boost to adoption rate when it comes the d language.

 -Alex
Without the preprocessor many header files will not work. C is general littered with #ifdef. Commonplace is the #ifdef __cplusplus and without the preprocessor the C++ will collide with the C part. The importC that will "just work", will not be the reality. It's not worth it in my opinion.
That why in the changelog (Which you didn't read apparently) suggest that you use the gcc '-e' option in your build set up, before you compile it with dmd. -Alex
May 11
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2021 9:57 AM, IGotD- wrote:
 Adding a C compiler into the D compiler will increase the maintenance work
load 
 and open up for new interesting bugs.
True enough. But *any* method of automatically importing/translating C code will have the same problem.
 I also find this a bit strange coming from a person that thinks making GC 
 pointers an own type would increase the complexity of the compiler, then 
 suddenly wants to add a complete C compiler into the D compiler.
ImportC is designed to be a "bag on the side" of dmd specifically to reduce complexity.
 Also the question raises what will be supported and what will not. There are a 
 lot of header files out there that are a mix between C and C++. Adding
importing 
 C++ is difficult and the scope what is supported must be limited. This means 
 that a lot of header files will not work directly. C++11 and beyond with 
 templates, just forget it.
I can answer that question: no support for C++!
 I understand that importC would greatly make FFI easier but I think this is 
 easier said than done. It is definitely not worth making the D compiler into a 
 Frankensteins monster. I would go the conversion tool (that converts C header 
 files to D files) route in order to decouple a foreign language to the D
language.
ImportC essentially does convert C files to D files, as its output is a D AST. The only way to make any C to D converter is to compile C to an AST, then convert the AST to D. If libclang was used, the exact same thing happens, except libclang hands you a C AST. We (as dpp does) still have to convert the AST. Attempting to convert C to D using a text macro processor or string matching or some such is doomed to a terrible fate.
May 11
prev sibling next sibling parent reply xBuzz <xenofuzz postmail.net> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
I'm gonna say something you don't like. I know everyone (including myself) hates such kind of posts. I'm sorry in advance, I simply don't have an idea how to make you realize that the current way of the language evolution leads to nowhere. Of course, it's your project and not my business. No one owes anyone anything, but if you continue to spread resources on something other than fixing what you already have, I doubt dlang will get more popularity. Nobody wants to invest time/money to build their project based on a broken foundation. Look at the language. It's not consistent. It's just a bunch of features coupled together, part of them don't even work as designed. "shared", "scope", properties, even the initialization of associative arrays aren't finished (and this is just the tip of the iceberg). I've been following these forums for years, trying dlang again and again. Many question threads end with advent of Jonathan M Davis (I really appreciate it) stating a fact that "sadly, it's not implemented/fixed yet". Look at changelogs of dmd. Bugfixes, deprecations and virtually no language improvements/fixes. There are many issues in existing functionality and nobody cares to do something with it. Of course it's much more entertaining to play with integration of a C compiler, rather than do a hard work of trying to eliminate broken/unfinished things. Is there a roadmap with planned features/fixes/improvements for each milestone? You don't plan features/improvements for upcoming releases? It's been many years of stagnation, maybe it's time to finally start working on getting a solid core language? I know, I know... Who am I to criticize you, right? I've done nothing and you've created a valuable project. I just hope you won't bury the fruit of your many years of hard work and I sincerely wish you a good luck!
May 12
next sibling parent reply Igor Shirkalin <isemsoft gmail.com> writes:
On Wednesday, 12 May 2021 at 09:24:05 UTC, xBuzz wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
I'm gonna say something you don't like. I know everyone (including myself) hates such kind of posts. I'm sorry in advance, I simply don't have an idea how to make you realize that the current way of the language evolution leads to nowhere. Of course, it's your project and not my business. No one owes anyone anything, but if you continue to spread resources on something other than fixing what you already have, I doubt dlang will get more popularity. Nobody wants to invest
New things are always not optimal if we talk about human rssources. At least it is the problem of thouse humans, who spend their resources.
 time/money to build their project based on a broken foundation. 
 Look at the language. It's not consistent. It's just a bunch of 
 features coupled together, part of them don't even work as 
 designed. "shared", "scope", properties, even the 
 initialization of associative arrays aren't finished (and this 
 is just the tip of the iceberg). I've been following these
Are you really exaggerating.There are deep problems, but you should never panic.
 forums for years, trying dlang again and again. Many question 
 threads end with advent of Jonathan M Davis (I really 
 appreciate it) stating a fact that "sadly, it's not 
 implemented/fixed yet". Look at changelogs of dmd. Bugfixes,
I do really appreciate it too.
 deprecations and virtually no language improvements/fixes. 
 There are many issues in existing functionality and nobody 
 cares to do something with it. Of course it's much more
Are you ready to care about it?
 entertaining to play with integration of a C compiler, rather 
 than do a hard work of trying to eliminate broken/unfinished 
 things. Is there a roadmap with planned 
 features/fixes/improvements for each milestone? You don't plan
To my mind, the support of C is what should be done 10 or more years ago. I'd not stop on the latest C ISO, I'd add more featurs from C++.
 features/improvements for upcoming releases? It's been many 
 years of stagnation, maybe it's time to finally start working 
 on getting a solid core language?
 I know, I know... Who am I to criticize you, right? I've done 
 nothing and you've created a valuable project. I just hope you
You're talking about what most people think.
 won't bury the fruit of your many years of hard work and I 
 sincerely wish you a good luck!
Everyone should do the best of him.
May 12
parent reply IGotD- <nise nise.com> writes:
On Wednesday, 12 May 2021 at 11:39:33 UTC, Igor Shirkalin wrote:
 years ago. I'd not stop on the latest C ISO, I'd add more 
 featurs from C++.
I'm thinking in the same lines. It would be nice if importC would be able to detect abstract C++ classes and convert them to extern(C++) interfaces. Then we have inheritance support to think of as well. This proposal has a tendency to grow. It might be a useful tool and people will demand more of it all the time if it becomes popular. Implementing importC will open that can of worms.
May 12
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2021 7:00 AM, IGotD- wrote:
 On Wednesday, 12 May 2021 at 11:39:33 UTC, Igor Shirkalin wrote:
 years ago. I'd not stop on the latest C ISO, I'd add more featurs from C++.
I'm thinking in the same lines. It would be nice if importC would be able to detect abstract C++ classes and convert them to extern(C++) interfaces. Then we have inheritance support to think of as well. This proposal has a tendency to grow. It might be a useful tool and people will demand more of it all the time if it becomes popular. Implementing importC will open that can of worms.
Just think - if it was so successful people want more out of it, that is a good thing!
May 12
prev sibling next sibling parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Wednesday, 12 May 2021 at 09:24:05 UTC, xBuzz wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
Of course, it's your project and not my business.
Agreed.
 one owes anyone anything, but if you continue to spread 
 resources on something other than fixing what you already have, 
 I doubt dlang will get more popularity. Nobody wants to invest 
 time/money to build their project based on a broken foundation.
 I know, I know... Who am I to criticize you, right? I've done 
 nothing and you've created a valuable project. I just hope you 
 won't bury the fruit of your many years of hard work and I 
 sincerely wish you a good luck!
Well one thing I have realized about the D project is that it is truly about whatever each person wants to work on. There is no organization / roadmap / plan. And yet the great thing is that it has a bunch of talented people working on it. Its a unique social phenomenon. To expect Walter to do what you think is right, is futile. I guess he has earned the right to work on whatever he fancies. Regards
May 12
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 12 May 2021 at 09:24:05 UTC, xBuzz wrote:
 [...]
My point of view: Adding this feature will raise attention in the developer community . My hope is this will lead to a lot new developers start using D because of the seamless integration with C. At the end, more D developers will lead to more developers which will work on the D ecosystem, including the D compilers / standard library. Therefore it is actually a smart decision in my opinion. Kind regards Andre
May 12
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 12 May 2021 at 14:41:17 UTC, Andre Pany wrote:
 On Wednesday, 12 May 2021 at 09:24:05 UTC, xBuzz wrote:
 [...]
My point of view: Adding this feature will raise attention in the developer community . My hope is this will lead to a lot new developers start using D because of the seamless integration with C. At the end, more D developers will lead to more developers which will work on the D ecosystem, including the D compilers / standard library. Therefore it is actually a smart decision in my opinion. Kind regards Andre
+1 If this get to "just works" it will be a game changer imo
May 12
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 May 2021 at 14:41:17 UTC, Andre Pany wrote:
 On Wednesday, 12 May 2021 at 09:24:05 UTC, xBuzz wrote:
 [...]
My point of view: Adding this feature will raise attention in the developer community . My hope is this will lead to a lot new developers start using D because of the seamless integration with C.
I don't think the people who have left did it because of C interop. C++ interop maybe. People who left most likely did it because of inconsistencies and memory management challenges.
May 12
next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Wednesday, 12 May 2021 at 15:22:08 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 12 May 2021 at 14:41:17 UTC, Andre Pany wrote:
 On Wednesday, 12 May 2021 at 09:24:05 UTC, xBuzz wrote:
 [...]
My point of view: Adding this feature will raise attention in the developer community . My hope is this will lead to a lot new developers start using D because of the seamless integration with C.
I don't think the people who have left did it because of C interop. C++ interop maybe. People who left most likely did it because of inconsistencies and memory management challenges.
I think it's possible to have people who left and people who join can have very little to do with each other. Jordan
May 12
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 12 May 2021 at 21:44:29 UTC, Jordan Wilson wrote:
 I think it's possible to have people who left and people who 
 join can have very little to do with each other.
If they joined for the wrong reasons, but D was initially "marketed" as a better C++, and only a small set of those early adopters are here still, so... Anyway, integration with C by translating to the D AST is something I did strongly suggest years ago in these forums, so I am not complaining about the feature. I only worry about existing ongoing efforts be significantly delayed. Like if refactoring the AST is desirable, then it better be done before this C-addition is merged in...
May 13
prev sibling parent reply Chris Piker <chris hoopjump.com> writes:
On Wednesday, 12 May 2021 at 15:22:08 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 12 May 2021 at 14:41:17 UTC, Andre Pany wrote:
 I don't think the people who have left did it because of C 
 interop. C++ interop maybe.  People who left most likely did it 
 because of inconsistencies and memory management challenges.
I'm only one data point, and maybe in the extreme minority, but in my field C++ interop, GC reliance, and language inconsistencies aren't critical issues. In fact many of our widely used languages are riddled with inconsistencies (I'm looking at you matlab & idl), but that doesn't stop them because the feature set is so nice. All the widely used libraries are written in C or Fortran, and most of our local legacy code is in C, or Python. This means C++ interop really isn't part of our picture. Since D can call C and it can look very pythonic it's a good fit. So for us, improved C interop would be a nice bonus, and a good selling point. (Heck if you really want to turn some heads add a fortran 77 parser :)
May 13
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 14 May 2021 at 06:38:34 UTC, Chris Piker wrote:
 In fact many of our widely used languages are riddled with
 inconsistencies (I'm looking at you matlab & idl), but that
 doesn't stop them because the feature set is so nice.
Right, but Matlab is being displaced by Python (at a slow pace). Of course that is also related to licensing (for students), but I think language-issues is also a factor. Especially when writing larger programs, then Python is a clear winner.
 So for us, improved C interop would be a nice bonus, and a good
 selling point.
Sure! BUT you also didn't dismiss D as a valid tool for you, am I right?
May 14
parent reply Chris Piker <chris hoopjump.com> writes:
I'm afraid my dubious contributions are a bit off topic for
this thread, but one more won't hurt I guess...

On Friday, 14 May 2021 at 08:26:30 UTC, Ola Fosheim Grøstad wrote:
 On Friday, 14 May 2021 at 06:38:34 UTC, Chris Piker wrote:
 In fact many of our widely used languages are riddled with
 inconsistencies (I'm looking at you matlab & idl), but that
 doesn't stop them because the feature set is so nice.
Right, but Matlab is being displaced by Python (at a slow pace). Of course that is also related to licensing (for students), but I think language-issues is also a factor. Especially when writing larger programs, then Python is a clear winner.
In general that's true, but lately Matlab and IDL are making a comeback among my peers because hardware projects have money to pay for licensing (staff are so much more expensive than software licenses anyway) and matplotlib is slow compared to the alternatives.
 So for us, improved C interop would be a nice bonus, and a good
 selling point.
Sure! BUT you also didn't dismiss D as a valid tool for you, am I right?
You're right, but I'm just one person at my work site. I'm looking to sell others on D. I'm already sold :) I think features get users, quality keeps them, so both matter.
May 14
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 14 May 2021 at 18:56:07 UTC, Chris Piker wrote:
 In general that's true, but lately Matlab and IDL are making a
 comeback among my peers because hardware projects have money to
 pay for licensing (staff are so much more expensive than
Matlab is also better for interactive experimentation because the syntax is a bit more compact, but I am no longer using Matlab/Octave. Python/PyCharm + ipython is quite ok.
 You're right, but I'm just one person at my work site.  I'm 
 looking to sell others on D.
What features would make a language easier to sell to your colleagues?
May 14
parent reply Chris Piker <chris hoopjump.com> writes:
On Friday, 14 May 2021 at 19:06:47 UTC, Ola Fosheim Grøstad wrote:
 What features would make a language easier to sell to your 
 colleagues?
* A good IDE * An on-site expert (I'm working that part) * A good IDE * A good book (Ali has that covered) * A good IDE * Seamless C interop (already pretty good, could be better) * Execution speed (check, done) * A large corporate or non-profit backer promoting D (prob. not in the cards) * Oh, and a good IDE. I'm giving a tiny monthly donation to Dexed, it's not enough to matter but maybe it could encourage others to join in. No one at work currently uses Visual Studio. The big environments are, in order from most to least used: Matlab, Netbeans, IDL & LabView. (A netbeans plugin would *really* turn some heads since we write a lot of Java, and also use it for C). I did switch over to Windows for a day and play around with the Visual-D plugin, but I'm not a very experienced Windows developer these days. Usually I write/debug on Linux and then port to Windows using vcpkg, nmake, cl, and other command line tools.
May 14
parent Zardoz <luis.panadero gmail.com> writes:
On Saturday, 15 May 2021 at 05:37:48 UTC, Chris Piker wrote:
 [...]

 I'm giving a tiny monthly donation to Dexed, it's not enough to 
 matter
 but maybe it could encourage others to join in.

 No one at work currently uses Visual Studio.  The big 
 environments are,
 in order from most to least used: Matlab, Netbeans, IDL & 
 LabView.
 (A netbeans plugin would *really* turn some heads since we 
 write a lot of
 Java, and also use it for C).  I did switch over to Windows for 
 a day
 and play around with the Visual-D plugin, but I'm not a very 
 experienced
 Windows developer these days.  Usually I write/debug on Linux 
 and then
 port to Windows using vcpkg, nmake, cl, and other command line 
 tools.
Have you try Visual Code (or VSCodium) with VisualD? . Visual Code have a decent VIM mode and a lot of interesting stuff. And VisualD manages to give some decent experience with D, specially when you have to debug.
May 14
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2021 11:56 AM, Chris Piker wrote:
 I think features get users, quality keeps them, so both matter.
An apt summary.
May 14
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2021 2:24 AM, xBuzz wrote:
 I'm gonna say something you don't like.
I don't mind. But I will say that show me a language that isn't getting a constant stream of bug fixes, improvements, etc., and I'll show you a dead language. Every D changelog is full of bug fixes and improvements. The true measure of a language its not its perfection, but its utility. Is D usable to easily create great programs? Hell yes! The only perfect languages are very small ones, and nobody uses them, because you can't do anything with them. The real world is dirty, and useful languages wind up being dirty to be able to play in the real world. As for ImportC, people have been asking for easy importation of C code for decades. D's inability to do that is very clearly a large barrier to adoption. I hear about this *all* the time. I decided to take a sledgehammer and bash that problem out of existence. It's absolutely what the D community ought to be doing.
May 12
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 13 May 2021 at 00:04:38 UTC, Walter Bright wrote:
 On 5/12/2021 2:24 AM, xBuzz wrote:
 [...]
I don't mind. But I will say that show me a language that isn't getting a constant stream of bug fixes, improvements, etc., and I'll show you a dead language. [...]
+1
May 13
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
The advantage of the forum is that it is lively and can discuss 
issues.

But the disadvantage of this forum is that it does not collect 
some useful information in a separate subsection.

So, I would suggest to the D people,

You should answer the user's questions and put a separate 
subsection.

Especially D novices, they need to understand the future of D, 
the future, the current situation of D.

Don't be afraid of late, don't be afraid of criticism, don't be 
afraid of making mistakes.

Fear is that the novice can not find a solution to their 
confusion.

Without the participation of novices, is water without a source, 
again.
So c++, is very concerned about novice friendly
we,should learn from it.
May 12
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 If you could add a C compiler to dmd with 3000 lines of code,
As of the time of this writing it has already grown to: https://github.com/dlang/dmd/pull/12507 +3,905 −42 30% overbudget just three days after the announcement. I stand by my prediction that this is going to end up a LOT bigger than it looked at first.
May 12
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 12 May 2021 at 13:01:41 UTC, Adam D. Ruppe wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 If you could add a C compiler to dmd with 3000 lines of code,
As of the time of this writing it has already grown to: https://github.com/dlang/dmd/pull/12507 +3,905 −42 30% overbudget just three days after the announcement. I stand by my prediction that this is going to end up a LOT bigger than it looked at first.
From the PR
 WalterBright added the Trivial label 3 days ago
Found it funny. C is not a fast moving target, so this is probably worth doing.
May 12
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2021 6:08 AM, deadalnix wrote:
  From the PR
 WalterBright added the Trivial label 3 days ago
Found it funny. C is not a fast moving target, so this is probably worth doing.
While adding the Trivial label was indeed my little joke, it's not entirely wrong. C is a small and very well understood language, so implementing a compiler for it doesn't require much cleverness. I've also gone around the horn implementing a C compiler before, and learned to take the canal this time.
May 12
parent reply Araq <rumpf_a web.de> writes:
On Thursday, 13 May 2021 at 00:11:58 UTC, Walter Bright wrote:
 On 5/12/2021 6:08 AM, deadalnix wrote:
  From the PR
 WalterBright added the Trivial label 3 days ago
Found it funny. C is not a fast moving target, so this is probably worth doing.
While adding the Trivial label was indeed my little joke, it's not entirely wrong. C is a small and very well understood language, so implementing a compiler for it doesn't require much cleverness. I've also gone around the horn implementing a C compiler before, and learned to take the canal this time.
Sequence points, volatile, shared memory model, undefined behavior, obscure aliasing rules... C is small and well understood indeed -- when you chose to ignore all these things that happen to contradict your narrative.
May 12
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 13 May 2021 at 06:56:07 UTC, Araq wrote:
 Sequence points, volatile, shared memory model, undefined 
 behavior, obscure aliasing rules... C is small and well 
 understood indeed -- when you chose to ignore all these things 
 that happen to contradict your narrative.
The goal of D is that tranlating C-code to D should be easy so D should adopt the sequence points and shared memory model of C/C++ anyway. Undefined behaviour is not relevant, as that means the compiler can define it any way it wants to as such code is not valid (should not be provided by the programmer), volatile is not frequently used outside embedded/kernel programming (and isn't difficult to implement anyway).
May 13
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2021 11:56 PM, Araq wrote:
 Sequence points, volatile, shared memory model, undefined behavior, obscure 
 aliasing rules... C is small and well understood indeed -- when you chose to 
 ignore all these things that happen to contradict your narrative.
Essentially none of that matters except sequence points for ImportC. And D follows the same sequence point rules.
May 13
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2021 6:01 AM, Adam D. Ruppe wrote:
 On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 If you could add a C compiler to dmd with 3000 lines of code,
As of the time of this writing it has already grown to: https://github.com/dlang/dmd/pull/12507 +3,905 −42 30% overbudget just three days after the announcement. I stand by my prediction that this is going to end up a LOT bigger than it looked at first.
LOL. Subtract out the changelog documentation, and all the comments.
May 12
prev sibling next sibling parent reply Chris Piker <chris hoopjump.com> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
From a new D user this idea looks... Great! Though it's a separate issue, I hope this opens a path to mixed C/D dub projects down the road. I currently support mixed C/Python projects and it's been a pain (hence why Anaconda arose). If I could take a C code base, make it a dub project and slowly convert it to D over time that would be really nice. It would mean I could call C code from D "scripts". That's crazy, as in crazy cool. I look forward to seeing how this turns out.
May 13
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 14 May 2021 at 01:47:21 UTC, Chris Piker wrote:
 Though it's a separate issue, I hope this opens a path to mixed 
 C/D dub projects down the road.
This is already fairly easy to do. dub isn't great at it, but you can use a pre-build command in the dub settings to run make (or whatever) to build your C parts, then the D parts are built and they link seamlessly. You can maintain your bindings by hand, or use dstep to build D bindings from C headers 90%ish reliably and dtoh to build C bindings from D files even better. It isn't actually that hard to do, but it can indeed be annoying if there's frequent changes to the interface.
May 13
parent reply Chris Piker <chris hoopjump.com> writes:
On Friday, 14 May 2021 at 02:04:47 UTC, Adam D. Ruppe wrote:
 This is already fairly easy to do. dub isn't great at it, but 
 you can use a pre-build command in the dub settings to run make 
 (or whatever) to build your C parts, then the D parts are built 
 and they link seamlessly.
Its easy to do so long as the tools you need are available on every platform you target. On Linux this trivial, but Windows is a different beast. Even the download URL for Windows build tools seems to move around all the time. And once the build tools are installed, there's no one obvious location for nmake.exe and cl.exe. Just getting dub to reliably find those tools on some random person's computer is difficult. On the other hand, dub can usually find dmd. Also the dmd+dub distribution is so easy to install that I would be happy to depend on it just to get away from nmake.exe & cl.exe.
 You can maintain your bindings by hand, or use dstep to build D 
 bindings from C headers 90%ish reliably and dtoh to build C 
 bindings from D files even better. It isn't actually that hard 
 to do, but it can indeed be annoying if there's frequent 
 changes to the interface.
Maybe I'm just unlucky (or doing it wrong) but I've never had dstep or htod work without customizing the output by hand. They are a good first step and a very welcome time saver but (so far at least) I wouldn't want to distribute C sources and hope that header parsing works. If the dmd distribution came with a real C preprocessor and dmd gained the ability to compile most C code, I think the end result would be more user friendly, especially on Windows. I know I'd try it out.
May 13
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 14 May 2021 at 03:03:04 UTC, Chris Piker wrote:
 On Linux this trivial, but Windows is a different beast.
You wanna run it from the x86 native tools for VS command prompt window, then the PATH is set up for it. But yeah I do agree it is quite a bit of a pain. Personally, I've actually ported full C files to D before to avoid having to deal with it (see stuff like jpeg.d and stb_ttf.d in my arsd repo as some examples - though i had help with those too).
 Maybe I'm just unlucky (or doing it wrong) but I've never had 
 dstep or htod work without customizing the output by hand.
Well this is what I mean by 90% reliable - you do have to do the other 10% by hand. But still that's not too bad. And tbh I rarely even do that, I just make C bindings as i need them by hand.
 If the dmd distribution came with a real C preprocessor and dmd 
 gained the ability to compile most C code, I think the end 
 result would be more user friendly, especially on Windows.  I 
 know I'd try it out.
Yea, there is definitely potential here in making it easier. Just like if you're willing to spend a few hours doing some boring tedium up front it can be done right now too.
May 13
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/12507

 If you could add a C compiler to dmd with 3000 lines of code, 
 so C code could be imported directly? I would!
importC has been added as a keyword to bugzilla, please monitor it as any bugs are critical to be fixed before first release. https://issues.dlang.org/buglist.cgi?keywords=importC
May 20