from:"Richard M. Heiberger"

success:
I mounted the remote disk directly without first downloading it to my machine:
rmh@MacBook-Air ~ % hdiutil mount 
"https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg;
/dev/disk6  GUID_partition_scheme
/dev/disk6s1Apple_APFS
/dev/disk7  EF57347C--11AA-AA11-0030654
/dev/disk7s141504653--11AA-AA11-0030654 
/Volumes/emacs-27.1-app-arm64-darwin20 1
rmh@MacBook-Air ~ %

Then I
1. opened "/Volumes/emacs-27.1-app-arm64-darwin20 1" and ran Emacs from there.
2. copied the Emacs.app to /Applications/ and ran Emacs from there.


From: R-SIG-Mac  on behalf of Richard M. 
Heiberger 
Sent: Monday, March 8, 2021 14:19
To: Prof Brian Ripley; Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] [External] Re: [External] Re: [External] Re: Mac M1 
emacs

Originally I used right-click "Download linked file" on the url in the email.  
The file appeared in ~/Downloads/
and looked normal to me.

Just now, following your suggestion,
I used curl three times, twice inside *shell* in emacs (Vincent Goulet's intel 
version) and once in Terminal.
This is from Terminal:
rmh@MacBook-Air ~ % curl -O 
http://mac.R-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   162  100   1620 0   1396  0 --:--:-- --:--:-- --:--:--  1396
rmh@MacBook-Air ~ % pwd
/Users/rmh
rmh@MacBook-Air ~ % ls -alF *dmg
-rw-r--r--@ 1 rmh  staff  162 Mar  8 13:42 emacs-27.1-app-arm64-darwin20.dmg
rmh@MacBook-Air ~ %

This is the contents of the downloaded file:

301 Moved Permanently

301 Moved Permanently
nginx







terminology.
My March 1 email to ess-help quoted the Apple Problem Report message
that included the lines:
Exception Type:EXC_CRASH (SIGABRT)
Exception Codes:   0x, 0x
Exception Note:EXC_CORPSE_NOTIFY






From: Prof Brian Ripley 
Sent: Monday, March 8, 2021 13:30
To: Richard M. Heiberger; Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: Mac M1 emacs

On 08/03/2021 17:59, Richard M. Heiberger wrote:
> I updated the OS to 11.2.2, again redownloaded the app
> https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg
> and still get the damaged app message.

How did you download it?  That page and R-admin recommend using curl and
when I did that it works for me, both running from the image and copying
somewhere other than /Applications (as I have another Emacs there).

OTOH, I've not seen any problems with Vincent Goulet's Intel build on my
M1 Mac.  The posting guide for this list does ask you not to use 'crash'


>
> I attempted Ctrl-Click Open (hoping to get past the app from untrusted source 
> issue) and that also gave me the Damaged App message.
>
> The next option they offer is
> "
> 4: Use xattr on the App Throwing the Damaged Error
> This is sort of a last resort and is only recommended for advanced Mac users. 
> Generally speaking if the app is still throwing a ‘damaged’ error message you 
> might want to not use it. Use this at your own risk.
>
> With the command line you can use xattr to view and remove extended 
> attributes from a file on the Mac including the application throwing the 
> “Appname.app is damaged and can’t be opened. You should move it to the 
> Trash.” error message.
>
> Launch Terminal and then issue the following command:
>
> xattr -cr /path/to/application.app
> "
> and I am not willing to do that.
>
> Perhaps if I compile on my machine from your recipe, it might work.
> I am a git novice, so I will need an explicit statement and instructions to 
> try that.
>
> Rich
>
> 
> From: R-SIG-Mac  on behalf of Richard M. 
> Heiberger 
> Sent: Monday, March 8, 2021 11:55
> To: Simon Urbanek
> Cc: r-sig-mac@r-project.org
> Subject: Re: [R-SIG-Mac] [External] Re:  [External] Re:  Mac M1 emacs
>
> I tried the all-purpose computer repair and rebooted the machine.  It still 
> reports a damaged app.
>
> I am now ooking at 
> https://osxdaily.com/2019/02/13/fix-app-damaged-cant-be-opened-trash-error-mac/
> and wi report back.
>
> 
> From: Richard M. Heiberger 
> Sent: Monday, March 8, 2021 00:29
> To: Simon Urbanek
> Cc: r-sig-mac@r-project.org
> Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs
>
> yes, I did.  that also gave the same message.
>
> Also, the ~/Downloads and ~/Desktop directories are no longer available from 
> the original intel Emacs (I c

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

wonderful.  thank you.

I copied from Vincent's version to Simon's
Resources/doc/
esources/etc/ess/
Resources/etc/org/schema/
Resources/etc/org/styles/
Resources/info/auctex.info*
Resources/info/auctex.info*
Resources/info/dir
Resources/info/ess.info
Resources/info/org
Resources/info/orgguide
Resources/info/preview-latex.info
Resources/site-lisp

I deleted from Simon's
Resources/share/
Resources/site-lisp/

Vincent's has a directory Contents/_CodeSignature that is not matched in Simon's


I renamed Vincent's to Emacs-27.1-intel.app

and use the name Emacs.app for the new arm64 app.



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

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

Originally I used right-click "Download linked file" on the url in the email.  
The file appeared in ~/Downloads/
and looked normal to me.

Just now, following your suggestion,
I used curl three times, twice inside *shell* in emacs (Vincent Goulet's intel 
version) and once in Terminal.
This is from Terminal:
rmh@MacBook-Air ~ % curl -O 
http://mac.R-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100   162  100   1620 0   1396  0 --:--:-- --:--:-- --:--:--  1396
rmh@MacBook-Air ~ % pwd
/Users/rmh
rmh@MacBook-Air ~ % ls -alF *dmg
-rw-r--r--@ 1 rmh  staff  162 Mar  8 13:42 emacs-27.1-app-arm64-darwin20.dmg
rmh@MacBook-Air ~ %

This is the contents of the downloaded file:

301 Moved Permanently

301 Moved Permanently
nginx







terminology.
My March 1 email to ess-help quoted the Apple Problem Report message
that included the lines:
Exception Type:EXC_CRASH (SIGABRT)
Exception Codes:   0x, 0x
Exception Note:EXC_CORPSE_NOTIFY






From: Prof Brian Ripley 
Sent: Monday, March 8, 2021 13:30
To: Richard M. Heiberger; Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: Mac M1 emacs

On 08/03/2021 17:59, Richard M. Heiberger wrote:
> I updated the OS to 11.2.2, again redownloaded the app
> https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg
> and still get the damaged app message.

How did you download it?  That page and R-admin recommend using curl and
when I did that it works for me, both running from the image and copying
somewhere other than /Applications (as I have another Emacs there).

OTOH, I've not seen any problems with Vincent Goulet's Intel build on my
M1 Mac.  The posting guide for this list does ask you not to use 'crash'


>
> I attempted Ctrl-Click Open (hoping to get past the app from untrusted source 
> issue) and that also gave me the Damaged App message.
>
> The next option they offer is
> "
> 4: Use xattr on the App Throwing the Damaged Error
> This is sort of a last resort and is only recommended for advanced Mac users. 
> Generally speaking if the app is still throwing a ‘damaged’ error message you 
> might want to not use it. Use this at your own risk.
>
> With the command line you can use xattr to view and remove extended 
> attributes from a file on the Mac including the application throwing the 
> “Appname.app is damaged and can’t be opened. You should move it to the 
> Trash.” error message.
>
> Launch Terminal and then issue the following command:
>
> xattr -cr /path/to/application.app
> "
> and I am not willing to do that.
>
> Perhaps if I compile on my machine from your recipe, it might work.
> I am a git novice, so I will need an explicit statement and instructions to 
> try that.
>
> Rich
>
> 
> From: R-SIG-Mac  on behalf of Richard M. 
> Heiberger 
> Sent: Monday, March 8, 2021 11:55
> To: Simon Urbanek
> Cc: r-sig-mac@r-project.org
> Subject: Re: [R-SIG-Mac] [External] Re:  [External] Re:  Mac M1 emacs
>
> I tried the all-purpose computer repair and rebooted the machine.  It still 
> reports a damaged app.
>
> I am now ooking at 
> https://osxdaily.com/2019/02/13/fix-app-damaged-cant-be-opened-trash-error-mac/
> and wi report back.
>
> 
> From: Richard M. Heiberger 
> Sent: Monday, March 8, 2021 00:29
> To: Simon Urbanek
> Cc: r-sig-mac@r-project.org
> Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs
>
> yes, I did.  that also gave the same message.
>
> Also, the ~/Downloads and ~/Desktop directories are no longer available from 
> the original intel Emacs (I changed
> its name to Emacs-21.7-intel.app).
> it says "access-files" are available.
> This is familiar.  I had it before.  the answer is here, and it works.
> https://emacs.stackexchange.com/questions/53904/why-cant-i-list-the-contents-of-desktop-on-macos-using-dired
>
> I don't this this is the damage problem.
> I have downloaded it three times from R-project and I get the same "damaged" 
> problem each time.
>
> 
> From: Simon Urbanek 
> Sent: Sunday, March 7, 2021 23:52
> To: Richard M. Heiberger
> Cc: r-sig-mac@r-project.org
> Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs
>
> 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 
> s

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

I updated the OS to 11.2.2, again redownloaded the app
https://mac.r-project.org/libs-arm64/emacs-27.1-app-arm64-darwin20.dmg
and still get the damaged app message.

I attempted Ctrl-Click Open (hoping to get past the app from untrusted source 
issue) and that also gave me the Damaged App message.

The next option they offer is
"
4: Use xattr on the App Throwing the Damaged Error
This is sort of a last resort and is only recommended for advanced Mac users. 
Generally speaking if the app is still throwing a ‘damaged’ error message you 
might want to not use it. Use this at your own risk.

With the command line you can use xattr to view and remove extended attributes 
from a file on the Mac including the application throwing the “Appname.app is 
damaged and can’t be opened. You should move it to the Trash.” error message.

Launch Terminal and then issue the following command:

xattr -cr /path/to/application.app
"
and I am not willing to do that.

Perhaps if I compile on my machine from your recipe, it might work.
I am a git novice, so I will need an explicit statement and instructions to try 
that.

Rich

From: R-SIG-Mac  on behalf of Richard M. 
Heiberger 
Sent: Monday, March 8, 2021 11:55
To: Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] [External] Re:  [External] Re:  Mac M1 emacs

I tried the all-purpose computer repair and rebooted the machine.  It still 
reports a damaged app.

I am now ooking at 
https://osxdaily.com/2019/02/13/fix-app-damaged-cant-be-opened-trash-error-mac/
and wi report back.

____
From: Richard M. Heiberger 
Sent: Monday, March 8, 2021 00:29
To: Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

yes, I did.  that also gave the same message.

Also, the ~/Downloads and ~/Desktop directories are no longer available from 
the original intel Emacs (I changed
its name to Emacs-21.7-intel.app).
it says "access-files" are available.
This is familiar.  I had it before.  the answer is here, and it works.
https://emacs.stackexchange.com/questions/53904/why-cant-i-list-the-contents-of-desktop-on-macos-using-dired

I don't this this is the damage problem.
I have downloaded it three times from R-project and I get the same "damaged" 
problem each time.

From: Simon Urbanek 
Sent: Sunday, March 7, 2021 23:52
To: Richard M. Heiberger
Cc: r-sig-mac@r-project.org
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

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 m

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

I tried the all-purpose computer repair and rebooted the machine.  It still 
reports a damaged app.

I am now ooking at 
https://osxdaily.com/2019/02/13/fix-app-damaged-cant-be-opened-trash-error-mac/
and wi report back.

From: Richard M. Heiberger 
Sent: Monday, March 8, 2021 00:29
To: Simon Urbanek
Cc: r-sig-mac@r-project.org
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

yes, I did.  that also gave the same message.

Also, the ~/Downloads and ~/Desktop directories are no longer available from 
the original intel Emacs (I changed
its name to Emacs-21.7-intel.app).
it says "access-files" are available.
This is familiar.  I had it before.  the answer is here, and it works.
https://emacs.stackexchange.com/questions/53904/why-cant-i-list-the-contents-of-desktop-on-macos-using-dired

I don't this this is the damage problem.
I have downloaded it three times from R-project and I get the same "damaged" 
problem each time.

From: Simon Urbanek 
Sent: Sunday, March 7, 2021 23:52
To: Richard M. Heiberger
Cc: r-sig-mac@r-project.org
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

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

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

yes, I did.  that also gave the same message.

Also, the ~/Downloads and ~/Desktop directories are no longer available from 
the original intel Emacs (I changed
its name to Emacs-21.7-intel.app).
it says "access-files" are available.
This is familiar.  I had it before.  the answer is here, and it works.
https://emacs.stackexchange.com/questions/53904/why-cant-i-list-the-contents-of-desktop-on-macos-using-dired

I don't this this is the damage problem.
I have downloaded it three times from R-project and I get the same "damaged" 
problem each time.


From: Simon Urbanek 
Sent: Sunday, March 7, 2021 23:52
To: Richard M. Heiberger
Cc: r-sig-mac@r-project.org
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re:  Mac M1 emacs

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

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

it claims to be damaged.

I sent a copy of this screenshot a few minutes ago and
it was >156KB and held for moderation, this copy is 32KB.


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

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

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

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 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
/Volumes/Emacs/Emacs.app/Contents/MacOS/lib-x86_64-10_14/libgnutls.30.dylib:
Mach-O 64-bit dynamically lin

[R-SIG-Mac] Mac M1 emacs

I originally asked this question on the ess-help list, I now think it belongs 
here.

emacs 21.1, specifically Vincent Goulet's distribution, crashes regularly on my 
Mac M1.
It looks to me like it is using the intel compilation through rosetta instead 
of the arm
compilation.
Vincent's distribution is based on
https://emacsformacosx.com/emacs-builds/Emacs-27.1-1-universal.dmg
which contains
lrwxr-xr-x   1 rmh  staff16 Aug 12  2020 bin -> bin-x86_64-10_10
  drwxr-xr-x   6 rmh  staff   204 Aug 12  2020 bin-x86_64-10_10
  drwxr-xr-x   6 rmh  staff   204 Aug 12  2020 bin-x86_64-10_14
 
The crash report says
My March 1 crash report said
> Process:   Emacs-x86_64-10_14 [1112]
> Path:  
> /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
> Identifier:org.gnu.Emacs
> Version:   Version 27.1 (9.0)
> Code Type: X86-64 (Translated)
> Parent Process:??? [1]
> Responsible:   Emacs-x86_64-10_14 [1112]

which I interpret as saying that it ran the intel compilation
> Responsible:   Emacs-x86_64-10_14 [1112]
 translated through
rosetta.  It seems not to have run the arm compilation, even though the link
rwxr-xr-x   1 rmh  staff16 Aug 12  2020 bin -> bin-x86_64-10_10
looks to me like it should have been running bin-x86_64-10_10

Is my interpretation correct? and if so how do I get the program to run the 
native M1
compilation.
___
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 Richard M. Heiberger

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

Re: [R-SIG-Mac] [External] Re: [External] Re: more rgl problems

2021-02-20 Thread Richard M. Heiberger

yes it is there. when you click the cran main page fir windows or mac, the mac 
is 4.0.3


Get Outlook for iOS<https://aka.ms/o0ukef>

From: John Fox 
Sent: Saturday, February 20, 2021 12:38:11 PM
To: Richard M. Heiberger ; Duncan Murdoch 
; r-sig-mac@r-project.org 
Subject: [External] Re: [R-SIG-Mac] [External] Re: more rgl problems

Dear Rich,

I see R-4.0.4.pkg (not RC) at <https://cran.r-project.org/bin/macosx/>.
Perhaps refresh the page in your browser?

Best,
  John

John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

On 2021-02-20 10:45 a.m., Richard M. Heiberger wrote:
> I am running it now on 4.0.4RC.
>
> The cran page
> https://cran.r-project.org
> offers download of 4.0.3 for mac, even though 4.0.4 is available on windows.
>
> 
> From: Duncan Murdoch 
> Sent: Saturday, February 20, 2021 9:41 AM
> To: Richard M. Heiberger; r-sig-mac@r-project.org
> Subject: Re: [External] Re: more rgl problems
>
> If you are set up to install from source, could you try this?
>
> devtools::install_github("dmurdoch/rgl@quartzbug", type="source")
>
> If you only have some of the requirements (e.g. no devel versions of
> packages) you might find you only get a partial build with no X11
> display; that won't really test the workaround.  In that case I'll try
> to build a binary for your R version.
>
> Duncan Murdoch
>
> On 18/02/2021 6:07 p.m., Richard M. Heiberger wrote:
>> This is from my MacBook Air mid-2012 running Catalina 10.15.7
>> with Xquartz 2.7.11
>> I never placed the beta on this machine.
>> I also see from a fresh R session
>>
>>  plot(1:10, col=7)
>>  library(rgl)
>>  open3d()
>>
>> is fine, whereas this:
>>
>>  library(rgl)
>>  plot(1:10, col=7)
>>  open3d()
>> segfaults
>>
>> 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)
>>
>> 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(rgl)
>>  plot(1:10, col=7)
>>  open3d()
>>  library(rgl)
>>>  plot(1:10, col=7)
>>>  open3d()
>>
>> error: xp_attach_gl_context returned: 2
>>
>>*** caught segfault ***
>> address 0x18, cause 'memory not mapped'
>>
>> Traceback:
>>1: rgl.open(useNULL)
>>2: open3d()
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> Selection: 2
>> Warning message:
>> In rgl.open(useNULL) : RGL: ERROR: can't bind glx context to window
>>
>> Process R finished at Thu Feb 18 17:57:37 2021
>>
>>
>> 
>> From: Duncan Murdoch 
>> Sent: Thursday, February 18, 2021 3:20 PM
>> To: Richard M. Heiberger; r-sig-mac@r-project.org
>> Subject: [External] Re: more rgl problems
>>
>> I've made some progress on this, but I don't know how to fix it properly.
>>
>> What's happening is that rgl is trying to open the new window that
>> open3d() asks for.  It gets most of the way through that operation, then
>> calls glXMakeCurrent, which associates the OpenGL context with that
>> window.  That call fails, but without generating any of the documented
>> errors:  it just fails, triggering an X11 error handler with error code
>> 0 (which typically means no error).
>>
>> In the released versions of rgl, that failure leads to a segfault,
>> because I wasn't doing enough error checking.  I've fixed the segfault,
>> but I'm still getting the error (in fact I'm getting it a lot more than
>> I used to; not sure if it's my debugging code causing that), and after I
>> get the error reported on screen, the new rgl window opens but doesn't
>&

Re: [R-SIG-Mac] [External] Re: more rgl problems

2021-02-20 Thread Richard M. Heiberger

it ran to completion (with warnings).  then i dropped the three lines in and it 
worked.

