Quantcast

Platform dependent native routine registration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Platform dependent native routine registration

Gábor Csárdi
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()
statements for the other platforms will generate R CMD check warnings,
both for the
"undefined" global functions and the registration "problems":

checking foreign function calls ... WARNING
Registration problems:
  symbol ‘c_keyring_macos_delete’ not in namespace:
   .Call(c_keyring_macos_delete, utf8(keyring), utf8(service), utf8(username))
  symbol ‘c_keyring_macos_get’ not in namespace:
   .Call(c_keyring_macos_get, utf8(keyring), utf8(service), utf8(username))

[...]

See chapter ‘System and foreign language interfaces’ in the ‘Writing R
Extensions’ manual.checking R code for possible problems ... NOTE
b_macos_delete: no visible binding for global variable
  ‘c_keyring_macos_delete’
b_macos_get: no visible binding for global variable
  ‘c_keyring_macos_get’

[...]

Undefined global functions or variables:
  c_keyring_macos_create c_keyring_macos_delete
  c_keyring_macos_delete_keyring c_keyring_macos_get
  c_keyring_macos_list c_keyring_macos_list_keyring
  c_keyring_macos_lock_keyring c_keyring_macos_set
  c_keyring_macos_unlock_keyring

If possible, I would like to avoid defining dummy functions for all functions
that are not available on a certain platform, simply because I have a lot of
them. Is it possible?

Thanks,
Gabor

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Platform dependent native routine registration

Dirk Eddelbuettel

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 provide a different method table for each platform, then the .Call()
| statements for the other platforms will generate R CMD check warnings,
| both for the
| "undefined" global functions and the registration "problems":
|
| checking foreign function calls ... WARNING
| Registration problems:
|   symbol ‘c_keyring_macos_delete’ not in namespace:
|    .Call(c_keyring_macos_delete, utf8(keyring), utf8(service), utf8(username))
|   symbol ‘c_keyring_macos_get’ not in namespace:
|    .Call(c_keyring_macos_get, utf8(keyring), utf8(service), utf8(username))
|
| [...]
|
| See chapter ‘System and foreign language interfaces’ in the ‘Writing R
| Extensions’ manual.checking R code for possible problems ... NOTE
| b_macos_delete: no visible binding for global variable
|   ‘c_keyring_macos_delete’
| b_macos_get: no visible binding for global variable
|   ‘c_keyring_macos_get’
|
| [...]
|
| Undefined global functions or variables:
|   c_keyring_macos_create c_keyring_macos_delete
|   c_keyring_macos_delete_keyring c_keyring_macos_get
|   c_keyring_macos_list c_keyring_macos_list_keyring
|   c_keyring_macos_lock_keyring c_keyring_macos_set
|   c_keyring_macos_unlock_keyring
|
| If possible, I would like to avoid defining dummy functions for all functions
| that are not available on a certain platform, simply because I have a lot of
| them. Is it possible?

Could you resort to preprocessor conditioning to only compile the code
relevant for a particular platform while hiding away the inapplicable parts?

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Platform dependent native routine registration

Gábor Csárdi
On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel <[hidden email]> 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_existent_function_on_this_platform, ...)

and R CMD check picks up on that.

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", ...)

Gabor

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Platform dependent native routine registration

Dirk Eddelbuettel

On 7 March 2017 at 14:47, Gábor Csárdi wrote:
| On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel <[hidden email]> 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_existent_function_on_this_platform, ...)
|
| and R CMD check picks up on that.

Silly me. Of course -- R code does not see the preprocessor.

You could move up one level then and ... do it via configure, ie have
'hidden' files osx-init.c, lnx-init.c, win-init.c and copy in the one you
need on a given platform.
 
| 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 literals on the fly at compilation time?

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Platform dependent native routine registration

Gábor Csárdi
On Tue, Mar 7, 2017 at 2:51 PM, Dirk Eddelbuettel <[hidden email]> 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 literals on the fly at compilation time?

No, I just leave them there. They are not supposed to be called on a platform
where the C function does not exist, and even if they would be, that's just an
error, which is fine.

I could dynamically include/exclude R code at install time, but that is not so
easy, either, I would probably need to deal with the docs as well, etc.

So I'll just leave it there....

G.

> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Platform dependent native routine registration

Martyn Plummer-3
On Tue, 2017-03-07 at 14:57 +0000, Gábor Csárdi wrote:

> On Tue, Mar 7, 2017 at 2:51 PM, Dirk Eddelbuettel <[hidden email]>
> 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 literals on the fly at compilation time?
>
> No, I just leave them there. They are not supposed to be called on a platform
> where the C function does not exist, and even if they would be, that's just an
> error, which is fine.
>
> I could dynamically include/exclude R code at install time, but that is not so
> easy, either, I would probably need to deal with the docs as well, etc.
>
> So I'll just leave it there....

You can put platform-specific R code and documentation in a
subdirectory named "unix" or "windows". But there is no provision for
MacOS-specific R code as far as I know.

Martyn


> G.
>
> > Dirk
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Loading...