On Tue, 2017-03-07 at 14:57 +, Gábor Csárdi wrote:
> On Tue, Mar 7, 2017 at 2:51 PM, Dirk Eddelbuettel
> wrote:
> [...]
> > > But I just found that using string literals in .Call() works just
> > > fine. Hopefully
> > > this will still be allowed in the long run:
> > >
> > > .Call("c_non_exis
On Tue, Mar 7, 2017 at 2:51 PM, Dirk Eddelbuettel wrote:
[...]
> | But I just found that using string literals in .Call() works just
> | fine. Hopefully
> | this will still be allowed in the long run:
> |
> | .Call("c_non_existent_function_on_this_platform", ...)
>
> So you are adjusting the liter
On 7 March 2017 at 14:47, Gábor Csárdi wrote:
| On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel wrote:
| [...]
| >
| > Could you resort to preprocessor conditioning to only compile the code
| > relevant for a particular platform while hiding away the inapplicable parts?
|
| Yes, I do exactly t
On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel wrote:
[...]
>
> Could you resort to preprocessor conditioning to only compile the code
> relevant for a particular platform while hiding away the inapplicable parts?
Yes, I do exactly that. The problem is that the R code still has
.Call(c_non_ex
On 7 March 2017 at 14:13, Gábor Csárdi wrote:
| Dear All,
|
| I am trying to convert a package to native routine registration, and
| not sure how to
| best solve the problem of C functions that are only used for a single
| platform, i.e.
| Windows, Linux (& Unix) or macOS.
|
| If I simply provid
Dear All,
I am trying to convert a package to native routine registration, and
not sure how to
best solve the problem of C functions that are only used for a single
platform, i.e.
Windows, Linux (& Unix) or macOS.
If I simply provide a different method table for each platform, then the .Call()
st
