On Wed, 2007-06-13 at 08:04 -0700, Seth Falcon wrote:
> Jari Oksanen <[EMAIL PROTECTED]> 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?
Cheers,
G
>
> + seth
>
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
