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 <[email protected]> wrote: > Dear Rich, > >> -----Original Message----- >> From: Richard M. Heiberger [mailto:[email protected]] >> 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 <[email protected]> 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:[email protected]] >> >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >> >>> >> >> >>>> Hi Marc, >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: Marc Schwartz [mailto:[email protected]] >> >> >>>>> Sent: Tuesday, August 12, 2014 5:10 PM >> >> >>>>> To: John Fox >> >> >>>>> Cc: [email protected] >> >> >>>>> 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 <[email protected]> >> 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:[email protected]] >> >> >>>>>>> Sent: Tuesday, August 12, 2014 4:04 PM >> >> >>>>>>> To: John Fox >> >> >>>>>>> Cc: [email protected] >> >> >>>>>>> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? >> >> >>>>>>> >> >> >>>>>>> On Aug 12, 2014, at 2:33 PM, John Fox <[email protected]> >> 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 >> >> >>>> [email protected] >> >> >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> >>>> >> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> >> R-SIG-Mac mailing list >> >> >> [email protected] >> >> >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> > >> >> >> >> >> >> -- >> >> Brian D. Ripley, [email protected] >> >> Emeritus Professor of Applied Statistics, University of Oxford >> >> 1 South Parks Road, Oxford OX1 3TG, UK >> > >> > _______________________________________________ >> > R-SIG-Mac mailing list >> > [email protected] >> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
