On Monday, 9 December 2013 at 16:31:54 UTC, Siavash Babaei wrote:
> It seems that I like the whole idea of D a bit too much to act conservatively. So I will start learning it and hope that things will get better by then. Although, I have to insist again, having "something" to call programmes/functions in R and MATLAB easily and readily is a must for D.
> Julia is also an upstart and very intriguing language and seems to have a solid basis, so it might not be a bad idea to collaborate with their Devs.
> On the business side, it is probably not the best idea to `sell' the best and one of the very few learning materials when you are trying to compete with a monster like C++.
> PS- Thank you for your help and once I have learned the language, I will perhaps ask for detailed help ...

Just a thought:

Matlab compiler (http://www.mathworks.co.uk/products/compiler/description2.html) produces a C header file for the library it generates.

There is a tool DStep (https://github.com/jacob-carlborg/dstep) that can convert C headers to D modules.


So, the following steps should work:


generate the C header and shared library from matlab

run DStep on the header

import the generated d module

use the relevant matlab functions you want in your program

link with the shared library when compiling.

On Saturday, 7 December 2013 at 17:08:49 UTC, Joseph Rushton Wakeling wrote:
> On 06/12/13 03:16, bachmeier wrote:
>> I have been using R and D together for several months. It is easy to embed
>> either inside the other. Unfortunately I have not found the time to write up any
>> decent notes about it. With the latest release of DMD, my workflow is to create
>> shared libraries with D and call them from R. Using the .C interface from R is
>> simple, but not much fun. I wrote up a few notes here:
>>
>> http://lancebachmeier.com/wiki/doku.php?id=rlang:calling-d
>
> That's very cool, and also something of a relief to see, as I think interfacing nicely with R is an essential feature for a programming language in some domains of research.
>
>> What I've been working on lately is a .Call-based interface that provides some
>> of the same convenience as Rcpp. I call into Gretl's C API to get a wide range
>> of econometric functions. It works well enough that I'm going to give a lecture
>> to my graduate students on calling D functions from R next week.
>>
>> To embed R inside D, which is maybe more what you're after, I created a simple C
>> interface to RInside. That works well. Unfortunately I don't have notes on that
>> either.
>>
>> I'll be happy to share more if any of this will help you.
>
> I think that you would be doing everyone a big favour if you would provide a good writeup on this.  Can I also suggest making a talk proposal to DConf 2014 about this work?

I will write something up as soon as I can, but it might be a while before that happens. I will also share my code for the .Call interface. Hopefully I will get feedback from someone more knowledgeable about D.

I'll leave DConf to the experts. I'm an economist who taught himself to program.

> Question: I remember a colleague who had worked on linking a C library into R telling me that he'd had to make copies of data before passing into R, because R expects variables to be immutable.  Is there anything that you can do with D's support for immutability that lets you avoid this?  Or are you constrained by the fact that you need to use an extern(C) API?

Your colleague might well be right, but I'm not familiar with that issue. In the other direction (R to C) you want to copy the data before mutating. Suppose you have

x <- c(1,2,3)
y <- x
.Call("foo", y)

R does a lazy copy of x into y, such that y is a pointer to x until the copy is actually needed. In this example, when you pass y from R to C, all you're passing is a pointer to the struct (SEXP). On the C side, you can do anything you want with that pointer, and it will modify both y and x unless you make a copy of y.

You can create an SEXP on the C side and pass it into R, but that's a bit clumsy so I avoid it. Whether I'm embedding R in C/C++/D or vice versa I do the allocation in R. Moving data between R and D is nothing more than passing a pointer around.

Here is a related link that is relevant to D:

https://stat.ethz.ch/pipermail/r-sig-mixed-models/attachments/20131209/ec911711/attachment.pl

It's an announcement that he's moving to Julia, but part of the problem is

"Eigen is a complex code base using what is called "template
meta-programming" in C++.  Making modifications to such code can be
difficult.  I can't claim to fully understand all the details in Eigen and
in Rcpp.  I am a user of these code bases, not a developer."

That's my experience as well. C++ is fine for simple things, but once you cross the line from simple to intermediate, all hell breaks loose. D is IMO a much better choice for working with R because it's possible to understand what is going on inside the D code even if you have less than 10 years of D programming experience.

Since it is not your (no-one specifically) job to do so and you are probably not as `expert', it is likely that you will mess things up. It is also time consuming ... The concept of "division of labour" has been around for several thousand years, after all.
C++, R, MATLAB, and the like have really aged and besides a large community/ecosystem, you cannot consider them good programming languages anymore. It would be nice to see more collaboration between D and Julia, while providing support for other necessary languages, so that things get done in the mean time.

Thank you ... load of my mind

On 09/12/13 21:22, bachmeier wrote:
> I will write something up as soon as I can, but it might be a while before that
> happens. I will also share my code for the .Call interface. Hopefully I will get
> feedback from someone more knowledgeable about D.
>
> I'll leave DConf to the experts. I'm an economist who taught himself to program.

It's always worth remembering that while there are probably plenty of people here who are more expert in D, you may be much rarer in having practical experience of R and in using it effectively in combination with D.

The other thing to remember is that it's valuable to highlight diverse use-cases for the language.  Don't be shy about things like this; simply publicizing the challenges of what you're doing is valuable in itself.

So, don't assume that DConf would not want to hear about your work :-)

> Your colleague might well be right, but I'm not familiar with that issue. In the
> other direction (R to C) you want to copy the data before mutating. Suppose you
> have
>
> x <- c(1,2,3)
> y <- x
> .Call("foo", y)
>
> R does a lazy copy of x into y, such that y is a pointer to x until the copy is
> actually needed. In this example, when you pass y from R to C, all you're
> passing is a pointer to the struct (SEXP). On the C side, you can do anything
> you want with that pointer, and it will modify both y and x unless you make a
> copy of y.
>
> You can create an SEXP on the C side and pass it into R, but that's a bit clumsy
> so I avoid it. Whether I'm embedding R in C/C++/D or vice versa I do the
> allocation in R. Moving data between R and D is nothing more than passing a
> pointer around.

Ahh, OK.  Good to know for future reference -- thank you!