On Thursday, 21 October 2021 at 23:06:18 UTC, jfondren wrote:

I've double-checked and the types names are fine in translated C file.

I have the latest compiler installed and I just double-checked by compiling dmd-master with the same result. The specific error is:

Error: function `Rf_allocVector(__tag28, long)` is not callable using argument types `(int, long)`
        cannot pass argument `REALSXP` of type `int` to parameter `__tag28`

Here __tag28 should be SEXPTYPE which is an enum int containing REALSXP.

Another (superficial by maybe related) issue is that REALSXP is an SEXPTYPE which is an enum int under the hood but dmd skips the SEXPTYPE description altogether, even though SEXPTYPE is correctly converted in the imported C file.

I thought I'd ask anyway, it looks like a question for the R community, where #undef R_NO_REMAP in the script has no effect. This is unrelated to the first issue.

As @Imperatorn said (and I was aware as I asked the question) this is a new feature that is currently being worked on, and we should expect and report stuff like this. It's a great feature and lots of people will use it heavily. Including myself.

On Friday, 22 October 2021 at 06:11:35 UTC, data pulverizer wrote:

I think you ran into this issue. The bug fix isn’t part of a released dmd yet.

On Friday, 22 October 2021 at 16:16:22 UTC, Dave P. wrote:

Yes that's the same error. When I try this:

...
this(R_xlen_t n)
  {
    SEXPTYPE _real_ = SEXPTYPE.REALSXP;
    _data = protect(allocVector(_real_, n));
    unprotect(1);
  }
...

I get a slightly more interesting error message:

types.d(43): Error: cannot implicitly convert expression `14` of type `int` to `__tag28`

So it's not recognising REALSXP as an SEXPTYPE, it's as if it is treating SEXPTYPE like a struct rather than an enum.

Also I was wandering, how long will it take release a fix for ImportC? I am aware that it is a new feature, the reason I ask is not to try to rush anyone but to plan my time better.

Many thanks

On Saturday, 23 October 2021 at 16:39:08 UTC, data pulverizer wrote:

...
this(R_xlen_t n)
  {
    SEXPTYPE _real_ = SEXPTYPE.REALSXP;
    _data = protect(allocVector(_real_, n));
    unprotect(1);
  }
...

Looking at that code, I realise didn't need the un/protect.

On Saturday, 23 October 2021 at 17:42:32 UTC, data pulverizer wrote:

...
this(R_xlen_t n)
  {
    SEXPTYPE _real_ = SEXPTYPE.REALSXP;
    _data = protect(allocVector(_real_, n));
    unprotect(1);
  }
...

Actually it's more complicated than that. On construction I do need to call protect and call unprotect or unprotect_ptr when the function in which the object is created returns. At the moment, I'm not even sure (or more likely do not think) that it is suitable to call it as part of the destructor. Anyway, that's an aside.

On Sunday, 24 October 2021 at 05:54:43 UTC, data pulverizer wrote:

Okay since it's stack allocated it's okay to call unprotect in the destructor if the object is a struct but not if it is a class.