Re: [R-SIG-Mac] Problem R-4.0 beta and Rmpfr (pre-release)

Carsten and Berend, It means your CPU doesn't support the instructions used, so your Mac is likely older. Can you, please, post the output of system_profiler SPHardwareDataType Thanks, Simon > On 16/04/2020, at 7:21 PM, carsten.dorm...@biom.uni-freiburg.de wrote: > > Can confirm problem: >

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

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

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

Thanks for the confirmation, Brian. I wasn't aware that Gtk+2 was abandoned for so long - then our 2.24.17 binaries are in fact quite reasonable and I'll go with that. Thanks, Simon > On 4/04/2020, at 9:11 PM, Prof Brian Ripley wrote: > > On 04/04/2020 05:15, Tom Elliott wrote: >> Simon,

Re: [R-SIG-Mac] [Rd] Rebuilding and re-checking of downstream dependencies on CRAN Mac build machines

^ > > This issue describes the same problem: > https://github.com/RcppCore/Rcpp/issues/1046 > > And it has been fixed in the development version of Rcpp by: > https://github.com/RcppCore/Rcpp/pull/1047 > > I know that Kevin Ushey has tried building wit

Re: [R-SIG-Mac] R devel == 4.0.0?

Constantin, no, as you can see from the log the regression tests failed for R-devel, so it doesn't currently build. You'll have to wait until that has been fixed. Cheers, Simon > On 26/03/2020, at 4:17 AM, Constantin Ahlmann-Eltze via R-SIG-Mac > wrote: > > Hi, > > I wanted to install R

[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

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

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

[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

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

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

gt;>>>> >>>>> 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 >>&g

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

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

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

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

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

Rainer, > On 3/04/2020, at 10:01 PM, Rainer M Krug wrote: > > Thanks a lot for your detailed response - it is very much appreciated. > >> On 2 Apr 2020, at 22:30, Simon Urbanek wrote: >> >> >> >>> On 2/04/2020, at 9:15 PM, Patrick Schratz w

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

rying to jump into the future - but this ist just an idea :) > That's an entirely different, unrelated topic. Testing cutting edge (or even pre-release) systems makes sense, but that's not our current worry (there was a separate thread about CI). Cheers, Simon > Thanks for your wo

Re: [R-SIG-Mac] out of date value at http://cran.r-project.org/bin/macosx/VERSION

Tim, thanks, now updated. R 3.6.3 was a bit problematic due the Apple changes, notarization and Catalina issues, but hopefully things have calmed down by now. Thanks, Simon > On 28/03/2020, at 2:53 PM, Timothy Bates wrote: > > http://cran.r-project.org/bin/macosx/VERSION > > is out of

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

, the package type is back to "mac.binary", so bin/macosx/contrib is the location. Cheers, Simon > Thanks! > H. > > > On 3/31/20 21:27, Simon Urbanek wrote: >> Dear Mac users, >> R 4.0.0 will be using an entirely new toolchain, entirely new build system &

Re: [R-SIG-Mac] contrib/3.5 and contrib/3.6 empty

Martin, thanks, yes, el-capitan builds end with 3.6 so I have removed 3.7 and r-devel. Your subject got me scared ;) Cheers, Simon > On 31/03/2020, at 9:02 AM, Martin Maechler wrote: > >> Bob Rudis >>on Thu, 26 Mar 2020 09:44:39 -0400 writes: > >> Simon (et al), >> FYI Ref:

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

/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk > CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk > > In addition there really seem to be major problems regarding the 10.15 SDK. > For example, {igraph} which is a package on which lots of other packages >

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

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

Re: [R-SIG-Mac] PCRE JIT compilation error

Bryan, thanks! There seems to be an issue with PCRE2 JIT on Mojave. I have now disabled JIT in PCRE2 which seems to be the recommended fix I have built the latest version of R 4.0.0 alpha - it is now available from http://mac.r-project.org/high-sierra/R-4.0-branch/R-4.0-branch.pkg as usual.

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

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

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

iven 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! >> &

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

Carl, I would argue that you won't really gain anything - if you use R the Linux-way (build R from sources), it would be the same on macOS and Linux - and some people do that. So for R I don't think there is a difference. I'm using Linux for everything other than my desktop/laptop and the main

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

