[R-sig-dyn-mod] Using dynamically compiled code for use with deSolve in a new package

[Rampal Etienne]

Hi Thomas,

Thanks. Package building works now. However, when running a check, I get:

* checking compiled code ... NOTE
File 'secsse/libs/i386/secsse.dll':
   Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
File 'secsse/libs/x64/secsse.dll':
   Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'

Where should I have made these calls?

Furthermore, I get:

* checking if this is a source package ... WARNING
Subdirectory 'src' contains:
   dimmod.mod

I did not create this file, so don't know where this is coming from. Do 
you have any clue?

Cheers, Rampal


On 30-Nov-17 09:43, Thomas Petzoldt wrote:
> [off-list]
>
> ... but roxygen2 **can** write the useDynLib line itself:
>
>  #' @useDynLib foo
>
> Thomas
>
>
> Am 30.11.2017 um 09:09 schrieb Rampal S. Etienne:
>> Hi Thomas,
>>
>> Thanks. I got it to work. The solution was to not let roxygen do the
>> namespace file, as it overwrites the line containing useDynLib.
>>
>> Cheers, Rampal
>>
>>
>> On 29-11-2017 23:30, Thomas Petzoldt wrote:
>>> Hi,
>>>
>>> including Fortran and/or C sources in /src is exactly what we (and the
>>> other CRAN authors) do. It is self-evident, that binary code (like
>>> dlls) cannot be included in portable packages, that are expected to
>>> run on different operating systems. Details are found in "Writing R
>>> Extensions".
>>>
>>> I don't see a problem with roxygen2, this is exactly how it was
>>> implemented in package "growthrates", mentioned earlier. Let's assume
>>> we have a package called "foo", add the following roxygen-directives
>>> to a file "R/foo-package.R":
>>>
>>> #' @useDynLib foo
>>> #'
>>> #' @importFrom deSolve ode
>>>
>>> Hope it helps,
>>>
>>> Thomas
>>>
>>>
>>> On 29.11.2017 14:44, Rampal S. Etienne wrote:
>>>> Dear Thomas,
>>>>
>>>> Thanks again for this reply. While this may work locally and for some
>>>> users, it does not work in my case where my namespace file is 
>>>> generated
>>>> by roxygen2. Also, CRAN does not like dll-file to be in the package
>>>> (inst folder), so it needs to be built at installation. How do I do
>>>> this? Simply including the Fortran code in the src directory does not
>>>> work (gives error 127, whatever that is). Any suggestions?
>>>>
>>>> Cheers, Rampal
>>>>
>>>>
>>>> On 11-6-2017 21:15, Thomas Petzoldt wrote:
>>>>> Hi,
>>>>>
>>>>> that's straightforward.
>>>>>
>>>>> 1) Put deSolve in Depends of your package DESCRIPTION:
>>>>>
>>>>> Depends: deSolve
>>>>>
>>>>>
>>>>> 2) Import the solver function (e.g. ode or lsoda) in the NAMESPACE of
>>>>> your package and declare your dynamic library (.dll or .so)
>>>>>
>>>>> importFrom(deSolve,ode)
>>>>>
>>>>> useDynLib(mypackage)
>>>>>
>>>>>
>>>>> 3) and then use this .dll/.so in the call to ode():
>>>>>
>>>>> ode(...., dllname = "mypackage", .....)
>>>>>
>>>>>
>>>>> An example can be found in package growthrates:
>>>>>
>>>>> https://github.com/tpetzoldt/growthrates/blob/master/pkg/R/grow_twostep.R 
>>>>>
>>>>>
>>>>>
>>>>> Hope it helps,
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>> On 11.06.2017 13:20, Rampal Etienne wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> I have written C and FORTRAN functions to use with deSolve and found
>>>>>> that it works significantly faster than the analogous R 
>>>>>> functions. So
>>>>>> far so good! However, now I want to build a package that uses this
>>>>>> code.
>>>>>> How do I do this? I can include the DLL in the package (so no more
>>>>>> compilation by the user of the package, just loading it), but 
>>>>>> then the
>>>>>> user needs to be able to find it. Where will this be installed?
>>>>>> That may
>>>>>> be different on different systems. Any suggestions?
>>>>>>
>>>>>> Cheers, Rampal
>>>
>>>
>>
>
>