Re: [R-SIG-Mac] Table of contents for book changed after LaTeX update

[Marc Schwartz via R-SIG-Mac]

Hi Antony,

Deleting the /Library/TeX folder tree would be another one to remove. There are 
also some links that may be in there that go back to the TexLive tree that 
presumably no longer exists.

That being said, in checking the uninstall instructions for TexLive, there is a 
note of caution that if you have multiple TeX installations, others such as 
TinyTeX, may very well use that same /Library/TeX tree for their own purposes.

Thus, if you do delete that tree for the sake of having a clean system, you may 
want to yet again, reinstall TinyTex.

If these additional steps still do not resolve the issue, it may be prudent to 
post to the TinyTex issues forum on Github:

  https://github.com/rstudio/tinytex/issues

perhaps with a reference back to that older rmarkdown issue, to see if any of 
the folks there might have some additional guidance.

Regards,

Marc



From: Antony Unwin 
Date: Wednesday, May 8, 2024 at 11:53 AM
To: Marc Schwartz 
Cc: 
Subject: Re: [R-SIG-Mac] Table of contents for book changed after LaTeX update

Marc,

That makes a lot of sense, thanks for finding the rmarkdown issue and for your 
detailed instructions.  It turned out I had three (!) TeXLive versions, the 
latest being 2015, and I have deleted these and the texmf-local folder.  I also 
uninstalled TinyTeX, rebooted, and installed TinyTeX again.  This has not 
solved my problem, but I suspect I have missed deleting something that should 
be deleted, perhaps /Library/TeX?

Antony 




On 8 May 2024, at 16:37, Marc Schwartz  wrote:

Hi Antony,

Going back and looking at the thread over the weekend, I am wondering, if you 
did not uninstall the older version of TexLive/MacTeX, and there may be some 
conflicts with TinyTex, especially given the age of your old TexLive/MacTeX 
version.

I found the following report, albeit, from 2021:

 https://github.com/rstudio/rmarkdown/issues/2172

that might support the hypothesis of a conflict between the two TeX 
installations.

TeXLive/MacTex will typically install in /usr/local/texlive/, where  is 
the year of the version. If that is still present, or there is more than one, 
and presuming that you want to stay with TinyTeX, I would remove the old 
installation(s).

There will also be a texmf-local folder in the /usr/local/texlive folder and 
you should probably remove that as well.

After the above, you may want to reboot your Mac, then reinstall TinyTeX, just 
to be sure that you then have a full and clean install.

I install the full MacTeX version of TexLive from https://tug.org/mactex/, and 
just update the installation each year, removing the prior year's version, 
typically in the March/April timeframe on release. I also do frequent 
incremental updates of the installation using the TexLive utility app.

Regards,

Marc Schwartz


-Original Message-
From: R-SIG-Mac mailto:r-sig-mac-boun...@r-project.org>> on behalf of Antony Unwin 
mailto:un...@math.uni-augsburg.de>>
Date: Wednesday, May 8, 2024 at 9:46 AM
To: mailto:r-sig-mac@r-project.org>>
Subject: [R-SIG-Mac] Table of contents for book changed after LaTeX update


At the weekend I asked about a LaTex problem I had on the Mac and got an 
immediate solution, great! I have accordingly updated my LaTeX using tinytex 
and have a new problem. When I built my book with bookdown using the updated 
LaTeX there were a few small changes that I had to fix, some of which I think 
may have been due to a bit more space being given around tables, graphics, and 
lists. There was also a large change, the table of contents has extra spacing 
everywhere, so that now it needs 7 pages instead of 5. How can I get the old 
table of contents back?


The book is for CRCPress and uses their krantz.cls LaTeX class file.


Thanks, as always, for any help.


Antony


Professor (em.) Antony Unwin
Mathematics Institute,
University of Augsburg, 
86135 Augsburg, Germany
___
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] Table of contents for book changed after LaTeX update

[Marc Schwartz via R-SIG-Mac]

Hi Antony,

Going back and looking at the thread over the weekend, I am wondering, if you 
did not uninstall the older version of TexLive/MacTeX, and there may be some 
conflicts with TinyTex, especially given the age of your old TexLive/MacTeX 
version.

I found the following report, albeit, from 2021:

  https://github.com/rstudio/rmarkdown/issues/2172

that might support the hypothesis of a conflict between the two TeX 
installations.

TeXLive/MacTex will typically install in /usr/local/texlive/, where  is 
the year of the version. If that is still present, or there is more than one, 
and presuming that you want to stay with TinyTeX, I would remove the old 
installation(s).

There will also be a texmf-local folder in the /usr/local/texlive folder and 
you should probably remove that as well.

After the above, you may want to reboot your Mac, then reinstall TinyTeX, just 
to be sure that you then have a full and clean install.

I install the full MacTeX version of TexLive from https://tug.org/mactex/, and 
just update the installation each year, removing the prior year's version, 
typically in the March/April timeframe on release. I also do frequent 
incremental updates of the installation using the TexLive utility app.

Regards,

Marc Schwartz


-Original Message-
From: R-SIG-Mac mailto:r-sig-mac-boun...@r-project.org>> on behalf of Antony Unwin 
mailto:un...@math.uni-augsburg.de>>
Date: Wednesday, May 8, 2024 at 9:46 AM
To: mailto:r-sig-mac@r-project.org>>
Subject: [R-SIG-Mac] Table of contents for book changed after LaTeX update


At the weekend I asked about a LaTex problem I had on the Mac and got an 
immediate solution, great! I have accordingly updated my LaTeX using tinytex 
and have a new problem. When I built my book with bookdown using the updated 
LaTeX there were a few small changes that I had to fix, some of which I think 
may have been due to a bit more space being given around tables, graphics, and 
lists. There was also a large change, the table of contents has extra spacing 
everywhere, so that now it needs 7 pages instead of 5. How can I get the old 
table of contents back?


The book is for CRCPress and uses their krantz.cls LaTeX class file.


Thanks, as always, for any help.


Antony


Professor (em.) Antony Unwin
Mathematics Institute,
University of Augsburg, 
86135 Augsburg, Germany
___
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] pdflatex not found! Not building PDF manual.

[Marc Schwartz via R-SIG-Mac]

Spencer,

My apologies, as my eyes caught a different post by Dennis on R-Help, as I was 
in the process of replying to yours.

Regards,

Marc

-Original Message-
From: R-SIG-Mac mailto:r-sig-mac-boun...@r-project.org>> on behalf of Marc Schwartz via 
R-SIG-Mac mailto:r-sig-mac@r-project.org>>
Reply-To: Marc Schwartz mailto:marc_schwa...@me.com>>
Date: Tuesday, February 27, 2024 at 4:06 PM
To: Spencer Graves mailto:spencer.gra...@prodsyse.com>>, r-sig-mac mailto:r-sig-mac@r-project.org>>
Subject: Re: [R-SIG-Mac] pdflatex not found! Not building PDF manual.


Dennis,


Do you have a TeX installation on your Mac?


pdflatex is typically installed with TeX, which for macOS is usually via MacTeX:


https://tug.org/mactex/ <https://tug.org/mactex/>


Once you have that installed, you should be good to go, but if you are 
currently running an interactive R session, you will likely need to exit that, 
and then after installing MacTex, restart your R session.


You will also end up with a TeX folder in your Applications folder, where 
supporting apps will reside, including the TeX Live utility, which can be used 
to update the TeX installation periodically.


Regards,


Marc Schwartz




-Original Message-
From: R-SIG-Mac mailto:r-sig-mac-boun...@r-project.org> 
<mailto:r-sig-mac-boun...@r-project.org 
<mailto:r-sig-mac-boun...@r-project.org>>> on behalf of Spencer Graves 
mailto:spencer.gra...@prodsyse.com> 
<mailto:spencer.gra...@prodsyse.com <mailto:spencer.gra...@prodsyse.com>>>
Date: Tuesday, February 27, 2024 at 2:02 PM
To: r-sig-mac mailto:r-sig-mac@r-project.org> 
<mailto:r-sig-mac@r-project.org <mailto:r-sig-mac@r-project.org>>>
Subject: [R-SIG-Mac] pdflatex not found! Not building PDF manual.




Hello:


Running "devtools::check_win_devel()", I got, "pdflatex not found! 
Not building PDF manual." "sessionInfo()" below.


Suggestions?
Thanks,
Spencer Graves








sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Sonoma 14.3.1




Matrix products: default
BLAS: 
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
 




LAPACK: 
/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;
 
LAPACK version 3.11.0




locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8




time zone: America/Chicago
tzcode source: internal




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




loaded via a namespace (and not attached):
[1] miniUI_0.1.1.1 compiler_4.3.2 promises_1.2.1 Rcpp_1.0.12 




[5] stringr_1.5.1 callr_3.7.3 later_1.3.2 
fastmap_1.1.1
[9] mime_0.12 R6_2.5.1 curl_5.2.0 
htmlwidgets_1.6.4
[13] tibble_3.2.1 desc_1.4.3 profvis_0.3.8 shiny_1.8.0
[17] pillar_1.9.0 rlang_1.1.3 utf8_1.2.4 cachem_1.0.8
[21] stringi_1.8.3 httpuv_1.6.14 fs_1.6.3 pkgload_1.3.4
[25] memoise_2.0.1 cli_3.6.2 magrittr_2.0.3 ps_1.7.6
[29] processx_3.8.3 digest_0.6.34 rstudioapi_0.15.0 xtable_1.8-4
[33] remotes_2.4.2.1 devtools_2.4.5 lifecycle_1.0.4 vctrs_0.6.5
[37] glue_1.7.0 urlchecker_1.0.1 sessioninfo_1.2.2 pkgbuild_1.4.3
[41] fansi_1.0.6 purrr_1.0.2 pkgconfig_2.0.3 tools_4.3.2
[45] usethis_2.2.3 ellipsis_0.3.2 htmltools_0.5.7
>




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


___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org <mailto:R-SIG-Mac@r-project.org>
https://stat.ethz.ch/mailman/listinfo/r-sig-mac 
<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] pdflatex not found! Not building PDF manual.

[Marc Schwartz via R-SIG-Mac]

Dennis,

Do you have a TeX installation on your Mac?

pdflatex is typically installed with TeX, which for macOS is usually via MacTeX:

  https://tug.org/mactex/

Once you have that installed, you should be good to go, but if you are 
currently running an interactive R session, you will likely need to exit that, 
and then after installing MacTex, restart your R session.

You will also end up with a TeX folder in your Applications folder, where 
supporting apps will reside, including the TeX Live utility, which can be used 
to update the TeX installation periodically.

Regards,

Marc Schwartz


-Original Message-
From: R-SIG-Mac mailto:r-sig-mac-boun...@r-project.org>> on behalf of Spencer Graves 
mailto:spencer.gra...@prodsyse.com>>
Date: Tuesday, February 27, 2024 at 2:02 PM
To: r-sig-mac mailto:r-sig-mac@r-project.org>>
Subject: [R-SIG-Mac] pdflatex not found! Not building PDF manual.


Hello:

Running "devtools::check_win_devel()", I got, "pdflatex not found! 
Not building PDF manual." "sessionInfo()" below.

Suggestions?
Thanks,
Spencer Graves




sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Sonoma 14.3.1


Matrix products: default
BLAS: 
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
 


LAPACK: 
/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;
 
LAPACK version 3.11.0


locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8


time zone: America/Chicago
tzcode source: internal


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


loaded via a namespace (and not attached):
[1] miniUI_0.1.1.1 compiler_4.3.2 promises_1.2.1 Rcpp_1.0.12 


[5] stringr_1.5.1 callr_3.7.3 later_1.3.2 
fastmap_1.1.1
[9] mime_0.12 R6_2.5.1 curl_5.2.0 
htmlwidgets_1.6.4
[13] tibble_3.2.1 desc_1.4.3 profvis_0.3.8 shiny_1.8.0
[17] pillar_1.9.0 rlang_1.1.3 utf8_1.2.4 cachem_1.0.8
[21] stringi_1.8.3 httpuv_1.6.14 fs_1.6.3 pkgload_1.3.4
[25] memoise_2.0.1 cli_3.6.2 magrittr_2.0.3 ps_1.7.6
[29] processx_3.8.3 digest_0.6.34 rstudioapi_0.15.0 xtable_1.8-4
[33] remotes_2.4.2.1 devtools_2.4.5 lifecycle_1.0.4 vctrs_0.6.5
[37] glue_1.7.0 urlchecker_1.0.1 sessioninfo_1.2.2 pkgbuild_1.4.3
[41] fansi_1.0.6 purrr_1.0.2 pkgconfig_2.0.3 tools_4.3.2
[45] usethis_2.2.3 ellipsis_0.3.2 htmltools_0.5.7
>


___
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] Using Microsoft Access from a Macintosh using R

[Marc Schwartz via R-SIG-Mac]

Hi,

You have identified the key components that you will need, which are the RODBC 
package:

  https://cran.r-project.org/web/packages/RODBC/index.html

and the Actual Technologies ODBC driver pack for MS Access:

  https://www.actualtech.com/product_access.php

