date:20200402

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.

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=

--
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

[R-SIG-Mac] GTK+ support (or rather lack thereof)

We have a fairly complete coverage of packages for R 4.0.0, but one exception 
is GTK+ (and thus RGtk2 and its dependencies). It seems that GTK+ has been 
abandoned several years ago, the documented macOS build doesn't work and there 
are no released binaries. To make things worse, Gnome has been switching from 
autoconf to custom build systems that are also broken (quite amazing - the 
build fails with an error in the build system's headers including Python 
headers...), so the path of building our own release from scratch is also not 
realistic anymore (we used to build GTK+ for X11 when it was still possible).

Hence this is a call to the R community to see if anyone actually cares. And if 
so, if there is any known source or path to macOS binaries (script to build it 
is fine, too). Unlike regular rules, we would allow dynamic linking as we have 
granted that exception to GTK+ before, but it has to be compatible with the 
native system. As a last resort, we could also re-use out GTK+ 2.24.17 binaries 
from Snow Leopard, but those are considerably old, so I'd prefer not to do 
that. Comments are welcome.

Thanks,
Simon

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] OpenMP on CRAN

Patrick,

you can't mix compilers - it really matters which iomp your'e using. llvm has 
its own modified version which may not be the same as the official Intel 
release. From your tests it looks like you're using the llvm one which will 
likely work only with that compiler. Since Apple doesn't have official omp 
support it's hard to say which versions work and which don't.


> On 3/04/2020, at 10:20 AM, Patrick Schratz  wrote:
> 
> Thanks Kevin, interesting approach.
> 
> However, when testing it against a few packages I get symbol pointer issues 
> (e.g. for data.table and xgboost). 
> Using llvm everything works. 
> Could llvm be the best middle way? Easy installation via brew and still clang 
> compliant.
> 
> Currently my Makevars look as follows
> 
> CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> […]
> 
> CC = ccache /usr/local/opt/llvm/bin/clang
> […]
> 
> Where llvm was installed via `brew install llvm`.
> SDK 10.13 because of {igraph} and {Rcpp} issues with SDK 10.14 and SDK 10.15


I mentioned that before, but I do not see issues with 10.14 SDK.

Cheers,
Simon


