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

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

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

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

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
 
<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 <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 
> <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 <http://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 > <mailto:marc_schwa...@me.com>> 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 >> <mailto:btup...@bigelow.org>> 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 >>> <mailto:marc_schwa...@me.com>> 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 >>>> <mailto:btup...@bigelow.org>> 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://127.0.0.1/>", "http://localhost 
>>>>> <http://localhost/>", x, fixed = TRUE)
>>>>>  .Call("aqua.custom.print", "help-files", x)
>>>>>  invisible(x)
>>>>> }
>>>>> Browse[2]> n
>>>>> debug: x <- gsub(

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

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

Re: [R-SIG-Mac] SHA-1 Hash for R-3.5.0.pkg Incorrect

[Marc Schwartz]

Hi Simon,

Understood, as the digital signature is superior to the stand alone hash value, 
since like the hash value, it provides a check against file 
modifications/corruption since being signed, and unlike the stand alone hash 
value, it provides source validation and non-repudiation.

In either case, I see that you have now changed the labeling of the SHA hash on 
CRAN, to indicate that it is SHA-1 specifically, and that hash value now checks 
locally. Thank you for making that change.

I wonder if it might make sense, given that the signature is superior to the 
stand alone hash values, to begin to drop the latter for signed PKG files 
intended for ongoing (non-legacy) binary versions of R for macOS, for the 
reasons below.

If so, it might make sense to also move in the same direction for the signed 
PKG files in the macOS tools folder on CRAN, which now just have the MD5 hash 
values.

Thanks again Simon.

Marc


> On Apr 26, 2018, at 1:35 PM, Simon Urbanek <simon.urba...@r-project.org> 
> wrote:
> 
> Marc,
> 
> no, the hashes merely a legacy to check that you don't have a corrupted 
> download. They are neither intended nor used for validation. To verify the 
> validity you should use the signature check.
> 
> Cheers,
> Simon
> 
> 
> 
>> On Apr 25, 2018, at 4:37 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
>> 
>> Hi Simon,
>> 
>> Thanks for the explanation.
>> 
>> It did not occur to me that SHA-0 was being used, since it was withdrawn as 
>> a standard circa early 90's, after significant flaws were identified.
>> 
>> Apple (and others) either have or are moving away from SHA-1 to SHA-2, at 
>> least for TLS/PKI security:
>> 
>>  https://support.apple.com/en-us/HT207459
>> 
>> recognizing the differences between session specific TLS/PKI trust uses and 
>> longer term file integrity checking. I know Linus is more "relaxed" 
>> regarding SHA-1 and the implications for Git, or at least was last year, 
>> albeit indicating a path away from it in time.
>> 
>> I guess the question boils down to, if we are going to provide hashes of the 
>> files under the premise that it should offer a high level of comfort to 
>> useRs that the file has not been modified/replaced since generation, 
>> presuming that the published hash value itself was not altered, I would put 
>> forth for further discussion, moving to SHA-2 and away from both MD5 and 
>> SHA-1 (certainly moving away from SHA-0), depending upon a more broad 
>> assessment of the implications of doing so.
>> 
>> Thanks!
>> 
>> Marc
>> 
>> 
>>> On Apr 25, 2018, at 2:54 PM, Simon Urbanek <simon.urba...@r-project.org> 
>>> wrote:
>>> 
>>> Marc,
>>> 
>>> thanks, the issue is:
>>> 
>>> hagal:R-3.5.0$ openssl sha R-3.5.0-el-capitan-signed.pkg
>>> SHA(R-3.5.0-el-capitan-signed.pkg)= 9f5f3365afee54d3fe3148a60c1405955916f076
>>> 
>>> hagal:R-3.5.0$ openssl sha1 R-3.5.0-el-capitan-signed.pkg
>>> SHA1(R-3.5.0-el-capitan-signed.pkg)= 
>>> 6e90d38892bb366630ae30c223a898e8af84dff7
>>> 
>>> so either we change the label to SHA (or SHA-0?) or change the checksum. In 
>>> the root we actually provide both, even if that may or may not be relevant. 
>>> For now I did the latter in the index.html.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Apr 25, 2018, at 7:57 AM, Marc Schwartz <marc_schwa...@me.com> wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> Last month:
>>>> 
>>>> https://stat.ethz.ch/pipermail/r-sig-mac/2018-March/012691.html
>>>> 
>>>> there was a report that the SHA-1 hash of the R-3.4.4.pkg, as listed on 
>>>> CRAN, was not correct, even though the MD5 hash and the digital signature 
>>>> appeared to be correct.
>>>> 
>>>> The same phenomenon is the case with R-3.5.0.pkg.
>>>> 
>>>> The MD5 hash on CRAN is:
>>>> 
>>>> MD5-hash: 414029c9c9f706d3d04baa887ccffbc4 
>>>> 
>>>> and I get:
>>>> 
>>>> md5 R-3.5.0.pkg
>>>> MD5 (R-3.5.0.pkg) = 414029c9c9f706d3d04baa887ccffbc4
>>>> 
>>>> from the CLI on my Mac.
>>>> 
>>>> However, the SHA-1 hash on CRAN is:
>>>> 
>>>> SHA-hash: 9f5f3365afee54d3fe3148a60c1405955916f076 
>>>> 
>>>> and I get:
>>>> 
>>>> shasum R-3.5.0.pkg
>>>> 6e90d38892bb366630ae30c223a898e8af84dff7  R-3.5.0.pkg
>>>> 
>>>> from the CLI on my Mac.
>>>> 
>>>> It would seem that there is a lingering issue with the generation of the 
>>>> SHA-1 hash value on CRAN.
>>>> 
>>>> 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] SHA-1 Hash for R-3.5.0.pkg Incorrect

[Marc Schwartz]

Hi Simon,

Thanks for the explanation.

It did not occur to me that SHA-0 was being used, since it was withdrawn as a 
standard circa early 90's, after significant flaws were identified.

Apple (and others) either have or are moving away from SHA-1 to SHA-2, at least 
for TLS/PKI security:

  https://support.apple.com/en-us/HT207459 
<https://support.apple.com/en-us/HT207459>

recognizing the differences between session specific TLS/PKI trust uses and 
longer term file integrity checking. I know Linus is more "relaxed" regarding 
SHA-1 and the implications for Git, or at least was last year, albeit 
indicating a path away from it in time.

I guess the question boils down to, if we are going to provide hashes of the 
files under the premise that it should offer a high level of comfort to useRs 
that the file has not been modified/replaced since generation, presuming that 
the published hash value itself was not altered, I would put forth for further 
discussion, moving to SHA-2 and away from both MD5 and SHA-1 (certainly moving 
away from SHA-0), depending upon a more broad assessment of the implications of 
doing so.

Thanks!

Marc


> On Apr 25, 2018, at 2:54 PM, Simon Urbanek <simon.urba...@r-project.org> 
> wrote:
> 
> Marc,
> 
> thanks, the issue is:
> 
> hagal:R-3.5.0$ openssl sha R-3.5.0-el-capitan-signed.pkg
> SHA(R-3.5.0-el-capitan-signed.pkg)= 9f5f3365afee54d3fe3148a60c1405955916f076
> 
> hagal:R-3.5.0$ openssl sha1 R-3.5.0-el-capitan-signed.pkg
> SHA1(R-3.5.0-el-capitan-signed.pkg)= 6e90d38892bb366630ae30c223a898e8af84dff7
> 
> so either we change the label to SHA (or SHA-0?) or change the checksum. In 
> the root we actually provide both, even if that may or may not be relevant. 
> For now I did the latter in the index.html.
> 
> Cheers,
> Simon
> 
> 
> 
> 
> 
>> On Apr 25, 2018, at 7:57 AM, Marc Schwartz <marc_schwa...@me.com> wrote:
>> 
>> Hi All,
>> 
>> Last month:
>> 
>> https://stat.ethz.ch/pipermail/r-sig-mac/2018-March/012691.html
>> 
>> there was a report that the SHA-1 hash of the R-3.4.4.pkg, as listed on 
>> CRAN, was not correct, even though the MD5 hash and the digital signature 
>> appeared to be correct.
>> 
>> The same phenomenon is the case with R-3.5.0.pkg.
>> 
>> The MD5 hash on CRAN is:
>> 
>> MD5-hash: 414029c9c9f706d3d04baa887ccffbc4 
>> 
>> and I get:
>> 
>> md5 R-3.5.0.pkg
>> MD5 (R-3.5.0.pkg) = 414029c9c9f706d3d04baa887ccffbc4
>> 
>> from the CLI on my Mac.
>> 
>> However, the SHA-1 hash on CRAN is:
>> 
>> SHA-hash: 9f5f3365afee54d3fe3148a60c1405955916f076 
>> 
>> and I get:
>> 
>> shasum R-3.5.0.pkg
>> 6e90d38892bb366630ae30c223a898e8af84dff7  R-3.5.0.pkg
>> 
>> from the CLI on my Mac.
>> 
>> It would seem that there is a lingering issue with the generation of the 
>> SHA-1 hash value on CRAN.
>> 
>> 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] SHA-1 Hash for R-3.5.0.pkg Incorrect

[Marc Schwartz]

Hi All,

Last month:

  https://stat.ethz.ch/pipermail/r-sig-mac/2018-March/012691.html

there was a report that the SHA-1 hash of the R-3.4.4.pkg, as listed on CRAN, 
was not correct, even though the MD5 hash and the digital signature appeared to 
be correct.

The same phenomenon is the case with R-3.5.0.pkg.

The MD5 hash on CRAN is:

MD5-hash: 414029c9c9f706d3d04baa887ccffbc4 

and I get:

md5 R-3.5.0.pkg
MD5 (R-3.5.0.pkg) = 414029c9c9f706d3d04baa887ccffbc4

from the CLI on my Mac.

However, the SHA-1 hash on CRAN is:

SHA-hash: 9f5f3365afee54d3fe3148a60c1405955916f076 

and I get:

shasum R-3.5.0.pkg
6e90d38892bb366630ae30c223a898e8af84dff7  R-3.5.0.pkg

from the CLI on my Mac.

It would seem that there is a lingering issue with the generation of the SHA-1 
hash value on CRAN.

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] Embedding PDF documents created in R in Word documents

[Marc Schwartz]

Hi Dennis,

Sounds like it is time to shift the communications to MS support. Perhaps 
providing them with application/OS version details and copies of the relevant 
files will enable some debugging on their end.

Still not sure why I am not experiencing the behavior...

Regards,

Marc


> On Mar 27, 2018, at 1:43 PM, Dennis Fisher <fis...@plessthan.com> wrote:
> 
> Mark
> 
> The two computers that exhibit this are both from 2017.  The one that works 
> correctly is a bit older. 
> Now that it is reasonably clear that R is doing the right thing, the question 
> is how to fix this in Office.
> 
> I just tried one more thing — I have an RTF document with embedded JPEGs that 
> was created on one of the problem computers.  I just opened the document on a 
> fourth computer (purchased in 2013) running El Capitan.   In Word 2016, 
> half-size; in Word 2008, full size.  So, Word appears to be the culprit, 
> although not consistently.
> 
> Dennis
>  
> Dennis Fisher MD
> P < (The "P Less Than" Company)
> Phone / Fax: 1-866-PLessThan (1-866-753-7784)
> www.PLessThan.com <http://www.plessthan.com/>
> 
> 
> 
> 
>> On Mar 27, 2018, at 5:25 PM, Marc Schwartz <marc_schwa...@me.com 
>> <mailto:marc_schwa...@me.com>> wrote:
>> 
>> Interesting.
>> 
>> Given that I am not [yet] experiencing this behavior, which has a retina 
>> display (mid 2014 15-inch MBP), it makes me wonder if there was some level 
>> of corruption in the upgrade to Office via the Autoupdate tool from MS. 
>> Unless both of you have much more recent hardware by chance...
>> 
>> Dennis, have you tried to do an uninstall of Office and a clean re-install?
>> 
>> Regards,
>> 
>> Marc
>> 
>> 
>>> On Mar 26, 2018, at 10:38 PM, Colin A. Smith <co...@colinsmith.org 
>>> <mailto:co...@colinsmith.org>> wrote:
>>> 
>>> Hello,
>>> 
>>> I’m seeing the exact same behavior on my version of Word (16.11.1 - 
>>> 180319). It only happened in the last month or two, so I was suspecting it 
>>> had something to do with this recent change:
>>> 
>>> https://arstechnica.com/gadgets/2018/01/office-for-mac-finally-has-real-time-collaboration-in-16-9-0-update/
>>>  
>>> <https://arstechnica.com/gadgets/2018/01/office-for-mac-finally-has-real-time-collaboration-in-16-9-0-update/>
>>>  
>>> <https://arstechnica.com/gadgets/2018/01/office-for-mac-finally-has-real-time-collaboration-in-16-9-0-update/
>>>  
>>> <https://arstechnica.com/gadgets/2018/01/office-for-mac-finally-has-real-time-collaboration-in-16-9-0-update/>>
>>> 
>>> It seems like that could be pretty a pretty major under the hood change to 
>>> me. I thought it could have something to do retina/non-retina 2X scaling.
>>> 
>>> Cheers,
>>> 
>>> Colin
>>> 
>>>> On Mar 26, 2018, at 16:49, Marc Schwartz <marc_schwa...@me.com 
>>>> <mailto:marc_schwa...@me.com>> wrote:
>>>> 
>>>> Hi Dennis, 
>>>> 
>>>> Very strange.
>>>> 
>>>> Perhaps you might consider completely removing all Office components and 
>>>> doing a fully clean install? 
>>>> 
>>>> If the PDF that I sent exhibited the same behavior as one you create 
>>>> locally, that would tend to suggest that the problem is not your R 
>>>> installation.
>>>> 
>>>> More info here:
>>>> 
>>>> https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3
>>>>  
>>>> <https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3>
>>>>  
>>>> <https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3
>>>>  
>>>> <https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3>>
>>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Marc
>>>> 
>>>>> On Mar 26, 2018, at 3:06 PM, Dennis Fisher <fis...@plessthan.com 
>>>>> <mailto:fis...@plessthan.com>> wrote:
>>>>> 
>>>>> Marc
>>>>> 
>>>>> Office is fully updated (see version as yours)
>>>>> Original size is 1/2 of the intended size.
>>>>> When the drag the file to TextEdit, the size is as intended!
>>&g

Re: [R-SIG-Mac] Embedding PDF documents created in R in Word documents

[Marc Schwartz]

Interesting.

Given that I am not [yet] experiencing this behavior, which has a retina 
display (mid 2014 15-inch MBP), it makes me wonder if there was some level of 
corruption in the upgrade to Office via the Autoupdate tool from MS. Unless 
both of you have much more recent hardware by chance...

Dennis, have you tried to do an uninstall of Office and a clean re-install?

Regards,

Marc


> On Mar 26, 2018, at 10:38 PM, Colin A. Smith <co...@colinsmith.org> wrote:
> 
> Hello,
> 
> I’m seeing the exact same behavior on my version of Word (16.11.1 - 180319). 
> It only happened in the last month or two, so I was suspecting it had 
> something to do with this recent change:
> 
> https://arstechnica.com/gadgets/2018/01/office-for-mac-finally-has-real-time-collaboration-in-16-9-0-update/
>  
> <https://arstechnica.com/gadgets/2018/01/office-for-mac-finally-has-real-time-collaboration-in-16-9-0-update/>
> 
> It seems like that could be pretty a pretty major under the hood change to 
> me. I thought it could have something to do retina/non-retina 2X scaling.
> 
> Cheers,
> 
> Colin
> 
>> On Mar 26, 2018, at 16:49, Marc Schwartz <marc_schwa...@me.com> wrote:
>> 
>> Hi Dennis, 
>> 
>> Very strange.
>> 
>> Perhaps you might consider completely removing all Office components and 
>> doing a fully clean install? 
>> 
>> If the PDF that I sent exhibited the same behavior as one you create 
>> locally, that would tend to suggest that the problem is not your R 
>> installation.
>> 
>> More info here:
>> 
>> https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3
>>  
>> <https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3>
>> 
>> 
>> Regards,
>> 
>> Marc
>> 
>>> On Mar 26, 2018, at 3:06 PM, Dennis Fisher <fis...@plessthan.com> wrote:
>>> 
>>> Marc
>>> 
>>> Office is fully updated (see version as yours)
>>> Original size is 1/2 of the intended size.
>>> When the drag the file to TextEdit, the size is as intended!
>>> So, the mystery continues.
>>> 
>>> Dennis
>>> 
>>> Dennis Fisher MD
>>> P < (The "P Less Than" Company)
>>> Phone / Fax: 1-866-PLessThan (1-866-753-7784)
>>> www.PLessThan.com <http://www.plessthan.com/>
>>> 
>>> 
>>> 
>>> 
>>>> On Mar 26, 2018, at 10:21 AM, Marc Schwartz <marc_schwa...@me.com 
>>>> <mailto:marc_schwa...@me.com>> wrote:
>>>> 
>>>> Hi Dennis,
>>>> 
>>>> I reviewed the Preference settings in Word and did not see anything that 
>>>> to my eye would be relevant to default embedded object sizes.
>>>> 
>>>> You might check to be sure that your Office installation is fully updated. 
>>>> There have been several updates of late. My Word is showing version 
>>>> 16.11.1 (180319) in the About Word dialog.
>>>> 
>>>> Also, right click on the embedded PDF in Word and check "Size and 
>>>> Position...". On the "Size" tab, see what the dialog box is showing for 
>>>> "Original size" at the bottom, and be sure that "Scale" is set to 100% for 
>>>> both height and width.
>>>> 
>>>> Regards,
>>>> 
>>>> Marc
>>>> 
>>>>> On Mar 26, 2018, at 12:01 PM, Dennis Fisher <fis...@plessthan.com 
>>>>> <mailto:fis...@plessthan.com>> wrote:
>>>>> 
>>>>> Marc
>>>>> 
>>>>> Thanks for trying this.  
>>>>> 
>>>>> Your PDF exhibited the problematic behavior (half-size).  It appears that 
>>>>> we are using the same version of the OS.  We are using the same 
>>>>> generation of Word (Office Home & Business 2016 for Mac (Work At Home)) 
>>>>> although there are probably several versions of Office floating around.  
>>>>> This left the version of R — but I can confirm the same problematic 
>>>>> behavior with R 3.4.4.
>>>>> 
>>>>> Of note, this behavior exists on two different OS X machines but a third 
>>>>> computer with OS X 13.2 works correctly.  
>>>>> Also, when I use R to create an RTF document that contains JPEG images, 
>>>>> the same problem happens.  
>>>>> 
>>>>> I am at a loss — per