The latter has some basic installation instructions for that product on the 
above page, and Actual offers a limited function evaluation option, if you want 
to try before you buy. Actual also has their own tech support available. The 
key is using their tools to set up the correct DSN specification for the 
database that you want to retrieve data from within R.

I used to use the Actual ODBC driver pack for Oracle on my Mac, and it worked 
quite well, albeit, it has now been a few years since I needed that 
functionality.

For the RODBC package, it can be installed from within an R session using:

  install.packages("RODBC")

Note that Prof. Ripley has spent a significant amount of time over the years 
creating a vignette for the RODBC package:

  https://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf

in addition to the package manual, and I would urge you to review the vignette 
for helpful information.

That should get you started.

Note also that there is a specific e-mail list for R and databases:

  https://stat.ethz.ch/mailman/listinfo/r-sig-db

however the traffic on that list has been essentially non-existent for some 
time, and since this is a Mac specific issue, feel free to continue this 
thread, or post subsequent questions, here.

Regards,

Marc Schwartz



On April 26, 2023 at 6:50:10 AM, list_email--- via R-SIG-Mac 
(r-sig-mac@r-project.org (mailto:r-sig-mac@r-project.org)) wrote:

> How can I make a Mac get data from a Microsoft Access database using R?
>
> I’m sorry if this has been asked a million times before but the list archives 
> don’t seem to be searchable and the Mac FAQ doesn’t mention this.
>
> Also, I’m asking for a colleague who doesn’t like messing around with a lot 
> of technical computer stuff and I do not have R on my own system. So please 
> be patient.
>
> It seems that there is a package called RODBC which needs to be installed. Is 
> that done using R’s package manager?
>
> And it seems that there is a driver from Actual Technologies with a Mac 
> installer package.
>
> Assuming that these two steps are taken, is there anything else that needs to 
> be done? Can R then access the Access database directly or is there an 
> intermediate step such as an Excel file? Is there a very short MWE
> that demonstrates accessing a public Microsoft Access database using this 
> method?
>
> My colleague is thinking of buying a Windows system just to solve this 
> problem!
>
> Many thanks,
>
> Jerry
>
> ___
> 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] Ventura users: do not install R from the Downloads folder

[Marc Schwartz via R-SIG-Mac]

Simon, I am not sure that this is a bug, it is a security "feature". There is a macOS Ventura setting in:   System Settings -> Privacy & Security -> Files and Folders -> Installer -> Downloads Folder   If that is not enabled, then installation from the Downloads folder will fail. That may be the issue that Max is experiencing. Regards, Marc Schwartz    P.S. Re-sending this without the screen capture, as that made the e-mail too large for the list.On February 8, 2023 at 10:38:09 PM, Simon Urbanek (simon.urba...@r-project.org) wrote: Apparently there is a bug in Ventura that prevents software installation from the Downloads folder. Once the installer package is moved someplace else - the home or Desktop - it works. So if you see "Installation failed", make sure you move the package (typically that would be the R-4.2.2-arm64.pkg file) out of the Downloads folder. (Thanks to Max for sending the installer log so we could trace the cause!).

Cheers,
Simon

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


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

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

[Marc Schwartz via R-SIG-Mac]

Hi,

