Re: [R-SIG-Mac] Bug in reading UTF-16LE file?

[Simon Urbanek]

>From the help page:

 The encodings ‘"UCS-2LE"’ and ‘"UTF-16LE"’ are treated specially,
 as they are appropriate values for Windows ‘Unicode’ text files.
 If the first two bytes are the Byte Order Mark ‘0xFEFF’ then these
 are removed as some implementations of ‘iconv’ do not accept BOMs.

so "UTF-16LE" is the documented way to reliably read such files.

Cheers,
Simon



> On 8 Sep 2024, at 21:23, Duncan Murdoch  wrote:
> 
> To R-SIG-Mac, with a copy to Jeff Newmiller:
> 
> On R-help there's a thread about reading a remote file that is coded in 
> UTF-16LE with a byte-order mark.  Jeff Newmiller pointed out 
> (https://stat.ethz.ch/pipermail/r-help/2024-September/479933.html) that it 
> would be better to declare the encoding as "UTF-16", because the BOM will 
> indicate little endian.
> 
> I tried this on my Mac running R 4.4.1, and it didn't work.  I get the same 
> incorrect result from all of these commands:
> 
> # Automatically recognizing a URL and using fileEncoding:
> read.delim(
> 'https://online.stat.psu.edu/onlinecourses/sites/stat501/files/ch15/employee.txt',
> fileEncoding = "UTF-16"
> )
> 
> # Using explicit url() with encoding:
> read.delim(
> url('https://online.stat.psu.edu/onlinecourses/sites/stat501/files/ch15/employee.txt',
>encoding = "UTF-16")
> )
> 
> # Specifying the endianness incorrectly:
> read.delim(
> url('https://online.stat.psu.edu/onlinecourses/sites/stat501/files/ch15/employee.txt',
>encoding = "UTF-16BE")
> )
> 
> The only way I get the correct result is if I specify "UTF-16LE" explicitly, 
> whereas Jeff got correct results on several different systems using "UTF-16".
> 
> Is this a MacOS bug or an R for MacOS bug?
> 
> Duncan Murdoch
> 
> ___
> 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] fcaR plot not working

[Simon Urbanek]

Peter,

hasseDiagram unfortunately depends on packages outside of CRAN, namely in 
Bioconductor, so you have to add the corresponding repositories before you 
install it, e.g.:

setRepositories(ind=1:4)
install.packages("hasseDiagram")
# also installing the dependencies ‘BiocGenerics’, ‘Rgraphviz’, 'graph’

Ideally, hasseDiagram would warn the user and provide an informative error, but 
that you’d have to take up with the author.

Cheers,
Simon



> On 23 Aug 2024, at 21:15, Peter van Summeren  
> wrote:
> 
> Hello,
> I have a MacBook Air M1
> 
> I newly installed R and R studio. Also fcaR(formal concept analysis for R).
> I followed fcaR via the help files.
> Finally I did fc_planets$standardize() : worked.
> Then: fc_planets$concepts$plot()
> Warning message:
> You have not installed the 'hasseDiagram' package, which is needed to plot 
> the lattice.
> So, I installed:
> install.packages("hasseDiagram”)
> Then: library("hasseDiagram”)
> Finally:
>  fc_planets$concepts$plot()
> It gave:
> Warning in install.packages :
>  dependencies ‘Rgraphviz’, ‘graph’ are not available
> trying URL 
> 'https://cran.rstudio.com/bin/macosx/big-sur-arm64/contrib/4.4/hasseDiagram_0.2.0.tgz'
> Content type 'application/x-gzip' length 37789 bytes (36 KB)
> ==
> downloaded 36 KB
> 
> No idea what to do to get a plot of the lattice. 
> Any help would be appreciated.
> Peter
> 
> ___
> 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 openssl package in R-devel

[Simon Urbanek]

On, and I just noticed - you appear to have some legacy Homebrew files as well 
in /usr/local - on a Mx Mac you should remove all from /usr/local as that is 
just Intel legacy that will cause a lot of problems.

Cheers,
Simon


> On 22/07/2024, at 10:11 AM, Simon Urbanek  wrote:
> 
> Probably the best is to remove (aka move aside) *everything* - both 
> /opt/R/arm64 and /opt/homebrew (or at least rename it to move it aside). The 
> openssl package provides a fallback, but only if it doesn't detect something 
> that gets in its way. It gets really confused if you have various various 
> pieces from different versions. Once you install openssl you can move things 
> back since it will be statically linked, but please note that Homebrew breaks 
> pretty much anything native so it's a good idea to disable Homebrew whenever 
> you are compiling something native.
> 
> Cheers,
> Simon
> 
> 
> 
>> On 22/07/2024, at 6:28 AM, Duncan Murdoch  wrote:
>> 
>> Okay, I've figured out the previous issue.  The openssl package configure 
>> script dies if it doesn't have openssl version 3, while install.libs() 
>> provides version 1.1.
>> 
>> So I followed the advice to install from Homebrew, and the configure 
>> succeeded, but the install still failed:
>> 
>>> ** testing if installed package can be loaded from temporary location
>>> Error: package or namespace load failed for ‘openssl’ in dyn.load(file, 
>>> DLLpath = DLLpath, ...):
>>> unable to load shared object 
>>> '/Users/murdoch/R/R-devel/library/00LOCK-openssl/00new/openssl/libs/openssl.so':
>>> dlopen(/Users/murdoch/R/R-devel/library/00LOCK-openssl/00new/openssl/libs/openssl.so,
>>>  0x0006): symbol not found in flat namespace 
>>> '_EVP_CIPHER_CTX_get_block_size'
>>> Error: loading failed
>>> Execution halted
>>> ERROR: loading failed
>>> * removing ‘/Users/murdoch/R/R-devel/library/openssl’
>> 
>> Any suggestions?
>> 
>> Duncan Murdoch
>> 
>> On 2024-07-21 2:11 p.m., Duncan Murdoch wrote:
>>> I'm trying to install the openssl package on an M3 Mac in R-devel.  It
>>> keeps failing with these messages:
>>>> * installing *source* package ‘openssl’ ...
>>>> ** package ‘openssl’ successfully unpacked and MD5 sums checked
>>>> ** using staged installation
>>>> Homebrew >=4.1.0 (shallow or no git repository)
>>>> Using PKG_CFLAGS=-I/usr/local/opt/openssl/include
>>>> --- [ANTICONF] 
>>>> Configuration failed because openssl was not found. Try installing:
>>>> * deb: libssl-dev (Debian, Ubuntu, etc)
>>>> * rpm: openssl-devel (Fedora, CentOS, RHEL)
>>>> * csw: libssl_dev (Solaris)
>>>> * brew: openssl (Mac OSX)
>>>> If openssl is already installed, check that 'pkg-config' is in your
>>>> PATH and PKG_CONFIG_PATH contains a openssl.pc file. If pkg-config
>>>> is unavailable you can set INCLUDE_DIR and LIB_DIR manually via:
>>>> R CMD INSTALL --configure-vars='INCLUDE_DIR=... LIB_DIR=...'
>>> I did install the openssl lib using Simon's install.libs() function from
>>> https://mac.r-project.org/bin/, and I do have pkg-config installed in
>>> /opt/R/arm64/bin and I see this:
>>> $ pkg-config openssl --cflags
>>> -I/opt/R/arm64/include
>>> So I don't know where the openssl config is finding the Homebrew info.
>>> Can someone suggest what I need to do to get this to work?
>>> Duncan Murdoch
>>> 
>> 
>> ___
>> 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 openssl package in R-devel

[Simon Urbanek]

Probably the best is to remove (aka move aside) *everything* - both 
/opt/R/arm64 and /opt/homebrew (or at least rename it to move it aside). The 
openssl package provides a fallback, but only if it doesn't detect something 
that gets in its way. It gets really confused if you have various various 
pieces from different versions. Once you install openssl you can move things 
back since it will be statically linked, but please note that Homebrew breaks 
pretty much anything native so it's a good idea to disable Homebrew whenever 
you are compiling something native.

Cheers,
Simon



> On 22/07/2024, at 6:28 AM, Duncan Murdoch  wrote:
> 
> Okay, I've figured out the previous issue.  The openssl package configure 
> script dies if it doesn't have openssl version 3, while install.libs() 
> provides version 1.1.
> 
> So I followed the advice to install from Homebrew, and the configure 
> succeeded, but the install still failed:
> 
>> ** testing if installed package can be loaded from temporary location
>> Error: package or namespace load failed for ‘openssl’ in dyn.load(file, 
>> DLLpath = DLLpath, ...):
>> unable to load shared object 
>> '/Users/murdoch/R/R-devel/library/00LOCK-openssl/00new/openssl/libs/openssl.so':
>>  
>> dlopen(/Users/murdoch/R/R-devel/library/00LOCK-openssl/00new/openssl/libs/openssl.so,
>>  0x0006): symbol not found in flat namespace '_EVP_CIPHER_CTX_get_block_size'
>> Error: loading failed
>> Execution halted
>> ERROR: loading failed
>> * removing ‘/Users/murdoch/R/R-devel/library/openssl’
> 
> Any suggestions?
> 
> Duncan Murdoch
> 
> On 2024-07-21 2:11 p.m., Duncan Murdoch wrote:
>> I'm trying to install the openssl package on an M3 Mac in R-devel.  It
>> keeps failing with these messages:
>>> * installing *source* package ‘openssl’ ...
>>> ** package ‘openssl’ successfully unpacked and MD5 sums checked
>>> ** using staged installation
>>> Homebrew >=4.1.0 (shallow or no git repository)
>>> Using PKG_CFLAGS=-I/usr/local/opt/openssl/include
>>> --- [ANTICONF] 
>>> Configuration failed because openssl was not found. Try installing:
>>>  * deb: libssl-dev (Debian, Ubuntu, etc)
>>>  * rpm: openssl-devel (Fedora, CentOS, RHEL)
>>>  * csw: libssl_dev (Solaris)
>>>  * brew: openssl (Mac OSX)
>>> If openssl is already installed, check that 'pkg-config' is in your
>>> PATH and PKG_CONFIG_PATH contains a openssl.pc file. If pkg-config
>>> is unavailable you can set INCLUDE_DIR and LIB_DIR manually via:
>>> R CMD INSTALL --configure-vars='INCLUDE_DIR=... LIB_DIR=...'
>> I did install the openssl lib using Simon's install.libs() function from
>> https://mac.r-project.org/bin/, and I do have pkg-config installed in
>> /opt/R/arm64/bin and I see this:
>> $ pkg-config openssl --cflags
>> -I/opt/R/arm64/include
>> So I don't know where the openssl config is finding the Homebrew info.
>> Can someone suggest what I need to do to get this to work?
>> Duncan Murdoch
>> 
> 
> ___
> 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] procedure to ship libomp.dylib run-time with package

[Simon Urbanek]

There seems to be some misunderstanding of the processes involved, so I'll try 
to clarify those.

First, there are two orthogonal uses for OpenMP: OpenMP use by R and OpenMP use 
by packages. R itself detects OpenMP when it is built (configured to be 
precise) and may use it when detected. By default, if OpenMP support is 
detected by R it will also be provided to packages via the SHLIB_OPENMP_*FLAGS. 
On macOS R does not attempt to use the combination of Apple clang + Intel 
OpenMP (intentionally) since the benefits are not significant (for R) and thus 
it is not worth the complexity and risk (of being sure that the combination 
will work) in general. Therefore R itself will not use OpenMP and will not set 
SHLIB_OPENMP_*FLAGS when used with Apple clang.

However, if a package deems that it wants to explicitly support such 
combination if available (e.g., because it is sure that is will lead to 
significant benefits to the user), it can simply perform the standard OpenMP 
compilation test with an additional attempt of adding -Xclang -fopenmp to 
CFLAGS instead of -fopenmp (which is otherwise required on most platforms). 
That's all - it is that simple (many packages already perform OpenMP tests 
anyway). The package should not care about R version, CRAN or anything - it's 
entirely irrelevant - it simply checks whether such functionality is available 
or not. If it is available, it will work and the package can use it.

In order to simplify distribution, CRAN makes sure that the package build 
environment includes working OpenMP in the Apple clang + Intel OpenMP 
combination such that the above test will succeed. As a technical detail, to 
make that work seamlessly, CRAN provides the Intel OpenMP run-time library 
libomp.dylib in the R binary framework distribution such that packages don't 
have to ship it themselves. Thus if a package correctly detects OpenMP it will 
be available on CRAN with OpenMP support. As explained above, the package 
should to not do anything special - it only had to perform the simple test for 
OpenMP functionality as explained above. The CRAN build process makes sure it 
will "just work".

If a user or developer wants to add the Apple clang + Intel OpenMP support to 
their macOS system independently, they only need to download and unpack the 
binary from https://mac.r-project.org/openmp/ - that's how they can check 
whether the package performs well enough to warrant enabling the support in the 
package - or for the user to force the package to use OpenMP even if the 
package does not do so itself.

To sum up: by default packages on macOS will not use OpenMP when Apple clang is 
used, but if the package author deems that OpenMP is crucial and will test the 
Apple clang + Intel OpenMP combination to make sure it is beneficial, then the 
package can enable the support by simply prepending -Xclang to the usual 
-fopenmp CFLAGS when testing for OpenMP availability and it will work both on 
CRAN (including distribution) and for any users that provide Intel OpenMP on 
their machine. As explained, the package should NOT check for specific R 
version, libraries, path or anything like that - simply just for the 
availability of the functionality as the details may vary by machine and 
installation.

I hope this clears up the misconceptions - really, the intention was for this 
to be as simple as possible.

Cheers,
Simon



> On Jul 6, 2024, at 01:40, Mikael Jagan  wrote:
> 
> Typo below ... not *_CPPFLAGS, but rather *_CFLAGS or *_CXXFLAGS: -fopenmp
> is not a preprocessor option ...
> 
> Mikael
> 
> On 2024-07-05 4:53 pm, Mikael Jagan wrote:
>> Some thoughts in line below, not "certified" but maybe helpful.  Corrections
>> welcome ...
>> Mikael
>>> From: "Balamuta, James" 
>>> To: Simon Urbanek 
>>> Cc: Timothy Bates , Kasper Daniel Hansen
>>> , "Sparapani, Rodney"
>>> , R list 
>>> Subject: Re: [R-SIG-Mac]  procedure to ship libomp.dylib run-time with
>>> package
>>> Message-ID:
>>> 
>>> 
>>> Content-Type: text/plain; charset="utf-8"
>>> 
>>> Simon,
>>> 
>>> Thanks for the update. I’m aware of the linking instructions [1,2,3,4] and 
>>> the purpose of configure{.ac} [5]. What I was not aware of was the CRAN 
>>> macOS build machine were outfitted with the appropriate OpenMP setup [6, 7] 
>>> in a post R 4.0.0 world. Thus, more than just local configurations that 
>>> adopted [8] could benefit from OpenMP especially since the top of [8] 
>>> contains:
>>> 
>>>> Warning! Everything described on this page is strictly experimental and 
>>>> not officially supported by CRAN, R-core or R Foundation. In may break at 
>>>> any time. The information is

Re: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package

[Simon Urbanek]

> On 27 Jun 2024, at 23:57, Balamuta, James  wrote:
> 
> Simon,
>  I think there is a communication issue regarding OpenMP for the macOS R 
> community. That said, I’m both thrilled and delighted that I’m wrong in this 
> case! To my knowledge, there was never a public facing note regarding 
> `libomp`  shipping with CRAN’s official R binary for mac, [1]. In fact, the 
> last tracking I have with respect to OpenMP and R on macOS was its abrupt and 
> painful removal that led to the instructions for experimental inclusion of 
> OpenMP on mac within the developer website [2] (gently acknowledge by Prof. 
> Ripley as being not current). This has led to a lot of lobotomization in 
> compiled code regarding macOS that can now hopefully be adjusted for the 
> multi-core world, [3].
>  With this in mind, I suppose this means that we would need to revisit the 
> `configure.ac` [3]. Potentially, as Prof. Ripley mentioned, we’re looking at 
> including on path/detecting:
>  `R 
> RHOME`/lib/libomp.dylib/Library/Frameworks/R.framework/Resources/lib/libomp.dylib


That's entirely unnecessary - you should not be requiring specific file paths - 
that's not how linking tests work. All the instructions are on the OpenMP page 
for years - it is as simple as -lomp (which is standard almost everywhere). The 
only non-standard requirement compared to other platforms is that instead of 
-fopemp in C flags the package should also check for -Xclang -fopenmp.

If a package explicitly disables OpenMP for Apple compilers, it is its 
deliberate choice - it was never necessary. The whole point of configure 
scripts is to detect functionality by testing it and use it if available.

Cheers,
Simon


>  Thus, the package binary downloaded from CRAN would correctly set and detect 
> cores per:
>  # install.packages("RcppArmadillo")
>  # Determine the number of active threads
> RcppArmadillo::armadillo_get_number_of_omp_threads()
> [1] 1
>  # Set number of threads
> RcppArmadillo::armadillo_set_number_of_omp_threads(3)
>  # Retrieve OpenMP threads after setting
> RcppArmadillo::armadillo_get_number_of_omp_threads()
> [1] 1
> # This should be 3.
>  I’m happy to talk more on the list or off the list.  Best,
>  James
>  [1]: https://cran.r-project.org/doc/manuals/r-release/NEWS.html
> [2]: https://mac.r-project.org/openmp/
> [3]: 
> https://github.com/RcppCore/RcppArmadillo/blob/37461ba36472305c699263afc229919d37daa5e3/configure.ac#L109
>   From: Simon Urbanek 
> Date: Thursday, June 27, 2024 at 10:25 AM
> To: Balamuta, James 
> Cc: Timothy Bates , Kasper Daniel Hansen 
> , Sparapani, Rodney , R list 
> 
> Subject: Re: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package
> Most of the claims below are false - libomp is shipped with CRAN R for quite 
> some time specifically so that packages which benefit from it significantly 
> can enable OpenMP reasonably easily - they only need to add the flags as 
> noted on the cited page and CRAN takes care of the rest. If there are any 
> problems, please feel free to contact me.
> 
> Cheers,
> Simon
>  
> 
> > On 26 Jun 2024, at 07:41, Balamuta, James  wrote:
> > 
> > Tim,
> > 
> > Unfortunately, there isn't a nice way of including OpenMP for macOS within 
> > a package.  One potential avenue would be to use a `configure.ac` file to 
> > check for whether OpenMP headers are present on the macOS computer and, 
> > then, allow the correct OpenMP compilation flags to be set. However, this 
> > requires the user to compile from source instead of using a CRAN binary.
> > 
> > Unfortunately, there isn't going to be an easier way as OpenMP on macOS 
> > with R is experimental by nature.
> > 
> > Best regards,
> > 
> > James
> > 
> > From: R-SIG-Mac  on behalf of Timothy 
> > Bates 
> > Sent: Tuesday, June 25, 2024 10:00 PM
> > To: Kasper Daniel Hansen ; Sparapani, Rodney 
> > 
> > Cc: R list 
> > Subject: Re: [R-SIG-Mac] procedure to ship libomp.dylib run-time with 
> > package
> > 
> > Thanks Kasper,
> > I read those lines and had installed the openmp software as instructed. It 
> > all works fine for me. But users don’t have my usr/ folder, not can a 
> > package write to their usr/ folder.
> > 
> > so what is confusing is how the user will get this lib. Where should make 
> > place libraries like libomp within the package so that if a user merely 
> > install.packages() it, the library will be found and loaded?
> > Best, tim
> > 
> > 
> > Sent from Outlook for 
> > iOS<https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!DZ3fjg!_OUXHENJ_

Re: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package

[Simon Urbanek]

Most of the claims below are false - libomp is shipped with CRAN R for quite 
some time specifically so that packages which benefit from it significantly can 
enable OpenMP reasonably easily - they only need to add the flags as noted on 
the cited page and CRAN takes care of the rest. If there are any problems, 
please feel free to contact me.

Cheers,
Simon
 

> On 26 Jun 2024, at 07:41, Balamuta, James  wrote:
> 
> Tim,
> 
> Unfortunately, there isn't a nice way of including OpenMP for macOS within a 
> package.  One potential avenue would be to use a `configure.ac` file to check 
> for whether OpenMP headers are present on the macOS computer and, then, allow 
> the correct OpenMP compilation flags to be set. However, this requires the 
> user to compile from source instead of using a CRAN binary.
> 
> Unfortunately, there isn't going to be an easier way as OpenMP on macOS with 
> R is experimental by nature.
> 
> Best regards,
> 
> James
> 
> From: R-SIG-Mac  on behalf of Timothy Bates 
> 
> Sent: Tuesday, June 25, 2024 10:00 PM
> To: Kasper Daniel Hansen ; Sparapani, Rodney 
> 
> Cc: R list 
> Subject: Re: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package
> 
> Thanks Kasper,
> I read those lines and had installed the openmp software as instructed. It 
> all works fine for me. But users don’t have my usr/ folder, not can a package 
> write to their usr/ folder.
> 
> so what is confusing is how the user will get this lib. Where should make 
> place libraries like libomp within the package so that if a user merely 
> install.packages() it, the library will be found and loaded?
> Best, tim
> 
> 
> Sent from Outlook for 
> iOS  >
> 
> From: Kasper Daniel Hansen 
> Sent: Tuesday, June 25, 2024 11:34:42 AM
> To: Sparapani, Rodney 
> Cc: Timothy Bates ; R list 
> Subject: Re: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package
> 
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the 
> email is genuine and the content is safe.
> If you read the next couple of sentences on that page, it says
> 
> The following are links to libomp OpenMP run-time built from official LLVM 
> release sources using Xcode compilers. They are signed and support macOS 
> 10.13 (High Sierra) and higher. All tar-balls contain the system tree 
> usr/local/lib and usr/local/include so the recommended installation is to 
> type in Terminal:
> 
>curl -O 
> https://urldefense.com/v3/__https://mac.r-project.org/openmp/openmp-14.0.6-darwin20-Release.tar.gz__;!!DZ3fjg!_OUXHENJ_6aGlU-humThmTaUR5okhDKW2EGEY49AjJ4AN8eXBWtZCWE3O01pnyxbRpGQDhCl8MMLThVBbWfUKf7B$
>sudo tar fvxz openmp-14.0.6-darwin20-Release.tar.gz -C /
> 
> 
> I think that is pretty clear? Note the -C / as part of the last line, that 
> tells tar where to put it on the system.
> 
> On Tue, Jun 25, 2024 at 8:20 AM Sparapani, Rodney via R-SIG-Mac 
> mailto:r-sig-mac@r-project.org>> wrote:
> Hi Tim:
> 
> /usr/local/lib it seems.  See the following page
> https://urldefense.com/v3/__https://mac.r-project.org/openmp/__;!!DZ3fjg!_OUXHENJ_6aGlU-humThmTaUR5okhDKW2EGEY49AjJ4AN8eXBWtZCWE3O01pnyxbRpGQDhCl8MMLThVBbaQGheD_$
> 
> --
> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> Vice President, Wisconsin Chapter of the American Statistical Association
> Institute for Health and Equity, Division of Biostatistics
> Medical College of Wisconsin, Milwaukee Campus
> 
> If this is outside of working hours, then please respond when convenient.
> 
> From: R-SIG-Mac 
> mailto:r-sig-mac-boun...@r-project.org>> on 
> behalf of Timothy Bates mailto:tim.ba...@ed.ac.uk>>
> Date: Monday, June 24, 2024 at 4:00 PM
> To: R list mailto:R-SIG-Mac@r-project.org>>
> Subject: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package
> ATTENTION: This email originated from a sender outside of MCW. Use caution 
> when clicking on links or opening attachments.
> 
> 
> At 
> https://urldefense.com/v3/__https://mac.r-project.org/openmp/__;!!H8mHWRdzp34!4HZ0uFxJQ121gF_TnX99OuMlgIXM600pq8wCbWruoLsdLTtaFgRB5_gMopCtxD0N9M4tUOO-7hBGADHx1sk$
>   it  says
> "any package you compile against libomp.dylib will need that run-time so you 
> have to ship it with your package or have users install it”
> 
> Are there  any  instructions on what to do/where to put libomp.dylib so it 
> will be found?
> 
> I’ve compiled a package (OpenMx) in which OpenMP is working locally but other 
> users get the error:
> 
> require(OpenMx)
> Error: package or namespace load failed for ‘OpenMx’ in dyn.

Re: [R-SIG-Mac] procedure to ship libomp.dylib run-time with package

[Simon Urbanek]

Tim,

There is no need to worry about libomp.dylib on macOS with CRAN packages as 
libomp is already shipped with R. When the package its built on CRAN, it will 
be pointed correctly to the version inside R.

However, in your output it seems that the problem may be that the user is using 
the wrong R version - the package is installed for R 4.4, but it seems to be 
looking for libomp in R 4.3. They are compatible, but the paths look wrong.  It 
is not clear to me what paths you used when building the package binary. Note 
that the package can only be installed for the same version that it has been 
compiled for. Also if you compile against libomp you have to either link 
against the version in R or use install_name_tool to change the linking path to 
make sure it points to the R version. Either way, check with tool -L to see 
what you are linking to.

Cheers,
Simon



> On 24 Jun 2024, at 23:00, Timothy Bates  wrote:
> 
> At https://mac.r-project.org/openmp/ it  says
> "any package you compile against libomp.dylib will need that run-time so you 
> have to ship it with your package or have users install it”
> 
> Are there  any  instructions on what to do/where to put libomp.dylib so it 
> will be found?
> 
> I’ve compiled a package (OpenMx) in which OpenMP is working locally but other 
> users get the error:
> 
> require(OpenMx)
> Error: package or namespace load failed for ‘OpenMx’ in dyn.load(file, 
> DLLpath = DLLpath, ...):
> unable to load shared object 
> '/Users/***/Library/R/x86_64/4.4/library/OpenMx/libs/OpenMx.so':
> 
> dlopen(/Users/***/Library/R/x86_64/4.4/library/OpenMx/libs/OpenMx.so, 
> 0x0006): Library not loaded: 
> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libomp.dylib
> 
> 
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336. Is e buidheann carthannais a th’ ann an 
> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh 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 CMD build" ...Error... "processing vignette ... failed with diagnostics:, Pandoc is required to build R Markdown vignettes but not available."

[Simon Urbanek]

Spencer,

Since you already have homebrew on your PATH you can simply run "brew install 
pandoc".

Otherwise you can just set the path while running R CMD:

PATH="~/Library/Application Support/r-pandoc/3.2:$PATH" R CMD build fda

As of where to set the PATH - it depends on where you run it from - if from 
Terminal then just set it in ~/.profile

Cheers,
Simon



> On Jun 13, 2024, at 23:00, Spencer Graves  wrote:
> 
> Hi, Duncan, Jeff et al.:
> 
> 
>  Thanks for the help. Can I edit "R CMD" so it modifies the path? If yes, 
> how? If that's not feasible, can I create a script of my own that would first 
> change the path and then call "R CMD"?
> 
> 
>  I asked Apple how to modify the path and was told they do not support that.
> 
> 
>  Thanks,
>  Spencer Graves
> 
> 
> On 6/13/24 13:51, Duncan Murdoch wrote:
>> On 2024-06-13 2:22 p.m., Spencer Graves wrote:
>>> 
>>> 
>>> On 6/13/24 12:27, Jeff Newmiller wrote:
 Don't assume the system environment variables defined at the R command 
 prompt are the same as the environment variables defined at the shell 
 prompt. Various R startup scripts often alter these variables within R. It 
 looks from my obscured position like the pandoc install directory is 
 present in your PATH directory from the shell.
>>> 
>>> 
>>> echo $PATH
>>> /opt/homebrew/bin:/opt/homebrew/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.11/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Library/TeX/texbin
>>> 
>>> 
>>>   I do not find "pandoc" in this path.
>>> 
>>> 
>>>   What do you suggest I do to fix this?
>> You can add it, and things should be fine.  I'd put it last, just in case 
>> there's anything else in that directory that might interfere with other 
>> things.  So you could do
>>   PATH=$PATH:~/Library/Application\ Support/r-pandoc/3.2 R CMD build ...
>> (or if you want, the equivalent that makes the PATH change permanent).
>> Duncan Murdoch
>>> 
>>> 
>>>   Thanks,
>>>   Spencer Graves
>>> 
 
 On June 13, 2024 10:09:25 AM PDT, Spencer Graves 
  wrote:
> Hello, All:
> 
> 
>   "R CMD build" fails for me, apparently because it cannot find 
> pandoc, even though R in a command prompt finds it. This is with R 4.4.0 
> under macOS 14.5. I get the following in a Terminal:
> 
> 
> ___% R CMD build fda
> * checking for file ‘fda/DESCRIPTION’ ... OK
> * preparing ‘fda’:
> * checking DESCRIPTION meta-information ... OK
> * installing the package to build vignettes
> * creating vignettes ... ERROR
> --- re-building ‘BasisBasics.Rmd’ using rmarkdown
> Error: processing vignette 'BasisBasics.Rmd' failed with diagnostics:
> Pandoc is required to build R Markdown vignettes but not available. 
> Please make sure it is installed.
> 
> 
>   "Pandoc 3.2 already installed", per the following interaction with 
> R in said Terminal:
> 
> 
>> library(pandoc)
>> pandoc_install()
> ℹ Fetching Pandoc releases info from github...
> ✔ Pandoc 3.2 already installed.
>Use 'force = TRUE' to overwrite.
>> 
>> 
>> pandoc_is_active()
> Error in pandoc_is_active() :
>argument "version" is missing, with no default
>> pandoc_is_active("system")
> [1] FALSE
>> pandoc_locate()
> [1] "~/Library/Application Support/r-pandoc/3.2"
> 
> 
>   sessionInfo() below.
>   Suggestions?
>   Thanks,
>   Spencer Graves
> 
> 
>> sessionInfo()
> R version 4.4.0 (2024-04-24)
> Platform: aarch64-apple-darwin20
> Running under: macOS Sonoma 14.5
> 
> Matrix products: default
> BLAS: 
> /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib;
>   LAPACK version 3.12.0
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> time zone: America/Chicago
> tzcode source: internal
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> other attached packages:
> [1] pandoc_0.2.0
> 
> loaded via a namespace (and not attached):
> [1] R6_2.5.1utf8_1.2.4  gh_1.4.1magrittr_2.0.3
> [5] rappdirs_0.3.3  glue_1.7.0  tibble_3.2.1pkgconfig_2.0.3
> [9] gitcreds_0.1.2  lifecycle_1.0.4 cli_3.6.2   fansi_1.0.6
> [13] vctrs_0.6.5 compiler_4.4.0  curl_5.2.1  pillar_1.9.0
> [17] httr2_1.0.1 rlang_1.1.4 jsonlite_1.8.8  fs_1

Re: [R-SIG-Mac] M3 not working with torch

[Simon Urbanek]

Gilberto,

since luz is a contributed package, you should probably start first by asking 
the authors. Given that the torch ecosystem is quite complex and has several 
layers that need to work together, even if you talk to them, you probably need 
to add details such as exact versions used (including the torch and metal 
layers) and how you installed the pieces (I know you helpfully supplied 
sesisonInfo() but I suspect that info such as exact torch run-time is pertinent 
as well). Next step would be to trace the error - check the system crash 
reporter or run R -d lldb to find out the exact library the crash happens in 
which may give you more clues. I don't have any M3 machines so I can't check 
myself, unfortunately.

Cheers,
Simon



