thank you, duncan. I get this particular error from subset(d, select=c( list.of.many.variables.one.of.which.is.misspelled) ); this is probably not too uncommon in data sets with many long-named variables. hunting down what causes it is a pain. I am definitely looking forward to 2.6.0 and hope that keeping source line numbers (as "comment do nothing" statements?) in the evaluator will happen.
regards, /ivo On 4/24/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 4/23/2007 7:23 PM, ivo welch wrote: > > Dear R developers: May I suggest that future versions of R improve a > > little on the error reporting? For example, right now, I am trying to > > figure out which of my column names in a select statement has been > > mis-spelled: > > > > Error in `[.data.frame`(x, r, vars, drop = drop) : > > undefined columns selected > > > > It would be nice if it could say what the name of the undefined column is. > > I think this message usually arises when you're doing something like > > > vars <- NA > > df[1, vars] > Error in `[.data.frame`(df, 1, vars) : undefined columns selected > > so the message is trying to tell you that there isn't any name > available. Conceivably the message could be clearer (e.g. in this > specific case, "NA in column selection"), but that may not be the only > way this error could arise. > > > Of course, I have already begged a couple of times that errors like > > this be preceded by a backtrace or the last line number from the > > user's R program. > > > > joke.R:22: Error in `[.data.frame`(x, r, vars, drop = drop) : > > undefined columns selected: "non.existing.name" in > "data.frame.name" > > > > That's quite difficult. The parser knows line numbers, and can report > them (as of 2.5.0), but these aren't kept when the lines are evaluated. > The sequence is: > > read the file > parse it into a list of expressions > evaluate it > > Parsing errors can report line numbers, but the evaluator doesn't keep them. > > This means R doesn't have any idea what line caused a particular error. > In principle it could (e.g. by keeping line number info in functions), > but it's tricky to get right, because there are so many ways to modify > expressions after parsing. > > There are limitations to the parser line number reporting (e.g. in a > package, all source files are concatenated before parsing; if you have a > syntax error you'll see the report about the concatenated file line > number, not the original source file line number). I'd say fixing those > is the first priority. My long range goal is to provide support for > source-level debugging, which has requirements similar to the error > reports you want: they may come at the same time. I'd guess this won't > happen in 2.6.0, but you never know. > > Duncan Murdoch > > > I don't understand why this is difficult (simply storing the currently > > executing line and/or linenumber) as the program executes---but then, > > I am a lousy freerider who does not look at the code. (All I do is > > occasionally donate to the R org.) > > > > of course, I appreciate the great language you have put together. > > just begging to make it a little better. (yes, I do not want to use > > ESS.) > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
