Re: [R-pkg-devel] CRAN check texi2dvi failure
Thanks Enrico for the great guess, and Georgi for the details.
If I omit the space as seems to be implied in some documentation, changing
\verb <https://www.bankofcanada.ca/2006/03/working-paper-2006-3> .
to
\verb<https://www.bankofcanada.ca/2006/03/working-paper-2006-3> .
then the R CMD check error "\verb ended by end of line" happens on my
linux machine. I did not try replacing the space with another
deliminator, which I guess would now be the correct way to use \verb.
The solution of adding
\usepackage{url}
and changing to
\url{https://www.bankofcanada.ca/2006/03/working-paper-2006-3}.
does seem to work. (No "on CRAN" confirmation yet but I have not had the
immediate pre-test rejection that I got previously.)
Paul
On 2021-01-10 8:04 a.m., Georgi Boshnakov wrote:
> The problem is not in the Warning from the example but from
> the \verb commands in the references.
> You use space to delimit the argument of \verb and I was surprised
> that it worked since TeX ignores spaces after commands.
> Apparently, this has been an exception for \verb but now this feature
> is considered a bug and hs been recently fixed, see the atacjexchange
> question below and the relevant paragraph from LaTeX News. Probably
> the linux machines have updated their TeX installations.
>
> In short, changing the space tp say + delimiter for \verb command
should fix the issue.
>
> Georgi Boshnakov
>
On 2021-01-09 6:52 p.m., Enrico Schumann wrote:
When I run R CMD check on my Linux machine [*], I also
do not get an error. But here is a guess: The error
mentions \verb, and the LaTeX manual says that \verb
should be followed by nonspace character. But in the
vignette it is followed by a space. Maybe using \url
in the vignette could fix the error?
kind regards
Enrico
[*] R version 4.0.3 (2020-10-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.10
> On Sat, 09 Jan 2021, Paul Gilbert writes:
I am trying to debug a problem that is appearing in the
linux and Solaris checks, but not Windows or Mac
checks, of my package tsfa as reported at
https://cran.r-project.org/web/checks/check_results_tsfa.html
The problem is with re-building the vignette
...
this is package 'tsfa' version '2014.10-1'
...
checking re-building of vignette outputs ... [6s/9s] WARNING
Error(s) in re-building vignettes:
...
Running 'texi2dvi' on 'Guide.tex' failed.
LaTeX errors:
! LaTeX Error: \verb ended by end of line.
...
In responding to the threat of removal I have also
fixes some long standing warnings about adding imports
to the NAMESPACE. The new version builds with --as-cran
giving no errors or warnings with both R-devel on
win-builder (2021-01-07 r79806) and on my linux machine
(R 2021-01-08 r79812 on Linux Mint 19.3 Tricia). When I
submit it to CRAN the Windows build is OK but the same
error happens at the 'texi2dvi' step in the debian
vignette re-build.
This seems to happens after an example that correctly
has a warning message (about Heywood cases). In my
linux build the the warning happens but the message
does not appear in the pdf output, so one possibility
is that the handling of the warning on the CRAN Unix
check machines fails to produce clean tex or suppress
output. Another possibility is that my build using
--as-cran is different from the actual CRAN build
options. For example, my 00check.log shows
...
* checking package vignettes in ‘inst/doc’ ... OK
* checking re-building of vignette outputs ... OK
* checking PDF version of manual ... OK
* checking for non-standard things in the check directory ... OK
...
so I am not sure if it uses texi2dvi. (I haven't used
dvi myself for a long time.)
I'm not sure how to debug this when I can't reproduce
the error. Suggestions would be appreciated.
Paul Gilbert
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] translation .mo files
I have been sent .po and .mo files with message translations for one of my packages. The .po file I know goes in the source package po/ directory but I have not had .mo files previously. The translator thinks the .mo file goes in inst/po. The .mo file seems to be generated from the .po file, but I am not sure if that happens in the install of the source package, or in some pre-process. I thought I could determine this by looking at an installed package, but I don't see .po or .mo files in installed packages. So far I have had no luck finding documentation on these details. So I have three questions. -Should the .mo file be included in the package, and if so, where? -When a package is installed, where does the translation information go in the directory structure of the library? -Is this documented somewhere? (Please not a vague reference to 'Writing R Extensions', I've looked there and many other places. I need a section or page reference.) Thanks, Paul Gilbert __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Submitting a package whose unit tests sometimes fail because of server connections
5.4 In the spirit of simple & stupid you can also use the built in mechanism for doing this: organize some of your tests in subdirectories like inst/testWithInternet, inst/veryLongTests, inst/testsNeedingLicence, inst/testsNeedingSpecialCluster, etc. CRAN will only run the tests in the tests/ directory, but you can check them yourself using R CMD check --test-dir=inst/testWithInternet whatever.tar.gz > In a separate response On 4/16/19 2:06 PM, Steven Scott wrote: > Just don't include the live fire stuff in the package. Please do not do this. If you omit tests from your package then it cannot be properly checked by other people. Paul Gilbert On 4/16/19 2:16 PM, Dirk Eddelbuettel wrote: On 16 April 2019 at 11:40, Will wrote: | Some things I have considered include: | |1. Skipping all unit tests on CRAN (using something like |*testtht::skip_on_cran*). This would immediately fix the problem, and as |a mitigating factor we report automated test result and coverage on the |package's GitHub page (https://github.com/ropensci/suppdata). |2. Using HTTP-mocking to avoid requiring a call to a server during tests |at all. I would be uncomfortable relying solely on this for all tests, |since if the data hosters changed things we wouldn't know. Thus I would |still want the Internet-enabled tests, which would also have to be turned |off for CRAN (see 1 above). This would also be a lot of additional work. |3. Somehow bypassing the requirement for the unit tests to all pass |before the package is checked by the CRAN maintainers. I have no idea if |this is something CRAN would be willing to do, or if it is even possible. |It would be the easiest option for me, but I don't want to create extra |work for other people! |4. Slowing the tests with something like *Sys.sleep*. This might work, |but would slow the tests massively and so might that cause problems for |CRAN? | | Does anyone have any advice as to which of the above would be the best | option, or who I should email directly about this? 5. Run a hybrid scheme where you have multiple levels: 5.1 Do what eg Rcpp does and only opt into 'all tests' when an overall variable is set; that variable can be set conveniently in .travis.yml and conditionally in your test runner below ~/tests/ That way you can skip tests that would fail. 5.2 Do a lot of work and wrap 3. above into try() / tryCatch() and pass if _your own aggregation of tests_ passes a threshold. Overkill to me. 5.3 Turn all tests on / off based on some other toggle. I.e. I don't think I test all features of RcppRedis on CRAN as I can't assume a redis server, but I do run those tests at home, on Travis, ... Overall, I would recommend to 'keep it simple & stupid' (KISS) as life is to short to argue^Hdebate this with CRAN. And their time is too precious so we should try to make their life easier. Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package fails with parallel make - would forcing a serial version work?
(I didn't see an answer to this, so ...) I think using .NOTPARALLEL will usually get rid of the error but, in my experience, this problem is usually caused by an incorrect or incomplete Makefile. When not done in parallel this missing target is usually getting done first as a side-affect of something that happens before and usually finishes before it is needed. Your luck does not hold in parallel. The better fix is to correct your Makefile. Paul On 1/10/19 4:54 PM, Satyaprakash Nayak wrote: Dear R package developers I published a package on CRAN last year (sundialr) which is now failing with as it is not make to compile a static library with parallel make. In this package, I compile a static library (libsundials_all.a) from source files of a third party. The specifics of compiling the static library can be found at - https://github.com/sn248/sundialr/blob/master/src/Makevars Now, I got the following error message from CRAN (actually, I was informed of this before, but had neglected to fix it). Here is the message from one of the CRAN maintainers .. *** This have just failed to install for me with a parallel make: g++ -std=gnu++98 -std=gnu++98 -shared -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm -lquadmath -L../inst/ ../inst/libsundials_all.a g++: error: ../inst/libsundials_all.a: No such file or directory make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6: sundialr.so] Error 1 * It seems the package fails to generate the static library with the parallel make. The easiest solution I could think of for this problem was to force a serial version of make using the .NOTPARALLEL phony command in Makevars and Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars). I have made this change and it seems to work on my machine and on testing with TravisCI and Appveyor(https://github.com/sn248/sundialr). However, before I re-submit to CRAN, I wanted to get an opinion as to will this be enough to get rid of the error with parallel make? Any suggestions would be very much appreciated, thank you! Satyaprakash [[alternative HTML version deleted]] __ 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] Handling Not-Always-Needed Dependencies? - Part 2
On 08/04/2016 11:51 AM, Dirk Eddelbuettel wrote: On 4 August 2016 at 11:46, Paul Gilbert wrote: | If my package has a test that needs another package, but that package is | not needed in the /R code of my package, then I indicate it as | "Suggests", not as "Depends" nor as "Imports". If that package is not | available when I run R CMD check, should the test pass? Wrong question. Better question: Should the test be running? My preference is for only inside of a requireNamespace() (or equivalent) block as the package is not guaranteed to be present. In theory. At the level of R CMD check throwing an error or not, I think this is arguing that it should be possible to pass the tests (not throw an error) even though they are not run, isn't it? (So your answer to my question is yes, at least the way I was thinking of the question.) Or do you mean you would just like the tests to fail with a more appropriate error message? Or do you mean, as Duncan suggests, that the person writing the test should be allowed to code in something to decide if the test is really important or not? In practice people seem to unconditionally install it anyway, and think that is a good idea. I disagree on both counts but remain in the vocal minority. Actually, I think you are in agreement with Uwe and Duncan on this point, Duncan having added the refinement that the test writer gets to decide. No one so far seems to be advocating for my position that the tests should necessarily fail if they cannot be run. So I guess I am the one in the minority. Paul Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Handling Not-Always-Needed Dependencies? - Part 2
(One question from the thread Handling Not-Always-Needed Dependencies?) I hope not to start another long tangled thread, but I have a basic confusion which I think has a yes/no answer and I would like to know if there is agreement on this point (or is it only me that is confused as usual). If my package has a test that needs another package, but that package is not needed in the /R code of my package, then I indicate it as "Suggests", not as "Depends" nor as "Imports". If that package is not available when I run R CMD check, should the test pass? Yes or no: ? (I realize my own answer might be different if the package was used in an example or demo in place of a test, but that is just the confusion caused by too many uses for Suggests. In the case of a test, my own thought is that the test must fail, so my own answer is no. If the test does not fail then there is no real testing being done, thus missing code coverage in the testing. If the answer is no, then the tests do not need to be run if the package is not available, because it is known that they must fail. I think that not bothering to run the tests because the result is known is even more efficient than other suggestions. I also think it is the status quo.) Hoping my confusion is cleared up, and this does not become another long tangled thread, Paul __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] download.file and https
On 07/02/2015 10:52 PM, Henrik Bengtsson wrote:
From R 3.2.0, check:
capabilities(libcurl)
libcurl
TRUE
TRUE means R was built such that HTTPS is supported. If you see
FALSE, make sure libcurl is available when/if you build R from source.
I do have TRUE for this. The default behaviour still does not work.
Paul
/Henrik
On Thu, Jul 2, 2015 at 7:46 PM, Paul Gilbert pgilbert...@gmail.com wrote:
(This problem with download.file() affects quantmod, and possibly several
other packages. e.g. getSymbols('M2',src='FRED') fails.)
I think the St Louis Fed has moved to using https for connections, and I
believe all the US government web sites are doing this. An http request is
automatically switched to https. The default download.file method does not
seem to handle this, but method=wget does:
tmp - tempfile()
download.file(http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv;,
destfile = tmp)
trying URL
'http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv'
Error in
download.file(http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv;,
:
cannot open URL
'http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv'
download.file(http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv;,
destfile = tmp, method=wget)
--2015-07-02 22:29:49--
http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv
Resolving research.stlouisfed.org (research.stlouisfed.org)... 65.89.18.120
Connecting to research.stlouisfed.org
(research.stlouisfed.org)|65.89.18.120|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location:
https://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv
[following]
--2015-07-02 22:29:49--
https://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv
Connecting to research.stlouisfed.org
(research.stlouisfed.org)|65.89.18.120|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/x-comma-separated-values]
Saving to: ‘/tmp/RtmpOX7kA1/file1ba639d7fd0f’
[ = ] 34,519 178KB/s in 0.2s
2015-07-02 22:29:50 (178 KB/s) - ‘/tmp/RtmpOX7kA1/file1ba639d7fd0f’ saved
[34519]
Paul
__
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] appropriate directory for data downloads in examples, demos and vignettes
Regarding alternative places for scripts, you can add a directory (eg
inst/testLocalScripts) and then with a recently added R CMD feature you
can do
R CMD check --test-dir=inst/testLocalScripts your-package.tar.gz
This will not (automatically) be checked on CRAN. Beware that you also
need to run R CMD check without this option to run your regular tests.
Paul
On 06/29/2015 11:25 AM, Jonathan Callahan wrote:
Hi,
The MazamaSpatialUtils
http://cran.r-project.org/package=MazamaSpatialUtils package has a
required package state variable which users set to specify where they
want to store large amounts of GIS data that is being downloaded and
converted by the package. The implementation of this follows Hadley's
advice here:
http://adv-r.had.co.nz/Environments.html#explicit-envs
The functionality is implemented with package environment and getter and
setter functions:
spatialEnv - new.env(parent = emptyenv())
spatialEnv$dataDir - NULL
getSpatialDataDir - function() {
if (is.null(spatialEnv$dataDir)) {
stop('No data directory found. Please set a data directory with
setSpatialDataDir(YOUR_DATA_DIR).',call.=FALSE)
} else {
return(spatialEnv$dataDir)
}
}
setSpatialDataDir - function(dataDir) {
old - spatialEnv$dataDir
dataDir - path.expand(dataDir)
tryCatch({
if (!file.exists(dataDir)) dir.create(dataDir)
spatialEnv$dataDir - dataDir
}, warning = function(warn) {
warning(Invalid path name.)
}, error = function(err) {
stop(paste0(Error in setSpatialDataDir(,dataDir,).))
})
return(invisible(old))
}
My question is:
*What is an appropriate directory to specify for vignettes (or demos or
examples) that need to go through CRAN testing?*
The R code in vignettes need to specify a directory that is writable during
the package build process but that will also be available to users.
Should we create a /tmp/hash directory? Would that be available on all
systems?
Alternatively,
*What is an alternative to vignettes and demos for tutorial scripts that
should not be tested upon submission to CRAN?*
Thanks for any suggestions.
Jon
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
