jarioksa@sun3.oulu.fi
2005-May-04 09:51 UTC
[Rd] MacOS X: update.packages(type="mac.binary") fails (PR#7836)
Message 2 of today: it works now. After re-installing R.app from the same R-2.1.0.dmg file, and fixInNamespace'ing(*) install.packages(), I managed to update 23 outdated packages from CRAN binaries for MacOS X. What I did was to: 1. change call to .install.macbinaries() into call to install.binaries() in install.packages(). install.binaries() is a function defined utils/R/aqua/GUI.R. 2. I also had to remove argument 'dependencies' since that is not defined in install.binaries() of utils/aqua. It seems that install.binaries of utils/aqua is mentioned in several places in R sources, but .install.macbinary() appears only in one place, so changing install.packages() is less hassle than changing utils/R/aqua/GUI.R and all other places (although this looks more natural). This still requires a fix in passing type in update.packages() that B. Ripley already did for R 2.1.1, or setting options(pkgType="mac.binary"). cheers, jari oksanen (*) "Object-oriented programming is an exceptionally bad idea which could only have originated in California." E. Dijkstra On Tue, 2005-05-03 at 16:14 +0100, Prof Brian Ripley wrote:> Binary installs are AFAIK only supported in the GUI, where the default is > as documented. So .install.macbinary() is not loaded except in the GUI. > > The reason is that those binaries are tied to that particular build of R, > and will not work with a general build on MacOS X. > > I would expect this to work from the command-line in the GUI console, and > had believed it had been tested there. > > > On Tue, 3 May 2005 jari.oksanen@oulu.fi wrote: > > > Full_Name: Jari Oksanen > > Version: R 2.1.0 > > OS: MacOS 10.3.9 > > Submission from: (NULL) (130.231.102.145) > > > > > > For various reasons (which need not be expanded here) I have tried to update my > > long neglected R in MacOS X using handy command line tool update.packages() > > using readily available binaries of contributed packages at CRAN. However, this > > fails with message saying that packages xxxx_*_tar.gz is not found at the server > > (HTTP error 404). Obviously, the package name is expanded wrongly as the binary > > packages for MacOS X have type *.tgz. However, this seems not be the problem, > > but there are two other problems: > > > > 1. update.packages does not transfer the value of 'type' to the next function > > install.packages, but install.packages uses the value of getOption("pkgType") > > which seems to be "source" in CRAN binary of MacOS X (contrary to documentation > > at ?options). > > > > 2. If this is corrected, or first set options(pkgType="mac.binary"), the update > > fails for missing function .install.macbinary(). > > > > The first problem is easy to correct: > > > > --- update.packages.R 2005-05-03 17:13:36.000000000 +0300 > > +++ jarioksa.update.packages.R 2005-05-03 17:13:58.000000000 +0300 > > @@ -59,5 +59,5 @@ > > install.packages(update[, "Package"], instlib, contriburl > > contriburl, > > method = method, available = available, destdir = destdir, > > - installWithVers = installWithVers, type) > > + installWithVers = installWithVers, type = type) > > } > > } > > > > > > For the second, problem, I don't know what to do. grepping > > R-patched_2005-05-03.tar.gz source found only one instance of > > .install.macbinary(): the failed call in > > R-patched/src/library/utils/R/packages2.R. I couldn't find the definition of the > > function. > > > > Do I really have to use GUI? Uh. > > > > cheers, jari oksanen > > > > ______________________________________________ > > R-devel@stat.math.ethz.ch mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > >
Prof Brian Ripley
2005-May-04 10:01 UTC
[Rd] MacOS X: update.packages(type="mac.binary") fails (PR#7836)
On Wed, 4 May 2005 jarioksa@sun3.oulu.fi wrote:> Message 2 of today: it works now. > > After re-installing R.app from the same R-2.1.0.dmg file, and > fixInNamespace'ing(*) install.packages(), I managed to update 23 > outdated packages from CRAN binaries for MacOS X. What I did was to: > > 1. change call to .install.macbinaries() into call to install.binaries() > in install.packages(). install.binaries() is a function defined > utils/R/aqua/GUI.R. > 2. I also had to remove argument 'dependencies' since that is not > defined in install.binaries() of utils/aqua.The point is that the omitted .install.macbinaries() does support dependencies and has several other improvements over install.binaries().> It seems that install.binaries of utils/aqua is mentioned in several > places in R sources, but .install.macbinary() appears only in one place, > so changing install.packages() is less hassle than changing > utils/R/aqua/GUI.R and all other places (although this looks more > natural). > > This still requires a fix in passing type in update.packages() that B. > Ripley already did for R 2.1.1, or setting > options(pkgType="mac.binary").This should not be required. What does .Platform say?> cheers, jari oksanen > > (*) "Object-oriented programming is an exceptionally bad idea which > could only have originated in California." E. Dijkstra > > On Tue, 2005-05-03 at 16:14 +0100, Prof Brian Ripley wrote: >> Binary installs are AFAIK only supported in the GUI, where the default is >> as documented. So .install.macbinary() is not loaded except in the GUI. >> >> The reason is that those binaries are tied to that particular build of R, >> and will not work with a general build on MacOS X. >> >> I would expect this to work from the command-line in the GUI console, and >> had believed it had been tested there. >> >> >> On Tue, 3 May 2005 jari.oksanen@oulu.fi wrote: >> >>> Full_Name: Jari Oksanen >>> Version: R 2.1.0 >>> OS: MacOS 10.3.9 >>> Submission from: (NULL) (130.231.102.145) >>> >>> >>> For various reasons (which need not be expanded here) I have tried to update my >>> long neglected R in MacOS X using handy command line tool update.packages() >>> using readily available binaries of contributed packages at CRAN. However, this >>> fails with message saying that packages xxxx_*_tar.gz is not found at the server >>> (HTTP error 404). Obviously, the package name is expanded wrongly as the binary >>> packages for MacOS X have type *.tgz. However, this seems not be the problem, >>> but there are two other problems: >>> >>> 1. update.packages does not transfer the value of 'type' to the next function >>> install.packages, but install.packages uses the value of getOption("pkgType") >>> which seems to be "source" in CRAN binary of MacOS X (contrary to documentation >>> at ?options). >>> >>> 2. If this is corrected, or first set options(pkgType="mac.binary"), the update >>> fails for missing function .install.macbinary(). >>> >>> The first problem is easy to correct: >>> >>> --- update.packages.R 2005-05-03 17:13:36.000000000 +0300 >>> +++ jarioksa.update.packages.R 2005-05-03 17:13:58.000000000 +0300 >>> @@ -59,5 +59,5 @@ >>> install.packages(update[, "Package"], instlib, contriburl >>> contriburl, >>> method = method, available = available, destdir = destdir, >>> - installWithVers = installWithVers, type) >>> + installWithVers = installWithVers, type = type) >>> } >>> } >>> >>> >>> For the second, problem, I don't know what to do. grepping >>> R-patched_2005-05-03.tar.gz source found only one instance of >>> .install.macbinary(): the failed call in >>> R-patched/src/library/utils/R/packages2.R. I couldn't find the definition of the >>> function. >>> >>> Do I really have to use GUI? Uh. >>> >>> cheers, jari oksanen >>> >>> ______________________________________________ >>> R-devel@stat.math.ethz.ch mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> >> > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > >-- 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