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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021