[R-pkg-devel] note
Hi,
I am trying to submit a package with a shiny app to cran.
I get 2 notes that I don't know how to resolve. I would appreciate very much
any suggestions/help.
Thanks a lot.
It seems the first note is on possibly misspelled words. I am using camel-case
to "explain" the name of the app, the app's name itself is mostly capitalized,
and the others are either names of objects or the title (Transcriptomics),
which I believe should be capitalized... So, I don't really know how to
overcome this.
With respect to the TRONCO license, I believe the reason for the message is
that they included a custom file, but they are also using GPL3 (which I am
required to use by my company) I don't see a solution...
Then, there are some global variables and things that are only defined under
the inst directory. I came about the solution of putting the main part of my
app /inst by finding similar solutions on google. I ran into a whole bunch of
problems with putting everything under /R and I can create a package etc on
GitHub and locally and install them through GitHub or locally. The only caveat
is that I had to define these variables to pass the arguments as there are
different environments involved... I think I chose the variable names in a way
that shouldn't interfere with anything...
As you can imagine by now, this is the first package I am submitting and it is
quite a daunting task, so I am very sorry to haven't understood by now all the
documentation and I am still hoping that the approach I took is viable. 😉
Thanks for taking the time to look into this.
Here is the log:
* using log directory 'd:/RCompile/CRANincoming/R-devel/SCHNAPPs.Rcheck'
* using R Under development (unstable) (2019-06-03 r76654)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'SCHNAPPs/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'SCHNAPPs' version '0.1.2'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Bernd Jagla '
New submission
Possibly mis-spelled words in DESCRIPTION:
APPlication (8:32)
SCHNAPPs (8:45)
SingleCellExperiment (11:5)
Transcriptomics (4:9)
sHiny (8:26)
Package has a FOSS license but eventually depends on the following
package which may restrict use:
TRONCO
Size of tarball: 14400839 bytes
* 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 hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'SCHNAPPs' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for future file timestamps ... OK
* checking 'build' directory ... OK
* checking DESCRIPTION meta-information ... OK
* 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
* loading checks for arch 'i386'
** 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 use of S3 registration ... OK
* loading checks for arch 'x64'
** 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 use of S3 registration ... 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 ... [10s] NOTE
schnapps: no visible global function definition for 'shinyApp'
schnapps: no visible binding for global variable 'scShinyUI'
schnapps: no visible binding for global variable 'scShinyServer'
schnapps: no visible global function definition for 'runApp'
Undefined global functions or variables:
runApp scShinyServer scShinyUI shinyApp
Found the following assignments to the global environment:
File 'SCHNAPPs/R/schnapps-Main.R':
assign(".SCHNAPPs_locContributionDir", localContributionDir,
envir = globalenv())
assign(".SCHNAPPs_defaultValueSingleGene", defaultValueSingleGene,
envir = globalenv())
assign(".SCHNAPPs_defaultValueMultiGenes", default
Re: [R-pkg-devel] note
On 04/06/2019 8:36 a.m., Bernd JAGLA wrote: Hi, I am trying to submit a package with a shiny app to cran. I get 2 notes that I don't know how to resolve. I would appreciate very much any suggestions/help. Thanks a lot. It seems the first note is on possibly misspelled words. I am using camel-case to "explain" the name of the app, the app's name itself is mostly capitalized, and the others are either names of objects or the title (Transcriptomics), which I believe should be capitalized... So, I don't really know how to overcome this. Explain in your submission note why you spelled things the way you did. Generally non-English words should be in single quotes; see https://cloud.r-project.org/web/packages/submission_checklist.html. But "sHiny" looks wrong in any case if it is not quoted. With respect to the TRONCO license, I believe the reason for the message is that they included a custom file, but they are also using GPL3 (which I am required to use by my company) I don't see a solution... TRONCO is a Bioconductor package, and isn't declaring its GPL-3 license in the format that CRAN wants. Explain this in your submission note. Then, there are some global variables and things that are only defined under the inst directory. I came about the solution of putting the main part of my app /inst by finding similar solutions on google. I ran into a whole bunch of problems with putting everything under /R and I can create a package etc on GitHub and locally and install them through GitHub or locally. The only caveat is that I had to define these variables to pass the arguments as there are different environments involved... I think I chose the variable names in a way that shouldn't interfere with anything... Don't create global variables. The global environment is off limits to you. You can have an environment in your package that contains those variables. This one you'll have to change, not just explain like the others. Duncan Murdoch As you can imagine by now, this is the first package I am submitting and it is quite a daunting task, so I am very sorry to haven't understood by now all the documentation and I am still hoping that the approach I took is viable. 😉 Thanks for taking the time to look into this. Here is the log: * using log directory 'd:/RCompile/CRANincoming/R-devel/SCHNAPPs.Rcheck' * using R Under development (unstable) (2019-06-03 r76654) * using platform: x86_64-w64-mingw32 (64-bit) * using session charset: ISO8859-1 * checking for file 'SCHNAPPs/DESCRIPTION' ... OK * checking extension type ... Package * this is package 'SCHNAPPs' version '0.1.2' * package encoding: UTF-8 * checking CRAN incoming feasibility ... NOTE Maintainer: 'Bernd Jagla ' New submission Possibly mis-spelled words in DESCRIPTION: APPlication (8:32) SCHNAPPs (8:45) SingleCellExperiment (11:5) Transcriptomics (4:9) sHiny (8:26) Package has a FOSS license but eventually depends on the following package which may restrict use: TRONCO Size of tarball: 14400839 bytes * 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 hidden files and directories ... OK * checking for portable file names ... OK * checking whether package 'SCHNAPPs' can be installed ... OK * checking installed package size ... OK * checking package directory ... OK * checking for future file timestamps ... OK * checking 'build' directory ... OK * checking DESCRIPTION meta-information ... OK * 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 * loading checks for arch 'i386' ** 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 use of S3 registration ... OK * loading checks for arch 'x64' ** 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 use of S3 registration ... OK * checking dependencies in R code ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking R c
Re: [R-pkg-devel] note
Regarding the global variables... I found [1] illuminating, in particular the comments on the solution. [1] https://stackoverflow.com/questions/41954302/where-to-create-package-environment-variables On June 4, 2019 11:07:20 AM PDT, Duncan Murdoch wrote: >On 04/06/2019 8:36 a.m., Bernd JAGLA wrote: >> Hi, >> >> >> I am trying to submit a package with a shiny app to cran. >> >> I get 2 notes that I don't know how to resolve. I would appreciate >very much any suggestions/help. >> >> >> Thanks a lot. >> >> >> It seems the first note is on possibly misspelled words. I am using >camel-case to "explain" the name of the app, the app's name itself is >mostly capitalized, and the others are either names of objects or the >title (Transcriptomics), which I believe should be capitalized... So, I >don't really know how to overcome this. > >Explain in your submission note why you spelled things the way you did. > >Generally non-English words should be in single quotes; see >https://cloud.r-project.org/web/packages/submission_checklist.html. >But >"sHiny" looks wrong in any case if it is not quoted. >> >> >> With respect to the TRONCO license, I believe the reason for the >message is that they included a custom file, but they are also using >GPL3 (which I am required to use by my company) I don't see a >solution... > >TRONCO is a Bioconductor package, and isn't declaring its GPL-3 license > >in the format that CRAN wants. Explain this in your submission note. >> >> >> Then, there are some global variables and things that are only >defined under the inst directory. I came about the solution of putting >the main part of my app /inst by finding similar solutions on google. I >ran into a whole bunch of problems with putting everything under /R and >I can create a package etc on GitHub and locally and install them >through GitHub or locally. The only caveat is that I had to define >these variables to pass the arguments as there are different >environments involved... I think I chose the variable names in a way >that shouldn't interfere with anything... > >Don't create global variables. The global environment is off limits to >you. You can have an environment in your package that contains those >variables. This one you'll have to change, not just explain like the >others. > >Duncan Murdoch >> >> >> As you can imagine by now, this is the first package I am submitting >and it is quite a daunting task, so I am very sorry to haven't >understood by now all the documentation and I am still hoping that the >approach I took is viable. 😉 >> >> >> Thanks for taking the time to look into this. >> >> >> Here is the log: >> >> * using log directory >'d:/RCompile/CRANincoming/R-devel/SCHNAPPs.Rcheck' >> * using R Under development (unstable) (2019-06-03 r76654) >> * using platform: x86_64-w64-mingw32 (64-bit) >> * using session charset: ISO8859-1 >> * checking for file 'SCHNAPPs/DESCRIPTION' ... OK >> * checking extension type ... Package >> * this is package 'SCHNAPPs' version '0.1.2' >> * package encoding: UTF-8 >> * checking CRAN incoming feasibility ... NOTE >> Maintainer: 'Bernd Jagla ' >> >> New submission >> >> Possibly mis-spelled words in DESCRIPTION: >>APPlication (8:32) >>SCHNAPPs (8:45) >>SingleCellExperiment (11:5) >>Transcriptomics (4:9) >>sHiny (8:26) >> >> Package has a FOSS license but eventually depends on the following >> package which may restrict use: >>TRONCO >> >> Size of tarball: 14400839 bytes >> * 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 hidden files and directories ... OK >> * checking for portable file names ... OK >> * checking whether package 'SCHNAPPs' can be installed ... OK >> * checking installed package size ... OK >> * checking package directory ... OK >> * checking for future file timestamps ... OK >> * checking 'build' directory ... OK >> * checking DESCRIPTION meta-information ... OK >> * 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 >> * loading checks for arch 'i386' >> ** 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 use of S3 registration ... OK >> * loading checks for arch 'x64' >> ** checking whether the package can be loaded ... OK >> ** checking whether the package can be loaded with stated
[R-pkg-devel] Non-portable flags.
I am working on a revision of my Iso package (which hasn't been revised for quite a while) and have added in registration of Fortran routines that are called directly by .Fortran() in R functions. When I do R CMD check --as-cran Iso_0.0-18.tar.gz I get a "NOTE": Compilation used the following non-portable flag(s): ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’ After experimenting with building a *.so file directly using SHLIB I discerned that the problem appears to arise from the compilation of the init.c file that I placed in "src" to effect the routine registration: gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG -fpic -g -O2 -fdebug-prefix-map=/build/r-base-VAQCff/r-base-3.6.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c init.c -o init.o I presume that I should do something about this note. (Non-portability is indeed an egregious sin.) How can I tell gcc not to use these flags? Note that the NOTE does not arise unless I use the "--as-cran" flag. Thanks for any insight. cheers, Rolf Turner P.S. I am running Ubuntu 18.04. Happy to supply any further details that might be relevant. R. T. -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Non-portable flags.
On 4 June 2019 at 16:42, Rolf Turner wrote:
| I am working on a revision of my Iso package (which hasn't been revised
| for quite a while) and have added in registration of Fortran routines
| that are called directly by .Fortran() in R functions.
|
| When I do
|
| R CMD check --as-cran Iso_0.0-18.tar.gz
|
| I get a "NOTE":
|
| > Compilation used the following non-portable flag(s):
| > ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
[...]
| P.S. I am running Ubuntu 18.04. Happy to supply any further details
| that might be relevant.
Upgrade to 3.6.0-2 and it will be taken care of -- first bullet of second
entry in what follows in relevant. I should have taken care of that earlier.
In any event, this was discussed here or on r-sig-debian very recently.
edd@rob:~$ zcat /usr/share/doc/r-base-core/changelog.Debian.gz | \
head -17 r-base (3.6.0-2cosmic) cosmic; urgency=medium
* Compilation for Ubuntu 18.10
* debian/control Changed dependency to generic tcl-dev and tk-dev
-- Michael Rutter Mon, 13 May 2019 00:41:33 +
r-base (3.6.0-2) unstable; urgency=medium
* debian/Renviron.site: Set variable _R_CHECK_COMPILATION_FLAGS_KNOWN_
to white-list compiler flags pulled in Debian's gcc configuration
* configure{,.ac}: Applied two upstream patches from this week to
accommodate gfortran 8 changes related to C to Fortran calls
-- Dirk Eddelbuettel Sat, 11 May 2019 13:58:42 -0500
edd@rob:~$
(I am on 18.10 but Michael kindly provides builds for all relevant flavours,
including your 18.04.)
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] Non-portable flags.
On 4/06/19 4:51 PM, Dirk Eddelbuettel wrote:
On 4 June 2019 at 16:42, Rolf Turner wrote:
| I am working on a revision of my Iso package (which hasn't been revised
| for quite a while) and have added in registration of Fortran routines
| that are called directly by .Fortran() in R functions.
|
| When I do
|
| R CMD check --as-cran Iso_0.0-18.tar.gz
|
| I get a "NOTE":
|
| > Compilation used the following non-portable flag(s):
| > ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
[...]
| P.S. I am running Ubuntu 18.04. Happy to supply any further details
| that might be relevant.
Upgrade to 3.6.0-2 and it will be taken care of -- first bullet of second
entry in what follows in relevant. I should have taken care of that earlier.
In any event, this was discussed here or on r-sig-debian very recently.
edd@rob:~$ zcat /usr/share/doc/r-base-core/changelog.Debian.gz | \
head -17 r-base (3.6.0-2cosmic) cosmic; urgency=medium
* Compilation for Ubuntu 18.10
* debian/control Changed dependency to generic tcl-dev and tk-dev
-- Michael Rutter Mon, 13 May 2019 00:41:33 +
r-base (3.6.0-2) unstable; urgency=medium
* debian/Renviron.site: Set variable _R_CHECK_COMPILATION_FLAGS_KNOWN_
to white-list compiler flags pulled in Debian's gcc configuration
* configure{,.ac}: Applied two upstream patches from this week to
accommodate gfortran 8 changes related to C to Fortran calls
-- Dirk Eddelbuettel Sat, 11 May 2019 13:58:42 -0500
edd@rob:~$
(I am on 18.10 but Michael kindly provides builds for all relevant flavours,
including your 18.04.)
Dirk
Thanks Dirk. I did an upgrade and the NOTE went away, so I guess that
all is well.
I'm never sure about upgrading with "sudo apt whatever", so I was a bit
apprehensive. For the record I did:
sudo apt update
sudo apt upgrade r.base
The latter took quite a while; 15 or 20 minutes. There's probably
something simpler that I could have done, but when you don't know, you
don't know.
There was no indication that I am now getting version 3.6.0-2; any
enquires about the version that I can seem to make indicate version
3.6.0; no "-2" in sight. However, as I said above, it seems to have worked.
cheers,
Rolf
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Non-portable flags.
On 4 June 2019 at 17:35, Rolf Turner wrote: | Thanks Dirk. I did an upgrade and the NOTE went away, so I guess that | all is well. Yes. | I'm never sure about upgrading with "sudo apt whatever", so I was a bit | apprehensive. For the record I did: | | sudo apt update | sudo apt upgrade r.base I have been doing 'wajig update; wajig dist-upgrade' thanks to Graham Williams for probaly 15 years now. 'wajig' normalizes a few of the commands, keeps state, and calls sudo for me. | The latter took quite a while; 15 or 20 minutes. There's probably | something simpler that I could have done, but when you don't know, you | don't know. "The best time to plant a tree was 20 years ago. The second best time is now." You can always learn about these commands. It pays you back with interest. | There was no indication that I am now getting version 3.6.0-2; any | enquires about the version that I can seem to make indicate version | 3.6.0; no "-2" in sight. However, as I said above, it seems to have worked. Upstream version: 3.6.0. What 'R --version' shows you. Distro build: 3.6.0-2. What eg 'dpkg -s r-base-core' or 'dpkg -k r-base-core' shows you. Two related but different systems. 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
