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

[Prof Brian Ripley]

On Mon, 17 Oct 2005, Luke Tierney wrote:

> 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.

I second the point about not having made a case, and also that (from the 
part deleted below) about needing to understand the internals before 
proposing changes.

a) I took a quick look at the patch, and it seems to be only half the 
story.  R_WriteConsole is also supported under Windows, in a different 
(and more flexible) way.  I think the part not covered is a lot more 
problematic, as I don't see how to introduce R_WriteErrConsole in a 
backwards compatible way.

b) There are several inaccuracies in the account.  First, `channels' are 
not what we are talking about here.  sink() allow output and messages to 
be sent to different connections, but the console is connected to fixed 
terminal connections stdout() and stderr().  There is a long-standing 
design for R consoles (sketched in src/unix/system.txt) that has all the 
output going to the console.  This is even true of the standard Unix 
terminal front end.  The only circumstances in which stdout() and stderr() 
are separated are when R is used for scripting.  Part of the motivation 
for this is to ensure that stdout() and stderr() appear in an integrated 
way (in particular, interleaved in the correct order) on a console.

No other console designer has seen a need for this, and there is at least 
the potential for presenting very misleading information to end users. So 
one ramification of allowing consoles to present stdout() and stderr() 
separately would have to be a review of how they are used.  This is not 
hypothetical: I have struggled many times over the years with an R-like 
system which when scripted wrote error messages in inappropriate places on 
a file, at one point sending prompts to stderr yet echoed input to stdout. 
We've worked hard in R to avoid that kind of thing, mainly by having a 
single route to the console.  (There are still residual problems if C++ or 
Fortran I/O is used, BTW, and note that R_ReadConsole also *writes* to the 
console.)

c) Anything in R involving more than one of the three main families of 
platforms is NOT a `small addition': it involves testing and subsequent 
maintenance by two or three people.

d) There is an existing mechanism that could be used.  If you want 
file-like stderr and stdout, you could drive R via a file-like interface 
(e.g. ptys).  That is not easy on non-Unix-alike platforms (and was 
probably impossible on classic MacOS R), but I understood Thomas was using 
KDE.  (There are live examples of this route, even on Windows.)

[...]


I have spent far longer (and written more) than I intended on this.  The 
length of correspondence so far (and much in a prolix style) is all part 
of the support costs.  One thing the R project can not afford is to 
explain to individual users how internals work -- we have not even been 
able to find the time to write down for the core team how a lot of the 
internals work, and some developments are being held up by that.  So this 
has to weighed against considering proposals which would appear to help 
just one user.

I suspect that we will only want to go forward if a concise and strong 
case can be made from a group of developers who have tested it out on all 
three main families of platforms.


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595