[Bioc-devel] no visible binding for global variable message

Keith Satterley keith at wehi.EDU.AU
Fri Apr 4 06:03:13 CEST 2008

> * 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,


>> 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

More information about the Bioc-devel mailing list