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

Kevin Coombes kev|n@r@coombe@ @end|ng |rom gm@||@com
Sun Jan 8 18:36:02 CET 2023


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.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
>
>
>           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 using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]



More information about the R-package-devel mailing list