[Rd] step() in sink() and Sweave()

[Seth Falcon]

Jari Oksanen <jarioksa at sun3.oulu.fi> writes:

> On Wed, 2007-06-13 at 13:33 +0100, Gavin Simpson wrote:
>> Dear Developers,
>> 
>> This change also just bit me whilst updating Sweave documents for some
>> computer classes.
>> 
>> Is there a work-around that can be employed so that we get both the
>> message() bits and the print() bits in the same place for our Sweave
>> files?
>> 
>> If not, is there any point in filing this as a bug in R? I see there
>> have been no (public) responses to Jari's email, yet the change is
>> rather annoying, and I do not see the rationale for "printing" different
>> parts of the output from step() in two different ways.
>> 
> I think this is a bug. You should not use message() with optional trace.
> The template for the usage in step() is first
>
> if (trace) message()
>
> and later
>
> if (trace) print()
>
> If you specifically request printing setting  trace = TRUE, then you
> should not get message().
>
> Interestingly, message() seems to be a warning() that cannot be
> suppressed by setting options.

message is a condition and so is a warning.  This means you have some
control over them.  For example, you can create a wrapper for step
that uses withCallingHandlers to cat out all messages (or print them,
or email them to your friends :-)

mystep <- function(object, scope, scale = 0,
                   direction = c("both", "backward", "forward"),
                   trace = 1, keep = NULL, steps = 1000, k = 2, 
                   ...)
{
    withCallingHandlers(step(object=object, scope=scope, scale=scale,
                             direction=direction, trace=trace,
                             keep=keep, steps=steps, k=k, ...),
                        message=function(m) {
                            cat(conditionMessage(m))
                        })
}

> This is so annoying that I haven't updated some of my Sweave documents.
> It is better to have outdated documents than crippled documents.

I'm not trying to argue that the function shouldn't change, but if it
is so annoying, you can also resolve this problem by defining your own
step function and calling it (forgetting about withCallingHandlers).
Clearly not ideal, but at the same time in the spirit of open source,
no?

+ seth

-- 
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org