> On 21/05/2024, at 12:48 AM, Gilberto Camara  wrote:
> 
> Dear R-SIG-MAC
> 
> I bought a new MacBook Air with the M3 chip, which has 8 CPUs, 10 GPUs, and 
> 16GB of integrated memory. My R `torch` apps are crashing. I have assembled 
> an MWE that works on other Mac architectures, including MacBook Air M1 and 
> MacMini. The OS is the same (Sonoma 14.5). The MWE follows:
> [...]
> ```
> The error occurs in the `luz::fit` function. Inside RStudio, the code gets 
> stuck, and then RStudio asks to restart R. When running R from the terminal, 
> the output is:
> ```{r}
> *** caught bus error ***
> address 0x16daa, cause 'invalid alignment'
> 
> *** caught segfault ***
> address 0x9, cause 'invalid permissions'
> zsh: segmentation fault  R
> ```
> The `sessionInfo()` output is as follows:

___
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.4 crashes loading dplyr

[Simon Urbanek]

Carl,

it shows that you apparently had some ancient version of magrittr installed way 
back from R 4.2.x. I have no idea why or how you got it, but 
update.packages(checkBuilt=TRUE) in R 4.4.0 should have fixed it.

Cheers,
Simon



> On 1/05/2024, at 12:32 AM, Carl Witthoft  wrote:
> 
> Thanks, Peter!   The funny thing is that I had kept R 4.2 around in the
> Frameworks directory, but didn't expect a new installation of R4.4 to
> choose that path for libs.  I removed R4.2 , then reinstalled R4.4 and now
> the correct libs are invoked.  I guess some config macro file must have
> remained in the list of startup items.
> FWIW,  after removing R4.2 but before reinstalling R4.4,   I tried
> 'library(dplyr)'  , which didn't crash but failed with the error msgs shown
> here.
> Error: package or namespace load failed for ‘dplyr’ in dyn.load(file,
> DLLpath = DLLpath, ...):
> unable to load shared object
> '/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so':
> 
> dlopen(/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so,
> 0x0006): Library not loaded:
> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib
>  Referenced from: 
> /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so
>  Reason: tried:
> '/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' (no
> such file),
> '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib'
> (no such file),
> '/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' (no
> such file), '/usr/local/lib/libR.dylib' (no such file),
> '/usr/lib/libR.dylib' (no such file, not in dyld cac
> 
> regards,
> Carl

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

Re: [R-SIG-Mac] error when installing the robustbase package (robustbase.rdb is corrupt)

[Simon Urbanek]

Y V,

as Duncan pointed out this is usually a problem with the RStudio session. Quit 
RStudio, re-install the package (if in doubt, use R), quit R and re-start 
RStudio.

Cheers,
Simon


> On 25/03/2024, at 10:54 AM, YV B  wrote:
> 
> I'm running R 4.3.3 GUI 1.80 Big Sur Intel build (8340) and RStudio Version
> 2023.12.1+402 on macOS Sonoma Version 14.4 (23E214) Intel Core i7.
> 
> I downloaded the package of robustbase
> - macosx/big-sur-x86_64/contrib/4.3/robustbase_0.99-2.tgz .
> , and tried to install it.
> 
> After installing it through Tools/Install Packages,
> it shows up in the Packages tab.
> 
> Clicking on the checkbox results in
> ```
>> install.packages(“path/to/robustbase_0.99-2.tgz", repos = NULL, type =
> .Platform$pkgType)
>> library(robustbase)
> Error: package or namespace load failed for ‘robustbase’ in get(Info[i, 1],
> envir = env):
> lazy-load database
> '/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/robustbase/R/robustbase.rdb'
> is corrupt
> In addition: Warning message:
> In get(Info[i, 1], envir = env) : internal error -3 in R_decompress1
> ```
> 
> I've reported this to r-project tracker. They cannot help me because this
> is not due to a problem of the source. Could you help me solving this
> problem?
> 
> Thank you.
> 
> Y V
> 
>   [[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] Graphics in R, version 4.3.2, does not work well in MacOS

[Simon Urbanek]

I can confirm that this is a rather nasty Sonoma bug at least since macOS 
14.3.1. It seems Apple tried to implement some kind of optimization that wants 
to minimize redraws in views, but it's buggy in that it doesn't detect that the 
contents have actually changed and thus refuses to redraw the view even though 
R tells it to do so. I found a somewhat convoluted work-around: if we draw two 
different things (just say dummy rectangles of varying color) and then 
overwrite them with the actual R plot then even Sonoma will redraw the view. It 
is rather bizarre... The work around of doodling unrelated things on the screen 
is now in R-devel and R-patched (85968 and 85969 resp.) so please check R 4.3.3 
beta r85969 or higher from mac.R-project.org

Cheers,
Simon



> On 22/02/2024, at 10:57 AM, Simon Urbanek  wrote:
> 
> I can confirm that this is a bug specific to macOS Sonoma 14.3.1, even 
> earlier versions of Sonoma don't have that problem. Given the number of 
> previous bugs in Sonoma chances are Apple may fix in the in the next release, 
> but I'll see if we can do anything about it on our end in the meantime.
> 
> Cheers,
> Simon
> 
> 
>> On 19/02/2024, at 5:56 AM, María de los Ángeles Casares de Cal via R-SIG-Mac 
>>  wrote:
>> 
>> Thank you very much for your information, Michael.
>> 
>> I had not realize that by changing the size of the window where all the 
>> plots should be, everything appears.
>> The same thing happens to me too.
>> 
>> Regards,
>> Ángeles
>> 
>> 
>> sessionInfo()
>> R version 4.3.2 (2023-10-31)
>> Platform: aarch64-apple-darwin20 (64-bit)
>> Running under: macOS Sonoma 14.3.1
>> 
>> Matrix products: default
>> BLAS:   
>> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib
>>  
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;
>>   LAPACK version 3.11.0
>> 
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> 
>> time zone: Europe/Madrid
>> tzcode source: internal
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base 
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_4.3.2
>> 
>> system_profiler SPHardwareDataType | grep Model
>>Model Name: MacBook Air
>>Model Identifier: Mac14,2
>>Model Number: Z161000GJY/A
>> 
>> 
>> 
>>> El 16 feb 2024, a las 14:10, Michael Grundler  
>>> escribió:
>>> 
>>> I am also observing the same behavior as María with the 4.3.2 Patched
>>> binary from mac.r-project.org running under Sonoma 14.3.1 on an m3
>>> mac. Using the default quartz() device and running the example line by
>>> line shows a blank device. If the device window is resized, however,
>>> the expected result appears. The example runs fine using x11(). The
>>> example also runs fine on both quartz() and x11() on my old x86
>>> running under Sonoma 14.2.1.
>>> 
>>>> sessionInfo()
>>> R version 4.3.2 Patched (2024-02-13 r85905)
>>> Platform: aarch64-apple-darwin20 (64-bit)
>>> Running under: macOS Sonoma 14.3.1
>>> 
>>> Matrix products: default
>>> BLAS:   
>>> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib
>>> LAPACK: 
>>> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;
>>> LAPACK version 3.11.0
>>> 
>>> locale:
>>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>>> 
>>> time zone: America/New_York
>>> tzcode source: internal
>>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] compiler_4.3.2
>>> 
>>> ___
>>> 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
>> 
> 
> ___
> 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] Graphics in R, version 4.3.2, does not work well in MacOS

[Simon Urbanek]

I can confirm that this is a bug specific to macOS Sonoma 14.3.1, even earlier 
versions of Sonoma don't have that problem. Given the number of previous bugs 
in Sonoma chances are Apple may fix in the in the next release, but I'll see if 
we can do anything about it on our end in the meantime.

Cheers,
Simon


> On 19/02/2024, at 5:56 AM, María de los Ángeles Casares de Cal via R-SIG-Mac 
>  wrote:
> 
> Thank you very much for your information, Michael.
> 
> I had not realize that by changing the size of the window where all the plots 
> should be, everything appears.
> The same thing happens to me too.
> 
> Regards,
> Ángeles
> 
> 
> sessionInfo()
> R version 4.3.2 (2023-10-31)
> Platform: aarch64-apple-darwin20 (64-bit)
> Running under: macOS Sonoma 14.3.1
> 
> Matrix products: default
> BLAS:   
> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib
>  
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;
>   LAPACK version 3.11.0
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> time zone: Europe/Madrid
> tzcode source: internal
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.3.2
> 
> system_profiler SPHardwareDataType | grep Model
> Model Name: MacBook Air
> Model Identifier: Mac14,2
> Model Number: Z161000GJY/A
> 
> 
> 
>> El 16 feb 2024, a las 14:10, Michael Grundler  
>> escribió:
>> 
>> I am also observing the same behavior as María with the 4.3.2 Patched
>> binary from mac.r-project.org running under Sonoma 14.3.1 on an m3
>> mac. Using the default quartz() device and running the example line by
>> line shows a blank device. If the device window is resized, however,
>> the expected result appears. The example runs fine using x11(). The
>> example also runs fine on both quartz() and x11() on my old x86
>> running under Sonoma 14.2.1.
>> 
>>> sessionInfo()
>> R version 4.3.2 Patched (2024-02-13 r85905)
>> Platform: aarch64-apple-darwin20 (64-bit)
>> Running under: macOS Sonoma 14.3.1
>> 
>> Matrix products: default
>> BLAS:   
>> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;
>> LAPACK version 3.11.0
>> 
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> 
>> time zone: America/New_York
>> tzcode source: internal
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_4.3.2
>> 
>> ___
>> 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
> 

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

Re: [R-SIG-Mac] Graphics in R, version 4.3.2, does not work well in MacOS

[Simon Urbanek]

Maria,

can you, please, include the full output of sessionInfo() in R and 
system_profiler SPHardwareDataType | grep Model
in Terminal? I cannot replicate it, either, but then we have no idea which 
hardware and macOS you are using.

Thanks,
Simon



> On Feb 16, 2024, at 10:25 PM, María de los Ángeles Casares de Cal 
>  wrote:
> 
> Dear Simon and anyone else who might be interested in this:
> 
> I have studied in more detail the problem referred to in the message below, 
> and can confirm that R does not work well on macOS when I do graphics (plots).
> I have only tested with the "abline” command, using the examples that are in 
> R’s help. And it does not work.
> I have tested it on several computers, in Terminal and with RGUI. 
> I have also checked it in RStudio in macOS (it does work) and with R in 
> Windows (it does work).
> 
> What I have done is the following:
> In the "abline" command help, the first example is:
> ## Setup up coordinate system (with x == y aspect ratio):
> 
> plot
> (c(-2,3), c(-1,5), type = "n", xlab = "x", ylab = "y", asp = 1)
> ## the x- and y-axis, and an integer grid
> 
> abline
> (h = 0, v = 0, col = "gray60")
> 
> text
> (1,0, "abline( h = 0 )", col = "gray60", adj = c(0, -.1))
> 
> abline
> (h = -1:5, v = -2:3, col = "lightgray", lty = 3)
> 
> abline
> (a = 1, b = 2, col = 2)
> 
> text
> (1,3, "abline( 1, 2 )", col = 2, adj = c(-.1, -.1))
> 
> if I run line by line, R does not do the plots (only open the Quartz window).
> If I run all together, R does the plots sometimes yes and sometimes no.
> 
> I have the latest stable version of XQuartz (2.8.5)
> 
> What could be the problem?
> 
> Thank you in advance.
> Best regards.
> María-Ángeles Casares-de-Cal
> 
> 
>> Inicio del mensaje reenviado:
>> 
>> De: María de los Ángeles Casares de Cal 
>> Asunto: Spanish version of R, version 4.3.2, does not work
>> Fecha: 14 de febrero de 2024, 20:29:09 CET
>> Para: r-sig-mac@r-project.org
>> 
>> Hi everyone,
>> 
>> I have a problem since I have installed the last version of R 4.3.2 (spanish 
>> version)
>> R does not work!
>> 
>> For example:
>> 
>> x <- 1:20#this is ok
>> y <- 10 + rnorm(n=20,mean=0,sd=1)#this is ok
>> plot(x,y,pch=20,col="red")   #this is ok, but I have to run some 
>> times this
>> model <- lm(y~x)#this is ok
>> summary(model)   #this is ok
>> abline(model)#R does not plot the regression line in 
>> the window where I have the points.
>> 
>> (And this code in RStudio works well).
>> 
>> (I have installed the last version of XQuartz.)
>> 
>> I do not know what is the problem.
>> Perhaps, because is the Spanish version?
>> How can I install the English version?
>> 
>> Any help?
>> Thank you in advance.
>> 
>> Best regards.
>> María-Ángeles Casares-de-Cal
> 

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

Re: [R-SIG-Mac] Miniature plot windows

[Simon Urbanek]

Erik,

thanks, this is very unusual. Can you, please, send me more details about your 
setup? Please run the following two lines in Terminal and send me the full 
output:

system_profiler SPHardwareDataType | grep Model
system_profiler SPDisplaysDataType

Then in R run the following code and also include the result:

inline::cfunction(,'CGDirectDisplayID md = CGMainDisplayID(); CGSize ds = 
CGDisplayScreenSize(md); Rprintf("%.2f x %.2f -> %d x %d\\n", ds.width/25.4, 
ds.height/25.4, (int)CGDisplayPixelsWide(md), (int)CGDisplayPixelsHigh(md)); 
return R_NilValue;','#include ')()

This should result in something like this (install the inline package if you 
don't have it and you will also need command line tools which you can get by 
running
xcode-select --install
in Terminal if you don't have them):

> inline::cfunction(,'CGDirectDisplayID md = CGMainDisplayID(); CGSize ds = 
> CGDisplayScreenSize(md); Rprintf("%.2f x %.2f -> %d x %d\\n", ds.width/25.4, 
> ds.height/25.4, (int)CGDisplayPixelsWide(md), (int)CGDisplayPixelsHigh(md)); 
> return R_NilValue;','#include ')()
23.54 x 13.24 -> 2048 x 1152

This shows the physical size of the screen (in inches) and the current 
resolution.

The Quartz dpi setting is NULL by default which means "detect from hardware" 
which works on all Macs I have seen so the fact that it is way off is odd. The 
code above is how the dimensions are determined.

Cheers,
Simon

PS: if the email processing mangled the above code here is a broken-down 
version that hopefully doesn't get mangled:

inline::cfunction(,'CGDirectDisplayID md = CGMainDisplayID();
CGSize ds = CGDisplayScreenSize(md);
Rprintf("%.2f x %.2f -> %d x %d\\n", ds.width/25.4, ds.height/25.4,
  (int)CGDisplayPixelsWide(md), (int)CGDisplayPixelsHigh(md));
return R_NilValue;',
'#include ')()



> On Jan 23, 2024, at 3:41 AM, Wright, Erik Scott  wrote:
> 
> Hi all,
> 
> I recently upgraded to a new Macbook Pro (Nov 23). Now every plot is 
> miniaturized.
> 
> For example, my screen measures about 13.5" x 8.8" with a ruler. When I 
> create a new plot with plot(1:10) or quartz(height=7, width=7), the plot 
> measures 2.0" x 2.0".
> 
> It is simple enough to initialize larger plot windows with dev.new or 
> quartz(height=24.5, width=24.5), but the points and font stay miniaturized. 
> Of course, I could rescale every single plot feature by 3.5-fold, but that 
> seems like an inefficient solution.
> 
> Any suggestions would be appreciated.
> 
> Erik
> 
> R version 4.3.2 (2023-10-31)
> Platform: aarch64-apple-darwin20 (64-bit)
> Running under: macOS Sonoma 14.2.1
> 
> ___
> 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] Arm 64 Nightly Build URL Missing

[Simon Urbanek]

Brodie,

thanks. There was a problem between the two build VMs where the x86_64 one 
could overwrite arm64's content with a stale content before they got branched. 
This should now be fixed - each should be supplying only its own part.

Cheers,
Simon



> On Jan 22, 2024, at 3:09 AM, Brodie Gaslam via R-SIG-Mac 
>  wrote:
> 
> Hi,
> 
> In addition to the missing link described below, it looks like the nightly 
> build tar.gz has not been updated since 2023-10-30.  This corresponds to the 
> build log[1].  The x86-64 version seems to have a much more recent version 
> (2024-01-19).  I have other methods of running R-devel so this is just an FYI.
> 
> Best,
> 
> B.
> 
> PS: the current arm64 version is 2023-10-30 r85440, which interestingly is a 
> bit newer than the one I reported in the prior e-mail.
> 
> [1]: https://mac.r-project.org/logs/log-R-devel.big-sur.arm64.html
> 
> 
> 
> 
> 
> 
> On Saturday, October 21, 2023 at 11:07:23 AM EDT, Brodie Gaslam 
>  wrote: 
> 
> 
> 
> 
> 
> Hi,
> 
> For some reason the URL in the nightly builds[1] table for the arm64 tar.gz 
> is missing.  The actual tar.gz is there if I start with the x86 URL and 
> modify it, but it is an older version r85331 vs r85355.  Not a big deal at 
> all on my account, just an FYI.
> 
> Thanks for all the hard work of keeping up this infrastructure.  It is really 
> helpful to me.
> 
> Best,
> 
> B.
> 
> [1]: https://mac.r-project.org/#nightly
> 
> ___
> 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 with remotes package

[Simon Urbanek]

Michael,

remotes is a contributed package, so you should contact the author if that is 
what fails (you didn't say). FWIW only the latest version package binaries are 
available on CRAN, so if you need a specific older version of a package you 
need to compile it from sources - so chances are you are missing the necessary 
dependencies or tools to do that, but we can't tell without more details about 
what exactly fails for you.

Cheers,
Simon


> On Dec 8, 2023, at 6:52 AM, Michael Sewell  wrote:
> 
> Hi - I'm a postdoc at the University of Edinburgh who's urgently trying to 
> install an older version of a package (Seurat) listed on CRAN but without 
> success. The package is Seurat_4.4.0.tar.gz.
> 
> I currently work on a M1 Macbook Pro (with Sonoma installed) with RStudio 
> version 4.3.2 and tried to install the package using the following code:
> remotes::install_version(package = 'Seurat', version = 
> package_version('4.4.0'))
> 
> However this appears to be unsuccessful - I was wondering if there is any 
> guidance on how to install these on M1 macbooks? I have also tried 
> uninstalling and reinstalling R many times which again did not succeed. Any 
> help you could give me on this would be much appreciated.
> 
> BW,
> Michael
> 
> 
> Michael Sewell
> Research Fellow
> Montagne Lab
> UK DRI
> The University of Edinburgh
> Twitter: @pichaelmichael_
> Linkedin
> The University of Edinburgh is a charitable body, registered in Scotland, 
> with registration number SC005336. Is e buidheann carthannais a th' ann an 
> Oilthigh Dh�n �ideann, cl�raichte an Alba, �ireamh cl�raidh SC005336.
> 
>   [[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] Nightly builds of R-devel?

[Simon Urbanek]

Kirill,

Due to the necessary iconv workarounds for Sonoma introduced in the R 4.3.2 
build, it complicates the automated nightly builds (they cannot reuse the same 
VM anymore) so the nightly process needs to be updated. I'm currently traveling 
so it will be restored when I get back later next week. Sorry about any 
inconvenience.

Cheers,
Simon



> On 28/11/2023, at 01:37, Kirill Müller via R-SIG-Mac 
>  wrote:
> 
> Hi Simon
> 
> 
> I wonder if it's possible to provide more up-to-date builds of R-devel 
> for macOS, via https://mac.r-project.org/ . I'd like to be able to "just 
> install" the latest and greatest R version. As of today, the most recent 
> is from the end of October, and it looks like three of my packages only 
> break with an R-devel version more recent than that. Thanks!
> 
> Downstream issue: https://github.com/r-lib/rig/issues/204 .
> 
> 
> Best regards
> 
> Kirill
> 
>   [[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] Compiling a library with Rcpp causing many 'unknown type'/'no member named' errors

[Simon Urbanek]

Brian,

you are using Anaconda so all bets are off since that is not supported by CRAN. 
It looks like a broken compiler/runtime combination in Anaconda so your best 
bet would be to contact their support as this is unrelated to R (updating 
Anaconda sounds like an obvious first step, hoping the compiler/runtime issue 
has been fixed in newer version). I would recommend removing Anaconda and using 
released CRAN R version and Apple tools instead if you want a stable solution.

Cheers,
Simon


> On 17/11/2023, at 5:02 AM, Brian Peng  wrote:
> 
> Hi All,
> 
> I am having issues with building my package that uses Rcpp in it. Using 
> 'install' I end up with a ton of compilation errors originating from Cpp 
> include files. There are more details on this Stack Overflow post 
> (https://stackoverflow.com/questions/77491429/compiling-a-library-with-rcpp-causing-many-unknown-type-no-member-named-erro)
>  including the output errors.
> 
> A user there suggested that I may be unable to use anaconda, which I am 
> currently using, as a compiler and should switch to gfortran. However, I we 
> were both unsure of how to direct R to use gfortran instead of anaconda, so 
> he directed me to post to this mailing list. Could the compiler be the issue 
> and if so, how do I switch to gfortran? Is there anything else that might be 
> wrong?
> 
> Thanks,
> Brian
> 
>   [[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] R

[Simon Urbanek]

Please read the instruction on the download page - this is typically due to 
your system setting disallowing installation from the downloaded location so 
you have to move the package to a location from which you have allowed 
installation such as your home.

Cheers,
Simon


> On 18/10/2023, at 1:25 AM, nina.moel...@uni-jena.de wrote:
> 
> 
> Hello,
> 
> I wanted to Download R for a Seminar at FSU Jena and read the posting Guide 
> and all relevant Information that was Provided but i cant install the 
> Package, Mac informed me to contact the platform as shown in the attachment. 
> What can i do ?
> 
> 
> Greetings 
> Nina Möller 
> ___
> 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 4.3.1 fails on Mac OS 14

[Simon Urbanek]

Federico,

yes, you can right-click and select Open. The app is signed, but is it not 
notarized - we only do that for the R release packages, because that's how our 
process works.

Cheers,
Simon


> On Oct 5, 2023, at 11:03 PM, Calboli Federico (LUKE) 
>  wrote:
> 
> “R.app” can’t be opened because Apple cannot check it for malicious software.
> 
>  
> 
> I can circumvent it but I thought it was pretty funny.
> 
>  
> 
> YT
> 
>  
> 
> F
> 
>  
> 
> Federico Calboli
> 
> Erityisasiantuntija, tutkimusrahoitus
> 
> Palveluryhmät
> 
> Luonnonvarakeskus
> 
>  
> 
> I had a look and can reproduce it. What happens is that macOS Sonoma is 
> sending dozens of notifications that a window will close (even if no window 
> is being closed!) and since we move the focus to the next window on close it 
> happens every time macOS sends that notification and thus many times in 
> sequence. Unfortunately it is not clear why Sonoma does it and it makes no 
> sense, so some more digging will be required. I have added a quick hack to 
> simply not change focus on close - it is not ideal as it doesn't address the 
> (unknown) cause which may have many more repercussions, but it lets you try 
> it out (R 4.3.x and arm64 only):
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmac.r-project.org%2Ftest%2FMac-GUI-R-4.3-arm64.dmg&data=05%7C01%7Cfederico.calboli%40luke.fi%7C2d377e4cce6647d542aa08dbc5411c14%7C7c14dfa4c0fc47259f0476a443deb095%7C0%7C0%7C638320655669614200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qBuV%2BBYZ8lod9XR5OxDb%2BSmBsEZ0ZQ24XBOEhVx1ZgM%3D&reserved=0
> 
> Do not use that build on other macOS systems that don't exhibit the bug. 
> There are still more known issues with Sonoma (e.g., you cannot close an R 
> document without saving), so avoid upgrading until it stabilizes more. In the 
> meantime I'll see if I can find out more about the mysterious bugs in Sonoma.
> 
> Cheers,
> Simon
> 
> 
> > On 2/10/2023, at 5:18 AM, William Revelle  wrote:
> > 
> > Dear Mac users of R and developers.
> > 
> > 
> > I recently updated to the Sonoma OS for Mac  (14.0)  and it has a serious 
> > problem for graphics.
> > 
> > plot(1:10) creates a graphic window but I can not switch back to the 
> > console window using either command-1 or the mouse.
> > 
> > Anybody else having this problem?  Any suggestions for a patch?
> > 
> > I am running a MacBook Pro with M1 Max.
> > 
> > Bill
> > 
> > 
> > (resent because of bad mail address)
> > William Revellepersonality-project.org/revelle.html
> > Professorpersonality-project.org
> > Department of Psychology 
> > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wcas.northwestern.edu%2Fpsych%2F&data=05%7C01%7Cfederico.calboli%40luke.fi%7C2d377e4cce6647d542aa08dbc5411c14%7C7c14dfa4c0fc47259f0476a443deb095%7C0%7C0%7C638320655669614200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wk25sWTofnbVZN%2BSruJ4vgQIMrPyudLObJ%2FFGDFwhyQ%3D&reserved=0
> > Northwestern University
> > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.northwestern.edu%2F&data=05%7C01%7Cfederico.calboli%40luke.fi%7C2d377e4cce6647d542aa08dbc5411c14%7C7c14dfa4c0fc47259f0476a443deb095%7C0%7C0%7C638320655669614200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y2IVhxJRzlbHi5xvmlyPvORuZqa5qJl%2B8WplofJ2sws%3D&reserved=0
> > Use R for psychology personality-project.org/r
> > It is 90 seconds to midnight
> > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.thebulletin.org%2F&data=05%7C01%7Cfederico.calboli%40luke.fi%7C2d377e4cce6647d542aa08dbc5411c14%7C7c14dfa4c0fc47259f0476a443deb095%7C0%7C0%7C638320655669614200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kxMB3j0YxyUyyxnRXNMImHSvKHOiF6ixoRKhF%2BOblv4%3D&reserved=0
> > 
> > ___
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-sig-mac&data=05%7C01%7Cfederico.calboli%40luke.fi%7C2d377e4cce6647d542aa08dbc5411c14%7C7c14dfa4c0fc47259f0476a443deb095%7C0%7C0%7C638320655669770414%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XLcVtXY0FJq2z%2BBMaduds7CgiVeWBPjqatpfVQG%2B1RI%3D&reserved=0
> >
> 

___
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.3.1 fails on Mac OS X Sonoma

[Simon Urbanek]

Kevin,


> On 4/10/2023, at 5:27 AM, Kevin Thorpe  wrote:
> 
> Hello.
> 
> I am wondering if this is just an issue on M1/2 chips or does it also affect 
> Intel?
> 

It is an issue with Sonoma macOS new TUI classes and not the architecture so it 
will affect both.


> I usually hold off upgrading until the first or second patch, but I feel I 
> should warn students in my class.
> 

Definitely - I always tell them not to upgrade right away as major macOS 
versions are notoriously buggy. Ideally, you shouldn't upgrade until next R 
patch release since if macOS breaks something we can't fix (officially) it 
until the next release.

Cheers,
Simon


> 
> 
>> On Oct 3, 2023, at 12:14 PM, William R Revelle  
>> wrote:
>> 
>> [You don't often get email from reve...@northwestern.edu. Learn why this is 
>> important at https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> It turns out that is not just the graphics window that the focus problem, it 
>> is all windows.  That is, opening the help window takes focus away from the 
>> console and help needs to be closed before the console window will be 
>> active.  The install package window has the same problem.
>> 
>> For each case, closing the extra window restores console functioning.
>> 
>> I report this just so Simon can see the report.
>> 
>> I remain in awe of the work of Simon in getting the Mac version to work so 
>> well.
>> 
>> I am running
>> 
>> R version 4.3.1 Patched (2023-09-30 r85239)
>> Platform: aarch64-apple-darwin20 (64-bit)
>> Running under: macOS Sonoma 14.0
>> 
>> Bill
>> 
>> 
>>> On Oct 1, 2023, at 12:13 PM, Sparapani, Rodney  wrote:
>>> 
>>> I hear you!  It is not just R either.  I know you mentioned R-studio.
>>> But there are lots of other things R-related like emacs.  I had the
>>> hardest time with emacs for Catalina and Big sur.  I’m not sure
>>> but I think Monterrey was better.  However, all of those issues
>>> finally went away with Ventura.  This makes me extremely hesitant for Sonoma
>>> since I am finally happy now.  So long story short: Apple gets there,
>>> but it can take years sometimes.  The new hardware like ARM (and
>>> the titanium iPhone!) look so cool it can be very tempting to go
>>> bleeding-edge. I learned my lesson when Ventura first came out.
>>> R was not ready and neither were lots of tools that we use here
>>> at work.  Good luck
>>> --
>>> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
>>> Vice President, Wisconsin Chapter of the American Statistical Association
>>> Institute for Health and Equity, Division of Biostatistics
>>> Medical College of Wisconsin, Milwaukee Campus
>>> From: William Revelle 
>>> Date: Sunday, October 1, 2023 at 12:01 PM
>>> To: Sparapani, Rodney , r-sig-mac@r-project.org 
>>> 
>>> Subject: Re: [R-SIG-Mac] R 4.3.1 fails on Mac OS X Sonoma
>>> ATTENTION: This email originated from a sender outside of MCW. Use caution 
>>> when clicking on links or opening attachments.
>>> 
>>> 
>>> Rodney,
>>> 
>>> Thanks for your quick reply.
>>> 
>>> It turns out this is just a problem with the base R  for Mac graphics 
>>> window (which is to say, the version I like).  I can still use R-studio 
>>> (which I don’t like as much).
>>> 
>>> I can wait patiently for a patch to the Mac version while using R-Studio.
>>> 
>>> That way I don’t have to go through the hassle of trying to reinstall 13.x 
>>> and dumping 14.0.
>>> 
>>> Bill
>>> 
>>> 
 On Oct 1, 2023, at 11:22 AM, Sparapani, Rodney  wrote:
 
 Hi Bill:
 Well, I am usually pretty cautious about this.  I don’t move to the
 next release until R is ready.  For Ventura, it took quite awhile
 before that happened.  Sorry
 --
 Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
 Vice President, Wisconsin Chapter of the American Statistical Association
 Institute for Health and Equity, Division of Biostatistics
 Medical College of Wisconsin, Milwaukee Campus
 From: R-SIG-Mac  on behalf of William 
 Revelle 
 Date: Sunday, October 1, 2023 at 11:19 AM
 To: r-sig-mac@r-project.org 
 Subject: [R-SIG-Mac] R 4.3.1 fails on Mac OS 1
 ATTENTION: This email originated from a sender outside of MCW. Use caution 
 when clicking on links or opening attachments.
 
 
 Dear Mac users of R and developers.
 
 
 I recently updated to the Sonoma OS for Mac  (14.0)  and it has a serious 
 problem for graphics.
 
 plot(1:10) creates a graphic window but I can not switch back to the 
 console window using either command-1 or the mouse.
 
 Anybody else having this problem?  Any suggestions for a patch?
 
 I am running a MacBook Pro with M1 Max.
 
 Bill
 
 
 (resent because of bad mail address)
 William Revellepersonality-project.org/revelle.html
 Professorpersonality-project.org
 Department of Psy

Re: [R-SIG-Mac] R 4.3.1 fails on Mac OS 14

[Simon Urbanek]

I had a look and can reproduce it. What happens is that macOS Sonoma is sending 
dozens of notifications that a window will close (even if no window is being 
closed!) and since we move the focus to the next window on close it happens 
every time macOS sends that notification and thus many times in sequence. 
Unfortunately it is not clear why Sonoma does it and it makes no sense, so some 
more digging will be required. I have added a quick hack to simply not change 
focus on close - it is not ideal as it doesn't address the (unknown) cause 
which may have many more repercussions, but it lets you try it out (R 4.3.x and 
arm64 only):

https://mac.R-project.org/test/Mac-GUI-R-4.3-arm64.dmg

Do not use that build on other macOS systems that don't exhibit the bug. There 
are still more known issues with Sonoma (e.g., you cannot close an R document 
without saving), so avoid upgrading until it stabilizes more. In the meantime 
I'll see if I can find out more about the mysterious bugs in Sonoma.

Cheers,
Simon


> On 2/10/2023, at 5:18 AM, William Revelle  wrote:
> 
> Dear Mac users of R and developers.
> 
> 
> I recently updated to the Sonoma OS for Mac  (14.0)  and it has a serious 
> problem for graphics.
> 
> plot(1:10) creates a graphic window but I can not switch back to the console 
> window using either command-1 or the mouse.
> 
> Anybody else having this problem?  Any suggestions for a patch?
> 
> I am running a MacBook Pro with M1 Max.
> 
> Bill
> 
> 
> (resent because of bad mail address)
> William Revellepersonality-project.org/revelle.html
> Professorpersonality-project.org
> Department of Psychology www.wcas.northwestern.edu/psych/
> Northwestern Universitywww.northwestern.edu/
> Use R for psychology personality-project.org/r
> It is 90 seconds to midnightwww.thebulletin.org
> 
> ___
> 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] How can I stop my R console and other R windows "flickering" after I updated my Mac OS to Sonoma 14.0?

[Simon Urbanek]

Desmond,

thanks for the report. There seem to be windows focus issue in Sonoma so I 
would not recommend upgrading at this point. Hopefully this will be fixed in a 
future macOS update (the .0 versions are notoriously flaky) - in the meantime 
I'll see if there is any work-around we could do in R.

Cheers,
Simon



> On Oct 1, 2023, at 5:46 AM, Smith, Desmond  wrote:
> 
> Dear All,
> 
> I updated my Apple Silicon M1 Pro MacBook from Ventura to Sonoma 14.0. I have 
> the latest version of R for Apple Silicon (4.3.1, "Beagle Scouts"). I also 
> have the latest version of XQuartz (2.8.5).
> 
> On Ventura, my R setup worked fine ("classic" R.app GUI using console and 
> script windows, not Rstudio or terminal). However, with Sonoma, when I try 
> and toggle between the R console and an R script, the windows transition at 
> very high speed between each other, making it nearly impossible to select 
> either the console or the script.
> 
> This "flickering" phenomenon lasts for ~ 10-15 seconds each time I change 
> windows between console and script, making the software nearly unusable. 
> Changing the screen refresh rate does not help.
> 
> The problem is specific for R.app and does not affect other software.
> 
> Any suggestions gratefully received. I have also posted this question to 
> stackoverflow.
> 
> Many thanks,
> 
> Desmond Smith
> 
> 
> 
> 
> 
> UCLA HEALTH SCIENCES IMPORTANT WARNING: This email (and any attachments) is 
> only intended for the use of the person or entity to which it is addressed, 
> and may contain information that is privileged and confidential. You, the 
> recipient, are obligated to maintain it in a safe, secure and confidential 
> manner. Unauthorized redisclosure or failure to maintain confidentiality may 
> subject you to federal and state penalties. If you are not the intended 
> recipient, please immediately notify us by return email, and delete this 
> message from your computer.
> 
>   [[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] Rebuild binaries when a LinkingTo dependency changes

[Simon Urbanek]

ing required namespace: TMB
> 
> 
> 
> # Example 2: upgrading Matrix after installing TMB
> 
> dir.create("templib")
> .libPaths(normalizePath("templib"))
> Sys.setenv(R_LIBS_USER = .libPaths()[[1]])
> 
> # Sanity check
> rownames(installed.packages())
> #>  [1] "base"   "boot"   "class"  "cluster""codetools" 
> #>  [6] "compiler"   "datasets"   "foreign""graphics"   "grDevices" 
> #> [11] "grid"   "KernSmooth" "lattice""MASS"   "Matrix"
> #> [16] "methods""mgcv"   "nlme"   "nnet"   "parallel"  
> #> [21] "rpart"  "spatial""splines""stats"  "stats4"
> #> [26] "survival"   "tcltk"  "tools"  "utils"
> packageVersion("Matrix")
> #> [1] '1.5.4.1'
> 
> # Install TMB from source, now matching the Matrix version
> install.packages(c("Rcpp", "RcppEigen"))
> #> Installing packages into 
> '/private/var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T/RtmpSL7Etm/reprex-bc8b4fff25a6-next-esok/templib'
> #> (as 'lib' is unspecified)
> #> 
> #> The downloaded binary packages are in
> #>  
> /var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T//RtmpyN9yHv/downloaded_packages
> install.packages("TMB", type = "source", repos = 
> "https://cloud.r-project.org/";)
> #> Installing package into 
> '/private/var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T/RtmpSL7Etm/reprex-bc8b4fff25a6-next-esok/templib'
> #> (as 'lib' is unspecified)
> 
> # Upgrading Matrix
> install.packages("Matrix")
> #> Installing package into 
> '/private/var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T/RtmpSL7Etm/reprex-bc8b4fff25a6-next-esok/templib'
> #> (as 'lib' is unspecified)
> #> 
> #> The downloaded binary packages are in
> #>  
> /var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T//RtmpyN9yHv/downloaded_packages
> 
> # Perform implicit consistency check
> packageVersion("Matrix")
> #> [1] '1.6.1.1'
> requireNamespace("TMB")
> #> Loading required namespace: TMB
> #> Warning in checkMatrixPackageVersion(): Package version inconsistency 
> detected.
> #> TMB was built with Matrix version 1.5.4.1
> #> Current Matrix version is 1.6.1.1
> #> Please re-install 'TMB' from source using install.packages('TMB', type = 
> 'source') or ask CRAN for a binary version of 'TMB' matching CRAN's 'Matrix' 
> package
> 
> 
> 
> On 25.09.23 15:22, Simon Urbanek wrote:
>> Kirill,
>> 
>> we have no way of knowing when a packages introduced a breaking change 
>> (which it really shouldn't), so the maintainers would have to inform as 
>> (Matrix authors did inform us that 1.6.0 introduces breaking change so 
>> that's why we did a manual re-bulid on that update). Also checking exact 
>> version (like TMB seems to do) doesn't work for the same reason and is not a 
>> good way to deal with the problem - we cannot re-build all packages with 
>> each change, because of the amount of time that would take (by now it takes 
>> more that a day to re-build CRAN just for one R target) and more fundamental 
>> problem with re-builds:
>> 
>> The real problem here is deeper than just triggering rebuilds: the users 
>> have no way of knowing if a package has been re-built and updated, because 
>> the version does not change. If let's say TMB is release 1.0 used Matrix 
>> 1.6.0 and then Matrix is updated to 1.6.1 then TMB cannot require it because 
>> it did not bump its version, i.e. the binary for TMB 1.0 with Matrix 1.6.0 
>> is indistinguishable from a binary of TMB 1.0 with Matrix 1.6.1 on CRAN so 
>> if the user used update.packages() it would not count as a new TMB version. 
>> Therefore TMB really has to update its version from 1.0 to let's say 1.0-1 
>> if it requests a rebuild against changes in Matrix 1.6.1. Clearly, this is 
>> not ideal, but currently there is other way that would guarantee consistency 
>> of binaries. We are aware of the problem and we are we are in fact thinking 
>> about possible solutions (special tags on binary versions) for future 
>> version of R, but for now the package authors have to be aware of potential 
>&

Re: [R-SIG-Mac] Rebuild binaries when a LinkingTo dependency changes

[Simon Urbanek]

Kirill,

we have no way of knowing when a packages introduced a breaking change (which 
it really shouldn't), so the maintainers would have to inform as (Matrix 
authors did inform us that 1.6.0 introduces breaking change so that's why we 
did a manual re-bulid on that update). Also checking exact version (like TMB 
seems to do) doesn't work for the same reason and is not a good way to deal 
with the problem - we cannot re-build all packages with each change, because of 
the amount of time that would take (by now it takes more that a day to re-build 
CRAN just for one R target) and more fundamental problem with re-builds:

The real problem here is deeper than just triggering rebuilds: the users have 
no way of knowing if a package has been re-built and updated, because the 
version does not change. If let's say TMB is release 1.0 used Matrix 1.6.0 and 
then Matrix is updated to 1.6.1 then TMB cannot require it because it did not 
bump its version, i.e. the binary for TMB 1.0 with Matrix 1.6.0 is 
indistinguishable from a binary of TMB 1.0 with Matrix 1.6.1 on CRAN so if the 
user used update.packages() it would not count as a new TMB version. Therefore 
TMB really has to update its version from 1.0 to let's say 1.0-1 if it requests 
a rebuild against changes in Matrix 1.6.1. Clearly, this is not ideal, but 
currently there is other way that would guarantee consistency of binaries. We 
are aware of the problem and we are we are in fact thinking about possible 
solutions (special tags on binary versions) for future version of R, but for 
now the package authors have to be aware of potential breakage upstream.

Cheers,
Simon


> On 26/09/2023, at 7:46 AM, Kirill Müller via R-SIG-Mac 
>  wrote:
> 
> Hi
> 
> 
> The TMB package has Matrix in its LinkingTo dependencies. In a clean package 
> library, I see behavior posted below.
> 
> Should the TMB package have been rebuilt when a new version of the Matrix 
> package was pushed? More general, should we rebuild all reverse LinkingTo 
> dependencies of a package that gets an update on CRAN? This will mean a lot 
> of package rebuilds with Rcpp, but also a lot less frustration down the road. 
> Thanks!
> 
> 
> Best regards
> 
> Kirill
> 
> 
> dir.create("templib")
> .libPaths(normalizePath("templib"))
> 
> # Sanity check
> rownames(installed.packages())
> #>  [1] "base"   "boot"   "class"  "cluster" "codetools"
> #>  [6] "compiler"   "datasets"   "foreign""graphics" "grDevices"
> #> [11] "grid"   "KernSmooth" "lattice""MASS" "Matrix"
> #> [16] "methods""mgcv"   "nlme"   "nnet" "parallel"
> #> [21] "rpart"  "spatial""splines""stats" "stats4"
> #> [26] "survival"   "tcltk"  "tools"  "utils"
> packageVersion("Matrix")
> #> [1] '1.5.4.1'
> 
> # Install fresh binary packages
> install.packages(c("Matrix", "TMB"))
> #> Installing packages into 
> '/private/var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T/RtmpXIjIPy/reprex-87aa25cc1fa4-sugar-cob/templib'
> #> (as 'lib' is unspecified)
> #> also installing the dependencies 'Rcpp', 'RcppEigen'
> #>
> #> The downloaded binary packages are in
> #> 
> /var/folders/dj/yhk9rkx97wn_ykqtnmk18xvcgn/T//Rtmp4GSL7m/downloaded_packages
> packageVersion("Matrix")
> #> [1] '1.6.1.1'
> 
> # Perform implicit consistency check
> requireNamespace("TMB")
> #> Loading required namespace: TMB
> #> Warning in checkMatrixPackageVersion(): Package version inconsistency 
> detected.
> #> TMB was built with Matrix version 1.6.0
> #> Current Matrix version is 1.6.1.1
> #> Please re-install 'TMB' from source using install.packages('TMB', type = 
> 'source') or ask CRAN for a binary version of 'TMB' matching CRAN's 'Matrix' 
> package
> 
> ___
> 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] Rcmdr

[Simon Urbanek]

Agreed, no problem here even with Rcmdr in older R 4.2.0. As Peter said, Rcmdr 
doesn't use tcltk2 so I'm sure there is a lot you're omitting here. If it 
doubt, make sure you don't load some old workspace and have the latest versions 
of all packages, e.g. via update.packages(ask=FALSE).

Cheers,
Simon



> On 1/08/2023, at 1:18 AM, peter dalgaard  wrote:
> 
> Hum.. Not happening here with 4.3.1 from CRAN. Why are you getting errors 
> relating to 4.2? Also puzzling is library/tcltk2, which I don't seem to have 
> (only tcltk). 
> 
> A hunch is that the tcltk2 package could be involved, but even installing 
> that, I don't see a directory of that name under R.framework.
> 
> - pd
> 
>> On 22 Jul 2023, at 14:20 , Sabrina Droussy  wrote:
>> 
>> 
>>> 
>>> Hello,
>>> I have a big problem with R. I hope you can help me please.
>>> I didn’t use R for some months and wanted to use it again to prepare an 
>>> exam. I can’t open Rcmdr anymore. I tried several things : install 
>>> packages, delete and reinstall R. It isn’t working.
>>> 
>>> Here is the message I get :
>>> error reading package index file / Library/ Frameworks / R. Framework/ 
>>> Versions/ 4.2/ Resources/ 
>>> library/tcltk2/tklibs/ttktheme_radiance/pkgIndex.tcl: can’t find package 
>>> tile
>>> error reading package index file / Library/ Frameworks / R. Framework/ 
>>> Versions/ 4.2/ Resources/ 
>>> library/tcltk2/tklibs/ttktheme_clearlooks/pkgIndex.tcl: too many nested 
>>> evaluations (infinite loop ? )  
>>> 
>>> Best regards 
>>> 
>>> Envoyé de mon iPhone
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> -- 
> 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
> 

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

Re: [R-SIG-Mac] M1+ R package test failures (local and Mac Builder)

[Simon Urbanek]

Daniel,

I'm not sure I understand your question. The package mmrm 0.2.2 fails its tests 
for me as well. If you can reproduce the problem locally (as you indicated), 
then that's good as you should be in the position to fix it.

Cheers,
Simon


> On 26/07/2023, at 1:50 AM, Sabanes Bove, Daniel via R-SIG-Mac 
>  wrote:
> 
> Hi R@Mac developers,
> 
> I switched yesterday to a new M2 MacBook, coming from a 3+ year old Intel
> MacBook.
> The concrete problem is that my R package mmrm (including C++ and in
> particular Eigen/TMB code) successfully compiles, but the tests fail, i.e.
> the compiled and installed R package does not behave correctly.
> 
> First I thought that this is just my local toolchain which is not yet
> appropriately configured, but I tried to read more on that and got OpenMP
> and gfortran and it should be ok.
> So I thought ok, maybe I will try the Mac Builder website and find out in
> which commit the R package broke.
> 
> Unfortunately, the problem is that the Mac Builder does not help us
> sufficiently here, because even the current CRAN release (0.2.2, where
> tests based on CRAN binary pass fine locally and on CRAN) leads to test
> failures on Mac Builder.
> 
> I do see a few differences between the CRAN reported setup and the mac
> Builder:
> - CRAN is running under macOS Big Sur 11.6.7, while Mac Builder is running
> under macOS Ventura 13.3.1 (same as my local machine)
> - CRAN uses C++ compiler ‘Apple clang version 13.0.0 (clang-1300.0.29.30)’
> (and not 14.0.0 as used for the R compilation!) for the package build,
> while Mac Builder uses ‘Apple clang version 14.0.3 (clang-1403.0.22.14.1)’
> (this is the same as on my local machine)
> 
> At least Mac Builder and my local machine thus use a similar setup it
> seems (even though M1 vs M2 difference exists)
> 
> My question is: what are your tips on how to move forward here? How can we
> set up the Apple clang version and maybe other build flags locally - as
> well as on Mac Builder for the whole community - to really match the CRAN
> configuration sufficiently well and thus allow for successful package
> builds?
> 
> Thanks all,
> best regards
> Daniel
> 
>   [[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] Macbuilder appears down again

[Simon Urbanek]

Avi,

thanks. Everything seems to work for me. 404 for the link shown in the response 
will occur if the job has not yet been picked up, because the system is 
somewhat optimistic about assuming a job will be picked up faster than you can 
click on the link. The result page is only generated as the first step of the 
job (before the actual check). If you can submit at all it means the submission 
system is running fine. Should you get 404 for a prolonged period of time, let 
me know. There is a time limit for each package check, so a package should not 
be able to block the system.

Cheers,
Simon



> On 21/07/2023, at 7:56 AM, Avraham Adler  wrote:
> 
> Hello,
> 
> I fear that the builder [1] is down again as my submissions consistently
> return a 404 error.
> 
> Thank you,
> 
> Avi
> 
> [1] https://mac.r-project.org/macbuilder/submit.html
> 

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

Re: [R-SIG-Mac] gfortran: command not found

[Simon Urbanek]

> On Jul 7, 2023, at 6:54 PM, Prof Brian Ripley  wrote:
> 
> An alternative is not to have gfortran on the path and use a personal 
> Makevars file, as documented at 
> https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#macOS-packages .
> 
> Reasons to do it that way include
> 
> a) GCC builds have included other compilers including gcc in the same 
> directory as gfortran, and I have been caught in the past by badly-written 
> software looking for gcc as a C compiler and finding that one rather than 
> Apple's gcc which is a wrapper for clang.  (The current gfortran distribution 
> only includes x86_64-apple-darwin20.0-gcc and similar.)
> 
> b) If the gfortran you have installed differs from that used to build R, you 
> may need to set FLIBS, and this has happened as different CRAN distributions 
> have been built with different versions of gfortran.
> 
> When I do want gfortran on the path, for example to build other software, I 
> do symlink it to somewhere on my path.
> 
> I would prefer if Simon continues to give the full path as FC in 
> etc/Makeconf: anyone who wants a different compiler can use a personal 
> Makevars.  (Continues at least for arm64, and I would prefer consistency.)
> 


I agree - it wasn't entirely intentional (it's really historical), but then 
there was request for a PATH-less gfortran settings. After this discussion I 
agree that it's not a good idea since the instructions on CRAN should be fully 
self-sufficient *and* we want to avoid other incompatible Fortran compilers. (I 
have trouble reaching the x86_64 build machine from home right now, so I'll 
change it on Monday).

Thanks,
Simon


> 
> On 07/07/2023 00:07, Simon Urbanek wrote:
>>> On 7/07/2023, at 10:15 AM, Spencer Graves  
>>> wrote:
>>> 
>>> Hi, Simon:
>>> 
>>> 
>>>   Thanks for this.  I have more questions:
>>> 
>>> 
>>> On 7/6/23 4:52 PM, Simon Urbanek wrote:
>>>> In the shell:
>>>> PATH=/opt/gfortran/bin:$PATH R CMD INSTALL ...
>>> 
>>> 
>>>   Please excuse my ignorance, but I don't understand this.  I 
>>> previously tried "PATH=/bin:/sbin:/user/bin:/user/sbin:/system/Library/ 
>>> export PATH", recommended on a page associated with support.apple.com, as 
>>> mentioned below.  That did not seem to work for me.
>>> 
>> That one sets the specified fixed path and then exports it. Setting a fixed 
>> PATH by hand is typically a bad idea since it removes all existing entries - 
>> and the one you listed didn't even have gfortran on it. Exporting is another 
>> alternative if you want to set the PATH for all subsequent commands.
>> The line I sent just prepends the /opt/gfortran/bin to the PATH for the one 
>> R CMD command, but doesn't affect anything else. I would recommend reading a 
>> basic tutorial on unix shell if you really want to know more (actually a 
>> good idea if you ever want to use the Terminal and not kill your machine).
>>>   How is this different?  What did I do wrong before that this would 
>>> fix?  [Or feel free to ignore this question:  My immediate problem seems to 
>>> be fixed, and I'm not eager to do more experimentation with this now ;-]
>>> 
>>>> in R if using install.packages()
>>>> Sys.setenv(PATH=paste0("/opt/gfortran/bin:", Sys.getenv("PATH")))
>>> 
>>> 
>>>   If I set this in RStudio, will it affect what I do in "Terminal" on 
>>> my Mac and vice versa?
>>> 
>> No, it is only valid for the current R session (and I don't know about 
>> RStudio - it's not R so sometimes R rules don't apply), that's why I said 
>> it's for the case where you run install.packages() in the R session.
>> Note that another alternative is to simply symlink gfortran to your 
>> /usr/local/bin since that is on the PATH on macOS by default, i.e., you only 
>> need to run this in the Terminal once (requires admin access):
>> sudo ln -sfn /opt/gfortran/bin/gfortran /usr/local/bin/gfortran
>> Cheers,
>> Simon
>>> 
>>>   This looks like a potentially similar thing to do from what I did. Is 
>>> the effect of this different?  If so, how? [Again, please feel free to 
>>> ignore this question.  I'm not eager to practice my "do-it-myself lobotomy" 
>>> skills ;-]
>>> 
>>> 
>>>   Thanks,
>>>   Spencer Graves>
>>>>> On Jul 7, 2023, at 5:58 AM, Spencer Graves  
>>>>> wrote:
>>>&

Re: [R-SIG-Mac] gfortran: command not found

[Simon Urbanek]

> On 7/07/2023, at 10:15 AM, Spencer Graves  wrote:
> 
> Hi, Simon:
> 
> 
> Thanks for this.  I have more questions:
> 
> 
> On 7/6/23 4:52 PM, Simon Urbanek wrote:
>> In the shell:
>> PATH=/opt/gfortran/bin:$PATH R CMD INSTALL ...
> 
> 
> Please excuse my ignorance, but I don't understand this.  I 
> previously tried "PATH=/bin:/sbin:/user/bin:/user/sbin:/system/Library/ 
> export PATH", recommended on a page associated with support.apple.com, as 
> mentioned below.  That did not seem to work for me.
> 

That one sets the specified fixed path and then exports it. Setting a fixed 
PATH by hand is typically a bad idea since it removes all existing entries - 
and the one you listed didn't even have gfortran on it. Exporting is another 
alternative if you want to set the PATH for all subsequent commands.

The line I sent just prepends the /opt/gfortran/bin to the PATH for the one R 
CMD command, but doesn't affect anything else. I would recommend reading a 
basic tutorial on unix shell if you really want to know more (actually a good 
idea if you ever want to use the Terminal and not kill your machine).


> How is this different?  What did I do wrong before that this would 
> fix?  [Or feel free to ignore this question:  My immediate problem seems to 
> be fixed, and I'm not eager to do more experimentation with this now ;-]
> 
>> in R if using install.packages()
>> Sys.setenv(PATH=paste0("/opt/gfortran/bin:", Sys.getenv("PATH")))
> 
> 
> If I set this in RStudio, will it affect what I do in "Terminal" on 
> my Mac and vice versa?
> 

No, it is only valid for the current R session (and I don't know about RStudio 
- it's not R so sometimes R rules don't apply), that's why I said it's for the 
case where you run install.packages() in the R session.


Note that another alternative is to simply symlink gfortran to your 
/usr/local/bin since that is on the PATH on macOS by default, i.e., you only 
need to run this in the Terminal once (requires admin access):

sudo ln -sfn /opt/gfortran/bin/gfortran /usr/local/bin/gfortran

Cheers,
Simon




> 
> This looks like a potentially similar thing to do from what I did. Is 
> the effect of this different?  If so, how? [Again, please feel free to ignore 
> this question.  I'm not eager to practice my "do-it-myself lobotomy" skills 
> ;-]
> 
> 
> Thanks,
> Spencer Graves>
>>> On Jul 7, 2023, at 5:58 AM, Spencer Graves  
>>> wrote:
>>> 
>>> 1.  I need to apologize to Simon:  I failed to see his reply to the 
>>> original post.  Then I found the instructions and installed 
>>> gfortran-12.2-universal.pkg, as indicated there, but it still didn't work.
>>> 
>>> 
>>> 2.  I'm not finding clear instructions on how to update the path on macOS 
>>> 11.7.8, which is the latest version available for my 2014 MacBook Pro with 
>>> a 2.8 GHz Quad-Core Intel Core i7.  I found several pages with differing 
>>> instructions.  I found one in "support.apple.com" that recommended 
>>> something that didn't work.[2]
>>> 
>>> 
>>>   Further suggestions?
>>> 
>>> 
>>>   Thanks again very much.
>>>   Spencer Graves
>>> 
>>> 
>>> [2] "support.apple.com" recommended 
>>> "PATH=/bin:/sbin:/user/bin:/user/sbin:/system/Library/ export PATH", then 
>>> "env".  I did "env" to get the current path, than appended 
>>> ":/opt/gfortran/bin" to that and executed the revised 
>>> "PATH=...:/opt/gfortran/bin export PATH".  However, when I checked with 
>>> "env" again, the change was not displayed.  I rebooted with the same result.
>>> 
>>> 
>>> https://support.apple.com/guide/terminal/use-environment-variables-apd382cc5fa-4f58-4449-b20a-41c53c006f8f/mac
>>> 
>>> 
>>> On 7/6/23 11:01 AM, Simon Urbanek wrote:
>>>> AFACT he didn't say so, there was no response, just double-posting of the 
>>>> same question after is was answered.
>>>> The installer says:
>>>> The resulting compiler will live in /opt/gfortran and can be called with
>>>> /opt/gfortran/bin/gfortran
>>>> so it's advisable to have /opt/gfortran/bin on the PATH.
>>>> (Side note: the arm64 build of R uses the full path, but some people have 
>>>> been objecting to that since they wanted to use other compilers for the 
>>>> legacy Intel builds, b

Re: [R-SIG-Mac] gfortran: command not found

[Simon Urbanek]

In the shell:

PATH=/opt/gfortran/bin:$PATH R CMD INSTALL ...

in R if using install.packages()

Sys.setenv(PATH=paste0("/opt/gfortran/bin:", Sys.getenv("PATH")))



> On Jul 7, 2023, at 5:58 AM, Spencer Graves  
> wrote:
> 
> 1.  I need to apologize to Simon:  I failed to see his reply to the original 
> post.  Then I found the instructions and installed 
> gfortran-12.2-universal.pkg, as indicated there, but it still didn't work.
> 
> 
> 2.  I'm not finding clear instructions on how to update the path on macOS 
> 11.7.8, which is the latest version available for my 2014 MacBook Pro with a 
> 2.8 GHz Quad-Core Intel Core i7.  I found several pages with differing 
> instructions.  I found one in "support.apple.com" that recommended something 
> that didn't work.[2]
> 
> 
> Further suggestions?
>   
> 
> Thanks again very much.
> Spencer Graves
> 
> 
> [2] "support.apple.com" recommended 
> "PATH=/bin:/sbin:/user/bin:/user/sbin:/system/Library/ export PATH", then 
> "env".  I did "env" to get the current path, than appended 
> ":/opt/gfortran/bin" to that and executed the revised 
> "PATH=...:/opt/gfortran/bin export PATH".  However, when I checked with "env" 
> again, the change was not displayed.  I rebooted with the same result.
> 
> 
> https://support.apple.com/guide/terminal/use-environment-variables-apd382cc5fa-4f58-4449-b20a-41c53c006f8f/mac
> 
> 
> On 7/6/23 11:01 AM, Simon Urbanek wrote:
>> AFACT he didn't say so, there was no response, just double-posting of the 
>> same question after is was answered.
>> The installer says:
>> The resulting compiler will live in /opt/gfortran and can be called with
>> /opt/gfortran/bin/gfortran
>> so it's advisable to have /opt/gfortran/bin on the PATH.
>> (Side note: the arm64 build of R uses the full path, but some people have 
>> been objecting to that since they wanted to use other compilers for the 
>> legacy Intel builds, but as I suspected that causes other issues, so I'll 
>> change that for the next release).
>> Cheers,
>> Simon
>>> On Jul 6, 2023, at 11:45 PM, Peter Dalgaard >> <mailto:pda...@gmail.com>> wrote:
>>> 
>>> AFAICT, Spencer followed the implied instructions and it still didn't work.
>>> 
>>> There may also be a PATH issue when upgrading to 4.3.x, /usr/local -> 
>>> /opt/R/ Does gfortran 12.2 install to /opt/R/.../bin ?
>>> 
>>> -pd
>>> 
>>>> On 6 Jul 2023, at 07:42 , Simon Urbanek >>> <mailto:simon.urba...@r-project.org>> wrote:
>>>> 
>>>> Already answered to you and on R-pkg-devel [9 mins after you posted there 
>>>> - now more than 5h ago...]:
>>>> 
>>>> To quote from the page you downloaded R from:
>>>> 
>>>> This release uses Xcode 14.2/14.3 and GNU Fortran 12.2. If you wish to 
>>>> compile R packages which contain Fortran code, you may need to download 
>>>> the corresponding GNU Fortran compiler from 
>>>> https://mac.R-project.org/tools <https://mac.R-project.org/tools> 
>>>> <https://mac.r-project.org/tools <https://mac.r-project.org/tools>>.
>>>> 
>>>> 
>>>> 
>>>>> On Jul 6, 2023, at 5:16 PM, Spencer Graves >>>> <mailto:spencer.gra...@prodsyse.com>> wrote:
>>>>> 
>>>>> Hello, All:
>>>>> 
>>>>> 
>>>>>  "R CMD check KFAS" under macOS 11.7.8 (the latest version that will run 
>>>>> on my aging Mac) complains "gfortran: command not found".
>>>>> 
>>>>> 
>>>>>  I just upgraded to R 4.3.1 and installed "gfortran-12.2-universal.pkg" 
>>>>> per "https://cran.r-project.org/bin/macosx/tools/ 
>>>>> <https://cran.r-project.org/bin/macosx/tools/>".  I expected this to 
>>>>> solve the problem.  It didn't.
>>>>> 
>>>>> 
>>>>>  Suggestions?
>>>>>  Thanks,
>>>>>  Spencer Graves
>>>>> 
>>>>> 
>>>>> p.s.  This is my fork of KFAS, available at 
>>>>> "https://github.com/sbgraves237/KFAS 
>>>>> <https://github.com/sbgraves237/KFAS>".  "sessionInfo()" appears below.
>>>>> 
>>>>> 
>>>>

Re: [R-SIG-Mac] gfortran: command not found

[Simon Urbanek]

AFACT he didn't say so, there was no response, just double-posting of the same 
question after is was answered.

The installer says:

The resulting compiler will live in /opt/gfortran and can be called with
/opt/gfortran/bin/gfortran

so it's advisable to have /opt/gfortran/bin on the PATH.

(Side note: the arm64 build of R uses the full path, but some people have been 
objecting to that since they wanted to use other compilers for the legacy Intel 
builds, but as I suspected that causes other issues, so I'll change that for 
the next release).

Cheers,
Simon



> On Jul 6, 2023, at 11:45 PM, Peter Dalgaard  wrote:
> 
> AFAICT, Spencer followed the implied instructions and it still didn't work. 
> 
> There may also be a PATH issue when upgrading to 4.3.x, /usr/local -> 
> /opt/R/ Does gfortran 12.2 install to /opt/R/.../bin ?
> 
> -pd  
> 
>> On 6 Jul 2023, at 07:42 , Simon Urbanek  wrote:
>> 
>> Already answered to you and on R-pkg-devel [9 mins after you posted there - 
>> now more than 5h ago...]:
>> 
>> To quote from the page you downloaded R from:
>> 
>> This release uses Xcode 14.2/14.3 and GNU Fortran 12.2. If you wish to 
>> compile R packages which contain Fortran code, you may need to download the 
>> corresponding GNU Fortran compiler from https://mac.R-project.org/tools 
>> <https://mac.r-project.org/tools>. 
>> 
>> 
>> 
>>> On Jul 6, 2023, at 5:16 PM, Spencer Graves  
>>> wrote:
>>> 
>>> Hello, All:
>>> 
>>> 
>>>   "R CMD check KFAS" under macOS 11.7.8 (the latest version that will 
>>> run on my aging Mac) complains "gfortran: command not found".
>>> 
>>> 
>>>   I just upgraded to R 4.3.1 and installed 
>>> "gfortran-12.2-universal.pkg" per 
>>> "https://cran.r-project.org/bin/macosx/tools/";.  I expected this to solve 
>>> the problem.  It didn't.
>>> 
>>> 
>>>   Suggestions?
>>>   Thanks,
>>>   Spencer Graves
>>> 
>>> 
>>> p.s.  This is my fork of KFAS, available at 
>>> "https://github.com/sbgraves237/KFAS";.  "sessionInfo()" appears below.
>>> 
>>> 
>>> ##
>>> 
>>> 
>>> sessionInfo()
>>> R version 4.3.1 (2023-06-16)
>>> Platform: x86_64-apple-darwin20 (64-bit)
>>> Running under: macOS Big Sur 11.7.8
>>> 
>>> Matrix products: default
>>> BLAS: 
>>> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
>>>  
>>> LAPACK: 
>>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;
>>>   LAPACK version 3.11.0
>>> 
>>> locale:
>>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>>> 
>>> time zone: America/Chicago
>>> tzcode source: internal
>>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] compiler_4.3.1  R6_2.5.1magrittr_2.0.3  cli_3.6.1
>>> [5] tools_4.3.1 glue_1.6.2  rstudioapi_0.14 roxygen2_7.2.3
>>> [9] xml2_1.3.4  vctrs_0.6.2 stringi_1.7.12  knitr_1.42
>>> [13] xfun_0.39   stringr_1.5.0   lifecycle_1.0.3 rlang_1.1.1
>>> [17] purrr_1.0.1
>>>> 
>>> 
>>> ___
>>> 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
> 
> -- 
> 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
> 


[[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] gfortran: command not found

[Simon Urbanek]

Already answered to you and on R-pkg-devel [9 mins after you posted there - now 
more than 5h ago...]:

To quote from the page you downloaded R from:

This release uses Xcode 14.2/14.3 and GNU Fortran 12.2. If you wish to compile 
R packages which contain Fortran code, you may need to download the 
corresponding GNU Fortran compiler from https://mac.R-project.org/tools 
. 



> On Jul 6, 2023, at 5:16 PM, Spencer Graves  
> wrote:
> 
> Hello, All:
> 
> 
> "R CMD check KFAS" under macOS 11.7.8 (the latest version that will 
> run on my aging Mac) complains "gfortran: command not found".
> 
> 
> I just upgraded to R 4.3.1 and installed 
> "gfortran-12.2-universal.pkg" per 
> "https://cran.r-project.org/bin/macosx/tools/";.  I expected this to solve the 
> problem.  It didn't.
> 
> 
> Suggestions?
> Thanks,
> Spencer Graves
> 
> 
> p.s.  This is my fork of KFAS, available at 
> "https://github.com/sbgraves237/KFAS";.  "sessionInfo()" appears below.
> 
> 
> ##
> 
> 
> sessionInfo()
> R version 4.3.1 (2023-06-16)
> Platform: x86_64-apple-darwin20 (64-bit)
> Running under: macOS Big Sur 11.7.8
> 
> Matrix products: default
> BLAS: 
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
>  
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;
>   LAPACK version 3.11.0
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> time zone: America/Chicago
> tzcode source: internal
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.3.1  R6_2.5.1magrittr_2.0.3  cli_3.6.1
> [5] tools_4.3.1 glue_1.6.2  rstudioapi_0.14 roxygen2_7.2.3
> [9] xml2_1.3.4  vctrs_0.6.2 stringi_1.7.12  knitr_1.42
> [13] xfun_0.39   stringr_1.5.0   lifecycle_1.0.3 rlang_1.1.1
> [17] purrr_1.0.1
> >
> 
> ___
> 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] macbuilder Site

[Simon Urbanek]

Roy,

thanks (this is the proper place to report it). We had a power failure on one 
of the circuits, and it so happened that the MacBuilder was on it. I have now 
restarted the services so please give it a go and let me know if there are 
issues

Thanks,
Simon


> On Jun 30, 2023, at 8:42 AM, Roy Mendelssohn - NOAA Federal via R-SIG-Mac 
>  wrote:
> 
> I debated whether this is the proper spot or the package mail-list,  but 
> either way mac builder at:
> 
> https://mac.r-project.org/macbuilder/submit.html
> 
> is failing.
> 
> Thanks and thanks for your work on this.
> 
> -Roy
> 
> **
> "The contents of this message do not reflect any position of the U.S. 
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
> 
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected" 
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
> 
> ___
> 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] Serious problem with R on macOS

[Simon Urbanek]

Fernando,

that looks like something is deleting files on your disk - that sounds pretty 
bad. I would probably recommend re-installing a fresh macOS as you may have 
some malware (or over-eager anti-virus or corporate software?) on your machine. 
Given that R works after installation it really seems like some issue on your 
OS and not with R itself.

Cheers,
Simon


> On 9/06/2023, at 4:33 AM, DePaolis, Fernando  wrote:
> 
> …well…here it goes again…it failed just now. This is the message I get when I 
> try to run R from the command line on my mac
> 
>  
> 
> fernandodepaolis@MacBook-Pro-2 ~ % R
> 
>  
> 
> R version 4.3.0 (2023-04-21) -- "Already Tomorrow"
> 
> Copyright (C) 2023 The R Foundation for Statistical Computing
> 
> Platform: x86_64-apple-darwin20 (64-bit)
> 
>  
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> 
> You are welcome to redistribute it under certain conditions.
> 
> Type 'license()' or 'licence()' for distribution details.
> 
>  
> 
>   Natural language support but running in an English locale
> 
>  
> 
> R is a collaborative project with many contributors.
> 
> Type 'contributors()' for more information and
> 
> 'citation()' on how to cite R or R packages in publications.
> 
>  
> 
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 
> 'help.start()' for an HTML browser interface to help.
> 
> Type 'q()' to quit R.
> 
>  
> 
> During startup - Warning message:
> 
> package ‘datasets’ in options("defaultPackages") was not found 
> 
> Error in loadNamespace(name) : object 'pkgInfo' not found
> 
> In addition: Warning message:
> 
> In loadNamespace(name) : package ‘compiler’ has no 'package.rds' in Meta/
> 
> Fatal error: unable to initialize the JIT
> 
>  
> 
>  
> 
>  
> 
> There was no ‘message’ of any sort when trying to run R.app. There was a 
> brief flickering (like quick blinking) but nothing else.
> 
>  
> 
> Thank you!
> 
>  
> 
>  
> 
> Fernando DePaolis, Ph.D.
> Dean of Academic Operations & Integration
> 
> Associate Professor
> 
> Middlebury Institute of International Studies at Monterey
> ------
> 
> [Sent from Outlook for Mac –MacBook Pro]
> 
> My working hours (US Pacific time zone) may not be your working hours. Please 
> do not feel obligated to respond outside your normal work hours, unless 
> otherwise indicated.
> 
>  
> 
> From: DePaolis, Fernando 
> Date: Wednesday, June 7, 2023 at 9:13 PM
> To: Simon Urbanek 
> Cc: r-sig-mac@r-project.org 
> Subject: Re: [R-SIG-Mac] Serious problem with R on macOS
> 
> Hi Simon,
> 
> You're right, I didn't post it...I'll make sure I do next time it 
> happens...it's working fine for now...
> 
>  
> 
> Thank you.
> 
>  
> 
>  
> 
>  
> 
> Fernando DePaolis
> 
> Dean Of Academic Operations & Integration 
> 
> Middlebury Institute of International Studies
> 
>  
> 
> Sent from Outlook for iOS. Apologies for any typos.
> 
>  

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

Re: [R-SIG-Mac] Serious problem with R on macOS

[Simon Urbanek]

Fernando,

I don't think you posted the error you get when running R on the command line - 
can you copy/paste what you get when running R in the Terminal? Similarly, do 
you also get an error when running the R app (in Applications)?

Cheers,
Simon



> On 6/06/2023, at 6:32 AM, DePaolis, Fernando  wrote:
> 
> Uwe Ligges (from CRAN sys admin) recommended that I post this to the list.
> 
>  
> 
> Thank you.
> 
>  
> 
>  
> 
>  
> 
> Fernando DePaolis, Ph.D.
> Dean of Academic Operations & Integration
> 
> Associate Professor
> 
> Middlebury Institute of International Studies at Monterey
> --
> 
> [Sent from Outlook for Mac –MacBook Pro]
> 
> My working hours (US Pacific time zone) may not be your working hours. Please 
> do not feel obligated to respond outside your normal work hours, unless 
> otherwise indicated.
> 
>  
> 
> From: DePaolis, Fernando 
> Date: Monday, June 5, 2023 at 10:19 AM
> To: cran-sysad...@r-project.org 
> Subject: Serious problem with R on macOS
> 
> Hello,
> 
> For a few months now, I’ve been having an odd and rather annoying problem. I 
> use RStudio and it frequently cannot start R, producing the error message 
> attached below. This is clearly not the, as I worked on it the night before 
> or even just a few hours earlier. What is clear is that R is not available on 
> my system, although all the files are still there (in 
> /Library/Frameworks/R.framework). It could be that a critical file becomes 
> corrupted, or the system can’t find it. I have not been able to determine 
> whether that is the case, or which file could be affected. I might have 
> re-installed R dozens of times in the last month. This is something that 
> never happened in the previous more than 15 years of using R.
> 
>  
> 
> I’ve tried everything I can think of, and the problem persists…and haven’t 
> found any satisfactory feedback online either.
> 
> Have you ever heard of a problem like this? Or do you have any suggestions?
> 
>  
> 
> Thank you so much for your support.
> 
>  
> 
>  
> 
> 
>  
> 
>  
> 
>  
> 
> Fernando DePaolis, Ph.D.
> Dean of Academic Operations & Integration
> 
> Associate Professor
> 
> Middlebury Institute of International Studies at Monterey
> --
> 
> [Sent from Outlook for Mac –MacBook Pro]
> 
> My working hours (US Pacific time zone) may not be your working hours. Please 
> do not feel obligated to respond outside your normal work hours, unless 
> otherwise indicated.
> 
> ___
> 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] Identifying computer from R

[Simon Urbanek]

Dennis,

PS1 is an internal shell environment variable (modifying prompt) which has 
nohting to do with R (and nothing to do with the computer name by default) so 
it won't be set in R, only in a shell.
If you want the machine's hostname you'd typically use system("hostname") in R.

Cheers,
Simon


> On 26/05/2023, at 17:15, Dennis Fisher  wrote:
> 
> R 4.2.3
> OS X
> 
> Colleagues 
> 
> Interesting (minor) problem.  I have code that I run automatically on two 
> different computers.  The code runs from Dropbox so there is not separate 
> code for each computer.
> 
> In order to identify which computer is running the code, I was hoping to do 
> something like:
>   Sys.getenv(SOMETHING)
> 
> In a terminal window:
>   echo $PS1
> returns the prompt on that particular computer.
> 
> However, when I attempt to access that from R, I am not successful.  For 
> example:
> 
> In a terminal:
>   echo $PS1
> returns:
>   PET\!>
> 
> In R:
>   Sys.getenv("PS1")
> returns:
>   ""
> 
> In R:
>   system("echo $PS1") 
> returns an empty line.
> 
> A solution to this immediate problem (how to obtain that environment variable 
> in R) or any other clever way to identify a particular computer would be much 
> appreciated.
> 
> Dennis
> 
> 
> Dennis Fisher MD
> P < (The "P Less Than" Company)
> Phone / Fax: 1-866-PLessThan (1-866-753-7784)
> www.PLessThan.com
> 
> ___
> 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] Problems compiling with R CMD build and devtools::build()

[Simon Urbanek]

Jarrett,

Duncan's suggestion was correct, but you are using older R, so I'd recommend 
simply upgrading R to the latest release.

If you want to use old R, you have to install the older Fortran binaries that 
match your R version, but that's not entirely trivial so it's easier to just 
upgrade R instead.

Cheers,
Simon


> On 18/05/2023, at 6:43 AM, Jarrett Phillips  
> wrote:
> 
> Hi Duncan,
> 
> I did exactly that, but still got the error above when I try building in
> both RStudio via devtools::build() and the Terminal via R CMD build.
> 
> To confirm that the right gfortran successfully installed in the correct
> location, I did
> 
> jarrettphillips@Jarretts-MacBook-Pro ~ % /opt/gfortran/bin/gfortran
> 
> *aarch64-apple-darwin20.0-gfortran:* *fatal error: *no input files
> 
> compilation terminated.
> 
> 
> Any other ideas?
> 
> 
> 
> 
> On Wed, May 17, 2023 at 2:13 PM Duncan Murdoch 
> wrote:
> 
>> I think the simplest solution is to remove the gfortran you installed,
>> and then install it back using the installer on
>> 
>>   https://mac.r-project.org/tools/
>> 
>> Duncan Murdoch
>> 
>> On 17/05/2023 1:26 p.m., Jarrett Phillips wrote:
>>> Hi Rodney,
>>> 
>>> When I paste the directories into the Terminal, I get
>>> 
>>> no such file or directory:
>>> 
>>> 
>>> 
>>> suggesting that they don't exist.
>>> 
>>> 
>>> Seems like I need to create them (I'm a newbie)?
>>> 
>>> 
>>> What should be my next steps?
>>> 
>>> 
>>> Thanks!
>>> 
>>> 
>>> Cheers,
>>> 
>>> 
>>> Jarrett
>>> 
>>> 
>>> 
>>> 
>>> On Wed, May 17, 2023 at 1:25 PM Jarrett Phillips <
>> phillipsjarre...@gmail.com>
>>> wrote:
>>> 
 Hi Rodney,
 
 When I paste the directories into the Terminal, I get
 
 no such file or directory:
 
 
 
 suggesting that they don't exist.
 
 
 Seems like I need to create them (I'm a newbie)?
 
 
 What should be my next steps?
 
 
 Thanks!
 
 
 Cheers,
 
 
 Jarrett
 
 
 
 
 
 On Wed, May 17, 2023 at 1:07 PM Sparapani, Rodney 
 wrote:
 
> Hi Jarrett:
> 
> 
> 
> Do the two directories exist that clang is warning you about?
> 
> 
> 
> '/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
> '/opt/R/arm64/gfortran/lib'
> 
> 
> 
> --
> 
> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> 
> Director, Wisconsin Chapter of the American Statistical Association
> 
> Institute for Health and Equity, Division of Biostatistics
> 
> Medical College of Wisconsin, Milwaukee Campus
> 
> 
> 
> *From: *R-SIG-Mac  on behalf of
>> Jarrett
> Phillips 
> *Date: *Wednesday, May 17, 2023 at 11:54 AM
> *To: *r-sig-mac@r-project.org 
> *Subject: *[R-SIG-Mac] Problems compiling with R CMD build and
> devtools::build()
> 
> ATTENTION: This email originated from a sender outside of MCW. Use
> caution when clicking on links or opening attachments.
> 
> 
> Hi All,
> 
> I'm trying to generate a `tar.gz` file on a Mac for R package
>> submission
> to
> CRAN but am having issues.
> 
> I'm using `devtools`, specifically `build()` and `install()`.
> 
> My package relies on compiled code via `Rcpp/RcppArmadillo`.
> 
> build("HACSim_OO")
> ── R CMD build
> ─
> ✔  checking for file ‘/Users/jarrettphillips/Desktop/HAC
> simulation/HACSim_OO/DESCRIPTION’ ...
> ─  preparing ‘HACSim’:
> ✔  checking DESCRIPTION meta-information ...
> ─  cleaning src
> ─  installing the package to process help pages
>  ---
> ─  installing *source* package ‘HACSim’ ...
>** using staged installation
>** libs
>clang++ -arch arm64 -std=gnu++11 -
> I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> 
> 
>> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
> 
> 
>> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
> -I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2
>> -Wall
> -pedantic -fdiagnostics-color=always -c RcppExports.cpp -o
>> RcppExports.o
>clang++ -arch arm64 -std=gnu++11
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
> 
> 
>> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
> 
> 
>> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
> -I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2
>> -Wall
> -pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
>clang++ -arch arm64 -std

Re: [R-SIG-Mac] symbol not found in flat namespace '___kmpc_critical'

[Simon Urbanek]

PLOgKyTDw$
>> <
>> https://urldefense.com/v3/__https:/github.com/rsparapa/bnptools.git__;!!H8mHWRdzp34!4rScCMt0gCJ2ZzuZjzo9CEWXYOBECh814z0fzF0OiVjfFcc609ThiLvNcCYt4sIk7wrZhld1ErXx7PLOgKyTDw$>
>> DIR
>> 
>> $ cd DIR
>> 
>> $ R CMD build nftbart
>> 
>> $ R CMD INSTALL nftbart_1.6.tar.gz
>> 
>> * installing to library
>> �/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library�
>> 
>> * installing *source* package �nftbart� ...
>> 
>> ** using staged installation
>> 
>> checking whether the C++ compiler works... yes
>> 
>> checking for C++ compiler default output file name... a.out
>> 
>> checking for suffix of executables...
>> 
>> checking whether we are cross compiling... no
>> 
>> checking for suffix of object files... o
>> 
>> checking whether we are using the GNU C++ compiler... yes
>> 
>> checking whether clang++ -arch x86_64 -std=gnu++17 accepts -g... yes
>> 
>> checking for clang++ -arch x86_64 -std=gnu++17 option to support OpenMP...
>> -lomp -Xclang -fopenmp
>> 
>> configure: creating ./config.status
>> 
>> config.status: creating src/Makevars
>> 
>> ** libs
>> 
>> using C compiler: �Apple clang version 14.0.3 (clang-1403.0.22.14.1)�
>> 
>> using C++ compiler: �Apple clang version 14.0.3 (clang-1403.0.22.14.1)�
>> 
>> using SDK: ��
>> 
>> clang -arch x86_64 -I"/Library/Frameworks/R.framework/Resources/include"
>> -DNDEBUG -lomp -Xclang -fopenmp
>> -I'/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/Rcpp/include'
>> -I/opt/R/x86_64/include-fPIC  -falign-functions=64 -Wall -g -O2  -c
>> init.c -o init.o
>> 
>> clang++ -arch x86_64 -std=gnu++17
>> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -lomp
>> -Xclang -fopenmp
>> -I'/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/Rcpp/include'
>> -I/opt/R/x86_64/include-fPIC  -falign-functions=64 -Wall -g -O2  -c
>> nftbart.cpp -o nftbart.o
>> 
>> clang++ -arch x86_64 -std=gnu++17 -dynamiclib
>> -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
>> -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib
>> -L/opt/R/x86_64/lib -o nftbart.so init.o nftbart.o
>> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
>> -Wl,CoreFoundation
>> 
>> installing to
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/00LOCK-nftbart/00new/nftbart/libs
>> 
>> ** R
>> 
>> ** data
>> 
>> ** demo
>> 
>> ** byte-compile and prepare package for lazy loading
>> 
>> ** help
>> 
>> *** installing help indices
>> 
>> ** building package indices
>> 
>> ** testing if installed package can be loaded from temporary location
>> 
>> Error: package or namespace load failed for �nftbart� in dyn.load(file,
>> DLLpath = DLLpath, ...):
>> 
>> unable to load shared object
>> '/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/00LOCK-nftbart/00new/nftbart/libs/nftbart.so':
>> 
>> 
>> dlopen(/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/00LOCK-nftbart/00new/nftbart/libs/nftbart.so,
>> 0x0006): symbol not found in flat namespace '___kmpc_critical'
>> 
>> Error: loading failed
>> 
>> Execution halted
>> 
>> ERROR: loading failed
>> 
>> * removing
>> �/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/nftbart�
>> 
>> * restoring previous
>> �/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/nftbart�
>> 
>>> sessionInfo()
>> R version 4.3.0 Patched (2023-04-27 r84338)
>> Platform: x86_64-apple-darwin20 (64-bit)
>> Running under: macOS Ventura 13.2.1
>> 
>> Matrix products: default
>> BLAS:
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
>> LAPACK:
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;
>> LAPACK version 3.11.0
>> 
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> 
>> time zone: America/Chicago
>> tzcode source: internal
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>> 
>> loaded via a namespace (and not attached):
&g

Re: [R-SIG-Mac] binaries for R 4.3 x86_64

[Simon Urbanek]

Ah, ok, thanks, It wasn't clear to me from the description, now also fixed.

Cheers,
Simon

 

> On Apr 25, 2023, at 8:01 PM, Uwe Ligges  
> wrote:
> 
> No, you have fixed the direct link to the binary, but further down the page 
> there is a link "big-sur-x86_64" that actally point to thw wrong directory.
> That is not yet fixed on the master.
> 
> Best,
> Uwe
> 
> 
> 
> On 24.04.2023 23:19, Simon Urbanek wrote:
>> This has been fixed a while time ago so I suspect the culprit are outdated 
>> mirrors. If in doubt, please use
>> https://mac.R-project.org/bin/macosx
>> which is the most up-to-date.
>> Cheers,
>> Simon
>>> On Apr 25, 2023, at 12:51 AM, Uwe Ligges  
>>> wrote:
>>> 
>>> 
>>> 
>>> On 24.04.2023 14:41, Kenneth Knoblauch wrote:
>>>> Hi,
>>>> I am upgrading to R 4.3.  and trying to upgrade the packages.  I had to 
>>>> upgrade to macOS 12 first because I was at 10 and my 2017 Intel Mac Air 
>>>> doesn't seem to be able to run later versions.  I was looking at the Mac 
>>>> binaries at the R for mac OS page and it looks like both links
>>>> big-sur-x86_64 and big-sur-arm64 lead to a page with header:
>>>> Index of /bin/macosx/big-sur-arm64
>>>> Is this just a heading error or is there a misdirect in the link?
>>> 
>>> Misdirect, simply replace arm64 by x86_64 in the link for now. I am sure 
>>> Simon will fix it soon, too.
>>> 
>>> Best,
>>> Uwe Ligges
>>> 
>>>> The formalities:
>>>> sessionInfo()
>>>> R version 4.3.0 (2023-04-21)
>>>> Platform: x86_64-apple-darwin20 (64-bit)
>>>> Running under: macOS Monterey 12.6.5
>>>> Matrix products: default
>>>> BLAS:   
>>>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
>>>> LAPACK: 
>>>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;
>>>>   LAPACK version 3.11.0
>>>> locale:
>>>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>>>> time zone: Europe/Paris
>>>> tzcode source: internal
>>>> attached base packages:
>>>> [1] stats graphics  grDevices utils datasets  methods   base
>>>> loaded via a namespace (and not attached):
>>>> [1] compiler_4.3.0
>>>>> capabilities()
>>>>jpeg pngtiff   tcltk X11aqua
>>>> http/ftp
>>>>TRUETRUETRUETRUETRUETRUE
>>>> TRUE
>>>> sockets  libxmlfifo  cledit   iconv NLS
>>>>Rprof
>>>>TRUE   FALSETRUETRUETRUETRUE
>>>> TRUE
>>>> profmem   cairo ICU long.double libcurl
>>>>TRUETRUETRUETRUETRUE
>>>>  Thank you.
>>>> best,
>>>> Ken
>>>>___
>>>>   Kenneth Knoblauch
>>>>  Inserm U1208
>>>>  Stem-cell and Brain Research Institute
>>>>  18 avenue du Doyen Lépine
>>>>  69500 Bron
>>>>  France
>>>>  tel: +33 (0)4 72 91 34 77
>>>>  fax: +33 (0)4 72 91 34 61
>>>>  portable: +33 (0)6 84 10 64 10
>>>>  https://sbri.fr/public-profile/63/single-member/
>>>> ___
>>>> 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] binaries for R 4.3 x86_64

[Simon Urbanek]

Kenneth,

type="mac.binary" is not appropriate as forces is only for old High-Sierra 
binaries which don't exist for R 4.3.0 anymore as that build is no longer 
supported. You should leave type="both" (default, recommended) or type="binary".

Cheers,
Simon



> On Apr 25, 2023, at 1:12 AM, Kenneth Knoblauch  
> wrote:
> 
> Thank you Uwe for the rapid response,
> 
> I tried: 
> 
> install.packages(p42[3], .libPaths()[1], repos = 
> "https://cran.r-project.org/bin/macosx/big-sur-x86_64/";, type = "mac.binary")
> 
> Warning: unable to access index for repository 
> https://cran.r-project.org/bin/macosx/big-sur-x86_64/bin/macosx/contrib/4.3:
>  cannot open URL 
> 'https://cran.r-project.org/bin/macosx/big-sur-x86_64/bin/macosx/contrib/4.3/PACKAGES'
> 
> and
> 
> install.packages(p42[3], .libPaths()[1], repos = 
> "https://cran.r-project.org/bin/macosx/big-sur-x86_64/contrib/4.3";, type = 
> "mac.binary")
> 
> Warning: unable to access index for repository 
> https://cran.r-project.org/bin/macosx/big-sur-x86_64/contrib/4.3/bin/macosx/contrib/4.3:
>  cannot open URL 
> 'https://cran.r-project.org/bin/macosx/big-sur-x86_64/contrib/4.3/bin/macosx/contrib/4.3/PACKAGES'
> 
> and 
> 
> install.packages(p42, .libPaths()[1], repos = "https://cran.r-project.org";, 
> type = "mac.binary")
> 
> Warning: unable to access index for repository 
> https://cran.r-project.org/bin/macosx/contrib/4.3:
>  cannot open URL 'https://cran.r-project.org/bin/macosx/contrib/4.3/PACKAGES'
> 
> where p42 was a character vector of the package names that I had installed 
> under 4.2
> 
> Any guidance would be greatly appreciated.
> 
> Thank you, in advance.
> 
> best,
> 
> Ken
> 
>  ___
>  Kenneth Knoblauch
> Inserm U1208
> Stem-cell and Brain Research Institute
> 18 avenue du Doyen Lépine
> 69500 Bron
> France
> tel: +33 (0)4 72 91 34 77
> fax: +33 (0)4 72 91 34 61
> portable: +33 (0)6 84 10 64 10
> https://sbri.fr/public-profile/63/single-member/
> 
> 
> 
> 
> 
> De : Uwe Ligges 
> Envoyé : lundi 24 avril 2023 14:51
> À : Kenneth Knoblauch; r-sig-mac@r-project.org
> Objet : Re: [R-SIG-Mac] binaries for R 4.3 x86_64
> 
> 
> 
> On 24.04.2023 14:41, Kenneth Knoblauch wrote:
>> Hi,
>> 
>> I am upgrading to R 4.3.  and trying to upgrade the packages.  I had to 
>> upgrade to macOS 12 first because I was at 10 and my 2017 Intel Mac Air 
>> doesn't seem to be able to run later versions.  I was looking at the Mac 
>> binaries at the R for mac OS page and  it looks like both links
>> 
>> big-sur-x86_64 and big-sur-arm64 lead to a page with header:
>> 
>> Index of /bin/macosx/big-sur-arm64
>> 
>> Is this just a heading error or is there a misdirect in the link?
> 
> Misdirect, simply replace arm64 by x86_64 in the link for now. I am sure 
> Simon will fix it soon, too.
> 
> Best,
> Uwe Ligges
> 
>> 
>> The formalities:
>> 
>> sessionInfo()
>> R version 4.3.0 (2023-04-21)
>> Platform: x86_64-apple-darwin20 (64-bit)
>> Running under: macOS Monterey 12.6.5
>> 
>> Matrix products: default
>> BLAS:   
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;
>>   LAPACK version 3.11.0
>> 
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> 
>> time zone: Europe/Paris
>> tzcode source: internal
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_4.3.0
>>> capabilities()
>>  jpeg pngtiff   tcltk X11aqua
>> http/ftp
>>  TRUETRUETRUETRUETRUETRUE
>> TRUE
>>   sockets  libxmlfifo  cledit   iconv NLS
>>Rprof
>>  TRUE   FALSETRUETRUETRUETRUE
>> TRUE
>>   profmem   cairo ICU long.double libcurl
>>  TRUETRUETRUETRUETRUE
>> 
>>Thank you.
>> 
>> best,
>> 
>> Ken
>> 
>>
>> ___
>> Kenneth Knoblauch
>>Inserm U1208
>>Stem-cell and Brain Research Institute
>>18 avenue du Doyen Lépine
>>69500 Bron
>>France
>>tel: +33 (0)4 72 91 34 77
>>fax: +33 (0)4 72 91 34 61
>>portable: +33 (0)6 84 10 64 10
>>https://sbri.fr/public-profile/63/single-member/
>>   
>> ___
>> 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] binaries for R 4.3 x86_64

[Simon Urbanek]

This has been fixed a while time ago so I suspect the culprit are outdated 
mirrors. If in doubt, please use

https://mac.R-project.org/bin/macosx

which is the most up-to-date.

Cheers,
Simon



> On Apr 25, 2023, at 12:51 AM, Uwe Ligges  
> wrote:
> 
> 
> 
> On 24.04.2023 14:41, Kenneth Knoblauch wrote:
>> Hi,
>> I am upgrading to R 4.3.  and trying to upgrade the packages.  I had to 
>> upgrade to macOS 12 first because I was at 10 and my 2017 Intel Mac Air 
>> doesn't seem to be able to run later versions.  I was looking at the Mac 
>> binaries at the R for mac OS page and it looks like both links
>> big-sur-x86_64 and big-sur-arm64 lead to a page with header:
>> Index of /bin/macosx/big-sur-arm64
>> Is this just a heading error or is there a misdirect in the link?
> 
> Misdirect, simply replace arm64 by x86_64 in the link for now. I am sure 
> Simon will fix it soon, too.
> 
> Best,
> Uwe Ligges
> 
>> The formalities:
>> sessionInfo()
>> R version 4.3.0 (2023-04-21)
>> Platform: x86_64-apple-darwin20 (64-bit)
>> Running under: macOS Monterey 12.6.5
>> Matrix products: default
>> BLAS:   
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;
>>   LAPACK version 3.11.0
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> time zone: Europe/Paris
>> tzcode source: internal
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>> loaded via a namespace (and not attached):
>> [1] compiler_4.3.0
>>> capabilities()
>>jpeg pngtiff   tcltk X11aqua
>> http/ftp
>>TRUETRUETRUETRUETRUETRUE  
>>   TRUE
>> sockets  libxmlfifo  cledit   iconv NLS  
>>  Rprof
>>TRUE   FALSETRUETRUETRUETRUE  
>>   TRUE
>> profmem   cairo ICU long.double libcurl
>>TRUETRUETRUETRUETRUE
>>  Thank you.
>> best,
>> Ken
>>___
>>   Kenneth Knoblauch
>>  Inserm U1208
>>  Stem-cell and Brain Research Institute
>>  18 avenue du Doyen Lépine
>>  69500 Bron
>>  France
>>  tel: +33 (0)4 72 91 34 77
>>  fax: +33 (0)4 72 91 34 61
>>  portable: +33 (0)6 84 10 64 10
>>  https://sbri.fr/public-profile/63/single-member/
>> ___
>> 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] 'Default' macos (x86) download URL now gone?

[Simon Urbanek]

Dirk,

thanks - the problem is that there is not a single installer package (for 
several years now), so that URL is ambiguous. Whether the missing link is a 
good or bad depends on how it is used. I would argue that any link to that URL 
is inherently bad, because there is no way of knowing that the link works for a 
particular system - that's why I have originally removed it with the R 4.3.0 
release. I have restored it now, making it point to the R 4.3.0 arm64 release 
since that is arguably the closest to a single "latest R". R releases have not 
been stored in /bin/macosx since 2015, so anyone using a link there is asking 
for trouble.

For any CI I would strongly recommend using the "last-success" links: 
https://mac.r-project.org/big-sur/last-success/ in particular the .xz versions 
are they are specifically designed to be used by CI (small download, fast and 
localized install).

Cheers,
Simon


> On 24/04/2023, at 3:25 AM, Dirk Eddelbuettel  wrote:
> 
> 
> The URL ${CRAN}/bin/macosx/R-latest.pkg is in fairlt widespread use. A quick
> Google query [1] reveals about 1.1k hits. And it happens to be used too in a
> CI job a colleague noticed failing yesterday.
> 
> The bin/macosx/ page now prominently displays both leading flavours
>  R-4.3.0-arm64.pkg
>  R-4.3.0-x86_64.pkg
> which makes sense give the architecture choices. We can of course update the
> CI script, and likely will.
> 
> But given that this was apparently a somewhat widely-used URL to fetch R on
> macOS, may I suggest that the convenience link be reestablished as a courtesy?
> 
> Best,  Dirk
> 
> https://github.com/search?q=macosx%2FR-latest.pkg&type=code
> 
> -- 
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 

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

Re: [R-SIG-Mac] Problem installing RUcausal library on MAC

[Simon Urbanek]

Varin,

you're missing the Fortran compiler which the package requires. To make the 
life a bit easier on you, upgrade to R 4.3.0 and then install GNU Fortran from 
https://mac.r-project.org/tools/

If you don't want to upgrade R then you'll need the Fortran from here: 
https://github.com/R-macos/gcc-darwin-arm64/releases/tag/R-4.2.0-release

Cheers,
Simon



> On Apr 24, 2023, at 9:05 AM, varin sacha via R-SIG-Mac 
>  wrote:
> 
> R-experts,
> 
> What is going wrong?
> 
> At the end of this page there is the installation command :
> https://gitlab.science.ru.nl/gbucur/RUcausal/-/blob/master/README.Rmd 
> 
> Working with a MAC, I have tried to install the RUcausal library (copy and 
> paste the installation command).
> 
> It is written that the package has been built on Linux using the GNU Compiler 
> Collection. To install the package, open an R instance and run:
> install.packages('devtools') # required package
> devtools::install_git('https://gitlab.science.ru.nl/gbucur/RUcausal')
> 
> I get this error message :
> 
>  ERROR: package installation failed
> Error: Failed to install 'RUcausal' from Git:
>  ! System command 'R' failed
> 0d0bz2p4xg64gn/T/RtmpMs1teQ/Rinst6453ee77bb8/RUcausal’
> 
> 
> 
> install.packages('devtools') # required package
> --- Please select a CRAN mirror for use in this session ---
> trying URL 
> 'https://stat.ethz.ch/CRAN/bin/macosx/big-sur-arm64/contrib/4.2/devtools_2.4.5.tgz'
> Content type 'application/x-gzip' length 421790 bytes (411 KB)
> ==
> downloaded 411 KB
> 
> 
> The downloaded binary packages are in
>
> /var/folders/t_/myv0vvms11g40d0bz2p4xg64gn/T//Rtmp7SUtUd/downloaded_packages
>> devtools::install_git('https://gitlab.science.ru.nl/gbucur/RUcausal')
> Downloading git repo https://gitlab.science.ru.nl/gbucur/RUcausal
> '/usr/bin/git' clone --depth 1 --no-hardlinks 
> https://gitlab.science.ru.nl/gbucur/RUcausal 
> /var/folders/t_/myv0vvms11g40d0bz2p4xg64gn/T//Rtmp7SUtUd/file61a2a8e336a
> ── R CMD build 
> ──
> ─ installing the package to process help pages
>  ---ges
> ─ installing *source* package ‘RUcausal’ ...
>  ** using staged installation
>  ** libs
>  clang++ -arch arm64 -std=gnu++14 
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG 
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
>  
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
>  -I/opt/R/arm64/include -fPIC -falign-functions=64 -Wall -g -O2 -Wall 
> -pedantic -c RcppExports.cpp -o RcppExports.o
>  clang++ -arch arm64 -std=gnu++14 
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG 
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
>  
> -I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
>  -I/opt/R/arm64/include -fPIC -falign-functions=64 -Wall -g -O2 -Wall 
> -pedantic -c compute_DAG_probabilities_BGe_fast.cpp -o 
> compute_DAG_probabilities_BGe_fast.o
>  clang++ -arch arm64 -std=gnu++14 -dynamiclib 
> -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module 
> -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib 
> -L/opt/R/arm64/lib -o RUcausal.so RcppExports.o 
> compute_DAG_probabilities_BGe_fast.o 
> -L/Library/Frameworks/R.framework/Resources/lib -lRlapack 
> -L/Library/Frameworks/R.framework/Resources/lib -lRblas 
> -L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1 
> -L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath 
> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework 
> -Wl,CoreFoundation
>  ld: warning: directory not found for option 
> '-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
>  ld: warning: directory not found for option '-L/opt/R/arm64/gfortran/lib'
>  ld: library not found for -lgfortran
>  clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>  make: *** [RUcausal.so] Error 1
>  ERROR: compilation failed for package ‘RUcausal’
> ─ removing 
> ‘/private/var/folders/t_/myv0vvms11g40d0bz2p4xg64gn/T/RtmpMs1teQ/Rinst6453ee77bb8/RUcausal’
>  ---
>  ERROR: package installation failed
> Error: Failed to install 'RUcausal' from Git:
>  ! System command 'R' failed
> 0d0bz2p4xg64gn/T/RtmpMs1teQ/Rinst6453ee77bb8/RUcausal’
> 
> 
> Envoyé de mon iPhone
> ___
> 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 241, Issue 5

[Simon Urbanek]

Mikael,

the OpenMP binaries are entirely unrelated to the R release. Also you cannot 
put libiomp anywhere else without modification, because it contains the path 
and is signed. Given that you need additional flags for OpenMP anyway, this is 
not really an issue, since you have to know what you are doing in the first 
place so you need several flags to make this work. If you are interested in 
OpenMP for your package then I'd suggest trying a static iomp build.

Cheers,
Simon


> On Apr 19, 2023, at 1:43 AM, Mikael Jagan  wrote:
> 
> The OpenMP binaries provided here
> 
>https://mac.r-project.org/openmp/
> 
> still have the usr/local/ prefix.  Is that intentional?  If that prefix were
> simply deleted, then users could unpack with (for example)
> 
>tar -xvf openmp-14.0.6-darwin20-Release.tar.gz -C /opt/R/$(uname -m)
> 
> And then not need
> 
>CPPFLAGS += -I/usr/local/include
>LDFLAGS += -L/usr/local/lib
> 
> just to include the header or link the shared library.
> 
> Mikael
> 
>> Date: Tue, 18 Apr 2023 15:18:03 +1200
>> From: Simon Urbanek 
>> To: R list 
>> Subject: [R-SIG-Mac] Please test R 4.3.0 RC, more information below
>> Message-ID: <19b7bfe5-2bb9-491d-99a2-bf572a5b4...@r-project.org>
>> Content-Type: text/plain; charset="us-ascii"
>> Dear Mac users,
>> the next major R release R 4.3.0 is coming very soon so I would like to ask 
>> you to, please, test the pre-releases from
>> https://mac.R-project.org
>> such that any possible new issues are detected *before* the release. The 
>> upcoming release will be for macOS 11 and higher only to leverage new 
>> compilers (important for modern C++ support) and libraries. As usual, there 
>> are two releases: one for the older Intel Macs (x86_64) and one for the new 
>> M1/M2 Macs (arm64) - please install the matching version.
>> R users can stop reading here, just test, please!
>> Package developers, please check the CRAN result pages for your package to 
>> make sure it passes checks. Also please note that we are now using a 
>> universal GNU Fortran compiler that works both on Intel and arm64 Macs - you 
>> can download an Apple Installer from
>> https://mac.r-project.org/tools/
>> There are two major changes for the Intel build relevant to advanced users:
>> a) .Platfrom$pkgType is "mac.binary.big-sur-x86_64" since we are targeting a 
>> new macOS version (this is to match arm64 which uses 
>> "mac.binary.big-sur-arm64"). It means that binaries for contributed packages 
>> in repositories live in bin/macosx/big-sur-x86_64/contrib/4.3.
>> b) the Intel build now matches the arm64 build such that dependent libraries 
>> are expected in /opt/R/x86_64 (to match arm64's /opt/R/arm64) to avoid 
>> conflicts with other tools. You can still add -I/usr/local/include to 
>> CPPFLAGS or -L/usr/local/lib to LDFLAGS if you want to use 3rd party 
>> libraries from /usr/local (refer to R and package documentation for details).
>> Finally, R will no longer sets the macos-version-min flag by default, which 
>> means R will build for the currently installed macOS version. This allows 
>> users to build packages that use the latest SDK and capabilities of the 
>> latest macOS without any changes. However, if you are distributing package 
>> binaries for use others, we strongly recommend that you set
>> export MACOSX_DEPLOYMENT_TARGET=11.0
>> when compiling binaries which will make sure that they will run on macOS 11 
>> and higher, otherwise your binary may not be compatible.
>> CRAN also uses the macOS11 SDK via
>> export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
>> However, depending on your Xcode version you may not have such SDK, so it is 
>> optional.
>> Cheers,
>> Simon
> 

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

[R-SIG-Mac] Please test R 4.3.0 RC, more information below

[Simon Urbanek]

Dear Mac users,

the next major R release R 4.3.0 is coming very soon so I would like to ask you 
to, please, test the pre-releases from

https://mac.R-project.org

such that any possible new issues are detected *before* the release. The 
upcoming release will be for macOS 11 and higher only to leverage new compilers 
(important for modern C++ support) and libraries. As usual, there are two 
releases: one for the older Intel Macs (x86_64) and one for the new M1/M2 Macs 
(arm64) - please install the matching version.

R users can stop reading here, just test, please!

Package developers, please check the CRAN result pages for your package to make 
sure it passes checks. Also please note that we are now using a universal GNU 
Fortran compiler that works both on Intel and arm64 Macs - you can download an 
Apple Installer from
https://mac.r-project.org/tools/

There are two major changes for the Intel build relevant to advanced users:

a) .Platfrom$pkgType is "mac.binary.big-sur-x86_64" since we are targeting a 
new macOS version (this is to match arm64 which uses 
"mac.binary.big-sur-arm64"). It means that binaries for contributed packages in 
repositories live in bin/macosx/big-sur-x86_64/contrib/4.3.

b) the Intel build now matches the arm64 build such that dependent libraries 
are expected in /opt/R/x86_64 (to match arm64's /opt/R/arm64) to avoid 
conflicts with other tools. You can still add -I/usr/local/include to CPPFLAGS 
or -L/usr/local/lib to LDFLAGS if you want to use 3rd party libraries from 
/usr/local (refer to R and package documentation for details).

Finally, R will no longer sets the macos-version-min flag by default, which 
means R will build for the currently installed macOS version. This allows users 
to build packages that use the latest SDK and capabilities of the latest macOS 
without any changes. However, if you are distributing package binaries for use 
others, we strongly recommend that you set

export MACOSX_DEPLOYMENT_TARGET=11.0

when compiling binaries which will make sure that they will run on macOS 11 and 
higher, otherwise your binary may not be compatible.

CRAN also uses the macOS11 SDK via

export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk

However, depending on your Xcode version you may not have such SDK, so it is 
optional.

Cheers,
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] typo in mac.r-project.org index?

[Simon Urbanek]

Mikael,

the SDK version (=system libraries) is independent of the Xcode version 
(=toolchain version). We are using macOS 11 SDK, because we want the binaries 
to run on macOS 11. R packages typically don't use run-time weak symbol guards, 
so they would likely crash when compiled against higher SDK version.

Cheers,
Simon


> On Apr 15, 2023, at 7:48 AM, Mikael Jagan  wrote:
> 
> Hi Simon,
> 
> Maybe I'm off the mark, but:
> 
> > R 4.3.0 CRAN builds are using Xcode 14.2, macOS 11.3 SDK and targetting 
> > macOS 11 (Big Sur)
> 
> AFAICT, Xcode 14.x includes an SDK for macOS 12.3 but not one for macOS 11.3.
> 
> https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes
> 
> Mikael
> 
> ___
> 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] Symbol not found: _timespec_get

[Simon Urbanek]

Jennifer,

that build in only for macOS 11 (Big Sur) and higher, older versions are no 
longer supported (neither by Apple nor by us). I'll update the installer to 
disallow installation on older macOS version to avoid confusion.

Thanks,
Simon


> On Apr 5, 2023, at 6:04 AM, Jennifer Wokaty  
> wrote:
> 
> Sorry, thank you for kindly reminding me!
> 
> R aborts so I can't provide sessionInfo(), but that's likely the problem as 
> we're running macOS 10.14.6 Mojave x86_64-apple-darwin18.7.0.
> 
> Jennifer Wokaty (they/them)
> 
> Waldron Lab at CUNY SPH
> Bioconductor Core Team
> 
> From: Tomas Kalibera 
> Sent: Tuesday, April 4, 2023 1:45 PM
> To: Jennifer Wokaty ; R list 
> 
> Subject: Re: [R-SIG-Mac] Symbol not found: _timespec_get
> 
> ***ATTENTION: This email came from an external source. Do not open 
> attachments or click on links from unknown senders or unexpected emails.***
> 
> 
> On 4/4/23 18:26, Jennifer Wokaty wrote:
>> Hi,
>> 
>> I tried installing the x86_64 alpha available today at 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mac.r-2Dproject.org_big-2Dsur-2Dx86-5F64_R-2D4.3-2Dbranch_R-2D4.3-2Dbranch-2Dx86-5F64.pkg&d=DwICaQ&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA&m=DmuhCksnwNg84omqA0JKgHs0D19_LtdOtLYF5PHjwhrrAGJd-oipKLVnv0P5zaCs&s=LxWPN-ZaCdXshO1N0P-FIM2vDwLCBud23G9_f9cQwQU&e=
>>  ; however, I'm getting the following error:
>> 
>> $ sudo installer -pkg R-4.3-branch-x86_64.pkg -target /
>> installer: Package name is R 4.3.0 for macOS (X86_64)
>> installer: Upgrading at base path /
>> installer: The upgrade was successful.
>> $ R
>> dyld: lazy symbol binding failed: Symbol not found: _timespec_get
>>   Referenced from: 
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib 
>> (which was built for Mac OS X 11.0)
>>   Expected in: /usr/lib/libSystem.B.dylib
>> 
>> dyld: Symbol not found: _timespec_get
>>   Referenced from: 
>> /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib 
>> (which was built for Mac OS X 11.0)
>>   Expected in: /usr/lib/libSystem.B.dylib
>> 
>> Abort trap: 6
>> 
>> Is this a problem with the .pkg file?
> 
> Hi Jen,
> 
> could you please report your macOS version, e.g. via sessionInfo()? Is
> it at least 11?
> 
> Tomas
> 
>> 
>> Jennifer Wokaty (they/them)
>> 
>> Waldron Lab at CUNY SPH
>> Bioconductor Core Team
>> 
>>  [[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&d=DwICaQ&c=mRWFL96tuqj9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=FKSqKXkUOES-D4VQb2jSn9QK7Vz5lE18rLcyn73CPhA&m=DmuhCksnwNg84omqA0JKgHs0D19_LtdOtLYF5PHjwhrrAGJd-oipKLVnv0P5zaCs&s=nz6Y3C8Ar-2cbE9KbTe2YIlyYm7i3AdQqFFmd3VhVSo&e=
> 
>   [[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] Install error for gmm package

[Simon Urbanek]

Hasan,

packages shouldn't be using gomp as it is not supported - it seems that gmm is 
hard-coding -lgomp even if it is not enabled by R. Although this is a bug in 
gmm (which the authors should fix), you can try to work around it by installing 
the GNU Fortran compiler as follows:

open the Terminal (under Application->Utilities) and type

cd /tmp
curl -O 
https://mac.r-project.org/tools/gfortran-12.0.1-20220312-is-darwin20-arm64.tar.xz
sudo tar fxz gfortran-12.0.1-20220312-is-darwin20-arm64.tar.xz -C /

Cheers,
Simon



> On Apr 2, 2023, at 6:15 PM, HASAN BULUT  wrote:
> 
> Hi everyone,
> 
> I have Macbook air M2 and I need the "gmm" package. But I cannot install 
> conventionally this package.
> When I install and call this package, I see below error message:
> 
> Loading required package: sandwich
> Error: package or namespace load failed for ‘gmm’ in dyn.load(file, DLLpath = 
> DLLpath, ...):
>  unable to load shared object 
> '/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/gmm/libs/gmm.so':
>   
> dlopen(/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/gmm/libs/gmm.so,
>  0x0006): Library not loaded: /opt/R/arm64/gfortran/lib/libgomp.1.dylib
>   Referenced from: <47242657-5A5D-3982-936B-398527D642B4> 
> /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/gmm/libs/gmm.so
>   Reason: tried: '/opt/R/arm64/gfortran/lib/libgomp.1.dylib' (no such file), 
> '/System/Volumes/Preboot/Cryptexes/OS/opt/R/arm64/gfortran/lib/libgomp.1.dylib'
>  (no such file), '/opt/R/arm64/gfortran/lib/libgomp.1.dylib' (no such file), 
> '/usr/local/lib/libgomp.1.dylib' (no such file), '/usr/lib/libgomp.1.dylib' 
> (no such file, not in dyld cache)
>  
> Could you help me?
> 
> Best wishes.
> 
> Hasan Bulut
> 
> 
> 
> 
> ___
> 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 installation error

[Simon Urbanek]

Nicolas,

we can't tell unless you post the error log and you didn't even tell us your 
macOS version, but in recent versions security settings prevent the 
installation from the Downloads folder, so make sure you move it away from 
there to some safe location (home, Desktop or /tmp). Otherwise, supply details 
and post the log.

Cheers,
Simon
 

> 
> On Mar 27, 2023, at 12:18 PM, Nicolas Conrad via R-SIG-Mac 
>  wrote:
> 
> Hello,
> 
> I am trying to install R on my Mac (Intel chip) and I keep getting this
> error message:
> 
> The install failed. (The Installer encountered an error that caused the
> installation to fail. Contact the software manufacturer for assistance. An
> unexpected error occurred while moving files to the final destination.)
> 
> 
> I was wondering if you knew anything I could try to fix this error.
> 
> 
> Thanks,
> 
> Nicolas
> 
>   [[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] Help on reducing size of shared libraries on MacOS on CRAN

[Simon Urbanek]

Gilberto,

Please note that size checks are not really relevant for binary packages - it 
is normal for binaries to be large as they may include static libraries (e.g., 
rgdal has 273Mb). Also note that 4.8Mb is rather small for a library since it 
also includes debugging symbols (CRAN packages are built with --dsym to make 
debugging easier) - so is there a particular reason you are concerned about the 
size? You can always remove the debugging symbols (libs/*.dsym) on your machine 
if you have issues with size.

Cheers,
Simon


> On 19/03/2023, at 07:02, Gilberto Camara  
> wrote:
> 
> Dear R-SIG-MAC members
> 
> We are the developers of R package sits and would like to ask for your help 
> in solving a problem with library size on R macOS binaries. 
> 
> Before submission to CRAN, version 1.3.0 of sits 
> (https://cran.r-project.org/web/packages/sits/index.html) has been tested in 
> various environments, including Ubuntu, Fedora, CRAN winbuilder (all 
> flavors). We have tested sits-1.3.0 on r-release-mac-x86_64 and 
> r-release-macos-arm64 with the following configurations:
> 
> - r-release-macos-x86_64: R 4.2.2, MacMini 3.2GHz, 6 cores, 32 MB RAM, macOS 
> Ventura 3.2.1, Apple clang version 14.0.3 (clang-1403.0.22.14.1).
> 
> - r-release-macos-arm64: R 4.2.2, MacBookAir, chip ARM M1, 8 cores, 16 MB 
> RAM, macOS Monterrey 12.6,  Apple clang version 14.0.0 (clang-1400.0.29.201). 
> 
> In our configuration of r-release-macos-x86_64, the installed size is 3.8 MB, 
> and the libs directory size is 436 KB. On r-release-macos-arm64, the 
> installed size is 5.4 MB and the libs directory size is 1.6 MB. 
> 
> The current CRAN check on sits version 1.3.0 reports a NOTE on 
> r-release-macos-arm64 and r-oldrel-macos-arm64, with an installation size of 
> 7.3Mb with the libs directory size reported as 4.8Mb. CRAN is using Apple 
> clang version 13.0.0 ((clang-1300.0.29.30) on r-release-macos-arm64 and Apple 
> clang version 12.0.0 (clang-1200.0.32.29) on r-oldrel-macos-arm64. 
> 
> There is a 3.2 MB difference in size between what CRAN reports and what we 
> obtain in our tests for r-release-macos-arm64. We would appreciate your 
> guidance on how to address this problem and, if possible, point to a reliable 
> way to reduce package size in macOS. 
> 
> Note that our package links to RCpp and RCppArmadillo.
> 
> Our current Makevars configuration is given below
> ==
> # suggestion by Dirk Eddelbuettel
> SHLIB_CXXLDFLAGS = -Wlto,-S -shared
> SHLIB_CXX11LDFLAGS = -Wlto,-S -shared
> SHLIB_CXX14LDFLAGS = -Wlto,-S -shared
> SHLIB_FCLDFLAGS = -Wlto,-S -shared
> SHLIB_LDFLAGS = -Wlto,-S -shared
> 
> ## suggestion by Dirk Eddelbuettel
> PKG_CXXFLAGS = $(SHLIB_OPENMP_CXXFLAGS)
> PKG_LIBS = $(SHLIB_OPENMP_CXXFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
> 
> strippedLib: $(SHLIB)
>   if test -e "/usr/bin/strip" & test -e "/bin/uname" & [[ `uname` 
> == "Linux" ]] ; then /usr/bin/strip --strip-debug $(SHLIB); fi
> 
> clean:
>   rm -f $(OBJECTS)
> 
> .phony: strippedLib clean
> ===
> 
> Any help would be much appreciated. 
> 
> Best regards
> Gilberto
> 
> Prof Dr Gilberto Camara
> Senior Researcher
> National Institute for Space Research (INPE), Brazil
> https://gilbertocamara.org/
> =
> 
> ___
> 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 , RCPP unsing MACOS ventura

[Simon Urbanek]

Well, what I saw in the searches what that it was a problem with Homebrew tools 
breaking on that flag. Again, it's all speculation, because no one posted the 
actual issue ... so it's anyone's guess what this is all about until someone 
actually posts the details I asked for - I don't see that problem myself, but I 
don't use Homebrew (at least not on the default PATH).

Cheers,
Simon


> On 15/03/2023, at 9:45 AM, Michael Hall  wrote:
> 
> 
> 
>> On Mar 14, 2023, at 3:32 PM, Simon Urbanek  
>> wrote:
>> 
>> If that is the case, can you actually post what the issue is? The original 
>> post had no details and did not follow up when asked for details. When 
>> googling the issue seems to arise in Homebrew, not the Apple tools so as I 
>> noted removing Homebrew should work.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> On 15/03/2023, at 12:52 AM, Michael Hall  wrote:
>>> 
>>> 
>>> 
>>>> On Mar 14, 2023, at 6:00 AM, r-sig-mac-requ...@r-project.org wrote:
>>>> 
>>>> [R-SIG-Mac] R , RCPP unsing MACOS ventura
>>> 
>>> Google shows others have had the issue.
>>> 
>>> Suggestions include...
>>> 
>>> Uninstall and reinstall command line tools.
>>> 
>>> ——
>>> 
>>> ...following the wisdom of the "homebrew doctor" solves it, i.e. remove and 
>>> reinstall:
>>> 
>>> sudo rm -rf /Library/Developer/CommandLineTools
>>> sudo xcode-select —install
>>> 
>>> ———
>>> 
>>> 
>>> Rebuild with export SYSTEM_VERSION_COMPAT=1 
>>> 
>>> Searched with…
>>> : error: unknown value ‘13.2.0’ of ‘-mmacosx-version-min’
> 
> The general suggestion seemed to be for some reason to remove and reinstall 
> the command line tools. The example I posted was one where it was the 
> home-brew doctor that made that suggestion. Not that homebrew itself was the 
> problem.
> 
> The 
>>> : error: unknown value ‘13.2.0’ of ‘-mmacosx-version-min’
> 
> Seemed to be what the underlying issue was? and was what I searched on
> 

___
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 , RCPP unsing MACOS ventura

[Simon Urbanek]

Federico,

given that Homebrew is likely the cause for the mess, advising to install a 
custom installation seems like a very bad idea. It is likely very dependent on 
the versions of the tools from Homebrew which is what breaks. Therefore I would 
strongly advise against it (unless you know what you are doing, but then if you 
do - you know how to fix it).

So to the list readers - please do NOT follow the advice for custom flags 
unless you know what it does and how to maintain it. If you use custom tools 
(which is fine for experts), you are likely to have problems down the road 
since such installations are not maintained by Apple and will break and will 
need fixing.

Cheers,
Simon
  



> On 15/03/2023, at 7:26 AM, Calboli Federico (LUKE)  
> wrote:
> 
> First off apologies for the horrible quoting from me, I have been forced to 
> move from Mail.app to Outlook and nothing works as it should.
> 
> I understand the XCode tool are needed to install homebrew, but after that 
> they are not the focus � my R makevars calls the gcc I installed with 
> homebrew, not the one supplied by XCode (which does not have fortran, hence 
> my use of the Homebrew gcc).
> 
> 
> Federico Calboli
> Tutkija
> Genomiikka ja jalostus
> Luonnonvarakeskus
> 
> 
> 
>> 
>> I actually do not use Rcpp, I was just curious to know whether it works on 
>> my machine or not.  Apparently it does.
>> 
> 
> 
> Me either. Fwiw.
> 
> xcode-select --version
> xcode-select version 2396.
> 
> Also Ventura 13.2.1
> 
>> library(Rcpp)
>> evalCpp( "1+1")
> [1] 2
>::sprintf(buff, "%02x", from);
>  ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:188:1:
>  note: 'sprintf' has been explicitly marked deprecated here
> __deprecated_msg("This function is provided for compatibility reasons only.  
> Due to security concerns inherent in the design of sprintf(3), it is highly 
> recommended that you use snprintf(3) instead.")
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48:
>  note: expanded from macro '__deprecated_msg'
>#define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
>  ^
> 1 warning generated.
>> 
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-sig-mac&data=05%7C01%7Cfederico.calboli%40luke.fi%7C8e5586946cd54b94cd7808db24ade8a1%7C7c14dfa4c0fc47259f0476a443deb095%7C0%7C0%7C638144101597319575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5l9Xe5xlggU4O3UJwRpIt62sbdZJMmsRoRnkufM2MzY%3D&reserved=0
> 
>   [[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] R , RCPP unsing MACOS ventura

[Simon Urbanek]

If that is the case, can you actually post what the issue is? The original post 
had no details and did not follow up when asked for details. When googling the 
issue seems to arise in Homebrew, not the Apple tools so as I noted removing 
Homebrew should work.

Cheers,
Simon



> On 15/03/2023, at 12:52 AM, Michael Hall  wrote:
> 
> 
> 
>> On Mar 14, 2023, at 6:00 AM, r-sig-mac-requ...@r-project.org wrote:
>> 
>> [R-SIG-Mac] R , RCPP unsing MACOS ventura
> 
> Google shows others have had the issue.
> 
> Suggestions include...
> 
> Uninstall and reinstall command line tools.
> 
> ——
> 
> ...following the wisdom of the "homebrew doctor" solves it, i.e. remove and 
> reinstall:
> 
> sudo rm -rf /Library/Developer/CommandLineTools
> sudo xcode-select —install
> 
> ———
> 
> 
> Rebuild with export SYSTEM_VERSION_COMPAT=1 
> 
> Searched with…
> : error: unknown value ‘13.2.0’ of ‘-mmacosx-version-min’
> 
> 
> 
> 
>   [[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] R , RCPP unsing MACOS ventura

[Simon Urbanek]

Andrea,

Make sure you don't have any outdated tools or flags overrides (e.g. in ~/.R). 
If it doubt clean /usr/local and uninstall Homebrew. The error suggests your 
are using compilers that don't support your system.

If you cleaned out those and still needs help, please post the full output of 
the installation and provide full sessionInfo() output.

Cheers,
Simon


> On Mar 14, 2023, at 7:26 AM, Andrea Apolloni  wrote:
> 
> Dear all I had the bad idea ,
> 3 weeks ago to install the new Mac OS Ventura 13.2.0 on my laptop
> I've instlalled the latest version of XCode (14.2) and CommandLine Tools
> 
> Since then I can not use RCPP, Nimble and Rstan on my laptop
> typical errror
> Error: Failed to create the shared library. Run 'printErrors()' to see the
> compilation errors.
> 
> and using printErrors()
> 
> : error: unknown value ‘13.2.0’ of ‘-mmacosx-version-min’
> make: *** [dynamicRegistrations_03_13_19_21_32.o] Error 1
> 
> version of R 4.2.2
> Thanks in advance for all your help
> 
>   [[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] Can R on a Mac use the GPU

[Simon Urbanek]

Bill,

to answer the general part of you question, there are quite a few packages that 
allow you to use your GPU. At the low level you can use OpenCL which allows you 
to write code directly on the GPU and turn it into R functions. At a higher 
level there are frameworks like Torch and Tensorflow that support GPUs and 
there are packages like keras or rTorch that provide interfaces to that, e.g. 
for machine learning models. All those support Apple silicon GPUs.

However, you mentioned bigCor which is orthogonal to that. There are papers 
(such as https://doi.org/10.1134/S1995080219050068 ) that describe some 
approaches to using GPUs to compute covariance matrices, but in general GPUs 
don't really give you a large benefit on their own since it is a lot more about 
memory management and using smart algorithms/data structures to reduce the 
necessary computation. You may have more luck asking in HPC forums about that 
since is not really Mac-specifc (and the answer may depend on what you are 
actually trying to do so may need more details).

Cheers,
Simon


> On 22/02/2023, at 6:12 AM, William R Revelle  wrote:
> 
> Dear R-Mac users.
> 
> In trying to speed up a large correlation problem (600K subjects, 6k 
> variables,)  which I can do using my bigCor function, I decided it was time 
> to learn how to use GPU on my Mac book with its M1 Max gpu.  
> 
> Having spent a day searching the web and trying  various approaches, I give 
> up.
> 
> Are there any packages I can use to do calculations on the GPU part of my Mac 
> using R?
> 
> Thanks.
> 
> Bill
> 
> William Revelle  personality-project.org/revelle.html
> Professor   personality-project.org
> Department of Psychology www.wcas.northwestern.edu/psych/
> Northwestern University  www.northwestern.edu/
> Use R for psychology personality-project.org/r
> It is 90 seconds to midnight   www.thebulletin.org
> 
> ___
> 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] macOS may not give R much time in a long compute

[Simon Urbanek]

> On Feb 19, 2023, at 3:50 AM, Spencer Graves  
> wrote:
> 
> On 2/18/23 6:40 AM, Prof Brian Ripley wrote:
>> Are you using R.app (you failed to say)?
> 
> 
> I'm "using the newest version of RStudio" [Version 2022.12.0+353 
> (2022.12.0+353)].  This means I am running R.app?
> 


No, it means you're not using R, so please ask RStudio support since that is 
not under R's control (since RStudio is a web server there are many ways how 
this could matter).

Cheers,
Simon

PS: that made me think - if R is embedded in another application we should 
probably include that information in sessionInfo() to avoid confusion of R with 
other tools.

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

Re: [R-SIG-Mac] List of unnecessary messages when I plot something in R from Terminal

[Simon Urbanek]

Christofer,

yes, unfortunately this is a known bug in macOS Ventura affecting a lot of 
command-line programs that use GUI. Do not upgrade to Ventura (usually a good 
advice given the long list of known bugs in Ventura) or wait for a fix from 
Apple.

Cheers,
Simon



> On Feb 11, 2023, at 11:28 PM, Christofer Bogaso  
> wrote:
> 
> Hi,
> 
> When I plot something in R, then it open Quartz and in the console I
> see below messages
> 
>> plot(1:4)
> 
>> 1   HIToolbox   0x7ff8229a2726 
>> _ZN15MenuBarInstance22EnsureAutoShowObserverEv + 102
> 
> 2   HIToolbox   0x7ff8229a22b8
> _ZN15MenuBarInstance14EnableAutoShowEv + 52
> 
> 3   HIToolbox   0x7ff822946908
> SetMenuBarObscured + 408
> 
> 4   HIToolbox   0x7ff8229464ca
> _ZN13HIApplication15HandleActivatedEP14OpaqueEventRefhP15OpaqueWindowPtrh
> + 164
> 
> 5   HIToolbox   0x7ff822940996
> _ZN13HIApplication13EventObserverEjP14OpaqueEventRefPv + 252
> 
> 6   HIToolbox   0x7ff822908bd2
> _NotifyEventLoopObservers + 153
> 
> 7   HIToolbox   0x7ff8229403e6
> AcquireEventFromQueue + 494
> 
> 8   HIToolbox   0x7ff82292f3ec
> ReceiveNextEventCommon + 285
> 
> 9   HIToolbox   0x7ff82292f2b3
> _BlockUntilNextEventMatchingListInModeWithFilter + 70
> 
> 10  AppKit  0x7ff81c136f33 _DPSNextEvent + 909
> 
> 11  AppKit  0x7ff81c135db4
> -[NSApplication(NSEvent)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1219
> 
> 12  grDevices.so0x0001086f7a3b input_handler + 155
> 
> 13  libR.dylib  0x000108b142cf
> Rstd_ReadConsole + 2127
> 
> 14  libR.dylib  0x000108a15b74
> Rf_ReplIteration + 100
> 
> 15  libR.dylib  0x000108a174b1 R_ReplConsole + 161
> 
> 16  libR.dylib  0x000108a17402 run_Rmainloop + 82
> 
> 17  libR.dylib  0x000108a1753e Rf_mainloop + 14
> 
> 18  R   0x00010847af5b main + 27
> 
> 19  dyld0x7ff818bde310 start + 2432
> 
> 1   HIToolbox   0x7ff822aa952b
> _ZN15MenuBarInstance21IsAutoShowHideAllowedEv + 259
> 
> 2   HIToolbox   0x7ff8229a233e
> _ZN15MenuBarInstance24UpdateAutoShowVisibilityE5Pointh + 34
> 
> 3   HIToolbox   0x7ff8229117a4
> _ZN15MenuBarInstance16ForEachMenuBarDoEU13block_pointerFvPS_E + 46
> 
> 4   HIToolbox   0x7ff8229a293d
> _ZN15MenuBarInstance20AutoShowHideObserverEjP14OpaqueEventRefPv + 165
> 
> 5   HIToolbox   0x7ff822908bd2
> _NotifyEventLoopObservers + 153
> 
> 6   HIToolbox   0x7ff82293afb8
> PostEventToQueueInternal + 700
> 
> 7   HIToolbox   0x7ff82293c871
> _ZL29CreateAndPostEventWithCGEventP9__CGEventjhP17__CFMachPortBoost +
> 404
> 
> 8   HIToolbox   0x7ff822948ee9
> _ZL15Convert1CGEventh + 246
> 
> 9   HIToolbox   0x7ff822948d91
> _ZL16MainLoopObserverjP14OpaqueEventRefPv + 41
> 
> 10  HIToolbox   0x7ff822908bd2
> _NotifyEventLoopObservers + 153
> 
> 11  HIToolbox   0x7ff82292f726
> RunCurrentEventLoopInMode + 228
> 
> 12  HIToolbox   0x7ff82292f396
> ReceiveNextEventCommon + 199
> 
> 13  HIToolbox   0x7ff82292f2b3
> _BlockUntilNextEventMatchingListInModeWithFilter + 70
> 
> 14  AppKit  0x7ff81c136f33 _DPSNextEvent + 909
> 
> 15  AppKit  0x7ff81c135db4
> -[NSApplication(NSEvent)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1219
> 
> 16  grDevices.so0x0001086f7a3b input_handler + 155
> 
> 17  libR.dylib  0x000108b142cf
> Rstd_ReadConsole + 2127
> 
> 18  libR.dylib  0x000108a15b74
> Rf_ReplIteration + 100
> 
> 19  libR.dylib  0x000108a174b1 R_ReplConsole + 161
> 
> 20  libR.dylib  0x000108a17402 run_Rmainloop + 82
> 
> 21  libR.dylib  0x000108a1753e Rf_mainloop + 14
> 
> 22  R   0x00010847af5b main + 27
> 
> 23  dyld0x7ff818bde310 start + 2432
> 
> 1   HIToolbox   0x7ff82292f0c2
> _ZN15MenuBarInstance22RemoveAutoShowObserverEv + 30
> 
> 2   HIToolbox   0x7ff8229467e3
> SetMenuBarObscured + 115
> 
> 3   HIToolbox   0x7ff82294d29e

[R-SIG-Mac] Ventura users: do not install R from the Downloads folder

[Simon Urbanek]

Apparently there is a bug in Ventura that prevents software installation from 
the Downloads folder. Once the installer package is moved someplace else - the 
home or Desktop - it works. So if you see "Installation failed", make sure you 
move the package (typically that would be the R-4.2.2-arm64.pkg file) out of 
the Downloads folder. (Thanks to Max for sending the installer log so we could 
trace the cause!).

Cheers,
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] Cannot open PDF Vignettes on Ventura

[Simon Urbanek]

Kevin,

oh, that's something entirely different - what I was talking about was if you 
use
vignette("survival")
in R it opens a Preview with the vignette.

What you describe seems like a browser plugin issue, because the help system is 
just an html page (assuming you are talking about the html help system). So it 
seems that you may have installed some Adobe browser plugin that doesn't work 
anymore. The plugins live in ~/Library/Internet\ Plug-Ins/ (user) and 
/Library/Internet\ Plug-Ins/ (global), so you should remove it from there.

Cheers,
Simon


> On 7/02/2023, at 12:01 PM, Kevin Thorpe  wrote:
> 
> When I try to open a PDF vignette (say a vignette from the survival 
> package)from the help system in R it does not open Preview. I cannot actually 
> open any PDF vignettes. All I get is a finder window with the error I 
> previously described. It asks me to select an appropriate viewer. Selecting 
> Preview opens nothing and more errors are thrown to the Console. I could send 
> you and Duncan screenshots off-list, since I know that theses lists are picky 
> about attachments.
> 
> The steps I take are:
> 
> 1. Open the R app.
> 2. Start the Help system.
> 3. Navigate to the survival package vignettes.
> 4. Click the PDF link for the The survival package
> 
> Then the errors happen.
> 
> I will send a screenshot of the result off list.
> 
> Kevin
> 
> -- 
> Kevin E. Thorpe
> Head of Biostatistics,  Applied Health Research Centre (AHRC)
> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
> Assistant Professor, Dalla Lana School of Public Health
> University of Toronto
> email: kevin.tho...@utoronto.ca  Tel: 416.864.5776  Fax: 416.864.3016
> 
>> On Feb 6, 2023, at 4:58 PM, Simon Urbanek  
>> wrote:
>> 
>> Kevin,
>> 
>> can you then describe in more detail what you are taking about? If you open 
>> a PDF vignette in R, it simply calls "open" so it will open in Preview (as 
>> that is your system viewer). And you have confirmed that it is what happens, 
>> so are you taking about something else? If so, please describe every step 
>> you make to reproduce whatever issue you are having.
>> 
>> Thanks,
>> Simon
>> 
>> 
>> On Feb 7, 2023, at 9:58 AM, Kevin Thorpe  wrote:
>>> 
>>> Yes, it does.
>>> 
>>> Kevin
>>> 
>>> -- 
>>> Kevin E. Thorpe
>>> Head of Biostatistics,  Applied Health Research Centre (AHRC)
>>> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
>>> Assistant Professor, Dalla Lana School of Public Health
>>> University of Toronto
>>> email: kevin.tho...@utoronto.ca  Tel: 416.864.5776  Fax: 416.864.3016
>>> 
>>>> On Feb 6, 2023, at 3:56 PM, Duncan Murdoch  
>>>> wrote:
>>>> 
>>>> On 06/02/2023 3:47 p.m., Kevin Thorpe wrote:
>>>>> Simon,
>>>>> Preview is my default viewer. In the finder window that came up I tried 
>>>>> selecting Preview as the viewer to use and it still failed. The following 
>>>>> errors went to the Console.
>>>>> 2023-02-06 15:43:55.448 R[62964:5174302] +[CATransaction synchronize] 
>>>>> called within transaction
>>>>> 2023-02-06 15:43:55.568 R[62964:5174302] +[CATransaction synchronize] 
>>>>> called within transaction
>>>>> 2023-02-06 15:44:03.253 R[62964:5174302] +[CATransaction synchronize] 
>>>>> called within transaction
>>>>> 2023-02-06 15:44:16.012 R[62964:5174302] +[CATransaction synchronize] 
>>>>> called within transaction
>>>>> Kevin
>>>> 
>>>> Hi Kevin.
>>>> 
>>>> If you just run `open some.pdf` in a terminal, does it open properly in 
>>>> Preview?
>>>> 
>>>> Duncan Murdoch
>>> 
>> 
> 

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

Re: [R-SIG-Mac] Cannot open PDF Vignettes on Ventura

[Simon Urbanek]

Kevin,

can you then describe in more detail what you are taking about? If you open a 
PDF vignette in R, it simply calls "open" so it will open in Preview (as that 
is your system viewer). And you have confirmed that it is what happens, so are 
you taking about something else? If so, please describe every step you make to 
reproduce whatever issue you are having.

Thanks,
Simon


On Feb 7, 2023, at 9:58 AM, Kevin Thorpe  wrote:
> 
> Yes, it does.
> 
> Kevin
> 
> -- 
> Kevin E. Thorpe
> Head of Biostatistics,  Applied Health Research Centre (AHRC)
> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
> Assistant Professor, Dalla Lana School of Public Health
> University of Toronto
> email: kevin.tho...@utoronto.ca  Tel: 416.864.5776  Fax: 416.864.3016
> 
>> On Feb 6, 2023, at 3:56 PM, Duncan Murdoch  wrote:
>> 
>> On 06/02/2023 3:47 p.m., Kevin Thorpe wrote:
>>> Simon,
>>> Preview is my default viewer. In the finder window that came up I tried 
>>> selecting Preview as the viewer to use and it still failed. The following 
>>> errors went to the Console.
>>> 2023-02-06 15:43:55.448 R[62964:5174302] +[CATransaction synchronize] 
>>> called within transaction
>>> 2023-02-06 15:43:55.568 R[62964:5174302] +[CATransaction synchronize] 
>>> called within transaction
>>> 2023-02-06 15:44:03.253 R[62964:5174302] +[CATransaction synchronize] 
>>> called within transaction
>>> 2023-02-06 15:44:16.012 R[62964:5174302] +[CATransaction synchronize] 
>>> called within transaction
>>> Kevin
>> 
>> Hi Kevin.
>> 
>> If you just run `open some.pdf` in a terminal, does it open properly in 
>> Preview?
>> 
>> Duncan Murdoch
> 

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

Re: [R-SIG-Mac] Cannot open PDF Vignettes on Ventura

[Simon Urbanek]

Kevin,

no this is an Adobe issue - it seems to hijack the PDF support. R simply uses 
"open" so it doesn't care who handles it - that is a system setting, it has 
nothing to do with R. Did you try setting Preview as your system viewer?

Cheers,
Simon


> On Feb 7, 2023, at 9:01 AM, Kevin Thorpe  wrote:
> 
> Thanks for the reply Simon.
> 
> As near as I can tell I have a working Adobe reader. I checked for updates 
> and have the current version, it is just not set as my default viewer for 
> PDF. Why has it stopped working with the Mac Preview app? Is it related to 
> the loss of PS/EPS support?
> 
> I would prefer not to have to set Adobe Reader as my default. I could try 
> removing and re-installing and see what happens.
> 
> Kevin
> 
> -- 
> Kevin E. Thorpe
> Head of Biostatistics,  Applied Health Research Centre (AHRC)
> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
> Assistant Professor, Dalla Lana School of Public Health
> University of Toronto
> email: kevin.tho...@utoronto.ca  Tel: 416.864.5776  Fax: 416.864.3016
> 
>> On Feb 6, 2023, at 2:45 PM, Simon Urbanek  
>> wrote:
>> 
>> Kevin,
>> 
>> this looks like a problem with your Adobe installation - you seem to have 
>> the stub installed, but not an actual Adobe viewer. Perhaps look for 
>> uninstallation instructions for Adobe, reinstall it or ask their support? 
>> After upgrades it is often necessary to re-install 3rd party software.
>> 
>> Cheers,
>> Simon
>> 
>> 
>>> On Feb 7, 2023, at 5:14 AM, Kevin Thorpe  wrote:
>>> 
>>> I noticed today that I can no longer open PDF vignettes from the help 
>>> system in Ventura. I first noticed it in RStudio. Previously PDFs would 
>>> open in Preview but now they try to open in a web page. So, I tried in 
>>> native R (outside RStudio). I started the help system and went to the 
>>> survival package vignettes and tried to open one. I eventually got a Finder 
>>> window with the message, "AdobePDFViewer cannot find a compatible Adobe 
>>> Acrobat or Adobe Reader to view this PDF. Please select one.” At the top of 
>>> it.
>>> 
>>> Besides Preview I do also have Adobe Acrobat Reader installed (but it is 
>>> not set as the default viewer for PDFs).
>>> 
>>> Additionally, the following error appeared in the Console when I tried to 
>>> view a PDF vignette (for the sake of reproducibility I tried to load the 
>>> survival.pdf vignette).
>>> 
>>> 2023-02-06 11:10:56.198 R[52961:4981916] CFURLResourceIsReachable failed 
>>> because it was passed a URL which has no scheme
>>> 
>>> Has anyone else encountered this?
>>> 
>>> Here is my sessionInfo()
>>> 
>>>> sessionInfo()
>>> R version 4.2.2 (2022-10-31)
>>> Platform: x86_64-apple-darwin17.0 (64-bit)
>>> Running under: macOS Ventura 13.1
>>> 
>>> Matrix products: default
>>> BLAS:   
>>> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRblas.0.dylib
>>> LAPACK: 
>>> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib
>>> 
>>> locale:
>>> [1] en_CA.UTF-8
>>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base 
>>> 
>>> other attached packages:
>>> [1] knitr_1.42
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] compiler_4.2.2 tools_4.2.2xfun_0.37 
>>> 
>>> 
>>> 
>>> -- 
>>> Kevin E. Thorpe
>>> Head of Biostatistics,  Applied Health Research Centre (AHRC)
>>> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
>>> Assistant Professor, Dalla Lana School of Public Health
>>> University of Toronto
>>> email: kevin.tho...@utoronto.ca  Tel: 416.864.5776  Fax: 416.864.3016
>>> 
>>> ___
>>> 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] Cannot open PDF Vignettes on Ventura

[Simon Urbanek]

Kevin,

this looks like a problem with your Adobe installation - you seem to have the 
stub installed, but not an actual Adobe viewer. Perhaps look for uninstallation 
instructions for Adobe, reinstall it or ask their support? After upgrades it is 
often necessary to re-install 3rd party software.

Cheers,
Simon


> On Feb 7, 2023, at 5:14 AM, Kevin Thorpe  wrote:
> 
> I noticed today that I can no longer open PDF vignettes from the help system 
> in Ventura. I first noticed it in RStudio. Previously PDFs would open in 
> Preview but now they try to open in a web page. So, I tried in native R 
> (outside RStudio). I started the help system and went to the survival package 
> vignettes and tried to open one. I eventually got a Finder window with the 
> message, "AdobePDFViewer cannot find a compatible Adobe Acrobat or Adobe 
> Reader to view this PDF. Please select one.” At the top of it.
> 
> Besides Preview I do also have Adobe Acrobat Reader installed (but it is not 
> set as the default viewer for PDFs).
> 
> Additionally, the following error appeared in the Console when I tried to 
> view a PDF vignette (for the sake of reproducibility I tried to load the 
> survival.pdf vignette).
> 
> 2023-02-06 11:10:56.198 R[52961:4981916] CFURLResourceIsReachable failed 
> because it was passed a URL which has no scheme
> 
> Has anyone else encountered this?
> 
> Here is my sessionInfo()
> 
>> sessionInfo()
> R version 4.2.2 (2022-10-31)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS Ventura 13.1
> 
> Matrix products: default
> BLAS:   
> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] en_CA.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
> 
> other attached packages:
> [1] knitr_1.42
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.2.2 tools_4.2.2xfun_0.37 
> 
> 
> 
> -- 
> Kevin E. Thorpe
> Head of Biostatistics,  Applied Health Research Centre (AHRC)
> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
> Assistant Professor, Dalla Lana School of Public Health
> University of Toronto
> email: kevin.tho...@utoronto.ca  Tel: 416.864.5776  Fax: 416.864.3016
> 
> ___
> 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] Issues Downloading R on Mac M1

[Simon Urbanek]

Emily,

first, R may already be installed - check your Application folder.

If that is not the case, restart your computer. Only then try the installation 
again.

If you get an error again, go to Window in the top menu and select "Installer 
Log". This will pop up a window on the bottom. There in the top left select 
"Show All Logs" and then click on "Save" in the top right corner. Save the log 
and post it here.

Thanks,
Simon



> On Jan 30, 2023, at 3:21 PM, Emily Steinman  wrote:
> 
> 
> Hi,
> 
> I’ve been having issues downloading R and it is required for my statistics 
> class. I have a macbook air with an M1 and it’s on Ventura. I followed the 
> steps on the website to download R-4.2.2-arm64.pkg but everytime I get this 
> error message:
> 
> Please help!!
> 
> Thanks,
> Emily Steinman___
> 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] Nightly builds for macOS Intel not available from https://mac.r-project.org/?

[Simon Urbanek]

Peter,

see the "last-success" section in the https://mac.r-project.org/ page which 
links to
https://mac.r-project.org/high-sierra/last-success/
The main page only has a download link if the build was successful, but the 
above will retained the last successful build when if there is a problem with 
the current build (which is something I have to look into).

Cheers,
Simon



> On Jan 24, 2023, at 10:52 PM, Peter Hickey  wrote:
> 
> Hi,
> 
> I haven't found a .pkg file (or tar.gz) for Intel Macs for
> R-4.2-branch or R-devel when I've looked over the last few days.
> I first noticed this sometime last week (can't remember exactly when,
> sorry), and have checked intermittently since but to no avail.
> The corresponding files for arm64 Macs are available.
> 
> Am I missing where I can download R-devel for an Intel mac (ideally,
> the .pkg version) or perhaps has something gone wrong with the
> packaging or upload?
> 
> Thanks,
> Pete
> 
> ___
> 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] Warnings installing from source

[Simon Urbanek]

Göran,

you can ignore the Fortran warnings, the ones you listed are not related to the 
code.

As for "undefined dynamic_lookup may not work with chained fixups" the easiest 
is to run
export MACOSX_DEPLOYMENT_TARGET=11.0
before you compile your package. Alternatively you can add -Wl,-no_fixup_chains 
to LDFLAGS.

Cheers,
Simon


> On Jan 9, 2023, at 11:57 PM, Göran Broström  wrote:
> 
> When running
> 
> R CMD INSTALL xxx.tar.gz
> 
> I get a lot of warnings, the first being
> 
> ld: warning: -undefined dynamic_lookup may not work with chained fixups
> 
> followed by several of the type
> 
> ld: warning: could not create compact unwind for _yyy_: registers 72 and 73 
> not saved contiguously in frame
> 
> where 'yyy' stands for names of fortran functions/subroutines in the package 
> xxx.
> 
> I have installed the usual tools, including gfortran, from
> https://mac.r-project.org/tools/
> 
> The C compiler is clang (14.0.0), for reasons I have forgotten.
> 
> However, the package loads an runs as usual(?), so I wonder what I should do 
> about it? Nothing?  But what do the warnings mean?
> 
> Thanks, Göran
> 
> PS. No warnings on Ubuntu.
> 
> > sessionInfo()
> R version 4.2.2 (2022-10-31)
> Platform: aarch64-apple-darwin20 (64-bit)
> Running under: macOS Ventura 13.0.1
> 
> Matrix products: default
> BLAS: 
> /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] sv_SE.UTF-8/sv_SE.UTF-8/sv_SE.UTF-8/C/sv_SE.UTF-8/sv_SE.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.2.2
> 
> ___
> 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 and Ventura

[Simon Urbanek]

> On Dec 15, 2022, at 1:37 AM, Calboli Federico (LUKE) 
>  wrote:
> 
> 
> 
>> On 14. Dec 2022, at 14.19, Kevin Thorpe  wrote:
>> 
>> Hello.
>> 
>> Shortly after Ventura released a saw a few posts on this list about 
>> peculiarities (I saw something about Xcode common line tools I believe). I 
>> am thinking of upgrading soon from Monterey to Ventura (Intel chip) and 
>> wanted to see if there were any pitfalls. I looked at the MAC FAQ on CRAN 
>> and in the tools directory (regarding compiler tools) and see no specific 
>> mention of Ventura.
> 
> I am on Ventura and I have no issue.  I do not use XCode, just the command 
> line tools.  Both are available as a stable release install.  I use homebrew 
> for gfortran.
> 


Just a side note: please don't use compilers from Homebrew, they are not 
compatible and cause issues when combined with other binaries because of 
different run-times. For R releases please use https://mac.r-project.org/tools/ 
if you need to compile Fortran packages from sources.

Cheers,
Simon


> XQuartz should probably be reinstalled, and a new version was made availble 
> early this/last week.
> 
> Basically, unless you expect to compile packages from source, everything 
> should work.  If you install from source, or use specific packages that call 
> C or Fortran code other might give better insight.
> 
> BW
> 
> F
> 
> 
> 
> 
> --
> Federico Calboli
> Tutkija
> Genomiikka ja jalostus, Luonnonvarakeskus 
> +358295322656
> 
> ___
> 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] CRAN-like M1mac test environment?

[Simon Urbanek]

Daniel,

note that you can choose R-devel in MacBuilder (select "development" under R 
version). If your package works on the MacBuilder then it's good as far as 
macOS goes since that is identical to the CRAN setup.

Cheers,
Simon



> On Dec 14, 2022, at 12:02 AM, Wollschlaeger, Daniel 
>  wrote:
> 
> (This is a re-post from R-pkg-devel hoping to get more feedback)
> 
> A package of mine was recently archived from CRAN because one of its
> examples results in a crash on the M1mac platform:
> https://www.stats.ox.ac.uk/pub/bdr/M1mac/MeshAgreement.out
> 
> As I don't have access to a Mac, I'm very grateful for Macbuilder. However,
> there, the package tests without errors (link likely to stop working):
> https://mac.r-project.org/macbuilder/results/1670186023-a7f313b721c2b516/
> 
> One difference I noticed between the Macbuilder and CRAN systems is that
> Macbuilder builds for aarch64-apple-darwin20 (64-bit), whereas CRAN builds
> for aarch64-apple-darwin22.1.0 (64-bit). Moreover, Macbuilder uses R-4.2.1
> whereas CRAN uses R-devel r83383.
> 
> The example leading to the crash uses a function from the imported package
> cgalMeshes which relies on compiled code. cgalMeshes itself is on CRAN and
> apparently tests without errors on M1mac. I would like to investigate
> further how to prevent the crash, but it may depend on the MacOS version, or
> on the R version. Are there publicly available options to test packages on a
> system that is very similar to the CRAN M1mac in order to implement the
> necessary changes to get the package back on CRAN?
> 
> Many thanks in advance
> 
> Daniel
> 
> ___
> 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] another R crash issue

[Simon Urbanek]

This is a clear bug in gmp (the R package) - simply division by zero in

templateMatrix.h:126:return this->size() / nRows();

  * frame #0: 0x0001076e1b12 
gmp.so`math::Matrix::nCols(this=0x7ffeefbfc5d8) const at 
templateMatrix.h:126:25 [opt]
frame #1: 0x0001076ea253 
gmp.so`matrixz::bigint_transpose(mat=0x7ffeefbfc5d8) at matrix.cc:484:23 
[opt]
frame #2: 0x0001076eb3be 
gmp.so`::biginteger_rbind(args=0x000108a60848) at matrix.cc:459:12 [opt]

