[R-SIG-Mac] Mac binary of rJava for R 4.1?
Hi there, Something strange has been going on with the PACKAGES index file of the macosx binaries for 4.1 for the last several days: rJava is present in the index despite the package binary not being in the repo. See index file: https://cran.r-project.org/bin/macosx/contrib/4.1/PACKAGES The index contains an entry for rJava. But no rJava binary here: https://cran.r-project.org/bin/macosx/contrib/4.1/ That being said, when can we expect to see a Mac binary of rJava for R 4.1? Thanks, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] fatal error: 'stdio.h' file not found
Hi Eric, FWIW, here is what I see on my system (Mojave): machv2:~ biocbuild$ which clang /usr/bin/clang machv2:~ biocbuild$ clang -v Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin machv2:~ biocbuild$ ls -l /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h -r--r--r-- 1 root wheel 16319 Feb 22 2019 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h I'm not a Mac expert but I believe these locations for Apple clang and associated standard C header files have not changed for years. Hope this helps, H. On 4/29/20 07:05, Eric K wrote: Running R 3.6 has been working fine. I just upgraded to R 4.0 and I cannot build packages from source. I have tried the following: 1. Installed R 4.0 binary on my mac (macOS 10.14.6). Installation went fine, but when I try to build packages from source I get errors like this: * installing *source* package ‘MASS’ ... ** package ‘MASS’ successfully unpacked and MD5 sums checked ** using staged installation ** libs clang -mmacosx-version-min=10.13 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I/usr/local/include -fPIC -Wall -g -O2 -c MASS.c -o MASS.o MASS.c:18:10: fatal error: 'stdlib.h' file not found #include Indeed, stdlib.h is not in /usr/local/include. 2. So I installed Command_Line_Tools_for_Xcode_11.3.1.dmg, but that did not fix the problem 3. So I installed Xcode 11.3.1 itself. That did not fix the problem. 4. For good measure, I re-ran xcode-select --install 5. Googling suggested installing /Library/Developer/CommandLineTools/ Packages/macOS_SDK_headers_for_macOS_10.14.pkg, but that package is not on my computer. 6. I tried building R 4.0 from source with this config.site: CC=clang OBJC=$CC FC=/usr/local/gfortran/bin/gfortran CXX=clang++ configure went ok, but then the build failed with: trying to compile and link a JNI program detected JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/darwin detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm clang -I"/Users/Eric.Kort/build/R-4.0.0/include" -DNDEBUG -I/Library/Java/JavaVirtualMachines/jdk-13.0.1.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk-13.0.1.jdk/Contents/Home/include/darwin -I/usr/local/include -fPIC -g -O2 -c conftest.c -o conftest.o In file included from conftest.c:1: /Library/Java/JavaVirtualMachines/jdk-13.0.1.jdk/Contents/Home/include/jni.h:39:10: fatal error: 'stdio.h' file not found #include Can anyone spot what I am doing wrong? Thank you! -Eric [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MF1GsseSwZpmjo7qspeJtAlyY9nDQ_XZnJGweoVjCfE=oFtPJDZ3gSkizBSLFUqqZ2SGa402cZZHDFxpHmk5rNM= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R
Yeah I **guess** so. Even though a close look at ?.Platform doesn't
particularly help clarify the somewhat fuzzy concept of "default type"
or "preferred setting for options('pkgType')":
pkgType: character string, the preferred setting for
‘options("pkgType")’. Values ‘"source"’,
‘"mac.binary.el-capitan"’ and ‘"win.binary"’ are
currently in use.
> options("pkgType")
$pkgType
[1] "both"
Cheers,
H.
On 4/2/20 13:34, Simon Urbanek wrote:
Hervé,
what Brian was referring to was
.Platform$pkgType
[1] "mac.binary"
Cheers,
Simon
On 2/04/2020, at 10:20 PM, Hervé Pagès wrote:
On 4/2/20 02:05, Prof Brian Ripley wrote:
On 02/04/2020 09:34, Simon Urbanek wrote:
Hervé,
"both" is a fairly recent addition and my guess would be that it has been guarded specifically
since it is the default and installing binaries only works for the CRAN version. I didn't look at the new
"both" code to see how it knows that it's the CRAN version - there is really no special
"CRAN" flag. At some point we were guarding binary installs in general by checking the OS and R,
but it was fragile - you could be building using the same system as we do and yet use a different compiler,
so I think it's in general impossible unless we introduce some extra identification of the binaries. So, yes,
if you compile R from sources yourself it is not guaranteed to be compatible with CRAN package binaries.
Those are only built and tested with the CRAN R binary.
It is simple: type = 'both' has to know what the two types are. Only the CRAN binaries have the
default type set to "mac.binary": building from the sources gives you a default type of
"source". See ?.Platform.
AFAIK the CRAN binary has the default type set to "both".
Anyway knowing the defaults is interesting but only orthogonal to the
discussion.
H.
Cheers,
Simon
On 2/04/2020, at 7:47 PM, Hervé Pagès wrote:
Hi Simon,
After installing R 4.0 alpha from source on a macOS Mojave system, R won't let me use
type="both" to install CRAN packages. I get:
Error in install.packages("rJava", type = "both", repos =
"https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MSzgfKtoxGL_KkQlwrc2_nVNhirnKTu8bSZjbK7pWfo=dwNIQLeXMIf8EpV1P4Y7_Dy14ehDLhEXXodGF8S4pu8=
") :
type == "both" can only be used on Windows or a CRAN build for macOS
OK so this suggests that the CRAN binary packages for R 4.0 are not compatible with my R.
Surprisingly though using type="mac.binary" doesn't complain and lets me
install these binaries. But then trying to load them causes segfaults. I've tried this
with rJava, Rcpp, ggplot2, and doing library() on any of them crashes my session. Note
that installing all these packages from source works without any problem.
So my questions are: is it the case that CRAN binary packages are not meant to be used with an R
4.0 installed from source? If yes then why isn't type="mac.binary" blocking this like
type="both" does?
Thanks,
H.
sessionInfo()
R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin18.7.0 (64-bit)
Running under: macOS Mojave 10.14.6
Matrix products: default
BLAS: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib
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] compiler_4.0.0
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MSzgfKtoxGL_KkQlwrc2_nVNhirnKTu8bSZjbK7pWfo=y45lZ-rli7qQ2JViPRCfXMg9UUKbXNAZ8S5y5Kn3IAU=
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MSzgfKtoxGL_KkQlwrc2_nVNhirnKTu8bSZjbK7pWfo=y45lZ-rli7qQ2JViPRCfXMg9UUKbXNAZ8S5y5Kn3IAU=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Se
Re: [R-SIG-Mac] Homebrew
Just for a minute let's ignore the fact that installing R via Homebrew
is not considered a good option by the competent authorities (which
sounds like a good enough reason to stay away from it). I'm still
wondering: what's the benefit vs installing the official CRAN binary?
Just curious.
Thanks,
H.
On 4/2/20 03:43, Rainer M Krug wrote:
On 2 Apr 2020, at 12:17, Duncan Murdoch wrote:
On 02/04/2020 5:58 a.m., Dr Eberhard W Lisse wrote:
New thread :-)-O
I am wondering if I should not try to figure out how automate this.
Is there a way of (only) listing all user installed (additional)
packages, ie not the ones that come with R?
I had something similar in mind - here is my repo which collects ides (no code yet)
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rkrug_install=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=ZUWEqptXXn0kw7PX-ToEnYb7DtfXGUcOn5PzyQVfVG8=
If you are interested, we could get this going.
If I understand correctly, this would be very useful in many cases.
Look at the "Priority" column in installed.packages(). "base" is part of R, "recommended" is
normally distributed with R. "recommended" packages can be updated after R is installed, "base" packages
can't.
That is a good idea. We should take this forward.
If you just copy all the packages to the new library that aren't already there,
and run update.packages(checkBuilt = TRUE) R will re-install everything that
was originally installed under an earlier version.
Cheers,
Rainer
Duncan Murdoch
I could then construct the below file automagically, and if I was
really bothered and bored find out how to make Homebrew pre/post
install scripts to automate this :-)-O
And, for the record, other than that, I can only recall one serious
issue, when the openblas library got lost recently which was however
fixed quite quickly.
greetings, el
On 02/04/2020 10:17, Dr Eberhard W Lisse wrote:
I do same, including Rstudio (Cask).
Once in a while after major updates I need to reinstall all my extra
packages, so I have written me a little script along the lines of
#!/usr/local/bin/Rscript
local({
r <- getOption("repos")
r["CRAN"] <-
"https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.r-2Dproject.org_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=rnzs7MN3dX-WT08dEbSoFz0AVBgX-xNNlW9keQhr0jg=
"
options(repos = r)
})
install.packages(c(
"RMariaDB", "rstudioapi"
))
made it 0755 and can run it from the command line. Put it in my
handbook so I don't forget and never looked back.
greetings, el
On 02/04/2020 10:03 am, Rainer M Krug wrote:
I am using Homebrew on a Mac (two Macs - one at home, one at work)
instead of the official R package, and I did not have any problems
after upgrades - maybe I am lucky, maybe not as picky in defining
“problem”, but my suggestion would be to try R from homebrew to
install R.
OK - no support from here - I know.
And homebrew has also binary versions. What is missing, is a hombrew
R package repository. Maybe an idea to create one?
Cheers,
Rainer
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=-Kazp7RDPhXbnKvMu3vyOfRSE7ZQBHDCH9Vy6MeGssA=
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Orcid ID: -0002-7490-0066
Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland
Office: +41 (0)44 635 47 64
Cell: +41 (0)78 630 66 57
email: rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug
PGP: 0x0F52F982
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=-Kazp7RDPhXbnKvMu3vyOfRSE7ZQBHDCH9Vy6MeGssA=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R
On 4/2/20 02:05, Prof Brian Ripley wrote:
On 02/04/2020 09:34, Simon Urbanek wrote:
Hervé,
"both" is a fairly recent addition and my guess would be that it has
been guarded specifically since it is the default and installing
binaries only works for the CRAN version. I didn't look at the new
"both" code to see how it knows that it's the CRAN version - there is
really no special "CRAN" flag. At some point we were guarding binary
installs in general by checking the OS and R, but it was fragile - you
could be building using the same system as we do and yet use a
different compiler, so I think it's in general impossible unless we
introduce some extra identification of the binaries. So, yes, if you
compile R from sources yourself it is not guaranteed to be compatible
with CRAN package binaries. Those are only built and tested with the
CRAN R binary.
It is simple: type = 'both' has to know what the two types are. Only
the CRAN binaries have the default type set to "mac.binary": building
from the sources gives you a default type of "source". See ?.Platform.
AFAIK the CRAN binary has the default type set to "both".
Anyway knowing the defaults is interesting but only orthogonal to the
discussion.
H.
Cheers,
Simon
On 2/04/2020, at 7:47 PM, Hervé Pagès wrote:
Hi Simon,
After installing R 4.0 alpha from source on a macOS Mojave system, R
won't let me use type="both" to install CRAN packages. I get:
Error in install.packages("rJava", type = "both", repos =
"https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MSzgfKtoxGL_KkQlwrc2_nVNhirnKTu8bSZjbK7pWfo=dwNIQLeXMIf8EpV1P4Y7_Dy14ehDLhEXXodGF8S4pu8=
") :
type == "both" can only be used on Windows or a CRAN build for macOS
OK so this suggests that the CRAN binary packages for R 4.0 are not
compatible with my R. Surprisingly though using type="mac.binary"
doesn't complain and lets me install these binaries. But then trying
to load them causes segfaults. I've tried this with rJava, Rcpp,
ggplot2, and doing library() on any of them crashes my session. Note
that installing all these packages from source works without any
problem.
So my questions are: is it the case that CRAN binary packages are not
meant to be used with an R 4.0 installed from source? If yes then why
isn't type="mac.binary" blocking this like type="both" does?
Thanks,
H.
sessionInfo()
R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin18.7.0 (64-bit)
Running under: macOS Mojave 10.14.6
Matrix products: default
BLAS: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib
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] compiler_4.0.0
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MSzgfKtoxGL_KkQlwrc2_nVNhirnKTu8bSZjbK7pWfo=y45lZ-rli7qQ2JViPRCfXMg9UUKbXNAZ8S5y5Kn3IAU=
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MSzgfKtoxGL_KkQlwrc2_nVNhirnKTu8bSZjbK7pWfo=y45lZ-rli7qQ2JViPRCfXMg9UUKbXNAZ8S5y5Kn3IAU=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R
Thanks. Only seeing this after I sent my other email about also getting
crashes when I use your conf.high-sierra-x86_64 settings. But of course
I'm not on Catalina so my setting is not exactly the same as yours.
Therefore I should conclude that the CRAN binaries are not meant for me.
H.
On 4/2/20 01:34, Simon Urbanek wrote:
Hervé,
"both" is a fairly recent addition and my guess would be that it has been guarded specifically
since it is the default and installing binaries only works for the CRAN version. I didn't look at the new
"both" code to see how it knows that it's the CRAN version - there is really no special
"CRAN" flag. At some point we were guarding binary installs in general by checking the OS and R,
but it was fragile - you could be building using the same system as we do and yet use a different compiler,
so I think it's in general impossible unless we introduce some extra identification of the binaries. So, yes,
if you compile R from sources yourself it is not guaranteed to be compatible with CRAN package binaries.
Those are only built and tested with the CRAN R binary.
Cheers,
Simon
On 2/04/2020, at 7:47 PM, Hervé Pagès wrote:
Hi Simon,
After installing R 4.0 alpha from source on a macOS Mojave system, R won't let me use
type="both" to install CRAN packages. I get:
Error in install.packages("rJava", type = "both", repos =
"https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=1-DiLdDSQroIloL3L_LKjjvH_qEO6FioafafYgQlOec=7DtbiQ_hSodOXZfS86zwIWgG79R3q9TbA6wYXp9_Dps=
") :
type == "both" can only be used on Windows or a CRAN build for macOS
OK so this suggests that the CRAN binary packages for R 4.0 are not compatible with my R.
Surprisingly though using type="mac.binary" doesn't complain and lets me
install these binaries. But then trying to load them causes segfaults. I've tried this
with rJava, Rcpp, ggplot2, and doing library() on any of them crashes my session. Note
that installing all these packages from source works without any problem.
So my questions are: is it the case that CRAN binary packages are not meant to be used with an R
4.0 installed from source? If yes then why isn't type="mac.binary" blocking this like
type="both" does?
Thanks,
H.
sessionInfo()
R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin18.7.0 (64-bit)
Running under: macOS Mojave 10.14.6
Matrix products: default
BLAS: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib
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] compiler_4.0.0
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=1-DiLdDSQroIloL3L_LKjjvH_qEO6FioafafYgQlOec=_OV3TWFsNFtJKjT7wgVfzpmhuXC8hjOLzEo7WdhdRjo=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R
FWIW I also get the same thing (i.e. R crashes on loading CRAN binary
packages) if I configure R 4.0 alpha like here
https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4/conf.high-sierra-x86_64,
that is, if all the compilers use -mmacosx-version-min=10.13 and I set
--build=x86_64-apple-darwin17.0
In that case I end up with the following sessionInfo():
> sessionInfo()
R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Mojave 10.14.6
Matrix products: default
BLAS: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib
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] compiler_4.0.0
H.
On 4/1/20 23:47, Hervé Pagès wrote:
Hi Simon,
After installing R 4.0 alpha from source on a macOS Mojave system, R
won't let me use type="both" to install CRAN packages. I get:
Error in install.packages("rJava", type = "both", repos =
"https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=H0XG-BbaqC0wtDJVNafEVTuhS6RZzzjXrTCwAq3rYGg=iXhmlQ7VZsVt9PcHpO66FPP66TY_GHko8gQqVv_CCNw=
") :
type == "both" can only be used on Windows or a CRAN build for macOS
OK so this suggests that the CRAN binary packages for R 4.0 are not
compatible with my R. Surprisingly though using type="mac.binary"
doesn't complain and lets me install these binaries. But then trying to
load them causes segfaults. I've tried this with rJava, Rcpp, ggplot2,
and doing library() on any of them crashes my session. Note that
installing all these packages from source works without any problem.
So my questions are: is it the case that CRAN binary packages are not
meant to be used with an R 4.0 installed from source? If yes then why
isn't type="mac.binary" blocking this like type="both" does?
Thanks,
H.
> sessionInfo()
R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin18.7.0 (64-bit)
Running under: macOS Mojave 10.14.6
Matrix products: default
BLAS: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib
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] compiler_4.0.0
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R
Hi Simon,
After installing R 4.0 alpha from source on a macOS Mojave system, R
won't let me use type="both" to install CRAN packages. I get:
Error in install.packages("rJava", type = "both", repos =
"https://cran.r-project.org;) :
type == "both" can only be used on Windows or a CRAN build for macOS
OK so this suggests that the CRAN binary packages for R 4.0 are not
compatible with my R. Surprisingly though using type="mac.binary"
doesn't complain and lets me install these binaries. But then trying to
load them causes segfaults. I've tried this with rJava, Rcpp, ggplot2,
and doing library() on any of them crashes my session. Note that
installing all these packages from source works without any problem.
So my questions are: is it the case that CRAN binary packages are not
meant to be used with an R 4.0 installed from source? If yes then why
isn't type="mac.binary" blocking this like type="both" does?
Thanks,
H.
> sessionInfo()
R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin18.7.0 (64-bit)
Running under: macOS Mojave 10.14.6
Matrix products: default
BLAS: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib
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] compiler_4.0.0
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Transitioning from Mac to LInux?
My 2 cents: Just go for the inexpensive desktop + Linux. Debian-based or RedHat-based distros are great for developing R/Bioconductor packages. I've been maintaining/troubleshooting package builds on Linux/Windows/Mac for 15 years and Linux is **by far** the easiest platform to deal with. Still a mystery to me why one would choose macOS for developing R/Bioconductor packages. H. On 4/1/20 11:48, Carl Witthoft wrote: If I should ask over at r-sig-debian instead of here, please tell me. I don't wish to clog r-sig-mac with off-topic stuff. I've been watching the massive headaches people are dealing with trying to keep R fully compatible with each MacOS X upgrade, I'm wondering whether replacing my iMac (2009) with a new Mac really makes sense from an R - user point of view, as opposed to getting some inexpensive desktop and installing Linux. I know I can run R and RStudio under Linux, for example, but don't know what limitations, if any there are when it comes to building packages from source, getting compatible compilers, and so on. What have some of you 'power R users' discovered when/if you tried to build , or incorporate Bioconductor or other repository's packages under Linux? -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Please test R 4.0.0 pre-releases!
I see bin/macosx/contrib/4.0/ now (e.g. https://cran.r-project.org/bin/macosx/contrib/4.0/). Thanks! H. On 4/1/20 00:37, Simon Urbanek wrote: Hervé, On 1/04/2020, at 6:19 PM, Hervé Pagès wrote: Thanks Simon. A couple of days ago we've started to use the R 4.0.0 alpha build from https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.r-2Dproject.org_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=SgN9XTf8oSzk28ZilVDsjOU2Fpf0lRzDmF8QEBnwJno=n2gZ5tfjXIG7SNEmqQd8-QMsUj5t6y0-r1r-qaCgd7I= for the Bioconductor build system. Bioconductor packages depend on thousands of CRAN packages and one thing that makes it hard for us and for our users to build/check Bioconductor packages at the moment is the absence of Mac binary packages for R 4.0.0 on CRAN. Do you have an estimate of when they will become available? Both the packages and R are now available. I always recommend using the Mac-master https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.R-2Dproject.org=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=SgN9XTf8oSzk28ZilVDsjOU2Fpf0lRzDmF8QEBnwJno=-zAfQSmtuRs4uqHBVFcX5ssEWKX2vsSrEqVTwxI_WuM= as "mirror" since that one is most up-to-date. Another question is where they are going to be hosted on CRAN. We need to follow CRAN's layout for Bioconductor package repositories. We have removed the extra layer, the package type is back to "mac.binary", so bin/macosx/contrib is the location. Cheers, Simon Thanks! H. On 3/31/20 21:27, Simon Urbanek wrote: Dear Mac users, R 4.0.0 will be using an entirely new toolchain, entirely new build system on entirely new macOS version and hardware. Therefore I would like to ask you kindly to test the binaries from https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.R-2Dproject.org=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=FJYxweW9WiMXbNMPpMM0bHXy020Gx9P-dHMrWmt7YzE= before the release as much as you can. Raising any issues after the release is too late! So please, please, test the pre-releases. Report any issues either directly to me or this mailing list. The nightly builds are signed, but not necessarily notarized. However, the build fulfils Apple's conditions and is known to pass notarization (in fact the the package available for download today is actually notarized) so it should be a good test for the release which will be notarized and should work on Catalina. For those that want to replicate our setup - technical details: we are now building with macOS 10.13 (High Sierra) as target (i.e. the oldest supported system), regular Apple Xcode/command line tools and GNU Fortran 8.2. R builds are running on macOS 10.15 (Catalina) with Xcode 11.4 using macOS 10.13 target. Packages are built on macOS 10.13 VMs with just Apple command line tools (this should make it easy to replicate the setup using Travis, for example). All 3rd party libraries that CRAN uses are available in https://urldefense.proofpoint.com/v2/url?u=http-3A__mac.r-2Dproject.org_libs-2D4_=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=3ZbcXBticg_8MfXltGKdQ9SFNqqeLqqwK_pUhEet7QY= The new R build system is in https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R-2Ddev-2Dweb_trunk_QA_Simon_R4=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=Mmt7_pVM5aUDR3hz93-e-PtadG7wSYpaZe8Ayi5Pv4I= Packages build system has not changed and is in https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R-2Ddev-2Dweb_trunk_QA_Simon_packages=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=eId6n08LVeIAMhMXe3jvLFKn9QGi4_by8owFreDDc84= We also plan to have a mac-builder available with similar function as the win-builder where pre-submission tests can be performed and potentially a Travis template. Please test R pre-releases and provide feedback! Thanks, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=ubqivtpb1OZ2I0MEbVvGlGDK-tfti3DPtIv4LQ-Ks6A= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eR
Re: [R-SIG-Mac] Please test R 4.0.0 pre-releases!
Thanks Simon. A couple of days ago we've started to use the R 4.0.0 alpha build from https://mac.r-project.org/ for the Bioconductor build system. Bioconductor packages depend on thousands of CRAN packages and one thing that makes it hard for us and for our users to build/check Bioconductor packages at the moment is the absence of Mac binary packages for R 4.0.0 on CRAN. Do you have an estimate of when they will become available? Another question is where they are going to be hosted on CRAN. We need to follow CRAN's layout for Bioconductor package repositories. Thanks! H. On 3/31/20 21:27, Simon Urbanek wrote: Dear Mac users, R 4.0.0 will be using an entirely new toolchain, entirely new build system on entirely new macOS version and hardware. Therefore I would like to ask you kindly to test the binaries from https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.R-2Dproject.org=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=FJYxweW9WiMXbNMPpMM0bHXy020Gx9P-dHMrWmt7YzE= before the release as much as you can. Raising any issues after the release is too late! So please, please, test the pre-releases. Report any issues either directly to me or this mailing list. The nightly builds are signed, but not necessarily notarized. However, the build fulfils Apple's conditions and is known to pass notarization (in fact the the package available for download today is actually notarized) so it should be a good test for the release which will be notarized and should work on Catalina. For those that want to replicate our setup - technical details: we are now building with macOS 10.13 (High Sierra) as target (i.e. the oldest supported system), regular Apple Xcode/command line tools and GNU Fortran 8.2. R builds are running on macOS 10.15 (Catalina) with Xcode 11.4 using macOS 10.13 target. Packages are built on macOS 10.13 VMs with just Apple command line tools (this should make it easy to replicate the setup using Travis, for example). All 3rd party libraries that CRAN uses are available in https://urldefense.proofpoint.com/v2/url?u=http-3A__mac.r-2Dproject.org_libs-2D4_=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=3ZbcXBticg_8MfXltGKdQ9SFNqqeLqqwK_pUhEet7QY= The new R build system is in https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R-2Ddev-2Dweb_trunk_QA_Simon_R4=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=Mmt7_pVM5aUDR3hz93-e-PtadG7wSYpaZe8Ayi5Pv4I= Packages build system has not changed and is in https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R-2Ddev-2Dweb_trunk_QA_Simon_packages=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=eId6n08LVeIAMhMXe3jvLFKn9QGi4_by8owFreDDc84= We also plan to have a mac-builder available with similar function as the win-builder where pre-submission tests can be performed and potentially a Travis template. Please test R pre-releases and provide feedback! Thanks, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=-PNBcsZhHb1MLy6fZakmLP6WDLMwL-VigJVzeFtPxOI=ubqivtpb1OZ2I0MEbVvGlGDK-tfti3DPtIv4LQ-Ks6A= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] contrib/3.5 and contrib/3.6 empty
Hi Simon, On 3/30/20 13:41, Simon Urbanek wrote: Martin, thanks, yes, el-capitan builds end with 3.6 so I have removed 3.7 and r-devel. Your subject got me scared ;) Thanks for the update. Do you mind me asking what these things are going to be replaced with? I was not able to find any 4.0 subfolder on CRAN yet (after trying a few shots in the dark e.g. bin/macosx/high-sierra/contrib/4.0/, bin/macosx/catalina/contrib/4.0/, bin/macosx/contrib/4.0/) Thanks, H. Cheers, Simon On 31/03/2020, at 9:02 AM, Martin Maechler wrote: Bob Rudis on Thu, 26 Mar 2020 09:44:39 -0400 writes: Simon (et al), FYI Ref: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_bearloga_status_1243159479492972545-3Fs-3D20=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=9lcm1EU4F0AsqywEcz1K1ZH7vd9AxFLF8bVP7Prelgo=UVYlK45rqDfz6HcA6cPDv26Zhf0OHJ9jbDVe8vzv2Vw= and also my confirmation that bin/macosx/el-capitan/contrib/3.4 is the only 3.x with binaries in it after checking home CRAN mirror. -BoB Well, I think our mirror https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.CH.r-2Dproject.org_=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=9lcm1EU4F0AsqywEcz1K1ZH7vd9AxFLF8bVP7Prelgo=tFuhG2OMwhRYFCEDEeaOozxo5tC-hZiPVzl2-KGN9uY= ( --> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_CRAN_bin_macosx_el-2Dcapitan_contrib_3.6_=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=9lcm1EU4F0AsqywEcz1K1ZH7vd9AxFLF8bVP7Prelgo=uPH6_oJ5nplMbCWQUMJ8oPyv_jhMRfPU1N9ZD-JYePg= ) would have helped too, as my rsync script is "slow to delete" on purpose. But that's not the reason for this e-mail: Rather to alert people (SU !) to the fact that in unix-style directory look, this is drwxrwxr-x. 2 1048576 Mar 30 18:00 3.4 drwxrwxr-x. 2 1048576 Mar 23 22:50 3.5 drwxrwxr-x. 2 1048576 Mar 30 21:48 3.6 drwxrwxr-x. 2 4096 Apr 26 2019 3.7 lrwxrwxrwx. 13 Apr 26 2019 r-devel -> 3.7 lrwxrwxrwx. 13 Apr 26 2019 r-oldrel -> 3.5 lrwxrwxrwx. 13 Apr 26 2019 r-release -> 3.6 where notably r-devel still sym.links to 3.7 rather than 4.0 (but is not yet populated anyway).. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=9lcm1EU4F0AsqywEcz1K1ZH7vd9AxFLF8bVP7Prelgo=uviIzX5RyMCRA1GpWLhYyjcNP_viq4A_cNy2pjEStcg= ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=9lcm1EU4F0AsqywEcz1K1ZH7vd9AxFLF8bVP7Prelgo=uviIzX5RyMCRA1GpWLhYyjcNP_viq4A_cNy2pjEStcg= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R is taking too long to load
Hi, First thing I would do is make sure you don't have any startup file or .Rhistory in the way. If starting R with --vanilla is fast, then that's probably the case. H. On 05/18/2017 12:44 PM, Christofer Bogaso wrote: Hi, It just started happening recently that R is taking too long to load and entire system freezes during its loading. Have anyone experienced something similar? Previously my R was completely okay, however it just started recently. Any solution for this? I have reinstalled R and now it is the latest version 3.4.0. I am using Sierra iOS. Appreciate for any pointer. Thanks, ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=m7VSPPECqAsFryKwwUO-q8QiizXtbiWc-kj9qtPO2h0=cSQVI4BrFUKhUyo5ZPrQMQOwu-ZSCMWpxh5IJ8y9L6s= -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] El Capitan binaries of CRAN packages and R
Hi, Just wanted to point out 2 things about the new El Capitan binaries in case they've not been noticed yet. 1) Many of the package binaries on CRAN (e.g. found here https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.4/) are currently broken. Most likely because they were generated just before the r72375 change in R (announced here https://stat.ethz.ch/pipermail/r-devel/2017-March/073940.html). For example: library(e1071) example(svm) # error: object 'R_svmtrain' not found or: library(rgl) rgl.clear() # error: object 'rgl_clear' not found etc... 2) It looks like there has been no successful El Capitan build of R since March 21st on the "R for Mac OS X Developer's Page": https://r.research.att.com/ Hopefully these issues can be taken care of soon. Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] slow compiling times with clang 4.0.0 (but faster code?)
Hi, Following the lead of the R folks, we've started to build and check Bioconductor packages on El Capitan using the compilers that Simon made available here: https://r.research.att.com/libs/ The cran-usr-local-darwin15.6-20170320.tar.gz tarball contains clang 4.0.0 that is used to compile package C and C++ code. Our latest daily build report can be found here: https://bioconductor.org/checkResults/3.5/bioc-LATEST/ The builder running El Capitan + clang 4.0.0 is veracruz2: veracruz2:~ biocbuild$ clang -v clang version 4.0.0 (tags/RELEASE_400/final) Target: x86_64-apple-darwin15.6.0 Thread model: posix InstalledDir: /usr/local/clang+llvm-4.0.0-x86_64-apple-darwin/bin toluca2 is another builder that has the same specs than veracruz2 but is running Mavericks and uses the clang compiler from Apple's Command Line Developer Tools: toluca2:~ biocbuild$ clang -v Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix We're observing significantly slower compiling times on veracruz2 compared to toluca2. For example, looking at packages where 'R CMD INSTALL' time is dominated by compilation: 683.0 vs 483.6 seconds for the mzR package (C++ code): https://bioconductor.org/checkResults/3.5/bioc-LATEST/mzR/veracruz2-install.html https://bioconductor.org/checkResults/3.5/bioc-LATEST/mzR/toluca2-install.html 378.3 vs 299.9 seconds for the flowWorkspace package (C++ code): https://bioconductor.org/checkResults/3.5/bioc-LATEST/flowWorkspace/veracruz2-install.html https://bioconductor.org/checkResults/3.5/bioc-LATEST/flowWorkspace/toluca2-install.html 186.3 vs 126.2 seconds for the rTANDEM package (C++ code): https://bioconductor.org/checkResults/3.5/bioc-LATEST/rTANDEM/veracruz2-install.html https://bioconductor.org/checkResults/3.5/bioc-LATEST/rTANDEM/toluca2-install.html 109.4 vs 80.8 seconds for the rhdf5 package (C code): https://bioconductor.org/checkResults/3.5/bioc-LATEST/rhdf5/veracruz2-install.html https://bioconductor.org/checkResults/3.5/bioc-LATEST/rhdf5/toluca2-install.html etc... The slowdown seems pretty consistent with a time_on_veracruz2 / time_on_toluca2 ratio varying between 1.25 and 1.5. In addition to clang 4.0.0 we also have the clang compiler from Apple's Command Line Developer Tools on veracruz2: veracruz2:sandbox biocbuild$ /usr/bin/clang -v Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin15.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin If I switch between the 2 compilers on veracruz2 I observe a similar slowdown i.e. the time_with_clang_4.0.0 / time_with_Apple_clang ratio is about the same as the previous ratios. The only difference this time is the compiler. I was wondering if anybody else observed this or if this a known "issue" with clang 4.0.0. On the other hand the good news is that packages with no native code seem to build and check slightly faster on veracruz2 than on toluca2. For example: https://bioconductor.org/checkResults/3.5/bioc-LATEST/GenomicFeatures/veracruz2-buildsrc.html https://bioconductor.org/checkResults/3.5/bioc-LATEST/GenomicFeatures/toluca2-buildsrc.html https://bioconductor.org/checkResults/3.5/bioc-LATEST/GenomicFeatures/veracruz2-checksrc.html https://bioconductor.org/checkResults/3.5/bioc-LATEST/GenomicFeatures/toluca2-checksrc.html Note that R was compiled with Apple's clang on toluca2 and with clang 4.0.0 on veracruz2. So is the deal that clang 4.0.0 produces more efficient code at the cost of longer compilation times? Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] R-devel binaries on R for Mac OS X Developer's Page are lagging 6 weeks behind
Hi, I noticed that the latest R-devel binaries available at "R for Mac OS X Developer's Page" are for R r71594 (from 2016-10-26): https://r.research.att.com/#nightly I tried both, the tarball (R-devel-mavericks-sa-x86_64.tar.gz) and .pkg (R-devel-mavericks.pkg). Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Installing packages from source for all installed sub-architectures
Hi Simon, Dan, On 03/05/2012 05:24 PM, Simon Urbanek wrote: Dan, On Mar 5, 2012, at 7:09 PM, Dan Tenenbaum wrote: Hello, Are there plans to modify install.packages() on Mac so that if type=source, the package is installed for all installed sub-architectures? This works for Windows. Currently, install.packages(mypkg, type=source) **may** do the right thing, depending on what type of native code the package has, whether if has a configure script., etc, but there's no guarantee. The same is true for Windows - to my best knowledge the rules are the same on all platforms -- Makefile or configure prevent a package from being built for more than one architecture, because they may modify the sources in-place and thus the package can only be built once. The only difference I'm aware of is that some Windows packages use configure.win for things other than configuration, so binary maintainers may choose to ignore those but that is not the default AFAIK. But OTOH, section 5.4 of the R for Mac OS X FAQ says: Once all tools are in place it is considerably easy to build an universal binary. If the package does not contain a configure script then a regular package installation using either install.packages or R CMD INSTALL automatically creates an universal binary. If the package contains a configure script then it cannot be compiled in-place for multiple platforms, and the following process should be used. Assuming that you have a source package called foo_1.0.tar.gz that uses a configure script, it can be installed universally using the following three-step process: # full 32-bitIntel install R --arch=i386 CMD INSTALL foo_1.0.tar.gz # 64-bit Intel library R --arch=x86_64 CMD INSTALL --libs-only foo_1.0.tar.gz # 32-bit PowerPC library (will require Rosetta to build) R --arch=ppc CMD INSTALL --libs-only foo_1.0.tar.gz So the question is: why can't R CMD INSTALL just do this? I can deal with the 3 above steps for a single package (assuming I have access to the shell). But in general I like to be able to install packages from R because typically the package I install requires a lot of dependencies and install.packages() will solve the dependency problem for me. Unfortunately, using the above trick in that context is a pain. Couldn't R CMD INSTALL --merge-multiarch be supported on Mac and do something like the 3 steps above? That would be a first step towards a little bit more convenience as I would be able to do install.packages(foo, INSTALL_opts=--merge-multiarch) Thanks, H. Cheers, Simon I might add that even installing a binary is not guaranteed to give you .so files for all sub-architectures. CRAN and Bioconductor create multi-arch binaries, but other package distributors may not do this, in fact, they likely won't, since the procedure for generating such binaries is not part of R and is therefore not documented as such. There are of course ways to work around this. But it would be nice not to have to work around it, and it would be very nice if a single command could install a package (and, importantly, all its dependencies) from source for all available architectures. Thanks! Dan ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
