duncan@wald.ucdavis.edu
2004-Oct-22 18:18 UTC
[Rd] Re: library.dynam() & .dynLibs() do not work as documented (PR#7305)
--d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Prof Brian Ripley wrote:> nor in any sensible way we could document. >=20 > In R 2.0.0 (and current R-patched and R-devel): >=20 > > X11() > > library.dynam() > Filename Dynamic.Lookup > base base FALSE > stats /usr/local/lib/R/library/stats/libs/stats.so TRUE > methods /usr/local/lib/R/library/methods/libs/methods.so TRUE > R_X11 /usr/local/lib/R/modules/R_X11.so TRUE >=20 > whereas 1.9.1 gives >=20 > > library.dynam() > [1] "stats" "methods" >=20 > and the documentation says >=20 > If 'chname' is not specified, 'library.dynam' returns a character > vector with the names of packages which have used it in the > current R session to load shared libraries. This vector is > returned as 'invisible', unless the 'chname' argument is missing. >=20 > which is clearly no longer true. I don't see why we want loaded modules=20 > in there that have nothing to do with packages, or even non-modules.Before we try to simply match documentation which was written for a simpler semantic, let's think about what we actually require in the context of versioned packages and where library.dynam() is currently being used and so what is broken. Returning a character vector with the names of packages which have used it does not permit version information to be included (unless they are in the package name).=20 For quite some time, I have wanted to move to package objects=20 and to return such self-describing objects which contain all their own details such as name, version, DLL, etc. Using names, just as using numbers of graphics devices, is a global mechanism that leads to clumsy code.=20 We can make the code match the documentation, but only if we still want what the documentation states. When we introduce multiple evaluators in the future, lots of things will "challenge" the current semantics and many of them will be desirable. One of these potential changes is the use of multiple concurrent versions of a package. Comments, before we fix things?=20 D.=20>=20 > At that point .dynLibs() gave >=20 > $base > DLL name: base > Filename: base > Dynamic lookup: FALSE >=20 > $stats > DLL name: stats > Filename: /usr/local/lib/R/library/stats/libs/stats.so > Dynamic lookup: TRUE >=20 > [[3]] > [1] "methods" >=20 > which seems useless for >=20 > '.dynLibs' is used for getting or setting the packages that have > loaded shared libraries (using 'library.dynam'). >=20 > One command later and we have >=20 > > library(MASS) > > .dynLibs() > $base > DLL name: base > Filename: base > Dynamic lookup: FALSE >=20 > $stats > DLL name: stats > Filename: /usr/local/lib/R/library/stats/libs/stats.so > Dynamic lookup: TRUE >=20 > $methods > DLL name: methods > Filename: /usr/local/lib/R/library/methods/libs/methods.so > Dynamic lookup: TRUE >=20 > $R_X11 > DLL name: R_X11 > Filename: /usr/local/lib/R/modules/R_X11.so > Dynamic lookup: TRUE >=20 > [[5]] > [1] "MASS" >=20 > ! >=20 > --=20 > Brian D. Ripley, ripley@stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595--=20 Duncan Temple Lang duncan@wald.ucdavis.edu Department of Statistics work: (530) 752-4782 371 Kerr Hall fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (OSF1) iD8DBQFBeTK29p/Jzwa2QP4RAkQ6AJwO+/Rk6+yPx5GRXwn+aJuTJnY3DACfa0Ze +x+pi8+sTc006byhX2jlY5o=B3bf -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND--
Maybe Matching Threads
- library.dynam() & .dynLibs() do not work as documented (PR#7304)
- Re: library.dynam() & .dynLibs() do not work as documented
- Re: (PR#7304) library.dynam() & .dynLibs() do not work as
- Relationship between dyn.load and library.dynam
- problem loading packages (PR#559)