i.e., bigint_transpose() cannot deal with 0-row matrices. That may be just the 
tip of the ice berg, even biginteger_rbind itself should probably just skip 
zero-length objects.

Cheers,
Simon


> On 17/11/2022, at 9:50 PM, Martin Maechler  wrote:
> 
>> Carl Witthoft 
>>on Wed, 16 Nov 2022 19:58:31 -0500 writes:
> 
>> This may be the fault of the `gmp` library, but posting to r-sig as well 
>> just in case.
> 
>> Mac OS 11.6.8  , R 4.2.2
> 
> Yes, the gmp package Mac version gives immediate seg faults.
> 
> Prof Brian Ripley has already alerted the gmp package maintainer, me
> (a gmp package co-author, not familiar with the C++ design in
> there, and maintainer of dependent R package 'Rmpfr') and
> the CRAN team.
> 
> He has debugged deeply and tediously until diagnosing the
> problem happens in *assembler* (!) code of the libgmp.a library
> (i.e, the 'gmp'  C library that has nothing to do with R).
> 
> Brian Ripley further found that when using the latest
> *development* version of that gmp C library and building libgmp
> and R packages gmp and Rmpfr himself from the sources he got no
> more segfaults.
> 
> The problem is only seen on the Mac.
> 
> Martin
> 
> 
>> Consider the following work:
> 
>Rgames> foo <- NULL
>Rgames> rbind(foo,c(1,3))
>> [,1] [,2]
>> [1,]13
>Rgames> foo <- NULL
>Rgames> # rbind(foo,as.bigz(c(1,3)))  ## instant crash
> 
> 
>> Further playing around suggests that , given that  as.bigz(NULL) returns 
>> a  "bigz(0) " empty object,   gmp is really unhappy trying to do almost 
>> anything with said object.
> 
> 
>> regards,
>> Carl
> 
> 
>> Crash log follows
>> Process:   R [11657]
>> Path:  /Applications/R.app/Contents/MacOS/R
>> Identifier:org.R-project.R
>> Version:   R 4.2.2 GUI 1.79 High Sierra build (8160)
>> Code Type: X86-64 (Native)
>> Parent Process:??? [1]
>> Responsible:   R [11657]
>> User ID:   502
> 
>> Date/Time: 2022-11-16 19:42:41.462 -0500
>> OS Version:macOS 11.6.8 (20G730)
>> Report Version:12
>> Anonymous UUID:B755C094-C366-46AB-8EEA-9D3B8E7B388D
> 
>> Sleep/Wake UUID:   D725679E-AF7A-4203-8EA3-B313AA2846F5
> 
>> Time Awake Since Boot: 98000 seconds
>> Time Since Wake:   2100 seconds
> 
>> System Integrity Protection: enabled
> 
>> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
>> Exception Type:EXC_ARITHMETIC (SIGFPE)
>> Exception Codes:   EXC_I386_DIV (divide by zero)
>> Exception Note:EXC_CORPSE_NOTIFY
> 
>> Termination Signal:Floating point exception: 8
>> Termination Reason:Namespace SIGNAL, Code 0x8
>> Terminating Process:   exc handler [11657]
> 
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   gmp.so   0x0001149159c2 
>> math::Matrix::nCols() const + 34
>> 1   gmp.so   0x00011491e5af 
>> matrixz::bigint_transpose(bigvec&) + 47
>> 2   gmp.so   0x00011491f8be biginteger_rbind + 
>> 158
>> 3   libR.dylib   0x000104b3f8dc R_doDotCall + 1420 
>> (dotcode.c:601)
>> 4   libR.dylib   0x000104b8b7ed bcEval + 104269 
>> (eval.c:7692)
>> 5   libR.dylib   0x000104b71a01 Rf_eval + 385 
>> (eval.c:748)
>> 6   libR.dylib   0x000104b91839 R_execClosure + 2169
>> 7   libR.dylib   0x000104b90627 Rf_applyClosure + 
>> 471 (eval.c:1844)
>> 8   libR.dylib   0x000104af61db do_bind + 1051 
>> (bind.c:1118)
>> 9   libR.dylib   0x000104bdbbfa do_internal + 362 
>> (names.c:1399)
>> 10  libR.dylib   0x000104b7920d bcEval + 29037 
>> (eval.c:7156)
>> 11  libR.dylib   0x000104b71a01 Rf_eval + 385 
>> (eval.c:748)
>> 12  libR.dylib   0x000104b91839 R_execClosure + 2169
>> 13  libR.dylib   0x000104b90627 Rf_applyClosure + 
>> 471 (eval.c:1844)
>> 14  libR.dylib   0x000104b71ebb Rf_eval + 1595 
>> (eval.c:871)
>> 15  libR.dylib   0x000104b95821 do_eval + 625 
>> (eval.c:3366)
>> 16  libR.dylib   0x000104b79035 bcEval + 28565 
>> (eval.c:7136)
>> 17  libR.dylib   0x000104b71a01 Rf_eval + 385 
>> (eval.c:748)
>> 18  libR.dylib

