Re: [Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))

From: Prof Brian Ripley <ripley_at_stats.ox.ac.uk>
Date: Sun 28 Aug 2005 - 17:17:20 GMT

We've never encountered this lying mirror problem. Perhaps you (or another user of the unreliable mirror) could contribute suitable fixes.

On Sun, 28 Aug 2005, Berwin A Turlach wrote:

> G'day Brian,
>
> I am splitting my reply to your e-mail into two since there are two
> separate spinoffs.
>
>>>>>> "BDR" == Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:
>
> BDR> Check your versions of MASS. The Windows one appears to be
> BDR> an outdated version, and does different things.
> Thanks, yes, this is the problem. On my linux box, I compile things
> from source and had the latest version of MASS (7.2-19) installed
> under R 2.1.1 and R 2.2.0.
>
> Since I hardly ever work under Windows, I rely for my Windows box on
> the precompiled versions provided from CRAN and do not compile R or
> packages from source. (Though I have it set up so that I can compile
> my own packages.) Actually, I only installed R 2.1.1 on that machine
> (which has an AMD processor) yesterday and it was using MASS version
> 7.2-16. Running `update.packages' today, updated MASS to version
> 7.2-18. And, lo and behold, there are no more warning messages, even
> more, running the example in `fitdistr' now returns:
>
>> set.seed(123)
>> x <- rgamma(100, shape = 5, rate = 0.1)
>> fitdistr(x, "gamma")
> shape rate
> 6.45947303 0.13593172
> (0.89052006) (0.01948648)
>> ## now do this directly with more control.
>> fitdistr(x, dgamma, list(shape = 1, rate = 0.1), lower = 0.01)
> shape rate
> 6.48714685 0.13651706
> (0.89442924) (0.01956916)
>
> So it was perhaps lucky that I did not run update.packages yesterday,
> since I would have expected that (like PR#1717) my bug report would be
> filed under not-reproducible. :-)
>
> But this made me curious, and I fired my laptop (which has an Intel
> chip) up under Windows (usually it runs under Linux) and installed R
> 2.1.1 on it. On that Windows machine, I get the same answers as those
> reported yesterday under both MASS 7.2-16 and 7.2-18. Thus, I am a
> bit baffled. Well, I just went back to the AMD box and re-run the
> code, now it gives me again the "nonsense" answer in the second case.
> There is definitely something wrong in the L-BFGS-B routine, which
> will be hard to find.
>
> Regarding the changed subject line:
>
> After installing R 2.1.1 on my laptop, I executed an R source file
> which, essentially, only contains an install.packages command with the
> list of contributed packages that I like to have installed. One of
> this packages is DAAG and it seems that overnight the file
> DAAG_0.58.zip disappeared from
> http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/
> so the install.packages command terminated with an error message that
> the source file could not be downloaded.
>
> Would it be possible to robustify the install.packages command such
> that it continues with installing all the other packages requested
> instead of terminating?
>
> After redirecting R 2.1.1 on my laptop to use
>
http://cran.au.r-project.org/
> for the CRAN repository, the install.packages() command ran without
> problems. I issued the command `library(MASS)' and tried out the
> example from fitdistr on that machine (same strange result for second
> command and warning messages were issued). So I said
> update.packages() and that command failed when it wanted to update
> the MASS package. So I detach()'ed MASS and re-ran update.packages()
> and again it failed. So I exited R 2.1.1 and restarted it again
> (probably I should have unloaded the namespace of MASS??) and then the
> update.packages command worked.

Yes, and that *is* in the rw-FAQ.

> However, update.packages() wanted to update quite a few packages
> besides MASS (the other packages in the VR bundle, nlme, lattice &c).
> Once it failed on MASS, it terminated with an error and did not update
> any of the other packages. Would it be possible to robustify
> update.packages behaviour such that it would continue in such
> situations with updating the remaining packages?

Not a good idea. Better to follow the FAQ. At that point the dependencies have been worked out and will not be re-computed if a package installation fails.

-- 
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

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Mon Aug 29 03:21:58 2005

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:19 GMT