Just as an FYI, without getting too far OT, if you are not familiar with 
Electron (https://www.electronjs.org), beyond being "free", it is 
cross-platform (Windows, macOS, and Linux), which is why a notable number of 
application developers, including "for profit" ones, are shifting to it. You 
can get a sense for that here:

  https://www.electronjs.org/apps
   
That being said, as with most such things, there are pros and cons to using 
that framework, in the latter case, notably the material memory overhead and 
that you lose the OS specific UI/UX as apps take on a more generic web-like 
esthetic across each platform. Some have also raised security issues with the 
framework.

I don't use RStudio, but it sounds like there is bug with RStudio's new 
version, which should be reported to them. It looks like they are in the midst 
of some structural changes to their web site given the recent corporate change 
from RStudio to Posit, but here is a link to the current community support page:

  https://community.rstudio.com

Regards,

Marc Schwartz


On February 7, 2023 at 7:28:23 AM, Kevin Thorpe (kevin.tho...@utoronto.ca 
(mailto:kevin.tho...@utoronto.ca)) wrote:

> Thanks for that Ken.
>
> I downloaded the “non-Electron” version from the link you posted and PDFs now 
> open properly. Naturally, RStudio now wants to update but I assume an update 
> will fetch the broken Electron version.
>
> Thanks for all the help troubleshooting.
>
> Kevin
>
> --
> Kevin E. Thorpe
> Head of Biostatistics, Applied Health Research Centre (AHRC)
> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
> Assistant Professor, Dalla Lana School of Public Health
> University of Toronto
> email: kevin.tho...@utoronto.ca Tel: 416.864.5776 Fax: 416.864.3016
>
> > On Feb 7, 2023, at 2:45 AM, Ken Beath wrote:
> >
> > The problem seems to be with the Electron framework they switched to in the 
> > current version.
> >
> > From https://dailies.rstudio.com/version/2022.07.1+554.pro3/ the previous 
> > version works, but not the Electron version. For those that are interested 
> > Electron is a newer framework that has the advantage of being completely 
> > free, and is what is now used by RStudio rather than Qt.
> >
> > Ken
> >
> >> On 7 Feb 2023, at 2:49 pm, Kevin Thorpe wrote:
> >>
> >> Thanks Simon and Duncan.
> >>
> >> I found the same plugins and removed them. It works correctly in the R.app.
> >>
> >> RStudio still directs me to a browser window at the localhost address 
> >> 127.0.0.1 and nothing loads. I know RStudio is not R and this list is for 
> >> R so will probably have to search elsewhere for that solution unless 
> >> anyone here happens to have an idea.
> >>
> >> Kevin
> >>
> >> --
> >> Kevin E. Thorpe
> >> Head of Biostatistics, Applied Health Research Centre (AHRC)
> >> Li Ka Shing Knowledge Institute of St. Michael’s Hospital
> >> Assistant Professor, Dalla Lana School of Public Health
> >> University of Toronto
> >> email: kevin.tho...@utoronto.ca Tel: 416.864.5776 Fax: 416.864.3016
> >>
> >>> On Feb 6, 2023, at 7:53 PM, Duncan Murdoch wrote:
> >>>
> >>> That worked for me. I deleted two plugins from the global 
> >>> /Library/Internet\ Plug-Ins folder named
> >>>
> >>> AdobePDFViewer.plugin
> >>> AdobePDFViewerNPAPI.plugin
> >>>
> >>> and dated from 2020. Now things are fine.
> >>>
> >>> Duncan Murdoch
> >>>
> >>> On 06/02/2023 7:36 p.m., Simon Urbanek wrote:
>  Kevin,
>  oh, that's something entirely different - what I was talking about was 
>  if you use
>  vignette("survival")
>  in R it opens a Preview with the vignette.
>  What you describe seems like a browser plugin issue, because the help 
>  system is just an html page (assuming you are talking about the html 
>  help system). So it seems that you may have installed some Adobe browser 
>  plugin that doesn't work anymore. The plugins live in 
>  ~/Library/Internet\ Plug-Ins/ (user) and /Library/Internet\ Plug-Ins/ 
>  (global), so you should remove it from there.
>  Cheers,
>  Simon
> > On 7/02/2023, at 12:01 PM, Kevin Thorpe wrote:
> >
> > When I try to open a PDF vignette (say a vignette from the survival 
> > package)from the help system in R it does not open Preview. I cannot 
> > actually open any PDF vignettes. All I get is a finder window with the 
> > error I previously described. It asks me to select an appropriate 
> > viewer. Selecting Preview opens nothing and more errors are thrown to 
> > the Console. I could send you and Duncan screenshots off-list, since I 
> > know that theses lists are picky about attachments.
> >
> > The steps I take are:
> >
> > 1. Open the R app.
> > 2. Start the Help system.
> > 3. Navigate to the survival package vignettes.
> > 4. Click the PDF link for the The survival package
> >
> > Then the errors happen.
> >
> > I will send a screenshot of the result off list.
> >
> 

Re: [R-SIG-Mac] [External] macOS Ventura (13) Preview App Drops Support for PS/EPS File Rendering

[Marc Schwartz via R-SIG-Mac]

Hi Rich,

macOS includes pstopdf (/usr/bin/pstopdf) as a local, albeit dated, distiller. 

ps2pdf (/usr/local/bin/ps2pdf) is installed with the macTeX distribution with 
Ghostscript, and I use that as a last step in a shell script to process the 
.tex files via latex and dvips, when using Sweave, since the use of PS based 
components like pstricks precludes directly going to pdf with pdflatex.

The advantage of Preview was that it was a quick way to view a PS/EPS file, 
since you could just click on the file in Finder and hit the space bar to do a 
quick visual file view, or also fully open the file and render it as well, if 
preferred. I would use the former frequently, especially if I had several 
PS/EPS files in a folder and quickly wanted to confirm which one had the 
content that I was looking for. That applied whether the PS/EPS file was 
generated via Sweave or directly using postscript() in an R session.

As noted below, there are multiple alternative options, some "free", some not, 
and it may come down to specific workflow issues as to which approach may be 
better suited for useRs that need this capability.

Thanks!

Marc


On October 26, 2022 at 10:31:29 AM, Richard M. Heiberger (r...@temple.edu) 
wrote:
> Have you considered ps2pdf?
>  
> > On Oct 26, 2022, at 10:11, Marc Schwartz via R-SIG-Mac  
> wrote:
> >
> > Hi Prof. Ripley,
> >
> > Thanks for your reply. Responses inline below.
> >
> > On October 25, 2022 at 11:11:43 PM, Prof Brian Ripley 
> > (rip...@stats.ox.ac.uk) wrote:  
> >> Somehow you sent HTML only, and that renders oddly in Thunderbird.
> >
> > My apologies on that.
> >
> > That is curious and I now see that in looking at the raw message content. I 
> > am not sure how  
> that occurred, as I had set the e-mail to plain text when composing, so 
> somehow that changed  
> at some point. What is even more confusing, is that by default, had the 
> e-mail been initially  
> composed as HTML/RTF, it would normally be sent as multipart MIME, which does 
> not appear  
> to have been the case here, leaving me even more confused.
> >
> > I am sending this now as plain text, so hopefully that is what is sent. I 
> > will keep track  
> and if that is not the case, report a bug.
> >
> >> Have you considered GhostScript? That used to be my viewer of choice
> >> for Postscript long ago. I think TeXShop may be a wrapper.
> >
> > Yes, TeXShop is a GUI front-end previewer as you note below, included in 
> > the macTeX distribution,  
> using underlying functionality. Ghostscript 9.55 is also installed as part of 
> macTeX,  
> which I have installed as I still heavily use Sweave to generate PDF reports 
> for clients,  
> some of which use pstricks to generate flow chart figures. Thus, the included 
> figure  
> content is generated as PDF and PS/EPS files, which I sometimes quickly 
> preview, until  
> now, using macOS Preview.
> >
> > There is some coverage now of this change in Preview in various Mac fora, 
> > with some hypothesizing  
> that this change in Preview may be security related, pointing to a change by 
> Microsoft  
> in Office back in 2017/2018:
> >
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.microsoft.com%2Fen-us%2Foffice%2Fsupport-for-eps-images-has-been-turned-off-in-office-a069d664-4bcf-415e-a1b5-cbb0c334a840=05%7C01%7Crmh%40temple.edu%7C78ef812c421947a3942608dab75c0425%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C638023903602892347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=TbOX5KoROWOLe%2BTAx3EN0rSDVwIp%2BbRwaQDhqSBJIz0%3D=0
> >   
> >
> > Of course, nothing official from Apple that I have seen.
> >
> >> My box has Photoshop as the default viewer for .eps and TeXShop for .ps.
> >> I almost never use Photoshop: it comes as part of Adobe's
> >> Photographers Bundle.
> >
> > I also have the full Adobe Acrobat application installed, as I have other 
> > functionality  
> provided by that app that I need, so pay for that as a business expense.
> >
> > It is interesting that now that I am trying to open some PS/EPS files with 
> > apps other than  
> Preview, if I use TeXShop, the file opens right away, whereas if I use 
> Acrobat, I get a security  
> pop-up asking me if I trust the source that generated the file, which in this 
> case, is me.  
> Perhaps Apple could take a similar approach with Preview, if security was the 
> motivation  
> for this change, and they elect to revert it.
> >
> > This was more of a heads up for folks, who like me, have been dependent 
> > upon using Preview  
>

Re: [R-SIG-Mac] macOS Ventura (13) Preview App Drops Support for PS/EPS File Rendering

[Marc Schwartz via R-SIG-Mac]

Hi Prof. Ripley,

Thanks for your reply. Responses inline below.

On October 25, 2022 at 11:11:43 PM, Prof Brian Ripley (rip...@stats.ox.ac.uk) 
wrote:
> Somehow you sent HTML only, and that renders oddly in Thunderbird.

My apologies on that. 

That is curious and I now see that in looking at the raw message content. I am 
not sure how that occurred, as I had set the e-mail to plain text when 
composing, so somehow that changed at some point. What is even more confusing, 
is that by default, had the e-mail been initially composed as HTML/RTF, it 
would normally be sent as multipart MIME, which does not appear to have been 
the case here, leaving me even more confused.

I am sending this now as plain text, so hopefully that is what is sent. I will 
keep track and if that is not the case, report a bug.

> Have you considered GhostScript? That used to be my viewer of choice
> for Postscript long ago. I think TeXShop may be a wrapper.

Yes, TeXShop is a GUI front-end previewer as you note below, included in the 
macTeX distribution, using underlying functionality. Ghostscript 9.55 is also 
installed as part of macTeX, which I have installed as I still heavily use 
Sweave to generate PDF reports for clients, some of which use ps-tricks to 
generate flow chart figures. Thus, the included figure content is generated as 
PDF and PS/EPS files, which I sometimes quickly preview, until now, using macOS 
Preview.

There is some coverage now of this change in Preview in various Mac fora, with 
some hypothesizing that this change in Preview may be security related, 
pointing to a change by Microsoft in Office back in 2017/2018:

  
https://support.microsoft.com/en-us/office/support-for-eps-images-has-been-turned-off-in-office-a069d664-4bcf-415e-a1b5-cbb0c334a840

Of course, nothing official from Apple that I have seen.

> My box has Photoshop as the default viewer for .eps and TeXShop for .ps.
> I almost never use Photoshop: it comes as part of Adobe's
> Photographers Bundle.

I also have the full Adobe Acrobat application installed, as I have other 
functionality provided by that app that I need, so pay for that as a business 
expense.

It is interesting that now that I am trying to open some PS/EPS files with apps 
other than Preview, if I use TeXShop, the file opens right away, whereas if I 
use Acrobat, I get a security pop-up asking me if I trust the source that 
generated the file, which in this case, is me. Perhaps Apple could take a 
similar approach with Preview, if security was the motivation for this change, 
and they elect to revert it.

This was more of a heads up for folks, who like me, have been dependent upon 
using Preview for a quick look at these files, which are commonly generated 
using R.

Thanks and regards,

Marc


> Brian
>  
> On 26/10/2022 01:06, Marc Schwartz via R-SIG-Mac wrote:
> > Hi All,
> >
> > Having updated to macOS Ventura, I just became aware that Ventura's
> > Preview app has dropped support for rendering PS and EPS files after all
> > these years.
> >
> > Not clear on the rationale for this change, but there is an Apple
> > Support article here on this:
> >
> > https://support.apple.com/en-us/HT213250
> >
> > Apparently, one can still print these files by dragging and dropping
> > them on to the printer queue, but you will need to find a different
> > application, such as the TeXShop app, which is bundled in macTeX for
> > free, or another option is the full Adobe Acrobat Pro application, if
> > you have and pay for that.
> >
> > If you are so inclined, you can provide product feedback to Apple here:
> >
> > https://www.apple.com/feedback/macos.html
> >
> > Regards,
> >
> > Marc Schwartz
> >
> >
> > ___
> > 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

[R-SIG-Mac] macOS Ventura (13) Preview App Drops Support for PS/EPS File Rendering

[Marc Schwartz via R-SIG-Mac]

Hi All,Having updated to macOS Ventura, I just became aware that Ventura's Preview app has dropped support for rendering PS and EPS files after all these years.Not clear on the rationale for this change, but there is an Apple Support article here on this:  https://support.apple.com/en-us/HT213250Apparently, one can still print these files by dragging and dropping them on to the printer queue, but you will need to find a different application, such as the TeXShop app, which is bundled in macTeX for free, or another option is the full Adobe Acrobat Pro application, if you have and pay for that.If you are so inclined, you can provide product feedback to Apple here:  https://www.apple.com/feedback/macos.htmlRegards,Marc Schwartz

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

Re: [R-SIG-Mac] CRAN Checks for R-Release appear to use R-Devel

[Marc Schwartz via R-SIG-Mac]

Simon,

Thanks!

Marc


Simon Urbanek wrote on 5/25/21 4:47 PM:

Marc,

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

Thanks,
Simon



On May 26, 2021, at 8:35 AM, Marc Schwartz  wrote:

Hi,

This is in reply to Simon's request that I post on this topic separately from 
Hans' prior thread on rlang related problems.

In the course of looking at a few CRAN packages for that thread, including my own, I 
noted on the CRAN checks page for each package, that the results logs indicate the use of 
"R Under development", rather than the current R release version.

Specific example:

The CRAN check page for rlang:

https://cran.r-project.org/web/checks/check_results_rlang.html

shows in row 10:

r-release-macos-x86_64  OK

If I click on OK to get the CRAN check log with the following URL:

https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/rlang-00check.html

noting that the above URL shows:

.../r-release-macos-x86_64/...

However, the log header shows:

"using R Under development (unstable) (2021-02-19 r80028)"

Thus, if I read correctly, while the link should be for the CRAN check results 
log for the package using R release (4.1.0), it appears to be using an R 
development version from February 19, 2021.

If I check the same R Release logs for Linux and Windows for rlang:

https://www.r-project.org/nosvn/R.check/r-release-linux-x86_64/rlang-00check.html

and:

https://www.r-project.org/nosvn/R.check/r-release-windows-ix86+x86_64/rlang-00check.html

respectively, both indicate:

using R version 4.1.0 (2021-05-18)

in the log headers.

If I check the rlang logs for other OSs on "r-devel", they indicate:

"using R Under development (unstable) (2021-05-20 r80347)"

Thus, a more recent development version of R from May 20, 2021.

So, perhaps naively, I would presume a configuration issue for the macOS 
binaries on CRAN.

Simon, does that clarify the point I was making in the prior thread?

Thanks,

Marc



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

[R-SIG-Mac] CRAN Checks for R-Release appear to use R-Devel

[Marc Schwartz via R-SIG-Mac]

Hi,

This is in reply to Simon's request that I post on this topic separately 
from Hans' prior thread on rlang related problems.


In the course of looking at a few CRAN packages for that thread, 
including my own, I noted on the CRAN checks page for each package, that 
the results logs indicate the use of "R Under development", rather than 
the current R release version.


Specific example:

The CRAN check page for rlang:

https://cran.r-project.org/web/checks/check_results_rlang.html

shows in row 10:

r-release-macos-x86_64  OK

If I click on OK to get the CRAN check log with the following URL:

https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/rlang-00check.html

noting that the above URL shows:

.../r-release-macos-x86_64/...

However, the log header shows:

"using R Under development (unstable) (2021-02-19 r80028)"

Thus, if I read correctly, while the link should be for the CRAN check 
results log for the package using R release (4.1.0), it appears to be 
using an R development version from February 19, 2021.


If I check the same R Release logs for Linux and Windows for rlang:

https://www.r-project.org/nosvn/R.check/r-release-linux-x86_64/rlang-00check.html

and:

https://www.r-project.org/nosvn/R.check/r-release-windows-ix86+x86_64/rlang-00check.html

respectively, both indicate:

using R version 4.1.0 (2021-05-18)

in the log headers.

If I check the rlang logs for other OSs on "r-devel", they indicate:

"using R Under development (unstable) (2021-05-20 r80347)"

Thus, a more recent development version of R from May 20, 2021.

So, perhaps naively, I would presume a configuration issue for the macOS 
binaries on CRAN.


Simon, does that clarify the point I was making in the prior thread?

Thanks,

Marc

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

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

[Marc Schwartz via R-SIG-Mac]

Hi,

You might try a different CRAN mirror to see if perhaps the rlang binary 
that you are getting is corrupted.


Looking at CRAN for the package, the results for rlang on what is 
supposed to be R release on macOS:


  https://cran.r-project.org/web/checks/check_results_rlang.html

shows a header indicating that R devel is being used, not R release:


https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/rlang-00check.html

So, I am not clear if there is a macOS binary build issue that may be 
resulting in a conflict of sorts.


A spot check of other CRAN packages (including my own) shows the same 
use of R devel for macOS, and not R release, so perhaps there is a wider 
issue going on with CRAN builds, unless I am missing something here.


Simon (cc'd now) may be able to address that issue.

Regards,

Marc Schwartz


Hans W wrote on 5/25/21 9:16 AM:

I installed the new R version 4.1.0 on my (normal) Macbook, and
everything seemed to work fine until one of the packages depended on
the 'rlang' package and I got the following error:

 > library(rlang)
 Error: package or namespace load failed for ‘rlang’ in
 dyn.load(file, DLLpath = DLLpath, ...): unable to load
 shared object '/Users/hwb/Library/R/4.0/library/rlang/libs/rlang.so':
 dlopen(/Users/hwb/Library/R/4.0/library/rlang/libs/rlang.so, 6):
 Library not loaded:
 /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libR.dylib
 Referenced from: /Users/hwb/Library/R/4.0/library/rlang/libs/rlang.so
 Reason: image not found

So I removed 'rlang' and reinstalled it. There was no error message,
but when I tried to load it, the error message was:

 Error: package or namespace load failed for ‘rlang’ in
 get(Info[i, 1], envir = env): lazy-load database
 '/Users/hwb/Library/R/4.0/library/rlang/R/rlang.rdb' is corrupt
 In addition: Warning message:
 In get(Info[i, 1], envir = env) : internal error -3 in R_decompress1

One of my current applications relies on 'rvest' which depends on
'rlang'. For the moment I am using it from a Linux computer, but it's
quite unfortunate that I cannot run it from macOS as well.

I also uninstalled the new R version and reinstalled it, but nothing
changed. Could you give me a hint on what to do (or what I did wrong)?

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



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

Re: [R-SIG-Mac] Apple Silicon aka M1 Macs

[Marc Schwartz via R-SIG-Mac]

Prof. Ripley,

Thanks for these updates and for the efforts by all involved in this process.

I am holding off on moving to the M1 based Macs until next year, as besides 
waiting for a larger display variant, as I am also waiting on updates to other 
applications that will support that hardware in time.

You reference XQuartz below, and unless I am mis-reading the tea leaves, there 
seems to be an indication in their list archives that there is no plan to 
update their binary release to support the new hardware. That release has not 
been updated since 2016.

They seem to be suggesting a dependence upon MacPorts moving forward, possibly 
HomeBrew, for installing a native XQuartz on the new hardware. Either scenario 
introduces other issues idiosyncratic to those environments.

Not sure if that influences any decisions here, and presume that you may 
already be aware of those dynamics.

Regards,

Marc Schwartz


> On Nov 17, 2020, at 9:57 AM, Prof Brian Ripley  wrote:
> 
> Mine (a 8GB MBA) arrived today, so I have started doing some comparisons.
> 
> For the CRAN build of R 4.0.3, §2.8 of R-admin recommends checking the 
> installation with
> 
> pdf("tests.pdf") ## optional, but prevents flashing graphics windows
> Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
> tools::testInstalledBasic("both")
> tools::testInstalledPackages(scope = "base")
> tools::testInstalledPackages(scope = "recommended")
> 
> That took 454s (using Rosetta) against 895s for my late-2016 MBP (2.9GHz i5): 
> happily nothing untoward was reported (some recommended packages give 
> differences from reference output on both systems).
> 
> You need to install XQuartz to provide the X11() devices and support for 
> package Tcl/Tk: everything I tried using that worked as expected.
> 
> Having done that post-installation check I would happily use the Intel R on 
> an M1 machine.
> 
> We plan to check many of the Intel-compiled packages under Rosetta.
> 
> There are many hours of work ahead to build/test a native toolchain: our goal 
> is to have a native distribution for R 4.1.0 ca April 2021.
> 
> -- 
> 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] Re: crash due to rgl and base graphics conflict

[Marc Schwartz via R-SIG-Mac]

Hi,

Just installed rgl and I get the same crash and error message from the original 
post below, running R from the CLI.

If I run R from within ESS (what I normally use), I get:

  Process R abort trap: 6 at Mon Aug  3 09:15:32 2020

If I run R from R.app (the default macOS GUI), the command runs fine and I get 
the graphic.

I am running R 4.0.2 (2020-06-22) on macOS 10.15.6.

R was cleanly installed, and XQuartz (2.7.11) was updated afterwards.

Regards,

Marc Schwartz


> On Aug 3, 2020, at 9:05 AM, Duncan Murdoch  wrote:
> 
> I just got a message from someone else using Catalina 10.15.5 who still gets 
> a crash from
> 
> library(rgl)
> plot(1:10)
> 
> I don't have Catalina, and haven't seen it.  Has anyone else?
> 
> Duncan Murdoch
> 
> On 31/05/2020 4:44 p.m., Richard M. Heiberger wrote:
>> I upgraded last night to Catalina 10.15.5 (19F96).
>> The crash has gone away and that example now works normally.
>> On Fri, May 29, 2020 at 3:25 PM Richard M. Heiberger  wrote:
>>> 
>>> my 12:35 email and the attached tmp.txt are from the Terminal.app,
>>> No emacs/ESS involved.
>>> 
>>> On Fri, May 29, 2020 at 3:13 PM Duncan Murdoch  
>>> wrote:
 
 On 29/05/2020 2:21 p.m., Richard M. Heiberger wrote:
> 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.
 
 Generally speaking rgl doesn't want to be reloaded in the same R
 session:  detaching it doesn't clean up everything.  That's not
 something that I'd put any priority on fixing, whereas I would look at
 the problems you're having on startup if I could reproduce them.
 
 I wonder if ESS is involved somehow:  your sessionInfo listed ESSR on
 the search list.  Do you have the same issues with plain R from the
 console, or R.app?
 
> Is there an rgl equivalent for dev.cur()?
 
 There's rgl.cur().  rgl only supports two kinds of devices:  on a Mac or
 Linux they'd be displayed as glX or null.  Windows also supports the
 null device (which doesn't display anything), and a different one to
 display within R:  I forget how the name is displayed.
 
 It might be that you'll need to set options(rgl.useNULL) before starting
 rgl, and only use the null device.  It won't display anything in R, but
 allows you to call rglwidget() for a display in a browser.
 
 Duncan Murdoch
 
> 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)(),
  
 

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

[Marc Schwartz via R-SIG-Mac]

Hi,

I will stand to be corrected, but from what I can tell, 'realpath' is not part 
of a default macOS installation, and would need to be installed from a third 
party repo (e.g. homebrew). 

There appear to be shell script incantations that would accomplish the same 
functionality, but in the end, in the absence of these approaches, there is not 
an easy way, under a standard macOS install, to trace through the layers of 
symlinks to the target file.

You can also do this manually via the Finder, by right clicking on the symlink 
and using Show Original to navigate as well.

Also, note that under Catalina, the default shell changed from bash to zsh.

Regards,

Marc


> On May 13, 2020, at 9:00 AM, Dr Eberhard W Lisse  wrote:
> 
> Marc,
> 
> this is not necessarily correct, it can be a symlink, hence my suggestion of
> 
>   realpath $(which pdflatex)
> 
> which will give you the final executable, in my case
> 
>   /usr/local/texlive/2020basic/bin/x86_64-darwin/pdftex
> 
> But, I agree, this looks like an ancient installation :-0-O
> 
> 
> el
> 
> 
> On 13/05/2020 14:16, Marc Schwartz via R-SIG-Mac wrote:
>> Spencer,
>> 
>> FWIW, this may be a situation where you need to remove your
>> current/older installations of TeXLive and start fresh with a clean
>> install of TeXLive 2020.  It is possible that there is some conflict
>> or corruption of the current multiple installations.
>> 
>> That 'which pdflatex' is pointing directly to an executable in
>> /usr/local/bin, rather than to a symlink in the TeXLive tree, suggests
>> that there is something amiss with your installation.
>> 
>> There are two primary folder trees that would need to be removed:
>> 
>>  /Library/TeX
>> 
>> and 
>> 
>>  /usr/local/texlive
>> 
>> The former path will show in Finder, but the latter will not, unless
>> you have hidden folders set to show.  If not, then you can use the
>> Finder menu option:
>> 
>>  Go -> Go to Folder
>> 
>> and enter:
>> 
>>  /usr/local
>> 
>> That will then show you the texlive folder, which you can then right
>> click on and delete.
>> 
>> Both folder trees will require your Admin password to delete.
>> 
>> Once you do this, if you elect to do so, you will then need to
>> re-install TeXLive 2020 and hopefully start fresh.
>> 
>> Regards,
>> 
>> Marc Schwartz
> 
> ___
> 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] obsolete LaTeX software in "R CMD check" on Mac?

[Marc Schwartz via R-SIG-Mac]

Spencer,

FWIW, this may be a situation where you need to remove your current/older 
installations of TeXLive and start fresh with a clean install of TeXLive 2020. 
It is possible that there is some conflict or corruption of the current 
multiple installations.

That 'which pdflatex' is pointing directly to an executable in /usr/local/bin, 
rather than to a symlink in the TeXLive tree, suggests that there is something 
amiss with your installation.

There are two primary folder trees that would need to be removed:

  /Library/TeX

and 

  /usr/local/texlive

The former path will show in Finder, but the latter will not, unless you have 
hidden folders set to show. If not, then you can use the Finder menu option:

  Go -> Go to Folder

and enter:

  /usr/local

That will then show you the texlive folder, which you can then right click on 
and delete.

Both folder trees will require your Admin password to delete.

Once you do this, if you elect to do so, you will then need to re-install 
TeXLive 2020 and hopefully start fresh.

Regards,

Marc Schwartz


> On May 13, 2020, at 7:00 AM, Spencer Graves  
> wrote:
> 
> Hi, Peter et al.:
> 
> 
>   It looks like you've properly diagnosed my problem.  How do I fix it?
> 
> 
>   "which pdflatex" and "echo $PATH" are as follows:
> 
> 
> $ which pdflatex
> /usr/local/bin/pdflatex
> 
> 
> $ echo $PATH
> /Library/Frameworks/Python.framework/Versions/3.7/bin:/Users/sbgraves/anaconda3/bin:/Library/Frameworks/Python.framework/Versions/3.7/bin:/opt/local/bin:/opt/local/sbin:/Users/sbgraves/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin
> 
> 
>   I do find "/Library/TeX/texbin/pdflatex" on my hard drive, but "which 
> pdflatex" doesn't find it.
> 
> 
>   Thanks,
>   Spencer Graves
> 
> 
> On 2020-05-13 01:31, peter dalgaard wrote:
>> You typically need to ensure that you have the right TeX installation in 
>> your PATH (and not an older one earlier in the path). You should see 
>> something like this
>> 
>> Peters-MacBook-Air:BUILD pd$ which pdflatex
>> /Library/TeX/texbin/pdflatex
>> Peters-MacBook-Air:BUILD pd$ pdflatex -version
>> pdfTeX 3.14159265-2.6-1.40.20 (TeX Live 2019)
>> kpathsea version 6.3.1
>> 
>> Peters-MacBook-Air:BUILD pd$ echo $PATH
>> /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/gfortran/bin:/usr/local/clang8/bin:/Library/TeX/texbin:/opt/X11/bin
>> 
>> (Notice that if I had older TeX stuff in /usr/local, I could be in similar 
>> trouble...)
>> 
>> -pd
>> 
>> 
>>> On 13 May 2020, at 06:15 , Spencer Graves  
>>> wrote:
>>> 
>>> Hi, Ken et al.:
>>> 
>>> 
>>>   Thanks for the info.  I tried to do what you suggested but still have 
>>> the problem.
>>> 
>>> 
>>>   Specifically, a web search for TexLive 2020 led me to 
>>> "https://tug.org/texlive/;.  That invited me to download and install MacTex 
>>> 2020 from "https://tug.org/mactex/mactex-download.html;, which I did.   
>>> Everything seemed to go smoothly, but when I ran "R CMD build Ecfun" and "R 
>>> CMD check Ecfun_0.2-4.tar.gz", I got the same error.  This is running those 
>>> commands in a Terminal.  When I invoked "r" there just now and requested 
>>> "sessionInfo()", I got the following:
>>> 
>>> 
>>> R version 4.0.0 (2020-04-24)
>>> Platform: x86_64-apple-darwin17.0 (64-bit)
>>> Running under: macOS Catalina 10.15.4
>>> 
>>> Matrix products: default
>>> BLAS: 
>>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
>>> LAPACK: 
>>> /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
>>> 
>>> locale:
>>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods base
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] compiler_4.0.0
>>> 
>>> 
>>>   Might you have other suggestions?
>>> 
>>> 
>>>   Thanks very much for eliminating one possible source of this problem.
>>> 
>>> 
>>>   Spencer Graves
>>> 
>>> 
>>> On 2020-05-12 20:12, Ken Beath wrote:
 Your package passes checks on my machine perfectly. It has R 4.0.0 with 
 RStudio and TexLive 2020 with updates to a week or two ago.
 
 Ken
 
> On 13 May 2020, at 8:17 am, Spencer Graves  
> wrote:
> 
> Hello, All:
> 
> 
>   Might "R CMD check" on Mac use obsolete LaTeX software?
> 
> 
>   I ask, because "R CMD check" on my Mac started reporting LaTeX
> errors on *.Rd files that previously passed "R CMD check" without
> problems.  Dirk Eddelbuettel recommended I ask tex.stackexchange about
> that.  I did that and got the following:
> 
> 
> * "In a current tex system \textasciigrave should work with
> your families - they don't have the glyph but latex will fall back
> without error. In older systems it could give an 

Re: [R-SIG-Mac] MacTeX 2020 and TeX Live Utility (No Longer Included)

[Marc Schwartz via R-SIG-Mac]

Rainer,

Are you running on Catalina?

I am not using homebrew, but if you are running on Catalina, then the homebrew 
folks would have had to address the notarization issue in their packaging 
independently.

Regards,

Marc


> On Apr 28, 2020, at 4:43 AM, Rainer M Krug  wrote:
> 
> I just checked - I still have them. I updated (using hombrew cask) to the new 
> version of MacTeX, ant all programs are still there. And TLU still works.
> 
> Rainer
> 
> 
>> On 27 Apr 2020, at 17:44, Marc Schwartz via R-SIG-Mac 
>> mailto:r-sig-mac@r-project.org>> wrote:
>> 
>> Thanks for the heads up on that. 
>> 
>> I confirmed that tlcockpit is included in the MacTeX 2020 distribution in 
>> /Library/TeX/texbin, as a symlink to the target shell script, and it is 
>> actively maintained.
>> 
>> Surprising that the missing apps PDF file did not mention that as an 
>> alternative GUI based manager that is immediately useable. 
>> 
>> Regards,
>> 
>> Marc
>> 
>> 
>>> On Apr 27, 2020, at 10:27 AM, Dr Eberhard W Lisse >> <mailto:e...@lisse.na>> wrote:
>>> 
>>> There is also the tlcockpit Java app on CTAN.
>>> 
>>> el
>>> 
>>> On 27/04/2020 16:07, Marc Schwartz via R-SIG-Mac wrote:
>>> [...]
>>>> One major change this year, as a result of Apple's requirement to now
>>>> use app notarization on Catalina, is that the TeX Live Utility (TLU),
>>>> as a GUI interface for updating the TeX distribution contents, is no
>>>> longer included in the MacTeX distribution.
>>> [...]
>>> 
>>> 
>>> -- 
>>> Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
>>> e...@lisse.na <mailto:e...@lisse.na> / *  |  Telephone: 
>>> +264 81 124 6733 (cell)
>>> PO Box 8421 Bachbrecht  \  /  If this email is signed with GPG/PGP
>>> 10007, Namibia   ;/ Sect 20 of Act No. 4 of 2019 may apply
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org <mailto:R-SIG-Mac@r-project.org>
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
> UCT), Dipl. Phys. (Germany)
> 
> Orcid ID: -0002-7490-0066
> 
> Department of Evolutionary Biology and Environmental Studies
> University of Zürich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Zürich
> Switzerland
> 
> Office:   +41 (0)44 635 47 64
> Cell: +41 (0)78 630 66 57
> email:      rainer.k...@uzh.ch <mailto:rainer.k...@uzh.ch>
>   rai...@krugs.de <mailto:rai...@krugs.de>
> Skype: RMkrug
> 
> PGP: 0x0F52F982
> 
> 
> 


