On Mar 5, 2013, at 10:38 PM, Benjamin Tyner wrote:
> Thank you Brian. So it sounds like appendix B.6 of
>
> http://cran.r-project.org/doc/manuals/R-admin.html
>
> should be updated to reflect that g77 is no longer supported; I will
> notify c...@r-project.org of this unless you suggest a diff
Thank you Brian. So it sounds like appendix B.6 of
http://cran.r-project.org/doc/manuals/R-admin.html
should be updated to reflect that g77 is no longer supported; I will
notify c...@r-project.org of this unless you suggest a different recipient.
In any case, I tried again but using gfortran
Paul,
I think your balanced and reasoned approach addresses all my current concerns.
Nice! I will likely adopt your methods. Let me ruminate. Thanks for this.
~ Malcolm
.-Original Message-
.From: Paul Gilbert [mailto:pgilbert...@gmail.com]
.Sent: Tuesday, March 05, 2013 4:34 PM
Hi Paul,
You outline some great suggestions!
I just wanted to point that in this case:
On Tue, Mar 5, 2013 at 5:34 PM, Paul Gilbert wrote:
[snip]
> Regarding NFS mounts, it is relatively robust. There can be occasional
> problems, especially for users that have a habit of keeping an R session
(More on the original question further below.)
On 13-03-05 09:48 AM, Cook, Malcolm wrote:
All,
What got me started on this line of inquiry was my attempt at
balancing the advantages of performing a periodic (daily or weekly)
update to the 'release' version of locally installed R/Bioconductor
pa
Dear expeRts,
Please find attached the .diff for a bug fix in R-devel 62124. format.ftable()
fails to format ftable()s correctly which have no row.vars or no
col.vars. That should work with the patch (the example code below also runs
correctly for all the (new) 'method's).
Cheers,
Marius
--8<-
One comment: I have found numerical changes due to updates to the OS's
compilers or runtime at least as often as I have been by changes in R or
packages when trying to reproduce results from a year or two back. That
aspect is rarely mentioned in these discussions.
On 05/03/2013 15:09, Cook, M
.> So, even if I wanted to go where dragons lurked, it would not be
.> possible to cobble a version of biocLite that installed specific
.> versions of software.
.>
.> Thus, I might rather consider an approach that at 'publish' time
.> tarzips up a copy of the R package dependencies based on a
On Tue, 5 Mar 2013, Cook, Malcolm wrote:
Thus, I might rather consider an approach that at 'publish' time tarzips
up a copy of the R package dependencies based on a config file defined
from sessionInfo and caches it in the project directory.
If you had a separate environment for every project,
All,
What got me started on this line of inquiry was my attempt at balancing the
advantages of performing a periodic (daily or weekly) update to the 'release'
version of locally installed R/Bioconductor packages on our institute-wide
installation of R with the disadvantages of potentially chang
On 5 Mar 2013, at 14:36, Cook, Malcolm wrote:
So, even if I wanted to go where dragons lurked, it would not be
possible to cobble a version of biocLite that installed specific
versions of software.
Thus, I might rather consider an approach that at 'publish' time
tarzips up a copy of the R pa
.>>> * where do the dragons lurk
.>>>
.>>
.>> webs of interconnected dynamically loaded libraries, identical versions of
.>> R compiled with different BLAS/LAPACK options, etc. Go with the VM if you
.>> really, truly, want this level of exact reproducibility.
.>
.> Sounds like the best bet
I hate to ask what go this thread started but it sounds like someone was
counting onÂ
exact numeric reproducibility or was there a bug in a specific release? In
actualÂ
fact, the best way to determine reproducibility is run the code in a variety of
packages. Alternatively, you can do everything
On Mon, Mar 4, 2013 at 4:13 PM, Cook, Malcolm wrote:
> * where do the dragons lurk
>
webs of interconnected dynamically loaded libraries, identical versions of
R compiled with different BLAS/LAPACK options, etc. Go with the VM if you
really, truly, want this level of exact reproducibility.
An
14 matches
Mail list logo
