[R-SIG-Mac] bypassing the R.app help browser?
Richard M. Heiberger
rmh at temple.edu
Thu Aug 14 02:33:47 CEST 2014
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 <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
>
More information about the R-SIG-Mac
mailing list