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