img - Significado de los objetos enmascarados por el entorno global.
tags$style shiny (4)
Esto significa que tiene objetos llamados load.schedule
, teamStats
en su área de trabajo, así como en la biblioteca que está cargando. Le está advirtiendo que cuando llame a load.schedule
usará la que está en su área de trabajo (ya que está en primer lugar en la ruta de búsqueda) en lugar de la que está adjuntando. Prueba por ejemplo
ddply <- function(x) x + 1
library(plyr)
# Attaching package: ‘plyr’
#
# The following object is masked _by_ ‘.GlobalEnv’:
#
# ddply
ddply(3) # the one we just defined is used, as global env is first in the search path
#[1] 4
Cuando cargo mi paquete en el entorno global, recibo el siguiente mensaje
> library(saber)
Attaching package: ‘saber’
The following objects are masked _by_ ‘.GlobalEnv’:
load.schedule, teamStats
No sé lo que eso significa, ni si debería preocuparme por ello.
¿Por qué se entrega este mensaje y qué significa?
Hay una tercera pregunta implícita que no creo que haya sido completamente respondida para este caso en particular. ¿Cómo solucionarlo en una situación en la que una versión anterior de su propia función está bloqueada en el entorno global y enmascara las nuevas versiones que está intentando probar?
Cambiar el nombre de su función con cada rev no es práctico en esta situación. Tuve la misma situación y encontré que eliminar el archivo .Rdata en el directorio de trabajo antes de reiniciar R resolvió el problema.
Esto me ha sucedido solo dos veces en cientos de veces al armar mis paquetes. Todavía no estoy seguro de cómo las funciones se atascan ocasionalmente en global.
Significa que tiene objetos (funciones, generalmente) presentes en su entorno global con el mismo nombre que las cosas (exportadas) en su paquete. Escriba search()
para ver el orden en que R resuelve los nombres.
La solución es a cualquiera,
- no cree objetos con esos nombres en su entorno global
- cambie el nombre de los objetos en su paquete a algo que sea menos probable que cree un conflicto, o reconsidere su decisión de exportarlos, o
- recuerde que siempre tendrá que referirse a esos objetos como
saber::teamStats
.
Probablemente (2) sea lo mejor, a menos que las circunstancias que llevaron al mensaje sean realmente inusuales.
La razón es que usaste las dos variables anteriores como una variable local en tu Rconsole. Ya que es una variable global, necesita limpiar su proyecto existente si no es necesario; de lo contrario, cambie el nombre de la variable local.
En mi caso:
Declaré una serie de tiempo como gas. Más tarde, durante el paquete de pronóstico de llamadas, encontré el mismo error y cambié el nombre de la biblioteca y utilicé el paquete