Help please,
I'm checking over my affylmGUI package under R-2.7.0dev.
If I do an R CMD check affylmGUI
with the environment variable _R_CHECK_USE_CODETOOLS_ set to true
There are no error messages and the package runs ok. However I get over 400
lines of messages, the first few of which are:
* checking R code for possible problems ... NOTE
affylmGUI: no visible binding for global variable
'affylmGUIenvironment'
affylmGUI: no visible binding for global variable '.affylmGUIglobals'
affylmGUI : <anonymous>: no visible binding for global variable
'.affylmGUIglobals'
...
There were some messages I found useful, such as " unused argument(s)"
After some investigation, I released I could load the codetools package and get
a function by function report using the checkUsage() function.
This gave me some more useful reports such as "no visible global function
definition for ?tkrplot?".
Dealing with the one problem at a time, I thought I would address the
no visible binding for global variable
'affylmGUIenvironment'
message which occurred in many functions, one for example was the
"ViewRNATargets" function.
"affylmGUIenvironment" is set in the affylmGUI function with the line:
assign("affylmGUIenvironment",new.env(),.GlobalEnv)
Many variables are assigned to this environment with statements like:
assign("Targets", data.frame(),affylmGUIenvironment)
assign("adjustMethod","BH", affylmGUIenvironment)
assign("weightsPLM", data.frame(),affylmGUIenvironment)
I (or the original programmer) then used it in the ViewRNATargets function with
some code like:
Targets <- get("Targets",envir=affylmGUIenvironment)
The affylmGUIenvironment variable was not passed to the ViewRNATargets function
- there were no arguments to this function.
By putting affylmGUIenvironment in as an argument to the ViewRNATargets
function, checkUsage(ViewRNATargets) was happy and no longer reported a non
visible binding for the global variable, However the function fails now with a
message "Error in get("Targets", envir = affylmGUIenvironment):invalid 'envir'
argument.
Question 1. Should I try an eliminate these "no visible binding for global
variable" warning messages from codetools?
Question 2. If I should, how can I do it and still have working code!
Thanks for any suggestions, I'm still learning a lot of the finer points of R,
cheers,
Keith
> sessionInfo()
R version 2.7.0 Under development (unstable) (2008-03-23 r44847)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] tools tcltk stats graphics grDevices datasets utils
methods base
other attached packages:
[1] affylmGUI_1.13.1 affy_1.17.8 preprocessCore_1.1.5 affyio_1.7.14
Biobase_1.99.2 limma_2.13.6
[7] codetools_0.1-3
========================
Keith Satterley
affylmGUI maintainer
Bioinformatics Division
The Walter and Eliza Hall Institute of Medical Research
Parkville, Melbourne,
Victoria, Australia
[Bioc-devel] no visible binding for global variable message
5 messages · Keith Satterley, Seth Falcon, Laurent Gautier
* On 2008-04-04 at 00:04 +1100 Keith Satterley wrote:
Help please, I'm checking over my affylmGUI package under R-2.7.0dev. If I do an R CMD check affylmGUI with the environment variable _R_CHECK_USE_CODETOOLS_ set to true There are no error messages and the package runs ok. However I get over 400 lines of messages, the first few of which are:
Do you mean that you get no errors when that var is set to false by any chance?
Dealing with the one problem at a time, I thought I would address the
no visible binding for global variable
'affylmGUIenvironment'
message which occurred in many functions, one for example was the
"ViewRNATargets" function.
"affylmGUIenvironment" is set in the affylmGUI function with the line:
assign("affylmGUIenvironment",new.env(),.GlobalEnv)
There's probably a cleaner way to code this now. I would consider creating the environment within your package instead of the global envirnt. And mostly for readability, I would not use assignsign() and get() when working with environments, but instead [[ and <-. So you could have: affylmGUIenvironment <- new.env(hash=TRUE, parent=emptyenv()) Read the help page for details, but generally if you are using an environment as a hashtable you don't what it to inherit bindings and parent=emptyenv() is what you want.
Many variables are assigned to this environment with statements like:
assign("Targets", data.frame(),affylmGUIenvironment)
assign("adjustMethod","BH", affylmGUIenvironment)
assign("weightsPLM", data.frame(),affylmGUIenvironment)
These could all be written like: affylmGUIenvironment[["Targets"]] <- data.frame()
I (or the original programmer) then used it in the ViewRNATargets function with
some code like:
Targets <- get("Targets",envir=affylmGUIenvironment)
And this can be written as: Targets <- affylmGUIenvironment[["Targets"]]
The affylmGUIenvironment variable was not passed to the ViewRNATargets function
- there were no arguments to this function.
By putting affylmGUIenvironment in as an argument to the ViewRNATargets
function, checkUsage(ViewRNATargets) was happy and no longer reported a non
visible binding for the global variable, However the function fails now with a
message "Error in get("Targets", envir = affylmGUIenvironment):invalid 'envir'
argument.
I think if the affylmGUIenvironment is defined at package scope, as suggested above, you can define functions that refer to it without incurring a warning from codetools (untested).
Question 1. Should I try an eliminate these "no visible binding for global variable" warning messages from codetools?
IMO, yes. It would be highly advisable to add a NAMESPACE file to the package as well. + seth
Seth Falcon | http://userprimary.net/user/
* On 2008-04-04 at 00:04 +1100 Keith Satterley wrote:
Help please, I'm checking over my affylmGUI package under R-2.7.0dev. If I do an R CMD check affylmGUI with the environment variable _R_CHECK_USE_CODETOOLS_ set to true There are no error messages and the package runs ok. However I get over 400 lines of messages, the first few of which are:
Do you mean that you get no errors when that var is set to false by any chance?
Good to see you around Seth! I was being a bit pedantic here. Last time I referred to the messages from codetools as errors, it was pointed out that they wern't error messgaes, but warnings. (I think perhaps they are NOTES to the programmer rather than warnings). So with _R_CHECK_USE_CODETOOLS_ set to true or false, I get no error messages as such, but with _R_CHECK_USE_CODETOOLS_ set to true, I get 400+ lines of messages from codetools and with it set to false, I get no messages from codetools. Thanks for the explanation on how to avoid the codetools messages and recode the approach to environments. I'll start on this next week. I have a lot of lines to change as the affylmGUIenvironment is referred to many times in the code, (and similar in my limmaGUI package). I'll test a small section first. I have a NAMESPACE in my code now, not sure if I have committed it yet. thanks Seth, Keith
Dealing with the one problem at a time, I thought I would address the
no visible binding for global variable
'affylmGUIenvironment'
message which occurred in many functions, one for example was the
"ViewRNATargets" function.
"affylmGUIenvironment" is set in the affylmGUI function with the line:
assign("affylmGUIenvironment",new.env(),.GlobalEnv)
There's probably a cleaner way to code this now. I would consider creating the environment within your package instead of the global envirnt. And mostly for readability, I would not use assignsign() and get() when working with environments, but instead [[ and <-. So you could have: affylmGUIenvironment <- new.env(hash=TRUE, parent=emptyenv()) Read the help page for details, but generally if you are using an environment as a hashtable you don't what it to inherit bindings and parent=emptyenv() is what you want.
Many variables are assigned to this environment with statements like:
assign("Targets", data.frame(),affylmGUIenvironment)
assign("adjustMethod","BH", affylmGUIenvironment)
assign("weightsPLM", data.frame(),affylmGUIenvironment)
These could all be written like: affylmGUIenvironment[["Targets"]] <- data.frame()
I (or the original programmer) then used it in the ViewRNATargets
function with
some code like:
Targets <- get("Targets",envir=affylmGUIenvironment)
And this can be written as: Targets <- affylmGUIenvironment[["Targets"]]
The affylmGUIenvironment variable was not passed to the ViewRNATargets
function
- there were no arguments to this function.
By putting affylmGUIenvironment in as an argument to the ViewRNATargets
function, checkUsage(ViewRNATargets) was happy and no longer reported a
non
visible binding for the global variable, However the function fails now
with a
message "Error in get("Targets", envir = affylmGUIenvironment):invalid
'envir'
argument.
I think if the affylmGUIenvironment is defined at package scope, as suggested above, you can define functions that refer to it without incurring a warning from codetools (untested).
Question 1. Should I try an eliminate these "no visible binding for global variable" warning messages from codetools?
IMO, yes. It would be highly advisable to add a NAMESPACE file to the package as well. + seth -- Seth Falcon | http://userprimary.net/user/
_______________________________________________ Bioc-devel at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
2008/4/3, Seth Falcon <seth at userprimary.net>:
* On 2008-04-04 at 00:04 +1100 Keith Satterley wrote:
[...]
> Dealing with the one problem at a time, I thought I would address the
> no visible binding for global variable
> 'affylmGUIenvironment'
> message which occurred in many functions, one for example was the
> "ViewRNATargets" function.
> "affylmGUIenvironment" is set in the affylmGUI function with the line:
>
> assign("affylmGUIenvironment",new.env(),.GlobalEnv)
There's probably a cleaner way to code this now. I would consider creating the environment within your package instead of the global envirnt. And mostly for readability, I would not use assignsign() and get() when working with environments, but instead [[ and <-. So you could have: affylmGUIenvironment <- new.env(hash=TRUE, parent=emptyenv()) Read the help page for details, but generally if you are using an environment as a hashtable you don't what it to inherit bindings and parent=emptyenv() is what you want.
Wow. I missed that one "new" feature with environments: methods "[[" and "[[<-". Looking quickly at the current development bioconductor code, it seems that "assign" is still very much used. L.
* On 2008-04-04 at 15:23 +0200 Laurent Gautier wrote:
2008/4/3, Seth Falcon <seth at userprimary.net>:
There's probably a cleaner way to code this now. I would consider creating the environment within your package instead of the global envirnt. And mostly for readability, I would not use assignsign() and get() when working with environments, but instead [[ and <-. So you could have: affylmGUIenvironment <- new.env(hash=TRUE, parent=emptyenv()) Read the help page for details, but generally if you are using an environment as a hashtable you don't what it to inherit bindings and parent=emptyenv() is what you want.
Wow. I missed that one "new" feature with environments: methods "[[" and "[[<-". Looking quickly at the current development bioconductor code, it seems that "assign" is still very much used.
These features are not particularly new, but new is in the eye of the beholder I suppose :-) I don't mean to malign assign(). The reason I prefer [[<- is that it reads like other assignments in R. + seth
Seth Falcon | http://userprimary.net/user/