lt for newer macOS version (11.0) than being linked (10.13)
ld: warning: dylib (/usr/local/lib/libpng16.dylib) was built for newer macOS 
version (11.0) than being linked (10.13)
mkdir -p ../inst/useNULL
mv useNULL/rgl.so ../inst/useNULL/
installing to /Users/rmh/Library/R/4.0/library/00LOCK-rgl/00new/rgl/libs
** R
** demo
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
*** copying figures
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (rgl)
>
>
>
>
>
>
> library(rgl)
> plot(1:10, col=7)
> open3d()

glX
  1


From: R-SIG-Mac  on behalf of Richard M. 
Heiberger 
Sent: Saturday, February 20, 2021 10:45 AM
To: Duncan Murdoch; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] [External] Re: more rgl problems

I am running it now on 4.0.4RC.

The cran page
https://cran.r-project.org
offers download of 4.0.3 for mac, even though 4.0.4 is available on windows.


From: Duncan Murdoch 
Sent: Saturday, February 20, 2021 9:41 AM
To: Richard M. Heiberger; r-sig-mac@r-project.org
Subject: Re: [External] Re: more rgl problems

If you are set up to install from source, could you try this?

   devtools::install_github("dmurdoch/rgl@quartzbug", type="source")

If you only have some of the requirements (e.g. no devel versions of
packages) you might find you only get a partial build with no X11
display; that won't really test the workaround.  In that case I'll try
to build a binary for your R version.

Duncan Murdoch

On 18/02/2021 6:07 p.m., Richard M. Heiberger wrote:
> This is from my MacBook Air mid-2012 running Catalina 10.15.7
> with Xquartz 2.7.11
> I never placed the beta on this machine.
> I also see from a fresh R session
>
> plot(1:10, col=7)
> library(rgl)
> open3d()
>
> is fine, whereas this:
>
> library(rgl)
> plot(1:10, col=7)
> open3d()
> segfaults
>
> 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)
>
> 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(rgl)
> plot(1:10, col=7)
> open3d()
> library(rgl)
>> plot(1:10, col=7)
>> open3d()
>
> error: xp_attach_gl_context returned: 2
>
>   *** caught segfault ***
> address 0x18, cause 'memory not mapped'
>
> Traceback:
>   1: rgl.open(useNULL)
>   2: open3d()
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> Selection: 2
> Warning message:
> In rgl.open(useNULL) : RGL: ERROR: can't bind glx context to window
>
> Process R finished at Thu Feb 18 17:57:37 2021
>
>
> 
> From: Duncan Murdoch 
> Sent: Thursday, February 18, 2021 3:20 PM
> To: Richard M. Heiberger; r-sig-mac@r-project.org
> Subject: [External] Re: more rgl problems
>
> I've made some progress on this, but I don't know how to fix it properly.
>
> What's happening is that rgl is trying to open the new window that
> open3d() asks for.  It gets most of the way through that operation, then
> calls glXMakeCurrent, which associates the OpenGL context with that
> window.  That call fails, but without generating any of the documented
> errors:  it just fails, triggering an X11 error handler with error code
> 0 (which typically means no error).
>
> In the released versions of rgl, that failure leads to a segfault,
> because I wasn't doing enough error checking.  I've fixed the segfault,
> but I'm still getting the error (in fact I'm getting it a lot more than
> I used to; not sure if it's my debugging code causing that), and after I
> get the error r

Re: [R-SIG-Mac] [External] Re: more rgl problems

2021-02-20 Thread Richard M. Heiberger

I am running it now on 4.0.4RC.

The cran page
https://cran.r-project.org
offers download of 4.0.3 for mac, even though 4.0.4 is available on windows.


From: Duncan Murdoch 
Sent: Saturday, February 20, 2021 9:41 AM
To: Richard M. Heiberger; r-sig-mac@r-project.org
Subject: Re: [External] Re: more rgl problems

If you are set up to install from source, could you try this?

   devtools::install_github("dmurdoch/rgl@quartzbug", type="source")

If you only have some of the requirements (e.g. no devel versions of
packages) you might find you only get a partial build with no X11
display; that won't really test the workaround.  In that case I'll try
to build a binary for your R version.

Duncan Murdoch

On 18/02/2021 6:07 p.m., Richard M. Heiberger wrote:
> This is from my MacBook Air mid-2012 running Catalina 10.15.7
> with Xquartz 2.7.11
> I never placed the beta on this machine.
> I also see from a fresh R session
>
> plot(1:10, col=7)
> library(rgl)
> open3d()
>
> is fine, whereas this:
>
> library(rgl)
> plot(1:10, col=7)
> open3d()
> segfaults
>
> 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)
>
> 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(rgl)
> plot(1:10, col=7)
> open3d()
> library(rgl)
>> plot(1:10, col=7)
>> open3d()
>
> error: xp_attach_gl_context returned: 2
>
>   *** caught segfault ***
> address 0x18, cause 'memory not mapped'
>
> Traceback:
>   1: rgl.open(useNULL)
>   2: open3d()
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> Selection: 2
> Warning message:
> In rgl.open(useNULL) : RGL: ERROR: can't bind glx context to window
>
> Process R finished at Thu Feb 18 17:57:37 2021
>
>
> 
> From: Duncan Murdoch 
> Sent: Thursday, February 18, 2021 3:20 PM
> To: Richard M. Heiberger; r-sig-mac@r-project.org
> Subject: [External] Re: more rgl problems
>
> I've made some progress on this, but I don't know how to fix it properly.
>
> What's happening is that rgl is trying to open the new window that
> open3d() asks for.  It gets most of the way through that operation, then
> calls glXMakeCurrent, which associates the OpenGL context with that
> window.  That call fails, but without generating any of the documented
> errors:  it just fails, triggering an X11 error handler with error code
> 0 (which typically means no error).
>
> In the released versions of rgl, that failure leads to a segfault,
> because I wasn't doing enough error checking.  I've fixed the segfault,
> but I'm still getting the error (in fact I'm getting it a lot more than
> I used to; not sure if it's my debugging code causing that), and after I
> get the error reported on screen, the new rgl window opens but doesn't
> work to display anything.
>
> I think it's probably something wrong in the rgl initialization code;
> running this:
>
> plot(1:10, col=7)
> library(rgl)
> open3d()
>
> is fine, whereas this:
>
> library(rgl)
> plot(1:10, col=7)
> open3d()
>
> is always failing for me.  Or possibly this is an Xquartz bug, maybe a
> leftover from when I installed the beta.
>
> I'd guess what's happening is that calling quartz() invalidates part of
> the initialization done by rgl.init(), but I don't know what part yet.
> I do want to call rgl.init() when loading rgl, because it might fail,
> and then I can drop back to the off-screen drawing.  It's too late to do
> that later.
>
> A workaround that works for me is for the .onload() function in rgl to
> execute
>
>dev.new()
>dev.off()
>
> before calling rgl.init(). It is less irritating than you might guess,
> because the window doesn't have time to appear before being destroyed,
> but I still don't like it.   I'll try it out a bit, and then push it to
> Github for other

Re: [R-SIG-Mac] [External] Re: more rgl problems

2021-02-18 Thread Richard M. Heiberger

This is from my MacBook Air mid-2012 running Catalina 10.15.7
with Xquartz 2.7.11
I never placed the beta on this machine.
I also see from a fresh R session

   plot(1:10, col=7)
   library(rgl)
   open3d()

is fine, whereas this:

   library(rgl)
   plot(1:10, col=7)
   open3d()
segfaults

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)

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(rgl)
   plot(1:10, col=7)
   open3d()
   library(rgl)
>plot(1:10, col=7)
>open3d()

error: xp_attach_gl_context returned: 2

 *** caught segfault ***
address 0x18, cause 'memory not mapped'

Traceback:
 1: rgl.open(useNULL)
 2: open3d()

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Warning message:
In rgl.open(useNULL) : RGL: ERROR: can't bind glx context to window

Process R finished at Thu Feb 18 17:57:37 2021

From: Duncan Murdoch 
Sent: Thursday, February 18, 2021 3:20 PM
To: Richard M. Heiberger; r-sig-mac@r-project.org
Subject: [External] Re: more rgl problems

I've made some progress on this, but I don't know how to fix it properly.

What's happening is that rgl is trying to open the new window that
open3d() asks for.  It gets most of the way through that operation, then
calls glXMakeCurrent, which associates the OpenGL context with that
window.  That call fails, but without generating any of the documented
errors:  it just fails, triggering an X11 error handler with error code
0 (which typically means no error).

In the released versions of rgl, that failure leads to a segfault,
because I wasn't doing enough error checking.  I've fixed the segfault,
but I'm still getting the error (in fact I'm getting it a lot more than
I used to; not sure if it's my debugging code causing that), and after I
get the error reported on screen, the new rgl window opens but doesn't
work to display anything.

I think it's probably something wrong in the rgl initialization code;
running this:

   plot(1:10, col=7)
   library(rgl)
   open3d()

is fine, whereas this:

   library(rgl)
   plot(1:10, col=7)
   open3d()

is always failing for me.  Or possibly this is an Xquartz bug, maybe a
leftover from when I installed the beta.

I'd guess what's happening is that calling quartz() invalidates part of
the initialization done by rgl.init(), but I don't know what part yet.
I do want to call rgl.init() when loading rgl, because it might fail,
and then I can drop back to the off-screen drawing.  It's too late to do
that later.

A workaround that works for me is for the .onload() function in rgl to
execute

  dev.new()
  dev.off()

before calling rgl.init(). It is less irritating than you might guess,
because the window doesn't have time to appear before being destroyed,
but I still don't like it.   I'll try it out a bit, and then push it to
Github for others to test.

Duncan Murdoch

On 18/02/2021 6:28 a.m., Duncan Murdoch wrote:
> I can reproduce this on a Catalina machine, working in R from the terminal.
>
> This definitely looks similar to the problem that
> rgl::setGraphicsDelay() was designed to solve, but even adding a 10
> second delay doesn't help.  I get a slightly different message than you:
>
>   > open3d()
> error: xp_attach_gl_context returned: 2
>
>*** caught segfault ***
> address 0x18, cause 'memory not mapped'
>
> but that might just be a different way of reporting the same underlying
> issue.
>
> It's clearly some kind of interaction between the Quartz device and rgl.
>I'll see if I can track it down.
>
> Duncan Murdoch
>
> On 17/02/2021 7:36 p.m., Richard M. Heiberger wrote:
>> This is repeatable when the lines are all pasted in at once.
>> The example works if I allow some time delay between lines.
>>
>> This is might be a relative of the one from a few months ago.
>> But this message is about invalid permissions.
>> =
>>
>> 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.
&

[R-SIG-Mac] more rgl problems

2021-02-17 Thread Richard M. Heiberger

This is repeatable when the lines are all pasted in at once.
The example works if I allow some time delay between lines.

This is might be a relative of the one from a few months ago.
But this message is about invalid permissions.
=

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.

> setwd('/Users/rmh/Rwd/')
> library(rgl)
> x <- matrix(1:3, 1,3)
> plot(1:10, col=7)
> open3d()
error: xp_attach_gl_context returned: 2

 *** caught segfault ***
address 0x18, cause 'invalid permissions'

Traceback:
 1: rgl.open(useNULL)
 2: open3d()

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 



MacBookAir with the M1 chip using the regular intel version of R from CRAN.
Big Sur 11.2.1.
The plot(1:10), col=7) ## went by default to the quartz() device.


I repeated this about 5 times in ESS, and then once in Terminal.

Let me know if you need more information.


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

Thank you.  dragging the org.xquartz.startx.* to Trash and reinstalling 2.7.11 
restored my system to sanity.


From: Duncan Murdoch 
Sent: Saturday, February 13, 2021 8:42 PM
To: Richard M. Heiberger; R-SIG-Mac
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: 
[External] Please test R 4.0.4 RC

This worked for me to apparently fix my system:

Start with a newly rebooted system.

Uninstall XQuartz by dragging it to the trash.

Look in /Library/LaunchAgents/ for filenames related to xquartz.  I had
two:  a five year old one called org.macosforge.xquartz.startx.plist,
and one from around the time I installed the XQuartz beta named
org.xquartz.startx.plist.  I deleted the latter.

Look in /Library/LaunchDaemons/ for similar files.  I deleted one with
the same name, i.e. org.xquartz.startx.plist, and left an older one.

Reboot the system again, and install XQuartz 2.7.11.  Relogin, and
things seem fine.

Duncan Murdoch



On 13/02/2021 7:22 p.m., Richard M. Heiberger wrote:
> It is looking for:
>   missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
>
> This is the entirety of
>/Library/Developer/CommandLineTools/usr/share/
>
>/Library/Developer/CommandLineTools/usr/share/man:
>total used in directory 40 available 1.3 TiB
>drwxr-xr-x  3 root  wheel 96 Feb 11 12:34 .
>drwxr-xr-x  3 root  wheel 96 Feb 11 12:34 ..
>-rw-r--r--  1 root  wheel  20198 Jan 27 16:11 whatis
>
> So I will again try
> sudo xcode-select --install
>
> It took a few minutes, and now from a new R session
>> X11()
> Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize,  :
>unable to start device X11
> In addition: Warning message:
> In X11() : unable to open connection to X11 display ''
>> Sys.getenv("DISPLAY")
> [1] "/private/tmp/com.apple.launchd.l0xAmiv83n/org.xquartz:0"
>> Sys.setenv(DISPLAY=":0.0")
>> Sys.getenv("DISPLAY")
> [1] ":0.0"
>> X11()
> Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize,  :
>unable to start device X11
> In addition: Warning message:
> In X11() : unable to open connection to X11 display ''
>>
>
>
>
> the xcrun is still not on the machine, and specifically not in 
> /Library/Developer/CommandLineTools/
> 
> From: Dr Eberhard W Lisse 
> Sent: Saturday, February 13, 2021 6:50 PM
> To: Duncan Murdoch; R-SIG-Mac; Richard M. Heiberger
> Cc: e...@lisse.na
> Subject: Re: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: 
> [External] Please test R 4.0.4 RC
>
> Remove the directory where xcrun says it is supposed to live and re-install 
> the command line tools?
>
> el
>
> —
> Sent from Dr Lisse’s iPhone
> On 14 Feb 2021, 01:41 +0200, Richard M. Heiberger , wrote:
> I reported on installing xcode tools in my email
> Sat 2/13/2021 3:59 PM
> It didn't help.
>
> I did all this R_4.0.4 RC testing after updating to Big Sur 11.2.1.
>
> 
> From: Dr Eberhard W Lisse 
> Sent: Saturday, February 13, 2021 4:44 PM
> To: Duncan Murdoch; R-SIG-Mac; Richard M. Heiberger
> Cc: e...@lisse.na
> Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: [External] 
> Please test R 4.0.4 RC
>
> the Xcode Command line tools are missing. Install them and see what happens.
>
> Did you recently upgrade MacOS?
>
> el
>
> —
> Sent from Dr Lisse’s iPhone
> On 13 Feb 2021, 23:21 +0200, Richard M. Heiberger , wrote:
> That is next. Again a fresh session.
>
>
> setwd('/Users/rmh/Rwd/')
> Sys.setenv(DISPLAY=":0.0")
> X11()
> 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() : unable to open connection to X11 display ''
>
>
>
> and the R session is still alive.
>
>
> This rasies for me a different question. Why should I want X11()?
>
> When X11 was working it was very slow, and didn't allow paging back through
> previous images.
>
> In favor of X11, I think it uses the display space better. X11() has better 
> size and spacing for xlab, ylab, and main than quartz(). But that isn't a 
> strong enough
> reason to use it while develkoping a graph. When I want it to look

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

It is looking for:
 missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

This is the entirety of
  /Library/Developer/CommandLineTools/usr/share/

  /Library/Developer/CommandLineTools/usr/share/man:
  total used in directory 40 available 1.3 TiB
  drwxr-xr-x  3 root  wheel 96 Feb 11 12:34 .
  drwxr-xr-x  3 root  wheel 96 Feb 11 12:34 ..
  -rw-r--r--  1 root  wheel  20198 Jan 27 16:11 whatis

So I will again try
sudo xcode-select --install

It took a few minutes, and now from a new R session
> X11()
Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize,  : 
  unable to start device X11
In addition: Warning message:
In X11() : unable to open connection to X11 display ''
> Sys.getenv("DISPLAY")
[1] "/private/tmp/com.apple.launchd.l0xAmiv83n/org.xquartz:0"
> Sys.setenv(DISPLAY=":0.0")
> Sys.getenv("DISPLAY")
[1] ":0.0"
> X11()
Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize,  : 
  unable to start device X11
In addition: Warning message:
In X11() : unable to open connection to X11 display ''
> 

the xcrun is still not on the machine, and specifically not in 
/Library/Developer/CommandLineTools/

From: Dr Eberhard W Lisse 
Sent: Saturday, February 13, 2021 6:50 PM
To: Duncan Murdoch; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: 
[External] Please test R 4.0.4 RC

Remove the directory where xcrun says it is supposed to live and re-install the 
command line tools?

el

—
Sent from Dr Lisse’s iPhone
On 14 Feb 2021, 01:41 +0200, Richard M. Heiberger , wrote:
I reported on installing xcode tools in my email
Sat 2/13/2021 3:59 PM
It didn't help.

I did all this R_4.0.4 RC testing after updating to Big Sur 11.2.1.

From: Dr Eberhard W Lisse 
Sent: Saturday, February 13, 2021 4:44 PM
To: Duncan Murdoch; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: [External] 
Please test R 4.0.4 RC

the Xcode Command line tools are missing. Install them and see what happens.

Did you recently upgrade MacOS?

el

—
Sent from Dr Lisse’s iPhone
On 13 Feb 2021, 23:21 +0200, Richard M. Heiberger , wrote:
That is next. Again a fresh session.

setwd('/Users/rmh/Rwd/')
Sys.setenv(DISPLAY=":0.0")
X11()
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() : unable to open connection to X11 display ''

and the R session is still alive.

This rasies for me a different question. Why should I want X11()?

When X11 was working it was very slow, and didn't allow paging back through
previous images.

In favor of X11, I think it uses the display space better. X11() has better 
size and spacing for xlab, ylab, and main than quartz(). But that isn't a 
strong enough
reason to use it while develkoping a graph. When I want it to look good,
I go directly to pdf() and get the spacing that I think looks better.

____________
From: Duncan Murdoch 
Sent: Saturday, February 13, 2021 4:05 PM
To: Richard M. Heiberger; R-SIG-Mac
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Please test R 
4.0.4 RC

Have you tried the change to DISPLAY, i.e.

Sys.setenv(DISPLAY=":0.0")

before running X11()?

Duncan Murdoch

On 13/02/2021 3:50 p.m., 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 d

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

I reported on installing xcode tools in my email
 Sat 2/13/2021 3:59 PM
It didn't help.

