Re: [R-SIG-Mac] packages, R-patched and RC [Was: Importing Excel files]
On Jun 23, 2012, at 12:50 AM, Prof Brian Ripley wrote: Other messages say this is a temporary snafu on the Mac builder, which will be resolved once it percolates through CRAN: the master is OK already. Then I must be confused. I thought this was the master: http://stat.ethz.ch/CRAN/bin/macosx/leopard/contrib/2.15 (I normally use the CMU, Berkeley or Fred-Hutch mirrors, but I tried the ETH-Z site as well. The Mac R build was obtained from the att.research site minutes before the posting.) -- David. On 23/06/2012 05:09, David Winsemius wrote: On Jun 20, 2012, at 8:14 AM, Prof Brian Ripley wrote: On 20/06/2012 11:20, peter dalgaard wrote: On Jun 19, 2012, at 23:29 , Prof Brian Ripley wrote: On 19/06/2012 17:35, Simon Urbanek wrote: On Jun 19, 2012, at 5:36 AM, peter dalgaard wrote: On Jun 19, 2012, at 01:16 , Colstat wrote: I think the error says it package Œgdata‚ was built under R version 2.15.1 and you have R 2.5.10. Update your R first, let me know if it doesn't work. 2.15.1 is announced for Friday... I think it's a bit of a glitch that CRAN is already automatically providing packages for it, but you are of course more than welcome to test the prereleases (from http://R.research.att.com/). I suppose that this comes about from building packages with R-patched, which transitions directly into the prereleases for the next version. Yes, this is a side-effect of that. I wonder what we can do about it - I used to build packages with released versions only, but then people complained that patched had fixes for some things they needed... We could simply not update the version of R-patched used during the beta/RC periods: they are after all only about 10 days. Yes, that would handle the formal issue of the version number conflict. However, there's a deeper issue which got highlighted by the identical() debacle in April-June: It seems that we can't guarantee ABI compatibility throughout the R-branch series (e.g., everything labeled 2.15.x). We try to ensure that the modified versions of R will run packages built with a previous version, but the other way around might not work. If that sort of thing happens in R-patched, midway between releases, then users could find themselves blocked from installing packages until they update to R-patched, which could be undesirable in corporate or educational settings. Note this only applies to binary packages: people can always install from the sources (trivially for 'gdata' since it has no compiled code). My understanding is that the Windows' policy is to stick with the current 2.15.x release: 2.15.0 is currently used but once 2.15.1 is out packages will be built with 2.15.1 (and re-built if their dependencies change). The 'debacle' was Bioconductor's lack of understanding of the assumptions of their own distribution model. As we said at the time, if you want to provide binary packages that work under all of 2.15.x, you need to prepare them with 2.15.0. But as Simon points out, that may stop binary packages being provided for some recent source packages. Note that there are other issues here: as we have seen in the last week, updates and downdates to a recommended package such as Matrix have required other packages to be re-installed. It is not just the version of R that is relevant but also what other packages were installed at the time the binary package was prepared. We may need to work harder to get people to understand that binary packages have 'use at your own risk' status. Do the foregoing observations explain why I am unable to get any access to the binary CRAN indexes using the MacGUI installer? I've tried with three different repositories, so I do not think it is due to a scheduled weekend maintenance problem: Warning: unable to access index for repository http://cran.fhcrc.org/bin/macosx/leopard/contrib/2.15 Warning: unable to access index for repository http://stat.ethz.ch/CRAN/bin/macosx/leopard/contrib/2.15 Warning: unable to access index for repository http://cran.cnr.Berkeley.edu/bin/macosx/leopard/contrib/2.15 I _can_ see the source directories and install source packages, so it seems not to be a connectivity issue. I started seeing this with R 2.15.0 , so I updated, but it continues: sessionInfo() R version 2.15.1 RC (2012-06-20 r59589) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.1 The problem persists in a non-GUI session: available.packages() --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... done Warning: unable to access index for repository http://cran.fhcrc.org/bin/macosx/leopard/contrib/2.15 Package Version Priority Depends Imports LinkingTo Suggests Enhances OS_type License Archs
Re: [R-SIG-Mac] packages, R-patched and RC [Was: Importing Excel files]
On 23/06/2012 07:28, David Winsemius wrote: On Jun 23, 2012, at 12:50 AM, Prof Brian Ripley wrote: Other messages say this is a temporary snafu on the Mac builder, which will be resolved once it percolates through CRAN: the master is OK already. Then I must be confused. I thought this was the master: http://stat.ethz.ch/CRAN/bin/macosx/leopard/contrib/2.15 cran.r-project.org is the master CRAN site: ETHZ is one of many mirrors. (I normally use the CMU, Berkeley or Fred-Hutch mirrors, but I tried the ETH-Z site as well. The Mac R build was obtained from the att.research site minutes before the posting.) -- Brian D. Ripley, rip...@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, UKFax: +44 1865 272595 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] packages, R-patched and RC [Was: Importing Excel files]
On Jun 23, 2012, at 2:28 AM, David Winsemius wrote: On Jun 23, 2012, at 12:50 AM, Prof Brian Ripley wrote: Other messages say this is a temporary snafu on the Mac builder, which will be resolved once it percolates through CRAN: the master is OK already. Then I must be confused. I thought this was the master: http://stat.ethz.ch/CRAN/bin/macosx/leopard/contrib/2.15 (I normally use the CMU, Berkeley or Fred-Hutch mirrors, but I tried the ETH-Z site as well. The Mac R build was obtained from the att.research site minutes before the posting. ... and that (R.research.att.com) is also the source for Mac R + package binaries (and those only). CRAN master syncs from there and in turn other mirrors sync from the CRAN master. Cheers, Simon ) -- David. On 23/06/2012 05:09, David Winsemius wrote: On Jun 20, 2012, at 8:14 AM, Prof Brian Ripley wrote: On 20/06/2012 11:20, peter dalgaard wrote: On Jun 19, 2012, at 23:29 , Prof Brian Ripley wrote: On 19/06/2012 17:35, Simon Urbanek wrote: On Jun 19, 2012, at 5:36 AM, peter dalgaard wrote: On Jun 19, 2012, at 01:16 , Colstat wrote: I think the error says it package Œgdata‚ was built under R version 2.15.1 and you have R 2.5.10. Update your R first, let me know if it doesn't work. 2.15.1 is announced for Friday... I think it's a bit of a glitch that CRAN is already automatically providing packages for it, but you are of course more than welcome to test the prereleases (from http://R.research.att.com/). I suppose that this comes about from building packages with R-patched, which transitions directly into the prereleases for the next version. Yes, this is a side-effect of that. I wonder what we can do about it - I used to build packages with released versions only, but then people complained that patched had fixes for some things they needed... We could simply not update the version of R-patched used during the beta/RC periods: they are after all only about 10 days. Yes, that would handle the formal issue of the version number conflict. However, there's a deeper issue which got highlighted by the identical() debacle in April-June: It seems that we can't guarantee ABI compatibility throughout the R-branch series (e.g., everything labeled 2.15.x). We try to ensure that the modified versions of R will run packages built with a previous version, but the other way around might not work. If that sort of thing happens in R-patched, midway between releases, then users could find themselves blocked from installing packages until they update to R-patched, which could be undesirable in corporate or educational settings. Note this only applies to binary packages: people can always install from the sources (trivially for 'gdata' since it has no compiled code). My understanding is that the Windows' policy is to stick with the current 2.15.x release: 2.15.0 is currently used but once 2.15.1 is out packages will be built with 2.15.1 (and re-built if their dependencies change). The 'debacle' was Bioconductor's lack of understanding of the assumptions of their own distribution model. As we said at the time, if you want to provide binary packages that work under all of 2.15.x, you need to prepare them with 2.15.0. But as Simon points out, that may stop binary packages being provided for some recent source packages. Note that there are other issues here: as we have seen in the last week, updates and downdates to a recommended package such as Matrix have required other packages to be re-installed. It is not just the version of R that is relevant but also what other packages were installed at the time the binary package was prepared. We may need to work harder to get people to understand that binary packages have 'use at your own risk' status. Do the foregoing observations explain why I am unable to get any access to the binary CRAN indexes using the MacGUI installer? I've tried with three different repositories, so I do not think it is due to a scheduled weekend maintenance problem: Warning: unable to access index for repository http://cran.fhcrc.org/bin/macosx/leopard/contrib/2.15 Warning: unable to access index for repository http://stat.ethz.ch/CRAN/bin/macosx/leopard/contrib/2.15 Warning: unable to access index for repository http://cran.cnr.Berkeley.edu/bin/macosx/leopard/contrib/2.15 I _can_ see the source directories and install source packages, so it seems not to be a connectivity issue. I started seeing this with R 2.15.0 , so I updated, but it continues: sessionInfo() R version 2.15.1 RC (2012-06-20 r59589) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.1 The problem persists in a non-GUI
Re: [R-SIG-Mac] packages, R-patched and RC [Was: Importing Excel files]
On Jun 20, 2012, at 8:14 AM, Prof Brian Ripley wrote: On 20/06/2012 11:20, peter dalgaard wrote: On Jun 19, 2012, at 23:29 , Prof Brian Ripley wrote: On 19/06/2012 17:35, Simon Urbanek wrote: On Jun 19, 2012, at 5:36 AM, peter dalgaard wrote: On Jun 19, 2012, at 01:16 , Colstat wrote: I think the error says it package Œgdata‚ was built under R version 2.15.1 and you have R 2.5.10. Update your R first, let me know if it doesn't work. 2.15.1 is announced for Friday... I think it's a bit of a glitch that CRAN is already automatically providing packages for it, but you are of course more than welcome to test the prereleases (from http://R.research.att.com/). I suppose that this comes about from building packages with R-patched, which transitions directly into the prereleases for the next version. Yes, this is a side-effect of that. I wonder what we can do about it - I used to build packages with released versions only, but then people complained that patched had fixes for some things they needed... We could simply not update the version of R-patched used during the beta/RC periods: they are after all only about 10 days. Yes, that would handle the formal issue of the version number conflict. However, there's a deeper issue which got highlighted by the identical() debacle in April-June: It seems that we can't guarantee ABI compatibility throughout the R-branch series (e.g., everything labeled 2.15.x). We try to ensure that the modified versions of R will run packages built with a previous version, but the other way around might not work. If that sort of thing happens in R-patched, midway between releases, then users could find themselves blocked from installing packages until they update to R-patched, which could be undesirable in corporate or educational settings. Note this only applies to binary packages: people can always install from the sources (trivially for 'gdata' since it has no compiled code). My understanding is that the Windows' policy is to stick with the current 2.15.x release: 2.15.0 is currently used but once 2.15.1 is out packages will be built with 2.15.1 (and re-built if their dependencies change). The 'debacle' was Bioconductor's lack of understanding of the assumptions of their own distribution model. As we said at the time, if you want to provide binary packages that work under all of 2.15.x, you need to prepare them with 2.15.0. But as Simon points out, that may stop binary packages being provided for some recent source packages. Note that there are other issues here: as we have seen in the last week, updates and downdates to a recommended package such as Matrix have required other packages to be re-installed. It is not just the version of R that is relevant but also what other packages were installed at the time the binary package was prepared. We may need to work harder to get people to understand that binary packages have 'use at your own risk' status. Do the foregoing observations explain why I am unable to get any access to the binary CRAN indexes using the MacGUI installer? I've tried with three different repositories, so I do not think it is due to a scheduled weekend maintenance problem: Warning: unable to access index for repository http://cran.fhcrc.org/bin/macosx/leopard/contrib/2.15 Warning: unable to access index for repository http://stat.ethz.ch/CRAN/bin/macosx/leopard/contrib/2.15 Warning: unable to access index for repository http://cran.cnr.Berkeley.edu/bin/macosx/leopard/contrib/2.15 I _can_ see the source directories and install source packages, so it seems not to be a connectivity issue. I started seeing this with R 2.15.0 , so I updated, but it continues: sessionInfo() R version 2.15.1 RC (2012-06-20 r59589) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.1 The problem persists in a non-GUI session: available.packages() --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... done Warning: unable to access index for repository http://cran.fhcrc.org/bin/macosx/leopard/contrib/2.15 Package Version Priority Depends Imports LinkingTo Suggests Enhances OS_type License Archs File Repository -- David Winsemius, MD Heritage Laboratories West Hartford, CT ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] packages, R-patched and RC [Was: Importing Excel files]
On Jun 19, 2012, at 23:29 , Prof Brian Ripley wrote: On 19/06/2012 17:35, Simon Urbanek wrote: On Jun 19, 2012, at 5:36 AM, peter dalgaard wrote: On Jun 19, 2012, at 01:16 , Colstat wrote: I think the error says it package Œgdata‚ was built under R version 2.15.1 and you have R 2.5.10. Update your R first, let me know if it doesn't work. 2.15.1 is announced for Friday... I think it's a bit of a glitch that CRAN is already automatically providing packages for it, but you are of course more than welcome to test the prereleases (from http://R.research.att.com/). I suppose that this comes about from building packages with R-patched, which transitions directly into the prereleases for the next version. Yes, this is a side-effect of that. I wonder what we can do about it - I used to build packages with released versions only, but then people complained that patched had fixes for some things they needed... We could simply not update the version of R-patched used during the beta/RC periods: they are after all only about 10 days. Yes, that would handle the formal issue of the version number conflict. However, there's a deeper issue which got highlighted by the identical() debacle in April-June: It seems that we can't guarantee ABI compatibility throughout the R-branch series (e.g., everything labeled 2.15.x). We try to ensure that the modified versions of R will run packages built with a previous version, but the other way around might not work. If that sort of thing happens in R-patched, midway between releases, then users could find themselves blocked from installing packages until they update to R-patched, which could be undesirable in corporate or educational settings. Some R-core deliberations might be called for... Cheers, Simon On Mon, Jun 18, 2012 at 5:28 PM, Victoria Xiaovictoriayx...@gmail.comwrote: Exactly. Every time I try to load it from the package manager, the check mark in the check box vanishes and the status goes back to 'not loaded'. At the same time, I get this error message: Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) : there is no package called Œgtools‚ In addition: Warning message: package Œgdata‚ was built under R version 2.15.1 Error: package/namespace load failed for Œgdata‚ It's very perplexing. Would uninstalling and reinstalling gdata help at all? Thanks again. On Mon, Jun 18, 2012 at 2:23 PM, Colstatcols...@gmail.com wrote: Looking at your output, and if you are using package 'gdata'. Then under Other attached packages of your output you don't have, gdata_2.6.2 Are you sure you have loaded the package correctly? It doesn't look like it. On Mon, Jun 18, 2012 at 5:15 PM, Victoria Xiaovictoriayx...@gmail.comwrote: On Mon, Jun 18, 2012 at 2:13 PM, Colstatcols...@gmail.com wrote: Hi Victor, could you type sessionInfo() in R terminal and paste here what you got? On Mon, Jun 18, 2012 at 5:06 PM, Victoria Xiaovictoriayx...@gmail.com wrote: Hi all, I'm trying to figure out how to import Excel files into R. I'm running Mac 10.6, and so far I've tried the xlsx and gdata packages; both gave error messages. For the xlsx package, here is what I got: library(xlsx) project.source = /Users/vicki/Desktop/R/test/kdReport.xls #change the path and file name here PIGF.elisa.dat = read.xlsx (file=project.source, 1, header=T) Error in .jcall(RJavaTools, Ljava/lang/Object;, invokeMethod, cl, : java.lang.IllegalArgumentException: Your InputStream was neither an OLE2 stream, nor an OOXML stream For the gdata package, it said that gtools was required; when gtools package was attempted to load, this error message resulted: Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) : there is no package called Œgtools‚ In addition: Warning message: package Œgdata‚ was built under R version 2.15.1 Error: package/namespace load failed for Œgdata‚ Does anyone know how to resolve either of these error messages, or if there are better packages to interact with Excel files in R on a Mac? Thanks so much. Sincerely, Victoria Xiao [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac sessionInfo() R version 2.15.0 (2012-03-30) Platform: i386-apple-darwin9.8.0/i386 (32-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] splines stats graphics grDevices utils datasets methods [8] base other attached packages: [1] epicalc_2.14.1.6 xlsx_0.4.2 xlsxjars_0.4.0 rJava_0.9-3 [5] rj_1.1.0-4 nnet_7.3-1 MASS_7.3-17 survival_2.36-12 [9] foreign_0.8-49 loaded via a namespace (and not attached): [1] tools_2.15.0 [[alternative HTML version deleted]]