Re: [R-SIG-Mac] [External] Re: problem with Rprof

[Simon Urbanek]

> On Nov 9, 2022, at 10:03 AM, Tomas Kalibera  wrote:
> 
> 
> On 11/7/22 01:58, luke-tier...@uiowa.edu wrote:
>> On Sun, 6 Nov 2022, Simon Urbanek wrote:
>> 
>>> Carl,
>>> 
>>> first, setting such low interval won't work anyway - the overhead is bigger 
>>> than the sampled time, so we should really not allow it to begin with (on 
>>> my machine the timer signals arrive before anything can be done so you have 
>>> to kill R and you get no output).
>>> 
>>> That said, it crashes in doprof() which is called on all threads - the main 
>>> R one is ok, but one of the other threads crashes in pthread_self(). At 
>>> that time R is trying to propagate the signal from all threads to the main 
>>> thread which seems odd to me (since the main thread already got the 
>>> signal), I'm CCing Luke in the hope that he has any ideas. This may fall in 
>>> the category of "don't do this" and the fix may be to set a lower bound on 
>>> the interval.
>> 
>> I can't reproduce this on Linux or macOS.
>> 
>> On Linux only one thread receives a signal sent to a process, but the
>> kernel picks which one if multiple threads have the signal unblocked,
>> so we make sure the signal gets relayed to the main thread. If macOS
>> behaves differently then someone who knows how signals and threads
>> interact there would have to adjust this code.
> 
> From my reading this is the same on macOS. The profiling signal is 
> asynchronous, sent to the process, it will be served by one thread which is 
> picked by the OS. POSIX doesn't say which thread is preferred.


