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, [EMAIL PROTECTED] 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
