www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Generating .di header files from ImportC files

reply Walter Bright <newshound2 digitalmars.com> writes:
Bruce and Adam and I met at a Red Robin in Seattle to chat about D, and they 
both made a case for the D compiler being able to translate C files into .di 
"header" files.

The idea is to:

1. be able to work with D IDE programs that can only deal with D code

2. be able to handle the vast bulk of converting .h to D code, and then tweak
by 
hand the bits that didn't translate well

Anyhow, I pontificated that this couldn't be done, because some C code is not 
representable as D code. Silly me.

But I got to thinking about it. It turns out that DMD can currently do this:

     dmd -c test.c -Hf=test.di

and voila! It creates a .di file from the C file. Who knew?

It could use some adjustment, but the bulk is there and it didn't crash or 
launch nuclear missiles. (Phew!)

Just like I discovered that ImportC could successfully import and use D code 
(including templates!), this is another fine discovery that DMD can convert C 
code to D code! An unexpected feature that (nearly) comes for free!

Wow!

Anyhow, have fun experimenting with this!
Oct 20 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 Bruce and Adam and I met at a Red Robin in Seattle to chat 
 about D, and they both made a case for the D compiler being 
 able to translate C files into .di "header" files.

 [...]
Interesting indeed. Nice work. Can you expand on how dmd can convert C to D? I didn't quite get that part.
Oct 21 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/21/2023 1:12 AM, Imperatorn wrote:
 Can you expand on how dmd can convert C to D? I didn't quite get that part.
DMD already has the capability to read in a .d file, then from the AST generate a .di file. Since ImportC gets turned into an AST, too, it can turn that AST into a .di file, too.
Oct 21 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 17:04:40 UTC, Walter Bright wrote:
 On 10/21/2023 1:12 AM, Imperatorn wrote:
 Can you expand on how dmd can convert C to D? I didn't quite 
 get that part.
DMD already has the capability to read in a .d file, then from the AST generate a .di file. Since ImportC gets turned into an AST, too, it can turn that AST into a .di file, too.
I see, nice. I will experiment with that a bit.
Oct 21 2023
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 21 October 2023 at 17:04:40 UTC, Walter Bright wrote:
 On 10/21/2023 1:12 AM, Imperatorn wrote:
 Can you expand on how dmd can convert C to D? I didn't quite 
 get that part.
DMD already has the capability to read in a .d file, then from the AST generate a .di file. Since ImportC gets turned into an AST, too, it can turn that AST into a .di file, too.
Nice, I just tried it and as long as you have your path setup right, it works well :) For others reading this, since I'm on Windows, I just opened the developer command prompt and just ran: dmd -c hashmap.c -Hf="hashmap.di" And it just worked. Pretty impressive.
Oct 21 2023
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/21/2023 11:33 AM, Imperatorn wrote:
 And it just worked. Pretty impressive.
Ain't it cool? I love it when things like this happen.
Oct 21 2023
prev sibling parent reply confuzzled <con fuzzled.com> writes:
On 10/22/23 3:33 AM, Imperatorn wrote:
 
 And it just worked. Pretty impressive.
or not ---- test.c ---- #include <stdlib.h> #include <time.h> ---------------- dmd -c test.c -Hf="test.di" Output: zsh: segmentation fault dmd -c test.c -Hf=parse_itch5.di OS: macOS Sonoma Compiler: DMD v2.105.2
Oct 26 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 26 October 2023 at 14:27:19 UTC, confuzzled wrote:
 On 10/22/23 3:33 AM, Imperatorn wrote:
 
 And it just worked. Pretty impressive.
or not ---- test.c ---- #include <stdlib.h> #include <time.h> ---------------- dmd -c test.c -Hf="test.di" Output: zsh: segmentation fault dmd -c test.c -Hf=parse_itch5.di OS: macOS Sonoma Compiler: DMD v2.105.2
I did not test on Mac. File a report!
Oct 26 2023
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 Bruce and Adam and I met at a Red Robin in Seattle to chat 
 about D, and they both made a case for the D compiler being 
 able to translate C files into .di "header" files.

 The idea is to:
