[R-pkg-devel] R_registerRoutines, etc.

[Rolf Turner]

I have, like many others it would appear, been struggling with
the new-ish convention of requiring --- or quasi-requiring --- that 
"routines" be "registered" and the warning generated by R CMD check to 
the effect:

> Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
>
> It is good practice to register native routines and to disable symbol
> search.
>
> See 'Writing portable packages' in the 'Writing R Extensions' manual.

Well, the material in the "Writing R Extensions" manual is completely 
incomprehensible to the human mind, which is what I'm equipped with. 
However I found a posting by Ege Rubak on this topic which sent me by a 
slightly roundabout route to a posting by Dirk Eddelbuttel
which told me to use package_native_routine_registration_skeleton() from 
the tools package.

After a bit more struggle, I found that that did the trick.  I have, 
however, a couple of questions remaining.

(1) I found that having an R function with the same name as that of a
routine (Fortran subroutine in this case) that it called, causes all 
sorts of chaos.  I had a function "binsrt" that called a Fortran 
subroutine named "binsrt" and a function "mnnd" that called a Fortran 
subroutine named "mnnd".  This induced several fairly mysterious 
warnings.  I resolved the issue by renaming the R functions "binsrtR"
and "mnndR" respectively, so as to eliminate the name conflict.

Would this be the recommended procedure, or is there a cleverer way to 
eliminate the problem?

(2) The help for package_native_routine_registration_skeleton() says:

> Optionally the skeleton will include declarations for the registered
> routines: they should be checked against the C/Fortran source code, not
> least as the number of arguments is taken from the R code. For .Call and
> .External calls they will often suffice, but for .C and .Fortran calls
> the void * arguments would ideally be replaced by the actual types.

OTOH a post from Ege Rubak (answering a question like unto mine from 
another user) basically says "Don't bother.  It doesn't really matter."

However, being a Good Little Boy, I like to follow instructions exactly. 
  So I tried to replace the "void *" strings by the "actual types", but 
then all hell broke loose.  Consequently I went back to the "void *" 
structures.  That appears to work, but:

    (a) Are there any perils lurking if one just leaves "void *" as is,
        throughout?

    (b) For the sake of completeness, how *does* one replace the "void *"
        constructions with "actual types" in a correct manner?

         Example:  In my init.c file I currently have (as produced by
         package_native_routine_registration_skeleton()) :

> extern void F77_NAME(mnnd)(void *, void *, void *, void *, void *);

         The code in mnnd.f reads:

> subroutine mnnd(x,y,n,dminbig,dminav)
> implicit double precision(a-h,o-z)
> .....

         I.e. the "actual types are "double precision",
         "double precision", "integer", "double precision",
         "double precision".

         So in this case I should (?) replace

> extern void F77_NAME(mnnd)(void *, void *, void *, void *, void *);

         by .... what?  Can anyone tell me?

Thanks.

cheers,

Rolf Turner

-- 
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276