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

From: Gavin Simpson <>
Date: Wed, 13 Jun 2007 17:50:20 +0100

On Wed, 2007-06-13 at 08:04 -0700, Seth Falcon wrote:
> Jari Oksanen <> 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?

Thanks for the info on bypassing this issue Seth.

I disagree about your final comment though. If one is trying to teach the use of step() to people in a computer practical class and you want to show example output along with the commands used to produce it, you can't do what you did and produce your own function - it wouldn't be a good way to teach step() if I was using mystep() in the example code!

If this had been a report I was writing, I'd have just hacked my own version of step that used print() all the time; one of the reasons I use R in the first place is that I can go and do this. But this isn't an option when teaching.

I am still a little mystified as to why the message() and print() bits are used anyway. I mean, someone obviously felt this was a good idea or they wouldn't have spent their time making the changes, and I accept that I am probably not seeing the bigger picture here, but I don't see the difference between the two bits of information and why you'd want to treat them differently - why isn't the bit that is print()ed considered a message for example?



> + seth

 Gavin Simpson                 [t] +44 (0)20 7679 0522
 ECRC, UCL Geography,          [f] +44 (0)20 7679 0565
 Pearson Building,             [e]
 Gower Street, London          [w]
 UK. WC1E 6BT.                 [w]

______________________________________________ mailing list
Received on Wed 13 Jun 2007 - 16:54:31 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 13 Jun 2007 - 17:34:42 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.