Re: [R-SIG-Mac] Embedding PDF documents created in R in Word documents

[Marc Schwartz]

Hi Dennis, 

Very strange.

Perhaps you might consider completely removing all Office components and doing 
a fully clean install? 

If the PDF that I sent exhibited the same behavior as one you create locally, 
that would tend to suggest that the problem is not your R installation.

More info here:

  
https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3
 
<https://support.office.com/en-us/article/uninstall-office-2016-for-mac-eefa1199-5b58-43af-8a3d-b73dc1a8cae3>


Regards,

Marc

> On Mar 26, 2018, at 3:06 PM, Dennis Fisher <fis...@plessthan.com> wrote:
> 
> Marc
> 
> Office is fully updated (see version as yours)
> Original size is 1/2 of the intended size.
> When the drag the file to TextEdit, the size is as intended!
> So, the mystery continues.
> 
> Dennis
> 
> Dennis Fisher MD
> P < (The "P Less Than" Company)
> Phone / Fax: 1-866-PLessThan (1-866-753-7784)
> www.PLessThan.com <http://www.plessthan.com/>
> 
> 
> 
> 
>> On Mar 26, 2018, at 10:21 AM, Marc Schwartz <marc_schwa...@me.com 
>> <mailto:marc_schwa...@me.com>> wrote:
>> 
>> Hi Dennis,
>> 
>> I reviewed the Preference settings in Word and did not see anything that to 
>> my eye would be relevant to default embedded object sizes.
>> 
>> You might check to be sure that your Office installation is fully updated. 
>> There have been several updates of late. My Word is showing version 16.11.1 
>> (180319) in the About Word dialog.
>> 
>> Also, right click on the embedded PDF in Word and check "Size and 
>> Position...". On the "Size" tab, see what the dialog box is showing for 
>> "Original size" at the bottom, and be sure that "Scale" is set to 100% for 
>> both height and width.
>> 
>> Regards,
>> 
>> Marc
>> 
>>> On Mar 26, 2018, at 12:01 PM, Dennis Fisher <fis...@plessthan.com 
>>> <mailto:fis...@plessthan.com>> wrote:
>>> 
>>> Marc
>>> 
>>> Thanks for trying this.  
>>> 
>>> Your PDF exhibited the problematic behavior (half-size).  It appears that 
>>> we are using the same version of the OS.  We are using the same generation 
>>> of Word (Office Home & Business 2016 for Mac (Work At Home)) although there 
>>> are probably several versions of Office floating around.  This left the 
>>> version of R — but I can confirm the same problematic behavior with R 3.4.4.
>>> 
>>> Of note, this behavior exists on two different OS X machines but a third 
>>> computer with OS X 13.2 works correctly.  
>>> Also, when I use R to create an RTF document that contains JPEG images, the 
>>> same problem happens.  
>>> 
>>> I am at a loss — perhaps there is something weird about my version of 
>>> Office or some preference that is set incorrectly.
>>> 
>>> Dennis
>>> 
>>> Dennis Fisher MD
>>> P < (The "P Less Than" Company)
>>> Phone / Fax: 1-866-PLessThan (1-866-753-7784)
>>> www.PLessThan.com <http://www.plessthan.com/>
>>> 
>>> 
>>> 
>>> 
>>>> On Mar 26, 2018, at 8:33 AM, Marc Schwartz <marc_schwa...@me.com 
>>>> <mailto:marc_schwa...@me.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Mar 26, 2018, at 11:11 AM, Dennis Fisher <fis...@plessthan.com 
>>>>> <mailto:fis...@plessthan.com>> wrote:
>>>>> 
>>>>> R 3.4.3
>>>>> OS X 13.3
>>>>> 
>>>>> Colleagues
>>>>> 
>>>>> I have encountered surprising behavior in the following circumstance:
>>>>> 
>>>>> 1.  I create a one-page PDF in R.  The command might be:
>>>>>   pdf(“/path/to/file”, width=5, height=3.5)
>>>>> 
>>>>> 2.  When I open the PDF in Preview, the “inspector” confirms the intended 
>>>>> size.
>>>>> 
>>>>> 3.  I embed the PDF into Word for Mac (the newest version).  I accomplish 
>>>>> this in one of several ways, all leading to the same outcome:
>>>>>   a.  I drag the icon into Word
>>>>>   b.  I copy the thumbnail and paste into Word
>>>>>   c.  I drag the thumbnail into Word
>>>>> 
>>>>> 4.  Previously, after the page was embedded, the size matched the 
>>>>> specifications (5 x 3.5, in this instance). Now, the width is one-half of 
>>>>

Re: [R-SIG-Mac] Embedding PDF documents created in R in Word documents

[Marc Schwartz]

Hi Dennis,

I reviewed the Preference settings in Word and did not see anything that to my 
eye would be relevant to default embedded object sizes.

You might check to be sure that your Office installation is fully updated. 
There have been several updates of late. My Word is showing version 16.11.1 
(180319) in the About Word dialog.

Also, right click on the embedded PDF in Word and check "Size and Position...". 
On the "Size" tab, see what the dialog box is showing for "Original size" at 
the bottom, and be sure that "Scale" is set to 100% for both height and width.

Regards,

Marc

> On Mar 26, 2018, at 12:01 PM, Dennis Fisher <fis...@plessthan.com> wrote:
> 
> Marc
> 
> Thanks for trying this.  
> 
> Your PDF exhibited the problematic behavior (half-size).  It appears that we 
> are using the same version of the OS.  We are using the same generation of 
> Word (Office Home & Business 2016 for Mac (Work At Home)) although there are 
> probably several versions of Office floating around.  This left the version 
> of R — but I can confirm the same problematic behavior with R 3.4.4.
> 
> Of note, this behavior exists on two different OS X machines but a third 
> computer with OS X 13.2 works correctly.  
> Also, when I use R to create an RTF document that contains JPEG images, the 
> same problem happens.  
> 
> I am at a loss — perhaps there is something weird about my version of Office 
> or some preference that is set incorrectly.
> 
> Dennis
> 
> Dennis Fisher MD
> P < (The "P Less Than" Company)
> Phone / Fax: 1-866-PLessThan (1-866-753-7784)
> www.PLessThan.com <http://www.plessthan.com/>
> 
> 
> 
> 
>> On Mar 26, 2018, at 8:33 AM, Marc Schwartz <marc_schwa...@me.com 
>> <mailto:marc_schwa...@me.com>> wrote:
>> 
>> 
>> 
>>> On Mar 26, 2018, at 11:11 AM, Dennis Fisher <fis...@plessthan.com 
>>> <mailto:fis...@plessthan.com>> wrote:
>>> 
>>> R 3.4.3
>>> OS X 13.3
>>> 
>>> Colleagues
>>> 
>>> I have encountered surprising behavior in the following circumstance:
>>> 
>>> 1.  I create a one-page PDF in R.  The command might be:
>>> pdf(“/path/to/file”, width=5, height=3.5)
>>> 
>>> 2.  When I open the PDF in Preview, the “inspector” confirms the intended 
>>> size.
>>> 
>>> 3.  I embed the PDF into Word for Mac (the newest version).  I accomplish 
>>> this in one of several ways, all leading to the same outcome:
>>> a.  I drag the icon into Word
>>> b.  I copy the thumbnail and paste into Word
>>> c.  I drag the thumbnail into Word
>>> 
>>> 4.  Previously, after the page was embedded, the size matched the 
>>> specifications (5 x 3.5, in this instance). Now, the width is one-half of 
>>> the intended size.
>>> 
>>> 5.  Interestingly, when I drag the thumbnail into Word, the image appears 
>>> twice
>>> 
>>> I suspect that the problem is in Word, rather than R, but I am curious as 
>>> to whether anyone has encountered this and has a solution.
>>> 
>>> Dennis
>> 
>> 
>> Hi Dennis,
>> 
>> Try it with the attached PDF, created with:
>> 
>> pdf("test.pdf", width = 5, height = 3.5)
>> plot(1:5)
>> dev.off()
>> 
>> I am using R 3.4.4 on macOS 10.13.3, with Word 2016.
>> 
>> When I drag the pdf file from my desktop into Word, or the thumbnail from 
>> Preview, the size of the embedded object is correct and I get the correct 
>> preview image of the plot in Word.
>> 
>> If I copy and paste the thumbnail into Word, it has the correct size, the 
>> but preview image in Word appears to be bitmapped, instead of vector, so the 
>> quality of the image in Word is not as good. Similar to what one might see 
>> embedding an EPS file in Word.
>> 
>> Also, if I "Insert" object from the Word menu, and select the PDF file, I 
>> get the correct size and the vector based image.
>> 
>> Regards,
>> 
>> Marc Schwartz
>> 
>> 
>> 
> 


[[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] Embedding PDF documents created in R in Word documents

[Marc Schwartz]

> On Mar 26, 2018, at 11:11 AM, Dennis Fisher <fis...@plessthan.com> wrote:
> 
> R 3.4.3
> OS X 13.3
> 
> Colleagues
> 
> I have encountered surprising behavior in the following circumstance:
> 
> 1.  I create a one-page PDF in R.  The command might be:
>   pdf(“/path/to/file”, width=5, height=3.5)
> 
> 2.  When I open the PDF in Preview, the “inspector” confirms the intended 
> size.
> 
> 3.  I embed the PDF into Word for Mac (the newest version).  I accomplish 
> this in one of several ways, all leading to the same outcome:
>   a.  I drag the icon into Word
>   b.  I copy the thumbnail and paste into Word
>   c.  I drag the thumbnail into Word
> 
> 4.  Previously, after the page was embedded, the size matched the 
> specifications (5 x 3.5, in this instance). Now, the width is one-half of the 
> intended size.
> 
> 5.  Interestingly, when I drag the thumbnail into Word, the image appears 
> twice
> 
> I suspect that the problem is in Word, rather than R, but I am curious as to 
> whether anyone has encountered this and has a solution.
> 
> Dennis


Hi Dennis,

Try it with the attached PDF, created with:

pdf("test.pdf", width = 5, height = 3.5)
plot(1:5)
dev.off()

I am using R 3.4.4 on macOS 10.13.3, with Word 2016.

When I drag the pdf file from my desktop into Word, or the thumbnail from 
Preview, the size of the embedded object is correct and I get the correct 
preview image of the plot in Word.

If I copy and paste the thumbnail into Word, it has the correct size, the but 
preview image in Word appears to be bitmapped, instead of vector, so the 
quality of the image in Word is not as good. Similar to what one might see 
embedding an EPS file in Word.

Also, if I "Insert" object from the Word menu, and select the PDF file, I get 
the correct size and the vector based image.

Regards,

Marc Schwartz




test.pdf
Description: Adobe PDF document
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] Opening single Terminal window and running syntax sequentially from R

[Marc Schwartz]

> On Jan 10, 2018, at 12:18 PM, Christofer Bogaso <bogaso.christo...@gmail.com> 
> wrote:
> 
> Hi,
> 
> I have an .app file saved in Harddisk, which I want to run from R. So
> below is the code which I use:
> 
> system("open '.../My_File.app'")
> 
> However, if I run above code multiple times (sequentially) then each
> time a new Terminal window opens that make my system cluttered.
> 
> So I wonder if there is any way to use a single Terminal window and
> run above code sequentially there only. R should search if any
> Terminal window is already open and then run syntax on that Terminal
> window only.
> 
> Any pointer will be highly appreciated.
> 
> Thanks,


Hi,

My initial reaction is that this is outside of R per se and more specific to 
macOS in terms of how the application is opened at the CLI, runs and then is 
exited/closed, before the next instance is run.

I would do a Google search on keywords along the lines of "macOS scripting" 
and/or "macOS open command".

One possibility would be to use the '-W' option for open, which theoretically 
will force the initial call to wait for the first application instance to be 
closed/exited before returning.

For example, compare the behaviors of:

  system("open -a TextEdit")

versus:

  system("open -W -a TextEdit")

from an R terminal session.

So, depending upon your actual workflow requirements, you may wish to consider 
using the system() function with a different call, or perhaps create a shell 
script that can be called via system(), rather than the actual single command, 
where the shell script can contain a sequence of CLI commands that are relevant 
to your workflow.

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

[Marc Schwartz]

Hi,

FWIW, the key R related issue with High Sierra, fixed in 3.4.3, relates to the 
setting of the time zone in R.

An easy work around was posted some time ago, which is to put:

  Sys.setenv(TZ = "YourTime/Zone")

in your ~/.Rprofile, so that the TZ is set with a new R session.

A list of TZ's is available here:

  https://en.wikipedia.org/wiki/List_of_tz_database_time_zones 
<https://en.wikipedia.org/wiki/List_of_tz_database_time_zones>

Regards,

Marc Schwartz


> On Dec 6, 2017, at 8:27 AM, peter dalgaard <pda...@gmail.com> wrote:
> 
> Homebrew is not particularly unrecommended either, but you could get in 
> trouble with compatibility vs. CRAN package binaries. "Unsupported" is more 
> precise: None of us are trying these builds so if they break, you could be on 
> your own. (From the Open Source perspective, the more people who know how to 
> deal with R at source code level, the better; and homebrew does appear to 
> have a substantially better reputation than the older MacPorts system did.)
> 
> From that point of view it could be easier for you just to grab R-patched 
> from r.research.att.com. Those binaries are unsigned, though, so you need to 
> make a leap of trust that noone has hacked their way in and replaced the 
> binaries since they were built. Pragmatically you need to download, open the 
> Downloads folder (in Finder!), right-click the package, choose to use 
> Installer.app, and accept to open it even though yadayadayada in the dialogue 
> window.
> 
> -pd
> 
>> On 6 Dec 2017, at 11:24 , Luis Puerto <luiss.pue...@gmail.com> wrote:
>> 
>> Hi Federico, 
>> 
>> I know that it isn’t recommended by R Core Group, but you can always instal 
>> it from source using Homebrew. I’ve believe that there is even a bottle 
>> already and you don’t need to compile. I’m not sure. 
>> 
>> I’ve using a pure Homebrew install in my Mac and runs faster then the CRAN 
>> one, with openBlas and OpenMP.  
>> 
>>> On 6 Dec 2017, at 11:26, Federico Calboli <federico.calb...@helsinki.fi> 
>>> wrote:
>>> 
>>> Hi All,
>>> 
>>> I know that I can get the latest and greatest binaries from 
>>> http://r.research.att.com/ but I am puzzled why there are still no OSX R 
>>> 3.4.3 binaries on CRAN.  The Windows installer has been up a few days 
>>> already.  Is there anything I am missing concerning this delay?  
>>> 
>>> Cheers
>>> 
>>> F


[[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] Executing iOS system code within R

[Marc Schwartz]

I was kind of wondering that myself...given the frequent prior discussions here 
regarding running R on iOS... :-)

My recommendation would be to use R's built in file/folder/path related 
functionality, such as:

  ?getwd (which includes ?setwd)

  ?list.files

  ?file.info

  ?files

and other related functions listed under the "See Also" sections of those help 
pages.

You can use getwd() to store the current working directory in a vector, execute 
whatever system() level commands you need to, then restore the current working 
directory to the original:

  CurrDir <- getwd()

  system(YourSystemLevelCallsHere)

  setwd(CurrDir)



Regards,

Marc Schwartz



> On Oct 10, 2017, at 2:05 PM, Christofer Bogaso <bogaso.christo...@gmail.com> 
> wrote:
> 
> Yes macOS - High Sierra
> 
> On Tue, Oct 10, 2017 at 11:33 PM, elijah wright <e...@stderr.org> wrote:
>> Did you mean macOS?  I am not aware of anything that can run both R
>> and iOS code - if there's some fancy thing out there that can, i would
>> like to know about that.  ;-)
>> 
>> --e
>> 
>> 
>> On Tue, Oct 10, 2017 at 12:58 PM, Christofer Bogaso
>> <bogaso.christo...@gmail.com> wrote:
>>> Hi again,
>>> 
>>> I need to execute few line of system codes for iOS from R. Basically
>>> that execution involves (as an example) :
>>> 
>>> 1. Change the Working directory first
>>> 2. Execute some task (e.g.deleting a file)
>>> 3. Then go back to original folder/directory
>>> 
>>> I am aware of system() function which can be used here. However it
>>> looks that system() function executes iOS code one-by-one i.e. after I
>>> execute system('cd .') for #1 above, that changed directory is not
>>> passed for #2 and so on.
>>> 
>>> Is there any way where I can run a chain on iOS code as-a-whole using R.
>>> 
>>> Your help will be highly appreciated.
>>> 
>>> Thanks for your time.
>>> 
>>> ___
>>> 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] Permanently fix R to open Help page in html

[Marc Schwartz]

Hi Christofer,

Here is the content of my fairly simple .Rprofile:

options(help_type = "html")
local({r <- getOption("repos")
   r["CRAN"] <- "http://cran.us.r-project.org;
   options(repos=r)
})
options(papersize = "letter")
options(show.signif.stars = FALSE)
options(device = "quartz")
options(width = 72)


Note that I do not have a .First function defined and HTML based help works 
just fine for me in a Terminal session.

The setting of my CRAN repo is based upon the examples in ?Startup.

Another thought, which may be a long shot. Check to see if there is a .RData 
file in your home directory and if so, move it to the Desktop or some other 
location and try a new R session without it being present. Alternatively start 
a new R session from the Terminal using:

  R --no-restore-data

It may be possible that there is some level of corruption in the .RData file or 
something was saved in the image file from a prior session that is causing a 
conflict.

Regards,

Marc

