Search
Question: Library installation: odd error
0
7.3 years ago by
Michael Bauer50 wrote:
I am a system administrator at a site with several R users. In response to a previous set of questions, we were encouraged to have individual users set up R library directories in their home directories and use the R environment variables to direct R to put auto-installed libraries there. However, we've run across one consistent problem: the library that prompted this whole string will not install on Linux. (It installs just fine in R on Windows.) When presented with a writable library directory to install into, it the installation invariably fails with the error: Error in ret[i, ] <- c(pkgs[i], lib, desc) : number of items to replace is not a multiple of replacement length Two examples: if a user loads data into R (on Linux) that requires a library not currently available, then tries to analyze it, the following happens: > library(affy) Loading required package: Biobase Welcome to Bioconductor Vignettes contain introductory material. To view, type 'openVignette()'. To cite Bioconductor, see 'citation("Biobase")' and for packages 'citation(pkgname)'. > test.mas5calls = mas5calls(CelData) Getting probe level data... Error in ret[i, ] <- c(pkgs[i], lib, desc) : number of items to replace is not a multiple of replacement length We've successfully had the library install on Windows, so I have the name of the library itself: hgu133plus2cdf. When I try to install the library directly, by hand, in Linux, I get the same error: > source("http://bioconductor.org/biocLite.R") BioC_mirror = http://bioconductor.org Change using chooseBioCmirror(). > biocLite("hgu133plus2cdf") Using R version 2.13.0, biocinstall version 2.8.4. Installing Bioconductor version 2.8 packages: [1] "hgu133plus2cdf" Please wait... Installing package(s) into '/h/mjbauer/Rlibs' (as 'lib' is unspecified) Error in ret[i, ] <- c(pkgs[i], lib, desc) : number of items to replace is not a multiple of replacement length > In both cases, the directory the library is trying to install into is writable. If we instead try to install the library into a non- writable directory, the error changes to: > source("http://bioconductor.org/biocLite.R") BioC_mirror = http://bioconductor.org Change using chooseBioCmirror(). > biocLite("hgu133plus2cdf") Using R version 2.13.0, biocinstall version 2.8.4. Installing Bioconductor version 2.8 packages: [1] "hgu133plus2cdf" Please wait... Installing package(s) into '/usr/lib64/R/library' (as 'lib' is unspecified) Warning in install.packages(pkgs = pkgs, repos = repos, ...) : 'lib = "/usr/lib64/R/library"' is not writable Would you like to create a personal library '~/R/x86_64-redhat-linux-gnu-library/2.13' to install packages into? (y/n) y Error in ret[i, ] <- c(pkgs[i], lib, desc) : number of items to replace is not a multiple of replacement length > Everything I can find on the text of the error itself suggests that there is a coding error of some sort involved. This is an attempt at installing a library on Linux that successfully installs on R on Windows, so presumably there's no coding error of the sort involved. Can anyone shed light on what might be going on here? My first thought is that the hgu133plus2cdf is somehow Windows only, as the version of R (2.13) and Bioconductor (2.8) are the same on both systems. Thanks, MJB
modified 7.3 years ago by Steve Lianoglou12k • written 7.3 years ago by Michael Bauer50
0
7.3 years ago by
Denali
Steve Lianoglou12k wrote:
Hi Michael, On Tue, Jul 12, 2011 at 3:47 PM, Michael Bauer <mjbauer at="" eecs.tufts.edu=""> wrote: > I am a system administrator at a site with several R users. ?In response to > a previous set of questions, we were encouraged to have individual users set > up R library directories in their home directories and use the R environment > variables to direct R to put auto-installed libraries there. > > However, we've run across one consistent problem: the library that prompted > this whole string will not install on Linux. ?(It installs just fine in R on > Windows.) ?When presented with a writable library directory to install into, > it the installation invariably fails with the error: > > Error in ret[i, ] <- c(pkgs[i], lib, desc) : > ?number of items to replace is not a multiple of replacement length I'll cut here. This has happened to me recently. Any time I tried to install *anything* I would get this error. So, first question: is it only when you try to install a particular package that this happens, or are all package-installs now hosed? I'm going to assume that all package installs are not working. This error was happening to me because there is a package that is *already* installed in the system which is "corrupt". I had installed a library that "hand crafted" its own installation, and I guess the meta-data that R requires a package to have has changed over time causing this custom-installed-package to trip things up. The details of my situation and how I fixed it are here: http://thread.gmane.org/gmane.comp.ai.machine-learning.shogun/2020 The details of your problem are likely different -- but maybe this will help you find the offending package (if one exists)? Is there some package that was installed in a non-traditional manner? If you compare the output of installed.packages()[*] between your linux and windows install, you can find which packages are installed on the linux machine and not the windows machine that might be causing these problems. HTH, -steve [*] you probably want to use installed.packages()[,1] since the object returned from the function call is a matrix. -- Steve Lianoglou Graduate Student: Computational Systems Biology ?| Memorial Sloan-Kettering Cancer Center ?| Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact
On 7/12/2011 4:06 PM, Steve Lianoglou wrote: > Hi Michael, > > On Tue, Jul 12, 2011 at 3:47 PM, Michael Bauer<mjbauer at="" eecs.tufts.edu=""> wrote: >> I am a system administrator at a site with several R users. In response to >> a previous set of questions, we were encouraged to have individual users set >> up R library directories in their home directories and use the R environment >> variables to direct R to put auto-installed libraries there. >> >> However, we've run across one consistent problem: the library that prompted >> this whole string will not install on Linux. (It installs just fine in R on >> Windows.) When presented with a writable library directory to install into, >> it the installation invariably fails with the error: >> >> Error in ret[i, ]<- c(pkgs[i], lib, desc) : >> number of items to replace is not a multiple of replacement length > I'll cut here. > > This has happened to me recently. Any time I tried to install > *anything* I would get this error. > > So, first question: is it only when you try to install a particular > package that this happens, or are all package-installs now hosed? > > I'm going to assume that all package installs are not working. > > This error was happening to me because there is a package that is > *already* installed in the system which is "corrupt". I had installed > a library that "hand crafted" its own installation, and I guess the > meta-data that R requires a package to have has changed over time > causing this custom-installed-package to trip things up. > > The details of my situation and how I fixed it are here: > http://thread.gmane.org/gmane.comp.ai.machine-learning.shogun/2020 > > The details of your problem are likely different -- but maybe this > will help you find the offending package (if one exists)? > > Is there some package that was installed in a non-traditional manner? > > If you compare the output of installed.packages()[*] between your > linux and windows install, you can find which packages are installed > on the linux machine and not the windows machine that might be causing > these problems. > > HTH, > > -steve > > [*] you probably want to use installed.packages()[,1] since the > object returned from the function call is a matrix. So far as I know, I'm the only one who would have altered our system-wide installation of R, and I've followed installation instructions on each occasion. I'll check out the one that caused you havoc (sg) as we also have that one installed, but the datestamp on it is from 2009, and we've successfully installed quite a bit since then. That datestamp, on the other hand, makes me suspect that several of our R libraries are significantly out of date. As a simple check, I'm building R from scratch in an alternate directory and will see if it can handle installs. One question: is there any R configuration directory that I should be looking in for environment changes, or is everything handled through environment variables in the appropriate shell configuration? MJB
On Tue, Jul 12, 2011 at 6:21 PM, Michael Bauer <mjbauer at="" eecs.tufts.edu=""> wrote: > On 7/12/2011 4:06 PM, Steve Lianoglou wrote: >> >> Hi Michael, >> >> On Tue, Jul 12, 2011 at 3:47 PM, Michael Bauer<mjbauer at="" eecs.tufts.edu=""> >> ?wrote: >>> >>> I am a system administrator at a site with several R users. ?In response >>> to >>> a previous set of questions, we were encouraged to have individual users >>> set >>> up R library directories in their home directories and use the R >>> environment >>> variables to direct R to put auto-installed libraries there. >>> >>> However, we've run across one consistent problem: the library that >>> prompted >>> this whole string will not install on Linux. ?(It installs just fine in R >>> on >>> Windows.) ?When presented with a writable library directory to install >>> into, >>> it the installation invariably fails with the error: >>> >>> Error in ret[i, ]<- c(pkgs[i], lib, desc) : >>> ?number of items to replace is not a multiple of replacement length >> >> I'll cut here. >> >> This has happened to me recently. Any time I tried to install >> *anything* I would get this error. >> >> So, first question: is it only when you try to install a particular >> package that this happens, or are all package-installs now hosed? >> >> I'm going to assume that all package installs are not working. >> >> This error was happening to me because there is a package that is >> *already* installed in the system which is "corrupt". I had installed >> a library that "hand crafted" its own installation, and I guess the >> meta-data that R requires a package to have has changed over time >> causing this custom-installed-package to trip things up. >> >> The details of my situation and how I fixed it are here: >> http://thread.gmane.org/gmane.comp.ai.machine-learning.shogun/2020 >> >> The details of your problem are likely different -- but maybe this >> will help you find the offending package (if one exists)? >> >> Is there some package that was installed in a non-traditional manner? >> >> If you compare the output of installed.packages()[*] between your >> linux and windows install, you can find which packages are installed >> on the linux machine and not the windows machine that might be causing >> these problems. >> >> HTH, >> >> -steve >> >> [*] you probably want to use installed.packages()[,1] since the >> object returned from the function call is a matrix. > > So far as I know, I'm the only one who would have altered our system-wide > installation of R, and I've followed installation instructions on each > occasion. ?I'll check out the one that caused you havoc (sg) as we also have > that one installed, but the datestamp on it is from 2009, and we've > successfully installed quite a bit since then. Heh .. that's pretty funny. I wonder if it's too late for me to go out and buy a lotto ticket tonight ... > That datestamp, on the other hand, makes me suspect that several of our R > libraries are significantly out of date. ?As a simple check, I'm building R > from scratch in an alternate directory and will see if it can handle > installs. Dollars to donuts it will. > One question: is there any R configuration directory that I should be > looking in for environment changes, or is everything handled through > environment variables in the appropriate shell configuration? The R shell script should handle most of that, so I guess you can peak through that to see what it's doing. Also, each user can have an .Rprofile file in their home directory (~/.Rprofile) that R will normally load so that the user can tweak his/her R environment as they please. Something else regarding what you mentioned about old timestamps on many of your libraries: that seems like a bad thing in general, especially since (if I remember correctly) you said you're running the latest version of R (2.13.x). R libraries that were build for one version of R shouldn't be copied over and used in new R versions. If I were you, and was looking for a quick fix, I'd: (1) move that sg package out of the way for now, ie. move the sg directory outside of your R's library directory (you can fix it later using the info from that posting to that shogun list I sent previously, once everything is back to normal). (2) Try to install a random package to make sure that the sg package was the one causing the problem. glmnet is always handy to have: R> install.packages('glmnet') It actually requires a FORTRAN compiler, so if that gives you problems, maybe you can try plyr R> install.packages('plyr') (3) Assuming (2) worked, now update your installed packages from within R as described on the bioconductor install page (http://www.bioconductor.org/install/) -- perhaps using the nuclear option: R> source("http://bioconductor.org/biocLite.R") R> pkgs <- rownames(installed.packages()) R> biocLite(pkgs) Although I'm pretty sure the option listed before that on that install page would work all the same ... -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology ?| Memorial Sloan-Kettering Cancer Center ?| Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact
On 7/12/2011 9:05 PM, Steve Lianoglou wrote: > On Tue, Jul 12, 2011 at 6:21 PM, Michael Bauer<mjbauer at="" eecs.tufts.edu=""> wrote: >> On 7/12/2011 4:06 PM, Steve Lianoglou wrote: >>> Hi Michael, >>> >>> On Tue, Jul 12, 2011 at 3:47 PM, Michael Bauer<mjbauer at="" eecs.tufts.edu=""> >>> wrote: >>>> I am a system administrator at a site with several R users. In response >>>> to >>>> a previous set of questions, we were encouraged to have individual users >>>> set >>>> up R library directories in their home directories and use the R >>>> environment >>>> variables to direct R to put auto-installed libraries there. >>>> >>>> However, we've run across one consistent problem: the library that >>>> prompted >>>> this whole string will not install on Linux. (It installs just fine in R >>>> on >>>> Windows.) When presented with a writable library directory to install >>>> into, >>>> it the installation invariably fails with the error: >>>> >>>> Error in ret[i, ]<- c(pkgs[i], lib, desc) : >>>> number of items to replace is not a multiple of replacement length >>> I'll cut here. >>> >>> This has happened to me recently. Any time I tried to install >>> *anything* I would get this error. >>> >>> So, first question: is it only when you try to install a particular >>> package that this happens, or are all package-installs now hosed? >>> >>> I'm going to assume that all package installs are not working. >>> >>> This error was happening to me because there is a package that is >>> *already* installed in the system which is "corrupt". I had installed >>> a library that "hand crafted" its own installation, and I guess the >>> meta-data that R requires a package to have has changed over time >>> causing this custom-installed-package to trip things up. >>> >>> The details of my situation and how I fixed it are here: >>> http://thread.gmane.org/gmane.comp.ai.machine-learning.shogun/2020 >>> >>> The details of your problem are likely different -- but maybe this >>> will help you find the offending package (if one exists)? >>> >>> Is there some package that was installed in a non-traditional manner? >>> >>> If you compare the output of installed.packages()[*] between your >>> linux and windows install, you can find which packages are installed >>> on the linux machine and not the windows machine that might be causing >>> these problems. >>> >>> HTH, >>> >>> -steve >>> >>> [*] you probably want to use installed.packages()[,1] since the >>> object returned from the function call is a matrix. >> So far as I know, I'm the only one who would have altered our system-wide >> installation of R, and I've followed installation instructions on each >> occasion. I'll check out the one that caused you havoc (sg) as we also have >> that one installed, but the datestamp on it is from 2009, and we've >> successfully installed quite a bit since then. > Heh .. that's pretty funny. I wonder if it's too late for me to go out > and buy a lotto ticket tonight ... > >> That datestamp, on the other hand, makes me suspect that several of our R >> libraries are significantly out of date. As a simple check, I'm building R >> from scratch in an alternate directory and will see if it can handle >> installs. > Dollars to donuts it will. > >> One question: is there any R configuration directory that I should be >> looking in for environment changes, or is everything handled through >> environment variables in the appropriate shell configuration? > The R shell script should handle most of that, so I guess you can peak > through that to see what it's doing. > > Also, each user can have an .Rprofile file in their home directory > (~/.Rprofile) that R will normally load so that the user can tweak > his/her R environment as they please. > > Something else regarding what you mentioned about old timestamps on > many of your libraries: that seems like a bad thing in general, > especially since (if I remember correctly) you said you're running the > latest version of R (2.13.x). > > R libraries that were build for one version of R shouldn't be copied > over and used in new R versions. > > If I were you, and was looking for a quick fix, I'd: > > (1) move that sg package out of the way for now, ie. move the sg > directory outside of your R's library directory (you can fix it later > using the info from that posting to that shogun list I sent > previously, once everything is back to normal). > > (2) Try to install a random package to make sure that the sg package > was the one causing the problem. glmnet is always handy to have: > > R> install.packages('glmnet') > > It actually requires a FORTRAN compiler, so if that gives you > problems, maybe you can try plyr > > R> install.packages('plyr') > > (3) Assuming (2) worked, now update your installed packages from > within R as described on the bioconductor install page > (http://www.bioconductor.org/install/) -- perhaps using the nuclear > option: > > R> source("http://bioconductor.org/biocLite.R") > R> pkgs<- rownames(installed.packages()) > R> biocLite(pkgs) > > Although I'm pretty sure the option listed before that on that install > page would work all the same ... > > -steve > As it turns out, yes, the old libraries were the obstruction. The new R I built worked fine until I added either one of the old library directories to R_LIBS. So now I have the joy of ripping out all the existing R libraries and replacing them with ones that people still want system-wide -- fortunately a far smaller set. Thanks for the help! MJB
Hi Michael, On 7/15/2011 11:58 AM, Michael Bauer wrote: > On 7/12/2011 9:05 PM, Steve Lianoglou wrote: >> On Tue, Jul 12, 2011 at 6:21 PM, Michael Bauer<mjbauer at="" eecs.tufts.edu=""> >> wrote: >>> On 7/12/2011 4:06 PM, Steve Lianoglou wrote: >>>> Hi Michael, >>>> >>>> On Tue, Jul 12, 2011 at 3:47 PM, Michael Bauer<mjbauer at="" eecs.tufts.edu=""> >>>> wrote: >>>>> I am a system administrator at a site with several R users. In >>>>> response >>>>> to >>>>> a previous set of questions, we were encouraged to have individual >>>>> users >>>>> set >>>>> up R library directories in their home directories and use the R >>>>> environment >>>>> variables to direct R to put auto-installed libraries there. >>>>> >>>>> However, we've run across one consistent problem: the library that >>>>> prompted >>>>> this whole string will not install on Linux. (It installs just fine >>>>> in R >>>>> on >>>>> Windows.) When presented with a writable library directory to install >>>>> into, >>>>> it the installation invariably fails with the error: >>>>> >>>>> Error in ret[i, ]<- c(pkgs[i], lib, desc) : >>>>> number of items to replace is not a multiple of replacement length >>>> I'll cut here. >>>> >>>> This has happened to me recently. Any time I tried to install >>>> *anything* I would get this error. >>>> >>>> So, first question: is it only when you try to install a particular >>>> package that this happens, or are all package-installs now hosed? >>>> >>>> I'm going to assume that all package installs are not working. >>>> >>>> This error was happening to me because there is a package that is >>>> *already* installed in the system which is "corrupt". I had installed >>>> a library that "hand crafted" its own installation, and I guess the >>>> meta-data that R requires a package to have has changed over time >>>> causing this custom-installed-package to trip things up. >>>> >>>> The details of my situation and how I fixed it are here: >>>> http://thread.gmane.org/gmane.comp.ai.machine- learning.shogun/2020 >>>> >>>> The details of your problem are likely different -- but maybe this >>>> will help you find the offending package (if one exists)? >>>> >>>> Is there some package that was installed in a non-traditional manner? >>>> >>>> If you compare the output of installed.packages()[*] between your >>>> linux and windows install, you can find which packages are installed >>>> on the linux machine and not the windows machine that might be causing >>>> these problems. >>>> >>>> HTH, >>>> >>>> -steve >>>> >>>> [*] you probably want to use installed.packages()[,1] since the >>>> object returned from the function call is a matrix. >>> So far as I know, I'm the only one who would have altered our >>> system-wide >>> installation of R, and I've followed installation instructions on each >>> occasion. I'll check out the one that caused you havoc (sg) as we >>> also have >>> that one installed, but the datestamp on it is from 2009, and we've >>> successfully installed quite a bit since then. >> Heh .. that's pretty funny. I wonder if it's too late for me to go out >> and buy a lotto ticket tonight ... >> >>> That datestamp, on the other hand, makes me suspect that several of >>> our R >>> libraries are significantly out of date. As a simple check, I'm >>> building R >>> from scratch in an alternate directory and will see if it can handle >>> installs. >> Dollars to donuts it will. >> >>> One question: is there any R configuration directory that I should be >>> looking in for environment changes, or is everything handled through >>> environment variables in the appropriate shell configuration? >> The R shell script should handle most of that, so I guess you can peak >> through that to see what it's doing. >> >> Also, each user can have an .Rprofile file in their home directory >> (~/.Rprofile) that R will normally load so that the user can tweak >> his/her R environment as they please. >> >> Something else regarding what you mentioned about old timestamps on >> many of your libraries: that seems like a bad thing in general, >> especially since (if I remember correctly) you said you're running the >> latest version of R (2.13.x). >> >> R libraries that were build for one version of R shouldn't be copied >> over and used in new R versions. >> >> If I were you, and was looking for a quick fix, I'd: >> >> (1) move that sg package out of the way for now, ie. move the sg >> directory outside of your R's library directory (you can fix it later >> using the info from that posting to that shogun list I sent >> previously, once everything is back to normal). >> >> (2) Try to install a random package to make sure that the sg package >> was the one causing the problem. glmnet is always handy to have: >> >> R> install.packages('glmnet') >> >> It actually requires a FORTRAN compiler, so if that gives you >> problems, maybe you can try plyr >> >> R> install.packages('plyr') >> >> (3) Assuming (2) worked, now update your installed packages from >> within R as described on the bioconductor install page >> (http://www.bioconductor.org/install/) -- perhaps using the nuclear >> option: >> >> R> source("http://bioconductor.org/biocLite.R") >> R> pkgs<- rownames(installed.packages()) >> R> biocLite(pkgs) >> >> Although I'm pretty sure the option listed before that on that install >> page would work all the same ... >> >> -steve >> > > As it turns out, yes, the old libraries were the obstruction. The new R > I built worked fine until I added either one of the old library > directories to R_LIBS. So now I have the joy of ripping out all the > existing R libraries and replacing them with ones that people still want > system-wide -- fortunately a far smaller set. It sounds like you are updating R and then just copying things into the new R's library directory. This will always end in tears unless you ensure that the packages all get updated (R and especially BioC have a tightly linked version structure, so you don't want to mix'n'match). You will have to download packages to update, so moving things isn't usually worth it. If you just want to recreate what you had after a new R install, you can fire up the old version and do dput(row.names(installed.packages(priority = "NA"))) Then copy that character vector and go to the new version and do source("http://www.bioconductor.org/biocLite.R") biocLite(paste_the_vector_here) alternatively, you could move the library directory over, then source("http://www.bioconductor.org/biocLite.R") biocLite("Biobase") library(Biobase) z <- biocReposList() update.packages(repos = z, ask = FALSE) Best, Jim > > Thanks for the help! > > MJB > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor -- James W. MacDonald, M.S. Biostatistician Douglas Lab University of Michigan Department of Human Genetics 5912 Buhl 1241 E. Catherine St. Ann Arbor MI 48109-5618 734-615-7826 ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
On 7/15/2011 2:47 PM, James W. MacDonald wrote: > Hi Michael, > > On 7/15/2011 11:58 AM, Michael Bauer wrote: >> On 7/12/2011 9:05 PM, Steve Lianoglou wrote: >>> On Tue, Jul 12, 2011 at 6:21 PM, Michael Bauer<mjbauer at="" eecs.tufts.edu=""> >>> wrote: >>>> On 7/12/2011 4:06 PM, Steve Lianoglou wrote: >>>>> Hi Michael, >>>>> >>>>> On Tue, Jul 12, 2011 at 3:47 PM, Michael >>>>> Bauer<mjbauer at="" eecs.tufts.edu=""> >>>>> wrote: >>>>>> I am a system administrator at a site with several R users. In >>>>>> response >>>>>> to >>>>>> a previous set of questions, we were encouraged to have individual >>>>>> users >>>>>> set >>>>>> up R library directories in their home directories and use the R >>>>>> environment >>>>>> variables to direct R to put auto-installed libraries there. >>>>>> >>>>>> However, we've run across one consistent problem: the library that >>>>>> prompted >>>>>> this whole string will not install on Linux. (It installs just fine >>>>>> in R >>>>>> on >>>>>> Windows.) When presented with a writable library directory to >>>>>> install >>>>>> into, >>>>>> it the installation invariably fails with the error: >>>>>> >>>>>> Error in ret[i, ]<- c(pkgs[i], lib, desc) : >>>>>> number of items to replace is not a multiple of replacement length >>>>> I'll cut here. >>>>> >>>>> This has happened to me recently. Any time I tried to install >>>>> *anything* I would get this error. >>>>> >>>>> So, first question: is it only when you try to install a particular >>>>> package that this happens, or are all package-installs now hosed? >>>>> >>>>> I'm going to assume that all package installs are not working. >>>>> >>>>> This error was happening to me because there is a package that is >>>>> *already* installed in the system which is "corrupt". I had installed >>>>> a library that "hand crafted" its own installation, and I guess the >>>>> meta-data that R requires a package to have has changed over time >>>>> causing this custom-installed-package to trip things up. >>>>> >>>>> The details of my situation and how I fixed it are here: >>>>> http://thread.gmane.org/gmane.comp.ai.machine- learning.shogun/2020 >>>>> >>>>> The details of your problem are likely different -- but maybe this >>>>> will help you find the offending package (if one exists)? >>>>> >>>>> Is there some package that was installed in a non-traditional manner? >>>>> >>>>> If you compare the output of installed.packages()[*] between your >>>>> linux and windows install, you can find which packages are installed >>>>> on the linux machine and not the windows machine that might be >>>>> causing >>>>> these problems. >>>>> >>>>> HTH, >>>>> >>>>> -steve >>>>> >>>>> [*] you probably want to use installed.packages()[,1] since the >>>>> object returned from the function call is a matrix. >>>> So far as I know, I'm the only one who would have altered our >>>> system-wide >>>> installation of R, and I've followed installation instructions on each >>>> occasion. I'll check out the one that caused you havoc (sg) as we >>>> also have >>>> that one installed, but the datestamp on it is from 2009, and we've >>>> successfully installed quite a bit since then. >>> Heh .. that's pretty funny. I wonder if it's too late for me to go out >>> and buy a lotto ticket tonight ... >>> >>>> That datestamp, on the other hand, makes me suspect that several of >>>> our R >>>> libraries are significantly out of date. As a simple check, I'm >>>> building R >>>> from scratch in an alternate directory and will see if it can handle >>>> installs. >>> Dollars to donuts it will. >>> >>>> One question: is there any R configuration directory that I should be >>>> looking in for environment changes, or is everything handled through >>>> environment variables in the appropriate shell configuration? >>> The R shell script should handle most of that, so I guess you can peak >>> through that to see what it's doing. >>> >>> Also, each user can have an .Rprofile file in their home directory >>> (~/.Rprofile) that R will normally load so that the user can tweak >>> his/her R environment as they please. >>> >>> Something else regarding what you mentioned about old timestamps on >>> many of your libraries: that seems like a bad thing in general, >>> especially since (if I remember correctly) you said you're running the >>> latest version of R (2.13.x). >>> >>> R libraries that were build for one version of R shouldn't be copied >>> over and used in new R versions. >>> >>> If I were you, and was looking for a quick fix, I'd: >>> >>> (1) move that sg package out of the way for now, ie. move the sg >>> directory outside of your R's library directory (you can fix it later >>> using the info from that posting to that shogun list I sent >>> previously, once everything is back to normal). >>> >>> (2) Try to install a random package to make sure that the sg package >>> was the one causing the problem. glmnet is always handy to have: >>> >>> R> install.packages('glmnet') >>> >>> It actually requires a FORTRAN compiler, so if that gives you >>> problems, maybe you can try plyr >>> >>> R> install.packages('plyr') >>> >>> (3) Assuming (2) worked, now update your installed packages from >>> within R as described on the bioconductor install page >>> (http://www.bioconductor.org/install/) -- perhaps using the nuclear >>> option: >>> >>> R> source("http://bioconductor.org/biocLite.R") >>> R> pkgs<- rownames(installed.packages()) >>> R> biocLite(pkgs) >>> >>> Although I'm pretty sure the option listed before that on that install >>> page would work all the same ... >>> >>> -steve >>> >> >> As it turns out, yes, the old libraries were the obstruction. The new R >> I built worked fine until I added either one of the old library >> directories to R_LIBS. So now I have the joy of ripping out all the >> existing R libraries and replacing them with ones that people still want >> system-wide -- fortunately a far smaller set. > > It sounds like you are updating R and then just copying things into > the new R's library directory. This will always end in tears unless > you ensure that the packages all get updated (R and especially BioC > have a tightly linked version structure, so you don't want to > mix'n'match). > > You will have to download packages to update, so moving things isn't > usually worth it. If you just want to recreate what you had after a > new R install, you can fire up the old version and do > > dput(row.names(installed.packages(priority = "NA"))) > > Then copy that character vector and go to the new version and do > > source("http://www.bioconductor.org/biocLite.R") > biocLite(paste_the_vector_here) > > alternatively, you could move the library directory over, then > > source("http://www.bioconductor.org/biocLite.R") > biocLite("Biobase") > library(Biobase) > z <- biocReposList() > update.packages(repos = z, ask = FALSE) > > Best, > > Jim This all started when the Linux autoupdater handed us a new R binary and standard libraries to replace our old one. As it turns out, the new R doesn't like where we keep some important stuff, so I'm building the new R from source, which should at least prevent this from happening again. Once I have the new R in place, my plan is to reinstall Bioconductor and other libraries from scratch. Thanks for the warning! MJB