Skip to content

Please test R 4.0.0 pre-releases!

20 messages · Simon Urbanek, Patrick Schratz, Göran Broström +8 more

Original
Simon Urbanek
# 
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
Balamuta, James Joseph
# 
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" <r-sig-mac-bounces at r-project.org on behalf of simon.urbanek at 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 at r-project.org
    https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Bob Rudis
# 
I shall pile on with an additional offer of assistance, Simon and a huge #ty for this and all the work you do.
Patrick Schratz
# 
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.

Best, Patrick
On 1. Apr 2020, 15:41 +0200, Bob Rudis <bob at rud.is>, wrote:

  
  


  


      

    

    

      
      

        


  

        

      Göran Broström
    

    

      
      #
    

  


  

      
Hello JJB,

Den 2020-04-01 kl. 15:30, skrev Balamuta, James Joseph:

            

      
      
      
    

        
One reason is that I am on 10.13(.6) without possibility to upgrade to 
10.14 (MacBook Pro & Air, 2010).

            

      
      
      
    

        
Hopefully very unlikely;)

Best, G?ran

PS. I have installed and run the 4.0.0 binary without any problem (so far).

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Bob Rudis
    

    

      
      #
    

  


  

      
Hey Simon!

At the bottom of https://mac.r-project.org/libs-4/ is:

    curl -O http://mac.R_project.org/libs-4/pkgconfig-0.28-darwin.17-x86_64.tar.gz

While most folks will figure it out, it should be:

    curl -O http://mac.R-project.org/libs-4/pkgconfig-0.28-darwin.17-x86_64.tar.gz

(dash instead of underline).

-boB

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
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.

2. we're talking about the oldest system that our binaries will run on, so 10.13 is actually very aggressive. There is still a very significant portion of users that have older versions of macOS and cannot upgrade. Apple is interested in selling new products, we are interested in supporting people that need a statistical software regardless of their income.

3. not at all. As I said, 10.13 is already way too high, in fact we picked it precisely so we don't need to change it for several years.

Just to make sure we're clear - it's ok to use Catalina to build binaries for let's say macOS 10.11, so it's not about what system you use to build. It is about who is able to use the resulting software. The current R builds are actually running on Catalina.

Thanks for your offer, it would be very helpful. Travis would be a good start - it needs command line tools, GNU fortran from
https://github.com/fxcoudert/gfortran-for-macOS/releases/download/8.2/gfortran-8.2-Mojave.dmg
the binaries from
http://mac.r-project.org/libs-4/
and there is actually a machine-readable list in
http://mac.r-project.org/libs-4/INDEX
and R from
http://mac.r-project.org/high-sierra/R-4.0-branch/R-4.0-branch.pkg

Thanks,
Simon

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Patrick, Bob et al ,

thanks! Please start a new thread here about CI builds - I'm open to whatever the best or most popular options are.

Thanks,
Simon

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Thanks! Now fixed.
Simon

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Balamuta, James Joseph
    

    

      
      #
    

  


  

      
Simon,

Thank you for the quick response!

            

      
      
      
    

        
Best news leading into R 4.0.0.

            

      
      
      
    

        
Okay.

            

      
      
      
    

        
Agreed. When I asked this question, I was worried about the backwards compatibility issues arising from the new security model enacted on 10.14/10.15 that caused installer signing problems in R 3.6.3.

            

      
      
      
    

        
Great to hear 10.13 will be the default for several years to come! As an added benefit, it is the last version with support for NVIDIA eGPUs.

Regarding Travis, I'll update the build script here with the new changes.

https://github.com/travis-ci/travis-build/blob/ab196aed5b227288a2f4dcb5c7822868b430b110/lib/travis/build/script/r.rb 

Best,

JJB

        
?On 4/1/20, 4:03 PM, "Simon Urbanek" <simon.urbanek at R-project.org> 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.
    
    2. we're talking about the oldest system that our binaries will run on, so 10.13 is actually very aggressive. There is still a very significant portion of users that have older versions of macOS and cannot upgrade. Apple is interested in selling new products, we are interested in supporting people that need a statistical software regardless of their income.
    
    3. not at all. As I said, 10.13 is already way too high, in fact we picked it precisely so we don't need to change it for several years.
    
    Just to make sure we're clear - it's ok to use Catalina to build binaries for let's say macOS 10.11, so it's not about what system you use to build. It is about who is able to use the resulting software. The current R builds are actually running on Catalina.
    
    Thanks for your offer, it would be very helpful. Travis would be a good start - it needs command line tools, GNU fortran from
    https://github.com/fxcoudert/gfortran-for-macOS/releases/download/8.2/gfortran-8.2-Mojave.dmg
    the binaries from
    http://mac.r-project.org/libs-4/
    and there is actually a machine-readable list in
    http://mac.r-project.org/libs-4/INDEX
    and R from
    http://mac.r-project.org/high-sierra/R-4.0-branch/R-4.0-branch.pkg
    
    Thanks,
    Simon

        
> On 2/04/2020, at 2:30 AM, Balamuta, James Joseph <balamut2 at illinois.edu> 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" <r-sig-mac-bounces at r-project.org on behalf of simon.urbanek at 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 at r-project.org
    >    https://stat.ethz.ch/mailman/listinfo/r-sig-mac
    > 
    > 
    > _______________________________________________
    > R-SIG-Mac mailing list
    > R-SIG-Mac at r-project.org
    > https://stat.ethz.ch/mailman/listinfo/r-sig-mac

  
  


  


      

    

    

      
      

        


  

        

      Balamuta, James Joseph
    

    

      
      #
    

  


  

      
Simon,