Re: [R-SIG-Mac] Using XQuartz - any known issues?

Just a quick note in the hopes that is may be helpful: X11 (fontconfig, really) creates a font cache the first time is it started which can take substantial time depending on hardware (HDD vs SSD...) during which XQuartz doesn't respond. So I wouldn't be surprised if that was actually

Re: [R-SIG-Mac] [Rd] R not running under lldb? (osx)

Tim, as a security precaution Apple has disabled the ability to debug notarized applications*. It means any software distributed on macOS Catalina (and they may have retro-actively enabled it for recent updates of Mojave) cannot be run in a debugger. If you want to debug R, you have to use

Re: [R-SIG-Mac] Using XQuartz - any known issues?

Bill, that has been always the case. You have to re-install XQuartz with every macOS upgrade. There are many issues with Catalina, but at least this one is not new ;). Cheers, Simon > On 22/04/2020, at 4:37 PM, William Michels via R-SIG-Mac > wrote: > > Hello, > > Regarding R with

Re: [R-SIG-Mac] [Rd] R not running under lldb? (osx)

t; that case. > > THK > > On Tue, Apr 21, 2020 at 6:51 PM Simon Urbanek > wrote: > Tim, > > as a security precaution Apple has disabled the ability to debug notarized > applications*. It means any software distributed on macOS Catalina (and they > may have re

Re: [R-SIG-Mac] OpenMP on CRAN (Simon Urbanek)

I have now created a page about this: http://mac.r-project.org/openmp which also provides libomp binaries for all recent versions of Xcode (and more). Important note: this is about Xcode - it is NOT about using Homebrew tools nor the custom compilers we used before R 4.0.0. Both of the latter

Re: [R-SIG-Mac] OpenMP on CRAN (Simon Urbanek)

e.g. https://github.com/r-windows > > Best, > > JJB > > On 4/30/20, 8:10 PM, "R-SIG-Mac on behalf of Simon Urbanek" > > wrote: > >I have now created a page about this: > >http://mac.r-project.org/openmp > >which als

Re: [R-SIG-Mac] incompatible lldb on mojave?

Vince, Apple no longer allows debugging of distributed apps - see R for Mac FAQ 10.17: http://mac.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R Another (not recommended) work-around is to disable SIP. Cheers, Simon > On 3/05/2020, at 10:42 AM, Vincent Carey wrote:

Re: [R-SIG-Mac] Function Hints in Mac Dark Mode aren't visible

for both modes. Ideally, we'd have two color sets, but that would be a lot harder to implement. Thanks, Simon > On 12/05/2020, at 9:25 AM, Simon Urbanek wrote: > > Andrew, > > thanks! The colors in the GUI are a mix of app-defined and system colors, so &g

Re: [R-SIG-Mac] Function Hints in Mac Dark Mode aren't visible

Andrew, thanks! The colors in the GUI are a mix of app-defined and system colors, so there are cases there they will clash. I'll see if we can implement better handling of the dark mode. Thanks, Simon > On 9/05/2020, at 3:19 AM, Andrew Swift via R-SIG-Mac > wrote: > > I noticed that with

Re: [R-SIG-Mac] obsolete LaTeX software in "R CMD check" on Mac?

Spencer, as Duncan pointed out that is an issue on your machine, so only you can fix it. The checks use whatever you give them. FWIW the macOS CRAN setup uses TeX Live 2019: $ pdflatex --version | head -n1 pdfTeX 3.14159265-2.6-1.40.20 (TeX Live 2019) You can upgrade your TeX installation if

Re: [R-SIG-Mac] Function Hints in Mac Dark Mode aren't visible

gt; Ideally just make it the same size/height as regular console text. > >> On 12 May 2020, at 00:36, Simon Urbanek wrote: >> >> Andrew, >> >> I have addressed it for the console and the document windows in the GUI >> revision 7839. You can download the up

Re: [R-SIG-Mac] R 3.6.3 for MacOS

he > toolchain for 4.0.0 if I want to upgrade the build machine to Catalina before > the release. > > -pd > >> On 6 Mar 2020, at 02:32 , Simon Urbanek wrote: >> >> Lori, >> >> as posted here earlier[1], Apple has tightened notarization requiremen

Re: [R-SIG-Mac] R.app GUI 1.71 (7827) crashes on Catalina

Unfortunately I cannot reproduce it. When opening a file in one of the protected folders with R 4.0.0 release on Catalina I get '"R" would like to access files in your Documents folder' - which you have to agree to (one of those Catalina annoyances). It only asks once - we don't explicitly

Re: [R-SIG-Mac] R-GUI Editor Window Offset

seen that behavior too. The scroll bar is nearly transparent > as well. Not sure what's going on there either. > > Thanks, > Brandon > > On Wed, May 20, 2020 at 4:16 PM Simon Urbanek > wrote: >> >> Ok, great, thanks, I can replicate that on Catalina, will look i

Re: [R-SIG-Mac] R-GUI Editor Window Offset

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 > > Thanks, > Brandon > > On

Re: [R-SIG-Mac] R-GUI Editor Window Offset

Can you please, supply full sessionInfo(), macOS version and details to reproduce? You are apparently loading some file, so is this by drang-drop via Open, via restore, …? Thanks, Simon > On May 21, 2020, at 10:53 AM, Brandon Hurr wrote: > > When loading R-GUI I'm getting this weird offset

Re: [R-SIG-Mac] Cannot compile Fortran on macOS

Ken, R can be built with just Xcode and GFortran (see also http://mac.r-project.org/tools/ ). If you have issues, those are very often due to conflicting package managers (Homebrew, macoports, fink ...) so a good exercise is to simply re-name /usr/local/ and setup a clean environment as above

Re: [R-SIG-Mac] Cannot compile Fortran on macOS

Adelchi, as pointed out you have conflicting libraries in /usr/local - likely from some conflicting package manager. I would recommend re-naming /usr/local to remove the issue and installing a clean GNU Fortran (see http://mac.r-project.org/tools/ or from the official GNU Fortran pages which

Re: [R-SIG-Mac] catalina humbug

Roger, the error points to an old local clang - did you remove (or move aside) that one? Check your /usr/local - you seem to have some old stuff there that is breaking. That would solve the original issue. You seem to have done a lot after that error, but didn't tell us what happened then… you

Re: [R-SIG-Mac] catalina humbug

posix >>> InstalledDir: >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin >>> >>> >>> The last time I faced this sort of thing James suggested this: >>> https://groups.google.com/g/r-sig-

[R-SIG-Mac] svn now available from the tools

If you want to build R from the svn repository you need svn (subversion). Xcode 10 has removed svn so it is no loner available from Apple, we are providing a binary (cmopatible with OS X 10.11 and higher) in https://mac.r-project.org/tools/ (in "optional tools and libraries" at the bottom),

Re: [R-SIG-Mac] svn location

ny building in quite a while: >>> recommended director to place the svn executable? >>> thanks >>> Carl >>> >>> On 8/26/20 6:00 AM, r-sig-mac-requ...@r-project.org wrote: >>> >>>>1. svn now available from the tools (S

Re: [R-SIG-Mac] bzip2 configure error

Duncan, We have a bunch of bugs in configure (on all platforms) when used with -Werror which is default for some Apple compiler builds recently, the one below is just one for them (failing to include stdlib.h and string.h in the test). It may be worth filing a bug report, this should be a

Re: [R-SIG-Mac] svn tarball

from someone who hasn't done any building in quite a while: >>> recommended director to place the svn executable? >>> thanks >>> Carl >>> >>> On 8/26/20 6:00 AM, r-sig-mac-requ...@r-project.org wrote: >>> >>>> 1. svn now avail

Re: [R-SIG-Mac] R, FORTRAN and Apple Silicon

Jim, thanks for the update, yes, we are aware and we have an ADP now, too, and are assessing the issues. I got base R working using f2c as a stop-gap measure, but it doesn't pass all checks due to fp issues (not necessarily related to Fortran) so there are more moving parts to this. It would

Re: [R-SIG-Mac] Building R 4.0.2 from source via clang/xcode for MKL on macOS

like the following? >>> >>> ./configure --enable-BLAS-shlib --with-blas="-lBLAS" ... >>> >>> Is this also possible with LAPACK? >>> >>> tx again. >>> cheers, roy >>> >>> >>> On Mon, Sep 28, 20

Re: [R-SIG-Mac] Bug crash on opening a document

Chris, please download the latest version from https://mac.r-project.org/ in particular you can also just download the updated R GUI from that page (which you can run directly from the image) to see if the issue has been fixed in the meantime since there was one major crash issue fixed since

Re: [R-SIG-Mac] Installation Problems

Roy, it looks like the sync from the Mac master to CRAN was incomplete for some reason (CCing CRAN in case there was some error). I presume it will fix itself on next sync, but you can use the Mac master in the meantime which worked for me: install.packages(c("rpf", "statespacer", "tmap",

Re: [R-SIG-Mac] Installation Problems

this was true using the R-GUI as well as RStudio, and I think I tried 3 > different repositories, including R-Cloud. So that got me worried there was > something nutty on my end. > > Anyway, thanks for the work. One package had some things I particularly > wanted to check out. &

Re: [R-SIG-Mac] Building R 4.0.2 from source via clang/xcode for MKL on macOS

Rollin, it has been several years since I last tested MKL, so take it with a grain of salt, but in general you don't necessarily have to build R with MKL in order to use it - you only need to use --enable-BLAS-shlib and link to any ABI-compatible BLAS which can be vecLib as well. Then you can

Re: [R-SIG-Mac] Binary R-devel Builds For OS-X

Our build is currently a bit in flux since I was moving the CRAN machines back to the university. Also for the betas I am notarising the builds which includes a manual step (I don’t do that for the regular nightlies). FWIW the time zone of the build machine is US/Eastern for historical reasons.

Re: [R-SIG-Mac] Update to versions GEOS 3.8.0, GDAL 3.0.4 and PROJ 7.0.0 in macOS Catalina

Manuel, see https://github.com/R-macos/recipes you can update the recipes to use the required versions to build a setup that works for your package. Once you do you can issue a pull request so we can update CRAN accordingly. Please note that it is generally

Re: [R-SIG-Mac] [External] Re: crash due to rgl and base graphics conflict

of X11 - there should be also an error on stderr. The libGL code is more than 10 years old, so I wouldn't expect any changes anytime soon. Cheers, Simon Begin forwarded message: From: Simon Urbanek Subject: rgl Date: April 1, 2020 at 13:05:20 GMT+13 To: Duncan Murdoch Duncan, I'm preparing

Re: [R-SIG-Mac] Workaround for crash due to rgl and base graphics conflict

Duncan, how is quartz() related to rgl? I thought that now you only supported X11 which wouldn't involve quartz. In general, Cocoa windows are asynchronous, i.e. when the quartz device is created the window may not exist yet, but I'm not sure why that would affect rgl (quartz device draws to

Re: [R-SIG-Mac] Daily builds

There is an issue with automated signing (more precisely the authorization of the codesigning tools), so the tar balls are available, but the packaging fails. The website generation scripts makes the output conditional on the presence of the package, so it wasn't showing the links even though

Re: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging

> On Jul 13, 2020, at 7:59 PM, Prof Brian Ripley wrote: > > On 08/07/2020 21:38, Simon Urbanek wrote: >> Dmitriy, >> due to permissions and the various limitations on passing environment >> variables across processes it is often easier to simply run R

Re: [R-SIG-Mac] R-devel daily build lagging

Jim, thanks, yes, you're right, the high-sierra nightly R-devel builds were suspended while I was re-working the package build system (it's all a bit more complex due to the legacy builds on El Capitan). I was re-building all the new VMs on the new hardware, and as of today we're finally on

Re: [R-SIG-Mac] Can't open files in 4.0 or 4.01

need more reports or to try something else. > > Brandon > > On Sun, Jun 28, 2020 at 4:00 PM Simon Urbanek > wrote: > >> Brandon, >> >> Yes, this is of great help! It shows the the GUI spins in the segfault >> handler (it segfaults while rendering text whi

Re: [R-SIG-Mac] Advise on building R on OSX without optimization for debugging

Dmitriy, due to permissions and the various limitations on passing environment variables across processes it is often easier to simply run R and attach the debugger to it: $ R [...] > Sys.getpid() [1] 89955 > $ sudo lldb Password: (lldb) attach 89955 [...] (lldb) c Process 89955 resuming

Re: [R-SIG-Mac] Can't open files in 4.0 or 4.01

ve suggestions or have > ideas on more information. I've been using BBEdit to open other scripts, > but often forget and end up with a crash because I double-click on a file. > I might try to get BBEdit to work with R more intimately as Carl pointed > out. > > B > > On Sun,

Re: [R-SIG-Mac] Download for MacOS

Paige, thanks, now fixed. The symlink was missing, the actual location worked https://cran.r-project.org/bin/macosx/base/R-4.0.2.pkg but the shortcut didn't. The master now works (https://mac.R-project.org/bin/macosx ), all others mirrors should sync up in time. Thanks, Simon > On Jun 24,

Re: [R-SIG-Mac] R 4 dumping tons of console messages in Big Sur

Tim, that is likely intentional on Apple side - see R for Mac FAQ if you don't want to see that Apple debugging output. Cheers, Simon > On 25/06/2020, at 2:49 AM, Timothy Bates wrote: > > R in pretty-much unusable in Big Sur (OSX beta) - it's generating many more > than ever warning

Re: [R-SIG-Mac] Can't open files in 4.0 or 4.01

d (e.g. synced folder, non-synced folder, >> external drive, system drive, etc.). I exited all of these programs and >> tried again and it still happened. >> Anything else I should try or more information I could supply to narrow this >> down? >> Thanks, &g

Re: [R-SIG-Mac] Can't open files in 4.0 or 4.01

ly system extensions I see in my Sys Preferences are Google Drive, >>> Dropbox, One Drive, and OneNote. I haven't ever used the OneNote one and >>> rarely One Drive. Google Drive and Dropbox are installed and regularly >>> syncing a few folders. R seems to crash when opening a second f

Re: [R-SIG-Mac] Can't open files in 4.0 or 4.01

Brandon, Yes, this is of great help! It shows the the GUI spins in the segfault handler (it segfaults while rendering text which calls the R segfault handler which in turn tries to render more text etc. ...). So first thing is to avoid the signal handler, run this command in Terminal: defaults

Re: [R-SIG-Mac] Can't open files in 4.0 or 4.01

Thanks for the reports. Unfortunately, I still cannot reproduce it on Catalina - neither with 4.0.1 nor 4.0.0. Can someone post exactly how to replicate? (How do exactly you open the file? - the Open dialog works fine for me...) Note that the GUI is independent of R and compatible up to the

Re: [R-SIG-Mac] Fail to install Rserve 1.8-6

here exactly I have to > configure.args=“--without-proxy” ? > > Sorry for my poor knowledge on this. > > Stavros > >> On 9 Jun 2020, at 11:42 AM, Simon Urbanek >> wrote: >> >> Stavros, >> >> as the error says, the proxy needs a val

Re: [R-SIG-Mac] macOS R packaging problem

Pieter, thank you, should be fixed in the R 4.0.1 release. Simon > On Jun 3, 2020, at 7:40 AM, Pieter Bowman wrote: > > I came across a problem with the macOS R-4.0.0.pkg released in April > and verified that it's still in the R-4.0-branch.pkg released > 1-Jun-2020. The problem is that the

Re: [R-SIG-Mac] Labels not displaying in R plots

David, that is typically a sign of damaged fonts in your system. Open the Font Book (in Applications), select User and see if there are any broken fonts and remove them. You can also select fonts and run File -> Validate Font. Either way, you can compare your font configuration on both

Re: [R-SIG-Mac] Fail to install Rserve 1.8-6

Stavros, as the error says, the proxy needs a valid ssl library. Apple has removed OpenSSL from Catalina and from the SDK already in Mojave. The most simple solution is to disable the QAP/WebSocket proxy with configure.args="—without-proxy" if you don’t need it (or any other SSL

Re: [R-SIG-Mac] Editor beginning-of-line-chomp?

Yes, this is a known problem on Catalina. It goes away if you use the touchpad to pan or if you start typing. It's unclear at this point what is causing it. Catalina generally exhibits few rendering issues (missing background for some elements etc.). Those are under investigation. Cheers,

Re: [R-SIG-Mac] OpenJPEG in GDAL [Was: Problems with R and Big Sur]

rs/gilbertocamara/Library/R/4.0/library/sf/gdal > GDAL binary built with GEOS: TRUE > Loaded PROJ runtime: Rel. 7.1.1, September 1st, 2020, [PJ_VERSION: 711] > Path to PROJ shared files: /Users/gilbertocamara/Library/Application > Support/proj:/usr/local/share/proj:/usr/local/share/pro

Re: [R-SIG-Mac] INSTALL R 4.0.2

R 4.0.2 and 4.0.3 are binary compatible and the latter fixes a rather important segfault on macOS, so I would not recommend anyone using R 4.0.2 on macOS ... > On 4/12/2020, at 3:19 AM, Spencer Graves wrote: > > If R 4.0.3 will do, that's easy to find via Google. > > > If

Re: [R-SIG-Mac] R-4.0-branch x86_64: make FAILED

Olivier, thank you for the report. It seems that the following build has succeeded. Since those are nightly builds from "live" branches it quite possible for them to fail - in this case whatever the issue was it got fixed by the next build. Thanks, Simon > On Dec 8, 2020, at 8:56 AM,

Re: [R-SIG-Mac] Problems with R and Big Sur

orks correctly. > > Best regards > Gilberto > >> On 2 Dec 2020, at 22:44, Simon Urbanek wrote: >> >> Are you chasing a red herring here? Switching tools won help you - in fact >> they cause more issues since you'd need R-devel version of R to avoid >&

Re: [R-SIG-Mac] Problems with R and Big Sur

Are you chasing a red herring here? Switching tools won help you - in fact they cause more issues since you'd need R-devel version of R to avoid breakage with the most recent tools or extra flags. I'm not sure which issue you are trying to solve. For gdal et al - make sure you install the

Re: [R-SIG-Mac] NSButton Message in R.app

Unfortunately, I don't have a Mac with a touch bar to replicate it, I'll see if there is any other way to test it. The GUI doesn't actually use the touch bar, so it's not clear where that message comes from. It seems like just a benign output from the system - it doesn't really affect any

Re: [R-SIG-Mac] is there an M1 virtual machine image available for linux?

I don't think that is feasible (assuming you mean macOS 11 arm64 system running in a VM). Note that M1 is not just the CPU, there is much tighter integration of all the components so you'd have to emulate a lot more than that and also all the Apple security components etc. in order to be able

Re: [R-SIG-Mac] is there an M1 virtual machine image available for linux?

d have not been fixed after several requests which why your packages were >under threat to be removed, it has nothing to fo with M1 as far as I can tell. Cheers, Simon > On 15/12/2020, at 4:02 PM, Joshua N Pritikin wrote: > > On Tue, Dec 15, 2020 at 03:54:12PM +1300, Simon Urbanek

Re: [R-SIG-Mac] Follow up on R 4.0.2 GUI does not terminate with Cmd+Q

Petar, there are two options that would be helpful to us to trace it: 1) use the Debug version of the GUI (from https://mac.R-project.org/ - make sure you pick the one that matches your R version) and check the console when that happens - you should likely see some output there 2) when using

Re: [R-SIG-Mac] Follow up on R 4.0.2 GUI does not terminate with Cmd+Q

ear Simon, > > Sample Process attached (it was faster) > > Regards, > Petar > > > > >> On 13 Dec 2020, at 20:37, Simon Urbanek wrote: >> >> Petar, >> >> there are two options that would be helpful to us to trace it: >> >> 1) use

Re: [R-SIG-Mac] sf installation problem under Mac OS 11 - Big Sur

JJB, FWIW if you have an issue that is related to macOS R please report it here. GH is fine for PRs, but I am only batch-processing GH notifications once in a while (with close to 100 repos it's not possible to do it continuously), so I only act on things flagged here as important. Cheers,

Re: [R-SIG-Mac] sf installation problem under Mac OS 11 - Big Sur

Just for posterity, please do NOT follow those instructions unless you really want to build packages from sources and maintain them. Building GDAL can be tricky since the feature set depends on the libraries you have available, so use at your own risk. CRAN libraries have been updated to be

Re: [R-SIG-Mac] BLAS veclib in R 4.1

Ashley, parallel BLAS has been know to cause issues in precision, stability (when mixed with other parallel use) and rarely performance. The vecLib stub has not been part of the distribution for some time now, however, you can download it and enable it as follows: curl -O

Re: [R-SIG-Mac] I cannot download "updateR" package for macOS

None of the tools you are mentioning are maintained or recommended by CRAN, please use untrusted sources at your own risk and contact the corresponding authors if you have questions. (Brief look at the URL leaves me absolutely horrified at the security implications). Cheers, Simon > On

Re: [R-SIG-Mac] Corrupt R installation

You seem to have entirely non-standard setup that you're on your own and I assume you're not using CRAN R since you involve homebrew (which explains the chaos) so presumably you re-compiled R yourself and all packages, but I'd like to point out that if all you are after is OpenMP support then

Re: [R-SIG-Mac] Grids not showing

You may want to ask the ggplot help - since you provided zero details we can't tell (you didn't even say what kind of output you're looking at). I have no idea if that is related (since you didn't provide any code), but one common mistake is to use lwd=0 which leads to undefined behavior

Re: [R-SIG-Mac] Corrupt R installation

Um, this is actually a lot easier purely with R - if you want to keep track of your favorite packages it is as simple as pkgs = rownames(installed.packages()) writeLines(pkgs, "packages.txt") and oyu have a list of all packages that you can edit if desired. if you ever want to re-install

Re: [R-SIG-Mac] tcltk on M1 mac?

Vince, Thanks for the report, yes, that is a known problem, because the R installer for arm64 doesn't include Tcl/Tk unlike the Intel version. It is a long story, but I hope to update the installer soon. Thanks, Simon > On May 14, 2021, at 02:47, Vincent Carey wrote: > > I can't seem to

Re: [R-SIG-Mac] R-4.0.5.pkg Bug Report

I have fixed it (it only needs a slight modification of the regex) and responded, unfortunately my posts get blocked at ETH :( The nightlies should have the new post flight script so please test. Cheers, Simon > On May 9, 2021, at 21:11, peter dalgaard wrote: > > Eek, yes, that needs

Re: [R-SIG-Mac] R-gui slow since last update

t safe to do so? > > Yan > > > On May 7, 2021, at 2:27 PM, Simon Urbanek <mailto:simon.urba...@r-project.org>> wrote: > > Yan, > > it's ok, I didn't need the Debug version. > > However, did you check the Touch Bar settings as discussed previously t

Re: [R-SIG-Mac] R-4.0.5.pkg Bug Report

Yuri, thanks, no, this has not been reported, so it is indeed very useful! Now fixed in r4560 so tonight's build should work. Thanks for doing the right thing which is to report the issue at the source instead of consulting the social media which doesn't help anyone. Thanks, Simon > On

Re: [R-SIG-Mac] R-gui slow since last update

lso, if you need me to test the fixes / updates, please don’t hesitate. > > Yan > > > On May 6, 2021, at 4:30 AM, Simon Urbanek wrote: > > Yan, > > thank you for the sampler files! > > From cursory glance the issue seems to be the touch bar, an amazing amount of &g

Re: [R-SIG-Mac] tcltk on M1 mac?

Vince, please try the latest build, Tcl/Tk should be included now. Thanks, Simon > On May 14, 2021, at 7:45 AM, Simon Urbanek > wrote: > > Vince, > > Thanks for the report, yes, that is a known problem, because the R installer > for arm64 doesn't include Tcl/Tk unl

Re: [R-SIG-Mac] [External] xaxis not displaying

I don't have the corresponding machine to replicate, but I recall something related to the fact that the display of the machine may be too small to accommodate the requested device size (the size specification is in inches). If the display is too small, you may want to reduce the requested

Re: [R-SIG-Mac] [External] xaxis not displaying

Much appreciated > > Mike > — > Mike McStephen > PO Box 147, Bruthen > m...@mcstephen.com.au > 0417 652 552 > >> On 15 May 2021, at 11:31 am, Simon Urbanek >> wrote: >> >> I don't have the corresponding machine to replicate, but I recall somethi

<    1   2   3   4   5   6   7   8   >