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
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.
On Tue, Sep 8, 2020 at 4:12 AM Tomas Kalibera wrote:
>
>
> The general principle is that R packages are only allowed to use what is
> documented in the R help (? command) and in Writing R Extensions. The
> former covers what is allowed from R code in extensions, the latter
> mostly what is
On 9/8/20 1:13 PM, Dan Kortschak wrote:
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
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
Thanks, Tomas.
This is unfortunate. Calling between Go and C is not cheap; the gc
implementation of the Go compiler (as opposed to gccgo) uses different
calling conventions from C and there are checks to ensure that Go
allocated memory pointers do not leak into C code. For this reason I
wanted
On 9/8/20 11:47 AM, Dan Kortschak wrote:
Thanks, Tomas.
This is unfortunate. Calling between Go and C is not cheap; the gc
implementation of the Go compiler (as opposed to gccgo) uses different
calling conventions from C and there are checks to ensure that Go
allocated memory pointers do not
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
Thanks, Tomas.
This is unfortunate. Calling between Go and C is not cheap; the gc
implementation of the Go compiler (as opposed to gccgo) uses different
calling conventions from C and there are checks to ensure that Go
allocated memory pointers do not leak into C code. For this reason I
wanted
Hi Dan,
For what it's worth, Renjin requires LISTSXPs to hold either a LISTSXP or a
NULL, and this appears to be largely the case in practice based on running
tests for thousands of packages (including cross compiled C code). I can
only remember it being briefly an issue with the rlang package,
Dan,
Sounds like a cool project! Response to one of your questions inline
On Mon, Sep 7, 2020 at 4:24 AM Dan Kortschak via R-devel <
r-devel@r-project.org> wrote:
>
> The last question is more a question of interest in design strategy,
> and the answer may have been lost to time. In order to
The general principle is that R packages are only allowed to use what is
documented in the R help (? command) and in Writing R Extensions. The
former covers what is allowed from R code in extensions, the latter
mostly what is allowed from C code in extensions (with some references
to
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
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
14 matches
Mail list logo