I could have sworn I told Bruce that he could do this two years ago shortly after importc came out!
Oct 22 2023
parent Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 22 October 2023 at 08:28:42 UTC, Iain Buclaw wrote:
 On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright 
 wrote:
 Bruce and Adam and I met at a Red Robin in Seattle to chat 
 about D, and they both made a case for the D compiler being 
 able to translate C files into .di "header" files.

 The idea is to:
I could have sworn I told Bruce that he could do this two years ago shortly after importc came out!
You probably did! :-) I knew that others had it brewing for a bit but had not remembered it as being *that* old! Kudos. Anyway, glad to see this is being explored/exposed. It's great to draft along behind the, well maintained, importC capability.
Oct 22 2023
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 Bruce and Adam and I met at a Red Robin in Seattle to chat 
 about D, and they both made a case for the D compiler being 
 able to translate C files into .di "header" files.

 [...]
Sorry but I don’t think I’ve ever used .di files. What is the significance of this?
Oct 22 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/22/2023 4:45 PM, jmh530 wrote:
 Sorry but I don’t think I’ve ever used .di files. What is the significance
of this?
.di files serve the same purpose as .h files do in C.
Oct 22 2023
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 23 October 2023 at 00:41:58 UTC, Walter Bright wrote:
 On 10/22/2023 4:45 PM, jmh530 wrote:
 Sorry but I don’t think I’ve ever used .di files. What is the 
 significance of this?
.di files serve the same purpose as .h files do in C.
Looks like the documentation on them has been improved too since the last time I looked at it: https://dlang.org/dmd-windows.html#interface-files
Oct 23 2023
parent reply d007 <d007 gmail.com> writes:
On Monday, 23 October 2023 at 12:43:24 UTC, jmh530 wrote:
 On Monday, 23 October 2023 at 00:41:58 UTC, Walter Bright wrote:
 On 10/22/2023 4:45 PM, jmh530 wrote:
 Sorry but I don’t think I’ve ever used .di files. What is the 
 significance of this?
.di files serve the same purpose as .h files do in C.
Looks like the documentation on them has been improved too since the last time I looked at it: https://dlang.org/dmd-windows.html#interface-files
try on osx: dmd, ldc2, ldmd2. all get this error: Error: unrecognized file extension h
Oct 23 2023
next sibling parent bachmeier <no spam.net> writes:
On Monday, 23 October 2023 at 16:08:58 UTC, d007 wrote:

 try on osx: dmd, ldc2, ldmd2.  all get this error:

 Error: unrecognized file extension h
What version is your compiler? If it's too old, it won't have that support.
Oct 23 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2023 9:08 AM, d007 wrote:
 Error: unrecognized file extension h
That's because recognizing h files caused Iain problems building gdc. To deal with: --- file.c --- #include "file.h" --------------
Oct 23 2023
parent reply d007 <d007 gmail.com> writes:
On Monday, 23 October 2023 at 18:00:39 UTC, Walter Bright wrote:
 On 10/23/2023 9:08 AM, d007 wrote:
 Error: unrecognized file extension h
