16.07.2018 17:32, bachmeier пишет:
> On Friday, 13 July 2018 at 19:53:45 UTC, Laeeth Isharc wrote:
>> On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote:
> 
>>> What are your ideas?
>>
>> If you would like to expose C function and type declarations to D, you could take a look at DPP, which allows you to just #include a C header.  If you encounter a bug, please file an issue and in time we will fix it.
>>
>> Does not yet work for C++ except in some cases.
>>
>> https://github.com/atilaneves/dpp
> 
> I would like to give this a try, but I don't see any instructions for installation on the Github page. I tried dub build dpp, but I got a bunch of error messages.
I just build it using dub then do something like that(from memory):
`d++ some_c_header.h --include-path path/to/other/c/header/files --keep-d-files` and it generates d file for the corresponding c header. Although dpp is intended to be used directly I use it for generating intermediate files. First of all because when I tried to import nuklear.h dpp generated nuklear.d with simple error - due to bug it included diagnostic message of libclang into d file and it was simpler and faster to edit intermediate file manually than wait for bug fixing.

On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote:
> I just build it using dub then do something like that(from memory):
> `d++ some_c_header.h --include-path path/to/other/c/header/files --keep-d-files` and it generates d file for the corresponding c header. Although dpp is intended to be used directly I use it for generating intermediate files. First of all because when I tried to import nuklear.h dpp generated nuklear.d with simple error - due to bug it included diagnostic message of libclang into d file and it was simpler and faster to edit intermediate file manually than wait for bug fixing.

I'm going to create an issue on Github. This is the output I get:

$ dub build dpp
Building package dpp in /home/office/.dub/packages/dpp-0.0.1/dpp/
WARNING: A deprecated branch based version specification is used for the dependency libclang. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.
Performing "debug" build using /usr/bin/dmd for x86_64.
libclang ~master: target for configuration "library" is up to date.
dpp 0.0.1: building configuration "executable"...
.dub/packages/dpp-0.0.1/dpp/source/dpp/runtime/app.d(106,16): Warning: C preprocessor directive #define is not supported
.dub/packages/dpp-0.0.1/dpp/source/dpp/cursor/typedef_.d(89,9): Error: @nogc function dpp.cursor.typedef_.isSomeFunction cannot call non-@nogc function clang.Type.pointee
.dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(176,8): Error: incompatible types for (type.pointee()) is (null): Type and typeof(null)
.dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(177,12): Error: incompatible types for (type.pointee()) !is (null): Type and typeof(null)
.dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(184,40): Error: can only * a pointer, not a Type
.dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(192,21): Error: can only * a pointer, not a Type
.dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(202,22): Error: cannot implicitly convert expression (*ptr).pointee() of type Type to const(Type)*
.dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(246,31): Error: can only * a pointer, not a Type
/usr/bin/dmd failed with exit code 1.

On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote:
> On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote:
>> [...]
>
> I'm going to create an issue on Github. This is the output I get:
>
> [...]

I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice.

On Tuesday, 17 July 2018 at 16:39:48 UTC, bachmeier wrote:
> On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote:
>> On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote:
>>> [...]
>>
>> I'm going to create an issue on Github. This is the output I get:
>>
>> [...]
>
> I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice.

Echoing what Andrei and Walter say all the time, it's not going to get fixed without bug reports...

On Tuesday, 17 July 2018 at 22:10:52 UTC, jmh530 wrote:
> On Tuesday, 17 July 2018 at 16:39:48 UTC, bachmeier wrote:
>> On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote:
>>> On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote:
>>>> [...]
>>>
>>> I'm going to create an issue on Github. This is the output I get:
>>>
>>> [...]
>>
>> I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice.
>
> Echoing what Andrei and Walter say all the time, it's not going to get fixed without bug reports...

I plan to report this...eventually.

On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote:

> Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification.

Can confirm that dpp works to create mex files. Rewriting the mypow2.c example in D:

File mypow3.dpp

#include "mex.h"
import std.conv, std.stdio;

extern(C) void mexFunction(int nlhs, mxArray** plhs,
             int nrhs, const mxArray** prhs) {
  mwSize n;
  mwIndex i;
  double * vri;
  double * vro;

  if (nrhs != 1 || !mxIsDouble(prhs[0]))
    mexErrMsgTxt ("ARG1 must be a double matrix");

  n = mxGetNumberOfElements(prhs[0]).to!int;
  plhs[0] = mxCreateNumericArray (mxGetNumberOfDimensions (prhs[0]),
                                  mxGetDimensions (prhs[0]),
                                  mxGetClassID (prhs[0]),
                                  mxIsComplex(prhs[0]).to!mxComplexity);
  vri = mxGetPr (prhs[0]);
  vro = mxGetPr (plhs[0]);

  if (mxIsComplex (prhs[0])) {
      double* vii, vio;
      vii = mxGetPi (prhs[0]);
      vio = mxGetPi (plhs[0]);

      for (i = 0; i < n; i++)
        {
          vro[i] = vri[i] * vri[i] - vii[i] * vii[i];
          vio[i] = 2 * vri[i] * vii[i];
        }
  } else {
      for (i = 0; i < n; i++)
        vro[i] = vri[i] * vri[i];
    }
}

Create the shared library using the information provided by mkoctfile:

d++ -c -fPIC --include-path /usr/include/octave-4.2.2/octave/.. \
--include-path /usr/include/octave-4.2.2/octave \
--include-path /usr/include/hdf5/serial mypow3.dpp

dmd -shared -defaultlib=libphobos2.so -of=mypow3.mex mypow3.o \
-L/usr/lib/x86_64-linux-gnu/liboctinterp.so \
-L/usr/lib/x86_64-linux-gnu/liboctave.so


In Octave:

>> b = randn (4,1);
>> mypow3(b)
ans =

   0.45984
   3.54732
   0.30075
   2.09107

On Friday, 20 July 2018 at 15:20:43 UTC, bachmeier wrote:
> 
>
> Can confirm that dpp works to create mex files. Rewriting the mypow2.c example in D:
>
> [snip]

This sounds really great. I assume if it works with Octave it is very likely to work with Matlab's mex.h without issues (I might get dragged in to using Matlab again here soon).