R and D interop with saucer

[data pulverizer]

On Friday, 5 January 2024 at 16:16:49 UTC, bachmeier wrote:
> On Saturday, 30 December 2023 at 00:50:54 UTC, data pulverizer 
> wrote:
>
> Here is the updated version of embedr: 
> https://github.com/bachmeil/embedrv2
>
> The old version you're referencing is from ages ago. I don't 
> know what you mean by Weka code. There was an old import 
> library from when I tried to get embedding of R inside D to 
> work on Windows.
>
> The updated library generates the R bindings for the user. 
> There might be something useful there, and the code isn't very 
> long: 
> https://github.com/bachmeil/embedrv2/blob/main/inst/embedr/r.d#L1228 There's an extern_R attribute to specify which functions to export to R.
>
> Here's an example from the readme:
>
> ```
> @extern_R ar1irf(double alpha, double shock, int h) {
> 	double[] result;
> 	result ~= shock;
> 	foreach(ii; 1..h) {
> 		result ~= alpha * result.last;
> 	}
> 	return result;
> }
> mixin(exportRFunctions);
>
> double last(double[] v) {
> 	if (v.length > 0) {
> 		return v[$-1];
> 	} else {
> 		return 0.0;
> 	}
> }
> ```
>
> I honestly don't use D much as a replacement for Rcpp any 
> longer. I mostly work in the other direction these days: 
> https://bachmeil.github.io/betterr/ I've been adding Windows 
> support lately so I can share my code with others.
>
> There are possibly things in there that are useful to you 
> (whether D calls R or R calls D is not relevant for working 
> with the API). For instance, if you want to pass a function to 
> R without creating a shared library (one example being an 
> objective function for optimization): 
> https://bachmeil.github.io/betterr/funcptr.html Another is 
> using a custom allocator to pass data to R even if it was 
> allocated in D: 
> https://github.com/bachmeil/betterr/blob/main/testing/testalloc.d There are pieces of knowledge I gained by debugging segfaults, like the fact that certain operations will change the pointer of an array and that sort of thing.

Thank you for your comments. I shall bear them in mind going 
forward. I should however make a correction and some 
clarifications.

Regarding your `R.lib` file (embedrv2 and the previous version), 
I thought it might have something to do with Weka, the machine 
learning library - I got my wires crossed there. Perhaps I was 
reading something to do with the ML library before/while I was 
reading your repo. My point still stands though. I've never 
worked anywhere that would allow a developer to install 
unverified pre-compiled code from an online repo. It would pose 
too much of a security issue.

As I explained my approach is to mirror the 'design language' of 
Rcpp/RInside/cpp11 libraries, because its a great approach, I'm 
familiar with it, and so are many others. A user (including 
myself) will be sensitive to on-boarding and usage friction, so I 
my library will present a clear, familiar, and easy to use 
interface.

I didn't know about your betterr R package. I think it is a 
different approach from the one I would take. I think both Rcpp 
and in particular cpp11 have very good design approaches and 
continuous improvements to their design that gives me plenty to 
think about. They are at the cutting edge and are pushing the 
boundaries, and I think it would be cool to show that D can play 
in the same space with ease, finesse, and style.

I'm pretty happy hacking the C API of R and have become quite 
familiar with its usage and foibles, though there is of course 
always more to learn. It's fun, as is using the power of D with 
R. As with many things it is a matter of patience, diligence, and 
continuous improvement. My focus is to bring the package up to 
scratch to a point where I am happy with it.

To be clear, regarding saucer; at this stage (and for the 
foreseeable future), I'm monomaniacally focused on where I want 
to take the library.