[Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()

[Peter Ruckdeschel]

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