Re: [R] [bug] spdep package?
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 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")
>
>
>> 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 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-8LC_COLLATE=en_US.UTF-8
>> >> [5] LC_MONETARY=en_US.UTF-8LC_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@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> >> https://stat.ethz.ch/mailman/listinfo/r-help
>> >> PLEASE do read the
Re: [R] [bug] spdep package?
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")
> 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 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-8LC_COLLATE=en_US.UTF-8
> >> [5] LC_MONETARY=en_US.UTF-8LC_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@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.
__
R-help@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.
Re: [R] [bug] spdep package?
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-8LC_COLLATE=en_US.UTF-8 >> [5] LC_MONETARY=en_US.UTF-8LC_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@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. __ R-help@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.
Re: [R] [bug] spdep package?
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 On Mon, Jul 23, 2018 at 12:30 PM Jeremie Juste wrote: > > > > Hello, > > > 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-8LC_COLLATE=en_US.UTF-8 > [5] LC_MONETARY=en_US.UTF-8LC_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@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. __ R-help@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.
[R] [bug] spdep package?
Hello, 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-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_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@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.
