[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 
>> <spencer.graves using effectivedefense.org 
>> <mailto:spencer.graves using 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
>>     <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 <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
>>     
>> <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 using r-project.org
>>     <mailto:R-package-devel using r-project.org> mailing list
>>      > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>     <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>>
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
 > E-mail is sent at my convenience; I don't expect replies outside of 
working hours.