Duncan Murdoch wrote: [...] > At the last useR meeting, Thomas Baier made an excellent suggestion: > someone should put together an API specifically for R GUIs. I think > eval.with.vis would have to be part of such an API; there are dozens of > other currently undocumented or unavailable functions as well.
Ah, ha! I am very happy to discover that Thomas Baier had this excellent idea at the last useR meeting. It is almost four years that I claims for a R GUI API. If you look at the manual that comes with the SciViews bundle (available on CRAN), you will notice that there is a manual called 'SciViews-R, A GUI API and a suite of application for R' (see http://www.sciviews.org/SciViews-R/Manual.pdf) with about 50 pages that discuss several aspects related to R GUI APIs. There are also threads in the R Wiki that discusses a similar topic (although more related to graphical widgets): http://wiki.r-project.org/rwiki/doku.php?id=developers:iwidgets&s=api, http://wiki.r-project.org/rwiki/doku.php?id=developers:gwidgets_api. This is mainly the work of John Versani, after a discussion between Him, Simon Urbanek (iWidgets), Michael Lawrence (RGtk2), and myself (SciViews). That said, I did several attempt to put all people at R-SIG-GUI around a table to define a common R GUI API,... and I got no significant echo. So, I personally give up with this topic and look at what others, perhaps stronger than me in R programming or in communication with other developers, will do. But, please, do not give credit for "first idea" to someone else on such a topic... It is long enough that I fight for better R GUIs (for instance, http://www.r-project.org/GUI), that this looks offending to me! Best, Philippe Grosjean > This is a difficult project, because it would have to get agreement on > what should be part of the API, and that will constrain future changes: > so there would be a lot of resistance to making it too constraining. It > will need to be flexible, so that R isn't required to supply services > that don't make sense in all contexts. > > Duncan Murdoch > >> For instance, I use eval.with.vis() in the latest version of svSockets >> package in the SciViews bundle, but I am afraid to release it on CRAN >> because I know of the nightware I will face if this function >> (silently) changes its behavior in subsequent versions of R. >> >> I guess there is no solution to this problem, since there is certainly >> a good reason for keeping portions of R code undocumented (and thus >> flagged as :" use-it-at-your-own-risk!"), but it does not eases our life! >> >> Best, >> >> Philippe Grosjean >> >>>> that is used within source() and capture.output(); you'll have to guess >>>> from the usage there what the args are. But here's an F that does >>>> something close to what you want: >>>> >>>> > fix(F) >>>> > f <- function() 1 >>>> > g <- function() invisible(1) >>>> > >>>> > F <- function (expr) >>>> + { >>>> + expr <- substitute(expr) >>>> + pf <- parent.frame() >>>> + tmp <- .Internal(eval.with.vis(expr, pf, >>>> + baseenv())) >>>> + tmp >>>> + } >>>> > F(f()) >>>> $value >>>> [1] 1 >>>> >>>> $visible >>>> [1] TRUE >>>> >>>> > F(g()) >>>> $value >>>> [1] 1 >>>> >>>> $visible >>>> [1] FALSE >>>> >>>> > > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