That's because recognizing h files caused Iain problems building gdc. To deal with: --- file.c --- #include "file.h" --------------
today I try use importC with libfuse3. DMD64 D Compiler v2.106.0-beta.1 ```sh dmd -c fuse.c -Hf=fuse.di fuse.c:1:10: fatal error: fuse3/fuse.h: No such file or directory 1 | #include "fuse3/fuse.h" | ^~~~~~~~~~~~~~ compilation terminated. Error: C preprocess command cpp failed for file fuse.c, exit status 1 ``` I am not sure how to pass c flags into dmd here, and I can not find document about this. try with: ```sh clang -E $dir/fuse.c -o fuse.i -I./include -DFUSE_USE_VERSION=30 dmd -c fuse.i -Hf=fuse.di /usr/include/x86_64-linux-gnu/bits/byteswap.h(34): Error: missing comma or semicolon after declaration of `__uint16_t`, found `__bswap_16` instead /usr/include/x86_64-linux-gnu/bits/byteswap.h(41): Error: no type for declarator before `}` /usr/include/x86_64-linux-gnu/bits/byteswap.h(49): Error: missing comma or semicolon after declaration of `__uint32_t`, found `__bswap_32` instead /usr/include/x86_64-linux-gnu/bits/byteswap.h(56): Error: no type for declarator before `}` /usr/include/x86_64-linux-gnu/bits/byteswap.h(69): Error: missing comma or semicolon after declaration of `__inline`, found `__uint64_t` instead /usr/include/x86_64-linux-gnu/bits/byteswap.h(77): Error: no type for declarator before `}` /usr/include/x86_64-linux-gnu/bits/uintn-identity.h(33): Error: missing comma or semicolon after declaration of `__uint16_t`, found `__uint16_identity` instead /usr/include/x86_64-linux-gnu/bits/uintn-identity.h(36): Error: no type for declarator before `}` /usr/include/x86_64-linux-gnu/bits/uintn-identity.h(39): Error: missing comma or semicolon after declaration of `__uint32_t`, found `__uint32_identity` instead /usr/include/x86_64-linux-gnu/bits/uintn-identity.h(42): Error: no type for declarator before `}` /usr/include/x86_64-linux-gnu/bits/uintn-identity.h(45): Error: missing comma or semicolon after declaration of `__uint64_t`, found `__uint64_identity` instead /usr/include/x86_64-linux-gnu/bits/uintn-identity.h(48): Error: no type for declarator before `}` /usr/include/x86_64-linux-gnu/sys/select.h(102): Error: found `__readfds` when expecting `,` /usr/include/x86_64-linux-gnu/sys/select.h(102): Error: no type-specifier for parameter /usr/include/x86_64-linux-gnu/sys/select.h(103): Error: found `__writefds` when expecting `,` /usr/include/x86_64-linux-gnu/sys/select.h(103): Error: no type-specifier for parameter /usr/include/x86_64-linux-gnu/sys/select.h(104): Error: found `__exceptfds` when expecting `,` /usr/include/x86_64-linux-gnu/sys/select.h(104): Error: no type-specifier for parameter /usr/include/x86_64-linux-gnu/sys/select.h(105): Error: found `__timeout` when expecting `,` /usr/include/x86_64-linux-gnu/sys/select.h(127): Error: found `__readfds` when expecting `,` ``` I use debian 12 amd64.
Nov 11 2023
next sibling parent d007 <d007 gmail.com> writes:
On Saturday, 11 November 2023 at 08:02:29 UTC, d007 wrote:
 On Monday, 23 October 2023 at 18:00:39 UTC, Walter Bright wrote:
 [...]
today I try use importC with libfuse3. DMD64 D Compiler v2.106.0-beta.1 [...]
Tips ? Walter Bright ?
Nov 24 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2023 12:02 AM, d007 wrote:
 dmd -c fuse.i -Hf=fuse.di
 
 /usr/include/x86_64-linux-gnu/bits/byteswap.h(34): Error: missing comma or 
 semicolon after declaration of `__uint16_t`, found `__bswap_16` instead
Try isolating the lines in byteswap.h that cause the error.
Nov 24 2023
parent reply d007 <d007 gmail.com> writes:
On Saturday, 25 November 2023 at 05:21:55 UTC, Walter Bright 
wrote:
 On 11/11/2023 12:02 AM, d007 wrote:
 dmd -c fuse.i -Hf=fuse.di
 
 /usr/include/x86_64-linux-gnu/bits/byteswap.h(34): Error: 
 missing comma or semicolon after declaration of `__uint16_t`, 
 found `__bswap_16` instead