> On Jul 11, 2017, at 10:55 AM, Christofer Bogaso <bogaso.christo...@gmail.com> 
> wrote:
> 
> Hi Marc,
> 
> When I enter 'open -a Textedit ~/.Rprofile' in Terminal .RProfie file
> opens. Below is the content of that file :
> 
> .First <- function() {
>options("repos" = c(CRAN = "http://cran.r-project.org/;))
>options(help_type = "html")
> }
> 
> An the R window looks like below :
> 
> R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
> 
> Copyright (C) 2017 The R Foundation for Statistical Computing
> 
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> 
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> 
> You are welcome to redistribute it under certain conditions.
> 
> Type 'license()' or 'licence()' for distribution details.
> 
> 
>  Natural language support but running in an English locale
> 
> 
> R is a collaborative project with many contributors.
> 
> Type 'contributors()' for more information and
> 
> 'citation()' on how to cite R or R packages in publications.
> 
> 
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 
> 'help.start()' for an HTML browser interface to help.
> 
> Type 'q()' to quit R.
> 
> 
> [Previously saved workspace restored]
> 
> 
>> ?sum
> 
> starting httpd help server ... done
> 
>> 
> 
> 
> Please let me know if you need anything else.
> 
> Thanks,
> 
> On Tue, Jul 11, 2017 at 8:29 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
>> Christofer,
>> 
>> The thing is that you really don't need to do that (use .First), which makes 
>> this situation curious and why it would be helpful to see the full content 
>> of your .Rprofile file, to be sure that there is not a conflict in content 
>> or structure someplace.
>> 
>> An extra set of eyes might be helpful.
>> 
>> Marc
>> 
>>> On Jul 11, 2017, at 9:52 AM, Christofer Bogaso 
>>> <bogaso.christo...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I just put options(help_type = "html") inside .First <- function() {}
>>> and now it works. Help page is now opening in Browser.
>>> 
>>> Thanks all for your time and help. Regards,
>>> 
>>> 

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

Re: [R-SIG-Mac] Permanently fix R to open Help page in html

[Marc Schwartz]

Christofer,

The thing is that you really don't need to do that (use .First), which makes 
this situation curious and why it would be helpful to see the full content of 
your .Rprofile file, to be sure that there is not a conflict in content or 
structure someplace.

An extra set of eyes might be helpful.

Marc

> On Jul 11, 2017, at 9:52 AM, Christofer Bogaso <bogaso.christo...@gmail.com> 
> wrote:
> 
> Hi,
> 
> I just put options(help_type = "html") inside .First <- function() {}
> and now it works. Help page is now opening in Browser.
> 
> Thanks all for your time and help. Regards,
> 
> 
> 
> On Tue, Jul 11, 2017 at 8:21 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
>> Christofer,
>> 
>> Can you post your .Rprofile file someplace online (e.g. Dropbox) so that we 
>> can take a look at it?
>> 
>> Marc
>> 
>> 
>>> On Jul 11, 2017, at 9:48 AM, Christofer Bogaso 
>>> <bogaso.christo...@gmail.com> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> I work with R from Terminal only.
>>> 
>>> If I explicitly set ' options(help_type = 'html')' after opening R in
>>> terminal, it works perfectly. Means, help page opens in Browser.
>>> 
>>> However I do not want to have this code ' options(help_type = 'html')'
>>> every time I open R. So I want R to set this option all time. Thats
>>> why I chose to create .RProfile file and put that code there. However
>>> in that case, it is not working.
>>> 
>>> Below is the snapshot like yours :
>>> 
>>> R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
>>> 
>>> Copyright (C) 2017 The R Foundation for Statistical Computing
>>> 
>>> Platform: x86_64-apple-darwin15.6.0 (64-bit)
>>> 
>>> 
>>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>>> 
>>> You are welcome to redistribute it under certain conditions.
>>> 
>>> Type 'license()' or 'licence()' for distribution details.
>>> 
>>> 
>>> Natural language support but running in an English locale
>>> 
>>> 
>>> R is a collaborative project with many contributors.
>>> 
>>> Type 'contributors()' for more information and
>>> 
>>> 'citation()' on how to cite R or R packages in publications.
>>> 
>>> 
>>> Type 'demo()' for some demos, 'help()' for on-line help, or
>>> 
>>> 'help.start()' for an HTML browser interface to help.
>>> 
>>> Type 'q()' to quit R.
>>> 
>>> 
>>> [Previously saved workspace restored]
>>> 
>>> 
>>>> ?sum
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> sumpackage:baseR Documentation
>>> 
>>> 
>>> Sum of Vector Elements
>>> 
>>> 
>>> Description:
>>> 
>>> 
>>>‘sum’ returns the sum of all the values present in its arguments.
>>> 
>>> 
>>> Usage:
>>> 
>>> 
>>>sum(..., na.rm = FALSE)
>>> 
>>> 
>>> 
>>> On Tue, Jul 11, 2017 at 7:45 PM, Ben Tupper <btup...@bigelow.org> wrote:
>>>> Hi,
>>>> 
>>>> I'm curious about what happens if you start a plain R session at the 
>>>> command line (not R.app) and set the option within the session.  Something 
>>>> like the following that open help in my browser.
>>>> 
>>>> $ R --vanilla
>>>> 
>>>> R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
>>>> Copyright (C) 2016 The R Foundation for Statistical Computing
>>>> Platform: x86_64-apple-darwin13.4.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 i

Re: [R-SIG-Mac] Permanently fix R to open Help page in html

[Marc Schwartz]

Christofer,

Can you post your .Rprofile file someplace online (e.g. Dropbox) so that we can 
take a look at it?

Marc


> On Jul 11, 2017, at 9:48 AM, Christofer Bogaso <bogaso.christo...@gmail.com> 
> wrote:
> 
> Hi Ben,
> 
> I work with R from Terminal only.
> 
> If I explicitly set ' options(help_type = 'html')' after opening R in
> terminal, it works perfectly. Means, help page opens in Browser.
> 
> However I do not want to have this code ' options(help_type = 'html')'
> every time I open R. So I want R to set this option all time. Thats
> why I chose to create .RProfile file and put that code there. However
> in that case, it is not working.
> 
> Below is the snapshot like yours :
> 
> R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
> 
> Copyright (C) 2017 The R Foundation for Statistical Computing
> 
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> 
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> 
> You are welcome to redistribute it under certain conditions.
> 
> Type 'license()' or 'licence()' for distribution details.
> 
> 
>  Natural language support but running in an English locale
> 
> 
> R is a collaborative project with many contributors.
> 
> Type 'contributors()' for more information and
> 
> 'citation()' on how to cite R or R packages in publications.
> 
> 
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 
> 'help.start()' for an HTML browser interface to help.
> 
> Type 'q()' to quit R.
> 
> 
> [Previously saved workspace restored]
> 
> 
>> ?sum
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> sumpackage:baseR Documentation
> 
> 
> Sum of Vector Elements
> 
> 
> Description:
> 
> 
> ‘sum’ returns the sum of all the values present in its arguments.
> 
> 
> Usage:
> 
> 
> sum(..., na.rm = FALSE)
> 
> 
> 
> On Tue, Jul 11, 2017 at 7:45 PM, Ben Tupper <btup...@bigelow.org> wrote:
>> Hi,
>> 
>> I'm curious about what happens if you start a plain R session at the command 
>> line (not R.app) and set the option within the session.  Something like the 
>> following that open help in my browser.
>> 
>> $ R --vanilla
>> 
>> R version 3.3.1 (2016-06-21) -- "Bug in Your Hair"
>> Copyright (C) 2016 The R Foundation for Statistical Computing
>> Platform: x86_64-apple-darwin13.4.0 (64-bit)
>> 
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>> 
>>  Natural language support but running in an English locale
>> 
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>> 
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>> 
>>> options(help_type = 'html')
>>> ?source
>> starting httpd help server ... done
>> 
>> Ben
>> 
>> 
>> 
>> 
>> 
>>> On Jul 11, 2017, at 10:10 AM, Christofer Bogaso 
>>> <bogaso.christo...@gmail.com> wrote:
>>> 
>>> I am not getting error.
>>> 
>>> However help page is not opening in html.
>>> 
>>> On Tue, Jul 11, 2017 at 5:16 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
>>>> 
>>>>> On Jul 10, 2017, at 10:33 PM, Christofer Bogaso 
>>>>> <bogaso.christo...@gmail.com> wrote:
>>>>> 
>>>>> Performed steps according to Marc's suggestions :
>>>>> 
>>>>> But not help page is not openning in Browser.
>>>> 
>>>> 
>>>> Are you getting the same error as before?
>>>> 
>>>> Do the single quotes still look like smart quotes or regular ASCII quotes?
>>>> 
>>>> Marc
>>>> 
>>>> 
>>>>> 
>>>>> On Tue, Jul 11, 2017 at 7:28 AM, Marc Schwartz <marc_schwa...@me.com> 
>>>>> wrote:
>>>>>> 
>>>>>>> On Jul 10, 2017, at 5:19 PM, Duncan Murdoch <murdoch.dun...@gmail.com> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> On 10/07/2017 5:02 P

Re: [R-SIG-Mac] Permanently fix R to open Help page in html

[Marc Schwartz]

> On Jul 10, 2017, at 5:19 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
> 
> On 10/07/2017 5:02 PM, Christofer Bogaso wrote:
>> Hi,
>> 
>> I wanted R to open any Help page in html permanently.
>> 
>> So 1st I created .Rprofile file with below code in terminal:
>> 
>> touch ~/.Rprofile
>> 
>> open -a Textedit ~/.Rprofile
>> 
>> 
>> And then in the .Rprofile file, I wrote below code :
>> 
>> options(help_type = ‘html’)
>> 
>> However after that when I start R (from Terminal) I get below error on 
>> loading R
>> 
>> Error: 1:20: unexpected input
>> 
>> 1: options(help_type = ?
>> 
>>   ^
> 
> Those don't look like ASCII quotes.  Use the R.app editor, not Textedit, and 
> it won't put in funny "smart quotes".


Alternatively, you can set TextEdit to not use "Smart quotes"  by disabling 
them in:

  Preferences -> New Document

There is a checkbox under Options for Smart quotes. Uncheck it.

Regards,

Marc Schwartz


> 
> Duncan Murdoch
> 
>> 
>> [Previously saved workspace restored]
>> 
>> 
>>> 
>> 
>> Can someone please point me on where I made mistake.
>> 
>> Thanks for your time.

___
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.4.1 precompiled binary for Mac?

[Marc Schwartz]

> On Jul 6, 2017, at 4:21 PM, MacQueen, Don <macque...@llnl.gov> wrote:
> 
> Sorry, I first sent this to
>   r-sig-mac-boun...@r-project.org
> by mistake. Apologies for any spam-like effect.
> -Don
> 
> Hi, the newest precompiled binary for Mac that I have been able to find on a 
> CRAN mirror is 3.4.0. This wouldn’t be much of a concern; I don’t mind 
> waiting. Except that:
> 
> (running in R 3.4.0)
> 
> require(sp)
> Loading required package: sp
> Warning message:
> package 'sp' was built under R version 3.4.1
> 
> So, what are the prospects for a 3.4.1 binary on CRAN? Or am I somehow doing 
> something wrong? I’ve hit “Refresh” many times in my browser. Or am I just 
> being impatient? (only about a week since R 3.4.1 was released)
> 
> 
> The sp package was a binary install:
> 
> install.packages('sp')
> Installing package into '/Users/macqueen1/Library/R/3.4/library'
> (as 'lib' is unspecified)
> --- Please select a CRAN mirror for use in this session ---
> trying URL 
> 'https://cran.cnr.berkeley.edu/bin/macosx/el-capitan/contrib/3.4/sp_1.2-5.tgz'
> Content type 'application/x-gzip' length 1545668 bytes (1.5 MB)
> ==
> downloaded 1.5 MB
> 
> The downloaded binary packages are in
>
> /var/folders/ts/p_9qz7b54kb5sy2sfs7vtdwh001k0_/T//RtmpXfXSP3/downloaded_packages
> 
> 
> 
> Thanks
> -Don



Hi Don,

I would imagine that it should be up soon. 

I might expect that with useR! 2017 going on in Brussels this week, along with 
DSC and R Foundation meetings, the binary build process for 3.4.1 may be 
delayed.

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] Experiences with macOS Sierra

[Marc Schwartz]

Hi All,

In follow up to my post yesterday and subsequent to an offline exchange with 
Rodney, I am posting some additional information that I located today.

First, for those who may be having scrolling issues with Logitech mice 
specifically under Sierra, there are some known issues as reported here:

  http://www.macrumors.com/2016/09/22/wrecked-scrolling-logitech-mice/ 
<http://www.macrumors.com/2016/09/22/wrecked-scrolling-logitech-mice/>

with an update to the LCC apparently posted by Logitech yesterday here:

  
http://support.logitech.com/en_us/software/logitech-control-center-for-macintosh-os-x
 
<http://support.logitech.com/en_us/software/logitech-control-center-for-macintosh-os-x>

That is not relevant to my scrolling issues, as I have Apple TrackPads both 
internally and externally, but this may be helpful to Logitech users.

That being said, today I found the following posts in the Apple Support 
Community Forums:

  https://discussions.apple.com/thread/7659385?start=0=0 
<https://discussions.apple.com/thread/7659385?start=0=0>

and:

  https://discussions.apple.com/thread/7679256?start=0=0 
<https://discussions.apple.com/thread/7679256?start=0=0>

which would seem to suggest some application specific hypersensitive scrolling 
and other issues. So the issue with Emacs/ESS that I observe may not be unique 
given these other reports and may support the notion of a Sierra issue. 

For those using Emacs, I now have the following in my .emacs file:

  (setq mouse-wheel-scroll-amount '(1 ((shift) . 1) ((control) . nil))) ;; one 
line at a time  
  (setq mouse-wheel-progressive-speed nil) ;; 'nil' for do not accelerate 
scrolling
  (setq mouse-wheel-follow-mouse 't) ;; scroll window under mouse
  (setq scroll-step 1) ;; keyboard scroll one line at a time

Note that the second line above disables scroll acceleration in Emacs, which is 
a double-edged sword. It makes scrolling tolerable as compared to having 
acceleration enabled, however for long source files, it is far too slow.

I also tried adjusting:

  (setq scroll-conservatively 10)

with acceleration enabled, where larger numbers are supposed to aid in 
smoothing scrolling, but it has no apparent effect on the behavior I observe.

I am still experimenting with other settings but have not found anything that 
comes close to desired behavior. One option, with acceleration disabled, is to 
increase the number of lines scrolled in the first line to something like:

  (setq mouse-wheel-scroll-amount '(3 ((shift) . 1) ((control) . nil))) ;; 
three lines at a time

but scrolling becomes "jumpier" as that first number increases, so use with 
caution. The number after '(shift) .' affects the speed of scrolling with the 
SHIFT key pressed.

Hope that this may be helpful to some.

Regards,

Marc Schwartz
[[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] Experiences with macOS Sierra

[Marc Schwartz]

> On Sep 22, 2016, at 1:39 AM, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote:
> 
> So far I have encountered few problems.  R.app runs but I do not normally use 
> it so my tests were minimal.
> 
> My observations are about installing packages from source.
> 
> - It seems Apple has been tidying up, and I had ca 20GB more free space after 
> upgrading (which is worthwhile on my MBA with a 128GB SSD).  It seems that 
> includes removing some headers, including those for openssl (used by packages 
> PKI and RSclient - package opensssl uses its own). This is but the latest 
> instance in a long-term trend, e.g. iodbc, pcre and liblzma have libraries 
> but no headers.
> 
> - Finally the POSIX 2008 function clock_gettime is supported (and will be 
> used by R): but package scrypt calls it incorrectly.
> 
> Xcode 8 is available for EL Capitan but I would caution against using it 
> there (despite it being pushed as an update from the AppStore).  AFAICS (and 
> googling will find other reports) it defaults to the macOS 10.12 SDK and that 
> declares functions such as clock_gettime not available in El Capitan.  (I 
> believe that R checks thoroughly enough not to be caught by this.)
> 
> There is a further problem with Xcode 8, also seen on Sierra.  Packages using 
> xml2-config (such as XML) fail to install.  Apple modified xml2-config to 
> look on the SDK path, which means packages using it attempt to link to .tbd 
> files rather than .dylibs.  Which should be OK but the supplied .tbd attempt 
> to link to libraries removed in Sierra and so linking fails. (This is not a 
> problem with the version 8 of the Command Line Tools, only available for 
> Sierra.)
> 
> -- 
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford


Thanks Prof. Ripley.

Just to add another voice, I have not had any issues with R under Sierra.

I did a clean install of R 3.3.1, after completely deleting the prior 
installation. I then re-installed XQuartz and installed a fairly substantial 
number of CRAN packages, which includes RODBC installed from source.

I do not typically use the default R GUI, but use ESS. In the latter case, I am 
now using Emacs 25.1 and the only issue that I have had so far, is that 
vertically scrolling a large file using either the built-in TrackPad on my 
MacBook Pro or my external TrackPad, results in overly sensitive scrolling. I 
barely need to move my fingers on the TrackPad and the file buffer scrolls a 
very large amount rapidly. I tried this using Emacs 24.5 and the behavior is 
the same, so this is not unique to Emacs 25.1 and seems to be a change under 
Sierra. 

A Google search, so far, does not reveal any reports on this and I do not have 
this behavior in any other apps. I have made some temporary changes to my 
.emacs file relative to scrolling, which helps to slow scrolling, but it is not 
ideal yet. There are no settings pertaining to the TrackPad in System 
Preferences that appear to be relevant.

I will keep playing around with this and perhaps post to the Emacs support 
list, as it is not clear if there is a bug in Sierra causing this, or there is 
a need for a change in Emacs itself or .emacs settings relative to scrolling to 
modify this behavior. There are posts on the Emacs list where folks were using 
Sierra betas, but no mention of this behavior as far as I can see.

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] Lost Library ?

[Marc Schwartz]

> On Sep 7, 2016, at 7:18 AM, Roger Koenker <rkoen...@illinois.edu> wrote:
> 
> 
> 
>> On Sep 7, 2016, at 2:13 AM, Rainer M Krug <rai...@krugs.de> wrote:
>> 
>> Roger Koenker <rkoen...@illinois.edu> writes:
>> 
>> 
>> This indicates, that you installed gurobi using homebrew?
> 
> No, I don’t use homebrew,  it was installed from the dmg downloaded
> from the gurobi website.
>> 
>> How did you install the R package? Did you install it as a binary? If
>> yes, then install it type="source" so that it is compiled with the
>> correct library paths.
> 
> The gurobi download includes a mac binary and I installed that — as
> far as I can tell there is no publicly available source version.
>> 
>> If both assumptions are wrong: how did you install R, gurobi and the R
>> packages?
>> 
>> Cheers,
>> 
>> Rainer
>> 


Roger,

According to this PDF:

  http://www.gurobi.com/documentation/6.5/quickstart_mac.pdf

there appears to be instructions on page 88 pertaining to R and for installing 
a source package for Linux in addition to the Mac binary (.tgz). So there does 
appear to be some availability of a source version.

Since the package appears to be from a third party who is a commercial vendor 
at some level, as Rainer noted, it may be prudent to contact them directly or 
via their Google support group.

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] Help files not available

[Marc Schwartz]

Hi,

Did you folks re-install R (and XQuartz) after upgrading to El Capitan?

As per the R Installation and Administration manual:

https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Installing-R-under-OS-X

"If you update your OS X version, you should re-install R (and perhaps 
XQuartz): the installer tailors the installation to the current version of the 
OS."


I am running El Capitan with R 3.2.3 and although I don't use the default GUI 
(I use ESS), I can run the GUI and get help files without issue.

Regards,

Marc Schwartz


> On Feb 25, 2016, at 5:42 PM, Josh Izzard <josh.izz...@gmail.com> wrote:
> 
> I also have this problem, I do not know what it is from
> 
> On Wednesday, February 10, 2016 at 11:44:24 PM UTC-5, Gray, Joshua wrote:
> I am having trouble with my R installation after upgrading to El Capitan 
> (although the timing could be entirely coincidental). The help files are not 
> available, for instance: 
> 
> > help("lm") 
> 
> Opens the help window in the R GUI, but the message there is: Error in 
> file(out, "wt") : cannot open the connection 
> 
> Similarly: 
> 
> > ?lm 
> Warning message: 
> In file(out, "wt") : 
>   cannot open file 
> '/var/folders/68/x1590pm56yvbbhrkcshd1_ywgn/T//RtmpJfjb7P/Rhttpd3bb208bacf':
>  No such file or directory 
> > 
> 
> The problem persists after a restart of R and the computer. 
> 
> Installation details: R 3.2.1 GUI 1.66 Mavericks build 
> System details: OS X 10.11.1 
> 
> Thanks in advance for your help 

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

Re: [R-SIG-Mac] Setting locale for running R in emacs / ess

[Marc Schwartz]

> On Oct 23, 2015, at 5:33 AM, Rainer M Krug <rai...@krugs.de> wrote:
> 
> Hi
> 
> I installed R via homebrew, but it should be the same for the normal R
> installation.
> 
> When I start R in emacs, I get these unset locale warnings:
> 
> ,
> | During startup - Warning messages:
> | 1: Setting LC_CTYPE failed, using "C" 
> | 2: Setting LC_COLLATE failed, using "C" 
> | 3: Setting LC_TIME failed, using "C" 
> | 4: Setting LC_MESSAGES failed, using "C" 
> | 5: Setting LC_MONETARY failed, using "C" 
> | > > options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient', 
> show.error.locations=TRUE)
> | > sessionInfo()
> | R version 3.2.2 (2015-08-14)
> | Platform: x86_64-apple-darwin14.5.0 (64-bit)
> | Running under: OS X 10.11 (El Capitan)
> | 
> | locale:
> | [1] C
> | 
> | attached base packages:
> | [1] stats graphics  grDevices utils datasets  methods   base 
> | > version
> |_   
> | platform   x86_64-apple-darwin14.5.0   
> | arch   x86_64  
> | os darwin14.5.0
> | system x86_64, darwin14.5.0
> | status 
> | major  3   
> | minor  2.2 
> | year   2015
> | month  08  
> | day14  
> | svn rev69053   
> | language   R   
> | version.string R version 3.2.2 (2015-08-14)
> | nickname   Fire Safety 
> | > 
> `
> 
> But I have the following in my .emacs file which should set the locales
> (as far as I know)
> 
> ,
> | (setq utf-translate-cjk-mode nil) ; disable CJK coding/encoding 
> (Chinese/Japanese/Korean characters)
> | (set-language-environment 'utf-8)
> | ;; (set-keyboard-coding-system 'utf-8-mac) ; For old Carbon emacs on OS X 
> only
> | (setq locale-coding-system 'utf-8)
> | (set-default-coding-systems 'utf-8)
> | (set-terminal-coding-system 'utf-8)
> | (unless (eq system-type 'windows-nt)
> |   (set-selection-coding-system 'utf-8))
> | (prefer-coding-system 'utf-8)
> `
> 
> which apparently does not work.
> 
> Do I have to resort to setting the locales as described at
> http://stackoverflow.com/questions/30264526/why-does-my-ess-r-session-fall-back-to-c-locale
> 
> or am I missing something?
> 
> Thanks,
> 
> Rainer


Rainer,

Download exec-path-from-shell.el from:

  https://github.com/purcell/exec-path-from-shell

and place it where you may have other Emacs related add ins.

Then, in your ~/.emacs file, add:

  (load "/PATH.TO/exec-path-from-shell")
  (exec-path-from-shell-initialize)

Replacing PATH.TO with the actual path to the exec-path-from-shell.el file.

You should remove the other lines pertaining to locales that you have above.

That should help Emacs/ESS started from the GUI/dock pick up the environment 
that you would normally have in a terminal session of R.

Also, in case you are not aware, there is a dedicated ESS list here:

  https://stat.ethz.ch/mailman/listinfo/ess-help


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] “pdflatex is not available” from “R CMD check”

[Marc Schwartz]

On Jan 26, 2015, at 6:20 PM, Spencer Graves spencer.gra...@prodsyse.com wrote:
 
 Hello:  
 
 
 What should I do to diagnose and fix “pdflatex is not available” from 
 “R CMD check” on a Mac running OS X 10.10.1 (see below for more details 
 including sessionInfo.)?  
 
 
 A blog on Building R packages: missing path to pdflatex” 
 (http://www.r-bloggers.com/building-r-packages-missing-path-to-pdflatex/ 
 http://www.r-bloggers.com/building-r-packages-missing-path-to-pdflatex/) 
 suggested the following:  
 
 
 Sys.which(pdflatex”) 
 #  
 Sys.getenv(PATH)
 # [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin”
 
 
 However, the suggested fix did not work for me.  
 
 
   1.  How can I determine if pdflatex is installed?  
 
 
   2.  If it is, how can I find it?  If it’s not, what i the 
 recommended install procedure?  
 
 
 Thanks 
 Spencer Graves
 
 
 ##
 
 
 R CMD check … 
 ...
 * checking PDF version of manual ... WARNING
 LaTeX errors when creating PDF version.
 This typically indicates Rd problems.
 * checking PDF version of manual without hyperrefs or index ... ERROR
 Re-running with no redirection of stdout/stderr.
 Hmm ... looks like a package
 Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  : 
  pdflatex is not available
 Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  : 
  pdflatex is not available
 Error in running tools::texi2pdf()
 You may want to clean up by 'rm -rf 
 /var/folders/mh/mrm_14nx19g13lsnj9zmvwjrgn/T//RtmpjOTCtB/Rd2pdf1651fa89c1’


Spencer,

First question would be, have you installed MacTex, which includes all the 
required components?

If not, then visit:

  https://tug.org/mactex/

MacTex 2014 is the current version. There are also some Yosemite specific notes 
here:

  http://www.tug.org/mactex/yosemite.html

The package should modify your $PATH upon installation, so that it includes:

  /usr/texbin

and Sys.which(pdflatex) in the R console run from the OS X terminal should 
return:

 Sys.which(pdflatex) 
  pdflatex 
/usr/texbin/pdflatex 


I would check:

  $PATH

and:

  which pdflatex

from the OS X terminal (not in an R session), just to be sure that you don't 
get different results there, as compared to what you are getting in R. In 
theory, the OS X terminal should provide the definitive response, whereas 
running some applications/GUI's, may not pick up (inherit) the system path.

You can also check:

  ls /usr/texbin

which contains links to the actual installation in:

  ls /usr/local/texlive/2014/bin/x86_64-darwin

to see if MacTex 2014 has been installed (it should show a large number of 
files and links, including pdflatex). If you have a prior version, then the 
path would be:

  ls /usr/local/texlive//...


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] poor quality png/tiff/pdf on mac

[Marc Schwartz]

Hi,

I am presuming that the PNG file that was attached to the original post by Mark 
is a screen cap and not the original file created by R.

If so, you might review the following R FAQ:

  http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-are-there-unwanted-borders

Regards,

Marc Schwartz


 On Nov 5, 2014, at 2:24 AM, Colin A. Smith co...@colinsmith.org wrote:
 
 Hi Mark,
 
 I assume you’re using a Mac. This problem comes from the way Quartz renders 
 immediately adjacent filled polygons. To get around it, you can add 
 type=“cairo” or type=“Xlib” as an argument to the tiff, png, or jpeg call. If 
 you really want to make a PDF, I can post those instructions to the list, but 
 it is a bit more involved and uses some custom code I’ve written.
 
 Cheers,
 
 Colin
 
 PS: I would avoid cross-posting to multiple lists in the future. That’s 
 generally frowned upon.
 
 On Nov 5, 2014, at 4:14, M P mzp3...@gmail.com wrote:
 
 Hello,
 I cannot fix image quality e.g. generated with filled.contour(). Whether I 
 use tiff, png, jpeg, or pdf I always see vertical and horizontal lines at 
 every grid increment on the plots like the attached. There is no problem 
 when I plot in x11.
 How to fix that?
 Thanks,
 Mark

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

Re: [R-SIG-Mac] Yosemite and R

[Marc Schwartz]

 On Oct 17, 2014, at 2:17 PM, Spencer Mass ma...@newpaltz.edu wrote:
 
 Has anyone had issues installing/running  R3.1.1 2014-07-11, R.app 1.65 on 
 Yosemite?
 
 Thanks,
 
 - SM


I upgraded (over Mavericks) to Yosemite last night. R was already installed and 
I have had no issues at this point.

I don't normally use R.app and use Emacs with ESS, however, R.app appears to be 
running without issue with the limited use that I attempted.

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] special paper option of postscript device not working

