[R-pkg-devel] Mysterious "invalid z limit"
Spencer Graves
@pencer@gr@ve@ @end|ng |rom e||ect|vede|en@e@org
Sun Jan 8 19:38:58 CET 2023
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
> <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>
>
More information about the R-package-devel
mailing list