Try isolating the lines in byteswap.h that cause the error.
I am not sure what cloud be done with this, here is the code from `/usr/include/x86_64-linux-gnu/bits/byteswap.h` ```c #if !defined _BYTESWAP_H && !defined _NETINET_IN_H && !defined _ENDIAN_H <byteswap.h> instead." #endif #ifndef _BITS_BYTESWAP_H #define _BITS_BYTESWAP_H 1 #include <features.h> #include <bits/types.h> /* Swap bytes in 16-bit value. */ #define __bswap_constant_16(x) \ ((__uint16_t) ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8))) static __inline __uint16_t __bswap_16 (__uint16_t __bsx) { #if __GNUC_PREREQ (4, 8) return __builtin_bswap16 (__bsx); #else return __bswap_constant_16 (__bsx); #endif } ```
Nov 24 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
Thank you

https://issues.dlang.org/show_bug.cgi?id=24304
Dec 27 2023
prev sibling next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 Bruce and Adam and I met at a Red Robin in Seattle to chat 
 about D, and they both made a case for the D compiler being 
 able to translate C files into .di "header" files.
If anybody else is in the area on the third Wednesday of the month we usually meetup at the NWCPP talk and then head out somewhere afterwards to chat. Usually D, sometimes not. If you want more details you can DM me on Discord.
 The idea is to:

 1. be able to work with D IDE programs that can only deal with 
 D code

 2. be able to handle the vast bulk of converting .h to D code, 
 and then tweak by hand the bits that didn't translate well
3. Can be useful for debugging calls to ImportC methods so you can see where you messed up at the call site.
 Anyhow, I pontificated that this couldn't be done, because some 
 C code is not representable as D code. Silly me.

 But I got to thinking about it. It turns out that DMD can 
 currently do this:

     dmd -c test.c -Hf=test.di

 and voila! It creates a .di file from the C file. Who knew?
This is pretty much how I stumbled on to it at DConf this year. I briefly started with a hand translation of the ODBC 4 headers, got bored, then Nick Wilson suggested I look into ImportC, and then I just decided to smash the -Hf onto the end to see if it would work. The first file I tried it on worked, so I kept going. Eventually I ran into an anonymous tagged enum that D doesn't support, but the trick was to just comment it out and retry. D simply doesn't support every C semantic, and that's OK, it's not supposed to, so where it doesn't, some better error messages are all we need to make this system more accessible. But it works! One place I can see something like this being popular is building DUB-based Code-D enabled (VSCode and others) bindings for non-source-available C libraries. There is a universe of C libraries waiting for us to generate bindings and bring them to D. And if you miss DConf, you're really missing out. The interactions are top-shelf, and even if you don't learn anything from the talks (but you will), the discussions you have with the attendees more than make up the price of admission.
 It could use some adjustment, but the bulk is there and it 
 didn't crash or launch nuclear missiles. (Phew!)
Some helpful adjustments (if possible): - Ability to set an explicit module name for the DI file. (Useful for creating properly namespaced bindings for libraries like ODBC.) - One module per header file. For example, in the ODBC headers, they all reference a common header for types. If D could follow that on the output side we wouldn't have undo the duplicated types by hand. Don't know if it's possible, but it'd be a serious time saver. Mix all that together and there are some significant gains to made to the language's capabilities just by importing C libraries. I love it! -AW
Oct 24 2023
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/24/2023 5:29 PM, Adam Wilson wrote:
 Eventually I ran into an anonymous tagged enum that D doesn't 
 support, but the trick was to just comment it out and retry.
File it as a bugzilla!
Oct 24 2023
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 25 October 2023 at 01:26:43 UTC, Walter Bright 
wrote:
 On 10/24/2023 5:29 PM, Adam Wilson wrote:
 Eventually I ran into an anonymous tagged enum that D doesn't 
 support, but the trick was to just comment it out and retry.
File it as a bugzilla!
Way ahead of you. From DConf: https://issues.dlang.org/show_bug.cgi?id=24121
Oct 24 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/24/2023 7:42 PM, Adam Wilson wrote:
 Way ahead of you. From DConf: https://issues.dlang.org/show_bug.cgi?id=24121