Yes, I saw the same with extra detail that thread signal blocking doesn't seem 
to necessarily work on macOS.


> While some OSes prefer the main thread (I read macOS and Linux do, but from 
> non-authoritative sources), R may also be embedded and not run on the main 
> thread.
> 
> We have to do something to ensure the R thread is not running while we sample 
> its R stack, anyway. On Windows we suspend the R thread for that. On Unix we 
> do the relaying.  We could in principle suspend the R thread on macOS as 
> well, but would have to use Mach calls directly.
> 
>> Disallowing such a low interval is reasonable, but if there is a real
>> issue on macOS then it would only mask the problem.
> 
> Yes. The key question is why pthread_self() crashed.


Yes, that is the main mystery. Looking at the xnu kernel sources it is 
equivalent to pthread_getspecific(0) [since it's just the first slot in TSD] 
plus a check of a magic content in there. I suspect it's that check which 
segfaults for whatever reason. I wanted to see if just comparing the pointer 
from pthread_getspecific(0) instead of pthread_self() would work since we don't 
care if the pthread_t is valid as we only compare it to the main thread value 
(not that I would propose that as a fix since it's very 
implementation-specific, just curious), but I didn't get that far (I cannot 
really reproduce it - the closest I get is a mach exception under lldb).



> Otherwise, from the stack trace, the behavior looks ok. The main thread (also 
> R thread) is serving the signal, hence the signal is blocked, but it is 
> received again, so another thread is picked to serve it, and it is relaying 
> it to the main thread. One more thread is picked to serve it, and it crashes 
> while calling pthread_self(). There is also one more thread not involved in 
> the signal handling.
> 
> POSIX statest that pthread_self() is async-signal-safe. macOS 12.6 manuals 
> (sigaction) however doesn't include any pthread function in the list of 
> async-signal-functions.
> 
> We could do some work-around (hiding the problem a bit more) like exit from 
> the handler if the signal is being served by another thread. We could also 
> report such situation to indicate that the interval is unreasonable. But it 
> would be good first to know for sure what caused the problem.
> 

