(Rich, you've heard this already, this message is for others:)
I think I've found the cause of this, and it might be a bug in the check
code in R.
Rich's package HH "Suggests" microplot, and microplot "Imports" HH.
When running checks on the new version 3.1-38 of HH it appears the tests
from the new version are run but the code being run is from the previous
version 3.1-37 which is on CRAN. I installed the old version
indirectly when I installed microplot before running check.
I've only seen this on Windows in R-devel when running --as-cran. It
doesn't happen in R-devel on MacOS with or without --as-cran, and I
don't think it happens on Windows without --as-cran (but it might just
be that there are no symptoms of testing the wrong version in that case).
A workaround is to explicitly remove HH, then install the new version
before running the check code.
Duncan Murdoch
On 08/12/2019 10:33 p.m., Richard M. Heiberger wrote:
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.dun...@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
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel