RFC: API to allow identification of warnings and errors in the output stream
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