On 8/28/2009 1:02 PM, Kevin Wright wrote:
On Fri, Aug 28, 2009 at 11:49 AM, Duncan Murdoch <murd...@stats.uwo.ca
<mailto:murd...@stats.uwo.ca>> wrote:
On 8/28/2009 12:33 PM, Kevin Wright wrote:
On Fri, Aug 28, 2009 at 11:10 AM, Henrik Bengtsson
<h...@stat.berkeley.edu <mailto:h...@stat.berkeley.edu>>wrote:
Quite a while ago I put up "R Coding Conventions (RCC) - a
draft", now at:
http://docs.google.com/View?id=dddzqd53_2646dcw759cb
It's useful for beginners and those coding "randomly". Like
it or not.
It's ok to try to persuade people coding randomly, but
otherwise it is
waste of time to get into arguing over if-else or bracketing
- we all
have our own favorite.
/Henrik
No, it IS not a waste of time. I have wasted considerable time
due the lack
of a standard. Yesterday I was debugging panel.levelplot and
found this
code:
if (x.is.factor) {
ux <- sort(unique(x[!is.na <http://is.na>(x)]))
lx <- rep(1, length(ux))
cx <- ux
}
else {
ux <- sort(unique(x[!is.na <http://is.na>(x)]))
bx <- if (length(ux) > 1)
c(3 * ux[1] - ux[2], ux[-length(ux)] + ux[-1], 3 *
ux[length(ux)] - ux[length(ux) - 1])/2
else ux + c(-0.5, 0.5) * minXwid
lx <- diff(bx)
cx <- (bx[-1] + bx[-length(bx)])/2
}
You can't step through this because the "else" block starts on a
new line.
In your other message you were talking about the browser. Does it
really have a problem with this (which would be a bug), or are you
basically just cutting and pasting?
So you have to manually evaluate the value of "x.is.factor" to
determine if
it is TRUE or FALSE, scroll down to the line below "else" and
continue
stepping through the code. Try not to forget to accidentally
evaluate the
last brace or do something else that kicks you out of the
browser and forces
you to start all over again.
Now that doesn't sound like the browser. Whatever debugger you are
using has a bug.
Duncan Murdoch
Ah, right you are. Thanks for the clarification. This is not a
"browser" phenomenon, but due to using "ess-eval-line-and-step" (which
is a kind of cut and paste, I guess) to go through the code in emacs.
(Maybe there's a better way?)
There's a better way to write a debugger, but I don't know if anyone has
done it. Rather than submitting a function one line at a time (which
doesn't necessarily evaluate the same as submitting it all at once), the
debugger could use the built in browser to single step through a
complete version of the code, and then synchronize the cursor in the
editor view according to the line number information reported by R.
This needs line numbers to be recorded in the code, or some tricky
pattern matching against the source. Line numbers are recorded by
default when you use source() to submit code, but (again by default)
this is turned off when packages are installed, so debugging a lattice
function would be a little tricky.
Revolution's IDE may use the proper method of debugging, I haven't seen
it yet.
Duncan Murdoch
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
