[Rd] RFC: API to allow identification of warnings and errors in the output stream

[Luke Tierney]

On Mon, 17 Oct 2005, Thomas Friedrichsmeier wrote:

>> I am strongly opposed to locking in anything from the C internals of
>> error handling that is not already part of the API.  This is all very
>> much subject to change and anything along the lines you propose will
>> make that change more difficult.
>
> Let's discuss this in two separate parts, then. The first is: adding
> ptr_R_WriteErrConsole as an anologon to ptr_R_WriteConsole. I can see nothing
> wrong with that (of course I'm not an R developer), and it would already help
> me a lot. As I pointed out in the previous mail, a distinction between a
> "message" channel and an "output" channel is done everywhere in R, except in
> the interface pointers. The R_WriteErrConsole comes into play at the very end
> of the "message" channel (REvprintf), and only there, exactly parallel to how
> R_WriteConsole works/gets invoked.
> Even if you're going to reject the other part of the proposed patch, please
> consider this small addition. If it helps, I can provide a stripped down
> patch for that.
>
> I'll discuss the second part (making inError, inWarning and inPrintWarnings
> available) in more detail below.

This looks less problematic, but others in R-core are more familiar
with the possible ramifications.  In any case but I also do not
believe you have made a solid case for the change.

>> Condition handling was added to make this sort of thing possible.  If
>> there are aspects of condition handling, or your understanding of
>> condition handing, that need to be improved then we can work on that.
>
> Both is quite possible. However I have reason to believe it's not just my
> understanding of condition handling that is lacking. If not so, I'll happily
> accept suggestions. Here's why I think condition handling will not help me
> much:
>
> First, for clarification, let me tell you some more about what I need: Besides
> other GUI elements, there is a pseudo-console for running commands in R
> interactively (or at least providing that illusion). I reality, all commands
> are evaluated using R_tryEval (). Still, the user should not see any of this,
> and the "console" should behave mostly just like R in a plain terminal,
> including how errors are printed (+ marking up errors in another color,
> however).
> So how could I use condition handlers?
>
> a) Wrap each call inside withCallingHandlers (...) before evaluating it in
> R_tryEval ():
> This would probably work, but add quite a bit of overhead for string
> manipulation, and parsing. The GUI runs a lot of small commands during normal
> operation.

How do you know the overhead added is significant?  The actual amount
of overhead depends on where the handler setup code is relative to the
UI loop, but even with the handler setup code pushed into the
innermost part I doubt very much that the overhead is noticeable in a
human/computer interaction context.

> There are additional hazzles, such as error messages would then
> all look like "Error in withCallingHandlers(...", and I'd have to use yet
> more string operations to make them look normal.

You need more than just withCallingHandlers if you want full control.
You will probably need a combination of withCallingHandlers, tryCatch
and withRestarts.  Look at the definition of .try_quietly in the tools
package for one example of this sort of thing.

> Also: Can I be sure, that all warnings (i.e. even from C-code) are signalled
> as conditions?

Yes--when handlers are established the internal errorcall and
warningcall functions produce and signal conditions.

> I'm afraid I do not fully understand the internal going-ons,
> here.

This remark from your earlier posting is the reson for the wording I
chose in my reply.  Instead of complicating the internals I would
prefer to help you get to the point were you understand what you need
know.

> b) Use ".Internal (.addCondHands (...))" once to set up persistent handlers:
> This worked fine, when testing it in the R-console. However, when testing in
> my GUI, it seems the condition handlers do not carry over between two
> successive calls of R_tryEval. So effectively, I'd once again be back at 3a.

There is a reason that .Internal (.addCondHands (...)) is only
documented in the primordial documentation (i.e. the source code) ...

> Of course, if there was an API to efficiently set up condition handlers from
> C, and persist over at least one call of R_tryEval, I could in fact use that,
> and would happily do so. I have not found something like that, however.

If efficiency in the sense of execution speed is really an issue we
can look into working on that.  Given my experience with similar
things on _much_ slower machines (33MHz Macintosh SE 30, for example)
I very much doubt that this is an issue.  If there are things that can
be done to make the condition system easier to work with then we can
look into that as well.

Best,

luke

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu