Hello!
Regarding the following NOTE:
* checking R code for possible problems ... [4s] NOTE
Found the following assignments to the global environment:
File 'TSEtools/R/getTSE.R':
assign(as.character(s), temp3, envir = as.environment(1))
Please let me know, how can I eliminate this problem? I didn't find out
any good information on websites!
Thanks in advance for your help,
Ali
P.S: The log of package as follows:
* using log directory 'd:/RCompile/CRANguest/R-release/TSEtools.Rcheck'
* using R version 3.4.3 (2017-11-30)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'TSEtools/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'TSEtools' version '0.1.0'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Ali Saeb <ali.saeb at gmail.com>'
New submission
License components with restrictions and base license permitting such:
BSD_2_clause + file LICENSE
File 'LICENSE':
YEAR: 2018
COPYRIGHT HOLDER: Ali Saeb
Possibly mis-spelled words in DESCRIPTION:
TSE (7:84)
performence (7:98)
* 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 'TSEtools' can be installed ... OK
* checking installed package size ... OK
* checking package 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 ... [8s] NOTE
Found the following assignments to the global environment:
File 'TSEtools/R/getTSE.R':
assign(as.character(s), temp3, envir = as.environment(1))
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd line widths ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking examples ...
** running examples for arch 'i386' ... [4s] OK
** running examples for arch 'x64' ... [4s] OK
* checking PDF version of manual ... OK
* DONE
Status: 2 NOTEs
[R-pkg-devel] Assignments to the Global environment
8 messages · Saeb, Peter Dalgaard, Uwe Ligges +3 more
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user variables. Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd
On 6 Jan 2018, at 20:36 , Saeb <ali.saeb at gmail.com> wrote: * checking R code for possible problems ... [4s] NOTE Found the following assignments to the global environment: File 'TSEtools/R/getTSE.R': assign(as.character(s), temp3, envir = as.environment(1)) Please let me know, how can I eliminate this problem? I didn't find out any good information on websites!
Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
Let me add: Frequently you can use storage in an enmvironment in yur package, if that helps to avoid assigning into .GlobalEnv. Best, Uwe Ligges
On 06.01.2018 22:07, peter dalgaard wrote:
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user variables. Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd
On 6 Jan 2018, at 20:36 , Saeb <ali.saeb at gmail.com> wrote: * checking R code for possible problems ... [4s] NOTE Found the following assignments to the global environment: File 'TSEtools/R/getTSE.R': assign(as.character(s), temp3, envir = as.environment(1)) Please let me know, how can I eliminate this problem? I didn't find out any good information on websites!
The function downloads the list of index's value and assigned them to the individual's name correspond with the indexes. If remove the .GlobalEnv, then we can not return the values in output. Since, the data is updated daily, I think that the storage on device is not user friendly enough. I already used the following code with same R report: assign(as.character(s), temp3, envir = .GlobalEnv) | |
On 01/07/2018 01:30 AM, Uwe Ligges wrote:
Let me add: Frequently you can use storage in an enmvironment in yur package, if that helps to avoid assigning into .GlobalEnv. Best, Uwe Ligges On 06.01.2018 22:07, peter dalgaard wrote:
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user variables. Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd
On 6 Jan 2018, at 20:36 , Saeb <ali.saeb at gmail.com> wrote: * checking R code for possible problems ... [4s] NOTE Found the following assignments to the global environment: File 'TSEtools/R/getTSE.R': assign(as.character(s), temp3, envir = as.environment(1)) Please let me know, how can I eliminate this problem? I didn't find out any good information on websites!
I'm not CRAN, but something like this might be permissible while
satisfying your requirements.
z <- function(..., assign.env = parent.frame(1))
assign(as.character(s), temp3, envir = assign.env)
The problem with assigning to the global environment is that z might
be called where it is expected to only have a local effect. If users
really want to assign to the global environment, providing an option
might be appropriate.
z <- function(y, s, assign.env = getOption("TSEtools.z.env",
parent.frame(1))) assign(as.character(s), temp3, envir = assign.env)
options("TSEtools.z.env" = .GlobalEnv)
On Sun, 7 Jan 2018 at 23:21 Saeb <ali.saeb at gmail.com> wrote:
The function downloads the list of index's value and assigned them to the individual's name correspond with the indexes. If remove the .GlobalEnv, then we can not return the values in output. Since, the data is updated daily, I think that the storage on device is not user friendly enough. I already used the following code with same R report: assign(as.character(s), temp3, envir = .GlobalEnv) | | On 01/07/2018 01:30 AM, Uwe Ligges wrote:
Let me add: Frequently you can use storage in an enmvironment in yur package, if that helps to avoid assigning into .GlobalEnv. Best, Uwe Ligges On 06.01.2018 22:07, peter dalgaard wrote:
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user variables. Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd
On 6 Jan 2018, at 20:36 , Saeb <ali.saeb at gmail.com> wrote: * checking R code for possible problems ... [4s] NOTE Found the following assignments to the global environment: File 'TSEtools/R/getTSE.R': assign(as.character(s), temp3, envir = as.environment(1)) Please let me know, how can I eliminate this problem? I didn't find out any good information on websites!
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
It is done. Thanks for the help!
On 01/07/2018 06:11 PM, Hugh Parsonage wrote:
I'm not CRAN, but something like this might be permissible while
satisfying your requirements.
z <- function(..., assign.env = parent.frame(1))
assign(as.character(s), temp3, envir = assign.env)
The problem with assigning to the global environment is that z might
be called where it is expected to only have a local effect. If users
really want to assign to the global environment, providing an option
might be appropriate.
z <- function(y, s, assign.env = getOption("TSEtools.z.env",
parent.frame(1))) assign(as.character(s), temp3, envir = assign.env)
options("TSEtools.z.env" = .GlobalEnv)
On Sun, 7 Jan 2018 at 23:21 Saeb <ali.saeb at gmail.com> wrote:
The function downloads the list of index's value and assigned them to the individual's name correspond with the indexes. If remove the .GlobalEnv, then we can not return the values in output. Since, the data is updated daily, I think that the storage on device is not user friendly enough. I already used the following code with same R report: assign(as.character(s), temp3, envir = .GlobalEnv) | | On 01/07/2018 01:30 AM, Uwe Ligges wrote:
Let me add: Frequently you can use storage in an enmvironment in yur package, if that helps to avoid assigning into .GlobalEnv. Best, Uwe Ligges On 06.01.2018 22:07, peter dalgaard wrote:
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user variables. Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd
On 6 Jan 2018, at 20:36 , Saeb <ali.saeb at gmail.com> wrote: * checking R code for possible problems ... [4s] NOTE Found the following assignments to the global environment: File 'TSEtools/R/getTSE.R': assign(as.character(s), temp3, envir = as.environment(1)) Please let me know, how can I eliminate this problem? I didn't find out any good information on websites!
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
I think that assigning something to parent.frame() is bad practice, for the
same reasons that assigning to .GlobalEnv is bad. You could instead make
an environment in your package called, say, "TSEtools.env", with
TSETools.env <- new.env()
in some *.R file in the package's R directory. Export it via NAMESPACE.
Then use
TSETools.env as the default value of assign.env().
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Sun, Jan 7, 2018 at 6:41 AM, Hugh Parsonage <hugh.parsonage at gmail.com>
wrote:
I'm not CRAN, but something like this might be permissible while
satisfying your requirements.
z <- function(..., assign.env = parent.frame(1))
assign(as.character(s), temp3, envir = assign.env)
The problem with assigning to the global environment is that z might
be called where it is expected to only have a local effect. If users
really want to assign to the global environment, providing an option
might be appropriate.
z <- function(y, s, assign.env = getOption("TSEtools.z.env",
parent.frame(1))) assign(as.character(s), temp3, envir = assign.env)
options("TSEtools.z.env" = .GlobalEnv)
On Sun, 7 Jan 2018 at 23:21 Saeb <ali.saeb at gmail.com> wrote:
The function downloads the list of index's value and assigned them to the individual's name correspond with the indexes. If remove the .GlobalEnv, then we can not return the values in output. Since, the data is updated daily, I think that the storage on device is not user friendly enough. I already used the following code with same R report: assign(as.character(s), temp3, envir = .GlobalEnv) | | On 01/07/2018 01:30 AM, Uwe Ligges wrote:
Let me add: Frequently you can use storage in an enmvironment in yur package, if that helps to avoid assigning into .GlobalEnv. Best, Uwe Ligges On 06.01.2018 22:07, peter dalgaard wrote:
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user
variables.
Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd
On 6 Jan 2018, at 20:36 , Saeb <ali.saeb at gmail.com> wrote: * checking R code for possible problems ... [4s] NOTE Found the following assignments to the global environment: File 'TSEtools/R/getTSE.R': assign(as.character(s), temp3, envir = as.environment(1)) Please let me know, how can I eliminate this problem? I didn't find
out
any good information on websites!
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 07/01/2018 12:17 PM, William Dunlap wrote:
I think that assigning something to parent.frame() is bad practice, for the
same reasons that assigning to .GlobalEnv is bad. You could instead make
an environment in your package called, say, "TSEtools.env", with
TSETools.env <- new.env()
in some *.R file in the package's R directory. Export it via NAMESPACE.
Then use
TSETools.env as the default value of assign.env().
Yes, that's one way to do what Saeb wants.
Another way is to define the relevant functions as local functions, and
do the assignment in their environment. For example,
fns <- local({
s <- NULL
saveS <- function( newSval ) {
s <<- newSval
}
showS <- function() s
list(saveS, showS)
})
saveS <- fns[[1]]
showS <- fns[[2]]
saveS(123)
showS()
which will return the saved value at the end.
As a general principle, writing into the global environment should
almost never be allowed.
Duncan
Bill Dunlap TIBCO Software wdunlap tibco.com On Sun, Jan 7, 2018 at 6:41 AM, Hugh Parsonage <hugh.parsonage at gmail.com> wrote:
I'm not CRAN, but something like this might be permissible while
satisfying your requirements.
z <- function(..., assign.env = parent.frame(1))
assign(as.character(s), temp3, envir = assign.env)
The problem with assigning to the global environment is that z might
be called where it is expected to only have a local effect. If users
really want to assign to the global environment, providing an option
might be appropriate.
z <- function(y, s, assign.env = getOption("TSEtools.z.env",
parent.frame(1))) assign(as.character(s), temp3, envir = assign.env)
options("TSEtools.z.env" = .GlobalEnv)
On Sun, 7 Jan 2018 at 23:21 Saeb <ali.saeb at gmail.com> wrote:
The function downloads the list of index's value and assigned them to the individual's name correspond with the indexes. If remove the .GlobalEnv, then we can not return the values in output. Since, the data is updated daily, I think that the storage on device is not user friendly enough. I already used the following code with same R report: assign(as.character(s), temp3, envir = .GlobalEnv) | | On 01/07/2018 01:30 AM, Uwe Ligges wrote:
Let me add: Frequently you can use storage in an enmvironment in yur package, if that helps to avoid assigning into .GlobalEnv. Best, Uwe Ligges On 06.01.2018 22:07, peter dalgaard wrote:
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user
variables.
Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd
On 6 Jan 2018, at 20:36 , Saeb <ali.saeb at gmail.com> wrote: * checking R code for possible problems ... [4s] NOTE Found the following assignments to the global environment: File 'TSEtools/R/getTSE.R': assign(as.character(s), temp3, envir = as.environment(1)) Please let me know, how can I eliminate this problem? I didn't find
out
any good information on websites!
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel