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

2022-11-08 Thread 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

2022-11-06 Thread 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)

2022-10-15 Thread 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

2022-10-06 Thread 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]

2022-06-08 Thread 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 

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

2022-06-06 Thread 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()' for some demos, 'help()' for on-line help, or
>>>>

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

2022-05-29 Thread 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

2022-04-24 Thread 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 

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

2022-04-20 Thread 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

2022-04-17 Thread 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

2022-01-25 Thread 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

2022-01-16 Thread 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

2022-01-13 Thread 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()

2022-01-12 Thread 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()

2022-01-11 Thread 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

2021-12-28 Thread 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

2021-12-21 Thread 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

2021-12-19 Thread 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

2021-12-09 Thread 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

2021-12-02 Thread 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

2021-12-02 Thread 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

2021-12-02 Thread 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

2021-11-29 Thread Simon Urbanek
lling 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 ESS
>>>>> 
>>>>>> packageVersion("Rmpfr")
>>>>> [1] ‘0.8.7’
>>>>>> library(Rmpfr)
>&g

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

2021-11-28 Thread 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-macdata=04%7C01%7Crmh%40temple.edu%7C3aabc743f322409d6fa308d9b259a7bb%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637736920545174898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=pNPM8x8q1%2BQxq4QevSbfjlcO44vDVEyUvsRlfDBfgBo%3Dreserved=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

2021-11-28 Thread 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

2021-11-22 Thread 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

2021-11-17 Thread 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

2021-11-08 Thread 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?)

2021-11-03 Thread 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


Re: [R-SIG-Mac] https://mac.r-project.org/benchmarks/

2021-10-31 Thread Simon Urbanek


Kieran,

the reference benchmarks have been calibrated against vecLib/Accelerate BLAS. 
If you use reference BLAS it can be a lot slower. You can switch between 
reference BLAS and vecLib in R CRAN releases simply by switching the 
libRblas.dylib symlink (in $R_HOME/lib), e.g.:

ls -l /Library/Frameworks/R.framework/Resources/lib/libRblas*dylib
-rwxrwxr-x  1 root admin  226288 Oct 31 14:41 
/Library/Frameworks/R.framework/Resources/lib/libRblas.0.dylib
lrwxr-xr-x  1 root.admin  21 Nov  1 09:56 
/Library/Frameworks/R.framework/Resources/lib/libRblas.dylib -> 
libRblas.vecLib.dylib
-rwxrwxr-x  1 root admin  154368 Oct 31 14:41 
/Library/Frameworks/R.framework/Resources/lib/libRblas.vecLib.dylib