> On 2. Apr 2020, 23:01 +0200, Simon Urbanek , 
> wrote:
>> Tim,
>> 
>> 
>>> On 3/04/2020, at 2:01 AM, BATES Timothy  wrote:
>>> 
>>> Moving to a compiler that drops support for OpenMP seems a sad choice, 
>>> especially now we’ve all climbed the learning curve of the non-Apple 
>>> compiler (the real barrier was lack of a pkg installer and that’s done now).
>>> 
>> 
>> It has caused a lot of issues, it trips people on a daily basis which is 
>> just not worth it. Also with Apple's increasingly strict rules about what 
>> can be distributed we don't want to be in the business in maintaining a 
>> separate toolchain. There have been numerous issues with C++ exceptions so 
>> the fall out was much bigger than originally expected and it would only get 
>> worse.
>> 
>> 
>>> Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would 
>>> be a big loss for users (for whom the CRAN version now supports OpenMP 
>>> giving them a 2-12x speed up). In general, R on Mac is made more viable by 
>>> having OpenMP
>>> 
>>> Re Brian’s points, I’d say that the distribution problem is crucial: 
>>> Packages not on CRAN have dramatically diminished accessibility/useage.
>>> 
>> 
>> The idea is that if a package deems this critical, it can enable this for 
>> the users. As it is now, packages can still supply iomp and use it.
>> 
>> That said, I would open for discussion the ability to distribute iomp with 
>> the R binary, but it would not be supported by R directly, i.e., it would be 
>> on the package author to make sure that the way the package operates is 
>> compatible with that binary. Let me know what you think.
>> 
>> 
>>> Second, a great range of compute-intensive problems are amenable to 
>>> division amongst cores, including nearly all models that take more than a 
>>> nominal amount of time to run: So simulations, CIs, bootstrapping, nearly 
>>> everything in genetics all speeds up.
>>> 
>> 
>> Yes, but OpenMP is rarely used for those tasks. In R OpenMP can be only used 
>> for very small subset of such tasks - which is why alternative approaches 
>> are much more common.
>> 
>> Cheers,
>> Simon
>> 
>> 
>>> I’d say especially on desktop/laptop. The big advantage of multi blade 
>>> systems requires snowfall-type solutions, but desktops profit automatically 
>>> from their multi-core structure and don;’t have multiple processors (except 
>>> graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP 
>>> is their one trick. I’d hope not to lose it.
>>> 
>>> Best, t
>>> 
>>> 
 On 2 Apr 2020, at 05:18, Prof Brian Ripley  wrote:
 
 On 01/04/2020 22:02, Simon Urbanek wrote:
> JJB,
> 1. correct, there was too much trouble in this. But please feel free to 
> start a new thread about this here if you have strong opinions.
 
 Also note that it is possible (and not hard) to install packages from 
 source with an OpenMP-supporting compiler, and how to do so is in the 
 R-admin manual. The problems come in distributing them.
 
 The benefits of OpenMP are often overestimated, especially on 
 desktop/laptop level hardware. But it is available for the small (tiny?) 
 proportion of users who need it.
>>> The University of Edinburgh is a charitable body, registered in Scotland, 
>>> with registration number SC005336.
>>> ___
>>> 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

___
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!

Yes, to a degree - but is'a bit counter-intuitive. Unfortunately, the 4.0 
installer won't keep 3.6 (not sure why, need to investigate), but vice-versa. 
So you have to install 4.0.0 alpha and then 3.6.3. Alternatively, you can move 
/Library/Frameworks/R.framework aside and then install 4.0.0 alpha.

Once you have both versions, you can just change the Current symlink from one 
to the other - see R for Mac FAQ 10.10:
https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Why-is-R_002ehome_0028_0029-not-versioned_003f
 

Cheers,
Simon



> On 3/04/2020, at 10:12 AM, Spencer Graves  wrote:
> 
>   Is there a procedure for dual install, e.g., so I could run "R4 CMD 
> check", etc.?
> 
> 
>   Please excuse if this has already been answered.
> 
> 
>   Thanks,
>   Spencer Graves
> 
> 
> On 2020-04-02 02:50, Rainer M Krug wrote:
>> 
>>> On 1 Apr 2020, at 16:07, Patrick Schratz  wrote:
>>> 
>>> The same goes here regarding support.
>>> 
>>> I am (co-)maintaining a package on ropensci focusing on provider-agnostic 
>>> CI approaches for R (tic) and have quite some experience with all the 
>>> little culprits there.
>>> 
>>> Since you mentioned Travis: Be aware that the R community is (slowly but 
>>> actively) moving away from Travis for a few reasons.
>>> Also on GitHub Actions you can only build on 10.15 (Catalina) right now.
>> So where is the R community moving too?
>> 
>> Rainer
>> 
>>> Best, Patrick
>>> On 1. Apr 2020, 15:41 +0200, Bob Rudis , wrote:
 I shall pile on with an additional offer of assistance, Simon and a huge 
 #ty for this and all the work you do.
 
> On Apr 1, 2020, at 09:30, Balamuta, James Joseph  
> wrote:
> 
> Simon,
> 
> Thanks for the overview! A few quick questions:
> 
> 1. Compiler-wise, the external clang compiler requirement was removed 
> and, so, there is no guarantee of OpenMP on macOS again?
> 2. Why was 10.13 chosen as the oldest system instead of 10.14 given the 
> new push for increased security by Apple?
> 3. How likely is the oldest system requirement to be bumped in a patch 
> release?
> 
> Also, if you need help with mac-builder, Travis, or GitHub Actions, I'm 
> more than happy to help!
> 
> Best,
> 
> JJB
> 
> On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of Simon Urbanek" 
>  simon.urba...@r-project.org> 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://mac.R-project.org
> 
> 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 http://mac.r-project.org/libs-4/
> 
> The new R build system is in
> https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4
> Packages build system has not changed and is in
> https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages
> 
> 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://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
 ___
 R-SIG-Mac mailing list
 R-SIG-Mac@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>> [[alternative HTML version deleted]]
>>> 
>>>

Re: [R-SIG-Mac] OpenMP on CRAN

2020-04-02 Thread Patrick Schratz

Thanks Kevin, interesting approach.

However, when testing it against a few packages I get symbol pointer issues 
(e.g. for data.table and xgboost).
Using llvm everything works.
Could llvm be the best middle way? Easy installation via brew and still clang 
compliant.

Currently my Makevars look as follows

CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
[…]

CC = ccache /usr/local/opt/llvm/bin/clang
[…]

Where llvm was installed via `brew install llvm`.
SDK 10.13 because of {igraph} and {Rcpp} issues with SDK 10.14 and SDK 10.15
On 2. Apr 2020, 23:01 +0200, Simon Urbanek , wrote:
> Tim,
>
>
> > On 3/04/2020, at 2:01 AM, BATES Timothy  wrote:
> >
> > Moving to a compiler that drops support for OpenMP seems a sad choice, 
> > especially now we’ve all climbed the learning curve of the non-Apple 
> > compiler (the real barrier was lack of a pkg installer and that’s done now).
> >
>
> It has caused a lot of issues, it trips people on a daily basis which is just 
> not worth it. Also with Apple's increasingly strict rules about what can be 
> distributed we don't want to be in the business in maintaining a separate 
> toolchain. There have been numerous issues with C++ exceptions so the fall 
> out was much bigger than originally expected and it would only get worse.
>
>
> > Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would 
> > be a big loss for users (for whom the CRAN version now supports OpenMP 
> > giving them a 2-12x speed up). In general, R on Mac is made more viable by 
> > having OpenMP
> >
> > Re Brian’s points, I’d say that the distribution problem is crucial: 
> > Packages not on CRAN have dramatically diminished accessibility/useage.
> >
>
> The idea is that if a package deems this critical, it can enable this for the 
> users. As it is now, packages can still supply iomp and use it.
>
> That said, I would open for discussion the ability to distribute iomp with 
> the R binary, but it would not be supported by R directly, i.e., it would be 
> on the package author to make sure that the way the package operates is 
> compatible with that binary. Let me know what you think.
>
>
> > Second, a great range of compute-intensive problems are amenable to 
> > division amongst cores, including nearly all models that take more than a 
> > nominal amount of time to run: So simulations, CIs, bootstrapping, nearly 
> > everything in genetics all speeds up.
> >
>
> Yes, but OpenMP is rarely used for those tasks. In R OpenMP can be only used 
> for very small subset of such tasks - which is why alternative approaches are 
> much more common.
>
> Cheers,
> Simon
>
>
> > I’d say especially on desktop/laptop. The big advantage of multi blade 
> > systems requires snowfall-type solutions, but desktops profit automatically 
> > from their multi-core structure and don;’t have multiple processors (except 
> > graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP 
> > is their one trick. I’d hope not to lose it.
> >
> > Best, t
> >
> >
> > > On 2 Apr 2020, at 05:18, Prof Brian Ripley  wrote:
> > >
> > > On 01/04/2020 22:02, Simon Urbanek wrote:
> > > > JJB,
> > > > 1. correct, there was too much trouble in this. But please feel free to 
> > > > start a new thread about this here if you have strong opinions.
> > >
> > > Also note that it is possible (and not hard) to install packages from 
> > > source with an OpenMP-supporting compiler, and how to do so is in the 
> > > R-admin manual. The problems come in distributing them.
> > >
> > > The benefits of OpenMP are often overestimated, especially on 
> > > desktop/laptop level hardware. But it is available for the small (tiny?) 
> > > proportion of users who need it.
> > The University of Edinburgh is a charitable body, registered in Scotland, 
> > with registration number SC005336.
> > ___
> > 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

[[alternative HTML version deleted]]

___
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!

2020-04-02 Thread Patrick Schratz

R versions on macOS are installed next to each other - you just need to 
“switch” between them during initialization.
In the end R CMD * will use the R interpreter that is first in your $PATH.

https://rud.is/rswitch/ helps - but you can also do so without by writing 
custom CLI wrappers.
On 2. Apr 2020, 23:13 +0200, Spencer Graves , 
wrote:
>   Is there a procedure for dual install, e.g., so I could run "R4
> CMD check", etc.?
>
>
>   Please excuse if this has already been answered.
>
>
>   Thanks,
>   Spencer Graves
>
>
> On 2020-04-02 02:50, Rainer M Krug wrote:
> >
> > > On 1 Apr 2020, at 16:07, Patrick Schratz  
> > > wrote:
> > >
> > > The same goes here regarding support.
> > >
> > > I am (co-)maintaining a package on ropensci focusing on provider-agnostic 
> > > CI approaches for R (tic) and have quite some experience with all the 
> > > little culprits there.
> > >
> > > Since you mentioned Travis: Be aware that the R community is (slowly but 
> > > actively) moving away from Travis for a few reasons.
> > > Also on GitHub Actions you can only build on 10.15 (Catalina) right now.
> > So where is the R community moving too?
> >
> > Rainer
> >
> > > Best, Patrick
> > > On 1. Apr 2020, 15:41 +0200, Bob Rudis , wrote:
> > > > I shall pile on with an additional offer of assistance, Simon and a 
> > > > huge #ty for this and all the work you do.
> > > >
> > > > > On Apr 1, 2020, at 09:30, Balamuta, James Joseph 
> > > > >  wrote:
> > > > >
> > > > > Simon,
> > > > >
> > > > > Thanks for the overview! A few quick questions:
> > > > >
> > > > > 1. Compiler-wise, the external clang compiler requirement was removed 
> > > > > and, so, there is no guarantee of OpenMP on macOS again?
> > > > > 2. Why was 10.13 chosen as the oldest system instead of 10.14 given 
> > > > > the new push for increased security by Apple?
> > > > > 3. How likely is the oldest system requirement to be bumped in a 
> > > > > patch release?
> > > > >
> > > > > Also, if you need help with mac-builder, Travis, or GitHub Actions, 
> > > > > I'm more than happy to help!
> > > > >
> > > > > Best,
> > > > >
> > > > > JJB
> > > > >
> > > > > On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of Simon Urbanek" 
> > > > >  > > > > simon.urba...@r-project.org> 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://mac.R-project.org
> > > > >
> > > > > 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 
> > > > > http://mac.r-project.org/libs-4/
> > > > >
> > > > > The new R build system is in
> > > > > https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4
> > > > > Packages build system has not changed and is in
> > > > > https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages
> > > > >
> > > > > 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://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
> > > > ___
> > > > 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!

2020-04-02 Thread Spencer Graves

  Is there a procedure for dual install, e.g., so I could run "R4 
CMD check", etc.?



  Please excuse if this has already been answered.


  Thanks,
  Spencer Graves


On 2020-04-02 02:50, Rainer M Krug wrote:



On 1 Apr 2020, at 16:07, Patrick Schratz  wrote:

The same goes here regarding support.

I am (co-)maintaining a package on ropensci focusing on provider-agnostic CI 
approaches for R (tic) and have quite some experience with all the little 
culprits there.

Since you mentioned Travis: Be aware that the R community is (slowly but 
actively) moving away from Travis for a few reasons.
Also on GitHub Actions you can only build on 10.15 (Catalina) right now.

So where is the R community moving too?

Rainer


Best, Patrick
On 1. Apr 2020, 15:41 +0200, Bob Rudis , wrote:

I shall pile on with an additional offer of assistance, Simon and a huge #ty 
for this and all the work you do.


On Apr 1, 2020, at 09:30, Balamuta, James Joseph  wrote:

Simon,

Thanks for the overview! A few quick questions:

1. Compiler-wise, the external clang compiler requirement was removed and, so, 
there is no guarantee of OpenMP on macOS again?
2. Why was 10.13 chosen as the oldest system instead of 10.14 given the new 
push for increased security by Apple?
3. How likely is the oldest system requirement to be bumped in a patch release?

Also, if you need help with mac-builder, Travis, or GitHub Actions, I'm more 
than happy to help!

Best,

JJB

On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of 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://mac.R-project.org

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 http://mac.r-project.org/libs-4/

The new R build system is in
https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4
Packages build system has not changed and is in
https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages

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://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

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

--
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://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

Re: [R-SIG-Mac] OpenMP on CRAN

Tim,


> On 3/04/2020, at 2:01 AM, BATES Timothy  wrote:
> 
> Moving to a compiler that drops support for OpenMP seems a sad choice, 
> especially now we’ve all climbed the learning curve of the non-Apple compiler 
> (the real barrier was lack of a pkg installer and that’s done now).
> 

It has caused a lot of issues, it trips people on a daily basis which is just 
not worth it. Also with Apple's increasingly strict rules about what can be 
distributed we don't want to be in the business in maintaining a separate 
toolchain. There have been numerous issues with C++ exceptions so the fall out 
was much bigger than originally expected and it would only get worse.


> Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would be 
> a big loss for users (for whom the CRAN version now supports OpenMP giving 
> them a 2-12x speed up). In general, R on Mac is made more viable by having 
> OpenMP
> 
> Re Brian’s points, I’d say that the distribution problem is crucial: Packages 
> not on CRAN have dramatically diminished accessibility/useage.
> 

The idea is that if a package deems this critical, it can enable this for the 
users. As it is now, packages can still supply iomp and use it.

That said, I would open for discussion the ability to distribute iomp with the 
R binary, but it would not be supported by R directly, i.e., it would be on the 
package author to make sure that the way the package operates is compatible 
with that binary. Let me know what you think.


> Second, a great range of compute-intensive problems are amenable to division 
> amongst cores, including nearly all models that take more than a nominal 
> amount of time to run: So simulations, CIs, bootstrapping, nearly everything 
> in genetics all speeds up.
> 

Yes, but OpenMP is rarely used for those tasks. In R OpenMP can be only used 
for very small subset of such tasks - which is why alternative approaches are 
much more common.

Cheers,
Simon


> I’d say especially on desktop/laptop. The big advantage of multi blade 
> systems requires snowfall-type solutions, but desktops profit automatically 
> from their multi-core structure and don;’t have multiple processors (except 
> graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP is 
> their one trick. I’d hope not to lose it.
> 
> Best, t
> 
> 
>> On 2 Apr 2020, at 05:18, Prof Brian Ripley  wrote:
>> 
>> On 01/04/2020 22:02, Simon Urbanek wrote:
>>> JJB,
>>> 1. correct, there was too much trouble in this. But please feel free to 
>>> start a new thread about this here if you have strong opinions.
>> 
>> Also note that it is possible (and not hard) to install packages from source 
>> with an OpenMP-supporting compiler, and how to do so is in the R-admin 
>> manual.  The problems come in distributing them.
>> 
>> The benefits of OpenMP are often overestimated, especially on desktop/laptop 
>> level hardware.  But it is available for the small (tiny?) proportion of 
>> users who need it.
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336.
> ___
> 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

Re: [R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R

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
> 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
>

[R-SIG-Mac] Homebrew [was: from Mac to LInux?]

> On 2/04/2020, at 9:15 PM, Patrick Schratz  wrote:
> 
> AFAIK most people on that list would vote hard against installing R via 
> homebrew for several reasons - maybe there should be a section about this on 
> the R dev / CRAN page to address this topic, @Simon? Otherwise this will come 
> up again and again.
> 

That main objection is that people are mixing Homebrew with CRAN and vice-versa 
which leads to many problems. You cannot use packages from CRAN when using 
Homebrew, period, and you have to be really careful if you want to mix Homebrew 
libraries (not anything R-related) with CRAN (it is doable if you know what 
you're doing).

The fundamental issue is that package managers like Homebrew replace system 
libraries with their own (for new features/updates that the system libraries 
don't provide) which break anything that relies on the system library. Out of 
all the package managers Homebrew the only one that is trying to address the 
issue by trying to separate them, but even that has been diverging over time.

The second issue is that they are increasingly replacing toolchains (compilers) 
with their own builds, which makes everything incompatible in explosive ways 
(things just segfault). Making sure that a compiler toolchain is stable is 
actually non-trivial and many packager manager authors/maintainers have little 
experience with this. That used the be the primary reason to avoid them, 
because it was just normal that the released binaries were miscompiled and 
things would break all the time. Fortunately, I think that has gotten better 
over time.

If you stick only with Homebrew, then you're likely ok, but you're on your own 
and have to compile all packages form sources. Majority of our time as CRAN 
maintainers for the binary releases is about providing dependent libraries for 
packages and making sure things "just work". It is doable, just a lot of work, 
so by using Homebrew every user has to spend that time.

(FWIW I use Hombrew myself for tools, but not in /usr/local (I'm using 
/opt/brew) and I only put it on the PATH for the tools that I need, never to 
compile anything "native" against it.)

Cheers,
Simon

> Anyhow, this is also not relating to the initial topic of that thread and 
> should probably discussed separately.
> On 2. Apr 2020, 10:04 +0200, 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
>> 
>> 
>>> On 2 Apr 2020, at 02:37, Duncan Murdoch  wrote:
>>> 
>>> On 01/04/2020 2:48 p.m., 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?
>>> 
>>> If your iMac is still working, try installing Ubuntu or some other Linux on 
>>> it. I think at that age Apple is no longer providing upgrades, but I just 
>>> put Ubuntu on a 2008 iMac, and it works well. (I needed to upgrade the 
>>> memory, but that just cost $40 for 4 GB.)
>>> 
>>> So I got a $40 desktop, with a nice screen.
>>> 
>>> Duncan Murdoch
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> --
>> 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
>>

Re: [R-SIG-Mac] R-SIG-Mac Digest, Vol 205, Issue 13

2020-04-02 Thread Eberhard W Lisse

I think I will play with this over the weekend, especially if the calm before 
the storm prevails.

el

—
Sent from Dr Lisse’s iPad Mini 5
On 2 Apr 2020, 22:21 +0200, Duncan Murdoch , wrote:
> That lists "base" as a package, as well as the other base and
> recommended packages. That's not what Dr. Lisse was looking for: he
> wanted "all user installed (additional) packages, ie not the ones that
> come with R?".
>
> Duncan Murdoch
>
> On 02/04/2020 10:47 a.m., Colin A. Smith wrote:
> > This will do it as well:
> >
> > package_list <- tapply(rownames(installed.packages()), 
> > installed.packages()[,"LibPath"], c)
> >
> > Bonus to find out which library directories are writable by the user:
> >
> > file.access(names(package_list), mode=2) == 0
> >
> > Cheers,
> >
> > Colin
> >
> > > On Apr 2, 2020, at 10:36, Michael Hall  wrote:
> > >
> > > > On Apr 2, 2020, at 6:10 AM, r-sig-mac-requ...@r-project.org wrote:
> > > >
> > > > > Is there a way of (only) listing all user installed (additional)
> > > > > packages, ie not the ones that come with R?
> > >
> > > https://www.r-bloggers.com/list-of-user-installed-r-packages-and-their-versions/
> > >  
> > > 
> > >
> > > Sys.getenv()
> > > …
> > > R_LIBS_USER ~/Library/R/3.6/library
> > > …
> > >
> > > list.files('~/Library/R/3.6/library')
> > > [1] "alphavantager" "BBmisc" "brew" "C50"
> > > [5] "checkmate" "clisymbols" "coda" "commonmark”
> > > ...
> >
> > ___
> > 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

[[alternative HTML version deleted]]

___
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-SIG-Mac Digest, Vol 205, Issue 13

2020-04-02 Thread Duncan Murdoch

That lists "base" as a package, as well as the other base and 
recommended packages.  That's not what Dr. Lisse was looking for:  he 
wanted "all user installed (additional) packages, ie not the ones that 
come with R?".


Duncan Murdoch

On 02/04/2020 10:47 a.m., Colin A. Smith wrote:

This will do it as well:

package_list <- tapply(rownames(installed.packages()), 
installed.packages()[,"LibPath"], c)

Bonus to find out which library directories are writable by the user:

file.access(names(package_list), mode=2) == 0

Cheers,

Colin


On Apr 2, 2020, at 10:36, Michael Hall  wrote:


On Apr 2, 2020, at 6:10 AM, r-sig-mac-requ...@r-project.org wrote:


Is there a way of (only) listing all user installed (additional)
packages, ie not the ones that come with R?


https://www.r-bloggers.com/list-of-user-installed-r-packages-and-their-versions/ 


Sys.getenv()
…
R_LIBS_USER ~/Library/R/3.6/library
…

list.files('~/Library/R/3.6/library')
[1] "alphavantager" "BBmisc""brew"  "C50"
[5] "checkmate" "clisymbols""coda"  "commonmark”
...


___
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

Re: [R-SIG-Mac] OpenMP on CRAN

2020-04-02 Thread Balamuta, James Joseph

Kevin,

Simon discussed why they opted to avoid this back in June '19 when Jon Clayden 
brought up a similar success.

https://stat.ethz.ch/pipermail/r-sig-mac/2019-June/012998.html

The sentiment was using the system compiler is in manner is unsupported and 
works only on some systems. I'm not sure with the OS bump whether there still 
is disparity across 10.13/14/15.

That said, I do agree with Tim that it would be nice to have OpenMP enabled-by 
default. But, I'm also equally okay with it being disabled to simplify workflow 
and encourage more parallelization through snow/future as getting into 
parallelized compiled code with R has far more dragons afoot.

Best,

JJB

On 4/2/20, 12:05 PM, "R-SIG-Mac on behalf of Kevin Ushey" 
 wrote:

Hi,

For what it's worth, it looks like it is still possible to use OpenMP
on macOS with the system toolchain. Using the example file here:

https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c

I can compile + link + run this on macOS 10.15.4 and with:

$ /usr/bin/clang -Xpreprocessor -fopenmp
-I/usr/local/opt/libomp/include -L/usr/local/opt/libomp/lib -lomp
omp_hello.c

As for whether this is 'safe', or whether R could conceivably bundle
and use its own copy of libomp is a separate question I cannot answer.
But at least this is a mechanism for enterprising users to enable
OpenMP in packages built from source if they so desire.

Best,
Kevin

On Thu, Apr 2, 2020 at 6:01 AM BATES Timothy  wrote:
>
> Moving to a compiler that drops support for OpenMP seems a sad choice, 
especially now we’ve all climbed the learning curve of the non-Apple compiler 
(the real barrier was lack of a pkg installer and that’s done now).
>
> Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would 
be a big loss for users (for whom the CRAN version now supports OpenMP giving 
them a 2-12x speed up). In general, R on Mac is made more viable by having 
OpenMP
>
> Re Brian’s points, I’d say that the distribution problem is crucial: 
Packages not on CRAN have dramatically diminished accessibility/useage.
>
> Second, a great range of compute-intensive problems are amenable to 
division amongst cores, including nearly all models that take more than a 
nominal amount of time to run: So simulations, CIs, bootstrapping, nearly 
everything in genetics all speeds up.
>
> I’d say especially on desktop/laptop. The big advantage of multi blade 
systems requires snowfall-type solutions, but desktops profit automatically 
from their multi-core structure and don;’t have multiple processors (except 
graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP is 
their one trick. I’d hope not to lose it.
>
> Best, t
>
>
> > On 2 Apr 2020, at 05:18, Prof Brian Ripley  
wrote:
> >
> > On 01/04/2020 22:02, Simon Urbanek wrote:
> >> JJB,
> >> 1. correct, there was too much trouble in this. But please feel free 
to start a new thread about this here if you have strong opinions.
> >
> > Also note that it is possible (and not hard) to install packages from 
source with an OpenMP-supporting compiler, and how to do so is in the R-admin 
manual.  The problems come in distributing them.
> >
> > The benefits of OpenMP are often overestimated, especially on 
desktop/laptop level hardware.  But it is available for the small (tiny?) 
proportion of users who need it.
> The University of Edinburgh is a charitable body, registered in Scotland, 
with registration number SC005336.
> ___
> 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


___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] OpenMP on CRAN

2020-04-02 Thread Kevin Ushey

Hi,

For what it's worth, it looks like it is still possible to use OpenMP
on macOS with the system toolchain. Using the example file here:

https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c

I can compile + link + run this on macOS 10.15.4 and with:

$ /usr/bin/clang -Xpreprocessor -fopenmp
-I/usr/local/opt/libomp/include -L/usr/local/opt/libomp/lib -lomp
omp_hello.c

As for whether this is 'safe', or whether R could conceivably bundle
and use its own copy of libomp is a separate question I cannot answer.
But at least this is a mechanism for enterprising users to enable
OpenMP in packages built from source if they so desire.

Best,
Kevin

On Thu, Apr 2, 2020 at 6:01 AM BATES Timothy  wrote:
>
> Moving to a compiler that drops support for OpenMP seems a sad choice, 
> especially now we’ve all climbed the learning curve of the non-Apple compiler 
> (the real barrier was lack of a pkg installer and that’s done now).
>
> Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would be 
> a big loss for users (for whom the CRAN version now supports OpenMP giving 
> them a 2-12x speed up). In general, R on Mac is made more viable by having 
> OpenMP
>
> Re Brian’s points, I’d say that the distribution problem is crucial: Packages 
> not on CRAN have dramatically diminished accessibility/useage.
>
> Second, a great range of compute-intensive problems are amenable to division 
> amongst cores, including nearly all models that take more than a nominal 
> amount of time to run: So simulations, CIs, bootstrapping, nearly everything 
> in genetics all speeds up.
>
> I’d say especially on desktop/laptop. The big advantage of multi blade 
> systems requires snowfall-type solutions, but desktops profit automatically 
> from their multi-core structure and don;’t have multiple processors (except 
> graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP is 
> their one trick. I’d hope not to lose it.
>
> Best, t
>
>
> > On 2 Apr 2020, at 05:18, Prof Brian Ripley  wrote:
> >
> > On 01/04/2020 22:02, Simon Urbanek wrote:
> >> JJB,
> >> 1. correct, there was too much trouble in this. But please feel free to 
> >> start a new thread about this here if you have strong opinions.
> >
> > Also note that it is possible (and not hard) to install packages from 
> > source with an OpenMP-supporting compiler, and how to do so is in the 
> > R-admin manual.  The problems come in distributing them.
> >
> > The benefits of OpenMP are often overestimated, especially on 
> > desktop/laptop level hardware.  But it is available for the small (tiny?) 
> > proportion of users who need it.
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336.
> ___
> 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

Re: [R-SIG-Mac] R-SIG-Mac Digest, Vol 205, Issue 13

2020-04-02 Thread peter dalgaard

> On 2 Apr 2020, at 16:47 , Colin A. Smith  wrote:
> 
> tapply(rownames(installed.packages()), installed.packages()[,"LibPath"], c)

or

X <- installed.packages()
split(rownames(X), X[,"LibPath"])


-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@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] R-SIG-Mac Digest, Vol 205, Issue 13

2020-04-02 Thread Colin A. Smith

This will do it as well:

package_list <- tapply(rownames(installed.packages()), 
installed.packages()[,"LibPath"], c)

Bonus to find out which library directories are writable by the user:

file.access(names(package_list), mode=2) == 0

Cheers,

Colin

> On Apr 2, 2020, at 10:36, Michael Hall  wrote:
> 
>> On Apr 2, 2020, at 6:10 AM, r-sig-mac-requ...@r-project.org wrote:
>> 
>>> Is there a way of (only) listing all user installed (additional)
>>> packages, ie not the ones that come with R?
> 
> https://www.r-bloggers.com/list-of-user-installed-r-packages-and-their-versions/
>  
> 
> 
> Sys.getenv()
> …
> R_LIBS_USER ~/Library/R/3.6/library
> …
> 
> list.files('~/Library/R/3.6/library')
> [1] "alphavantager" "BBmisc""brew"  "C50"  
> [5] "checkmate" "clisymbols""coda"  "commonmark”   
> ...

___
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-SIG-Mac Digest, Vol 205, Issue 13

2020-04-02 Thread Michael Hall




> On Apr 2, 2020, at 6:10 AM, r-sig-mac-requ...@r-project.org wrote:
> 
>> Is there a way of (only) listing all user installed (additional)
>> packages, ie not the ones that come with R?

https://www.r-bloggers.com/list-of-user-installed-r-packages-and-their-versions/
 


Sys.getenv()
…
R_LIBS_USER ~/Library/R/3.6/library
…

list.files('~/Library/R/3.6/library')
 [1] "alphavantager" "BBmisc""brew"  "C50"  
 [5] "checkmate" "clisymbols""coda"  "commonmark”   
...
[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Homebrew

Rainer,

I am definitively interested.

But, as a disclaimer, I am an elderly Gynecologist only dabbling in R
and a little in Perl :-)-O. 

el

On 02/04/2020 12: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://github.com/rkrug/install
> 
> 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
[...]

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421  \  / If this email is signed with GPG/PGP
Bachbrecht 10007, Namibia ;/ Section 20 of Act No. 4 of 2019 may apply

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] OpenMP on CRAN

2020-04-02 Thread BATES Timothy

Moving to a compiler that drops support for OpenMP seems a sad choice, 
especially now we’ve all climbed the learning curve of the non-Apple compiler 
(the real barrier was lack of a pkg installer and that’s done now).

Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would be a 
big loss for users (for whom the CRAN version now supports OpenMP giving them a 
2-12x speed up). In general, R on Mac is made more viable by having OpenMP

Re Brian’s points, I’d say that the distribution problem is crucial: Packages 
not on CRAN have dramatically diminished accessibility/useage.

Second, a great range of compute-intensive problems are amenable to division 
amongst cores, including nearly all models that take more than a nominal amount 
of time to run: So simulations, CIs, bootstrapping, nearly everything in 
genetics all speeds up.

I’d say especially on desktop/laptop. The big advantage of multi blade systems 
requires snowfall-type solutions, but desktops profit automatically from their 
multi-core structure and don;’t have multiple processors (except graphics, 
which no-one seems to be exploiting on CRAN-style R), so OpenMP is their one 
trick. I’d hope not to lose it.

Best, t

> On 2 Apr 2020, at 05:18, Prof Brian Ripley  wrote:
>
> On 01/04/2020 22:02, Simon Urbanek wrote:
>> JJB,
>> 1. correct, there was too much trouble in this. But please feel free to 
>> start a new thread about this here if you have strong opinions.
>
> Also note that it is possible (and not hard) to install packages from source 
> with an OpenMP-supporting compiler, and how to do so is in the R-admin 
> manual.  The problems come in distributing them.
>
> The benefits of OpenMP are often overestimated, especially on desktop/laptop 
> level hardware.  But it is available for the small (tiny?) proportion of 
> users who need it.
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Homebrew

Argument for homebrew:

brew upgrade

which will figure out what needs to be upgraded so I don't have 
manually keep track of it.


BTW, it usually pulls the binary, and these have worked without any 
issues for many years, the last time something went wrong on the 
Download and it pulled the source. I don't care either way.

Packages must be installed from source, but not as source. R will look 
for the package on CRAN like any other and usually takes the binary, 
sometimes asking whether it should take a (newer) source )of the 
package)

The first run of (re-)installing additional packages does indeed take 
some time, but it doesn't happen often.

The point is that there is a channel for issues with homebrew packages 
but few people (especially when desperate) will take the time :-)-O

greetings, el

 02/04/2020 13:09, Rainer M Krug wrote:
> 
> 
>> On 2 Apr 2020, at 12:56, Hervé Pagès  wrote:
>>
>> 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.
> 
> Arguments against homebrew:
> 
> Not an official response, but in the past, homebrew was compiling
> everything on the local machine.  This is not the case anymore, and
> the default installation in homebrew, installs a binary.
> 
> All packages need to be installed from source.  This takes time, but I
> had no problems with any of the packages I use.
> 
> Just some tidbits from previous discussions.
> 
> But I would like to also hear the official reason (no resources would
> be a good enough justification as well).
> 
> Arguments for homebrew:
> 
> it is more Linux like, in the way that you have more control over the
> tools used.  e.g. when still using the official R installation, I
> regularly used different versions of GDAL in R, GRASS, …, which can
> cause inconsistencies.
> 
> The installation is done without requiring root privileges, which is a
> big advantage (as I see it).
> 
> 
> 
> Cheers,
> 
> Rainer
[...]

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421  \  / If this email is signed with GPG/PGP
Bachbrecht 10007, Namibia ;/ Section 20 of Act No. 4 of 2019 may apply

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Homebrew




> On 2 Apr 2020, at 12:56, Hervé Pagès  wrote:
> 
> 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.

Arguments against homebrew:

Not an official response, but in the past, homebrew was compiling everything on 
the local machine. This is not the case anymore, and the default installation 
in homebrew, installs a binary. 

All packages need to be installed from source. This takes time, but I had no 
problems with any of the packages I use.

Just some tidbits from previous discussions.

But I would like to also hear the official reason (no resources would be a good 
enough justification as well).

Arguments for homebrew: 

it is more Linux like, in the way that you have more control over the tools 
used. e.g. when still using the official R installation, I regularly used 
different versions of GDAL in R, GRASS, …, which can cause inconsistencies.

The installation is done without requiring root privileges, which is a big 
advantage (as I see it).



Cheers,

Rainer


> 
> 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

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] Homebrew




> 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://github.com/rkrug/install

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://cloud.r-project.org/;
>>> 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://stat.ethz.ch/mailman/listinfo/r-sig-mac

--
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://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Homebrew

2020-04-02 Thread Duncan Murdoch


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?


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.


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.


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://cloud.r-project.org/;
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://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Homebrew

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 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://cloud.r-project.org/;
>   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

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421  \  / If this email is signed with GPG/PGP
Bachbrecht 10007, Namibia ;/ Section 20 of Act No. 4 of 2019 may apply

___
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] Transitioning from Mac to LInux?