Thanks. I think I can take care of it.
Oct 24 2023
prev sibling parent reply singingbush <singingbush hotmail.com> writes:
On Wednesday, 25 October 2023 at 00:29:17 UTC, Adam Wilson wrote:
 This is pretty much how I stumbled on to it at DConf this year. 
 I briefly started with a hand translation of the ODBC 4 
 headers, got bored, then Nick Wilson suggested I look into 
 ImportC, and then I just decided to smash the -Hf onto the end 
 to see if it would work. The first file I tried it on worked, 
 so I kept going. Eventually I ran into an anonymous tagged enum 
 that D doesn't support, but the trick was to just comment it 
 out and retry.

 ...
What's the status of your ODBC 4 work? Is it something you plan on creating a dub package for? Potentially it could be worth putting the changes into the current [odbc package](https://code.dlang.org/packages/odbc) (copied from _etc.c.odbc.*_ so that it can be used in DDBC & HibernateD) which is v3 only.
Oct 26 2023
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 26 October 2023 at 13:50:26 UTC, singingbush wrote:
 What's the status of your ODBC 4 work? Is it something you plan 
 on creating a dub package for? Potentially it could be worth 
 putting the changes into the current [odbc 
 package](https://code.dlang.org/packages/odbc) (copied from 
 _etc.c.odbc.*_ so that it can be used in DDBC & HibernateD) 
 which is v3 only.
I am currently awaiting a couple of bug-fixes to ImportC, but I've been using my local hacked up version of the ODBC4 headers for inclusion in Phobos, so I can confirm that the ImportC version of the MSFT standard headers work, with workarounds. (Repo here: https://github.com/microsoft/ODBC-Specification/) As for where it will end up. I've already received support for merging ODBC4 into etc.c.odbc, which is why those packages are rescued from deprecation in 2.106 and fixed up to enable working on non-Windows platforms. And merging it into etc.c.odbc makes it easier to get my Recordset code included in Phobos. DConf this year was good for SQL/DB folks.
Oct 26 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 27 October 2023 at 01:22:43 UTC, Adam Wilson wrote:
 On Thursday, 26 October 2023 at 13:50:26 UTC, singingbush wrote:
 [...]
I am currently awaiting a couple of bug-fixes to ImportC, but I've been using my local hacked up version of the ODBC4 headers for inclusion in Phobos, so I can confirm that the ImportC version of the MSFT standard headers work, with workarounds. (Repo here: https://github.com/microsoft/ODBC-Specification/) [...]
Many thanks for your work.
Oct 26 2023
prev sibling parent reply singingbush <singingbush hotmail.com> writes:
On Friday, 27 October 2023 at 01:22:43 UTC, Adam Wilson wrote:
 On Thursday, 26 October 2023 at 13:50:26 UTC, singingbush wrote:
 What's the status of your ODBC 4 work? Is it something you 
 plan on creating a dub package for? Potentially it could be 
 worth putting the changes into the current [odbc 
 package](https://code.dlang.org/packages/odbc) (copied from 
 _etc.c.odbc.*_ so that it can be used in DDBC & HibernateD) 
 which is v3 only.
... As for where it will end up. I've already received support for merging ODBC4 into etc.c.odbc, which is why those packages are rescued from deprecation in 2.106 and fixed up to enable working on non-Windows platforms. And merging it into etc.c.odbc makes it easier to get my Recordset code included in Phobos.
Wait, _etc.c.odbc_ is no longer being removed? That's good to know. I was not aware of it. Was there an announcement somewhere? The last I heard about this was in a thread I started in May 2021: https://forum.dlang.org/thread/rspvigghtqnerlbszctx forum.dlang.org?page=1 It seemed at the time that a dub package was the way to go
Oct 27 2023
parent Adam Wilson <flyboynw gmail.com> writes:
On Friday, 27 October 2023 at 15:25:31 UTC, singingbush wrote:
 Wait, _etc.c.odbc_ is no longer being removed? That's good to 
 know. I was not aware of it. Was there an announcement 
 somewhere?

 The last I heard about this was in a thread I started in May 
 2021:
 https://forum.dlang.org/thread/rspvigghtqnerlbszctx forum.dlang.org?page=1

 It seemed at the time that a dub package was the way to go