[Marc Schwartz]

Denis,

If you are submitting figures to a journal, you don't want a multipage file, 
you want one plot per file and EPS is a single page format.

They will usually then embed that EPS figure/file in whatever process they use 
to create the full paper. If they are using LaTeX, there are \includegraphics 
directives in the source .tex file that will tell the LaTeX processor to insert 
the EPS file (or other file types) into the resultant document at that point.

If you want a multipage PS file, you can create that, just like a multipage PDF 
file, but it would not be suitable for the submission of figures.

For example:

postscript(Multipage.ps, height = 5, width = 5)
barplot(1:5)
plot(1:10)
dev.off()

However, each page will be the same size (eg. US letter or A4, as defined by 
options()$papersize) and the plot size within the page will be defined by the 
height and width arguments.

Regards,

Marc

On Sep 22, 2014, at 8:51 PM, Denis Chabot chabot.de...@gmail.com wrote:

 Thanks Marc,
 
 You are correct, it works if I add onefile=FALSE. 
 
 But how would you control page size for a multiple-page document (say 5 
 figures, one per page), for which you would normally use onefile=TRUE?
 
 Denis
 Le 2014-09-22 à 13:55, Marc Schwartz marc_schwa...@me.com a écrit :
 
 On Sep 22, 2014, at 12:15 PM, Denis Chabot chabot.de...@gmail.com wrote:
 
 Hi,
 
 The journal where I want to submit does not accept PDF figures, only
 postscript (or bitmaps, which I want to avoid).
 
 I want to control paper size by combining paper = special and width and
 height parameters to the postscript command, but the resulting page is
 always 8 x 11, at least as viewed with Preview and Illustrator.
 
 This is with this code:
  postscript(file=test.ps, width=5.5, height=4.25, horizontal=T, paper
 = special)
  par(mar=c(2.8, 2.8, 1.8, 0.2)+0.1, xpd=F, mgp=c(1.5,0.5,0), cex.lab=1)
 
  plot(1:10)
  dev.off()
 
 The plot occupies 1/4 of the 11x8.5 inch page.
 
 I can live with this, but my reading of the postscript device documentation
 is that width and height control the size of the paper if I also use the
 page = special option. Because this could be the result of working on a
 Mac, I write here first, but will ask on the general R Help list if this
 has nothing to do with the Mac.
 
 Thanks in advance,
 
 Denis
 
 
 Denis,
 
 In general and as noted in the Details section of ?postscript, you will want 
 to create an EPS file, using the following incantation:
 
 postscript(file = ..., width = ..., height = ..., horizontal = FALSE, 
paper = special, onefile = FALSE)
 
 Thus:
 
 postscript(file = test.eps, width = 5.5, height = 4.25, 
  horizontal = FALSE, paper = special, onefile = FALSE)
 par(mar=c(2.8, 2.8, 1.8, 0.2)+0.1, xpd=F, mgp=c(1.5,0.5,0), cex.lab=1)
 plot(1:10)
 dev.off()
 
 
 On my Mac, with OS X 10.9.5, the attached file is generated in the fashion 
 that you would expect.
 
 There is also the ?setEPS function.
 
 Regards,
 
 Marc Schwartz
 
 test.eps
 

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

Re: [R-SIG-Mac] special paper option of postscript device not working

[Marc Schwartz]

On Sep 22, 2014, at 12:15 PM, Denis Chabot chabot.de...@gmail.com wrote:

 Hi,
 
 The journal where I want to submit does not accept PDF figures, only
 postscript (or bitmaps, which I want to avoid).
 
 I want to control paper size by combining paper = special and width and
 height parameters to the postscript command, but the resulting page is
 always 8 x 11, at least as viewed with Preview and Illustrator.
 
 This is with this code:
postscript(file=test.ps, width=5.5, height=4.25, horizontal=T, paper
 = special)
par(mar=c(2.8, 2.8, 1.8, 0.2)+0.1, xpd=F, mgp=c(1.5,0.5,0), cex.lab=1)
 
plot(1:10)
dev.off()
 
 The plot occupies 1/4 of the 11x8.5 inch page.
 
 I can live with this, but my reading of the postscript device documentation
 is that width and height control the size of the paper if I also use the
 page = special option. Because this could be the result of working on a
 Mac, I write here first, but will ask on the general R Help list if this
 has nothing to do with the Mac.
 
 Thanks in advance,
 
 Denis


Denis,

In general and as noted in the Details section of ?postscript, you will want to 
create an EPS file, using the following incantation:

  postscript(file = ..., width = ..., height = ..., horizontal = FALSE, 
 paper = special, onefile = FALSE)

Thus:

postscript(file = test.eps, width = 5.5, height = 4.25, 
   horizontal = FALSE, paper = special, onefile = FALSE)
par(mar=c(2.8, 2.8, 1.8, 0.2)+0.1, xpd=F, mgp=c(1.5,0.5,0), cex.lab=1)
plot(1:10)
dev.off()


On my Mac, with OS X 10.9.5, the attached file is generated in the fashion that 
you would expect.

There is also the ?setEPS function.

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] Mac OS X tcltk/X11 issues

[Marc Schwartz]

John,

First, apologies for my narrow focus on the solutions that I proposed 
yesterday. I suffered from tunnel vision on the OS X issue and as Gabor has 
noted, it would not be sufficiently portable. There can be potential variations 
on where X11 is installed on OS X, depending upon the use of Xquartz, the 
original Apple distribution of X11 and presumably could further vary if one 
installs from source, is using Homebrew, Macports or similar, which are package 
management systems for OS X. Thus, as Gabor pointed out, capabilities(X11) is 
the most portable approach.

With respect to Linux, to the best of my knowledge, X11 (for some time X.org) 
is still a requirement for tk (but not tcl). In checking at least the current 
Fedora repos, X11 is still listed as a dependency for tk. So if one is using 
the common package management systems, X11 will be installed if not already, 
when installing tk, unless one overrides the defaults.

Also, at least for Fedora and perhaps other Linuxen, X11 is listed as a 
dependency for R itself, so if one is installing R on Fedora, X11 will be 
installed as well, if not present.

Thus, between the common Linux package management systems and that Linux users 
tend to be more technically saavy, you do not see many reports.

You likely already know this, but you could utilize a more generic approach to 
testing the platform by using:

  if (.Platform$OS.type == unix)
...

which would cover Linuxen, Unixen and OS X and then run your X11 checks, 
secondarily perhaps testing for OS X, if you wish to give a more specific error 
message for OS X users and point them to XQuartz.

Regards,

Marc

 

On Jul 14, 2014, at 11:37 PM, John Fox j...@mcmaster.ca wrote:

 Hi Gabor,
 
 Thanks for the clarification.
 
 I agree that it would be best to intercept the problem on Linux/Unix as well 
 as on Mac OS X. Do you know that X11 is necessary for the tcltk package to 
 work on Linux/Unix systems (or is there possibly a non-X11 Tcl/Tk there 
 that's compatible with the tcltk package)?
 
 As a practical matter, the problem occurs with some regularity on Mac OS X 
 (I'm aware that the availability and default installation of X11 varies by 
 version of the OS), but I've not seen a report of it on Linux, so my 
 immediate concern was to solve the problem on Mac OS X.
 
 Best,
 John
 
 On Mon, 14 Jul 2014 21:37:54 -0400
 Gábor Csárdi csardi.ga...@gmail.com wrote:
 Hi John,
 
 On Mon, Jul 14, 2014 at 8:12 PM, John Fox j...@mcmaster.ca wrote:
 Dear Gabor,
 
 As I just explained, the problem isn't testing for X11, which I know how to 
 do -- though capabilities(X11) is a bit better than what I suggested. The 
 issue is specific to Mac OS X because the Windows implementation of R 
 includes a Tcl/Tk that doesn't use X11, and I've never seen the problem on 
 Linux.
 
 actually, what I am saying is, that it is not specific to OSX. Some
 (older, before 2012) OSX versions do include an X11 server, and some
 Linux or other Unix installations do not.
 
 I am not saying tcltk should not test for an X11 server, all I am
 saying is that the test suggested below (based on the os and the
 existence of a certain file) is not the best one.
 
 If it turns out that there is no X11 server, and the os is OSX, then
 indeed a dialog box could be displayed, see e.g. the one at
 http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/
 
 Best,
 Gabor
 
 Best,
 John
 
 -Original Message-
 From: Gábor Csárdi [mailto:csardi.ga...@gmail.com]
 Sent: Monday, July 14, 2014 6:37 PM
 To: Marc Schwartz
 Cc: John Fox; urba...@research.att.com; R-SIG-Mac
 Subject: Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues
 
 What's wrong with capabilities(X11)?
 
 I am not sure if teting for the OS, and especially for a particular X
 server, installed in a particular directory, is a good idea, even if
 it covers most of the _current_ installations.
 
 Gabor
 
 On Mon, Jul 14, 2014 at 6:13 PM, Marc Schwartz marc_schwa...@me.com
 wrote:
 
 On Jul 14, 2014, at 4:53 PM, Marc Schwartz marc_schwa...@me.com
 wrote:
 
 On Jul 14, 2014, at 4:13 PM, John Fox j...@mcmaster.ca wrote:
 
 Dear Simon and list members,
 
 As many of you are aware, when X11 isn't installed on Mac OS X,
 loading the
 tcltk package produces an error, with a message that many users
 find
 cryptic. There was yet another instance of this problem reported to
 the list
 today.
 
 I'm interested in the issue because the Rcmdr package uses tcltk
 and thus
 fails to load when X11 is absent. Rcmdr users tend to be
 inexperienced and
 so, unless they find their way to the Rcmdr installation webpage,
 where
 detailed installation instructions are provided, they tend to be
 stymied by
 the problem.
 
 If I could, I'd intercept the problem by checking
 capabilities()[X11] in
 the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr
 package
 imports the tcltk namespace, the error occurs before these startup
 functions

Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues

[Marc Schwartz]

On Jul 14, 2014, at 4:13 PM, John Fox j...@mcmaster.ca wrote:

 Dear Simon and list members,
 
 As many of you are aware, when X11 isn't installed on Mac OS X, loading the
 tcltk package produces an error, with a message that many users find
 cryptic. There was yet another instance of this problem reported to the list
 today.
 
 I'm interested in the issue because the Rcmdr package uses tcltk and thus
 fails to load when X11 is absent. Rcmdr users tend to be inexperienced and
 so, unless they find their way to the Rcmdr installation webpage, where
 detailed installation instructions are provided, they tend to be stymied by
 the problem.
 
 If I could, I'd intercept the problem by checking capabilities()[X11] in
 the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr package
 imports the tcltk namespace, the error occurs before these startup functions
 are executed -- a chicken-and-egg problem.
 
 It occurs to me that tcltk could fail more gracefully on Mac OS X when X11
 is absent, perhaps popping up a webpage in a browser with instructions and a
 link for installing XQuartz. I'd do this myself in the Rcmdr package if I
 could. Or tcltk could check for the presence of X11 and not try to start it
 if it's absent, reporting a warning rather than throwing an error.
 
 Alternatively, I'd be grateful if someone could suggest how I might detect
 the problem in the Rcmdr package before loading fails. The only thing that I
 could think of was writing a separate RcmdrInstall package that bypasses
 tcltk, but that would be awkward and would only help users who discovered
 that RcmdrInstall exists.
 
 Thanks,
 John


John,

Is there someplace in your startup process where you could run code along the 
lines of:

if (grepl(apple, R.version$platform)  length(list.files(/opt/X11/bin, 
pattern = Xquartz)) == 0) {
 cat(X11 is required. Please visit http://xquartz.macosforge.org to 
download and install Xquartz.)
 stop()
}


The above code will check to see if the user is running R on OS X and also if 
the Xquartz binary is present in the default location.

Not sure if this is helpful.

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] Mac OS X tcltk/X11 issues