I did all this R_4.0.4 RC testing after updating to Big Sur 11.2.1.

From: Dr Eberhard W Lisse 
Sent: Saturday, February 13, 2021 4:44 PM
To: Duncan Murdoch; R-SIG-Mac; Richard M. Heiberger
Cc: e...@lisse.na
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Re: [External] 
Please test R 4.0.4 RC

the Xcode Command line tools are missing. Install them and see what happens.

Did you recently upgrade MacOS?

el

—
Sent from Dr Lisse’s iPhone
On 13 Feb 2021, 23:21 +0200, Richard M. Heiberger , wrote:
That is next. Again a fresh session.

setwd('/Users/rmh/Rwd/')
Sys.setenv(DISPLAY=":0.0")
X11()
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() : unable to open connection to X11 display ''

and the R session is still alive.

This rasies for me a different question. Why should I want X11()?

When X11 was working it was very slow, and didn't allow paging back through
previous images.

In favor of X11, I think it uses the display space better. X11() has better 
size and spacing for xlab, ylab, and main than quartz(). But that isn't a 
strong enough
reason to use it while develkoping a graph. When I want it to look good,
I go directly to pdf() and get the spacing that I think looks better.

From: Duncan Murdoch 
Sent: Saturday, February 13, 2021 4:05 PM
To: Richard M. Heiberger; R-SIG-Mac
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Please test R 
4.0.4 RC

Have you tried the change to DISPLAY, i.e.

Sys.setenv(DISPLAY=":0.0")

before running X11()?

Duncan Murdoch

On 13/02/2021 3:50 p.m., 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

___
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

Well, my original report didn't give full information because R locked up too 
early.

>From here I am following instructions and reporting back:

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.

> setwd('/Users/rmh/Rwd/')
> system("Applications/Xquartz")
sh: Applications/Xquartz: No such file or directory
Warning message:
In system("Applications/Xquartz") : error in running command
> system("/Applications/Xquartz")
sh: /Applications/Xquartz: No such file or directory
Warning message:
In system("/Applications/Xquartz") : error in running command
> system("/Applications/Utilities/Xquartz")
sh: /Applications/Utilities/Xquartz: No such file or directory
Warning message:
In system("/Applications/Utilities/Xquartz") : error in running command
> system("/Applications/Utilities/Xquartz.app")
sh: /Applications/Utilities/Xquartz.app: is a directory
> system("/Applications/Utilities/Xquartz.app/Contents/MacOS/X11")
> X11()
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() : unable to open connection to X11 display ''
> system("/Applications/Utilities/Xquartz.app/Contents/MacOS/X11")
> ## from the Cmd-Tab I opened Xquartz, and from its Applications I opened 
> xterm, and then ran an ls in xterm. it works.
> X11()
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() : unable to open connection to X11 display ''
> Sys.getenv("DISPLAY")
[1] "/private/tmp/com.apple.launchd.l0xAmiv83n/org.xquartz:0"
> unlink(Sys.getenv("DISPLAY"))
>Sys.setenv(DISPLAY=":0.0")
> X11()
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() : unable to open connection to X11 display ''
>

From: Simon Urbanek 
Sent: Saturday, February 13, 2021 5:35 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

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:

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

another new session


> setwd('/Users/rmh/Rwd/')
> Sys.getenv("DISPLAY")
[1] "/private/tmp/com.apple.launchd.l0xAmiv83n/org.xquartz:0"
> unlink(Sys.getenv("DISPLAY"))
>Sys.setenv(DISPLAY=":0.0")
> X11()
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() : unable to open connection to X11 display ''
> Sys.getenv("DISPLAY")
[1] ":0.0"
>


I didn't make any more changes to the Xquartz.  I previously had the beta and 
replaced it with 2.7.11, so I just continued from there.

________
From: Duncan Murdoch 
Sent: Saturday, February 13, 2021 4:55 PM
To: Richard M. Heiberger; R-SIG-Mac
Subject: Re: [External] Re: [R-SIG-Mac] [External] Re: [External] Please test R 
4.0.4 RC

Thanks for your detailed descriptions!  I can now reproduce this, and I
have an ugly workaround.  I should be able to get a better workaround soon.

To reproduce:

Install the beta.  (I did this when it was pushed to me.)  It worked
fine for me.

Install the previous version, 2.7.11.  Reboot the system.

Now running x11() in R causes the spinning beach ball.

The workaround:

Start R.  The DISPLAY environment variable will show the name something like

[1] "/private/tmp/com.apple.launchd.RuLLnvteCn/org.xquartz:0"

This is a socket, not a regular file.

Delete this, and set DISPLAY to ":0.0":

   unlink(Sys.getenv("DISPLAY"))
   Sys.setenv(DISPLAY=":0.0")

Now x11() is fine.

This is only a workaround.  The unlink() is permanent, but setting the
environment variable only lasts for the length of the R session.  You'll
need to enter Sys.setenv(DISPLAY=":0.0") again in future sessions, and I
would guess the socket will be recreated the next time you restart the
system (or maybe on login).

Duncan Murdoch








On 13/02/2021 4:21 p.m., Richard M. Heiberger wrote:
> That is next.  Again a fresh session.
>
>
>> setwd('/Users/rmh/Rwd/')
>> Sys.setenv(DISPLAY=":0.0")
>> X11()
> 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() : unable to open connection to X11 display ''
>>
>
>
> and the R session is still alive.
>
>
> This rasies for me a different question.  Why should I want X11()?
>
> When X11 was working it was very slow, and didn't allow paging back through
> previous images.
>
> In favor of X11, I think it uses the display space better.  X11() has better 
> size and spacing for xlab, ylab, and main than quartz().  But that isn't a 
> strong enough
> reason to use it while develkoping a graph.  When I want it to look good,
> I go directly to pdf() and get the spacing that I  think looks better.
>
> 
> From: Duncan Murdoch 
> Sent: Saturday, February 13, 2021 4:05 PM
> To: Richard M. Heiberger; R-SIG-Mac
> Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Please test R 
> 4.0.4 RC
>
> Have you tried the change to DISPLAY, i.e.
>
> Sys.setenv(DISPLAY=":0.0")
>
> before running X11()?
>
> Duncan Murdoch
>
> On 13/02/2021 3:50 p.m., 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] [Ex

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

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

That is next.  Again a fresh session.


> setwd('/Users/rmh/Rwd/')
> Sys.setenv(DISPLAY=":0.0")
> X11()
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() : unable to open connection to X11 display ''
>


and the R session is still alive.


This rasies for me a different question.  Why should I want X11()?

When X11 was working it was very slow, and didn't allow paging back through
previous images.

In favor of X11, I think it uses the display space better.  X11() has better 
size and spacing for xlab, ylab, and main than quartz().  But that isn't a 
strong enough
reason to use it while develkoping a graph.  When I want it to look good,
I go directly to pdf() and get the spacing that I  think looks better.


From: Duncan Murdoch 
Sent: Saturday, February 13, 2021 4:05 PM
To: Richard M. Heiberger; R-SIG-Mac
Subject: [External] Re: [R-SIG-Mac] [External] Re: [External] Please test R 
4.0.4 RC

Have you tried the change to DISPLAY, i.e.

Sys.setenv(DISPLAY=":0.0")

before running X11()?

Duncan Murdoch

On 13/02/2021 3:50 p.m., 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
>

___
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

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] Please test R 4.0.4 RC

2021-02-12 Thread Richard M. Heiberger

Thank you for 4.0.4 RC.
I am running on Mac M1 using the intel R_4.0.4RC

The inappropriate quartz() behavior I reported on "[R-SIG-Mac] Behaviour or 
Quartz windows"
on Tuesday, February 9, 2021 11:56 AM has been repaired.

The entire set of lattice panels are printed on screen.  CMD-left and CMD-right 
now
correctly shift to previous and next pages.


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

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

2021-02-12 Thread Richard M. Heiberger

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

Re: [R-SIG-Mac] [External] Re: [External] Behaviour or Quartz windows

2021-02-09 Thread Richard M. Heiberger

Your are correct.  I have been using quartz() on the released intel build of 
R_4.0.3 on the
Mac Silicon.  The misbehavior I reported is about quartz(). R graphics defaults 
to quartz()
when no device is specified.

I was unaware that XQuartz and quartz are unrelated.   quartz is faster and 
allows pagination.  XQuartz is very slow, you can watch it draw each panel, and 
each bar in a bar graph.
XQuartz does not have pagination.

From: Prof Brian Ripley 
Sent: Tuesday, February 9, 2021 1:26 PM
To: Richard M. Heiberger; Peter West; r-sig-mac@r-project.org
Subject: [External] Re: [R-SIG-Mac] [External] Behaviour or Quartz windows

The quartz() device has nothing to so with XQuartz.  Quartz is part of
macOS: https://en.wikipedia.org/wiki/Quartz_(graphics_layer)

Using XQuartz betas is not supported: it is very unfortunate that they
are persuading users to install a beta version.

You have not followed the posting guide and posted the sessionInfo().
We are left to guess that you are using an Intel build of R under
emulation, but homebrew does have (a rather broken) arm64 build of R
4.0.3: we do not support arm64 builds on R < 4.1.0.  My understanding is
that in the CRAN release of R 4.0.3 only the X11() device and parts of
Tk interact with XQuartz, although other parts may in other builds.

On 09/02/2021 17:33, Richard M. Heiberger wrote:
> Is R on M1 really talking to the REAL XQuartz?  After I opened XQuartz from 
> the spotlignt, it acknowledged the xterm window, but not the R graphics 
> window.  When I closed the XQuartz
> app, the R graphics window was still open and functioning.  dev.cur() says 
> "quartz".
>
> just checked on my older intel mac.  same behavior.  the Xquartz.app menu 
> doesn't list
> the R graphics window, and the R graphics shows "...", not "XQuartz" in the 
> menu bar.
>
> ________
> From: R-SIG-Mac  on behalf of Richard M. 
> Heiberger 
> Sent: Tuesday, February 9, 2021 11:56 AM
> To: Peter West; r-sig-mac@r-project.org
> Subject: Re: [R-SIG-Mac] [External]  Behaviour or Quartz windows
>
> When I draw a 9x7 panel lattice it displays 12 panels, then sits there until 
> I resize the window. then the rest appears.  When I display another 9x7, it 
> too sits at 12 panels.
> When I Cmd-left for the previous display, the current one vanishes entirely.
> When I send the command again, after it sits I resize the window.  Now the 
> full second display
> is visible.  When I Cmd-left followed by Cmd-right, the second display is 
> lost.
>
> I am using R version 4.0.3 (2020-10-10) on Silicon Mac Big Sur 11.1 from 
> inside ESS.
>
> XQuartz doesn't report correctly.  On the MenuBar it doesn't say "XQuartz".  
> Instead it shows a
> small Apple Icon which has no information when clicked.  When I search using 
> the MenuBar Spotlight icon, it tells me Xquartz 2.8.0_beta1 and offers to 
> update to beta3.  Clicking on XQuartz.app in the Spotlight menu gives proper 
> XQuartz information in the upper left corner
> of the MenuBar.
>
> Rich
>
> Get Outlook for iOS<https://aka.ms/o0ukef>
> 
> From: R-SIG-Mac  on behalf of Peter West 
> 
> Sent: Tuesday, February 9, 2021 10:35:59 AM
> To: r-sig-mac@r-project.org 
> Subject: [External] [R-SIG-Mac] Behaviour or Quartz windows
>
> Hi,
>
> I�ll just confirm the odd behaviour of the Quartz window in Big Sur 11.2 R 
> 4.0.3 GUI 1.73 on M1 silicon. I have installed the beta3 version of Quartz. 
> In my case I have to CMD <- twice, then go forward to get the next to last 
> plot.
>
> Are these Quartz windows constructed using native MacOS graphics or XQuartz?
>
> Peter
>
> �
> Peter West
> peter.b.w...@ehealth.id.au
> �that they might touch even the fringe of his garment. And as many as touched 
> it were made well.
>
> ___
> 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
>

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
___
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] Behaviour or Quartz windows

2021-02-09 Thread Richard M. Heiberger

Is R on M1 really talking to the REAL XQuartz?  After I opened XQuartz from the 
spotlignt, it acknowledged the xterm window, but not the R graphics window.  
When I closed the XQuartz
app, the R graphics window was still open and functioning.  dev.cur() says 
"quartz".

just checked on my older intel mac.  same behavior.  the Xquartz.app menu 
doesn't list
the R graphics window, and the R graphics shows "...", not "XQuartz" in the 
menu bar.


From: R-SIG-Mac  on behalf of Richard M. 
Heiberger 
Sent: Tuesday, February 9, 2021 11:56 AM
To: Peter West; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] [External]  Behaviour or Quartz windows

When I draw a 9x7 panel lattice it displays 12 panels, then sits there until I 
resize the window. then the rest appears.  When I display another 9x7, it too 
sits at 12 panels.
When I Cmd-left for the previous display, the current one vanishes entirely.
When I send the command again, after it sits I resize the window.  Now the full 
second display
is visible.  When I Cmd-left followed by Cmd-right, the second display is lost.

I am using R version 4.0.3 (2020-10-10) on Silicon Mac Big Sur 11.1 from inside 
ESS.

XQuartz doesn't report correctly.  On the MenuBar it doesn't say "XQuartz".  
Instead it shows a
small Apple Icon which has no information when clicked.  When I search using 
the MenuBar Spotlight icon, it tells me Xquartz 2.8.0_beta1 and offers to 
update to beta3.  Clicking on XQuartz.app in the Spotlight menu gives proper 
XQuartz information in the upper left corner
of the MenuBar.

Rich

Get Outlook for iOS<https://aka.ms/o0ukef>

From: R-SIG-Mac  on behalf of Peter West 

Sent: Tuesday, February 9, 2021 10:35:59 AM
To: r-sig-mac@r-project.org 
Subject: [External] [R-SIG-Mac] Behaviour or Quartz windows

Hi,

I�ll just confirm the odd behaviour of the Quartz window in Big Sur 11.2 R 
4.0.3 GUI 1.73 on M1 silicon. I have installed the beta3 version of Quartz. In 
my case I have to CMD <- twice, then go forward to get the next to last plot.

Are these Quartz windows constructed using native MacOS graphics or XQuartz?

Peter

�
Peter West
peter.b.w...@ehealth.id.au
�that they might touch even the fringe of his garment. And as many as touched 
it were made well.

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

[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] [External] Behaviour or Quartz windows

2021-02-09 Thread Richard M. Heiberger

When I draw a 9x7 panel lattice it displays 12 panels, then sits there until I 
resize the window. then the rest appears.  When I display another 9x7, it too 
sits at 12 panels.
When I Cmd-left for the previous display, the current one vanishes entirely.
When I send the command again, after it sits I resize the window.  Now the full 
second display
is visible.  When I Cmd-left followed by Cmd-right, the second display is lost.

I am using R version 4.0.3 (2020-10-10) on Silicon Mac Big Sur 11.1 from inside 
ESS.

XQuartz doesn't report correctly.  On the MenuBar it doesn't say "XQuartz".  
Instead it shows a
small Apple Icon which has no information when clicked.  When I search using 
the MenuBar Spotlight icon, it tells me Xquartz 2.8.0_beta1 and offers to 
update to beta3.  Clicking on XQuartz.app in the Spotlight menu gives proper 
XQuartz information in the upper left corner
of the MenuBar.

Rich

Get Outlook for iOS

From: R-SIG-Mac  on behalf of Peter West 

Sent: Tuesday, February 9, 2021 10:35:59 AM
To: r-sig-mac@r-project.org 
Subject: [External] [R-SIG-Mac] Behaviour or Quartz windows

Hi,

I�ll just confirm the odd behaviour of the Quartz window in Big Sur 11.2 R 
4.0.3 GUI 1.73 on M1 silicon. I have installed the beta3 version of Quartz. In 
my case I have to CMD <- twice, then go forward to get the next to last plot.

Are these Quartz windows constructed using native MacOS graphics or XQuartz?

Peter

�
Peter West
peter.b.w...@ehealth.id.au
�that they might touch even the fringe of his garment. And as many as touched 
it were made well.

___
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] Fw: Question about stripchart

2021-02-02 Thread Richard M. Heiberger

months<-c("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec")

monames.factor <- factor(monamescon$monames, levels=months)
stripchart(conc~monames.factor, data=monamescon, vert=TRUE)

read the help file
?factor

and see that the levels factor must contain unique values.

Please always keep the list as a recipient when you respond.
This question belongs on r-h...@r-project.org
because it is not Macintosh specific.
Any followup should be sent to r-h...@r-project.org


____
From: Parkhurst, David F. 
Sent: Tuesday, February 2, 2021 4:29 PM
To: Richard M. Heiberger
Subject: Re: Question about stripchart

Hmm.  I’m guessing that this might work with my stripchart problem:

Define 
months<-c("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec")

Then use mofac<-factor(months, months)

Then set up a vector of 73 elements like

mos<-c(mofac[4],mofac[4],…,mofac[12])

Then my call to stripchart would be (conc~mos, …)

Is that what I need to do?


From: Richard M. Heiberger 
Date: Monday, February 1, 2021 at 9:10 PM
To: Parkhurst, David F. 
Subject: Re: Question about stripchart
month.factor <- factor(month.name, month.name)


> month.name
 [1] "January"   "February"  "March" "April" "May"   "June"
 [7] "July"  "August""September" "October"   "November"  "December"
> class(month.name)
[1] "character"
> month.factor <- factor(month.name, month.name)
> levels(factor(month.name))
 [1] "April" "August""December"  "February"  "January"   "July"
 [7] "June"  "March" "May"   "November"  "October"   "September"
> levels(factor(month.factor))
 [1] "January"   "February"  "March" "April" "May"   "June"
 [7] "July"  "August""September" "October"   "November"  "December"
>


From: R-SIG-Mac  on behalf of Parkhurst, David 
F. 
Sent: Monday, February 1, 2021 8:53 PM
To: r-sig-mac@r-project.org
Subject: [R-SIG-Mac] Question about stripchart

I have E. coli data (variable �conc�) for 73 dates over months from Apr through 
Dec (variable �monames�).  The data are in order from the April through 
December, and are in a data.frame titled "monamescon�.  When I run 
stripchart(conc~monames, data=monamescon, vert=TRUE), the months come out in 
alphabetical order along the x axis.  How can I get them to come out in time 
order instead?


