R devel - Oct 2006 - R GUI API: suggestion for R function to put in there?

> - To execute R code contained in a string and return the result of this
> evaluation in a string (including presentation of error messages and
> warnings) exactly as if this was entered at the prompt. Duncan Murdoch
> is against such a kind of function (he says a GUI should not substitute
> to the R interpreter, and it should manage and present errors or
> warnings in a better way than the teletype approach of the command
This is useful for useful for things like Sweave.  I have a modified
version of capture.output that captures everything:

capture.all <- function(code, envir = globalenv()) {
	printErrors <- function(code) {
		tryCatch(
			eval(parse(text=code), envir = envir),
			error = function(e) o(e)
		)
	}

	paste(capture.output(
	  withCallingHandlers(printErrors(code), warning = function(x) {
		cat("Warning: ", x$message, "\n")
		invokeRestart("muffleWarning")
	})), collapse="\n", sep="")
}

for my (unreleased) sweave-like package.  It's not perfect, but it has
served my needs.

Hadley

Thanks for posting this list.  I just want to clarify one place where 
you quote me:

On 10/29/2006 11:54 AM, Philippe Grosjean wrote:

  ... deletions
> - To execute R code contained in a string and return the result of this 
> evaluation in a string (including presentation of error messages and 
> warnings) exactly as if this was entered at the prompt. Duncan Murdoch 
> is against such a kind of function (he says a GUI should not substitute 
> to the R interpreter, and it should manage and present errors or 
> warnings in a better way than the teletype approach of the command 
> line). 
I actually said that a GUI should "be able to" do these things.  My
only
objection to the proposed function is that it's not sufficient.  R 
should supply facilities that make it easy to write that function, by 
supplying the mechanisms for the GUI to get at everything necessary.

Duncan Murdoch

Well, following a discussion with Duncan Murdoch, where he suggests me 
to rewrite my requests, here it is.

Just a couple of problems I found difficult to solve, as a writer of R 
GUIs, and for which I would be very happy to get a R function (plus 
rationates):

- To know if an evaluation returns invisibly or not. This is discussed 
in a previous thread. We now have withVisible().

- To know if some R code is complete or is continued to the next line. 
The following trick was suggested by Peter Dalgaard once, but it is 
fragile because it depends on the way R prints errors, and that may 
change in the future:

isLineComplete <- function(x) {
       # x is a character string vector with R code
       # The function determines if the parser is satisfied with it
       # or it needs more input (code is continued at the next line)

       # First parse code
       con <- textConnection(x)
       expr <- try(parse(con), silent = TRUE)
       close(con)

       # Determine if this code is correctly parsed
       if (inherits(expr, "try-error")) {
           results <- expr
           # Determine if it is an incomplete line
           if (length(grep("\n2:", results)) == 1) return(FALSE)
       }
       # Note: here, we return TRUE also if the code is wrong
       # but one could enhance the function to return something
       # else in case of wrong R code
       return(TRUE)
  }

   > isLineComplete("ls()")
  [1] TRUE
   > isLineComplete("ls(")
  [1] FALSE
   > isLineComplete("ls())")
  [1] TRUE

- To execute R code contained in a string and return the result of this 
evaluation in a string (including presentation of error messages and 
warnings) exactly as if this was entered at the prompt. Duncan Murdoch 
is against such a kind of function (he says a GUI should not substitute 
to the R interpreter, and it should manage and present errors or 
warnings in a better way than the teletype approach of the command 
line). However, there are occasions where we would like to embed a 
little R interpreter in a GUI. R Commander and Tinn-R are two good 
examples. Also, I advocate for a R GUI that is a layer on top of the R 
Console, but ultimately shows to the user (1) what is the equivalent R 
code he should type at the prompt, and (2) what does R replies if this 
code is issued at the prompt. That way, the GUI is just a convenient way 
to learn R, and to get a smooth move to the intimidating command line. 
In this context a kind of 'execute("some R code")' function
should be
fine (and I see a couple of additional usages for this too).

- In the same idea, to write a similar function, but that returns a list 
of strings, each string being flagged as 'output', 'warning' or
'error'.
The succession should correspond to the evaluation (this is especially 
tricky for warning messages, due to the complex way R handles those 
warning message.

- To know which objects were changed since a given date, or during last 
call. This should require a time flag on the variable that contains this 
object. One particular application is an object explorer that could 
update information quickly if it could query only those objects that 
have changed since last process. This topic has already been discussed a 
couple of times, and no convincing solution has emerged (technical 
problems), it seems... but it is worth to continue thinking about it.

- To know if R is currently processing something in another event loop. 
Since R was designed initially to work with a single event loop, this 
was obviously useless. Now that we can use separate event loops for, 
let's say, command issued at the prompt, and do some other jobs with the 
embedded Tcl (tcltk package), for instance, it could be useful to know 
the state of R for the respective event loops. For instance, I would 
like to know if R is processing some code issued at the prompt, from an 
interface written in Tcl (like svSockets, for instance, or the mini-web 
server built in Rpad, for another example).

This is just a couple of suggestions that would make the life of R GUI 
writers a little bit easier (at least mine). Now, I don't want to enter 
in endless discussion if something is useful or not,... but if someone 
has the solution for one of these problems, or is ready to write an R 
function to provide such functionalities, i would be very happy.

Best,

Philippe Grosjean

Hi Philippe!

Sorry to break the threading and formatting, I'm not subscribed to r-devel, 
hence just copying from the web archive.

Philippe Grosjean wrote:
>- To know if some R code is complete or is continued to the next line. 
> The following trick was suggested by Peter Dalgaard once, but it is 
> fragile because it depends on the way R prints errors, and that may 
> change in the future:
This is doable in C using R_ParseVector. If you would like to see details, of 
how this is done in RKWard, contact me via private mail.

One problem, however, we did not solve: Is there a way to get at syntax errors 
(if any) from C? parseError () is not exported.
> - To execute R code contained in a string and return the result of this 
> evaluation in a string (including presentation of error messages and 
> warnings) exactly as if this was entered at the prompt.
In RKWard we come close to this using R_ParseVector and some further tricks 
(not quite perfect, however), so again, contact me on this, if you like.
Still, having a more straight-forward way to evaluate a string just as like it 
had been entered on the console would be very nice to have.
> - In the same idea, to write a similar function, but that returns a list 
> of strings, each string being flagged as 'output',
'warning' or 'error'.
> The succession should correspond to the evaluation (this is especially 
> tricky for warning messages, due to the complex way R handles those 
> warning message.
I very much second this. Note also that I would be nice to catch direct uses 
of REprintf () (which may not neccessarily be a warning or error, but may be 
elegible for special handling in the front-end; hence the suggestion by 
Hadley Wickham does not cover everything I'd like to see covered).
I once made a proposal on how to achieve some of this from C (last public 
message on this was 
https://stat.ethz.ch/pipermail/r-devel/2005-October/035144.html). Patch has 
since been improved 
(http://rkward.sourceforge.net/temp/r_writeerrconsole_v3_updated2.diff), but 
it seems, whenever I send it to Duncan, it happens to be a bad point of time 
for him to review it. Anybody else willing to test this on Windows / help me 
get this to an includable state?
> - To know which objects were changed since a given date, or during last 
> call. This should require a time flag on the variable that contains this 
> object. One particular application is an object explorer that could 
> update information quickly if it could query only those objects that 
> have changed since last process. This topic has already been discussed a 
> couple of times, and no convincing solution has emerged (technical 
> problems), it seems... but it is worth to continue thinking about it.
I've attacked this problem in RKWard very recently (not a full time flag,
but
at least catching all modifications). The approach we use since 0.4.0 is to
1) after each evaluation check for new / removed symbols in .GlobalEnv (not 
very elegant, but good enough)
2) move all symbols in .GlobalEnv to a dedicated environment, and 
in .GlobalEnv replace them with active bindings. Assignments to the symbols 
can now simply be detected via the active binding.
Once again, more details on request. Of course an easier solution would be 
very welcome, but it seems to work pretty well.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
https://stat.ethz.ch/pipermail/r-devel/attachments/20061030/a1fb6dfc/attachment-0004.bin