Hello,
I am writing an R/Go interoperability tool[1] that work similarly to
Rcpp; the tool takes packages written in Go and performs the necessary
Go type analysis to wrap the Go code with C and R shims that allow the
Go code to then be called from R. The system is largely complete (with
the exc
Thanks, Alex.
That might be good enough for me for this particular concern; in the
absence of a language specification specifying my behaviour and
referring to precedent seems like a reasonable fall back.
Dan
On Tue, 2020-09-08 at 09:33 +0200, Bertram, Alexander wrote:
> Hi Dan,
>
> For what it
r values types as "void *". SEXPs that
> packages
> obtain using the interface in WRE should not be C NULL, only R NULL
> (R_NilValue). External pointers can become C NULL and this is
> documented
> in WRE 5.13.
>
> Best
> Tomas
>
> On 9/6/20 3:44 AM, D
Thanks, Gabriel.
On Mon, 2020-09-07 at 14:38 -0700, Gabriel Becker wrote:
> I cannot speak to initial intent, perhaps others can. I can say that
> there is at least one place where the difference between R_NilValue
> and NULL is very important as of right now. The current design of the
> ALTREP
r values types as "void *". SEXPs that
> packages
> obtain using the interface in WRE should not be C NULL, only R NULL
> (R_NilValue). External pointers can become C NULL and this is
> documented
> in WRE 5.13.
>
> Best
> Tomas
>
> On 9/6/20 3:44 AM, D
On Tue, 2020-09-08 at 12:08 +0200, Tomas Kalibera wrote:
> I am not sure if I understand correctly, but if you were accessing
> directly the memory of SEXPs from Go implementation instead of
> calling
> through exported access functions documented in WRE, that would be a
> really bad idea. Of cours
I was not. I was explaining why my expectations exist. I honestly
surprised that this would be misinterpreted.
Dan
On Tue, 2020-09-08 at 13:47 +0200, Tomas Kalibera wrote:
> Please don't use this list for advertising on other languages, there
> may be other lists for that.
__
Thank you everyone who has helped a non-R developer attempt to build a
tool to extend the R ecosystem.
>From what I've read, it looks like I should document the sexp internals
package I provide as a here-be-dragons package, keep the hand-holding
level of the rgo tool using Cgo calls to perform dat
