[Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()
Peter Ruckdeschel
Peter.Ruckdeschel at uni-bayreuth.de
Wed Apr 19 21:26:59 CEST 2006
Dear Seth,
thank you very much for your helpful comments:
>I had a quick look and for what it's worth, a few comments...
>
>* Seems a bit more code than I would expect.
Arguable, yes...
> I think you have some use cases that I don't have ;-).
hopefully I'm not the only one to have these cases :-)
> In terms of general use, I would suggest making a stab at a
> simplified version.
I have tried to do something in that direction:
* files startUpMessage.R / StartupUtilities.Rd now gather the code
addressing a more general audience; (?"startupmsg")
* files illustration.R / myStartupUtilities.Rd
[ with mySMHandler, mystartupMessage, buildStartupMessage ]
(?"mySMHandler") may be thought of an illustration of the concept
(and hence should not enter general packages, I suppose)
the revised code is available again under
http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.2.tar.gz
> For example, what's the difference between startupMessage and
> startupVersionMessage; are both needed?
I guessed so: the idea is to have more than one type of
StartupMessage, and suppressing should be done according to the type;
I have rethought this now: instead of two (or more) subclasses
of StartupMessage, I now have endowed class StartupMessage with an
extra slot type, which currently is supposed to take one of the tree
values
+ "version": version and title information from the DESCRIPTION file
+ "notabene": "nota bene"s on the package to be given at
this prominent place
+ "information": (starting) pointers for more information on the
package:
-howto call the package help file,
-howto inspect the NEWS file,
-additional manuals/vignettes
-URLs
(but the code already supports arbitrarily many type values)
> And linestarter?
I agree: this should better be dealt with in a more general/flexible way
by allowing + the developper using 'startupMessages'
to use his own SMHandler (for /S/tartup/M/essage/Handler/)
as illustrated in 'mystartupMessages'
+ the user of a package with 'startupMessages'
to specify a suitable custom restart
(see examples in ?"startupmsg")
--- is achieved using your code example
>* Consider adding a customizable restart. As it stands, startupmsg
> doesn't give a user more control than message().
Now it does; I admit, I should have integrated your proposed elegant
code right from the beginning.
> That is, you can either muffle the messages or not. If I want to write
> them to a file or prefix them with funny characters, doing so by grabbing
> hold of the message before it is emitted via the restart seems like a
> nice approach (although one could argue for a more general system
> logging system that probably would not need the fancy condition
> system use).
Thank you again
Peter
More information about the R-devel
mailing list