[Marc Schwartz]

On Jul 14, 2014, at 4:53 PM, Marc Schwartz marc_schwa...@me.com wrote:

 On Jul 14, 2014, at 4:13 PM, John Fox j...@mcmaster.ca wrote:
 
 Dear Simon and list members,
 
 As many of you are aware, when X11 isn't installed on Mac OS X, loading the
 tcltk package produces an error, with a message that many users find
 cryptic. There was yet another instance of this problem reported to the list
 today.
 
 I'm interested in the issue because the Rcmdr package uses tcltk and thus
 fails to load when X11 is absent. Rcmdr users tend to be inexperienced and
 so, unless they find their way to the Rcmdr installation webpage, where
 detailed installation instructions are provided, they tend to be stymied by
 the problem.
 
 If I could, I'd intercept the problem by checking capabilities()[X11] in
 the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr package
 imports the tcltk namespace, the error occurs before these startup functions
 are executed -- a chicken-and-egg problem.
 
 It occurs to me that tcltk could fail more gracefully on Mac OS X when X11
 is absent, perhaps popping up a webpage in a browser with instructions and a
 link for installing XQuartz. I'd do this myself in the Rcmdr package if I
 could. Or tcltk could check for the presence of X11 and not try to start it
 if it's absent, reporting a warning rather than throwing an error.
 
 Alternatively, I'd be grateful if someone could suggest how I might detect
 the problem in the Rcmdr package before loading fails. The only thing that I
 could think of was writing a separate RcmdrInstall package that bypasses
 tcltk, but that would be awkward and would only help users who discovered
 that RcmdrInstall exists.
 
 Thanks,
 John
 
 
 John,
 
 Is there someplace in your startup process where you could run code along the 
 lines of:
 
 if (grepl(apple, R.version$platform)  length(list.files(/opt/X11/bin, 
 pattern = Xquartz)) == 0) {
 cat(X11 is required. Please visit http://xquartz.macosforge.org to 
 download and install Xquartz.)
 stop()
 }
 
 
 The above code will check to see if the user is running R on OS X and also if 
 the Xquartz binary is present in the default location.
 
 Not sure if this is helpful.


A possible correction in the above code relative to detecting OS X:

if ((Sys.info()[sysname] == Darwin)  length(list.files(/opt/X11/bin, 
pattern = Xquartz)) == 0) {
cat(X11 is required. Please visit http://xquartz.macosforge.org to 
download and install Xquartz.)
stop()
}


I believe that Sys.info()[sysname] == Darwin is preferred for detecting the 
OS that R is running on versus the OS that it was built upon according to the 
help files, if I read correctly. This could be important if someone is building 
R from source versus installing Simon's CRAN binary, I presume.

Regards,

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] Mac OS X tcltk/X11 issues

[Marc Schwartz]

Kasper,

Understood. I was not sure if there was someplace in John's startup code that 
might catch it early on before tcltk loads, but that may be confounded by the 
sequence of the package import process as John notes below.

Reading R-exts and the related help files does not make it clear to me that 
there is a window of opportunity to run the check before the import occurs, but 
I would defer to Simon et al on the finer points here.

Regards,

Marc


On Jul 14, 2014, at 5:07 PM, Kasper Daniel Hansen 
kasperdanielhan...@gmail.com wrote:

 Basically John is asking for code like this to be included in tcltk.
 
 Best,
 Kasper
 
 
 On Mon, Jul 14, 2014 at 11:53 PM, Marc Schwartz marc_schwa...@me.com wrote:
 On Jul 14, 2014, at 4:13 PM, John Fox j...@mcmaster.ca wrote:
 
  Dear Simon and list members,
 
  As many of you are aware, when X11 isn't installed on Mac OS X, loading the
  tcltk package produces an error, with a message that many users find
  cryptic. There was yet another instance of this problem reported to the list
  today.
 
  I'm interested in the issue because the Rcmdr package uses tcltk and thus
  fails to load when X11 is absent. Rcmdr users tend to be inexperienced and
  so, unless they find their way to the Rcmdr installation webpage, where
  detailed installation instructions are provided, they tend to be stymied by
  the problem.
 
  If I could, I'd intercept the problem by checking capabilities()[X11] in
  the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr package
  imports the tcltk namespace, the error occurs before these startup functions
  are executed -- a chicken-and-egg problem.
 
  It occurs to me that tcltk could fail more gracefully on Mac OS X when X11
  is absent, perhaps popping up a webpage in a browser with instructions and a
  link for installing XQuartz. I'd do this myself in the Rcmdr package if I
  could. Or tcltk could check for the presence of X11 and not try to start it
  if it's absent, reporting a warning rather than throwing an error.
 
  Alternatively, I'd be grateful if someone could suggest how I might detect
  the problem in the Rcmdr package before loading fails. The only thing that I
  could think of was writing a separate RcmdrInstall package that bypasses
  tcltk, but that would be awkward and would only help users who discovered
  that RcmdrInstall exists.
 
  Thanks,
  John
 
 
 John,
 
 Is there someplace in your startup process where you could run code along the 
 lines of:
 
 if (grepl(apple, R.version$platform)  length(list.files(/opt/X11/bin, 
 pattern = Xquartz)) == 0) {
  cat(X11 is required. Please visit http://xquartz.macosforge.org to 
 download and install Xquartz.)
  stop()
 }
 
 
 The above code will check to see if the user is running R on OS X and also if 
 the Xquartz binary is present in the default location.
 
 Not sure if this is helpful.
 
 Regards,
 
 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

Re: [R-SIG-Mac] upgrade to Mavericks

[Marc Schwartz]

On Apr 24, 2014, at 10:15 PM, Richard M. Heiberger r...@temple.edu wrote:

 Thank you to all who replied.
 
 I did accept the upgrade to Mavericks last week.  In retrospect I think it
 was a mistake for me.  Most of the changes are not relevant to my
 workflow.  One was an improvement.  One was a big negative.
 
 The improvement is the handling of a secondary display screen.
 The Desktop on that screen is now independent of the Desktops on the main
 screen.  The Desktop on the secondary screen is retained when I unplug the
 secondary screen and then plug it back in.
 
 There are two big negatives is how Preview handles revision to my
 pdflatex documents.
 
 Previously (OS X Lion), when I ran pdflatex, the pdf file was revised with
 the display showing the same page and the same positioning on the page.
 Now (Mavericks) the display jumps to the top left corner of the current page.
 Since I keep the window focussed only on the part of the page with text,
 that means the top and left margins dominate the new display.  My
 workaround is to construct an if statement that sets the margins to 0
 when I am in revision mode and gives them normal values otherwise.
 
 The other negative is that yellow stickies now appear in a Comic font instead
 of a sedate font.  Also, the alignment between the left marginal column of
 yellow stickies and their location in the body of the document is broken.
 clicking on the page number in the marginal listing moves the document
 to the right page.  But clicking on the sticky itself does not move the 
 marginal
 listing to the matching sticky.
 
 An even more serious problem, and I don't know if this is Mavericks-specific
 or more general to OS X, is that several R packages no longer work with
 the released R-3.1.0.  As of :Last updated on 2014-04-25 04:47:05.,
 latticeExtra gives an error with r-devel-osx-x86_64-gcc and a warning with
 r-release-osx-x86_64-mavericks.


Rich,

On this issue, presumably you installed the Mavericks build of R 3.1.0. 

If you install the Snow Leopard build instead, this will be a non-issue.

There are some CRAN packages that do not yet pass testing using the Mavericks R 
build and so will be unavailable to install as binaries yet.

This post from Prof Ripley earlier this week may be helpful:

  https://stat.ethz.ch/pipermail/r-sig-mac/2014-April/010835.html

Regards,

Marc Schwartz


 
 I reverted back to R-3.0.3.  I will try again with the R-patched when CRAN
 shows all the packages I use are checking without warnings.
 
 Rich
 

snip

___
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.1.0: Running 'R CMD Sweave' deletes non tex files created upon batch mode exit

[Marc Schwartz]

Hi all,

With R version 3.1.0 on OSX, using either the Snow Leopard or the Mavericks 
binary installation on a Mac with fully updated Mavericks, there has been a 
change in behavior since 3.0.3.

I have a master .Rnw file which runs a series of outputs from multiple R code 
files, each called in BATCH mode using system() from within the master .Rnw 
file. The output of the R code files go to separate text files in order to 
catch some of the function call output that would not otherwise be included in 
the resultant .tex file due to output redirection.

Those text files are then included in the resultant .tex file using, for 
example:

  \lstinputlisting[caption={}]{test.out}

directives which are included in the .Rnw source file.

A simple example to replicate the observed behaviors.

The test.Rnw file content:

%% R CMD Sweave test.Rnw
results=tex,echo=false=
system(R CMD BATCH test.R test.out)
@ 


The test.R file content:

options(echo = FALSE)
options(useFancyQuotes = FALSE)
installed.packages()


On version 3.0.3, the file test.out is created, along with test.tex. test.out 
contains the output of installed.packages(). I did not include the 
aforementioned listing directive in test.Rnw here for simplicity.

On version 3.1.0, the file test.out is created, but when the R CMD Sweave 
command exits and returns to the CLI in the console, test.out is deleted, 
presumably as part of a post R batch session clean up process. The file 
test.tex is retained.

I uninstalled 3.1.0 and reinstalled 3.0.3 and observed the prior behavior. I 
then tried clean installs of both the Snow Leopard and Mavericks 3.1.0 
binaries, with the new behavior observed in both cases.

In reading the NEWS file for 3.1.0, there are multiple references to Sweave, 
but there is nothing explicit about this new behavior. 

I should note that when the .Rnw file is run from within an R 3.1.0 interactive 
session using:

  Sweave(test.Rnw)

the test.out file is created and not deleted upon the function exit, or when 
exiting the R session back to the console. 

Thus, this new behavior seems to be limited to running Sweave from the CLI 
using R CMD. It is not clear to me if this new behavior is by design or perhaps 
an unintended consequence of changes elsewhere in Sweave processing or in the 
handling of R in BATCH mode.

When watching the folder where the file output activity takes place, I note 
that a file .build.timestamp is created and then deleted, which leads me to 
believe that the new functions fileSnapshot() and changedFiles() are being used 
in the course of processing R in BATCH mode. If that is correct and there is a 
clean up step that is occurring upon BATCH mode exit, which deletes all files 
and folders other than .tex files, is it possible that this process is being 
overly aggressive? Or if not, is there a way to not have these files deleted or 
have a protected folder where these files can be retained?

Thanks for any insights.

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] java quit unexpectedly while opening multiple Quartz devices

[Marc Schwartz]

On Nov 21, 2013, at 9:02 AM, Simon Urbanek simon.urba...@r-project.org wrote:

 On Nov 21, 2013, at 1:49 AM, Francesco Novelli ceco2lon...@yahoo.co.uk 
 wrote:
 
 Hallo everybody,
 
 I'm doing an econometric analysis with R and I've written a script which 
 automatically opens multiple Quartz devices I need to visually inspect.
 
 Unfortunately I often (i.e., not always and not following any pattern I'm 
 able to recognize) get a Java error which causes the Java runtime to hang 
 and stops R altogether, obliging me to restart it.
 
 
 You'll have to elaborate -- Java is not used by Quartz, Apple doesn't allow 
 Java UI to be run from R and Quartz is not supported to be run from Java, so 
 are probably doing something bad in the first place. If you use Java, you 
 have to use JavaGD (or similar) instead of Quartz.
 
 Cheers,
 Simon


From below, it looks like he is running R in Eclipse/StatET, which is a Java 
based IDE. That is likely to be the source of the problem.

The problem may be best reported to them, barring additional information to the 
contrary.

Regards,

Marc Schwartz


 
 
 The error is not always the same - I've noted these so far:
 
 java quit unexpectedly while using the graphics.so plug-in
 java quit unexpectedly while using the libjri.jnilib plug-in
 java quit unexpectedly while using the grDevices.so plug-in
 
 My environment is as follows:
 R 3.0.1 64bit
 
 Eclipse Platform 4.3.0 with StatET 3.3
 JRE Java SE 6 [1.6.0_51-b11-457]
 OSX 10.8.5
 
 Has anybody experienced a similar problem and can suggest any workaround I 
 might try?
 
 
 By the way, is there a keyboard shortcut to cycle through multiple Quartz 
 windows just like you can do in other OSX applications? I couldn't find any.
 
 Thank you very much
 Kind regards
 
 Francesco
  [[alternative HTML version deleted]]
 
 ___
 R-SIG-Mac mailing list
 R-SIG-Mac@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-mac
 
 
 ___
 R-SIG-Mac mailing list
 R-SIG-Mac@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

Re: [R-SIG-Mac] RODBC not connecting from my Mac

[Marc Schwartz]

 On 25/10/2013 13:54, Marc Schwartz wrote:
 
 On Oct 13, 2013, at 11:41 AM, Mikkel Grum mi2kelg...@yahoo.com wrote:
 
 iODBC appears no longer to come standard with OSX, so I installed unixodbc 
 and set it up following instructions here: 
 http://www.boriel.com/en/2013/01/16/postgresql-odbc-connection-from-mac-os-x/
 
 I connected to my remote database with isql -v mydsn. No problem. Then I 
 tried from R:
 
 library(RODBC)
 pg - odbcConnect(mydsn)  # waited for a couple of minutes before 
 pressing Ctrl-C
 ^C
 There were 50 or more warnings (use warnings() to see the first 50)
 warnings()[1:2]
 Warning messages:
 1: In odbcDriverConnect(DSN=mydsn) :
   [RODBC] ERROR: state IM002, code 1606406032, message [iODBC][Driver 
 Manager]Data source name not found and no default driver specified. Driver 
 could not be loaded
 2: In odbcDriverConnect(DSN=mydsn) :
   [RODBC] ERROR: state IM002, code 1606406032, message [iODBC][Driver 
 Manager]Data source name not found and no default driver specified. Driver 
 could not be loaded
 
 It looks like RODBC might only work with iODBC on the Mac. Is that the 
 case? I haven't been able to configure iODBC correctly, and therefore 
 haven't been able to test whether that would work with RODBC. Any chance 
 that I can get RODBC to work with unixodbc? Any other information that 
 would be useful in resolving it?
 
 sessionInfo()
 R version 3.0.2 (2013-09-25)
 Platform: x86_64-apple-darwin10.8.0 (64-bit)
 
 locale:
 [1] C/UTF-8/C/C/C/C
 
 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base
 
 other attached packages:
 [1] RODBC_1.3-8
 
 Regards
 Mikkel
 
 
 First, no need to cross-post to three groups. I am replying to R-SIG-Mac 
 only here.
 
 iODBC is still available on OSX. Apple removed the ODBC Administrator 
 application back on Snow Leopard. A newer ODBC Manager application is freely 
 available for download here:
 
   http://www.odbcmanager.net/index.php
 
 It is supported by Actual Technologies, which offers for purchase, ODBC 
 drivers on OSX for various data sources. I use their driver for Oracle.
 
 If you want to use the older Apple ODBC Administrator application, it is 
 still available here:
 
   http://support.apple.com/kb/DL895
 
 If you want to stay with unixODBC, you may want to read through the vignette 
 for RODBC that Prof. Ripley has written and pay attention to the 
 Installation section on page 22:
 
   http://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf
 
 which has some hints that should be helpful, such as using:
 
   --with-odbc-manager=odbc
 
 when installing RODBC from source. Yes, RODBC will, by default, use iODBC on 
 OSX, since that is the default ODBC installation on OSX. Thus, the 
 precompiled binary for RODBC will not work for what you are attempting to do.
 
 Regards,
 
 Marc Schwartz


Hi All,

I wanted to follow up on this thread, as the information that I provided above 
was not complete, as I now know from conversations with Prof. Ripley, 
information found online by searching in the Apple Developer Forums and an 
e-mail exchange with Actual Technologies' (AT) tech support.

Beginning with OS X 10.6 (Snow Leopard), Apple removed the ODBC Administrator 
GUI application from the default OS installation, as I noted above. The Apple 
version was and is still available as a separate download from Apple.com and 
the AT folks began to support and release and updated version called ODBC 
Manager, as I also noted.

However, that was only part of the story as it turns out.

Beginning with OS X 10.8 (Mountain Lion), Apple began the process of 
deprecating direct support for iODBC. The header files for iODBC that were 
included with XCode on 10.8 in the SDK tree apparently had indications of this, 
but it was not overtly documented anywhere else, including the XCode release 
notes. The binary dylib files for iODBC were still present in /usr/lib on 10.8, 
so if you wanted to use, for example, the RODBC binary for OS X on 10.8, there 
was not an issue. You still need the ODBC Administrator/Manager GUI to set up 
the DSN configuration of course, unless you manually set up the configuration 
files.

