[R] [bug] spdep package?

Jeremie Juste jerem|eju@te @end|ng |rom gm@||@com
Mon Jul 23 20:13:00 CEST 2018


Many thanks for the info.

I see the point but I'll think calling the spData would be a cheaper
price to pay. If each package one load provide access to their variables
things are likely to get messy.

I guess many R users would like to control the variables in their global
environment.

And since it is not trival to protect variables inside a function from
the parent environment this is potentially dangerous.

Best wishes,

Jeremie










Henrik Bengtsson <henrik.bengtsson using gmail.com> writes:

> This is intended/expected because the spdep package *depends* on the
> spData package (see https://cran.r-project.org/web/packages/spdep/),
> which means that the maintainer of spdep intends also spData to be
> *attached* whenever spdep is attached.    If they would have only
> imported it, then spData would only be *loaded* (but not attached),
> and you would not get 'spData' on your search() path and therefore not
> see 'x' either.
>
> Example:
>
> ## Loading spData
>> loadNamespace("spData")
> <environment: namespace:spData>
>
>> loadedNamespaces()
> [1] "compiler"  "graphics"  "utils"     "grDevices" "stats"     "datasets"
> [7] "methods"   "spData"    "base"
>
> ## The search path used to find objects
>> search()
> [1] ".GlobalEnv"        "package:stats"     "package:graphics"
> [4] "package:grDevices" "package:utils"     "package:datasets"
> [7] "package:methods"   "Autoloads"         "package:base"
>
> ## So, spData::x is not found
>> x
> Error: object 'x' not found
>
> ## But is still there
>> spData::x
>  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>
> ## Attaching spData, which also happens when you do library(spdat)
>> library(spData)
> To access larger datasets in this package, install the spDataLarge
> package with: `install.packages('spDataLarge',
> repos='https://nowosad.github.io/drat/', type='source'))
>
>> loadedNamespaces()
> [1] "compiler"  "graphics"  "utils"     "grDevices" "stats"     "datasets"
> [7] "methods"   "spData"    "base"
>
> ## Now, spData is on the search path
>> search()
>  [1] ".GlobalEnv"        "package:spData"    "package:stats"
>  [4] "package:graphics"  "package:grDevices" "package:utils"
>  [7] "package:datasets"  "package:methods"   "Autoloads"
> [10] "package:base
>
>> x
>  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>
>> find("x")
> [1] "package:spData"
>
> /Henrik
> On Mon, Jul 23, 2018 at 2:01 PM Jeremie Juste <jeremiejuste using gmail.com> wrote:
>>
>>
>> Helllo,
>>
>> Thanks for the info. I still think these variables should not be loaded
>> when library(spdep) is called.
>>
>> But I'll handle it following your suggestion.
>>
>> Thanks,
>>
>> Jeremie
>>
>>
>>
>>
>>
>>
>> > It turns out that that 'x' comes from the spData package and lives
>> > inside that package (part of its namespace).
>> >
>> >> spData::x
>> >  [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> >
>> > This is conceptually no different from other objects in package
>> > namespace, although we are more used to seeing functions and not data
>> > object.  Another well-known example of this is:
>> >
>> >> base::pi
>> > [1] 3.141593
>> >
>> > So, this 'x' is *not* in your global workspace and you cannot remove
>> > it without unloading the package.
>> >
>> > /Henrik
>>
>>
>> >>
>> >>
>> >> I found a dangerous issue in the library spdep. I get variables x and y
>> >> that cannot be removed by rm() and I don't don't how they show up. Can
>> >> anyone reproduce this?
>> >>
>> >> ~$ R --vanilla
>> >> > rm(list=ls())
>> >> > library(spdep)
>> >> > x
>> >> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> >> > rm(list=ls())
>> >> > x
>> >> [1]   0  30  60  90 120 150 180 210 240 270 300 330 360 390 420 450
>> >>
>> >>
>> >>
>> >> > Sys.info()
>> >>
>> >> sysname        "Linux"
>> >> release        "4.9.0-6-amd64"
>> >> version        "#1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07)"
>> >> nodename       "freegnu"
>> >> machine        "x86_64"
>> >>
>> >>
>> >> > Session
>> >>
>> >>
>> >> > sessionInfo()
>> >>
>> >> R version 3.4.1 (2017-06-30)
>> >> Platform: x86_64-pc-linux-gnu (64-bit)
>> >> Running under: Debian GNU/Linux 9 (stretch)
>> >>
>> >> Matrix products: default
>> >> BLAS: /usr/local/lib/R/lib/libRblas.so
>> >> LAPACK: /usr/local/lib/R/lib/libRlapack.so
>> >>
>> >> locale:
>> >>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>> >>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>> >>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>> >>  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
>> >>  [9] LC_ADDRESS=C               LC_TELEPHONE=C
>> >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>> >>
>> >> attached base packages:
>> >> [1] stats     graphics  grDevices utils     datasets  methods   base
>> >>
>> >> loaded via a namespace (and not attached):
>> >> [1] compiler_3.4.1
>> >>
>> >> ______________________________________________
>> >> R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> >> https://stat.ethz.ch/mailman/listinfo/r-help
>> >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>> >> and provide commented, minimal, self-contained, reproducible code.




More information about the R-help mailing list