> 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. > 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. 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. Also: Can I be sure, that all warnings (i.e. even from C-code) are signalled as conditions? I'm afraid I do not fully understand the internal going-ons, here. 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. 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. Thanks! Thomas ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