There is not a specific indication as to why, but an entry from August of 
*2012* in the Apple Dev Forums by an Apple rep indicated that a decision had 
been made by Apple to engage in the deprecation of the default installation of 
iODBC on OS X. This reply was to another user who had noted the header file 
content indicating this and posted a query. The Apple rep suggested that users 
begin to consider going to iODBC.org for OS X binaries where available or the 
source code moving forward. Alternatively, users should consider moving to 
other ODBC tools such as unixODBC or the use of native (non-ODBC) drivers for 
the data sources of interest.

With 10.9 (Mavericks), Apple has now completely removed iODBC from the default 
OS X installation. In the latest version of XCode, the binary dylib files

Re: [R-SIG-Mac] no title bar on mavericks X11 windows

[Marc Schwartz]

On Oct 30, 2013, at 12:11 PM, Andy Jacobson (NOAA Affiliate) andy.jacob...@noaa.gov wrote:Hi,Since upgrading to Mavericks, all X11 windows created by R are without title bar (no maximize/minimize/close buttons, no title)...just a blankwhite canvas placed in the upper-left corner of my primary display. R draws into this just fine, but I can't move, close, or otherwise manipulatethe window. This occurs with X11() called from remote machines (an older R-2.14.1), and from R-3.0.0 and R-3.0.2 locally. Other X applications,both locally- and remotely-executed, do not suffer from this issue. I also upgraded Xquartz to the 2.7.5-rc3 recommended for Mavericks users bythe Xquartz team, but it had no effect on this issue. I don't know if this is an R issue or an Xquartz issue...any ideas?Thanks,AndyHi,I am running 3.0.2 on Mavericks (CRAN binary install) and when I use X11() running R in a terminal session, I get a full window with title bar on my MacBook Pro. I re-installed XQuartz (2.7.4) after upgrading from 10.8 to 10.9.See the attached screen capture PNG.I tested it via R.app as well, with the same result.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 3.0.2 closes on loading xlsx package

[Marc Schwartz]

On Oct 29, 2013, at 12:22 AM, Luca Meyer lucam1...@gmail.com wrote:

 Since I have upgraded to OSX 10.9 R closes down suddently any time I try to
 upload the xlsx package - that is using either
 require(xlsx)
 or
 library(xlsx)
 
 Does any one have had a similar issue? How did you solve it?
 
 Thanks,
 Luca


Hi,

It looks like the xlsx package requires Java and you will need to re-install 
Java after the Mavericks update. Java is not included as part of the upgrade 
process.

You can download the Apple variant of Java for Mavericks here:

  http://support.apple.com/kb/DL1572

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] RODBC not connecting from my Mac

[Marc Schwartz]

On Oct 13, 2013, at 11:41 AM, Mikkel Grum mi2kelg...@yahoo.com wrote:

 iODBC appears no longer to come standard with OSX, so I installed unixodbc 
 and set it up following instructions here: 
 http://www.boriel.com/en/2013/01/16/postgresql-odbc-connection-from-mac-os-x/
 
 I connected to my remote database with isql -v mydsn. No problem. Then I 
 tried from R:
 
 library(RODBC)
 pg - odbcConnect(mydsn)  # waited for a couple of minutes before pressing 
 Ctrl-C
 ^C
 There were 50 or more warnings (use warnings() to see the first 50)
 warnings()[1:2]
 Warning messages:
 1: In odbcDriverConnect(DSN=mydsn) :
   [RODBC] ERROR: state IM002, code 1606406032, message [iODBC][Driver 
 Manager]Data source name not found and no default driver specified. Driver 
 could not be loaded
 2: In odbcDriverConnect(DSN=mydsn) :
   [RODBC] ERROR: state IM002, code 1606406032, message [iODBC][Driver 
 Manager]Data source name not found and no default driver specified. Driver 
 could not be loaded
 
 It looks like RODBC might only work with iODBC on the Mac. Is that the case? 
 I haven't been able to configure iODBC correctly, and therefore haven't been 
 able to test whether that would work with RODBC. Any chance that I can get 
 RODBC to work with unixodbc? Any other information that would be useful in 
 resolving it?
 
 sessionInfo()
 R version 3.0.2 (2013-09-25)
 Platform: x86_64-apple-darwin10.8.0 (64-bit)
 
 locale:
 [1] C/UTF-8/C/C/C/C
 
 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base 
 
 other attached packages:
 [1] RODBC_1.3-8
 
 Regards
 Mikkel


First, no need to cross-post to three groups. I am replying to R-SIG-Mac only 
here.

iODBC is still available on OSX. Apple removed the ODBC Administrator 
application back on Snow Leopard. A newer ODBC Manager application is freely 
available for download here:

  http://www.odbcmanager.net/index.php
 
It is supported by Actual Technologies, which offers for purchase, ODBC drivers 
on OSX for various data sources. I use their driver for Oracle.

If you want to use the older Apple ODBC Administrator application, it is still 
available here:

  http://support.apple.com/kb/DL895

If you want to stay with unixODBC, you may want to read through the vignette 
for RODBC that Prof. Ripley has written and pay attention to the Installation 
section on page 22:

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

which has some hints that should be helpful, such as using:

  --with-odbc-manager=odbc 

when installing RODBC from source. Yes, RODBC will, by default, use iODBC on 
OSX, since that is the default ODBC installation on OSX. Thus, the precompiled 
binary for RODBC will not work for what you are attempting to do.

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] mac mavericks problem

[Marc Schwartz]

On Oct 24, 2013, at 11:21 AM, Richard M. Heiberger r...@temple.edu wrote:

 one of my students just download mac mavericks.
 starting with the new system, R-3.0.1 in the APP is misbehaving.
 
 enter
 TRUE - FALSE
 (to illustrate why use of T is not a good practice)
 
 R app gives the error message
 invalid (do_set) left-hand side to assignment
 
 *** caught segfault ***
 address 0x7c0, cause 'memory not mapped'
 Possible actions
 1 2 3 4
 
 
 The R program run in the terminal behaves correctly.
 it reports the invalid assignment and then gives a normal R prompt.
 
 Will this happen in R-3.0.2? (yes we will download and check that).


Rich,

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

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

...

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

which I otherwise never use.

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



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] mac mavericks problem

[Marc Schwartz]

Rich, 

Just for clarification, I was referring to never using R.app, since I use ESS. 

Of course, I don't use the assignment statement either... :-)

Regards,

Marc

On Oct 24, 2013, at 11:56 AM, Richard M. Heiberger r...@temple.edu wrote:

 of course you never use it.  it won't work.
 the point of the email is that writing an invalid statement should
 trigger only an error message.  It should not trigger the segfault.
 
 It looks like the segfault is specific to 3.0.1 since your and Marc both 
 report
 that you don't see the segfault on 3.0.2
 
 I will tell the student to upgrade to 3.0.2 immediately.
 
 On Thu, Oct 24, 2013 at 12:46 PM, Federico Calboli
 f.calb...@imperial.ac.uk wrote:
 On 24 Oct 2013, at 17:37, Marc Schwartz marc_schwa...@me.com wrote:
 
 Rich,
 
 I get the same error message, but not the segfault, using 3.0.2 on 
 Mavericks, using R.app:
 
 R version 3.0.2 (2013-09-25) -- Frisbee Sailing
 Copyright (C) 2013 The R Foundation for Statistical Computing
 Platform: x86_64-apple-darwin10.8.0 (64-bit)
 
 ...
 
 [R.app GUI 1.62 (6558) x86_64-apple-darwin10.8.0]
 
 which I otherwise never use.
 
 
 TRUE - FALSE
 Error in TRUE - FALSE : invalid (do_set) left-hand side to assignment
 
 
 On Mountain Lion, R 3.0.2:
 
 TRUE = FALSE
 Error in TRUE = FALSE : invalid (do_set) left-hand side to assignment
 
 in R.app, and in a terminal.  I also get the same on a linux machine.
 
 I think that's a  feature, not a bug.
 
 BW
 
 F
 
 ___
 R-SIG-Mac mailing list
 R-SIG-Mac@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

Re: [R-SIG-Mac] R on Mac: framework or homebrew?

[Marc Schwartz]

On Sep 12, 2013, at 9:20 AM, Rainer M Krug rai...@krugs.de wrote:

 Hi
 
 I am using R at the moment installed from the official installation as a
 framework, buit I also installed it from homebrew. As I am not using the
 Mac GUI (I am using mainly emacs, a little bit RStudio), so from there
 there was no difference.
 
 So which approach has which advantages? I can think of advantages when
 using homebrew (updates and upgrades of R) and also the framework
 approach (Ease of maintenance). 
 
 I personaly lean towards the homebrew installation (linux background),
 but are there any disadvantages to using the official framework
 installation?
 
 Any comments?
 
 Cheers,
 
 Rainer


Rainer,

I have not used Homebrew.

Having come to OSX 4+ years ago from Linux myself, I was comfortable using 
online third party Linux repos for things that were not in the default 
distribution. However, much like the early Fedora repos, before things were 
centralized and standardized, I found that the Mac repos (MacPorts and Fink) 
caused more trouble than they were worth. This was primarily due to 
non-standard dependencies, that installed all kinds of stuff that I really did 
not need or want and in some cases, conflicted with components that were 
already present in OSX. That was my common experience with MacPorts and I 
rapidly removed everything that they installed and just went to the upstream 
sources or binaries (when available) when I needed something.

I can't say whether or not Homebrew has similar characteristics to MacPorts 
and/or Fink, but I would say, be very careful and know exactly what you are 
getting if you do.

I used to build R from source on OSX, since I had done the same on Linux for 
years. However, for the past year or two now, I have been using Simon's CRAN 
binary releases and life has been much simplified as a result.

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.app doesn't respect DYLD_FALLBACK_LIBRARY_PATH

[Marc Schwartz]

Hi all,

Just for clarification, I only set the variable in ~/.Renviron to be sure that 
it was picked up by R.app, in case Tom had not used the correct syntax. I did 
not actually install the package under discussion from the source at GitHub, so 
I cannot confirm that the approach resolved the issue that Tom is reporting. 
Tom's report would suggest that it does not.

Berend's reply would seem to support the notion that this is a problem in the 
way in which the package ends up being built, so would lead one down the path, 
I believe, of a bug in the package, perhaps in its make related files vis-a-vis 
the included C++ code. Thus a report to the package author would seem to be in 
order.

With respect to Kasper's reply, there are potential issues in resetting or 
unsetting DYLD_FALLBACK_LIBRARY_PATH or DYLD_LIBRARY_PATH in that there are 
other applications that can depend upon their value and if altered, can break 
those applications. So the caution is warranted.

If Tom is on Mountain Lion, the message:

  dyld: DYLD_ environment variables being ignored because main executable 
(/usr/bin/login) is setuid or setgid

may be related to a known bug in Mountain Lion (OS X 10.8) that occurs when 
running sudo in a terminal session. It has been widely reported, with various 
attempts at resolution, including things like creating shell wrappers for sudo, 
but no definitive solution that lacks side effects has been put forth. Apple 
appears to know about the bug, since reports would suggest that it has been 
resolved in beta releases of Mavericks (OS X 10.9), but no official fix is yet 
pending for Mountain Lion. Perhaps a future update to Mountain Lion might 
include the fix if the Mavericks solution is stable.

If Tom is not on Mountain Lion, then the problem may yet be related in terms of 
the underlying etiology in setting DYLD_FALLBACK_LIBRARY_PATH, which brings 
Kasper's note of caution into consideration.

Regards,

Marc


On Aug 9, 2013, at 2:10 AM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:

 R.app is a process. R is a shell script that launches a process.  Both 
 inherit the environment they are launched from, but it is usually different 
 from the GUI and from a terminal.
 
 It is regarded as a security hole to allow a running process to change the 
 settings of its dynamic loader (dyld on OS X), so I would not expect that 
 setting such environment variables from within R.app (including from reading 
 .Renviron) to affect dyld.  So if it did for Marc, I am surprised and would 
 expect that hole to be plugged in due course.
 
 It is not 'R.app doesn't respect DYLD_FALLBACK_LIBRARY_PATH': R.app knows 
 nothing about it.  Rather, it is dyld which I would expect to read its 
 environment variables only when the process is launched (and as Steve 
 Lianoglou has pointed out, which plists are read before dyld is initialized 
 for a process has changed over time).
 
 This is not really the best way to extend the library search path.  In this 
 case, for one package, the simplest way is to use -rpath when the package was 
 installed (and I believe you can set or edit the runpath after the .so is 
 made with install_name_tool).
 
 On 08/08/2013 22:00, Marc Schwartz wrote:
 On Aug 8, 2013, at 3:42 PM, Tom Schoenemann t...@indiana.edu wrote:
 
 Hello,
 
 I am trying to get a custom R package (from another group) to run on my 
 system. If I call it from the command line r, it works fine.  If I call it 
 from R.app, it complains with:
 
 Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object 
 '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so':
  
 dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so,
  6): Library not loaded: libitkdouble-conversion-4.5.1.dylib
  Referenced from: 
 /Applications/image-processing/ANTsR/src/ANTS/ANTS-build/lib/libl_antsRegistration.dylib
  Reason: image not found
 Error: package or namespace load failed for ‘ANTsR’
 
 (ANTsR is the package I'm trying to get working)
 
 I CAN get it to work by doing this on the command line first:
 
 export 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 
 and then also opening the R.app from the command line:
 
 open /Applications/R.app/
 
 However, I can't seem to get R.app to know about
 export 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 unless I do it this way.
 
 So my questions are:
 
 1) how can I get R.app to know about the DYLD_FALLBACK_LIBRARY_PATH?  I 
 tried putting it into my .Renviron file, but it doesn't work  (maybe the 
 syntax is supposed to be different?)
 
 2) why does r on the command line know about dynamic libraries, but R.app 
 does not?? This seems like a bug, but maybe there is a good reason for it?
 
 Thanks for any suggestions,
 
 -Tom
 
 
 In general, OSX GUI based apps do not inherit the shell environment. This is 
 the case

Re: [R-SIG-Mac] R.app doesn't respect DYLD_FALLBACK_LIBRARY_PATH

[Marc Schwartz]

On Aug 8, 2013, at 3:42 PM, Tom Schoenemann t...@indiana.edu wrote:

 Hello,
 
 I am trying to get a custom R package (from another group) to run on my 
 system. If I call it from the command line r, it works fine.  If I call it 
 from R.app, it complains with:
 
 Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object 
 '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so':
  
 dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so,
  6): Library not loaded: libitkdouble-conversion-4.5.1.dylib
  Referenced from: 
 /Applications/image-processing/ANTsR/src/ANTS/ANTS-build/lib/libl_antsRegistration.dylib
  Reason: image not found
 Error: package or namespace load failed for ‘ANTsR’
 
 (ANTsR is the package I'm trying to get working)
 
 I CAN get it to work by doing this on the command line first:
 
 export 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 
 and then also opening the R.app from the command line:
 
 open /Applications/R.app/
 
 However, I can't seem to get R.app to know about 
 export 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 unless I do it this way. 
 
 So my questions are:
 
 1) how can I get R.app to know about the DYLD_FALLBACK_LIBRARY_PATH?  I tried 
 putting it into my .Renviron file, but it doesn't work  (maybe the syntax is 
 supposed to be different?)
 
 2) why does r on the command line know about dynamic libraries, but R.app 
 does not?? This seems like a bug, but maybe there is a good reason for it?
 
 Thanks for any suggestions,
 
 -Tom


In general, OSX GUI based apps do not inherit the shell environment. This is 
the case with Emacs on OSX for example.

What is the syntax that you used in .Renviron? It should be along the lines of:

  DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib

Note, do not use 'export' before the above. I just tried it here and it worked. 

Take a look at ?Startup for more details.

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.app doesn't respect DYLD_FALLBACK_LIBRARY_PATH

[Marc Schwartz]

Tom,

Please use 'reply-all' so that the thread stays on the list and therefore in 
the archives where it can be of assistance to others.

My guess is that the package, which appears to not yet be on CRAN and is still 
only in development on GitHub, may require some tweaking for the shell (eg. in 
~/.bash_profile), where you can use the full 'export ...' line. So I would add 
the line to that file and see if it works.

That it works in the manner you describe is an indication that the shell 
environment is picked up for the package when you start R from within a 
terminal session, which is not entirely surprising. Presumably, it will also 
work if you simply ran text console R within the terminal session.

Of course, it could be a bug in the package in terms of how it is getting 
environment variables, at least on OSX, which is either something the authors 
need to address or at least document.

If the above does not work, you may be better off directly contacting the 
package author for assistance with this since it is still in development and 
therefore not yet stable.

Regards,

Marc

On Aug 8, 2013, at 4:18 PM, Tom Schoenemann t...@indiana.edu wrote:

 Thanks Marc,
 
 My .Renviron looks like this:
 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 
 When I restart R.app, it does seem to have this set:
 
  Sys.getenv()
 DYLD_FALLBACK_LIBRARY_PATH 
/Library/Frameworks/R.framework/Resources/lib  
 
 However, the package that needs to know this is still complaining that it 
 can't find the dynamic libraries it needs.  
 
 
 But when I do:
 
 export 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 
 on the command line, followed by:
 
 open /Applications/R.app/
 
 R.app starts, and I can then load the package without it complaining (i.e., 
 it found the dynamic libraries it needs).  I don't understand why…
 
 -Tom
 
 
 On Aug 8, 2013, at 5:00 PM, Marc Schwartz marc_schwa...@me.com wrote:
 
 On Aug 8, 2013, at 3:42 PM, Tom Schoenemann t...@indiana.edu wrote:
 
 Hello,
 
 I am trying to get a custom R package (from another group) to run on my 
 system. If I call it from the command line r, it works fine.  If I call it 
 from R.app, it complains with:
 
 Error in dyn.load(file, DLLpath = DLLpath, ...) : 
 unable to load shared object 
 '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so':
 dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so,
  6): Library not loaded: libitkdouble-conversion-4.5.1.dylib
 Referenced from: 
 /Applications/image-processing/ANTsR/src/ANTS/ANTS-build/lib/libl_antsRegistration.dylib
 Reason: image not found
 Error: package or namespace load failed for ‘ANTsR’
 
 (ANTsR is the package I'm trying to get working)
 
 I CAN get it to work by doing this on the command line first:
 
 export 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 
 and then also opening the R.app from the command line:
 
 open /Applications/R.app/
 
 However, I can't seem to get R.app to know about 
 export 
 DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 unless I do it this way. 
 
 So my questions are:
 
 1) how can I get R.app to know about the DYLD_FALLBACK_LIBRARY_PATH?  I 
 tried putting it into my .Renviron file, but it doesn't work  (maybe the 
 syntax is supposed to be different?)
 
 2) why does r on the command line know about dynamic libraries, but R.app 
 does not?? This seems like a bug, but maybe there is a good reason for it?
 
 Thanks for any suggestions,
 
 -Tom
 
 
 In general, OSX GUI based apps do not inherit the shell environment. This is 
 the case with Emacs on OSX for example.
 
 What is the syntax that you used in .Renviron? It should be along the lines 
 of:
 
  DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
 
 Note, do not use 'export' before the above. I just tried it here and it 
 worked. 
 
 Take a look at ?Startup for more details.
 
 Regards,
 
 Marc Schwartz
 
 
 
 _
 P. Thomas Schoenemann
 
 Associate Professor
 Department of Anthropology
 Cognitive Science Program
 Indiana University
 Bloomington, IN  47405
 Phone: 812-855-8800
 E-mail: t...@indiana.edu
 
 Open Research Scan Archive (ORSA) Co-Director
 Consulting Scholar
 Museum of Archaeology and Anthropology
 University of Pennsylvania
 
 http://www.indiana.edu/~brainevo
 
 
 
 
 
 
 
 
 
 


