[R-SIG-Mac] bypassing the R.app help browser?
John Fox
jfox at mcmaster.ca
Thu Aug 14 14:09:07 CEST 2014
Dear Rich,
On Wed, 13 Aug 2014 20:33:47 -0400
"Richard M. Heiberger" <rmh at 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 <jfox at mcmaster.ca> wrote:
> > Dear Rich,
> >
> >> -----Original Message-----
> >> From: Richard M. Heiberger [mailto:rmh at 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 <jfox at 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:ripley at 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 <jfox at 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.urbanek at 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 <jfox at mcmaster.ca> wrote:
> >> >> >>>
> >> >> >>>> Hi Marc,
> >> >> >>>>
> >> >> >>>>> -----Original Message-----
> >> >> >>>>> From: Marc Schwartz [mailto:marc_schwartz at me.com]
> >> >> >>>>> Sent: Tuesday, August 12, 2014 5:10 PM
> >> >> >>>>> To: John Fox
> >> >> >>>>> Cc: r-sig-mac at 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 <jfox at 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_schwartz at me.com]
> >> >> >>>>>>> Sent: Tuesday, August 12, 2014 4:04 PM
> >> >> >>>>>>> To: John Fox
> >> >> >>>>>>> Cc: r-sig-mac at r-project.org
> >> >> >>>>>>> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?
> >> >> >>>>>>>
> >> >> >>>>>>> On Aug 12, 2014, at 2:33 PM, John Fox <jfox at 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 at r-project.org
> >> >> >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >> >> >>>>
> >> >> >>>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> R-SIG-Mac mailing list
> >> >> >> R-SIG-Mac at r-project.org
> >> >> >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Brian D. Ripley, ripley at stats.ox.ac.uk
> >> >> Emeritus Professor of Applied Statistics, University of Oxford
> >> >> 1 South Parks Road, Oxford OX1 3TG, UK
> >> >
> >> > _______________________________________________
> >> > R-SIG-Mac mailing list
> >> > R-SIG-Mac at 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/
More information about the R-SIG-Mac
mailing list