How can you check anything if pthread functions fail? If a simple pthead_self() 
crashes then I don't see how you can do anything since we don't even know what 
thread we are, cannot call mutexes etc.

Cheers,
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] problem with Rprof

[Simon Urbanek]

Carl,

first, setting such low interval won't work anyway - the overhead is bigger 
than the sampled time, so we should really not allow it to begin with (on my 
machine the timer signals arrive before anything can be done so you have to 
kill R and you get no output).

That said, it crashes in doprof() which is called on all threads - the main R 
one is ok, but one of the other threads crashes in pthread_self(). At that time 
R is trying to propagate the signal from all threads to the main thread which 
seems odd to me (since the main thread already got the signal), I'm CCing Luke 
in the hope that he has any ideas. This may fall in the category of "don't do 
this" and the fix may be to set a lower bound on the interval.

Cheers,
Simon



> On Nov 6, 2022, at 6:46 AM, Carl Witthoft  wrote:
> 
> Wondering if this is a hiccup in  R-mac 4.2.1 (running under 11.6.8 Big Sur), 
> or a bug in Rprof:
> 
> If I try to set a very small time interval,
> 
> >>  Rprof(interval = 0.01)  ,
> R crashes.
> 
> Crash report follows:
> 
> Process:   R [54439]
> Path:  /Applications/R.app/Contents/MacOS/R
> Identifier:org.R-project.R
> Version:   R 4.2.1 GUI 1.79 High Sierra build (8095)
> Code Type: X86-64 (Native)
> Parent Process:??? [1]
> Responsible:   R [54439]
> User ID:   502
> 
> Date/Time: 2022-11-05 13:37:36.003 -0400
> OS Version:macOS 11.6.8 (20G730)
> Report Version:12
> Anonymous UUID:B755C094-C366-46AB-8EEA-9D3B8E7B388D
> 
> Sleep/Wake UUID:   6135D492-FF9D-4ED1-AF9F-C0F790F64110
> 
> Time Awake Since Boot: 150 seconds
> Time Since Wake:   7200 seconds
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:6
> 
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS at 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Termination Signal:Segmentation fault: 11
> Termination Reason:Namespace SIGNAL, Code 0xb
> Terminating Process:   exc handler [54439]
> 
> VM Regions Near 0:
> -->
>__TEXT  103034000-1030bc000[  544K] r-x/r-x SM=COW 
>  /Applications/R.app/Contents/MacOS/R
> 
> Thread 0:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib0x7fff208cdf4a __sigaction + 10
> 1   libsystem_platform.dylib  0x7fff2094367c __platform_sigaction 
> + 103
> 2   libsystem_c.dylib 0x7fff207fe689 signal__ + 66
> 3   libR.dylib0x00010323a23c doprof + 1676 
> (eval.c:345)
> 4   libsystem_platform.dylib  0x7fff20943d7d _sigtramp + 29
> 5   ???   0x8000 0 + 
> 9223372036854775808
> 6   libsystem_malloc.dylib0x7fff207255ed nanov2_allocate + 367
> 7   libsystem_malloc.dylib0x7fff2072754d nanov2_calloc + 123
> 8   libsystem_malloc.dylib0x7fff2073fff4 _malloc_zone_calloc 
> + 59
> 9   libobjc.A.dylib   0x7fff2079c5fa class_createInstance 
> + 65
> 10  com.apple.CoreFoundation  0x7fff2097a335 __CFAllocateObject + 
> 15
> 11  com.apple.CoreFoundation  0x7fff20980f04 __NSDictionaryI_new 
> + 126
> 12  com.apple.CoreFoundation  0x7fff20980d48 +[NSDictionary 
> dictionaryWithObjects:forKeys:count:] + 49
> 13  com.apple.AppKit  0x7fff23a5 
> -[_NSToolbarButtonCell _symbolImageHints] + 213
> 14  com.apple.AppKit  0x7fff2326659a -[NSButtonCell 
> _currentImageInView:] + 401
> 15  com.apple.AppKit  0x7fff232c0992 -[NSButtonCell 
> _effectiveContentStyleForImageInView:] + 184
> 16  com.apple.AppKit  0x7fff232646c4 -[NSButtonCell 
> _updateImageViewImageInView:] + 93
> 17  com.apple.AppKit  0x7fff232645a4 __60-[NSButtonCell 
> _updateSubviewsInView:includeTitleTextField:]_block_invoke + 134
> 18  com.apple.AppKit  0x7fff231ea835 +[NSAppearance 
> _performWithCurrentAppearance:usingBlock:] + 66
> 19  com.apple.AppKit  0x7fff23231321 -[NSButtonCell 
> _updateSubviewsInView:includeTitleTextField:] + 131
> 20  com.apple.AppKit  0x7fff232310eb -[NSButton 
> updateCell:] + 87
> 21  com.apple.AppKit  0x7fff23230a84 -[NSCell 
> setEnabled:] + 156
> 22  com.apple.AppKit  0x7fff23230d0f -[NSControl 
> setEnabled:] + 120
> 23  com.apple.AppKit  0x7fff2330af46 -[NSToolbarItem 
> _reallySetEnabled:] + 124
> 24  org.R-project.R   0x00010304542b Re_RBusy + 59
> 25  libR.dylib0x0001032694bf R_ReplDLLdo1 + 559 
> (main.c:408)
> 26  org.R-project.R   0x000103052e15 run_REngineRmainloop 
> + 261
> 27  org.R-project.R   0x00010304798f -[REngine runREPL] + 
> 143
>

Re: [R-SIG-Mac] (no subject)

[Simon Urbanek]

Noah,

this looks like you may be using R for older Intel machines on a M1 Mac Book 
(via emulation). Please double-check that you installed the R version 
appropriate to your machine - your sessionInfo() shoud show:

Platform: aarch64-apple-darwin20 (64-bit)

If not, install the correct R version.

Cheers,
Simon



> On Oct 15, 2022, at 9:09 AM, Noah Jussila  wrote:
> 
> Dear R-SIG-MAC list members,
> 
> I'm attempting to use the function as.bigq() in R's gmp package, but it
> always causes an "illegal operation". For example, it triggers the
> following output:
> 
> *** caught illegal operation ***
> address 0x11ffc8b21, cause 'illegal opcode'
> 
> Traceback:
> 1: as.bigq(1)
> 
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> 
> I cannot reproduce this on a Windows machine. I'm working on a MacBook Pro
> with model identifier MacBookPro18,1.
> 
> Thank you,
> Noah
> 
>   [[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] rprograming

[Simon Urbanek]

Julie,

the R binaries compatible with macOS 10.12 can be seen here:

https://mac.r-project.org/bin/macosx/el-capitan/base/

since those work on Mac OS X 10.11 and higher.

If you need a more recent version of R you would have to compile R and all 
packages from sources. However, given the dangers of using such an old version 
as macOS 10.12 I would strongly recommend updating the macOS version instead.

Cheers,
Simon



> On 7/10/2022, at 9:14 AM, Julie Coughlin  wrote:
> 
> Hi,
> what version is best compatible with MacOS 10.12.6?
> I cannot get r program on my computer.
> Thank You, Julie
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-https://mac.r-project.org/bin/macosx/el-capitan/base/

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

[R-SIG-Mac] System-wide site library [Was: CRAN installer for macOS - directory permissions]

[Simon Urbanek]

We could re-design the layout of the framework and site locations to be more in 
line with the modern Apple standards. Splitting the library into system (R 
itself only) and site library could make the framework more correctly self 
sufficient. The site library would then go into "/Library/Application 
Support/org.R-project.R/library” and user library in the equally named 
subdirectory of $HOME. That would directly correspond to the Apple designations 
of NSApplicationSupportDirectory in NSLocalDomainMask and NSUserDomainMask 
domains. The drawback would be that none of this is versioned any longer, so we 
probably would have to rely on different bundle IDs (e.g. to distinguish 
big-sur builds from high-sierra builds) and possibly add versioned 
subdirectories inside our realm. Also this would make it impossible to make 
self-contained R apps, because the packages are outside of the framework path 
structure, but I have not seen anyone using that feature in a long time.

Obviously, this would be a major breaking change so for R-devel and R.app would 
have to be updated to use the corresponding paths for the package management, 
but that’s not too hard. I wouldn’t put this on top of my list given that the 
effect is mostly cosmetic, but by using the Apple API it would allow the 
framework to be used in a container if anyone cared (there are bigger issues if 
anyone wanted to create an iOS version, though ;)).

Cheers,
Simon



> On 9/06/2022, at 06:56, Duncan Murdoch  wrote:
> 
> Henrik, you posted this a couple of days ago and I didn't address the 
> _R_CHECK_DEPENDS_ONLY_ point you raised.
> 
> You're right that the current implementation of _R_CHECK_DEPENDS_ONLY_ 
> doesn't work if all packages are installed in one lib.  This is a flaw, with 
> one fix being to never put contributed packages into the system lib.  (I 
> haven't done a Linux install in a long time; don't they by default put 
> recommended packages there?  They can also be Suggested packages, so if 
> they're in the system lib, that's a bug.)
> 
> Another possible fix is to change how _R_CHECK_DEPENDS_ONLY_ works, so that 
> it affects package loading directly, by allowing the user to specify a 
> whitelist of packages (e.g. based on the dependencies in the DESCRIPTION 
> file) and having the package loader refuse to load any package unless it's in 
> there.  I think I like the current implementation better.
> 
> So I'd change my recommendation for single-user systems:  they should have 
> two libs.  One contains base packages and nothing else, the other contains 
> all contributed packages, including recommended ones.  Assuming the single 
> user is in the admin group, they could modify the second lib, but only 
> reinstalls of R would change the first one.
> 
> On a multi-user system there would typically be another lib in the user 
> account.
> 
> Duncan Murdoch
> 
> On 03/06/2022 12:45 p.m., Henrik Bengtsson wrote:
>> I see two fairly big problems with users installing R packages to
>> .Library by default.  One is related to package checking and CRAN, and
>> one is related to translation of expectations when moving between
>> operating systems (as Patrick already pointed out).  At the end, I'll
>> also argue that R_LIBS_SITE exists for those who wish to maintain
>> site-wide R package libraries to be shared among users, which is
>> better than using .Library for this.
>> # R CMD check
>> When you check a package with 'R CMD check --as-cran', or, with
>> environment variable `_R_CHECK_DEPENDS_ONLY_` set to true, the checks
>> are run in a sandbox where only declared package dependencies and any
>> packages in the system package library (= .Library) are on the library
>> path (= .libPaths()), e.g.
>> print(.libPaths())
>> [1] "/tmp/alice/RtmpYDq3KF/RLIBS_2410b74eb16752"
>> [2] "/path/to/R-4.2.0/lib/R/library"
>> What's in the user's library (= R_LIBS_USER) or in the site library (=
>> .Library.site/R_LIBS_SITE) is not part of the testing.  This mechanism
>> is very valuable since it helps to identify undeclared package
>> dependencies.
>> **The default behavior on macOS discussed here, where R packages are
>> installed to .Library, breaks this.**  Developers with non-base R
>> packages in .Library will not benefit from the 'R CMD check --as-cran'
>> checks for undeclared packages. This increases the risk of them not
>> being aware of the problem of undeclared packages, which is a
>> discussion we see from time to time on R-devel and R-pkg-devel, e.g.
>> when it comes to what should be listed under Suggests: or not.
>> BTW, this makes me wonder how many macOS developers notice this
>> problem only as they submit to CRAN, and have to resubmit. Also, this
>> issue might add extra work to the CRAN Team, e.g. spending time
>> locking at and responding to possible false positives, handling more
>> emails, and handling more re-submissions.
>> # Social expectations
>> The second problem with the current default macOS behavior is when
>> people ho