[[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] Problem with R 3.0.1

[Marc Schwartz]

On Jun 27, 2013, at 11:44 AM, Chen, Gang (NIH/NIMH) [C] 
gangc...@mail.nih.gov wrote:

 R 3.0.1 does not seem to work properly on two of my Mac notebooks, one with 
 10.8.2 and the other 10.6.8. When I start R on the terminal, I get the 
 following:
 
 Error in .Call(R_isMethodsDispatchOn, onOff, PACKAGE = base) :
  R_isMethodsDispatchOn not available for .Call() for package base
 
 R version 3.0.1 (2013-05-16) -- Good Sport
 ...
 
 Even the following does not work:
 
 citation()
 Error: could not find function citation
 
 However, once I downgraded R from 3.0.1 to 3.0, everything works fine. What 
 could be the source of the problem?
 
 Thanks!
 
 Gang


I would try to download 3.0.1 from a different CRAN mirror. My first guess is 
that your download was corrupted and/or did not install correctly or fully.

You could try to test the MD5 hash for the downloaded file. The correct hash 
value is listed on the download page for OSX:

In a terminal:

md5 R-3.0.1.pkg
MD5 (R-3.0.1.pkg) = c0e6e702742f17cd9b2f2e4cb1c5dcad


Regards,

Marc Schwartz

P.S. to Simon. Should there be a consideration for replacing MD5 with SHA, 
given the issues with the former?

___
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.0.0 beta

[Marc Schwartz]

On Mar 21, 2013, at 10:29 AM, Simon Urbanek simon.urba...@r-project.org wrote:

 
 On Mar 20, 2013, at 1:08 PM, Marc Schwartz wrote:
 
 Prof Ripley,
 
 A quick note to indicate that it appears that the primary 'tests' directory, 
 which contains the code and related files for running 
 tools::testInstalledBasic() is not present in the current OSX binary package 
 for 3.0.0 beta 
 (http://r.research.att.com/snowleopard/R-3.0-branch/R-3.0-branch-snowleopard-signed.pkg).
 
 As a consequence, the following fails:
 
 testInstalledBasic(both)
 Error in setwd(file.path(R.home(), tests)) : 
 cannot change working directory
 
 with the missing directory being:
 
 file.path(R.home(), tests)
 [1] /Library/Frameworks/R.framework/Resources/tests
 
 
 Similarly, it seems that the individual 'tests' directories, where 
 appropriate, for base and recommended packages (used via 
 tools::testInstalledPackages()) are also not present in the current OSX beta 
 binary package.
 
 I presume that this may have been inadvertent in the preparation of this 
 build prior to Simon's departure.
 
 
 Yes, the build just did make install and not install-tests, now fixed. Also 
 there was a crontab hiccup so hopefully nightlies will be showing up as 
 before.
 
 Thanks,
 Simon


Thanks for the update Simon. I will re-try with an updated binary build as soon 
as I get a chance.

Regards,

Marc

 
 
 Beyond that, I also wanted to note and say thanks (Fritz?) for modifying 
 Sweave so that the output now includes the line number for the chunk being 
 processed. A major help for debugging.
 
 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] R 3.0.0 beta

[Marc Schwartz]

Prof Ripley,

A quick note to indicate that it appears that the primary 'tests' directory, 
which contains the code and related files for running 
tools::testInstalledBasic() is not present in the current OSX binary package 
for 3.0.0 beta 
(http://r.research.att.com/snowleopard/R-3.0-branch/R-3.0-branch-snowleopard-signed.pkg).

As a consequence, the following fails:

 testInstalledBasic(both)
Error in setwd(file.path(R.home(), tests)) : 
  cannot change working directory

with the missing directory being:

 file.path(R.home(), tests)
[1] /Library/Frameworks/R.framework/Resources/tests


Similarly, it seems that the individual 'tests' directories, where appropriate, 
for base and recommended packages (used via tools::testInstalledPackages()) are 
also not present in the current OSX beta binary package.

I presume that this may have been inadvertent in the preparation of this build 
prior to Simon's departure.

Beyond that, I also wanted to note and say thanks (Fritz?) for modifying Sweave 
so that the output now includes the line number for the chunk being processed. 
A major help for debugging.

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] Encoding issue with text output from R

[Marc Schwartz]

On Jan 31, 2013, at 11:17 AM, Fisher Dennis fis...@plessthan.com wrote:

 R 2.15.2
 OS X ML
 
 Colleagues,
 
 I am sinking output from statistical tests to a text file:
   sink(FILENAME)
   SOMETEST()
   sink()
 
 When I open the file with TextEdit, the output from lm() contains:
   Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1 
 
 When I open the identical file in Word (2008), that same text appears as:
   Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 
 0.1 ‘ ’ 1 
 When Word opens, it asks about the selection of encoding for the file.  I 
 tried a number of options and all lead to the same distorted text.
 
 Any idea how to resolve this (other than to ignore Word!)?
 
 Dennis  


Looks like the directional quotes are messing you up.

Modify your code to use:

  options(useFancyQuotes = FALSE)

before you use sink().

Also, you could use:

  options(show.signif.stars = FALSE)

to suppress the inclusion of the significance stars, which I have in my 
.Rprofile file.

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 2.15.2, OS X 10.8.2, JGR

[Marc Schwartz]

On Dec 28, 2012, at 3:05 PM, peter dalgaard pda...@gmail.com wrote:

 
 On Dec 28, 2012, at 20:40 , Roy Mendelssohn - NOAA Federal wrote:
 
 Hi All:
 
 I recently upgraded my computer to 10.8.2, and my Java is now java 1.7 from 
 Oracle.  I am running R 2.15.2, and now rjava and JGR don't work because 
 what appears to be a problem with ipot.  I tried reinstalling rjava and got 
 the following:
 
 I can't remember this kind of stuff form one occasion to the next either, but 
 wouldn't it be something with sudo R CMD javareconf ?



For Mountain Lion, it should be:

  sudo R CMD javareconf 
JAVA_CPPFLAGS=-I/System/Library/Frameworks/JavaVM.framework/Headers

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 2.15.2, OS X 10.8.2, JGR

[Marc Schwartz]

Roy,

Did you install the 1.7 JRE only, or did you also install the JDK?  

If you did not also install the JDK, I believe that you need to do so. It is 
available here:

  
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

Install that and then run the full javareconf command as I had in my reply 
below.

Regards,

Marc

On Dec 28, 2012, at 6:11 PM, Roy Mendelssohn - NOAA Federal 
roy.mendelss...@noaa.gov wrote:

 Thanks.  But I am still stuck.  No matter which command I give, I  get the 
 following:
 
 sudo R CMD javareconf
 Password:
 Java interpreter : /usr/bin/java
 Java version : 1.6.0_29
 Java home path   : 
 /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
 Java compiler: /usr/bin/javac
 Java headers gen.: /usr/bin/javah
 Java archive tool: /usr/bin/jar
 Java library path: 
 JNI linker flags : -framework JavaVM
 JNI cpp flags: -I$(JAVA_HOME)/include
 
 
 Note the Java home path.  But when I  do the following:
 
 bash-$ which java
 /usr/bin/java
 bash-$ java -version
 java version 1.7.0_06
 Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
 Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode)
 
 
 So where is ti getting that the home path is to 
 /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home?  Is 
 there a file that I can hand edit to give R the correct values?
 
 Thanks.
 
 -Roy M.
 On Dec 28, 2012, at 1:28 PM, Marc Schwartz marc_schwa...@me.com wro
 
 On Dec 28, 2012, at 3:05 PM, peter dalgaard pda...@gmail.com wrote:
 
 
 On Dec 28, 2012, at 20:40 , Roy Mendelssohn - NOAA Federal wrote:
 
 Hi All:
 
 I recently upgraded my computer to 10.8.2, and my Java is now java 1.7 
 from Oracle.  I am running R 2.15.2, and now rjava and JGR don't work 
 because what appears to be a problem with ipot.  I tried reinstalling 
 rjava and got the following:
 
 I can't remember this kind of stuff form one occasion to the next either, 
 but wouldn't it be something with sudo R CMD javareconf ?
 
 
 
 For Mountain Lion, it should be:
 
 sudo R CMD javareconf 
 JAVA_CPPFLAGS=-I/System/Library/Frameworks/JavaVM.framework/Headers
 
 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] R 32-bit suddenly the default on Mountain Lion 10.8.2?

[Marc Schwartz]

Hi All,

I am on a fully updated MacBook Pro, running 10.8.2. I get:

uname -m
x86_64

from the terminal, as would be expected.

I have been using the CRAN OSX binaries for some time now, rather than building 
from source, which I had been doing previously.

Somewhere along the way in the past few weeks, apparently since I installed R 
2.15.2, the default architecture under which R is running is now 32 bit, not 64 
bit, which was the case previously. I just noted this today due to some funny 
encoding issues that I had not seen before and have spent the past few hours 
trying to figure out what changed.

I initially thought something was amiss with the latest 2.15.2 release .pkg 
file. I completely removed R (Framework and symlinks to the startup scripts, 
etc.) and re-installed. Same thing. 32 bit R was the default link from 'R'.

So I removed R again and re-installed 2.15.1 (getting the older binary from 
CRAN), since that was the last version of R that I had installed which 
defaulted to 64 bit.

Funny, same thing, it defaulted to 32 bit R.

Then I wondered if there was something related to some anti-virus software 
(Avast) that I had recently installed due to some events that had occurred 
recently. I completely removed the AV software, rebooted, removed R and then 
re-installed R. Same thing, 32 bit R as the default.

What am I missing here? What is the installation program and/or the R startup 
script itself looking for that determines whether 64 or 32 bit R should the 
default when one simply uses 'R' to start it up? A read of the R startup script 
suggests that the output (as above) of 'uname -m' being 'x86_64' may be all 
that is needed, but perhaps I am missing something else.

I am also attaching the full installation log file here (for 2.15.2). I did not 
see anything there obvious to my eyes.

I can't recall the timeline well enough right now to consider whether some OSX 
update changed something, or if there is something strictly unique to my MBP 
that is causing this problem. 

Thanks for any insights.

Regards,

Marc

Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: @(#)PROGRAM:Install  
PROJECT:Install-735
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: @(#)PROGRAM:Installer 
 PROJECT:Installer-614
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Hardware: 
MacBookPro5,2 @ 2.93 GHz (x 2), 8192 MB RAM
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Running OS Build: Mac 
OS X 10.8.2 (12C60)
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
PATH=/usr/bin:/bin:/usr/sbin:/sbin
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
TMPDIR=/var/folders/gs/c40xg0qx2gx1xsxjtkhvj9_mgn/T/
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: SHELL=/bin/bash
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
HOME=/Users/marcschwartz
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: USER=marcschwartz
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
LOGNAME=marcschwartz
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
SSH_AUTH_SOCK=/tmp/launch-hGcfqP/Listeners
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
Apple_Ubiquity_Message=/tmp/launch-q7Pvlb/Apple_Ubiquity_Message
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
Apple_PubSub_Socket_Render=/tmp/launch-a5t0gM/Render
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
DISPLAY=/tmp/launch-pAOUPH/org.macosforge.xquartz:0
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
COMMAND_MODE=unix2003
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Env: 
__CF_USER_TEXT_ENCODING=0x1F5:0:0
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: R 2.15.2 for Mac OS X 
10.5 or higher (Leopard build)  Installation Log
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Opened from: 
/Users/marcschwartz/R.Files/SourceAndBinaries/OSX-Binary/Release/R-2.15.2.pkg
Nov 13 12:12:28 ws195.mednetregistry.com Installer[1078]: Product archive 
/Users/marcschwartz/R.Files/SourceAndBinaries/OSX-Binary/Release/R-2.15.2.pkg 
trustLevel=202
Nov 13 12:13:51 ws195.mednetregistry.com Installer[1078]: 
InstallerStatusNotifications plugin loaded
Nov 13 12:14:04 ws195.mednetregistry.com runner[1088]: Administrator 
authorization granted.
Nov 13 12:14:04 ws195.mednetregistry.com Installer[1078]: 

Nov 13 12:14:04 ws195.mednetregistry.com Installer[1078]: User picked Standard 
Install
Nov 13 12:14:04 ws195.mednetregistry.com Installer[1078]: Choices selected for 
installation:
Nov 13 12:14:04 ws195.mednetregistry.com Installer[1078]:   Upgrade: R 
2.15.2 for Mac OS X 10.5 or higher (Leopard build)
Nov 13 12:14:04 ws195.mednetregistry.com Installer[1078]:   Upgrade: R 
2.15.2 Framework
Nov 13 12:14:04 ws195.mednetregistry.com Installer[1078]:   
R-2.15.2.pkg#r.pkg : 

Re: [R-SIG-Mac] R 32-bit suddenly the default on Mountain Lion 10.8.2?

[Marc Schwartz]

On Nov 13, 2012, at 1:59 PM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:

 Marc,
 
 Start with 'which R', or run /usr/bin/R explicitly.  


Hi Prof Ripley,

Thanks.


~  which R
/usr/bin/R


/usr/bin/R called directly launches 32 bit R.


R64 launches 64 bit R as one might expect:

~  ls -l /usr/bin/R64
lrwxr-xr-x  1 root  wheel  49 Nov 13 12:15 /usr/bin/R64 - 
/Library/Frameworks/R.framework/Resources/bin/R64


 That should be a symlink to
 
 /Library/Frameworks/R.framework/Resources/bin/R
 

~  ls -l /usr/bin/R
lrwxr-xr-x  1 root  wheel  47 Nov 13 12:14 /usr/bin/R - 
/Library/Frameworks/R.framework/Resources/bin/R


 and that should be a symlink,  If it is not like
 
 lrwxr-xr-x  1 root  admin  3 28 Oct 08:03 
 /Library/Frameworks/R.framework/Resources/bin/R@ - R64
 
 or is linked to R32, change it to point to R64.


~  ls -l /Library/Frameworks/R.framework/Resources/bin/R
-rwxrwxr-x  1 root  admin  8775 Oct 26 11:22 
/Library/Frameworks/R.framework/Resources/bin/R


 
 It is the installer which determines what it links to.  Specifically 
 https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/Simon/R-build/packaging/leopard/scripts/postflight
  .
 
 If running /Library/Frameworks/R.framework/Resources/bin/R64 is not x86_64, 
 come back to us.


That does run 64 bit R, as expected.

Looks like a key flag in the shell script in SVN is:

~  /usr/sbin/sysctl hw.cpu64bit_capable
hw.cpu64bit_capable: 1


Going to try to work my way through the shell script a bit more, but wanted to 
get back with this information.

Thanks,

Marc


 
 Brian
 
 On 13/11/2012 19:06, Marc Schwartz wrote:
 Hi All,
 
 I am on a fully updated MacBook Pro, running 10.8.2. I get:
 
 uname -m x86_64
 
 from the terminal, as would be expected.
 
 I have been using the CRAN OSX binaries for some time now, rather
 than building from source, which I had been doing previously.
 
 Somewhere along the way in the past few weeks, apparently since I
 installed R 2.15.2, the default architecture under which R is running
 is now 32 bit, not 64 bit, which was the case previously. I just
 noted this today due to some funny encoding issues that I had not
 seen before and have spent the past few hours trying to figure out
 what changed.
 
 I initially thought something was amiss with the latest 2.15.2
 release .pkg file. I completely removed R (Framework and symlinks to
 the startup scripts, etc.) and re-installed. Same thing. 32 bit R was
 the default link from 'R'.
 
 So I removed R again and re-installed 2.15.1 (getting the older
 binary from CRAN), since that was the last version of R that I had
 installed which defaulted to 64 bit.
 
 Funny, same thing, it defaulted to 32 bit R.
 
 Then I wondered if there was something related to some anti-virus
 software (Avast) that I had recently installed due to some events
 that had occurred recently. I completely removed the AV software,
 rebooted, removed R and then re-installed R. Same thing, 32 bit R as
 the default.
 
 What am I missing here? What is the installation program and/or the R
 startup script itself looking for that determines whether 64 or 32
 bit R should the default when one simply uses 'R' to start it up? A
 read of the R startup script suggests that the output (as above) of
 'uname -m' being 'x86_64' may be all that is needed, but perhaps I am
 missing something else.
 
 I am also attaching the full installation log file here (for 2.15.2).
 I did not see anything there obvious to my eyes.
 
 I can't recall the timeline well enough right now to consider whether
 some OSX update changed something, or if there is something strictly
 unique to my MBP that is causing this problem.
 
 Thanks for any insights.
 
 Regards,
 
 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] R 32-bit suddenly the default on Mountain Lion 10.8.2?

[Marc Schwartz]

On Nov 13, 2012, at 3:15 PM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:

 Simon is pretty much off-line, which is why I replied.


Thank you for doing so.


 I would simply set the R-R64 symlink as the installer would have done in SL 
 and Lion.  The things will work as you expected.


Yeah, that's probably a good idea. Murphy's Law would kick in at some point and 
I would forget to use 'R64'. :-)

Thanks again,

