Summing up the discussions in this thread, I have built a package 'startupmsg' available (in a first version) for the moment at
http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.1.tar.gz (see documentation within) In particular, I took up suggestions from Seth Falcon's mail as to the condition system in R as well as a suggestion by Brian Ripley in some earlier reply in this thread to use options() to control start-up messages. Any comments/suggestions are welcome. If you find 'startupmsg' useful, you might decide to integrate (parts of) it to the 'utils' package (or some yet to be built package "packageutils" ) later on --- for the moment, I would simply submit it to CRAN in the next days. Best, Peter Seth Falcon <[EMAIL PROTECTED]> writes: >Paul Roebuck <roebuck at mdanderson.org> writes: >>Prof Brian Ripley <[EMAIL PROTECTED]> writes: >>> Similarly for Bill Dunlap's proposal: suppressMessages would squelch all >>> messages from the call, not just the one from your package's startup code. >>> Now, at present there may not be any, but that could well change as >>> message() gets more widely used. >> >> I found Bill's suggestion a bit scary myself; suppressing messages >> when dealing with loading packages seems a bit like disabling the >> compiler's warning messages - a bad idea. But it was a novel >> approach. > >What's the use case where this would be scary? suppressMessages >doesn't supress warnings or errors, just messages. If the info to be >communicated to the user is important enough that it would be "scary" >to not see it, then shouldn't it sent as a a warning or an error? > >> Given what you said above, do you favor the suggestion to use >> message() instead of cat() for the purpose of .onAttach() startup >> messages? I've seen message() before in the manpages but never saw >> any documentation on how or when it might be considered appropriate >> to use. [...] >>>>>> On Thu, 13 Apr 2006, Prof Brian Ripley wrote: >>>>>>> I did think you could make use of an option to decide whether to >>>>>>> the print the message or not, [snip] [...] >> Why would one want to represent a simple non-error message as a >> condition in the first place? > >Because it allows another developer to have control over those >messages. That's the beauty of the condition system in R. > >Right now, developers can choose to allow or suppress messages sent >via message(). With a small change, developers could have a lot more >control. The message code could define a restart that would allow a >developer-specified function to handle the message. This could be >useful, for example, to log all messages to a file. [snip] >For anyone still with me: > >* If there was much concern about squelching "important" messages by > accident, then one could define a new subclass of simpleMessage, say > startupMessage or blatherMessage, and then suppress just those. > >* This use case of handling messages could also be addressed with a > logging system like Python's logging module. Basically, it would > allow users to install log handlers, set priorities, etc. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