I sent a PR that updates the Travis CI to use the R 4.0.0 branch as R-devel and new gfortran binaries.

https://github.com/travis-ci/travis-build/pull/1885

I'm waiting to hear back from the community maintainers if they are interested in pulling in binaries from 

http://mac.r-project.org/libs-4/

Best,

JJB

?On 4/1/20, 5:01 PM, "R-SIG-Mac on behalf of Balamuta, James Joseph" <r-sig-mac-bounces at r-project.org on behalf of balamut2 at illinois.edu> wrote:

    Simon,
    
    Thank you for the quick response! 
    
    >  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.
    
    Best news leading into R 4.0.0.
    
    > 2.  we're talking about the oldest system that our binaries will run on, so 10.13 is actually very aggressive.
    
    Okay.  
    
    > There is still a very significant portion of users that have older versions of macOS and cannot upgrade. Apple is interested in selling new products, we are interested in supporting people that need a statistical software regardless of their income.
    
    Agreed. When I asked this question, I was worried about the backwards compatibility issues arising from the new security model enacted on 10.14/10.15 that caused installer signing problems in R 3.6.3.
    
    >    3. not at all. As I said, 10.13 is already way too high, in fact we picked it precisely so we don't need to change it for several years.
    
    Great to hear 10.13 will be the default for several years to come! As an added benefit, it is the last version with support for NVIDIA eGPUs.
    
    Regarding Travis, I'll update the build script here with the new changes.
    
    https://github.com/travis-ci/travis-build/blob/ab196aed5b227288a2f4dcb5c7822868b430b110/lib/travis/build/script/r.rb 
    
    Best,
    
    JJB

        
On 4/1/20, 4:03 PM, "Simon Urbanek" <simon.urbanek at R-project.org> 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.
        
        2. we're talking about the oldest system that our binaries will run on, so 10.13 is actually very aggressive. There is still a very significant portion of users that have older versions of macOS and cannot upgrade. Apple is interested in selling new products, we are interested in supporting people that need a statistical software regardless of their income.
        
        3. not at all. As I said, 10.13 is already way too high, in fact we picked it precisely so we don't need to change it for several years.
        
        Just to make sure we're clear - it's ok to use Catalina to build binaries for let's say macOS 10.11, so it's not about what system you use to build. It is about who is able to use the resulting software. The current R builds are actually running on Catalina.
        
        Thanks for your offer, it would be very helpful. Travis would be a good start - it needs command line tools, GNU fortran from
        https://github.com/fxcoudert/gfortran-for-macOS/releases/download/8.2/gfortran-8.2-Mojave.dmg
        the binaries from
        http://mac.r-project.org/libs-4/
        and there is actually a machine-readable list in
        http://mac.r-project.org/libs-4/INDEX
        and R from
        http://mac.r-project.org/high-sierra/R-4.0-branch/R-4.0-branch.pkg
        
        Thanks,
        Simon

        
> On 2/04/2020, at 2:30 AM, Balamuta, James Joseph <balamut2 at illinois.edu> 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" <r-sig-mac-bounces at r-project.org on behalf of simon.urbanek at 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 at r-project.org
        >    https://stat.ethz.ch/mailman/listinfo/r-sig-mac
        > 
        > 
        > _______________________________________________
        > R-SIG-Mac mailing list
        > R-SIG-Mac at r-project.org
        > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
        
        
    
    _______________________________________________
    R-SIG-Mac mailing list
    R-SIG-Mac at r-project.org
    https://stat.ethz.ch/mailman/listinfo/r-sig-mac

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On 01/04/2020 22:02, Simon Urbanek wrote:

            

      
      
      
    

        
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.

            

      
      
      
    

        
And 3.6.x running on >= 10.11 will be (we intend) supported with binary 
packages for another year.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Rainer M Krug
    

    

      
      #
    

  


  

          

      
      
      
    

        
So where is the R community moving too?

Rainer

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Orcid ID: 0000-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.Krug at uzh.ch
		Rainer at krugs.de
Skype:     RMkrug

PGP: 0x0F52F982

  
  


  


      

    

    

      
      

        


  

        

      Timothy Bates
    

    

      
      #
    

  


  

      
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

            

      
      
      
    

        
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

  
  


  


      

    

    

      
      

        


  

        

      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 <tim.bates at ed.ac.uk> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      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" <r-sig-mac-bounces at r-project.org on behalf of kevinushey at gmail.com> 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 <tim.bates at ed.ac.uk> 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 <ripley at stats.ox.ac.uk> 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 at r-project.org
    > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
    
    _______________________________________________
    R-SIG-Mac mailing list
    R-SIG-Mac at r-project.org
    https://stat.ethz.ch/mailman/listinfo/r-sig-mac

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Tim,

            

      
      
      
    

        
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.

            

      
      
      
    

        
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.

            

      
      
      
    

        
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

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      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:

            

      
      
      
    

        

      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
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

            

      
      
      
    

        

      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Berend Hasselman
    

    

      
      #
    

  


  

      
Simon,

I have tested an R-4.0.0 (i.e. R version 4.0.0 alpha (2020-04-01 r78130)
with my two packages (nleqslv and geigen) and all my private tests.
I have not found any problems with checking and testing these packages.
(I used Apple clang and Coudert's gfortran 8.2)

The only issue I have encountered is:

The R GUI hangs when I click "What's New In This Version" in the Help menu item.

Berend

            

      
      
      
    

        
R version 4.0.0 alpha (2020-04-01 r78130)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.4

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib

locale:
[1] en_IE.UTF-8/en_IE.UTF-8/en_IE.UTF-8/C/en_IE.UTF-8/en_IE.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