[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Question about stripchart

2021-02-01 Thread Richard M. Heiberger

month.factor <- factor(month.name, month.name)


> month.name
 [1] "January"   "February"  "March" "April" "May"   "June"
 [7] "July"  "August""September" "October"   "November"  "December"
> class(month.name)
[1] "character"
> month.factor <- factor(month.name, month.name)
> levels(factor(month.name))
 [1] "April" "August""December"  "February"  "January"   "July"
 [7] "June"  "March" "May"   "November"  "October"   "September"
> levels(factor(month.factor))
 [1] "January"   "February"  "March" "April" "May"   "June"
 [7] "July"  "August""September" "October"   "November"  "December"


From: R-SIG-Mac  on behalf of Parkhurst, David 
F. 
Sent: Monday, February 1, 2021 8:53 PM
To: r-sig-mac@r-project.org
Subject: [R-SIG-Mac] Question about stripchart

I have E. coli data (variable �conc�) for 73 dates over months from Apr through 
Dec (variable �monames�).  The data are in order from the April through 
December, and are in a data.frame titled "monamescon�.  When I run 
stripchart(conc~monames, data=monamescon, vert=TRUE), the months come out in 
alphabetical order along the x axis.  How can I get them to come out in time 
order instead?


[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] [External] summary() suddently producing weird NULL: values for factors and character attributes

2020-12-13 Thread Richard M. Heiberger

please send to the list the output from both:

dput(head(P2))

utils::sessionInfo()

This is the Macintosh list.  Is this specifically a Macintosh problem?



On Sun, Dec 13, 2020 at 6:32 PM John Helly via R-SIG-Mac <
r-sig-mac@r-project.org> wrote:

> Aloha.
>
> For the past few weeks, maybe 6 or more, I've been getting strange results
> from the summary() function for data.frames.  Has anyone else noticed
> something like this?  I don't think I've done anything to cause this but
> cannot find anything to attribute it to.  Example below.  It lists every
> row as a value in the data frame attribute DAUCO.  Similar behavior found
> with other read.table results using syntax below.
>
>
> PRISM=
> read.table(PRISM_INPUT,header=TRUE,stringsAsFactors=TRUE,sep=',',
>
> colClasses=c('character','numeric','numeric','numeric','numeric','numeric'))
>
> P2 is a subset of PRISM.
>
>
>
> J.
>
> --
>
> 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
>
> ___
> 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] Catalina Crashes R

2020-06-01 Thread Richard M. Heiberger

My reproducible issue looked resolved (as I posted) when I upgraded to
10.15.5.

Today I found another issue, but not repeatable so I haven't
posted it yet. this is the headline:

> car::scatter3d(RRS ~ CCS + JCS,
+data=RespJ$variables,
+surface=FALSE, residuals=TRUE, bg="white",
+axis.scales=TRUE, grid=TRUE, ellipsoid=FALSE,
+  point.col="black")
Loading required namespace: mgcv
error: xp_attach_gl_context returned: 2

 *** caught segfault ***
address 0x18, cause 'memory not mapped'

Traceback:
 1: rgl.open(useNULL)
 2: open3d()
 3: .check3d()
 4: rgl::next3d()
 5: scatter3d.default(X[, 2], X[, 1], X[, 3], xlab = xlab, ylab = ylab,
zlab = zlab, radius = radius, id = id, ...)
 6: scatter3d(X[, 2], X[, 1], X[, 3], xlab = xlab, ylab = ylab, zlab =
zlab, radius = radius, id = id, ...)
 7: scatter3d.formula(RRS ~ CCS + JCS, data = RespJ$variables, surface =
FALSE, residuals = TRUE, bg = "white", axis.scales = TRUE, grid = TRUE,
ellipsoid = FALSE, point.col = "black")
 8: car::scatter3d(RRS ~ CCS + JCS, data = RespJ$variables, surface =
FALSE, residuals = TRUE, bg = "white", axis.scales = TRUE, grid = TRUE,
ellipsoid = FALSE, point.col = "black")

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 4
Warning message:
In rgl.open(useNULL) : RGL: ERROR: can't bind glx context to window

Process R exited abnormally with code 71 at Mon Jun  1 13:53:39 2020



On Mon, Jun 1, 2020 at 20:02 Joseph Vanterpool 
wrote:

> Hello,
>
> Yesterday, I started using the John Hopkins course that includes R
> training. I currently have a Mac with Catalina (Version 10.15.4).
>
> For simple examples, they have you install and load KernSmooth to view the
> copyright date. The first time I tried this, the installation was fine, but
> loading didn’t work. I tried a second time and it worked.
>
> I noticed on the forum that other people had similar problems, though were
> further along in their use of R. Have these problems been resolved?
>
> Thanks,
>
> Joseph
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

[[alternative HTML version deleted]]

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

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

I attempted to update xquartz when I updated to Catalina, and the same
number is still the current version number.

Here is a related issue, attached tmp2.txt is the R transcript.
The interesting thing here is that rgl.quit() prevents rgl from being
reattached.

Is there an rgl equivalent for dev.cur()?

On Fri, May 29, 2020 at 1:51 PM Duncan Murdoch  wrote:
>
> On 29/05/2020 12:35 p.m., Richard M. Heiberger wrote:
> > I have the same Xquartz as you.
>
> I'd guess it should be updated.  Generally XQuartz needs updates with
> every MacOS release, and your 10.15.4 is two releases further along than
> my 10.13.6.
>
> > I have rgl-0.100.50 from CRAN
>
> You could update that, but I doubt if it would make any difference.
>
> > Apple is macOS Catalina, Version 10.15.4
> > Do you need hardware information?
> > MacBpok Air (13 -inch, Mid 2012)
> > Processor 2GHz Dual-Core Intel Core i7
> > Memory 8 GB 1600 MHz DDR3
> > Graphics Intel HD Graphics 4000 1536 MB
>
> I think the XQuartz issue is most likely to help, but if it doesn't, I'm
> not sure what I could suggest:  I don't have Catalina.
>
> Duncan Murdoch
> >
> >
> > from the Terminal App:
> > The Apple Crash Report is in the attached tmp.txt
> > I didn't send it to Apple.
> >
> > R version 4.0.0 (2020-04-24) -- "Arbor Day"
> >
> > Copyright (C) 2020 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.
> >
> >
> >> library(rgl)
> >
> >> plot(1:10)
> >
> >> 2020-05-29 12:30:00.536 R[24961:3275889] *** Assertion failure in BOOL 
> >> NSScreenConfigurationInvalidateIfNeededForReason(_NSScreenConfigurationUpdateReason)(),
> >>  
> >> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.40.150/AppKit.subproj/NSScreenConfiguration.m:473
> >
> > 2020-05-29 12:30:00.543 R[24961:3275889] *** Terminating app due to
> > uncaught exception 'NSInternalInconsistencyException', reason:
> > 'NSScreen reconfig must only happen on the main thread.'
> >
> > *** First throw call stack:
> >
> > (
> >
> > 0   CoreFoundation  0x7fff371698d7
> > __exceptionPreprocess + 250
> >
> > 1   libobjc.A.dylib 0x7fff6ff47a9e
> > objc_exception_throw + 48
> >
> > 2   CoreFoundation  0x7fff37192bb0
> > +[NSException raise:format:arguments:] + 88
> >
> > 3   Foundation  0x7fff398de456
> > -[NSAssertionHandler
> > handleFailureInFunction:file:lineNumber:description:] + 166
> >
> > 4   AppKit  0x7fff34503083
> > +[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] +
> > 361
> >
> > 5   AppKit  0x7fff34e4bda8
> > _NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243
> >
> > 6   AppKit  0x7fff34502c85
> > -[NSApplication(ScreenHandling) _reactToDockChanged] + 144
> >
> > 7   AppKit  0x7fff345024dc
> > _NSCGSDockMessageReceive + 268
> >
> > 8   HIToolbox   0x7fff35d34a3c
> > _ZL12DockCallbackjjPvS_ + 1987
> >
> > 9   HIServices  0x7fff3539c8ec
> > dockClientNotificationProc + 217
> >
> > 10  SkyLight0x7fff6626f174
> > _ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1_ +
> > 1002
> >
> > 11  SkyLight0x7fff6626de71
> > CGSSnarfAndDispatchDatagrams + 1671
> >
> > 12  SkyLight0x7fff6649d5a5
> > SLSGetNextEventRecordInternal + 83
> >
> > 13  SkyLight0x7fff6

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

this prevents the crash

> rgl.quit()
> plot(1:10)
>

On Fri, May 29, 2020 at 12:35 PM Richard M. Heiberger  wrote:
>
> I have the same Xquartz as you.
> I have rgl-0.100.50 from CRAN
> Apple is macOS Catalina, Version 10.15.4
> Do you need hardware information?
> MacBpok Air (13 -inch, Mid 2012)
> Processor 2GHz Dual-Core Intel Core i7
> Memory 8 GB 1600 MHz DDR3
> Graphics Intel HD Graphics 4000 1536 MB
>
>
> from the Terminal App:
> The Apple Crash Report is in the attached tmp.txt
> I didn't send it to Apple.
>
> R version 4.0.0 (2020-04-24) -- "Arbor Day"
>
> Copyright (C) 2020 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.
>
>
> > library(rgl)
>
> > plot(1:10)
>
> > 2020-05-29 12:30:00.536 R[24961:3275889] *** Assertion failure in BOOL 
> > NSScreenConfigurationInvalidateIfNeededForReason(_NSScreenConfigurationUpdateReason)(),
> >  
> > /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.40.150/AppKit.subproj/NSScreenConfiguration.m:473
>
> 2020-05-29 12:30:00.543 R[24961:3275889] *** Terminating app due to
> uncaught exception 'NSInternalInconsistencyException', reason:
> 'NSScreen reconfig must only happen on the main thread.'
>
> *** First throw call stack:
>
> (
>
> 0   CoreFoundation  0x7fff371698d7
> __exceptionPreprocess + 250
>
> 1   libobjc.A.dylib 0x7fff6ff47a9e
> objc_exception_throw + 48
>
> 2   CoreFoundation  0x7fff37192bb0
> +[NSException raise:format:arguments:] + 88
>
> 3   Foundation  0x7fff398de456
> -[NSAssertionHandler
> handleFailureInFunction:file:lineNumber:description:] + 166
>
> 4   AppKit  0x7fff34503083
> +[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] +
> 361
>
> 5   AppKit  0x7fff34e4bda8
> _NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243
>
> 6   AppKit  0x7fff34502c85
> -[NSApplication(ScreenHandling) _reactToDockChanged] + 144
>
> 7   AppKit  0x7fff345024dc
> _NSCGSDockMessageReceive + 268
>
> 8   HIToolbox   0x7fff35d34a3c
> _ZL12DockCallbackjjPvS_ + 1987
>
> 9   HIServices  0x7fff3539c8ec
> dockClientNotificationProc + 217
>
> 10  SkyLight0x7fff6626f174
> _ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1_ +
> 1002
>
> 11  SkyLight0x7fff6626de71
> CGSSnarfAndDispatchDatagrams + 1671
>
> 12  SkyLight0x7fff6649d5a5
> SLSGetNextEventRecordInternal + 83
>
> 13  SkyLight0x7fff6633bfbe
> SLEventCreateNextEvent + 136
>
> 14  libXplugin.1.dylib  0x00010686df0c
> ___xp_init_service_cg_event_port_block_invoke + 104
>
> 15  libdispatch.dylib   0x7fff7108d658
> _dispatch_client_callout + 8
>
> 16  libdispatch.dylib   0x7fff7108f818
> _dispatch_continuation_pop + 414
>
> 17  libdispatch.dylib   0x7fff7109f4be
> _dispatch_source_invoke + 2084
>
> 18  libdispatch.dylib   0x7fff71092af6
> _dispatch_lane_serial_drain + 263
>
> 19  libdispatch.dylib   0x7fff710935d6
> _dispatch_lane_invoke + 363
>
> 20  libdispatch.dylib   0x7fff7109cc09
> _dispatch_workloop_worker_thread + 596
>
> 21  libsystem_pthread.dylib 0x7fff712eba3d
> _pthread_wqthread + 290
>
> 22  libsystem_pthread.dylib 0x7fff712eab77 start_wqthread + 15
>
> )
>
> libc++abi.dylib: terminating with uncaught exception of type NSException
>
> zsh: abort  R
>
> rmh@rmhs-Air ~ %
>
>
> On Fri, May 29, 2020 at 12:16 PM Duncan Murdoch
>  wrote:
> >
> > I'm not seeing that with R-patched r

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

I have the same Xquartz as you.
I have rgl-0.100.50 from CRAN
Apple is macOS Catalina, Version 10.15.4
Do you need hardware information?
MacBpok Air (13 -inch, Mid 2012)
Processor 2GHz Dual-Core Intel Core i7
Memory 8 GB 1600 MHz DDR3
Graphics Intel HD Graphics 4000 1536 MB


from the Terminal App:
The Apple Crash Report is in the attached tmp.txt
I didn't send it to Apple.

R version 4.0.0 (2020-04-24) -- "Arbor Day"

Copyright (C) 2020 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.


> library(rgl)

> plot(1:10)

> 2020-05-29 12:30:00.536 R[24961:3275889] *** Assertion failure in BOOL 
> NSScreenConfigurationInvalidateIfNeededForReason(_NSScreenConfigurationUpdateReason)(),
>  
> /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.40.150/AppKit.subproj/NSScreenConfiguration.m:473

2020-05-29 12:30:00.543 R[24961:3275889] *** Terminating app due to
uncaught exception 'NSInternalInconsistencyException', reason:
'NSScreen reconfig must only happen on the main thread.'

*** First throw call stack:

(

0   CoreFoundation  0x7fff371698d7
__exceptionPreprocess + 250

1   libobjc.A.dylib 0x7fff6ff47a9e
objc_exception_throw + 48

2   CoreFoundation  0x7fff37192bb0
+[NSException raise:format:arguments:] + 88

3   Foundation  0x7fff398de456
-[NSAssertionHandler
handleFailureInFunction:file:lineNumber:description:] + 166

4   AppKit  0x7fff34503083
+[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] +
361

5   AppKit  0x7fff34e4bda8
_NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243

6   AppKit  0x7fff34502c85
-[NSApplication(ScreenHandling) _reactToDockChanged] + 144

7   AppKit  0x7fff345024dc
_NSCGSDockMessageReceive + 268

8   HIToolbox   0x7fff35d34a3c
_ZL12DockCallbackjjPvS_ + 1987

9   HIServices  0x7fff3539c8ec
dockClientNotificationProc + 217

10  SkyLight0x7fff6626f174
_ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1_ +
1002

11  SkyLight0x7fff6626de71
CGSSnarfAndDispatchDatagrams + 1671

12  SkyLight0x7fff6649d5a5
SLSGetNextEventRecordInternal + 83

13  SkyLight0x7fff6633bfbe
SLEventCreateNextEvent + 136

14  libXplugin.1.dylib  0x00010686df0c
___xp_init_service_cg_event_port_block_invoke + 104

15  libdispatch.dylib   0x7fff7108d658
_dispatch_client_callout + 8

16  libdispatch.dylib   0x7fff7108f818
_dispatch_continuation_pop + 414

17  libdispatch.dylib   0x7fff7109f4be
_dispatch_source_invoke + 2084

18  libdispatch.dylib   0x7fff71092af6
_dispatch_lane_serial_drain + 263

19  libdispatch.dylib   0x7fff710935d6
_dispatch_lane_invoke + 363

20  libdispatch.dylib   0x7fff7109cc09
_dispatch_workloop_worker_thread + 596

21  libsystem_pthread.dylib 0x7fff712eba3d
_pthread_wqthread + 290

22  libsystem_pthread.dylib 0x7fff712eab77 start_wqthread + 15

)

libc++abi.dylib: terminating with uncaught exception of type NSException

zsh: abort  R

rmh@rmhs-Air ~ %


On Fri, May 29, 2020 at 12:16 PM Duncan Murdoch
 wrote:
>
> I'm not seeing that with R-patched r78557, run from the console.  I'm
> not sure I have the same MacOS version as you (R prints the same thing,
> Apple says High Sierra 10.13.6).  I tried with the CRAN binary of rgl
> 0.100.54.  I'd guess the version of XQuartz may be important:  I'm not
> seeing rgl in the call stack, but libXplugin is there.  Mine is "XQuartz
> 2.7.11 (xorg-server 1.18.4)".
>
> Duncan Murdoch
>
>
>
> On 29/05/2020 11:44 a.m., Richard M. Heiberger wrote:
> > R version 4.0.0 (2020-04-24) -- "Arbor Day"
> > Copyright (C) 2020 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

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

R version 4.0.0 (2020-04-24) -- "Arbor Day"
Copyright (C) 2020 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.

> if(identical(getOption('pager'), file.path(R.home('bin'), 'pager'))) 
> options(pager='cat') # rather take the ESS one
> options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient', 
> show.error.locations=TRUE)
> version
   _
platform   x86_64-apple-darwin17.0
arch   x86_64
os darwin17.0
system x86_64, darwin17.0
status
major  4
minor  0.0
year   2020
month  04
day24
svn rev78286
language   R
version.string R version 4.0.0 (2020-04-24)
nickname   Arbor Day
>
> library(rgl)
> plot(1:10)
>

Process R abort trap: 6 at Fri May 29 11:32:59 2020
2020-05-29 11:32:59.542 R[24448:3255600] *** Assertion failure in BOOL
NSScreenConfigurationInvalidateIfNeededForReason(_NSScreenConfigurationUpdateReason)(),
/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1894.40.150/AppKit.subproj/NSScreenConfiguration.m:473
2020-05-29 11:32:59.560 R[24448:3255600] *** Terminating app due to
uncaught exception 'NSInternalInconsistencyException', reason:
'NSScreen reconfig must only happen on the main thread.'
*** First throw call stack:
(
0   CoreFoundation  0x7fff371698d7
__exceptionPreprocess + 250
1   libobjc.A.dylib 0x7fff6ff47a9e
objc_exception_throw + 48
2   CoreFoundation  0x7fff37192bb0
+[NSException raise:format:arguments:] + 88
3   Foundation  0x7fff398de456
-[NSAssertionHandler
handleFailureInFunction:file:lineNumber:description:] + 166
4   AppKit  0x7fff34503083
+[_NSScreenConfiguration invalidateConfigurationIfNeededForReason:] +
361
5   AppKit  0x7fff34e4bda8
_NSApplicationInvalidateScreenConfigurationMaybeIfNeeded + 243
6   AppKit  0x7fff34502c85
-[NSApplication(ScreenHandling) _reactToDockChanged] + 144
7   AppKit  0x7fff345024dc
_NSCGSDockMessageReceive + 268
8   HIToolbox   0x7fff35d34a3c
_ZL12DockCallbackjjPvS_ + 1987
9   HIServices  0x7fff3539c8ec
dockClientNotificationProc + 217
10  SkyLight0x7fff6626f174
_ZN12_GLOBAL__N_123notify_datagram_handlerEj15CGSDatagramTypePvmS1_ +
1002
11  SkyLight0x7fff6626de71
CGSSnarfAndDispatchDatagrams + 1671
12  SkyLight0x7fff6649d5a5
SLSGetNextEventRecordInternal + 83
13  SkyLight0x7fff6633bfbe
SLEventCreateNextEvent + 136
14  libXplugin.1.dylib  0x00010ffa5f0c
___xp_init_service_cg_event_port_block_invoke + 104
15  libdispatch.dylib   0x7fff7108d658
_dispatch_client_callout + 8
16  libdispatch.dylib   0x7fff7108f818
_dispatch_continuation_pop + 414
17  libdispatch.dylib   0x7fff7109f4be
_dispatch_source_invoke + 2084
18  libdispatch.dylib   0x7fff71092af6
_dispatch_lane_serial_drain + 263
19  libdispatch.dylib   0x7fff710935d6
_dispatch_lane_invoke + 363
20  libdispatch.dylib   0x7fff7109cc09
_dispatch_workloop_worker_thread + 596
21  libsystem_pthread.dylib 0x7fff712eba3d
_pthread_wqthread + 290
22  libsystem_pthread.dylib 0x7fff712eab77 start_wqthread + 15
)
libc++abi.dylib: terminating with uncaught exception of type NSException

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

