Re: [R-pkg-devel] R CMD check --as-cran problem
The source file is on a local computer, so I would not be able to send a link. Nevertheless, I downloaded a stable version at https://cran.r-project.org/src/contrib/bujar_0.2-3.tar.gz, and attached results from R CMD check --as-cran Thanks, Zhu From: Dirk Eddelbuettel on behalf of Dirk Eddelbuettel Sent: Monday, January 14, 2019 4:19 PM To: Wang, Zhu Cc: Uwe Ligges; Dirk Eddelbuettel; Duncan Murdoch; r-package-devel@r-project.org Subject: RE: [R-pkg-devel] R CMD check --as-cran problem On 14 January 2019 at 21:05, Wang, Zhu wrote: | Apologize for multiple emails but my another email with source version of the package was hold waiting for moderator approval. I now formally rejected the post. Why? There is a reason there is a size limit there. You were not asked to send your sources, the comment approach is email a link to the repo. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check --as-cran problem
On 14 January 2019 at 21:05, Wang, Zhu wrote: | Apologize for multiple emails but my another email with source version of the package was hold waiting for moderator approval. I now formally rejected the post. Why? There is a reason there is a size limit there. You were not asked to send your sources, the comment approach is email a link to the repo. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check --as-cran problem
On 14/01/2019 2:30 p.m., Wang, Zhu wrote:
First, I removed the Rnw file in vignettes to make simple.
Then I followed Duncan's suggestions below, but I had the same error.
Next, in the DESCRIPTION, I added survival in Imports, and importFrom("survival",
"survfitKM") in NAMESPACE. But I still had the same error: there is no package called
'Matrix'.
I think we'd need to see at least the check log, and likely the whole
package, to diagnose this.
Duncan Murdoch
Thanks,
Zhu
-Original Message-
From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk
Eddelbuettel
Sent: Monday, January 14, 2019 12:45 PM
To: Duncan Murdoch
Cc: Dirk Eddelbuettel; Wang, Zhu; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check --as-cran problem
On 14 January 2019 at 13:19, Duncan Murdoch wrote:
| On 14/01/2019 12:37 p.m., Dirk Eddelbuettel wrote:
| >
| > On 14 January 2019 at 16:52, Wang, Zhu wrote:
| > | Thanks Dirk and Klaus. The package Matrix is not used directly but it is
used by package survival, which was called in Suggests. So I am not sure what is
the problem. But why CRAN has no such error
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the CRAN
check uses the same R version 3.5.2 as I have. The problem only occurred when I
used --as-cran option.
| >
| > Doesn't this mean that you may to ensure Matrix is present when survival
| > might be used -- so if your package suggests survival it should also suggest
| > Matrix?
|
| That shouldn't be necessary. Since survival imports Matrix, you
| shouldn't be able to load survival unless Matrix is available.
| requireNamespace("survival") should fail.
|
| I think the problem in bujar is that it never checks
| requireNamespace("survival"), it just calls
| getFromNamespace('survfitKM','survival'). That will usually work (just
| about everyone has survival installed, since it's recommended), but is
| unsafe. Zhu should use survival::survfitKM, but only after checking
| that requireNamespace("survival") is successful.
Yes, I agree. I mostly tried to be helpful but my email wasn't all that
effective in that.
Zhu: the behaviour when --as-cran is not set is irrelevant as CRAN asks you
to test with --as-cran set, so there really is only one relevant choice.
And Duncan now kindly detailed the appropriate use case: test for a suggested
package. Or if your use is not conditional, import from it.
Dirk
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check --as-cran problem
What happens if you submit to winbuilder?
If that gives the same error, make the source version of your package
available that you are checking.
Best,
Uwe Ligges
On 14.01.2019 20:30, Wang, Zhu wrote:
First, I removed the Rnw file in vignettes to make simple.
Then I followed Duncan's suggestions below, but I had the same error.
Next, in the DESCRIPTION, I added survival in Imports, and importFrom("survival",
"survfitKM") in NAMESPACE. But I still had the same error: there is no package called
'Matrix'.
Thanks,
Zhu
-Original Message-
From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk
Eddelbuettel
Sent: Monday, January 14, 2019 12:45 PM
To: Duncan Murdoch
Cc: Dirk Eddelbuettel; Wang, Zhu; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check --as-cran problem
On 14 January 2019 at 13:19, Duncan Murdoch wrote:
| On 14/01/2019 12:37 p.m., Dirk Eddelbuettel wrote:
| >
| > On 14 January 2019 at 16:52, Wang, Zhu wrote:
| > | Thanks Dirk and Klaus. The package Matrix is not used directly but it is
used by package survival, which was called in Suggests. So I am not sure what is
the problem. But why CRAN has no such error
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the CRAN
check uses the same R version 3.5.2 as I have. The problem only occurred when I
used --as-cran option.
| >
| > Doesn't this mean that you may to ensure Matrix is present when survival
| > might be used -- so if your package suggests survival it should also suggest
| > Matrix?
|
| That shouldn't be necessary. Since survival imports Matrix, you
| shouldn't be able to load survival unless Matrix is available.
| requireNamespace("survival") should fail.
|
| I think the problem in bujar is that it never checks
| requireNamespace("survival"), it just calls
| getFromNamespace('survfitKM','survival'). That will usually work (just
| about everyone has survival installed, since it's recommended), but is
| unsafe. Zhu should use survival::survfitKM, but only after checking
| that requireNamespace("survival") is successful.
Yes, I agree. I mostly tried to be helpful but my email wasn't all that
effective in that.
Zhu: the behaviour when --as-cran is not set is irrelevant as CRAN asks you
to test with --as-cran set, so there really is only one relevant choice.
And Duncan now kindly detailed the appropriate use case: test for a suggested
package. Or if your use is not conditional, import from it.
Dirk
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package fails with parallel make - would forcing a serial version work?
Thank you Paul and Avi for your response. Indeed, there was an error in Makefile which could have been contributing to the issues with parallel make. I have re-submitted after correcting for the mistakes in Makefile, hopefully it will not throw errors with parallel make now. Thank you for your advice. Satyaprakash On Mon, Jan 14, 2019 at 2:01 PM Avraham Adler wrote: > If you want to use .NOTPARRALLEL, that’s considered non-portable as it’s > GNU-make specific, (I got an email from Dr. Ripley this week) so you have > to add Gnu Make to the system requirements in the DESCRIPTION or find the > right sequence of targets to ensure order is maintained even in parallel > make. > > Avi > > On Mon, Jan 14, 2019 at 1:29 PM Paul Gilbert > wrote: > >> (I didn't see an answer to this, so ...) >> >> I think using .NOTPARALLEL will usually get rid of the error but, in my >> experience, this problem is usually caused by an incorrect or incomplete >> Makefile. When not done in parallel this missing target is usually >> getting done first as a side-affect of something that happens before and >> usually finishes before it is needed. Your luck does not hold in >> parallel. The better fix is to correct your Makefile. >> >> Paul >> >> On 1/10/19 4:54 PM, Satyaprakash Nayak wrote: >> > Dear R package developers >> > >> > I published a package on CRAN last year (sundialr) which is now failing >> > with as it is not make to compile a static library with parallel make. >> > >> > In this package, I compile a static library (libsundials_all.a) from >> source >> > files of a third party. The specifics of compiling the static library >> can >> > be found at - >> https://github.com/sn248/sundialr/blob/master/src/Makevars >> > >> > Now, I got the following error message from CRAN (actually, I was >> informed >> > of this before, but had neglected to fix it). Here is the message from >> one >> > of the CRAN maintainers .. >> > >> > >> *** >> > This have just failed to install for me with a parallel make: >> > >> > g++ -std=gnu++98 -std=gnu++98 -shared >> > -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so >> > cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack >> > -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm >> > -lquadmath -L../inst/ ../inst/libsundials_all.a >> > g++: error: ../inst/libsundials_all.a: No such file or directory >> > make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6: >> > sundialr.so] Error 1 >> > >> * >> > >> > It seems the package fails to generate the static library with the >> parallel >> > make. The easiest solution I could think of for this problem was to >> force a >> > serial version of make using the .NOTPARALLEL phony command in Makevars >> and >> > Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars). >> I >> > have made this change and it seems to work on my machine and on testing >> > with TravisCI and Appveyor(https://github.com/sn248/sundialr). >> > >> > However, before I re-submit to CRAN, I wanted to get an opinion as to >> will >> > this be enough to get rid of the error with parallel make? >> > >> > Any suggestions would be very much appreciated, thank you! >> > Satyaprakash >> > >> > [[alternative HTML version deleted]] >> > >> > __ >> > 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 >> > -- > Sent from Gmail Mobile > [[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] R CMD check --as-cran problem
First, I removed the Rnw file in vignettes to make simple.
Then I followed Duncan's suggestions below, but I had the same error.
Next, in the DESCRIPTION, I added survival in Imports, and
importFrom("survival", "survfitKM") in NAMESPACE. But I still had the same
error: there is no package called 'Matrix'.
Thanks,
Zhu
-Original Message-
From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk
Eddelbuettel
Sent: Monday, January 14, 2019 12:45 PM
To: Duncan Murdoch
Cc: Dirk Eddelbuettel; Wang, Zhu; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check --as-cran problem
On 14 January 2019 at 13:19, Duncan Murdoch wrote:
| On 14/01/2019 12:37 p.m., Dirk Eddelbuettel wrote:
| >
| > On 14 January 2019 at 16:52, Wang, Zhu wrote:
| > | Thanks Dirk and Klaus. The package Matrix is not used directly but it is
used by package survival, which was called in Suggests. So I am not sure what
is the problem. But why CRAN has no such error
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the
CRAN check uses the same R version 3.5.2 as I have. The problem only occurred
when I used --as-cran option.
| >
| > Doesn't this mean that you may to ensure Matrix is present when survival
| > might be used -- so if your package suggests survival it should also suggest
| > Matrix?
|
| That shouldn't be necessary. Since survival imports Matrix, you
| shouldn't be able to load survival unless Matrix is available.
| requireNamespace("survival") should fail.
|
| I think the problem in bujar is that it never checks
| requireNamespace("survival"), it just calls
| getFromNamespace('survfitKM','survival'). That will usually work (just
| about everyone has survival installed, since it's recommended), but is
| unsafe. Zhu should use survival::survfitKM, but only after checking
| that requireNamespace("survival") is successful.
Yes, I agree. I mostly tried to be helpful but my email wasn't all that
effective in that.
Zhu: the behaviour when --as-cran is not set is irrelevant as CRAN asks you
to test with --as-cran set, so there really is only one relevant choice.
And Duncan now kindly detailed the appropriate use case: test for a suggested
package. Or if your use is not conditional, import from it.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package fails with parallel make - would forcing a serial version work?
If you want to use .NOTPARRALLEL, that’s considered non-portable as it’s GNU-make specific, (I got an email from Dr. Ripley this week) so you have to add Gnu Make to the system requirements in the DESCRIPTION or find the right sequence of targets to ensure order is maintained even in parallel make. Avi On Mon, Jan 14, 2019 at 1:29 PM Paul Gilbert wrote: > (I didn't see an answer to this, so ...) > > I think using .NOTPARALLEL will usually get rid of the error but, in my > experience, this problem is usually caused by an incorrect or incomplete > Makefile. When not done in parallel this missing target is usually > getting done first as a side-affect of something that happens before and > usually finishes before it is needed. Your luck does not hold in > parallel. The better fix is to correct your Makefile. > > Paul > > On 1/10/19 4:54 PM, Satyaprakash Nayak wrote: > > Dear R package developers > > > > I published a package on CRAN last year (sundialr) which is now failing > > with as it is not make to compile a static library with parallel make. > > > > In this package, I compile a static library (libsundials_all.a) from > source > > files of a third party. The specifics of compiling the static library can > > be found at - https://github.com/sn248/sundialr/blob/master/src/Makevars > > > > Now, I got the following error message from CRAN (actually, I was > informed > > of this before, but had neglected to fix it). Here is the message from > one > > of the CRAN maintainers .. > > > > > *** > > This have just failed to install for me with a parallel make: > > > > g++ -std=gnu++98 -std=gnu++98 -shared > > -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so > > cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack > > -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm > > -lquadmath -L../inst/ ../inst/libsundials_all.a > > g++: error: ../inst/libsundials_all.a: No such file or directory > > make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6: > > sundialr.so] Error 1 > > > * > > > > It seems the package fails to generate the static library with the > parallel > > make. The easiest solution I could think of for this problem was to > force a > > serial version of make using the .NOTPARALLEL phony command in Makevars > and > > Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars). > I > > have made this change and it seems to work on my machine and on testing > > with TravisCI and Appveyor(https://github.com/sn248/sundialr). > > > > However, before I re-submit to CRAN, I wanted to get an opinion as to > will > > this be enough to get rid of the error with parallel make? > > > > Any suggestions would be very much appreciated, thank you! > > Satyaprakash > > > > [[alternative HTML version deleted]] > > > > __ > > 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 > -- Sent from Gmail Mobile [[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] R CMD check --as-cran problem
On 14 January 2019 at 13:19, Duncan Murdoch wrote:
| On 14/01/2019 12:37 p.m., Dirk Eddelbuettel wrote:
| >
| > On 14 January 2019 at 16:52, Wang, Zhu wrote:
| > | Thanks Dirk and Klaus. The package Matrix is not used directly but it is
used by package survival, which was called in Suggests. So I am not sure what
is the problem. But why CRAN has no such error
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the
CRAN check uses the same R version 3.5.2 as I have. The problem only occurred
when I used --as-cran option.
| >
| > Doesn't this mean that you may to ensure Matrix is present when survival
| > might be used -- so if your package suggests survival it should also suggest
| > Matrix?
|
| That shouldn't be necessary. Since survival imports Matrix, you
| shouldn't be able to load survival unless Matrix is available.
| requireNamespace("survival") should fail.
|
| I think the problem in bujar is that it never checks
| requireNamespace("survival"), it just calls
| getFromNamespace('survfitKM','survival'). That will usually work (just
| about everyone has survival installed, since it's recommended), but is
| unsafe. Zhu should use survival::survfitKM, but only after checking
| that requireNamespace("survival") is successful.
Yes, I agree. I mostly tried to be helpful but my email wasn't all that
effective in that.
Zhu: the behaviour when --as-cran is not set is irrelevant as CRAN asks you
to test with --as-cran set, so there really is only one relevant choice.
And Duncan now kindly detailed the appropriate use case: test for a suggested
package. Or if your use is not conditional, import from it.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package fails with parallel make - would forcing a serial version work?
(I didn't see an answer to this, so ...) I think using .NOTPARALLEL will usually get rid of the error but, in my experience, this problem is usually caused by an incorrect or incomplete Makefile. When not done in parallel this missing target is usually getting done first as a side-affect of something that happens before and usually finishes before it is needed. Your luck does not hold in parallel. The better fix is to correct your Makefile. Paul On 1/10/19 4:54 PM, Satyaprakash Nayak wrote: Dear R package developers I published a package on CRAN last year (sundialr) which is now failing with as it is not make to compile a static library with parallel make. In this package, I compile a static library (libsundials_all.a) from source files of a third party. The specifics of compiling the static library can be found at - https://github.com/sn248/sundialr/blob/master/src/Makevars Now, I got the following error message from CRAN (actually, I was informed of this before, but had neglected to fix it). Here is the message from one of the CRAN maintainers .. *** This have just failed to install for me with a parallel make: g++ -std=gnu++98 -std=gnu++98 -shared -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm -lquadmath -L../inst/ ../inst/libsundials_all.a g++: error: ../inst/libsundials_all.a: No such file or directory make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6: sundialr.so] Error 1 * It seems the package fails to generate the static library with the parallel make. The easiest solution I could think of for this problem was to force a serial version of make using the .NOTPARALLEL phony command in Makevars and Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars). I have made this change and it seems to work on my machine and on testing with TravisCI and Appveyor(https://github.com/sn248/sundialr). However, before I re-submit to CRAN, I wanted to get an opinion as to will this be enough to get rid of the error with parallel make? Any suggestions would be very much appreciated, thank you! Satyaprakash [[alternative HTML version deleted]] __ 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] R CMD check --as-cran problem
On 14/01/2019 12:37 p.m., Dirk Eddelbuettel wrote:
On 14 January 2019 at 16:52, Wang, Zhu wrote:
| Thanks Dirk and Klaus. The package Matrix is not used directly but it is used
by package survival, which was called in Suggests. So I am not sure what is
the problem. But why CRAN has no such error
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the
CRAN check uses the same R version 3.5.2 as I have. The problem only occurred
when I used --as-cran option.
Doesn't this mean that you may to ensure Matrix is present when survival
might be used -- so if your package suggests survival it should also suggest
Matrix?
That shouldn't be necessary. Since survival imports Matrix, you
shouldn't be able to load survival unless Matrix is available.
requireNamespace("survival") should fail.
I think the problem in bujar is that it never checks
requireNamespace("survival"), it just calls
getFromNamespace('survfitKM','survival'). That will usually work (just
about everyone has survival installed, since it's recommended), but is
unsafe. Zhu should use survival::survfitKM, but only after checking
that requireNamespace("survival") is successful.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] size of package and splitting into 2
If you re-exported all the psychTools functions from psych, I doubt a typical user would notice or care. For example, this is how dplyr split out some of it's functions in to another package: https://github.com/tidyverse/dplyr/blob/master/R/reexport-tidyselect.R On Mon, Jan 14, 2019 at 9:03 AM William Revelle wrote: > Dear friends, > > For the last several iterations of psych I have received the Note that the > installed size is 6.7 MB with two subdirectories greater than 1 MB. > > In the most recent submission to CRAN this led to an automatic rejection > which then Uwe kindly overrode to allow the installation on CRAN. > > In order to make life easier for the CRAN folk, I would like to try to > avoid this problem in the future. > > The only way I can see to get around this note is to split the package > into 2: psych and psychTools where psych would require psychTools but > psychTools would not require psych. The presumption is that with > appropriate splitting, both packages would meet the 1 MB suggestion. > > However, this implies that loading psych still takes up just as much space > as before (since it would also load psychTools) and so it is not clear if > this is a benefit. It might even be detrimental to the naive user who > doesn’t load them both. It would be useful, perhaps, for those who use > psych for the extra features rather than core psychometric ones. They > would just need to load psychTools. > > I am not sure how well the splitting would work in terms of solving the > problem and before embarking on this exercise, I would appreciate > suggestions as to whether it is necessary (or at least useful). > > Thanks, > > Bill > > > William Revellepersonality-project.org/revelle.html > Professor personality-project.org > Department of Psychology www.wcas.northwestern.edu/psych/ > Northwestern Universitywww.northwestern.edu/ > Use R for psychology personality-project.org/r > It is 2 minutes to midnight www.thebulletin.org > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[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] R CMD check --as-cran problem
I added Matrix in Suggests (I am not sure that is the way to go), but the same error occurred with --as-cran: there is no package called 'Matrix.' Again, there is no problem without --as-cran. Zhu -Original Message- From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk Eddelbuettel Sent: Monday, January 14, 2019 11:38 AM To: Wang, Zhu Cc: Dirk Eddelbuettel; Klaus Schliep; r-package-devel@r-project.org Subject: RE: [R-pkg-devel] R CMD check --as-cran problem On 14 January 2019 at 16:52, Wang, Zhu wrote: | Thanks Dirk and Klaus. The package Matrix is not used directly but it is used by package survival, which was called in Suggests. So I am not sure what is the problem. But why CRAN has no such error https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the CRAN check uses the same R version 3.5.2 as I have. The problem only occurred when I used --as-cran option. Doesn't this mean that you may to ensure Matrix is present when survival might be used -- so if your package suggests survival it should also suggest Matrix? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check --as-cran problem
On 14 January 2019 at 16:52, Wang, Zhu wrote: | Thanks Dirk and Klaus. The package Matrix is not used directly but it is used by package survival, which was called in Suggests. So I am not sure what is the problem. But why CRAN has no such error https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the CRAN check uses the same R version 3.5.2 as I have. The problem only occurred when I used --as-cran option. Doesn't this mean that you may to ensure Matrix is present when survival might be used -- so if your package suggests survival it should also suggest Matrix? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] undocumented data sets
Thanks a lot
T
-Oprindelig meddelelse-
Fra: Iñaki Ucar
Sendt: 14. januar 2019 15:50
Til: Troels Ring
Cc: package-develop
Emne: Re: [R-pkg-devel] undocumented data sets
See an example with roxygen2:
https://github.com/r-quantities/errors/blob/master/R/data.R
And how this is translated if you prefer to write the Rd yourself:
https://github.com/r-quantities/errors/blob/master/man/datasets.Rd
Iñaki
On Mon, 14 Jan 2019 at 15:45, Troels Ring wrote:
>
> Dear friends - with your help I'm almost through developing a package
> and Ctrl-shit-E now only has a single warning
>
> > checking for missing documentation entries ... WARNING
>
> Undocumented data sets:
>
> 'Cl' 'K' 'Na' 'TOTAL' 'WA' 'INPUT' 'Alb' 'Ca' 'Lact' 'Mg' 'PCO2' 'S1'
>
> 'Brom' 'pHOBS'
>
> All user-level objects in a package should have documentation entries.
>
> See chapter 'Writing R documentation files' in the 'Writing R
>
> Extensions' manual.
>
>
>
> But in 2.1.2.Documenting data sets in Writing R extensions it is said
> that \arguments is not needed and in the template on p 72 in the
> manual I see no entry directly making for this documentation.
> Everything runs just well - but I must have it clean now!
>
> I also tried the RStudio option of generating a Rd file on data, and
> there was an entry I filled out like this
>
>
>
> \describe{
>
> \item{\code{Brom}}{Dataframe of Table S4 in Glaser et al}
>
>
>
> But t didn't cure the warning (Brom entry) above?
>
>
>
> All best wishes
>
> Troels
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Iñaki Úcar
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] size of package and splitting into 2
Dear friends, For the last several iterations of psych I have received the Note that the installed size is 6.7 MB with two subdirectories greater than 1 MB. In the most recent submission to CRAN this led to an automatic rejection which then Uwe kindly overrode to allow the installation on CRAN. In order to make life easier for the CRAN folk, I would like to try to avoid this problem in the future. The only way I can see to get around this note is to split the package into 2: psych and psychTools where psych would require psychTools but psychTools would not require psych. The presumption is that with appropriate splitting, both packages would meet the 1 MB suggestion. However, this implies that loading psych still takes up just as much space as before (since it would also load psychTools) and so it is not clear if this is a benefit. It might even be detrimental to the naive user who doesn’t load them both. It would be useful, perhaps, for those who use psych for the extra features rather than core psychometric ones. They would just need to load psychTools. I am not sure how well the splitting would work in terms of solving the problem and before embarking on this exercise, I would appreciate suggestions as to whether it is necessary (or at least useful). Thanks, Bill William Revellepersonality-project.org/revelle.html Professor personality-project.org Department of Psychology www.wcas.northwestern.edu/psych/ Northwestern Universitywww.northwestern.edu/ Use R for psychology personality-project.org/r It is 2 minutes to midnight www.thebulletin.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check --as-cran problem
Thanks Dirk and Klaus. The package Matrix is not used directly but it is used by package survival, which was called in Suggests. So I am not sure what is the problem. But why CRAN has no such error https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the CRAN check uses the same R version 3.5.2 as I have. The problem only occurred when I used --as-cran option. Zhu -Original Message- From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk Eddelbuettel Sent: Saturday, January 12, 2019 5:19 PM To: Wang, Zhu Cc: r-package-devel@r-project.org Subject: Re: [R-pkg-devel] R CMD check --as-cran problem On 11 January 2019 at 22:51, Wang, Zhu wrote: | ** testing if installed package can be loaded | Error: package or namespace load failed for 'bujar' in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]): | there is no package called 'Matrix' | Error: loading failed | Execution halted | ERROR: loading failed | | | I will appreciate advice on the matter. Something tries to use package Matrix but it is not installed. You may need it in Imports: (and then in NAMESPACE) or in Suggests: (and then test via if (requireNamepace(...) and load). Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] RData files with identical objects in package
Thanks a lot - for my purpose right now I seem to prosper from not loading
lazy
All best
Troels
-Oprindelig meddelelse-
Fra: peter dalgaard
Sendt: 14. januar 2019 15:17
Til: Troels Ring
Cc: Michael Dewey ; package-develop
Emne: Re: [R-pkg-devel] RData files with identical objects in package
There is (of course) a difference between what is the default for a
(missing) field in DESCRIPTION and what shells like RStudio put into the
field by default...
I don't think there is a discrepancy between what is in the official
documentation and what R and R CMD * actually does.
-pd
> On 14 Jan 2019, at 07:10 , Troels Ring wrote:
>
> Thank you so much! Perhaps it could be mentioned in the official
> documentation on writing R extensions - even if - if I can read
> English - the default is to avoid "lazyData" loading - and "laxyData"
> loading is in some opposition to loading using data() - whereas - if
> we use RStudio, and make an R documentation file for data, we have it
> ending with:
> \examples{
> data(ddd)
> ## maybe str(ddd) ; plot(ddd) ...
> }
> \keyword{datasets}
>
> At the same time as "lazyData" is used default in DESCRIPTION ?
>
> 1.1.6 Data in packages
> The data subdirectory is for data files, either to be made available
> via lazy-loading or for loading using data(). (The choice is made by
> the 'LazyData' field in the DESCRIPTION file: the default is not to do
> so.) It should not be used for other data files needed by the package,
> and the convention has grown up to use directory inst/extdata for such
files.
>
> All best wishes
> Troels
>
>
> -Oprindelig meddelelse-
> Fra: peter dalgaard
> Sendt: 13. januar 2019 22:00
> Til: Troels Ring
> Cc: Michael Dewey ; package-develop
>
> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>
> I think it is illegal if you use the lazyload database, because that
> is indexed by name and contains every object that would be created by
data().
> This creates an obvious issue if two objects share a name.
>
> Once you use the lazyload database, loading the package creates an
> environment which is initially full of promises, one for each object.
> Evaluating one of these makes the actual object appear in the environment.
>
> Using data() causes the corresponding promise(s) to be created in the
> global environment. IIRC, there is a registry that says which objects
> are created by which arguments to data(), but as they are still taken
> from the lazydata database, the last one created with a given name still
wins.
>
> -ps
>
>> On 13 Jan 2019, at 14:13 , Troels Ring wrote:
>>
>> Thanks a lot - I'm sure you are right that I could just use different
>> names but I cannot understand why it could cause problem to have two
>> different well formated .RData files in the /data directory both with
>> an "x" - is that really illegal? I cannot see it stated in the
>> official munual - but it is long (wrting r extensions) -BW Troels
>>
>> -Oprindelig meddelelse-
>> Fra: Michael Dewey
>> Sendt: 13. januar 2019 12:56
>> Til: Troels Ring ; package-develop
>>
>> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>>
>> Dear Troels
>>
>> Perhaps I misunderstand what you are trying to do but would it be
>> possible to put each x and y into a list or a dataframe with
>> different names and then modify your usgae to pull them from there?
>> Then there would be no danger of users getting the wrong x and y
>>
>> Michael
>>
>> On 13/01/2019 08:38, Troels Ring wrote:
>>> Dear friends - I have a package under creation making heavy
>>> calculations on chemical/clinical data and I plan to include as
>>> "examples" the use of some literature data used in my papers. To
>>> illustrate what then occurs, I made two RData files consisting only
>>> of x and y with different values for x and y like
>>>
>>> X <- 100
>>>
>>> Y <- 1000
>>>
>>> save(x,y,file="first.RData")
>>>
>>> and then a new x and y in "second" with x <- 45 and y <- 32
>>>
>>> When I put these in a "data" directory of a new package without
>>> further ado in RStudio
>>>
>>> Ctrl-shift-L
>>>
>>> Ctrl-shift-B
>>>
>>>
>>>
>>> .there is a warning
>>>
>>> * installing *source* package 'try' ...
>>>
>>> ** R
>>>
>>> ** data
>>>
>>> *** moving datasets to lazyload DB
>>>
>>> warning: objects 'x', 'y' are created by more than one data call
>>>
>>> ** byte-compile and prepare package for lazy loading
>>>
>>> ** help
>>>
>>> converting help for package 'try'
>>>
>>> *** installing help indices
>>>
>>>finding HTML links ...hello
> html
>>>
>>> done
>>>
>>>
>>>
>>> Now, when I clear the workspace:
>>>
ls()
>>> character(0)
devtools::load_all(".")
>>> Loading try
>>>
>>> Restarting R session...
>>>
library(try)
ls()
>>> character(0)
x #-- so even if workspace Is empty x is still kept
>>> [1] 45
data(first) # and "first" is not seen x
>>> [1] 45
>>>
>>>
>>>
[R-pkg-devel] undocumented data sets
Dear friends - with your help I'm almost through developing a package and
Ctrl-shit-E now only has a single warning
> checking for missing documentation entries ... WARNING
Undocumented data sets:
'Cl' 'K' 'Na' 'TOTAL' 'WA' 'INPUT' 'Alb' 'Ca' 'Lact' 'Mg' 'PCO2' 'S1'
'Brom' 'pHOBS'
All user-level objects in a package should have documentation entries.
See chapter 'Writing R documentation files' in the 'Writing R
Extensions' manual.
But in 2.1.2.Documenting data sets in Writing R extensions it is said that
\arguments is not needed and in the template on p 72 in the manual I see no
entry directly making for this documentation. Everything runs just well -
but I must have it clean now!
I also tried the RStudio option of generating a Rd file on data, and there
was an entry I filled out like this
\describe{
\item{\code{Brom}}{Dataframe of Table S4 in Glaser et al}
But t didn't cure the warning (Brom entry) above?
All best wishes
Troels
[[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] RData files with identical objects in package
There is (of course) a difference between what is the default for a (missing)
field in DESCRIPTION and what shells like RStudio put into the field by
default...
I don't think there is a discrepancy between what is in the official
documentation and what R and R CMD * actually does.
-pd
> On 14 Jan 2019, at 07:10 , Troels Ring wrote:
>
> Thank you so much! Perhaps it could be mentioned in the official
> documentation on writing R extensions - even if - if I can read English -
> the
> default is to avoid "lazyData" loading - and "laxyData" loading is in some
> opposition to loading using data() - whereas - if we use RStudio, and make
> an R documentation file for data, we have it ending with:
> \examples{
> data(ddd)
> ## maybe str(ddd) ; plot(ddd) ...
> }
> \keyword{datasets}
>
> At the same time as "lazyData" is used default in DESCRIPTION ?
>
> 1.1.6 Data in packages
> The data subdirectory is for data files, either to be made available via
> lazy-loading or for loading using data(). (The choice is made by the
> 'LazyData' field in the DESCRIPTION file: the default is not to do so.) It
> should not be used for other data files needed by the package, and the
> convention has grown up to use directory inst/extdata for such files.
>
> All best wishes
> Troels
>
>
> -Oprindelig meddelelse-
> Fra: peter dalgaard
> Sendt: 13. januar 2019 22:00
> Til: Troels Ring
> Cc: Michael Dewey ; package-develop
>
> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>
> I think it is illegal if you use the lazyload database, because that is
> indexed by name and contains every object that would be created by data().
> This creates an obvious issue if two objects share a name.
>
> Once you use the lazyload database, loading the package creates an
> environment which is initially full of promises, one for each object.
> Evaluating one of these makes the actual object appear in the environment.
>
> Using data() causes the corresponding promise(s) to be created in the global
> environment. IIRC, there is a registry that says which objects are created
> by which arguments to data(), but as they are still taken from the lazydata
> database, the last one created with a given name still wins.
>
> -ps
>
>> On 13 Jan 2019, at 14:13 , Troels Ring wrote:
>>
>> Thanks a lot - I'm sure you are right that I could just use different
>> names but I cannot understand why it could cause problem to have two
>> different well formated .RData files in the /data directory both with
>> an "x" - is that really illegal? I cannot see it stated in the
>> official munual - but it is long (wrting r extensions) -BW Troels
>>
>> -Oprindelig meddelelse-
>> Fra: Michael Dewey
>> Sendt: 13. januar 2019 12:56
>> Til: Troels Ring ; package-develop
>>
>> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>>
>> Dear Troels
>>
>> Perhaps I misunderstand what you are trying to do but would it be
>> possible to put each x and y into a list or a dataframe with different
>> names and then modify your usgae to pull them from there? Then there
>> would be no danger of users getting the wrong x and y
>>
>> Michael
>>
>> On 13/01/2019 08:38, Troels Ring wrote:
>>> Dear friends - I have a package under creation making heavy
>>> calculations on chemical/clinical data and I plan to include as
>>> "examples" the use of some literature data used in my papers. To
>>> illustrate what then occurs, I made two RData files consisting only
>>> of x and y with different values for x and y like
>>>
>>> X <- 100
>>>
>>> Y <- 1000
>>>
>>> save(x,y,file="first.RData")
>>>
>>> and then a new x and y in "second" with x <- 45 and y <- 32
>>>
>>> When I put these in a "data" directory of a new package without
>>> further ado in RStudio
>>>
>>> Ctrl-shift-L
>>>
>>> Ctrl-shift-B
>>>
>>>
>>>
>>> .there is a warning
>>>
>>> * installing *source* package 'try' ...
>>>
>>> ** R
>>>
>>> ** data
>>>
>>> *** moving datasets to lazyload DB
>>>
>>> warning: objects 'x', 'y' are created by more than one data call
>>>
>>> ** byte-compile and prepare package for lazy loading
>>>
>>> ** help
>>>
>>> converting help for package 'try'
>>>
>>> *** installing help indices
>>>
>>>finding HTML links ...hello
> html
>>>
>>> done
>>>
>>>
>>>
>>> Now, when I clear the workspace:
>>>
ls()
>>> character(0)
devtools::load_all(".")
>>> Loading try
>>>
>>> Restarting R session...
>>>
library(try)
ls()
>>> character(0)
x #-- so even if workspace Is empty x is still kept
>>> [1] 45
data(first) # and "first" is not seen x
>>> [1] 45
>>>
>>>
>>>
>>> x is still present - and y
>>>
>>>
>>>
>>> I have been reading and searching in "Writing R extensions" but so
>>> far didn't find the clue.
>>>
>>> Seemingly it is the file with the last name that is assessed - when I
>>> rename first.RData to "xfile.RData" we get 100 and 1000.
>>>
>>> Now and then
