[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