[R-pkg-devel] inconsistent behavior between R CMD check and interactive use

[Richard M. Heiberger]

Duncan,

Thank you offering to look.
I have tried all the obvious things that I could think of.  None helped.
Perhaps you will think of something I haven't tried

The reproducible example (not minimal) I can suggest is to use the
submitted file.

ftp://CRAN.R-project.org/incoming/archive/HH_3.1-38.tar.gz

On my windows machine

R CMD check --as-cran HH_3.1-38.tar.gz
halts with
> BB <- likert(tmp[2:6,], box.width=unit(.4,"cm"), positive.order=TRUE)
Error in apply(x, 3:ldx, function(x) list(x)) :
  'MARGIN' does not match dim(X)
Calls: likert ... as.MatrixList -> as.MatrixList.array -> lapply -> apply
Execution halted

This is wrong.  That problem was in 3.1-37 and is why I needed a new version.
I repaired that problem. Running interactively, that command succeeds
on my machine.

R CMD check --as-cran --run-dontrun     HH_3.1-38.tar.gz
halts with
> tmp.data <- confintervaldata()
Error in confintervaldata() : could not find function "confintervaldata"
Execution halted

That is wrong.  confintervaldata is in the NAMESPACE.
Running interactively, that command succeeds.
I added an ls("package:HH") ## yes I spelled it correctly
and the confinervaldata is missing from the list.  Again, it is in the
NAMESPACE for the generated executable package.


On the CRAN machines, neither of these problems appeared.  Instead
they found a different error
from code analysis, not from an execution failure.  I don't understand
why I didn't get that issue on
my machine when I used --as-cran.  The repair is in 3.1-39, which I
haven't sent in yet.
The repair is to replace
class(xxx) == "try-error"
with
"try-error" %in% class(xxx)

Please let me know if you see these same problems, or if you can think
of something else to try.

Rich


On Sun, Dec 8, 2019 at 4:58 PM Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>
> On 08/12/2019 3:14 p.m., Richard M. Heiberger wrote:
> > I am seeing this in
> >> version
> >                 _
> > platform       x86_64-w64-mingw32
> > arch           x86_64
> > os             mingw32
> > system         x86_64, mingw32
> > status         Under development (unstable)
> > major          4
> > minor          0.0
> > year           2019
> > month          12
> > day            05
> > svn rev        77528
> > language       R
> > version.string R Under development (unstable) (2019-12-05 r77528)
> > nickname       Unsuffered Consequences
> >
> > I also saw this in 2019-12-03 r77513
> >
> >
> > In my interactive use I set
> >> Sys.setenv("_R_CLASS_MATRIX_ARRAY_"="true")
> > to match what --as-cran does for class(matrix(1))
> >
> > There are two problems, unrelated I think.
> >
> > 1. I have an example which works correctly in interactive use and which
> > shows an error under R CMD check.  The error message is the one we now expect
> > when class(matrix(1)) is just "matrix".  The error should not be
> > triggered when the class
> > is c("matrix","array") >
> >
> > 2. I export many functions.  Several are not handled correctly during
> > R CMD check testing.
> > They appear in the NAMESPACE in the source, and also in both the
> > Rcheck 00_pkg_src and the Rcheck built package.
> > Yet, when those functions are called during the testing of the
> > examples, they aren't visible.
> > An ls() call inserted into the \examples{} section does not include them.
>
> ls() wouldn't normally see functions exported from packages.  You'd need
> ls("package:foo") to see the exports from package foo, and that only
> works after attaching the package.  But examples should be running with
> your package attached during testing, so if that's what you really
> meant, then you do have a problem.
>
> > The functions are visible and work correctly during interactive use.
> >
> >
> > I am running a WIndows 10 system inside a Parallels Virtual Machine on
> > a Macintosh.
> >
> > Has anyone else seen similar misbehavior?
> > Or can suggest a repair?
>
> Not seen this, and can't suggest a repair without seeing a reproducible
> example.
>
> Duncan