On Thu, Jul 11, 2013 at 11:01 AM, Kasper Daniel Hansen <kasperdanielhan...@gmail.com> wrote: > On Thu, Jul 11, 2013 at 9:57 AM, Henrik Bengtsson > <h...@biostat.ucsf.edu>wrote: > >> On Wed, Jul 10, 2013 at 9:10 PM, Hervé Pagès <hpa...@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 <dtene...@fhcrc.org> >> >> wrote: >> >> >> >>> On Wed, Jul 10, 2013 at 9:17 AM, Michael Lawrence >> >>> <lawrence.mich...@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 < >> >>>> kasperdanielhan...@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@r-project.org mailing list >> >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >>>>> >> >>>> >> >>>> [[alternative HTML version deleted]] >> >>>> >> >>>> _______________________________________________ >> >>>> Bioc-devel@r-project.org mailing list >> >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >>> >> >>> >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> _______________________________________________ >> >> Bioc-devel@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: hpa...@fhcrc.org >> > Phone: (206) 667-5791 >> > Fax: (206) 667-1319 >> > >> > >> > _______________________________________________ >> > Bioc-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > [[alternative HTML version deleted]] > > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel