Okay I'm definitely trying to use importC rather than the regular extern(C) way. I can see where I went wrong. The steps for importC for header files are:

1. Prepend the following directives to test_og.c or whatever your interface c script is:

#define __restrict restrict
#define __asm__ asm
#define __extension__
#define __inline
#define __builtin_bswap16
#define __builtin_bswap32
#define __builtin_bswap64

2. Run the commands:

gcc -E -P test_og.c > test_c.c
dmd test.d test_c.c && ./test

which works. Now I've tried the same thing with library fftw3 and getting:

Error: undefined identifier `__float128`

Which I guess I have to define somehow in the original c directives?

On Sunday, 17 October 2021 at 03:38:43 UTC, data pulverizer wrote:

gcc -E -P test_og.c > test_c.c
dmd test.d test_c.c && ./test

Error: undefined identifier `__float128`

Yep, you have to look at test_c.c and fine the line with that error and decide what to do about it.

I ended up defining typedef struct __float128__ {unsigned long long x[2];} __float128__; and doing a find and replace for __float128 which is totally overkill since I won't be using it and according to the documentation, the D compiler doesn't support 128-bit floats yet though it has reserved keywords for it.

Many thanks.

On Sunday, 17 October 2021 at 04:45:26 UTC, data pulverizer wrote:

Decided the best idea to just to comment it out altogether.

Okay wow, this is amazing, I can now call R's standalone math library Rmath.h by converting:

//r2d_con.c
#define __restrict restrict
#define __asm__ asm
#define __extension__
#define __inline
#define __builtin_bswap16
#define __builtin_bswap32
#define __builtin_bswap64

#define MATHLIB_STANDALONE 1
typedef struct _Float128 {unsigned long long x[2];} _Float128;
#include "Rmath.h"
#include "R_ext/Random.h"

//callr
import r2d;
import std.random: unpredictableSeed;
import std.stdio: writeln;

void main()
{
  set_seed(unpredictableSeed(), unpredictableSeed());
  writeln("rgamma (2, 3): ", rgamma(2, 3));
}

Using:

gcc -E -P -I"/usr/share/R/include" -lRmath r2d_con.c > r2d.c
dmd callr.d -L-lRmath -L-lm && ./callr

Okay it's only the standalone library which is a small part of R, but this rocks. The PAHWAHR! Lol.

On Sunday, 17 October 2021 at 10:46:30 UTC, data pulverizer wrote:

Sorry you don't need -lRmath so the initial call should be:

gcc -E -P -I"/usr/share/R/include" r2d_con.c > r2d.c

On Sunday, 17 October 2021 at 10:46:30 UTC, data pulverizer wrote:

Yeah it's pretty nice hey ☀️

But will become even more convenient later

Hi,

I'm getting an odd issue with ImportC when I import a header converted with gcc -E -P ... some of the types signatures in functions don't come through with their proper names but as __tagXX where XX is some number. It's got to the point where the type itself might get imported correctly, but the same type in a function might be __tag28 or some other mangled name so when I create an instance of the proper type and try to call the respective function, I get a type error.

Also, with some definitions in the C file, when I try to #undef something to get some conditional C definitions to be converted with gcc -E -P ..., nothing happens.

Thanks.

On Thursday, 21 October 2021 at 22:23:50 UTC, data pulverizer wrote:

Just remember you're using stuff that's currently worked on

On Thursday, 21 October 2021 at 22:23:50 UTC, data pulverizer wrote:

I'd first check that the type names look OK in the processed C. If they do, then it's an importc bug. Those are still getting reported, but yours might be new. Worth checking out.

It might also be a bug that's been fixed since release--try dmd master on it. These were fixed a few days ago:

fix Issue 22404 - importC: Error: cannot pass argument 'ENUMMEM' of type 'int' to parameter '__tag2
fix Issue 22402 - importC: Error: can't subtract '__tag2[1]' from pointer

d doesn't do any C preprocessing, so any problem here is with gcc. Your #undefs may be coming before the C preprocessor's own #defines and have no effect.