If you use GitHub, I highly recommend using "GitHub Action" as
described by Wickham and Bryan, R Packages:
https://r-pkgs.org/code.html#code-style
I'm not sure the best way to get it set up, but I have all my
packages on GitHub configured so each "push" that changes anything has
"R CMD Check" run on 5 different platforms: The release version of R on
the latest Windows, macOS, and Ubuntu plus the development version and
the most recent old release on Ubuntu. I rarely run R CMD check on my
local machine anymore: I just "git commit" and "git push". Then GitHub
Action manages testing on those 5 platforms.
To be precise, I do "git status" before "git push" to make sure I
have "committed" everything I want to commit before I "git push". And I
do "git pull" to make sure a collaborator hasn't "pushed" something new
I should look at before I "git push".
Finally, I want to thank again Gábor Csárdi who helped me greatly get
past problems I hand with "GitHub Action" for my "sos" package. He
provided example workflows in:
https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml
I also needed LaTeX support, for which Gábor suggested the following:
https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages
Spencer Graves
On 1/8/23 9:11 AM, Kevin R. Coombes wrote:
A very helpful answer. For some reason (probably because I have an
ancient perl script that automates the steps i take when building and
checking packages), I keep forgetting that the "tools" package let's me
do these things from within R.
I had already isolated the offending line ("plot(obj)") inside the chunk
where the error occurred, and removed any additional arguments. I
wrapped that line in a "try" command followed by a conditional
"traceback()" to find the problem. This allowed the package build to
knit the vignette and provide some feedback about what was going on. It
turned out that I had copied and pasted an assignment line of the form
main <- [compute the title]
from earlier in the code and pasted it directly as an argument to the
call to image.default. And R did exactly what I told it to (not
surprisingly), and interpreted the value of that assignment as the
unnamed "zlim" option that would have been the corresponding positional
argument that should have been there.
And yes, I still use "left arrow" <- instead of equals = as assignments.
(Heck, I even use emacs and ESS with a leftover keybinding that uses the
underscore key to insert the left arrow. Apparently, I'm ancient myself.)
Kevin
On 1/8/2023 5:04 AM, Duncan Murdoch wrote:
On 07/01/2023 8:43 p.m., Kevin R. Coombes wrote:
Hi,
I am in the middle of developing a new package, which contains a
markdown-knitr-html vignette. When I try to run
R CMD build [mypackagedirectory]
I get an error message
Quitting from lines 330-336
Error: processing vignette failed with diagnostics:
invalid z limits
If I run the same markdown script interactively inside R Studio, there
is no error.
If I knit the markdown script inside R Studio, it produces the correct
HTML output, with no error.
The offending lines of code (the chunk at 330-336) invoke an "image"
method on an object of a class defined in the package, which in turn
computes a matrix from items inside the object and calls image.default,
which is presumably where the error is coming from.
Two questions: (1) How is it possible that the same code works error
free in the RStudio contexts, but fails in the attempt to build the
package?
(2) Any suggestions on how to debug something that only throws an error
from "R CMD build" would be most welcome.
Debugging that sort of thing is hard. Here's what I would try:
From inside an R session, run
tools:::.build_packages("[mypackagedirectory]")
That runs the code that R CMD build runs, so it might trigger the same
error. If so, debug in the usual way, with traceback(), etc.
If that doesn't trigger the error, try it using a different front-end,
e.g. running R at the command line instead of running it in RStudio.
If you still can't trigger it, then start modifying the vignette to
find the exact line that causes the error (e.g. by commenting out the
second half of the code in that chunk; did the error go away? etc.).
Then modify it again to save all the inputs to the bad line in a file
before running it, and see if running that line in a different context
still triggers the error. Etc.
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