2020-04-02 Thread Rainer Krug




> On 2 Apr 2020, at 10:15, Patrick Schratz  wrote:
> 
> AFAIK most people on that list would vote hard against installing R via 
> homebrew for several reasons - maybe there should be a section about this on 
> the R dev / CRAN page to address this topic, @Simon? Otherwise this will come 
> up again and again.

I think there is - at least it is clear to me (that is why I said “no support 
from here”). Although I do not see the problem why, which is a different topic 
altogether.

I was fully aware of the opposition to my way of using R (homebrew), but I 
decided to post it anyway, as I think it is a valid and useful approach 
(different discussion!).


> 
> Anyhow, this is also not relating to the initial topic of that thread and 
> should probably discussed separately.

The OP states:

 I'm wondering whether replacing my iMac (2009) with a new Mac really makes 
sense from an R - user point of view

Which I think is addressed in my post.

Cheers,

Rainer



> On 2. Apr 2020, 10:04 +0200, 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
>> 
>> 
>>> On 2 Apr 2020, at 02:37, Duncan Murdoch  wrote:
>>> 
>>> On 01/04/2020 2:48 p.m., 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?
>>> 
>>> If your iMac is still working, try installing Ubuntu or some other Linux on 
>>> it. I think at that age Apple is no longer providing upgrades, but I just 
>>> put Ubuntu on a 2008 iMac, and it works well. (I needed to upgrade the 
>>> memory, but that just cost $40 for 4 GB.)
>>> 
>>> So I got a $40 desktop, with a nice screen.
>>> 
>>> Duncan Murdoch
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> --
>> 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://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac



