[Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()
Peter.Ruckdeschel at uni-bayreuth.de
Wed Apr 19 00:59:39 CEST 2006
Summing up the discussions in this thread, I have built a package
'startupmsg' available (in a first version) for the moment at
(see documentation within)
In particular, I took up suggestions from Seth Falcon's mail as to the
in R as well as a suggestion by Brian Ripley in some earlier reply in
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
for the moment, I would simply submit it to CRAN in the next days.
Seth Falcon <sfalcon at fhcrc.org> writes:
>Paul Roebuck <roebuck at mdanderson.org> writes:
>>Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
>>> Similarly for Bill Dunlap's proposal: suppressMessages would squelch all
>>> messages from the call, not just the one from your package's startup
>>> 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
>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.
>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.
More information about the R-devel