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
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
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.
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
> 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
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
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
Thanks! Now fixed.
Simon
> On 2/04/2020, at 4:08 AM, Bob Rudis wrote:
>
> 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:
>
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
> On 2/04/2020, at 3:07 AM, Patrick Schratz wrote:
>
> The same goes here regarding support.
>
> I am (co-)maintaining a package on
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
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
I see bin/macosx/contrib/4.0/ now (e.g.
https://cran.r-project.org/bin/macosx/contrib/4.0/). Thanks!
H.
On 4/1/20 00:37, Simon Urbanek wrote:
Hervé,
On 1/04/2020, at 6:19 PM, Hervé Pagès wrote:
Thanks Simon. A couple of days ago we've started to use the R 4.0.0 alpha build from
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
Hello JJB,
Den 2020-04-01 kl. 15:30, skrev 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
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)
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
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
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
Hervé,
> On 1/04/2020, at 6:19 PM, Hervé Pagès wrote:
>
> Thanks Simon. A couple of days ago we've started to use the R 4.0.0 alpha
> build from https://mac.r-project.org/ for the Bioconductor build system.
> Bioconductor packages depend on thousands of CRAN packages and one thing that
>
Thanks Simon. A couple of days ago we've started to use the R 4.0.0
alpha build from https://mac.r-project.org/ for the Bioconductor build
system. Bioconductor packages depend on thousands of CRAN packages and
one thing that makes it hard for us and for our users to build/check
Bioconductor
20 matches
Mail list logo
