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 so
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
I made some updates and ran a couple of additional checks, e.g., R CMD
check --as-cran, win-builder, AppVeyor, Travis. Everything is giving me
status OK. However, when I try to resubmit my package, I get another
ERROR running
examples for arch 'i386':
https://win-builder.r-project.org/incoming_pret
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 wit
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
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 al
