[Rd] The install.R and R_PROFILE.R files
R-exts says Both install.R and R_PROFILE.R should be viewed as experimental; the mechanism to execute code before attaching or installing the package may change in the near future. With the other facilities available as from R 2.0.0 they should be removed if possible. Every usage of these on CRAN is unnecessary. If you want to save the image, say so in the SaveImage field in DESCRIPTION (but why not LazyLoad instead?). If you require methods, say so in Depends in DESCRIPTION. I propose that we deprecate/remove this mechanism (as it makes installation a lot convoluted than it needs to be). Does any one know of (a) A usage that requires one of these files to do something which cannot now be done more simply via fields in DESCRIPTION, or (b) A package that requires a saved image (and lazy loading is insufficient)? If so, please let us know. I am also minded to deprecate/remove the following command-line flags to INSTALL -s, --save[=ARGS] save the package source as an image file, and arrange for this file to be loaded when the package is attached; if given, ARGS are passed to R when creating the save image --no-save do not save the package source as an image file --lazyuse lazy loading --no-lazy do not use lazy loading --lazy-data use lazy loading for data --no-lazy-datado not use lazy loading for data (current default) since these have been superseded by the DESCRIPTION fields (and Windows does not support --save=ARGS). -- Brian D. Ripley, [EMAIL PROTECTED] 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] akima 0.4-5, interpp() bug = COMMON block problem
Hi, I'm currently hunting a bug in the akima library, especially in the code behind the interpp.old function (bi-variate linear interpolation). It is based on a triangulation algorithm, interpolation at a given point needs to know the triangle which contains this point, then the interpolation is a straightforward calculation based on the three vertexes. The problem is: Sometimes the triangle indices are not given back correctly, they just default to 1 leading to wrong results. The following lines can be used to visualize it using the rgl library. If the error occurs (may be architecture depending) the interpolation steepest part of the interp() surface will not be hit by the interpp() interpolation points. library(akima) library(rgl) data(akima) # data rgl.spheres(akima$x,akima$z , akima$y,0.5,color=red) rgl.bbox() # interp: akima.li - interp(akima$x, akima$y, akima$z, xo=seq(min(akima$x), max(akima$x), length = 200), yo=seq(min(akima$y), max(akima$y), length = 200)) # interp surface: rgl.surface(akima.li$x,akima.li$y,akima.li$z,color=green,alpha=c(0.5)) # interpp: akima.p - interpp(akima$x, akima$y, akima$z, runif(2000,0,25), runif(2000,0,20)) # interpp (partially wrong) points: rgl.points(akima.p$x,akima.p$z , akima.p$y,size=4,color=yellow) The errors occurs at least with R 2.1.1 on a i386 Ubuntu Breezy system. If I compile without -O2 in FFLAGS the error vanishes. Meanwhile I could track down the bug to the use of COMMON blocks in the underlying Fortran code: During the interpp() call a Fortran routine (IDLCTN called from IDBVIP) is called several times. Only during the first call a COMMON block is initialized, subsequent calls rely on the values initialized by the first call. But these values just vanish after the first call. I already have workaround: I call the initialization on every entry, this fixes the problem. === RCS file: /home/cvs/math/stat/R/akima/src/idlctn.f,v retrieving revision 1.2 diff -u -r1.2 idlctn.f --- idlctn.f19 Aug 1998 21:54:17 - 1.2 +++ idlctn.f1 Feb 2006 10:28:53 - @@ -49,7 +49,7 @@ X0 = XII Y0 = YII C PROCESSING FOR A NEW SET OF DATA POINTS - IF (NIT.NE.0) GO TO 80 +C IF (NIT.NE.0) GO TO 80 NIT = 1 C - DIVIDES THE X-Y PLANE INTO NINE RECTANGULAR SECTIONS. XMN = XD(1) I guess, using COMMON blocks is generally a bad idea when using Fortran code within R? Shall I leave it with my workaround or should I search for more details of the COMMON block misuse? Best regards Albrecht Gebhardt -- // Albrecht Gebhardt Tel.: (++43 463) 2700/3118 // Institut fuer Mathematik Fax : (++43 463) 2700/3198 // Universitaet Klagenfurtmailto:[EMAIL PROTECTED] // Universitaetsstr. 65 http://www.math.uni-klu.ac.at/~agebhard // A-9020 Klagenfurt, Austria // GPG PK: http://www.math.uni-klu.ac.at/~agebhard/agebhard.asc // GPG FP: F46F 656E E83C 9323 CE30 FF8F 9DBA D1A3 B55A 78A6 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] akima 0.4-5, interpp() bug = COMMON block problem
After reading my own question once again, I think I can answer it myself: The code had too _few_ COMMON blocks. It seems the code relied on that, that several local variables would carry their values after being initialised in the first subroutine call until the second call. This is not the case. I introduced a new COMMON block containing (at least) all these variables and this fixes it. After I have done some more checks, you should expect a new version of akima soon. Best wishes Albrecht Am Mittwoch, den 01.02.2006, 11:31 +0100 schrieb Albrecht Gebhardt: Hi, I'm currently hunting a bug in the akima package, especially in the code behind the interpp.old function (bi-variate linear interpolation). It is based on a triangulation algorithm, interpolation at a given point needs to know the triangle which contains this point, then the interpolation is a straightforward calculation based on the three vertexes. The problem is: Sometimes the triangle indices are not given back correctly, they just default to 1 leading to wrong results. The following lines can be used to visualize it using the rgl package. If the error occurs (may be architecture depending) the interpolation steepest part of the interp() surface will not be hit by the interpp() interpolation points. library(akima) library(rgl) data(akima) # data rgl.spheres(akima$x,akima$z , akima$y,0.5,color=red) rgl.bbox() # interp: akima.li - interp(akima$x, akima$y, akima$z, xo=seq(min(akima$x), max(akima$x), length = 200), yo=seq(min(akima$y), max(akima$y), length = 200)) # interp surface: rgl.surface(akima.li$x,akima.li$y,akima.li$z,color=green,alpha=c(0.5)) # interpp: akima.p - interpp(akima$x, akima$y, akima$z, runif(2000,0,25), runif(2000,0,20)) # interpp (partially wrong) points: rgl.points(akima.p$x,akima.p$z , akima.p$y,size=4,color=yellow) The errors occurs at least with R 2.1.1 on a i386 Ubuntu Breezy system. If I compile without -O2 in FFLAGS the error vanishes. Meanwhile I could track down the bug to the use of COMMON blocks in the underlying Fortran code: During the interpp() call a Fortran routine (IDLCTN called from IDBVIP) is called several times. Only during the first call a COMMON block is initialized, subsequent calls rely on the values initialized by the first call. But these values just vanish after the first call. I already have workaround: I call the initialization on every entry, this fixes the problem. === RCS file: /home/cvs/math/stat/R/akima/src/idlctn.f,v retrieving revision 1.2 diff -u -r1.2 idlctn.f --- idlctn.f19 Aug 1998 21:54:17 - 1.2 +++ idlctn.f1 Feb 2006 10:28:53 - @@ -49,7 +49,7 @@ X0 = XII Y0 = YII C PROCESSING FOR A NEW SET OF DATA POINTS - IF (NIT.NE.0) GO TO 80 +C IF (NIT.NE.0) GO TO 80 NIT = 1 C - DIVIDES THE X-Y PLANE INTO NINE RECTANGULAR SECTIONS. XMN = XD(1) I guess, using COMMON blocks is generally a bad idea when using Fortran code within R? Shall I leave it with my workaround or should I search for more details of the COMMON block misuse? Best regards Albrecht Gebhardt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- // Albrecht Gebhardt Tel.: (++43 463) 2700/3118 // Institut fuer Mathematik Fax : (++43 463) 2700/3198 // Universitaet Klagenfurtmailto:[EMAIL PROTECTED] // Universitaetsstr. 65 http://www.math.uni-klu.ac.at/~agebhard // A-9020 Klagenfurt, Austria // GPG PK: http://www.math.uni-klu.ac.at/~agebhard/agebhard.asc // GPG FP: F46F 656E E83C 9323 CE30 FF8F 9DBA D1A3 B55A 78A6 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Word boundaries and gregexpr in R 2.2.1 (PR#8547)
Should be patched in R-devel, will be available shortly [EMAIL PROTECTED] wrote: Full_Name: Stefan Th. Gries Version: 2.2.1 OS: Windows XP (Home and Professional) Submission from: (NULL) (68.6.34.104) The problem is this: I have a vector of two character strings. text-c(This is a first example sentence., And this is a second example sentence.) If I now look for word boundaries with regexpr, this is what I get: regexpr(\\b, text, perl=TRUE) [1] 1 1 attr(,match.length) [1] 0 0 So far, so good. But with gregexpr I get: gregexpr(\\b, text, perl=TRUE) Error: cannot allocate vector of size 524288 Kb In addition: Warning messages: 1: Reached total allocation of 1015Mb: see help(memory.size) 2: Reached total allocation of 1015Mb: see help(memory.size) Why don't I get the locations and extensions of all word boundaries? I am using R 2.2.1 on a machine running Windows XP: R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major2 minor2.1 year 2005 month12 day 20 svn rev 36812 language R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package introductions
I have been experimenting with different possibilities for an
introduction page for my packages. That is, a good place to tell users
about the most important things in a package, and where to start.
Recently there was a discussion about this, and a suggestion to use
foo-package.Rd, and also a function that generates a skeleton
document. My problem with this suggestion is that foo-package may not
be high in the sort order, so users will not find this unless they know
to look for it (and so there is difficulty establishing the convention).
A second problem is that the skeleton document has information that may
be useful, but is not really what I am looking for. (It has all the
methods in the package, but what I want is to tell users the most
important ones to look at first. It also has high maintenance
information, like version numbers. I want something that is either
completely automatic, or manual but low maintenance.) Another related
problem is that the information put in the skeleton foo-package.Rd
possibly should be in a man page somewhere, so if this does happen, that
naming convention will likely be used and would then conflict with my
introduction.
I now think I have found something that works fairly well. I put the
introduction in a file 00.foo.Intro.Rd and in that file have
/name{00.foo.Intro}
/alias{00.foo.Intro}
/alias{foo.Intro}
Then sorting puts the 00 version at the beginning of the table of
contents in both the pdf version with all the help pages, and in the
html version for the help.start() system. Also, ?foo.Intro works.
(?00.foo.Intro works too, but the quote marks are necessary and this
seems likely to cause problems for beginners.)
It is also helpful to put something like See ?foo.Intro for more
details in the Description: line of the DESCRIPTION file, so users
see this with help(package=foo). (I don't think users of the
help.start() system ever see this, but perhaps someone can correct me.)
I also would like to put in my vote for a DESCRIPTION file tag
GettingStarted: foo.Intro
probably as an optional tag to begin.
Of course, the biggest simplification happens when things like this are
done in a similar way by everyone. ( configure ; make is not
intuitively simple, but everyone now knows the incantation.)
Paul Gilbert
La version française suit le texte anglais.
This email message from the Bank of Canada is given in good faith, and shall
not be
binding or construed as constituting any obligation on the part of the Bank.
This email may contain privileged and/or confidential information, and the Bank
of
Canada does not waive any related rights. Any distribution, use, or copying of
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately
from
your system and notify the sender promptly by email that you have done so.
Recipients are advised to apply their own virus checks to this message upon
receipt.
L'information communiquée dans les courriels en provenance de la Banque du
Canada
est soumise de bonne foi, mais elle ne saurait lier la Banque et ne doit
aucunement
être interprétée comme constituant une obligation de sa part.
Le présent courriel peut contenir de l'information privilégiée ou
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite Si vous
recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
votre
ordinateur toute copie du courriel reçu.
Dès la réception du présent message, le ou les destinataires doivent activer
leur
programme de détection de virus pour éviter toute contamination possible.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (no subject)
Suppose X is a data.frame with n obs and k vars, all variables are factors. tab - table(X) containes a k-dim array I would like to get a list from tab. This list is such that, each element contain the indexes corresponding to the observations which are in the same cell of this k-dim array. Of course, only for non empty cell. E.g. set.seed(123) X - as.data.frame(matrix(rnorm(5000),100,5)) X$V1 - cut(X$V1, br=5) X$V2 - cut(X$V2, br=5) X$V3 - cut(X$V3, br=5) X$V4 - cut(X$V4, br=5) X$V5 - cut(X$V5, br=5) tab - table(X) which(tab0) - cells length(cells) [1] 94 thus, of course, 94 cells over 5^5 = 3125 are non empty. I would like a smart way (without reimplementing table/tabulate) to get the list of length 94 which contains the indexes of the obs in each cell Or, viceversa, a vector of length n which tells, observation by observation, which cell (out of the 3125) the observation is in. stefano __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cutting up a k-D space (no subject)
Stefano, Try this XX - as.numeric(X[[1]]) for (i in 2:length(X)) XX - 10*XX + as.numeric(X[[i]]) split(seq(along=XX), XX) You can read off the cell from the decimal expansion of the label. And XX goes from observations to cells. The hard work is done by unique() under the skin (split makes XX into a factor). Brian On Wed, 1 Feb 2006, stefano iacus wrote: Suppose X is a data.frame with n obs and k vars, all variables are factors. tab - table(X) containes a k-dim array I would like to get a list from tab. This list is such that, each element contain the indexes corresponding to the observations which are in the same cell of this k-dim array. Of course, only for non empty cell. E.g. set.seed(123) X - as.data.frame(matrix(rnorm(5000),100,5)) X$V1 - cut(X$V1, br=5) X$V2 - cut(X$V2, br=5) X$V3 - cut(X$V3, br=5) X$V4 - cut(X$V4, br=5) X$V5 - cut(X$V5, br=5) tab - table(X) which(tab0) - cells length(cells) [1] 94 thus, of course, 94 cells over 5^5 = 3125 are non empty. I would like a smart way (without reimplementing table/tabulate) to get the list of length 94 which contains the indexes of the obs in each cell Or, viceversa, a vector of length n which tells, observation by observation, which cell (out of the 3125) the observation is in. stefano __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no subject)
Apologizies, I forgot the subject. Btw, I found it stefano Il giorno 01/feb/06, alle ore 18:25, stefano iacus ha scritto: Suppose X is a data.frame with n obs and k vars, all variables are factors. tab - table(X) containes a k-dim array I would like to get a list from tab. This list is such that, each element contain the indexes corresponding to the observations which are in the same cell of this k-dim array. Of course, only for non empty cell. E.g. set.seed(123) X - as.data.frame(matrix(rnorm(5000),100,5)) X$V1 - cut(X$V1, br=5) X$V2 - cut(X$V2, br=5) X$V3 - cut(X$V3, br=5) X$V4 - cut(X$V4, br=5) X$V5 - cut(X$V5, br=5) tab - table(X) which(tab0) - cells length(cells) [1] 94 thus, of course, 94 cells over 5^5 = 3125 are non empty. I would like a smart way (without reimplementing table/tabulate) to get the list of length 94 which contains the indexes of the obs in each cell Or, viceversa, a vector of length n which tells, observation by observation, which cell (out of the 3125) the observation is in. stefano __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cutting up a k-D space (no subject)
Thanks Brian, stefano Il giorno 01/feb/06, alle ore 19:00, Prof Brian Ripley ha scritto: Stefano, Try this XX - as.numeric(X[[1]]) for (i in 2:length(X)) XX - 10*XX + as.numeric(X[[i]]) split(seq(along=XX), XX) You can read off the cell from the decimal expansion of the label. And XX goes from observations to cells. The hard work is done by unique() under the skin (split makes XX into a factor). Brian On Wed, 1 Feb 2006, stefano iacus wrote: Suppose X is a data.frame with n obs and k vars, all variables are factors. tab - table(X) containes a k-dim array I would like to get a list from tab. This list is such that, each element contain the indexes corresponding to the observations which are in the same cell of this k-dim array. Of course, only for non empty cell. E.g. set.seed(123) X - as.data.frame(matrix(rnorm(5000),100,5)) X$V1 - cut(X$V1, br=5) X$V2 - cut(X$V2, br=5) X$V3 - cut(X$V3, br=5) X$V4 - cut(X$V4, br=5) X$V5 - cut(X$V5, br=5) tab - table(X) which(tab0) - cells length(cells) [1] 94 thus, of course, 94 cells over 5^5 = 3125 are non empty. I would like a smart way (without reimplementing table/tabulate) to get the list of length 94 which contains the indexes of the obs in each cell Or, viceversa, a vector of length n which tells, observation by observation, which cell (out of the 3125) the observation is in. stefano __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The install.R and R_PROFILE.R files
On 1 Feb 2006, [EMAIL PROTECTED] wrote: Every usage of these on CRAN is unnecessary. If you want to save the image, say so in the SaveImage field in DESCRIPTION (but why not LazyLoad instead?). If you require methods, say so in Depends in DESCRIPTION. I've looked over the packages in the Bioconductor repository and I believe that every usage of R_PROFILE.R and install.R is also unnecessary. (b) A package that requires a saved image (and lazy loading is insufficient)? Many Bioc packages use SaveImage in their DESCRIPTION file. Could someone provide more detail on the difference between SaveImage and LazyLoad. It is possible that LazyLoad would do just as well. Thanks, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rd files with unknown sections
On Wed, 1 Feb 2006, Herve Pages wrote:
Hi,
With recent versions of R-devel, R CMD check complains about
some Rd files with unknown sections.
[EMAIL PROTECTED]:~ R CMD check multtest_1.9.4.tar.gz
...
...
* checking Rd files ... WARNING
Rd files with unknown sections:
/home/hpages/multtest.Rcheck/00_pkg_src/multtest/man/boot.resample.Rd:
notes
/home/hpages/multtest.Rcheck/00_pkg_src/multtest/man/MTP.Rd: notes
See chapter 'Writing R documentation files' in manual 'Writing R
Extensions'.
...
...
WARNING: There was 1 warning, see
/home/hpages/multtest.Rcheck/00check.log
for details
I've tried with other Bioconductor packages and R CMD check complains
that alias, warning, detail, etc... are unknown sections.
I get these warnings with R-devel built from a snapshot tarball
from 2006-01-23 (r37152) and 2006-01-31 (r37220).
I don't get it with R-devel tarball from 2006-01-04 (r36984).
It is new test (thanks to Kurt Hornik). Those are all incorrect, and
will result in incorrect output (or at least, not the intended output).
It is
\note
\alias (the warning I see is \alais)
\details
and there is no \warning (etc), you need \section(Warning}{...}
Previously (as Rd is not a defined format with e.g. a DTD), almost all
errors were silently ignored.
All the reports I have looked at are genuine user errors. (The same
applies to the recent subdirectory checks.)
--
Brian D. Ripley, [EMAIL PROTECTED]
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Retrieving an unevaluated argument
I'm trying to retrieve an unevalated argument (a list in particular). I can do this easily when I call the function directly: a1 - function(x) match.call()$x a1(list(y=x^2)) list(y = x^2) But when the function is called by another function, it gets trickier b - function(x, f) f(x) b(list(x^2), a1) x The best I've been able to do is: a2 - function(x) parse(text=deparse(substitute(x, parent.frame([[1]] b(list(x^2), a2) list(x^2) But I'm sure there must be a better way! Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Converting an unevaluted list to list of unevaluted elements
Thanks to Andy Liaw, I have realised my problem isn't getting an unevaluated argument, my problem really is converting an unevaluted list to list of unevaluted elements. That is, how can I go from substitute(list(a=x, b=c)) to list(a=substitute(x), b=substitute(c)) (I am also interested in a general means of getting the correct unevaluated argument. ie, what should a be to always return list(x=1) for these functions: b - function(x) a(x) c - function(x) b(x) d - function(x) c(x) a(list(x=1)) b(list(x=1)) c(list(x=1)) d(list(x=1)) ) Thanks, as always, for your help Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The install.R and R_PROFILE.R files
On Wed, 1 Feb 2006, Seth Falcon wrote:
On 1 Feb 2006, [EMAIL PROTECTED] wrote:
Every usage of these on CRAN is unnecessary. If you want to save the
image, say so in the SaveImage field in DESCRIPTION (but why not
LazyLoad instead?). If you require methods, say so in Depends in
DESCRIPTION.
I've looked over the packages in the Bioconductor repository and I
believe that every usage of R_PROFILE.R and install.R is also
unnecessary.
Thanks for that.
(b) A package that requires a saved image (and lazy loading is
insufficient)?
Many Bioc packages use SaveImage in their DESCRIPTION file.
Could someone provide more detail on the difference between SaveImage
and LazyLoad. It is possible that LazyLoad would do just as well.
When an R package is installed, a file is prepared which is the
concatenation of the (valid) files in the R directory.
With SaveImage, that file is loaded into an environment, and the
environment dumped as a all.rda file. The R code is then replaced by
a loader whose sole job is to load the all.rda file.
With LazyLoad, the R file is loaded into an environment, and the objects
in the environment are dumped individually into a simple database. The R
code is then replaced by a loader whose sole job is to create an
environment of promises to load the objects from the database.
(There is an article in R-news about lazy-loading.)
Lazy-loading is the norm for all but packages with very small amounts of R
code.
I don't know when saving an image might be needed in preference to
lazy-loading. The differences in space (and hence time) when the package
is used can be considerable, in favour of lazy-loading. Since saving the
objects in an environment and saving an environment are not quite the same
thing there are potential differences. (I have forgotten, if I ever knew,
what happens with lazy-loading when you have an object whose environment
is another namespace, for example.)
There have been packages ('aod' and 'gamlss' are two) which have both
SaveImage and LazyLoad true. That works but is wasteful.
I just looked at the 12 non-Windows CRAN packages with SaveImage: yes and
replaced this by LazyLoad: yes. All passed R CMD check after the change.
This included 'debug' and 'mvbutils' which had SaveImage: yes, LazyLoad:
no which suggests the author thought otherwise.
There is no intention to withdraw SaveImage: yes. Rather, if lazy-loading
is not doing a complete job, we could see if it could be improved.
--
Brian D. Ripley, [EMAIL PROTECTED]
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