[[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] MacTeX 2020 and TeX Live Utility (No Longer Included)

[Marc Schwartz via R-SIG-Mac]

Thanks for the heads up on that. 

I confirmed that tlcockpit is included in the MacTeX 2020 distribution in 
/Library/TeX/texbin, as a symlink to the target shell script, and it is 
actively maintained.

Surprising that the missing apps PDF file did not mention that as an 
alternative GUI based manager that is immediately useable. 

Regards,

Marc


> On Apr 27, 2020, at 10:27 AM, Dr Eberhard W Lisse  wrote:
> 
> There is also the tlcockpit Java app on CTAN.
> 
> el
> 
> On 27/04/2020 16:07, Marc Schwartz via R-SIG-Mac wrote:
> [...]
>> One major change this year, as a result of Apple's requirement to now
>> use app notarization on Catalina, is that the TeX Live Utility (TLU),
>> as a GUI interface for updating the TeX distribution contents, is no
>> longer included in the MacTeX distribution.
> [...]
> 
> 
> -- 
> Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
> e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
> PO Box 8421 Bachbrecht  \  /  If this email is signed with GPG/PGP
> 10007, Namibia   ;/ Sect 20 of Act No. 4 of 2019 may apply

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

Re: [R-SIG-Mac] random message on opening R-app

[Marc Schwartz via R-SIG-Mac]

> On Jan 12, 2020, at 7:51 AM, Federico Calboli  
> wrote:
> 
> Hi All,
> 
> just to check whether I am the only one (or one of the lucky few) who 
> randomly get the message (I posted it before but we did not seem to find a 
> solution then):
> 
> 2020-01-12 14:45:19.462 R[4163:3012268] Failed to connect (separatorView) 
> outlet from (NSView) to (NSTitlebarSeparatorView): missing setter or instance 
> variable
> 
> on opening R-app.
> 
> sessionInfo()
> R version 3.6.2 (2019-12-12)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS Mojave 10.14.6
> 
> Matrix products: default
> BLAS:   
> /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
> 
> loaded via a namespace (and not attached):
> [1] compiler_3.6.2
> 
> 
> It is harmless but offends my retentive nature — is there a permanent fix?
> 
> Cheers
> 
> F


Hi,

Based upon a reply by Simon to your query last April:

  https://stat.ethz.ch/pipermail/r-sig-mac/2019-April/012972.html

while I do not have a definite response, you might try the following:

1. Check your ~/.Rprofile to see what if any settings or packages are defined 
at startup. You might rename the file to something else so that it does not get 
used, and see if the message persists. If not, then there may be something in 
that file that you may need to identify through trial and error.

2. Re-install XQuartz, which should done after each R update, to see if there 
is something related to that.

3. You might consider fully deleting R, all installed packages and R.app, and 
doing a clean install. The issue you had last April was with 3.6.0, so it is 
possible that something was corrupted and persists with 3.6.2. A prior post 
from you in March of last year with the same issue was with 3.5.3, so whatever 
was happening goes back a bit.


Not sure if that will get you anywhere, or are perhaps things that you have 
already tried, but some initial thoughts.

Regards,

Marc Schwartz

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

Re: [R-SIG-Mac] R-patched installers cannot be run on Catalina

[Marc Schwartz via R-SIG-Mac]

Simon,

Thanks for the clarification.

Regards,

Marc


> On Oct 11, 2019, at 4:55 PM, Simon Urbanek  
> wrote:
> 
> The issue is not the process, the issue is that Apple requires particular way 
> to build the binaries with particular tools in order to even be able to pass 
> the notarization process and our current build does not use those. We can't 
> change the tools in the middle of the release so for R 3.6.x we're stuck with 
> what we are currently using which Apple doesn't accept. Hence the only hope 
> is for R 4.0.0 and we're working on that.
> 
> Cheers,
> Simon
> 
> 
> 
>> On Oct 11, 2019, at 4:39 PM, Marc Schwartz via R-SIG-Mac 
>>  wrote:
>> 
>> Hi,
>> 
>> I am going to presume that Simon is already aware of this, but there is a 
>> page on the Apple Dev site that describes the workflow that can be 
>> implemented/customized to automate the notarization process via scripting:
>> 
>> https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow
>> 
>> Whether this can be done efficiently to support the nightly builds via the 
>> current build system would be the question.
>> 
>> Also, with nightly builds, there is a risk of the notarization process 
>> introducing delays, as just happened:
>> 
>> https://www.macrumors.com/2019/10/10/apple-macos-catalina-app-notarization-slow/
>> 
>> Regards,
>> 
>> Marc Schwartz
>> 
>> 
>>> On Oct 11, 2019, at 4:25 PM, Dr Eberhard W Lisse  wrote:
>>> 
>>> You could always issue
>>> 
>>> sudo spctl --master-disable
>>> 
>>> :-)-O
>>> 
>>> el
>>> 
>>> On 2019-10-11 19:59 , Kevin Ushey wrote:
>>>> Hi,
>>>> 
>>>> I'm seeing the following when I attempt to install R-patched, as from
>>>> http://mac.r-project.org/:
>>>> 
>>>> ---
>>>> 
>>>> “R-3.6-branch-el-capitan-signed.pkg” can’t be opened because Apple
>>>> cannot check it for malicious software.
>>>> 
>>>> This software needs to be updated. Contact the developer for more 
>>>> information.
>>>> 
>>>> ---
>>>> 
>>>> I suspect this is pain being imposed by the requirement for notarized
>>>> applications / installers. The dialog can be overridden through the
>>>> Security & Privacy preferences pane, but Apple does not make this
>>>> obvious.
>>>> 
>>>> The official R 3.6.1 installer is not affected; likely because it was
>>>> grandfathered in due to its being published before Catalina was rolled
>>>> out.
>>>> 
>>>> Are there plans to notarize these builds of R? (can we be helpful in
>>>> making that happen?)
>>>> 
>>>> Best,
>>>> Kevin
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 

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

Re: [R-SIG-Mac] R-patched installers cannot be run on Catalina

[Marc Schwartz via R-SIG-Mac]

Hi,

I am going to presume that Simon is already aware of this, but there is a page 
on the Apple Dev site that describes the workflow that can be 
implemented/customized to automate the notarization process via scripting:

  
https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow

Whether this can be done efficiently to support the nightly builds via the 
current build system would be the question.

Also, with nightly builds, there is a risk of the notarization process 
introducing delays, as just happened:

  
https://www.macrumors.com/2019/10/10/apple-macos-catalina-app-notarization-slow/

Regards,

Marc Schwartz


> On Oct 11, 2019, at 4:25 PM, Dr Eberhard W Lisse  wrote:
> 
> You could always issue
> 
>   sudo spctl --master-disable
> 
> :-)-O
> 
> el
> 
> On 2019-10-11 19:59 , Kevin Ushey wrote:
>> Hi,
>> 
>> I'm seeing the following when I attempt to install R-patched, as from
>> http://mac.r-project.org/:
>> 
>> ---
>> 
>> “R-3.6-branch-el-capitan-signed.pkg” can’t be opened because Apple
>> cannot check it for malicious software.
>> 
>> This software needs to be updated. Contact the developer for more 
>> information.
>> 
>> ---
>> 
>> I suspect this is pain being imposed by the requirement for notarized
>> applications / installers. The dialog can be overridden through the
>> Security & Privacy preferences pane, but Apple does not make this
>> obvious.
>> 
>> The official R 3.6.1 installer is not affected; likely because it was
>> grandfathered in due to its being published before Catalina was rolled
>> out.
>> 
>> Are there plans to notarize these builds of R? (can we be helpful in
>> making that happen?)
>> 
>> Best,
>> Kevin

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

Re: [R-SIG-Mac] Apparent interaction between XQuartz and the Catalina (10.15) macOS upgrade

[Marc Schwartz via R-SIG-Mac]

Bob,

If you have not tried to actually delete the relocated files folder, with the 
X11R6 symlink and then empty the trash, you have not experienced the issue in 
question.

In the past 24 hours, as a result of an increasing number of people upgrading 
to Catalina, the number of posts on the relocated files issue found via a 
Google search have increased by a magnitude.

Many of these are people simply expressing surprise at the new folder showing 
up on their desktops, but an increasing number are relevant to the specific 
issue that I raised, in not being able to delete these files from the trash and 
then having to go into Recovery mode to deal with it. 

That is not an acceptable solution for non-technical users, and the XQuartz 
folks need to address it specifically, but it is likely that Apple will need to 
address it more broadly.

Regards,

Marc


> On Oct 8, 2019, at 10:00 PM, Bob Rudis  wrote:
> 
> I've been running Catalina since the first beta and upgraded to GM the day of 
> release. Apart from having to stick R things into Full Disk Access I've had 
> no issues with R nor XQuartz.
> 
> I read through the links provided and, while I do have said symlink in the 
> relocated items folder Apple creates (this is new behavior for the GM), it 
> gets re-created fine for me & XQuartz works fine (and the minor pkg deps I 
> have installed that use it also work fine.
> 
> This would appear to be a YMMV situation.
> 
> -Bob
> 
>> On Oct 8, 2019, at 4:19 PM, Luis Puerto  wrote:
>> 
>> Thanks a lot for the heads up! 
>> 
>> Cheers!
>> Luis
>> 
>>> On 8 Oct 2019, at 22:49, Marc Schwartz via R-SIG-Mac 
>>>  wrote:
>>> 
>>> Hi All,
>>> 
>>> Perhaps I missed something relevant along the way someplace, but I ran the 
>>> upgrade to Catalina (10.15) last night. I wanted to give folks a heads up 
>>> on an issue that you may face, especially if you have XQuartz installed 
>>> alongside R.
>>> 
>>> One of the sequelae of the upgrade is that some files may get relocated 
>>> during the upgrade, likely in part due to the macOS SIP.
>>> 
>>> In my case, this involved the symlink for XQuartz, 'usr/X11R6', which gets 
>>> placed into a "Relocated Items" folder on the Desktop. That folder, which 
>>> is actually an alias to /Users/Shared, contains a folder tree with: 
>>> Security/usr/X11R6. Naively, after seeing this, I elected to move the 
>>> entire folder to the Trash.
>>> 
>>> That led me into a cycle of trying to figure out how to then delete that 
>>> folder tree from the Trash, as I would get various OS errors in the course 
>>> of doing so.
>>> 
>>> That led me to some Google searches, with incremental attempts at 
>>> solutions, but eventually landing on the following thread in the Apple 
>>> Community forums:
>>> 
>>> https://discussions.apple.com/thread/250712783
>>> 
>>> After the first review of the thread there, and before user 'faikbey' 
>>> posted a possible solution using Recovery Mode, I filed an Issue on the 
>>> XQuartz github repo here:
>>> 
>>> https://github.com/XQuartz/XQuartz/issues/1
>>> 
>>> It would seem that, at some level, one workaround would be to uninstall 
>>> XQuartz fully before the Catalina upgrade, but there is no uninstall 
>>> program provided by them. There is a series of CLI commands in a github 
>>> gist here:
>>> 
>>> https://gist.github.com/pwnsdx/d127873e24cef159d4d603accaf37ee4#file-gistfile1-txt
>>> 
>>> which appears to work, but would likely be best used prior to the Catalina 
>>> upgrade, and then re-install XQuartz after the upgrade is complete.
>>> 
>>> The solution to the problem posted by 'faikbey' in the Apple forum appears 
>>> to work in the original scenario, albeit, as I noted in my reply in that 
>>> thread, I needed to first mount the user volume in Recovery Mode using Disk 
>>> Utility, before I could proceed with the additional steps of deleting the 
>>> files from the Trash, then rebooting into normal mode. 
>>> 
>>> If anyone else has experienced this and knows of an alternative/better 
>>> solution, let us know.
>>> 
>>> Otherwise, let's see what the XQuartz folks might come up with on this, as 
>>> this was not an issue with prior macOS upgrades.
>>> 
>>> Regards,
>>> 
>>> Marc Schwartz
>>> 
>>> ___
>>> 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] Where is "sh" used by "R CMD check"?

[Marc Schwartz via R-SIG-Mac]

> On Sep 20, 2019, at 5:02 PM, Spencer Graves  
> wrote:
> 
> Hello:
> 
> 
>   How can I find "sh" that is used by "R CMD check" on my Mac?
> 
> 
>   I ask, my "Bitdefender Antivirus for Mac" blocks "R CMD check" with a 
> pop up saying, "Bitdefender Safe Files blocked a new process, sh, from 
> accessing your protected files.  What would you like to do?"  I'm allowed to 
> allow access "For 5 minutes" or "For this time only" -- or I can block it 
> forever.  I've been clicking "Allow access".
> 
> 
>   If I knew where "sh" was on my hard drive, I might be able to add it to 
> a "white list" maintained by the antivirus.  Sadly, I don't know where it is.
> 
> 
>   Thanks,
>   Spencer Graves


Hi Spencer,

Typically via 'which' from a terminal:

~  which sh
/bin/sh

There is also 'whereis', but that will only check default system binary paths, 
whereas 'which' will also search your $PATH.

In this case, they return the same information:

~  whereis sh
/bin/sh


It sounds like you have the "Safe Files" option in Bitdefender enabled, which 
is optional, which is why the messages. I use BF also.

Regards,

Marc Schwartz

___
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 postscript -- unknown family 'Arial'

[Marc Schwartz via R-SIG-Mac]

Hi, 

An additional pointer that might be helpful:

  
https://support.apple.com/guide/font-book/install-and-validate-fonts-fntbk1000/mac
 



Regards,

Marc Schwartz