Re: [R-SIG-Mac] [External] [External] Xquartz started crashing today

[Simon Urbanek]

Rich,

it looks like the same problem, you have some infinite loop in your fonts. No 
idea how that can happen, possibly recursive symlink in your font directory?

Cheers.
Simon


> On Jun 7, 2022, at 2:12 AM, Richard M. Heiberger  wrote:
> 
> i think i will bring it to apple this afternoon.
> what font does the default graphics device use?
> 
> this morning the time is up to 4:26.17 and the bar is still at 1%.
> 
> From: Ken Beath 
> Sent: Monday, June 6, 2022 1:44:58 AM
> To: Richard M. Heiberger 
> Cc: Simon Urbanek ; r-sig-mac R 
> 
> Subject: [External] Re: [R-SIG-Mac] [External] Xquartz started crashing today
>  
> Less than 30 seconds on my iMac, so something is very wrong with your fonts 
> or file system.
> 
> Ken
> 
>> On 6 Jun 2022, at 2:34 pm, Richard M. Heiberger  wrote:
>> 
>> I am in the middle of validating fonts. The machine has been running for 
>> about 12 hours, the Activity Monitor CPU
>> time for the Font Book app is currently at 2:35.15. It keeps going up but 
>> very slowly.
>> The progress bar at the bottom of the Font Validation window has been stuck 
>> at about 1% from when it started and hasn't moved.
>> How long is this task supposed to take?
>> 
>>> On Jun 04, 2022, at 00:49, Richard M. Heiberger  wrote:
>>> 
>>> Simon,
>>> 
>>> Thank you for reading this.
>>> 
>>> I sent what Apple gave me. I had not previously tried reading one of these.
>>> So should I be so lucky in the future, then all you need is everything 
>>> between
>>> Process: R [
>>> and the next occurence of
>>> Process: 
>>> ?
>>> 
>>> and maybe also the up front stuff before the Process: information.
>>> 
>>> I already rebooted, installed a new R, and a new Xquartz. Those didn't help.
>>> Reinstalling R is probably irrelevant because the problem occurred first in 
>>> 4.1-arm64,
>>> which is why I upgraded to 4.2-arm64. And it was still there.
>>> 
>>> This suggests that the problem is with the Fonts. I have never touched them 
>>> (on purpose).
>>> I will learn a little in the next frew days and see what can be done with 
>>> validation.
>>> I will let you know. But what made the fonts (if that is indeed the 
>>> problem) go invalid.
>>> I can't think of anything I did that could be relevant.
>>> 
>>> Rich
>>> 
>>> 
>>>> On Jun 03, 2022, at 23:32, Simon Urbanek  
>>>> wrote:
>>>> 
>>>> Rich,
>>>> 
>>>> thanks. You sent a log of all processes on your machine, just the R report 
>>>> would have been fine (which is only 18k).
>>>> 
>>>> The hang occurs in ATSFontFindFromName() where the system is looking for 
>>>> fonts, so you could try: a) reboot he machine, b) run Font Book (in 
>>>> Applications), c) select all fonts () d) in the menu select File 
>>>> -> Validate Fonts e) select any invalid fonts and remove them f) reboot
>>>> 
>>>> If the problem persists try re-installing the R 4.2.0 release if it makes 
>>>> any difference.
>>>> 
>>>> Cheers,
>>>> Simon
>>>> 
>>>> 
>>>>> On Jun 4, 2022, at 3:10 AM, Richard M. Heiberger  wrote:
>>>>> 
>>>>> cover letter for crash report, that also got stopped for being part of a 
>>>>> too large email,
>>>>> 
>>>>> 
>>>>> I am doing nothing different that I know of.
>>>>> I start R within emacs using ESS with M-x R
>>>>> 
>>>>> 
>>>>> R version 4.2.0 Patched (2022-06-02 r82444) -- "Vigorous Calisthenics"
>>>>> Copyright (C) 2022 The R Foundation for Statistical Computing
>>>>> Platform: aarch64-apple-darwin20 (64-bit)
>>>>> 
>>>>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>>>>> You are welcome to redistribute it under certain conditions.
>>>>> Type 'license()' or 'licence()' for distribution details.
>>>>> 
>>>>> Natural language support but running in an English locale
>>>>> 
>>>>> R is a collaborative project with many contributors.
>>>>> Type 'contributors()' for more information and
>>>>> 'citation()' on how to cite R or R packages in publications.
>>>>> 
>>>>> Type 'demo()&#x

Re: [R-SIG-Mac] tcltk causes help() to hang in R 4.2.0 on macOS

[Simon Urbanek]

John,

thanks, this is a regression caused by r78421 (deadlock when TclTk's event loop 
is called in http processing). Removing L875 in src/modules/internet/Rhttpd.c 
restores the previous behavior, but the underlying problem is more complex and 
will require more investigation.

Cheers,
Simon


> On 29/05/2022, at 5:36 AM, John Fox  wrote:
> 
> Dear R-sig-mac list members,
> 
> I've discovered that loading the tcltk package apparently causes R 4.2.0 
> (including the current patched version) to hang on an M1 Mac.
> 
> Try, e.g.,
> 
> library("tcltk")
> help("lm")
> 
> My session info:
> 
> --- snip ---
> 
> > sessionInfo()
> R version 4.2.0 Patched (2022-05-28 r82413)
> Platform: aarch64-apple-darwin20 (64-bit)
> Running under: macOS Monterey 12.3.1
> 
> Matrix products: default
> BLAS: 
> /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/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] tcltk stats graphics  grDevices utils datasets  methods
> [8] base
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.2.0
> 
> --- snip ---
> 
> Some additional details: The problem occurs both in the R macOS console and, 
> if options(help_type="html"), when R is run in a terminal window on macOS, 
> but not when options(help_type="text"). The former is the default in the Mac 
> R console, the latter when R is run in a terminal.
> 
> The problem is apparently new in R 4.2.0 -- it doesn't, e.g., occur in R 
> 4.1.3. My apologies for not turning it up earlier.
> 
> I discovered the problem when accessing help in the Rcmdr GUI, which uses 
> tcltk, caused R to hang.
> 
> Has anyone else encountered this problem?
> 
> Best,
> John
> -- 
> John Fox, Professor Emeritus
> McMaster University
> Hamilton, Ontario, Canada
> web: https://socialsciences.mcmaster.ca/jfox/
> 
> ___
> 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] CRAN installer for macOS - directory permissions

[Simon Urbanek]

Patrick,

sorry fo the delayed reply - this was not a quick e-mail so I had to find time 
after the release :)


> On Apr 3, 2022, at 8:26 PM, Patrick Schratz  wrote:
> 
> Hi Simon,
> 
> thanks for your extensive reply.
> 
> The choice is deliberate: the admin group on macOS corresponds to users that 
> are allowed to install system-wide software so it allows all admins on the 
> machine to install packages which is the expected way on macOS.
> 
> I think this choice is unfortunate as it contrasts with existing behavior on 
> other platforms where one needs to explicitly request admin privileges by 
> either using sudo or starting R as an admin.
> On macOS, packages just go into the system lib “silently” because of the 
> write permissions granted via the admin group.
> See also my comments further down for more details on this.
> 

They don't go there "silently" as in unnoticed - they go there if you instruct 
R to do so. That's why there is an explicit choice in the Installer. Otherwise 
regular R rules apply.


> Also the versioning of the R framework as x.y is also deliberate - upgrading 
> R to a new patch version does *not* require re-installation of packages, they 
> work by design so in fact the system location is the safest way to do that. 
> Also note that packages are never removed by the installer.
> 
> Thanks, I am aware that a patch update does not require a reinstallation as 
> the packages are functional across minor versions.
> 
> I checked again and was indeed wrong, patch updates from the CRAN installer 
> do not remove additional custom packages in the system lib.
> I was confused by some custom approaches of mine which cause this behavior - 
> sorry for this!
> 
> So out of the items listed in "The problem" they are all not true with the 
> exception of the comparison with the other platforms, but even that 
> difference is very subtle as it only affects the default on the first 
> installation and not regular use (and I'm, not even sure it that is true 
> since admin users can still install in the system location on other 
> platforms).
> 
> On Linux you would need to do explicitly invoke sudo R to allow writing into 
> the system lib.
> The issue on macOS is that a regular start of R allows system lib write 
> permissions.
> In my current view I think a similar behavior as on Linux would be great, 
> i.e. to explicitly having to request admin privileges for this task.
> 

It only does so for admin users. Unlike "managed" unix systems, on macOS you 
have essentially two situations:

On a "personal" machine (like laptop) the user is the main user and admin. 
Therefore it makes a lot more sense for the user to use a single location for 
managing packages which is at the system level. This also allows easy R 
upgrades. In addition, locations in user home raise a lot of issues (see the 
various discussion where this bites people on Windows) due to interactions with 
software that does mirroring, backups etc.. Hence this approach "just works" as 
one would expect on a Mac. If the user wishes to use his/her private library, 
it is trivial - just click on "At User Level" and from then on all packages are 
managed user's local library just like on any other platform.

On a "managed" Mac the user is not an admin and therefore the behavior makes no 
difference. The status quo just makes it easier for admins to manage the shared 
library, but in reality this doesn't matter as one would assume the admins know 
what they are doing.


> I don’t understand the part “as it only affects the default on the first 
> installation and not regular use” of your reply - could you clarify this?
> Unless a user creates a user lib manually, packages will always go into the 
> system lib - not only on first use - but I might be misunderstanding your 
> comment here.
> 
> I would argue that the current setup tends to be a lot safer than the 
> alternatives, because it allows commonly used packages to be installed at the 
> system level and private packages to be installed at user level. This is also 
> the design typically used on shared machines, where you separate local 
> packages from user packages where local ones are installed by administrators 
> - so exactly the same setup. Moreover R upgrades are a lot cleaner, since you 
> can easily upgrade all system packages at once so you don't have to worry 
> about individual users having stale packages - the biggest problem for admins.
> 
> Yes and no.
> Sometimes system admins want to install certain packages globally - however, 
> I never do so for the following reason:
> Often this will lead to multiple package installations, i.e. one in the 
> syslib and one in the user lib (if the user installs the package again for 
> some reason which quite often happens).
> Often these duplicated packages will have different versions and users are 
> confused which one is actually loaded (the user lib one is as it is first in 
> the path).
> 
> Aside from this practical p

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

[Simon Urbanek]

Ok, apparently it may not be trivial to add the results and then move them 
again in two days because of the release changes on CRAN, so for those 
interested I have created a quick and dirty web front-end that allows you to 
dump all results for a given package from the macOS staging server. The URL is 
"https://stats2021.nz/macos-results?" so, for example, if you want the 
result for the package "uuid" you would use 
https://stats2021.nz/macos-results?uuid - this will likely be only temporary 
until the release since it's truly just a file dump without the formatting that 
CRAN uses.

Cheers,
Simon



> On Apr 20, 2022, at 2:29 PM, Simon Urbanek  
> wrote:
> 
> Jeroen,
> 
> as far as I can tell MacBuilder currently works - I see no problems. If you 
> have a question about a specific submission, send me the ID and I can have a 
> look.
> 
> As for CRAN checks - good point, there are available in the reports area, but 
> it seems that the flavors are not registered on the CRAN website. CCing CRAN 
> - can we, please, have the R-devel-macos checks listed?
> 
> Thanks,
> Simon
> 
> 
> 
>> On Apr 20, 2022, at 4:32 AM, Jeroen Ooms  wrote:
>> 
>> On Sun, Apr 17, 2022 at 4:38 AM Simon Urbanek
>>  wrote:
>>> 
>>> Dear Mac users,
>>> 
>>> we are nearing the release of R 4.2.0 (on Friday) which introduces some 
>>> significant changes not only in R itself, but also in some Mac-specific 
>>> build settings. Please help us by testing R pre-releases *before* the 
>>> release such that any obvious issues can be caught prior to the release. 
>>> The nightly pre-releases both for Intel Macs (high-sierra build) as well as 
>>> M1 Macs (big-sur build) are available at
>>> 
>>> https://mac.r-project.org/
>>> 
>>> The nightly Installer packages (R-4.2-branch.pkg) are created just like the 
>>> release and signed, but not always Apple notarized, so to install hold the 
>>>  key when opening and pick "Open" in the dialog box if prompted.
>>> 
>>> Package binaries for R 4.2.0 are also now available on CRAN, please report 
>>> any issues to me. The Mac Builder has also been updated to use latest 
>>> libraries and it now defaults to the R pre-release.
>> 
>> Is the m1 macbuilder (https://mac.r-project.org/macbuilder/submit.html
>> ) still supported? I tried uploading a package, but it still says
>> "Please check back later" after an hour, and I did not receive any
>> email, and the auto-refresh seems broken (the embedded jquery url is
>> 404). Afaict, the package check logs for mac-4.2 are also still not
>> available on cran, so this makes it quite difficult for package
>> authors to help with timely reporting the Mac-specific build issues
>> that you mention.
>> 
> 

___
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.2.0 pre-releases

[Simon Urbanek]

Adrian,

thanks for testing!

1) Re package installation:

The regular R rules apply here: If the user-specific library (see 
Sys.getenv("R_LIBS_USER")) exists at the time of the start of R, then R will 
prepend it to the search path (see ?.libPaths). The default in 
install.packages() is to pick the first entry of .libPaths() (see 
?install.packages) so packages will be installed into the user library if it is 
present and at the system location otherwise. Again, this is standard R 
behavior on all platforms.

The Package Installer in the R.app GUI gives you full control - you are 
explicitly setting the location where you want to install the package. However, 
no effort is made to check that the target location is on you current search 
path. I can see that this may be confusing in case where you don't have a user 
library (and thus it is not on .libPaths()) and then install packages "At User 
Level" which creates the user library, but packages installed there will be 
only found on the next start of R since the library did not exist when R was 
constructing the .libPaths(). I can modify the GUI to check and make sure the 
user library is added to the path after it has been created.

2) tab-complete: can you elaborate on that one? I cannot reporduce the error, 
so please send more details instructions how to reproduce.

Thanks,
Simon



> On Apr 18, 2022, at 5:50 AM, Adrian Dușa  wrote:
> 
> Hello Simon,
> 
> A couple of things, here.
> From a terminal, using R CMD INSTALL, as well as using install.packages() 
> from within R, packages get installed into the default .libPaths() location:
> /Library/Frameworks/R.framework/Versions/4.2/Resources/library/
> 
> However, using the RGui menu Packages & Data / Package Installer, packages 
> are installed in the R_LIBS_USER:
> /Users/dusadrian/Library/R/x86_64/4.2/library
> 
> Since .libPaths() does not know this location, packages installed this way 
> are not found.
> 
> Also, most likely unrelated to R 4.2 but to some unicode problems on 
> Monterey, when using double-tab autocomplete in the RGui
> (R for macOS GUI 1.78-devel High Sierra build 8067), I get an additional red 
> message:
> IsMenuKeyEvent: found no unichar data in event; retranslated without deadkeys 
> to produce ''
> 
> If this could somehow be captured and silenced by the GUI, it would be 
> perfect. Otherwise, any hint on what should be done would be greatly 
> appreciated.
> 
> I hope this helps,
> Adrian
> 
> On Sun, 17 Apr 2022 at 05:38, Simon Urbanek  
> wrote:
> Dear Mac users,
> 
> we are nearing the release of R 4.2.0 (on Friday) which introduces some 
> significant changes not only in R itself, but also in some Mac-specific build 
> settings. Please help us by testing R pre-releases *before* the release such 
> that any obvious issues can be caught prior to the release. The nightly 
> pre-releases both for Intel Macs (high-sierra build) as well as M1 Macs 
> (big-sur build) are available at
> 
> https://mac.r-project.org/
> 
> The nightly Installer packages (R-4.2-branch.pkg) are created just like the 
> release and signed, but not always Apple notarized, so to install hold the 
>  key when opening and pick "Open" in the dialog box if prompted.
> 
> Package binaries for R 4.2.0 are also now available on CRAN, please report 
> any issues to me. The Mac Builder has also been updated to use latest 
> libraries and it now defaults to the R pre-release.
> 
> Thanks,
> Simon
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> 
> -- 
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr. 90-92
> 050663 Bucharest sector 5
> Romania
> https://adriandusa.eu

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

Re: [R-SIG-Mac] Trouble compiling packages in R

[Simon Urbanek]

Jarrett,

you seem to have some ancient compilers in /usr/local. In order to avoid issue, 
I would strongly recommend removing the content of /usr/local (or putting it 
aside - see below). You don't need any extra tools on Big Sur, only standard 
Apple Xcode or CLT are needed (see R documentation).

Also please note that your github repository 
(https://github.com/jphill01/HACSim.R) has binary files checked in which is a 
bad idea, so you may want to fix that problem first.

Cheers,
Simon


to remove all files from /usr/local:
sudo rm -rf /usr/local/*

to put them aside:
sudo -i
cd /usr/local
mkdir .bak
mv * .bak/

to restore  if needed:
sudo -i
cd /usr/local
mv .bak/* .
rmdir .bak





> On Jan 26, 2022, at 5:43 PM, Jarrett Phillips  
> wrote:
> 
> Hi All,
> I am new to the list and am running RStudio Version 1.4.1717 on macOS Big
> Sur 11.4 and have R 4.1.1 installed.
> 
> I just re-installed Xcode as well as Command Line Tools via instructions at
> https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/
> 
> I am attempting to build my package using devtools::build I have verified
> that both Rcpp and RcppArmadillo are working properly.
> 
> However, when I build, I get the following error message
> 
> Error: package or namespace load failed for ‘HACSim’ in dyn.load(file,
> DLLpath = DLLpath, ...):
>unable to load shared object
> '/private/var/folders/wv/4_z4h7ns57g7qvd600qgd__wgn/T/RtmpGe2Cqt/Rinst118e1e9f13a0/00LOCK-HACSim/00new/HACSim/libs/HACSim.so':
> 
> dlopen(/private/var/folders/wv/4_z4h7ns57g7qvd600qgd__wgn/T/RtmpGe2Cqt/Rinst118e1e9f13a0/00LOCK-HACSim/00new/HACSim/libs/HACSim.so,
> 6): Symbol not found: ___addtf3
> Referenced from: /usr/local/lib/libquadmath.0.dylib
> Expected in: /usr/local/lib/libgcc_s_x86_64.1.dylib
>in /usr/local/lib/libquadmath.0.dylib
>   Error: loading failed
>   Execution halted
>   ERROR: loading failed
> ─  removing
> ‘/private/var/folders/wv/4_z4h7ns57g7qvd600qgd__wgn/T/RtmpGe2Cqt/Rinst118e1e9f13a0/HACSim’
> ---
>   ERROR: package installation failed
> Error in (function (command = NULL, args = character(), error_on_status =
> TRUE,  :
>  System command 'R' failed, exit status: 1, stdout + stderr (last 10
> lines):
> E>
> dlopen(/private/var/folders/wv/4_z4h7ns57g7qvd600qgd__wgn/T/RtmpGe2Cqt/Rinst118e1e9f13a0/00LOCK-HACSim/00new/HACSim/libs/HACSim.so,
> 6): Symbol not found: ___addtf3
> E>   Referenced from: /usr/local/lib/libquadmath.0.dylib
> E>   Expected in: /usr/local/lib/libgcc_s_x86_64.1.dylib
> E>  in /usr/local/lib/libquadmath.0.dylib
> E> Error: loading failed
> E> Execution halted
> E> ERROR: loading failed
> E> * removing
> ‘/private/var/folders/wv/4_z4h7ns57g7qvd600qgd__wgn/T/RtmpGe2Cqt/Rinst118e1e9f13a0/HACSim’
> E>   ---
> E> ERROR: package installation failed
> Type .Last.error.trace to see where the error occurred
> 
> Here is the traceback:
> 
> Stack trace:
> 
> 1. devtools:::build("HACSim_OO")
> 2. pkgbuild::build(path = pkg, dest_path = path, binary = binary,  ...
> 3. withr::with_temp_libpaths(rcmd_build_tools(options$cmd, c(options$path,
> ...
> 4. base:::force(code)
> 5. pkgbuild:::rcmd_build_tools(options$cmd, c(options$path, options$args),
> ...
> 6. pkgbuild:::with_build_tools(callr::rcmd_safe(..., env = env,  ...
> 7. callr::rcmd_safe(..., env = env, spinner = FALSE, show = FALSE,  ...
> 8. callr:::run_r(options)
> 9. base:::with(options, with_envvar(env, do.call(processx::run,  ...
> 10. base:::with.default(options, with_envvar(env, do.call(processx::run,
> ...
> 11. base:::eval(substitute(expr), data, enclos = parent.frame())
> 12. base:::eval(substitute(expr), data, enclos = parent.frame())
> 13. callr:::with_envvar(env, do.call(processx::run, c(list(bin, args =
> real_c ...
> 14. base:::force(code)
> 15. base:::do.call(processx::run, c(list(bin, args = real_cmdargs,  ...
> 16. (function (command = NULL, args = character(), error_on_status = TRUE,
> ...
> 17. throw(new_process_error(res, call = sys.call(), echo = echo,  ...
> 
> x System command 'R' failed, exit status: 1, stdout + stderr (last 10
> lines):
> E>
> dlopen(/private/var/folders/wv/4_z4h7ns57g7qvd600qgd__wgn/T/RtmpGe2Cqt/Rinst118e1e9f13a0/00LOCK-HACSim/00new/HACSim/libs/HACSim.so,
> 6): Symbol not found: ___addtf3
> E>   Referenced from: /usr/local/lib/libquadmath.0.dylib
> E>   Expected in: /usr/local/lib/libgcc_s_x86_64.1.dylib
> E>  in /usr/local/lib/libquadmath.0.dylib
> E> Error: loading failed
> E> Execution halted
> E> ERROR: loading failed
> E> * removing
> ‘/private/var/folders/wv/4_z4h7ns57g7qvd600qgd__wgn/T/RtmpGe2Cqt/Rinst118e1e9f13a0/HACSim’
> E>   ---
> E> ERROR: package installation failed
> 
> 
> Any ideas?
> 
> Any assistance is warmly welcomed and greatly appreciated.
> 
> Cheers,
> 
> Jarrett
> 
>   [[alternative HTML version deleted]]
> 
> _

Re: [R-SIG-Mac] Mac Builder offline

[Simon Urbanek]

The network equipment has been replaced and the service is back online. Let me 
know if you encounter any issues.

Cheers,
Simon


> On Jan 14, 2022, at 8:34 PM, Simon Urbanek  
> wrote:
> 
> The hardware connecting the Mac Builder network has died so the service is 
> currently offline. Due to complicated reasons the service likely cannot be 
> restored before Monday. I apologize for any inconvenience this may cause.
> 
> Cheers,
> Simon

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

[R-SIG-Mac] Mac Builder offline

[Simon Urbanek]

The hardware connecting the Mac Builder network has died so the service is 
currently offline. Due to complicated reasons the service likely cannot be 
restored before Monday. I apologize for any inconvenience this may cause.

Cheers,
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] Libre SSL bug on MacOS Monterey => error in download.file()

[Simon Urbanek]

> On Jan 13, 2022, at 12:47 AM, Jeroen Ooms  wrote:
> 
> On Tue, Jan 11, 2022 at 10:12 PM Simon Urbanek
>  wrote:
>> 
>> Petře,
>> 
>> thanks, for the detailed analysis. It is rather curious that the issue 
>> appears only on _newer_ systems - we are more used to issues due to older CA 
>> chains and similar. It looks like an Apple bug on specific systems, so 
>> hopefully it will be fixed eventually. In general I was trying to avoid 
>> having to supply our own SSL library since that opens a whole can of worms - 
>> on one hand due the dependency issues (which libraries get compiled against 
>> what) and on the other hand we become responsible for security updates.
>> 
>> Thanks to Jeroen for the work-around (CURL_SSL_BACKEND=SecureTransport), 
>> using the native API is certainly preferred, there have been several issues 
>> with both OpenSSL and LibreSSL before. It seems that Apple has been 
>> flip-flopping with libcurl a lot - on El Capitan it was shipped with 
>> SecureTransport, on High-Sierra with LibreSSL, on Catalina and higher with 
>> both, but Libre the default.
>> 
>> I am somewhat less apprehensive to use static libcurl for R than SSL 
>> libraries as the fallout is a bit smaller. As a trial I have added static 
>> curl[2] which is close to the Apple build minus MultiSSL to big-sur nightly 
>> builds of R[3] and as expected that solves the problem. It may not be 
>> entirely unproblematic for package space, because packages often forget to 
>> prepend  --static when using static builds of libraries, and so do other 
>> dependencies that may use curl, but I'll see what comes out of it.
> 
> I would much recommend to stick with the apple version of libcurl; perhaps 
> override the default ssl-backend if you like. There is some example code to 
> do this in the curl package that you could adapt for base r: 
> https://github.com/jeroen/curl/blob/master/src/ssl.c
> 
> The benefit of dynamically linking to apple's libcurl is that we 
> automatically get a version of libcurl+deps+certs that is tuned and 
> maintained for that version of macos, including future ones. If you ship a 
> version of base-R with a static libcurl now, that version of R may not work 
> anymore a few years from now or on a future version of macos, when things 
> have moved on (for example, when servers start to require TLS1.3).
> 


Yes, but if you are using an old version of R on a new system, you have a lot 
of other worries - you can't expect new technologies to work with old software. 
CURL itself has fewer evolution issues than SSL libraries. As I said, I am a 
big proponent of re-using system libraries as much as possible, but, for 
example, High Sierra doesn't ship with ST back-end support, so using a static 
version that does is better there as Apple doesn't not maintain the curl CAs 
but it does the system ones so it's arguably better. The current issue is quite 
curious since breaking on the latest system is quite unusual, just preferring 
ST works only because it is the latest system that breaks and it has the ST 
option.

As Brian pointed out static curl has its own issues since its pkg-config flags 
are broken - that's why I have not activated the add-on recipes by default, I 
have seen those issues before.

For R itself there are thee options:

a) add CURL_SSL_BACKEND=${CURL_SSL_BACKEND-'SecureTransport'} to 
$R_HOME/etc/Renviron of the distribution

b) add something like your 
https://github.com/r-devel/r-svn/pull/75/commits/79b22b461e527e8a46de84c145e8e5fb59e75d14
 to R

c) build against static libcurl


The big advantage of the first one is that it applies to all processes, so even 
command line curl will then work and so will all packages.

The drawback of the second one is that it only applies the R itself. The third 
one could be done both for R and packages, but causes headaches resp. requires 
slight patching of libcurl.pc. The advantage is that it can bring more recent 
curl to all older systems.

I don't have a strong opinion. I am not thrilled with option b) because that is 
a hack just to react to something which is never a good idea from maintenance 
point of view (we would require all curl-based code to use it). So I think a) 
and c) are more palatable with a) having the benefit of handling non-R cases. A 
slight benefit of c) is that some dependencies require more recent curl version 
than provided by older systems, so that would cover it at the cost of 
maintaining the curl binaries. Finally, the real benefit of c) is that if Apple 
screws things up even more we don't care - we may not be at that point yet, 
though.

Cheers,
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] Libre SSL bug on MacOS Monterey => error in download.file()

[Simon Urbanek]

Petře,

thanks, for the detailed analysis. It is rather curious that the issue appears 
only on _newer_ systems - we are more used to issues due to older CA chains and 
similar. It looks like an Apple bug on specific systems, so hopefully it will 
be fixed eventually. In general I was trying to avoid having to supply our own 
SSL library since that opens a whole can of worms - on one hand due the 
dependency issues (which libraries get compiled against what) and on the other 
hand we become responsible for security updates.

Thanks to Jeroen for the work-around (CURL_SSL_BACKEND=SecureTransport), using 
the native API is certainly preferred, there have been several issues with both 
OpenSSL and LibreSSL before. It seems that Apple has been flip-flopping with 
libcurl a lot - on El Capitan it was shipped with SecureTransport, on 
High-Sierra with LibreSSL, on Catalina and higher with both, but Libre the 
default.

I am somewhat less apprehensive to use static libcurl for R than SSL libraries 
as the fallout is a bit smaller. As a trial I have added static curl[2] which 
is close to the Apple build minus MultiSSL to big-sur nightly builds of R[3] 
and as expected that solves the problem. It may not be entirely unproblematic 
for package space, because packages often forget to prepend  --static when 
using static builds of libraries, and so do other dependencies that may use 
curl, but I'll see what comes out of it.

Cheers,
Šimon

[1] - https://github.com/R-macos/recipes
[2] - https://github.com/R-macos/recipes/blob/add-ons/recipes/curl
[3] - https://mac.r-project.org/



> On 10/01/2022, at 11:22 PM, Petr Bouchal  wrote:
> 
> Dear all,
> 
> In brief: on Monterey, R cannot reach certain web domains due to a bug in 
> Libre SSL - and perhaps not relying on system curl/openssl in R would be a 
> systematic solution to this and símilar issues.
> 
> Specifically: on MacOS Monterey 12.1 using R 4.1.2, download.file() and other 
> functions that rely on system-provided curl/openssl/Libre SSL (including in 
> the curl package) have been failing on specific domains. 
> 
> So running 
> 
> download.file(“https://www.czso.cz/”, tempfile()) 
> 
> returns: 
> 
> status was ‘SSL connect error’
> 
> the underlying error being
> 
> error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length.
> 
> This is caused by the Libre SSL bundled in MacOS Monterey and also affects 
> several other domains, most notably https://libzip.org.
> 
> It is clearly an OS bug but infortunately also a situation where it affects R 
> users because of how R relates to system libraries and is very difficult to 
> work around.
> 
> It has manifested on CRAN (causing a package archival) and Github outside of 
> R, so is not caused by a specific machine. It can be replicated on both M1 
> and Intel and also occurs when using curl in the system command line. 
> 
> The czso.cz domain is the Czech Statistical Office, which makes it quite 
> important for a number of users, also of a package I maintain (czso) which 
> relies on accessing this domain. I have reported this to the server admin but 
> since the problem is in the OS, I do not expect them to be able to help. I am 
> not an expert in web security so cannot tell if there is anything in the 
> certificates which could be causing this. In browsers, no such issue occurs 
> and the server is configured correctly as per ssllabs.com testing. I have 
> also reported to Apple but it is unclear whether they will fix this given the 
> rare nature of the issue.
> 
> It is difficult to work around even on individual machines as replacing the 
> system curl/openssl requires steps beyond what a most users are comfortable 
> with (or should be doing to begin with). Using HTTP instead of HTTPS does not 
> work, nor does using curl —insecure and equivalents.
> 
> This brings back the question of whether R on MacOS should include its own 
> openssl instead of relying on the system-provided library. This has been 
> discussed on the r-devel list: 
> https://stat.ethz.ch/pipermail/r-devel/2020-June/079657.html.
> 
> Apple also recommends against relying on shared openssl, if I understand this 
> correctly: https://developer.apple.com/forums/thread/89051. Given Apple’s 
> approach to openssl/Libre SSL in MacOS (the bundled Libre SSL version is 3 
> years old), such hard-to-handle issues are likely to reappear over time. (I 
> don’t have in-depth knowledge of how R is compiled, so apologies for any 
> inaccuracies; hopefully it is clear what I mean.)
> 
> I’d be grateful for any thoughts on how this might be handled in the specific 
> case and perhaps generally.
> 
> Kind regards
> Petr Bouchal
> 
> ___
> 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] Compiling Cairo package

[Simon Urbanek]

Erich,

can you, please, send me the full output and the exact setup you used? I 
suspect you may be using XQuartz 2.8.0 or higher which has broken pkg-config 
files - latest XQuartz requires a patch to make any compilation against it work 
(see https://github.com/R-macos/recipes/blob/master/other/tcltk/pkgconfig.patch 
for what we do to compile Tk).

>From what I can see the only line that has actually any effect at all is

Sys.setenv(C_INCLUDE_PATH="/opt/X11/include")

so all the others are likely not needed, but I'm not sure of your setup so 
can't test.

Cheers,
Simon



> On Dec 27, 2021, at 4:00 AM, Erich Neuwirth  
> wrote:
> 
> Duncan’s suggestion did not work
> So I tried
> 
> Sys.setenv(LD_LIBRARY_PATH="/opt/X11:/opt/X11/lib")
> system("export LD_LIBRARY_PATH")
> Sys.setenv(C_INCLUDE_PATH="/opt/X11/include")
> system("export C_INCLUDE_PATH")
> Sys.getenv()
> 
> and then simply doing
> 
> install.packages(“Cairo”)
> worked.
> 
> 
>> On 26.12.2021, at 12:36, Duncan Murdoch  wrote:
>> 
>> On 26/12/2021 6:04 a.m., Erich Neuwirth wrote:
>>> I am trying to compile Cairo.
>>> I get the following error
>>> xlib-backend.c:34:10: fatal error: 'X11/Intrinsic.h' file not found
>>> #include   /*->Xlib.h  Xutil.h Xresource.h .. */
>>> I have X11/Intrinsic.h in /opt/X11/include
>>> I tried
>>> Sys.setenv(LD_LIBRARY_PATH="/opt/X11:/opt/X11/lib")
>>> Sys.getenv("LD_LIBRARY_PATH")
>>> system("export LD_LIBRARY_PATH”)
>>> and compiled again, but I get the same error.
>>> What do I need to do so Intrinsic.h is found by the compiler?
>> 
>> Usually the location of include files is set at configure time.  For R, I use
>> 
>> ../R-devel-src/configure --with-x --x-includes=/opt/X11/include 
>> --x-libraries=/opt/X11/lib
>> 
>> It's not clear to me whether Cairo is the R package or an external library, 
>> but if it's the R package, you might try
>> 
>> install.packages("Cairo", type = "source", configure.args = 
>> "--x-includes=/opt/X11/include --x-libraries=/opt/X11/lib")
>> 
>> Duncan Murdoch
>> 
>> ___
>> 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] .Machine differences between Intel and M1

[Simon Urbanek]

Matt,

yes, arm64 does not support long doubles. In C the long double type is 64-bit 
there so has the same precision as doubles (this is allowed by the standard).

Cheers,
Simon


> On Dec 22, 2021, at 9:21 AM, Matthew Heun via R-SIG-Mac 
>  wrote:
> 
> All:
> 
> I'm seeing some test failures on a new M1 Pro machine that I do not see on my 
> Intel machine.  I'm investigating whether the test failures are caused by 
> machine precision differences.  On my M1 Pro machine, differences of large 
> numbers are greater than a specified tolerance.  (On my Intel machine, 
> differences between the supposed same numbers are within tolerance.)
> 
> The output of .Machine shows some differences.  I have 2 questions below, 
> each identified by "".
> 
> (1) For sizeof.longdouble, I see the following:
> 
> Intel machine:
> 
>> $sizeof.longdouble
>> [1] 16
> 
> M1 Pro machine:
> 
>> $sizeof.longdouble
>> [1] 8
> 
> 
> 
> ?.Machine says:
> 
> sizeof.longdouble 
> the number of bytes in a C long double type. Will be zero if there is no such 
> type (or its use was disabled when R was built), otherwise possibly12 (most 
> 32-bit builds) or 16 (most 64-bit builds).
> 
> The M1 Pro uses a 64-bit architecture.  So this result is surprising to me.
> 
> Furthermore, 
> 
>>> capabilities("long.double")
>> long.double 
>>   TRUE 
> 
> So somebody thinks that long doubles are supported.
> 
>  Is the difference in sizeof.longdouble between the Intel and M1 
> architectures expected?
> 
> 
> (2) Also, my M1 Pro machine is missing additional fields (that the Intel 
> machine reports):
> 
>> $longdouble.eps
>> [1] 1.084202e-19
>> 
>> $longdouble.neg.eps
>> [1] 5.421011e-20
>> 
>> $longdouble.digits
>> [1] 64
>> 
>> $longdouble.rounding
>> [1] 5
>> 
>> $longdouble.guard
>> [1] 0
>> 
>> $longdouble.ulp.digits
>> [1] -63
>> 
>> $longdouble.neg.ulp.digits
>> [1] -64
>> 
>> $longdouble.exponent
>> [1] 15
>> 
>> $longdouble.min.exp
>> [1] -16382
>> 
>> $longdouble.max.exp
>> [1] 16384
> 
>  Is there a reason why the above entries are missing from the output of 
> .Machine on the M1 Pro machine?
> 
> 
> 
> My R installation is:  4.1.2 Patched (2021/12/16, r81394)
> 
> 
> 
> Any help will be appreciated.
> 
> 
> 
> Cheers,
> 
> Matt
> 
> ___
> 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] Missing qpdf

