[R-pkg-devel] No reference output from knitr vignettes
Hi, After having converted a couple of package vignettes from Sweave to knitr, I discovered that the reference output generated by R CMD check, i.e., .Rnw.log in the check directory, is now empty except for the timings. When doing the conversion I added knitr to DESCRIPTION's Suggests and VignetteBuilder fields. I also added %\VignetteEngine(knitr::knitr) to the LaTeX preamble in .Rnw. The vignettes are built OK. Am I doing something wrong here? Henric Winell __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note and warning about subdirectory sizes
Den 2016-10-04 kl. 03:02, skrev Luck Buttered:
Hi all,
Thank you for your help. The only original question I am still a bit
stuck on is #3. I read a lot about the command today, and tried
several approaches, but am unsure how to remove that warning.
* checking sizes of PDF files under ‘inst/doc’ ... WARNING
‘gs+qpdf’ made some significant size reductions:
compacted ‘ePort.pdf’ from 1655Kb to 1076Kb
consider running tools::compactPDF(gs_quality = "ebook") on these files
I work on a Mac with both RStudio and terminal (can do either). In
either RStudio or terminal, I could run the command:
compactPDF("inst/doc", qpdf = Sys.which(Sys.getenv("R_QPDF", "qpdf")),
gs_quality = "ebook")
I would not get any output from that. And when I then run:
check()
I noticed the WARNING was still there.
I also ran:
R CMD build --compact-vignettes=gs
What was the output of that command?
Note that using '--compact-vignettes=gs+qpdf', as suggested by the
warning message, typically results in even better compression.
But then when I ran check(), I still noticed the WARNING.
Assuming that this is devtools::check(), which I'm unfamiliar with, a
quick glance at its man page suggests that it checks (and builds) your
*source* file. But the compacted pdfs are in the newly built tarball
that resulted from running 'R CMD build', so I think you want
devtools::check_built()? Alternatively, It seems to me that you can use
devtools::check() and pass on the compacting command through the
'build_args' argument.
Henric Winell
I also ran:
build(compact-vignettes("gs+qpdf"))
which gave me the error:
Error in inherits(x, "package") : object 'compact' not found
I tried a few other syntax I found online, but they mostly gave me warnings.
So, what I would love for any advice/input on, is what I can do to
remove that WARNING (if I must)? I am not sure if I am running
commands incorrectly, running in the wrong folder, should be using
command/Rstudio, etc. Even reading advice online and looking at the
documentation of build and compactPDF is not solving this for me (and
it may be due to my inexperience with R and terminal).
Thanks again for any help!!!
On Sun, Oct 2, 2016 at 3:43 PM, Duncan Murdoch wrote:
On 02/10/2016 4:05 PM, S johnson wrote:
Hi all,
I am running check() on an R package, and receive one note and one warning
(seem to be related):
* checking installed package size ... NOTE
installed size is 25.9Mb
sub-directories of 1Mb or more:
doc 3.4Mb
extdata 22.1Mb
* checking sizes of PDF files under ‘inst/doc’ ... WARNING
‘gs+qpdf’ made some significant size reductions:
compacted ‘ePort.pdf’ from 1655Kb to 1076Kb
consider running tools::compactPDF(gs_quality = "ebook") on these files
After pondering this note, I have three brief questions as follows,
1) When I run "du -hs" on the doc sub-directory, it lists its size as
only 10K. There is only one file inside the doc sub-directory, and
similarly, when I run "du -hs" on that one file, it lists its size as
only 10K. I wonder, then, why check() reports that this sub-directory
called doc is 3.4 Mb?
You are probably looking at the package source; the measurements are made
after installation. At that point the vignettes have been copied into the
doc directory.
2) My extdata sub-directory is rather large. It is certainly over 1Mb.
This is due to a few dozen example images (.png files) that we feel is
important to include in the package. In general, do notes like these
prevent
CRAN submission acceptance? If so, what would be an alternative? I
imagine there were other packages that had extdata subdirectory with
example components that are larger than 1Mb - and upon a Google search
that seems to be the case. Still, I wanted to seek your input!
There isn't a hard and fast rule. If the data is necessary for the function
of the package, then it will be allowed. If it is not needed, then maybe
not. Often if the data is relatively stable but the code may be improved,
you'll be asked to put them in separate packages, so that CRAN doesn't fill
up with archived repetitions of the same data.
3) I am unfamiliar with what I should consider running compactPDF() on.
None of the files are PDF files. The doc sub-directory has one .R file,
and
the extdata sub-directory has .R files, .png files (taking up the most
space), and .txt files.
That message is likely talking about a vignette. See the help page
?compactPDF for how to invoke it during a build.
Duncan Murdoch
__
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] building binary gives error when trying to load
Den 2016-11-01 kl. 21:24, skrev Duncan Murdoch: On 01/11/2016 9:49 AM, Rampal Etienne wrote: Dear all, When I try to build a Windows binary in RStudio using R-devel, everything goes well until the packages is tested whether it can be loaded. I then get the error: ** testing if installed package can be loaded *** arch - i386 Error: '\U' used without hex digits in character string starting "'C:\U" Execution halted *** arch - x64 Error: '\U' used without hex digits in character string starting "'C:\U" Execution halted ERROR: loading failed for 'i386', 'x64' * removing 'C:\Users\rampa\AppData\Local\Temp\Rtmp0o1Fm1\temp_libpath1cd445c31688/SADISA' Error: Command failed (1) Execution halted Exited with status 1. I have updated RStudio, Rtools and Rdevel,and the problem persists. Does anyone have a clue how to solve this? Before I updated to the newest Rdevel, everything worked fine. This has been fixed as of revision 71616. Many thanks for looking into and fixing this issue. Henric Winell Duncan Murdoch __ 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] Warnings if Carriage Returns in Code Elements of R Documentation
On 2018-03-05 10:00, Dario Strbenac wrote:
Good day,
The package checking software emits a warning if \cr is used inside \code. The
reason I'd like to do that is to avoid a S4 constructor specification being
limited to one line and running off the side of the PDF page of the PDF manual,
as happens by default. The style of the documentation which I wrote is:
See WRE. First, get of \cr. Second, replacing \code{} with
\preformatted{} and your manual formatting will be preserved.
Henric Winell
\section{Constructor}{
\describe{
\item{}{
\code{DataClass(parameter1, parameter2, parameter3, parameter4,\cr
parameter5, parameter6)
}
See WRE. Get rid of \cr and use \preformatted instead of \code. But
note that it often requires padding with spaces to get exactly the
result you want.
Henric Winell
}
} \describe{
\item{\code{parameter1}}{A description of the requirements of the
first parameter.}
}
}
How can wrapping be forced without causing a warning during checking?
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
__
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
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