Marc


 Because I have so many flavours of R installed, I make my own links (in 
 ~/bin, which is on my path).
 
 On 13/11/2012 20:58, Marc Schwartz wrote:
 
 On Nov 13, 2012, at 2:30 PM, Berend Hasselman b...@xs4all.nl wrote:
 
 
 On 13-11-2012, at 21:07, Federico Calboli f.calb...@imperial.ac.uk wrote:
 
 On 13 Nov 2012, at 19:59, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:
 
 Marc,
 
 Start with 'which R', or run /usr/bin/R explicitly.
 
 $ which R
 /usr/bin/R
 
 
 That should be a symlink to
 
 /Library/Frameworks/R.framework/Resources/bin/R
 
 it does:
 
 $ ls -l /usr/bin/R
 lrwxr-xr-x  1 root  wheel  47 28 Oct 10:47 /usr/bin/R@ - 
 /Library/Frameworks/R.framework/Resources/bin/R
 
 
 and that should be a symlink,
 
 it's not:
 
 $ ls -l /Library/Frameworks/R.framework/Resources/bin/R
 -rwxrwxr-x  1 root  admin  8775 26 Oct 17:22 
 /Library/Frameworks/R.framework/Resources/bin/R*
 
 $ ls /Library/Frameworks/R.framework/Resources/bin/R*
 /Library/Frameworks/R.framework/Resources/bin/R*   
 /Library/Frameworks/R.framework/Resources/bin/Rd2pdf*
 /Library/Frameworks/R.framework/Resources/bin/R32* 
 /Library/Frameworks/R.framework/Resources/bin/Rdconv*
 /Library/Frameworks/R.framework/Resources/bin/R64* 
 /Library/Frameworks/R.framework/Resources/bin/Rdiff*
 /Library/Frameworks/R.framework/Resources/bin/REMOVE*  
 /Library/Frameworks/R.framework/Resources/bin/Rprof*
 /Library/Frameworks/R.framework/Resources/bin/Rcmd*
 /Library/Frameworks/R.framework/Resources/bin/Rscript*
 
 
 BW
 
 F
 
 The postflight script tests for 10.6 and 10.7 but not for 10.8.
 The relevant  lines are
 
 # some jobs needed specifically on Mac OS X 10.6 (Snow Leopard) and 10.7 
 (Lion)
 if uname -r | grep ^1[01] /dev/null; then
 
 On 10.8.2 uname -r returns 12.2.0 and that doesn't match the grep test.
 It would seem that the test should be grep ^1[012] or grep ^1[0-2] .
 
 Actually, I think it needs to be future-proofed.
 
 
 Berend
 
 
 I was just getting around to that section of the script.
 
 I suspect that this is correct and the timing would make sense with my 
 observations here.
 
 Mountain Lion was released on July 25 and I updated shortly thereafter.
 
 The R 2.15.1 OSX binary is dated June 22, before ML was available, so I 
 would have had that installed under Lion, since I would have updated from 
 2.15.0 soon after the R OSX binary became available. Thus, 64 bit R would 
 have been the default at that time.
 
 R 2.15.2 was of course released after ML, so that is when the change 
 occurred to 32 bit R.
 
 
 Under ML as Berend notes above:
 
 ~  uname -r
 12.2.0
 
 ~  uname -r | grep ^1[012]
 12.2.0
 
 
 I had sent an initial e-mail to Simon with the information, but he replied 
 from his iPhone that he is away for a couple of weeks sans computer.
 
 In the mean time, I will get in the habit of using 'R64' from the CLI and in 
 ESS.
 
 If there is anything else that is needed, let me know.
 
 Thanks all!
 
 Regards,
 
 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] Re-creating PDF's

[Marc Schwartz]

On Oct 22, 2012, at 12:36 PM, Fisher Dennis fis...@plessthan.com wrote:

 R 2.15.1
 Lion
 
 Colleagues
 
 In previous versions of OS X, I might do the following:
   1.  create a PDF in R
   pdf(FILENAME)
   plot(1)
   dev.off() 
   2.  open the file using the command 
   system(open …)
   3.  create the file again (same commands as above). 
 The opened file was replaced with the new version.
 (This differs from Windows in which the file needed to be closed in order to 
 create a new version)
 
 As of Lion, it appears that something changed.  In some instances, the 
 behavior is identical, i.e., creating the new version of the file results in 
 the open version being replaced with the second version.  However, in some 
 circumstances, I observe the following behavior:
   1.  the original version of the file remains open
   2.  the new version appears as a second instance of Preview
   3.  the system appears to freeze for a few seconds
   4.  Preview is frozen and requires a ForceQuit
 
 Sample code is:
 pdf(xx.pdf) ; plot(1); dev.off() ; system(open xx.pdf); Sys.sleep(3) ; 
 pdf(xx.pdf) ; plot(2); dev.off()
 
 The code above results in the desired outcome and I can't provide a short 
 reproducible example (the problem only happens with extremely large multipage 
 documents).
 
 Does anyone have any thoughts as to whether this is a problem in OS X 
 (Preview) or R?  Any thoughts on how to prevent it from happening?  I suspect 
 that this will be a un-solveable mystery but I thought that it was worth 
 asking.
 
 Dennis



This may be a consequence of the change in Lion, which introduced Auto Save and 
Versions (a local version control system) as part of the OS functionality. Note 
the little pull down menu (downward pointing triangle) to the right of the file 
name in the Preview title bar when you move the cursor over the file name.

These might be helpful for background:

  http://support.apple.com/kb/HT4753

  http://support.apple.com/kb/PH3729

but the distinctions between the various operations (Save As, Duplicate, 
Export) can be confusing. Save As came back in Mountain Lion if you press 
the Alt key while viewing the File menu in the app.

Using your sample code above, the original file is replaced with the second 
version when I actually click on the Preview app window, so that it has focus. 
This is a behavior that has been consistent to me for some time, when using 
Sweave, for example, even with very large (100's of pages) PDF documents. I 
have never ended up with a second instance of Preview, when viewing the same 
PDF file.

You might want to check/change the When opening files: options in Preview's 
Preferences - General tab to see if that affects the behavior you are 
observing.

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 console

[Marc Schwartz]

On Aug 24, 2012, at 7:03 AM, Noia Raindrops noia.raindr...@gmail.com wrote:

 Hello, 
 
 I thing you need to install X11.app.
 see: http://support.apple.com/kb/HT5293


Strictly speaking, that is only needed on Mountain Lion, as prior versions of 
OSX include X11 on the installation DVD/DMG.

I don't use the R OSX GUI, but Emacs/ESS. That being said, I can replicate the 
problem on Mountain Lion (10.8.1) with XQuartz installed.

If Weiwei is using ML, then he should install the above, however note that the 
name of the app is now XQuartz.app and not X11.app. So even if installed, the 
GUI icon selection will still fail. 

If  Weiwei is not using ML, then X11 is available on the installation DVD on 
pre-Lion versions of OSX, or if on Lion (10.7) it is available from the 
'Packages' folder on the install DMG.

I am adding John Fox as a cc: to this e-mail as in the course of searching, I 
noted the R Commander installation instructions 
(http://socserv.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html), which 
includes mention of X11.app, but not XQuartz.app for Mountain Lion. So that 
page and related documentation will need to be updated.

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] Tab setting in R.app editor

[Marc Schwartz]

On Jun 9, 2012, at 3:56 PM, David Winsemius wrote:

 
 On Jun 9, 2012, at 11:11 AM, David Winsemius wrote:
 
 
 On Jun 9, 2012, at 5:03 AM, Hans-Jörg Bibiko wrote:
 
 
 On Jun 9, 2012, at 2:05 AM, zListserv wrote:
 
 Is there a way to change to default tab stop setting from the present 4 
 characters (stops at 5, 9, etc) to 8 characters (stops at 9, 17, etc)?
 
 Yes,
 
 you can set it by executing the following line in the Terminal:
 
 defaults write org.R-project.R  R Script Editor tab width 8
 
 Thanks, Hans for that taste of customization. And thanks for all your work 
 on R.app.
 
 Is there a more general list of features that could be adjusted? Is the 
 Script Editor built on a platform that is more generally used and might have 
 external documentation?
 
 After looking around a bit more it looks to me that the Script Editor is its 
 own entity. I found this list of PreferenceKeys in which R Script Editor tab 
 width is one instance:
 
 https://svn.r-project.org/R-packages/trunk/Mac-GUI/PreferenceKeys.h
 
 Am I correct in assuming these are stored in a .plist file?



David,

Looks like it might be:

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

The Property List Editor application that used to be included in OSX has been 
integrated into XCode, AFAICS, which makes it a bit more cumbersome to edit the 
file.

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] Building binary packages for distribution

[Marc Schwartz]

Hi,

I will readily admit that I am naive in terms of some of the subtleties, but 
would running Leopard under Lion in a VM be a suitable possibility?

It would seem that with Lion, some of the licensing issues relative to running 
non-server versions of the older OSX distributions under a VM have changed, at 
least that it what is intimated by an article here for VMWare Fusion:

  
http://www.macworld.com/article/1163755/vmware_fusion_update_lets_users_virtualize_leopard_snow_leopard.html

Not sure if that is helpful, but recalled seeing some discussions on this over 
the past few months or so.

Regards,

Marc Schwartz

On Apr 13, 2012, at 12:34 PM, Prof Brian Ripley wrote:

 Thanks, that is bad news.
 
 I really don't want to ask our sysadmins to maintain a Leopard system for the 
 very limited amount of package building we do, so we'll have to hope this 
 suffices.
 
 On 13/04/2012 18:05, Simon Urbanek wrote:
 
 On Apr 13, 2012, at 11:36 AM, Prof Brian Ripley wrote:
 
 I have hitherto used a Leopard system to build Mac binary packages
 for distribution, but that system has died and we only have Lion
 systems left (and the replacement hardware only runs Lion).  I'm
 only concerned with building i386/x86_64 packages.
 
 We saw problems with packages built on Snow Leopard which would not
 run on Leopard, and the trick was to use -mmacosx-version-min=10.5
 for compiling and linking.
 
 
 It is only partially sufficient. The min version makes sure that the
 Mach-O output is 10.5-compatible, but it will still happily use
 Lion-only libraries when linking. You have to use 10.5 SDK (typically
 via -isysroot) in order to make sure the linked frameworks and
 libraries are actually compatible and present on Leopard.
 
 I have at some point contemplated building the R releases and
 packages on SL with the 10.5 SDK, but it is simply too fragile. There
 are issues in details of dependencies, such as packages that use
 configuration scripts to determine flags (like gsl-config) -- you'd
 have to maintain a full system and worry about paths (linker/include
 paths may work with -isysroot re-direction but any other paths
 won't).
 
 That said, it is possible to build R itself that way. I'd even argue
 that it's better to simply create pre-drivers for compilers that
 automatically add the corresponding -isysroot et al. and then exec
 the compiler rather than setting the flags fully.
 
 
 
 Does anyone know for certain if that suffices?  And does setting
 the environment variable MACOSX_DEPLOYMENT_TARGET to 10.5 do the
 same thing?  (My man pages suggest so, but I don't trust Apple's
 documentation to be current.)
 
 
 AFAIK, yes, but it is equally insufficient. Apple has been warning
 about the env vars for a while that they may get rid of them, but I
 dont' think they did so far (there were more useful ones for managing
 sysroot which I think they got rid of by now).
 
 Best, Simon


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

Re: [R-SIG-Mac] Building binary packages for distribution

[Marc Schwartz]

On Apr 13, 2012, at 12:48 PM, Marc Schwartz wrote:

 Hi,
 
 I will readily admit that I am naive in terms of some of the subtleties, but 
 would running Leopard under Lion in a VM be a suitable possibility?
 
 It would seem that with Lion, some of the licensing issues relative to 
 running non-server versions of the older OSX distributions under a VM have 
 changed, at least that it what is intimated by an article here for VMWare 
 Fusion:
 
  
 http://www.macworld.com/article/1163755/vmware_fusion_update_lets_users_virtualize_leopard_snow_leopard.html
 
 Not sure if that is helpful, but recalled seeing some discussions on this 
 over the past few months or so.


Snipped older content

Just as a follow up and in the course of an offlist exchange with Prof. Ripley, 
I located some additional information on the issue of non-server versions of 
OSX running as guest OS's under Lion.

The Release Notes for VMWare's Fusion, version 4.1.1, include a Resolved 
Issues list 
(http://www.vmware.com/support/fusion4/doc/releasenotes_fusion_411.html#resolvedissues),
 which notes:

  Fusion 4.1.1 includes the Mac OS X Server check omitted from VMware Fusion 
4.1.0.

So it would seem that the prior behavior described in the MacWorld article was 
either an error on the part of VMWare and/or Apple's corporate counsel made 
some phone calls.

I also posted a comment to the MacWorld article with the above information for 
the benefit of others who may, as I did, read the article and get the wrong 
impression of the current state of affairs.

So with that, based upon other research, each of the VM providers, VMWare, 
Parallels and VirtualBox, are limited to using the server versions of Leopard 
and Snow Leopard under Lion as a host.

Regards,

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] Wish for the GUI: themes

[Marc Schwartz]

On Mar 13, 2012, at 7:15 AM, Timothy Bates wrote:

 Hi,
 Teaching with R, I find the mac GUI very nice, and so do students once they 
 see the shortcuts etc. (I don’t get why mac people would use R-Studio…)
 
 For myself, I still use a customized Textmate command bundle to work with R.
 
 One thing I miss in R.app at present is themes, especially this one
 
 https://github.com/avian/TextMate-Tomorrow-Theme
 
 It would be great if R Gui could look like this
   http://d.pr/CqdM
 Instead of this
   http://d.pr/DZjA
 
 
 Bes, tim


To narrowly address the why would Mac people use R-Studio, as a user of 
Emacs/ESS for 10 years, the advantage is going to be primarily cross-platform 
support AFAICS. As one who has evolved from using R on Windows starting in 
late 2001, to RH/Fedora Linux in late 2002, to OSX in early 2009, the one 
constant has been Emacs/ESS.

If one is in a mixed OS environment, I can see much logic in using R-Studio, if 
one is not open to Emacs/ESS. It can provide a consistent and productive 
working environment. You don't have to deal with training on multiple IDEs, 
recalling instinctively multiple methods of interacting with editors and other 
functionality, which increases productivity.

I have played with R-Studio and R.app. Both are good and much credit goes to 
the developers of both.

Also, as one who has been routinely using version control (svn) for a number of 
years, the support in Emacs/ESS has been extremely helpful. R-Studio appears to 
have support for both svn and git from what I can tell via the project 
functionality, though I have not played with it. I don't believe that such 
support is available in R.app, though I stand to be corrected on that. Of 
course for svn on OSX, there is always the CLI or GUI based apps such as 
Cornerstone.

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] OSX Binary Installation and testInstalledPackages()

[Marc Schwartz]

Simon,

Thanks so much for making this change!

I downloaded the latest nightly and ran all tests (testInstalledBasic(both) 
and then testInstalledPackages() for examples, tests and vignettes for both 
base and recommended) locally here, which all pass. This is great!

Will this change also show up in the next stable release on CRAN?

For those who may still be following this thread, be sure that you run these 
tests in an R session using 'R --vanilla' from the command line (OSX Terminal 
app in Applications/Utilities), rather than using R.app or other GUIs (eg. 
RStudio, etc.). You may have modifications in your .Rprofile or elsewhere that 
may conflict with these tests and the GUI's may similarly alter the default 
environment. In addition, you should run these tests before installing any CRAN 
or other third party packages, which may also result in some conflicts with 
these tests. 

Simon, thanks again for this change and the incredibly fast turn around!

Best regards,

Marc


On Feb 2, 2012, at 9:40 AM, Simon Urbanek wrote:

 The current builds now contains tests. As Brian noted size is probably not an 
 issue anymore so it was the easiest to simply run install-tests in the build.
 
 Cheers,
 Simon
 
 
 On Feb 1, 2012, at 2:18 PM, Marc Schwartz wrote:
 
 Hi Simon,
 
 On Feb 1, 2012, at 12:08 PM, Simon Urbanek wrote:
 
 Marc,
 
 On Feb 1, 2012, at 12:13 PM, Marc Schwartz wrote:
 
 Hi all,
 
 I have been building R from source for a number of years on Linux and for 
 the past 3 years, on OSX. Since circa version 2.9.0 I believe, there have 
 been functions available in the 'tools' package to run post-installation 
 tests of the base and recommended packages. These parallel the post-build 
 from source 'make check-all' functionality, but can be run within R. They 
 run the help file examples, more extensive package specific tests as well 
 as vignette code when present.
 
 When building from source, one can run 'make install-tests' to install the 
 required files to run the more extensive package tests after the initial 
 build, rather then just the examples in the help files.
 
 On Windows, there is an option during the GUI installation of the 
 pre-built binary, to install these additional test files.
 
 When installing the pre-built binary for OSX, just to consider that path, 
 I did not see an option to install these test files and I don't see any 
 CLI functionality to replicate the installation of the test files that 
 would be performed when building from source. A search of the R.framework 
 tree did not yield any indication that the files are present, which would 
 normally be in a 'tests' folder (eg. see 
 https://svn.r-project.org/R/branches/R-2-14-branch/tests/).
 
 So, are these files not installed or made available when using the OSX 
 binary or am I missing something?
 
 Yes, they are not available in the binary distribution. You can still use 
 make install-tests when compiling your own R, and since they are 
 arch-independent you can pick any architecture for that.
 
 It would be certainly possible to include the test files in the 
 distribution, but so far you are the first person asking about that, so it 
 doesn't seem prudent. However, it would be even easier to just add a 
 separate tar ball of tests to the http://R.reasearch.att.com site for 
 nightly builds if that would satisfy your needs.
 
 Cheers,
 Simon
 
 
 Thanks for your reply and confirmation. I can certainly continue, as I have 
 done, to build R from source. In my case, I build 32 bit R, as I don't have 
 a need for the additional memory address space provided by 64 bits, even 
 though I have 8Gb on my MBP. It takes about 20 minutes to build and another 
 40 to run the full suite of tests.
 
 I was just doing some forward looking, considering alternatives to building 
 from source and instead using the OSX binaries, both the stable release on 
 CRAN and the patched versions that you kindly provide at the URL you list 
 above. There are benefits to using the official binaries of course.
 
 Providing a tarball of the tests folder, matching svn revs, for the 
 nightlies, would certainly be helpful. Presumably there would need to be a 
 brief README file so that folks would know how and where to install them. I 
 can assist with that, if you desire. The default location would be 
 /Library/Frameworks/R.framework/Resource/tests (eg. R.home(tests)).
 
 My broad perspective is that these tests are in effect, an integral part of 
 validating an R installation, which is something that I do. While this has 
 special meaning for folks involved in clinical trials (eg. see 6.3 in 
 http://www.r-project.org/doc/R-FDA.pdf), it seems logical that this would 
 have value to folks in other domains as well. It would make it easier for 
 useRs to fully utilize the functions in 'tools' that R Core has taken the 
 time and consideration to provide.
 
 Presumably, somewhere along the way around the time of 2.9.0, a decision was 
 made