Re: [R-pkg-devel] Mysterious "invalid z limit"

[Ben Bolker]

On 2023-01-08 1:38 p.m., Spencer Graves wrote:



On 1/8/23 11:36 AM, Kevin Coombes wrote:
I have been using R-Forge for many years for package development. And 
I have been using GitLab for other projects almost as long.


However, over the past few months, the R-Forge support seems to be 
decaying, and I now have several projects that won't currently build 
there because of various items that appear to need fixing at their 
end. So, I am actively exploring what it will take to move packages 
and projects to git.



   R-Forge was wonderful for me when I started using it.  Then 
several years ago, I started having problems like you described.  A few 
years ago I migrated from R-Forge to GitHub.



   One problem I encountered in the transition:  On R-Forge, I had 
multiple packages in the same R-Forge project.  I had to split them 
apart for GitHub.




I already know how to use a git client to clone a Subversion 
repository from R-Forge (using "git svn"). And how to change the 
remote origin to push it to a new git location. (And I  may also be 
willing to lose the revision history if it is going to make the 
transition easier.)


I am now at the step of understanding the recent changes at GitLab 
with respect to support for "Educational" or "Open Source" status, 
especially in terms of how many monthly minutes of CI/CD time I can 
use for free. When working on a new package, I tend to make lots of 
small commit-pushes, and it sounds like each one of those will eat up 
minutes. So, any advice on how to manage that issue would be greatly 
appreciated.



   When I first got into Subversion, I remember Doug Bates saying, 
"Commit early and often."  The word "Commit" doesn't mean the same in 
Git as in Subversion, so I would encourage you to "Git push early and 
often."



   There may be limits on free use of GitHub, but I'm not aware of 
them:  If you want a private account, you need to pay for that, but the 
charges for that are not much.


  The free tier of Github allows 2000 minutes/month of continuous 
integration testing for private repos, and unlimited (???) for public 
repos.  (2000 minutes/month is more than I've ever needed.)


  Furthermore, it's pretty easy to set up github actions so that it 
only runs tests if you ask it to (by appending e.g. "[run ci]" to your 
commit message), or in opt-out mode (i.e., skip tests if "[skip ci]" is 
in your commit message).





   If anyone knows anything different from what I've just said, I 
hope they will disabuse my of this part of my ignorance.



   Spencer



Best,
   Kevin

On Sun, Jan 8, 2023, 11:30 AM Spencer Graves 
> wrote:


           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 

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Spencer Graves]

On 1/8/23 11:36 AM, Kevin Coombes wrote:
I have been using R-Forge for many years for package development. And I 
have been using GitLab for other projects almost as long.


However, over the past few months, the R-Forge support seems to be 
decaying, and I now have several projects that won't currently build 
there because of various items that appear to need fixing at their end. 
So, I am actively exploring what it will take to move packages and 
projects to git.



	  R-Forge was wonderful for me when I started using it.  Then several 
years ago, I started having problems like you described.  A few years 
ago I migrated from R-Forge to GitHub.



	  One problem I encountered in the transition:  On R-Forge, I had 
multiple packages in the same R-Forge project.  I had to split them 
apart for GitHub.




I already know how to use a git client to clone a Subversion repository 
from R-Forge (using "git svn"). And how to change the remote origin to 
push it to a new git location. (And I  may also be willing to lose the 
revision history if it is going to make the transition easier.)


I am now at the step of understanding the recent changes at GitLab with 
respect to support for "Educational" or "Open Source" status, especially 
in terms of how many monthly minutes of CI/CD time I can use for free. 
When working on a new package, I tend to make lots of small 
commit-pushes, and it sounds like each one of those will eat up minutes. 
So, any advice on how to manage that issue would be greatly appreciated.



	  When I first got into Subversion, I remember Doug Bates saying, 
"Commit early and often."  The word "Commit" doesn't mean the same in 
Git as in Subversion, so I would encourage you to "Git push early and 
often."



	  There may be limits on free use of GitHub, but I'm not aware of them: 
 If you want a private account, you need to pay for that, but the 
charges for that are not much.



	  If anyone knows anything different from what I've just said, I hope 
they will disabuse my of this part of my ignorance.



  Spencer



Best,
   Kevin

On Sun, Jan 8, 2023, 11:30 AM Spencer Graves 
> wrote:


           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 

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Kevin Coombes]

I have been using R-Forge for many years for package development. And I
have been using GitLab for other projects almost as long.

However, over the past few months, the R-Forge support seems to be
decaying, and I now have several projects that won't currently build there
because of various items that appear to need fixing at their end. So, I am
actively exploring what it will take to move packages and projects to git.

I already know how to use a git client to clone a Subversion repository
from R-Forge (using "git svn"). And how to change the remote origin to push
it to a new git location. (And I  may also be willing to lose the revision
history if it is going to make the transition easier.)

I am now at the step of understanding the recent changes at GitLab with
respect to support for "Educational" or "Open Source" status, especially in
terms of how many monthly minutes of CI/CD time I can use for free. When
working on a new package, I tend to make lots of small commit-pushes, and
it sounds like each one of those will eat up minutes. So, any advice on how
to manage that issue would be greatly appreciated.

Best,
  Kevin

On Sun, Jan 8, 2023, 11:30 AM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

>   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 

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Spencer Graves]

	  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

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Kevin R. Coombes]

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

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Kevin R. Coombes]

A terrific answer; thanks. (I am kicking myself for not realizing the 
answer you gave to question 1. Of course that's the explanation. Too 
many consecutive hours debugging other items to get to that point, I 
suppose.)

  Kevin

On 1/8/2023 6:58 AM, Ivan Krylov wrote:

On Sat, 7 Jan 2023 20:43:10 -0500
"Kevin R. Coombes"  wrote:


(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?

When knitting the vignette from RStudio, it uses the package you
already have installed. When knitting the vignette from R CMD build, it
uses the code it's about to package. Could it be that your source code
is different from the copy installed in your library?


(2) Any suggestions on how to debug something that only
throws an error from "R CMD build" would be most welcome.

R CMD build --no-build-vignettes should let you proceed and get a
tarball that could be installed. Hopefully you'll be able to reproduce
the error then.



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Ivan Krylov]

On Sat, 7 Jan 2023 20:43:10 -0500
"Kevin R. Coombes"  wrote:

> (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?

When knitting the vignette from RStudio, it uses the package you
already have installed. When knitting the vignette from R CMD build, it
uses the code it's about to package. Could it be that your source code
is different from the copy installed in your library?

> (2) Any suggestions on how to debug something that only
> throws an error from "R CMD build" would be most welcome.

R CMD build --no-build-vignettes should let you proceed and get a
tarball that could be installed. Hopefully you'll be able to reproduce
the error then.

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Georgi Boshnakov]

A frequent cause of such errors is that in the offending scenario a method is 
not visible, so the call goes directly to the default method. This often can be 
verified by temporarily printing something from your method when it gets 
control.

Without more details it is difficult to be more specific. It may be a missing 
import or export, for example.

Georgi Boshnakov


Get Outlook for Android


From: R-package-devel  on behalf of 
Duncan Murdoch 
Sent: Sunday, 8 January 2023, 10:05
To: Kevin R. Coombes ; R Package Development 

Subject: Re: [R-pkg-devel] Mysterious "invalid z limit"

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


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Duncan Murdoch]

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