(For recent R you'll need R 4.1.1 or higher)

Cheers,
Simon

PS: reminder to everyone, please test R 4.1.2 RC - now are the last few hours 
to report anything!



> On Nov 1, 2021, at 11:31 AM, Kieran Healy  wrote:
> 
> Hello, 
> 
> Just out of interest, I ran benchmark-25.R from Simon’s repo, as I have 
> access to an M1 Max. Are the *very* long times on cross-product, linear 
> regression, and Matrix functions a consequence of the BLAS version?
> 
> Kieran
> 
>> sessionInfo()
> R version 4.1.1 (2021-08-10)
> Platform: aarch64-apple-darwin20 (64-bit)
> Running under: macOS Monterey 12.0.1
> 
> Matrix products: default
> BLAS:   
> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libRlapack.dylib
> 
> 
>> source("R-benchmark-25.R")
> Loading required package: SuppDists
> 
> 
>   R Benchmark 2.5
>   ===
> Number of times each test is run__:  3
> 
>   I. Matrix calculation
>   -
> Creation, transp., deformation of a 2500x2500 matrix (sec):  0.2496656
> 2400x2400 normal distributed random matrix ^1000 (sec):  0.1050009
> Sorting of 7,000,000 random values__ (sec):  0.5946673
> 2800x2800 cross-product matrix (b = a' * a)_ (sec):  13.30167
> Linear regr. over a 3000x3000 matrix (c = a \ b')___ (sec):  6.270334
>  
> Trimmed geom. mean (2 extremes eliminated):  0.976431082297569
> 
>   II. Matrix functions
>   
> FFT over 2,400,000 random values (sec):  
> 0.07266631
> Eigenvalues of a 640x640 random matrix__ (sec):  0.4256672
> Determinant of a 2500x2500 random matrix (sec):  1.738333
> Cholesky decomposition of a 3000x3000 matrix (sec):  5.17
> Inverse of a 1600x1600 random matrix (sec):  1.430996
>  
>Trimmed geom. mean (2 extremes eliminated):  1.01925013610031
> 
>   III. Programmation
>   --
> 3,500,000 Fibonacci numbers calculation (vector calc)(sec):  
> 0.09500273
> Creation of a 3000x3000 Hilbert matrix (matrix calc) (sec):  0.1153335
> Grand common divisors of 400,000 pairs (recursion)__ (sec):  
> 0.07999841
> Creation of a 500x500 Toeplitz matrix (loops)___ (sec):  
> 0.01733593
> Escoufier's method on a 45x45 matrix (mixed) (sec):  0.1529963
>  
>Trimmed geom. mean (2 extremes eliminated):  0.0957023962714685
> 
> 
> Total time for all 15 tests_ (sec):  29.823
> Overall mean (sum of I, II and III trimmed means/3)_ (sec):  0.45668322781674
>  --- End of test ---
> 
> Warning messages:
> 1: In remove("a", "b") : object 'a' not found
> 2: In remove("a", "b") : object 'b' not found
> 
>> On Oct 31, 2021, at 5:11 PM, Simon Urbanek  
>> wrote:
>> 
>> 
>> Tim,
>> 
>> that is a great idea, those test are really old. Just for the fun of it I 
>> have run the tests on my old iMac, but with R 4.1.2 and they still work.
>> It's nice to see the huge speed improvements in loops and similar (see below 
>> - recall the original tests were scaled to be around 1).
>> 
>> I have added the page to the repo
>> https://github.com/R-macos/R-mac-dev
>> so I'd be happy to review PRs, but I'll probably want to re-do it first so 
>> it is better organized for comparisons as we have to also accommodate M1 etc.
>> 
>> Cheers,
>> Simon
>> 
>> ---
>> iMac14,2 3.2Ghz i5, macOS 10.4.6, R 4.1.2 vecib/Accelerate BLAS

Re: [R-SIG-Mac] https://mac.r-project.org/benchmarks/

2021-10-31 Thread Simon Urbanek


Tim,

that is a great idea, those test are really old. Just for the fun of it I have 
run the tests on my old iMac, but with R 4.1.2 and they still work.
It's nice to see the huge speed improvements in loops and similar (see below - 
recall the original tests were scaled to be around 1).

I have added the page to the repo
https://github.com/R-macos/R-mac-dev
so I'd be happy to review PRs, but I'll probably want to re-do it first so it 
is better organized for comparisons as we have to also accommodate M1 etc.

Cheers,
Simon

---
iMac14,2 3.2Ghz i5, macOS 10.4.6, R 4.1.2 vecib/Accelerate BLAS


   R Benchmark 2.5
   ===
Number of times each test is run__:  3

   I. Matrix calculation
   -
Creation, transp., deformation of a 2500x2500 matrix (sec):  0.8296667 
2400x2400 normal distributed random matrix ^1000 (sec):  0.1553334 
Sorting of 7,000,000 random values__ (sec):  0.6383334 
2800x2800 cross-product matrix (b = a' * a)_ (sec):  0.2420001 
Linear regr. over a 3000x3000 matrix (c = a \ b')___ (sec):  0.170 
  
 Trimmed geom. mean (2 extremes eliminated):  0.29781941072597 

   II. Matrix functions
   
FFT over 2,400,000 random values (sec):  0.331 
Eigenvalues of a 640x640 random matrix__ (sec):  0.3470001 
Determinant of a 2500x2500 random matrix (sec):  0.2070001 
Cholesky decomposition of a 3000x3000 matrix (sec):  0.2543334 
Inverse of a 1600x1600 random matrix (sec):  0.3456663 
  
Trimmed geom. mean (2 extremes eliminated):  0.307686639256803 

   III. Programmation
   --
3,500,000 Fibonacci numbers calculation (vector calc)(sec):  0.245 
Creation of a 3000x3000 Hilbert matrix (matrix calc) (sec):  0.2896669 
Grand common divisors of 400,000 pairs (recursion)__ (sec):  0.2593331 
Creation of a 500x500 Toeplitz matrix (loops)___ (sec):  0.0415 
Escoufier's method on a 45x45 matrix (mixed) (sec):  0.2630005 
  
Trimmed geom. mean (2 extremes eliminated):  0.255658395143118 


Total time for all 15 tests_ (sec):  4.618667 
Overall mean (sum of I, II and III trimmed means/3)_ (sec):  0.286136920519432 
  --- End of test ---



> On Nov 1, 2021, at 2:48 AM, Tim Bates  wrote:
> 
> I wonder if this (2008/R 2.7) page could be updated with some current 
> benchmark runs?
> 
> Especially current Intel server chips, i9, and M1/+ 
> 
> I'm guessing if Simon could help upload the resulting updated page, people 
> here could contribute bench mark runs on different hardware.
> 
> 
> Also be interesting to see different blas results.
> 
> I wonder if either intel or arm chip "neural" cores (dot product engines?) or 
> multi-core and GPU are being used in current R builds?
> 
> tim
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Link to headers lost? Headers not where they should be?

2021-10-22 Thread Simon Urbanek


Bryan,

you seen to be using non-standard compiler in /usr/local/clang4. Remove it and 
check you overrides - do you have some forgotten invalid ~/.R/Makeconf file? 
Remove those if you do - and check ~/.R for any old stuff. (In fact the latter 
will probably fix it alone).

Cheers,
Simon



> On Oct 23, 2021, at 11:29 AM, Bryan Hanson  wrote:
> 
> I don’t know how/when this problem arose, but as of a few days ago, I can’t 
> build source packages any longer.  I’ve been through quite a lot of resources 
> looking for answers and no luck so far, so turning to the mercies of this 
> list.
> 
> I have this problem with either R 4.1.1 or R 4.2.0  I’ve disabled .Rprofile 
> and .cshrc files and the problem persists.  Running BigSur 10.16
> 
> When I try for instance to install MASS (as an example, the problem occurs 
> with any pkg needing compilation) I see this:
> 
> [Abbott-2:~/Desktop] bryanhanson% R CMD INSTALL MASS
> * installing to library 
> ‘/Library/Frameworks/R.framework/Versions/4.1/Resources/library’
> * installing *source* package ‘MASS’ ...
> ** package ‘MASS’ successfully unpacked and MD5 sums checked
> ** using staged installation
> ** libs
> /usr/local/clang4/bin/clang 
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG   
> -I/usr/local/include   -fPIC  -Wall -g -O2  -c MASS.c -o MASS.o
> MASS.c:18:10: fatal error: 'stdlib.h' file not found
> #include 
> ^~
> 1 error generated.
> make: *** [MASS.o] Error 1
> ERROR: compilation failed for package ‘MASS’
> * removing 
> ‘/Library/Frameworks/R.framework/Versions/4.1/Resources/library/MASS’
> * restoring previous 
> ‘/Library/Frameworks/R.framework/Versions/4.1/Resources/library/MASS’
> 
> I think this feedback says the compiler is present and working. 
> 
> Most resources about "fatal error: 'stdlib.h' file not found” end up being 
> cases  of the headers are actually not installed.  However I can see the 
> “missing” headers in /Library/Developer/CommandLineTools/usr/include/c++/v1 
> but I’m not sure this is place R is looking (information on the web is 
> sometimes dated, and Apple seems to have moved things around in recent 
> versions).  So my best guess is that R is looking elsewhere or doesn’t have a 
> link to the correct location.  R Installation and Administration doesn’t 
> appear to spell the location or I missed it.
> 
> I have carefully uninstalled Xcode (13) and re-installed it, and run 
> Xcode-select —install (it thinks the CLTs are already installed).  This does 
> not make any difference, the problem persists.  Restarting the machine after 
> updates does not make a difference either.
> 
> Thanks for any suggestions, as I’m really stuck...
> 
> Bryan
> 
> 
>> sessionInfo()
> R version 4.1.1 Patched (2021-10-18 r81073)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS Big Sur 10.16
> 
> Matrix products: default
> BLAS:   
> /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib
> 
> Random number generation:
> RNG: Mersenne-Twister 
> Normal:  Inversion 
> Sample:  Rounding 
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.1.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] strange segfault error in R from command-line on Mac laptop

2021-09-30 Thread Simon Urbanek


David,

Jeffrey said he is using Quartz and that is key here (since that initializes 
threads in the process). We have been handing this offline and it is a crash in 
readline. I cannot reproduce it so we're still tracking down the circumstances 
which as a bit odd (there are suddenly two threads in R that use the console 
but it is unclear where the second thread comes from and why is it calling the 
console API).

Cheers,
Simon

 

> On Oct 1, 2021, at 7:02 AM, David Winsemius  wrote:
> 
> 
> On 9/29/21 11:17 AM, Jeffrey Rosenthal wrote:
>> Hello. I often use R from the command-line (i.e. just typing "R") within the 
>> "Terminal" application on my MacBook Pro laptop.  And sometimes I get a 
>> sudden strange error "*** caught segfault *** address 0x10, cause 'memory 
>> not mapped'" (after which R allows me to abort/exit/etc, but not to 
>> continue).  It occurs when using the arrow or delete keys (perhaps related 
>> to readline?).  After much testing, I have found a very simple reproducible 
>> minimal example. Namely, if I start R from the command line, and then type 
>> "plot(0)", and then type any character (e.g. "a") and then the delete key, 
>> then it always triggers this error.  Does this error occur for anyone else?  
>> Any ideas how to fix it?
> 
> 
> I would reinstall XQuartz. The `plot(0)` command changes the focus from R to 
> XQuartz, so the processing of the typed letter "a" is being handled by that 
> system function rather than by R. On my 3 year-old MacAir running R 4.1.0 
> typing a letter with the system focus on a plot window produces a mild error 
> tone, as does typing the delete key. (No crash after returning focus to the R 
> process by mouse-clicking in the Terminal window.
> 
> 
> -- 
> 
> David
> 
>> 
>> I know that this problem is quite specific to my Mac laptop set-up; it does 
>> not occur on my iMac nor on my friend's Mac.  On the other hand, I did try 
>> upgrading R and that did not fix it.  My sessionInfo() output follows.  I am 
>> *not* saving R history, nor setting R_SAVEHIST, and I do *not* have any 
>> .Rhistory or .Rapp.history file in my directory.  Thank you very much for 
>> any suggestions!
>> 
>> 
>> 
>>> sessionInfo()
>> 
>> R version 4.0.2 (2020-06-22)
>> Platform: x86_64-apple-darwin17.0 (64-bit)
>> Running under: macOS Catalina 10.15.7
>> 
>> Matrix products: default
>> BLAS:
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
>> LAPACK:
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib 
>> 
>> locale:
>> [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods base
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_4.0.2
>> 
>> 
>>   Jeffrey S. Rosenthal
>>   Professor of Statistics, University of Toronto
>>   Web site: http://probability.ca/jeff/
>> 
>> ___
>> 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] strange segfault error in R from command-line on Mac laptop

2021-09-29 Thread Simon Urbanek


Jeffrey,

can you send me the crash log, please? (Utilities ->Console->User Reports).

Thanks,
Simon


> On Sep 30, 2021, at 7:17 AM, Jeffrey Rosenthal  wrote:
> 
> Hello.  I often use R from the command-line (i.e. just typing "R") within the 
> "Terminal" application on my MacBook Pro laptop.  And sometimes I get a 
> sudden strange error "*** caught segfault *** address 0x10, cause 'memory not 
> mapped'" (after which R allows me to abort/exit/etc, but not to continue).  
> It occurs when using the arrow or delete keys (perhaps related to readline?). 
>  After much testing, I have found a very simple reproducible minimal example. 
> Namely, if I start R from the command line, and then type "plot(0)", and then 
> type any character (e.g. "a") and then the delete key, then it always 
> triggers this error.  Does this error occur for anyone else?  Any ideas how 
> to fix it?
> 
> I know that this problem is quite specific to my Mac laptop set-up; it does 
> not occur on my iMac nor on my friend's Mac.  On the other hand, I did try 
> upgrading R and that did not fix it.  My sessionInfo() output follows.  I am 
> *not* saving R history, nor setting R_SAVEHIST, and I do *not* have any 
> .Rhistory or .Rapp.history file in my directory.  Thank you very much for any 
> suggestions!
> 
> 
> 
>> sessionInfo()
> 
> R version 4.0.2 (2020-06-22)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS Catalina 10.15.7
> 
> Matrix products: default
> BLAS:
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
> LAPACK:
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.0.2
> 
> 
>   Jeffrey S. Rosenthal
>   Professor of Statistics, University of Toronto
>   Web site: http://probability.ca/jeff/
> 
> ___
> 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] checking whether the C compiler works... no

2021-09-23 Thread Simon Urbanek


Before anyone actually follows this, the setup below is quite badly broken so 
this won't work on any normal Mac. Please do NOT set flags you don't understand 
even if you googled it somewhere. There is no need to modify Makevars (both 
versions below are bad - one is forcing locally installed clang the other 
gcc-11 presumably from Homebrew - neither is compatible with R releases). You 
should NEVER set CC/CXX in package's Makevars since the compilers have to match 
what R is using and R will automatically provide the correct setting, so 
overriding it will only break things.

Cheers,
Simon



> On Sep 24, 2021, at 8:34 AM, Naresh Gurbuxani  
> wrote:
> 
> With some search on the internet, I was able to solve my problem with a small 
> edit in Makevars file.  When installing data.table, I had added some lines to 
> Makevars file.  These lines were pointing to clang.  The problem was fixed 
> when it was changed to gcc.  
> 
> # My Makevars file new
> # Successful installation of reshape2 package
> VER=-11   
>  
> CC=gcc$(VER)  
>  
> CXX=g++$(VER) 
> 
> # My Makevars file old
> # These lines were recommended by data.table installation
> # Could not install reshape2 package
> CC=$(LLVM_LOC)/bin/clang -fopenmp 
>
> CXX=$(LLVM_LOC)/bin/clang++ -fopenmp 
> 
> Hope this will help some user,
> Naresh
> 
> From: David Winsemius 
> Sent: Tuesday, September 7, 2021 12:02 AM
> To: Naresh Gurbuxani 
> Cc: r-sig-mac@r-project.org Mac 
> Subject: Re: [R-SIG-Mac] checking whether the C compiler works... no 
>  
> The   C compiler aka clang is not the same as the C++ compiler. 
> 
> Why don’t you install the pre-compiled version.
> 
> — 
> David
> 
> Sent from my iPhone
> 
>> On Sep 6, 2021, at 12:44 AM, Naresh Gurbuxani  
>> wrote:
>> When trying to install library reshape2, I get below messages.  But I do 
>> have some other packages which depend upon C compiler (e.g., Rcpp).  How can 
>> this problem be fixed?
>> 
>> Thanks,
>> Naresh
>> 
>> Messages when trying to install reshape2:
>>> install.packages("reshape2", repos = "https://cran.r-project.org;)
>> Installing package into ‘/usr/local/lib/R/4.1/site-library’
>> (as ‘lib’ is unspecified)
>> also installing the dependencies ‘stringi’, ‘stringr’
>> 
>> trying URL 'https://cran.r-project.org/src/contrib/stringi_1.7.4.tar.gz'
>> Content type 'application/x-gzip' length 7599762 bytes (7.2 MB)
>> ==
>> downloaded 7.2 MB
>> 
>> trying URL 'https://cran.r-project.org/src/contrib/stringr_1.4.0.tar.gz'
>> Content type 'application/x-gzip' length 135777 bytes (132 KB)
>> ==
>> downloaded 132 KB
>> 
>> trying URL 'https://cran.r-project.org/src/contrib/reshape2_1.4.4.tar.gz'
>> Content type 'application/x-gzip' length 37307 bytes (36 KB)
>> ==
>> downloaded 36 KB
>> 
>> * installing *source* package ‘stringi’ ...
>> ** package ‘stringi’ successfully unpacked and MD5 sums checked
>> ** using staged installation
>> checking for R_HOME... /usr/local/Cellar/r/4.1.1/lib/R
>> checking for R... /usr/local/Cellar/r/4.1.1/lib/R/bin/R
>> checking for endianness... little
>> checking for R >= 3.1.0 for C++11 use... yes
>> checking for R < 3.4.0 for CXX1X flag use... no
>> checking for cat... /bin/cat
>> checking for local ICUDT_DIR... icu69/data
>> checking for gcc... /usr/local/opt/llvm/bin/clang -fopenmp
>> checking whether the C compiler works... no
>> configure: error: in 
>> `/private/var/folders/97/5377j5_d207fshvjz_pz7szwgn/T/RtmpCOKBRx/R.INSTALL64822d9c75a/stringi':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>> ERROR: configuration failed for package ‘stringi’
>> * removing ‘/usr/local/lib/R/4.1/site-library/stringi’
>> ERROR: dependency ‘stringi’ is not available for package ‘stringr’
>> * removing ‘/usr/local/lib/R/4.1/site-library/stringr’
>> ERROR: dependency ‘stringr’ is not available for package ‘reshape2’
>> * removing ‘/usr/local/lib/R/4.1/site-library/reshape2’
>> 
>> The downloaded source packages are in
>> 
>> ‘/private/var/folders/97/5377j5_d207fshvjz_pz7szwgn/T/RtmpDOExfD/downloaded_packages’
>> Warning messages:
>> 1: In install.packages("reshape2", repos = "https://cran.r-project.org;) :
>>   installation of package ‘stringi’ had non-zero exit status
>> 2: In install.packages("reshape2", repos = "https://cran.r-project.org;) :
>>   installation of package ‘stringr’ had non-zero exit status
>> 3: In install.packages("reshape2", repos = "https://cran.r-project.org;) :
>>   installation of package ‘reshape2’ had non-zero exit status
>> 
>> My session info:
>>> sessionInfo()
>> R version 4.1.1 (2021-08-10)
>> Platform: x86_64-apple-darwin20.5.0 (64-bit)
>> Running under: 

[R-SIG-Mac] CRAN Mac Builder based on M1

2021-09-22 Thread Simon Urbanek


Dear Mac useRs.

I'm pleased to announce that thanks to the R Foundation and donations from 
users like you we are now able to offer a CRAN Mac Builder based on M1 hardware 
which allows package authors that don't have access to a recent Mac to check 
their package using the same process as CRAN:

https://mac.r-project.org/macbuilder/submit.html

The machine mirrors all CRAN packages nightly and uses the CRAN building and 
checking system[1] so the results should be as close to the CRAN setup as 
feasible.
The resources are limited, so do not treat this as a CI setup, but rather as a 
service for package authors to facilitate checks before CRAN submissions.

The setup is new and experimental, so please contact me for any comments, 
problem reports or suggestions regarding the Mac Builder.

Cheers,
Simon


[1] - https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages

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


Re: [R-SIG-Mac] .libPaths and library directory

2021-09-05 Thread Simon Urbanek


Adrian,

thank you, this is indeed a bug that got unnoticed for a while. Apparently the 
R defaults and the R GUI got out of sync at some point when the R_LIBS_USER 
defaults were tweaked in R but the corresponding change has not been made in 
the GUI.  I suppose the right thing to do would be for the GUI to check 
R_LIBS_USER.

Cheers,
Simon



> On Sep 5, 2021, at 10:16 PM, Adrian Dușa  wrote:
> 
> Dear All,
> 
> My .libPaths for the user defined directory shows:
> "/Users/dusadrian/Library/R/x86_64/4.1/library"
> 
> and indeed, the command install.packages() does install the packages in
> this location.
> 
> However, when installing from the RGUI menu, using Packages & Data /
> Package installer,
> the installation directory is:
> "/Users/dusadrian/Library/R/4.1/library"
> 
> I don't remember at which exact version this started to happen (it was also
> present in 4.1.0), and could not find any particular setting that I should
> tweak to make these equal.
> 
> This is the R.version result:
>   _
> 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
> 
> running under MacOS BigSur version 11.5.2
> 
> Thanks for any hint,
> Adrian
> 
> --
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr. 90-92
> 050663 Bucharest sector 5
> Romania
> https://adriandusa.eu
> 
>   [[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] rgl in R version 4.1.1 Patched (2021-08-13 r80752)

2021-08-21 Thread Simon Urbanek


Duncan,

thanks, update received and it did pass checks on M1 so the binary is now on 
CRAN.

Thanks,
Simon


> On Aug 22, 2021, at 4:28 AM, Duncan Murdoch  wrote:
> 
> The rgl patch was accepted by CRAN an hour ago, so you should see it soon.
> 
> Duncan Murdoch
> 
> On 19/08/2021 8:57 p.m., Simon Urbanek wrote:
>> Duncan,
>> using that checkout I get
>> * checking package dependencies ... ERROR
>> Package suggested but not available: ‘webshot2’
>> but otherwise it works as advertised.
>> However, I just found out that there is another problem in R that rgl 
>> exposed. Using non-session terminal:
>>> png("/tmp/1.png", type="quartz")
>>> plot(1)
>> Warning in axis(side = side, at = at, labels = labels, ...) :
>>   no font could be found for family "Arial"
>> so requests for fonts using Quartz-back-end without an UI session fail. It 
>> works fine inside a session, but since checks are normally run without a 
>> session that explains the check failures. I can run checks in a session, so 
>> I think that's what I'll do for now.
>> Now, back to rgl - so checks can be run in a session, but oddly, rgl manages 
>> to segfault XQuartz in the checks. I don't think it's rgl's fault - more 
>> likely something in XQuartz (a TCP connection shouldn't be able to segfault 
>> the other end...).
>> Anyway, so if you can post the fixed release I'd be happy the recompile and 
>> publish manually.
>> Cheers,
>> Simon
>> PS: I found yet another problem - XQuartz has moved the location of fonts 
>> from X11/lib to X11/shared so our fontconfig configuration in R needs to add 
>> that directory as well. So all is all this has highlighted quite a few 
>> related issues ;)
>>> On Aug 20, 2021, at 11:43 AM, Duncan Murdoch  
>>> wrote:
>>> 
>>> Thanks Simon (and Prof Ripley, offline).  The --static modifier needs to be 
>>> added in two places in configure.ac, which leads to it being added in two 
>>> places in configure.
>>> 
>>> If anyone wants to build from source, you could get the CRAN release plus 
>>> this modification using
>>> 
>>>  remotes::install_github("dmurdoch/rgl@configpatch")
>>> 
>>> Duncan Murdoch
>>> 
>>> 
>>> On 19/08/2021 6:08 p.m., Simon Urbanek wrote:
>>>> R (and the CRAN builds) use more recent static freetype with harfbuzz 
>>>> support so it does not depend for those in XQuartz.
>>>> The issue is that rgl doesn't use sufficient flags to compile against 
>>>> freetype since it misses the dependencies - in fact is fails checks,
>>>> https://www.r-project.org/nosvn/R.check/r-release-macos-arm64/rgl-00check.html
>>>> pkg-config has to be used with --static --libs otherwise the linking 
>>>> doesn't have all the dependencies included that are necessary:
>>>> $ pkg-config freetype2 --libs
>>>> -L/opt/R/arm64/lib -lfreetype
>>>> $ pkg-config freetype2 --static --libs
>>>> -L/opt/R/arm64/lib -lfreetype -lbz2 -lpng16 -lz -lharfbuzz -lm -lglib-2.0 
>>>> -lintl -liconv -lm -Wl,-framework,CoreFoundation -Wl,-framework,Carbon 
>>>> -Wl,-framework,Foundation -Wl,-framework,AppKit -lpcre
>>>> The CRAN binaries are built against static libraries to make sure the user 
>>>> doesn't have to install 3rd party dependencies.
>>>> It looks line rgl does the right thing for libpng but not for freetype.
>>>> Cheers,
>>>> Simon
>>>>> On Aug 19, 2021, at 9:54 PM, Stefan Evert  
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 19 Aug 2021, at 10:40, Duncan Murdoch  
>>>>>> wrote:
>>>>>> 
>>>>>>> Error in dyn.load(dynlib <- getDynlib(dir)) :
>>>>>>>  unable to load shared object 
>>>>>>> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so':
>>>>>>>  
>>>>>>> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so,
>>>>>>>  6): Symbol not found: _hb_buffer_add_utf8
>>>>>>>  Referenced from: 
>>>>>>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
>>>>>>>  Expected in: flat namespace
>>>>>>> in 
>>>>>>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Re

Re: [R-SIG-Mac] rgl in R version 4.1.1 Patched (2021-08-13 r80752)

2021-08-19 Thread Simon Urbanek


Duncan,

using that checkout I get

* checking package dependencies ... ERROR
Package suggested but not available: ‘webshot2’

but otherwise it works as advertised.

However, I just found out that there is another problem in R that rgl exposed. 
Using non-session terminal:

> png("/tmp/1.png", type="quartz")
> plot(1)
Warning in axis(side = side, at = at, labels = labels, ...) :
  no font could be found for family "Arial"

so requests for fonts using Quartz-back-end without an UI session fail. It 
works fine inside a session, but since checks are normally run without a 
session that explains the check failures. I can run checks in a session, so I 
think that's what I'll do for now.

Now, back to rgl - so checks can be run in a session, but oddly, rgl manages to 
segfault XQuartz in the checks. I don't think it's rgl's fault - more likely 
something in XQuartz (a TCP connection shouldn't be able to segfault the other 
end...).

Anyway, so if you can post the fixed release I'd be happy the recompile and 
publish manually.

Cheers,
Simon

PS: I found yet another problem - XQuartz has moved the location of fonts from 
X11/lib to X11/shared so our fontconfig configuration in R needs to add that 
directory as well. So all is all this has highlighted quite a few related 
issues ;)



> On Aug 20, 2021, at 11:43 AM, Duncan Murdoch  wrote:
> 
> Thanks Simon (and Prof Ripley, offline).  The --static modifier needs to be 
> added in two places in configure.ac, which leads to it being added in two 
> places in configure.
> 
> If anyone wants to build from source, you could get the CRAN release plus 
> this modification using
> 
>  remotes::install_github("dmurdoch/rgl@configpatch")
> 
> Duncan Murdoch
> 
> 
> On 19/08/2021 6:08 p.m., Simon Urbanek wrote:
>> R (and the CRAN builds) use more recent static freetype with harfbuzz 
>> support so it does not depend for those in XQuartz.
>> The issue is that rgl doesn't use sufficient flags to compile against 
>> freetype since it misses the dependencies - in fact is fails checks,
>> https://www.r-project.org/nosvn/R.check/r-release-macos-arm64/rgl-00check.html
>> pkg-config has to be used with --static --libs otherwise the linking doesn't 
>> have all the dependencies included that are necessary:
>> $ pkg-config freetype2 --libs
>> -L/opt/R/arm64/lib -lfreetype
>> $ pkg-config freetype2 --static --libs
>> -L/opt/R/arm64/lib -lfreetype -lbz2 -lpng16 -lz -lharfbuzz -lm -lglib-2.0 
>> -lintl -liconv -lm -Wl,-framework,CoreFoundation -Wl,-framework,Carbon 
>> -Wl,-framework,Foundation -Wl,-framework,AppKit -lpcre
>> The CRAN binaries are built against static libraries to make sure the user 
>> doesn't have to install 3rd party dependencies.
>> It looks line rgl does the right thing for libpng but not for freetype.
>> Cheers,
>> Simon
>>> On Aug 19, 2021, at 9:54 PM, Stefan Evert  wrote:
>>> 
>>> 
>>> 
>>>> On 19 Aug 2021, at 10:40, Duncan Murdoch  wrote:
>>>> 
>>>>> Error in dyn.load(dynlib <- getDynlib(dir)) :
>>>>>  unable to load shared object 
>>>>> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so':
>>>>>  
>>>>> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so,
>>>>>  6): Symbol not found: _hb_buffer_add_utf8
>>>>>  Referenced from: 
>>>>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
>>>>>  Expected in: flat namespace
>>>>> in 
>>>>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
>>>> 
>>>> That looks like a symbol in the harfbuzz lib.  rgl doesn't reference it 
>>>> directly, I think FreeType does.  I don't know what you need to do to fix 
>>>> this, but maybe that's enough of a hint.
>>> 
>>> I just ran into the same problem with a M1 MacBook and XQuartz 2.8.1 
>>> installed.  My MacBook has no developer tools installed, not even XCode – 
>>> just R, "rgl" (and various other packages) from CRAN, and XQuartz.
>>> 
>>> XQuartz doesn't include libharfbuzz, so I doubt that it's libfreetype 
>>> depends on it.  Any chance that the CRAN machine that builds the aarch64 
>>> binary package links against some other version of freetype that pulls in 
>>> the dependency?
>>> 
>>> Best,
>>> Stefan
>>> ___
>>> 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] rgl in R version 4.1.1 Patched (2021-08-13 r80752)

2021-08-19 Thread Simon Urbanek


R (and the CRAN builds) use more recent static freetype with harfbuzz support 
so it does not depend for those in XQuartz.

The issue is that rgl doesn't use sufficient flags to compile against freetype 
since it misses the dependencies - in fact is fails checks,
https://www.r-project.org/nosvn/R.check/r-release-macos-arm64/rgl-00check.html

pkg-config has to be used with --static --libs otherwise the linking doesn't 
have all the dependencies included that are necessary:

$ pkg-config freetype2 --libs
-L/opt/R/arm64/lib -lfreetype 

$ pkg-config freetype2 --static --libs
-L/opt/R/arm64/lib -lfreetype -lbz2 -lpng16 -lz -lharfbuzz -lm -lglib-2.0 
-lintl -liconv -lm -Wl,-framework,CoreFoundation -Wl,-framework,Carbon 
-Wl,-framework,Foundation -Wl,-framework,AppKit -lpcre 

The CRAN binaries are built against static libraries to make sure the user 
doesn't have to install 3rd party dependencies.
It looks line rgl does the right thing for libpng but not for freetype.

Cheers,
Simon



> On Aug 19, 2021, at 9:54 PM, Stefan Evert  wrote:
> 
> 
> 
>> On 19 Aug 2021, at 10:40, Duncan Murdoch  wrote:
>> 
>>> Error in dyn.load(dynlib <- getDynlib(dir)) :
>>>  unable to load shared object 
>>> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so':
>>>  
>>> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so,
>>>  6): Symbol not found: _hb_buffer_add_utf8
>>>  Referenced from: 
>>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
>>>  Expected in: flat namespace
>>> in 
>>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/rgl/libs/rgl.so
>> 
>> That looks like a symbol in the harfbuzz lib.  rgl doesn't reference it 
>> directly, I think FreeType does.  I don't know what you need to do to fix 
>> this, but maybe that's enough of a hint.
> 
> I just ran into the same problem with a M1 MacBook and XQuartz 2.8.1 
> installed.  My MacBook has no developer tools installed, not even XCode – 
> just R, "rgl" (and various other packages) from CRAN, and XQuartz. 
> 
> XQuartz doesn't include libharfbuzz, so I doubt that it's libfreetype depends 
> on it.  Any chance that the CRAN machine that builds the aarch64 binary 
> package links against some other version of freetype that pulls in the 
> dependency?
> 
> Best,
> Stefan
> ___
> 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] sf installation problem under Mac OS 11 - Big Sur

2021-08-19 Thread Simon Urbanek


Michal,

those instructions work for released CRAN R. Apparently, that's not what you 
are using - if you want to compile sf and gdal from sources, that is more 
challenging and you have to install all its dependencies first. In the output 
below you're missing at the very least the PROJ4/6 library - it may not be the 
only thing you're missing, so make sure you read the errors and install all 
necessary dependencies.

Cheers,
Simon



> On Aug 19, 2021, at 10:52 AM, Michal Ben-Nun  wrote:
> 
> Hi,
> 
> I installed R 4.10 on my Mac OS 11.3.1
> 
> I am trying to install 'sf' and 'rgdal'
> 
> From the mailing list I understood that this command should work:
> 
> install.packages(c("rgdal","sf"),,"https://mac.R-project.org
> ")
> 
> However I am still getting an error, see below.
> 
> Any suggestions would be welcome.
> 
> Thanks,
> Michal
> 
> p.s. I am using macports NOT brew
> 
>> install.packages(c("rgdal","sf"),,"https://mac.R-project.org;)
> Installing packages into ‘/Users/michal/Library/R/x86_64/4.1/library’
> (as ‘lib’ is unspecified)
> trying URL 'https://mac.R-project.org/src/contrib/rgdal_1.5-23.tar.gz'
> Content type 'application/octet-stream' length 4393536 bytes (4.2 MB)
> ==
> downloaded 4.2 MB
> 
> trying URL 'https://mac.R-project.org/src/contrib/sf_1.0-2.tar.gz'
> Content type 'application/octet-stream' length 3645982 bytes (3.5 MB)
> ==
> downloaded 3.5 MB
> 
> * installing *source* package ‘rgdal’ ...
> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> ** using staged installation
> configure: R_HOME: /opt/local/Library/Frameworks/R.framework/Resources
> configure: CC: /opt/local/bin/clang-mp-12
> configure: CXX: /opt/local/bin/clang++-mp-12 -std=gnu++14
> configure: CFLAGS: -pipe -Os
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64
> configure: CPPFLAGS: -I/opt/local/include
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
> configure: CXXFLAGS: -pipe -Os -stdlib=libc++
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64
> configure: LDFLAGS: -L/opt/local/lib -Wl,-headerpad_max_install_names
> -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch
> x86_64
> configure: LDFLAGS: -L/opt/local/lib -Wl,-headerpad_max_install_names
> -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch
> x86_64
> configure: CXX11 is: /opt/local/bin/clang++-mp-12, CXX11STD is: -std=gnu++11
> configure: CXX is: /opt/local/bin/clang++-mp-12 -std=gnu++11
> configure: C++11 support available
> configure: rgdal: 1.5-23
> checking for /usr/bin/svnversion... no
> configure: svn revision: 1121
> checking for gdal-config... /opt/local/bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 3.3.0
> checking GDAL version >= 1.11.4... yes
> checking GDAL version <= 2.5 or >= 3.0... yes
> checking GDAL: linking with --libs only... yes
> checking GDAL: gdal-config data directory readable... yes
> checking GDAL: /opt/local/share/gdal/stateplane.csv readable... yes
> configure: pkg-config proj not available
>  set PKG_CONFIG_PATH to the directory containing proj.pc
> configure: PROJ version not determined using pkg-config proj
> configure: PROJ CPP flags:  -I/opt/local/include
> configure: PROJ LIBS:  -lproj
> checking PROJ header API:... yes
> configure: API to be used as yet undetermined, searching ...
> configure: error: API to be used not found
> ERROR: configuration failed for package ‘rgdal’
> * removing ‘/Users/michal/Library/R/x86_64/4.1/library/rgdal’
> * installing *source* package ‘sf’ ...
> ** package ‘sf’ successfully unpacked and MD5 sums checked
> ** using staged installation
> configure: CC: /opt/local/bin/clang-mp-12
> configure: CXX: /opt/local/bin/clang++-mp-12 -std=gnu++11
> checking for gdal-config... /opt/local/bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 3.3.0
> checking GDAL version >= 2.0.1... yes
> checking for gcc... /opt/local/bin/clang-mp-12
> 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 /opt/local/bin/clang-mp-12 accepts -g... yes
> checking for /opt/local/bin/clang-mp-12 option to accept ISO C89... none
> needed
> checking how to run the C preprocessor... /opt/local/bin/clang-mp-12 -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... 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 

Re: [R-SIG-Mac] R.app spontaneously switching windows during editing

2021-08-15 Thread Simon Urbanek


John,

I tried to reproduce on macOS 11.4, but failed to so far. Can you send us the 
details on your setup, e.g., is this a MacBook or a mini etc? Also what exactly 
is the sequence - i.e. what were you doing and what happened?

One thing I noted, however, is that if you use a trackpad have tap-to-click 
enabled, it's amazingly easy to accidentally click on another windows while 
you're typing on MacBooks since your hands are hovering very close to the touch 
pad. To see if that makes a difference, disable the tap-to-click in the 
trackpad system preferences.

FWIW the behavior in the text editing is defined by Apple and the OS, so things 
like replacing the selection are UI standards by Apple. You can always use Undo 
in case you select and replace something inadvertently.

Thanks,
Simon



> On 16/08/2021, at 7:45 AM, Simon Urbanek  wrote:
> 
> 
> John,
> 
> Thank you for the report. We have not changed anything recently so it's 
> likely some odd behaviour by the macOS. I'll try to reproduce and will get 
> back to you.
> 
> Cheers,
> Simon
> 
> 
> 
>> On Aug 15, 2021, at 14:43, John Helly via R-SIG-Mac 
>>  wrote:
>> 
>> Aloha.
>> 
>> Apparently since I switched to Big Sur, R has begun spontaneously 
>> switching the active window from console to editor back and forth for no 
>> obvious reason.  This disrupts editing and has almost destroyed whole 
>> editing files due to the deletion of highlighted lines (a different 
>> behavior that has always been dangerous but is exacerbated by the 
>> window-switching).
>> 
>> I've looked at the default settings in the Preferences and can't see or 
>> change anything that seems to affect this behavior. I've tried turning 
>> off everything that might be doing it (e.g., matching delimiters) and I 
>> can't find anything or anyone else that complains about this. Am I the 
>> only one?
>> 
>> Any suggestions for debugging this would be welcome.  sessionInfo below.
>> 
>> J. Helly.
>> 
>> -- John Helly, University of California, San Diego / San Diego 
>> Supercomputer Center / Scripps Institution of Oceanography / 760 840 
>> 8660 mobile / http://www.sdsc.edu/~hellyj ORCID ID: 
>> orcid.org/-0002-3779-0603
>> 
>> 
>> 
>>> sessionInfo()
>> R version 4.1.0 (2021-05-18)
>> Platform: x86_64-apple-darwin17.0 (64-bit)
>> Running under: macOS Big Sur 11.4
>> 
>> Matrix products: default
>> BLAS: 
>> /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRblas.dylib
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.1/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] stats graphics  grDevices utils datasets  methods base
>> 
>> other attached packages:
>> [1] Hmisc_4.5-0  Formula_1.2-4survival_3.2-11 lattice_0.20-44  
>> runner_0.4.0 GGally_2.1.2 rpart.plot_3.0.9
>> [8] rpart_4.1-15 stargazer_5.2.2  texreg_1.37.5 factoextra_1.0.7 
>> forcats_0.5.1stringr_1.4.0dplyr_1.0.6
>> [15] purrr_0.3.4  readr_1.4.0  tidyr_1.1.3 tibble_3.1.2 
>> tidyverse_1.3.1  tables_0.9.6 reshape2_1.4.4
>> [22] plyr_1.8.6   ggplot2_3.3.5
>> 
>> loaded via a namespace (and not attached):
>> [1] fs_1.5.0lubridate_1.7.10RColorBrewer_1.1-2 
>> httr_1.4.2  tools_4.1.0 backports_1.2.1
>> [7] utf8_1.2.1  R6_2.5.0DBI_1.1.1 
>> colorspace_2.0-1nnet_7.3-16 withr_2.4.2
>> [13] tidyselect_1.1.1gridExtra_2.3   curl_4.3.1 
>> compiler_4.1.0  cli_2.5.0   rvest_1.0.0
>> [19] htmlTable_2.2.1 xml2_1.3.2  labeling_0.4.2 
>> scales_1.1.1checkmate_2.0.0 digest_0.6.27
>> [25] foreign_0.8-81  rio_0.5.27  base64enc_0.1-3 
>> jpeg_0.1-8.1pkgconfig_2.0.3 htmltools_0.5.1.1
>> [31] dbplyr_2.1.1htmlwidgets_1.5.3   rlang_0.4.11 
>> readxl_1.3.1rstudioapi_0.13 generics_0.1.0
>> [37] farver_2.1.0jsonlite_1.7.2  zip_2.2.0 
>> car_3.0-11  magrittr_2.0.1  Matrix_1.3-3
>> [43] Rcpp_1.0.6  munsell_0.5.0   fansi_0.5.0 
>> abind_1.4-5 lifecycle_1.0.0 stringi_1.6.2
>> [49] carData_3.0-4   grid_4.1.0  parallel_4.1.0 
>> ggrepel_0.9.1   crayon_1.4.1haven_2.4.1
>> [55] splines_4.1.0   hms_1.1.0   knitr_1.33 
>> ps_1.6.0pillar_1.6.1ggpubr_0.4.0
>> [61] ggsignif_0.6.2  reprex_2.0.0glue_1.4.2 
>> latticeExt

Re: [R-SIG-Mac] R.app spontaneously switching windows during editing

2021-08-15 Thread Simon Urbanek


John,

Thank you for the report. We have not changed anything recently so it's likely 
some odd behaviour by the macOS. I'll try to reproduce and will get back to you.

Cheers,
Simon



> On Aug 15, 2021, at 14:43, John Helly via R-SIG-Mac  
> wrote:
> 
> Aloha.
> 
> Apparently since I switched to Big Sur, R has begun spontaneously 
> switching the active window from console to editor back and forth for no 
> obvious reason.  This disrupts editing and has almost destroyed whole 
> editing files due to the deletion of highlighted lines (a different 
> behavior that has always been dangerous but is exacerbated by the 
> window-switching).
> 
> I've looked at the default settings in the Preferences and can't see or 
> change anything that seems to affect this behavior. I've tried turning 
> off everything that might be doing it (e.g., matching delimiters) and I 
> can't find anything or anyone else that complains about this. Am I the 
> only one?
> 
> Any suggestions for debugging this would be welcome.  sessionInfo below.
> 
> J. Helly.
> 
> -- John Helly, University of California, San Diego / San Diego 
> Supercomputer Center / Scripps Institution of Oceanography / 760 840 
> 8660 mobile / http://www.sdsc.edu/~hellyj ORCID ID: 
> orcid.org/-0002-3779-0603
> 
> 
> 
>> sessionInfo()
> R version 4.1.0 (2021-05-18)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS Big Sur 11.4
> 
> Matrix products: default
> BLAS: 
> /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRblas.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.1/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] stats graphics  grDevices utils datasets  methods base
> 
> other attached packages:
>  [1] Hmisc_4.5-0  Formula_1.2-4survival_3.2-11 lattice_0.20-44  
> runner_0.4.0 GGally_2.1.2 rpart.plot_3.0.9
>  [8] rpart_4.1-15 stargazer_5.2.2  texreg_1.37.5 factoextra_1.0.7 
> forcats_0.5.1stringr_1.4.0dplyr_1.0.6
> [15] purrr_0.3.4  readr_1.4.0  tidyr_1.1.3 tibble_3.1.2 
> tidyverse_1.3.1  tables_0.9.6 reshape2_1.4.4
> [22] plyr_1.8.6   ggplot2_3.3.5
> 
> loaded via a namespace (and not attached):
>  [1] fs_1.5.0lubridate_1.7.10RColorBrewer_1.1-2 
> httr_1.4.2  tools_4.1.0 backports_1.2.1
>  [7] utf8_1.2.1  R6_2.5.0DBI_1.1.1 
> colorspace_2.0-1nnet_7.3-16 withr_2.4.2
> [13] tidyselect_1.1.1gridExtra_2.3   curl_4.3.1 
> compiler_4.1.0  cli_2.5.0   rvest_1.0.0
> [19] htmlTable_2.2.1 xml2_1.3.2  labeling_0.4.2 
> scales_1.1.1checkmate_2.0.0 digest_0.6.27
> [25] foreign_0.8-81  rio_0.5.27  base64enc_0.1-3 
> jpeg_0.1-8.1pkgconfig_2.0.3 htmltools_0.5.1.1
> [31] dbplyr_2.1.1htmlwidgets_1.5.3   rlang_0.4.11 
> readxl_1.3.1rstudioapi_0.13 generics_0.1.0
> [37] farver_2.1.0jsonlite_1.7.2  zip_2.2.0 
> car_3.0-11  magrittr_2.0.1  Matrix_1.3-3
> [43] Rcpp_1.0.6  munsell_0.5.0   fansi_0.5.0 
> abind_1.4-5 lifecycle_1.0.0 stringi_1.6.2
> [49] carData_3.0-4   grid_4.1.0  parallel_4.1.0 
> ggrepel_0.9.1   crayon_1.4.1haven_2.4.1
> [55] splines_4.1.0   hms_1.1.0   knitr_1.33 
> ps_1.6.0pillar_1.6.1ggpubr_0.4.0
> [61] ggsignif_0.6.2  reprex_2.0.0glue_1.4.2 
> latticeExtra_0.6-29 data.table_1.14.0   modelr_0.1.8
> [67] png_0.1-7   vctrs_0.3.8 cellranger_1.1.0 
> gtable_0.3.0reshape_0.8.8   assertthat_0.2.1
> [73] openxlsx_4.2.4  xfun_0.23   broom_0.7.6 
> rstatix_0.7.0   cluster_2.1.2   ellipsis_0.3.2
>> 
> 
> -- 
> John Helly, University of California, San Diego / San Diego Supercomputer 
> Center / Scripps Institution of Oceanography / 760 840 8660 mobile / 
> http://www.sdsc.edu/~hellyj
> ORCID ID: orcid.org/-0002-3779-0603
> 
> 
>   [[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] R 4.1.1 installer Apple notarization

2021-08-14 Thread Simon Urbanek


The R 4.1.1 package installers have not been notarized when first released, 
however, the notarization has been completed after the release. The 
notarization receipts have been then added to the packages, so the most current 
releases have the following hashes:

MD5:MD5(base/R-4.1.1.pkg)= 0e9684e8fc9c8a5eda675aef99c6a6ee
MD5:MD5(big-sur-arm64/base/R-4.1.1-arm64.pkg)= f7a249c9a4b5f32efbfd44b821a6a846

SHA1:SHA1(base/R-4.1.1.pkg)= d0eed7d0755bc80911acb616508d41e1396f810e
SHA1:SHA1(big-sur-arm64/base/R-4.1.1-arm64.pkg)= 
e58f4b78f9e4d347a12cc9160ee69d3d23e69f3b

You can check your download for the receipt by comparing the hash above. The 
actual contents of the released packages are identical, they only vary by the 
absence or presence of the notarization receipt which allows off-line 
notarization check. If in doubt, you can always download from 
http://mac.R-project.org/bin/macosx which has always the latest version.

If you use the files without receipts from Aug 10, they will install since the 
package itself was notarized, but you will need internet connection to allow 
installer to pull the notarization receipt from Apple.

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] Can't make odbc FreeTDS connections in R.app, can with RStudio, /usr/local/bin/R, Rscript

2021-08-11 Thread Simon Urbanek


Joey,

it is hard to say - it could be a bug in the driver. I would recommend using 
lldb to find the trace so you know where it happens - it would be anywhere from 
the odbc package, odbc library or the driver. If there is a difference, also 
check if you are loading the same versions of packages in each (cf .libPaths()) 
and which libraries are used. You could use JDBC with jTDS instead to see if 
that works better (or a native driver if it exists).

Cheers,
Simon



> On 12/08/2021, at 5:31 AM, Joey Reid via R-SIG-Mac  
> wrote:
> 
> I’m experiencing some weirdness with database connections using R 4.1 on 
> macOS 11.5.1 and the `odbc` package with the FreeTDS driver. I can replicate 
> the problem on my coworker’s Mac with R 4.0 (macOS 11, not sure which 
> version). 
> 
> Running this code works fine on the command line (or with RStudio, 
> /usr/local/bin/R), /usr/local/bin/Rscript -e “library(odbc); con = 
> dbConnect(odbc(), 'GISLibrary'); dbGetQuery(con, ‘select 1 num’); 
> dbDisconnect(con)”
> 
> But the connection fails with the exact same code in R.app (I’ve tried R.app 
> rev 7976 and 7982). I often get a segfault, like "address 0x7f975f481cb0, 
> cause 'memory not mapped’”. The connection works fine with the ODBC Driver 17 
> for SQL Server in all execution environments.
> 
> The connection also fails in some environments (rmarkdown::render, Rscript 
> -e) if I load the package sf before making the first connection attempt, 
> e.g., Rscript -e "library(odbc); library(sf);  con = dbConnect(odbc(), 
> 'GISLibrary'); dbGetQuery(con, 'select 1 num'); dbDisconnect(con);". If I 
> delay loading sf until after I’ve successfully made a connection with the 
> FreeTDS driver I can continue to make connections.
> 
> I saw the recent post about breaking ABI changes in the Rcpp package, so I 
> followed the instructions to re-install all packages that depend on Rcpp. 
> That did not solve the problem.
> 
> Thanks,
> 
> Joey Reid
> ___
> 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] Problem with createDataPartition

2021-08-09 Thread Simon Urbanek


Richard, 

Rcpp has made an ABI-breaking change in 1.0.7 so you need to re-install all 
packages that use Rcpp (i.e. not only Rcpp itself but all other packages).

One way to re-install all packages is to use something like

install.packages(rownames(installed.packages()), type='binary')

If you want to install only Rcpp dependencies then something like this should 
work:

deps = 
tools:::CRAN_package_reverse_dependencies_with_maintainers("Rcpp")[,"Package"]
have = rownames(installed.packages())
install.packages(have[have %in% deps], type='binary')

Cheers,
Simon



> On Aug 10, 2021, at 4:41 AM, Martin Maechler  
> wrote:
> 
>> RoqueRichard  
>>on Thu, 5 Aug 2021 12:54:36 +0800 writes:
> 
> Dear Richard,
> you sent all this to   r-sig-mac-ow...@r-project.org
> 
> but you really should re-send it to the mailing list, i.e.
> 
> r-sig-mac@r-project.org
> 
> Best,
> Martin
> 
>> Hi,
> 
>> Im currently using R4.1.0 version on Mac OS. I tried using
>> the createDataPartition function but got the following
>> reply:
> 
>>> test_index <- createDataPartition(y, times = 1, p = 0.5,
>>> list = FALSE)
> 
>> Error in split_indices(as.integer(splitv), attr(splitv,
>> "n")) : function 'Rcpp_precious_remove' not provided by
>> package ‘Rcpp'
> 
>> Is the Rcpp outdated? If so, could you advise how to
>> update Rcpp?
> 
>> Thanks a lot for any assistance you can provide.  Richard
> 

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


Re: [R-SIG-Mac] [Rd] R Can Use Your Help: Testing R Before Release

2021-07-13 Thread Simon Urbanek


Brodie,
thanks, good catch, there is space again after deleting old builds.
Cheers,
Simon



> On 13/07/2021, at 11:06 PM, brodie gaslam via R-SIG-Mac 
>  wrote:
> 
> In case this has not been noticed, the x86_64 builds on mac.r-project.org
> are showing errors.  This is the error from 4.1:
> 
> Testing examples for package 'base'
> Warning in file(out, "wt") :
>   cannot open file 
> '/var/folders/2b/t0kwbtmn3p7brv2mvx39c9crgn/T//Rtmp4ZevDn/file1399b189e156f/chol2inv.R':
>  No space left on device
> Error in file(out, "wt") : cannot open the connection
> Calls:  ... testInstalledPackage -> .createExdotR -> Rd2ex -> file
> Execution halted
> make[3]: *** [test-Examples-Base] Error 1
> make[2]: *** [test-Examples] Error 2
> make[1]: *** [test-all-basics] Error 1
> make: *** [check] Error 2
> 
> The other two builds don't make it to the `make check` step, maybe because
> of what happened on the 4.1 build if they are running concurrently.
> 
> Best,
> 
> B.
> 
> 
> - Forwarded Message -
> 
> From: Tomas Kalibera 
> To: r-devel 
> Sent: Tuesday, July 13, 2021, 6:26:27 AM EDT
> Subject: [Rd] R Can Use Your Help: Testing R Before Release
> 
> 
> If anyone is interested in helping out, this is a good time to test R 
> 4.1.1 before it is released. Now is the time to look for and report
> 
> - regressions (things that worked in 4.1.0, but not in 4.1.1)
> - regressions in 4.1.0 not fixed by 4.1.1
> - bugs in new features in 4.1.0 not fixed by 4.1.1
> 
> For more tips and details, please see
> https://developer.r-project.org/Blog/public/2021/04/28/r-can-use-your-help-testing-r-before-release
> 
> Thanks
> Tomas
> 
> __
> r-de...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ___
> 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] BLAS veclib in R 4.1

2021-06-14 Thread Simon Urbanek


Ashley,

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

curl -O https://mac.r-project.org/libs-4/libRblas-vecLib-signed.tar.gz 
tar fxzP libRblas-vecLib-signed.tar.gz -C /
cd /Library/Frameworks/R.framework/Resources/lib
mv libRblas.dylib libRblas.0.dylib
ln -s  libRblas.vecLib.dylib libRblas.dylib

You can also choose to use the unsigned version for debugging or if you want to 
change its id. Use at your own risk as this setup has not been tested.

Cheers,
Simon



> On 15/06/2021, at 9:43 AM, Ashley Stephen Doane via R-SIG-Mac 
>  wrote:
> 
> Hi,
> 
> I would like to use blas from Apple�s Accelerate framework instead of the 
> reference R blas in R 4.1.0.  The 
> FAQ
>  indicates that two Rblas shared libraries are supplied, 
> libRblas.vecLib.dylib which uses vecLib BLAS and libRblas.0.dylib which uses 
> reference BLAS from R.  However, in the current release 4.1 and 4.1-patched 
> binaries, I only see the reference blas.  Does the answer in the FAQ no 
> longer apply?  I am on Mac OS 11.4, and installed in the default location and 
> looking for the blas libraries here: 
> /Library/Frameworks/R.framework/Versions/Current/Resources/lib.  I am looking 
> in the wrong place?
> 
> Best,
> Ashley
> 
> Ashley Stephen Doane, Ph.D.
> Postdoctoral Research Associate
> 
> Weill Cornell Medicine
> Elemento Lab
> Institute for Computaional Biomedicine
> asd2...@med.cornell.edu
> 
> 
>   [[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] Corrupt R installation

2021-06-09 Thread Simon Urbanek


Um, this is actually a lot easier purely with R - if you want to keep track of 
your favorite packages it is as simple as

pkgs = rownames(installed.packages())
writeLines(pkgs, "packages.txt")

and oyu have a list of all packages that you can edit if desired. if you ever 
want to re-install then simply

pkgs = readLines("packages.txt")
install.packages(pkgs)

and if you only want to install missing it's simply

missing.pkgs = pkgs[!pkgs %in% rownames(installed.packages())]
install.packages(missing.pkgs)

All trivially done in R. It is always beyond me why people come up with 
incredibly convoluted solutions to simple things ..

Cheers,
Simon



> On 9/06/2021, at 8:55 PM, Dr Eberhard Lisse  wrote:
> 
> On 08/06/2021 22:46, moleps islon wrote:
> [...]
>> I have no idea why, but my R installation (Mac OS X - Big Sur)
>> automatically updates causing havoc with my libraries each time.  My
>> Mac is under administration from the university and their software
>> center, but they claim it is not their fault - but I still suspect
>> them for causing all the trouble.
> [...]
> 
> Sounds like Homebrew to me.  If so, or anyway, create a file (before
> updating) which contains something like
> 
>#!/usr/bin/env Rscript --vanilla
>#
># set the Mirror
>#
>local({
>   r <- getOption("repos")
>r["CRAN"] <- "https://cloud.r-project.org/;
>   options(repos = r)
>})
>install.packages(c(
> "lubridate",
> "tidyverse"
>), dependencies = TRUE)
> 
> 
> or similar and run it if the additional libraries disappear.
> 
> You can fill this with something like
> 
>grep -h library *R \
>|awk -F 'library' '{print $2}' \
>|sed 's/(//g;s/)//g' \
>|sort -u \
>|awk '{print "\"" $1 "\","}'
>|sed '$ s/,$//'
> 
> or in a few lines of the language of your choice generate the whole
> script. And of course refine to your liking with something like
> 
>find ~/R -name '*.R' -exec grep -h library {} ';' \
>...
> 
> greetings, el
> 
> -- 
> To email me replace 'nospam' with 'el'
> 
> ___
> 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] Corrupt R installation

2021-06-08 Thread Simon Urbanek


You seem to have entirely non-standard setup that you're on your own and I 
assume you're not using CRAN R since you involve homebrew (which explains the 
chaos) so presumably you re-compiled R yourself and all packages, but I'd like 
to point out that if all you are after is OpenMP support then you don't need 
any of that fragile mess as explained at https://mac.r-project.org/openmp/

Cheers,
Simon


> On 9/06/2021, at 8:46 AM, moleps islon  wrote:
> 
> Copied from SO (
> https://stackoverflow.com/questions/67892321/major-r-installation-corruption)
> and sent here instead at the suggestion of  Dirk Eddelbuettel
> 
> 
> I have no idea why, but my R installation (Mac OS X - Big Sur)
> automatically updates causing havoc with my libraries each time. My Mac is
> under administration from the university and their software center, but
> they claim it is not their fault - but I still suspect them for causing all
> the trouble.
> 
> Anyhow - after that last update to 4.1.0 the packages were again all lost.
> I tried a dirty hack just symlinking to the old version and updating (I
> know-- very stupid, but I didnt have time for a major update of all the
> packages), but after this my R-installation has been totally chaos for the
> past week. I´ve reinstalled everything multiple times (brew, llvm, gcc,
> CLI, X-code -- you name it) and I´ve finally managed to get data.table
> working again with openMP support using the instructions at SO
> 
> (
> https://stackoverflow.com/questions/65251887/clang-7-error-linker-command-failed-with-exit-code-1-for-macos-big-sur/65334247#65334247
> ).
> 
> However I still get the following error message when installing data.table
> from source:
> 
> dylib (/usr/local/opt/llvm/lib/libunwind.dylib) was built for newer macOS
> version (11.0) than being linked (10.16)
> Does it matter? Any idea how I can fix it?
> 
>   [[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] I cannot download "updateR" package for macOS

2021-06-08 Thread Simon Urbanek


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

Cheers,
Simon



> On 9/06/2021, at 2:58 AM, Shehu Usman Gulumbe  wrote:
> 
> I have trying to download the “updateR” package for my Mac Pro but have been 
> getting the following error message :
> 
>> library(devtools)
>> install_github("andreacirilloac/updateR")
> Downloading GitHub repo andreacirilloac/updateR@HEAD
> Error in utils::download.file(url, path, method = method, quiet = quiet,  : 
>  download from 
> 'https://api.github.com/repos/andreacirilloac/updateR/tarball/HEAD’ failed
> 
> 
> I would appreciate any help on this.
> 
> 
> Usman
>   [[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] Grids not showing

2021-06-07 Thread Simon Urbanek


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

Cheers,
Simon


> On Jun 8, 2021, at 2:22 AM, Parkhurst, David  wrote:
> 
> Avi Gross has been helping me with ggplot lattice plots.  When he sends me 
> graphs he has created (on a windows computer I think), if I view those on my 
> iPad I can see a vague grid in the background on each panel.  I would like to 
> have that effect in the graphs I produce.  However, when I view his graphs on 
> my iMac, or if I use his code to produce a graph on my iMac, the grids 
> disappear.  How can I get the grids to show in the graphs I produce?
> 
>   [[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] tcltk on M1 mac?

2021-05-25 Thread Simon Urbanek


Rich,

I think tcltk attempts to find the location of the libraries via otool from 
Xcode tools so it can tell you to install the missing libraries if you didn't 
(otherwise it would just crash). I agree that it may be worthwhile to just 
silence the warning when you are missing xcrun, since XCode is not a 
requirement at run time, so you can file a bug report. It's just a benign 
warning since the non-existence of xcrun doesn't prevent from running 
eventually.

As for XQuartz, we already do say that explicitly on the CRAN page (with a link 
to XQuartz 2.8.1):
"Note: the use of X11 (including tcltk) requires XQuartz. Always re-install 
XQuartz when upgrading your macOS to a new major version."

Cheers,
Simon



> On 26/05/2021, at 4:20 AM, Richard M. Heiberger  wrote:
> 
> I just upgraded from XQuartz 2.7.11 to the current 2.8.1, and then rebooted 
> the Mac M1.
> 
> tcltk now loads and gives warnings:
> 
> 
> R version 4.1.0 Patched (2021-05-23 r80364) -- "Camp Pontanezen"
> Copyright (C) 2021 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()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
> 
>> setwd('/Users/rmh/Rwd/')
>> library(tcltk)
> xcrun: error: invalid active developer path 
> (/Library/Developer/CommandLineTools), missing xcrun at: 
> /Library/Developer/CommandLineTools/usr/bin/xcrun
> Warning message:
> In system2("/usr/bin/otool", c("-L", shQuote(DSO)), stdout = TRUE) :
>  running command ''/usr/bin/otool' -L 
> '/Library/Frameworks/R.framework/Resources/library/tcltk/libs//tcltk.so'' had 
> status 1
>> search()
> [1] ".GlobalEnv""package:tcltk" "ESSR" 
> [4] "package:stats" "package:graphics"  "package:grDevices"
> [7] "package:utils" "package:datasets"  "package:methods"  
> [10] "Autoloads" "package:base" 
>> 
> 
> 
> There are fewer messages than before.
> tcltk now loads with warnings.
> Rcmdr now loads.
> 
> What should I do about xcrun and otool?
> 
> Simon, can you add a note to the CRAN download page that XQuartz 2.8.1 is 
> needed for the Mac M1.
> 
> Rich
> 
> 
>> On May 25, 2021, at 01:36, Simon Urbanek  wrote:
>> 
>> Rich,
>> you need to instal XQuartz (see instructions on the CRAN page).
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> On 25/05/2021, at 4:02 PM, Richard M. Heiberger  wrote:
>>> 
>>> I am not seeing tcltk in either the released R
>>> R version 4.1.0 (2021-05-18) -- "Camp Pontanezen"
>>> Copyright (C) 2021 The R Foundation for Statistical Computing
>>> Platform: aarch64-apple-darwin20 (64-bit)
>>> 
>>> 
>>> or the nightly
>>> R version 4.1.0 Patched (2021-05-23 r80364) -- "Camp Pontanezen"
>>> Copyright (C) 2021 The R Foundation for Statistical Computing
>>> Platform: aarch64-apple-darwin20 (64-bit)
>>> 
>>> that I just downloaded.
>>> 
>>> Here is the transcript
>>> 
>>> R version 4.1.0 Patched (2021-05-23 r80364) -- "Camp Pontanezen"
>>> Copyright (C) 2021 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()' for some demos, 'help()' for on-line help, or
>>> 'help.start()' for an HTML browser interface to help.
>>> Type 'q()' to quit R.
>>> 
>>>> setwd('/Users/rmh/Rwd/')
>>>> library(tcltk)
>>> xcrun: error: invalid active developer path 
>>

Re: [R-SIG-Mac] rlang and the new R version 4.1.0

2021-05-25 Thread Simon Urbanek


Hans,

you have to re-install *all* packages whenever you upgrade R. R only guarantees 
compatibility between patch versions (i.e. upgrading from R 4.0.0 to 4.0.1 does 
not require re-install, but from R 4.0.0 to R 4.1.0 does). That was always the 
case on all platforms, it's not new.

Note that the R Mac GUI makes the upgrade easier - in the Package Manager you 
can select to install package from previous R version if you use the system 
location. Otherwise you can always use simply 

install.packages(rownames(installed.packages("path-to-old-library")))

Cheers,
Simon



> On 26/05/2021, at 7:58 AM, Hans W  wrote:
> 
> Following this tip I had to remove and reinstall one after the other
> the following packages:
> 
>rvest, rlang, magrittr, xml2, stringi, ellipsis,
>fansi, utf8, vctrs, tibble, Rcpp, lbfgs, and GauPro
> 
> each time restarting R to make sure. Then the application worked again.
> Does this mean I would be better off deleting all of my installed
> packages and starting a fresh R?
> Was this even a requirement for installing R version 4.1 on macOS -- a
> requirement I didn't get?
> 
> Thanks for the help  --HW
> 
> 
> On Tue, 25 May 2021 at 20:31, Kevin Ushey  wrote:
>> 
>> This error:
>> 
>>Error: package or namespace load failed for ‘rlang’ in
>>get(Info[i, 1], envir = env): lazy-load database
>>'/Users/hwb/Library/R/4.0/library/rlang/R/rlang.rdb' is corrupt
>>In addition: Warning message:
>>In get(Info[i, 1], envir = env) : internal error -3 in R_decompress1
>> 
>> is commonly seen when reinstalling an already-installed package. See
>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16644 for more
>> details.
>> 
>> The resolution is to restart R after reinstalling an already-loaded package.
>> 
>> Best,
>> Kevin
> 
> ___
> 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 Checks for R-Release appear to use R-Devel

2021-05-25 Thread Simon Urbanek


Marc,

thanks, now it makes sense to me. Yes, the checks results don't seem to be 
synced and it is also missing the arm64 checks. I'll investigate.

Thanks,
Simon


> On May 26, 2021, at 8:35 AM, Marc Schwartz  wrote:
> 
> Hi,
> 
> This is in reply to Simon's request that I post on this topic separately from 
> Hans' prior thread on rlang related problems.
> 
> In the course of looking at a few CRAN packages for that thread, including my 
> own, I noted on the CRAN checks page for each package, that the results logs 
> indicate the use of "R Under development", rather than the current R release 
> version.
> 
> Specific example:
> 
> The CRAN check page for rlang:
> 
> https://cran.r-project.org/web/checks/check_results_rlang.html
> 
> shows in row 10:
> 
> r-release-macos-x86_64  OK
> 
> If I click on OK to get the CRAN check log with the following URL:
> 
> https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/rlang-00check.html
> 
> noting that the above URL shows:
> 
> .../r-release-macos-x86_64/...
> 
> However, the log header shows:
> 
> "using R Under development (unstable) (2021-02-19 r80028)"
> 
> Thus, if I read correctly, while the link should be for the CRAN check 
> results log for the package using R release (4.1.0), it appears to be using 
> an R development version from February 19, 2021.
> 
> If I check the same R Release logs for Linux and Windows for rlang:
> 
> https://www.r-project.org/nosvn/R.check/r-release-linux-x86_64/rlang-00check.html
> 
> and:
> 
> https://www.r-project.org/nosvn/R.check/r-release-windows-ix86+x86_64/rlang-00check.html
> 
> respectively, both indicate:
> 
> using R version 4.1.0 (2021-05-18)
> 
> in the log headers.
> 
> If I check the rlang logs for other OSs on "r-devel", they indicate:
> 
> "using R Under development (unstable) (2021-05-20 r80347)"
> 
> Thus, a more recent development version of R from May 20, 2021.
> 
> So, perhaps naively, I would presume a configuration issue for the macOS 
> binaries on CRAN.
> 
> Simon, does that clarify the point I was making in the prior thread?
> 
> Thanks,
> 
> Marc
> 

___
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] tcltk on M1 mac?

2021-05-25 Thread Simon Urbanek


Roy,

that discussion was on Intel Mac when XQuartz was in beta and thus breaking. In 
the meantime there is now stable XQuartz 2.8.1 and you can use either version 
on Intel (we do build agains 2.7.1 for compatibility). But there is no XQuartz 
2.7.x for M1 so you can only use the latest version there.

Cheers,
Simon


> On May 26, 2021, at 2:44 AM, Roy Mendelssohn - NOAA Federal 
>  wrote:
> 
> I seem to remember a discussion not too long ago that the very latest version 
> fo XQuartz did not install all the libraries needed by R, and to install the 
> previous on instead  (I hav XQuartz 2.7.11, the latest is 2.8.1).  Is this 
> still the case?
> 
> Thanks,
> 
> -Roy
> 
>> On May 24, 2021, at 10:36 PM, Simon Urbanek  
>> wrote:
>> 
>> 
>> Rich,
>> you need to instal XQuartz (see instructions on the CRAN page).
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> On 25/05/2021, at 4:02 PM, Richard M. Heiberger  wrote:
>>> 
>>> I am not seeing tcltk in either the released R
>>> R version 4.1.0 (2021-05-18) -- "Camp Pontanezen"
>>> Copyright (C) 2021 The R Foundation for Statistical Computing
>>> Platform: aarch64-apple-darwin20 (64-bit)
>>> 
>>> 
>>> or the nightly
>>> R version 4.1.0 Patched (2021-05-23 r80364) -- "Camp Pontanezen"
>>> Copyright (C) 2021 The R Foundation for Statistical Computing
>>> Platform: aarch64-apple-darwin20 (64-bit)
>>> 
>>> that I just downloaded.
>>> 
>>> Here is the transcript
>>> 
>>> R version 4.1.0 Patched (2021-05-23 r80364) -- "Camp Pontanezen"
>>> Copyright (C) 2021 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()' for some demos, 'help()' for on-line help, or
>>> 'help.start()' for an HTML browser interface to help.
>>> Type 'q()' to quit R.
>>> 
>>>> setwd('/Users/rmh/Rwd/')
>>>> library(tcltk)
>>> xcrun: error: invalid active developer path 
>>> (/Library/Developer/CommandLineTools), missing xcrun at: 
>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>> Error: package or namespace load failed for ‘tcltk’:
>>> .onLoad failed in loadNamespace() for 'tcltk', details:
>>> call: dyn.load(file, DLLpath = DLLpath, ...)
>>> error: unable to load shared object 
>>> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so':
>>> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so,
>>>  10): Library not loaded: /opt/X11/lib/libX11.6.dylib
>>> Referenced from: 
>>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so
>>> Reason: no suitable image found.  Did find:
>>> /opt/X11/lib/libX11.6.dylib: no matching architecture in universal 
>>> wrapper
>>> /opt/X11/lib/libX11.6.dylib: no matching architecture in universal 
>>> wrapper
>>> In addition: Warning message:
>>> In system2("/usr/bin/otool", c("-L", shQuote(DSO)), stdout = TRUE) :
>>> running command ''/usr/bin/otool' -L 
>>> '/Library/Frameworks/R.framework/Resources/library/tcltk/libs//tcltk.so'' 
>>> had status 1
>>>> 
>>> 
>>> 
>>>> On May 14, 2021, at 19:57, Simon Urbanek  
>>>> wrote:
>>>> 
>>>> 
>>>> Vince,
>>>> 
>>>> please try the latest build, Tcl/Tk should be included now.
>>>> 
>>>> Thanks,
>>>> Simon
>>>> 
>>>> 
>>>> 
>>>>> On May 14, 2021, at 7:45 AM, Simon Urbanek  
>>>>> wrote:
>>>>> 
>>>>> Vince,
>>>>> 
>>>>> Thanks for the report, yes, that is a known problem, because the R 
>>>>> installer for arm64 doesn't include Tcl/Tk unlike the Intel version. It 
>>>>> is a long story, but I hope to update the installer soon.
>>>

Re: [R-SIG-Mac] rlang and the new R version 4.1.0

2021-05-25 Thread Simon Urbanek


Hans,

you seem to be using old library from 4.0 (see the 4.0 in the path). Make sure 
you remove old packages and use a clean library for 4.1 since you cannot mix 
packages from R 4.0.x and R 4.1.0. I would best recommend removing (or 
re-naming) ~/Library/R before installation to make sure you don't have 
incompatible old packages. Also don't forget to re-start R.

(Marc, I can't parse your post, it makes no sense to me, there no R-devel 
involved in any of this, so please post separately about whatever is on your 
heart as that doesn't seem to be related).

Cheers,
Simon



> On May 26, 2021, at 2:06 AM, Marc Schwartz  wrote:
> 
> Hi,
> 
> You might try a different CRAN mirror to see if perhaps the rlang binary that 
> you are getting is corrupted.
> 
> Looking at CRAN for the package, the results for rlang on what is supposed to 
> be R release on macOS:
> 
>  https://cran.r-project.org/web/checks/check_results_rlang.html
> 
> shows a header indicating that R devel is being used, not R release:
> 
> https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/rlang-00check.html
> 
> So, I am not clear if there is a macOS binary build issue that may be 
> resulting in a conflict of sorts.
> 
> A spot check of other CRAN packages (including my own) shows the same use of 
> R devel for macOS, and not R release, so perhaps there is a wider issue going 
> on with CRAN builds, unless I am missing something here.
> 
> Simon (cc'd now) may be able to address that issue.
> 
> Regards,
> 
> Marc Schwartz
> 
> 
> Hans W wrote on 5/25/21 9:16 AM:
>> I installed the new R version 4.1.0 on my (normal) Macbook, and
>> everything seemed to work fine until one of the packages depended on
>> the 'rlang' package and I got the following error:
>> > library(rlang)
>> Error: package or namespace load failed for ‘rlang’ in
>> dyn.load(file, DLLpath = DLLpath, ...): unable to load
>> shared object '/Users/hwb/Library/R/4.0/library/rlang/libs/rlang.so':
>> dlopen(/Users/hwb/Library/R/4.0/library/rlang/libs/rlang.so, 6):
>> Library not loaded:
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libR.dylib
>> Referenced from: /Users/hwb/Library/R/4.0/library/rlang/libs/rlang.so
>> Reason: image not found
>> So I removed 'rlang' and reinstalled it. There was no error message,
>> but when I tried to load it, the error message was:
>> Error: package or namespace load failed for ‘rlang’ in
>> get(Info[i, 1], envir = env): lazy-load database
>> '/Users/hwb/Library/R/4.0/library/rlang/R/rlang.rdb' is corrupt
>> In addition: Warning message:
>> In get(Info[i, 1], envir = env) : internal error -3 in R_decompress1
>> One of my current applications relies on 'rvest' which depends on
>> 'rlang'. For the moment I am using it from a Linux computer, but it's
>> quite unfortunate that I cannot run it from macOS as well.
>> I also uninstalled the new R version and reinstalled it, but nothing
>> changed. Could you give me a hint on what to do (or what I did wrong)?
>> ___
>> 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] tcltk on M1 mac?

2021-05-24 Thread Simon Urbanek


Rich,
you need to instal XQuartz (see instructions on the CRAN page).
Cheers,
Simon



> On 25/05/2021, at 4:02 PM, Richard M. Heiberger  wrote:
> 
> I am not seeing tcltk in either the released R
> R version 4.1.0 (2021-05-18) -- "Camp Pontanezen"
> Copyright (C) 2021 The R Foundation for Statistical Computing
> Platform: aarch64-apple-darwin20 (64-bit)
> 
> 
> or the nightly
> R version 4.1.0 Patched (2021-05-23 r80364) -- "Camp Pontanezen"
> Copyright (C) 2021 The R Foundation for Statistical Computing
> Platform: aarch64-apple-darwin20 (64-bit)
> 
> that I just downloaded.
> 
> Here is the transcript
> 
> R version 4.1.0 Patched (2021-05-23 r80364) -- "Camp Pontanezen"
> Copyright (C) 2021 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()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
> 
>> setwd('/Users/rmh/Rwd/')
>> library(tcltk)
> xcrun: error: invalid active developer path 
> (/Library/Developer/CommandLineTools), missing xcrun at: 
> /Library/Developer/CommandLineTools/usr/bin/xcrun
> Error: package or namespace load failed for ‘tcltk’:
> .onLoad failed in loadNamespace() for 'tcltk', details:
>  call: dyn.load(file, DLLpath = DLLpath, ...)
>  error: unable to load shared object 
> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so':
>  
> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so,
>  10): Library not loaded: /opt/X11/lib/libX11.6.dylib
>  Referenced from: 
> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so
>  Reason: no suitable image found.  Did find:
>   /opt/X11/lib/libX11.6.dylib: no matching architecture in universal 
> wrapper
>   /opt/X11/lib/libX11.6.dylib: no matching architecture in universal 
> wrapper
> In addition: Warning message:
> In system2("/usr/bin/otool", c("-L", shQuote(DSO)), stdout = TRUE) :
>  running command ''/usr/bin/otool' -L 
> '/Library/Frameworks/R.framework/Resources/library/tcltk/libs//tcltk.so'' had 
> status 1
>> 
> 
> 
>> On May 14, 2021, at 19:57, Simon Urbanek  wrote:
>> 
>> 
>> Vince,
>> 
>> please try the latest build, Tcl/Tk should be included now.
>> 
>> Thanks,
>> Simon
>> 
>> 
>> 
>>> On May 14, 2021, at 7:45 AM, Simon Urbanek  
>>> wrote:
>>> 
>>> Vince,
>>> 
>>> Thanks for the report, yes, that is a known problem, because the R 
>>> installer for arm64 doesn't include Tcl/Tk unlike the Intel version. It is 
>>> a long story, but I hope to update the installer soon.
>>> 
>>> Thanks,
>>> Simon
>>> 
>>> 
>>>> On May 14, 2021, at 02:47, Vincent Carey  
>>>> wrote:
>>>> 
>>>> I can't seem to get tcltk running with R on M1 machine.  Homebrew tcltk
>>>> seems to have wrong architecture; attempt to build from source does not
>>>> help.  Any hints appreciated.
>>>> 
>>>> 
>>>> R version 4.1.0 RC (2021-05-10 r80283) -- "Camp Pontanezen"
>>>> 
>>>> Copyright (C) 2021 The R Foundation for Statistical Computing
>>>> 
>>>> Platform: aarch64-apple-darwin20 (64-bit)
>>>> 
>>>> 
>>>>> library(tcltk)
>>>> 
>>>> *Error: package or namespace load failed for 'tcltk':*
>>>> 
>>>> * .onLoad failed in loadNamespace() for 'tcltk', details:*
>>>> 
>>>> *  call: dyn.load(file, DLLpath = DLLpath, ...)*
>>>> 
>>>> *  error: unable to load shared object
>>>> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so':*
>>>> 
>>>> *
>>>> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so,
>>>> 10): Library not loaded: 
>>>> /Library/Frameworks/Tcl.framework/Versions/8.6/Tcl*
>>>> 
>>>> *  Referenced fro

Re: [R-SIG-Mac] R 4.1 for my Mac M1 crashing on installing packages

2021-05-22 Thread Simon Urbanek


Roy,

yes, note that we are talking about the the Big Sur arm64 build. I would still 
recommend using the "stable" High Sierra Intel build if you prefer stability 
over speed.

And, yes, if you depend on/import a package that doesn't pass tests, your 
package won't be available, either. If you have a package in Suggests, then you 
hopefully wrote your examples/test such that it works even when that package is 
not available.

Cheers,
Simon



> On May 23, 2021, at 10:15 AM, Roy Mendelssohn - NOAA Federal 
>  wrote:
> 
> Hi Simon:
> 
> So perhaps the take-home message is that if you depend on that suite of 
> packages,  perhaps the time is not ripe to update to R4.1?
> 
> Also wondering how this will affect CRAN checks for packages that have on of 
> those packages as "Suggest" or "Depend"?
> 
> Thanks,
> -Roy
> 
>> On May 22, 2021, at 2:57 PM, Simon Urbanek  
>> wrote:
>> 
>> 
>> Renato,
>> 
>> rgdal didn't pass checks in the big-sur build, that's why it was not 
>> available. rgdal has a very long list of dependencies that are very fragile, 
>> so it is quite hard to build yourself (you'd need to build and compile quite 
>> a few libraries).
>> For now I have temporarily disabled the checks for some of the spatial 
>> libraries like sf and rdgal since they don't pass them, but it would be good 
>> if the issues could be sorted out upstream.
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>>> On May 22, 2021, at 12:31 PM, Renato Morais  
>>> wrote:
>>> 
>>> Hi Simon and all,
>>> 
>>> After reinstalling the official binary and reinstalling all packages, 
>>> almost everything is working fine. The only exception is rgdal, which is 
>>> not available as a binary and, when I try to compile it, I get the error 
>>> below. I did extract gFortran from the link you provided and moved it to 
>>> the folder /opt/R/arm64 as indicated on CRAN (print screen below).
>>> 
>>> Anything I'm clearly doing wrong? I appreciate the help.
>>> 
>>> Cheers and thanks again,
>>> Renato
>>> 
>>>> install.packages('rgdal')
>>> Package which is only available in source form, and may need compilation of 
>>> C/C++/Fortran: ‘rgdal’
>>> Do you want to attempt to install these from sources? (Yes/no/cancel) yes
>>> installing the source package ‘rgdal’
>>> 
>>> trying URL 'https://cran.csiro.au/src/contrib/rgdal_1.5-23.tar.gz'
>>> Content type 'application/x-gzip' length 4393536 bytes (4.2 MB)
>>> ==
>>> downloaded 4.2 MB
>>> 
>>> configure: R_HOME: /Library/Frameworks/R.framework/Resources
>>> configure: CC: clang -arch arm64
>>> configure: CXX: clang++ -arch arm64 -std=gnu++14
>>> configure: CFLAGS: -falign-functions=64 -Wall -g -O2
>>> configure: CPPFLAGS: -I/opt/R/arm64/include
>>> configure: CXXFLAGS: -falign-functions=64 -Wall -g -O2
>>> configure: LDFLAGS: -L/opt/R/arm64/lib
>>> configure: LDFLAGS: -L/opt/R/arm64/lib
>>> configure: CXX11 is: clang++ -arch arm64, CXX11STD is: -std=gnu++11
>>> configure: CXX is: clang++ -arch arm64 -std=gnu++11
>>> configure: C++11 support available
>>> configure: rgdal: 1.5-23
>>> checking for /usr/bin/svnversion... no
>>> configure: svn revision: 1121
>>> checking for gdal-config... no
>>> no
>>> 
>>> The downloaded source packages are in
>>> 
>>> ‘/private/var/folders/g0/k2tmg4q931s1x3cy_vm_m4crgn/T/RtmpydK1sm/downloaded_packages’
>>> Warning message:
>>> In install.packages("rgdal") :
>>> installation of package ‘rgdal’ had non-zero exit status
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, 20 May 2021 at 11:46, Simon Urbanek  
>>> wrote:
>>> I was able to replicate the problem - it is a bug in select.list() in the 
>>> R.app GUI and it is present in both the Intel and the arm64 version of R 
>>> 4.1.0 so it is not M1-specific.
>>> 
>>> The work-around is as Jeroen said to set
>>> options(menu.graphics=FALSE)
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 20/05/2021, at 12:28 PM, Renato Morais  
>>>> wrote:
>>>> 
>>>> Hi Simon,
>>>> 
>>>> I'll attach the crash reports available, I hope that helps and sorry 
>&

Re: [R-SIG-Mac] R 4.1 for my Mac M1 crashing on installing packages

2021-05-22 Thread Simon Urbanek


Renato,

rgdal didn't pass checks in the big-sur build, that's why it was not available. 
rgdal has a very long list of dependencies that are very fragile, so it is 
quite hard to build yourself (you'd need to build and compile quite a few 
libraries).
For now I have temporarily disabled the checks for some of the spatial 
libraries like sf and rdgal since they don't pass them, but it would be good if 
the issues could be sorted out upstream.

Cheers,
Simon



> On May 22, 2021, at 12:31 PM, Renato Morais  
> wrote:
> 
> Hi Simon and all,
> 
> After reinstalling the official binary and reinstalling all packages, almost 
> everything is working fine. The only exception is rgdal, which is not 
> available as a binary and, when I try to compile it, I get the error below. I 
> did extract gFortran from the link you provided and moved it to the folder 
> /opt/R/arm64 as indicated on CRAN (print screen below).
> 
> Anything I'm clearly doing wrong? I appreciate the help.
> 
> Cheers and thanks again,
> Renato
> 
> > install.packages('rgdal')
> Package which is only available in source form, and may need compilation of 
> C/C++/Fortran: ‘rgdal’
> Do you want to attempt to install these from sources? (Yes/no/cancel) yes
> installing the source package ‘rgdal’
> 
> trying URL 'https://cran.csiro.au/src/contrib/rgdal_1.5-23.tar.gz'
> Content type 'application/x-gzip' length 4393536 bytes (4.2 MB)
> ==
> downloaded 4.2 MB
> 
> configure: R_HOME: /Library/Frameworks/R.framework/Resources
> configure: CC: clang -arch arm64
> configure: CXX: clang++ -arch arm64 -std=gnu++14
> configure: CFLAGS: -falign-functions=64 -Wall -g -O2
> configure: CPPFLAGS: -I/opt/R/arm64/include
> configure: CXXFLAGS: -falign-functions=64 -Wall -g -O2
> configure: LDFLAGS: -L/opt/R/arm64/lib
> configure: LDFLAGS: -L/opt/R/arm64/lib
> configure: CXX11 is: clang++ -arch arm64, CXX11STD is: -std=gnu++11
> configure: CXX is: clang++ -arch arm64 -std=gnu++11
> configure: C++11 support available
> configure: rgdal: 1.5-23
> checking for /usr/bin/svnversion... no
> configure: svn revision: 1121
> checking for gdal-config... no
> no
> 
> The downloaded source packages are in
>   
> ‘/private/var/folders/g0/k2tmg4q931s1x3cy_vm_m4crgn/T/RtmpydK1sm/downloaded_packages’
> Warning message:
> In install.packages("rgdal") :
>   installation of package ‘rgdal’ had non-zero exit status
> 
> 
> 
> 
> 
> 
> 
> On Thu, 20 May 2021 at 11:46, Simon Urbanek  
> wrote:
> I was able to replicate the problem - it is a bug in select.list() in the 
> R.app GUI and it is present in both the Intel and the arm64 version of R 
> 4.1.0 so it is not M1-specific.
> 
> The work-around is as Jeroen said to set
> options(menu.graphics=FALSE)
> 
> Cheers,
> Simon
> 
> 
> 
> 
> 
> > On 20/05/2021, at 12:28 PM, Renato Morais  
> > wrote:
> > 
> > Hi Simon,
> > 
> > I'll attach the crash reports available, I hope that helps and sorry 
> > there's probably repeated crash reports, as I repeatedly tried the same 
> > things.
> > 
> > So, relative to the source packages there's actually nothing I can do for 
> > now?
> > 
> > Thanks for the attention,
> > Renato
> > 
> > On Thu, 20 May 2021 at 08:52, Simon Urbanek  
> > wrote:
> > Renato,
> > 
> > just open the Console application (under Utilities) - it has all logs from 
> > your machine - there will be either an R crash log or some entries in the 
> > system log.
> > 
> > As for packages, it will be solved once the R 4.1.0 binaries for arm64 are 
> > released (as soon as all builds finish), but you will have to make sure you 
> > re-install all packages to remove the pre-releases.
> > 
> > Thanks,
> > Simon
> > 
> > 
> > 
> > > On 20/05/2021, at 10:27 AM, Renato Morais  
> > > wrote:
> > > 
> > > Hi Simon,
> > > 
> > > I'm happy to, I'm just not sure how to check previous logs...
> > > 
> > > On another note, and I'm sure this is a problem with the compiler, now 
> > > that my packages are installed, the ones I had to compile from the source 
> > > cannot be loaded.
> > > 
> > > Error: package or namespace load failed for ‘nlme’ in dyn.load(file, 
> > > DLLpath = DLLpath, ...):
> > >  unable to load shared object 
> > > '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so':
> > >   
> > > dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/

Re: [R-SIG-Mac] R 4.1 for my Mac M1 crashing on installing packages

2021-05-19 Thread Simon Urbanek


I was able to replicate the problem - it is a bug in select.list() in the R.app 
GUI and it is present in both the Intel and the arm64 version of R 4.1.0 so it 
is not M1-specific.

The work-around is as Jeroen said to set
options(menu.graphics=FALSE)

Cheers,
Simon





> On 20/05/2021, at 12:28 PM, Renato Morais  
> wrote:
> 
> Hi Simon,
> 
> I'll attach the crash reports available, I hope that helps and sorry there's 
> probably repeated crash reports, as I repeatedly tried the same things.
> 
> So, relative to the source packages there's actually nothing I can do for now?
> 
> Thanks for the attention,
> Renato
> 
> On Thu, 20 May 2021 at 08:52, Simon Urbanek  
> wrote:
> Renato,
> 
> just open the Console application (under Utilities) - it has all logs from 
> your machine - there will be either an R crash log or some entries in the 
> system log.
> 
> As for packages, it will be solved once the R 4.1.0 binaries for arm64 are 
> released (as soon as all builds finish), but you will have to make sure you 
> re-install all packages to remove the pre-releases.
> 
> Thanks,
> Simon
> 
> 
> 
> > On 20/05/2021, at 10:27 AM, Renato Morais  
> > wrote:
> > 
> > Hi Simon,
> > 
> > I'm happy to, I'm just not sure how to check previous logs...
> > 
> > On another note, and I'm sure this is a problem with the compiler, now that 
> > my packages are installed, the ones I had to compile from the source cannot 
> > be loaded.
> > 
> > Error: package or namespace load failed for ‘nlme’ in dyn.load(file, 
> > DLLpath = DLLpath, ...):
> >  unable to load shared object 
> > '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so':
> >   
> > dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so,
> >  6): Library not loaded: /opt/R/arm64/gfortran/lib/libgfortran.5.dylib
> >   Referenced from: 
> > /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so
> >   Reason: image not found
> > 
> > Any insights on how that could be solved?
> > 
> > Thanks again for your help,
> > Renato
> > 
> > On Thu, 20 May 2021 at 07:00, Simon Urbanek  
> > wrote:
> > Renato,
> > 
> > I'm glad you have work-around, but I'd still like to get to the core of the 
> > issue, we don't want R to crash ;).
> > Can you, please, check your Console log to see if there is a trace of the 
> > crash and if so, send it to me?
> > Also are you using R in the Terminal or the R.app GUI?
> > 
> > Thanks,
> > Simon
> > 
> > 
> > > On 20/05/2021, at 12:07 AM, Renato Morais  
> > > wrote:
> > > 
> > > Thanks Jeroen, fixing the repo connected me with CRAN (it was defaulted to
> > > '@CRAN@' I think)!
> > > 
> > > Cheers,
> > > Renato
> > > 
> > > On Wed, 19 May 2021 at 21:00, Jeroen Ooms  wrote:
> > > 
> > >> On Wed, May 19, 2021 at 11:34 AM Renato Morais
> > >>  wrote:
> > >>> 
> > >>> Hi all,
> > >>> 
> > >>> I'm new here, so please forgive my clumsy error reporting.
> > >>> 
> > >>> I have just downloaded *R-4.1-branch.pkg* for my Mac M1, as I wanted to
> > >>> finally enjoy a native normal-speed R (for some reason running v 4.0.5 
> > >>> on
> > >>> Rosetta was extremely slow on my machine). I also installed the latest
> > >>> XQuartz, as indicated (v 2.8.1).
> > >>> 
> > >>> Sad story is, when I try a simple install.packages command, it first
> > >>> appears to ignore me, after returning 'Please select a CRAN mirror for
> > >> use
> > >>> in this session'. if I insist, it crashes. No useful error messages.
> > >> Trying
> > >>> via the Package Installer tab didn't work either. It doesn't find any
> > >>> packages, indeed it crashes if I ask it to load the list.
> > >> 
> > >> This indeed sounds like an xQuartz issue, failing to popup the mirror
> > >> selection menu. Does everything work if you manually set your CRAN
> > >> mirror first, e.g:
> > >> 
> > >>  options(repos=c(CRAN="https://cloud.r-project.org;))
> > >> 
> > >> Alternatively you can disable the popup menus all-together using:
> > >> 
> > >>  options(menu.graphics=FALSE)
> > >> 
> > >> Which should probably be the default

Re: [R-SIG-Mac] R 4.1 for my Mac M1 crashing on installing packages

2021-05-19 Thread Simon Urbanek


Thanks for the logs. Unfortunately, there is no obvious reason for the R crash 
so I'll need to see if I can replicate it.

As for packages, well, there is if you are really that impatient you can either 
change the path to the R framework in the package instead of /opt/R or you can 
install the Fortran compiler from
https://mac.r-project.org/libs-arm64/gfortran-f51f1da0-darwin20.0-arm64.tar.gz
but I don't quite see why you would go into all the trouble just to run the old 
experimental binaries instead of the release.

Cheers,
Simon


> On 20/05/2021, at 12:28 PM, Renato Morais  
> wrote:
> 
> Hi Simon,
> 
> I'll attach the crash reports available, I hope that helps and sorry there's 
> probably repeated crash reports, as I repeatedly tried the same things.
> 
> So, relative to the source packages there's actually nothing I can do for now?
> 
> Thanks for the attention,
> Renato
> 
> On Thu, 20 May 2021 at 08:52, Simon Urbanek  
> wrote:
> Renato,
> 
> just open the Console application (under Utilities) - it has all logs from 
> your machine - there will be either an R crash log or some entries in the 
> system log.
> 
> As for packages, it will be solved once the R 4.1.0 binaries for arm64 are 
> released (as soon as all builds finish), but you will have to make sure you 
> re-install all packages to remove the pre-releases.
> 
> Thanks,
> Simon
> 
> 
> 
> > On 20/05/2021, at 10:27 AM, Renato Morais  
> > wrote:
> > 
> > Hi Simon,
> > 
> > I'm happy to, I'm just not sure how to check previous logs...
> > 
> > On another note, and I'm sure this is a problem with the compiler, now that 
> > my packages are installed, the ones I had to compile from the source cannot 
> > be loaded.
> > 
> > Error: package or namespace load failed for ‘nlme’ in dyn.load(file, 
> > DLLpath = DLLpath, ...):
> >  unable to load shared object 
> > '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so':
> >   
> > dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so,
> >  6): Library not loaded: /opt/R/arm64/gfortran/lib/libgfortran.5.dylib
> >   Referenced from: 
> > /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so
> >   Reason: image not found
> > 
> > Any insights on how that could be solved?
> > 
> > Thanks again for your help,
> > Renato
> > 
> > On Thu, 20 May 2021 at 07:00, Simon Urbanek  
> > wrote:
> > Renato,
> > 
> > I'm glad you have work-around, but I'd still like to get to the core of the 
> > issue, we don't want R to crash ;).
> > Can you, please, check your Console log to see if there is a trace of the 
> > crash and if so, send it to me?
> > Also are you using R in the Terminal or the R.app GUI?
> > 
> > Thanks,
> > Simon
> > 
> > 
> > > On 20/05/2021, at 12:07 AM, Renato Morais  
> > > wrote:
> > > 
> > > Thanks Jeroen, fixing the repo connected me with CRAN (it was defaulted to
> > > '@CRAN@' I think)!
> > > 
> > > Cheers,
> > > Renato
> > > 
> > > On Wed, 19 May 2021 at 21:00, Jeroen Ooms  wrote:
> > > 
> > >> On Wed, May 19, 2021 at 11:34 AM Renato Morais
> > >>  wrote:
> > >>> 
> > >>> Hi all,
> > >>> 
> > >>> I'm new here, so please forgive my clumsy error reporting.
> > >>> 
> > >>> I have just downloaded *R-4.1-branch.pkg* for my Mac M1, as I wanted to
> > >>> finally enjoy a native normal-speed R (for some reason running v 4.0.5 
> > >>> on
> > >>> Rosetta was extremely slow on my machine). I also installed the latest
> > >>> XQuartz, as indicated (v 2.8.1).
> > >>> 
> > >>> Sad story is, when I try a simple install.packages command, it first
> > >>> appears to ignore me, after returning 'Please select a CRAN mirror for
> > >> use
> > >>> in this session'. if I insist, it crashes. No useful error messages.
> > >> Trying
> > >>> via the Package Installer tab didn't work either. It doesn't find any
> > >>> packages, indeed it crashes if I ask it to load the list.
> > >> 
> > >> This indeed sounds like an xQuartz issue, failing to popup the mirror
> > >> selection menu. Does everything work if you manually set your CRAN
> > >> mirror first, e.g:
> > >> 
> > >>  options(repos=c(CRAN="https://cloud.r-project.o

Re: [R-SIG-Mac] R 4.1 for my Mac M1 crashing on installing packages

2021-05-19 Thread Simon Urbanek


Renato,

just open the Console application (under Utilities) - it has all logs from your 
machine - there will be either an R crash log or some entries in the system log.

As for packages, it will be solved once the R 4.1.0 binaries for arm64 are 
released (as soon as all builds finish), but you will have to make sure you 
re-install all packages to remove the pre-releases.

Thanks,
Simon



> On 20/05/2021, at 10:27 AM, Renato Morais  
> wrote:
> 
> Hi Simon,
> 
> I'm happy to, I'm just not sure how to check previous logs...
> 
> On another note, and I'm sure this is a problem with the compiler, now that 
> my packages are installed, the ones I had to compile from the source cannot 
> be loaded.
> 
> Error: package or namespace load failed for ‘nlme’ in dyn.load(file, DLLpath 
> = DLLpath, ...):
>  unable to load shared object 
> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so':
>   
> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so,
>  6): Library not loaded: /opt/R/arm64/gfortran/lib/libgfortran.5.dylib
>   Referenced from: 
> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/nlme/libs/nlme.so
>   Reason: image not found
> 
> Any insights on how that could be solved?
> 
> Thanks again for your help,
> Renato
> 
> On Thu, 20 May 2021 at 07:00, Simon Urbanek  
> wrote:
> Renato,
> 
> I'm glad you have work-around, but I'd still like to get to the core of the 
> issue, we don't want R to crash ;).
> Can you, please, check your Console log to see if there is a trace of the 
> crash and if so, send it to me?
> Also are you using R in the Terminal or the R.app GUI?
> 
> Thanks,
> Simon
> 
> 
> > On 20/05/2021, at 12:07 AM, Renato Morais  
> > wrote:
> > 
> > Thanks Jeroen, fixing the repo connected me with CRAN (it was defaulted to
> > '@CRAN@' I think)!
> > 
> > Cheers,
> > Renato
> > 
> > On Wed, 19 May 2021 at 21:00, Jeroen Ooms  wrote:
> > 
> >> On Wed, May 19, 2021 at 11:34 AM Renato Morais
> >>  wrote:
> >>> 
> >>> Hi all,
> >>> 
> >>> I'm new here, so please forgive my clumsy error reporting.
> >>> 
> >>> I have just downloaded *R-4.1-branch.pkg* for my Mac M1, as I wanted to
> >>> finally enjoy a native normal-speed R (for some reason running v 4.0.5 on
> >>> Rosetta was extremely slow on my machine). I also installed the latest
> >>> XQuartz, as indicated (v 2.8.1).
> >>> 
> >>> Sad story is, when I try a simple install.packages command, it first
> >>> appears to ignore me, after returning 'Please select a CRAN mirror for
> >> use
> >>> in this session'. if I insist, it crashes. No useful error messages.
> >> Trying
> >>> via the Package Installer tab didn't work either. It doesn't find any
> >>> packages, indeed it crashes if I ask it to load the list.
> >> 
> >> This indeed sounds like an xQuartz issue, failing to popup the mirror
> >> selection menu. Does everything work if you manually set your CRAN
> >> mirror first, e.g:
> >> 
> >>  options(repos=c(CRAN="https://cloud.r-project.org;))
> >> 
> >> Alternatively you can disable the popup menus all-together using:
> >> 
> >>  options(menu.graphics=FALSE)
> >> 
> >> Which should probably be the default.
> >> 
> > 
> > 
> > -- 
> > 
> > *Renato Morais | **ARC Postdoctoral Research Associate*
> > 
> > Research Hub for Coral Reef Ecosystem Functions
> > 
> > College of Science and Engineering
> > 
> > ARC Centre of Excellence for Coral Reef Studies
> > 
> > James Cook University
> > 
> > Townsville, Queensland, Australia
> > 
> > https://www.reeffunctionhub.org
> > 
> > http://thebellwoodreeffishlab.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
> > 
> 
> 
> 
> -- 
> Renato Morais | ARC Postdoctoral Research Associate
> 
> Research Hub for Coral Reef Ecosystem Functions
> College of Science and Engineering
> ARC Centre of Excellence for Coral Reef Studies
> James Cook University
> Townsville, Queensland, Australia
> https://www.reeffunctionhub.org
> http://thebellwoodreeffishlab.com
>  
> -- 

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


Re: [R-SIG-Mac] R 4.1 for my Mac M1 crashing on installing packages

2021-05-19 Thread Simon Urbanek


Renato,

I'm glad you have work-around, but I'd still like to get to the core of the 
issue, we don't want R to crash ;).
Can you, please, check your Console log to see if there is a trace of the crash 
and if so, send it to me?
Also are you using R in the Terminal or the R.app GUI?

Thanks,
Simon


> On 20/05/2021, at 12:07 AM, Renato Morais  
> wrote:
> 
> Thanks Jeroen, fixing the repo connected me with CRAN (it was defaulted to
> '@CRAN@' I think)!
> 
> Cheers,
> Renato
> 
> On Wed, 19 May 2021 at 21:00, Jeroen Ooms  wrote:
> 
>> On Wed, May 19, 2021 at 11:34 AM Renato Morais
>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> I'm new here, so please forgive my clumsy error reporting.
>>> 
>>> I have just downloaded *R-4.1-branch.pkg* for my Mac M1, as I wanted to
>>> finally enjoy a native normal-speed R (for some reason running v 4.0.5 on
>>> Rosetta was extremely slow on my machine). I also installed the latest
>>> XQuartz, as indicated (v 2.8.1).
>>> 
>>> Sad story is, when I try a simple install.packages command, it first
>>> appears to ignore me, after returning 'Please select a CRAN mirror for
>> use
>>> in this session'. if I insist, it crashes. No useful error messages.
>> Trying
>>> via the Package Installer tab didn't work either. It doesn't find any
>>> packages, indeed it crashes if I ask it to load the list.
>> 
>> This indeed sounds like an xQuartz issue, failing to popup the mirror
>> selection menu. Does everything work if you manually set your CRAN
>> mirror first, e.g:
>> 
>>  options(repos=c(CRAN="https://cloud.r-project.org;))
>> 
>> Alternatively you can disable the popup menus all-together using:
>> 
>>  options(menu.graphics=FALSE)
>> 
>> Which should probably be the default.
>> 
> 
> 
> -- 
> 
> *Renato Morais | **ARC Postdoctoral Research Associate*
> 
> Research Hub for Coral Reef Ecosystem Functions
> 
> College of Science and Engineering
> 
> ARC Centre of Excellence for Coral Reef Studies
> 
> James Cook University
> 
> Townsville, Queensland, Australia
> 
> https://www.reeffunctionhub.org
> 
> http://thebellwoodreeffishlab.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
> 

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


Re: [R-SIG-Mac] possible bug in R's make install

2021-05-17 Thread Simon Urbanek


Has anyone reported this bug at bugs.R-project.org? Quick search doesn't yield 
anything - Peter can you post the reference, please, if you reported it there? 
Since this is not a Mac-specific issue that's where should go if it is to be 
fixed.

Cheers,
Simon


> On May 18, 2021, at 12:32 AM, Kasper Daniel Hansen 
>  wrote:
> 
> This bug is still present in the R-4.1.
> 
> Best,
> Kasper
> 
> On Fri, Sep 28, 2018 at 8:02 PM Peter Langfelder 
> wrote:
> 
>> For what it's worth, the same bug is present on linux when compiling R
>> with a custom BLAS (either ATLAS or OpenBLAS). The directory needs to
>> be made by hand first. I beleive I have reported this some time ago
>> but no action was taken. Compiling R with R internal BLAS does not
>> results in the error.
>> 
>> Peter
>> On Fri, Sep 28, 2018 at 10:52 AM Kasper Daniel Hansen
>>  wrote:
>>> 
>>> I am trying to compile and install R under High Sierra with Accelerate
>> BLAS
>>> but with R lapack.
>>> 
>>> My relevant configure call is   --with-blas="-framework Accelerate" but
>>> omitting --with-lapack. Full call is pasted at the end of this email
>>> 
>>> I can do
>>>  make
>>>  make check
>>> but make install fails with
>>> 
>>> make[2]: Nothing to be done for `install'.
>>> /usr/local/clang6/bin/clang -I. -I../../src/include
>>> -I../../../R-3.5.x-src/src/include -I/opt/X11/include
>> -I/usr/local/include
>>> -DHAVE_CONFIG_H-Wall -mtune=native -g -O2  -L/usr/local/clang6/lib
>>> -L/usr/local/lib -L/usr/local/opt/tcl-tk/lib
>>> -DR_HOME='"/usr/local/R/R-3.5.x/lib/R"' \
>>>  -o Rscript ../../../R-3.5.x-src/src/unix/Rscript.c
>>> mkdir /usr/local/R/R-3.5.x/lib/R/bin/exec
>>> mkdir /usr/local/R/R-3.5.x/lib/R/modules
>>> cp: /usr/local/R/R-3.5.x/lib/R/lib/libRlapack.dylib: No such file or
>>> directory
>>> make[3]: *** [install] Error 1
>>> make[2]: *** [install] Error 1
>>> make[1]: *** [install] Error 1
>>> make: *** [install] Error 1
>>> 
>>> I manually verified that libRlapack.dylib had been build in the building
>>> directory's "lib".  I then just did
>>> 
>>> sudo mkdir /usr/local/R/R-3.5.x/lib/R/lib
>>> 
>>> (my installation directory is /usr/local/R/R-3.5.x) and redid make
>> install
>>> which now worked.  I get
>>> 
>>> $ ls /usr/local/R/R-3.5.x/lib/R/lib
>>> libRlapack.dylib
>>> 
>>> My _guess_ is that since I am using R's lapack and system BLAS that the
>>> RHOME/lib directory does not get created.
>>> 
>>> Btw., this might be a bad idea (happy to hear about this) but the
>>> installation should work since I can do make check
>>> 
>>> Kasper
>>> 
>>> configure
>>> 
>>> ../${SRCDIR}/configure SHELL='/bin/bash' \
>>>  --prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
>>>  CC="/usr/local/clang6/bin/clang" \
>>>  CXX="/usr/local/clang6/bin/clang++" \
>>>  F77="/usr/local/gfortran/bin/gfortran" \
>>>  FC="$F77" \
>>>  OBJC="clang" \
>>>  CFLAGS="-Wall -mtune=native -g -O2" \
>>>  CXXFLAGS="-Wall -mtune=natuve -g -O2" \
>>>  OBJCFLAGS="-Wall -mtune=native -g -O2 -fobjc-exceptions" \
>>>  F77FLAGS="-Wall -g -O2 -mtune=generic" \
>>>  FCFLAGS="$F77FLAGS" \
>>>  FLIBS="-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
>>> -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm" \
>>>  LDFLAGS="-L/usr/local/clang6/lib -L/usr/local/lib" \
>>>  DYLD_FALLBACK_LIBRARY_PATH="/usr/local/clang6/lib:/usr/local/lib" \
>>> 
>>> 
>> PKG_CONFIG_PATH="/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig"
>>> \
>>>  JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Home" \
>>>  JAVA_CPPFLAGS="-I/System/Library/Frameworks/JavaVM.framework/Headers" \
>>>  JAVA_LD_LIBRARY_PATH="" \
>>>  JAVA_LIBS="-framework JavaVM" \
>>>  --enable-memory-profiling\
>>>  --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib\
>>>  -with-tcltk=/usr/local/opt/tcl-tk/lib\
>>>  --with-blas="-framework Accelerate" | tee ../configure-${R_VERSION}
>>> 
>>>[[alternative HTML version deleted]]
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
> 
> 
> -- 
> Best,
> Kasper
> 
>   [[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] xaxis not displaying

2021-05-14 Thread Simon Urbanek


Thanks. I'm pretty sure I saw this before so maybe something to add to the R 
for Mac FAQ …


> On May 15, 2021, at 1:38 PM, Mike McStephen  wrote:
> 
> Thanks Simon and Luke.
> 
> This fixed the problem for me too.
> 
> I’ll adjust this in my script library.  
> 
> Much appreciated
> 
> Mike
> —
> Mike McStephen
> PO Box 147, Bruthen
> m...@mcstephen.com.au
> 0417 652 552
> 
>> On 15 May 2021, at 11:31 am, Simon Urbanek  
>> wrote:
>> 
>> I don't have the corresponding machine to replicate, but I recall something 
>> related to the fact that the display of the machine may be too small to 
>> accommodate the requested device size (the size specification is in inches). 
>> If the display is too small, you may want to reduce the requested size, e.g. 
>> with
>> quartz.options(width=5,height=5)
>> Is my recollection correct?
>> 
>> Thanks,
>> Simon
>> 
>> 
>> 
>>> On May 15, 2021, at 12:03 PM, Tierney, Luke  wrote:
>>> 
>>> Resizing the window a tiny bit seems to fix this. Not sure why that is 
>>> needed.
>>> 
>>> Best,
>>> 
>>> luke 
>>> 
>>> Sent from my iPad
>>> 
>>>> On May 14, 2021, at 6:02 PM, Mike McStephen  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I’m using v4.0.5 on a MacBook Air with the new M1 (apple) chip.  
>>>> 
>>>> I’m testing out R having not used it for some years and giving a simple 
>>>> plot command:
>>>> 
>>>> plot(Drinks.data[,i])
>>>> 
>>>> Gives a scatter plot (value vs sequence) but no values on the X axis.  The 
>>>> it could be the window size as the axis is close to the bottom of the 
>>>> window.  Is this a known problem, should I be setting some plotting 
>>>> parameter to make this work?
>>>> 
>>>> Thanks
>>>> 
>>>> Mike
>>>> 
>>>> —
>>>> Mike McStephen
>>>> PO Box 147, Bruthen
>>>> m...@mcstephen.com.au
>>>> 0417 652 552
>>>> 
>>>> 
>>>> 
>>>>  [[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] [External] xaxis not displaying

2021-05-14 Thread Simon Urbanek


I don't have the corresponding machine to replicate, but I recall something 
related to the fact that the display of the machine may be too small to 
accommodate the requested device size (the size specification is in inches). If 
the display is too small, you may want to reduce the requested size, e.g. with
quartz.options(width=5,height=5)
Is my recollection correct?

Thanks,
Simon

 

> On May 15, 2021, at 12:03 PM, Tierney, Luke  wrote:
> 
> Resizing the window a tiny bit seems to fix this. Not sure why that is needed.
> 
> Best,
> 
> luke 
> 
> Sent from my iPad
> 
>> On May 14, 2021, at 6:02 PM, Mike McStephen  wrote:
>> 
>> Hi,
>> 
>> I’m using v4.0.5 on a MacBook Air with the new M1 (apple) chip.  
>> 
>> I’m testing out R having not used it for some years and giving a simple plot 
>> command:
>> 
>> plot(Drinks.data[,i])
>> 
>> Gives a scatter plot (value vs sequence) but no values on the X axis.  The 
>> it could be the window size as the axis is close to the bottom of the 
>> window.  Is this a known problem, should I be setting some plotting 
>> parameter to make this work?
>> 
>> Thanks
>> 
>> Mike
>> 
>> —
>> Mike McStephen
>> PO Box 147, Bruthen
>> m...@mcstephen.com.au
>> 0417 652 552
>> 
>> 
>> 
>>   [[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] tcltk on M1 mac?

2021-05-14 Thread Simon Urbanek


Vince,

please try the latest build, Tcl/Tk should be included now.

Thanks,
Simon



> On May 14, 2021, at 7:45 AM, Simon Urbanek  
> wrote:
> 
> Vince,
> 
> Thanks for the report, yes, that is a known problem, because the R installer 
> for arm64 doesn't include Tcl/Tk unlike the Intel version. It is a long 
> story, but I hope to update the installer soon.
> 
> Thanks,
> Simon
> 
> 
>> On May 14, 2021, at 02:47, Vincent Carey  wrote:
>> 
>> I can't seem to get tcltk running with R on M1 machine.  Homebrew tcltk
>> seems to have wrong architecture; attempt to build from source does not
>> help.  Any hints appreciated.
>> 
>> 
>> R version 4.1.0 RC (2021-05-10 r80283) -- "Camp Pontanezen"
>> 
>> Copyright (C) 2021 The R Foundation for Statistical Computing
>> 
>> Platform: aarch64-apple-darwin20 (64-bit)
>> 
>> 
>>> library(tcltk)
>> 
>> *Error: package or namespace load failed for 'tcltk':*
>> 
>> * .onLoad failed in loadNamespace() for 'tcltk', details:*
>> 
>> *  call: dyn.load(file, DLLpath = DLLpath, ...)*
>> 
>> *  error: unable to load shared object
>> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so':*
>> 
>> *
>> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so,
>> 10): Library not loaded: /Library/Frameworks/Tcl.framework/Versions/8.6/Tcl*
>> 
>> *  Referenced from:
>> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so*
>> 
>> *  Reason: image not found*
>> 
>> -- 
>> The information in this e-mail is intended only for the ...{{dropped:18}}
>> 
>> ___
>> 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] tcltk on M1 mac?

2021-05-13 Thread Simon Urbanek


Vince,

Thanks for the report, yes, that is a known problem, because the R installer 
for arm64 doesn't include Tcl/Tk unlike the Intel version. It is a long story, 
but I hope to update the installer soon.

Thanks,
Simon


> On May 14, 2021, at 02:47, Vincent Carey  wrote:
> 
> I can't seem to get tcltk running with R on M1 machine.  Homebrew tcltk
> seems to have wrong architecture; attempt to build from source does not
> help.  Any hints appreciated.
> 
> 
> R version 4.1.0 RC (2021-05-10 r80283) -- "Camp Pontanezen"
> 
> Copyright (C) 2021 The R Foundation for Statistical Computing
> 
> Platform: aarch64-apple-darwin20 (64-bit)
> 
> 
>> library(tcltk)
> 
> *Error: package or namespace load failed for 'tcltk':*
> 
> * .onLoad failed in loadNamespace() for 'tcltk', details:*
> 
> *  call: dyn.load(file, DLLpath = DLLpath, ...)*
> 
> *  error: unable to load shared object
> '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so':*
> 
> *
> dlopen(/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so,
> 10): Library not loaded: /Library/Frameworks/Tcl.framework/Versions/8.6/Tcl*
> 
> *  Referenced from:
> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/tcltk/libs/tcltk.so*
> 
> *  Reason: image not found*
> 
> -- 
> The information in this e-mail is intended only for th...{{dropped:8}}

___
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-gui slow since last update

2021-05-11 Thread Simon Urbanek


Yan,

it's ok, I didn't need the Debug version.

However, did you check the Touch Bar settings as discussed previously to see if 
disabling the app Touch Bar fixes the problem?
If it does, there may be hope - I have created a test version at
https://github.com/R-macos/Mac-GUI/actions/runs/820226842
at the bottom there is "R-GUI-Build" link under Artifacts which gives you a zip 
file with R-GUI-Build.dmg image which has both release and debug version which 
disable the Touch Bar for the console (built for R 4.0.x). Please let me know 
if that works for you.

Thanks,
Simon



> On May 7, 2021, at 2:37 AM, ALPEROVYCH Yan  wrote:
> 
> Thank you Simon,
> 
> Brandon suggested to use the debug version of the R-gui, but you seem to be 
> ok with what I sent. Please let me know if you also want the sampler files 
> using the the debug version.
> 
> Also, if you need me to test the fixes / updates, please don’t hesitate.
> 
> Yan
> 
> 
> On May 6, 2021, at 4:30 AM, Simon Urbanek  wrote:
> 
> Yan,
> 
> thank you for the sampler files!
> 
> From cursory glance the issue seems to be the touch bar, an amazing amount of 
> time is spent in the Apple's touchbar API (almost all of it is in some way 
> related to [NSTextView(NSTextView_TouchBar_API) updateTextTouchBarItems]). 
> That also explains why I was not able to reproduce it, because I don't have a 
> Mac with touch bar and Big Sur. I don't know what is available in the 
> settings, but you may want to see if you can adjust your touch bar system 
> preferences (if I recall there are different options for the touch bar) - the 
> R GUI doesn't use the touch bar at all, so the issue is entirely at the 
> system level. I will look is there is anything we can do to block the touch 
> bar API on our end or otherwise deal with it by have R explicitly handle the 
> touch bar.
> 
> Thanks,
> Simon
> 
> 
> 
>> On 4/05/2021, at 7:10 PM, ALPEROVYCH Yan  wrote:
>> 
>> Simon,
>> 
>> I sampled the process of my test (the slowdown). I was able to do it without 
>> downloading the "Debug" version. There are two files attached.
>> 1. The first one (run at 8:58:14 am) is the replication of my test (the 
>> slowdown) using the external editor
>> 2. The second (run at 9:05:09 am) is the replication of my test using the 
>> in-built editor
>> 
>> While doing the second sampling R also popped the red warnings (if that is 
>> useful).
>> 
>> I am also answering Peter’s question: my version of Big Sur is 11.3.
>> 
>> Let me know what else I can do to help.
>> Yan
>> 
>> 
>> On May 4, 2021, at 5:53 AM, Simon Urbanek  
>> wrote:
>> 
>> Yan,
>> 
>> thanks for the reports. I cannot reproduce the slow-down, either (Mac mini 
>> M1, Big Sur 11.3).
>> 
>> However, you can help by sampling the R process and sending the sample to 
>> me. You can do that as follows:
>> 
>> 1) open R.app
>> 2) open Terminal (under Applications -> Utilities)
>> 3) in Terminal type:
>> 
>> sample R 30
>> 
>> 4) switch to R and perform your test. You have 30 seconds (that's the number 
>> above which specifies how long the sampler will run) to do it. In Terminal 
>> it will show the sampler output -in the beginning it will also tell you the 
>> location of the text file - it's typically /tmp/R_*.sample.txt - send that 
>> file to me.
>> 
>> It may not allow you to debug the released version of the GUI, so you may 
>> need to download the "Debug" version of the GUI (scroll down) from
>> 
>> https://mac.R-project.org
>> 
>> You should pick the
>> Mac OS X GUI rev.XXX for R 4.0.x
>> high-sierra-Release.dmg
>> download if you have R 4.0.x. You don't need to install the GUI, you can run 
>> it directly from the image so it won't affect your installed version.
>> 
>> Thanks,
>> Simon
>> 
>> PS: you may need to install Xcode command line tools if you didn't already:
>> sudo xcode-select --install
>> 
>> 
>>> On 4/05/2021, at 3:06 AM, ALPEROVYCH Yan  wrote:
>>> 
>>> Dear Peter, Simon,
>>> 
>>> Since I am not that of an expert in programming, is there any way to trace 
>>> what happens 'under the hood' of the gui to see what exactly slows down the 
>>> rendering of output on my end?
>>> 
>>> On the warnings, some more came today. How that happened and the text that 
>>> came out are below.
>>> 
>>> Thank you for your help,
>>> Yan
>>> 
>>> I looked at the Preferences -> Editor (once the window

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

2021-05-11 Thread Simon Urbanek
Yan,

great, thanks! I'll put the touchbar changes into the release. I also started 
looking at some of the warnings - the button ones are easy to fix.
Although you can move the Release build to Applications, it is not signed, so 
you may get a warning when you run it - otherwise it is safe. When I make the 
change it will be in the nightly builds in https://mac.R-project.org and those 
are signed so that will be the best.

Thanks,
Simon


> On May 9, 2021, at 9:25 AM, ALPEROVYCH Yan  wrote:
> 
> Simon, 
> 
> Yes, I tried to play with touch bar preferences, to no avail. 
> 
> On the bright side, I also tested your build. Both debug and release version 
> work. There was one NS warning in the release version, but it did not 
> affected at all the test (I was running the same sequence as I described in 
> the original message). 
> 
> In the following transfer are the sampler files for both versions:
> https://www.dropbox.com/t/xDqbbZma9i0XdHBk 
> <https://www.dropbox.com/t/xDqbbZma9i0XdHBk>
> 
> I am tempted to slide the new release version to /Applicaitons and use it 
> instead of the one shipped with the CRAN release; is it safe to do so?
> 
> Yan
> 
> 
> On May 7, 2021, at 2:27 PM, Simon Urbanek  <mailto:simon.urba...@r-project.org>> wrote:
> 
> Yan,
> 
> it's ok, I didn't need the Debug version.
> 
> However, did you check the Touch Bar settings as discussed previously to see 
> if disabling the app Touch Bar fixes the problem?
> If it does, there may be hope - I have created a test version at
> https://github.com/R-macos/Mac-GUI/actions/runs/820226842 
> <https://github.com/R-macos/Mac-GUI/actions/runs/820226842>
> at the bottom there is "R-GUI-Build" link under Artifacts which gives you a 
> zip file with R-GUI-Build.dmg image which has both release and debug version 
> which disable the Touch Bar for the console (built for R 4.0.x). Please let 
> me know if that works for you.
> 
> Thanks,
> Simon
> 
> 
> 
>> On May 7, 2021, at 2:37 AM, ALPEROVYCH Yan  wrote:
>> 
>> Thank you Simon,
>> 
>> Brandon suggested to use the debug version of the R-gui, but you seem to be 
>> ok with what I sent. Please let me know if you also want the sampler files 
>> using the the debug version.
>> 
>> Also, if you need me to test the fixes / updates, please don’t hesitate.
>> 
>> Yan
>> 
>> 
>> On May 6, 2021, at 4:30 AM, Simon Urbanek  
>> wrote:
>> 
>> Yan,
>> 
>> thank you for the sampler files!
>> 
>> From cursory glance the issue seems to be the touch bar, an amazing amount 
>> of time is spent in the Apple's touchbar API (almost all of it is in some 
>> way related to [NSTextView(NSTextView_TouchBar_API) 
>> updateTextTouchBarItems]). That also explains why I was not able to 
>> reproduce it, because I don't have a Mac with touch bar and Big Sur. I don't 
>> know what is available in the settings, but you may want to see if you can 
>> adjust your touch bar system preferences (if I recall there are different 
>> options for the touch bar) - the R GUI doesn't use the touch bar at all, so 
>> the issue is entirely at the system level. I will look is there is anything 
>> we can do to block the touch bar API on our end or otherwise deal with it by 
>> have R explicitly handle the touch bar.
>> 
>> Thanks,
>> Simon
>> 
>> 
>> 
>>> On 4/05/2021, at 7:10 PM, ALPEROVYCH Yan  wrote:
>>> 
>>> Simon,
>>> 
>>> I sampled the process of my test (the slowdown). I was able to do it 
>>> without downloading the "Debug" version. There are two files attached.
>>> 1. The first one (run at 8:58:14 am) is the replication of my test (the 
>>> slowdown) using the external editor
>>> 2. The second (run at 9:05:09 am) is the replication of my test using the 
>>> in-built editor
>>> 
>>> While doing the second sampling R also popped the red warnings (if that is 
>>> useful).
>>> 
>>> I am also answering Peter’s question: my version of Big Sur is 11.3.
>>> 
>>> Let me know what else I can do to help.
>>> Yan
>>> 
>>> 
>>> On May 4, 2021, at 5:53 AM, Simon Urbanek  
>>> wrote:
>>> 
>>> Yan,
>>> 
>>> thanks for the reports. I cannot reproduce the slow-down, either (Mac mini 
>>> M1, Big Sur 11.3).
>>> 
>>> However, you can help by sampling the R process and sending the sample to 
>>> me. You can do that as follows:
>>> 
>>> 1) open R.app
>>> 2) open Terminal (under Ap

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

2021-05-11 Thread Simon Urbanek


Yuri,

thanks, no, this has not been reported, so it is indeed very useful! Now fixed 
in r4560 so tonight's build should work.

Thanks for doing the right thing which is to report the issue at the source 
instead of consulting the social media which doesn't help anyone.

Thanks,
Simon



> On May 9, 2021, at 11:15 AM, Yuri Broze  wrote:
> 
> Hi folks,
> 
> Apologies if this bug has already been noticed, but I wanted to share just
> in case it hasn't yet, and this was the best place I found.
> 
> The current CRAN-hosted MacOS installation package fails to correctly
> create symbolic links to /usr/local/bin for machines with `uname -r`
> release version of 20 or above. The faulty logic is in
> R/R-fw.pkg/Scripts/postflight; lines 6-13:
> 
> if uname -r | grep '^1[5-9]' >/dev/null; then
>## 15.0 and higher don't allow messing with /usr/bin
>## so use /usr/local/bin instead
>if [ ! -e /usr/local/bin ]; then
>mkdir -p /usr/local/bin
>fi
>cd /usr/local/bin
> fi
> 
> This seems to have resulted in some commotion on Stack Exchange and other
> places around an inability to access `R` or `Rscript` from the commandline,
> along with the usual hacky workarounds.
> 
> Hope this is helpful to bring to your attention!
> 
> Best,
> Yuri
> 
> Yuri Broze
> 314.910.3152
> 
>   [[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-4.0.5.pkg Bug Report

2021-05-11 Thread Simon Urbanek


I have fixed it (it only needs a slight modification of the regex) and 
responded, unfortunately my posts get blocked at ETH :( The nightlies should 
have the new post flight script so please test.

Cheers,
Simon



> On May 9, 2021, at 21:11, peter dalgaard  wrote:
> 
> Eek, yes, that needs fixing. And of course only newcomers get hit because 
> others will have the symlinks in place already.
> 
> I believe that instead of the grep '^1[5-9]' business you need something like
> 
> IFS=. read major minor pl << EOF
> `uname -r`
> EOF
> 
> and then a numeric check on $major.
> 
> -pd
> 
>> On 9 May 2021, at 01:15 , Yuri Broze  wrote:
>> 
>> Hi folks,
>> 
>> Apologies if this bug has already been noticed, but I wanted to share just
>> in case it hasn't yet, and this was the best place I found.
>> 
>> The current CRAN-hosted MacOS installation package fails to correctly
>> create symbolic links to /usr/local/bin for machines with `uname -r`
>> release version of 20 or above. The faulty logic is in
>> R/R-fw.pkg/Scripts/postflight; lines 6-13:
>> 
>> if uname -r | grep '^1[5-9]' >/dev/null; then
>>   ## 15.0 and higher don't allow messing with /usr/bin
>>   ## so use /usr/local/bin instead
>>   if [ ! -e /usr/local/bin ]; then
>>   mkdir -p /usr/local/bin
>>   fi
>>   cd /usr/local/bin
>> fi
>> 
>> This seems to have resulted in some commotion on Stack Exchange and other
>> places around an inability to access `R` or `Rscript` from the commandline,
>> along with the usual hacky workarounds.
>> 
>> Hope this is helpful to bring to your attention!
>> 
>> Best,
>> Yuri
>> 
>> Yuri Broze
>> 314.910.3152
>> 
>>  [[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
> 
> ___
> 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] Re: [External] Re: Mac M1 emacs

2021-03-07 Thread Simon Urbanek
Did you try running it from the image? At which point does it complain? It 
works for me.
Note that macOS may not be happy if you mangle the content due to code signing, 
so you may want to move aside the old version first if you are putting it in 
/Applications.
Unfortunately I have only one M1 system, so I can't try it on another "clean" 
one to see if there are issues.

Cheers,
Simon


> On Mar 8, 2021, at 5:43 PM, Richard M. Heiberger  wrote:
> 
> it claims to be damaged.
> 
> I looked it and the filenames and directory structure look ok.
> 
> ________
> From: Simon Urbanek 
> Sent: Sunday, March 7, 2021 21:42
> To: Richard M. Heiberger
> Cc: r-sig-mac@r-project.org
> Subject: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs
> 
> Richard,
> 
> please note the binary supports mouse integration if you enable it (see Emacs 
> documentation - ad-hoc: M-x xterm-mouse-mode).
> 
> Like I said, it is trivial to build the GUI version of you care - I have very 
> explicitly disabled the GUI since I hate it personally (I want emacs to run 
> in the terminal, not have it pop-up random windows). But you seem to think 
> otherwise ;) so I have added the app build as well:
> https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg
> 
> Cheers,
> Simon
> 
> 
>> On Mar 8, 2021, at 1:53 PM, Richard M. Heiberger  wrote:
>> 
>> Simon's binary works.  As he noted, it is missing mouse support.
>> 
>> I copied the entirety of
>> /Applications/Emacs.app/Contents/Resources/site-lisp
>> into
>> /opt/R/arm64/share/emacs/27.1/site-lisp
>> 
>> I turned off the request for mouse support in
>> site-lisp/site-start.el
>> by changing the first mouse line (line 47) to
>> (if (equal 'system-configuration "x86_64-apple-darwin18.7.0") 
>> (mouse-wheel-mode t)); activate mouse scrolling on intel
>> 
>> 
>> I opened Terminal and started emacs with
>> /opt/R/arm64/bin/emacs
>> It gives an ERROR:ess-etc-directory which I can ignore (it looks to me like 
>> the ../etc is there).
>> it gives a warning about server which I am ignoring for now.
>> 
>> M-x R works.
>> the major mouse functionality I miss are replaced by C-x ^ and C-x } and C-x 
>> o
>> make-frame doesn't make a new frame.
>> 
>> I had hoped that I could drop files from this version into the complete 
>> setup that Vincent Goulet has
>> provided.  The file structure isn't identical, so that won't work naively.
>> 
>> Now to see if I prefer the mouse-accesible x86_64 with random crashes or the
>> aarch64 (presumably more stable) without mouse ability.
>> 
>> 
>> From: R-SIG-Mac  on behalf of Richard M. 
>> Heiberger 
>> Sent: Sunday, March 7, 2021 18:31
>> To: Bob Rudis
>> Cc: r-sig-mac@r-project.org
>> Subject: Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs
>> 
>> My understanding had been that "universal" meant both intel and arm, and 
>> therefore
>> that _10 and _14 was the indicator. Apparently not.
>> 
>> I will look at the binary that Simon just told us about.
>> 
>> I don't know how to check though, because the highly frequent crashes I see 
>> have
>> nothing obvious in common.
>> 
>> Rich
>> 
>> 
>> From: Bob Rudis 
>> Sent: Sunday, March 7, 2021 14:37
>> To: Richard M. Heiberger
>> Cc: r-sig-mac@r-project.org
>> Subject: [External] Re: [R-SIG-Mac] Mac M1 emacs
>> 
>> you should likely re-post to the list or double check the download as
>> there are no x86_64 + amd64 universal binaries in there:
>> 
>>   $ find  /Volumes/Emacs/Emacs.app/Contents/MacOS -type f -exec file {} \;
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ctags:
>> Mach-O 64-bit executable x86_64
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ebrowse:
>> Mach-O 64-bit executable x86_64
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/emacsclient:
>> Mach-O 64-bit executable x86_64
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/etags:
>> Mach-O 64-bit executable x86_64
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ctags:
>> Mach-O 64-bit executable x86_64
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ebrowse:
>> Mach-O 64-bit executable x86_64
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/emacsclient:
>> Mach-O 64-bit executable x86_64
>>   /Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-

Re: [R-SIG-Mac] [External] Re: Mac M1 emacs

2021-03-07 Thread Simon Urbanek
Richard,

please note the binary supports mouse integration if you enable it (see Emacs 
documentation - ad-hoc: M-x xterm-mouse-mode).

Like I said, it is trivial to build the GUI version of you care - I have very 
explicitly disabled the GUI since I hate it personally (I want emacs to run in 
the terminal, not have it pop-up random windows). But you seem to think 
otherwise ;) so I have added the app build as well:
https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg

Cheers,
Simon


> On Mar 8, 2021, at 1:53 PM, Richard M. Heiberger  wrote:
> 
> Simon's binary works.  As he noted, it is missing mouse support.
> 
> I copied the entirety of
> /Applications/Emacs.app/Contents/Resources/site-lisp
> into
> /opt/R/arm64/share/emacs/27.1/site-lisp
> 
> I turned off the request for mouse support in
> site-lisp/site-start.el
> by changing the first mouse line (line 47) to
> (if (equal 'system-configuration "x86_64-apple-darwin18.7.0") 
> (mouse-wheel-mode t)); activate mouse scrolling on intel
> 
> 
> I opened Terminal and started emacs with
> /opt/R/arm64/bin/emacs
> It gives an ERROR:ess-etc-directory which I can ignore (it looks to me like 
> the ../etc is there).
> it gives a warning about server which I am ignoring for now.
> 
> M-x R works.
> the major mouse functionality I miss are replaced by C-x ^ and C-x } and C-x o
> make-frame doesn't make a new frame.
> 
> I had hoped that I could drop files from this version into the complete setup 
> that Vincent Goulet has
> provided.  The file structure isn't identical, so that won't work naively.
> 
> Now to see if I prefer the mouse-accesible x86_64 with random crashes or the
> aarch64 (presumably more stable) without mouse ability.
> 
> 
> From: R-SIG-Mac  on behalf of Richard M. 
> Heiberger 
> Sent: Sunday, March 7, 2021 18:31
> To: Bob Rudis
> Cc: r-sig-mac@r-project.org
> Subject: Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs
> 
> My understanding had been that "universal" meant both intel and arm, and 
> therefore
> that _10 and _14 was the indicator. Apparently not.
> 
> I will look at the binary that Simon just told us about.
> 
> I don't know how to check though, because the highly frequent crashes I see 
> have
> nothing obvious in common.
> 
> Rich
> 
> 
> From: Bob Rudis 
> Sent: Sunday, March 7, 2021 14:37
> To: Richard M. Heiberger
> Cc: r-sig-mac@r-project.org
> Subject: [External] Re: [R-SIG-Mac] Mac M1 emacs
> 
> you should likely re-post to the list or double check the download as
> there are no x86_64 + amd64 universal binaries in there:
> 
>$ find  /Volumes/Emacs/Emacs.app/Contents/MacOS -type f -exec file {} \;
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ctags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ebrowse:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/emacsclient:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/etags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ctags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ebrowse:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/emacsclient:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/etags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs: Ruby script text,
> UTF-8 Unicode text
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_10: Mach-O
> 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_10.pdmp: data
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14: Mach-O
> 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14.pdmp: data
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs.pdmp: data
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libffi.6.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libgmp.10.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libgnutls.30.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libhogweed.4.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libjansson.4.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libnettle.6.dylib:
> Mach-O 64-bit dynamically linked shared 

Re: [R-SIG-Mac] Mac M1 emacs

2021-03-07 Thread Simon Urbanek
FWIW I have a command-line-only version of emacs in the libs-arm64 directory:

https://mac.r-project.org/libs-arm64/emacs-27.1-darwin.20-arm64.tar.gz

It is intentionally compiled without GUI so a replacement for the emacs as was 
shipped by Apple in older versions of macOS (see 
https://github.com/R-macos/recipes/tree/master/recipes
for the recipe if you want to tweak it to add GUI support or similar).

Cheers,
Simon




> On Mar 8, 2021, at 8:37 AM, Bob Rudis  wrote:
> 
> you should likely re-post to the list or double check the download as
> there are no x86_64 + amd64 universal binaries in there:
> 
>$ find  /Volumes/Emacs/Emacs.app/Contents/MacOS -type f -exec file {} \;
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ctags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/ebrowse:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/emacsclient:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_10/etags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ctags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/ebrowse:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/emacsclient:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/bin-x86_64-10_14/etags:
> Mach-O 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs: Ruby script text,
> UTF-8 Unicode text
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_10: Mach-O
> 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_10.pdmp: data
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14: Mach-O
> 64-bit executable x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14.pdmp: data
>/Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs.pdmp: data
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libffi.6.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libgmp.10.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libgnutls.30.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libhogweed.4.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libjansson.4.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libnettle.6.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libp11-kit.0.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libtasn1.6.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/lib-x86_64-10_10/libunistring.2.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libffi.6.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libgmp.10.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libgnutls.30.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libhogweed.4.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libjansson.4.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libnettle.6.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libp11-kit.0.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libtasn1.6.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> /Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_10/libunistring.2.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libffi.7.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libgmp.10.dylib:
> Mach-O 64-bit dynamically linked shared library x86_64
>
> 

Re: [R-SIG-Mac] devtools problem on MacOS 10.14.6

2021-02-24 Thread Simon Urbanek
Tim.,

The mirror you are using seems to be broken. Please use that main CRAN server 
or another mirror that works.

Cheers,
Simon



> On Feb 25, 2021, at 07:48, Tim Dickinson  wrote:
> 
> Hi--- I would like to install the new package lcvplants 
> (https://www.nature.com/articles/s41597-020-00702-z.pdf, 
> https://idiv-biodiversity.github.io/lcvplants/articles/taxonomic_resolution_using_lcplants.html)
>  and need to use devtools to do so.
> 
> I don't seem to be able to install devtools:
> 
> R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
> Copyright (C) 2020 The R Foundation for Statistical Computing
> Platform: x86_64-apple-darwin17.0 (64-bit)
> 
> > install.packages("devtools")
> Warning: unable to access index for repository 
> http://cran.utstat.utoronto.ca/src/contrib:
>   cannot open URL 'http://cran.utstat.utoronto.ca/src/contrib/PACKAGES'
> Warning: unable to access index for repository 
> http://cran.utstat.utoronto.ca/bin/macosx/contrib/4.0:
>   cannot open URL 
> 'http://cran.utstat.utoronto.ca/bin/macosx/contrib/4.0/PACKAGES'
> Warning message:
> package ‘devtools’ is not available for this version of R
> 
> A version of this package for your version of R might be available elsewhere,
> see the ideas at
> https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages
>  
> >
> 
> and same result after updating...
> R version 4.0.4 (2021-02-15) -- "Lost Library Book"
> Copyright (C) 2021 The R Foundation for Statistical Computing
> Platform: x86_64-apple-darwin17.0 (64-bit)
> 
> My thanks to anyone who can suggest a way forward!
> 
> ---tad.
> 
> <
><
>   <100 Queen's Park
>   <
>   http://orcid.org/-0003-1366-145X
> http://www.rom.on.ca/en/collections-research/rom-staff/tim-dickinson
> <
> 
> ___
> 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] Rosetta2/M1-Compatibility of R

2021-02-23 Thread Simon Urbanek
Johannes,

Thank you for your inquiry, I'm glad that you have finally found the right 
place for your query - few weeks too late, but better than never. But that 
said, if you actually bothered to read the list you're posting to you'd see the 
answer to your question already. Admittedly, the answer is only satisfactory to 
more experienced R users (since the solution requires you to obtain libmpfr for 
M1 one way or another), but if you bear with me for few more hours I do plan to 
post the corresponding native library tomorrow.

Cheers,
Simon


> On Feb 23, 2021, at 21:45, Johannes Truffer  
> wrote:
> 
> Dear SIG-Mac
> 
> I’m rather new to the R Universe and I really hope, I don’t violate any 
> conventionalized procedures by posting to this list as a definite rookie.
> 
> For my PhD at University of Basel, I’m using different approaches to text 
> mining, which are almosty exclusively R-based. Because I’m about to analyse 
> bigger text-corpora, I bought the new M1 Mac Mini. Sadly, most of my scripts 
> suddenly stopped working on it, and I was baffled to find out, that it always 
> crashed on the Rmpfr-Package's mpfr-command. Somebody else asked the exact 
> same question on Stack Overflow about 15 days ago, but still hasn’t received 
> a definitive answer 
> (https://stackoverflow.com/questions/66089887/mpfr-always-crash-r-studio?noredirect=1#comment117251458_66089887).
> 
> I even reached out to Prof. Dr. Martin Maechler, the maintainer(“Rmpfr”). He 
> pointed out to me in an earlier Mail, that the package itself is not likely 
> to be the culprit in this. It may have to do with something more low level, 
> perhaps in connection with the M1’s architecture or Rosetta 2 itself. So I 
> thought maybe the SIG could be of help in answering this.
> 
> Thanks a lot in advance.
> 
> Kind regards
> 
> Johannes Truffer
> 
>   [[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 on M1 Mac cause 'illegal trap'

2021-02-22 Thread Simon Urbanek
Jean,

yes it does by definition - the issue is the Intel translation on arm, so if 
you run native R there is no issue. There should be also no issue if you 
compile Intel mpfr on the M1 machine since it should detect capabilities 
correctly. Maybe I should have been more clear that the issue is that the 
binary we distribute has been compiled on CPU that has more capabilities than 
the Intel translation on M1 does. So compiling from source is the other 
alternative (whether native or not doesn't matter).

Cheers,
Simon



> On 23/02/2021, at 8:09 AM, Jean Thioulouse  
> wrote:
> 
> 
> The good news is that it works fine in the last arm64 R-devel version:
> 
>> a <- mpfr(1:10, precBits=100)
>> a
> 10 'mpfr' numbers of precision  100   bits 
> [1]  1  2  3  4  5  6  7  8  9 10
>> sessionInfo()
> R Under development (unstable) (2021-02-18 r80027)
> Platform: aarch64-apple-darwin20.0 (64-bit)
> Running under: macOS Big Sur 11.2.1
> 
> Matrix products: default
> BLAS:   
> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libRblas.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libRlapack.dylib
> 
> Random number generation:
> RNG: Mersenne-Twister 
> Normal:  Inversion 
> Sample:  Rounding 
> 
> locale:
> [1] fr_FR.UTF-8/fr_FR.UTF-8/fr_FR.UTF-8/C/fr_FR.UTF-8/fr_FR.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
> 
> other attached packages:
> [1] Rmpfr_0.8-2 gmp_0.6-2  
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.1.0 tools_4.1.0   
> 
> 
> 
>> Le 22 févr. 2021 à 19:46, Richard M. Heiberger  a écrit :
>> 
>> I confirm the error on Mac M1
>> R version 4.0.4 RC (2021-02-12 r79998) -- "Lost Library Book"
>> 
>> I also ran it on an intel Mac with R 4.0.3
>> and it worked correctly there.
>> 
>> 
>> From: R-SIG-Mac  on behalf of Zhang, Jialin 
>> via R-SIG-Mac 
>> Sent: Monday, February 22, 2021 1:36 PM
>> To: r-sig-mac@r-project.org
>> Subject: [External] [R-SIG-Mac] Rmpfr on M1 Mac cause 'illegal trap'
>> 
>> Hello,
>> 
>> First time sending an email to this list. Please correct me if I�m doing 
>> anything wrong. Thank you!
>> 
>> I am reporting an error when using Rmpfr::mpfr on an M1 MacBook Air. Codes 
>> below:
>> 
>>> library(Rmpfr)
>>> a <- mpfr(1:10, precBits=100)
>> 
>> *** caught illegal operation ***
>> address 0x10daa2bfb, cause 'illegal trap'
>> 
>> Traceback:
>> 1: mpfr.default(1:10, precBits = 100)
>> 2: mpfr(1:10, precBits = 100)
>> 
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> 
>>> sessionInfo()
>> R version 4.0.4 (2021-02-15)
>> Platform: x86_64-apple-darwin17.0 (64-bit)
>> Running under: macOS Big Sur 10.16
>> 
>> Matrix products: default
>> BLAS:   
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
>> 
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>> 
>> other attached packages:
>> [1] Rmpfr_0.8-2 gmp_0.6-2
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_4.0.4
>> 
>> 
>> 
>> The issue was first published on 
>> https://stackoverflow.com/questions/66089887/mpfr-always-crash-r-studio/66321334#66321334.
>>  Please let me know if any more info is needed. Thanks!
>> 
>> Best,
>> JZ
>> 
>> �
>> 
>> Jialin Zhang (JZ), Assistant Professor of Statistics
>> Department of Mathematics and Statistics
>> Mississippi State University
>> tel: (662) 325-7137; email: 
>> jzh...@math.msstate.edu
>> 
>> 
>>   [[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] Rmpfr on M1 Mac cause 'illegal trap'

2021-02-22 Thread Simon Urbanek
JZ,

Thanks for the report, this is likely due to Rosetta2 not supporting some 
advanced x86_64 instructions used by Rmpfr. I'll see if I can create a less 
optimised build of Rmpfr which uses only supported instructions.

Thanks,
Simon


> On Feb 23, 2021, at 07:36, Zhang, Jialin via R-SIG-Mac 
>  wrote:
> 
> Hello,
> 
> First time sending an email to this list. Please correct me if I�m doing 
> anything wrong. Thank you!
> 
> I am reporting an error when using Rmpfr::mpfr on an M1 MacBook Air. Codes 
> below:
> 
>> library(Rmpfr)
>> a <- mpfr(1:10, precBits=100)
> 
> *** caught illegal operation ***
> address 0x10daa2bfb, cause 'illegal trap'
> 
> Traceback:
> 1: mpfr.default(1:10, precBits = 100)
> 2: mpfr(1:10, precBits = 100)
> 
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> 
>> sessionInfo()
> R version 4.0.4 (2021-02-15)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS Big Sur 10.16
> 
> Matrix products: default
> BLAS:   
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> other attached packages:
> [1] Rmpfr_0.8-2 gmp_0.6-2
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.0.4
> 
> 
> 
> The issue was first published on 
> https://stackoverflow.com/questions/66089887/mpfr-always-crash-r-studio/66321334#66321334.
>  Please let me know if any more info is needed. Thanks!
> 
> Best,
> JZ
> 
> �
> 
> Jialin Zhang (JZ), Assistant Professor of Statistics
> Department of Mathematics and Statistics
> Mississippi State University
> tel: (662) 325-7137; email: 
> jzh...@math.msstate.edu
> 
> 
>   [[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] Flang

2021-02-19 Thread Simon Urbanek
This message is for very advanced/curios expert users only!

Flang is a Fortran compiler based on clang/llvm which has been mostly donated 
by nVidia. It has existed on Linux for a while, but with some patching can be 
made to work on macOS as well. For quite some time I have a PR 
https://github.com/flang-compiler/flang/pull/592 which adds macOS support to 
the upstream sources. Since there was some activity recently, I decided to 
update it to the latest flang and to test it. It is now capable of building R 
(macOS x86_64 build) which passes all checks (that was not the case before) so 
I have created a binary of the compiler (since it's quite a beast to build) at
https://github.com/s-u/flang-macos/releases/tag/fixed-b23418
in case those very adventurous decide to play wit it. It lives in /opt/flang 
and should work on macOS Catalina or higher.
In order to build R I had to add 'LDFLAGS=-L/opt/flang/lib -lpgmath -lflang 
-lflangrti -lomp' when using this compiler since R cannot figure out the 
correct flags for mixing flang and clang yet.

Note: there is a namespace collision regarding the name "flang" since the flang 
I refer to (https://github.com/flang-compiler/flang) is what was originally 
called flang, but now there is f18 which is an attempt to re-write Fortran 
support in clang/llvm from scratch and recently they decided to rename it from 
f18 to flang, to cause complete confusion. f18 is part of the mainstream llvm 
sources, but is nowhere close to be usable (it cannot generate code yet) so is 
unrelated to what I'm talking about here.

Cheers,
Simon

PS: if we have any compiler geeks here - the sources suggest that nVidia has 
also added arm64 sources of the libpgmath runtime library aimed at Windows. It 
would be interesting to see if those could be made work to support aarch64 
(Apple silicon) - in theory it should work. My initial attempts failed as I 
could not get them to compile, but if someone had more spare time on their 
hands may be more successful...

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


Re: [R-SIG-Mac] Please test R 4.0.4 RC

2021-02-16 Thread Simon Urbanek
John,

thanks, yes, it has not actually disappeared, but I am now explicitly 
suppressing it (only in the console stderr forwarding, it will still appear in 
the logs if you run the debug version or disable stderr forwarding). It is a 
rather terrible hack, but until I have a way to replicate and find what 
macOS-internal part is triggering it, it's better to suppress it as it is 
confusing people that are taking it for an error.

Thanks,
Simon


> On Feb 17, 2021, at 3:20 AM, John Fox  wrote:
> 
> Dear Simon,
> 
> I just installed R 4.0.4 and the warning has disappeared. I expect that you 
> know that but thought that it might be useful to confirm it just in case.
> 
> Best,
> John
> 
> On 2021-02-12 9:05 p.m., John Fox wrote:
>> Dear Simon,
>> I'm still seeing the warning on a MacBook Pro with a touchbar running Big 
>> Sur:
>> --- snip 
>> R version 4.0.4 RC (2021-02-12 r79998) -- "Lost Library Book"
>> Copyright (C) 2021 The R Foundation for Statistical Computing
>> Platform: x86_64-apple-darwin17.0 (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.
>> [R.app GUI 1.74 (7929) x86_64-apple-darwin17.0]
>> [History restored from /Users/johnfox/.Rapp.history]
>> 2021-02-12 21:00:21.163 R[19677:11057750] Warning: Expected min height of 
>> view: () to be less than or 
>> equal to 30 but got a height of 32.00. This error will be logged once 
>> per view in violation.
>> > sessionInfo()
>> R version 4.0.4 RC (2021-02-12 r79998)
>> Platform: x86_64-apple-darwin17.0 (64-bit)
>> Running under: macOS Big Sur 10.16
>> Matrix products: default
>> BLAS: 
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
>> locale:
>> [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>> loaded via a namespace (and not attached):
>> [1] compiler_4.0.4
>> --- snip 
>> I hope this helps,
>>  John
>> John Fox, Professor Emeritus
>> McMaster University
>> Hamilton, Ontario, Canada
>> web: https://socialsciences.mcmaster.ca/jfox/
>> On 2021-02-12 6:50 p.m., Simon Urbanek wrote:
>>> Dear macOS useRs,
>>> 
>>> please test the latest R 4.0.4 RC builds from
>>> 
>>> https://mac.r-project.org/
>>> 
>>> especially if you are running macOS Big Sur. The known issues introduced by 
>>> Big Sur have been fixed, but I cannot replicate nor test the spurious 
>>> touchbar warning.
>>> 
>>> Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - 
>>> they are betas for a reason (=unstable) and break things.
>>> 
>>> 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] XML packages source compilation on macOS 10.15.7

2021-02-15 Thread Simon Urbanek
Kemal,

it looks like you're completely missing the libxml2 includes on that system. 
XML prefers xml2-config over pkg-config so it will by default pick the system 
version of xml2, but you don't have the includes for that.

According to your setup, they are supposed to be in
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libxml
but my guess is they are not.

Check the usual culprits 
 sudo xcode-select --install
and if in doubt reset 
 sudo xcode-select --reset

If that doesn't help, you can set LIBXML_INCDIR (without the libxml part) and 
LIBXML_LIBDIR yourself if you know where they are.
You also have miniconda and /usr/local so if you want to use any of that, you'd 
the teh two variables above. Alternatively, you can set --with-xml-config  to 
point to your non-system xml2-config if it points to the right 
includes/libraries.

Good luck,
Simon



> On Feb 16, 2021, at 4:20 PM, Kemal Akat  wrote:
> 
> Hi Duncan and Simon,
> 
> Thanks for getting back to me.
> 
> The R version I use(d) is 
> 
> R Under development (unstable) (2021-01-15 r79833)
> 
> This was installed via the installer package downloaded from 
> https://mac.r-project.org. It was not compiled from source. That was the case 
> on all Macs.
> 
> Please note that the partially log at the bottom of my original message is 
> from a successful compilation on a Mac where ‘install.packages(“XML”) works. 
> It includes references to the CommandLineTools/SDK but that was completely 
> without my doing. I tried it explicitly in various forms, though, when I 
> thought this is the right way. Thanks for clarifying it is not.
> 
> Now, on the Mac where I still have trouble, the output from 
> ‘install.packages(“XML”) is (rather brief):
> 
> > install.packages("XML")
> Warning: unable to access index for repository 
> https://mac.R-project.org/bin/macosx/contrib/4.1:
>   cannot open URL 'https://mac.R-project.org/bin/macosx/contrib/4.1/PACKAGES'
> Package which is only available in source form, and may need compilation of 
> C/C++/Fortran: ‘XML’
> Do you want to attempt to install these from sources? (Yes/no/cancel) Yes
> installing the source package ‘XML’
> 
> trying URL 'https://mac.R-project.org/src/contrib/XML_3.99-0.5.tar.gz'
> Content type 'application/x-gzip' length 968563 bytes (945 KB)
> ==
> downloaded 945 KB
> 
> * installing *source* package ‘XML’ ...
> ** package ‘XML’ successfully unpacked and MD5 sums checked
> ** using staged installation
> checking for gcc... gcc
> 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 gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking how to run the C preprocessor... gcc -E
> checking for sed... /usr/bin/sed
> checking for pkg-config... /usr/local/bin/pkg-config
> checking for xml2-config... /usr/bin/xml2-config
> USE_XML2 = yes
> SED_EXTENDED_ARG: -E
> Minor 9, Patch 4 for 2.9.4
> Located parser file 
> -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/parser.h
> Checking for 1.8:  
> -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
> Using libxml2.*
> checking for gzopen in -lz... yes
> checking for xmlParseFile in -lxml2... yes
> You are trying to use a version 2.* edition of libxml
> but an incompatible library. The header files and library seem to be
> mismatched. If you have specified LIBXML_INCDIR, make certain to also
> specify an appropriate LIBXML_LIBDIR if the libxml2 library is not in the 
> default
> directories.
> ERROR: configuration failed for package ‘XML’
> * removing 
> ‘/Library/Frameworks/R.framework/Versions/4.1/Resources/library/XML’
> * restoring previous 
> ‘/Library/Frameworks/R.framework/Versions/4.1/Resources/library/XML’
> 
> The downloaded source packages are in
>   
> ‘/private/var/folders/j8/1gn6jwcx4bv8td2h83ghk1hhgp/T/RtmpXuYoas/downloaded_packages’
> Warning message:
> In install.packages("XML") :
>   installation of package ‘XML’ had non-zero exit status
> >
> 
> Best,
> Kemal
> 
> 
>> On Feb 15, 2021, at 5:42 PM, Simon Urbanek  
>> wrote:
>> 
>> Kemal,
>> 
>> what Duncan said, since what you provided does not include any of the 
>> information needed.
>> 
>> In addition, you should not include SDK paths directly - SDK is used by the 
>> dev tools and does *not* include the actual libraries. So when you say 
>> 

Re: [R-SIG-Mac] XML packages source compilation on macOS 10.15.7

2021-02-15 Thread Simon Urbanek
Kemal,

what Duncan said, since what you provided does not include any of the 
information needed.

In addition, you should not include SDK paths directly - SDK is used by the dev 
tools and does *not* include the actual libraries. So when you say /foo/bar it 
is actually searched inside the SDK the compiler is using. If you happen to use 
compilers that don't use SDKs (non-Apple) then you can use -isysroot to specify 
the SDK root (hopefully not your case as that is a whole can of worms). In 
addition, the issue may come from your version of R as well so the exact 
information about that is also need (how you compiled it, which flags etc.).

Cheers,
Simon


> On Feb 16, 2021, at 4:26 AM, Duncan Temple Lang via R-SIG-Mac 
>  wrote:
> 
> Hi Kemal
> Can you please send the output from the entire installation attempt, and
> also the config.log file.
> 
> Thanks
> Duncan
> 
> 
> On Mon, Feb 15, 2021 at 5:14 AM Kemal Akat  wrote:
> 
>> Hello all,
>> 
>> I have to compile the XML package from source for R 4.1 (development
>> version) on a Mac with OS version 10.15.7. It works well on all machines
>> that do not come with any significant ballast on developer tools. One
>> machine, however, that I have used for some time returns a mismatch of
>> header files and library. I looked into possible offenders and purged what
>> I could (e.g. deleted Homebrew although the other machines have Homebrew
>> and Miniconda installed as well) but to no avail.
>> 
>> install.packages(“XML”) fails and install.packages("XML",
>> configure.args=c("LIBXML_INCDIR=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libxml2",
>> "LIBXML_LIBDIR=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib”))
>> also fails.
>> 
>> There are obviously differences I cannot track down so far but I am
>> running out of ideas. Both machines have MacOSX10.14.sdk and
>> MacOSX10.15.sdk installed with MacOSX.sdk linking to MacOSX10.15.sdk.
>> 
>> Here is part of the log of a successful compilation, and I was hoping
>> someone could point me towards a solution.
>> 
>> libxml include directory:
>> -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
>> libxml library directory:
>> -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lxml2 -lz
>> -lpthread -licucore -lm -lz  -lxml2
>> libxml 2: -DLIBXML2=1
>> 
>> Compilation flags: -DLIBXML
>> -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
>> -DUSE_EXTERNAL_SUBSET=1 -DROOT_HAS_DTD_NODE=1 -DDUMP_WITH_ENCODING=1
>> -DUSE_XML_VERSION_H=1 -DXML_ELEMENT_ETYPE=1 -DXML_ATTRIBUTE_ATYPE=1
>> -DNO_XML_HASH_SCANNER_RETURN=1 -DLIBXML_NAMESPACE_HAS_CONTEXT=1
>> -DHAVE_R_CETYPE_T=1 -DHAVE_XML_WITH_ZLIB=1 -DHAVE_XML_HAS_FEATURE=1
>> -DUSE_R=1 -D_R_=1  -DHAVE_VALIDITY=1 -DXML_REF_COUNT_NODES=1
>> Link flags:
>> -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lxml2 -lz
>> -lpthread -licucore -lm -lz  -lxml2
>> 
>> 
>> Thanks,
>> Kemal
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
> 
> 
> -- 
> ===
> Duncan Temple Lang
> Associate Dean for Graduate Programs
> Professor, Department of Statistics
> UC Davis
> 
>   [[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] Please test R 4.0.4 RC

2021-02-13 Thread Simon Urbanek
Michael,
Thanks, but please don't post 3rd party links that are just one-liners with 
extra advertising, especially when they have been already mentioned.
Cheers,
Simon


> On Feb 14, 2021, at 15:00, Michael Hall  wrote:
> 
> 
> 
>> On Feb 13, 2021, at 5:41 PM, r-sig-mac-requ...@r-project.org wrote:
>> 
>> xcrun: error: invalid active developer path 
>> (/Library/Developer/CommandLineTools), missing xcrun at: 
>> /Library/Developer/CommandLineTools/usr/bin/xcrun
> 
> https://ma.ttias.be/mac-os-xcrun-error-invalid-active-developer-path-missing-xcrun/
> 
> 
>   [[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] Re: [External] Please test R 4.0.4 RC

2021-02-13 Thread Simon Urbanek
Duncan,

not really - this is why the XQuartz betas are such a disaster - they replace 
libraries with incompatible versions (under same file name) - and even remove 
some libraries, thus breaking anything that was compiled against either 
version. If you downgrade, you have to re-compile anything you compiled against 
the beta. That is probably one of the lesser evils since you can't expect 
anything to be forwards-compatible.

In theory, you could detect the version using otool - that's what X11() is 
doing to find whether XQuartz is present, but it only works for users that have 
dev tools installed, so not a good idea in general.

Cheers,
Simon



> On Feb 14, 2021, at 11:32 AM, Duncan Murdoch  wrote:
> 
> On 13/02/2021 4:54 p.m., Simon Urbanek wrote:
>> As mentioned earlier, the issue is likely that your X11-auto-launch is not 
>> working. You can start X11 (=XQuartz) yourself and set DISPLAY=:0 as you 
>> would on any unix system or start X11 with X11(":0")
>> [personally, I hate that auto-launch "feature" since it tries to start 
>> XQuartz even if you don't want it].
> 
> Thanks.  Here's another datum:  I did my last build of rgl with the beta 
> XQuartz installed.  I'm now back to 2.7.11 and I get this when I try to start 
> rgl:
> 
> > library(rgl)
> Error in dyn.load(dynlib) :
>  unable to load shared object 
> '/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so':
> dlopen(/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so,
>  6): Library not loaded: /opt/X11/lib/libX11.6.dylib
>  Referenced from: 
> /Library/Frameworks/R.framework/Versions/4.0/Resources/library/rgl/libs/rgl.so
>  Reason: Incompatible library version: rgl.so requires version 11.0.0 or 
> later, but libX11.6.dylib provides version 10.0.0
> Error: package or namespace load failed for ‘rgl’:
> .onLoad failed in loadNamespace() for 'rgl', details:
>  call: NULL
>  error:   Loading rgl's DLL failed.
>   This build of rgl depends on XQuartz, which you can download from 
> xquartz.org.
> 
> So it appears they updated the version of libX11.6.dylib, and rgl is asking 
> for the wrong one.
> 
> Is there some way for me to request a particular version during my build, or 
> at least detect that the wrong version is installed?
> 
> Duncan Murdoch
> 
>> Cheers,
>> Simon
>>> On Feb 14, 2021, at 9:50 AM, Richard M. Heiberger  wrote:
>>> 
>>> I tried this.  It made no difference.  Both before and after running
>>> sudo xcode-select —install
>>> I ran (in both cases, in a brand new *R* sessio n)
>>> 
>>>> X11()
>>> xcrun: error: invalid active developer path 
>>> (/Library/Developer/CommandLineTools), missing xcrun at: 
>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>> 
>>> 
>>> My prior was that the xcode call was irrelevant is that X11() using XQuart 
>>> 8.0.3beta
>>> worked with intel R_4.0.3 on the Mac M1.
>>> 
>>> 
>>> From: Dr Eberhard W Lisse 
>>> Sent: Saturday, February 13, 2021 3:33 AM
>>> To: Simon Urbanek; R-SIG-Mac; Richard M. Heiberger
>>> Cc: e...@lisse.na
>>> Subject: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC
>>> 
>>> that has nothing to do with Xquartz but means you need to install the 
>>> Command line tools
>>> 
>>> sudo xcode-select —install
>>> 
>>> —
>>> Sent from Dr Lisse’s iPhone
>>> On 13 Feb 2021, 06:13 +0200, Richard M. Heiberger , wrote:
>>> Using the intel R_4.0.4RC on the Mac M1.
>>> 
>>> Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the 
>>> 8.0.3beta.
>>> X11() now does not work at all.
>>> 
>>> X11()
>>> xcrun: error: invalid active developer path 
>>> (/Library/Developer/CommandLineTools), missing xcrun at: 
>>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>>> C-c C-c C-c C-c
>>> 
>>> Force-Killing XQuartz from the Activity Monitor doesn't help.
>>> I have to Force-kill the R process.
>>> 
>>> 
>>> From: R-SIG-Mac  on behalf of Simon 
>>> Urbanek 
>>> Sent: Friday, February 12, 2021 6:50 PM
>>> To: R-SIG-Mac
>>> Subject: [External] [R-SIG-Mac] Please test R 4.0.4 RC
>>> 
>>> Dear macOS useRs,
>>> 
>>> please test the latest R 4.0.4 RC builds from
>>> 
>>> https://mac.r-project.org/
>>> 
>>> especially if you are running 

Re: [R-SIG-Mac] [External] Re: [External] Please test R 4.0.4 RC

2021-02-13 Thread Simon Urbanek
Richard,

thanks - finally a more complete output to go on. This is exactly the reminder 
why it is so important to post the _full_output - the actual facts were 
completely missing from your previous report.

Firstly, the xcrun output is just a warning which indicates that R can't find 
out whether you have XQuartz installed or not. It also shows that your 
Xcode/command line tools are broken. That in itself is not a problem as long as 
you don't intend to compile packages - but probably you should look into it.

But more importantly your XQuartz doesn't work - or at least is not running at 
the time you are trying to run X11() in R. Make sure you start XQuartz first 
(from Applications -> Utilities) and it works. If in doubt, you can wipe it (it 
lives in /opt/X11) and re-install.

Either way, neither seems to be an R issue per se.

Cheers,
Simon


`
> On Feb 14, 2021, at 11:00 AM, Richard M. Heiberger  wrote:
> 
> another fresh R session
> 
>> X11(":0")
> xcrun: error: invalid active developer path 
> (/Library/Developer/CommandLineTools), missing xcrun at: 
> /Library/Developer/CommandLineTools/usr/bin/xcrun
> Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize,  :
>  unable to start device X11
> In addition: Warning messages:
> 1: In system2("otool", c("-L", shQuote(DSO)), stdout = TRUE) :
>  running command ''otool' -L 
> '/Library/Frameworks/R.framework/Resources/modules/R_X11.so'' had status 1
> 2: In X11(":0") : unable to open connection to X11 display ':0'
>> 
> 
> 
> From: Simon Urbanek 
> Sent: Saturday, February 13, 2021 4:54 PM
> To: Richard M. Heiberger
> Cc: Dr Eberhard W Lisse; R-SIG-Mac
> Subject: Re: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC
> 
> As mentioned earlier, the issue is likely that your X11-auto-launch is not 
> working. You can start X11 (=XQuartz) yourself and set DISPLAY=:0 as you 
> would on any unix system or start X11 with X11(":0")
> [personally, I hate that auto-launch "feature" since it tries to start 
> XQuartz even if you don't want it].
> 
> Cheers,
> Simon
> 
> 
>> On Feb 14, 2021, at 9:50 AM, Richard M. Heiberger  wrote:
>> 
>> I tried this.  It made no difference.  Both before and after running
>> sudo xcode-select —install
>> I ran (in both cases, in a brand new *R* sessio n)
>> 
>>> X11()
>> xcrun: error: invalid active developer path 
>> (/Library/Developer/CommandLineTools), missing xcrun at: 
>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>> 
>> 
>> My prior was that the xcode call was irrelevant is that X11() using XQuart 
>> 8.0.3beta
>> worked with intel R_4.0.3 on the Mac M1.
>> 
>> 
>> From: Dr Eberhard W Lisse 
>> Sent: Saturday, February 13, 2021 3:33 AM
>> To: Simon Urbanek; R-SIG-Mac; Richard M. Heiberger
>> Cc: e...@lisse.na
>> Subject: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC
>> 
>> that has nothing to do with Xquartz but means you need to install the 
>> Command line tools
>> 
>> sudo xcode-select —install
>> 
>> —
>> Sent from Dr Lisse’s iPhone
>> On 13 Feb 2021, 06:13 +0200, Richard M. Heiberger , wrote:
>> Using the intel R_4.0.4RC on the Mac M1.
>> 
>> Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the 
>> 8.0.3beta.
>> X11() now does not work at all.
>> 
>> X11()
>> xcrun: error: invalid active developer path 
>> (/Library/Developer/CommandLineTools), missing xcrun at: 
>> /Library/Developer/CommandLineTools/usr/bin/xcrun
>> C-c C-c C-c C-c
>> 
>> Force-Killing XQuartz from the Activity Monitor doesn't help.
>> I have to Force-kill the R process.
>> 
>> 
>> From: R-SIG-Mac  on behalf of Simon Urbanek 
>> 
>> Sent: Friday, February 12, 2021 6:50 PM
>> To: R-SIG-Mac
>> Subject: [External] [R-SIG-Mac] Please test R 4.0.4 RC
>> 
>> Dear macOS useRs,
>> 
>> please test the latest R 4.0.4 RC builds from
>> 
>> https://mac.r-project.org/
>> 
>> especially if you are running macOS Big Sur. The known issues introduced by 
>> Big Sur have been fixed, but I cannot replicate nor test the spurious 
>> touchbar warning.
>> 
>> Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - 
>> they are betas for a reason (=unstable) and break things.
>> 
>> 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
>> 
> 

___
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] Re: [External] Please test R 4.0.4 RC

2021-02-13 Thread Simon Urbanek
As mentioned earlier, the issue is likely that your X11-auto-launch is not 
working. You can start X11 (=XQuartz) yourself and set DISPLAY=:0 as you would 
on any unix system or start X11 with X11(":0")
[personally, I hate that auto-launch "feature" since it tries to start XQuartz 
even if you don't want it].

Cheers,
Simon


> On Feb 14, 2021, at 9:50 AM, Richard M. Heiberger  wrote:
> 
> I tried this.  It made no difference.  Both before and after running
> sudo xcode-select —install
> I ran (in both cases, in a brand new *R* sessio n)
> 
>> X11()
> xcrun: error: invalid active developer path 
> (/Library/Developer/CommandLineTools), missing xcrun at: 
> /Library/Developer/CommandLineTools/usr/bin/xcrun
> 
> 
> My prior was that the xcode call was irrelevant is that X11() using XQuart 
> 8.0.3beta
> worked with intel R_4.0.3 on the Mac M1.
> 
> 
> From: Dr Eberhard W Lisse 
> Sent: Saturday, February 13, 2021 3:33 AM
> To: Simon Urbanek; R-SIG-Mac; Richard M. Heiberger
> Cc: e...@lisse.na
> Subject: [External] Re: [R-SIG-Mac] [External] Please test R 4.0.4 RC
> 
> that has nothing to do with Xquartz but means you need to install the Command 
> line tools
> 
> sudo xcode-select —install
> 
> —
> Sent from Dr Lisse’s iPhone
> On 13 Feb 2021, 06:13 +0200, Richard M. Heiberger , wrote:
> Using the intel R_4.0.4RC on the Mac M1.
> 
> Based on your recommendation I reinstalled XQuartz 2.7.11 instead of the 
> 8.0.3beta.
> X11() now does not work at all.
> 
> X11()
> xcrun: error: invalid active developer path 
> (/Library/Developer/CommandLineTools), missing xcrun at: 
> /Library/Developer/CommandLineTools/usr/bin/xcrun
> C-c C-c C-c C-c
> 
> Force-Killing XQuartz from the Activity Monitor doesn't help.
> I have to Force-kill the R process.
> 
> 
> From: R-SIG-Mac  on behalf of Simon Urbanek 
> 
> Sent: Friday, February 12, 2021 6:50 PM
> To: R-SIG-Mac
> Subject: [External] [R-SIG-Mac] Please test R 4.0.4 RC
> 
> Dear macOS useRs,
> 
> please test the latest R 4.0.4 RC builds from
> 
> https://mac.r-project.org/
> 
> especially if you are running macOS Big Sur. The known issues introduced by 
> Big Sur have been fixed, but I cannot replicate nor test the spurious 
> touchbar warning.
> 
> Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - 
> they are betas for a reason (=unstable) and break things.
> 
> 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
> 

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


Re: [R-SIG-Mac] Please test R 4.0.4 RC

2021-02-13 Thread Simon Urbanek
Thanks for testing and the reports!

Unfortunately, I cannot reproduce the touch-bar issue, because it doesn''t 
appear when run in Xcode with touch-bar emulation and I don't have a Mac with 
Big Sur and a touch-bar. Moreover, R is not providing custom touch-bar icons so 
I can't even find out which element it is complaining about. If anyone has any 
leads, let me know. If we ever find a work-arournd, it should be possible to do 
in the GUI alone so possibly after the release (unlike the Quartz bug which 
needed changes in core R).

Other projects have seen the same issue so it's likely a macOS bug, but the fix 
that worked for others (re-compile with Xcode 12) did not work for us (the last 
build was using the latests Xcode 12.4). 

Cheers,
Simon



> On Feb 13, 2021, at 3:05 PM, John Fox  wrote:
> 
> Dear Simon,
> 
> I'm still seeing the warning on a MacBook Pro with a touchbar running Big Sur:
> 
> --- snip 
> 
> R version 4.0.4 RC (2021-02-12 r79998) -- "Lost Library Book"
> Copyright (C) 2021 The R Foundation for Statistical Computing
> Platform: x86_64-apple-darwin17.0 (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.
> 
> [R.app GUI 1.74 (7929) x86_64-apple-darwin17.0]
> 
> [History restored from /Users/johnfox/.Rapp.history]
> 
> 2021-02-12 21:00:21.163 R[19677:11057750] Warning: Expected min height of 
> view: () to be less than or 
> equal to 30 but got a height of 32.00. This error will be logged once per 
> view in violation.
> 
> > sessionInfo()
> R version 4.0.4 RC (2021-02-12 r79998)
> Platform: x86_64-apple-darwin17.0 (64-bit)
> Running under: macOS Big Sur 10.16
> 
> Matrix products: default
> BLAS: 
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> loaded via a namespace (and not attached):
> [1] compiler_4.0.4
> 
> --- snip 
> 
> I hope this helps,
> John
> 
> John Fox, Professor Emeritus
> McMaster University
> Hamilton, Ontario, Canada
> web: https://socialsciences.mcmaster.ca/jfox/
> 
> On 2021-02-12 6:50 p.m., Simon Urbanek wrote:
>> Dear macOS useRs,
>> please test the latest R 4.0.4 RC builds from
>> https://mac.r-project.org/
>> especially if you are running macOS Big Sur. The known issues introduced by 
>> Big Sur have been fixed, but I cannot replicate nor test the spurious 
>> touchbar warning.
>> Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - 
>> they are betas for a reason (=unstable) and break things.
>> 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] Optional Libraries, Frameworks and Applications for macOS

2021-02-13 Thread Simon Urbanek
The libraries are used to build the packages - they are all static, so the 
package binaries will include them. It is not intended for users, but rather if 
you were to compile packages on your own and wanted to replicate the CRAN setup.

Cheers,
Simon



> On Feb 13, 2021, at 7:33 PM, Peter West  wrote:
> 
> Are the various libraries at different versions (e.g. geos-3.7.2 & 
> geos-3.8.1) dependencies for different packages? I don’t suppose there’s a 
> list of reverse package dependencies?
> 
> Peter
> 
> 
> —
> p...@ehealth.id.au
> “What comes out of a person is what defiles him.”
> 
> ___
> 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] Please test R 4.0.4 RC

2021-02-12 Thread Simon Urbanek
Dear macOS useRs,

please test the latest R 4.0.4 RC builds from

https://mac.r-project.org/

especially if you are running macOS Big Sur. The known issues introduced by Big 
Sur have been fixed, but I cannot replicate nor test the spurious touchbar 
warning.

Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - 
they are betas for a reason (=unstable) and break things.

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] Bug report: R.app drops Enter key in editor window after line evaluation

2021-02-11 Thread Simon Urbanek
Girish,

Thanks, I can reproduce it, I'll have a look.

Cheers,
Simon


> On Feb 11, 2021, at 21:51, Girish Palya  wrote:
> 
> To reproduce:
> - Open editor window (Cmd-N)
> - type some command (say, x <- 3)
> - hit Cmd-Enter (to evaluate line; cursor stays on the line)
> - hit Enter again (nothing happens - why?)
> - hit Enter the second time (cursor goes to the new line, as expected)
> 
> I don't see the same problem in the command prompt window. This problem
> happens only in the editor window.
> 
> I am using:
> R for macOS GUI 1.74-devel Catalina build (7917), on Macbook Air.
> 
> Thanks
> gp
> 
>   [[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] Problem with dot chart examples in my Mac

2021-02-08 Thread Simon Urbanek
More importantly, the message is a spurious message from the OS, not an error, 
and does not affect the functionality - the FAQ mentions how to disable those 
if they bother you since R has not control over those. If there is an actual 
bug to report, then please use the bug reporting system.

Cheers,
Simon


> On Feb 9, 2021, at 2:52 AM, Peter Dalgaard  wrote:
> 
> R is a collaborative project, not a commercial one. You may need to look 
> around or ask questions if you need something special. For the present case, 
> someone was complaining about a problem, for which the solution was in the 
> very same mailing list thread that he had himself contributed to. 
> 
> We have mechanisms in place for releasing updates in both source and binary 
> formats. The general procedure is outlined on CRAN. For source releases, 
> there is a daily snapshots link on the front page of CRAN. 
> 
> For Mac and Windows binaries, you need to go via the relevant links and for 
> Windows, select links under "Other builds". 
> 
> For Mac, the link is on the Mac page, where you need to find the line saying 
> "Information, tools and most recent daily builds of the R GUI, R-patched and 
> R-devel can be found at http://mac.R-project.org/;. 
> 
> What we do not do is to rush out full releases for any minor problem. We run 
> carefully orchestrated patch releases approximately 4 times per year, with 
> alpha/beta/RC cycles every time, so as to minimize the risk of destabilizing 
> the code.
> 
> - Peter D.
> 
>> On 8 Feb 2021, at 14:02 , Thomas Hopper  wrote:
>> 
>> Peter,
>> 
>> Your comment might be tongue-in-cheek, but taking it at face value, I’d like 
>> to point out that if there’s a fix and users don’t know about it, that’s a 
>> developer communication problem; not a user problem. Most developers deal 
>> with this problem by releasing updated versions of their software, which has 
>> not happened (current CRAN version is 1.73, which is what I’m using); I know 
>> of no developers who have been able to solve this communication problem by 
>> publishing notes about beta versions of their software to email lists that 
>> have low signal to noise ratios.
>> 
>> Seems like there’s a better way to get updates out if the developers want to 
>> avoid users repeatedly pointing out the same bugs.
>> 
>> Thank you,
>> 
>> Tom
>> 
>>> On Feb 8, 2021, at 5:05 AM, Peter Dalgaard  wrote:
>>> 
>>> If you are not aware of the fix, then you are not reading your email...
>>> 
>>> The NSButton message was reported to be gone in RGui v.7903, on r-help by 
>>> mal...@malonequantitative.com on Jan. 18. 
>>> 
>>> Current patch versions (https://mac.r-project.org) are at v.7922. Next 
>>> formal patch release (4.0.4) is on Feb 15, prerelease downloadable from 
>>> said page.
>>> 
>>> - Peter Dalgaard
>>> 
>>> 
>>> 
 On 8 Feb 2021, at 05:47 , Gregory Coats via R-SIG-Mac 
  wrote:
 
 Tom Hopper,
 On Jan 8, 2021, I first reported that R on Mac gave the error message you 
 reported today.
 We R Mac users are all getting this error. It is now a month later. I am 
 not aware of any fix.
 Greg Coats
 
 2021-01-07 22:58:42.997 R[8311:37566]
 Warning: Expected min height of view: 
 () 
 to be less than or equal to 30 but got a height of 32.00. 
 This error will be logged once per view in violation.
 
> On Feb 7, 2021, at 2:51 PM, Tom Hopper  wrote:
 
 
 I'm also seeing the following error:
 2021-02-07 14:41:15.950 R[4408:267051] 
 Warning: Expected min height of view: 
 () 
 to be less than or equal to 30 but got a height of 32.00. 
 This error will be logged once per view in violation.
 
 ___
 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
> 
> -- 
> 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] is there an M1 virtual machine image available for linux?

2020-12-14 Thread Simon Urbanek
To my best knowledge the only way to test anything on M1 is to buy one. As far 
as I know there is no virtual solution yet. If you see one, let me know.

As for CRAN there is no official arm64 build yet - the hardware just arrived 
and I need to setup the nightly builds first before moving to packages. 
However, Brian Ripley has run a first pass over all packages to give authors 
chance to look at what breaks on the new architecture - it is listed on the 
check page in the additional checks section.

>From what I can see some of your packages broke on the regular check systems 
>and have not been fixed after several requests which why your packages were 
>under threat to be removed, it has nothing to fo with M1 as far as I can tell.

Cheers,
Simon



> On 15/12/2020, at 4:02 PM, Joshua N Pritikin  wrote:
> 
> On Tue, Dec 15, 2020 at 03:54:12PM +1300, Simon Urbanek wrote:
>> I don't think that is feasible (assuming you mean macOS 11 arm64 
>> system running in a VM). Note that M1 is not just the CPU, there is 
>> much tighter integration of all the components so you'd have to 
>> emulate a lot more than that and also all the Apple security 
>> components etc. in order to be able to boot macOS on an arm emulation. 
> 
> OK, so how do I test my package on M1?
> 
> I've been threatened with removal from CRAN if I don't get it working.
> 
> Thank you.
> 

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


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

2020-12-14 Thread Simon Urbanek
I don't think that is feasible (assuming you mean macOS 11 arm64 system running 
in a VM). Note that M1 is not just the CPU, there is much tighter integration 
of all the components so you'd have to emulate a lot more than that and also 
all the Apple security components etc. in order to be able to boot macOS on an 
arm emulation. It is possible to run Intel macOS in a VM on an Intel Mac, 
because there is the pass-through to the underlying hardware for things that 
cannot be emulated, but I suspect that is not possible for the arm version. You 
can certainly run Linux in arm emulation, but I don't think you can expect 
macOS to work that way anytime soon.

Cheers,
Simon




> On 15/12/2020, at 2:02 PM, Joshua N Pritikin  wrote:
> 
> Something like https://wiki.debian.org/Arm64Qemu ?
> 
> ___
> 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] NSButton Message in R.app

2020-12-14 Thread Simon Urbanek
Unfortunately, I don't have a Mac with a touch bar to replicate it, I'll see if 
there is any other way to test it. The GUI doesn't actually use the touch bar, 
so it's not clear where that message comes from. It seems like just a benign 
output from the system - it doesn't really affect any functionality, but if it 
annoys you, you can disable it until we find out more - see R for Mac FAQ 10.4.

Cheers,
Simon


> On 15/12/2020, at 1:14 PM, Macdonald, Peter  wrote:
> 
> We discussed this in r-sig-mac a couple of weeks ago but the thread got 
> hijacked by unrelated Big Sur issues and I don’t think this problem was ever 
> resolved.
> 
> It seems to be an issue with R GUI and MacBook Pro. It arose with the final 
> versions of Catalina and continued with Big Sur on my 15 inch 2018 MacBook 
> Pro. The error is generated whenever the GUI uses the Touch Bar.
> 
> The Touch Bar works correctly despite and I’ve seen no other consequences.
> 
> I was going to bring this up again, thanks for saving me the trouble!
> 
> Hoping that an R GUI developer can fix it?
> 
> Thanks,
> Peter 
> 
> --
> Peter D.M. Macdonald, D.Phil., P.Stat.   
> Professor Emeritus of Math & Statistics
> McMaster University
> Hamilton, Ontario, Canada L8S 4K1
> 
> 
> 
> 
>> On Dec 14, 2020, at 6:43 PM, Chacko, George  wrote:
>> 
>> Hello all:
>> 
>> My apologies if I’m not providing this information in a useful manner, I’m 
>> new to this list. I’d be happy to revise this message for greater clarity 
>> with a little advice from the list. After upgrading to Big Sur on a 16 inch 
>> Macbook Pro, I’ve noticed an NSButton warning message. Reinstalling R hasn’t 
>> helped. Thanks for any advice. George Chacko
>> 
>> 
>>  1.  when R.app is started up
>> 
>> 2020-12-14 09:24:32.330 R[30638:726731] Warning: Expected min height of 
>> view: () to be less than or 
>> equal to 30 but got a height of 32.00. This error will be logged once 
>> per view in violation.
>> 
>> 
>>  1.  Once R is running, if I use Command-W to exit and then hit cancel, 5 
>> copies of this message are printed on screen.
>> 
>> 2020-12-14 09:25:25.900 R[30638:726731] Warning: Expected min height of 
>> view: () to be less than or equal to 30 but got a 
>> height of 32.00. This error will be logged once per view in violation.
>> 2020-12-14 09:25:25.904 R[30638:726731] Warning: Expected min height of 
>> view: () to be less than or equal to 30 but got a 
>> height of 32.00. This error will be logged once per view in violation.
>> 2020-12-14 09:25:25.904 R[30638:726731] Warning: Expected min height of 
>> view: () to be less than or equal to 30 but got a 
>> height of 32.00. This error will be logged once per view in violation.
>> 2020-12-14 09:25:27.513 R[30638:726731] Warning: Expected min height of 
>> view: () to be less than or equal to 30 but got a 
>> height of 32.00. This error will be logged once per view in violation.
>> 2020-12-14 09:25:27.516 R[30638:726731] Warning: Expected min height of 
>> view: () to be less than or equal to 30 but got a 
>> height of 32.00. This error will be logged once per view in violation.
>> 2020-12-14 09:25:27.517 R[30638:726731] Warning: Expected min height of 
>> view: () to be less than or equal to 30 but got a 
>> height of 32.00. This error will be logged once per view in violation.
>> 
>> 
>> 
>> 
>>> utils::sessionInfo()
>> R version 4.0.3 (2020-10-10)
>> Platform: x86_64-apple-darwin17.0 (64-bit)
>> Running under: macOS Big Sur 10.16
>> 
>> Matrix products: default
>> BLAS:   
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
>> LAPACK: 
>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
>> 
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_4.0.3
>> 
>> 
>> Model Name:  MacBook Pro
>> 
>>  Model Identifier:   MacBookPro16,1
>> 
>>  Processor Name: 8-Core Intel Core i9
>> 
>>  Processor Speed:2.3 GHz
>> 
>>  Number of Processors:1
>> 
>>  Total Number of Cores:   8
>> 
>>  L2 Cache (per Core):256 KB
>> 
>>  L3 Cache: 16 MB
>> 
>>  Hyper-Threading Technology:Enabled
>> 
>>  Memory:32 GB
>> 
>>  System Firmware Version:  1554.50.3.0.0 (iBridge: 18.16.12561.0.0,0)
>> 
>>  Serial Number (system):  C02DM3MVMD6T
>> 
>>  Hardware UUID:   
>> 4A8B6D86-683A-5ED1-A229-BD6147F02F11
>> 
>>  Provisioning UDID:   
>> 4A8B6D86-683A-5ED1-A229-BD6147F02F11
>> 
>>  Activation Lock Status:Disabled
>> 
>> 
>> 
>> 
>> 
>> [[alternative HTML version deleted]]
>> 
>> 

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

2020-12-13 Thread Simon Urbanek
Petar,

thanks, that output helps. As part of the cleanup R executes a system() command 
which crashes, causing the hang as the GUI tries to recover from the crash, but 
fails.

I tried to use a different way to issue the system() command, so please try the 
Mac GUI rev. 7903 or higher from https://mac.R-project.org which should become 
available after the nightly build in the next 24h (scroll down to Mac OS X GUI 
and you can run it directly from the downloaded image, you don't have to 
install it).

Thanks,
Simon



> On 14/12/2020, at 10:21 AM, Petar Milin  wrote:
> 
> Dear Simon,
> 
> Sample Process attached (it was faster)
> 
> Regards,
> Petar
> 
> 
> 
> 
>> On 13 Dec 2020, at 20:37, Simon Urbanek  wrote:
>> 
>> Petar,
>> 
>> there are two options that would be helpful to us to trace it:
>> 
>> 1) use the Debug version of the GUI (from https://mac.R-project.org/ - make 
>> sure you pick the one that matches your R version) and check the console 
>> when that happens - you should likely see some output there
>> 
>> 2) when using the regular version and this happens, please open the Activity 
>> Monitor, select the R process, click on the little wheel in the tool bar and 
>> select "Sample Process" and send me the resulting file.
>> 
>> Thanks,
>> Simon
>> 
>> 
>> 
>>> On 14/12/2020, at 1:47 AM, Petar Milin  wrote:
>>> 
>>> Following on this thread
>>> https://stat.ethz.ch/pipermail/r-sig-mac/2020-October/013752.html 
>>> <https://stat.ethz.ch/pipermail/r-sig-mac/2020-October/013752.html>
>>> 
>>> I did upgrade to 4.0.3, but the same problem persist: occasionally R 
>>> refuses to terminate and I need to do the Force Quit. This happens only 
>>> with GUI and not if I use RStudio.
>>> 
>>> The difference in behaviour between 4.0.2 and 4.0.3 is that the former 
>>> closed the GUI but R remain to run and started heating the machine. The 
>>> latter's GUI stays open and just hangs. Activity Monitor shows that this is 
>>> taking a lot of resources.
>>> 
>>> Any suggestion?
>>> 
>>> Many thanks!
>>> Petar
>>> [[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] Follow up on R 4.0.2 GUI does not terminate with Cmd+Q

2020-12-13 Thread Simon Urbanek
Petar,

there are two options that would be helpful to us to trace it:

1) use the Debug version of the GUI (from https://mac.R-project.org/ - make 
sure you pick the one that matches your R version) and check the console when 
that happens - you should likely see some output there

2) when using the regular version and this happens, please open the Activity 
Monitor, select the R process, click on the little wheel in the tool bar and 
select "Sample Process" and send me the resulting file.

Thanks,
Simon



> On 14/12/2020, at 1:47 AM, Petar Milin  wrote:
> 
> Following on this thread
>   https://stat.ethz.ch/pipermail/r-sig-mac/2020-October/013752.html 
> 
> 
> I did upgrade to 4.0.3, but the same problem persist: occasionally R refuses 
> to terminate and I need to do the Force Quit. This happens only with GUI and 
> not if I use RStudio.
> 
> The difference in behaviour between 4.0.2 and 4.0.3 is that the former closed 
> the GUI but R remain to run and started heating the machine. The latter's GUI 
> stays open and just hangs. Activity Monitor shows that this is taking a lot 
> of resources.
> 
> Any suggestion?
> 
> Many thanks!
> Petar
>   [[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-4.0-branch x86_64: make FAILED

2020-12-08 Thread Simon Urbanek
Olivier,

thank you for the report. It seems that the following build has succeeded. 
Since those are nightly builds from "live" branches it quite possible for them 
to fail - in this case whatever the issue was it got fixed by the next build.

Thanks,
Simon



> On Dec 8, 2020, at 8:56 AM, Olivier  wrote:
> 
> There is an issue with the build usually available at 
> https://mac.r-project.org/high-sierra/R-4.0-branch/x86_64/R-4.0-branch.tar.gz 
> 
> 
>   x86_64: make FAILED
> 
> Apologies if it’s not the proper channel to report that.
> 
> Regards,
> Olivier
>   [[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] OpenJPEG in GDAL [Was: Problems with R and Big Sur]

2020-12-03 Thread Simon Urbanek
Gilberto,

well, that one is easy and has nothing to do with tools nor with BigSur - no 
one asked for OpenJPEG support so that's why OpenJPEG is not included on the 
build machine. There are several dozen of optional features in GDAL and I have 
no idea which are useful, which are not and which are legacy, so it's up to the 
rgdal maintainers or users to signal if there is anything useful missing. Given 
the complexity of GDAL dependencies and corresponding continuous build issues 
I'm relying on them to tell me when it's safe to update/change settings. Simply 
adding the OpenJPEG library seems sufficient:

> grep("JP2", rgdal::gdalDrivers()$name, value=TRUE)
[1] "JP2OpenJPEG"

so that is now available in the CRAN binary.

Cheers,
Simon



> On 3/12/2020, at 9:50 PM, Gilberto Camara  
> wrote:
> 
> Dear Simon, 
> 
> To test the error, please do the following on a Mac with Big Sur:
> 
> 1. Install GDAL
>   The available binaries I could find out are Mac OS Frameworks from 
> https://www.kyngchaos.com/software/frameworks/ and “homebrew”.
> 
> 2. Install rgdal binary from CRAN
> I am using R version 4.0.3 Patched (2020-11-25 r79505) and the rgdal version 
> is 1.5-18 (SVN revision 1082), the latest ones available on CRAN.
> 
> 3. Do the following R commands:
>> drvs <- rgdal::gdalDrivers()$name; drvs[grep("JP2", drvs)]
> character(0)
> 
> The response indicates that the JPEG2000 driver is not installed.
> 
> After installing both GDAL and rgdal from source with Apple clang 12.0, we get
> 
>> drvs <- rgdal::gdalDrivers()$name; drvs[grep("JP2", drvs)]
> “JP2OpenJPEG"
> 
> More details on the rgdal version compiled from source with the new GDAL: 
> 
>> library(rgdal)
> Loading required package: sp
> rgdal: version: 1.5-18, (SVN revision 1082)
> Geospatial Data Abstraction Library extensions to R successfully loaded
> Loaded GDAL runtime: GDAL 3.2.0, released 2020/10/26
> Path to GDAL shared files: /Users/gilbertocamara/Library/R/4.0/library/sf/gdal
> GDAL binary built with GEOS: TRUE 
> Loaded PROJ runtime: Rel. 7.1.1, September 1st, 2020, [PJ_VERSION: 711]
> Path to PROJ shared files: /Users/gilbertocamara/Library/Application 
> Support/proj:/usr/local/share/proj:/usr/local/share/proj
> PROJ CDN enabled: FALSE
> Linking to sp version:1.4-4
> 
> Hope this helps
> Gilberto
> 
> 
>> On 3 Dec 2020, at 01:07, Simon Urbanek  wrote:
>> 
>> Gilberto,
>> 
>> can you provide details, please? (code, file to test etc.) The claim was 
>> that this is specific to BigSur which I doubt from your description. Please 
>> start a new thread about that at it seem entirely unrelated to the 
>> discussion at hand. There was an incompatibility with BigSur, but that was 
>> addressed.
>> 
>> Thanks,
>> Simon
>> 
>> 
>> 
>> 
>>> On 3/12/2020, at 11:11 AM, GilbertoCamara  
>>> wrote:
>>> 
>>> Dear Simon 
>>> 
>>> Unfortunately, the problems reported are real. The rgdal version from CRAN 
>>> fails to recognise images in JPEG2000 format used by Copernicus Sentinel-2 
>>> satellite. I have investigated the matter carefully with Roger Bivand. 
>>> 
>>> I tried many combinations on Mac OS Big Sur: 
>>> (a) rgdal from CRAN (binary) + GDAL from homebrew.
>>> (b) rgdal from CRAN (source) + GDAL from homebrew.
>>> (c) rgdal from CRAN (binary) + GDAL Mac OS Frameworks from 
>>> https://www.kyngchaos.com/software/frameworks/
>>> (d) rgdal from CRAN (source) + GDAL from kyngchaos. 
>>> (e) rgdal from CRAN (source) + GDAL/GEOS/etc (source) with Apple clang 11.0
>>> (f) rgdal from CRAN (source) + GDAL/GEOS/etc (source) with Apple clang 12.0
>>> 
>>> Only option (f) works correctly. 
>>> 
>>> Best regards
>>> Gilberto 
>>> 
>>>> On 2 Dec 2020, at 22:44, Simon Urbanek  wrote:
>>>> 
>>>> Are you chasing a red herring here? Switching tools won help you - in fact 
>>>> they cause more issues since you'd need R-devel version of R to avoid 
>>>> breakage with the most recent tools or extra flags. I'm not sure which 
>>>> issue you are trying to solve. For gdal et al - make sure you install the 
>>>> latest version for CRAN - it is compatible with BigSur, older versions 
>>>> (before BigSur) were not.
>>>> 
>>>> Please start a new thread about questions unrelated to the original post 
>>>> as it's unclear if there are any open questions in the thread. Also please 
>>>> only answer if your have anything useful to sa

  1   2   3   4   5   6   7   >