Re: [R-pkg-devel] Saving output of check()
I have at various times tried the built-in (tools package) solution;
fairly complex hand-rolled stuff I did myself; and revdepcheck. I found
that revdepcheck handled installation of needed dependencies, including
caching packages where necessary, more easily. It felt like the 'tools'
machinery worked better if I already had all or most of the CRAN
packages installed ... (My experimentation has been done
non-systematically and over a long period of time, so I may well have
mistaken/missed something.)
On 2018-04-11 06:03 PM, Uwe Ligges wrote:
> Not sure why nobody dicusses the R internal check functionality, also
> for reverse dependencies, from the tools package?
> That is what CRAN uses for the reverse dependency checks.
>
> Best,
> Uwe Ligges
>
>
>
>
> On 11.04.2018 23:14, J C Nash wrote:
>> Another workaround is to use
>>
>> tlogl <- readLines(attr(cpkg.chk, "path"))
>>
>> Possibly this may suggest a way to improve functionality.
>>
>> JN
>>
>> On 2018-04-11 03:24 PM, Henrik Bengtsson wrote:
>>> R CMD check, which is used internally runs checks in standalone
>>> background R processes. Output from these is not capturable/sinkable
>>> by the master R process. The gist of what's happening is:
>>>
sink("output.log")
system("echo hello") ## not sinked/captured
>>> hello
sink()
readLines("output.log")
>>> character(0)
>>>
>>> /Henrik
>>>
>>> On Wed, Apr 11, 2018 at 11:05 AM, J C Nash wrote:
Hi,
In trying to test that an upgrade to my optimx package does not
break other
packages, I wanted to loop over a list of all such packages in
alldep, with
nall the length of this list.
cat("Check the dependent packages\n")
for (ii in 1:nall){
cpkg <- alldep[ii]
dd <- "/home/john/temp/wrkopt/dlpkg"
dlname <- download.packages(cpkg, destdir=dd )[[2]]
cat("Downloaded ", dlname,"\n")
cpkg.chk <- devtools::check_built(dlname)
cat("Results package:",cpkg,"\n")
print(cpkg.chk)
}
Before running this, I did
sink("dpkgcheck.txt", split=TRUE)
and afterwards, I did sink().
But ... none of the check output, nor the result of the final print,
show
up in the output file dpkgcheck.txt.
Have I totally misunderstood sink(), or is there a nasty bug?
I've tried running in Rstudio and in the terminal. I'm running Linux
Mint
18.3 Sylvia.
Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10
16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
john@john-j6-18 ~ $ R
R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
J C Nash
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Saving output of check()
Not sure why nobody dicusses the R internal check functionality, also
for reverse dependencies, from the tools package?
That is what CRAN uses for the reverse dependency checks.
Best,
Uwe Ligges
On 11.04.2018 23:14, J C Nash wrote:
Another workaround is to use
tlogl <- readLines(attr(cpkg.chk, "path"))
Possibly this may suggest a way to improve functionality.
JN
On 2018-04-11 03:24 PM, Henrik Bengtsson wrote:
R CMD check, which is used internally runs checks in standalone
background R processes. Output from these is not capturable/sinkable
by the master R process. The gist of what's happening is:
sink("output.log")
system("echo hello") ## not sinked/captured
hello
sink()
readLines("output.log")
character(0)
/Henrik
On Wed, Apr 11, 2018 at 11:05 AM, J C Nash wrote:
Hi,
In trying to test that an upgrade to my optimx package does not break other
packages, I wanted to loop over a list of all such packages in alldep, with
nall the length of this list.
cat("Check the dependent packages\n")
for (ii in 1:nall){
cpkg <- alldep[ii]
dd <- "/home/john/temp/wrkopt/dlpkg"
dlname <- download.packages(cpkg, destdir=dd )[[2]]
cat("Downloaded ", dlname,"\n")
cpkg.chk <- devtools::check_built(dlname)
cat("Results package:",cpkg,"\n")
print(cpkg.chk)
}
Before running this, I did
sink("dpkgcheck.txt", split=TRUE)
and afterwards, I did sink().
But ... none of the check output, nor the result of the final print, show
up in the output file dpkgcheck.txt.
Have I totally misunderstood sink(), or is there a nasty bug?
I've tried running in Rstudio and in the terminal. I'm running Linux Mint
18.3 Sylvia.
Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
john@john-j6-18 ~ $ R
R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
J C Nash
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Saving output of check()
Indeed these are useful for one of my present tasks. Thanks. JN
On 2018-04-11 03:10 PM, Georgi Boshnakov wrote:
>
> Hi,
>
> Not really an answer but I only recently discovered devtools::revdep(),
> which automates checking reverse dependencies.
>
> Georgi Boshnakov
>
>
>
>
>
> From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of J
> C Nash [profjcn...@gmail.com]
> Sent: 11 April 2018 19:05
> To: List r-package-devel
> Subject: [R-pkg-devel] Saving output of check()
>
> Hi,
>
> In trying to test that an upgrade to my optimx package does not break other
> packages, I wanted to loop over a list of all such packages in alldep, with
> nall the length of this list.
>
> cat("Check the dependent packages\n")
> for (ii in 1:nall){
> cpkg <- alldep[ii]
> dd <- "/home/john/temp/wrkopt/dlpkg"
> dlname <- download.packages(cpkg, destdir=dd )[[2]]
> cat("Downloaded ", dlname,"\n")
> cpkg.chk <- devtools::check_built(dlname)
> cat("Results package:",cpkg,"\n")
> print(cpkg.chk)
> }
>
> Before running this, I did
>
> sink("dpkgcheck.txt", split=TRUE)
>
> and afterwards, I did sink().
>
> But ... none of the check output, nor the result of the final print, show
> up in the output file dpkgcheck.txt.
>
> Have I totally misunderstood sink(), or is there a nasty bug?
>
> I've tried running in Rstudio and in the terminal. I'm running Linux Mint
> 18.3 Sylvia.
>
> Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> john@john-j6-18 ~ $ R
>
> R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
>
>
> J C Nash
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Saving output of check()
Another workaround is to use
tlogl <- readLines(attr(cpkg.chk, "path"))
Possibly this may suggest a way to improve functionality.
JN
On 2018-04-11 03:24 PM, Henrik Bengtsson wrote:
> R CMD check, which is used internally runs checks in standalone
> background R processes. Output from these is not capturable/sinkable
> by the master R process. The gist of what's happening is:
>
>> sink("output.log")
>> system("echo hello") ## not sinked/captured
> hello
>> sink()
>> readLines("output.log")
> character(0)
>
> /Henrik
>
> On Wed, Apr 11, 2018 at 11:05 AM, J C Nash wrote:
>> Hi,
>>
>> In trying to test that an upgrade to my optimx package does not break other
>> packages, I wanted to loop over a list of all such packages in alldep, with
>> nall the length of this list.
>>
>> cat("Check the dependent packages\n")
>> for (ii in 1:nall){
>> cpkg <- alldep[ii]
>> dd <- "/home/john/temp/wrkopt/dlpkg"
>> dlname <- download.packages(cpkg, destdir=dd )[[2]]
>> cat("Downloaded ", dlname,"\n")
>> cpkg.chk <- devtools::check_built(dlname)
>> cat("Results package:",cpkg,"\n")
>> print(cpkg.chk)
>> }
>>
>> Before running this, I did
>>
>> sink("dpkgcheck.txt", split=TRUE)
>>
>> and afterwards, I did sink().
>>
>> But ... none of the check output, nor the result of the final print, show
>> up in the output file dpkgcheck.txt.
>>
>> Have I totally misunderstood sink(), or is there a nasty bug?
>>
>> I've tried running in Rstudio and in the terminal. I'm running Linux Mint
>> 18.3 Sylvia.
>>
>> Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10
>> 16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>> john@john-j6-18 ~ $ R
>>
>> R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
>>
>>
>> J C Nash
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Saving output of check()
I got several responses to my query. Henrik's does suggest "why", but I
am rather unhappy that R has this weakness. (See below for a sort of
workaround for Linux users.)
In particular, note that the check_built() function DOES return an object,
but it does NOT print().
In fact, putting alldep <- "embryogrowth" gives a result file
> Check the dependent packages
> Downloaded /home/john/temp/wrkopt/dlpkg/embryogrowth_7.4.tar.gz
> Results package: embryogrowth
>
while the bottom of the terminal file gives
> * checking data for non-ASCII characters ... OK
> * checking data for ASCII and uncompressed saves ... OK
> * checking examples ... OK
> * DONE
>
> Status: OK
>
> Results package: embryogrowth
> R CMD check results
> 0 errors | 0 warnings | 0 notes
>
>>
>> sink()
>>
Now the object cpkg.chk is still present, so I continued the exercise (terminal
copy here)
>
>> ls()
> [1] "alldep" "cpkg" "cpkg.chk" "dd" "dlname" "ii" "nall"
>
>> sink("sinktest2.txt", split=TRUE)
>> cpkg.chk
> R CMD check results
> 0 errors | 0 warnings | 0 notes
>
>> print(cpkg.chk)
> R CMD check results
> 0 errors | 0 warnings | 0 notes
>
>> cat("note the above use just the object name as well as print()\n")
> note the above use just the object name as well as print()
>> sink()
>>
but the file sinktest2.txt is just
>
> note the above use just the object name as well as print()
Perhaps this isn't a bug, but it rather smells like one, especially the
failure to show the cpkg.chk.
Workaround for Linux: Run things via
R |& tee -a myteeoutput.txt
This will keep all the output (sink not needed). But it isn't quite as nice
for keeping the data.
I've also not managed to find a way to get the information out of the cpkg.chk
object. If someone knows how to do that, it would help.
Best, JN
On 2018-04-11 03:24 PM, Henrik Bengtsson wrote:
> R CMD check, which is used internally runs checks in standalone
> background R processes. Output from these is not capturable/sinkable
> by the master R process. The gist of what's happening is:
>
>> sink("output.log")
>> system("echo hello") ## not sinked/captured
> hello
>> sink()
>> readLines("output.log")
> character(0)
>
> /Henrik
>
> On Wed, Apr 11, 2018 at 11:05 AM, J C Nash wrote:
>> Hi,
>>
>> In trying to test that an upgrade to my optimx package does not break other
>> packages, I wanted to loop over a list of all such packages in alldep, with
>> nall the length of this list.
>>
>> cat("Check the dependent packages\n")
>> for (ii in 1:nall){
>> cpkg <- alldep[ii]
>> dd <- "/home/john/temp/wrkopt/dlpkg"
>> dlname <- download.packages(cpkg, destdir=dd )[[2]]
>> cat("Downloaded ", dlname,"\n")
>> cpkg.chk <- devtools::check_built(dlname)
>> cat("Results package:",cpkg,"\n")
>> print(cpkg.chk)
>> }
>>
>> Before running this, I did
>>
>> sink("dpkgcheck.txt", split=TRUE)
>>
>> and afterwards, I did sink().
>>
>> But ... none of the check output, nor the result of the final print, show
>> up in the output file dpkgcheck.txt.
>>
>> Have I totally misunderstood sink(), or is there a nasty bug?
>>
>> I've tried running in Rstudio and in the terminal. I'm running Linux Mint
>> 18.3 Sylvia.
>>
>> Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10
>> 16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>> john@john-j6-18 ~ $ R
>>
>> R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
>>
>>
>> J C Nash
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Saving output of check()
R CMD check, which is used internally runs checks in standalone
background R processes. Output from these is not capturable/sinkable
by the master R process. The gist of what's happening is:
> sink("output.log")
> system("echo hello") ## not sinked/captured
hello
> sink()
> readLines("output.log")
character(0)
/Henrik
On Wed, Apr 11, 2018 at 11:05 AM, J C Nash wrote:
> Hi,
>
> In trying to test that an upgrade to my optimx package does not break other
> packages, I wanted to loop over a list of all such packages in alldep, with
> nall the length of this list.
>
> cat("Check the dependent packages\n")
> for (ii in 1:nall){
> cpkg <- alldep[ii]
> dd <- "/home/john/temp/wrkopt/dlpkg"
> dlname <- download.packages(cpkg, destdir=dd )[[2]]
> cat("Downloaded ", dlname,"\n")
> cpkg.chk <- devtools::check_built(dlname)
> cat("Results package:",cpkg,"\n")
> print(cpkg.chk)
> }
>
> Before running this, I did
>
> sink("dpkgcheck.txt", split=TRUE)
>
> and afterwards, I did sink().
>
> But ... none of the check output, nor the result of the final print, show
> up in the output file dpkgcheck.txt.
>
> Have I totally misunderstood sink(), or is there a nasty bug?
>
> I've tried running in Rstudio and in the terminal. I'm running Linux Mint
> 18.3 Sylvia.
>
> Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> john@john-j6-18 ~ $ R
>
> R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
>
>
> J C Nash
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Saving output of check()
Hi,
Not really an answer but I only recently discovered devtools::revdep(), which
automates checking reverse dependencies.
Georgi Boshnakov
From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of J C
Nash [profjcn...@gmail.com]
Sent: 11 April 2018 19:05
To: List r-package-devel
Subject: [R-pkg-devel] Saving output of check()
Hi,
In trying to test that an upgrade to my optimx package does not break other
packages, I wanted to loop over a list of all such packages in alldep, with
nall the length of this list.
cat("Check the dependent packages\n")
for (ii in 1:nall){
cpkg <- alldep[ii]
dd <- "/home/john/temp/wrkopt/dlpkg"
dlname <- download.packages(cpkg, destdir=dd )[[2]]
cat("Downloaded ", dlname,"\n")
cpkg.chk <- devtools::check_built(dlname)
cat("Results package:",cpkg,"\n")
print(cpkg.chk)
}
Before running this, I did
sink("dpkgcheck.txt", split=TRUE)
and afterwards, I did sink().
But ... none of the check output, nor the result of the final print, show
up in the output file dpkgcheck.txt.
Have I totally misunderstood sink(), or is there a nasty bug?
I've tried running in Rstudio and in the terminal. I'm running Linux Mint
18.3 Sylvia.
Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
john@john-j6-18 ~ $ R
R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
J C Nash
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Saving output of check()
Hi,
In trying to test that an upgrade to my optimx package does not break other
packages, I wanted to loop over a list of all such packages in alldep, with
nall the length of this list.
cat("Check the dependent packages\n")
for (ii in 1:nall){
cpkg <- alldep[ii]
dd <- "/home/john/temp/wrkopt/dlpkg"
dlname <- download.packages(cpkg, destdir=dd )[[2]]
cat("Downloaded ", dlname,"\n")
cpkg.chk <- devtools::check_built(dlname)
cat("Results package:",cpkg,"\n")
print(cpkg.chk)
}
Before running this, I did
sink("dpkgcheck.txt", split=TRUE)
and afterwards, I did sink().
But ... none of the check output, nor the result of the final print, show
up in the output file dpkgcheck.txt.
Have I totally misunderstood sink(), or is there a nasty bug?
I've tried running in Rstudio and in the terminal. I'm running Linux Mint
18.3 Sylvia.
Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
john@john-j6-18 ~ $ R
R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
J C Nash
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] GPL + other licence
I agree with Brian. This type of license is classified by the Free Software Foundation as "lax" or "permissive" because it does not prevent incorporation of the code into proprietary software. Here is what Richard Stallman has to say: https://www.gnu.org/licenses/ license-compatibility.en.html "[L]ax licenses are usually compatible with any copyleft license. In the combined program, the parts that came in under lax licenses still carry them, and the combined program as a whole carries the copyleft license." Hence you can license your package under the GPL. Martyn On Tue, 2018-04-10 at 08:14 -0500, Brian G. Peterson wrote: > I'm not a lawyer, but I don't see why the entire package can't be > released under GPL, while also respecting the QHull license for the > QHull code and the derived QHull portions. > > Many existing R packages released under GPL, and R itself, include BSD > and MIT licensed code. > > The QHull license is a very permissive license, basically BSD or MIT- > like in its permissions. > > BSD and MIT code may be included in GPL'd code, as long as its license > (inclusion of the copyright notice, etc.) is also included where > required. > > GPL applies to the entire work, in this case the R package. I think > you should discuss this with the CRAN maintainers and release the > package under GPL. > > Regards, > > Brian > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] registering native routines
Changing the path solved the problem. Thanks everyone!
Rampal
On 11-Apr-18 14:24, Marcelino de la Cruz Rot wrote:
Thank you for the hint, Henric.
I was also having the same NOTE.
Changing the path from \Rtools\mingw_32\bin to \Rtools\mingw_64\bin
solved it completely. Cheers, Marcelino
El 11/04/2018 a las 11:56, Henric Winell escribió:
Den 2018-04-10 kl. 23:30, skrev Rampal Etienne:
Dear Thomas,
Yes, I followed all those suggestions but it did not fix the x64
notes. Indeed I am using Windows. I am going to try this on a Linux
system.
On a 64-bit system you need to have 64-bit versions of the necessary
tools on the path, but the Rtools installer defaults to 32-bit
versions. The issue was brought up on the R-devel list about a year
ago:
https://stat.ethz.ch/pipermail/r-devel/2017-February/073785.html
Henric Winell
Cheers, Rampal
On 10-Apr-18 14:17, Thomas Petzoldt wrote:
Hi,
I assume you followed "Writing R Extension" and the examples given
in package deSolve (and maybe some other packages).
Am I right that this fixed the i386 notes, but not for x64?
Here I conclude that you tested it on Windows. This is relevant,
because I remember a recent discussion (maybe on this mailing
list), that the "register native routines" check can sometimes
produce false positives on Windows.
Would it be possible for you, to check your package on a recent
Linux system?
Thomas Petzoldt
Am 10.04.2018 um 13:19 schrieb Rampal S. Etienne:
Dear all,
I am using Fortran code with the deSolve package in my package called
"DDD". When checking my package I get the message:
checking compiled code ... NOTE
File 'DDD/libs/x64/DDD.dll':
Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
It is good practice to register native routines and to disable
symbol search.
Although it is "just" a note, I would like to solve this, but after
quite some googling, I cannot find a solution.
I have tried
tools::package_native_routine_registration_skeleton('.')
but this produces nothing, or only an empty file when I specify the
argument con. I put the following R-init_DDD.c in the src folder and
useDynLib("DDD",.registration = TRUE) in the namespace file. #include
#include #include // for NULL
#include
/* .Fortran calls */ extern void
F77_NAME(fill1d)(double *vec, int *DIMP, double *parms, int *II);
extern
void F77_NAME(initmod)(void (*steadyparms)(int *, double *)); extern
void F77_NAME(runmod)(int *neq, double *t, double *Conc, double
*dConc,
double *yout, int *ip); static const R_FortranMethodDef
FortranEntries[]
= { {"fill1d", (DL_FUNC) &F77_NAME(fill1d), 4}, {"initmod", (DL_FUNC)
&F77_NAME(initmod), 1}, {"runmod", (DL_FUNC) &F77_NAME(runmod), 6},
{NULL, NULL, 0} }; void R_init_DDD(DllInfo *dll) {
R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
R_useDynamicSymbols(dll, FALSE); }
Note that I only get the message for x64, but I don't get it for
i386,
which I did before. So somehow, this is only an issue on 64-bit?
How do
I fix this?
Regards,
Rampal
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] registering native routines
Thank you for the hint, Henric.
I was also having the same NOTE.
Changing the path from \Rtools\mingw_32\bin to \Rtools\mingw_64\bin
solved it completely. Cheers, Marcelino
El 11/04/2018 a las 11:56, Henric Winell escribió:
Den 2018-04-10 kl. 23:30, skrev Rampal Etienne:
Dear Thomas,
Yes, I followed all those suggestions but it did not fix the x64
notes. Indeed I am using Windows. I am going to try this on a Linux
system.
On a 64-bit system you need to have 64-bit versions of the necessary
tools on the path, but the Rtools installer defaults to 32-bit
versions. The issue was brought up on the R-devel list about a year ago:
https://stat.ethz.ch/pipermail/r-devel/2017-February/073785.html
Henric Winell
Cheers, Rampal
On 10-Apr-18 14:17, Thomas Petzoldt wrote:
Hi,
I assume you followed "Writing R Extension" and the examples given
in package deSolve (and maybe some other packages).
Am I right that this fixed the i386 notes, but not for x64?
Here I conclude that you tested it on Windows. This is relevant,
because I remember a recent discussion (maybe on this mailing list),
that the "register native routines" check can sometimes produce
false positives on Windows.
Would it be possible for you, to check your package on a recent
Linux system?
Thomas Petzoldt
Am 10.04.2018 um 13:19 schrieb Rampal S. Etienne:
Dear all,
I am using Fortran code with the deSolve package in my package called
"DDD". When checking my package I get the message:
checking compiled code ... NOTE
File 'DDD/libs/x64/DDD.dll':
Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
It is good practice to register native routines and to disable
symbol search.
Although it is "just" a note, I would like to solve this, but after
quite some googling, I cannot find a solution.
I have tried
tools::package_native_routine_registration_skeleton('.')
but this produces nothing, or only an empty file when I specify the
argument con. I put the following R-init_DDD.c in the src folder and
useDynLib("DDD",.registration = TRUE) in the namespace file. #include
#include #include // for NULL #include
/* .Fortran calls */ extern void
F77_NAME(fill1d)(double *vec, int *DIMP, double *parms, int *II);
extern
void F77_NAME(initmod)(void (*steadyparms)(int *, double *)); extern
void F77_NAME(runmod)(int *neq, double *t, double *Conc, double
*dConc,
double *yout, int *ip); static const R_FortranMethodDef
FortranEntries[]
= { {"fill1d", (DL_FUNC) &F77_NAME(fill1d), 4}, {"initmod", (DL_FUNC)
&F77_NAME(initmod), 1}, {"runmod", (DL_FUNC) &F77_NAME(runmod), 6},
{NULL, NULL, 0} }; void R_init_DDD(DllInfo *dll) {
R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
R_useDynamicSymbols(dll, FALSE); }
Note that I only get the message for x64, but I don't get it for i386,
which I did before. So somehow, this is only an issue on 64-bit?
How do
I fix this?
Regards,
Rampal
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
.
--
Marcelino de la Cruz Rot
Depto. de Biología y Geología
Física y Química Inorgánica
Universidad Rey Juan Carlos
Móstoles España
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] registering native routines
On 10 April 2018 at 23:30, Rampal Etienne wrote: | Yes, I followed all those suggestions but it did not fix the x64 notes. | Indeed I am using Windows. I am going to try this on a Linux system. You could consider the R Hub service at https://builder.r-hub.io/ and/or via the CRAN package rhub. It gives you access to over a dozen different configuration, including of course several plain vanilla Linux setups. I use it all the time, and call 'check_for_cran()' which submits to a set of systems suggested for a CRAN submission (ie Windows and Linux and r-release and r-devel) as much of a regular check as submitting to win-builder. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] registering native routines
Den 2018-04-10 kl. 23:30, skrev Rampal Etienne:
Dear Thomas,
Yes, I followed all those suggestions but it did not fix the x64 notes.
Indeed I am using Windows. I am going to try this on a Linux system.
On a 64-bit system you need to have 64-bit versions of the necessary
tools on the path, but the Rtools installer defaults to 32-bit versions.
The issue was brought up on the R-devel list about a year ago:
https://stat.ethz.ch/pipermail/r-devel/2017-February/073785.html
Henric Winell
Cheers, Rampal
On 10-Apr-18 14:17, Thomas Petzoldt wrote:
Hi,
I assume you followed "Writing R Extension" and the examples given in
package deSolve (and maybe some other packages).
Am I right that this fixed the i386 notes, but not for x64?
Here I conclude that you tested it on Windows. This is relevant,
because I remember a recent discussion (maybe on this mailing list),
that the "register native routines" check can sometimes produce false
positives on Windows.
Would it be possible for you, to check your package on a recent Linux
system?
Thomas Petzoldt
Am 10.04.2018 um 13:19 schrieb Rampal S. Etienne:
Dear all,
I am using Fortran code with the deSolve package in my package called
"DDD". When checking my package I get the message:
checking compiled code ... NOTE
File 'DDD/libs/x64/DDD.dll':
Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
It is good practice to register native routines and to disable symbol
search.
Although it is "just" a note, I would like to solve this, but after
quite some googling, I cannot find a solution.
I have tried
tools::package_native_routine_registration_skeleton('.')
but this produces nothing, or only an empty file when I specify the
argument con. I put the following R-init_DDD.c in the src folder and
useDynLib("DDD",.registration = TRUE) in the namespace file. #include
#include #include // for NULL #include
/* .Fortran calls */ extern void
F77_NAME(fill1d)(double *vec, int *DIMP, double *parms, int *II); extern
void F77_NAME(initmod)(void (*steadyparms)(int *, double *)); extern
void F77_NAME(runmod)(int *neq, double *t, double *Conc, double *dConc,
double *yout, int *ip); static const R_FortranMethodDef FortranEntries[]
= { {"fill1d", (DL_FUNC) &F77_NAME(fill1d), 4}, {"initmod", (DL_FUNC)
&F77_NAME(initmod), 1}, {"runmod", (DL_FUNC) &F77_NAME(runmod), 6},
{NULL, NULL, 0} }; void R_init_DDD(DllInfo *dll) {
R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
R_useDynamicSymbols(dll, FALSE); }
Note that I only get the message for x64, but I don't get it for i386,
which I did before. So somehow, this is only an issue on 64-bit? How do
I fix this?
Regards,
Rampal
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