> On May 1, 2019, at 9:48 AM, Simon Urbanek  wrote:
> 
> You likely don't have "Arial" installed (or it's corrupted). Use a font that 
> you have present in your system (see Font Book under Applications).
> 
> Cheers,
> Simon
> 
> 
> 
>> On Apr 30, 2019, at 6:50 PM, Ryan Pavlovicz  wrote:
>> 
>> Hi,
>> 
>> I am a new R user and am trying to run another person's data analysis
>> script that is failing with the following:
>> 
>> Error in postscript("Fig.eps", FALSE, "Arial", width = 13.83,  :
>> 
>> unknown family 'Arial'
>> 
>> 
>> I am running with Mojave 10.14.4 if that matters. Any help would be much
>> appreciated!
>> 
>> Thanks!
>> 
>> -ryan


[[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] R 3.5.3 macOS binary not signed?

[Marc Schwartz via R-SIG-Mac]

Hi Simon,

Thanks for following up. 

I presumed that this was a production issue of some nature, as you had 
established the pattern of digitally signing the binaries some time ago.

Thanks again!

Marc


> On Mar 14, 2019, at 9:36 AM, Simon Urbanek  
> wrote:
> 
> Marc,
> 
> thanks, I'm glad that at least someone pays attention and checks the 
> signature ;). I'm surprised my machine didn't raise a flag - I did test the 
> image locally from the master URL before releasing.
> 
> I have now updated the package to be signed, it is identical content, just 
> signed. You can get is from the Mac master server 
> https://mac.R-project.org/bin/macosx now and other CRAN servers will sync in 
> due time.
> 
> Thanks,
> Simon
> 
> 
> 
>> On Mar 14, 2019, at 8:18 AM, Marc Schwartz via R-SIG-Mac 
>>  wrote:
>> 
>> Hi,
>> 
>> I just tried to install the R 3.5.3 macOS binary from CRAN.
>> 
>> The SHA hash matches what is on CRAN, but I get an unknown developer message 
>> when I try to install.
>> 
>> I get:
>> 
>> pkgutil --check-signature R-3.5.3.pkg
>> Package "R-3.5.3.pkg":
>>  Status: no signature
>> 
>> 
>> I rechecked the 3.5.2 binary and do not have the issue there.
>> 
>> Thanks,
>> 
>> Marc Schwartz
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 

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

Re: [R-SIG-Mac] R 3.5.3 macOS binary not signed?

[Marc Schwartz via R-SIG-Mac]

Hi,

I am aware of the workaround, both from the CLI and via System Preferences.

The question is more about confirming that the binary is valid and from a 
source that is trusted, which is the point of digitally signing binaries as a 
trusted Apple developer.

Thanks,

Marc


> On Mar 14, 2019, at 8:43 AM, Dr Eberhard W Lisse  wrote:
> 
> Try from the commandline
> 
> sudo spctl --master-disable
> 
> and then install the package
> 
> el
> 
> Sent from Dr Lisse's iPad mini 4
> On 14 Mar 2019, 21:18 +0900, Marc Schwartz via R-SIG-Mac 
> , wrote:
>> Hi,
>> 
>> I just tried to install the R 3.5.3 macOS binary from CRAN.
>> 
>> The SHA hash matches what is on CRAN, but I get an unknown developer message 
>> when I try to install.
>> 
>> I get:
>> 
>> pkgutil --check-signature R-3.5.3.pkg
>> Package "R-3.5.3.pkg":
>> Status: no signature
>> 
>> 
>> I rechecked the 3.5.2 binary and do not have the issue there.
>> 
>> Thanks,
>> 
>> Marc Schwartz
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

[R-SIG-Mac] R 3.5.3 macOS binary not signed?

[Marc Schwartz via R-SIG-Mac]

Hi,

I just tried to install the R 3.5.3 macOS binary from CRAN.

The SHA hash matches what is on CRAN, but I get an unknown developer message 
when I try to install.

I get:

pkgutil --check-signature R-3.5.3.pkg
Package "R-3.5.3.pkg":
   Status: no signature


I rechecked the 3.5.2 binary and do not have the issue there.

Thanks,

Marc Schwartz

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

Re: [R-SIG-Mac] Studio Server under High Sierra

[Marc Schwartz via R-SIG-Mac]

Hi,

Also, to point out that RStudio has their own product support resources here:

  https://support.rstudio.com/hc/en-us 

Regards,

Marc Schwartz


> On Oct 24, 2018, at 4:18 AM, Luis Puerto  wrote:
> 
> Hey! 
> 
> AFAIK you have to compile rstudio-server to install it on macOS. 
> 
> You have the “detailed" instructions here: 
> https://github.com/rstudio/rstudio/blob/master/INSTALL 
> 
> 
> I haven’t done myself in macOS so I can give you more guidance. I don’t know 
> why they removed the formula from homebrew, but I guess it was giving 
> problems or something. 
> 
> 
> 
> Best Regards
> Luis Puerto
> luispuerto.net 
> 
> 
>> On 21 Oct 2018, at 13:42, Fuchs Ira  wrote:
>> 
>> Can I run Rstudio Server on OSX 10.13 (High Sierra). If so, can someone
>> please point me to install directions? I found an old post that talks about
>> using homebrew but I can't find the rstudio-server brew to install.
>> 
>> 

[[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] Blank help window

[Marc Schwartz via R-SIG-Mac]

Hi,

Ok, that confirms the issue, as surmised.

The default hosts file on macOS typically contains the following entries:

##
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost


Somewhere along the way, the content of that file has been changed and the 
above content deleted, possibly by whatever VPN configuration process was 
implemented at some point.

Ben, if you know how to edit and save the /etc/hosts file, which should require 
the admin password, add the above lines before the #BEGIN line in the file as 
it is now.

I would recommend saving the current version of the file, before you start 
editing, just in case. So, from the terminal, use something like:

  sudo cp /etc/hosts /etc/hosts.SAVE

If you are not sure how to edit the file, here is one resource:

  https://www.imore.com/how-edit-your-macs-hosts-file-and-why-you-would-want

and there are others online as well.

Once you do that, hopefully, that will resolve this issue.

Marc


> On Oct 18, 2018, at 6:34 PM, Ben Tupper  wrote:
> 
> Hi,
> 
> 
> ben@gale ~ $ ping localhost
> ping: cannot resolve localhost: Unknown host
> 
> Here's /etc/hosts in its entirety.
> 
> ben@gale ~ $ more /etc/hosts
> # BEGIN section for OpenVPN Client SSL sites
> 127.94.0.1  client.openvpn.net
> 127.94.0.2  openvpn-client.vpn.bigelow.org
> # END section for OpenVPN Client SSL sites
> 
> I'm not currently using VPN.
> 
> 
>> On Oct 18, 2018, at 6:29 PM, peter dalgaard  wrote:
>> 
>> Cannot _find_ localhost?? Can you do this (in a Terminal window) ?
>> 
>> Peter-Dalgaards-MacBook-Air:STAT pd$ ping localhost
>> PING localhost (127.0.0.1): 56 data bytes
>> Request timeout for icmp_seq 0
>> Request timeout for icmp_seq 1
>> ^C
>> --- localhost ping statistics ---
>> 3 packets transmitted, 0 packets received, 100.0% packet loss
>> 
>> If not, what is in the first couple of lines in /etc/hosts?
>> 
>> -pd
>> 
>>> On 19 Oct 2018, at 00:09 , Ben Tupper  wrote:
>>> 
>>> Just a little followup.  Switching the default browser from Firefox to 
>>> Safari yields a similar message in the browser after...
>>> 
>>> Browse[2]> browseURL(x)
>>> 
>>> 'Safari can't open the page "localhost:29682/library/utils/html/help.html"
>>> because Safari can't find the server "localhost".'
>>> 
>> 
>> -- 
>> Peter Dalgaard, Professor,
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Office: A 4.23
>> Email: pd@cbs.dk  Priv: pda...@gmail.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
> 
> Ecological Forecasting: https://eco.bigelow.org/
> 
> 
> 
> 
> 
> 
>   [[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] Blank help window

[Marc Schwartz via R-SIG-Mac]

Ok, I think that Peter and Duncan are on to the key issue here.

I have been trying to figure out what the difference is between displaying HTML 
help in R.app versus in the terminal and we now know.

If running R in R.app, where .Platform$GUI == "AQUA", the key line in the HTML 
browser display process is:

  x <- gsub("http://127.0.0.1 ", "http://localhost 
", x, fixed = TRUE)

where the IP address in the help file URL ('x') is changed to localhost. That 
does not happen when running R from the terminal and the IP address is used.

In other words, a url something like:

  "http://127.0.0.1:27572/library/graphics/html/plot.html;

gets regex'd to:

  "http://localhost:27572/library/graphics/html/plot.html;


Typically there is an entry in /etc/hosts that maps 127.0.0.1 to localhost. If 
that entry is not present, then the OS does not know how to map the domain 
'localhost' to a physical IP address, much like a DNS server could not map an 
internet domain name to a physical server IP address.

Ben, if you are not sure about how to look at /etc/hosts per Peter's message 
below, you can use:

  cat /etc/hosts | grep localhost

in a terminal and see what it returns.

Marc



> On Oct 18, 2018, at 6:29 PM, peter dalgaard  wrote:
> 
> Cannot _find_ localhost?? Can you do this (in a Terminal window) ?
> 
> Peter-Dalgaards-MacBook-Air:STAT pd$ ping localhost
> PING localhost (127.0.0.1): 56 data bytes
> Request timeout for icmp_seq 0
> Request timeout for icmp_seq 1
> ^C
> --- localhost ping statistics ---
> 3 packets transmitted, 0 packets received, 100.0% packet loss
> 
> If not, what is in the first couple of lines in /etc/hosts?
> 
> -pd
> 
>> On 19 Oct 2018, at 00:09 , Ben Tupper  wrote:
>> 
>> Just a little followup.  Switching the default browser from Firefox to 
>> Safari yields a similar message in the browser after...
>> 
>> Browse[2]> browseURL(x)
>> 
>> 'Safari can't open the page "localhost:29682/library/utils/html/help.html"
>> because Safari can't find the server "localhost".'
>> 
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac


[[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] Blank help window

[Marc Schwartz via R-SIG-Mac]

Ugggh

I was fully expecting it to fail, given my presumptive new found wisdom...

Had it failed, then it would support the notion that R,app was irrelevant to 
the underlying issue with help and there was something going on with the server 
itself.

However, this now suggests (back to my original view), that there is something 
different in the manner in which R.app displays HTML help content in the 
built-in  browser window.

Did you try to set the help browser in R.app to use an external viewer using 
the command line invocation that I sent earlier?

That is, with R.app not running, in a terminal type:

  defaults write org.R-project.R use.external.help YES

Then run R.app and see what happens with ?plot.

To return R.app to use the default internal browser, close R.app and then in a 
terminal, type:

  defaults delete org.R-project.R use.external.help 




> On Oct 18, 2018, at 6:13 PM, Ben Tupper  wrote:
> 
> Hi,
> 
> ben@gale ~ $ R
> 
> R version 3.5.1 (2018-07-02) -- "Feather Spray"
> 
> 
> > options(help_type = "html")
> > ?plot
> starting httpd help server ... done
> 
> 
> That brings up visible help in the default browser (Safari or Firefox 
> depending upon which is set to be the default browser).
> 
> 
>> On Oct 18, 2018, at 6:04 PM, Marc Schwartz > > wrote:
>> 
>> Hi Ben,
>> 
>> Ok, thanks for that clarification. That fundamentally alters my view of the 
>> issue.
>> 
>> For verification, can you start R in a terminal and then type:
>> 
>>  options(help_type = "html")
>> 
>> after which, then try help for some function (e.g. ?plot) and see what 
>> happens.
>> 
>> Thanks,
>> 
>> Marc
>> 
>> 
>>> On Oct 18, 2018, at 5:45 PM, Ben Tupper >> > wrote:
>>> 
>>> You are correct that it only comes up in the text pager when I invoke R 
>>> from the terminal (with or without --vanilla).
>>> 
>>> RStudio help works as expected in the sense that help content is rendered 
>>> within the RStudio panes on the "Help" tab - just as you surmised.
>>> 
>>> Cheers (really!),
>>> Ben
>>> 
 On Oct 18, 2018, at 5:32 PM, Marc Schwartz >>> > wrote:
 
 Hi Ben,
 
 A question, because as I go back and re-read both this thread and the 
 prior one you posted on this issue, I have been presuming that when you 
 run R from the terminal, you can successfully get help to open in an 
 external browser.
 
 However, given my re-read and what you now post below, I am wondering if, 
 in fact, when running R in the terminal, you simply get the help 
 displaying in the text pager.
 
 I don't use RStudio, so not sure if help comes up in their own internal 
 browser, or if it comes up in an external browser. Albeit, looking at 
 their website, it appears to be an internal browser that stays within the 
 IDE, in contrast to R.app opening the internal browser in an external 
 window.
 
 Can you confirm that when you run R from the terminal, does help appear 
 within the terminal window in the pager, or does it come up in whatever 
 external browser you are using, which I am guessing is Firefox based upon 
 the output below.
 
 Thanks,
 
 Marc
 
 
 
> On Oct 18, 2018, at 5:09 PM, Ben Tupper  > wrote:
> 
> Hi,
> 
> In a fresh R.app session
> 
>> debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
>> help('help')
> starting httpd help server ... done
> debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
> debug: {
>  x <- gsub("http://127.0.0.1 ", "http://localhost 
> ", x, fixed = TRUE)
>  .Call("aqua.custom.print", "help-files", x)
>  invisible(x)
> }
> Browse[2]> n
> debug: x <- gsub("http://127.0.0.1 ", 
> "http://localhost ", x, fixed = TRUE)
> Browse[2]> n
> debug: .Call("aqua.custom.print", "help-files", x)
> Browse[2]> browseURL(x)
> 
> 
> opens the external browser 
> http://localhost:28450/library/utils/html/help.html
>  
> 
> 
> but the browser says...
> 
> "Hmm. We’re having trouble finding that site.
> We can’t connect to the server at localhost.
> If that address is correct, here are three other things you can try:
> 
>  Try again later.
>  Check your network connection.
>  If you are connected but behind a firewall, check that Firefox has 
> permission to access the Web."
> 
> 
> And...
> 
> Browse[2]> c
> exiting from: browser(if (encodeIfNeeded) URLencode(url) else url)
> 
> ... opens the blank help window.
> 
> 
> Finally, 

Re: [R-SIG-Mac] Blank help window

[Marc Schwartz via R-SIG-Mac]

Hi Ben,

Ok, thanks for that clarification. That fundamentally alters my view of the 
issue.

For verification, can you start R in a terminal and then type:

  options(help_type = "html")

after which, then try help for some function (e.g. ?plot) and see what happens.

Thanks,

Marc


> On Oct 18, 2018, at 5:45 PM, Ben Tupper  wrote:
> 
> You are correct that it only comes up in the text pager when I invoke R from 
> the terminal (with or without --vanilla).
> 
> RStudio help works as expected in the sense that help content is rendered 
> within the RStudio panes on the "Help" tab - just as you surmised.
> 
> Cheers (really!),
> Ben
> 
>> On Oct 18, 2018, at 5:32 PM, Marc Schwartz  wrote:
>> 
>> Hi Ben,
>> 
>> A question, because as I go back and re-read both this thread and the prior 
>> one you posted on this issue, I have been presuming that when you run R from 
>> the terminal, you can successfully get help to open in an external browser.
>> 
>> However, given my re-read and what you now post below, I am wondering if, in 
>> fact, when running R in the terminal, you simply get the help displaying in 
>> the text pager.
>> 
>> I don't use RStudio, so not sure if help comes up in their own internal 
>> browser, or if it comes up in an external browser. Albeit, looking at their 
>> website, it appears to be an internal browser that stays within the IDE, in 
>> contrast to R.app opening the internal browser in an external window.
>> 
>> Can you confirm that when you run R from the terminal, does help appear 
>> within the terminal window in the pager, or does it come up in whatever 
>> external browser you are using, which I am guessing is Firefox based upon 
>> the output below.
>> 
>> Thanks,
>> 
>> Marc
>> 
>> 
>> 
>>> On Oct 18, 2018, at 5:09 PM, Ben Tupper  wrote:
>>> 
>>> Hi,
>>> 
>>> In a fresh R.app session
>>> 
 debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
 help('help')
>>> starting httpd help server ... done
>>> debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
>>> debug: {
>>>   x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
>>>   .Call("aqua.custom.print", "help-files", x)
>>>   invisible(x)
>>> }
>>> Browse[2]> n
>>> debug: x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
>>> Browse[2]> n
>>> debug: .Call("aqua.custom.print", "help-files", x)
>>> Browse[2]> browseURL(x)
>>> 
>>> 
>>> opens the external browser 
>>> http://localhost:28450/library/utils/html/help.html
>>> 
>>> but the browser says...
>>> 
>>> "Hmm. We’re having trouble finding that site.
>>> We can’t connect to the server at localhost.
>>> If that address is correct, here are three other things you can try:
>>> 
>>>   Try again later.
>>>   Check your network connection.
>>>   If you are connected but behind a firewall, check that Firefox has 
>>> permission to access the Web."
>>> 
>>> 
>>> And...
>>> 
>>> Browse[2]> c
>>> exiting from: browser(if (encodeIfNeeded) URLencode(url) else url)
>>> 
>>> ... opens the blank help window.
>>> 
>>> 
>>> Finally, following up on Marc's suggestion that I invoke R without 
>>> --vanilla...
>>> 
>>> ben@gale ~ $ diff R-app-options R-options 
>>> 81c81
>>> < 
>>> ---
 
>>> 108,110d107
>>> < $help_type
>>> < [1] "html"
>>> < 
>>> 184,185c181,182
>>> < CRAN 
>>> < "http://cran.utstat.utoronto.ca; 
>>> ---
   CRAN 
 "@CRAN@" 
>>> 247c244
>>> < [1] 168
>>> ---
 [1] 80
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 On Oct 18, 2018, at 4:49 PM, Duncan Murdoch  
 wrote:
 
 On 18/10/2018 8:50 AM, Ben Tupper wrote:
> I also have no firewall running on the platform.  I do have 
> anti-virus/malware and have turned it off.  The help window still renders 
> with a blank page and there is no text captured with a copy-paste.
> I tried debug() as Duncan suggested and get the following in a fresh 
> R.app session...
 
 Okay, that wasn't as informative as I had hoped.  Could you try the 
 following:
 
 debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
 
 then ask for help on something.  You should stop in the debugger seeing 
 something like
 
 debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
 debug: {
  x <- gsub("http://127.0.0.1 ", "http://localhost 
 ", x, fixed = TRUE)
  .Call("aqua.custom.print", "help-files", x)
  invisible(x)
 }
 
 At the prompt, type "n" (without the quotes, followed by return) twice, 
 until you are at the .Call line.  Then type
 
 browseURL(x)
 
 This should open your external browser.  It will either show a blank page, 
 or the help page:  that will indicate whether the problem is in the 
 internal browser or in the server.
 
 Then go back to R.app, and type "c".  This should open the same help page 

Re: [R-SIG-Mac] Blank help window

[Marc Schwartz via R-SIG-Mac]

Hi Ben,

A question, because as I go back and re-read both this thread and the prior one 
you posted on this issue, I have been presuming that when you run R from the 
terminal, you can successfully get help to open in an external browser.

However, given my re-read and what you now post below, I am wondering if, in 
fact, when running R in the terminal, you simply get the help displaying in the 
text pager.

I don't use RStudio, so not sure if help comes up in their own internal 
browser, or if it comes up in an external browser. Albeit, looking at their 
website, it appears to be an internal browser that stays within the IDE, in 
contrast to R.app opening the internal browser in an external window.

Can you confirm that when you run R from the terminal, does help appear within 
the terminal window in the pager, or does it come up in whatever external 
browser you are using, which I am guessing is Firefox based upon the output 
below.

Thanks,

Marc



> On Oct 18, 2018, at 5:09 PM, Ben Tupper  wrote:
> 
> Hi,
> 
> In a fresh R.app session
> 
>> debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
>> help('help')
> starting httpd help server ... done
> debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
> debug: {
>x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
>.Call("aqua.custom.print", "help-files", x)
>invisible(x)
> }
> Browse[2]> n
> debug: x <- gsub("http://127.0.0.1;, "http://localhost;, x, fixed = TRUE)
> Browse[2]> n
> debug: .Call("aqua.custom.print", "help-files", x)
> Browse[2]> browseURL(x)
> 
> 
> opens the external browser 
> http://localhost:28450/library/utils/html/help.html 
> 
> 
> but the browser says...
> 
> "Hmm. We’re having trouble finding that site.
> We can’t connect to the server at localhost.
> If that address is correct, here are three other things you can try:
> 
>Try again later.
>Check your network connection.
>If you are connected but behind a firewall, check that Firefox has 
> permission to access the Web."
> 
> 
> And...
> 
> Browse[2]> c
> exiting from: browser(if (encodeIfNeeded) URLencode(url) else url)
> 
> ... opens the blank help window.
> 
> 
> Finally, following up on Marc's suggestion that I invoke R without 
> --vanilla...
> 
> ben@gale ~ $ diff R-app-options R-options 
> 81c81
> < 
> ---
>> 
> 108,110d107
> < $help_type
> < [1] "html"
> < 
> 184,185c181,182
> < CRAN 
> < "http://cran.utstat.utoronto.ca; 
> ---
>>CRAN 
>> "@CRAN@" 
> 247c244
> < [1] 168
> ---
>> [1] 80
> 
> 
> 
> 
> 
> 
> 
>> On Oct 18, 2018, at 4:49 PM, Duncan Murdoch  wrote:
>> 
>> On 18/10/2018 8:50 AM, Ben Tupper wrote:
>>> I also have no firewall running on the platform.  I do have 
>>> anti-virus/malware and have turned it off.  The help window still renders 
>>> with a blank page and there is no text captured with a copy-paste.
>>> I tried debug() as Duncan suggested and get the following in a fresh R.app 
>>> session...
>> 
>> Okay, that wasn't as informative as I had hoped.  Could you try the 
>> following:
>> 
>> debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
>> 
>> then ask for help on something.  You should stop in the debugger seeing 
>> something like
>> 
>> debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
>> debug: {
>>   x <- gsub("http://127.0.0.1 ", "http://localhost 
>> ", x, fixed = TRUE)
>>   .Call("aqua.custom.print", "help-files", x)
>>   invisible(x)
>> }
>> 
>> At the prompt, type "n" (without the quotes, followed by return) twice, 
>> until you are at the .Call line.  Then type
>> 
>> browseURL(x)
>> 
>> This should open your external browser.  It will either show a blank page, 
>> or the help page:  that will indicate whether the problem is in the internal 
>> browser or in the server.
>> 
>> Then go back to R.app, and type "c".  This should open the same help page in 
>> the internal browser.  It might show a blank page, or the regular help page: 
>>  either one would tell us something.
>> 
>> Duncan Murdoch
>> 



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

Re: [R-SIG-Mac] Blank help window

[Marc Schwartz via R-SIG-Mac]

Hi Ben,

Ok, if I read correctly, it looks like you must have started R in the terminal 
using 'R --vanilla', based upon the file name below.

In that case, R should bring up help pages in the terminal using the internal 
text pager, as opposed to externally in a browser with HTML.

Start R in the Terminal just using 'R' and see what, if any, differences there 
are in the output of options() in that case.


Grasping at another straw, let's change the default browser in R.app to see if 
using an external browser, instead of the built-in browser, behaves differently.

As it turns out, from discussions some years ago, it is a bit more complex with 
R.app, as it does not honor the usual options() settings.

So, with R.app NOT running, in a terminal, use:

  defaults write org.R-project.R use.external.help YES

and hit enter.

Then, start R.app and try to use help again and see what happens.


To restore the default use of the internal R.app browser, exit R.app and in a 
terminal, use:

  defaults delete org.R-project.R use.external.help 

and hit enter.


See if that does anything.

Marc



> On Oct 18, 2018, at 10:52 AM, Ben Tupper  wrote:
> 
> Hi,
> 
> Thanks for your persistence and kind help.
> 
> (1)  Comparing output of options()
> 
> R.app options() includes 
> 
> $help_type
> [1] "html"
> 
> that terminal R options() does not.  Here's the diff of the two...
> 
> ben@gale ~ $ diff R-vanilla-options R-app-options 
> 81c81
> < 
> ---
> > 
> 107a108,110
> > $help_type
> > [1] "html"
> > 
> 181,182c184,185
> < CRAN 
> < "@CRAN@" 
> ---
> > CRAN 
> > "http://cran.utstat.utoronto.ca; 
> 244c247
> < [1] 80
> ---
> > [1] 168
> 
> 
> (2) Removing ~/Library/Preferences/org.R-project.R.plist
> 
> Starting R.app after removing the plist does not resolve the blank help 
> window (but did restore R.app's factory-default appearance and settings.)
> 
> > help("help")# brings up blank help page
> starting httpd help server ... done 
> 
> 
> 
> 
> 
> 
> 
>> On Oct 18, 2018, at 10:36 AM, Marc Schwartz  wrote:
>> 
>> Hi,
>> 
>> Two things:
>> 
>> 1. Can one or both of you guys check locally on your own computers, to see 
>> if there is any difference between the output of options() in R.app, versus 
>> the output when R is run from a Terminal session. Many elements will not be 
>> germane to this issue, but others might, if there are differences.
>> 
>> Just wondering if some option() is altered from the default and/or causing a 
>> conflict unique to R.app.
>> 
>> 
>> 
>> 2. Exit from R.app so that it is not running.
>> 
>> Then look for the file:
>> 
>>   ~/Library/Preferences/org.R-project.R.plist
>> 
>> From what I can tell, that is the file that stores the default settings and 
>> user specific Preferences configurations for R.app.
>> 
>> With R.app NOT running, delete that file, or drag it to the desktop, if 
>> preferred.
>> 
>> Then start R.app and see what happens with help. The above .plist file, will 
>> be created new, with the new R.app session, so will return to default 
>> settings. Perhaps there is something in there screwing things up.
>> 
>> 
>> Marc
>> 
>> 
>> 
> 
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
> 
> Ecological Forecasting: https://eco.bigelow.org/
> 
> 
> 
> 
> 

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

Re: [R-SIG-Mac] Blank help window

[Marc Schwartz via R-SIG-Mac]

Hi,

Two things:

1. Can one or both of you guys check locally on your own computers, to see if 
there is any difference between the output of options() in R.app, versus the 
output when R is run from a Terminal session. Many elements will not be germane 
to this issue, but others might, if there are differences.

Just wondering if some option() is altered from the default and/or causing a 
conflict unique to R.app.



2. Exit from R.app so that it is not running.

Then look for the file:

  ~/Library/Preferences/org.R-project.R.plist

>From what I can tell, that is the file that stores the default settings and 
>user specific Preferences configurations for R.app.

With R.app NOT running, delete that file, or drag it to the desktop, if 
preferred.

Then start R.app and see what happens with help. The above .plist file, will be 
created new, with the new R.app session, so will return to default settings. 
Perhaps there is something in there screwing things up.


Marc




[[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] Blank help window

[Marc Schwartz via R-SIG-Mac]

Ok, strange. I figured that there was some conflict/corruption in place with 
R.app that was not immediately clear.

Peter raised the possibility of a firewall issue, but I am curious as to why 
that would affect the use of help in R.app, but not via other environments, 
like the Mac Terminal app. Theoretically, it should be via similar protocols 
and ports in each setting, unless there is something specific that R.app does 
to the OS environment when running, that would inhibit the dynamic generation 
of the HTML pages. But if so, why just for the two of you?

It seems like the server is starting up ok, but the help pages are not being 
generated by Rd2HTML() in R.app.

However, it sparked a thought in my head, which is always risky, and that is, 
do you guys have any anti-virus/malware software running? I may be grasping at 
straws here, but such applications have been known to cause all kinds of flaky 
behaviors, that are not immediately evident nor associated with them.

One other thought. When you get the blank HTML page, presumably white 
background, drag the cursor around the page to try to highlight text, as if the 
text was also white, thus not showing against the white background. Another 
straw

Regards,

Marc


> On Oct 17, 2018, at 8:06 PM, Ben Tupper  wrote:
> 
> Darn.  No joy from a complete clean-and-reinstall with a reinstall of XQuartz 
> as Marc suggested.  It is still a blank help page.
> 
> Below is everything I can think of from the new session.
> 
> 
> R version 3.5.1 (2018-07-02) -- "Feather Spray"
> Copyright (C) 2018 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.
> 
> [R.app GUI 1.70 (7543) x86_64-apple-darwin15.6.0]
> 
>> ?data.frame
> starting httpd help server ... done
>> sessionInfo()
> R version 3.5.1 (2018-07-02)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS Sierra 10.12.6
> 
> Matrix products: default
> BLAS: 
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
> LAPACK: 
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
> 
> loaded via a namespace (and not attached):
> [1] compiler_3.5.1 tools_3.5.1   
> 
>> capabilities()
>   jpeg pngtiff   tcltk X11aqua
> http/ftp sockets  libxmlfifo 
>   TRUETRUETRUETRUETRUETRUE
> TRUETRUETRUETRUE 
> cledit   iconv NLS profmem   cairo ICU 
> long.double libcurl 
>   TRUETRUETRUETRUETRUETRUE
> TRUETRUE 
> 
> 
> 
> And from shell...
> 
> ben@gale ~ $ ll /usr | grep X11
> lrwxr-xr-x 1 root  wheel 8B Oct 17 19:35 X11 -> /opt/X11
> lrwxr-xr-x 1 root  wheel 8B Oct 17 19:35 X11R6 -> /opt/X11
> 
> 
> 
> 
> 
> 
>> On Oct 17, 2018, at 7:20 PM, Ben Tupper  wrote:
>> 
>> Ahoy!
>> 
>>> ?data.frame
>> starting httpd help server ... done
>>> (tools::startDynamicHelp(NA))
>> [1] 31048
>> 
>> Connecting to http://127.0.0.1:31048/NEWS  
>> brings up NEWS as expected.
>> 
>> If I understand the MacOS preferences the firewall is OFF.  
>> 
>> I'll try the clean-then-reinstall that Marc suggests and report back.
>> 
>> Ben
>> 
>>> On Oct 17, 2018, at 5:42 PM, Peter Dalgaard >> > wrote:
>>> 
>>> Hmm, when trying from R.app, do you see the following?
>>> 
 ?data.frame
>>> starting httpd help server ... done
 (tools::startDynamicHelp(NA))
>>> [1] 26163
>>> 
>>> (The last bit is the port number of the HTTP server and will differ between 
>>> invokations. I think you get 0 if the server isn't running and -1 if it 
>>> failed to start.)
>>> 
>>> If the server is there, you could try connecting from your favourite 
>>> browser at (say) http://127.0.0.1:26163/NEWS 
>>> 
>>> If the server is there, but you cannot talk to it, then I suspect that a 
>>> firewall is getting in the way.
>>> 
>>> -pd
>>> 
>>> 
 On 17 Oct 2018, at 20:53 , Ben Tupper >>> > wrote:
 
 Hi,
 
 The behavior I see is identical to what you describe 

Re: [R-SIG-Mac] Blank help window

[Marc Schwartz via R-SIG-Mac]

Hi, 

I am on a MBP with Mojave (10.14) and do not observe this issue in R.app, which 
I tested, but don't otherwise use, as I use Emacs/ESS and I don't have any 
issues there either.

It is not clear to me if the use of the Migration Assistant and/or Brew are 
germane or simply red herrings, or if either one are common to what Ben is 
experiencing.

That being said, my recommendation would be to completely remove your R 
installation. If you used the CRAN binary, it should be in:
  
  /Library/Frameworks/R.framework

I would delete the entire R folder tree from R.framework on down.

I would also delete R.app from \Applications, since that seems to be at least 
associated with the issue, if not an actual cause.

Once you have done the above, re-install R using the correct CRAN binary as a 
new, clean install.

After re-installing R, then re-install XQuartz from https://www.xquartz.org 
. In theory, that should be unrelated to this issue, 
I believe, but it should be re-installed after installing/re-installing R in 
either case.

After the above, then try using help in R.app again and see what happens.

Regards,

Marc Schwartz

  

> On Oct 17, 2018, at 1:48 PM, zListserv  wrote:
> 
> Many thanks for your suggestions.  Not sure whether Ben’s issue is the same 
> as mine.  Ben has problems with ?data.frame.  My issue is a blank help window 
> when typing ?mean (or any other function).
> 
> Peter suggested checking capabilities().  They are all TRUE.
> 
> You both suggested checking configuration files.  Removing .Rprofile, .Rdata, 
> and .Rapp.history made no difference.
> 
> Simon suggested:
> 
>> On 2018-10 -17, at 08:57, Simon Urbanek  wrote:
>> 
>> Few things to try:
>> 
>> - do you see anything in the error console?
> 
> Nothing noticeable in the error console, though I’m inexpert at reading it.
>> 
>> - remove (rename) any and all customization files like ~/.Rprofle ~/.RData 
>> etc.
> 
> No effect
> 
>> 
>> - try running R from the console and starting the html help by hand to see 
>> if it works at all:
>> tools::startDynamicHelp()
>> help.start(browser="/usr/bin/open”)
>> 
> 
> Help works when running R from console
> 
>> - if that works try the same from the R.app gui *before* using help:
>> help.start(browser="/usr/bin/open”)
> 
> No effect in R (except it opens my default browser).
> 
>> 
>> Cheers,
>> Simon
>> 
>> 
>>> On Oct 16, 2018, at 7:11 PM, zListserv  wrote:
>>> 
>>> 
>>> I recently migrated to a MacBook Pro (15-inch, 2018) using the Migration 
>>> Assistant.  Everything went well, though there are always a few things that 
>>> don't transfer such as applications installed by Brew which I installed 
>>> manually.
>>> 
>>> An issue with R arose I can't solve.  The help systen opens with a blank 
>>> window.
>>> 
>>> Help works when I run R from the terminal so I know the files are 
>>> installed.  Help works fine on the Macintosh I used a the source for the 
>>> migration so it isn't a problem I inherited.  Re-installing R (see 
>>> sessionInfo below) didn't solve the problem.
>>> 
>>> Anyone have any suggestions how I can get help to work?
>>> 
>>> R version 3.5.1 (2018-07-02)
>>> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>>> Running under: macOS High Sierra 10.13.6
>>> 
>>> Matrix products: default
>>> BLAS: 
>>> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
>>> LAPACK: 
>>> /Library/Frameworks/R.framework/Versions/3.5/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  
>>> [7] base 
>>> 
>>> other attached packages:
>>> [1] HANDLS_0.34 zUtil_0.121
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] Rcpp_0.12.17lattice_0.20-35 digest_0.6.15   MASS_7.3-50
>>> [5] chron_2.3-52grid_3.5.1  plyr_1.8.4  xtable_1.8-2   
>>> [9] DBI_1.0.0   RSQLite_2.1.1   sqldf_0.4-11blob_1.1.1 
>>> [13] sp_1.3-1gsubfn_0.7  proto_1.0.0 tools_3.5.1
>>> [17] Matching_4.9-3  bit64_0.9-7 foreign_0.8-70  bit_1.1-14 
>>> [21] compiler_3.5.1  maptools_0.9-2  memoise_1.1.0  


[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Installing R on 10.14 (Mojave)

[Marc Schwartz via R-SIG-Mac]

Hi Tim,

Be sure that you are running the latest version of Xcode:

  https://itunes.apple.com/us/app/xcode/id497799835?mt=12

and that you also install/re-install the command line tools afterwards:

  xcode-select --install

With a major macOS version upgrade like this, you should do a fully clean 
install of R and afterwards, of XQuartz:

  https://www.xquartz.org

Regards,

Marc


> On Sep 25, 2018, at 11:59 AM, Tim Bates  wrote:
> 
> fyi
> 
> home$ sudo installer -pkg \
>> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>>  \
>> -target /
> Password:
> installer: Error - the package path specified was invalid: 
> '/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg'.
> spearman:OpenMx tim$ 
> 
> 
>> On 25 Sep 2018, at 1:04 pm, Marc Schwartz via R-SIG-Mac 
>>  wrote:
>> 
>> Thanks to both of you for the pointers on this.
>> 
>> I have not used a dark theme since my Fedora days. Still getting used to 
>> it... :-)
>> 
>> Regards,
>> 
>> Marc Schwartz
>> 
>> 
>>> On Sep 25, 2018, at 5:55 AM, peter dalgaard  wrote:
>>> 
>>> [Oops. Forgot to copy this back to R-sig-mac, it seems...]
>>> 
>>> Thanks, Brian,
>>> 
>>> Yes, we have previously learned the hard way that timing R releases too 
>>> close to MacOS updates is a bad idea...
>>> 
>>> The manual updates haven't made it to CRAN yet, you need to look in the 
>>> sources. 
>>> 
>>> For those who might be curious, but lazy:
>>> 
>>>>>>> 
>>> As from macOS 10.14 (‘Mojave’) an additional step is needed to install the 
>>> headers to /usr/include: from a Terminal run
>>> 
>>> sudo installer -pkg \
>>> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>>>  \
>>> -target /
>>> 
>>> Alternatively, change the include path via
>>> 
>>> CPPFLAGS="-isystem 
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include"
>>> <<<<
>>> 
>>> 
>>> Incidentally, probably unrelated, I discovered that the R-patched snapshots 
>>> had stalled since Sep 13 due to an SVN database error. This should be 
>>> cleared up now.
>>> 
>>> -pd 
>>> 
>>>> On 25 Sep 2018, at 08:59 , Prof Brian Ripley  wrote:
>>>> 
>>>> A heads up:
>>>> 
>>>> The Mojave update removes /usr/include and (re)installing the Command Line 
>>>> Tools does not put the standard system headers there.  Workarounds are now 
>>>> described in the R-admin manual for R-devel and R-patched.
>>>> 
>>>> -- 
>>>> 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
>>> 
>>> -- 
>>> Peter Dalgaard, Professor,
>>> Center for Statistics, Copenhagen Business School
>>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>>> Phone: (+45)38153501
>>> Office: A 4.23
>>> Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [R-SIG-Mac] Installing R on 10.14 (Mojave)

[Marc Schwartz via R-SIG-Mac]

Thanks to both of you for the pointers on this.

I have not used a dark theme since my Fedora days. Still getting used to it... 
:-)

Regards,

Marc Schwartz


> On Sep 25, 2018, at 5:55 AM, peter dalgaard  wrote:
> 
> [Oops. Forgot to copy this back to R-sig-mac, it seems...]
> 
> Thanks, Brian,
> 
> Yes, we have previously learned the hard way that timing R releases too close 
> to MacOS updates is a bad idea...
> 
> The manual updates haven't made it to CRAN yet, you need to look in the 
> sources. 
> 
> For those who might be curious, but lazy:
> 
> 
> As from macOS 10.14 (‘Mojave’) an additional step is needed to install the 
> headers to /usr/include: from a Terminal run
> 
> sudo installer -pkg \
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>  \
> -target /
> 
> Alternatively, change the include path via
> 
> CPPFLAGS="-isystem 
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include"
> 
> 
> 
> Incidentally, probably unrelated, I discovered that the R-patched snapshots 
> had stalled since Sep 13 due to an SVN database error. This should be cleared 
> up now.
> 
> -pd 
> 
>> On 25 Sep 2018, at 08:59 , Prof Brian Ripley  wrote:
>> 
>> A heads up:
>> 
>> The Mojave update removes /usr/include and (re)installing the Command Line 
>> Tools does not put the standard system headers there.  Workarounds are now 
>> described in the R-admin manual for R-devel and R-patched.
>> 
>> -- 
>> 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
> 
> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

Re: [R-SIG-Mac] How to change default Browser for R

[Marc Schwartz via R-SIG-Mac]

> On Aug 4, 2018, at 2:41 AM, Christofer Bogaso  
> wrote:
> 
> Hi,
> 
> In my Mac, I have 2 browsers installed :
> 
> Chrome (system default)
> Google Chrome Canary
> 
> While for my regular browsing work I use Chrome, However for R I prefer to
> use Canary (like, opening Help page). Is there any way to set Canary only
> for R, however keeping system default unchanged.
> 
> Thanks for your feedback.


Hi,

There are several steps involved during R ?Startup that set system and session 
specific ?options.

In your ~/.Rprofile, for session specific settings, you can add something like 
the following:

  options(browser = "/usr/bin/open -a '/Applications/Google Chrome.app'")

replacing the Chrome binary filename above with the Canary name.

Be sure to exit your R session after setting the above, then start a new 
session to pick up the change.

The above works for me, to change the default from Safari to Chrome, just 
within my R session, without affecting the system default.

Regards,

Marc Schwartz

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