I have a bunch of D functions I would like to make available to Excel (and possibly Julia) without having to write wrappers for each function individually.

For Excel, I think one needs two levels of wrapper - one is to create a C style interface [using extern(Windows) calling convention, and pointers to doubles or structs rather than dynamic arrays], and the second is to write the VBA wrapper that calls the C interface.  (There may be more efficient purer ways of doing this, but I don't wish to spend time learning Excel internals/object models, and I know my route will work reasonably well).

So a very simple D function:
double test(double[] inp,  ref double[] oup)
{
	double sum=0.0;
	oup.length=inp.length;
	foreach(i;0..inp.length)
	{
		oup[i]=inp[i]*inp[i];
		sum+=oup[i];
	}
	return sum;
}

and my first attempt at a wrapper:

extern(Windows) double vbwrap_test(double* inp,size_t num_inp,double* oup,size_t num_oup)
{
	double[] arg_inp;
	arg_inp.length=num_inp;
	double[] arg_oup;
	arg_oup.length=num_oup;
	foreach(arg;0..num_inp)
	{
		arg_inp[arg]=inp[arg];
	}

	foreach(arg;0..num_oup)
	{
		arg_oup[arg]=oup[arg];
	}

	return test(arg_inp,arg_oup);
}

I didn't yet write the bit that copies the result from test back to the calling double*.

Slowly learning metaprogramming/CTFE in D, and the code above was generated from the function definition by some horrible looking D code, ready to place into a string mixin.  I need to make it more general (to accept structs etc), and write the VBA wrapper generation too.

But if anyone has any useful pointers or suggestions or would like to help, do let me know.  I guess this project could be of broader application since in the financial and other sectors people still are stuck with Excel as a front end in many cases, for better or for worse.

I will look at LuaD and PyD and Adam's web.d for inspiration..

Julia was just something to think about further down the line.  I haven't used it much yet.


Thanks.


Laeeth.

On 12/18/2014 12:41 PM, Laeeth Isharc wrote:
> I have a bunch of D functions I would like to make available to Excel
> (and possibly Julia) without having to write wrappers for each function
> individually.
>

I've thought about refactoring the reflection parts of pyd into a reusable library for e.g. resurrecting RuD. Come to think of it, that would probably be necessary for supporting pypy.

It'd be a heck of a lot of work, though.



For your wrapper, you can probably do something like

extern(Windows) double vbwrap_test(double* inp,size_t num_inp,double* oup,size_t num_oup)
{
    return test(inp[0 .. num_inp], arg_oup[0 .. num_oup]);
}

with .dup sprinkled in as you see fit. And you don't need to explicitly copy the results back! Might need to take the ref off oup in test..

On Thursday, 18 December 2014 at 20:41:39 UTC, Laeeth Isharc wrote:
> (There may be more efficient purer ways of doing this, but I don't wish to spend time learning Excel internals/object models, and I know my route will work reasonably well).

ActiveX is not internal to Excel. Being a generic component interface, it's available over almost all microsoft technologies.

On Friday, 19 December 2014 at 01:59:05 UTC, Ellery Newcomer wrote:
> On 12/18/2014 12:41 PM, Laeeth Isharc wrote:
>> I have a bunch of D functions I would like to make available to Excel
>> (and possibly Julia) without having to write wrappers for each function
>> individually.
>>
>
> I've thought about refactoring the reflection parts of pyd into a reusable library for e.g. resurrecting RuD. Come to think of it, that would probably be necessary for supporting pypy.
>
> It'd be a heck of a lot of work, though.
>
>
>
> For your wrapper, you can probably do something like
>
> extern(Windows) double vbwrap_test(double* inp,size_t num_inp,double* oup,size_t num_oup)
> {
>     return test(inp[0 .. num_inp], arg_oup[0 .. num_oup]);
> }
>
> with .dup sprinkled in as you see fit. And you don't need to explicitly copy the results back! Might need to take the ref off oup in test..

Thanks for the pointers, Ellery.

What was RuD?  RubyD?


>>There may be more efficient purer ways of doing this, but I
>> don't wish to spend time learning Excel internals/object models, and I know my route will work reasonably well).
>ActiveX is not internal to Excel. Being a generic component interface, it's available over almost all microsoft technologies.

True, but how does that help me right a function I can call from a spreadsheet?  I had understood ActiveX was for scripting the app, but not so useful if you want to write a function  that can be entered in a cell formula.  So it seems to me that ActiveX doesn't create an obvious way to avoid  writing a C API wrapper and then VBA wrapper around that.