On 28/10/2019 1:01 p.m., William Dunlap wrote:
The Matrix package explicitly sets LazyData to "no" with a note saying
that it is necessary.
LazyData: no
LazyDataNote: not possible, since we use data/*.R *and* our classes
My notes on implementing install.packages() in TERR include
When R's install.packages() processes *.R files in the package's
data directory, they may use functions defined in the package's R
directory, whether or not LazyData is yes or no.
If LazyData is no (but not if yes), then the *.R files in data can
refer to files copied from pkg/inst/blah to pkg/blah.
TERR must be able to do this to install the Matrix package from source.
Hence changing the default to "yes" may break the installation of some
packages.
Thanks! This also shows another solution to Luis-Miguel's problem. He had
\usage{growth.curves}
in his .Rd file, but that doesn't work unless LazyData: yes is used (as
pointed out earlier). In fact, it is incorrect: running
growth.curves
in the R console gives the error
Error: object 'growth.curves' not found
Since data is not lazy-loaded, the approach used by Matrix is needed,
i.e. an explicit call to data():
\usage{
data(growth.curves)
}
So this isn't a bug in the checks after all, it was an error in the
package and was being reported correctly.
Duncan Murdoch
Bill Dunlap
TIBCO Software
wdunlap tibco.com <http://tibco.com>
On Sun, Oct 27, 2019 at 12:35 PM Duncan Murdoch
<murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>> wrote:
On 27/10/2019 6:04 a.m., Luis-Miguel Rodríguez Rojas wrote:
> Thanks a lot Xavier!
> This solved my issue.
This seems like a simple workaround for the bug. Perhaps "LazyData:
yes" should become the default. I don't know what are the
advantages of
the current "LazyData: no" default.
BTW, another issue is that the environment variable controlling this
test, "_R_CHECK_CODOC_VARIABLES_IN_USAGES_", doesn't appear to be
documented. I did a fairly rough search through the sources for other
undocumented check variables, and found this list:
[1] "_R_CHECK_CODOC_VARIABLES_IN_USAGES_"
[2] "_R_CHECK_CRAN_INCOMING_ASPELL_RECHECK_MAYBE_"
[3] "_R_CHECK_CRAN_INCOMING_ASPELL_RECHECK_START_"
[4] "_R_CHECK_CRAN_INCOMING_CHECK_FILE_URIS_"
[5] "_R_CHECK_CRAN_INCOMING_DESCR_BAD_START_RECHECK_MAYBE_"
[6] "_R_CHECK_CRAN_INCOMING_DESCR_BAD_START_RECHECK_START_"
[7] "_R_CHECK_CRAN_INCOMING_GNU_MAKE_RECHECK_MAYBE_"
[8] "_R_CHECK_CRAN_INCOMING_GNU_MAKE_RECHECK_START_"
[9] "_R_CHECK_CRAN_INCOMING_NOTE_GNU_MAKE_"
[10] "_R_CHECK_CRAN_INCOMING_SKIP_DATES_"
[11] "_R_CHECK_CRAN_INCOMING_SKIP_DOI_CHECKS_"
[12] "_R_CHECK_CRAN_INCOMING_SKIP_URL_CHECKS_IF_REMOTE_"
[13] "_R_CHECK_CRAN_INCOMING_SKIP_VERSIONS_"
[14] "_R_CHECK_CRAN_INCOMING_TITLE_CASE_RECHECK_MAYBE_"
[15] "_R_CHECK_CRAN_INCOMING_TITLE_CASE_RECHECK_START_"
[16] "_R_CHECK_CRAN_INCOMING_TITLE_INCLUDES_NAME_RECHECK_MAYBE_"
[17] "_R_CHECK_CRAN_INCOMING_TITLE_INCLUDES_NAME_RECHECK_START_"
[18] "_R_CHECK_CRAN_INCOMING_USE_ASPELL_"
[19] "_R_CHECK_CRAN_STATUS_SUMMARY_"
[20] "_R_CHECK_FF_AS_CRAN_"
[21] "_R_CHECK_FILE_TIMES_TOL_"
[22] "_R_CHECK_FUTURE_FILE_TIMESTAMPS_LEEWAY_"
[23] "_R_CHECK_MAINTAINER_ADDRESS_"
[24] "_R_CHECK_PACKAGE_DATASETS_SUPPRESS_NOTES_"
[25] "_R_CHECK_PACKAGE_DEPENDS_IGNORE_MISSING_ENHANCES_"
[26] "_R_CHECK_PACKAGES_USED_CRAN_INCOMING_NOTES_"
[27] "_R_CHECK_PACKAGES_USED_IGNORE_UNUSED_IMPORTS_"
[28] "_R_CHECK_RD_CONTENTS_KEYWORDS_"
[29] "_R_CHECK_SIZE_OF_TARBALL_"
[30] "_R_CHECK_SRC_MINUS_W_SOMETIMES_UNINITIALIZED_"
[31] "_R_CHECK_STANGLE_WARNINGS_"
[32] "_R_CHECK_SUPPRESS_RANDR_MESSAGE_"
[33] "_R_CHECK_UNLOAD_NAMESPACES_"
[34] "_R_CHECK_URLS_USE_CURL_"
[35] "_R_CHECK_VIGNETTE_TITLES_"
[36] "_R_CHECK_VIGNETTES_SKIP_RUN_MAYBE_"
Some of these (including _R_CHECK_CODOC_VARIABLES_IN_USAGES_) may be
intended for internal use only; I'm not even certain the others are
used
in the checks. All I was looking for were patterns in the source using
grep -r _R_CHECK_ *
and within those lines I assumed ones with the pattern
Sys.getenv("...")
were actually environment variables being used, and ones in files in
the
doc directory were documented. The ones listed above appear to be used
but not documented.
Duncan Murdoch
>
> Best,
> Miguel.
>
> --
> Luis M. Rodriguez-R, Ph.D.
> [ https://rodriguez-r.com <https://rodriguez-r.com/> ]
> ---------------------------------
> Research Engineer
> Georgia Institute of Technology
> 311 Ferst Drive, ES&T, Room 3324
> Atlanta, GA 30332, USA
> [ http://enve-omics.gatech.edu/ ]
>
>
>
> On Sun, Oct 27, 2019 at 3:09 AM Xavier Robin
<Xavier.Robin@sib.swiss> wrote:
>
> Hi,
>
> It seems you have LazyLoad in your DESCRIPTION:
>
> LazyLoad: yes
>
> I ran into the same warning a few months ago and realized that
> LazyLoad has been ignored since R 2.14.0. As a consequence your
> dataset is not actually loaded lazily, which triggers the
warning.
>
> Apparently the new way to lazy load a dataset is to use
LazyData in
> the DESCRIPTION:
>
> LazyData: yes
>
> I don't know in which R version LazyData was introduced, but I
> expect around the same time.
>
>
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file
>
> I ended up making the following change, and the warning
disappeared:
>
>
https://github.com/xrobin/pROC/commit/77bbb151412643628f2549868700325c8e47cad4
>
> I hope it helps.
> Xavier
>
>
> On 27.10.19 02:14, Duncan Murdoch wrote:
>> I think this is a bug. It starts to appear in R-devel revision
>> 76780,
>>
>>
------------------------------------------------------------------------
>>
>> r76780 | hornik | 2019-07-04 14:55:52 -0400 (Thu, 04 Jul
2019) | 1
>> line
>>
>> Tweaks for c76774.
>>
------------------------------------------------------------------------
>>
>>
>> where the default for a new test is set to TRUE. The new
test was
>> introduced in 76774,
>>
>>
------------------------------------------------------------------------
>>
>> r76774 | hornik | 2019-07-03 05:02:40 -0400 (Wed, 03 Jul
2019) | 2
>> lines
>>
>> Have codoc() report variables in usages not in the code.
>> (Optionally for now).
>>
------------------------------------------------------------------------
>>
>>
>> Duncan Murdoch
>>
>>
>> On 26/10/2019 4:54 p.m., Luis-Miguel Rodríguez Rojas wrote:
>>> Hello Duncan,
>>>
>>> Thanks for your quick response!
>>>
>>> I tried re-building and re-submitting and I'm still getting
>>> the same error:
>>>
https://win-builder.r-project.org/incoming_pretest/enveomics.R_1.5.0_20191026_224156/Windows/00check.log
>>>
>>>
https://win-builder.r-project.org/incoming_pretest/enveomics.R_1.5.0_20191026_224156/Debian/00check.log
>>>
>>>
>>> I've made the tarball temporarily available directly in the
>>> repository in case that helps at all:
>>>
https://github.com/lmrodriguezr/enveomics/blob/master/enveomics.R_1.5.0.tar.gz
>>>
>>>
>>> Thanks a lot!
>>> Miguel.
>>>
>>> --
>>> Luis M. Rodriguez-R, Ph.D.
>>> [ https://rodriguez-r.com <https://rodriguez-r.com/>
>>> <https://rodriguez-r.com/> ]
>>> ---------------------------------
>>> Research Engineer
>>> Georgia Institute of Technology
>>> 311 Ferst Drive, ES&T, Room 3324
>>> Atlanta, GA 30332, USA
>>> [ http://enve-omics.gatech.edu/ ]
>>>
>>>
>>>
>>> On Sat, Oct 26, 2019 at 1:39 PM Duncan Murdoch
>>> <murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>
<mailto:murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>>
>>> *MailScanner has detected a possible fraud attempt from
>>> "gmail.com <http://gmail.com>" claiming to be*
<mailto:murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>>
>>> <mailto:murdoch.dun...@gmail.com
<mailto:murdoch.dun...@gmail.com>>> wrote:
>>>
>>> On 26/10/2019 11:39 a.m., Luis-Miguel Rodríguez Rojas
wrote:
>>> > Dear all,
>>> >
>>> > I maintain a package that has data fields, and
didn't have
>>> any
>>> problems
>>> > with this before. However, in my latest update, I'm
>>> getting the
>>> following
>>> > error message from the CRAN tests:
>>> >
>>> > Flavor: r-devel-linux-x86_64-debian-gcc,
>>> r-devel-windows-ix86+x86_64
>>> > Check: for code/documentation mismatches, Result:
WARNING
>>> > Variables with usage in documentation object
>>> 'growth.curves'
>>> but not in
>>> > code:
>>> > 'growth.curves'
>>> >
>>> > Variables with usage in documentation object
>>> 'phyla.counts'
>>> but not in
>>> > code:
>>> > 'phyla.counts'
>>>
>>> I'm not seeing those messages when testing your package in
>>> the same R
>>> version as win-builder used, so it could be a transient
>>> issue, or a
>>> problem with the tarball that you submitted. In either
case,
>>> I'd
>>> suggest just trying again: rebuild and submit.
>>>
>>> Duncan Murdoch
>>>
>>> >
>>> > The variables are indeed NOT in the code, because
they're
>>> only to
>>> be used
>>> > in the examples. In this version I moved my
documentation
>>> from
>>> the old (now
>>> > defunct) inlinedocs to ROxygen2. In the previous form, I
>>> had to
>>> define a
>>> > structure in the code including both the function
and the
>>> example, so
>>> > technically the code was using the variables. In the new
>>> form, I
>>> simply
>>> > define the examples with the @examples tag (that ends up
>>> in the
>>> .rd file
>>> > within an \examples{} block).
>>> >
>>> > Does anyone have any idea on how I should define data in
>>> the code
>>> to avoid
>>> > this issue? I could simply add the example lines
after the
>>> return (so
>>> > they're never reached), but that sounds like a
horrible hack.
>>> >
>>> > Just in case it's useful:
>>> > GitHub repository (inside the enveomics.R folder):
>>> > https://github.com/lmrodriguezr/enveomics/
>>> > Full test output:
>>> >
>>>
https://win-builder.r-project.org/incoming_pretest/enveomics.R_1.5.0_20191026_032029/Windows/00check.log
>>> >
>>> > Thanks!
>>> > Miguel.
>>> >
>>> >
>>> > --
>>> > Luis M. Rodriguez-R, Ph.D.
>>> > [ https://rodriguez-r.com ]
>>> > ---------------------------------
>>> > Research Engineer
>>> > Georgia Institute of Technology
>>> > 311 Ferst Drive, ES&T, Room 3324
>>> > Atlanta, GA 30332, USA
>>> > [ http://enve-omics.gatech.edu/ ]
>>> >
>>> > [[alternative HTML version deleted]]
>>> >
>>> > ______________________________________________
>>> > R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>
>>> <mailto:R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>>
>>> *MailScanner has detected a possible fraud attempt from
>>> "r-project.org <http://r-project.org>" claiming to be*
>>> <mailto:R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>>
>>> <mailto:R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>> mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>> >
>>>
>>
>> ______________________________________________
>> R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
>> <mailto:R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org>> mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Xavier Robin, PhD
> University of Basel | Swiss Institute of Bioinformatics
> Biozentrum - Klingelbergstrasse 50/70 - 4056 Basel
> t: +41 61 207 18 77 | m: +41 78 865 09 01
> Xavier.Robin@sib.swiss <mailto:Xavier.Robin@sib.swiss
<mailto:Xavier.Robin@sib.swiss>> -http://www.sib.swiss
>
______________________________________________
R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
