Dear Rich, On Wed, 13 Aug 2014 20:33:47 -0400 "Richard M. Heiberger" <[email protected]> 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 <[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 > > ------------------------------------------------ John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