[Simon Urbanek]

Matt,

First option: try using the latest R from https://mac.R-project.org since the 
latest releases include qpdf in the distribution so there is no need to install 
it externally.

Second option: use R instead of RStudio since the latter is just a complicated 
way to call "R CMD check" so calling it directly should work.

Third option: ask RStudio support how to get it to work since that requires 
manipulation of (exported) PATH inside RStudio.

Cheers,
Simon


> On Dec 20, 2021, at 3:16 PM, Matthew Heun via R-SIG-Mac 
>  wrote:
> 
> All:
> 
> I'm hoping this list is the right place to post this question.  If not, feel 
> free to direct me elsewhere.  I also looked for a search option for this list 
> but couldn't find one.  Sorry!
> 
> I'm on a new M1 Pro MacBook Pro.  (Yay!)  I installed the arm64 version of R 
> and the latest version of RStudio.  I'm now setting up for package 
> development with RStudio.  When checking any of my packages in RStudio 
> (Build|Check Package), I see:
> 
> 
> checking data for ASCII and uncompressed saves ... OK
>   WARNING
>  ‘qpdf’ is needed for checks on size reduction of PDFs
> 
> 
> This warning does not appear on my Intel Mac.
> 
> 
> I attempted the following to try to eliminate this warning:
> 
> * Installed qpdf (from https://mac.r-project.org/libs-arm64/) into 
> /opt/R/arm64/bin. 
> 
> * As suggested at https://mac.r-project.org/libs-arm64/, I added 
> /opt/R/arm64/bin to PATH such that I see the following in the macOS Terminal 
> app:
> 
> mkh2@Mac91836 ~ % echo $PATH
> /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin:/Library/Apple/usr/bin:/opt/R/arm64/bin
> 
> and
> 
> mkh2@Mac91836 ~ % which qpdf
> /opt/R/arm64/bin/qpdf
> 
> 
> However, the problem persists.
> 
> 
> Is there something else I should be doing to eliminate this warning?
> 
> 
> Any suggestions will be welcome.
> 
> Thanks,
> 
> Matt
> 
> 
> P.S.  Many, many thanks to everyone who keeps R for Mac viable!  Your 
> contributions are incredibly valuable.
> ___
> 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] Reverse search not working in ARM binary of R-4.1.2 (or 4.1.0) from CRAN

[Simon Urbanek]

Ziv,

the released arm binaries use libedit from the system (supplied by Apple) which 
doesn't support reverse-search. The latest nightly binaries now include 
readline instead - see https://mac.R-project.org

Cheers,
Simon



> On Dec 10, 2021, at 6:13 AM, Ziv Wolkowicki  wrote:
> 
> Team,
> 
> I have an unusual issue I am only observing on specific binaries of R. I used 
> to have ARM build of R-4.1.0 from https://cran.r-project.org/bin/macosx/ 
> , and updated to R-4.1.2 running on 
> my M1 Mac. Hitting ‘Ctrl+R’ (reverse search of previously run commands) did 
> nothing on either version. It does not react in any way. Though it reacts to 
> Ctrl+C for example, so it is respond to some signals.
> 
> The unusual thing is, installing the ARM version for R-4.1.2 from homebrew, 
> and also the x86 Mac build of R-4.1.2 from 
> https://cran.r-project.org/bin/macosx/ 
> , Ctrl+R works just fine.
> 
> I still have both homebrew and pre-packaged versions installed on my system 
> if you need some additional information or experiments run.
> 
> Thanks,
> Ziv
> 
> 
>   [[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] unable to install from source packages needing compiled C code

[Simon Urbanek]

Kevin has a good point, there is likely a lot more messed up in your system. A 
good way to restore normality is something like:

sudo -i
cd /usr/local
mkdir .disable
mv * .disable/

Things should work then. You can undo the above with something like

sudo -i
cd /usr/local
mv .disable/* .
rmdir .disable

On older macOS versions it was so much easier since you could simple rename 
/usr/local but Apple doesn't want us to do such simple things anymore ...

Cheers,
Simon



> On Dec 3, 2021, at 12:32 PM, Kevin Ushey  wrote:
> 
> This may also make your life challenging:
> 
> /usr/local/include/sys/_types.h:33:10: fatal error: 'machine/_types.h' file
> not found
> #include 
> ^~
> 1 error generated.
> 
> You have some headers installed in /usr/local/include that are
> shadowing the default macOS toolchain's headers, and those appear to
> be incompatible with the system toolchain. You'll likely need to
> remove those as well.
> 
> To be complete, x86_64 builds of R usually have something like:
> 
> CPPFLAGS = -I/usr/local/include
> 
> within their Makeconf; if you've placed headers there that shadow the
> default system headers, they'll be used instead.
> 
> tl;dr: you probably need to do a couple things.
> 
> (1) Remove /usr/local/opt/llvm/bin from your PATH so llvm clang stops
> shadowing the system clang;
> (2) Remove the system headers in /usr/local/include that are masking
> your system header includes.
> 
> You could also probably force the use of system clang in R by setting
> CC = /usr/bin/clang and CXX = /usr/bin/clang++ in (say) ~/.R/Makevars,
> but I haven't tried that.
> 
> Best,
> Kevin
> 
> On Thu, Dec 2, 2021 at 1:29 PM Simon Urbanek
>  wrote:
>> 
>> 
>> Adrian,
>> 
>> 
>>> On Dec 3, 2021, at 10:12 AM, Adrian Dușa  wrote:
>>> 
>>> Thank you Simon,
>>> 
>>> I have the official Apple CLT, but not the full Xcode. If needed I can 
>>> install that as well, with a difference of about 10GB more space getting 
>>> used.
>>> This is what I get:
>>> 
>>> $ xcode-select -p
>>> /Library/Developer/CommandLineTools
>>> 
>>> $ xcrun --show-sdk-path
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
>>> 
>>> $ which clang
>>> /usr/local/opt/llvm/bin/clang
>>> 
>> 
>> 
>> ^^^-- this is your problem. You're not using Xcode so that's exactly what I 
>> said, you have a broken compiler. Remove /usr/local/opt and it should work.
>> 
>> Cheers,
>> 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

Re: [R-SIG-Mac] unable to install from source packages needing compiled C code

[Simon Urbanek]

Adrian,


> On Dec 3, 2021, at 10:12 AM, Adrian Dușa  wrote:
> 
> Thank you Simon,
> 
> I have the official Apple CLT, but not the full Xcode. If needed I can 
> install that as well, with a difference of about 10GB more space getting used.
> This is what I get:
> 
> $ xcode-select -p
> /Library/Developer/CommandLineTools
> 
> $ xcrun --show-sdk-path
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> 
> $ which clang
> /usr/local/opt/llvm/bin/clang
> 


^^^-- this is your problem. You're not using Xcode so that's exactly what I 
said, you have a broken compiler. Remove /usr/local/opt and it should work.

Cheers,
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] unable to install from source packages needing compiled C code

[Simon Urbanek]

Adrian,

please check your tools. The error looks like you may be mixing different 
compilers. So, first check that you are using Xcode tools (command line tools 
or Xcode itself doesn't matter) and not Homebrew or other non-Apple compilers 
as they need additional configuration. For example:

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

$ which clang
/usr/bin/clang

$ clang --version
Apple clang version 12.0.5 (clang-1205.0.22.11)
Target: arm64-apple-darwin20.6.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


If in doubt, you can always use
sudo xcode-select --install
to make sure you have the tools.

Second, make sure you don't have old overrides in ~/.R such as Makeconf or 
similar. Remove ~/.R if needed.

Finally, if you still have issues, please post the full output since you didn't 
give us any details whatsoever so we can only guess.

Cheers,
Simon



> On Dec 3, 2021, at 12:22 AM, Adrian Dușa  wrote:
> 
> Dear All,
> 
> I am not sure when this started, presumably after upgrading my OS to
> Monterey 12.0.1
> With packages needing compilation, under a Terminal I get this error:
> 
> /Library/Frameworks/R.framework/Resources/include/R.h:55:11: fatal error:
> 'stdlib.h' file not found
> # include  /* Not used by R itself, but widely assumed in
> packages */
>  ^~
> 1 error generated.
> 
> I've searched over the Internet, the most common problem is the absence of
> the Command Line Tools, but I do have those installed.
> 
> An old topic mentioned installing:
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.
> pkg
> 
> However the /Library/Developer/CommandLineTools/ directory does not hold a
> "Packages" subdirectory.
> 
> Does anyone else have this problem?
> 
> Thanks very much in advance for any hint,
> Adrian
> 
>   [[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] [External] Rmpfr crashes on Mac

[Simon Urbanek]

reproduces more readily because RStudio is calling str() behind
>> the scenes (which is the cause of the crash in this case). So, a plain R
>> reproducible example:
>> library(Rmpfr)
>> x <- mpfr(-50.1, 200)
>> str(x)
>> and I see:
>>> str(x)
>> Class 'mpfr' [package "Rmpfr"] of length 1 and precision 200
>>  *** caught illegal operation ***
>> address 0x112833ed5, cause 'illegal opcode'
>> Traceback:
>>  1: .mpfr2str(x, digits, maybe.full = maybe.full, base = base)
>>  2: formatMpfr(object, digits = digits.d, drop0trailing = drop0trailing,
>>   ...)
>>  3: str.mpfr(x)
>>  4: str(x)
>> From lldb:
>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>> frame #0: 0x000107ec7ed5 Rmpfr.so`mpfr_get_str_aux + 165
>> Rmpfr.so`mpfr_get_str_aux:
>> ->  0x107ec7ed5 <+165>: adcxq  %rsi, %rcx
>> 0x107ec7edb <+171>: movq   %r10, %rdi
>> 0x107ec7ede <+174>: movq   %r8, %rsi
>> 0x107ec7ee1 <+177>: movq   %r10, %rbx
>> and relevant part of the backtrace:
>> (lldb) bt
>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>>   * frame #0: 0x000107ec7ed5 Rmpfr.so`mpfr_get_str_aux + 165
>> frame #1: 0x000107ec78da Rmpfr.so`mpfr_get_str + 2890
>> frame #2: 0x000107eb9c9e Rmpfr.so`mpfr2str(x=0x0001053ed768,
>> digits=, maybeFull=, base=) at
>> convert.c:608:2 [opt]
>> < ... >
>> If I understand correctly, 'adcx' was introduced with Broadwell CPUs (so,
>> October 2014) and so that could explain why I'm seeing this crash. It'd be
>> helpful if others could try to verify with newer / older macOS machines,
>> though.
>>> sessionInfo()
>> R version 4.1.2 (2021-11-01)
>> Platform: x86_64-apple-darwin17.0 (64-bit)
>> Running under: macOS Big Sur 10.16
>> Best,
>> Kevin
>> On Sun, Nov 28, 2021 at 6:22 PM Simon Urbanek 
>> wrote:
>>> Kevin,
>>> 
>>> that is a different story, yes, Rosetta2 is incomplete - the advice on M1
>>> is to use native R.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
>>>> On Nov 29, 2021, at 12:30 PM, Kevin Ushey  wrote:
>>>> 
>>>> I can reproduce something similar on my M1 macOS machine, when using the
>>>> x86_64 build of R. I see:
>>>> 
>>>>> x1 <- mpfr(-50, 200)
>>>> *** caught illegal operation ***
>>>> address 0x10c5f623b, cause 'illegal opcode'
>>>> 
>>>> This is with the binary of Rmpfr 0.8-7 as from CRAN, with R 4.1.2. Here's
>>>> what LLDB says:
>>>> 
>>>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>>>> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>>>>frame #0: 0x00010f69c23b Rmpfr.so`mpfr_set_d + 43
>>>> Rmpfr.so`mpfr_set_d:
>>>> ->  0x10f69c23b <+43>: vucomisd %xmm0, %xmm0
>>>>0x10f69c23f <+47>: jp 0x10f69c39a   ; <+394>
>>>>0x10f69c245 <+53>: vpxor  %xmm1, %xmm1, %xmm1
>>>>0x10f69c249 <+57>: vucomisd %xmm1, %xmm0
>>>> 
>>>> And the relevant part of the stack trace:
>>>> 
>>>> (lldb) bt
>>>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>>>> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>>>>  * frame #0: 0x00010f69c23b Rmpfr.so`mpfr_set_d + 43
>>>>frame #1: 0x00010f6809d3 Rmpfr.so`d2mpfr1_(x=-50,
>>>> i_prec=, rnd=MPFR_RNDN) at convert.c:129:5 [opt]
>>>>frame #2: 0x00010f680eb0 Rmpfr.so`d2mpfr1_list(x=,
>>>> prec=, rnd_mode=) at convert.c:186:29 [opt]
>>>> 
>>>> At least for my case, my guess is that the 'vucomisd' instruction isn't
>>>> available via Apple's Rosetta emulation. It's possible users with older
>>>> macOS machines not supporting AVX instructions could see this, as well?
>>>> 
>>>> Best,
>>>> Kevin
>>>> 
>>>> On Sun, Nov 28, 2021 at 9:54 AM Richard M. Heiberger 
>>> wrote:
>>>> 
>>>>> Works normally in R-4.1.2 with Rmpfr_0.8-7 on Macintosh
>>>>> aarch64-apple-darwin20
>>>>> I am running inside Emacs using

Re: [R-SIG-Mac] [External] Rmpfr crashes on Mac

[Simon Urbanek]

Kevin,

that is a different story, yes, Rosetta2 is incomplete - the advice on M1 is to 
use native R.

Cheers,
Simon


> On Nov 29, 2021, at 12:30 PM, Kevin Ushey  wrote:
> 
> I can reproduce something similar on my M1 macOS machine, when using the
> x86_64 build of R. I see:
> 
>> x1 <- mpfr(-50, 200)
> *** caught illegal operation ***
> address 0x10c5f623b, cause 'illegal opcode'
> 
> This is with the binary of Rmpfr 0.8-7 as from CRAN, with R 4.1.2. Here's
> what LLDB says:
> 
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>frame #0: 0x00010f69c23b Rmpfr.so`mpfr_set_d + 43
> Rmpfr.so`mpfr_set_d:
> ->  0x10f69c23b <+43>: vucomisd %xmm0, %xmm0
>0x10f69c23f <+47>: jp 0x10f69c39a   ; <+394>
>0x10f69c245 <+53>: vpxor  %xmm1, %xmm1, %xmm1
>0x10f69c249 <+57>: vucomisd %xmm1, %xmm0
> 
> And the relevant part of the stack trace:
> 
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
>  * frame #0: 0x00010f69c23b Rmpfr.so`mpfr_set_d + 43
>frame #1: 0x00010f6809d3 Rmpfr.so`d2mpfr1_(x=-50,
> i_prec=, rnd=MPFR_RNDN) at convert.c:129:5 [opt]
>frame #2: 0x00010f680eb0 Rmpfr.so`d2mpfr1_list(x=,
> prec=, rnd_mode=) at convert.c:186:29 [opt]
> 
> At least for my case, my guess is that the 'vucomisd' instruction isn't
> available via Apple's Rosetta emulation. It's possible users with older
> macOS machines not supporting AVX instructions could see this, as well?
> 
> Best,
> Kevin
> 
> On Sun, Nov 28, 2021 at 9:54 AM Richard M. Heiberger  wrote:
> 
>> Works normally in R-4.1.2 with Rmpfr_0.8-7 on Macintosh
>> aarch64-apple-darwin20
>> I am running inside Emacs using ESS
>> 
>>> packageVersion("Rmpfr")
>> [1] ‘0.8.7’
>>> library(Rmpfr)
>> Loading required package: gmp
>> 
>> Attaching package: ‘gmp’
>> 
>> The following objects are masked from ‘package:base’:
>> 
>>%*%, apply, crossprod, matrix, tcrossprod
>> 
>> C code of R package 'Rmpfr': GMP using 64 bits per limb
>> 
>> 
>> Attaching package: ‘Rmpfr’
>> 
>> The following object is masked from ‘package:gmp’:
>> 
>>outer
>> 
>> The following objects are masked from ‘package:stats’:
>> 
>>dbinom, dgamma, dnbinom, dnorm, dpois, dt, pnorm
>> 
>> The following objects are masked from ‘package:base’:
>> 
>>cbind, pmax, pmin, rbind
>> 
>>> x1 <- mpfr(-50, 200)
>>> x1
>> 1 'mpfr' number of precision  200   bits
>> [1] -50
>>> x2 <- mpfr(-50.1, 200)
>>> x2
>> 1 'mpfr' number of precision  200   bits
>> [1] -50.10142108547152020037174224853515625
>>> version
>>   _
>> platform   aarch64-apple-darwin20
>> arch   aarch64
>> os darwin20
>> system aarch64, darwin20
>> status
>> major  4
>> minor  1.2
>> year   2021
>> month  11
>> day01
>> svn rev81115
>> language   R
>> version.string R version 4.1.2 (2021-11-01)
>> nickname   Bird Hippie
>>> 
>> 
>>> On Nov 27, 2021, at 15:46, Dev Chakraborty  wrote:
>>> 
>>> I used package Rmpfr ca. 2017 and it worked fine. The latest version
>>> (0.8-7) causes R (running under RStudio) to crash. A simple example is:
>>> 
>>> library(Rmpfr)
>>> x1 <- mpfr(-50, 200)
>>> x2 <- mpfr(-50.1, 200)
>>> 
>>> Which gives the message:
>>> 
>>> R Session Aborted
>>> R encountered a fatal error
>>> The session was terminated
>>> Start New Session
>>> 
>>> I am using R version 4.1.1 on a Mac running MacOS 12.0.1. and an older
>> iMac
>>> running 10.15.7. The problem occurs with both machines.
>>> 
>>> When I install from the CRAN archive file  Rmpfr_0.6-1.tar.gz (the
>> version
>>> of the package around 2017, corresponding to the last time I used it) the
>>> problem goes away.
>>> 
>>>  [[alternative HTML version deleted]]
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> 
>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-sig-mac&data=04%7C01%7Crmh%40temple.edu%7C3aabc743f322409d6fa308d9b259a7bb%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637736920545174898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=pNPM8x8q1%2BQxq4QevSbfjlcO44vDVEyUvsRlfDBfgBo%3D&reserved=0
>> 
>> ___
>> 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
> 

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

Re: [R-SIG-Mac] [External] Rmpfr crashes on Mac

[Simon Urbanek]

Dev,

as a first step, please don't use RStudio - we have to establish if this is an 
R issue or not first (RStudio is not R). Second, if it still crashes, please 
provide
1) the crash report
2) the output od sesionInfo() in R and
3) the output of
system_profiler SPHardwareDataType SPSoftwareDataType
fron Terminal (or system("system_profiler SPHardwareDataType 
SPSoftwareDataType") in R).

Cheers,
Simon



> On Nov 29, 2021, at 9:36 AM, Dev Chakraborty  wrote:
> 
> I still get the crash. I tried to recreate your commands on my machine
> (macOS Monterey, Version 12.0.1). Here is a summary; further details are
> below.
> 
> 1. Installing from CRAN downloaded file Rmpfr_0.8-7.tar.gz failed, see
> further details.
> 2. Therefore I had to instal the binary file from CRAN, see further details.
> 3. Loaded library(Rmpfr), see further details
> 4. Ran the two commands at the RStudio console:
> x <- mpfr(-50, 2000)
> y <- mpfr(-50.1, 2000)
> This caused a crash.
> 5. Restarted my system and ran:
> 
> version
>   _
> platform   x86_64-apple-darwin17.0
> arch   x86_64
> os darwin17.0
> system x86_64, darwin17.0
> status
> major  4
> minor  1.1
> year   2021
> month  08
> day10
> svn rev80725
> language   R
> version.string R version 4.1.1 (2021-08-10)
> nickname   Kick Things
> 
> 6. Details of my machine (system report)
> Model Name: MacBook Pro
>  Model Identifier: MacBookPro11,5
>  Processor Name: Quad-Core Intel Core i7
>  Processor Speed: 2.5 GHz
>  Number of Processors: 1
>  Total Number of Cores: 4
>  L2 Cache (per Core): 256 KB
>  L3 Cache: 6 MB
>  Hyper-Threading Technology: Enabled
>  Memory: 16 GB
>  System Firmware Version: 428.40.10.0.0
>  OS Loader Version: 540.40.4~45
>  SMC Version (system): 2.30f2
>  Serial Number (system): C02PTX43G8WP
>  Hardware UUID: 85D23F6B-40E1-5D82-BF89-909EF7141116
>  Provisioning UDID: 85D23F6B-40E1-5D82-BF89-909EF7141116
> 
> 
> Other details
> 1.
> install.packages("~/Downloads/Rmpfr_0.8-7.tar.gz", repos = NULL, type =
> "source")
> * installing *source* package ‘Rmpfr’ ...
> ** package ‘Rmpfr’ successfully unpacked and MD5 sums checked
> ** using staged installation
> checking for gcc... clang -mmacosx-version-min=10.13
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether clang -mmacosx-version-min=10.13 accepts -g... yes
> checking for clang -mmacosx-version-min=10.13 option to accept ISO C89...
> none needed
> checking how to run the C preprocessor... clang -mmacosx-version-min=10.13
> -E
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for ANSI C header files... rm: conftest.dSYM: is a directory
> rm: conftest.dSYM: is a directory
> yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking mpfr.h usability... no
> checking mpfr.h presence... no
> checking for mpfr.h... no
> configure: error: Header file mpfr.h not found; maybe use
> --with-mpfr-include=INCLUDE_PATH
> ERROR: configuration failed for package ‘Rmpfr’
> * removing
> ‘/Library/Frameworks/R.framework/Versions/4.1/Resources/library/Rmpfr’
> Warning in install.packages :
>  installation of package ‘/Users/Dev/Downloads/Rmpfr_0.8-7.tar.gz’ had
> non-zero exit status
> 
> 2.
> install.packages("Rmpfr")
> trying URL 'https://cran.rstudio.com/bin/macosx/contrib/4.1/Rmpfr_0.8-7.tgz'
> Content type 'application/x-gzip' length 1556368 bytes (1.5 MB)
> ==
> downloaded 1.5 MB
> 
> 
> The downloaded binary packages are in
> /var/folders/d1/mx6dcbzx3v39r260458z2b20gn/T//Rtmpfbzg9i/downloaded_packages
>> 
> 
> 3.
> library(Rmpfr)
> Loading required package: gmp
> 
> Attaching package: ‘gmp’
> 
> The following objects are masked from ‘package:base’:
> 
>%*%, apply, crossprod, matrix, tcrossprod
> 
> C code of R package 'Rmpfr': GMP using 64 bits per limb
> 
> 
> Attaching package: ‘Rmpfr’
> 
> The following object is masked from ‘package:gmp’:
> 
>outer
> 
> The following objects are masked from ‘package:stats’:
> 
>dbinom, dgamma, dnbinom, dnorm, dpois, dt, pnorm
> 
> The following objects are masked from ‘package:base’:
> 
>cbind, pmax, pmin, rbind
> 
> 
> On Sun, Nov 28, 2021 at 12:53 PM Richard M. Heiberger 
> wrote:
> 
>> Works normally in R-4.1.2 with Rmpfr_0.8-7 on Macintosh
>> aarch64-apple-darwin20
>> I am running inside Emacs using ESS
>> 
>>> packageVersion("Rmpfr")
>> [1] ‘

Re: [R-SIG-Mac] NaN bug with arima() on Mac

[Simon Urbanek]

Nikolas,

what makes you think it is a bug? It is an optimization process, so the 
objective function is free to produce NaN for unsuitable parameters so it can 
steer the optimization away from such areas.

Cheers,
Simon


> On Nov 23, 2021, at 2:29 AM, Kuschnig, Nikolas  
> wrote:
> 
> Dear all,
> 
> There seems to be a small bug with `arima()` on Mac. For some very specific 
> data
> I get the following warning:
>   Warning message:
>   In log(s2) : NaNs produced
> This seems to stem from `.Call(C_ARIMA_Like, x, Z, 0L, FALSE)` in the 
> `armafn()`
> objective function. This warning does not occur on Linux or Windows systems or
> when using the `arima0()` function.
> Below is an example that I hope reproduces (please excuse the dependency, I 
> only
> encountered it with this data, partly due to my lack of a Mac). Note that the
> warning in question occurs during estimation, printing always induces a 
> warning.
> 
> 
> # install.packages("BVAR")
> library("BVAR")
> 
> x <- fred_qd[1:243, 
> c("GDPC1", "PCECC96", "GPDIC1", "HOANBS", "GDPCTPI", "FEDFUNDS")]
> x <- fred_transform(x, codes = c(4, 4, 4, 4, 4, 1))
> Y <- as.matrix(x)[6:nrow(x), ]
> 
> ar <- apply(Y, 2, arima, order = c(5, 0, 0)) # Warning only on Mac
> ar0 <- apply(Y, 2, arima0, order = c(5, 0, 0)) # No warning
> 
> 
> Does anyone have any more information on this? Thanks for the help!
> 
> Best,
> -- 
> Nikolas Kuschnig
> 
> ___
> 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] Nightly build segfaults

[Simon Urbanek]

Gábor,

sorry for the late reply. The issue is that arm64 binaries get signed no matter 
what (requirement by the kernel), but our post-install process changes the path 
entries (moving dependent libraries to $R_HOME/lib etc.) which invalidates the 
(anonymous) signatures. For released pkg that's no problem, because the 
packaging process re-signs everything with proper developer account signature 
so it works, but the tar balls were packed up "raw" without signing. I have now 
added an extra step where the whole framework is re-signed before taring-up - 
but to address your concern it's just signed, no entitlements are added.

Some additional background - there are following layers:

1) unsigned
2) signed anonymously
3) signed with identity
4) hardened run-time / entitlements
5) notarization

On Intel 1) is all you need to run. On arm64 2) is required else you get the 
Trap: 9 error. 

Entitlements are additional key/values attached to a binary at signing which 
are used by the OS to determine what the binary is allowed to do. They 
essentially declare what security the user can expect. Technically, they are 
voluntary, i.e. a binary without entitlements is essentially free to do 
anything (almost, some some system services are only available to processes 
which have entitlements so it does cut both ways).

Finally, notarization is a process by which Apple scans software for malicious 
code and other things they may not like. If a software passes their checks it 
is "notarized" which is essentially a stamp from Apple that is it ok. The way 
it works is that you send the full package (pkg) to Apple, they inspect it and 
record its hash in their database as "passed". Anyone can then check that 
package with Apple to see that it's ok. As a convenience they also provide a 
"stamp" that you can then attach to the package so it doesn't need online 
service to check with Apple - it's essentially an additional signature from 
Apple you tack on.

Anyway, for us most relevant is that Apple requires notarization in order to be 
able to install package using Apple Installer (.pkg) without any warnings. 
Notarization in turn requires hardened run-time - Apple simply won't notarize 
anything that is not using hardened run-time. So that's why we use hardened 
run-time + notarization for releases, but that puts restrictions on what we're 
allowed to do.

Homebrew is just wild-west - they are random binaries downloaded from the 
internet so they don't come with any guarantees whatsoever. They now must sign 
on arm64 simply because the kernel requires it, but ther eis no meaning to that.

I hope it helps - please let me know if today's binaries work. I still have 
some permission issues with R.app, but the framework should be ok.

Cheers,
Simon

PS: I am playing with the macOS virtualization https://github.com/s-u/macosvm 
and it seems to work perfectly - I was able to check the new build tar ball on 
a clean VM in less than a minute ;).



> On Nov 17, 2021, at 11:28 AM, Gábor Csárdi  wrote:
> 
> This is Monterey:
> ❯ uname -a
> Darwin Gabors-MacBook-Pro-3.local 21.1.0 Darwin Kernel Version 21.1.0:
> Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
> arm64
> 
> The R-devel build segfaults:
> 
> ❯ curl -O https://mac.r-project.org/monterey/R-devel/arm64/R-devel.tar.gz
> ❯ sudo tar xzf R-devel.tar.gz -C /
> ❯ R -q --vanilla
> zsh: killed R -q --vanilla
> 
> So does the R-4.1 build:
> 
> ❯ curl -O 
> https://mac.r-project.org/monterey/R-4.1-branch/arm64/R-4.1-branch.tar.gz
> ❯ sudo tar xzf R-4.1-branch.tar.gz -C /
> ❯ R -q --vanilla
> zsh: killed R -q --vanilla
> 
> The big-sur arm64 builds at
> https://mac.r-project.org/big-sur/R-devel/arm64/R-devel.tar.gz
> and https://mac.r-project.org/big-sur/R-4.1-branch/arm64/R-4.1-branch.tar.gz
> also do the same.
> 
> I know that another user has seen this as well, so chances are that it
> is not some issue on my machine. Can anyone reproduce this?
> 
> Gabor
> 
> ___
> 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] Uninstall R for clean install of R on a Mac

[Simon Urbanek]

Drag the R framework and R application to trash. They are under /Applications 
and /Library/Frameworks.

If you are more comfortable with the command line, using Terminal you can use

rm -rf /Library/Frameworks/R.framework
rm -rf /Applications/R.app

If you get any permission issues, prepend sudo before the command.

Cheers,
Simon



> On Nov 8, 2021, at 11:39 PM, Amarjit Chandhial via R-SIG-Mac 
>  wrote:
> 
> 
> Hi
> 
> 
> This is probably an email for Simon Urbanek.
> 
> I have been an R user on Windows for many years, however switched to 
> using R on my MacBook Pro 2012 running MacOS Mojave 10.14.6.
> 
> Please can you provide instructions on how to properly and completely 
> uninstall R (I am currently using R 4.1.1), so I may make a clean 
> install of R 4.1.2.
> 
> 
> thanks,
> Amarjit
> 
> 
>   [[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] ANSI escape weirdness on M1 (libedit issue?)

[Simon Urbanek]

Gabor,

as you can see the x86_64 readline is a very old build 5.2-14 - it is the last 
version released under GPL-2. Later versions are to my best knowledge 
license-incompatible since they are released under GPL-3 only and thus do not 
allow the use in GPL-2 software. The arm64 version currently relies on the 
system library which is libedit. If it is of interest I can check if readline 
5.2 can be built for arm64, but it predates the architecture by quite a few 
years ;).

Cheers,
Simon


> On Nov 4, 2021, at 7:12 AM, Gábor Csárdi  wrote:
> 
> On Wed, Nov 3, 2021 at 7:00 PM Prof Brian Ripley  
> wrote:
> [...]
>> AFAIK the reason for not distributing readline with binary distributions
>> of R is perceived licence restrictions.
> 
> So is the license different for x86_64? Because those builds come with 
> readline:
> ❯ R-4.1 -q -e 'extSoftVersion()[["readline"]]'
>> extSoftVersion()[["readline"]]
> [1] "5.2"
> 
> Whereas the arm64 build has:
> ❯ R-4.1-arm64 -q -e 'extSoftVersion()[["readline"]]'
>> extSoftVersion()[["readline"]]
> [1] "4.2 (EditLine wrapper)"
> 
> Gabor
> 
> ___
> 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