[R-pkg-devel] Conditional use of suggested package in example code

[Christian Sigg]

I am updating the ’nsprcomp’ package to follow the recommendations of Section 
1.1.3.1 of the Writing R Extensions manual.

Before the update, the example code for the `nsprcomp` function looked like 
this:

> library(MASS)
> set.seed(1)
> 
> # Regular PCA, with the tolerance set to return five PCs
> prcomp(Boston, tol = 0.36, scale. = TRUE)
> 
> # Sparse PCA with different cardinalities per component. The number of 
> components
> # is derived from the length of vector k.
> nsprcomp(Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
> 
> (…)

The unconditional use of the suggested package ‘MASS’ produces an error on 
systems where ‘MASS’ is not installed. 

I personally think that this is fine in an interactive session. The error makes 
it obvious what the user has to do to run the example - install the missing 
package. But I understand that it would increase the complexity of automated 
checking of examples, where one would have to distinguish between this kind of 
error and an actual bug in the example code.

In any case, the WRE manual recommends conditional use of suggested packages 
via `requireNamespace`. A straightforward way to follow the recommendation is 
to wrap the whole example in a conditional statement:

> if (requireNamespace("MASS", quietly = TRUE)) {
>  set.seed(1)
> 
>  # Regular PCA, with the tolerance set to return five PCs
>  prcomp(MASS::Boston, tol = 0.36, scale. = TRUE)
> 
>  # Sparse PCA with different cardinalities per component. The number of 
> components
>  # is derived from the length of vector k.
>  nsprcomp(MASS::Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
> 
>  (…)
> }

I don’t like this for two reasons:

1. The if statement and the indentation add clutter to the example code, making 
the help page harder to read.

2. The if statement breaks the output of `example(“nsprcomp”, “nsprcomp”)`. Now 
only the statement before the closing curly brace has its output printed to the 
console. I would have to add explicit print statements that further clutter up 
the example.

Is there a coding pattern that satisfies the WRE recommendations, but avoids 
these two problems?

Regards
Christian

—
Christian Sigg
https://sigg-iten.ch/research

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Conditional use of suggested package in example code

[Martin Maechler]

> Christian Sigg 
> on Wed, 30 May 2018 11:08:38 +0200 writes:

> I am updating the ’nsprcomp’ package to follow the recommendations of 
Section 1.1.3.1 of the Writing R Extensions manual.
> Before the update, the example code for the `nsprcomp` function looked 
like this:

>> library(MASS)
>> set.seed(1)
>> 
>> # Regular PCA, with the tolerance set to return five PCs
>> prcomp(Boston, tol = 0.36, scale. = TRUE)
>> 
>> # Sparse PCA with different cardinalities per component. The number of 
components
>> # is derived from the length of vector k.
>> nsprcomp(Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
>> 
>> (…)

First, a only a "stylistic" remark to you (and many others):
If you only need a dataset from a package, you typically should not attach the
package [to the search() path] via library()/require(), but typically use

   data(Boston, package="MASS")

which only loads MASS' namespace *and* is self-describing that
indeed you only use MASS for getting that data set.

... but see below for your real question

> The unconditional use of the suggested package ‘MASS’ produces an error 
on systems where ‘MASS’ is not installed. 

> I personally think that this is fine in an interactive session. The error 
makes it obvious what the user has to do to run the example - install the 
missing package. But I understand that it would increase the complexity of 
automated checking of examples, where one would have to distinguish between 
this kind of error and an actual bug in the example code.

> In any case, the WRE manual recommends conditional use of suggested 
packages via `requireNamespace`. A straightforward way to follow the 
recommendation is to wrap the whole example in a conditional statement:

>> if (requireNamespace("MASS", quietly = TRUE)) {
>> set.seed(1)
>> 
>> # Regular PCA, with the tolerance set to return five PCs
>> prcomp(MASS::Boston, tol = 0.36, scale. = TRUE)
>> 
>> # Sparse PCA with different cardinalities per component. The number of 
components
>> # is derived from the length of vector k.
>> nsprcomp(MASS::Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
>> 
>> (…)
>> }

> I don’t like this for two reasons:

> 1. The if statement and the indentation add clutter to the example code, 
making the help page harder to read.

> 2. The if statement breaks the output of `example(“nsprcomp”, 
“nsprcomp”)`. Now only the statement before the closing curly brace has its 
output printed to the console. I would have to add explicit print statements 
that further clutter up the example.

> Is there a coding pattern that satisfies the WRE recommendations, but 
avoids these two problems?

A very good question:

I have introduced the function   withAutoprint( . )  into R 3.4.0  
to address your '2.'  -- not perfectly but at least
transparently,
so the if would going to be

  if (requireNamespace("MASS", quietly = TRUE)) withAutoprint({


  })

{and you'd have to add  'Depends: R (>= 3.4.0)'}

To address '1.'  you could wrap  \dontshow{ * } around the two
if()-related lines in your example code which makes the code
*look* better to the help page readers. 

These two "techniques" together get you quite far, though I
agree it's a bit of fiddling..

Last but not least - of course you know that, I'm just stating
the obvious here:  The small 'datasets' that comes with R
does not need any conditionals (nor does simple random-generated
data that you could use).

Best,
Martin


> Regards
> Christian

> —
> Christian Sigg
> https://sigg-iten.ch/research

> __
> 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

Re: [R-pkg-devel] Conditional use of suggested package in example code

[Christian Sigg]

Hi Martin

Thank you for your reply.

> On 30 May 2018, at 12:03, Martin Maechler  wrote:
> 
>> Christian Sigg 
>>on Wed, 30 May 2018 11:08:38 +0200 writes:
> 
>> I am updating the ’nsprcomp’ package to follow the recommendations of 
>> Section 1.1.3.1 of the Writing R Extensions manual.
>> Before the update, the example code for the `nsprcomp` function looked like 
>> this:
> 
>>> library(MASS)
>>> set.seed(1)
>>> 
>>> # Regular PCA, with the tolerance set to return five PCs
>>> prcomp(Boston, tol = 0.36, scale. = TRUE)
>>> 
>>> # Sparse PCA with different cardinalities per component. The number of 
>>> components
>>> # is derived from the length of vector k.
>>> nsprcomp(Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
>>> 
>>> (…)
> 
> First, a only a "stylistic" remark to you (and many others):
> If you only need a dataset from a package, you typically should not attach the
> package [to the search() path] via library()/require(), but typically use
> 
>   data(Boston, package="MASS")
> 
> which only loads MASS' namespace *and* is self-describing that
> indeed you only use MASS for getting that data set.

I agree with you. In my specific example, I later also use MASS::ginv(), but 
unfortunately that was not visible in the excerpt.

> ... but see below for your real question
> 
>> The unconditional use of the suggested package ‘MASS’ produces an error on 
>> systems where ‘MASS’ is not installed. 
> 
>> I personally think that this is fine in an interactive session. The error 
>> makes it obvious what the user has to do to run the example - install the 
>> missing package. But I understand that it would increase the complexity of 
>> automated checking of examples, where one would have to distinguish between 
>> this kind of error and an actual bug in the example code.
> 
>> In any case, the WRE manual recommends conditional use of suggested packages 
>> via `requireNamespace`. A straightforward way to follow the recommendation 
>> is to wrap the whole example in a conditional statement:
> 
>>> if (requireNamespace("MASS", quietly = TRUE)) {
>>> set.seed(1)
>>> 
>>> # Regular PCA, with the tolerance set to return five PCs
>>> prcomp(MASS::Boston, tol = 0.36, scale. = TRUE)
>>> 
>>> # Sparse PCA with different cardinalities per component. The number of 
>>> components
>>> # is derived from the length of vector k.
>>> nsprcomp(MASS::Boston, k = c(13, 7, 5, 5, 5), scale. = TRUE)  
>>> 
>>> (…)
>>> }
> 
>> I don’t like this for two reasons:
> 
>> 1. The if statement and the indentation add clutter to the example code, 
>> making the help page harder to read.
> 
>> 2. The if statement breaks the output of `example(“nsprcomp”, “nsprcomp”)`. 
>> Now only the statement before the closing curly brace has its output printed 
>> to the console. I would have to add explicit print statements that further 
>> clutter up the example.
> 
>> Is there a coding pattern that satisfies the WRE recommendations, but avoids 
>> these two problems?
> 
> A very good question:
> 
> I have introduced the function   withAutoprint( . )  into R 3.4.0  
> to address your '2.'  -- not perfectly but at least
> transparently,
> so the if would going to be
> 
>  if (requireNamespace("MASS", quietly = TRUE)) withAutoprint({
> 
> 
>  })
> 
> {and you'd have to add  'Depends: R (>= 3.4.0)’}

Thank you for that!

> 
> To address '1.'  you could wrap  \dontshow{ * } around the two
> if()-related lines in your example code which makes the code
> *look* better to the help page readers. 

But how do I only hide the if statement and its closing curly brace? The 
following doesn’t work:

> \examples{
>   \dontshow{
> if (TRUE) {
>   }
>   test(1)
>   \dontshow{
> }
>   }
> }


The example section on the help page is empty, because the curly braces of the 
if statement and the \dontshow get mixed up. 

Ordering the statements this way:

> \examples{
>   \dontshow{
> if (TRUE) 
>   }
>   {
> test(1)
>   }
> }

is better, but the opening and closing curly brace of the if statement remain 
on the help page. 

Furthermore, I keep the examples in standalone files that I include in the 
documentation using roxygen2’s @example. Adding the \dontshow markup means I 
can’t source them anymore.

> 
> These two "techniques" together get you quite far, though I
> agree it's a bit of fiddling..
> 
> Last but not least - of course you know that, I'm just stating
> the obvious here:  The small 'datasets' that comes with R
> does not need any conditionals (nor does simple random-generated
> data that you could use).

Quoting from the WRE manual:

> Some people have assumed that a ‘recommended’ package in ‘Suggests’ can 
> safely be used unconditionally, but this is not so. (R can be installed 
> without recommended packages, and which packages are ‘recommended’ may 
> change.) 


So according to the manual, even MASS needs a conditional.

I do use random data in my tests, but I think that the examples profit from 
using a real dataset.

Re

Re: [R-pkg-devel] RcppArmadillo-based package works in every tested OS except Debian

[Julia A. Pilowsky]

Hello Dirk,


Thank you for the advice. Currently I get a bug whenever I try to use R Builder 
on my computer, no matter which browser I launch it from, but I will try the 
Rocker images, as I have worked with Docker before and have some familiarity.


Gratefully,

Julia


From: Dirk Eddelbuettel  on behalf of Dirk 
Eddelbuettel 
Sent: Monday, May 28, 2018 6:55:25 PM
To: Julia A. Pilowsky
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] RcppArmadillo-based package works in every tested OS 
except Debian


Hi Julia,

On 28 May 2018 at 16:33, Julia A. Pilowsky wrote:
| I am the maintainer of the 
colorednoise package, which employs 
RcppArmadillo. The package passes all checks on my local OS X install, on 
win_builder, and on Travis CI's Ubuntu 
distribution.
|
| However, when I submitted the package to CRAN, I got an error 
message
 for Debian and only Debian � all the other systems appear to run it fine. The 
error is for the unit test the package has for a RcppArmadillo-based function � 
all the other unit tests are for R or Rcpp functions.
|
| I am really scratching my head over why this RcppArmadillo function is 
working on every OS except Debian, and I'm at a loss as to how to fix it, since 
I don't have a Debian install on my computer, and Travis CI only tests in 
Ubuntu. Any advice would be greatly appreciated.

1) You get easy access to Debian systems via RHub, either using the web
   interface at https://builder.r-hub.io or via the CRAN package rhub.
   A highly recommended service.

2) Another possibility is Docker. It is pretty easy to set up, and I often
   use Docker instances to test things I do not want more permanently on my
   system(s). Also, our Rocker images happen to already use Debian and give
   you R. Maybe start with our recent intro paper to learn more:
   https://journal.r-project.org/archive/2017/RJ-2017-065/index.html

3) As Rcpp maintainer, I happen to run a lot of reverse dependency checks for
   Rcpp, RcppArmadillo, ... and yes, colorednoise also failed for me on the
   last three Rcpp reverse depends checks. I log these in a GitHub repo at
   https://github.com/RcppCore/rcpp-logs -- that won't give you details
   but it simply re-affirms the CRAN failures.

Hth, Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0

[Hugh Parsonage]

Hi,

There are a few problems with the submission. Probably more than can
be resolved by people on the mailing list. Speaking generally, a
WARNING in a CRAN check is something that *must* be fixed, rather than
something which you can just acknowledge. The two warnings that you
mentioned are that you probably have (in your DESCRIPTION file)

License: GNU General Public License v3.0

when you should have

License: GPL-3

The second warning is about undocumented code objects. You can choose
not to export them, but if you do export them as you currently are,
you will need to document them.

I notice that there are other problems too: consult the links in the
auto-generated email from CRAN, see the 00check file. You should fix
every problem until there are no ERRORS, WARNINGS, or NOTEs.


Best.

On 31 May 2018 at 00:03, khoong Wei Hao  wrote:
> Hi Everyone,
>
> I encountered an issue during my submission of my package (see original 
> message below).
>
> I ran checks and tests with testthat::test_dir("tests/") and 
> devtoos::check(), and all seemed fine except some issues with undocumented 
> objects which I did note in the .Rd file, and the documentation appeared in 
> the console as I ran the package. The following is my R console output:
>
>> devtools::check()
> Updating bwt documentation
> Loading bwt
> First time using roxygen2. Upgrading automatically...
> Warning: The existing 'NAMESPACE' file was not generated by roxygen2, and 
> will not be overwritten.
> Setting env vars 
> 
> CFLAGS  : -Wall -pedantic
> CXXFLAGS: -Wall -pedantic
> Building bwt 
> 
> "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ --no-save 
> --no-restore --quiet CMD build  \
>   "C:\Users\khoongwh\Documents\bwt" --no-resave-data --no-manual
>
> * checking for file 'C:\Users\khoongwh\Documents\bwt/DESCRIPTION' ... OK
> * preparing 'bwt':
> * checking DESCRIPTION meta-information ... OK
> * checking for LF line-endings in source and make files
> * checking for empty or unneeded directories Removed empty directory 'bwt/man'
> Removed empty directory 'bwt/tests/testthat'
> * building 'bwt_1.1.0.tar.gz'
>
> Setting env vars 
> 
> _R_CHECK_CRAN_INCOMING_ : FALSE
> _R_CHECK_FORCE_SUGGESTS_: FALSE
> Checking bwt 
> 
> "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ --no-save 
> --no-restore --quiet CMD check  \
>   "C:\Users\khoongwh\AppData\Local\Temp\RtmpKmUMRO/bwt_1.1.0.tar.gz" 
> --as-cran --timings --no-manual
>
> * using log directory 
> 'C:/Users/khoongwh/AppData/Local/Temp/RtmpKmUMRO/bwt.Rcheck'
> * using R version 3.3.2 (2016-10-31)
> * using platform: x86_64-w64-mingw32 (64-bit)
> * using session charset: ISO8859-1
> * using options '--no-manual --as-cran'
> * checking for file 'bwt/DESCRIPTION' ... OK
> * checking extension type ... Package
> * this is package 'bwt' version '1.1.0'
> * package encoding: UTF-8
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for .dll and .exe files ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking whether package 'bwt' can be installed ... OK
> * checking package directory ... OK
> * checking DESCRIPTION meta-information ... WARNING Non-standard license 
> specification:
>   GNU General Public License v3.0
> Standardizable: FALSE
> * checking top-level files ... OK
> * checking for left-over files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking R files for non-ASCII characters ... OK
> * checking R files for syntax errors ... OK
> * checking whether the package can be loaded ... OK
> * checking whether the package can be loaded with stated dependencies ... OK
> * checking whether the package can be unloaded cleanly ... OK
> * checking whether the namespace can be loaded with stated dependencies ... OK
> * checking whether the namespace can be unloaded cleanly ... OK
> * checking loading without being on the library search path ... OK
> * checking dependencies in R code ... OK
> * checking S3 generic/method consistency ... OK
> * checking replacement functions ... OK
> * checking foreign function calls ... OK
> * checking R code for possible problems ... OK
> * checking for missing documentation entries ... WARNING Undocumented code 
> objects:
>   'bwt' 'ibwt'
> All user-level objects in a package should have documentation entries.
> See chapter 'Writing R documentation files' in the 'Writing R Extensions

Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0

[Joris Meys]

Hi Khoong,

I'm going to address the elephant in the room: your package is not ready
for CRAN, and I'm not even sure CRAN is the right place for that code.

There's two large issues with your package, next to the license problem
Hugh pointed out already:

1. R code needs to be in subdirectory R, the Rd file needs to be in a
subdirectory called man. In the tar.gz file, both are in the main folder.
That's never going to work.

2. Your Rd file is seriously messed up. The name and alias contain what
should be the title, the title isn't filled in. I suggest you take a look
at roxygen2 to help you write the documentation, or go through Writing R
extensions again to check the details on the man pages.

\name{bwt}
\alias{ibwt}

will at least get the one warning about undocumented objects away.

3. The package in its entirity is 2 rather short functions. I'm not from
CRAN, but I don't know if that would pass the "non-trivial contribution"
test. You might want to think about a package that could import your code
rather than submitting a separate package. Not saying the code is not
valuable or the package has no place on CRAN, but you might get questions
on that and then it's better to be prepared with a good answer as to why
this really should be on CRAN.

Your error otoh looks like something that is not your fault. As far as I
know, having a test suite using testthat is not obligatory for a CRAN
package. Yet, CRAN did try to run the tests and errored because it couldn't
find any. I'll raise that at R-devel and see what's going on there.
Nevertheless, adding a few tests would be a good idea. testthat lets you do
that rather easily, and you can find more information in the vignettes of
that package and Hadley's book on writing packages.

Hope this helps
Cheers
Joris



On Wed, May 30, 2018 at 4:52 PM, Hugh Parsonage 
wrote:

> Hi,
>
> There are a few problems with the submission. Probably more than can
> be resolved by people on the mailing list. Speaking generally, a
> WARNING in a CRAN check is something that *must* be fixed, rather than
> something which you can just acknowledge. The two warnings that you
> mentioned are that you probably have (in your DESCRIPTION file)
>
> License: GNU General Public License v3.0
>
> when you should have
>
> License: GPL-3
>
> The second warning is about undocumented code objects. You can choose
> not to export them, but if you do export them as you currently are,
> you will need to document them.
>
> I notice that there are other problems too: consult the links in the
> auto-generated email from CRAN, see the 00check file. You should fix
> every problem until there are no ERRORS, WARNINGS, or NOTEs.
>
>
> Best.
>
> On 31 May 2018 at 00:03, khoong Wei Hao  wrote:
> > Hi Everyone,
> >
> > I encountered an issue during my submission of my package (see original
> message below).
> >
> > I ran checks and tests with testthat::test_dir("tests/") and
> devtoos::check(), and all seemed fine except some issues with undocumented
> objects which I did note in the .Rd file, and the documentation appeared in
> the console as I ran the package. The following is my R console output:
> >
> >> devtools::check()
> > Updating bwt documentation
> > Loading bwt
> > First time using roxygen2. Upgrading automatically...
> > Warning: The existing 'NAMESPACE' file was not generated by roxygen2,
> and will not be overwritten.
> > Setting env vars --
> --
> > CFLAGS  : -Wall -pedantic
> > CXXFLAGS: -Wall -pedantic
> > Building bwt --
> --
> > "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ
> --no-save --no-restore --quiet CMD build  \
> >   "C:\Users\khoongwh\Documents\bwt" --no-resave-data --no-manual
> >
> > * checking for file 'C:\Users\khoongwh\Documents\bwt/DESCRIPTION' ... OK
> > * preparing 'bwt':
> > * checking DESCRIPTION meta-information ... OK
> > * checking for LF line-endings in source and make files
> > * checking for empty or unneeded directories Removed empty directory
> 'bwt/man'
> > Removed empty directory 'bwt/tests/testthat'
> > * building 'bwt_1.1.0.tar.gz'
> >
> > Setting env vars --
> --
> > _R_CHECK_CRAN_INCOMING_ : FALSE
> > _R_CHECK_FORCE_SUGGESTS_: FALSE
> > Checking bwt --
> --
> > "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ
> --no-save --no-restore --quiet CMD check  \
> >   "C:\Users\khoongwh\AppData\Local\Temp\RtmpKmUMRO/bwt_1.1.0.tar.gz"
> --as-cran --timings --no-manual
> >
> > * using log directory 'C:/Users/khoongwh/AppData/
> Local/Temp/RtmpKmUMRO/bwt.Rcheck'
> > * using R version 3.3.2 (2016-10-31)
> > * using platform: x86_64-w64-mingw32 (64-bit)
> > 

Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0

[Joris Meys]

Hi Khoong,

About your error: I now realized that's the output at your local console.
To test your package, you should run R CMD check --as-cran bwt_1.1.0.tar.gz
from the command line. So the error has nothing to do with CRAN but with
you testing your development directory structure as opposed to the file you
sent to CRAN.

Cheers
Joris

On Wed, May 30, 2018 at 5:17 PM, Joris Meys  wrote:

> Hi Khoong,
>
> I'm going to address the elephant in the room: your package is not ready
> for CRAN, and I'm not even sure CRAN is the right place for that code.
>
> There's two large issues with your package, next to the license problem
> Hugh pointed out already:
>
> 1. R code needs to be in subdirectory R, the Rd file needs to be in a
> subdirectory called man. In the tar.gz file, both are in the main folder.
> That's never going to work.
>
> 2. Your Rd file is seriously messed up. The name and alias contain what
> should be the title, the title isn't filled in. I suggest you take a look
> at roxygen2 to help you write the documentation, or go through Writing R
> extensions again to check the details on the man pages.
>
> \name{bwt}
> \alias{ibwt}
>
> will at least get the one warning about undocumented objects away.
>
> 3. The package in its entirity is 2 rather short functions. I'm not from
> CRAN, but I don't know if that would pass the "non-trivial contribution"
> test. You might want to think about a package that could import your code
> rather than submitting a separate package. Not saying the code is not
> valuable or the package has no place on CRAN, but you might get questions
> on that and then it's better to be prepared with a good answer as to why
> this really should be on CRAN.
>
> Your error otoh looks like something that is not your fault. As far as I
> know, having a test suite using testthat is not obligatory for a CRAN
> package. Yet, CRAN did try to run the tests and errored because it couldn't
> find any. I'll raise that at R-devel and see what's going on there.
> Nevertheless, adding a few tests would be a good idea. testthat lets you do
> that rather easily, and you can find more information in the vignettes of
> that package and Hadley's book on writing packages.
>
> Hope this helps
> Cheers
> Joris
>
>
>
> On Wed, May 30, 2018 at 4:52 PM, Hugh Parsonage 
> wrote:
>
>> Hi,
>>
>> There are a few problems with the submission. Probably more than can
>> be resolved by people on the mailing list. Speaking generally, a
>> WARNING in a CRAN check is something that *must* be fixed, rather than
>> something which you can just acknowledge. The two warnings that you
>> mentioned are that you probably have (in your DESCRIPTION file)
>>
>> License: GNU General Public License v3.0
>>
>> when you should have
>>
>> License: GPL-3
>>
>> The second warning is about undocumented code objects. You can choose
>> not to export them, but if you do export them as you currently are,
>> you will need to document them.
>>
>> I notice that there are other problems too: consult the links in the
>> auto-generated email from CRAN, see the 00check file. You should fix
>> every problem until there are no ERRORS, WARNINGS, or NOTEs.
>>
>>
>> Best.
>>
>> On 31 May 2018 at 00:03, khoong Wei Hao  wrote:
>> > Hi Everyone,
>> >
>> > I encountered an issue during my submission of my package (see original
>> message below).
>> >
>> > I ran checks and tests with testthat::test_dir("tests/") and
>> devtoos::check(), and all seemed fine except some issues with undocumented
>> objects which I did note in the .Rd file, and the documentation appeared in
>> the console as I ran the package. The following is my R console output:
>> >
>> >> devtools::check()
>> > Updating bwt documentation
>> > Loading bwt
>> > First time using roxygen2. Upgrading automatically...
>> > Warning: The existing 'NAMESPACE' file was not generated by roxygen2,
>> and will not be overwritten.
>> > Setting env vars --
>> --
>> > CFLAGS  : -Wall -pedantic
>> > CXXFLAGS: -Wall -pedantic
>> > Building bwt --
>> 
>> --
>> > "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ
>> --no-save --no-restore --quiet CMD build  \
>> >   "C:\Users\khoongwh\Documents\bwt" --no-resave-data --no-manual
>> >
>> > * checking for file 'C:\Users\khoongwh\Documents\bwt/DESCRIPTION' ...
>> OK
>> > * preparing 'bwt':
>> > * checking DESCRIPTION meta-information ... OK
>> > * checking for LF line-endings in source and make files
>> > * checking for empty or unneeded directories Removed empty directory
>> 'bwt/man'
>> > Removed empty directory 'bwt/tests/testthat'
>> > * building 'bwt_1.1.0.tar.gz'
>> >
>> > Setting env vars --
>> --
>> > _R_CHECK_CRAN_INCOMING_ : FALSE
>> > _R_CHECK_FORCE_SUGGE