Re: [R-SIG-Mac] java version, perhaps related to ggplot2

2018-05-25 Thread Richard M. Heiberger

Simon,
thank you for the information about javareconf.
Would it be possible to build that into the installation of RJava?

David,
Thank you for verifying the behavior.


I decided to stay with Java 8, because the Java updater thought that
171 was the next step and I did that yesterday.

I attempted to install rJava_0.9-10
from http://www.rforge.net/rJava/files/
It didn't complete, telling me to run
R CMD javareconf as root.

javareconf ran successfully.

The next time I tried to install rJava_0.9-10
it got farther, recognizing the jdk1.8.0_60.jdk that I have.
It still didn't continue because I don't have JDK.

I will now try building microplot with ggplot2_2.2.1.9000
Success! microplot now builds.

Now to the intended task which is to R CMD check microplot with the
ggplot2_2.2.1.9000

it passes
R CMD check microplot_1.0-39.tar.gz

R CMD check --run-dontrun microplot_1.0-39.tar.gz
this also passes

One more step, the demo/ subdirectory
Almost clear.  One error which I will investigate tomorrow.

The error is due to a change in behavior in ggplot2.
Specifically, the last statement in demo/latex-ggplot.r no longer works
due to a change inside ggplot.  Previously it was reporting NULL, now
it is reporting character(0).

I will file an issue with https://github.com/tidyverse/ggplot2/issues asking
whether the change was accidental or whether I need to change my code
to allow for the new value.

Rich

On Thu, May 24, 2018 at 1:47 PM, Simon Urbanek
<simon.urba...@r-project.org> wrote:
> You need to configure R to match your Java using R CMD javareconf.
>
> The CRAN machine uses JDK 1.9 which was the default until Java 10 was 
> released recently. If you use something else, you have to configure R 
> accordingly.
>
> Also I strongly recommend using rJava 0.9-10 since it works around some issue 
> with Java on macOS and with Java 10.
>
> Cheers,
> Simon
>
>
>
>
>
>> On May 23, 2018, at 7:50 PM, David Winsemius <dwinsem...@comcast.net> wrote:
>>
>>
>>
>>> On May 22, 2018, at 1:36 AM, Richard M. Heiberger <r...@temple.edu> wrote:
>>>
>>> sI have Macintosh High Sierra 10.13.4
>>> and R_3.5.0
>>>
>>> I am attempting to R CMD build and check my package microplot against
>>> the imminent ggplot2_2.2.1.9000
>>>
>>
>> I have a new High Sierra Machine with a System that was ported over from an 
>> earlier version of the OS. I've installed R 3.5.0.  I tried installing micro 
>> plot from binary without error, but when I try to load the rJava library I 
>> was getting an error with the old Java version 151, so I accepted the Oracle 
>> offer of installing version 171 downloaded from the Java website, but I'm 
>> also seeing:
>>
>> library(rJava)
>> Error: package or namespace load failed for ‘rJava’:
>> .onLoad failed in loadNamespace() for 'rJava', details:
>>  call: dyn.load(file, DLLpath = DLLpath, ...)
>>  error: unable to load shared object 
>> '/Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so':
>>  
>> dlopen(/Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so,
>>  6): Library not loaded: 
>> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/lib/server/libjvm.dylib
>>  Referenced from: 
>> /Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so
>>  Reason: image not found
>>
>>
>> There is a folder  /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk, but 
>> nothing named with a jdk-9 prefix
>>
>>
>> S
>> Best;
>>
>> David.
>>
>>> The build fails with messages
>>>
>>> ** byte-compile and prepare package for lazy loading
>>> Error : .onLoad failed in loadNamespace() for 'rJava', details:
>>> call: dyn.load(file, DLLpath = DLLpath, ...)
>>> error: unable to load shared object
>>> '/Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so':
>>> dlopen(/Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so,
>>> 6): Library not loaded:
>>> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/lib/server/libjvm.dylib
>>> Referenced from:
>>> /Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so
>>> Reason: image not found
>>> ERROR: lazy loading failed for package ‘microplot’
>>>
>>> Indeed I do not have Java 9, I have Java 8, which the Java updater
>>> says is current (171).
>>> The java site
>>> http://www.oracle.com/technetwork/java/javase/overview/index.html
>>> seems to want to give me Ja

[R-SIG-Mac] java version, perhaps related to ggplot2

2018-05-21 Thread Richard M. Heiberger

sI have Macintosh High Sierra 10.13.4
and R_3.5.0

I am attempting to R CMD build and check my package microplot against
the imminent ggplot2_2.2.1.9000

The build fails with messages

** byte-compile and prepare package for lazy loading
Error : .onLoad failed in loadNamespace() for 'rJava', details:
  call: dyn.load(file, DLLpath = DLLpath, ...)
  error: unable to load shared object
'/Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so':
  
dlopen(/Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so,
6): Library not loaded:
/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/lib/server/libjvm.dylib
  Referenced from:
/Library/Frameworks/R.framework/Versions/3.5/Resources/library/rJava/libs/rJava.so
  Reason: image not found
ERROR: lazy loading failed for package ‘microplot’

Indeed I do not have Java 9, I have Java 8, which the Java updater
says is current (171).
The java site
http://www.oracle.com/technetwork/java/javase/overview/index.html
seems to want to give me Java 10 (not Java 9), and the discussion on
this R-sig-mac list
[R-SIG-Mac] R and Java 10 ➜ rJava not able to build
beginning March 29 seems to say 8 is still correct.  As suggested
there I looked at R-admin for 3.5.0
and discover "The situation with Java support on macOS is messy".
I attempted the suggested workaround
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home
and got the same message as above.

I need guidance as to the next steps I should take.

Rich

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

[R-SIG-Mac] png error message problem, and potential crash

2017-06-22 Thread Richard M. Heiberger

bash-3.2$ R --vanilla

R version 3.4.0 Patched (2017-04-28 r72639) -- "You Stupid Darkness"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.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.

> png("abcd.png", height=.22, width=2)
Jun 22 12:13:08  R[59491] : CGContextTranslateCTM: invalid
context 0x0. If you want to see the backtrace, please set
CG_CONTEXT_SHOW_BACKTRACE environmental variable.
Jun 22 12:13:08  R[59491] : CGContextScaleCTM: invalid context
0x0. If you want to see the backtrace, please set
CG_CONTEXT_SHOW_BACKTRACE environmental variable.
> png("abcd.png", height=.22, width=2, units="in", res=300)
> dev.cur()
quartz_off_screen
3
> dev.off()
quartz_off_screen
2
> dev.off()
null device
  1
> version
   _
platform   x86_64-apple-darwin15.6.0
arch   x86_64
os darwin15.6.0
system x86_64, darwin15.6.0
status Patched
major  3
minor  4.0
year   2017
month  04
day28
svn rev72639
language   R
version.string R version 3.4.0 Patched (2017-04-28 r72639)
nickname   You Stupid Darkness
> q()
bash-3.2$

Deep inside a function with png() inside a loop,
after about 70 of the CGContextTranslateCTM messages,
I got the crash message
Jun 22 11:40:48  R[59174] : CGBitmapContextCreateImage: invalid
context 0x0. If you want to see the backtrace, please set
CG_CONTEXT_SHOW_BACKTRACE environmental variable.

Process R trace/BPT trap: 5 at Thu Jun 22 11:40:48 2017


For comparison, on Windows
R version 3.4.0 Patched (2017-04-28 r72638) -- "You Stupid Darkness"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

I get an appropriate error message

> png("abcd.png", height=.22, width=2)
Warning message:
In png("abcd.png", height = 0.22, width = 2) :
  'width=2, height=0' are unlikely values in pixels
>

For completeness, the repair, shown above, is to use the units and res
arguments.

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

[R-SIG-Mac] graphics problem from Macintosh system software

2015-12-17 Thread Richard M. Heiberger

This has been reported before.  I am still seeing it with R-3.2.3.
It appears randomly.  It sounds scary.

Rich

>
Dec 17 15:14:01 rmhs-MacBook-Air.local R[3534] :
CGContextSetFont: invalid context 0x7fb698259080. This is a serious
error. This application, or a library it uses, is using an invalid
context  and is thereby contributing to an overall degradation of
system stability and reliability. This notice is a courtesy: please
fix this problem. It will become a fatal error in an upcoming update.
Dec 17 15:14:01 rmhs-MacBook-Air.local R[3534] :
CGContextSetFontSize: invalid context 0x7fb698259080. This is a
serious error. This application, or a library it uses, is using an
invalid context  and is thereby contributing to an overall degradation
of system stability and reliability. This notice is a courtesy: please
fix this problem. It will become a fatal error in an upcoming update.
Dec 17 15:14:01 rmhs-MacBook-Air.local R[3534] :
CGContextGetFont: invalid context 0x7fb698259080. This is a serious
error. This application, or a library it uses, is using an invalid
context  and is thereby contributing to an overall degradation of
system stability and reliability. This notice is a courtesy: please
fix this problem. It will become a fatal error in an upcoming update.
p

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

Re: [R-SIG-Mac] graphics problem from Macintosh system software

2015-12-17 Thread Richard M. Heiberger

No idea at all.  It happens randomly.  I have noticed it since June
2012 when I first started using the Macintosh.  This is the first time
I saw it with R-3.2.3 so I decided to
report it again.

My guess is that it is deep in the Macintosh device driver software.

Rich

On Thu, Dec 17, 2015 at 4:23 PM, Erich Neuwirth
<erich.neuwi...@univie.ac.at> wrote:
> Do you have any idea under what circumstances this happens.
>
>
>> On Dec 17, 2015, at 21:44, Richard M. Heiberger <r...@temple.edu> wrote:
>>
>> This has been reported before.  I am still seeing it with R-3.2.3.
>> It appears randomly.  It sounds scary.
>>
>> Rich
>>
>>>
>> Dec 17 15:14:01 rmhs-MacBook-Air.local R[3534] :
>> CGContextSetFont: invalid context 0x7fb698259080. This is a serious
>> error. This application, or a library it uses, is using an invalid
>> context  and is thereby contributing to an overall degradation of
>> system stability and reliability. This notice is a courtesy: please
>> fix this problem. It will become a fatal error in an upcoming update.
>> Dec 17 15:14:01 rmhs-MacBook-Air.local R[3534] :
>> CGContextSetFontSize: invalid context 0x7fb698259080. This is a
>> serious error. This application, or a library it uses, is using an
>> invalid context  and is thereby contributing to an overall degradation
>> of system stability and reliability. This notice is a courtesy: please
>> fix this problem. It will become a fatal error in an upcoming update.
>> Dec 17 15:14:01 rmhs-MacBook-Air.local R[3534] :
>> CGContextGetFont: invalid context 0x7fb698259080. This is a serious
>> error. This application, or a library it uses, is using an invalid
>> context  and is thereby contributing to an overall degradation of
>> system stability and reliability. This notice is a courtesy: please
>> fix this problem. It will become a fatal error in an upcoming update.
>> p
>>
>> ___
>> 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] Yosemite and R

2014-10-27 Thread Richard M. Heiberger

I just did a workshop for new R users.  the only serious installation problem I
saw was Macintosh users and tctlk.  From this discussion, I knew to tell both
people they needed to download quartz.macosforge.org
and indeed that solved it.

Is there a place on the package DESCRIPTION file to state that dependency,
thus triggering the download and installation of quartz?  That would
take the responsibility for discovering this need away from the end user?

Rich