[[alternative HTML version deleted]]

___
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

2020-04-02 Thread Prof Brian Ripley

On 02/04/2020 09:34, Simon Urbanek wrote:

Hervé,

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.

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://cran.r-project.org;) :
type == "both" can only be used on Windows or a CRAN build for macOS

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

--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

___
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.

On 4/2/20 01:34, Simon Urbanek wrote:

Hervé,

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

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

Re: [R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R

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://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
> 

___
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?



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://cloud.r-project.org/;
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://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Transitioning from Mac to LInux?

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


> On 2 Apr 2020, at 02:37, Duncan Murdoch  wrote:
> 
> On 01/04/2020 2:48 p.m., 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?
> 
> If your iMac is still working, try installing Ubuntu or some other Linux on 
> it.  I think at that age Apple is no longer providing upgrades, but I just 
> put Ubuntu on a 2008 iMac, and it works well.  (I needed to upgrade the 
> memory, but that just cost $40 for 4 GB.)
> 
> So I got a $40 desktop, with a nice screen.
> 
> Duncan Murdoch
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

--
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://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Please test R 4.0.0 pre-releases!




> On 1 Apr 2020, at 16:07, Patrick Schratz  wrote:
> 
> The same goes here regarding support.
> 
> I am (co-)maintaining a package on ropensci focusing on provider-agnostic CI 
> approaches for R (tic) and have quite some experience with all the little 
> culprits there.
> 
> Since you mentioned Travis: Be aware that the R community is (slowly but 
> actively) moving away from Travis for a few reasons.
> Also on GitHub Actions you can only build on 10.15 (Catalina) right now.

So where is the R community moving too?

Rainer

> 
> Best, Patrick
> On 1. Apr 2020, 15:41 +0200, Bob Rudis , wrote:
>> I shall pile on with an additional offer of assistance, Simon and a huge #ty 
>> for this and all the work you do.
>> 
>>> On Apr 1, 2020, at 09:30, Balamuta, James Joseph  
>>> wrote:
>>> 
>>> Simon,
>>> 
>>> Thanks for the overview! A few quick questions:
>>> 
>>> 1. Compiler-wise, the external clang compiler requirement was removed and, 
>>> so, there is no guarantee of OpenMP on macOS again?
>>> 2. Why was 10.13 chosen as the oldest system instead of 10.14 given the new 
>>> push for increased security by Apple?
>>> 3. How likely is the oldest system requirement to be bumped in a patch 
>>> release?
>>> 
>>> Also, if you need help with mac-builder, Travis, or GitHub Actions, I'm 
>>> more than happy to help!
>>> 
>>> Best,
>>> 
>>> JJB
>>> 
>>> On 3/31/20, 11:59 PM, "R-SIG-Mac on behalf of 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://mac.R-project.org
>>> 
>>> 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 http://mac.r-project.org/libs-4/
>>> 
>>> The new R build system is in
>>> https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4
>>> Packages build system has not changed and is in
>>> https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages
>>> 
>>> 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://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
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

--
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://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] R 4.0 toolchain

2020-04-02 Thread Patrick Schratz

Thanks Simon.
Branching off here to discuss the toolchain in general.
I see the danger posting not 100% correct scripts and in blog posts in general 
because they might get outdated and not always reflect the official 
documentation.
On the other side: What is the middle way? Arguably installing a robust 
toolchain (on Catalina especially but for macOS in general) is not just done 
with the installation of the signed package.
Most normal users are not aware about all the little specialties on macOS 
(missing openMP enabled compiler, SDK issues) and why adjustments might be 
needed.

Even though the idea is to require as less manual configuration as possible, 
this is not always practical in the end (unless all maintainers agree on 
configuring their package without the need of an openMP enabled C compiler for 
example).
And I also think that “installing from source” is not a dev-only thing.

1. By using the Apple internal clang as the default, will maintainers be 
indirectly forced to remove the dependency on an openMP enabled compiler with 
respect to getting source installations on macOS working?
2. Can there be an official section easily accessible for users which 
recommends which compiler to use (and how to set the Makevars) if users really 
need/want to do so?
a. Regarding openMP enabled compilers: llvm is probably the one with the 
least differences to Apples clang. It can be installed via brew (brew install 
llvm) and then linked in Makevars. Would that be an alternative?
3. SDK: I did not wanted to induce that setting the SDK vars is needed for the 
CRAN build chain (maybe we got each other wrong here). However, as of now, 
there are real issues with SDK 10.15 that result in errors that are really hard 
to track down or even fall under the radar when testing (if someone does not 
run Catalina). Therefore I am linking locally against SDK 10.13 since some days 
and that resolved many issues (see again the Rcpp issue and the igraph issue). 
Since Catalina is the latest release and many people run it there should be 
test/instructions somewhere on mac.rproject that deal with this/suggest not to 
use SDK 10.15 for R IMO. Maybe this issue deserves a special thread.

Cheers, Patrick

On 1. Apr 2020, 22:29 +0200, Simon Urbanek , wrote:
> Patrick,
>
> firstly, please don't post such things - they are often wrong (as are parts 
> of what you included it this e-mail) and it's impossible for us to track all 
> blogs that have incorrect advice. Unfortunately, a lot of the issues we see 
> out there are due to people finding bad advice and using it. Ideally, it 
> should be sufficient to point to the official R documentation since that is 
> the canonical source. If you post a blog, it should point to the official 
> documentation. If that documentation is missing or not covering a need, 
> please post here so we can fix it. It is more important that the official 
> source is complete and much better for the community than to have random 
> tidbits that may or may not be correct floating around.
>
> As for the script, please do not use R tar balls - first, you're picking the 
> wrong one (there is no R-devel for el-capitan. R 4.0.0 pre-releases are in 
> R-4-0-branch and they are built for high sierra). Second, the tar ball 
> doesn't have the entitlements enabled so it doesn't match the release. Please 
> use the signed R package. This may change, but with the complications of the 
> Apple notarization process that's what it is today.
>
> Then there is the question of the SDK. What are you trying to setup here? 
> What you posted here has nothing to do with the CRAN setup. You don't need 
> 10.13 SDK to compile igraph, it compiles just fine using stock command line 
> tools on High Sierra which is what we use on CRAN. You can, of course, pick 
> any SDK you like, but please don't tell people that's what they should do. 
> One of the most annoying issues is that people are recommending messing with 
> Makevars which is incredibly fragile and will cause things to break left and 
> right with any update. It's ok to do that for a very special purpose, but no 
> regular user should have Makevars in their home.
>
> So if you really want to serve the community, please suggest improvements to 
> the official documentation and post them here. If you have special needs, ask 
> about them here.
>
> Thanks,
> Simon
>
>
>
> > On 1/04/2020, at 9:47 PM, Patrick Schratz  wrote:
> >
> > Thanks Simon,
> >
> > This simplifies things a lot and clears up the process. While the 
> > instructions on https://mac.r-project.org/ are more clear now I think there 
> > is still simplification needed for the install process and custom 
> > modifications that are needed.
> > This not only applies to the dev page but finally also to production end 
> > users if the SDK 10.15 issues (see below) persists.
> >
> > I’ve scripted all installation steps (R-devel, gfortran, SDK 10.13) and 
> > will probably write a blog post about it to make

[R-SIG-Mac] Installing CRAN binary packages with R 4.0 installed from source crashes R