Re: [R-SIG-Mac] Rcmdr
Hello Simon, Actually the Rcmdr *does* import (and use) the tcltk2 package, but I've had no other report of this kind of problem and haven't observed it myself. Best, John -- John Fox, Professor Emeritus McMaster University Hamilton, Ontario, Canada web: https://www.john-fox.ca/ On 2023-07-31 6:46 p.m., Simon Urbanek wrote: Caution: External email. Agreed, no problem here even with Rcmdr in older R 4.2.0. As Peter said, Rcmdr doesn't use tcltk2 so I'm sure there is a lot you're omitting here. If it doubt, make sure you don't load some old workspace and have the latest versions of all packages, e.g. via update.packages(ask=FALSE). Cheers, Simon On 1/08/2023, at 1:18 AM, peter dalgaard wrote: Hum.. Not happening here with 4.3.1 from CRAN. Why are you getting errors relating to 4.2? Also puzzling is library/tcltk2, which I don't seem to have (only tcltk). A hunch is that the tcltk2 package could be involved, but even installing that, I don't see a directory of that name under R.framework. - pd On 22 Jul 2023, at 14:20 , Sabrina Droussy wrote: Hello, I have a big problem with R. I hope you can help me please. I didn’t use R for some months and wanted to use it again to prepare an exam. I can’t open Rcmdr anymore. I tried several things : install packages, delete and reinstall R. It isn’t working. Here is the message I get : error reading package index file / Library/ Frameworks / R. Framework/ Versions/ 4.2/ Resources/ library/tcltk2/tklibs/ttktheme_radiance/pkgIndex.tcl: can’t find package tile error reading package index file / Library/ Frameworks / R. Framework/ Versions/ 4.2/ Resources/ library/tcltk2/tklibs/ttktheme_clearlooks/pkgIndex.tcl: too many nested evaluations (infinite loop ? ) Best regards Envoyé de mon iPhone ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0
Thank you Brian and Simon for fixing these problems. Best, John On 2021-09-18 2:20 a.m., Prof Brian Ripley wrote: On 09/09/2021 19:03, John Fox wrote: Dear Simon, Philippe, and list members, I've encountered some Tcl/Tk-related issues with the Apple silicon arm64 build of R 4.1.0 for macOS. These issues affect the Rcmdr package, although they don't prevent it from working: (1) Some fonts that are available for the Intel build appear to be missing from the arm64 build. Compare the screen shots of the Rcmdr main window at <https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png> (Intel build) and <https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png> (arm64 build). This problem is purely aesthetic. (2) The Tcl/Tk Tktable package is apparently absent from the arm64 build but still present in the Intel build. The Rcmdr detects its absence and suppresses some features (i.e., those requiring the Rcmdr data editor). I understand that the Tktable package is problematic and it may have been removed intentionally. The Tcl/Tk Tablelist package would be a reasonable substitute, and were it available, I could use it to restore the missing features in the Rcmdr. I'm aware that Philippe Grosjean planned to incorporate Tablelist in his tcltk2 package, but as far as I know, that plan hasn't yet materialized. If I knew how to supply a Tcl/Tk package in an R package, I could put Tablelist directly in the Rcmdr. Any help would be greatly appreciated. John To close this circle, Simon has provided https://mac.r-project.org/libs-arm64/tcltk-8.6.11-xft-darwin20.4-arm64.pkg If you install that, it updates Tk and adds Tktable, solving both problems. (As the Tcl/Tk installation is shared between R versions, this will fix 4.1.0 as well as 4.1.1. It will be incorporated in future releases.) ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0
Dear Brian, Thanks for this. When the Tktable package is available in the arm64 macOS binary, I'll test it. Best, John On 2021-09-10 1:54 a.m., Prof Brian Ripley wrote: On 09/09/2021 19:59, Prof Brian Ripley wrote: On 09/09/2021 19:03, John Fox wrote: Dear Simon, Philippe, and list members, ... (2) The Tcl/Tk Tktable package is apparently absent from the arm64 build but still present in the Intel build. The Rcmdr detects its absence and suppresses some features (i.e., those requiring the Rcmdr data editor). I understand that the Tktable package is problematic and it may have been removed intentionally. https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz (apparently the latest version from 2008) does not compile against recent Tcl/Tk (8.6.11 seems to be used): it uses 'panic' which should be 'Tcl_Panic'. (The Intel build appears to be much older, 8.6.6.) I have a patched version: AFAICS it installs entirely into /opt/R/arm64/lib I could tar it up and make it available. I could also send the patch to Simon for future use, but note that https://mac.r-project.org/libs-arm64/ contains an aqua build of Tcl/Tk (not the X11 build in the CRAN build of R 4.1.[01]) and which does not support Tcl/Tk. I have put the patch and the tarball at https://www.stats.ox.ac.uk/pub/bdr/Tktable/ . There is a README.txt with installation instructions. But as I have only one M1 Mac, they are minimally tested. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0
Dear Philippe,
Thanks for getting back to me.
On 2021-09-09 10:42 p.m., Philippe GROSJEAN wrote:
Dear John,
The tcltk2 package on CRAN includes tablelist version 5.5. The latest
development version on https://github.com/SciViews/tcltk2
<https://github.com/SciViews/tcltk2> includes tablelist version 6.9. The
last version of tcltk2 was not pushed to CRAN yet because many Tcl/Tk
packages were updated to higher versions and not everything is
completely tested today (I just recently got a Mac M1 machine for
testing on this system).
In the meantime, since I know you really want version 6.9 of tablelist,
you can do remotes::install_github(“SciViews/tcltk2@25df401”), or
inspect the code in tcltk2 to see how to include a pure-Tcl package and
place it in Rcmdr (it weights roughly 1Mb).
I coincidentally found your development version of tcltk2 on GitHub and
installed it earlier this evening.
I may do as you suggest, and temporarily incorporate tablelist directly
in the Rcmdr package, or just wait until the newest version of tcltk2 is
sent to CRAN. In the long run, I think that it's more maintainable not
to duplicate in the Rcmdr resources that are provided by tcltk2.
Best,
John
Best,
Philippe
..<°}))><
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
) ) ) ) )
( ( ( ( ( Numerical Ecology
) ) ) ) ) Mons University, Belgium
( ( ( ( (
..
On 9 Sep 2021, at 23:44, John Fox <mailto:j...@mcmaster.ca>> wrote:
Dear Brian,
Thank you for the additional explanation.
If I understand correctly, the X11 version of Tcl/Tk will continue to
be distributed with the R CRAN Intel and arm64 builds because it is
compatible with R.app. If so, the simplest solution is probably to
distribute the patched TkTable package with these builds, for
backwards compatibility (perhaps not just for the Rcmdr package).
Your instructions for including tktablelist with the Rcmdr package
seem clear, and I'll give that a try in case TkTable continues to be
unavailable in the arm64 build.
Best,
John
On 2021-09-09 4:57 p.m., Prof Brian Ripley wrote:
On 09/09/2021 21:34, John Fox wrote:
Dear Brian,
Thank you for responding so quickly. Please see below:
On 2021-09-09 2:59 p.m., Prof Brian Ripley wrote:
On 09/09/2021 19:03, John Fox wrote:
Dear Simon, Philippe, and list members,
I've encountered some Tcl/Tk-related issues with the Apple silicon
arm64 build of R 4.1.0 for macOS. These issues affect the Rcmdr
package, although they don't prevent it from working:
(1) Some fonts that are available for the Intel build appear to be
missing from the arm64 build. Compare the screen shots of the
Rcmdr main window at
<https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png
<https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png>>
(Intel build) and
<https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png
<https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png>>
(arm64 build). This problem is purely aesthetic.
It would be helpful to know what those fonts are. This is likely
to be a fontconfig issue and needs to be debugged by name.
I query the Tk default and fixed-width fonts via
tclvalue(.Tcl("font actual TkDefaultFont -family")
tclvalue(.Tcl("font actual TkFixedFont -family"))
and use those -- in the past, that produced pleasing font choices on
all platforms. In the macOS Intel build, the resulting font families
are "Verdana" and "Andale Mono"; in the arm64 build, "helvetica" and
"courier". Perhaps the Intel and arm64 builds were just configured
differently.
Yes, I think fontconfig was, and that may help Simon dig into this.
(2) The Tcl/Tk Tktable package is apparently absent from the arm64
build but still present in the Intel build. The Rcmdr detects its
absence and suppresses some features (i.e., those requiring the
Rcmdr data editor). I understand that the Tktable package is
problematic and it may have been removed intentionally.
https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz
<https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz>
(apparently the latest version from 2008)
does not compile against recent Tcl/Tk (8.6.11 seems to be used):
it uses 'panic' which should be 'Tcl_Panic'. (The Intel build
appears to be much older, 8.6.6.)
I have a patched version: AFAICS it installs entirely into
/opt/R/arm64/lib I could tar it up and make it available.
I could also send the patch to Simon for future use, but note that
https://mac.r-project.org/libs-arm64/
<https://mac.r-project.org/libs-arm64/> contains an aqua build of
Tcl/Tk (not the X11 build in the CRAN build of R 4.1.[01]) and
which doe
Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0
Dear Brian,
Thank you for the additional explanation.
If I understand correctly, the X11 version of Tcl/Tk will continue to be
distributed with the R CRAN Intel and arm64 builds because it is
compatible with R.app. If so, the simplest solution is probably to
distribute the patched TkTable package with these builds, for backwards
compatibility (perhaps not just for the Rcmdr package).
Your instructions for including tktablelist with the Rcmdr package seem
clear, and I'll give that a try in case TkTable continues to be
unavailable in the arm64 build.
Best,
John
On 2021-09-09 4:57 p.m., Prof Brian Ripley wrote:
On 09/09/2021 21:34, John Fox wrote:
Dear Brian,
Thank you for responding so quickly. Please see below:
On 2021-09-09 2:59 p.m., Prof Brian Ripley wrote:
On 09/09/2021 19:03, John Fox wrote:
Dear Simon, Philippe, and list members,
I've encountered some Tcl/Tk-related issues with the Apple silicon
arm64 build of R 4.1.0 for macOS. These issues affect the Rcmdr
package, although they don't prevent it from working:
(1) Some fonts that are available for the Intel build appear to be
missing from the arm64 build. Compare the screen shots of the Rcmdr
main window at
<https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png>
(Intel build) and
<https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png>
(arm64 build). This problem is purely aesthetic.
It would be helpful to know what those fonts are. This is likely to
be a fontconfig issue and needs to be debugged by name.
I query the Tk default and fixed-width fonts via
tclvalue(.Tcl("font actual TkDefaultFont -family")
tclvalue(.Tcl("font actual TkFixedFont -family"))
and use those -- in the past, that produced pleasing font choices on
all platforms. In the macOS Intel build, the resulting font families
are "Verdana" and "Andale Mono"; in the arm64 build, "helvetica" and
"courier". Perhaps the Intel and arm64 builds were just configured
differently.
Yes, I think fontconfig was, and that may help Simon dig into this.
(2) The Tcl/Tk Tktable package is apparently absent from the arm64
build but still present in the Intel build. The Rcmdr detects its
absence and suppresses some features (i.e., those requiring the
Rcmdr data editor). I understand that the Tktable package is
problematic and it may have been removed intentionally.
https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz
(apparently the latest version from 2008)
does not compile against recent Tcl/Tk (8.6.11 seems to be used): it
uses 'panic' which should be 'Tcl_Panic'. (The Intel build appears
to be much older, 8.6.6.)
I have a patched version: AFAICS it installs entirely into
/opt/R/arm64/lib I could tar it up and make it available.
I could also send the patch to Simon for future use, but note that
https://mac.r-project.org/libs-arm64/ contains an aqua build of
Tcl/Tk (not the X11 build in the CRAN build of R 4.1.[01]) and which
does not support Tcl/Tk.
I'm sorry, but I don't quite understand that -- perhaps there's a typo
here? Do you mean to say that an aqua build of Tcl/Tk will replace the
X11 build after R 4.1.1, and that Tktable will be incompatible with it?
There was, so let me expand.
There are two Tk implementations on macOS,
- using aqua, which is included in https://mac.r-project.org/libs-arm64/
- using X11, included in the CRAN distributions of R 4.1.[01] on amd64,
and always used for Intel. So I do not have access to the details of
that build.
As I recall, TkTable does not install for the aqua implementation, but
does (when patched) for the X11 implementation. My recollection is that
XQuartz became available for amd64 not long before R 4.0.0 and Simon
switched to X11 Tk, although pre-releases had aqua Tk.
If so, first, I think that an aqua Tcl/Tk would be preferable to the
current X11 version. If I understand correctly, for example, aqua
would put Tk menus where Mac users expect them.
aqua Tk does not work correctly with R.app, and is not supported by
package tkrplot (which lots of other packages depend on). Personally I
usually use aqua Tk in my own builds, but then I only use R.app if
needed to debug something.
Second, given the problems that Tktable seems to be producing,
wouldn't it be better to make Tablelist available as a substitute? I'm
happy to rewrite the Rcmdr data editor using Tablelist (actually, it's
mostly done), and, as I said, if I knew how to incorporate the Tcl/Tk
Tablelist package in the Rcmdr package (if it's undesirable simply to
make it available generally), I'd do it.
That's your choice. The sources are at
https://www.nemethi.de/tablelist/tablelist6.15.tar.gz and contain a
README.txt with a 'How to Install It?'. At least on a Unix-alike you
just need to unpack that into somewhere on the Tcl path. So to
distrib
Re: [R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0
Dear Brian,
Thank you for responding so quickly. Please see below:
On 2021-09-09 2:59 p.m., Prof Brian Ripley wrote:
On 09/09/2021 19:03, John Fox wrote:
Dear Simon, Philippe, and list members,
I've encountered some Tcl/Tk-related issues with the Apple silicon
arm64 build of R 4.1.0 for macOS. These issues affect the Rcmdr
package, although they don't prevent it from working:
(1) Some fonts that are available for the Intel build appear to be
missing from the arm64 build. Compare the screen shots of the Rcmdr
main window at
<https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png>
(Intel build) and
<https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png>
(arm64 build). This problem is purely aesthetic.
It would be helpful to know what those fonts are. This is likely to be
a fontconfig issue and needs to be debugged by name.
I query the Tk default and fixed-width fonts via
tclvalue(.Tcl("font actual TkDefaultFont -family")
tclvalue(.Tcl("font actual TkFixedFont -family"))
and use those -- in the past, that produced pleasing font choices on all
platforms. In the macOS Intel build, the resulting font families are
"Verdana" and "Andale Mono"; in the arm64 build, "helvetica" and
"courier". Perhaps the Intel and arm64 builds were just configured
differently.
(2) The Tcl/Tk Tktable package is apparently absent from the arm64
build but still present in the Intel build. The Rcmdr detects its
absence and suppresses some features (i.e., those requiring the Rcmdr
data editor). I understand that the Tktable package is problematic and
it may have been removed intentionally.
https://sourceforge.net/projects/tktable/files/tktable/2.10/Tktable2.10.tar.gz
(apparently the latest version from 2008)
does not compile against recent Tcl/Tk (8.6.11 seems to be used): it
uses 'panic' which should be 'Tcl_Panic'. (The Intel build appears to
be much older, 8.6.6.)
I have a patched version: AFAICS it installs entirely into
/opt/R/arm64/lib I could tar it up and make it available.
I could also send the patch to Simon for future use, but note that
https://mac.r-project.org/libs-arm64/ contains an aqua build of Tcl/Tk
(not the X11 build in the CRAN build of R 4.1.[01]) and which does not
support Tcl/Tk.
I'm sorry, but I don't quite understand that -- perhaps there's a typo
here? Do you mean to say that an aqua build of Tcl/Tk will replace the
X11 build after R 4.1.1, and that Tktable will be incompatible with it?
If so, first, I think that an aqua Tcl/Tk would be preferable to the
current X11 version. If I understand correctly, for example, aqua would
put Tk menus where Mac users expect them.
Second, given the problems that Tktable seems to be producing, wouldn't
it be better to make Tablelist available as a substitute? I'm happy to
rewrite the Rcmdr data editor using Tablelist (actually, it's mostly
done), and, as I said, if I knew how to incorporate the Tcl/Tk Tablelist
package in the Rcmdr package (if it's undesirable simply to make it
available generally), I'd do it.
Best,
John
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Tcl/Tk issues in arm64 build of R 4.1.0
Dear Simon, Philippe, and list members, I've encountered some Tcl/Tk-related issues with the Apple silicon arm64 build of R 4.1.0 for macOS. These issues affect the Rcmdr package, although they don't prevent it from working: (1) Some fonts that are available for the Intel build appear to be missing from the arm64 build. Compare the screen shots of the Rcmdr main window at <https://socialsciences.mcmaster.ca/jfox/.Pickup/x86_64-apple-darwin17.0.png> (Intel build) and <https://socialsciences.mcmaster.ca/jfox/.Pickup/aarch64-apple-darwin20.png> (arm64 build). This problem is purely aesthetic. (2) The Tcl/Tk Tktable package is apparently absent from the arm64 build but still present in the Intel build. The Rcmdr detects its absence and suppresses some features (i.e., those requiring the Rcmdr data editor). I understand that the Tktable package is problematic and it may have been removed intentionally. The Tcl/Tk Tablelist package would be a reasonable substitute, and were it available, I could use it to restore the missing features in the Rcmdr. I'm aware that Philippe Grosjean planned to incorporate Tablelist in his tcltk2 package, but as far as I know, that plan hasn't yet materialized. If I knew how to supply a Tcl/Tk package in an R package, I could put Tablelist directly in the Rcmdr. Any help would be greatly appreciated. John -- John Fox, Professor Emeritus McMaster University Hamilton, Ontario, Canada web: https://socialsciences.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [External] Re: more rgl problems
Dear Rich,
I see R-4.0.4.pkg (not RC) at <https://cran.r-project.org/bin/macosx/>.
Perhaps refresh the page in your browser?
Best,
John
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/
On 2021-02-20 10:45 a.m., Richard M. Heiberger wrote:
I am running it now on 4.0.4RC.
The cran page
https://cran.r-project.org
offers download of 4.0.3 for mac, even though 4.0.4 is available on windows.
From: Duncan Murdoch
Sent: Saturday, February 20, 2021 9:41 AM
To: Richard M. Heiberger; r-sig-mac@r-project.org
Subject: Re: [External] Re: more rgl problems
If you are set up to install from source, could you try this?
devtools::install_github("dmurdoch/rgl@quartzbug", type="source")
If you only have some of the requirements (e.g. no devel versions of
packages) you might find you only get a partial build with no X11
display; that won't really test the workaround. In that case I'll try
to build a binary for your R version.
Duncan Murdoch
On 18/02/2021 6:07 p.m., Richard M. Heiberger wrote:
This is from my MacBook Air mid-2012 running Catalina 10.15.7
with Xquartz 2.7.11
I never placed the beta on this machine.
I also see from a fresh R session
plot(1:10, col=7)
library(rgl)
open3d()
is fine, whereas this:
library(rgl)
plot(1:10, col=7)
open3d()
segfaults
R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin17.0 (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
setwd('/Users/rmh/Rwd/')
library(rgl)
plot(1:10, col=7)
open3d()
library(rgl)
plot(1:10, col=7)
open3d()
error: xp_attach_gl_context returned: 2
*** caught segfault ***
address 0x18, cause 'memory not mapped'
Traceback:
1: rgl.open(useNULL)
2: open3d()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Warning message:
In rgl.open(useNULL) : RGL: ERROR: can't bind glx context to window
Process R finished at Thu Feb 18 17:57:37 2021
From: Duncan Murdoch
Sent: Thursday, February 18, 2021 3:20 PM
To: Richard M. Heiberger; r-sig-mac@r-project.org
Subject: [External] Re: more rgl problems
I've made some progress on this, but I don't know how to fix it properly.
What's happening is that rgl is trying to open the new window that
open3d() asks for. It gets most of the way through that operation, then
calls glXMakeCurrent, which associates the OpenGL context with that
window. That call fails, but without generating any of the documented
errors: it just fails, triggering an X11 error handler with error code
0 (which typically means no error).
In the released versions of rgl, that failure leads to a segfault,
because I wasn't doing enough error checking. I've fixed the segfault,
but I'm still getting the error (in fact I'm getting it a lot more than
I used to; not sure if it's my debugging code causing that), and after I
get the error reported on screen, the new rgl window opens but doesn't
work to display anything.
I think it's probably something wrong in the rgl initialization code;
running this:
plot(1:10, col=7)
library(rgl)
open3d()
is fine, whereas this:
library(rgl)
plot(1:10, col=7)
open3d()
is always failing for me. Or possibly this is an Xquartz bug, maybe a
leftover from when I installed the beta.
I'd guess what's happening is that calling quartz() invalidates part of
the initialization done by rgl.init(), but I don't know what part yet.
I do want to call rgl.init() when loading rgl, because it might fail,
and then I can drop back to the off-screen drawing. It's too late to do
that later.
A workaround that works for me is for the .onload() function in rgl to
execute
dev.new()
dev.off()
before calling rgl.init(). It is less irritating than you might guess,
because the window doesn't have time to appear before being destroyed,
but I still don't like it. I'll try it out a bit, and then push it to
Github for others to test.
Duncan Murdoch
On 18/02/2021 6:28 a.m., Duncan Murdoch wrote:
I can reproduce this on a Catalina machine, working in R from the terminal.
This definitely looks similar to the problem that
rgl::setGraphicsDelay() wa
Re: [R-SIG-Mac] Please test R 4.0.4 RC
Dear Simon, I just installed R 4.0.4 and the warning has disappeared. I expect that you know that but thought that it might be useful to confirm it just in case. Best, John On 2021-02-12 9:05 p.m., John Fox wrote: Dear Simon, I'm still seeing the warning on a MacBook Pro with a touchbar running Big Sur: --- snip R version 4.0.4 RC (2021-02-12 r79998) -- "Lost Library Book" Copyright (C) 2021 The R Foundation for Statistical Computing Platform: x86_64-apple-darwin17.0 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. [R.app GUI 1.74 (7929) x86_64-apple-darwin17.0] [History restored from /Users/johnfox/.Rapp.history] 2021-02-12 21:00:21.163 R[19677:11057750] Warning: Expected min height of view: () to be less than or equal to 30 but got a height of 32.00. This error will be logged once per view in violation. > sessionInfo() R version 4.0.4 RC (2021-02-12 r79998) Platform: x86_64-apple-darwin17.0 (64-bit) Running under: macOS Big Sur 10.16 Matrix products: default BLAS: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.4 --- snip I hope this helps, John John Fox, Professor Emeritus McMaster University Hamilton, Ontario, Canada web: https://socialsciences.mcmaster.ca/jfox/ On 2021-02-12 6:50 p.m., Simon Urbanek wrote: Dear macOS useRs, please test the latest R 4.0.4 RC builds from https://mac.r-project.org/ especially if you are running macOS Big Sur. The known issues introduced by Big Sur have been fixed, but I cannot replicate nor test the spurious touchbar warning. Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - they are betas for a reason (=unstable) and break things. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Please test R 4.0.4 RC
Dear Simon, I'm still seeing the warning on a MacBook Pro with a touchbar running Big Sur: --- snip R version 4.0.4 RC (2021-02-12 r79998) -- "Lost Library Book" Copyright (C) 2021 The R Foundation for Statistical Computing Platform: x86_64-apple-darwin17.0 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. [R.app GUI 1.74 (7929) x86_64-apple-darwin17.0] [History restored from /Users/johnfox/.Rapp.history] 2021-02-12 21:00:21.163 R[19677:11057750] Warning: Expected min height of view: () to be less than or equal to 30 but got a height of 32.00. This error will be logged once per view in violation. > sessionInfo() R version 4.0.4 RC (2021-02-12 r79998) Platform: x86_64-apple-darwin17.0 (64-bit) Running under: macOS Big Sur 10.16 Matrix products: default BLAS: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.4 --- snip I hope this helps, John John Fox, Professor Emeritus McMaster University Hamilton, Ontario, Canada web: https://socialsciences.mcmaster.ca/jfox/ On 2021-02-12 6:50 p.m., Simon Urbanek wrote: Dear macOS useRs, please test the latest R 4.0.4 RC builds from https://mac.r-project.org/ especially if you are running macOS Big Sur. The known issues introduced by Big Sur have been fixed, but I cannot replicate nor test the spurious touchbar warning. Also a reminder to *not* install XQuartz betas even if XQuartz ask you to - they are betas for a reason (=unstable) and break things. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] checking for pdflatex
Dear JJ,
I apologize for not providing more context: I think that we all understand the
source of the problem, and I've already read the webpage that you reference and
have looked at the RStudio fix.
I've put code in the development version of the Rcmdr that resets the PATH so
that it's the same as for R run from a terminal or RStudio, but that may
violate CRAN policies and would override a PATH that a user deliberately sets.
I thought that there might be a simple way to modify the rmarkdown package so
that it doesn't rely on pdflatex being present on the PATH to produce pdf
output, but that might not prove feasible.
It's not clear to me why Simon hasn't adopted a fix for R.app similar to the
one implemented by RStudio. That would deal with the problem more generally,
but perhaps there's some consideration of which I'm unaware.
Best,
John
On Tue, 17 Mar 2015 06:21:14 -0400
JJ Allaire j...@rstudio.com wrote:
Sounds like this may be targeted at fixing the OS X Yosemite bug
wherein some environment variables for GUI applications are
duplicated:
http://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
Until Apple fixes this issue I think that GUI applications need to
clean the duplicated environment variables received at launch time.
Here's what we do in RStudio:
https://github.com/rstudio/rstudio/commit/09c9be12
On Mon, Mar 16, 2015 at 9:12 PM, John Fox j...@mcmaster.ca wrote:
Dear Simon,
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: March-16-15 3:57 PM
To: j...@mcmaster.ca
Cc: Berend Hasselman; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
On Mar 16, 2015, at 3:43 PM, John Fox j...@mcmaster.ca wrote:
Dear all,
I've now implemented Simon's solution, setting the path in the .onLoad()
function of the Rcmdr package and resetting it to its pre-existing value in
.onUnload(). This seems to work fine for me and, I hope, will be a more
robust solution.
I don't think messing with PATH of the R process is a good idea - as a
user I'd
be somewhat unpleasantly surprised if you changed the PATH of my running
session. I'm not quite sure what's your intention, but I would suggest
using
the setting to locate the binary to run it explicitly - that is what R does
normally. If you rely on some scripts that you don't control, then I would
suggest setting it in the shell that you start the script with, but not in
the R
process itself.
That occurred to me, but the problem arises when a function in the
rmarkdown package calls pandoc and pandoc fails to run pdflatex. I don't
think that I have control over this.
I'm cc'ing J. J. Alaire, the maintainer of the rmarkdown package in case he
sees a solution in that package. The problem doesn't of course occur when
rmarkdown is run from RStudio (or a terminal) but only from R.app, as I
explained initially. (J.J.: Please let me know if this is unclear, and I
can send you the rest of this thread.)
OTOH, I doubt whether Rcmdr users will care that the package alters the
PATH of the R process (though it would be better to avoid that).
Best,
John
Cheers,
Simon
Thanks again to everyone for their help.
John
-Original Message-
From: R-SIG-Mac [mailto:r-sig-mac-boun...@r-project.org] On Behalf Of
John Fox
Sent: March-16-15 2:45 PM
To: 'Berend Hasselman'
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
Dear Berend and Simon,
I've now tried Berend's solution and it appears to work fine: If
necessary, I add /usr/texbin to the path when the Rcmdr GUI starts up
and restore the path to its previous state when it closes.
I agree that Simon's solution will be more flexible since it should
work if pdflatex is located elsewhere (as long as it's on the path
reported by path_helper), and I'll give that a try as well.
Thanks again for all the help,
John
-Original Message-
From: Berend Hasselman [mailto:b...@xs4all.nl]
Sent: March-16-15 2:34 PM
To: j...@mcmaster.ca
Cc: Simon Urbanek; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
John,
On 16-03-2015, at 18:53, John Fox j...@mcmaster.ca wrote:
Dear Berend,
.
For what its worth: I have the following code in the .First
function in
~/.Rprofile:
(R 3.1.3 on OS X Yosemite)
if( .Platform$GUI == AQUA ) {
# this appends /usr/local/bin to what is already in PATH
# by default this is already in PATH (at least in 10.6.8)
# so remove any duplicated items
z - Sys.getenv(PATH)
z - unlist(strsplit(z,.Platform$path.sep,fixed=TRUE))
# add path to MacTeX executables for OS X Yosemite (which
has a
bug)
# in Terminal it is added
Re: [R-SIG-Mac] checking for pdflatex
Dear Rainer, Thanks for this. I already have a more general fix that followed from one of Simon Urbanek's posts yesterday. The sticking point now is having a CRAN package -- the Rcmdr -- mess with the PATH for the R process. Best, John On Tue, 17 Mar 2015 12:02:39 +0100 Rainer M Krug rai...@krugs.de wrote: Gábor Csárdi csardi.ga...@gmail.com writes: John, my guess is that on OSX, 95% of the users have https://tug.org/mactex/, which seems to have pdflatex in /usr/texbin. If it is not there, then most likely the user does not have pdflatex installed, and you can give a note or warning about it. If you want to be sure, you can check other tex distributions for OSX, to be honest I don't know any other. Based on http://mactex-wiki.tug.org/wiki/index.php/Distribution_Matrix pretty much MacTeX is the only player. Maybe people also install TeX with brew, so it might be worth checking that, too. Brew does not support LaTeX, as there is MacTex. But brew-cask does, but it installs the originally binary and also links the binaries to /usr/texbin/. Cheers, Rainer Gabor On Mon, Mar 16, 2015 at 12:25 PM, John Fox j...@mcmaster.ca wrote: Dear Simon, Thanks for this, and to the others who responded to my question. The FAQ and Matt Denwood's response jogged my memory, and reminded me that I encountered this problem before. In this case, I don't see a good solution, but I'll think about the problem some more. Without providing too many tedious details, the development version of the Rcmdr package checks at startup what resources are available to it, including pdflatex, and configures itself accordingly. Having inexperienced users edit, e.g., their .Renviron files is probably a non-starter. The Rcmdr could offer to do this at the user's option (it already provides dialogs that guide the user to locations of missing software like LaTeX and pandoc), but I'd still have to be able to figure out whether pdflatex is available and if so where it's located. Ian Gow suggested using locate, but I apparently can't rely on a locate database having been compiled -- it wasn't on my Mac -- and the overhead of compiling the locate db is excessive for a start-up check. Again, thanks for explaining the problem. John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: March-16-15 10:39 AM To: John Fox Cc: Ian Gow; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex John, see R for Mac FAQ 10.13: I get command not found in the GUI yet it works in the Terminal why? Cheers, Simon On Mar 15, 2015, at 6:21 PM, John Fox j...@mcmaster.ca wrote: Dear Ian, Thanks for this. Please see below: -Original Message- From: Ian Gow [mailto:iand...@gmail.com] Sent: March-15-15 5:07 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex I think it's driven by the PATH variable, which appears to differ for me between RStudio and R from Terminal on the one hand and R.app on the other. Yes, I understand that, though I don't understand why there's a difference in the path. Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Sys.which(pdflatex) pdflatex If I add Sys.setenv(PATH=paste(Sys.getenv(PATH),/opt/local/bin, sep=:)) to ~/.Rprofile then R.app finds pdflatex (from MacPorts in my case). Sys.which(pdflatex) pdflatex /opt/local/bin/pdflatex Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin The problem for me is to determine whether pdflatex is installed *without* knowing in advance where it's installed. I haven't described the purpose of this, and, in the interest of brevity, won't for the time-being, but it may also prove necessary to determine where pdflatex resides. Best, John On 15 Mar 2015, at 16:46, John Fox wrote: Dear list members, I need to determine whether pdflatex is installed and have been doing that via Sys.which(pdflatex). This works when R is run in a terminal window (or in RStudio): Sys.which(pdflatex) pdflatex /usr/texbin/pdflatex but not from R.app: Sys.which(pdflatex) pdflatex The session info is the same in both cases: -- snip sessionInfo() R version 3.1.3 (2015-03-09) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.10.2 (Yosemite) locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF- 8/en_CA.UTF- 8 attached base packages: [1] stats graphics grDevices utils datasets methods base -- snip
Re: [R-SIG-Mac] checking for pdflatex
Dear Simon,
Sorry to prolong this, but I have two additional questions:
(1) Is there a reason that R.app uses a different default PATH than R in a
terminal window does? That is, why not make them the same? I suspect that
there's a consideration that I'm not aware of.
(2) Would it still be objectionable if I reverted to the previous solution of
having the Rcmdr package add /usr/texbin to the current PATH if it's not
already present rather than replacing the PATH? Though that wouldn't be as
bullet-proof, it would cover the large majority of cases, and wouldn't
potentially surprise a user by removing a directory from the PATH.
Thanks,
John
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: March-17-15 10:34 AM
To: JJ Allaire
Cc: j...@mcmaster.ca; Berend Hasselman; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
JJ,
this is unrelated - this is about apps started via LS not using shell
profiles. (The
issue you refer to has been fixed long time ago on our end).
Cheers,
Simon
On Mar 17, 2015, at 6:21 AM, JJ Allaire j...@rstudio.com wrote:
Sounds like this may be targeted at fixing the OS X Yosemite bug
wherein some environment variables for GUI applications are
duplicated:
http://tex.stackexchange.com/questions/208181/why-did-my-tex-related-
g
ui-program-stop-working-in-mac-os-x-yosemite
Until Apple fixes this issue I think that GUI applications need to
clean the duplicated environment variables received at launch time.
Here's what we do in RStudio:
https://github.com/rstudio/rstudio/commit/09c9be12
On Mon, Mar 16, 2015 at 9:12 PM, John Fox j...@mcmaster.ca wrote:
Dear Simon,
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: March-16-15 3:57 PM
To: j...@mcmaster.ca
Cc: Berend Hasselman; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
On Mar 16, 2015, at 3:43 PM, John Fox j...@mcmaster.ca wrote:
Dear all,
I've now implemented Simon's solution, setting the path in the
.onLoad()
function of the Rcmdr package and resetting it to its pre-existing
value in .onUnload(). This seems to work fine for me and, I hope,
will be a more robust solution.
I don't think messing with PATH of the R process is a good idea - as
a user I'd be somewhat unpleasantly surprised if you changed the
PATH of my running session. I'm not quite sure what's your
intention, but I would suggest using the setting to locate the
binary to run it explicitly - that is what R does normally. If you
rely on some scripts that you don't control, then I would suggest
setting it in the shell that you start the script with, but not in the R
process itself.
That occurred to me, but the problem arises when a function in the
rmarkdown package calls pandoc and pandoc fails to run pdflatex. I don't
think that I have control over this.
I'm cc'ing J. J. Alaire, the maintainer of the rmarkdown package in
case he sees a solution in that package. The problem doesn't of
course occur when rmarkdown is run from RStudio (or a terminal) but
only from R.app, as I explained initially. (J.J.: Please let me know
if this is unclear, and I can send you the rest of this thread.)
OTOH, I doubt whether Rcmdr users will care that the package alters the
PATH of the R process (though it would be better to avoid that).
Best,
John
Cheers,
Simon
Thanks again to everyone for their help.
John
-Original Message-
From: R-SIG-Mac [mailto:r-sig-mac-boun...@r-project.org] On Behalf
Of John Fox
Sent: March-16-15 2:45 PM
To: 'Berend Hasselman'
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
Dear Berend and Simon,
I've now tried Berend's solution and it appears to work fine: If
necessary, I add /usr/texbin to the path when the Rcmdr GUI starts
up and restore the path to its previous state when it closes.
I agree that Simon's solution will be more flexible since it
should work if pdflatex is located elsewhere (as long as it's on
the path reported by path_helper), and I'll give that a try as well.
Thanks again for all the help,
John
-Original Message-
From: Berend Hasselman [mailto:b...@xs4all.nl]
Sent: March-16-15 2:34 PM
To: j...@mcmaster.ca
Cc: Simon Urbanek; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
John,
On 16-03-2015, at 18:53, John Fox j...@mcmaster.ca wrote:
Dear Berend,
….
For what it’s worth: I have the following code in the .First
function in
~/.Rprofile:
(R 3.1.3 on OS X Yosemite)
if( .Platform$GUI == AQUA ) {
# this appends /usr/local/bin to what is already in PATH
# by default this is already in PATH (at least in 10.6.8)
# so remove any duplicated items
z - Sys.getenv(PATH)
z - unlist(strsplit(z
Re: [R-SIG-Mac] checking for pdflatex
Dear Brian,
Would it be acceptable to CRAN for the Rcmdr package to add /user/texbin to the
end of the PATH of the R process is it's not already there, restoring the PATH
to its previous state when the Commander() function exits, closing the Rcmdr
GUI?
That seems innocuous to me. I could add a dialog that asks the user's
permission unless an Rcmdr option for this behaviour is set, though for most
users that would mean that the dialog would appear every time the Rcmdr is
started.
Thanks,
John
-Original Message-
From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
Sent: March-16-15 3:56 PM
To: j...@mcmaster.ca; 'Berend Hasselman'
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
Note that it not just MacTex which uses /usr/texbin. /usr/texbin is a link to
/Library/TeX/Distributions/Programs/texbin which is an /etc/alternatives
scheme to manage multiple TeX distributions which used (prior to Yosemite,
at least) to be controlled by a Systems Preferences widget. See
https://tug.org/mactex/multipletexdistributions.html .
That does not apply to e.g. Fink or MacPorts distributions of TeX, but people
using those are not likely to be using R.app.
/usr/libexec/path_helper is not the whole story either: it reads system
versions of PATH which might not apply to a user's shell: it does not get my
settings completely correct (in particular it has /usr/texbin too far down the
PATH and I had moved it because the system path found the wrong
'makeindex').
On 16/03/2015 18:44, John Fox wrote:
Dear Berend and Simon,
I've now tried Berend's solution and it appears to work fine: If necessary,
I
add /usr/texbin to the path when the Rcmdr GUI starts up and restore the
path to its previous state when it closes.
I agree that Simon's solution will be more flexible since it should work if
pdflatex is located elsewhere (as long as it's on the path reported by
path_helper), and I'll give that a try as well.
Thanks again for all the help,
John
-Original Message-
From: Berend Hasselman [mailto:b...@xs4all.nl]
Sent: March-16-15 2:34 PM
To: j...@mcmaster.ca
Cc: Simon Urbanek; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
John,
On 16-03-2015, at 18:53, John Fox j...@mcmaster.ca wrote:
Dear Berend,
….
For what it’s worth: I have the following code in the .First
function in
~/.Rprofile:
(R 3.1.3 on OS X Yosemite)
if( .Platform$GUI == AQUA ) {
# this appends /usr/local/bin to what is already in PATH
# by default this is already in PATH (at least in 10.6.8)
# so remove any duplicated items
z - Sys.getenv(PATH)
z - unlist(strsplit(z,.Platform$path.sep,fixed=TRUE))
# add path to MacTeX executables for OS X Yosemite (which
has a
bug)
# in Terminal it is added automatically
z[length(z)+1] - /usr/texbin
Sys.setenv(PATH=paste(z[!duplicated(z)],collapse=.Platform$path.sep))
}
This should work fine if pdflatex is in /usr/texbin, which I now
understand is
by far the most common case (and is the case on my Mac).
Do you mind if I adapt your code for the Rcmdr? I can fix the path
in this
manner at startup of the Rcmdr GUI and restore it to its initial
value on exit from the GUI.
Go right ahead. Don’t forget it assumes MacTeX.
But do also have a look Simon’s suggestion of using path_helper,
which seems more flexible than my solution:
I tried this in R-GUI
system2(/usr/libexec/path_helper,-s, stdout=TRUE)
and got this answer
[1]
PATH=\/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/us
r/texbi
n\; export PATH;”
which will have to be fiddled with to get something that is usable.
Berend
Thanks for this,
John
Berend
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
---
This email has been checked for viruses by Avast antivirus software.
___
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
1 South Parks Road, Oxford OX1 3TG, UK
---
This email has been checked for viruses by Avast antivirus software.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] checking for pdflatex
Dear Simon, -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: March-17-15 10:48 AM To: j...@mcmaster.ca Cc: JJ Allaire; Berend Hasselman; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex On Mar 17, 2015, at 10:41 AM, John Fox j...@mcmaster.ca wrote: Dear Simon, Sorry to prolong this, but I have two additional questions: (1) Is there a reason that R.app uses a different default PATH than R in a terminal window does? That is, why not make them the same? I suspect that there's a consideration that I'm not aware of. See the FAQ I was pointing to. Yes, I did read that, but it's really more an explanation of *what* happens rather than *why* R.app doesn't circumvent this behaviour, and the Apple technical QA linked to is labelled Retired Document. (2) Would it still be objectionable if I reverted to the previous solution of having the Rcmdr package add /usr/texbin to the current PATH if it's not already present rather than replacing the PATH? Though that wouldn't be as bullet-proof, it would cover the large majority of cases, and wouldn't potentially surprise a user by removing a directory from the PATH. I guess that would be less disruptive. If the user has picked a custom order at least it would be preserved. But as noted earlier I also think that this should be better fixed in rmarkdown - preferably by using the full path so it doesn't depend on PATH. I'm told RStudio is providing pandoc binaries so I would guess it's easy for them to guarantee the functionality but JJ is included so he can weigh in. Yes, and RStudio also uses a PATH that includes pdflatex. But rmarkdown is intended to work outside of RStudio too and won't under R.app if pdflatex isn't on the PATH. No need to respond further. Thanks again for your time. John Cheers, Simon Thanks, John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: March-17-15 10:34 AM To: JJ Allaire Cc: j...@mcmaster.ca; Berend Hasselman; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex JJ, this is unrelated - this is about apps started via LS not using shell profiles. (The issue you refer to has been fixed long time ago on our end). Cheers, Simon On Mar 17, 2015, at 6:21 AM, JJ Allaire j...@rstudio.com wrote: Sounds like this may be targeted at fixing the OS X Yosemite bug wherein some environment variables for GUI applications are duplicated: http://tex.stackexchange.com/questions/208181/why-did-my-tex- related - g ui-program-stop-working-in-mac-os-x-yosemite Until Apple fixes this issue I think that GUI applications need to clean the duplicated environment variables received at launch time. Here's what we do in RStudio: https://github.com/rstudio/rstudio/commit/09c9be12 On Mon, Mar 16, 2015 at 9:12 PM, John Fox j...@mcmaster.ca wrote: Dear Simon, -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: March-16-15 3:57 PM To: j...@mcmaster.ca Cc: Berend Hasselman; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex On Mar 16, 2015, at 3:43 PM, John Fox j...@mcmaster.ca wrote: Dear all, I've now implemented Simon's solution, setting the path in the .onLoad() function of the Rcmdr package and resetting it to its pre-existing value in .onUnload(). This seems to work fine for me and, I hope, will be a more robust solution. I don't think messing with PATH of the R process is a good idea - as a user I'd be somewhat unpleasantly surprised if you changed the PATH of my running session. I'm not quite sure what's your intention, but I would suggest using the setting to locate the binary to run it explicitly - that is what R does normally. If you rely on some scripts that you don't control, then I would suggest setting it in the shell that you start the script with, but not in the R process itself. That occurred to me, but the problem arises when a function in the rmarkdown package calls pandoc and pandoc fails to run pdflatex. I don't think that I have control over this. I'm cc'ing J. J. Alaire, the maintainer of the rmarkdown package in case he sees a solution in that package. The problem doesn't of course occur when rmarkdown is run from RStudio (or a terminal) but only from R.app, as I explained initially. (J.J.: Please let me know if this is unclear, and I can send you the rest of this thread.) OTOH, I doubt whether Rcmdr users will care that the package alters the PATH of the R process (though it would be better to avoid that). Best, John Cheers, Simon Thanks again to everyone for their help. John -Original Message- From: R-SIG-Mac [mailto:r-sig-mac-boun...@r-project.org] On Behalf Of John Fox Sent: March
Re: [R-SIG-Mac] checking for pdflatex
Dear Simon,
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: March-16-15 3:57 PM
To: j...@mcmaster.ca
Cc: Berend Hasselman; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
On Mar 16, 2015, at 3:43 PM, John Fox j...@mcmaster.ca wrote:
Dear all,
I've now implemented Simon's solution, setting the path in the .onLoad()
function of the Rcmdr package and resetting it to its pre-existing value in
.onUnload(). This seems to work fine for me and, I hope, will be a more
robust solution.
I don't think messing with PATH of the R process is a good idea - as a user
I'd
be somewhat unpleasantly surprised if you changed the PATH of my running
session. I'm not quite sure what's your intention, but I would suggest using
the setting to locate the binary to run it explicitly - that is what R does
normally. If you rely on some scripts that you don't control, then I would
suggest setting it in the shell that you start the script with, but not in
the R
process itself.
That occurred to me, but the problem arises when a function in the rmarkdown
package calls pandoc and pandoc fails to run pdflatex. I don't think that I
have control over this.
I'm cc'ing J. J. Alaire, the maintainer of the rmarkdown package in case he
sees a solution in that package. The problem doesn't of course occur when
rmarkdown is run from RStudio (or a terminal) but only from R.app, as I
explained initially. (J.J.: Please let me know if this is unclear, and I can
send you the rest of this thread.)
OTOH, I doubt whether Rcmdr users will care that the package alters the PATH of
the R process (though it would be better to avoid that).
Best,
John
Cheers,
Simon
Thanks again to everyone for their help.
John
-Original Message-
From: R-SIG-Mac [mailto:r-sig-mac-boun...@r-project.org] On Behalf Of
John Fox
Sent: March-16-15 2:45 PM
To: 'Berend Hasselman'
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
Dear Berend and Simon,
I've now tried Berend's solution and it appears to work fine: If
necessary, I add /usr/texbin to the path when the Rcmdr GUI starts up
and restore the path to its previous state when it closes.
I agree that Simon's solution will be more flexible since it should
work if pdflatex is located elsewhere (as long as it's on the path
reported by path_helper), and I'll give that a try as well.
Thanks again for all the help,
John
-Original Message-
From: Berend Hasselman [mailto:b...@xs4all.nl]
Sent: March-16-15 2:34 PM
To: j...@mcmaster.ca
Cc: Simon Urbanek; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
John,
On 16-03-2015, at 18:53, John Fox j...@mcmaster.ca wrote:
Dear Berend,
….
For what it’s worth: I have the following code in the .First
function in
~/.Rprofile:
(R 3.1.3 on OS X Yosemite)
if( .Platform$GUI == AQUA ) {
# this appends /usr/local/bin to what is already in PATH
# by default this is already in PATH (at least in 10.6.8)
# so remove any duplicated items
z - Sys.getenv(PATH)
z - unlist(strsplit(z,.Platform$path.sep,fixed=TRUE))
# add path to MacTeX executables for OS X Yosemite (which
has a
bug)
# in Terminal it is added automatically
z[length(z)+1] - /usr/texbin
Sys.setenv(PATH=paste(z[!duplicated(z)],collapse=.Platform$path.sep)
)
}
This should work fine if pdflatex is in /usr/texbin, which I now
understand is
by far the most common case (and is the case on my Mac).
Do you mind if I adapt your code for the Rcmdr? I can fix the path
in this
manner at startup of the Rcmdr GUI and restore it to its initial
value on exit from the GUI.
Go right ahead. Don’t forget it assumes MacTeX.
But do also have a look Simon’s suggestion of using path_helper,
which seems more flexible than my solution:
I tried this in R-GUI
system2(/usr/libexec/path_helper,-s, stdout=TRUE)
and got this answer
[1]
PATH=\/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/u
sr
/texbi
n\; export PATH;”
which will have to be fiddled with to get something that is usable.
Berend
Thanks for this,
John
Berend
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
---
This email has been checked for viruses by Avast antivirus software.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
---
This email has been checked for viruses by Avast antivirus software.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch
Re: [R-SIG-Mac] checking for pdflatex
Dear Simon, Thanks for this, and to the others who responded to my question. The FAQ and Matt Denwood's response jogged my memory, and reminded me that I encountered this problem before. In this case, I don't see a good solution, but I'll think about the problem some more. Without providing too many tedious details, the development version of the Rcmdr package checks at startup what resources are available to it, including pdflatex, and configures itself accordingly. Having inexperienced users edit, e.g., their .Renviron files is probably a non-starter. The Rcmdr could offer to do this at the user's option (it already provides dialogs that guide the user to locations of missing software like LaTeX and pandoc), but I'd still have to be able to figure out whether pdflatex is available and if so where it's located. Ian Gow suggested using locate, but I apparently can't rely on a locate database having been compiled -- it wasn't on my Mac -- and the overhead of compiling the locate db is excessive for a start-up check. Again, thanks for explaining the problem. John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: March-16-15 10:39 AM To: John Fox Cc: Ian Gow; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex John, see R for Mac FAQ 10.13: I get “command not found” in the GUI yet it works in the Terminal – why? Cheers, Simon On Mar 15, 2015, at 6:21 PM, John Fox j...@mcmaster.ca wrote: Dear Ian, Thanks for this. Please see below: -Original Message- From: Ian Gow [mailto:iand...@gmail.com] Sent: March-15-15 5:07 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex I think it's driven by the PATH variable, which appears to differ for me between RStudio and R from Terminal on the one hand and R.app on the other. Yes, I understand that, though I don't understand why there's a difference in the path. Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Sys.which(pdflatex) pdflatex If I add Sys.setenv(PATH=paste(Sys.getenv(PATH),/opt/local/bin, sep=:)) to ~/.Rprofile then R.app finds pdflatex (from MacPorts in my case). Sys.which(pdflatex) pdflatex /opt/local/bin/pdflatex Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin The problem for me is to determine whether pdflatex is installed *without* knowing in advance where it's installed. I haven't described the purpose of this, and, in the interest of brevity, won't for the time-being, but it may also prove necessary to determine where pdflatex resides. Best, John On 15 Mar 2015, at 16:46, John Fox wrote: Dear list members, I need to determine whether pdflatex is installed and have been doing that via Sys.which(pdflatex). This works when R is run in a terminal window (or in RStudio): Sys.which(pdflatex) pdflatex /usr/texbin/pdflatex but not from R.app: Sys.which(pdflatex) pdflatex The session info is the same in both cases: -- snip sessionInfo() R version 3.1.3 (2015-03-09) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.10.2 (Yosemite) locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF- 8/en_CA.UTF- 8 attached base packages: [1] stats graphics grDevices utils datasets methods base -- snip Why is the result different? Is there a better way to check for the presence of pdflatex? Any help would be appreciated. Thanks, John John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac --- This email has been checked for viruses by Avast antivirus software. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac --- This email has been checked for viruses by Avast antivirus software. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] checking for pdflatex
Dear Gabor, -Original Message- From: Gábor Csárdi [mailto:csardi.ga...@gmail.com] Sent: March-16-15 12:39 PM To: John Fox Cc: Simon Urbanek; R-SIG-Mac Subject: Re: [R-SIG-Mac] checking for pdflatex John, my guess is that on OSX, 95% of the users have https://tug.org/mactex/, which seems to have pdflatex in /usr/texbin. If it is not there, then most likely the user does not have pdflatex installed, and you can give a note or warning about it. If that's the case, then this certainly makes sense as a solution. In fact, if the Rcmdr (development version) doesn't detect pdflatex it provides a menu item and dialog under its Tools menu that will take the user to http://www.tug.org/mactex/. If you want to be sure, you can check other tex distributions for OSX, to be honest I don't know any other. Based on http://mactex- wiki.tug.org/wiki/index.php/Distribution_Matrix pretty much MacTeX is the only player. Maybe people also install TeX with brew, so it might be worth checking that, too. I think that I'll initially go for the simpler solution. I suspect that most Rcmdr Mac OS X users won't have LaTeX installed prior to installing the Rcmdr package. I can put an explanation in the help page for the dialog. Thanks for the suggestion, John Gabor On Mon, Mar 16, 2015 at 12:25 PM, John Fox j...@mcmaster.ca wrote: Dear Simon, Thanks for this, and to the others who responded to my question. The FAQ and Matt Denwood's response jogged my memory, and reminded me that I encountered this problem before. In this case, I don't see a good solution, but I'll think about the problem some more. Without providing too many tedious details, the development version of the Rcmdr package checks at startup what resources are available to it, including pdflatex, and configures itself accordingly. Having inexperienced users edit, e.g., their .Renviron files is probably a non-starter. The Rcmdr could offer to do this at the user's option (it already provides dialogs that guide the user to locations of missing software like LaTeX and pandoc), but I'd still have to be able to figure out whether pdflatex is available and if so where it's located. Ian Gow suggested using locate, but I apparently can't rely on a locate database having been compiled -- it wasn't on my Mac -- and the overhead of compiling the locate db is excessive for a start-up check. Again, thanks for explaining the problem. John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: March-16-15 10:39 AM To: John Fox Cc: Ian Gow; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex John, see R for Mac FAQ 10.13: I get “command not found” in the GUI yet it works in the Terminal – why? Cheers, Simon On Mar 15, 2015, at 6:21 PM, John Fox j...@mcmaster.ca wrote: Dear Ian, Thanks for this. Please see below: -Original Message- From: Ian Gow [mailto:iand...@gmail.com] Sent: March-15-15 5:07 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex I think it's driven by the PATH variable, which appears to differ for me between RStudio and R from Terminal on the one hand and R.app on the other. Yes, I understand that, though I don't understand why there's a difference in the path. Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Sys.which(pdflatex) pdflatex If I add Sys.setenv(PATH=paste(Sys.getenv(PATH),/opt/local/bin, sep=:)) to ~/.Rprofile then R.app finds pdflatex (from MacPorts in my case). Sys.which(pdflatex) pdflatex /opt/local/bin/pdflatex Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin The problem for me is to determine whether pdflatex is installed *without* knowing in advance where it's installed. I haven't described the purpose of this, and, in the interest of brevity, won't for the time-being, but it may also prove necessary to determine where pdflatex resides. Best, John On 15 Mar 2015, at 16:46, John Fox wrote: Dear list members, I need to determine whether pdflatex is installed and have been doing that via Sys.which(pdflatex). This works when R is run in a terminal window (or in RStudio): Sys.which(pdflatex
Re: [R-SIG-Mac] checking for pdflatex
Dear Berend,
-Original Message-
From: Berend Hasselman [mailto:b...@xs4all.nl]
Sent: March-16-15 1:27 PM
To: j...@mcmaster.ca
Cc: Simon Urbanek; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
On 16-03-2015, at 17:25, John Fox j...@mcmaster.ca wrote:
Dear Simon,
Thanks for this, and to the others who responded to my question. The FAQ
and Matt Denwood's response jogged my memory, and reminded me that I
encountered this problem before.
In this case, I don't see a good solution, but I'll think about the problem
some more.
Without providing too many tedious details, the development version of
the Rcmdr package checks at startup what resources are available to it,
including pdflatex, and configures itself accordingly. Having inexperienced
users edit, e.g., their .Renviron files is probably a non-starter. The Rcmdr
could offer to do this at the user's option (it already provides dialogs that
guide the user to locations of missing software like LaTeX and pandoc), but
I'd still have to be able to figure out whether pdflatex is available and if
so
where it's located.
Ian Gow suggested using locate, but I apparently can't rely on a locate
database having been compiled -- it wasn't on my Mac -- and the overhead
of compiling the locate db is excessive for a start-up check.
Again, thanks for explaining the problem.
For what it’s worth: I have the following code in the .First function in
~/.Rprofile:
(R 3.1.3 on OS X Yosemite)
if( .Platform$GUI == AQUA ) {
# this appends /usr/local/bin to what is already in PATH
# by default this is already in PATH (at least in 10.6.8)
# so remove any duplicated items
z - Sys.getenv(PATH)
z - unlist(strsplit(z,.Platform$path.sep,fixed=TRUE))
# add path to MacTeX executables for OS X Yosemite (which has a bug)
# in Terminal it is added automatically
z[length(z)+1] - /usr/texbin
Sys.setenv(PATH=paste(z[!duplicated(z)],collapse=.Platform$path.sep))
}
This should work fine if pdflatex is in /usr/texbin, which I now understand is
by far the most common case (and is the case on my Mac).
Do you mind if I adapt your code for the Rcmdr? I can fix the path in this
manner at startup of the Rcmdr GUI and restore it to its initial value on exit
from the GUI.
Thanks for this,
John
Berend
---
This email has been checked for viruses by Avast antivirus software.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] checking for pdflatex
Dear Berend and Simon,
I've now tried Berend's solution and it appears to work fine: If necessary, I
add /usr/texbin to the path when the Rcmdr GUI starts up and restore the path
to its previous state when it closes.
I agree that Simon's solution will be more flexible since it should work if
pdflatex is located elsewhere (as long as it's on the path reported by
path_helper), and I'll give that a try as well.
Thanks again for all the help,
John
-Original Message-
From: Berend Hasselman [mailto:b...@xs4all.nl]
Sent: March-16-15 2:34 PM
To: j...@mcmaster.ca
Cc: Simon Urbanek; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
John,
On 16-03-2015, at 18:53, John Fox j...@mcmaster.ca wrote:
Dear Berend,
….
For what it’s worth: I have the following code in the .First function in
~/.Rprofile:
(R 3.1.3 on OS X Yosemite)
if( .Platform$GUI == AQUA ) {
# this appends /usr/local/bin to what is already in PATH
# by default this is already in PATH (at least in 10.6.8)
# so remove any duplicated items
z - Sys.getenv(PATH)
z - unlist(strsplit(z,.Platform$path.sep,fixed=TRUE))
# add path to MacTeX executables for OS X Yosemite (which has a
bug)
# in Terminal it is added automatically
z[length(z)+1] - /usr/texbin
Sys.setenv(PATH=paste(z[!duplicated(z)],collapse=.Platform$path.sep))
}
This should work fine if pdflatex is in /usr/texbin, which I now understand
is
by far the most common case (and is the case on my Mac).
Do you mind if I adapt your code for the Rcmdr? I can fix the path in this
manner at startup of the Rcmdr GUI and restore it to its initial value on exit
from the GUI.
Go right ahead. Don’t forget it assumes MacTeX.
But do also have a look Simon’s suggestion of using path_helper, which
seems more flexible than my solution:
I tried this in R-GUI
system2(/usr/libexec/path_helper,-s, stdout=TRUE)
and got this answer
[1]
PATH=\/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/texbi
n\; export PATH;”
which will have to be fiddled with to get something that is usable.
Berend
Thanks for this,
John
Berend
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
---
This email has been checked for viruses by Avast antivirus software.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] checking for pdflatex
Dear all,
I've now implemented Simon's solution, setting the path in the .onLoad()
function of the Rcmdr package and resetting it to its pre-existing value in
.onUnload(). This seems to work fine for me and, I hope, will be a more robust
solution.
Thanks again to everyone for their help.
John
-Original Message-
From: R-SIG-Mac [mailto:r-sig-mac-boun...@r-project.org] On Behalf Of
John Fox
Sent: March-16-15 2:45 PM
To: 'Berend Hasselman'
Cc: r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
Dear Berend and Simon,
I've now tried Berend's solution and it appears to work fine: If necessary, I
add /usr/texbin to the path when the Rcmdr GUI starts up and restore the
path to its previous state when it closes.
I agree that Simon's solution will be more flexible since it should work if
pdflatex is located elsewhere (as long as it's on the path reported by
path_helper), and I'll give that a try as well.
Thanks again for all the help,
John
-Original Message-
From: Berend Hasselman [mailto:b...@xs4all.nl]
Sent: March-16-15 2:34 PM
To: j...@mcmaster.ca
Cc: Simon Urbanek; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] checking for pdflatex
John,
On 16-03-2015, at 18:53, John Fox j...@mcmaster.ca wrote:
Dear Berend,
….
For what it’s worth: I have the following code in the .First
function in
~/.Rprofile:
(R 3.1.3 on OS X Yosemite)
if( .Platform$GUI == AQUA ) {
# this appends /usr/local/bin to what is already in PATH
# by default this is already in PATH (at least in 10.6.8)
# so remove any duplicated items
z - Sys.getenv(PATH)
z - unlist(strsplit(z,.Platform$path.sep,fixed=TRUE))
# add path to MacTeX executables for OS X Yosemite (which
has a
bug)
# in Terminal it is added automatically
z[length(z)+1] - /usr/texbin
Sys.setenv(PATH=paste(z[!duplicated(z)],collapse=.Platform$path.sep))
}
This should work fine if pdflatex is in /usr/texbin, which I now
understand is
by far the most common case (and is the case on my Mac).
Do you mind if I adapt your code for the Rcmdr? I can fix the path
in this
manner at startup of the Rcmdr GUI and restore it to its initial value
on exit from the GUI.
Go right ahead. Don’t forget it assumes MacTeX.
But do also have a look Simon’s suggestion of using path_helper, which
seems more flexible than my solution:
I tried this in R-GUI
system2(/usr/libexec/path_helper,-s, stdout=TRUE)
and got this answer
[1]
PATH=\/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr
/texbi
n\; export PATH;”
which will have to be fiddled with to get something that is usable.
Berend
Thanks for this,
John
Berend
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
---
This email has been checked for viruses by Avast antivirus software.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
---
This email has been checked for viruses by Avast antivirus software.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] checking for pdflatex
Dear list members, I need to determine whether pdflatex is installed and have been doing that via Sys.which(pdflatex). This works when R is run in a terminal window (or in RStudio): Sys.which(pdflatex) pdflatex /usr/texbin/pdflatex but not from R.app: Sys.which(pdflatex) pdflatex The session info is the same in both cases: -- snip sessionInfo() R version 3.1.3 (2015-03-09) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.10.2 (Yosemite) locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base -- snip Why is the result different? Is there a better way to check for the presence of pdflatex? Any help would be appreciated. Thanks, John John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] checking for pdflatex
Dear Ian, Thanks for this. Please see below: -Original Message- From: Ian Gow [mailto:iand...@gmail.com] Sent: March-15-15 5:07 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex I think it's driven by the PATH variable, which appears to differ for me between RStudio and R from Terminal on the one hand and R.app on the other. Yes, I understand that, though I don't understand why there's a difference in the path. Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Sys.which(pdflatex) pdflatex If I add Sys.setenv(PATH=paste(Sys.getenv(PATH),/opt/local/bin, sep=:)) to ~/.Rprofile then R.app finds pdflatex (from MacPorts in my case). Sys.which(pdflatex) pdflatex /opt/local/bin/pdflatex Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin The problem for me is to determine whether pdflatex is installed *without* knowing in advance where it's installed. I haven't described the purpose of this, and, in the interest of brevity, won't for the time-being, but it may also prove necessary to determine where pdflatex resides. Best, John On 15 Mar 2015, at 16:46, John Fox wrote: Dear list members, I need to determine whether pdflatex is installed and have been doing that via Sys.which(pdflatex). This works when R is run in a terminal window (or in RStudio): Sys.which(pdflatex) pdflatex /usr/texbin/pdflatex but not from R.app: Sys.which(pdflatex) pdflatex The session info is the same in both cases: -- snip sessionInfo() R version 3.1.3 (2015-03-09) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.10.2 (Yosemite) locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF- 8 attached base packages: [1] stats graphics grDevices utils datasets methods base -- snip Why is the result different? Is there a better way to check for the presence of pdflatex? Any help would be appreciated. Thanks, John John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac --- This email has been checked for viruses by Avast antivirus software. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] checking for pdflatex
Dear Jordan, I'm not looking for an R package, I'm looking for the pdflatex program. Best, John On Sun, 15 Mar 2015 21:17:53 -0400 Jordan Meyer jordanmeyer1...@gmail.com wrote: You may wish to try using the logical.return argument of library(). If it returns TRUE, you could use find.package() to locate the package you are looking for. For example: library(package = BEST, logical.return = TRUE) Loading required package: rjags Loading required package: coda Linked to JAGS 3.4.0 Loaded modules: basemod,bugs [1] TRUE find.package(package = BEST) [1] /Library/Frameworks/R.framework/Versions/3.1/Resources/library/BEST On Sun, Mar 15, 2015 at 6:21 PM, John Fox j...@mcmaster.ca wrote: Dear Ian, Thanks for this. Please see below: -Original Message- From: Ian Gow [mailto:iand...@gmail.com] Sent: March-15-15 5:07 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] checking for pdflatex I think it's driven by the PATH variable, which appears to differ for me between RStudio and R from Terminal on the one hand and R.app on the other. Yes, I understand that, though I don't understand why there's a difference in the path. Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Sys.which(pdflatex) pdflatex If I add Sys.setenv(PATH=paste(Sys.getenv(PATH),/opt/local/bin, sep=:)) to ~/.Rprofile then R.app finds pdflatex (from MacPorts in my case). Sys.which(pdflatex) pdflatex /opt/local/bin/pdflatex Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin The problem for me is to determine whether pdflatex is installed *without* knowing in advance where it's installed. I haven't described the purpose of this, and, in the interest of brevity, won't for the time-being, but it may also prove necessary to determine where pdflatex resides. Best, John On 15 Mar 2015, at 16:46, John Fox wrote: Dear list members, I need to determine whether pdflatex is installed and have been doing that via Sys.which(pdflatex). This works when R is run in a terminal window (or in RStudio): Sys.which(pdflatex) pdflatex /usr/texbin/pdflatex but not from R.app: Sys.which(pdflatex) pdflatex The session info is the same in both cases: -- snip sessionInfo() R version 3.1.3 (2015-03-09) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.10.2 (Yosemite) locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF- 8 attached base packages: [1] stats graphics grDevices utils datasets methods base -- snip Why is the result different? Is there a better way to check for the presence of pdflatex? Any help would be appreciated. Thanks, John John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac --- This email has been checked for viruses by Avast antivirus software. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] tcltk problem with R 3.1.2
Dear Paul, -Original Message- From: Paul J. Campbell [mailto:campb...@beloit.edu] Sent: January-26-15 3:31 PM To: j...@mcmaster.ca Subject: tcltk problem with R 3.1.2 John, I am comparing GUIs for R (Rcmdr, RStudio, JGR) to recommend one to my stats class. I have followed your instructions re installation of Rcmdr on my home Mac OS 10.6.8 with R 3.1.2, which has XTools and XQuartz, and I have installed the Tc/Tlk 8.6 that came with R 3.1.2. Tcl/Tk is part of the standard R 3.1.2 installation. You should not have had to do a separate install (though perhaps you didn't). You shouldn't need XTools (though if it's installed, I suppose that it should provide otool). I get a different error msg, re otools: Error: package or namespace load failed for 'Rcmdr' sh: otool: command not found library(tcltk) Error : .onLoad failed in loadNamespace() for 'tcltk', details: call: system2(otool, c(-L, shQuote(DLL)), stdout = TRUE) error: error in running command Error: package or namespace load failed for 'tcltk' sh: otool: command not found When the tcltk package loads it checks for the presence of otool, which I believe is intended to determine whether there's a functioning X Windows (though why this check is used is unclear to me). This is a relatively new check and may be source of the problem, or something may be broken in your system. You might try reinstalling XQuartz and perhaps uninstalling the Tcl/Tk that you installed separately from R (if you did so). install.packages(tcltk) This isn't necessary: the tcltk package is part of the standard R installation. Warning: unable to access index for repository http://www.ibiblio.org/pub/languages/R/CRAN/bin/macosx/contrib/3.1 Warning message: package 'tcltk' is not available (for R version 3.1.2) install.packages(tcltk2) Warning: unable to access index for repository http://www.ibiblio.org/pub/languages/R/CRAN/bin/macosx/contrib/3.1 Warning message: package 'tcltk2' is not available (for R version 3.1.2) There's some problem with the CRAN mirror that you're accessing, but tcltk2 should have been installed along with the Rcmdr package and needn't be installed in a separate step. I'm copying this response to the R-SIG-MAC email list and to Simon Urbanek and Brian Ripley, who are likely to have more insight into your problem that I do. Best, John --- John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ The suggestions at your Web page do not cover this case; there are no permissions denials: system(ls -ld /usr/local /usr/local/lib /usr/local/lib/libtcl*) drwxr-xr-x 14 root wheel 476 Dec 26 21:57 /usr/local drwxrwxrwx 124 root wheel 4216 Jan 26 13:19 /usr/local/lib -rwxr-xr-x1 root wheel 4820229 Oct 21 2008 /usr/local/lib/libtcl8.5.dylib -r-xr-xr-x1 root wheel 1419604 Mar 29 2013 /usr/local/lib/libtcl8.6.dylib -rw-r--r--1 root wheel11072 Oct 21 2008 /usr/local/lib/libtclstub8.5.a -rwxr-xr-x1 root wheel 4824 Mar 29 2013 /usr/local/lib/libtclstub8.6.a Searching the Internet does not produce any usable solutions. Do you have any suggestions? Most of my students have Macs with OS 10.9 (a minority have Windows PCs), and I run OS 10.10 on the ofc machine. I will give Rcmdr a try there later today but could use a work-around for at home, where I do all my class prep. (I am too much a fan of Eudora to give up yet on 10.6.8; I find Apple Mail and other mail clients lacking.) Thanks, Paul C -- Paul J. Campbell Mathematics and Computer Science Beloit College 700 College St. Beloit, WI 53511-5595 USA ofc:please send email instead fax: (608) 363-2052 res: (608) 362-2805 really old archived Web page at https://web.archive.org/web/20090221120714/http://cs.beloit.edu/campbel l/ --- This email has been checked for viruses by Avast antivirus software. http://www.avast.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] Yosemite and R
Dear all, Brian Ripley has brought it my attention that R 3.1.2, due to be released soon, *does* check that X11 is present and prints an informative error message if it isn't. That's a substantial improvement. Thanks, John On Tue, 28 Oct 2014 09:43:53 -0400 John Fox j...@mcmaster.ca wrote: Dear Rich, I've made a similar suggestions before, I believe. It would even help to have tcltk fail less cryptically if X-Windows is unavailable under Mac OS X, suggesting that XQuartz be installed and pointing to the XQuartz website. And it shouldn't be hard to check capabilities()[X11] when tcltk loads. The large majority of Rcmdr problems about which people write me concern this one issue. There are clear, detailed installation instructions on the Rcmdr website but no way for me to insure that people are aware of them. I spent some time trying to find a way to report the absence of X-Windows at Rcmdr start-up, but the dependency on tcltk causes the Rcmdr to fail to load before an informative message can be printed -- a chicken-and-egg problem. Maybe there's a way to do this that I didn't discover. The essential problem here is that naive users don't have an obvious way of avoiding the problem. They install the software and expect it to work. There are similar issues with the system path under Yosemite and with app nap. This leads to repetitious emails to package maintainers and to repetitive questions on the various help lists, etc. That said, I think that there is a good solution for teachers of courses, workshops, etc.: Create -- or point to existing -- clear installation instructions that include installing XQuartz under OS X. The less tractable problem is individual users downloading and installing R from CRAN. Best, John On Tue, 28 Oct 2014 00:03:52 -0400 Richard M. Heiberger r...@temple.edu wrote: I just did a workshop for new R users. the only serious installation problem I saw was Macintosh users and tctlk. From this discussion, I knew to tell both people they needed to download quartz.macosforge.org and indeed that solved it. Is there a place on the package DESCRIPTION file to state that dependency, thus triggering the download and installation of quartz? That would take the responsibility for discovering this need away from the end user? Rich On Thu, Oct 23, 2014 at 2:15 PM, John Fox j...@mcmaster.ca wrote: Dear Simon, I installed Yosemite a couple of days ago and everything seems to work fine so far, including the tcltk demo that caused problems for Peter, and the Rcmdr package, which gives Tcl/Tk a pretty good workout. I first reinstalled XQuartz, as suggested, and I also reinstalled R and updated all packages, though the latter two steps probably weren't necessary. I figured that it would help to hear positive experiences as well as problems. The only issue that I've encountered so far is specific to checking packages under RStudio, which doesn't appear to find pdflatex; OTOH, R CMD check runs fine in a terminal window. I haven't yet tried to resolve this problem. Best, John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Tuesday, October 21, 2014 4:38 PM To: John Fox Cc: Amos B. Elberg; r-sig-mac; Spencer Mass; Ben Clark; peter dalgaard; Marc Schwartz; David Winsemius; Hadley Wickham Subject: Re: [R-SIG-Mac] Yosemite and R I wasn't able to reproduce but I suspect those are all red herrings - there are really no subprocesses involved at all in either case. On Oct 21, 2014, at 4:19 PM, John Fox j...@mcmaster.ca wrote: Dear all, I wonder whether this issue also accounts for the tcltk problems that have been reported. (I haven't yet upgraded to Yosemite myself, hoping to wait for the wrinkles to be ironed out, though I'll likely do so shortly if only to see what happens.) Best, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Amos B. Elberg Sent: Tuesday, October 21, 2014 12:40 PM To: David Winsemius; Hadley Wickham Cc: r-sig-mac; Spencer Mass Subject: Re: [R-SIG-Mac] Yosemite and R If the full environment isnt getting passed to R-spawned sub- processes, that might explain an error Ive been having since the update: when R is launched from the command line, calls that should create an X11 window in the background fail unless an X11 window has already been created with the width and height specified: plot(rnorm(100)) Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, : invalid 'width' or 'height' X11() Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, : invalid 'width' or 'height' X11(width = 5, height = 5) plot
Re: [R-SIG-Mac] Yosemite and R
Dear all, I wonder whether this issue also accounts for the tcltk problems that have been reported. (I haven't yet upgraded to Yosemite myself, hoping to wait for the wrinkles to be ironed out, though I'll likely do so shortly if only to see what happens.) Best, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Amos B. Elberg Sent: Tuesday, October 21, 2014 12:40 PM To: David Winsemius; Hadley Wickham Cc: r-sig-mac; Spencer Mass Subject: Re: [R-SIG-Mac] Yosemite and R If the full environment isn’t getting passed to R-spawned sub- processes, that might explain an error I’ve been having since the update: when R is launched from the command line, calls that should create an X11 window in the background fail unless an X11 window has already been created with the width and height specified: plot(rnorm(100)) Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, : invalid 'width' or 'height' X11() Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, : invalid 'width' or 'height' X11(width = 5, height = 5) plot(rnorm(100)) [now it works - and any number of additional windows can be spawned without repeating the error] [quitting R and reopening, without quitting XQuartz, and I get the same error calling plot() before X11(width = , height = ) This does not happen in RStudio. I don’t use the R.app gui; I opened it just now to test and I got a slew of path-related errors, but they’re as likely to have to do with my not-maintained R.app as with anything else. I had not reported this already because I wasn’t confident whether its a yosemite issue, an R-patched issue, or just something odd in the way I built R. If incomplete-environment-passing is the new normal, is this not going to be a common issue for packages that spawn sub-processes? From: Hadley Wickham h.wick...@gmail.com Reply: Hadley Wickham h.wick...@gmail.com Date: October 21, 2014 at 10:12:13 AM To: David Winsemius dwinsem...@comcast.net Cc: r-sig-mac r-sig-mac@r-project.org, Spencer Mass ma...@newpaltz.edu Subject: Re: [R-SIG-Mac] Yosemite and R No, it is not. It is expected that the path in the terminal be different to the path in R, it is _not_ expected that the path in R be different to the path in a subprocess started by R. (Well it is now expected, because this appears to be a new security feature in Yosemite) The best thread I could find on the problem is here: https://code.google.com/p/mactlmgr/issues/detail?id=102 -- http://had.co.nz/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Brian, Peter, and Simon, As I explained, I removed the call to tkwait.window() in Rcmdr modal dialogs, and I've now had a chance to test the consequences. AFAICS, in almost all cases, the change is benign. Because control is returned to the R command prompt before a dialog closes, there is the possibility that a user will put R in a state that produce an error (e.g., erasing a data set that existed when the dialog opened), but that seems to me unlikely. In some cases, however, when the OK button is pressed in a dialog, another dialog opens, and, to work properly, the function dispatched by the OK button should wait until the second dialog closes, since it requires information supplied by the user in the second dialog. Removing tkwait.window() from the second dialog produces an error in this circumstance. I've therefore introduced an optional force.tkwait argument, which defaults to FALSE, to the Rcmdr dialogSuffix() macro; setting the argument to TRUE in a secondary dialog solves the problem that I outlined. With these changes, I think that the Rcmdr now behaves correctly on all platforms, permitting, e.g., help pages to display properly under Mac OS X and in RStudio. Thanks to everyone who addressed this problem, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of John Fox Sent: Wednesday, August 13, 2014 12:57 PM To: 'Prof Brian Ripley'; 'peter dalgaard' Cc: 'R-SIG-Mac' Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() - - runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: John, can't you address
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Rich, On Wed, 13 Aug 2014 20:33:47 -0400 Richard M. Heiberger r...@temple.edu wrote: I have a hypothesis why R-Forge might be having trouble. This is the first time I used Rcmdr in R_3.1.1 on the Mac. It said it needed to install sem, relimp, lmtest, aplpack. It also installed the dependency matrixcalc. matrixcalc is not in the Rcmdr Suggests: list. My guess is that adding matrixcalc to the Suggests list might be the missing item that will allow building on R-Forge. No, these packages in Suggests are not new in version 2.1-0 of the Rcmdr; they are also in the current CRAN version. matrixcalc is required by sem, and that indirect dependency doesn't cause a problem. Here's what R-Forge isn't finding: 'abind' 'aplpack' 'colorspace' 'effects' 'e1071' 'Hmisc' 'knitr' 'leaps' 'lmtest' 'markdown' 'multcomp' 'relimp' 'rgl' 'rJava' 'RODBC' 'sem' . BTW, I noticed that this problem doesn't occur anymore on the Linux platform on R-Forge, just on Windows, so maybe it's being fixed. Thanks for trying to help, John Rich On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote: Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Rich, On Wed, 13 Aug 2014 21:11:34 -0400 Richard M. Heiberger r...@temple.edu wrote: I downloaded Rcmdr_2.1-0 and installed it on my Mac. I am using 57531778 Jul 16 23:58 R-3.1-branch-mavericks.pkg R version 3.1.1 Patched (2014-07-16 r66175) Rcmdr needs RcmdrMisc which I see is in the same svn download, so I installed it too. I don't see anything on the Tools Options that looks relevant to the help system. No, not all Rcmdr options are there. options(Rcmdr) comes up NULL. Yes, until you've set it. I tried Rcmdr - list( help_type=text) options()$Rcmdr NULL options(Rcmdr=Rcmdr) options(Rcmdr) $Rcmdr $Rcmdr$help_type [1] text and also options(help_type=text) Neither helped. Help files are sent to an X11 viewer. Looking at the current Rcmdr code on R-Forge, I actually removed the application of the Rcmdr help_type option in the last set of changes, so it's simply ignored. I apologize for the misinformation in my previous message. OTOH, the standard R help_type option should then control help, so setting options(help_type=text) should produce plain-text help. I just checked on my Windows system under the R Console, and it behaves as expected. If you're seeing the plain-text help in X-Windows, I don't know how to make it appear instead in Emacs. Sorry, John I detached Rcmdr with unload=TRUE and help files went back to an emacs buffer. Please suggest something else for me to try. Rich On Wed, Aug 13, 2014 at 8:33 PM, Richard M. Heiberger r...@temple.edu wrote: I have a hypothesis why R-Forge might be having trouble. This is the first time I used Rcmdr in R_3.1.1 on the Mac. It said it needed to install sem, relimp, lmtest, aplpack. It also installed the dependency matrixcalc. matrixcalc is not in the Rcmdr Suggests: list. My guess is that adding matrixcalc to the Suggests list might be the missing item that will allow building on R-Forge. Rich On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote: Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: John, can't you address the underlying issue instead and don't block the event loop? A lot of things don't work if the event loop is blocked and I would argue that changing user's preferences behind the scenes is a violation of the CRAN policies. I'm happy to help if you send me a bit more details. Cheers, Simon On Aug 12, 2014, at 6:15 PM, John Fox j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? Hi John, Happy to help. I recalled seeing something previously on this, so a search using rseek.org was fruitful. The potential gotcha, of course, is if for some reason the GUI exits in a manner possibly not under your control. The setting would not be returned to the default and the therefore, as you note, retained for a subsequent session where the behavior may not be desired. Yes, there is that possibility. If this is for Rcmdr, perhaps this is something that could be added to a menu, where the user can alter the behavior in either direction as desired, if that makes sense. As you guessed, this is for the Rcmdr, where the built-in R.app browser doesn't play well with dialog help buttons -- the browser is unresponsive until the dialog that called it closes -- while an external html-help browser works fine. I've now successfully implemented the approach I outlined, in which the previous setting is restored when the Commander GUI closes. As you point out, this isn't bullet-proof, but I think it is the best I can do for now. Allowing the user to apply the change would be safer, but users are unlikely to discover the option. Simon would need to comment on the potential for alternatives. Yes, that would be welcome. I still think that a setting via options() would be better. Thanks again for your help, John Best regards, Marc On Aug 12, 2014, at 3:46 PM, John Fox j...@mcmaster.ca wrote: Hi Marc, Thanks for this. It does work, and I wasn't aware of it -- you've obviously done a better job than I did of searching for a solution! Although this approach works, it has the disadvantage of permanently changing the help browser in R.app, beyond the current session, at least until the change is explicitly undone. I think that I can work around that by something like current - system(defaults read org.R-project.R, intern=TRUE) to discover whether the use.external.help preference exists, and if so, what its value is; to then set the preference to YES if it's NO or unset; and finally to remove the preference on exit. Again, thanks -- I think that I can work with this, though it would in my opinion be better if the help browser were settable for the current session directly via options() in R, or if one could specify the browser in a call to help(). Best (and thanks again), John -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@mcmaster.ca wrote: Dear list members, Is there a way to bypass the R.app help browser, and to use instead an alternative browser, such as the one pointed to by getOption(browser)? I've tried a number of strategies, including setting .Platform$GUI - unknown. The only approach I tried that works is to mask the help() function with a modified version, but this produces other problems, such as referencing unexported objects from utils and tools. It would be nice if the help() function had a browser argument, similar to that in browseURL(), and defaulting to the current
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: John, can't you address the underlying issue instead and don't block the event loop? A lot of things don't work if the event loop is blocked and I would argue that changing user's preferences behind the scenes is a violation of the CRAN policies. I'm happy to help if you send me a bit more details. Cheers, Simon On Aug 12, 2014, at 6:15 PM, John Fox j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? Hi John, Happy to help. I recalled seeing something previously on this, so a search using rseek.org was fruitful. The potential gotcha, of course, is if for some reason the GUI exits in a manner possibly not under your control. The setting would not be returned to the default and the therefore, as you note, retained for a subsequent session where the behavior may not be desired. Yes, there is that possibility. If this is for Rcmdr, perhaps this is something that could be added to a menu, where the user can alter the behavior in either direction as desired, if that makes sense. As you guessed, this is for the Rcmdr, where the built-in R.app browser doesn't play well with dialog help buttons -- the browser is unresponsive until the dialog that called it closes -- while an external html- help browser works fine. I've now successfully implemented the approach I outlined, in which the previous setting is restored when the Commander GUI closes. As you point out
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote
[R-SIG-Mac] bypassing the R.app help browser?
Dear list members, Is there a way to bypass the R.app help browser, and to use instead an alternative browser, such as the one pointed to by getOption(browser)? I've tried a number of strategies, including setting .Platform$GUI - unknown. The only approach I tried that works is to mask the help() function with a modified version, but this produces other problems, such as referencing unexported objects from utils and tools. It would be nice if the help() function had a browser argument, similar to that in browseURL(), and defaulting to the current behaviour. Any suggestions would be appreciated. John John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] bypassing the R.app help browser?
Hi Marc, Thanks for this. It does work, and I wasn't aware of it -- you've obviously done a better job than I did of searching for a solution! Although this approach works, it has the disadvantage of permanently changing the help browser in R.app, beyond the current session, at least until the change is explicitly undone. I think that I can work around that by something like current - system(defaults read org.R-project.R, intern=TRUE) to discover whether the use.external.help preference exists, and if so, what its value is; to then set the preference to YES if it's NO or unset; and finally to remove the preference on exit. Again, thanks -- I think that I can work with this, though it would in my opinion be better if the help browser were settable for the current session directly via options() in R, or if one could specify the browser in a call to help(). Best (and thanks again), John -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@mcmaster.ca wrote: Dear list members, Is there a way to bypass the R.app help browser, and to use instead an alternative browser, such as the one pointed to by getOption(browser)? I've tried a number of strategies, including setting .Platform$GUI - unknown. The only approach I tried that works is to mask the help() function with a modified version, but this produces other problems, such as referencing unexported objects from utils and tools. It would be nice if the help() function had a browser argument, similar to that in browseURL(), and defaulting to the current behaviour. Any suggestions would be appreciated. John John, I found this post from Simon that seems to work: https://stat.ethz.ch/pipermail/r-sig-mac/2009-December/006908.html I tried it on my Mac in the latest version of R.app, which I normally do not use and the help system does now popup a browser. 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] bypassing the R.app help browser?
Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? Hi John, Happy to help. I recalled seeing something previously on this, so a search using rseek.org was fruitful. The potential gotcha, of course, is if for some reason the GUI exits in a manner possibly not under your control. The setting would not be returned to the default and the therefore, as you note, retained for a subsequent session where the behavior may not be desired. Yes, there is that possibility. If this is for Rcmdr, perhaps this is something that could be added to a menu, where the user can alter the behavior in either direction as desired, if that makes sense. As you guessed, this is for the Rcmdr, where the built-in R.app browser doesn't play well with dialog help buttons -- the browser is unresponsive until the dialog that called it closes -- while an external html-help browser works fine. I've now successfully implemented the approach I outlined, in which the previous setting is restored when the Commander GUI closes. As you point out, this isn't bullet-proof, but I think it is the best I can do for now. Allowing the user to apply the change would be safer, but users are unlikely to discover the option. Simon would need to comment on the potential for alternatives. Yes, that would be welcome. I still think that a setting via options() would be better. Thanks again for your help, John Best regards, Marc On Aug 12, 2014, at 3:46 PM, John Fox j...@mcmaster.ca wrote: Hi Marc, Thanks for this. It does work, and I wasn't aware of it -- you've obviously done a better job than I did of searching for a solution! Although this approach works, it has the disadvantage of permanently changing the help browser in R.app, beyond the current session, at least until the change is explicitly undone. I think that I can work around that by something like current - system(defaults read org.R-project.R, intern=TRUE) to discover whether the use.external.help preference exists, and if so, what its value is; to then set the preference to YES if it's NO or unset; and finally to remove the preference on exit. Again, thanks -- I think that I can work with this, though it would in my opinion be better if the help browser were settable for the current session directly via options() in R, or if one could specify the browser in a call to help(). Best (and thanks again), John -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@mcmaster.ca wrote: Dear list members, Is there a way to bypass the R.app help browser, and to use instead an alternative browser, such as the one pointed to by getOption(browser)? I've tried a number of strategies, including setting .Platform$GUI - unknown. The only approach I tried that works is to mask the help() function with a modified version, but this produces other problems, such as referencing unexported objects from utils and tools. It would be nice if the help() function had a browser argument, similar to that in browseURL(), and defaulting to the current behaviour. Any suggestions would be appreciated. John John, I found this post from Simon that seems to work: https://stat.ethz.ch/pipermail/r-sig-mac/2009-December/006908.html I tried it on my Mac in the latest version of R.app, which I normally do not use and the help system does now popup a browser. 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
Dear Marc and Kasper,
I already know how to test whether the Rcmdr is running under Mac OS X and
to test whether X11 is installed. But AFAICS there is no way for me to run
this code in the Rcmdr package at startup *before* tcltk fails to load -- I
did try to do this, both in .onLoad() and in .onAttach().
I thought that I'd made this problem clear in my initial message but
apparently I hadn't. I'd be happy if someone proved me wrong by showing me
another way to intercept the problem on startup of the Rcmdr package, but I
think that the fix has to go into tcltk, as Kasper suggests.
Best,
John
-Original Message-
From: Marc Schwartz [mailto:marc_schwa...@me.com]
Sent: Monday, July 14, 2014 6:33 PM
To: Kasper Daniel Hansen
Cc: John Fox; urba...@research.att.com; r-sig-mac@r-project.org
Subject: Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues
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 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
___
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
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.
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
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
___
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
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
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
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Hi Rob, On Wed, 04 Dec 2013 20:16:39 -0700 Robert J Goedman goed...@icloud.com wrote: Hi John, I had a quick read of the notes and I think they are correct. The only case that is not covered is if someone builds R.app themselves against OS X 10.9 (as I mentioned previously). I don't think right now this is a big deal. Those folks will have to use 'defaults ...' or add/update the NSAppSleepDisabled entry in the plist directly. Thanks for checking out the Rcmdr installation notes. I don't think that many Rcmdr users will build R.app themselves. Brian and I had been looking at intercepting the App Nap capability at the point where the R-busy indicator is activated. That also covers some important cases, but unfortunately not tcltk (as far as I can tell). That makes sense. What about providing an installer option to prevent App Nap? Best, John Regards, Rob J. Goedman goed...@icloud.com On Dec 4, 2013, at 3:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Rob, Pending another solution, I've modified the Rcmdr installation notes at http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html to suggest that users of the Rcmdr under OS X 10.9 either run R from a terminal window or check the Prevent App Nap box in the R.app Get Info dialog. Please take a look at the notes and see whether they are sufficiently clear and correct. Thanks, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Prof Brian Ripley Sent: Sunday, December 01, 2013 10:51 AM To: Robert J Goedman Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks So for people with a CRAN build of R, the tick box is the way to go (and/or keep the console visible). I've added that to the R-admin manual. If you do build R.app against 10.9, then you should be using the App Nap API. I think that in part is straightforward, as 'busy' gets set when the R interpreter is evaluating. So Re_RBusy needs to use the beginActivityWithOptions:reason:, endActivity:, methods on the NSProcessInfo class. I'll leave that to someone fluent in ObjC. On 30/11/2013 23:19, Robert J Goedman wrote: HI peter, My understanding is that that box disappears if R.app is build against OS X 10.9. I've never seen that box (as I have been building against 10.9 for quite a while now), but I know folks have. As long as it is there I fully agree, much easier than defaults Regards, Rob J. Goedman goed...@icloud.com On Nov 30, 2013, at 11:09 AM, peter dalgaard pda...@gmail.com wrote: On 30 Nov 2013, at 16:58 , Robert J Goedman goed...@icloud.com wrote: Yes, I've seen that as well and it is likely not limited to tcltk. Question is, for R.app, do we want to ship with NSAppSleepDisabled? I would be in favor (my $0.02). If yes I will commit. One item: I found that there is a tick box Prevent App Nap available via Get Info for applications (secondary click in the Applications folder), which is somewhat more intuitive that the defaults write ... route. If we make your change, will the same box appear, just selected by default? Regards, Rob J. Goedman goed...@icloud.com On Nov 30, 2013, at 7:00 AM, peter dalgaard pda...@gmail.com wrote: On 30 Nov 2013, at 12:37 , Prof Brian Ripley rip...@stats.ox.ac.uk wrote: This does not happen for me provided R.app is visible. From https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInO SX/Articles/MacOSX10_9.html 'An app is considered to be a candidate for sleep if: It is not visible-if all of an app's windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground (other necessary conditions)'. which if accurate indicates that keeping the R.app console unhidden should suffice. On Nov 28, 2013, at 6:35 AM, Robert J Goedman goed...@icloud.com wrote: Hi, and Happy Thanksgiving for those that celebrate it! If Peter is right (and I expect he is, but will experiment a bit more if the setting can be updated while R.app is running and take effect immediately), I would suggest for now folks just use 'defaults ...' from a terminal window if they encounter these issues. Once we understand better what might be affected by allowing the sleep mode we can possibly refine that approach. Regards, Rob [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Dear Brian, Keeping R.app visible should deal with the case of a long computation as long as users are conscious of the problem, but it's likely that users of the Rcmdr will normally cover up the R.app window or minimize it. Best, John On Sat, 30 Nov 2013 11:37:19 + Prof Brian Ripley rip...@stats.ox.ac.uk wrote: This does not happen for me provided R.app is visible. From https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html 'An app is considered to be a candidate for sleep if: It is not visibleif all of an apps windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground (other necessary conditions)'. which if accurate indicates that keeping the R.app console unhidden should suffice. On 30/11/2013 10:59, peter dalgaard wrote: On 29 Nov 2013, at 16:35 , Simon Urbanek simon.urba...@r-project.org wrote: But let me say that what has been proposed is very heavy-handed to say it mildly - changing user's configuration files is not something that should be done without user's consent (if at all) - and AFAIK you're not allowed to do it if you plan to put this on CRAN. In addition, it's trying to swat the symptom with a hammer, it doesn't solve the problem (which is why doesn't tcltk wake up sleep with its activity). On the other hand, the OS is also acting very heavy-handed here! Try this for (i in 1:100) print(system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[[elapsed]]) and go surf the net or something while you wait. The time per iteration shoots up by a factor of 5-6 as R.app goes into App Nap. I.e., the problem is not confined to tcltk. Wouldn't it be better to handle this issue in R.app or even in tcltk, however? Yes, it should be handled in either of the two - if this problem is tcltk-specific then tcltk should wake up the sleep, if it is something that affects other R code as well, then it may need to be handled in the R event loop. Looks like it is that latter. Until we figure out how to do that, I think we need to prepare to tell users to set NSAppSleepDisabled, if they want to do something computationally intensive (and be able to go for a cup of coffee in the meantime). Of course it is nicer, OS-wise, to leave App Nap enabled, but it reduces the energy footprint of an inactive R.app from only about 1.5 to nearly 0.0, compared to about 100 when R is actually working. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac John Fox McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Dear Peter, On Thu, 28 Nov 2013 12:00:31 +0100 peter dalgaard pda...@gmail.com wrote: On 28 Nov 2013, at 01:46 , John Fox j...@mcmaster.ca wrote: Hi Rob, I had some time today and so I started to implement this solution in the Rcmdr. I first tested whether setting system(defaults write org.R-project.R NSAppSleepDisabled -bool yes) fixes the problem; I verified via system(defaults read org.R-project.R NSAppSleepDisabled) that the key was in fact set properly. I'm afraid that even with NSAppSleepDisabled set, the Rcmdr still freezes periodically. Whatever is going on is probably more complicated than power-saving. Hmm. The tkfaq issue seems to have gone away for me. You did remember to restart R.app after setting the key? I didn't remember to restart R.app because I didn't know that it was necessary to do so. In fact, the code that I wrote, but didn't commit, for the Rcmdr carefully resets the key to its previous state or deletes it if it didn't previously exist when the Commander is closed. I think that you've almost surely identified my problem, but the solution also raises a question about what to do. I'm reluctant to have the Rcmdr make a permanent change to users' OS settings. I guess that I could detect whether the NSAppSleepDisabled key is set and pop up a dialog box if it isn't, offering to make the change, and suggesting that the user restart R.app. (BTW, is there an easy way to check whether R is running in R.app or a terminal?) Wouldn't it be better to handle this issue in R.app or even in tcltk, however? If restarting R.app after setting the NSAppSleepDisabled key doesn't work for me, I'll then pursue Rob's suggestions. Thanks for this, John -pd Best, John -Original Message- From: Robert J Goedman [mailto:goed...@icloud.com] Sent: Sunday, November 24, 2013 11:50 AM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks Hi John, If it's not too much work, I would implement it in Rcmdr because I don't know if there are other consequences of App Nap, so until the dust settles using the defaults system might be ok. Regards, Rob J. Goedman goed...@icloud.com On Nov 24, 2013, at 8:30 AM, John Fox j...@mcmaster.ca wrote: Hi Rob, You've just answered my next question! I was holding off to give you a chance to address the issue directly in R.app. Is there any reason for me, at least for the time-being, not to do this from the Rcmdr via system()? I just tried, and that seems to work. If necessary, I could check for the existence and (if it exists) the current state of this key, and restore that when the Commander() exits. Of course, if you plan to address the issue directly soon, it doesn't make sense for me to do so. Thanks again for your help. John -Original Message- From: Robert J Goedman [mailto:goed...@icloud.com] Sent: Sunday, November 24, 2013 10:32 AM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks Hi John, If you want to play around with NSAppSleepDisabled yourself, you can, in a Terminal: defaults write org.R-project.R NSAppSleepDisabled -bool yes to check the setting: defaults read org.R-project.R NSAppSleepDisabled or to re-enable AppNap: defaults write org.R-project.R NSAppSleepDisabled -bool no or just delete the key: defaults delete org.R-project.R NSAppSleepDisabled Regards, Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 10:31 PM, Robert J Goedman goed...@icloud.com wrote: Hi John, I'm just starting, but it look likes 'defaults write ...' can be used to manage the setting. Not elegant, but maybe temporarily ok for tcltk users. Someone from TexShop (Richard Koch) reported that if R.app is compiled against the 10.9 APIs, the 'Prevent App Nap' check box will not appear. The ultimate solution is for R.app to know when App Nap should not kick in, there is a new API for that. So, some more homework... Regards, Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 9:06 PM, John Fox j...@mcmaster.ca wrote: Hi Rob, Thanks for the explanation -- that makes sense of the current behaviour. I think that you know that I'm not very knowledgeable about OS X. A couple of follow-up questions: If you make this change to R.app, will the default be to disable App Nap or just to provide the check box? If App Nap isn't disable by R.app by default, would it be possible to disable it under program control, e.g., when the Rcmdr package is loaded? Best, John On Sat, 23 Nov 2013 18:59:12 -0800 Robert J Goedman
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Dear Philippe, Thanks for this. Since I can already tell when R is running under Mac OS X, that should solve the problem of differentiating R.app and R running in a terminal. Best, John On Thu, 28 Nov 2013 14:54:52 +0100 Philippe Grosjean phgrosj...@sciviews.org wrote: On 28 Nov 2013, at 14:38, John Fox j...@mcmaster.ca wrote: Dear Peter, On Thu, 28 Nov 2013 12:00:31 +0100 peter dalgaard pda...@gmail.com wrote: On 28 Nov 2013, at 01:46 , John Fox j...@mcmaster.ca wrote: Hi Rob, I had some time today and so I started to implement this solution in the Rcmdr. I first tested whether setting system(defaults write org.R-project.R NSAppSleepDisabled -bool yes) fixes the problem; I verified via system(defaults read org.R-project.R NSAppSleepDisabled) that the key was in fact set properly. I'm afraid that even with NSAppSleepDisabled set, the Rcmdr still freezes periodically. Whatever is going on is probably more complicated than power-saving. Hmm. The tkfaq issue seems to have gone away for me. You did remember to restart R.app after setting the key? I didn't remember to restart R.app because I didn't know that it was necessary to do so. In fact, the code that I wrote, but didn't commit, for the Rcmdr carefully resets the key to its previous state or deletes it if it didn't previously exist when the Commander is closed. I think that you've almost surely identified my problem, but the solution also raises a question about what to do. I'm reluctant to have the Rcmdr make a permanent change to users' OS settings. I guess that I could detect whether the NSAppSleepDisabled key is set and pop up a dialog box if it isn't, offering to make the change, and suggesting that the user restart R.app. (BTW, is there an easy way to check whether R is running in R.app or a terminal?) Look at svMisc::isAqua(), which uses indeed .Platform$GUI returning Aqua on R.app or X11 on R under a terminal. I am not sure, however, that R on a terminal returns *always* X11. Best, Philippe Wouldn't it be better to handle this issue in R.app or even in tcltk, however? If restarting R.app after setting the NSAppSleepDisabled key doesn't work for me, I'll then pursue Rob's suggestions. Thanks for this, John [ ] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Hi Rob, I had some time today and so I started to implement this solution in the Rcmdr. I first tested whether setting system(defaults write org.R-project.R NSAppSleepDisabled -bool yes) fixes the problem; I verified via system(defaults read org.R-project.R NSAppSleepDisabled) that the key was in fact set properly. I'm afraid that even with NSAppSleepDisabled set, the Rcmdr still freezes periodically. Whatever is going on is probably more complicated than power-saving. Best, John -Original Message- From: Robert J Goedman [mailto:goed...@icloud.com] Sent: Sunday, November 24, 2013 11:50 AM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks Hi John, If it's not too much work, I would implement it in Rcmdr because I don't know if there are other consequences of App Nap, so until the dust settles using the defaults system might be ok. Regards, Rob J. Goedman goed...@icloud.com On Nov 24, 2013, at 8:30 AM, John Fox j...@mcmaster.ca wrote: Hi Rob, You've just answered my next question! I was holding off to give you a chance to address the issue directly in R.app. Is there any reason for me, at least for the time-being, not to do this from the Rcmdr via system()? I just tried, and that seems to work. If necessary, I could check for the existence and (if it exists) the current state of this key, and restore that when the Commander() exits. Of course, if you plan to address the issue directly soon, it doesn't make sense for me to do so. Thanks again for your help. John -Original Message- From: Robert J Goedman [mailto:goed...@icloud.com] Sent: Sunday, November 24, 2013 10:32 AM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks Hi John, If you want to play around with NSAppSleepDisabled yourself, you can, in a Terminal: defaults write org.R-project.R NSAppSleepDisabled -bool yes to check the setting: defaults read org.R-project.R NSAppSleepDisabled or to re-enable AppNap: defaults write org.R-project.R NSAppSleepDisabled -bool no or just delete the key: defaults delete org.R-project.R NSAppSleepDisabled Regards, Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 10:31 PM, Robert J Goedman goed...@icloud.com wrote: Hi John, I'm just starting, but it look likes 'defaults write ...' can be used to manage the setting. Not elegant, but maybe temporarily ok for tcltk users. Someone from TexShop (Richard Koch) reported that if R.app is compiled against the 10.9 APIs, the 'Prevent App Nap' check box will not appear. The ultimate solution is for R.app to know when App Nap should not kick in, there is a new API for that. So, some more homework... Regards, Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 9:06 PM, John Fox j...@mcmaster.ca wrote: Hi Rob, Thanks for the explanation -- that makes sense of the current behaviour. I think that you know that I'm not very knowledgeable about OS X. A couple of follow-up questions: If you make this change to R.app, will the default be to disable App Nap or just to provide the check box? If App Nap isn't disable by R.app by default, would it be possible to disable it under program control, e.g., when the Rcmdr package is loaded? Best, John On Sat, 23 Nov 2013 18:59:12 -0800 Robert J Goedman goed...@icloud.com wrote: Hi John, Looking at Activity Monitor on my system, R will always take up say 2.5% CPU time while R.app will almost go away if it is not active. This might be because in a terminal the process might not be treated as a pure application but maybe more as a traditional Unix process. But that's just a guess from my side. What surprised me a bit is that we couldn't switch off App Nap, as is possible with several other apps (go to the Info panel of an app and it should show a 'Prevent App Nap' box, e.g. Dropbox). R.app did not show that box, probably a consequence of an older build/project creation? Anyway, on my system I added that property in the info.plist and disabled the App Nap behavior. It seems to be working fine now. I'll do some more testing to see if I can get the check box on the Info screen show up and check with Simon if it's ok to commit the change. Of course, in that case R.app will also always consume 2.5% CPU. Under the energy tab of the Activity Monitor you can see which apps allow App Nap. Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 5:43 AM, John Fox
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Hi Rob, OK -- thanks. I'll do that in the development version of the package on R-Forge when I have a chance, likely sometime this week. I'll then post a message to this list. Best, John -Original Message- From: Robert J Goedman [mailto:goed...@icloud.com] Sent: Sunday, November 24, 2013 11:50 AM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks Hi John, If it's not too much work, I would implement it in Rcmdr because I don't know if there are other consequences of App Nap, so until the dust settles using the defaults system might be ok. Regards, Rob J. Goedman goed...@icloud.com On Nov 24, 2013, at 8:30 AM, John Fox j...@mcmaster.ca wrote: Hi Rob, You've just answered my next question! I was holding off to give you a chance to address the issue directly in R.app. Is there any reason for me, at least for the time-being, not to do this from the Rcmdr via system()? I just tried, and that seems to work. If necessary, I could check for the existence and (if it exists) the current state of this key, and restore that when the Commander() exits. Of course, if you plan to address the issue directly soon, it doesn't make sense for me to do so. Thanks again for your help. John -Original Message- From: Robert J Goedman [mailto:goed...@icloud.com] Sent: Sunday, November 24, 2013 10:32 AM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks Hi John, If you want to play around with NSAppSleepDisabled yourself, you can, in a Terminal: defaults write org.R-project.R NSAppSleepDisabled -bool yes to check the setting: defaults read org.R-project.R NSAppSleepDisabled or to re-enable AppNap: defaults write org.R-project.R NSAppSleepDisabled -bool no or just delete the key: defaults delete org.R-project.R NSAppSleepDisabled Regards, Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 10:31 PM, Robert J Goedman goed...@icloud.com wrote: Hi John, I'm just starting, but it look likes 'defaults write ...' can be used to manage the setting. Not elegant, but maybe temporarily ok for tcltk users. Someone from TexShop (Richard Koch) reported that if R.app is compiled against the 10.9 APIs, the 'Prevent App Nap' check box will not appear. The ultimate solution is for R.app to know when App Nap should not kick in, there is a new API for that. So, some more homework... Regards, Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 9:06 PM, John Fox j...@mcmaster.ca wrote: Hi Rob, Thanks for the explanation -- that makes sense of the current behaviour. I think that you know that I'm not very knowledgeable about OS X. A couple of follow-up questions: If you make this change to R.app, will the default be to disable App Nap or just to provide the check box? If App Nap isn't disable by R.app by default, would it be possible to disable it under program control, e.g., when the Rcmdr package is loaded? Best, John On Sat, 23 Nov 2013 18:59:12 -0800 Robert J Goedman goed...@icloud.com wrote: Hi John, Looking at Activity Monitor on my system, R will always take up say 2.5% CPU time while R.app will almost go away if it is not active. This might be because in a terminal the process might not be treated as a pure application but maybe more as a traditional Unix process. But that's just a guess from my side. What surprised me a bit is that we couldn't switch off App Nap, as is possible with several other apps (go to the Info panel of an app and it should show a 'Prevent App Nap' box, e.g. Dropbox). R.app did not show that box, probably a consequence of an older build/project creation? Anyway, on my system I added that property in the info.plist and disabled the App Nap behavior. It seems to be working fine now. I'll do some more testing to see if I can get the check box on the Info screen show up and check with Simon if it's ok to commit the change. Of course, in that case R.app will also always consume 2.5% CPU. Under the energy tab of the Activity Monitor you can see which apps allow App Nap. Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 5:43 AM, John Fox j...@mcmaster.ca wrote: Dear Rob et al., I'm glad that there's progress in understanding the source of the problem, but I wonder why the problem doesn't manifest itself -- at least in my experience -- when R runs in a terminal
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Hi Rob, Thanks for the explanation -- that makes sense of the current behaviour. I think that you know that I'm not very knowledgeable about OS X. A couple of follow-up questions: If you make this change to R.app, will the default be to disable App Nap or just to provide the check box? If App Nap isn't disable by R.app by default, would it be possible to disable it under program control, e.g., when the Rcmdr package is loaded? Best, John On Sat, 23 Nov 2013 18:59:12 -0800 Robert J Goedman goed...@icloud.com wrote: Hi John, Looking at Activity Monitor on my system, R will always take up say 2.5% CPU time while R.app will almost go away if it is not active. This might be because in a terminal the process might not be treated as a pure application but maybe more as a traditional Unix process. But that's just a guess from my side. What surprised me a bit is that we couldn't switch off App Nap, as is possible with several other apps (go to the Info panel of an app and it should show a 'Prevent App Nap' box, e.g. Dropbox). R.app did not show that box, probably a consequence of an older build/project creation? Anyway, on my system I added that property in the info.plist and disabled the App Nap behavior. It seems to be working fine now. I'll do some more testing to see if I can get the check box on the Info screen show up and check with Simon if it's ok to commit the change. Of course, in that case R.app will also always consume 2.5% CPU. Under the energy tab of the Activity Monitor you can see which apps allow App Nap. Rob J. Goedman goed...@icloud.com On Nov 23, 2013, at 5:43 AM, John Fox j...@mcmaster.ca wrote: Dear Rob et al., I'm glad that there's progress in understanding the source of the problem, but I wonder why the problem doesn't manifest itself -- at least in my experience -- when R runs in a terminal window. Best, John On Fri, 22 Nov 2013 14:42:00 -0800 Robert J Goedman goed...@icloud.com wrote: Thansk Peter, Now I can reproduce it! Rob J. Goedman goed...@icloud.com On Nov 22, 2013, at 1:00 PM, peter dalgaard pda...@gmail.com wrote: On 22 Nov 2013, at 16:42 , Robert J Goedman goed...@icloud.com wrote: Not sure how long it takes to see the lagging (a few minutes someone reported), but I've not been able to reproduce this problem. For me, library(tcltk); demo(tkfaq), click to focus, then use Fn-Down (i.e. PgDown) to go to the bottom of the file, Fn-Up to the top, etc. Less than two iteration for me before the effect kicks in. Which makes me wonder if anyone has seen this behavior after rebuilding R.app on Mavericks (from the R.app sources). Regards, Rob J. Goedman goed...@icloud.com On Nov 22, 2013, at 7:29 AM, Simon Urbanek simon.urba...@r-project.org wrote: On Nov 20, 2013, at 11:41 AM, Jonathan Chapman petsr...@icloud.com wrote: I upgraded to XQuartz 2.7.5, but it still lags. Please read Peter's response - it has nothing to do with XQuartz versions [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Dear all, I was able to reproduce the problem on my Macbook and believe I have a solution, which is to run R and the Rcmdr in a terminal window. When I did this, the Rcmdr behaved normally. I'll investigate further and report my findings back to the list. I'm copying this message to Simon Urbanek who maintains R.app in case he has insight into the problem. I'm also interested whether running R from a terminal window solves the problem for others who experienced it. Best, John On Wed, 20 Nov 2013 12:19:04 -0500 John Fox j...@mcmaster.ca wrote: Dear Jonathan et al, First, thank you to all who responded. As I said, I haven't noticed this problem myself, but I'll try again on my Mac later today when I have some time and see whether I can reproduce it. I suspect that this is a tcltk-related issue, not specific to the Rcmdr, but I don't know that for sure. In the meantime, here are two things to try: (1) Reijo Sund suggested trying to run R and the Rcmdr from the command line (i.e., in a terminal window), to see whether the problem manifests itself there. The Rcmdr doesn't need R.app. (2) It's possible that the slowdown is caused by the way that the Rcmdr handles R Markdown documents. The overhead gets greater as the session proceeds. To test this possibility, you could suppress the R Markdown tab (via the Rcmdr Tools - Options menu, Output tab -- uncheck the box for R Markdown) and see whether the problem disappears. Please let me know what happens. Best, John On Wed, 20 Nov 2013 10:41:28 -0600 Jonathan Chapman petsr...@icloud.com wrote: I upgraded to XQuartz 2.7.5, but it still lags. Jonathan M. Chapman, DVM 312-813-1166 petsr...@icloud.com On Nov 20, 2013, at 10:05 AM, Manuel Spínola mspinol...@gmail.com wrote: I also have the same experience (like Jonathan) with Rcmdr in Mac with Mavericks. After few minutes Rcmdr starts to have time lags. I updated to XQuartz 2.7.5 but the behavior is the same. Best, Manuel 2013/11/20 Reijo Sund reijo.s...@helsinki.fi So far I have not had problems with XQuartz, but similar slow-down occasionally happens while using tcltk-applications with the Aqua version of Tcl/Tk (ActiveTcl 8.6.x binary distribution). Unfortunately I have not been able to create a reproducible example. Anyhow, if XQuartz update wont help, maybe it is worth checking if there is any difference while using R.app or command-line R. - - - Prof Brian Ripley rip...@stats.ox.ac.uk wrote: Just checking: which version of XQuartz? Although I have not experienced any problems, people recommended updating to 2.7.5 and I got prompted to do that yesterday (it was released last week). On 20/11/2013 11:52, John Fox wrote: Dear Jonathan, I'm afraid that I don't know why you're experiencing this problem. I upgraded my own Mac to Mavericks and the Rcmdr still appears to work fine. Also, no one else has reported this problem to me, which of course doesn't mean that no one else has experienced it. I don't doubt that something is wrong on your system but I don't know what it might be. You've already reinstalled all of the relevant software, which is what I would have suggested. I'm copying this response to the R Mac OS X email list in case someone who reads the list has a suggestion or, perhaps, has also experienced the problem. I'm sorry that I can't be of more help at this time. John On Wed, 20 Nov 2013 00:19:54 -0600 Jonathan Chapman petsr...@icloud.com wrote: Dr. Fox, I am an MPH student at the University of Minnesota. I was referred to you by Dr. Ann Brearley because I am having issues running Rcmdr in XQuartz since upgrading to OSX Mavericks. Rcmdr runs slowly, more-so as a lag, after an initial 1-2 minutes of use. Prior to that 1-2 minutes of use and the subsequent lag in performance, Rcmdr runs perfectly fine via XQuartz. Once closing out XQuartz and restarting it, Rcmdr runs fine until after 1-2 minutes of use when the lag sets in again. Ive tried to remedy the situation prior to contacting you. First, I reinstalled XQuartz. When that failed to solve the problem, I reinstalled XQuartz along with R and Rcmdr. That attempt also failed. I do not know what else to do or who/where else to turn. Do you have any incite? Have you heard of anyone else encountering this problem? Jonathan M. Chapman, DVM 312-813-1166 petsr...@icloud.com ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Manuel Spínola, Ph.D. Instituto Internacional en Conservación y Manejo de Vida Silvestre Universidad Nacional Apartado
Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
Dear Peter, Thank you very much for taking a look at this problem and for confirming that the problem is general to tcltk. I coincidentally just send a message to the list with the same conclusion -- that the problem occurs in R.app but not in a terminal window. Best, John On Wed, 20 Nov 2013 21:17:40 +0100 peter dalgaard pda...@gmail.com wrote: Notes inlined below, -pd On 20 Nov 2013, at 18:19 , John Fox j...@mcmaster.ca wrote: Dear Jonathan et al, First, thank you to all who responded. As I said, I haven't noticed this problem myself, but I'll try again on my Mac later today when I have some time and see whether I can reproduce it. I suspect that this is a tcltk-related issue, not specific to the Rcmdr, but I don't know that for sure. Affirmative. You can get similar behaviour from library(tcltk); demo(tkfaq) in R.app. It doesnt seem to be happening with R in a Terminal window. You can snap out of it temporarily by switching to the R console and back. So a working hypothesis is that something is backgrounding the R process after a while, if it doesnt have input focus. Since the tcltk event loop runs off the keyboard loop, we have the trouble. My take is that someone needs to take a look at how R.app handles keyboard input, in particular the timeout aspect. In the meantime, here are two things to try: (1) Reijo Sund suggested trying to run R and the Rcmdr from the command line (i.e., in a terminal window), to see whether the problem manifests itself there. The Rcmdr doesn't need R.app. (2) It's possible that the slowdown is caused by the way that the Rcmdr handles R Markdown documents. The overhead gets greater as the session proceeds. To test this possibility, you could suppress the R Markdown tab (via the Rcmdr Tools - Options menu, Output tab -- uncheck the box for R Markdown) and see whether the problem disappears. Negative. I see the issue even with an older Rcmdr version without the Markdown stuff. Please let me know what happens. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com John Fox McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] similar problems installing Rcmdr with R.
Dear Simon, -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Wednesday, September 25, 2013 2:30 AM To: John Fox Cc: 'Hebblewhite, Mark'; r-sig-mac@r-project.org; 'Rodney Sparapani' Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. On Sep 24, 2013, at 8:34 PM, John Fox j...@mcmaster.ca wrote: Dear Mark, -Original Message- From: Hebblewhite, Mark [mailto:mark.hebblewh...@umontana.edu] Sent: Tuesday, September 24, 2013 12:32 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. Yes, the solution proposed by Rodney Sparapani below worked to fix my problem, but was a slightly different command than proposed to Sarah earlier. Thanks very much Rodney! It will be challenging to fix this problem, however, for other 'naïve' users of MAC if the solution is different each time. Just to be clear: sudo chmod a+rx /usr/local/* didn't work, but sudo zsh chmod -R 755 /usr/local did work? The later is bad, do NOT use it! It will set exec permissions on *everything* even files are are not supposed to be executable. You probably want sudo chmod -R a+rX /usr/local Yes, that's better than what I had in the troubleshooting section of the Rcmdr installation notes, which was sudo chmod -R a+rx /usr/local and which, as you say, would set execute permission for files as well as directories. I've fixed that now. When I first read Mark's message, I didn't realize that there were subdirectories below /usr/local that might also have incorrectly set permissions. Thanks, John Cheers, Simon Frankly, I don't get that, since the first command should insure that everyone has (at least) read and execute permission (i.e., level 5). I think that I'll add a trouble-shooting section to the Rcmdr Mac installation notes, but I would like to understand why one approach worked here and not the other. Best, John Thanks very much John, Simon and Rodney! On 09/24/2013 07:45 AM, Hebblewhite, Mark wrote: 7. From previous posts on this list serve [http://grokbase.com/t/r/r-sig-mac/138nv3tj17/unable-to-load-rcmdr- with-r- 3 -0-1-on-a-mac-os-x-10-8-3] I followed this set of instructions to see whether there were problems with my permissions: system(ls -ld /usr/local /usr/local/lib /usr/local/lib/libtcl*) ls: /usr/local/lib: Permission denied ls: /usr/local/lib/libtcl*: Permission denied drwx-- 8 root wheel 272 Sep 24 10:21 /usr/local 8. But in my disk utilities I can see no clear disk permissions related to R. I ran repair disk permissions earlier today and there was 1 R problem but that¹s been apparently fixed. Hi Mark: I am assuming you came to Mac from Windows, rather than UNIX/Linux, right? On Mac OS X (and UNIX/Linux in general), you need to have permission to read/write/execute files. But, I think you can fix this rather easily. In a terminal... % sudo zsh # chmod -R 755 /usr/local ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] similar problems installing Rcmdr with R.
Dear Mark, -Original Message- From: Hebblewhite, Mark [mailto:mark.hebblewh...@umontana.edu] Sent: Wednesday, September 25, 2013 3:17 AM To: Simon Urbanek; John Fox Cc: r-sig-mac@r-project.org; 'Rodney Sparapani' Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. Yes, originally, 1) sudo chmod a+rx/usr/local/* did not work but 2) sudo zsh chmod -R 755/usr/local did work. However, at your advice, Simon, I've gone and entered 3) sudo chmod -R a+rX /usr/local in terminal, and now Rcmdr works. Is there something else I should do to 'reverse' the 2nd incorrect command? Incidentally, this is obviously a broader problem and I encountered similar problems with other packages like adehabitat. Of course. As I explained earlier, the problem was that the tcltk package couldn't load, not with the Rcmdr directly, and the adehabitat package also uses the tcltk package. Thanks SO much for all your assistance and help, especially for updating the help files for Rcmdr John. I will ask some of my current graduate students to test it out on their Mac's too. They likely won't experience the same problem as you did, unless they too have incorrect permissions set for the /usr/local directory or subdirectories of it. Most people who follow the Rcmdr Mac OS X installation notes won't experience a problem. Anyway, I have some troubleshooting tips there now that cover the issue that arose on your Mac. If you turn up other problems not currently covered by the notes, I'd appreciate learning about them. Best, John thanks again! Mark Hebblewhite On 9/25/13 8:30 AM, Simon Urbanek simon.urba...@r-project.org wrote: On Sep 24, 2013, at 8:34 PM, John Fox j...@mcmaster.ca wrote: Dear Mark, -Original Message- From: Hebblewhite, Mark [mailto:mark.hebblewh...@umontana.edu] Sent: Tuesday, September 24, 2013 12:32 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. Yes, the solution proposed by Rodney Sparapani below worked to fix my problem, but was a slightly different command than proposed to Sarah earlier. Thanks very much Rodney! It will be challenging to fix this problem, however, for other 'naïve' users of MAC if the solution is different each time. Just to be clear: sudo chmod a+rx /usr/local/* didn't work, but sudo zsh chmod -R 755 /usr/local did work? The later is bad, do NOT use it! It will set exec permissions on *everything* even files are are not supposed to be executable. You probably want sudo chmod -R a+rX /usr/local Cheers, Simon Frankly, I don't get that, since the first command should insure that everyone has (at least) read and execute permission (i.e., level 5). I think that I'll add a trouble-shooting section to the Rcmdr Mac installation notes, but I would like to understand why one approach worked here and not the other. Best, John Thanks very much John, Simon and Rodney! On 09/24/2013 07:45 AM, Hebblewhite, Mark wrote: 7. From previous posts on this list serve [http://grokbase.com/t/r/r-sig-mac/138nv3tj17/unable-to-load- rcmdr- with-r- 3 -0-1-on-a-mac-os-x-10-8-3] I followed this set of instructions to see whether there were problems with my permissions: system(ls -ld /usr/local /usr/local/lib /usr/local/lib/libtcl*) ls: /usr/local/lib: Permission denied ls: /usr/local/lib/libtcl*: Permission denied drwx-- 8 root wheel 272 Sep 24 10:21 /usr/local 8. But in my disk utilities I can see no clear disk permissions related to R. I ran repair disk permissions earlier today and there was 1 R problem but that¹s been apparently fixed. Hi Mark: I am assuming you came to Mac from Windows, rather than UNIX/Linux, right? On Mac OS X (and UNIX/Linux in general), you need to have permission to read/write/execute files. But, I think you can fix this rather easily. In a terminal... % sudo zsh # chmod -R 755 /usr/local ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] similar problems installing Rcmdr with R.
Hi Rodney, Unless you see a compelling reason not to, I think that I'll stick with the current version of the instructions. The object is to have something simple for unsophisticated users, and the current version of the troubleshooting instructions are already a bit complicated. Best, John -Original Message- From: Rodney Sparapani [mailto:rspar...@mcw.edu] Sent: Wednesday, September 25, 2013 11:27 AM To: John Fox Cc: 'Hebblewhite, Mark'; r-sig-mac@r-project.org; 'Simon Urbanek' Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. On 09/24/2013 07:57 PM, John Fox wrote: Hi Rodney, I've added a section on Mac OS X Trouble-shooting to the Rcmdr installation notes at http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation- notes.html, with explicit instructions on the recent problems experienced by Sarah and Mark. I'd appreciate it if you could take a look at this to see whether the instructions are clear. Also, are there other cases that I should cover? Thanks, John Hi John: It looks pretty good to me; lot's of useful info. I see that you have sudo chmod -R a+rX /usr/local as has been suggested. It definitely makes sense; why have /usr/local if no one can actually do anything with it? However, we are doing a bit more than fixing this issue at hand. What if you said it this way? Having confirmed the problem, you can change the file permissions in /usr/local/lib by opening a terminal window on your Mac (Terminal.app is in the Applications Utilities folder) and entering the following command at the $ prompt in the terminal window: sudo chmod -R a+rX /usr/local/lib The operating system will ask you to supply your password to execute this command. File-permissions problems such as this may also occur when you attempt to install other R packages. In that case, you might consider performing the same operation on the directories /usr/local/bin and/or /usr/local/include. Since there is not much point having /usr/local if no one can actually use it, then you might consider altering the entire /usr/local hierarchy: sudo chmod -R a+rX /usr/local But, now we have traveled pretty far afield from just Rcmdr... -- Rodney Sparapani, PhD Manager of Statistical Computational Operations Center for Patient Care and Outcomes Research (PCOR) Medical College of Wisconsin (MCW), Milwaukee, USA http://www.linkedin.com/in/rodneysparapani ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] similar problems installing Rcmdr with R.
Dear Mark, As was the case with other similar recent problems, this issue appears to pertain to the tcltk package and only indirectly to the Rcmdr. You can verify that by trying to load tcltk directly via library(tcltk). I assume that when you say that you updated everything, that included running Mac OS X Software Update. As you point out, your problem appears to be similar to an earlier problem reported by Sarah Hardy at http://grokbase.com/t/r/r-sig-mac/138nv3tj17/unable-to-load-rcmdr-with-r-3- 0-1-on-a-mac-os-x-10-8-3. In her case, fixing the files permissions fixed the problem, as indicated in the same thread. Did sudo chmod a+rx /usr/local/* work for you as it did for her? (I see that Rodney Sparapani has just made an equivalent suggestion.) Another question, assuming that this fix works, is why you experienced the problem in the first place. In Sarah's case, the permissions were screwed up by MacPorts. I'm copying this response to Simon Urbanek to make sure that he's aware of this thread (though there's no need for Simon to respond if fixing the permissions works). I hope this helps, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Hebblewhite, Mark Sent: Tuesday, September 24, 2013 8:46 AM To: r-sig-mac@r-project.org Subject: [R-SIG-Mac] similar problems installing Rcmdr with R. I have recently installed R 3.0.1 on my MacBook Pro OS X 10.8.5 (very new version), and am experiencing similar problems that Sarah Hardy posted almost a month ago. I similarly teach an introduction to R course to about 20 graduate students, many of whom use Mac's, but luckily not this semester. I have used R for 6 years, but am new (1 year) to MACs, but expect that if I'm having this problem with 10.8.5, then others must be too. I have read through the entire thread of solutions for this problem on this list serve, the notes on Joseph Fox's webpage (http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation- notes.html) and have tried to do my absolute best to fix the problem myself and with a colleague. Here is a summary of my particulars: 1. I have a Mac OS X 10.8.5, and updated everything today. 2. I also installed the XQuartz package today, version 2.7.4 from last Sept 2012. 3. I uninstalled R manually from my MAC (both moving old version to the trash and cleaning out R directories) 4. I re-installed R (R 3.0.1 GUI 1.61 Snow Leopard build (6492) directly from the CRAN (Italy) using this command: install.packages(Rcmdr, dependencies = TRUE) 5. I then followed the instructions for downloading Rcmdr package in both the command line and from the R.app menu. I have also tried it from two different CRAN sites. It downloaded and installed apparently fine as it appears in my library files (version dated august 22) The downloaded binary packages are in /var/folders/30/710s5wkn59959r6mfhmssyvrc0w434/T//RtmpGry9Bb/downl oaded_pa ckages 6.No matter what series of these steps I take, I receive the similar error message as others: library(Rcmdr) Error : .onLoad failed in loadNamespace() for 'tcltk', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared object '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/tcltk/l ibs/ tcltk.so': dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/t cltk /libs/tcltk.so, 10): Library not loaded: /usr/local/lib/libtcl8.6.dylib Referenced from: /Library/Frameworks/R.framework/Versions/3.0/Resources/library/tcltk/li bs/t cltk.so Reason: no suitable image found. Did find: /usr/local/lib/libtcl8.6.dylib: stat() failed with errno=13 /usr/local/lib/libtcl8.6.dylib: stat() failed with errno=13 Error: package or namespace load failed for ŒRcmdr¹ 7. From previous posts on this list serve [http://grokbase.com/t/r/r-sig-mac/138nv3tj17/unable-to-load-rcmdr- with-r-3 -0-1-on-a-mac-os-x-10-8-3] I followed this set of instructions to see whether there were problems with my permissions: system(ls -ld /usr/local /usr/local/lib /usr/local/lib/libtcl*) ls: /usr/local/lib: Permission denied ls: /usr/local/lib/libtcl*: Permission denied drwx-- 8 root wheel 272 Sep 24 10:21 /usr/local 8. But in my disk utilities I can see no clear disk permissions related to R. I ran repair disk permissions earlier today and there was 1 R problem but that¹s been apparently fixed. My own troubleshooting abilities are at an end. As best I can determine, it seems as if the XQuartz version I downloaded might not be working with my Mac OSX 10.8.5, but beyond that I really have no clue how best to proceed. thanks very much for your patience with this problem and with me if my query is naïve in anyway. Sincerely, Mark Hebblewhite Wildlife Biology Program Department of Ecosystem and Conservation Sciences College
Re: [R-SIG-Mac] similar problems installing Rcmdr with R.
Dear Mark, -Original Message- From: Hebblewhite, Mark [mailto:mark.hebblewh...@umontana.edu] Sent: Tuesday, September 24, 2013 12:32 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. Yes, the solution proposed by Rodney Sparapani below worked to fix my problem, but was a slightly different command than proposed to Sarah earlier. Thanks very much Rodney! It will be challenging to fix this problem, however, for other 'naïve' users of MAC if the solution is different each time. Just to be clear: sudo chmod a+rx /usr/local/* didn't work, but sudo zsh chmod -R 755 /usr/local did work? Frankly, I don't get that, since the first command should insure that everyone has (at least) read and execute permission (i.e., level 5). I think that I'll add a trouble-shooting section to the Rcmdr Mac installation notes, but I would like to understand why one approach worked here and not the other. Best, John Thanks very much John, Simon and Rodney! On 09/24/2013 07:45 AM, Hebblewhite, Mark wrote: 7. From previous posts on this list serve [http://grokbase.com/t/r/r-sig-mac/138nv3tj17/unable-to-load-rcmdr- with-r- 3 -0-1-on-a-mac-os-x-10-8-3] I followed this set of instructions to see whether there were problems with my permissions: system(ls -ld /usr/local /usr/local/lib /usr/local/lib/libtcl*) ls: /usr/local/lib: Permission denied ls: /usr/local/lib/libtcl*: Permission denied drwx-- 8 root wheel 272 Sep 24 10:21 /usr/local 8. But in my disk utilities I can see no clear disk permissions related to R. I ran repair disk permissions earlier today and there was 1 R problem but that¹s been apparently fixed. Hi Mark: I am assuming you came to Mac from Windows, rather than UNIX/Linux, right? On Mac OS X (and UNIX/Linux in general), you need to have permission to read/write/execute files. But, I think you can fix this rather easily. In a terminal... % sudo zsh # chmod -R 755 /usr/local ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] similar problems installing Rcmdr with R.
Hi Rodney, Thanks for the explanation. I guess that Sarah's but not Mark's file-permission problems were all at the first level of usr/local/. Best, John -Original Message- From: Rodney Sparapani [mailto:rspar...@mcw.edu] Sent: Tuesday, September 24, 2013 2:43 PM To: John Fox Cc: 'Hebblewhite, Mark'; r-sig-mac@r-project.org; Simon Urbanek Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. On 09/24/2013 01:34 PM, John Fox wrote: Just to be clear: sudo chmod a+rx/usr/local/* didn't work, but sudo zsh chmod -R 755 /usr/local did work? Frankly, I don't get that, since the first command should insure that everyone has (at least) read and execute permission (i.e., level 5). I think that I'll add a trouble-shooting section to the Rcmdr Mac installation notes, but I would like to understand why one approach worked here and not the other. Best, John Hi John: That makes sense. sudo chmod a+rx /usr/local/* does not descend into the subdirectories. To make that work, you need sudo chmod -R a+rx /usr/local -- Rodney Sparapani, PhD Manager of Statistical Computational Operations Center for Patient Care and Outcomes Research (PCOR) Medical College of Wisconsin (MCW), Milwaukee, USA http://www.linkedin.com/in/rodneysparapani ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] similar problems installing Rcmdr with R.
Hi Rodney, I've added a section on Mac OS X Trouble-shooting to the Rcmdr installation notes at http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html, with explicit instructions on the recent problems experienced by Sarah and Mark. I'd appreciate it if you could take a look at this to see whether the instructions are clear. Also, are there other cases that I should cover? Thanks, John -Original Message- From: Rodney Sparapani [mailto:rspar...@mcw.edu] Sent: Tuesday, September 24, 2013 2:43 PM To: John Fox Cc: 'Hebblewhite, Mark'; r-sig-mac@r-project.org; Simon Urbanek Subject: Re: [R-SIG-Mac] similar problems installing Rcmdr with R. On 09/24/2013 01:34 PM, John Fox wrote: Just to be clear: sudo chmod a+rx/usr/local/* didn't work, but sudo zsh chmod -R 755 /usr/local did work? Frankly, I don't get that, since the first command should insure that everyone has (at least) read and execute permission (i.e., level 5). I think that I'll add a trouble-shooting section to the Rcmdr Mac installation notes, but I would like to understand why one approach worked here and not the other. Best, John Hi John: That makes sense. sudo chmod a+rx /usr/local/* does not descend into the subdirectories. To make that work, you need sudo chmod -R a+rx /usr/local -- Rodney Sparapani, PhD Manager of Statistical Computational Operations Center for Patient Care and Outcomes Research (PCOR) Medical College of Wisconsin (MCW), Milwaukee, USA http://www.linkedin.com/in/rodneysparapani ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear Brian, On Fri, 20 Sep 2013 07:49:05 +0100 Prof Brian Ripley rip...@stats.ox.ac.uk wrote: On 20/09/2013 01:52, John Fox wrote: Dear Sarah, -Original Message- From: Sarah Hardy [mailto:sarah.ha...@maine.edu] Sent: Thursday, September 19, 2013 8:08 PM To: John Fox Cc: Simon Urbanek; David Winsemius; r-sig-mac Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Running the Software Update and reinstalling R and Rcmdr worked for the student with the 10.7.2. We did not reinstall XQuartz. Now I will I'm glad that this worked. Apparently, the student had an old version of X-Windows that was updated by Software Update. As Simon explained, in this situation installing XQuartz is irrelevant because the other version of X-Windows is invoked by R. see if it works for the others. BTW - I have identified at least one student with a 10.6.8 who had no problems installing R and Rcmdr without installing XQuartz (per my instructions) - am going to check with other students tomorrow. If the student installed a sufficiently up-to-date X-Windows, that should work, and apparently did. The X-Windows used needn't be XQuartz. My new instructions suggest that everyone install XQuartz because that will give them an up-to-date X-Windows if they don't already have X-windows installed, and will do no harm if they do have another X-Windows. I am not so sure about that. It will do no harm running CRAN binary R. But it does mean that there are multiple versions of X11 things about and that will cause problems for other things (including possibly installing packages from source). Thanks for pointing out this potential problem. Oh well -- I hoped to have a simple set of instructions, and having everyone install XQuartz followed what I took to be Simon's suggestion (below). Almost all of the problems people have with the Rcmdr package are on the Mac OS X platform, and since most of these people are not sophisticated in their computer use, having simple instructions is important. How about the following? (1) Run System Update. (2) Check whether X-Windows is installed. (I can restore my previous instructions about how to check.) (3) If X-Windows isn't installed, install XQuartz. etc. Best, John . . . -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Thursday, September 19, 2013 11:49 AM To: John Fox Cc: 'David Winsemius'; 'Sarah Hardy'; 'r-sig-mac' Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Well, the I think it reads far more complicated that in needs to be. You should have a quickstart section that just says: * Install R 3.0.1 or later * Install XQuartz from http://xquartz.macosforge.org Done. Current R only supports 10.6.8+ and so does XQuartz so the above covers everything that is supported right now (I recall having that discussion earlier...). Then you can have troubleshooting section which says a) make sure you installed R with Tcl/Tk (it is the default) - if in doubt, re-install R from CRAN b) use Software Update Then you can have a technical section with the details you show below, but 99% of users should not need to read it. Cheers, Simon . . . ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear flip, -Original Message- From: Flip Phillips [mailto:f...@skidmore.edu] Sent: Friday, September 20, 2013 8:41 AM To: r-sig-mac@r-project.org; rip...@stats.ox.ac.uk; j...@mcmaster.ca Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Ouch. I keep forgetting how sophisticated the users of Windows are. In case this isn't simply a joke, I referred to people using the Rcmdr, not Mac OS X. Most Windows users of the R Commander are also not sophisticated computer users, but on that platform installation of the package is very simple. John On Sep 20, 2013, at 8:36 AM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: Almost all of the problems people have with the Rcmdr package are on the Mac OS X platform, and since most of these people are not sophisticated in their computer use, having simple instructions is important. - flip phillips www.skidmore.edu/~flip ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear Brian, I've modified the Mac installation instructions again to add back the check for a prior installation of X-Windows. The instructions are at http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html. Thanks for your help, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Friday, September 20, 2013 8:37 AM To: John Fox Cc: 'r-sig-mac' Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 On 20/09/2013 12:54, John Fox wrote: Dear Brian, On Fri, 20 Sep 2013 07:49:05 +0100 Prof Brian Ripley rip...@stats.ox.ac.uk wrote: On 20/09/2013 01:52, John Fox wrote: Dear Sarah, -Original Message- From: Sarah Hardy [mailto:sarah.ha...@maine.edu] Sent: Thursday, September 19, 2013 8:08 PM To: John Fox Cc: Simon Urbanek; David Winsemius; r-sig-mac Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Running the Software Update and reinstalling R and Rcmdr worked for the student with the 10.7.2. We did not reinstall XQuartz. Now I will I'm glad that this worked. Apparently, the student had an old version of X-Windows that was updated by Software Update. As Simon explained, in this situation installing XQuartz is irrelevant because the other version of X-Windows is invoked by R. see if it works for the others. BTW - I have identified at least one student with a 10.6.8 who had no problems installing R and Rcmdr without installing XQuartz (per my instructions) - am going to check with other students tomorrow. If the student installed a sufficiently up-to-date X-Windows, that should work, and apparently did. The X-Windows used needn't be XQuartz. My new instructions suggest that everyone install XQuartz because that will give them an up-to-date X-Windows if they don't already have X-windows installed, and will do no harm if they do have another X-Windows. I am not so sure about that. It will do no harm running CRAN binary R. But it does mean that there are multiple versions of X11 things about and that will cause problems for other things (including possibly installing packages from source). Thanks for pointing out this potential problem. Oh well -- I hoped to have a simple set of instructions, and having everyone install XQuartz followed what I took to be Simon's suggestion (below). Almost all of the problems people have with the Rcmdr package are on the Mac OS X platform, and since most of these people are not sophisticated in their computer use, having simple instructions is important. How about the following? (1) Run System Update. (2) Check whether X-Windows is installed. (I can restore my previous instructions about how to check.) (3) If X-Windows isn't installed, install XQuartz. I think so. And I have no problem with installing XQuartz on 10.6 or 10.7 if Apple X11 is not installed. Our experience on Solaris (which itself comes with two X11 setups) shows how easily it is to get them mixed and how hard it can be to disentangle. etc. Best, John . . . -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Thursday, September 19, 2013 11:49 AM To: John Fox Cc: 'David Winsemius'; 'Sarah Hardy'; 'r-sig-mac' Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Well, the I think it reads far more complicated that in needs to be. You should have a quickstart section that just says: * Install R 3.0.1 or later * Install XQuartz from http://xquartz.macosforge.org Done. Current R only supports 10.6.8+ and so does XQuartz so the above covers everything that is supported right now (I recall having that discussion earlier...). Then you can have troubleshooting section which says a) make sure you installed R with Tcl/Tk (it is the default) - if in doubt, re-install R from CRAN b) use Software Update Then you can have a technical section with the details you show below, but 99% of users should not need to read it. Cheers, Simon . . . -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear Simon, Thank you very much for these clarifications (and also for responding to David and Sarah's posts in this thread). I think that I understand what's going on now, and will add a note to the Rcmdr installation instructions to run Software Update prior to installing R, the Rcmdr, and (if necessary) XQuartz. (Sarah: You could try asking your student(s) to run Software Update, and then reinstall R and the Rcmdr package. If you do this, can you report to the list whether it works?) I do have one further question: I understand now that R will use an older X-11 in preference to XQuartz if XQuartz doesn't install a symbolic link to /usr/X11. Is there a reason for this? That is, why not have R use XQuartz in preference to another X-11 if XQuartz is installed -- or to pick the newest X-server, if it's possible to ascertain that? Thanks again for your help, John -Original Message- From: Simon Urbanek [mailto:urba...@research.att.com] Sent: Thursday, September 19, 2013 9:25 AM To: John Fox Cc: David Winsemius; Sarah Hardy; r-sig-mac Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 On Sep 19, 2013, at 9:05 AM, John Fox wrote: Dear David, On Thu, 19 Sep 2013 01:04:18 -0700 David Winsemius dwinsem...@comcast.net wrote: On Sep 18, 2013, at 8:47 PM, John Fox wrote: . . . It also seems apparent from the error message that there's a mismatch between the version of Tcl/Tk, presumably the one supplied with the R distribution, and the version of X-Windows. That is not what I am reading. libfreetype.6 version 13 is the reported problem with a need to update to version 14. Do you know where libfreetype.6 comes from? Is it installed independently of Tcl/Tk and XQuartz? If so, do you know how to update it? . . . I'm not really a student but maybe this will be useful anyway. There is a version of Tk at: http://r.research.att.com/src/tk8.6.0-src.tar.gz ... which appears to be the most up-to-date version. I'm actually running version 8.5 with OSX 10.7.5 Version 8.6-0 of Tcl/Tk for X-Windows is included in the R 3.0.1 installer for Mac OS X. Is it possible that it doesn't get installed if there's already a Tcl/Tk for X-Windows installed? . . . The error message below says that libfreetype.6 is an old version and that you need version 14.0 for libtk8.6 From Unix cmd line: otool -L /opt/local/lib/libfreetype.6.dylib # reports ___ /opt/local/lib/libfreetype.6.dylib: /opt/local/lib/libfreetype.6.dylib (compatibility version 16.0.0, current version 16.0.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7) /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) So tcltk and the Rcmdr 2.0-0 work on your system because you have a sufficiently up-to-date libfreetype.6. It would be additionally helpful to be able to answer the following questions: (1) Why is it that some users have old versions of libfreetype.6. guess: they don't use Software Update and thus have outdated system libraries (2) Why doesn't installing the newest versions of R (which includes Tcl/Tk) and XQuartz, not solve this problem? guess: they are running an older version or didn't install R properly from the CRAN package (3) What can users experiencing this problem do to fix it? Run Software Update for (1) , re-install R for (2)? We have only 3rd hand report here so we're reduced to guessing so far. As I said, one important thing is that we uses system X11 and not XQuartz so installing XQuartz has no effect if there is a system X11 installed. However, on an up-todate system there should be no problems. Cheers, S If I knew the answers to these questions, I could update the Rcmdr installation notes to help users avoid the problem. Thank you for your help, John ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear Simon, OK -- thanks for the further clarification. If you can bear with me a bit longer, I've drafted an update to the Rcmdr installation notes, the relevant part of which now reads as follows -- [link] represents a hyperlink: -- snip --- . . . These instructions are for R version 3.0.0 or later; if you're using an earlier version of R, I suggest that you upgrade, or, failing that, consult the special Mac OS X installation notes [link] for the R Commander under older versions of R. Before installing R or the R Commander, make sure that your Mac OS X system is up-to-date by running Software Update from the apple menu at the top-left of the screen. This is important, because R assumes that the system is up-to-date and may not function properly if it is not. The procedure for installing the R Commander under Mac OS X is a bit complicated, so please read and follow these instructions carefully. These instructions and the associated files are intended for 10.6 (Snow Leopard), 10.7 (Lion), and 10.8 (Mountain Lion) systems. I assume that you've already installed R, version 3.0.0 or later. O Check to see if the X11 windowing system (X Windows) has already been installed on your computer. For OS X 10.6 and 10.7, the file X11.app should appear in the Utilities folder under Applications in the finder. This application should always be installed under OS X 10.7. For OS X 10.8, the file is named XQuartz.app and is no longer included with the operating system. O If X11.app is missing under OS X 10.6 or 10.7, you can (preferably) download and install XQuartz from http://xquartz.macosforge.org [link], following the directions for OS X 10.8 below, or you can install X11.app from your Mac OS X installation disc as follows: - Insert your Mac OS X install disc. (If you have two discs it will be on theInstall Disc 1). - Double click on Optional Installs. - Double click on Optional Installs.mpkg, then click Continue and accept the license agreement. - Click the triangle next to Applications in order to expand the list of applications. - Check X11, and then click Continue and Install. Click Close when the installation finishes. - If you install X11 from your Mac OS X discs rather than XQuartz, then run Software Update afterwards to make sure that your X11 system is up-to-date. Under OS X 10.8 (Mountain Lion), when you first try to use X11 -- for example, by installing and then loading the Rcmdr package in R (see the bullets below) -- OS X will offer to help you install X11, with a message like To open 'R,' you need to install X11. Would you like to install X11 now? O Click the continue button, which will take you to the Apple support website, and thence to http://xquartz.macosforge.org [link], where you can download the disk image (dmg) file for XQuartz. O When you open this file by double-clicking on it, you'll find XQuartz.pkg; double-click on it to run the installer, clicking through all the defaults. O After the installer runs, you'll have to log out and back on to your Mac OS X account. . . . -- snip --- Does that seem to cover the bases? Remember that many of the people using these instructions will be even more ignorant than I am about Mac OS X. Thanks for your help, John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Thursday, September 19, 2013 11:16 AM To: John Fox Cc: 'David Winsemius'; 'Sarah Hardy'; 'r-sig-mac' Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 John, On Sep 19, 2013, at 10:29 AM, John Fox wrote: Dear Simon, Thank you very much for these clarifications (and also for responding to David and Sarah's posts in this thread). I think that I understand what's going on now, and will add a note to the Rcmdr installation instructions to run Software Update prior to installing R, the Rcmdr, and (if necessary) XQuartz. (Sarah: You could try asking your student(s) to run Software Update, and then reinstall R and the Rcmdr package. If you do this, can you report to the list whether it works?) I do have one further question: I understand now that R will use an older X-11 in preference to XQuartz if XQuartz doesn't install a symbolic link to /usr/X11. Is there a reason for this? That is, why not have R use XQuartz in preference to another X-11 if XQuartz is installed -- or to pick the newest X-server, if it's possible to ascertain that? It's not. This is not about preferences - R has no choice, it has to links against something and we picked something that's more likely to exist. You cannot pick and choose at run time since the libraries (with paths) are linked in. Note that this is *not* about the X11 that the user will be running - this is just for internal libraries use by R - these are two entirely separate things (server vs client). Also
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear Simon, That's a good suggestion. In fact, I don't see a real function for the technical details, so I've just eliminated them. I also think that adding the step to run Software Update is harmless and a good idea, so I've added that. The full set of instructions (including the parts that I omitted earlier) now reads: - snip - These instructions are for R version 3.0.1 or later; if you're using an earlier version of R, I suggest that you upgrade, or, failing that, consult the special Mac OS X installation notes for the R Commander under older versions of R. R 3.0.1 only supports Mac OS X version 10.6.8 (Snow Leopard) or greater. O Before installing R and the R Commander, make sure that your Mac OS X system is up-to-date by running Software Update from the apple menu at the top-left of the screen. This is important, because R assumes that the system is up-to-date and may not function properly if it is not. O Install R 3.0.1 or later from the Comprehensive R Archive Network (CRAN), selecting a mirror site near you; a list of CRAN mirrors appears at the upper left of the CRAN home page. O Install XQuartz from http://xquartz.macosforge.org. (The R Commander uses the tcltk package for R, which requires X-Windows. Your Mac may already have X-Windows installed, but it should not hurt in any event to install XQuartz.) O Start R by running R.app. At the R command prompt, type the following command and press the return key (to avoid errors, you can copy the command from this document and paste it at the R command prompt): install.packages(Rcmdr) R will ask you to select a CRAN mirror; pick a mirror site near you. O Once it is installed, to load the Rcmdr package, simply issue the command library(Rcmdr) at the R command prompt and press return. When you first load the Rcmdr package, it will offer to download and install missing dependencies; allow it to do so. - snip - There's no need to respond again if you think these instructions are OK. Thanks again, John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Thursday, September 19, 2013 11:49 AM To: John Fox Cc: 'David Winsemius'; 'Sarah Hardy'; 'r-sig-mac' Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Well, the I think it reads far more complicated that in needs to be. You should have a quickstart section that just says: * Install R 3.0.1 or later * Install XQuartz from http://xquartz.macosforge.org Done. Current R only supports 10.6.8+ and so does XQuartz so the above covers everything that is supported right now (I recall having that discussion earlier...). Then you can have troubleshooting section which says a) make sure you installed R with Tcl/Tk (it is the default) - if in doubt, re-install R from CRAN b) use Software Update Then you can have a technical section with the details you show below, but 99% of users should not need to read it. Cheers, Simon On Sep 19, 2013, at 11:36 AM, John Fox wrote: Dear Simon, OK -- thanks for the further clarification. If you can bear with me a bit longer, I've drafted an update to the Rcmdr installation notes, the relevant part of which now reads as follows - - [link] represents a hyperlink: -- snip --- . . . These instructions are for R version 3.0.0 or later; if you're using an earlier version of R, I suggest that you upgrade, or, failing that, consult the special Mac OS X installation notes [link] for the R Commander under older versions of R. Before installing R or the R Commander, make sure that your Mac OS X system is up-to-date by running Software Update from the apple menu at the top-left of the screen. This is important, because R assumes that the system is up-to-date and may not function properly if it is not. The procedure for installing the R Commander under Mac OS X is a bit complicated, so please read and follow these instructions carefully. These instructions and the associated files are intended for 10.6 (Snow Leopard), 10.7 (Lion), and 10.8 (Mountain Lion) systems. I assume that you've already installed R, version 3.0.0 or later. O Check to see if the X11 windowing system (X Windows) has already been installed on your computer. For OS X 10.6 and 10.7, the file X11.app should appear in the Utilities folder under Applications in the finder. This application should always be installed under OS X 10.7. For OS X 10.8, the file is named XQuartz.app and is no longer included with the operating system. O If X11.app is missing under OS X 10.6 or 10.7, you can (preferably) download and install XQuartz from http://xquartz.macosforge.org [link], following the directions for OS X 10.8 below, or you can install X11.app from your Mac OS X installation disc as follows: - Insert your
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear Sarah, -Original Message- From: Sarah Hardy [mailto:sarah.ha...@maine.edu] Sent: Thursday, September 19, 2013 8:08 PM To: John Fox Cc: Simon Urbanek; David Winsemius; r-sig-mac Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Running the Software Update and reinstalling R and Rcmdr worked for the student with the 10.7.2. We did not reinstall XQuartz. Now I will I'm glad that this worked. Apparently, the student had an old version of X-Windows that was updated by Software Update. As Simon explained, in this situation installing XQuartz is irrelevant because the other version of X-Windows is invoked by R. see if it works for the others. BTW - I have identified at least one student with a 10.6.8 who had no problems installing R and Rcmdr without installing XQuartz (per my instructions) - am going to check with other students tomorrow. If the student installed a sufficiently up-to-date X-Windows, that should work, and apparently did. The X-Windows used needn't be XQuartz. My new instructions suggest that everyone install XQuartz because that will give them an up-to-date X-Windows if they don't already have X-windows installed, and will do no harm if they do have another X-Windows. Best, John Best, Sarah On Thu, Sep 19, 2013 at 3:17 PM, John Fox j...@mcmaster.ca wrote: Dear Simon, That's a good suggestion. In fact, I don't see a real function for the technical details, so I've just eliminated them. I also think that adding the step to run Software Update is harmless and a good idea, so I've added that. The full set of instructions (including the parts that I omitted earlier) now reads: - snip - These instructions are for R version 3.0.1 or later; if you're using an earlier version of R, I suggest that you upgrade, or, failing that, consult the special Mac OS X installation notes for the R Commander under older versions of R. R 3.0.1 only supports Mac OS X version 10.6.8 (Snow Leopard) or greater. O Before installing R and the R Commander, make sure that your Mac OS X system is up-to-date by running Software Update from the apple menu at the top-left of the screen. This is important, because R assumes that the system is up-to-date and may not function properly if it is not. O Install R 3.0.1 or later from the Comprehensive R Archive Network (CRAN), selecting a mirror site near you; a list of CRAN mirrors appears at the upper left of the CRAN home page. O Install XQuartz from http://xquartz.macosforge.org. (The R Commander uses the tcltk package for R, which requires X-Windows. Your Mac may already have X-Windows installed, but it should not hurt in any event to install XQuartz.) O Start R by running R.app. At the R command prompt, type the following command and press the return key (to avoid errors, you can copy the command from this document and paste it at the R command prompt): install.packages(Rcmdr) R will ask you to select a CRAN mirror; pick a mirror site near you. O Once it is installed, to load the Rcmdr package, simply issue the command library(Rcmdr) at the R command prompt and press return. When you first load the Rcmdr package, it will offer to download and install missing dependencies; allow it to do so. - snip - There's no need to respond again if you think these instructions are OK. Thanks again, John -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: Thursday, September 19, 2013 11:49 AM To: John Fox Cc: 'David Winsemius'; 'Sarah Hardy'; 'r-sig-mac' Subject: Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8 Well, the I think it reads far more complicated that in needs to be. You should have a quickstart section that just says: * Install R 3.0.1 or later * Install XQuartz from http://xquartz.macosforge.org Done. Current R only supports 10.6.8+ and so does XQuartz so the above covers everything that is supported right now (I recall having that discussion earlier...). Then you can have troubleshooting section which says a) make sure you installed R with Tcl/Tk (it is the default) - if in doubt, re-install R from CRAN b) use Software Update Then you can have a technical section with the details you show below, but 99% of users should not need to read it. Cheers, Simon On Sep 19
Re: [R-SIG-Mac] Problems loading Rcmdr on a Mac 10.7.2 and a Mac 10.6.8
Dear Sarah, It seems likely from the message that you reported that the problem isn't directly related to the Rcmdr package, but rather to the tcltk package on which the Rcmdr depends. Your student (and the other students who are experiencing problems) can verify this by trying to load the tcltk package directly, via library(tcltk), to see whether he gets the same error. It also seems apparent from the error message that there's a mismatch between the version of Tcl/Tk, presumably the one supplied with the R distribution, and the version of X-Windows. I'm not sure why that happened, and there was a previous message about a similar problem on the list. I suggested that the user install the current version of X-Quartz, but you student apparently already has done that. Is it possible that there's an old version of X-Windows on the student's computer? I assume that your students have been following the Rcmdr installation instructions for Mac OS X at http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html. Have any of them been successful? Are all the problems identical? You mentioned that another student installed a version of Tcl/Tk independently of R. I suppose that this could cause problems if the wrong Tcl/Tk is invoked. I too am teaching with the Rcmdr this Fall, and about half the students in my (small) class have Macs. None have experienced problems with the tcltk package or version 2.0-1 of the Rcmdr under R 3.0.1. Nor have I on my Mac, running OS X 10.8.5 and XQuartz 2.7.4 Like you, I'm not terribly knowledgeable about Mac OS X. I expect that someone else on the list will be able to offer better help, and I've taken the liberty of copying this response to Simon Urbanek. I'm sorry that you're experiencing this problem. John On Wed, 18 Sep 2013 21:46:00 -0400 Sarah Hardy sarah.ha...@maine.edu wrote: I myself am not a Mac user, but I have about 6 students with Macs all having the same (or similar) problem loading Rcmdr 2.0.1 on their Mac (but have successfully installed R 3.0.1). One student has a Mac 10.7.2. I know he installed XQuartz-2.7.4.dmg and then completely logged out and back in. Before he did that he ran the Repair Disk Permissions in Disk Utility. Afterwards I checked Verify Disk Permissions and I didn't see any warnings. When installing Rcmdr there are no unusual messages. The message he gets in R when attempting to load Rcmdr is: R version 3.0.1 (2013-05-16) -- Good Sport Copyright (C) 2013 The R Foundation for Statistical Computing Platform: x86_64-apple-darwin10.8.0 (64-bit) ... library(Rcmdr) Loading required package: splines Error : .onLoad failed in loadNamespace() for 'tcltk', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared object '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/tcltk/libs/tcltk.so': dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/tcltk/libs/tcltk.so, 10): Library not loaded: /usr/X11/lib/libfreetype.6.dylib Referenced from: /usr/local/lib/libtk8.6.dylib Reason: Incompatible library version: libtk8.6.dylib requires version 14.0.0 or later, but libfreetype.6.dylib provides version 13.0.0 Error: package or namespace load failed for Rcmdr I'm not sure if this provides any clues, but I also ran this system function: . system(ls -ld /usr/local /usr/local/lib /usr/local/lib/libtcl*) drwxr-xr-x 7 root wheel 238 Mar 29 20:36 /usr/local drwxr-xr-x 27 root wheel 918 Sep 17 16:55 /usr/local/lib -r-xr-xr-x 1 root wheel 4820229 Oct 21 2008 /usr/local/lib/libtcl8.5.dylib -r-xr-xr-x 1 root wheel 1419604 Mar 29 20:35/usr/local/lib/libtcl8.6.dylib -rw-r--r-- 1 root wheel11072 Oct 21 2008 /usr/local/lib/libtclstub8.5.a -rwxr-xr-x 1 root wheel 4824 Mar 29 20:35/usr/local/lib/libtclstub8.6.a Another student with identical messages has a Mac 10.6.8. I think she installed tcltk-8.5.5-x11.dmg. Any tips or suggestions on how to proceed would be greatly appreciated. Thank you, Sarah Hardy -- Sarah Hardy, PhD Associate Professor of Mathematics University of Maine Farmington 207-778-7124Office: Brinkman 100 [[alternative HTML version deleted]] John Fox McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Can't load on Rcmdr
Dear Josh, -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Josh Lipkowitz Sent: Thursday, August 29, 2013 5:47 PM To: r-sig-mac@r-project.org Subject: [R-SIG-Mac] Can't load on Rcmdr Hi, I am trying to load the Rcmdr package. I am running a Mac, OS 10.6.8. Below is the error message I get. Any ideas? Yes, please read the Rcmdr installation notes for Mac users at http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html, paying particular attention to the instructions for Mac OS X 10.6. I hope this helps, John library(Rcmdr) Error : .onLoad failed in loadNamespace() for 'tcltk', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared object '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/tcltk/l ibs/tcltk.so': dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/t cltk/libs/tcltk.so, 10): Library not loaded: /usr/X11/lib/libfreetype.6.dylib Referenced from: /usr/local/lib/libtk8.6.dylib Reason: Incompatible library version: libtk8.6.dylib requires version 14.0.0 or later, but libfreetype.6.dylib provides version 13.0.0 Error: package or namespace load failed for Rcmdr Thanks, Josh [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Error with library(tcltk) on R-devel
Dear Dan, You also have to install X11 and Tcl/Tk for X-Windows. The R Commander installation notes at http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html have detailed instructions for various versions of Mac OS X. (You can disregard the part about installing the Rcmdr package if you're not interested in that.) I hope this helps, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Dan Tenenbaum Sent: Friday, March 08, 2013 6:15 PM To: r-sig-mac@r-project.org Subject: [R-SIG-Mac] Error with library(tcltk) on R-devel On a vanilla Snow Leopard machine with nothing but XCode installed, I installed R-devel and then got this when trying to load the tcltk package: library(tcltk) Error : .onLoad failed in loadNamespace() for 'tcltk', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared object '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/tcltk/l ibs/x86_64/tcltk.so': dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/t cltk/libs/x86_64/tcltk.so, 10): Library not loaded: /usr/local/lib/libtcl8.5.dylib Referenced from: /Library/Frameworks/R.framework/Versions/3.0/Resources/library/tcltk/li bs/x86_64/tcltk.so Reason: image not found Error: package or namespace load failed for 'tcltk' sessionInfo() R Under development (unstable) (2013-03-03 r62117) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] C attached base packages: [1] stats graphics grDevices utils datasets methods base FWIW, there is no /usr/local directory on this machine. Dan [[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] Ugly default Tk font on Mac OS
Dear David,
-Original Message-
From: David Winsemius [mailto:dwinsem...@comcast.net]
Sent: Monday, October 08, 2012 1:54 PM
To: John Fox
Cc: 'Milan Bouchet-Valat'; 'r-sig-mac'
Subject: Re: [R-SIG-Mac] Ugly default Tk font on Mac OS
On Oct 8, 2012, at 10:26 AM, John Fox wrote:
Dear all,
Milan and I have now corresponded about this issue privately, and it
appears that there's a difference in the font used under his Mac OS X
system (running Snow Leopard) and mine (running Mountain Lion). I
currently get the font
tkfont.actual(RcmdrDefaultFont)
Tcl -family {Bitstream Vera Sans} -size 10 -weight normal -slant
roman -underline 0 -overstrike 0
which (to my eye) is substantially more attractive than what I get
when I hard-code Helvetica:
Tcl -family Helvetica -size 10 -weight normal -slant roman -
underline 0 -overstrike 0
I don't know what the source of the difference is -- a different X-
windows is used for Snow Leopard and Mountain Lion, and Milan and I are
in different language locales.
Of course, if there's a way to correct this problem, I'm happy to
implement it.
Just as a point of reference. With a recently installed update to Snow
Leopard (yes, I'm way behind that adoption curve) and Rcmdr version
1.8.4 ( I'm not a user and I see this is out-of-date) , I get:
tkfont.actual(RcmdrDefaultFont)
Tcl -family {Bitstream Vera Sans} -size 12 -weight normal -slant roman
-underline 0 -overstrike 0
Thanks for this -- it's helpful, though (as you note), the current CRAN
version of the Rcmdr is 1.9-1. The development version, 1.9-2 on R-Forge,
has a number of cosmetic improvements, but not a change to font-handling.
Best,
John
Best,
John
-Original Message-
From: Milan Bouchet-Valat [mailto:nalimi...@club.fr]
Sent: Monday, October 08, 2012 4:15 AM
To: r-sig-mac
Cc: John Fox
Subject: Ugly default Tk font on Mac OS
Hi!
On Mac OS, since John Fox has removed the code that forced the
default
font to be Helvetica (which is a good idea), Rcommander looks
terribly
ugly (try by yourself ;-). I've reports of this on at least two
machines, under Snow Leopard.
I've played a bit with fonts on such machines, and I discovered that
the
problem is not particular to Rcmdr at all, but that it affects all
named
fonts that are created manually.
Rcommander uses a font created that way:
.Tcl(font create RcmdrDefaultFont -size X) # with X a given value
On Mac OS, this command creates a font whose family name is fixed,
according to tkfont.actual(), and it is somewhat translated to an
ugly
font. This is weird, because all default Tk fonts, like
TkDefaultFont,
TkTextFont, TkMenuFont... all use helvetica as font family, which
is a
reasonable default (and not a fixed font). What might be happening on
Macs is that system fonts like systemSystemFont,
systemApplicationFont and friends are _not_ defined correctly, i.e.
they also use fixed as font family. So maybe newly created named
fonts
inherits from them.
On Linux (and most likely on Windows), the default font family is
correct when creating a named font.
Here's a minimal example that reproduces the issue:
library(tcltk)
.Tcl(font create test)
tkfont.actual(test) # Wrong
tkfont.actual(TkDefaultFont) # OK
tkfont.actual(systemSystemFont) # Wrong
etc.
Regards
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
David Winsemius, MD
Alameda, CA, USA
___
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] problem with the installation of r commander on a mac
Dear Marco, To provide some background, you and I have corresponded about your problem, and now at least you appear to have the tcltk package installed. Did you reinstall R as I suggested? Have you checked that tcltk is working, following the instructions I sent you in an earlier email? I don't believe that the Rcmdr ever calls tk_messageBox directly, but there is a tk_messageBox() function in tcltk, and you can check whether this is the source (or a symptom) of the problem by issuing the following commands in a fresh R session: library(tcltk) tk_messageBox(message=test) That should, as the function name suggests, bring up a Tk message box. Also I'm not sure what's going on with 'couldn't connect to display :0', which suggests an X-Windows issue. Finally, I'm moving this discussion to r-sig-mac, where you're more likely to get knowledgeable assistance. Best, John --- John Fox Senator McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada -Original Message- From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On Behalf Of Marco Mello Sent: Thursday, October 04, 2012 12:57 PM To: r-h...@r-project.org Subject: [R] problem with the installation of r commander on a mac Dear list members, Im trying to install R Commander under Mac OSX Mountain Lion (10.8.2). After following all the steps described in the installation notes (http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation- notes.html), I got this error message: = Loading required package: tcltk Loading Tcl/Tk interface ... done Loading required package: car Loading required package: MASS Loading required package: nnet Error : .onLoad failed in loadNamespace() for 'Rcmdr', details: call: structure(.External(dotTclObjv, objv, PACKAGE = tcltk), class = tclObj) error: [tcl] invalid command name tk_messageBox. In addition: Warning message: In fun(libname, pkgname) : couldn't connect to display :0 Error: package/namespace load failed for Rcmdr = The strange thing is that Ive installed Tcl/Tk and XQuark as recommended. Ive also tried uninstalling R, reinstalling the latest version (2.15.1 signed) and all packages, and following the same official steps again. It didnt work neither. Could you please help me? R Commander always worked fine on my iMac, until I updated to Mountain Lion. Best regards, Marco Prof. Dr. Marco A. R. Mello Universidade Federal de Minas Gerais ICB - Depto. Biologia Geral http://marcomello.casadosmorcegos.org marme...@gmail.com [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [R] problem with the installation of r commander on a mac
Dear Simon, Marco says that he installed XQuark (see his original message), which I translate as XQuartz. Marco, can you run XQuartz.app (in Utilities on my Mac), which should open an Xterm window? Best, John -Original Message- From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On Behalf Of Simon Urbanek Sent: Thursday, October 04, 2012 5:47 PM To: John Fox Cc: 'Marco Mello'; r-h...@r-project.org; r-sig-mac@r-project.org Subject: Re: [R] [R-SIG-Mac] problem with the installation of r commander on a mac In fun(libname, pkgname) : couldn't connect to display :0 suggests that X11 is not running. Note that X11 is no longer part of OS X since Mountain Lion. Cheers, Simon On Oct 4, 2012, at 4:32 PM, John Fox wrote: Dear Marco, To provide some background, you and I have corresponded about your problem, and now at least you appear to have the tcltk package installed. Did you reinstall R as I suggested? Have you checked that tcltk is working, following the instructions I sent you in an earlier email? I don't believe that the Rcmdr ever calls tk_messageBox directly, but there is a tk_messageBox() function in tcltk, and you can check whether this is the source (or a symptom) of the problem by issuing the following commands in a fresh R session: library(tcltk) tk_messageBox(message=test) That should, as the function name suggests, bring up a Tk message box. Also I'm not sure what's going on with 'couldn't connect to display :0', which suggests an X-Windows issue. Finally, I'm moving this discussion to r-sig-mac, where you're more likely to get knowledgeable assistance. Best, John --- John Fox Senator McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada -Original Message- From: r-help-boun...@r-project.org [mailto:r-help-bounces@r- project.org] On Behalf Of Marco Mello Sent: Thursday, October 04, 2012 12:57 PM To: r-h...@r-project.org Subject: [R] problem with the installation of r commander on a mac Dear list members, Im trying to install R Commander under Mac OSX Mountain Lion (10.8.2). After following all the steps described in the installation notes (http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation- notes.html), I got this error message: = Loading required package: tcltk Loading Tcl/Tk interface ... done Loading required package: car Loading required package: MASS Loading required package: nnet Error : .onLoad failed in loadNamespace() for 'Rcmdr', details: call: structure(.External(dotTclObjv, objv, PACKAGE = tcltk), class = tclObj) error: [tcl] invalid command name tk_messageBox. In addition: Warning message: In fun(libname, pkgname) : couldn't connect to display :0 Error: package/namespace load failed for Rcmdr = The strange thing is that Ive installed Tcl/Tk and XQuark as recommended. Ive also tried uninstalling R, reinstalling the latest version (2.15.1 signed) and all packages, and following the same official steps again. It didnt work neither. Could you please help me? R Commander always worked fine on my iMac, until I updated to Mountain Lion. Best regards, Marco Prof. Dr. Marco A. R. Mello Universidade Federal de Minas Gerais ICB - Depto. Biologia Geral http://marcomello.casadosmorcegos.org marme...@gmail.com [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting- guide.html and provide commented, minimal, self-contained, reproducible code. ___ 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 Tcl/Tk 8.5.5 for X11 on Mountain Lion
Dear John, -Original Message- From: John Maindonald [mailto:john.maindon...@anu.edu.au] Sent: Sunday, September 30, 2012 6:36 PM To: John Fox Cc: 'Simon Urbanek'; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] installing Tcl/Tk 8.5.5 for X11 on Mountain Lion All that is needed is to do a right click (or its equivalent), where for approved software a left click works the needed magic. The user is then asked whether, notwithstanding the lack of an Apple imprimatur, they wish to proceed. A note to this effect might accompany any software that is to be downloaded. Most Mountain Lion users will rather quickly latch onto this. I'm an occasional Mac user and I didn't know that right-click - Open works. My response was to find the security option and permanently select allow applications downloaded from anywhere. The user who contacted me didn't get that far. Mountain Lion has been out for a while and only one person has complained, so you're probably right, though I'm not sure why it's better for people to have to discover the right-click trick than to tell them. I don't think that it will hurt to add a remark to the Rcmdr Mac installation instructions, so I'll do that. Best, John John Maindonald email: john.maindon...@anu.edu.au phone : +61 2 (6125)3473fax : +61 2(6125)5549 Centre for Mathematics Its Applications, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200. http://www.maths.anu.edu.au/~johnm On 01/10/2012, at 3:33 AM, John Fox j...@mcmaster.ca wrote: Dear Simon, I received an email recently from a user trying to install the Rcmdr package under OS X 10.8 (Mountain Lion). It materialized that he was unable to install Tcl/Tk 8.5.5 from the R for Mac OS X Development Tools and Libraries page because his security settings didn't permit installation of software from unidentified developers. The problem was solved by resetting this option temporarily. I notice that the R Mac OS X binary itself is now signed to circumvent the problem, and wonder whether the same thing can be done for the Tcl/Tk that's provided -- or if not whether instructions for proceeding in Mountain Lion can be added to the web page. Depending on how the issue is resolved, I may add an instruction to the Rcmdr Mac installation notes. Thanks, John --- John Fox Senator McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada ___ 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] installing Tcl/Tk 8.5.5 for X11 on Mountain Lion
Dear Simon, I received an email recently from a user trying to install the Rcmdr package under OS X 10.8 (Mountain Lion). It materialized that he was unable to install Tcl/Tk 8.5.5 from the R for Mac OS X Development Tools and Libraries page because his security settings didn't permit installation of software from unidentified developers. The problem was solved by resetting this option temporarily. I notice that the R Mac OS X binary itself is now signed to circumvent the problem, and wonder whether the same thing can be done for the Tcl/Tk that's provided -- or if not whether instructions for proceeding in Mountain Lion can be added to the web page. Depending on how the issue is resolved, I may add an instruction to the Rcmdr Mac installation notes. Thanks, John --- John Fox Senator McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Rcmdr 1.8.3 on Lion with R 2.15 shutting down when trying import data
Dear Graham, As I just verified, Data - Import data - From text file, clipboard, or URL works fine for me, with R 2.15.0 and Rcmdr 1.8-3 (the version currently on CRAN) under Mac OS X Lion. I'm not sure what to suggest. Can you provide some more details? Best, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Graham Smith Sent: April-11-12 11:51 AM To: r-sig-mac@r-project.org Subject: [R-SIG-Mac] Rcmdr 1.8.3 on Lion with R 2.15 shutting down when trying import data I have just updated to R 2.15 on Lion but now when trying to import data using Rcmdr 1.8.3, both Rcmdr and R shut down. I can get to Open dialog box, but when I double click on a directory to open it, Rcmdr and R shut down. Selecting the directory and clicking on the Open button does nothing, not sure if it has ever done anything as I normally double click. It was working before upgrade and I can open data using the Data in packages menu. I have the same problem with both the Macs I have upgraded to 2.15, but a search hasn't found anyone else with the same problem. Has anyone any idea what might be wrong. Many thanks, Graham [[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] Rcmdr 1.8.3 on Lion with R 2.15 shutting down when trying import data
Dear Graham, I'm glad that you've gotten a bit further diagnosing the problem. I'm not sure why the problem would afflict only the Rcmdr but one guess is that it's Tcl/Tk related. Anyway, a work-around is to move the data to another location. Best, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Graham Smith Sent: April-11-12 12:58 PM To: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Rcmdr 1.8.3 on Lion with R 2.15 shutting down when trying import data Simon, Dropbox is typically write-only (i.e. you can't list it), so maybe check the permissions? As far as I can see permissions are OK, but not sure why this would only affect Rcmdr ? There is no problem using R, or Rstudio, excel etc its just Rcmdr that is having a problem, and only since the update to 2.15. Thanks, Graham [[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] Visualizing coefficients
Hi Jarrett, Take a look at the effects package, in particular ?effect, which includes methods for mer and lme objects. (I'm not sure why you'd post this to the r-sig-mac list.) Best, John John Fox Sen. William McMaster Prof. of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ On Thu, 26 Jan 2012 10:52:52 -0500 Jarrett Byrnes byr...@nceas.ucsb.edu wrote: Before I re-invent a well built wheel, has anyone on this list put together a good set of functions for visualizing net effects and the variation in the estimates for a fitter lmer or glmer model? I realize that this can be done to some extent via simulation and then putting the results into coda or R2WinBUGS, but, has anyone gone about it via a different route? I'm also curious to track down other resources for visualizing the results of fitted mer objects. -Jarrett Jarrett Byrnes Postdoctoral Fellow National Center for Ecological Analysis and Synthesis 735 State Street, Suite 300 Santa Barbara, CA 93101 http://jarrettbyrnes.info [[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] Rcmdr 1.7.2 on Mac
Dear Kristian, Odd as it seems, I think that the problem is with the CRAN build of the Rcmdr package. When I tried installing the Rcmdr package version 1.7-2 on my own Mac (OS X Lion, R 2.14.0) from CRAN via install.packages(Rcmdr) I got the same error as your students, but when I installed from CRAN sources, install.packages(Rcmdr, type=source), the package worked just fine. (There is one .c file in the Rcmdr sources.) I'm not sure what's going on and thus have copied this response to the R Mac email list for comments. Best, John John Fox Senator William McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox -Original Message- From: Kristian Hovde Liland [mailto:kristian.lil...@umb.no] Sent: November-10-11 4:39 PM To: 'j...@mcmaster.ca' Subject: Rcmdr 1.7.2 on Mac Dear John Fox. Thank you again for your feedback after my talk at useR! on teaching statistics to natural science students. I am getting feedback from several Mac users that are installing Rcmdr 1.7.2 on a fresh install of R 2.14.0 that the R Commander will not launch. There is an error concerning a missing file named Rcmdr.so both for 32-bit and 64-bit installations. Do you have any tips? Or do you know where I can get hold of the Mac version of Rcmdr 1.7.0 as a temporary fix? Best regards, Kristian Hovde Liland ___ 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 the Aqua Tcl/Tk theme by default on Mac OS
Dear Simon, As you know, I have an interest in Tcl/Tk as developer of the Rcmdr package. It would be nice if use of R Tcl/Tk applications could be made as convenient and aesthetically pleasing for Mac users as for Windows users. Thanks, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of Simon Urbanek Sent: September-23-11 10:10 AM To: Milan Bouchet-Valat Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] Using the Aqua Tcl/Tk theme by default on Mac OS On Sep 23, 2011, at 6:12 AM, Milan Bouchet-Valat wrote: Le vendredi 23 septembre 2011 à 10:55 +0100, Prof Brian Ripley a écrit : Why not? It's easy on Mac OS X (as easy as on Linux). As easy as on Linux means much too hard for my intended audience. :-) I'm creating a Rcmdr plugin that I'd like people to install without typing more than two lines of code, and if possible none at all. But I don't care that much about the look of the GUI, that would only be a nice improvement. You are welcome to contribute a fix. Simon will no doubt chip in with more details. I'll see what I can do, being totally ignorant of Mac OS X programming. A first step is identifying where the bug is, or where it's easier to fix (R or Tk). But let's hear what Simon says. I didn't check the most recent version of native Tk, but the design of the native Tk was that it assumes that it will be the one driving the UI - it didn't even check that it is being loaded into an existing application that has already initialized Cocoa. There were additional issues with the event loop, but more recently I think Brian had some success on that front. In a spare minute (at the earliest next week) I'll see if I an get my knowledge on that issue up to date.. 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] package-install problem on Mac OS X lion
Dear Kasper, Thanks -- that gave me the hint I needed. Although the Mac app store said that Xcode was installed, and I checked that previously since I thought it might be the problem, it turned out that the installer had only been downloaded. Completing the installation solved the problem. Thanks again, John -Original Message- From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com] Sent: September-22-11 7:07 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] package-install problem on Mac OS X lion Based on this output On Thu, Sep 22, 2011 at 6:54 PM, John Fox j...@mcmaster.ca wrote: sh: make: command not found I would hypothesize you need to (re)install the developer tools. Kasper ___ 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 checking packages with R 2.13.0
Dear Kasper, On Mon, 18 Apr 2011 22:32:35 -0400 Kasper Daniel Hansen kasperdanielhan...@gmail.com wrote: On Mon, Apr 18, 2011 at 9:49 PM, John Fox j...@mcmaster.ca wrote: Dear Brian, On Mon, 18 Apr 2011 14:34:31 +0100 (BST) Prof Brian Ripley rip...@stats.ox.ac.uk wrote: John, Having resolved the path issues, I think you do have a problem with your latex installation. Try (in the terminal) tystie% kpsewhich 8r.enc /usr/local/texlive/2010/texmf-dist/fonts/enc/dvips/base/8r.enc That is indeed empty. If that comes back empty, try (possibly with sudo) tystie% texhash to rebuild the indices. If that doesn't work, you need to work out how you have an incomplete installation, something I've never seen with Mactex. (I'm just lucky, I guess.) I tried this and it didn't fix the problem. I then reinstalled MacTeX-2010, taking all of the defaults in the installer, as I did before, and that fixed the problem. Obviously, my original TeX installation was broken. I don't think that I should have to set the PATH explicitly in my .Rprofile when I use eclipse (I've never had to before, on any platform), but that works too. I'll investigate further and maybe send a message to the StatET list. I don't set my PATH either, but it is useful for various purposes. If you use the CRAN binary of R, my guess would be that most programs know where to look. But that does depend on the program you use. Remember that the problem was that eclipse wasn't finding pdflatex when I checked R packages; eclipse had no problem finding R since defining an R environment in eclipse involves pointing to R_HOME. Anyway, as I mentioned in my previous email, Brian's suggestions led me to a solution. Best, John Kasper Thank you for all of your help -- I really appreciate it. John (FWIW 8r.enc is what tells latex how to encode output for Type 1 fonts: it is nothing to do with the encoding of the latex inputs.) Brian On Sun, 17 Apr 2011, John Fox wrote: Dear Kasper, -Original Message- From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com] Sent: April-17-11 7:27 PM To: John Fox Cc: Prof Brian Ripley; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] problem checking packages with R 2.13.0 On Sun, Apr 17, 2011 at 7:16 PM, John Fox j...@mcmaster.ca wrote: Dear Kaspar, -Original Message- From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com] Sent: April-17-11 5:59 PM To: John Fox Cc: Prof Brian Ripley; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] problem checking packages with R 2.13.0 . . . Since this is a new Mac, what file system are you using? I have no idea on how to troubleshoot your error, but I guess that info about the file system might help more knowledgeable people. I'm afraid I don't know how to answer: I didn't make any changes to the file system that came with the machine. Don't Macs use the HFS+ file system? By defualt . Or could this be e problem with the encoding of (one of) the help files in the package? I don't think so: The car package checks on my Windows 7 system, on an older Mac, and on R-Forge. Thanks again for trying to help. John Kasper On Sun, Apr 17, 2011 at 4:21 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and others, Yes, I installed the CRAN build of R, and yes, something is changing the path in R.app, and in eclipse, but not apparently when R is run in a terminal window. From a terminal window: - snip -- John-Foxs-MacBook-Pro:Rmpi jfox$ R R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin - snip -- In R.app (and in R64.app): - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: i386-apple-darwin9.8.0/i386 (32-bit) . . . [R.app GUI 1.40 (5751) i386-apple-darwin9.8.0] [History restored from /Users/jfox/.Rapp.history] Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin - snip -- And in eclipse: - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /Library/Frameworks/R.framework/Versions/2.13/Resources/bin:/usr/bin: /bin:/ usr/sbin:/sbin - snip
Re: [R-SIG-Mac] problem checking packages with R 2.13.0
Dear Brian and others, Yes, I installed the CRAN build of R, and yes, something is changing the path in R.app, and in eclipse, but not apparently when R is run in a terminal window. From a terminal window: - snip -- John-Foxs-MacBook-Pro:Rmpi jfox$ R R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin - snip -- In R.app (and in R64.app): - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: i386-apple-darwin9.8.0/i386 (32-bit) . . . [R.app GUI 1.40 (5751) i386-apple-darwin9.8.0] [History restored from /Users/jfox/.Rapp.history] Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin - snip -- And in eclipse: - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /Library/Frameworks/R.framework/Versions/2.13/Resources/bin:/usr/bin:/bin:/ usr/sbin:/sbin - snip -- I've had no luck, however, figuring out what's changing the path: As far as I can tell, I have no Rprofile.site file, no .Rprofile file, and the R_PROFILE and R_PROFILE_USER environment variables are unset. In fact the only R initialization files that I could find anywhere on my system are the Rprofile files in the base and Rmpi packages; as far as I can see, the former can't shorten the path and I'm not using the latter. Finally, looking more closely at the errors I'm getting when I try to check a package, the errors in a terminal window and from eclipse look different: From a terminal window, I think that pdflatex is actually found; to repeat the error message: - snip -- * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding file for reading == Fatal error occurred, no output PDF file produced! * checking PDF version of manual without hyperrefs or index ... ERROR - snip -- From eclipse, pdflatex clearly isn't found: - snip -- * 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 You may want to clean up by 'rm -rf /var/folders/ay/ayD+f6yQFomFC5SGQV6vPTI/-Tmp- //RtmpopONVs/Rd2pdf16f793c' Error in texi2dvi(Rd2.tex, pdf = (out_ext == pdf), quiet = FALSE, : pdflatex is not available Error in running tools::texi2dvi - snip -- So there are possibly two independent problems here. I'm not sure where to look next, so again any help would be appreciated. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: April-17-11 1:37 AM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] problem checking packages with R 2.13.0 On Sat, 16 Apr 2011, John Fox wrote: Dear list members, I'm experiencing a problem checking packages with R 2.13.0 on a new Mac OS X 10.6.7 system. As far as I can tell, R isn't finding my LaTeX installation. Packages seem to build fine. Some details follow: Assuming this is the CRAN build of R, it is looking on the path. So all I can think is that you have the path set incorrectly somewhere in your R statrtup files. Here's what happens when I try to check a package: - snip -- John-Foxs-MacBook-Pro:workspace jfox$ R CMD check car * using log directory ?/Users/jfox/Documents/workspace/car.Rcheck? * using R version 2.13.0 (2011-04-13) * using platform: x86_64-apple-darwin9.8.0 (64-bit) * using session charset: UTF-8 * checking for file ?car/DESCRIPTION? ... OK * this is package ?car? version ?2.0-10? . . . * checking examples ... OK * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding file for reading == Fatal error occurred, no output PDF file produced! * checking PDF version of manual without hyperrefs or index ... ERROR - snip -- I get the following error when I try to check the package under eclipse/StatET (deleting the lines before the error): - snip -- * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version
Re: [R-SIG-Mac] problem checking packages with R 2.13.0
Dear Kaspar, -Original Message- From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com] Sent: April-17-11 5:59 PM To: John Fox Cc: Prof Brian Ripley; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] problem checking packages with R 2.13.0 John, I don't know about Eclipse, but on a Mac it is completely standard that a GUI does not inherit anything from .bashrc/.profile. So it is pretty standard that you may have problems with environment variables. You can do two things (1) use environment.plist (google it) (2) use Sys.setenv() inside your .Rprofile That helps a bit. That is, I didn't previously have a .Rprofile file, so I put one in my home directory, setting the PATH to /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin. Now both R CMD check in a terminal window and checking inside eclipse fail with the same error, !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding file (etc.), rather than with different errors. So, at this point, I don't think that finding pdflatex is the issue. Now, regarding latex, the standard on Mac would be to run MacTex. I am unaware of how R.app deals with MacTex but I would be ready to guess that the PATH might be semi-build in (I am sure some of the R.app people will correct me on this). So you might want to add info about what tex distribution you are using. Good point. I used the MacTeX-2010 distribution, which I got to from item 2.1 in the R for Mac OS X FAQ. Thanks for trying to help. John Kasper On Sun, Apr 17, 2011 at 4:21 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and others, Yes, I installed the CRAN build of R, and yes, something is changing the path in R.app, and in eclipse, but not apparently when R is run in a terminal window. From a terminal window: - snip -- John-Foxs-MacBook-Pro:Rmpi jfox$ R R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin - snip -- In R.app (and in R64.app): - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: i386-apple-darwin9.8.0/i386 (32-bit) . . . [R.app GUI 1.40 (5751) i386-apple-darwin9.8.0] [History restored from /Users/jfox/.Rapp.history] Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin - snip -- And in eclipse: - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /Library/Frameworks/R.framework/Versions/2.13/Resources/bin:/usr/bin: /bin:/ usr/sbin:/sbin - snip -- I've had no luck, however, figuring out what's changing the path: As far as I can tell, I have no Rprofile.site file, no .Rprofile file, and the R_PROFILE and R_PROFILE_USER environment variables are unset. In fact the only R initialization files that I could find anywhere on my system are the Rprofile files in the base and Rmpi packages; as far as I can see, the former can't shorten the path and I'm not using the latter. Finally, looking more closely at the errors I'm getting when I try to check a package, the errors in a terminal window and from eclipse look different: From a terminal window, I think that pdflatex is actually found; to repeat the error message: - snip -- * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding file for reading == Fatal error occurred, no output PDF file produced! * checking PDF version of manual without hyperrefs or index ... ERROR - snip -- From eclipse, pdflatex clearly isn't found: - snip -- * 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 You may want to clean up by 'rm -rf /var/folders/ay/ayD+f6yQFomFC5SGQV6vPTI/-Tmp- //RtmpopONVs/Rd2pdf16f793c' Error in texi2dvi(Rd2.tex, pdf = (out_ext == pdf), quiet = FALSE, : pdflatex is not available Error in running tools::texi2dvi - snip -- So there are possibly two independent problems here. I'm not sure where to look next, so again
Re: [R-SIG-Mac] problem checking packages with R 2.13.0
Dear Kasper, -Original Message- From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com] Sent: April-17-11 7:27 PM To: John Fox Cc: Prof Brian Ripley; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] problem checking packages with R 2.13.0 On Sun, Apr 17, 2011 at 7:16 PM, John Fox j...@mcmaster.ca wrote: Dear Kaspar, -Original Message- From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com] Sent: April-17-11 5:59 PM To: John Fox Cc: Prof Brian Ripley; r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] problem checking packages with R 2.13.0 . . . Since this is a new Mac, what file system are you using? I have no idea on how to troubleshoot your error, but I guess that info about the file system might help more knowledgeable people. I'm afraid I don't know how to answer: I didn't make any changes to the file system that came with the machine. Don't Macs use the HFS+ file system? Or could this be e problem with the encoding of (one of) the help files in the package? I don't think so: The car package checks on my Windows 7 system, on an older Mac, and on R-Forge. Thanks again for trying to help. John Kasper On Sun, Apr 17, 2011 at 4:21 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and others, Yes, I installed the CRAN build of R, and yes, something is changing the path in R.app, and in eclipse, but not apparently when R is run in a terminal window. From a terminal window: - snip -- John-Foxs-MacBook-Pro:Rmpi jfox$ R R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin - snip -- In R.app (and in R64.app): - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: i386-apple-darwin9.8.0/i386 (32-bit) . . . [R.app GUI 1.40 (5751) i386-apple-darwin9.8.0] [History restored from /Users/jfox/.Rapp.history] Sys.getenv(PATH) [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin - snip -- And in eclipse: - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) . . . Sys.getenv(PATH) [1] /Library/Frameworks/R.framework/Versions/2.13/Resources/bin:/usr/bin: /bin:/ usr/sbin:/sbin - snip -- I've had no luck, however, figuring out what's changing the path: As far as I can tell, I have no Rprofile.site file, no .Rprofile file, and the R_PROFILE and R_PROFILE_USER environment variables are unset. In fact the only R initialization files that I could find anywhere on my system are the Rprofile files in the base and Rmpi packages; as far as I can see, the former can't shorten the path and I'm not using the latter. Finally, looking more closely at the errors I'm getting when I try to check a package, the errors in a terminal window and from eclipse look different: From a terminal window, I think that pdflatex is actually found; to repeat the error message: - snip -- * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding file for reading == Fatal error occurred, no output PDF file produced! * checking PDF version of manual without hyperrefs or index ... ERROR - snip -- From eclipse, pdflatex clearly isn't found: - snip -- * 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 You may want to clean up by 'rm -rf /var/folders/ay/ayD+f6yQFomFC5SGQV6vPTI/-Tmp- //RtmpopONVs/Rd2pdf16f793c' Error in texi2dvi(Rd2.tex, pdf = (out_ext == pdf), quiet = FALSE, : pdflatex is not available Error in running tools::texi2dvi - snip -- So there are possibly two independent problems here. I'm not sure where to look next, so again any help would be appreciated. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: April-17-11 1:37 AM To: John Fox Cc: r-sig-mac
[R-SIG-Mac] problem checking packages with R 2.13.0
Dear list members, I'm experiencing a problem checking packages with R 2.13.0 on a new Mac OS X 10.6.7 system. As far as I can tell, R isn't finding my LaTeX installation. Packages seem to build fine. Some details follow: Here's what happens when I try to check a package: - snip -- John-Foxs-MacBook-Pro:workspace jfox$ R CMD check car * using log directory /Users/jfox/Documents/workspace/car.Rcheck * using R version 2.13.0 (2011-04-13) * using platform: x86_64-apple-darwin9.8.0 (64-bit) * using session charset: UTF-8 * checking for file car/DESCRIPTION ... OK * this is package car version 2.0-10 . . . * checking examples ... OK * checking PDF version of manual ... WARNING LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX errors found: !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding file for reading == Fatal error occurred, no output PDF file produced! * checking PDF version of manual without hyperrefs or index ... ERROR - snip -- I get the following error when I try to check the package under eclipse/StatET (deleting the lines before the error): - snip -- * 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 You may want to clean up by 'rm -rf /var/folders/ay/ayD+f6yQFomFC5SGQV6vPTI/-Tmp-//RtmpopONVs/Rd2pdf16f793c' Error in texi2dvi(Rd2.tex, pdf = (out_ext == pdf), quiet = FALSE, : pdflatex is not available Error in running tools::texi2dvi - snip -- But I have no problem running pdflatex from a terminal window: - snip -- John-Foxs-MacBook-Pro:~ jfox$ pdflatex --help Usage: pdftex [OPTION]... [TEXNAME[.tex]] [COMMANDS] or: pdftex [OPTION]... \FIRST-LINE - snip --- Nor does Sys.which() seem to find pdflatex: - snip -- R version 2.13.0 (2011-04-13) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: i386-apple-darwin9.8.0/i386 (32-bit) . . . [R.app GUI 1.40 (5751) i386-apple-darwin9.8.0] [History restored from /Users/jfox/.Rapp.history] Sys.which(pdflatex) pdflatex - snip -- Some more information about my system: - snip -- Sys.info() sysname Darwin release 10.7.3 version Darwin Kernel Version 10.7.3: Sun Mar 6 13:37:56 PST 2011; root:xnu-1504.14.2~1/RELEASE_X86_64 nodename John-Foxs-MacBook-Pro.local machine x86_64 login jfox user jfox sessionInfo() R version 2.13.0 (2011-04-13) Platform: i386-apple-darwin9.8.0/i386 (32-bit) locale: [1] en_CA.UTF-8/en_CA.UTF-8/C/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base - snip -- Any suggestions would be appreciated. Thanks, John John Fox Sen. William McMaster Prof. of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