Correct. I was able to rescue it at DConf and patched it up to work on non-Windows systems. No major announcement, just an entry in in the changelog: https://dlang.org/changelog/pending.html#PR8804 I didn't think it worthy of a forum announcement or anything, although that may be blindness on my part as I talked to a bunch of people at DConf about it and most seemed OK with it, so I just went ahead and did it. Reading the thread you linked it seems that people raised the same issues I did. Interesting. It appears that nobody realized that the MinGW versions, aside from being ancient, were also version(Windows), which is just hysterically wrong. They should never have been in DRT to begin with.
Oct 27 2023
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 and voila! It creates a .di file from the C file. Who knew?
I knew. In fact, it only works because I fixed it myself: https://github.com/dlang/dmd/pull/15557
 It could use some adjustment, but the bulk is there and it 
 didn't crash or launch nuclear missiles. (Phew!)
https://www.youtube.com/watch?v=79DijItQXMM
Oct 24 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/24/2023 5:52 PM, Adam D Ruppe wrote:
 I knew. In fact, it only works because I fixed it myself:
 
 https://github.com/dlang/dmd/pull/15557
Thanks for fixing it.
Oct 24 2023
prev sibling next sibling parent reply Dave P. <dave287091 gmail.com> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 [...]
I’ve filed some bugs that block this feature from being useful: https://issues.dlang.org/show_bug.cgi?id=24199 https://issues.dlang.org/show_bug.cgi?id=24200 https://issues.dlang.org/show_bug.cgi?id=24201
Oct 25 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/25/2023 9:33 AM, Dave P. wrote:
 I’ve filed some bugs that block this feature from being useful:
Thank you. It's nice to see the interest in this feature!
Oct 26 2023
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Friday, 27 October 2023 at 01:44:01 UTC, Walter Bright wrote:
 On 10/25/2023 9:33 AM, Dave P. wrote:
 I’ve filed some bugs that block this feature from being useful:
Thank you. It's nice to see the interest in this feature!
Don't hurt me, but would the solution I present in this bug work? https://issues.dlang.org/show_bug.cgi?id=24132#c4
Oct 28 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 28 October 2023 at 09:50:19 UTC, Adam Wilson wrote:
 On Friday, 27 October 2023 at 01:44:01 UTC, Walter Bright wrote:
 On 10/25/2023 9:33 AM, Dave P. wrote:
 I’ve filed some bugs that block this feature from being 
 useful:
Thank you. It's nice to see the interest in this feature!
Don't hurt me, but would the solution I present in this bug work? https://issues.dlang.org/show_bug.cgi?id=24132#c4
Interesting. Need to try and see what happens :D
Oct 28 2023
prev sibling next sibling parent singingbush <singingbush hotmail.com> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 ...
It would be nice if the Intellij plugin could do this by right-clicking on a c file. I've created a github issue for it: https://github.com/intellij-dlanguage/intellij-dlanguage/issues/906
Oct 26 2023
prev sibling parent Bradley Chatha <sealabjaster gmail.com> writes:
On Saturday, 21 October 2023 at 02:13:24 UTC, Walter Bright wrote:
 ...
Great hidden feature! I just tried this out for converting the libsodium headers into a .di file. It requires a little work before turning it into a .di (e.g. removing extensions) and then a little bit after (since the compiler generates code like `void someFunc(const struct someStruct* param1)`. But after a few seds and a small D script to remove declarations I don't care about, it actually wasn't too painful compared to using something like dstep which is a 50/50 gamble on whether it works, and is a much bigger pain to automatically clean the output of.
Dec 27 2023