On Thu, Oct 23, 2014 at 2:15 PM, John Fox j...@mcmaster.ca wrote:
 Dear Simon,

 I installed Yosemite a couple of days ago and everything seems to work fine 
 so far, including the tcltk demo that caused problems for Peter, and the 
 Rcmdr package, which gives Tcl/Tk a pretty good workout. I first reinstalled 
 XQuartz, as suggested, and I also reinstalled R and updated all packages, 
 though the latter two steps probably weren't necessary. I figured that it 
 would help to hear positive experiences as well as problems.

 The only issue that I've encountered so far is specific to checking packages 
 under RStudio, which doesn't appear to find pdflatex; OTOH, R CMD check runs 
 fine in a terminal window. I haven't yet tried to resolve this problem.

 Best,
  John

 -Original Message-
 From: Simon Urbanek [mailto:simon.urba...@r-project.org]
 Sent: Tuesday, October 21, 2014 4:38 PM
 To: John Fox
 Cc: Amos B. Elberg; r-sig-mac; Spencer Mass; Ben Clark; peter dalgaard;
 Marc Schwartz; David Winsemius; Hadley Wickham
 Subject: Re: [R-SIG-Mac] Yosemite and R

 I wasn't able to reproduce but I suspect those are all red herrings -
 there are really no subprocesses involved at all in either case.

 On Oct 21, 2014, at 4:19 PM, John Fox j...@mcmaster.ca wrote:
 
  Dear all,
 
  I wonder whether this issue also accounts for the tcltk problems that
 have been reported. (I haven't yet upgraded to Yosemite myself, hoping
 to wait for the wrinkles to be ironed out, though I'll likely do so
 shortly if only to see what happens.)
 
  Best,
  John
 
  -Original Message-
  From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r-
  project.org] On Behalf Of Amos B. Elberg
  Sent: Tuesday, October 21, 2014 12:40 PM
  To: David Winsemius; Hadley Wickham
  Cc: r-sig-mac; Spencer Mass
  Subject: Re: [R-SIG-Mac] Yosemite and R
 
  If the full environment isn’t getting passed to R-spawned sub-
  processes, that might explain an error I’ve been having since the
  update:  when R is launched from the command line, calls that should
  create an X11 window in the background fail unless an X11 window has
  already been created with the width and height specified:
 
  plot(rnorm(100))
  Error in .External2(C_X11, d$display, d$width, d$height,
  d$pointsize,  :
   invalid 'width' or 'height'
  X11()
  Error in .External2(C_X11, d$display, d$width, d$height,
  d$pointsize,  :
   invalid 'width' or 'height'
  X11(width = 5, height = 5)
  plot(rnorm(100))
  [now it  works - and any number of additional windows can be spawned
  without repeating the error]
  [quitting R and reopening, without quitting XQuartz, and I get the
 same
  error calling plot() before X11(width = , height = )
 
  This does not happen in RStudio.  I don’t use the R.app gui; I
 opened
  it just now to test and I got a slew of path-related errors, but
  they’re as likely to have to do with my not-maintained R.app as with
  anything else.
 
  I had not reported this already because I wasn’t confident whether
 its
  a yosemite issue, an R-patched issue, or just something odd in the
 way
  I built R.
 
  If incomplete-environment-passing is the new normal, is this not
 going
  to be a common issue for packages that spawn sub-processes?
 
 
  From: Hadley Wickham h.wick...@gmail.com
  Reply: Hadley Wickham h.wick...@gmail.com
  Date: October 21, 2014 at 10:12:13 AM
  To: David Winsemius dwinsem...@comcast.net
  Cc: r-sig-mac r-sig-mac@r-project.org, Spencer Mass
  ma...@newpaltz.edu
  Subject:  Re: [R-SIG-Mac] Yosemite and R
 
  No, it is not. It is expected that the path in the terminal be
  different to the path in R, it is _not_ expected that the path in R
  be
  different to the path in a subprocess started by R.
 
  (Well it is now expected, because this appears to be a new security
  feature in Yosemite)
 
  The best thread I could find on the problem is here:
  https://code.google.com/p/mactlmgr/issues/detail?id=102
 
  --
  http://had.co.nz/
 
  ___
  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] Yosemite and R

2014-10-27 Thread Richard M. Heiberger

thank you for catching that typo

Rich

On Tue, Oct 28, 2014 at 12:21 AM, John Maindonald
john.maindon...@anu.edu.au wrote:
 http://xquartz.macosforge.org/ ?

 John Maindonald email: john.maindon...@anu.edu.au
 phone : +61 2 (6125)3473fax  : +61 2(6125)5549
 Centre for Mathematics  Its Applications, Room 1194,
 John Dedman Mathematical Sciences Building (Building 27)
 Australian National University, Canberra ACT 0200.


 On 28 Oct 2014, at 15:03, Richard M. Heiberger r...@temple.edu wrote:

 I just did a workshop for new R users.  the only serious installation 
 problem I
 saw was Macintosh users and tctlk.  From this discussion, I knew to tell both
 people they needed to download quartz.macosforge.org
 and indeed that solved it.

 Is there a place on the package DESCRIPTION file to state that dependency,
 thus triggering the download and installation of quartz?  That would
 take the responsibility for discovering this need away from the end user?

 Rich


 On Thu, Oct 23, 2014 at 2:15 PM, John Fox j...@mcmaster.ca wrote:
 Dear Simon,

 I installed Yosemite a couple of days ago and everything seems to work fine 
 so far, including the tcltk demo that caused problems for Peter, and the 
 Rcmdr package, which gives Tcl/Tk a pretty good workout. I first 
 reinstalled XQuartz, as suggested, and I also reinstalled R and updated all 
 packages, though the latter two steps probably weren't necessary. I figured 
 that it would help to hear positive experiences as well as problems.

 The only issue that I've encountered so far is specific to checking 
 packages under RStudio, which doesn't appear to find pdflatex; OTOH, R CMD 
 check runs fine in a terminal window. I haven't yet tried to resolve this 
 problem.

 Best,
 John

 -Original Message-
 From: Simon Urbanek [mailto:simon.urba...@r-project.org]
 Sent: Tuesday, October 21, 2014 4:38 PM
 To: John Fox
 Cc: Amos B. Elberg; r-sig-mac; Spencer Mass; Ben Clark; peter dalgaard;
 Marc Schwartz; David Winsemius; Hadley Wickham
 Subject: Re: [R-SIG-Mac] Yosemite and R

 I wasn't able to reproduce but I suspect those are all red herrings -
 there are really no subprocesses involved at all in either case.

 On Oct 21, 2014, at 4:19 PM, John Fox j...@mcmaster.ca wrote:

 Dear all,

 I wonder whether this issue also accounts for the tcltk problems that
 have been reported. (I haven't yet upgraded to Yosemite myself, hoping
 to wait for the wrinkles to be ironed out, though I'll likely do so
 shortly if only to see what happens.)

 Best,
 John

 -Original Message-
 From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r-
 project.org] On Behalf Of Amos B. Elberg
 Sent: Tuesday, October 21, 2014 12:40 PM
 To: David Winsemius; Hadley Wickham
 Cc: r-sig-mac; Spencer Mass
 Subject: Re: [R-SIG-Mac] Yosemite and R

 If the full environment isn’t getting passed to R-spawned sub-
 processes, that might explain an error I’ve been having since the
 update:  when R is launched from the command line, calls that should
 create an X11 window in the background fail unless an X11 window has
 already been created with the width and height specified:

 plot(rnorm(100))
 Error in .External2(C_X11, d$display, d$width, d$height,
 d$pointsize,  :
 invalid 'width' or 'height'
 X11()
 Error in .External2(C_X11, d$display, d$width, d$height,
 d$pointsize,  :
 invalid 'width' or 'height'
 X11(width = 5, height = 5)
 plot(rnorm(100))
 [now it  works - and any number of additional windows can be spawned
 without repeating the error]
 [quitting R and reopening, without quitting XQuartz, and I get the
 same
 error calling plot() before X11(width = , height = )

 This does not happen in RStudio.  I don’t use the R.app gui; I
 opened
 it just now to test and I got a slew of path-related errors, but
 they’re as likely to have to do with my not-maintained R.app as with
 anything else.

 I had not reported this already because I wasn’t confident whether
 its
 a yosemite issue, an R-patched issue, or just something odd in the
 way
 I built R.

 If incomplete-environment-passing is the new normal, is this not
 going
 to be a common issue for packages that spawn sub-processes?


 From: Hadley Wickham h.wick...@gmail.com
 Reply: Hadley Wickham h.wick...@gmail.com
 Date: October 21, 2014 at 10:12:13 AM
 To: David Winsemius dwinsem...@comcast.net
 Cc: r-sig-mac r-sig-mac@r-project.org, Spencer Mass
 ma...@newpaltz.edu
 Subject:  Re: [R-SIG-Mac] Yosemite and R

 No, it is not. It is expected that the path in the terminal be
 different to the path in R, it is _not_ expected that the path in R
 be
 different to the path in a subprocess started by R.

 (Well it is now expected, because this appears to be a new security
 feature in Yosemite)

 The best thread I could find on the problem is here:
 https://code.google.com/p/mactlmgr/issues/detail?id=102

 --
 http://had.co.nz/

 ___
 R-SIG-Mac mailing list
 R-SIG-Mac@r-project.org

[R-SIG-Mac] context message

2014-09-19 Thread Richard M. Heiberger

Sep 19 16:37:16 rmhs-air.home R[15381] Error:
CGContextDelegateCreateForContext: invalid context 0x7fe3bb796370.
This is a serious error. This application, or a library it uses, is
using an invalid context  and is thereby contributing to an overall
degradation of system stability and reliability. This notice is a
courtesy: please fix this problem. It will become a fatal error in an
upcoming update.

I get this message occasionally, but not systematically enough to
give a recipe for generating it.

I believe it is an OS message related to graphing on the Quartz device.

bash-3.2$ ps
  PID TTY   TIME CMD
15381 ttys000   21:13.77 /Library/Frameworks/R.framework/Resources/bin/exec/R --
14282 ttys0010:00.06 /bin/bash --noediting -i

 sessionInfo()
R version 3.1.1 Patched (2014-07-16 r66175)
Platform: x86_64-apple-darwin13.1.0 (64-bit)

locale:
[1] C

attached base packages:
[1] splines   grid  stats graphics  grDevices
[6] utils datasets  methods   base

other attached packages:
 [1] reshape2_1.4abind_1.4-0
 [3] vcd_1.3-1   HH2writing_0.0-2
 [5] car_2.0-20  HH_3.1-6
 [7] multcomp_1.3-4  TH.data_1.0-3
 [9] survival_2.37-7 mvtnorm_1.0-0
[11] latticeExtra_0.6-26 RColorBrewer_1.0-5
[13] lattice_0.20-29

loaded via a namespace (and not attached):
 [1] MASS_7.3-33  Rcmdr_2.1-0  Rcpp_0.11.2
 [4] colorspace_1.2-4 compiler_3.1.1   digest_0.6.4
 [7] leaps_2.9memoise_0.2.1nnet_7.3-8
[10] plyr_1.8.1   sandwich_2.3-0   stringr_0.6.2
[13] tcltk_3.1.1  tcltk2_1.2-10tools_3.1.1
[16] zoo_1.7-11



Rich

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

Re: [R-SIG-Mac] bypassing the R.app help browser?

2014-08-13 Thread Richard M. Heiberger

John,

I have noticed what I think is a related issue.  I normally run R
under emacs with ESS.
help files open an emacs buffer.  When I run Rcmdr on the Mac, then
Rcmdr changes the help
file location to something on the Mac.  It restores the emacs buffer
destination when I close Rcmdr.
Is there, or can there be, an option to leave the help files in emacs?

Thanks

Rich


On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote:
 Dear Brian and Peter,

 Thanks for picking up this issue.

 The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk
 doc that he quotes is what I consulted. It's not surprising to me that the R
 process waits until the Tk window calling tkwait.window() is destroyed. I
 suppose that because the internal help browser runs under the R process, it
 too waits, while an external browser -- as is spawned by help.start() --
 runs in an independent process.

 As I mentioned, I've removed the call to tkwait.window() in the Rcmdr
 sources (it's in a macro called by every Rcmdr modal dialog) and will test
 whether there are negative consequences. I've observed none so far.

 BTW, the same issue arises when the Rcmdr is run inside of RStudio, which
 directs help to its own browser.

 Best,
  John

 -Original Message-
 From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
 Sent: Wednesday, August 13, 2014 11:08 AM
 To: peter dalgaard; John Fox
 Cc: R-SIG-Mac
 Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?

 On 13/08/2014 15:11, peter dalgaard wrote:
  This isn't unique to tcltk. Anything that blocks the keyboard loop
 blocks the help browser too. Try e.g. opening the help for ls, type
 Sys.sleep(15) and watch the beach ball in the help browser as you try
 to scroll in it.

 But Sys.sleep should not be blocking an event loop: from its help

   The intention is that this function suspends execution of R
   expressions but wakes the process up often enough to respond to
   GUI events, typically every 0.5 seconds.

 The mechanisms to mesh event loops which are in place for Sys.sleep
 are
 R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers.

 Note that the help for tkwait says (on my box)

 While  the  tkwait command is waiting it processes events in
 the
 normal
 fashion, so the application will continue to respond to  user
 interac-
 tions.   If  an  event handler invokes tkwait again, the nested
 call to
 tkwait must complete before the outer call can complete.

 but as this is X11 Tk, it means X11/Unix events.  You can demonstrate
 that, as e.g the http server still works (use help.start() first).


  -pd
 
 
  On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote:
 
  Dear Simon,
 
  Here's a simple script that will demonstrate the problem:
 
  - snip -
 
  library(tcltk)
 
  top - tktoplevel()
  button - ttkbutton(top, text=help, command=function()
 print(help(lm)))
  tkgrid(button)
  tkwait.window(top)
 
  - snip -
 
  The problem is produced by tkwait.window(), and this call is in all
 Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause
 problems, but obviously it's causing this problem.  I'm also not
 certain whether calling tkwait.windows() is necessary and will look
 into the consequences of removing it -- I believe that it's been there
 for many years, from the earliest versions of the Rcmdr.
 
  With respect to changing using preferences, this is done only until
 the Commander() exits. If getting rid of the call to tkwait.window()
 proves problematic, I can ask the user for permission in a pop-up
 dialog.
 
  Thanks for your help,
  John
 
  On Wed, 13 Aug 2014 00:25:30 -0400
  Simon Urbanek simon.urba...@r-project.org wrote:
  John,
 
  can't you address the underlying issue instead and don't block the
 event loop? A lot of things don't work if the event loop is blocked and
 I would argue that changing user's preferences behind the scenes is a
 violation of the CRAN policies.
  I'm happy to help if you send me a bit more details.
 
  Cheers,
  Simon
 
 
  On Aug 12, 2014, at 6:15 PM, John Fox j...@mcmaster.ca wrote:
 
  Hi Marc,
 
  -Original Message-
  From: Marc Schwartz [mailto:marc_schwa...@me.com]
  Sent: Tuesday, August 12, 2014 5:10 PM
  To: John Fox
  Cc: r-sig-mac@r-project.org
  Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
 
  Hi John,
 
  Happy to help. I recalled seeing something previously on this, so
 a
  search using rseek.org was fruitful.
 
  The potential gotcha, of course, is if for some reason the GUI
 exits in
  a manner possibly not under your control. The setting would not
 be
  returned to the default and the therefore, as you note, retained
 for a
  subsequent session where the behavior may not be desired.
 
 
  Yes, there is that possibility.
 
  If this is for Rcmdr, perhaps this is something that could be
 added to
  a menu, where the user can alter the behavior in either direction
 as

Re: [R-SIG-Mac] bypassing the R.app help browser?

2014-08-13 Thread Richard M. Heiberger

I have a hypothesis why R-Forge might be having trouble.
This is the first time I used Rcmdr in R_3.1.1 on the Mac.
It said it needed to install sem, relimp, lmtest, aplpack.
It also installed the dependency matrixcalc.
matrixcalc is not in the Rcmdr Suggests: list.

My guess is that adding matrixcalc to the Suggests list might be the
missing item
that will allow building on R-Forge.

Rich

On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote:
 Dear Rich,

 -Original Message-
 From: Richard M. Heiberger [mailto:r...@temple.edu]
 Sent: Wednesday, August 13, 2014 1:30 PM
 To: John Fox
 Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac
 Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?

 John,

 I have noticed what I think is a related issue.  I normally run R
 under emacs with ESS.
 help files open an emacs buffer.  When I run Rcmdr on the Mac, then
 Rcmdr changes the help
 file location to something on the Mac.  It restores the emacs buffer
 destination when I close Rcmdr.
 Is there, or can there be, an option to leave the help files in emacs?

 At the moment, help handling is in flux as a consequence of this thred. 
 Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr 
 help_type option that overrides (and restores on exit) the help_type option 
 in options(). By default, this is set to html, but you should be able to 
 set it to whatever works with emacs -- I suppose 
 options(Rcmdr=list(help_type=text)) would do the trick.

 Please try this out and let me know if it does what you want. The Rcmdr 
 package isn't currently building on R-Forge for reasons that I don't 
 completely understand: R-Forge complains that some package dependencies are 
 missing, but these missing packages *are* on CRAN. So you'll have to 
 download the Rcmdr sources via svn checkout 
 svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the 
 package yourself.

 Best,
  John

 Thanks

 Rich


 On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote:
  Dear Brian and Peter,
 
  Thanks for picking up this issue.
 
  The behaviour that Brian reports is exactly what I observed, and the
 Tcl/Tk
  doc that he quotes is what I consulted. It's not surprising to me
 that the R
  process waits until the Tk window calling tkwait.window() is
 destroyed. I
  suppose that because the internal help browser runs under the R
 process, it
  too waits, while an external browser -- as is spawned by help.start()
 --
  runs in an independent process.
 
  As I mentioned, I've removed the call to tkwait.window() in the Rcmdr
  sources (it's in a macro called by every Rcmdr modal dialog) and
 will test
  whether there are negative consequences. I've observed none so far.
 
  BTW, the same issue arises when the Rcmdr is run inside of RStudio,
 which
  directs help to its own browser.
 
  Best,
   John
 
  -Original Message-
  From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
  Sent: Wednesday, August 13, 2014 11:08 AM
  To: peter dalgaard; John Fox
  Cc: R-SIG-Mac
  Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
 
  On 13/08/2014 15:11, peter dalgaard wrote:
   This isn't unique to tcltk. Anything that blocks the keyboard loop
  blocks the help browser too. Try e.g. opening the help for ls, type
  Sys.sleep(15) and watch the beach ball in the help browser as you
 try
  to scroll in it.
 
  But Sys.sleep should not be blocking an event loop: from its help
 
The intention is that this function suspends execution of R
expressions but wakes the process up often enough to respond
 to
GUI events, typically every 0.5 seconds.
 
  The mechanisms to mesh event loops which are in place for Sys.sleep
  are
  R_CheckUserInterrupt (which calls R_ProcessEvents) and
 R_runHandlers.
 
  Note that the help for tkwait says (on my box)
 
  While  the  tkwait command is waiting it processes events in
  the
  normal
  fashion, so the application will continue to respond to
 user
  interac-
  tions.   If  an  event handler invokes tkwait again, the
 nested
  call to
  tkwait must complete before the outer call can complete.
 
  but as this is X11 Tk, it means X11/Unix events.  You can
 demonstrate
  that, as e.g the http server still works (use help.start() first).
 
 
   -pd
  
  
   On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote:
  
   Dear Simon,
  
   Here's a simple script that will demonstrate the problem:
  
   - snip -
  
   library(tcltk)
  
   top - tktoplevel()
   button - ttkbutton(top, text=help, command=function()
  print(help(lm)))
   tkgrid(button)
   tkwait.window(top)
  
   - snip -
  
   The problem is produced by tkwait.window(), and this call is in
 all
  Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause
  problems, but obviously it's causing this problem.  I'm also not
  certain whether calling tkwait.windows() is necessary and will look

Re: [R-SIG-Mac] bypassing the R.app help browser?

2014-08-13 Thread Richard M. Heiberger

I downloaded Rcmdr_2.1-0 and installed it on my Mac.
I am using
57531778 Jul 16 23:58 R-3.1-branch-mavericks.pkg
R version 3.1.1 Patched (2014-07-16 r66175)
Rcmdr needs RcmdrMisc which I see is in the same
svn download, so I installed it too.

I don't see anything on the Tools  Options that looks relevant to the
help system.

options(Rcmdr) comes up NULL.

I tried

 Rcmdr - list( help_type=text)
 options()$Rcmdr
NULL
 options(Rcmdr=Rcmdr)
 options(Rcmdr)
$Rcmdr
$Rcmdr$help_type
[1] text

and also
 options(help_type=text)

Neither helped.  Help files are sent to an X11 viewer.

I detached Rcmdr with unload=TRUE and help files went back to an emacs buffer.

Please suggest something else for me to try.

Rich


On Wed, Aug 13, 2014 at 8:33 PM, Richard M. Heiberger r...@temple.edu wrote:
 I have a hypothesis why R-Forge might be having trouble.
 This is the first time I used Rcmdr in R_3.1.1 on the Mac.
 It said it needed to install sem, relimp, lmtest, aplpack.
 It also installed the dependency matrixcalc.
 matrixcalc is not in the Rcmdr Suggests: list.

 My guess is that adding matrixcalc to the Suggests list might be the
 missing item
 that will allow building on R-Forge.

 Rich

 On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote:
 Dear Rich,

 -Original Message-
 From: Richard M. Heiberger [mailto:r...@temple.edu]
 Sent: Wednesday, August 13, 2014 1:30 PM
 To: John Fox
 Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac
 Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?

 John,

 I have noticed what I think is a related issue.  I normally run R
 under emacs with ESS.
 help files open an emacs buffer.  When I run Rcmdr on the Mac, then
 Rcmdr changes the help
 file location to something on the Mac.  It restores the emacs buffer
 destination when I close Rcmdr.
 Is there, or can there be, an option to leave the help files in emacs?

 At the moment, help handling is in flux as a consequence of this thred. 
 Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr 
 help_type option that overrides (and restores on exit) the help_type option 
 in options(). By default, this is set to html, but you should be able to 
 set it to whatever works with emacs -- I suppose 
 options(Rcmdr=list(help_type=text)) would do the trick.

 Please try this out and let me know if it does what you want. The Rcmdr 
 package isn't currently building on R-Forge for reasons that I don't 
 completely understand: R-Forge complains that some package dependencies are 
 missing, but these missing packages *are* on CRAN. So you'll have to 
 download the Rcmdr sources via svn checkout 
 svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build 
 the package yourself.

 Best,
  John

 Thanks

 Rich


 On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote:
  Dear Brian and Peter,
 
  Thanks for picking up this issue.
 
  The behaviour that Brian reports is exactly what I observed, and the
 Tcl/Tk
  doc that he quotes is what I consulted. It's not surprising to me
 that the R
  process waits until the Tk window calling tkwait.window() is
 destroyed. I
  suppose that because the internal help browser runs under the R
 process, it
  too waits, while an external browser -- as is spawned by help.start()
 --
  runs in an independent process.
 
  As I mentioned, I've removed the call to tkwait.window() in the Rcmdr
  sources (it's in a macro called by every Rcmdr modal dialog) and
 will test
  whether there are negative consequences. I've observed none so far.
 
  BTW, the same issue arises when the Rcmdr is run inside of RStudio,
 which
  directs help to its own browser.
 
  Best,
   John
 
  -Original Message-
  From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
  Sent: Wednesday, August 13, 2014 11:08 AM
  To: peter dalgaard; John Fox
  Cc: R-SIG-Mac
  Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
 
  On 13/08/2014 15:11, peter dalgaard wrote:
   This isn't unique to tcltk. Anything that blocks the keyboard loop
  blocks the help browser too. Try e.g. opening the help for ls, type
  Sys.sleep(15) and watch the beach ball in the help browser as you
 try
  to scroll in it.
 
  But Sys.sleep should not be blocking an event loop: from its help
 
The intention is that this function suspends execution of R
expressions but wakes the process up often enough to respond
 to
GUI events, typically every 0.5 seconds.
 
  The mechanisms to mesh event loops which are in place for Sys.sleep
  are
  R_CheckUserInterrupt (which calls R_ProcessEvents) and
 R_runHandlers.
 
  Note that the help for tkwait says (on my box)
 
  While  the  tkwait command is waiting it processes events in
  the
  normal
  fashion, so the application will continue to respond to
 user
  interac-
  tions.   If  an  event handler invokes tkwait again, the
 nested
  call to
  tkwait must complete before the outer call can complete

Re: [R-SIG-Mac] Hello

2014-08-01 Thread Richard M. Heiberger

R Commander menus are sensitive to the currently active data.frame.
My guess is that you didn't declare that.  Do so on the R Commander
menu with item
Data set:

Also be sure to read the Introduction to the R Commander on the
Rcmdr Help menu item.

On Fri, Aug 1, 2014 at 11:35 AM, Grant Rettke g...@wisdomandwonder.com wrote:
 Gotchat. CC'd the list for you.
 Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
 g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
 “Wisdom begins in wonder.” --Socrates
 ((λ (x) (x x)) (λ (x) (x x)))
 “Life has become immeasurably better since I have been forced to stop
 taking it seriously.” --Thompson


 On Fri, Aug 1, 2014 at 10:34 AM, Endrin Koni endrink...@gmail.com wrote:
 And   The X Window System  XQuartz 2.6.5 (xorg-server 1.10.6)


 On Fri, Aug 1, 2014 at 4:37 PM, Grant Rettke g...@wisdomandwonder.com
 wrote:

 What did you do and what did you expect to have happen and what
 happened instead?

 What operating system and version of R are you running and where did
 you obtain it?
 Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
 g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
 “Wisdom begins in wonder.” --Socrates
 ((λ (x) (x x)) (λ (x) (x x)))
 “Life has become immeasurably better since I have been forced to stop
 taking it seriously.” --Thompson


 On Fri, Aug 1, 2014 at 9:26 AM, Endrin Koni endrink...@gmail.com wrote:
  I am a new user of R software on Mac but I face difficulties applying
  the
  commands. I am trying to watch tutorials but my program   responds in
  different way. Please can you help me to perform analyses with this
  software?
 
  Many thanks in advance
 
  Koni Endrin
 
  [[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

[R-SIG-Mac] consistent segfault

2014-07-17 Thread Richard M. Heiberger

I can consistently get a segfault from Mavericks 3.1 and I suspect it
is from a mismatch
of compiled code.  Can this type of mismatch be detected when the
package is loaded?


When I moved to the Mavericks R distribution, I copied packages from
my 3.0 (SnowLeopard) library and then did an update.packages().  That
gives a segfault.
I did a fresh install of the relevant package and then it worked.
Both listings are below.

A. segfault listing with copied colorspace package

R version 3.1.1 (2014-07-10) -- Sock it to Me
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin13.1.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.

  options(STERM='iESS', str.dendrogram.last=', editor='emacsclient', 
  show.error.locations=TRUE)
 library(colorspace)
 ?hex
  hsv = HSV(seq(0, 360, length = 7)[-7], 1, 1)
  hsv
   H S V
[1,]   0 1 1
[2,]  60 1 1
[3,] 120 1 1
[4,] 180 1 1
[5,] 240 1 1
[6,] 300 1 1
  hex(hsv)

 *** caught segfault ***
address 0x0, cause 'memory not mapped'

Traceback:
 1: .Call(as_sRGB, from@coords, class(from), .WhitePoint, PACKAGE =
colorspace)
 2: cbind(R, if (missing(G)) NULL else G, if (missing(B)) NULL else B)
 3: sRGB(.Call(as_sRGB, from@coords, class(from), .WhitePoint,
PACKAGE = colorspace), names = dimnames(from@coords)[[1]])
 4: asMethod(object)
 5: as(from, sRGB)
 6: hex(hsv)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2

Process R finished at Thu Jul 17 07:25:40 2014


B. same R distribution with newer colorspace

R version 3.1.1 (2014-07-10) -- Sock it to Me
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin13.1.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.

  options(STERM='iESS', str.dendrogram.last=', editor='emacsclient', 
  show.error.locations=TRUE)
 install.packages(colorspace)
--- Please select a CRAN mirror for use in this session ---
trying URL 
'http://lib.stat.cmu.edu/R/CRAN/bin/macosx/mavericks/contrib/3.1/colorspace_1.2-4.tgz'
Content type 'application/x-gzip' length 391920 bytes (382 Kb)
opened URL
==
downloaded 382 Kb


The downloaded binary packages are in
/var/folders/vq/xl0j17pn29g52mgx7lqxl8d8gn/T//Rtmp5YxaKt/downloaded_packages
 library(colorspace)
  hsv = HSV(seq(0, 360, length = 7)[-7], 1, 1)
  hsv
   H S V
[1,]   0 1 1
[2,]  60 1 1
[3,] 120 1 1
[4,] 180 1 1
[5,] 240 1 1
[6,] 300 1 1
  hex(hsv)
[1] #FF #00 #00FF00 #00 #FF #FF00FF
 q()

Process R finished at Thu Jul 17 07:34:55 2014



Both colorspace package DESCRIPTION files start with
Package: colorspace
Version: 1.2-4
Date: 2013-09-30

The only difference in the DESCRIPTION file is
Built: R 3.0.2; x86_64-apple-darwin10.8.0; 2014-01-09 19:11:14 UTC; unix
Built: R 3.1.0; x86_64-apple-darwin13.1.0; 2014-04-24 15:04:36 UTC; unix

The files in the libs directory are different

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

[R-SIG-Mac] warning message from OS X

2014-05-06 Thread Richard M. Heiberger

May  6 15:08:33 rmhs-MacBook-Air.local R[21671] Error:
CGContextSetFont: invalid context 0x10064d430. This is a serious
error. This application, or a library it uses, is using an invalid
context  and is thereby contributing to an overall degradation of
system stability and reliability. This notice is a courtesy: please
fix this problem. It will become a fatal error in an upcoming update.

I get this message when I page up and down too quickly when using
the Quartz device.
I use the keyboard Apple-LeftArrow and Apple-RightArrow.

Rich

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

[R-SIG-Mac] mac mavericks problem

2013-10-24 Thread Richard M. Heiberger

one of my students just download mac mavericks.
starting with the new system, R-3.0.1 in the APP is misbehaving.

enter
TRUE - FALSE
(to illustrate why use of T is not a good practice)

R app gives the error message
invalid (do_set) left-hand side to assignment

*** caught segfault ***
address 0x7c0, cause 'memory not mapped'
Possible actions
1 2 3 4


The R program run in the terminal behaves correctly.
it reports the invalid assignment and then gives a normal R prompt.

Will this happen in R-3.0.2? (yes we will download and check that).

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

Re: [R-SIG-Mac] mac mavericks problem

2013-10-24 Thread Richard M. Heiberger

of course you never use it.  it won't work.
the point of the email is that writing an invalid statement should
trigger only an error message.  It should not trigger the segfault.

It looks like the segfault is specific to 3.0.1 since your and Marc both report
that you don't see the segfault on 3.0.2

I will tell the student to upgrade to 3.0.2 immediately.

On Thu, Oct 24, 2013 at 12:46 PM, Federico Calboli
f.calb...@imperial.ac.uk wrote:
 On 24 Oct 2013, at 17:37, Marc Schwartz marc_schwa...@me.com wrote:

 Rich,

 I get the same error message, but not the segfault, using 3.0.2 on 
 Mavericks, using R.app:

 R version 3.0.2 (2013-09-25) -- Frisbee Sailing
 Copyright (C) 2013 The R Foundation for Statistical Computing
 Platform: x86_64-apple-darwin10.8.0 (64-bit)

 ...

 [R.app GUI 1.62 (6558) x86_64-apple-darwin10.8.0]

 which I otherwise never use.


 TRUE - FALSE
 Error in TRUE - FALSE : invalid (do_set) left-hand side to assignment


 On Mountain Lion, R 3.0.2:

 TRUE = FALSE
 Error in TRUE = FALSE : invalid (do_set) left-hand side to assignment

 in R.app, and in a terminal.  I also get the same on a linux machine.

 I think that's a  feature, not a bug.

 BW

 F

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

[R-SIG-Mac] problem in quartz with emacs/ESS

2012-11-23 Thread Richard M. Heiberger

I think this is a quartz problem interacting with emacs/ESS.  When I run the
following lines in the *R* buffer,

## --
library(grid)
library(lattice)
library(png)

Rlogo.png  -
readPNG(/Library/Frameworks/R.framework/Versions/2.15/Resources/library/png/img/Rlogo.png,
TRUE)

Rlogo.grob - rasterGrob(Rlogo.png, width=unit(.64,in), y=unit(0,npc))
Rlogo.legend - list(left=list(fun=Rlogo.grob))

## example
xyplot(1:10 ~ 1:10, legend=Rlogo.legend)
## --


the plot shows up on the quartz device ok.  When I print from the quartz
device, the sample image
in the print window has two superimposed graphs.  One is the actual image.
 The other is
an upside down mirror image about twice as big.  The printed page shows the
doubled image.

When I print directly to the pdf() device on the Mac, it behaves normally.
When I run the same lines above on the windows() device in Windows, it also
behaves ok.
When I run the same lines from the R gui on the Mac, it behaves normally.

I saw this first with R version 2.15.2 RC (2012-10-18 r60960) and
then when I updated a few minutes ago to
R version 2.15.2 (2012-10-26) -- Trick or Treat, I still see it.

Sometimes, when I attempt to print from the quartz device while running
under ESS,
I get the pinwheel and this message in the *R* buffer.
 Error: REAL() can only be applied to a 'numeric', not a 'NULL'

Killing R is the only recourse at this point.

Rich

[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Naive question about permissions

2012-10-19 Thread Richard M. Heiberger

R runs in emacs on the mac.  I use
GNU Emacs 23.4.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of
2012-01-29 on bob.porkrind.org

with Vincent Goulet's distribution.  M-x R works.

On Fri, Oct 19, 2012 at 5:28 PM, Paul Hewson paul.hew...@plymouth.ac.ukwrote:

 typing R in the console gets the error you don't have permission to use
 the application R.   the message is on a dialog box that pops up.

 the R gui though is marvellous, works fine.   Problem is I can't run r
 from aquamacs (same error message), or from make.

 R will though run as sudo, but that seems like a naughty workround.   But
 at least it suggests all the paths etc. are correct.

 Fairly sure this is all dumb newbie mac user, but I hope I'm not the
 first.   I couldn't see anything on any helplists anywhere.   The only
 thing close was to run the repair permissions which I've done and a email
 from you a couple of years ago about mac installer setting permissions.
 As I say, I think I've tracked the symlink itself as well as the files it
 links to /usr/bin/R is itself a symlink to R64.All three users have an
 x when you do ls -l , they don't all have r and w.


 Thanks
 paul
 =+=+=+=+=+=+=+=+=+=+=+=
 Paul Hewson
 Editor, Teaching Statistics (www.teachingstatistics.co.uk)
 Associate Professor (SL) Statistics
 School of Computing  Maths
 Plymouth University
 Drake Circus
 Plymouth PL4 8AA
 ++44 (0)1752 586870


 On 19 Oct 2012, at 22:05, Simon Urbanek simon.urba...@r-project.org
 wrote:

  Paul,
 
  On Oct 19, 2012, at 3:52 PM, Paul Hewson wrote:
 
  Hello,
  I have just been given an institutional macbook - I'm very used to
 linux, but some apple things are baffling me (like the lack of sudo apt-get
 update and upgrade for example).
 
 
  It's called softwareupdate on OS X ... apt is specific to Debian, so,
 yes, OS X is not Debian :) Just install Debian on the MacBook if you don't
 want to be baffled, it's possible and some people that buy Macs just for
 the hardware do it.
 
 
  I've installed roasted marshmallows, it's very nice.   However, I can't
 run it from command line (or aquamacs) due to some permissions error.
 I've checked both R, the R64 and the symlink as described on the FAQ page.
   All the permissions look OK (everyone seems to have x).
 
  The only thing I can think of is that I'm not in the admin group (and
 can't seem to put myself in that group).Could this be a chmod issue or
 am I barking up the wrong tree completely.
 
 
  We can't tell because you omitted all useful information ... (what
 error? where? how do you start it?)
 
  Cheers,
  Simon
 
 
 
 
  Paul
 
  =+=+=+=+=+=+=+=+=+=+=+=
  Paul Hewson
  Editor, Teaching Statistics (www.teachingstatistics.co.uk)
  Associate Professor (SL) Statistics
  School of Computing  Maths
  Plymouth University
  Drake Circus
  Plymouth PL4 8AA
  ++44 (0)1752 586870
 
  ___
  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


[[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] warning on macintosh 2.16 that is not on 2.15.2 or on windows

2012-10-19 Thread Richard M. Heiberger

mylegend -
structure(list(bottom = structure(list(fun = draw.key, args =
structure(list(
key = structure(list(y = -0.2, x = 0.15, points = structure(list(
col = c(red, blue), pch = c(16, 17)), .Names = c(col,
pch)), text = structure(list(c(TREATMENT A (N=216), TREATMENT B
(N=431)
), col = c(red, blue), cex = 0.9), .Names = c(, col,
cex)), columns = 2, between = 0.5, space = bottom), .Names = c(y,
x, points, text, columns, between, space)), draw = FALSE),
.Names = c(key,
draw))), .Names = c(fun, args))), .Names = bottom)


lattice:::evaluate.legend(mylegend)


On Macintosh 2.16
version.string R Under development (unstable) (2012-10-18 r60960)
I get a warning

 lattice:::evaluate.legend(mylegend)
$bottom
$bottom$obj
frame[plot_01.key.frame]


Warning messages:
1: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
2: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
3: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
4: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
5: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL


On Macintosh
R version 2.15.2 RC (2012-10-18 r60960)
it works normally
 lattice:::evaluate.legend(mylegend)
$bottom
$bottom$obj
frame[.key.frame]





On Windows, it works normally
version.string R version 2.15.1 (2012-06-22)

 lattice:::evaluate.legend(mylegend)
$bottom
$bottom$obj
frame[plot_01.key.frame]






This is the Macintosh trace

 trace(lattice:::evaluate.legend, exit=recover)
Tracing function evaluate.legend in package lattice
(not-exported)
[1] evaluate.legend
 lattice:::evaluate.legend(ae.tr$legend)
Tracing lattice:::evaluate.legend(ae.tr$legend) on exit

Enter a frame number, or 0 to exit

1: lattice:::evaluate.legend(ae.tr$legend)

Selection: 1
Called from: .doTrace(recover(), on exit)
Browse[1] ls()
[1] funi  legend
Warning messages:
1: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
2: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
3: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
4: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
5: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
Browse[1] fun
frame[plot_01.key.frame]
Browse[1] i
[1] 1
Browse[1] legend
$bottom
$bottom$obj
frame[plot_01.key.frame]


Browse[1] Q




This is the Windows trace

 trace(lattice:::evaluate.legend, exit=recover)
Tracing function evaluate.legend in package lattice
(not-exported)
[1] evaluate.legend
 lattice:::evaluate.legend(ae.tr$legend)
Tracing lattice:::evaluate.legend(ae.tr$legend) on exit

Enter a frame number, or 0 to exit

1: lattice:::evaluate.legend(ae.tr$legend)

Selection: 1
Called from: .doTrace(recover(), on exit)
Browse[1] ls()
[1] funi  legend
Browse[1] fun
frame[plot_01.key.frame]
Browse[1] i
[1] 1
Browse[1] legend
$bottom
$bottom$obj
frame[plot_01.key.frame]


Browse[1] Q




On Windows I have
version.string R version 2.15.1 (2012-06-22)

On Macintosh I have
version.string R Under development (unstable) (2012-08-02 r60091)

[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] graphics device with record=TRUE

2012-07-05 Thread Richard M. Heiberger

It is interesting to compare working styles. I am not up to anything. I
am trying
to recreate in Mac the standard working style I use in R on windows and
also in S-Plus on windows. I just keep the complete graph history until it
complains about lack of memory.
In S-Plus, it is possible to delete individual plots. In R on windows I
haven't found an easy
way to do that, so I just delete the R object containing the entire
history. When I adjust
arguments to xyplot or plot it is very helpful to be able to back up and
see what the previous
incarnation of the graph looked like.

Where is R MacOSX FAQ? I don't see it on my computer
inside /Library/Frameworks/R.framework/
I am using R-2.15.1 from CRAN.

What is GEcreateSnapshot? I tried ?, emacs apropos, and man with no
success.

Where is the display list kept on the mac? ls(all=TRUE) isn't showing it.
On windows, it is
ls(all=TRUE)
[1] .SavedPlots

When I do find the display list on the mac, how can I index into it farther
back than 16?

What I would like are two features that I have become accustomed to.
From either R on windows or S-Plus, click graphs forward or backward in
sequence as far back as memory supports.
From S-Plus on windows, click on a tab to get to a specific graph, or click
on a tab and delete
a specific graph.

On Thu, Jul 5, 2012 at 10:01 AM, Simon Urbanek
simon.urba...@r-project.orgwrote:

On Jul 5, 2012, at 9:42 AM, David Winsemius wrote:

On Jul 4, 2012, at 11:47 PM, Richard M. Heiberger wrote:

David,

thank you. it works.

Where is it documented?

The first place I find written documentation of the cmd-arrow
functions is in the R MacOSX FAQ:
12.8 Why are Quartz plots much bigger than they used to be?
(Second paragraph)

(I may have read about the stack depth in one of the postings from
Simon in this venue. The figure of ten is a rough guess. The true
value is somewhere in the range of 8 to 15.)

I want to set the depth to something much larger than 10.

I have not found a place for users to change this. May be that a
compile time change is needed. (Simon will hopefully correct me if
this is wrong.)

R-devel/src/library/grDevices/src/qdCocoa.m@37:

#define histsize 16

so, yes, it is hard-coded in R.

It is not part of the R.app GUI but actually of the Quartz device in R
itself so it is not configurable.

It simply saves display lists and replays them as you go back - you can do
that with any device that has display lists enabled (see dev.control). I'm
not sure what Rich is up to but you can always save and restore plots with
GEcreateSnapshot and GEplayDisplayList regardless of the device and the
display list is just an R object. Keeping more than 16 plots seems a little
tedious to go through ...

Cheers,
Simon

I tried searching MarkMail's archive with a couple of strategies, ...
the last unsuccessful one was:

http://markmail.org/search/?q=simon+urbanek+list%3Aorg.r-project.r-sig-mac+graphics+increase#query
:simon%20urbanek%20list%3Aorg.r-project.r-sig-mac%20graphics%20increase
+page:2+mid:ykmzj6mwesj3wywu+state:results

(I don't know if that will be paste-worthy or click-worthy.)

I don't see anything about the stack on the ?quartz page
and there appears not to be any control option on the quartz menu
item on the device
itself.

If the Quartz window is the focus, the Quartz menu options will become
active and even if not the focus the menu will also tell you the
keyboard equivalents (standard Mac behavior). I think that is where I
learned it.

Rich

On Wed, Jul 4, 2012 at 11:35 PM, David Winsemius
dwinsem...@comcast.net
wrote:

On Jul 4, 2012, at 11:12 PM, Richard M. Heiberger wrote:

The windows feature I miss most on the Mac is a graphics device that
remembers the previous graphs,
specifically
windows.options(record=TRUE) ## R for Windows

Is there a similar feature available on the macintosh?

There is a graphics stack, whose default depth is 10, and you can
scroll backward with cmd-left-arrow ... at least in the R64.app
and r.app GUI's.

--
David Winsemius, MD
West Hartford, CT

David Winsemius, MD
West Hartford, CT

[[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] graphics device with record=TRUE

2012-07-05 Thread Richard M. Heiberger

thank you again.

I have a request for Simon.

On the windows machines, the R and Windows FAQ are both in
c:/Program Files/R/R-2.15.1/doc
Hence I looked for the Mac FAQ in the same place as the R FAQ on Mac.

On windows, searchpaths() gives a list of items like
c:/Program Files/R/R-2.15.1/library/base
which gives a starting directory in which to look.

On the Mac, search paths() gives
/Library/Frameworks/R.framework/Resources/library/base
which in this case was not helpful for finding the Mac FAQ.

Can you set up a symbolic link from
/Library/Frameworks/R.framework/Versions/2.15/Resources/doc
to point to /Applications/R.app/Contents/Resources?
That will make it easier for the next person converting from windows to mac.

Thanks
Rich

On Thu, Jul 5, 2012 at 11:59 AM, David Winsemius dwinsem...@comcast.netwrote:

On Jul 5, 2012, at 10:58 AM, Richard M. Heiberger wrote:

It is interesting to compare working styles. I am not up to anything.
I am trying
to recreate in Mac the standard working style I use in R on windows and
also in S-Plus on windows. I just keep the complete graph history until it
complains about lack of memory.
In S-Plus, it is possible to delete individual plots. In R on windows I
haven't found an easy
way to do that, so I just delete the R object containing the entire
history. When I adjust
arguments to xyplot or plot it is very helpful to be able to back up and
see what the previous
incarnation of the graph looked like.

Where is R MacOSX FAQ? I don't see it on my computer
inside /Library/Frameworks/R.framework/
I am using R-2.15.1 from CRAN.

I use the Help menu in the GUI when I want to look at it. It will also be
the first google hit on search using r mac faq.

A bit of messing around with links in the displayed copy shows that I am
looking at:

file:///Applications/R64.app/Contents/Resources/RMacOSX-FAQ.html

What is GEcreateSnapshot? I tried ?, emacs apropos, and man with no
success.

Where is the display list kept on the mac? ls(all=TRUE) isn't showing it.
On windows, it is
ls(all=TRUE)
[1] .SavedPlots

When I do find the display list on the mac, how can I index into it
farther back than 16?

On Thu, Jul 5, 2012 at 10:01 AM, Simon Urbanek
simon.urba...@r-project.org wrote:

On Jul 5, 2012, at 9:42 AM, David Winsemius wrote:

On Jul 4, 2012, at 11:47 PM, Richard M. Heiberger wrote:

David,

thank you. it works.

Where is it documented?

The first place I find written documentation of the cmd-arrow
functions is in the R MacOSX FAQ:
12.8 Why are Quartz plots much bigger than they used to be?
(Second paragraph)

(I may have read about the stack depth in one of the postings from
Simon in this venue. The figure of ten is a rough guess. The true
value is somewhere in the range of 8 to 15.)

I want to set the depth to something much larger than 10.

I have not found a place for users to change this. May be that a
compile time change is needed. (Simon will hopefully correct me if
this is wrong.)

R-devel/src/library/grDevices/src/qdCocoa.m@37:

#define histsize 16

so, yes, it is hard-coded in R.

It is not part of the R.app GUI but actually of the Quartz device in R
itself so it is not configurable.

It simply saves display lists and replays them as you go back - you can
do that with any device that has display lists enabled (see dev.control).
I'm not sure what Rich is up to but you can always save and restore plots
with GEcreateSnapshot and GEplayDisplayList regardless of the device and
the display list is just an R object. Keeping more than 16 plots seems a
little tedious to go through ...

Cheers,
Simon

I tried searching MarkMail's archive with a couple of strategies, ...
the last unsuccessful one was:

(I don't know if that will be paste-worthy or click-worthy.)

I don't see anything about the stack on the ?quartz page
and there appears not to be any control option on the quartz menu
item on the device
itself.

Rich

On Wed, Jul 4, 2012 at 11:35 PM, David Winsemius
dwinsem...@comcast.net
wrote:

On Jul 4, 2012, at 11:12 PM, Richard M. Heiberger wrote:

The windows feature I miss most on the Mac

Re: [R-SIG-Mac] graphics device with record=TRUE

2012-07-04 Thread Richard M. Heiberger

David,

thank you.  it works.

Where is it documented?  I want to set the depth to something much larger
than 10.
I don't see anything about the stack on the ?quartz page
and there appears not to be any control option on the quartz menu item on
the device
itself.

Rich

On Wed, Jul 4, 2012 at 11:35 PM, David Winsemius dwinsem...@comcast.netwrote:


 On Jul 4, 2012, at 11:12 PM, Richard M. Heiberger wrote:

  The windows feature I miss most on the Mac is a graphics device that
 remembers the previous graphs,
 specifically
 windows.options(record=TRUE)  ## R for Windows

 Is there a similar feature available on the macintosh?


 There is a graphics stack, whose default depth is 10, and you can scroll
 backward with cmd-left-arrow  ... at least in the R64.app and r.app GUI's.

 --
 David Winsemius, MD
 West Hartford, CT



[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Error in xzfile(file, wb, compression = 9)

2012-06-09 Thread Richard M. Heiberger

Here is the solution.  David suggested it was a Parallels setting.
I searched through the Parallels documentation.

I turned off the option to share Mac programs with the Windows machine.
Then I rebooted both the Mac and the Windows within it.
Now it works correctly.

I think what I did was overkill.  My guess is that some form of controlled
sharing
should be possible.  I don't need that feature now so I will not take this
any further
at this time.  My guess is rebooting the Windows might have been
sufficient, it was
definitely necessary because rebooting the Mac and leaving the Windows
suspended
didn't do it.

On Fri, Jun 8, 2012 at 6:36 PM, Richard M. Heiberger r...@temple.edu wrote:

 cygwin has bin/xz

 the mac doesnt have xz in its /bin
 I won't follow through today.  reading the r code
 for

 Browse[1] xzfile
 function (description, open = , encoding = getOption(encoding),
 compression = 6)
 .Internal(xzfile(description, open, encoding, compression))
 bytecode: 0x095cce70
 environment: namespace:base
 is the next step, but not today.


 On Fri, Jun 8, 2012 at 6:09 PM, Richard M. Heiberger r...@temple.eduwrote:

 I am using exactly the same Rtools etc on both the real Windows machine
 and the Parallels version on the Mac.

 FOllowigin your hint I am sure the problem is a file
 extension association inside parallels.  The trick is to
 find it.  I am now doing a find / -name xz
 on both machines.

 Is it true that noone else has attempted to build a package on the
 windows side of a parallels windows on a mac?
  On Fri, Jun 8, 2012 at 5:56 PM, David Winsemius 
 dwinsem...@comcast.netwrote:


 On Jun 8, 2012, at 5:16 PM, Richard M. Heiberger wrote:

 I just changed all 6 to
 C:\Program Files\R\R-2.15.0\bin\i386\Rgui.exe which
 displays as R for Windows Gui front-end
 Doing that did not solve this problem.


 As I suggested before, I don't really think this is a Mac problem. I
 think you should be looking for solutions that involve creating Windows
 capabilities to handle the deficient compressed file format processing.
 WinZip is not a free program, but perhaps the Win-GNU facilities would be
 available. Have you gone through the process of installing Murdoch's Rtools
 suite on your virtualized Windows?

 --
 David.


  I guess the next step is reading the scripts in Rtools.
 On Fri, Jun 8, 2012 at 5:05 PM, Richard M. Heiberger r...@temple.eduwrote:

 Yes,
 .q .r .rcommand .rd .rda .rds
 are sent to R (Mac).

 .rdata ggoes to R for Windows GUI front end.
 I will experiment with the right target for the others.

 On Fri, Jun 8, 2012 at 5:03 PM, Richard M. Heiberger 
 r...@temple.eduwrote:

 David,


 that makes sense to me.  How do I respond to it?


 I ran into a similar situation yesterday.  On the Windows side I

 have Acrobat Reader.  Yet the default for pdf files on the Windows
 side was Macintosh Preview and Windows couldn't start it.  I changed it

 to Acrobat Reader and then Windows could display the pdf files.

 I will look at the file extensions map now for lzma.  Should you get
 back to me before I find it, I would be very happy.


 Rich

  On Fri, Jun 8, 2012 at 4:53 PM, David Winsemius 
 dwinsem...@comcast.net wrote:


 On Jun 8, 2012, at 4:21 PM, Richard M. Heiberger wrote:

  I just bought a Mac and am learning it.

 I have a package which R CMD checks normally on a PC and in Mac
 mode on
 the new Mac.
 Under Windows in Parallels on the Mac, I am getting a message I don't
 understand.

 * checking data for ASCII and uncompressed saves ... WARNING
  Error in xzfile(file, wb, compression = 9) : cannot open the
 connection
  Calls: Anonymous - resaveRdaFiles - save - xzfile
  In addition: Warning message:
  In xzfile(file, wb, compression = 9) :
   cannot initialize lzma encoder, error 5
  Execution halted

 I looked for xzfile and lzma on the mac list archive in gmane and
 didn't
 see anything.
 Does anyone have experience with this message?
 Is gmane the best way to search the mac list archive?


 It sounds more like a Windows/Parallels problem. I would not have
 expected the Mac xzfile functions to be offered to R running within
 Windows, even if they are on Mac hardware.

 --

 David Winsemius, MD
 West Hartford, CT





  David Winsemius, MD
 West Hartford, CT





[[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] Error in xzfile(file, wb, compression = 9)

I just bought a Mac and am learning it.

I have a package which R CMD checks normally on a PC and in Mac mode on
the new Mac.
Under Windows in Parallels on the Mac, I am getting a message I don't
understand.

* checking data for ASCII and uncompressed saves ... WARNING
  Error in xzfile(file, wb, compression = 9) : cannot open the connection
  Calls: Anonymous - resaveRdaFiles - save - xzfile
  In addition: Warning message:
  In xzfile(file, wb, compression = 9) :
cannot initialize lzma encoder, error 5
  Execution halted

I looked for xzfile and lzma on the mac list archive in gmane and didn't
see anything.
Does anyone have experience with this message?
Is gmane the best way to search the mac list archive?

Thanks
Rich

[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Error in xzfile(file, wb, compression = 9)

David,



that makes sense to me.  How do I respond to it?



I ran into a similar situation yesterday.  On the Windows side I

have Acrobat Reader.  Yet the default for pdf files on the Windows side was
Macintosh Preview and Windows couldn't start it.  I changed it

to Acrobat Reader and then Windows could display the pdf files.

I will look at the file extensions map now for lzma.  Should you get back
to me before I find it, I would be very happy.



Rich

On Fri, Jun 8, 2012 at 4:53 PM, David Winsemius dwinsem...@comcast.netwrote:


 On Jun 8, 2012, at 4:21 PM, Richard M. Heiberger wrote:

  I just bought a Mac and am learning it.

 I have a package which R CMD checks normally on a PC and in Mac mode on
 the new Mac.
 Under Windows in Parallels on the Mac, I am getting a message I don't
 understand.

 * checking data for ASCII and uncompressed saves ... WARNING
  Error in xzfile(file, wb, compression = 9) : cannot open the connection
  Calls: Anonymous - resaveRdaFiles - save - xzfile
  In addition: Warning message:
  In xzfile(file, wb, compression = 9) :
   cannot initialize lzma encoder, error 5
  Execution halted

 I looked for xzfile and lzma on the mac list archive in gmane and didn't
 see anything.
 Does anyone have experience with this message?
 Is gmane the best way to search the mac list archive?


 It sounds more like a Windows/Parallels problem. I would not have expected
 the Mac xzfile functions to be offered to R running within Windows, even if
 they are on Mac hardware.

 --

 David Winsemius, MD
 West Hartford, CT



[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Error in xzfile(file, wb, compression = 9)

Yes,
.q .r .rcommand .rd .rda .rds
are sent to R (Mac).

.rdata ggoes to R for Windows GUI front end.
I will experiment with the right target for the others.

On Fri, Jun 8, 2012 at 5:03 PM, Richard M. Heiberger r...@temple.edu wrote:

 David,



 that makes sense to me.  How do I respond to it?



 I ran into a similar situation yesterday.  On the Windows side I

 have Acrobat Reader.  Yet the default for pdf files on the Windows side
 was Macintosh Preview and Windows couldn't start it.  I changed it

 to Acrobat Reader and then Windows could display the pdf files.

 I will look at the file extensions map now for lzma.  Should you get back
 to me before I find it, I would be very happy.



 Rich

 On Fri, Jun 8, 2012 at 4:53 PM, David Winsemius dwinsem...@comcast.netwrote:


 On Jun 8, 2012, at 4:21 PM, Richard M. Heiberger wrote:

  I just bought a Mac and am learning it.

 I have a package which R CMD checks normally on a PC and in Mac mode on
 the new Mac.
 Under Windows in Parallels on the Mac, I am getting a message I don't
 understand.

 * checking data for ASCII and uncompressed saves ... WARNING
  Error in xzfile(file, wb, compression = 9) : cannot open the
 connection
  Calls: Anonymous - resaveRdaFiles - save - xzfile
  In addition: Warning message:
  In xzfile(file, wb, compression = 9) :
   cannot initialize lzma encoder, error 5
  Execution halted

 I looked for xzfile and lzma on the mac list archive in gmane and didn't
 see anything.
 Does anyone have experience with this message?
 Is gmane the best way to search the mac list archive?


 It sounds more like a Windows/Parallels problem. I would not have
 expected the Mac xzfile functions to be offered to R running within
 Windows, even if they are on Mac hardware.

 --

 David Winsemius, MD
 West Hartford, CT




[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Error in xzfile(file, wb, compression = 9)

I just changed all 6 to
C:\Program Files\R\R-2.15.0\bin\i386\Rgui.exe which
displays as R for Windows Gui front-end
Doing that did not solve this problem.

I guess the next step is reading the scripts in Rtools.
On Fri, Jun 8, 2012 at 5:05 PM, Richard M. Heiberger r...@temple.edu wrote:

 Yes,
 .q .r .rcommand .rd .rda .rds
 are sent to R (Mac).

 .rdata ggoes to R for Windows GUI front end.
 I will experiment with the right target for the others.

 On Fri, Jun 8, 2012 at 5:03 PM, Richard M. Heiberger r...@temple.eduwrote:

 David,



 that makes sense to me.  How do I respond to it?



 I ran into a similar situation yesterday.  On the Windows side I

 have Acrobat Reader.  Yet the default for pdf files on the Windows side
 was Macintosh Preview and Windows couldn't start it.  I changed it

 to Acrobat Reader and then Windows could display the pdf files.

 I will look at the file extensions map now for lzma.  Should you get back
 to me before I find it, I would be very happy.



 Rich

  On Fri, Jun 8, 2012 at 4:53 PM, David Winsemius 
 dwinsem...@comcast.netwrote:


 On Jun 8, 2012, at 4:21 PM, Richard M. Heiberger wrote:

  I just bought a Mac and am learning it.

 I have a package which R CMD checks normally on a PC and in Mac mode
 on
 the new Mac.
 Under Windows in Parallels on the Mac, I am getting a message I don't
 understand.

 * checking data for ASCII and uncompressed saves ... WARNING
  Error in xzfile(file, wb, compression = 9) : cannot open the
 connection
  Calls: Anonymous - resaveRdaFiles - save - xzfile
  In addition: Warning message:
  In xzfile(file, wb, compression = 9) :
   cannot initialize lzma encoder, error 5
  Execution halted

 I looked for xzfile and lzma on the mac list archive in gmane and didn't
 see anything.
 Does anyone have experience with this message?
 Is gmane the best way to search the mac list archive?


 It sounds more like a Windows/Parallels problem. I would not have
 expected the Mac xzfile functions to be offered to R running within
 Windows, even if they are on Mac hardware.

 --

 David Winsemius, MD
 West Hartford, CT





[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Error in xzfile(file, wb, compression = 9)

I am using exactly the same Rtools etc on both the real Windows machine and
the Parallels version on the Mac.

FOllowigin your hint I am sure the problem is a file
extension association inside parallels.  The trick is to
find it.  I am now doing a find / -name xz
on both machines.

Is it true that noone else has attempted to build a package on the windows
side of a parallels windows on a mac?
On Fri, Jun 8, 2012 at 5:56 PM, David Winsemius dwinsem...@comcast.netwrote:


 On Jun 8, 2012, at 5:16 PM, Richard M. Heiberger wrote:

 I just changed all 6 to
 C:\Program Files\R\R-2.15.0\bin\i386\Rgui.exe which
 displays as R for Windows Gui front-end
 Doing that did not solve this problem.


 As I suggested before, I don't really think this is a Mac problem. I think
 you should be looking for solutions that involve creating Windows
 capabilities to handle the deficient compressed file format processing.
 WinZip is not a free program, but perhaps the Win-GNU facilities would be
 available. Have you gone through the process of installing Murdoch's Rtools
 suite on your virtualized Windows?

 --
 David.


 I guess the next step is reading the scripts in Rtools.
 On Fri, Jun 8, 2012 at 5:05 PM, Richard M. Heiberger r...@temple.eduwrote:

 Yes,
 .q .r .rcommand .rd .rda .rds
 are sent to R (Mac).

 .rdata ggoes to R for Windows GUI front end.
 I will experiment with the right target for the others.

 On Fri, Jun 8, 2012 at 5:03 PM, Richard M. Heiberger r...@temple.eduwrote:

 David,


 that makes sense to me.  How do I respond to it?


 I ran into a similar situation yesterday.  On the Windows side I

 have Acrobat Reader.  Yet the default for pdf files on the Windows side
 was Macintosh Preview and Windows couldn't start it.  I changed it

 to Acrobat Reader and then Windows could display the pdf files.

 I will look at the file extensions map now for lzma.  Should you get
 back to me before I find it, I would be very happy.


 Rich

  On Fri, Jun 8, 2012 at 4:53 PM, David Winsemius dwinsem...@comcast.net
  wrote:


 On Jun 8, 2012, at 4:21 PM, Richard M. Heiberger wrote:

  I just bought a Mac and am learning it.

 I have a package which R CMD checks normally on a PC and in Mac mode
 on
 the new Mac.
 Under Windows in Parallels on the Mac, I am getting a message I don't
 understand.

 * checking data for ASCII and uncompressed saves ... WARNING
  Error in xzfile(file, wb, compression = 9) : cannot open the
 connection
  Calls: Anonymous - resaveRdaFiles - save - xzfile
  In addition: Warning message:
  In xzfile(file, wb, compression = 9) :
   cannot initialize lzma encoder, error 5
  Execution halted

 I looked for xzfile and lzma on the mac list archive in gmane and
 didn't
 see anything.
 Does anyone have experience with this message?
 Is gmane the best way to search the mac list archive?


 It sounds more like a Windows/Parallels problem. I would not have
 expected the Mac xzfile functions to be offered to R running within
 Windows, even if they are on Mac hardware.

 --

 David Winsemius, MD
 West Hartford, CT





 David Winsemius, MD
 West Hartford, CT



[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Error in xzfile(file, wb, compression = 9)