Re: [R-pkg-devel] Assignments to the Global environment
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 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Assignments to the Global environment
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 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 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@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] Assignments to the Global environment
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 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 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@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] Help with R check
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_pretest/180107_170932_DataExplorer_050/00check.log Is there a difference in configuration for the "incoming_pretest" check? And is there a way to re-produce this error other than trying to release it? Apologies if I am missing something obvious, and thank you! Best, Boxuan (Bo) On Sat, Jan 6, 2018 at 5:11 PM, Uwe Ligges wrote: > > > On 06.01.2018 18:36, Boxuan Cui wrote: > >> Hi all, >> >> *[Issue 1]* >> >> This is the first time I have encountered this, and I have no idea what's >> going on. I really appreciate anyone's help on this. >> >> My package: https://cran.r-project.org/package=DataExplorer >> >> My story: >> >> - *[Jan 01]* >>- I plan to release the latest version to CRAN. I ran all checks >>(including win-builder through *devtools::build_win()*) on my >>package, everything is OK, so I submitted it. >>- The URL for win-builder has expired, but in case you can find the >>check log: https://win-builder.r-project.org/D52z9NcU7633 >>- AppVeyor build log: >>https://ci.appveyor.com/project/boxuancui/dataexplorer/ >> build/master.36 >>- Travis CI build log: >>https://travis-ci.org/boxuancui/DataExplorer/builds/323730230 >> - *[Jan 03]* >>- I was told that I need to update my MIT license file, since I >> made >>some changes there. I did as told and re-submit the package. I >> didn't >>change anything. >> - *[Jan 03 (later of the day)]* >>- My package is failing example checks on arch 'i386' for Windows, >>according to >>https://win-builder.r-project.org/incoming_pretest/ >> 180103_161227_DataExplorer_050/00check.log >>- Note the example was failing for *split_columns()*. >> - *[Jan 05]* >>- I saw the Email and did another *devtools::build_win()* with no >>changes at all. >>- I received the same error, but on another function, i.e., >>*set_missing()*. >>- The check log is here: >>https://win-builder.r-project.org/9bKr71mwef11/00check.log >> - *[Jan 05]* >>- After some investigation, I believe it is due to dependency >>versions, so I update DESCRIPTION with latest version for all, >> including R >>(was 3.3.0). >> > > > No, not the reason: You checked with R-devel, hence the version > requirement is not the reason for the problems you reported above. > >- This time the check log is showing a warning: *checking >> DESCRIPTION >>meta-information ... WARNING Dependence on R version '3.4.3' not >> with >>patchlevel 0*. >>- The check log is here: >>https://win-builder.r-project.org/5Px18P21h44a/00check.log >> >> Has anyone encountered this issue before? >> > > > In order to get consistent binary repositories etc., we ask you to find > proper vresion requirement with patchlevel 0, i.e. 3.3.0 or 3.4.0 if > applicable. > > > Best, > Uwe Ligges > > > > *[Issue 2]* >> >> Does anyone know how to remove these warnings for vignettes? >> https://cran.r-project.org/web/checks/check_results_DataExplorer.html >> They happen on the following systems: >> >> - r-patched-solaris-x86 >> - r-release-osx-x86_64 >> - r-oldrel-osx-x86_64 >> >> Warning message: >> >> *Warning in engine$weave(file, quiet = quiet, encoding = enc) :* >> * Pandoc (>= 1.12.3) and/or pandoc-citeproc not available. Falling >> back >> to R Markdown v1.* >> *Warning in normalizePath(f2) :* >> * path[1]="./webshot3eaf50bf136e.png": No such file or directory* >> *Warning in file(con, "rb") :* >> * cannot open file './webshot3eaf50bf136e.png': No such file or >> directory* >> *Quitting from lines 57-68 (dataexplorer-intro.Rmd) * >> *Error: processing vignette 'dataexplorer-intro.Rmd' failed with >> diagnostics:* >> *cannot open the connection* >> *Execution halted * >> >> >> After searching for the same warnings online, I found that vignettes (from >> other pakcages) that loads JavaScript files tend to have these. Is there a >> way to fix this? >> >> >> Thank you very much for your time! >> >> >> Best, >> Boxuan (Bo) >> >> [[alternative HTML version deleted]] >> >> __ >> 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] Assignments to the Global environment
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
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 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 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@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
>
[[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] Assignments to the Global environment
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
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 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 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@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
[[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
