[Bioc-devel] best practice: verbose messages

Sean Davis sdavis2 at mail.nih.gov
Thu Jul 11 18:18:36 CEST 2013 

On Thu, Jul 11, 2013 at 11:01 AM, Kasper Daniel Hansen
<kasperdanielhansen at gmail.com> wrote:
> On Thu, Jul 11, 2013 at 9:57 AM, Henrik Bengtsson <hb at biostat.ucsf.edu>wrote:
>
>> On Wed, Jul 10, 2013 at 9:10 PM, Hervé Pagès <hpages at fhcrc.org> wrote:
>> > Hi Kasper,
>> >
>> >
>> > On 07/10/2013 10:50 AM, Kasper Daniel Hansen wrote:
>> >>
>> >> On Wed, Jul 10, 2013 at 12:38 PM, Dan Tenenbaum <dtenenba at fhcrc.org>
>> >> wrote:
>> >>
>> >>> On Wed, Jul 10, 2013 at 9:17 AM, Michael Lawrence
>> >>> <lawrence.michael at gene.com> wrote:
>> >>>>
>> >>>> If it's an informational message, like one you might log, use
>> message().
>> >>>
>> >>> If
>> >>>>
>> >>>> you're rendering an object as text, like in a show method, use cat().
>> >>>>
>> >>>
>> >>> Another thing to consider is that messages can be suppressed with
>> >>> suppressMessages() but cat() output cannot.
>> >>
>> >>
>> >>
>> >> Sure.  What I cannot decide is whether that is good or bad.
>> >
>> >
>> > If you use message(), then you don't need to have a 'verbose' arg since
>> > the messages can be suppressed with suppressMessages(). That makes
>> > your code simpler/cleaner. However this approach is only appropriate if
>> > you want your function to be verbose by default. If you want it to be
>> > quiet by default then I don't know what's best. 'verbose' arg + cat() or
>> > 'verbose' arg + message() ? That's the question...
>>
>> You can also imagine different amounts of verbose, so not always TRUE or
>> FALSE.
>>
>> About Kasper's original question, I'd also say use message().  I've
>> recently done this transition in several of my packages (mostly via
>> the Verbose class in R.utils).  I've thought about this for a long
>> time, but what made me do the transition is the fact that many of the
>> literate programming tools in R echoes the standard output in code
>> chunks, but not the standard errors.  I don't want my verbose/log
>> messages to be displayed in reports/vignettes (by default)
>>
>
> Henrik (and others),
>
> thanks for your contribution to this, I know you have spent a lot of time
> thinking about things like this.
>
> I think it would be nice to try to be somewhat uniform between packages on
> this issue, as it is always nice for users to not have every package be
> slightly different.
>
> I use verbose messages to inform the user that something is happening, and
> for my own (and the user) debugging / analysis optimization. These days I
> tend to have most of my slow code running in parallel using mclapply, I
> could not (easily) figure out how to have a progress report.  I tend to do
> the following
>   verbose supports more than one level, but the standard level is 1
> equivalent to verbose=TRUE.  Higher levels is really only for extensive
> debugging.
>   default is always FALSE
>   I have started to include "[function name]" in each message, like
> "[bumphunterEngine] message", which I find very useful
>   many verbose messages include some timing, like "... done in X secs"
> which I find very useful for development.

Hi, Kasper.

It sounds like you are describing a logging framework.  I haven't
tried any of these, but they might be worth a look.

http://cran.r-project.org/web/packages/logging/
http://cran.r-project.org/web/packages/futile.logger/
http://cran.r-project.org/web/packages/log4r/

Sean


>   A given function tend to only have one verbose level, but I then use the
> following paradigm
>      ... inside some function ...
>      subverbose = max(as.integer(verbose) - 1L, 0L)
>      helpfunction( ..., verbose = subverbose)
>   ie. higher levels of verbose just propogates verbose to sub functions.
>   many functions do not have verbose, only stuff that can take a long time
>   I only use verbose around the parts of a function that really take a long
> time, ie. it can take a "while" before the first message appear
>
> Because of this, I tend to actually like to have the messages printed in
> the console (and since default is FALSE, I don't see it in vignettes unless
> I want to), and was therefore not too happy to see that message() print on
> stderr.
>
> Now, there are many ways of doing it, but as I started this email with, I
> do think there is some value to having a single (a few) paradigms for user
> ease.
>
> Kasper
>
>
>
>> /Henrik
>>
>> >
>> >
>> > H.
>> >
>> >>
>> >> Kasper
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>> Dan
>> >>>
>> >>>
>> >>>> Just my opinion,
>> >>>> Michael
>> >>>>
>> >>>>
>> >>>> On Wed, Jul 10, 2013 at 8:24 AM, Kasper Daniel Hansen <
>> >>>> kasperdanielhansen at gmail.com> wrote:
>> >>>>
>> >>>>> Should I use cat() or message() (or something else) for
>> >>>>>    if(verbose) cat("my message\n")
>> >>>>>
>> >>>>> Best,
>> >>>>> Kasper
>> >>>>>
>> >>>>>          [[alternative HTML version deleted]]
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Bioc-devel at r-project.org mailing list
>> >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>>>>
>> >>>>
>> >>>>          [[alternative HTML version deleted]]
>> >>>>
>> >>>> _______________________________________________
>> >>>> Bioc-devel at r-project.org mailing list
>> >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>>
>> >>>
>> >>
>> >>         [[alternative HTML version deleted]]
>> >>
>> >> _______________________________________________
>> >> Bioc-devel at r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>
>> >
>> > --
>> > Hervé Pagès
>> >
>> > Program in Computational Biology
>> > Division of Public Health Sciences
>> > Fred Hutchinson Cancer Research Center
>> > 1100 Fairview Ave. N, M1-B514
>> > P.O. Box 19024
>> > Seattle, WA 98109-1024
>> >
>> > E-mail: hpages at fhcrc.org
>> > Phone:  (206) 667-5791
>> > Fax:    (206) 667-1319
>> >
>> >
>> > _______________________________________________
>> > Bioc-devel at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>         [[alternative HTML version deleted]]
>
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

More information about the Bioc-devel mailing list