Re: [Rd] R_parseVector and syntax error [was: error messages while parsing with rniParse]
Duncan Murdoch wrote:
Romain Francois wrote:
Duncan Murdoch wrote:
Simon Urbanek wrote:
On Jun 18, 2009, at 17:02 , Duncan Murdoch wrote:
Romain Francois wrote:
Hello,
[I'm redirecting this here from stats-rosuda-devel]
When parsing R code through R_parseVector and the code generates
an error (syntax error), is there a way to grab the error.
It looks like yyerror populates the buffer "R_ParseErrorMsg",
but then the variable is not part of the public api.
Would it be possible to add yet another entry point to the
parser that would basically wrap R_parseVector so that it would
have an extra char* argument that would bring back the error
message if there is an error?
I would oppose that. Suggest ways to reduce the complexity of
the parser interface and I'd be interested. It's a nightmare to
make any changes there.
You can always call the R function wrapped in try(), so it's not
as though this would give you anything that you don't already
have access to.
I'm not quite following - we're talking about R_ParseVector in C
code so the point is that the C code gets access to the error
message so it can relay it to the user.
I understood that. But the C code can get the error message by
evaluating an R expression and looking at the result.
There are no R-level functions involved here. The issue here for
the moment is that this information is retrievable at R level but
not (officially) at the C level.
I wouldn't mind exposing the underlying information in a clean way,
but the string in R_ParseVector isn't all a front end should get.
Great. Let's do that.
Is a function that simply returns some of the static variables used
by bison clean enough ?
It could be. I'd like a design that allows for the possibility of
multiple syntax errors to be reported. I have parse_Rd doing that,
though not committed yet. parse() is different because we have to be
less tolerant of errors in R code than in Rd files. But we could
still report multiple errors in one parse, not just stop at the first
one.
This is an interesting problem. Just being curious here: how do you
continue parsing after a syntax error in parse ? Does it depend on the
kind of syntax error ? Do you use some of the recovery protocols of
bison (the special "error" token only appears in the very top level prog
symbol :
prog:END_OF_INPUT{ return 0; }
|'\n'{ return xxvalue(NULL,2,NULL); }
|expr_or_assign '\n'{ return xxvalue($1,3,&@1); }
|expr_or_assign ';'{ return xxvalue($1,4,&@1); }
|error { YYABORT; }
;
Anyway, what about using the extra information to structure an error
message of a custom condition class.
Duncan Murdoch
At the time of an R_ParseVector syntax error, the parser knows what
token it couldn't handle, and it knows its classification, and the
location in the file where it came from. Not all of that makes it
through to the error message.
As for reducing complexity - technically, there is no complexity
added since all this is already in place ... [adding extra char *
argument to ParseVector may not be the best way but that's not
what I'm arguing for].
It was what I was arguing against.
Duncan Murdoch
Or am I missing something?
Cheers,
S
Romain
Simon Urbanek wrote:
On Jun 15, 2009, at 12:05 , Romain Francois wrote:
Hello,
In JRI, is there a way to get the error message that is
generated by the
parser through rniParse
For example, if I have this :
long y = re.rniParse( "rnorm( 10 ))", 1 ) ;
this obviously generates a parse error, so y will be the same as
(R_NilValue) :
long null_id = re.rniEval( re.rniParse( "NULL", 1 ), 0 ) ;
I guess the underlying question is : "Is R_ParseErrorMsg
exposed to
JRI".
AFAICT R_ParseErrorMsg and friends are not exposed by the R API
- they are not accessible outside, so they cannot be use by
JRI. It would be nice if there was a way of accessing that
info, but R doesn't currently support that.
Cheers,
Simon
The reason is I would like to bring back the message as part of an
exception generated when the code does not parse.
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RGui Configuration Editor crashes when using an unlisted font
I am using R2.9.0 under Windows XP SP 2 (32-bit).
I just discovered a rather excellent programming font
(http://www.dafont.com/bitstream-vera-mono.font). Since it isn't one of
the fonts listed as an option in the RGui Configuration Editor, I manually
editted my RConsole file font line to
font = Bitstream Vera Sans Mono
When I opened R, the text in the console displayed correctly, but when I
tried to open the RGui Configuration Editor (via Edit -> Gui preferences),
R crashed.
I've repeated this with several other fonts that aren't on the standard
list of available fonts and the behaviour is reproduced. I've also
reproduced the crash on another machine running R2.9.0 and WinXP.
Please can someone check to see if the problem occurs on the development
build/other operating systems, and I will file a bug report.
Regards,
Richie.
Mathematical Sciences Unit
HSL
ATTENTION:
This message contains privileged and confidential inform...{{dropped:20}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] validObject throws non-caught error when slot doesn't exist
Patrick,
Thanks for the bug report and the proposed patch.
There are some related ways that validObject can fail (e.g., if the
revised class definition extends one of the object types or if the
object is an S3 object), so the patch needs to be a little more general,
but I will commit something to the 2.10 development version and send mail).
John
Patrick Aboyoun wrote:
I have been retooling an S4 class definition to include another slot
and have found that the methods::validObject function (defined in
methods/R/SClasses.R) in R-devel throws an error that isn't caught
internally (and thus not controllable by 'test' argument) when
retrieving a non-existent slot. The offending line of code is shown
below:
> validObject
function (object, test = FALSE, complete = FALSE)
{
...
for (i in seq_along(slotTypes)) {
classi <- slotTypes[[i]]
sloti <- slot(object, slotNames[[i]]) # offending line of code
One potential patch is to substitute the offending line with
sloti <- try(slot(object, slotNames[[i]]), silent = TRUE)
if (class(sloti) == "try-error") {
errors <- c(errors, paste("missing slot \"", slotNames[[i]],
"\"", sep = ""))
next
}
Here is a reproduce and an example using vaildObject2 that substitutes
the offending line with the code given above:
> setClass("Foo", representation(bar = "character"))
[1] "Foo"
> a <- new("Foo", bar = letters)
> setClass("Foo", representation(bar = "character", star = "numeric"))
[1] "Foo"
> validObject(a, test = TRUE)
Error in slot(object, slotNames[[i]]) :
no slot of name "star" for this object of class "Foo"
> validObject2(a, test = TRUE)
[1] "missing slot \"star\""
> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-06-12 r48755)
i386-apple-darwin9.6.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Patrick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] validObject throws non-caught error when slot doesn't exist
A fix for this and related problems is now committed (r48803).
Some of the interesting ways that validObject() could fail previously
are in the attached regression-test file.
John
John Chambers wrote:
Patrick,
Thanks for the bug report and the proposed patch.
There are some related ways that validObject can fail (e.g., if the
revised class definition extends one of the object types or if the
object is an S3 object), so the patch needs to be a little more
general, but I will commit something to the 2.10 development version
and send mail).
John
Patrick Aboyoun wrote:
I have been retooling an S4 class definition to include another slot
and have found that the methods::validObject function (defined in
methods/R/SClasses.R) in R-devel throws an error that isn't caught
internally (and thus not controllable by 'test' argument) when
retrieving a non-existent slot. The offending line of code is shown
below:
> validObject
function (object, test = FALSE, complete = FALSE)
{
...
for (i in seq_along(slotTypes)) {
classi <- slotTypes[[i]]
sloti <- slot(object, slotNames[[i]]) # offending line of code
One potential patch is to substitute the offending line with
sloti <- try(slot(object, slotNames[[i]]), silent = TRUE)
if (class(sloti) == "try-error") {
errors <- c(errors, paste("missing slot \"", slotNames[[i]],
"\"", sep = ""))
next
}
Here is a reproduce and an example using vaildObject2 that
substitutes the offending line with the code given above:
> setClass("Foo", representation(bar = "character"))
[1] "Foo"
> a <- new("Foo", bar = letters)
> setClass("Foo", representation(bar = "character", star = "numeric"))
[1] "Foo"
> validObject(a, test = TRUE)
Error in slot(object, slotNames[[i]]) :
no slot of name "star" for this object of class "Foo"
> validObject2(a, test = TRUE)
[1] "missing slot \"star\""
> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-06-12 r48755)
i386-apple-darwin9.6.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Patrick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
setClass("Foo", representation(bar = "character"))
a <- new("Foo", bar = letters)
setClass("Foo", representation(bar = "character", star = "numeric", flag =
"logical"))
stopifnot(is.character(validObject(a, test = TRUE)))
setClass("Foo", representation(bar = "POSIXt"))
stopifnot(is.character(validObject(a, test = TRUE)))
setClass("Foo", contains = "character", representation(bar = "character"))
stopifnot(is.character(validObject(a, test = TRUE)))
setClass("Foo", contains = "lm", representation(bar = "character"))
stopifnot(is.character(validObject(a, test = TRUE)))
setClass("myEnv", contains = "environment", representation(bar = "character"))
mvv = new("myEnv", new.env(), bar = "test")
setClass("c1", representation(x="numeric"))
setClass("c2", representation(y = "numeric", xx = "c1"))
xx <- new("c2", y = 1, xx = new("c1", x = 2))
removeClass("c1")
stopifnot(is.character(validObject(xx, test = TRUE)))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changes to Rd handling in R-devel
I've just committed some fairly big changes to R-devel.
- There's a new tag \Sexpr which allows R code to be embedded within
the Rd file, similar to Sweave, \RdOpts
corresponds to \SweaveOpts.
- The parser now mainly issues warnings, rather than errors, in case
of syntax errors. It throws away a few tokens and tries to restart.
This should let you see most of your errors in one pass, rather than one
at a time. (Don't ignore the warnings -- you've lost some of your file
if you get them!) (Romain: yes, this is done using the special "error"
token in bison.)
- There are also a number of bug fixes to the rendering code (e.g.
Rd2HTML). I'm hoping to switch over soon to the new parser being used
to produce all man pages.
I need to write up more about \Sexpr, but the basic idea is that the
format is
\Sexpr{R code}
or
\Sexpr[options]{R code}
Currently the R code is not executed unless you do it manually, but once
we're using this engine for man pages, you'll be able to choose when to
execute the code: build time, install time, or render time.
I hope these changes don't introduce any bugs in old Rd files, but if
they do, please let me know and I'll fix them. (Not today; I'll be
travelling.)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes to Rd handling in R-devel
On Fri, Jun 19, 2009 at 6:12 PM, Duncan Murdoch wrote:
> I've just committed some fairly big changes to R-devel. - There's a new tag
> \Sexpr which allows R code to be embedded within the Rd file, similar to
> Sweave, \RdOpts
> corresponds to \SweaveOpts.
> - The parser now mainly issues warnings, rather than errors, in case of
> syntax errors. It throws away a few tokens and tries to restart. This
> should let you see most of your errors in one pass, rather than one at a
> time. (Don't ignore the warnings -- you've lost some of your file if you
> get them!) (Romain: yes, this is done using the special "error" token in
> bison.)
> - There are also a number of bug fixes to the rendering code (e.g.
> Rd2HTML). I'm hoping to switch over soon to the new parser being used to
> produce all man pages.
>
> I need to write up more about \Sexpr, but the basic idea is that the format
> is
>
> \Sexpr{R code}
>
> or
>
> \Sexpr[options]{R code}
>
> Currently the R code is not executed unless you do it manually, but once
> we're using this engine for man pages, you'll be able to choose when to
> execute the code: build time, install time, or render time.
Can the R code emit top-level rdoc tags? i.e. could the complete rd
file just be \Sexpr{} ?
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes to Rd handling in R-devel
hadley wickham wrote:
On Fri, Jun 19, 2009 at 6:12 PM, Duncan Murdoch wrote:
I've just committed some fairly big changes to R-devel. - There's a new tag
\Sexpr which allows R code to be embedded within the Rd file, similar to
Sweave, \RdOpts
corresponds to \SweaveOpts.
- The parser now mainly issues warnings, rather than errors, in case of
syntax errors. It throws away a few tokens and tries to restart. This
should let you see most of your errors in one pass, rather than one at a
time. (Don't ignore the warnings -- you've lost some of your file if you
get them!) (Romain: yes, this is done using the special "error" token in
bison.)
- There are also a number of bug fixes to the rendering code (e.g.
Rd2HTML). I'm hoping to switch over soon to the new parser being used to
produce all man pages.
I need to write up more about \Sexpr, but the basic idea is that the format
is
\Sexpr{R code}
or
\Sexpr[options]{R code}
Currently the R code is not executed unless you do it manually, but once
we're using this engine for man pages, you'll be able to choose when to
execute the code: build time, install time, or render time.
Can the R code emit top-level rdoc tags? i.e. could the complete rd
file just be \Sexpr{} ?
There are details to be worked out (and bugs to be fixed) as this is
integrated into the build/install system, but so far I can't think of
any reason why that would not be possible, as long as the required tags
(e.g. \alias, \name, \title) were emitted early enough.
The current plan is that you would use a name like foo.Rdin to indicate
that you have code to execute before building the tarball, and the build
system would emit a text .Rd file. At install time that would be
converted to a binary representation which is what would be installed,
and the final conversion to HTML or displayed text or other rendered
format would happen as late as possible. (Ideally, this would be fully
dynamic, doing the conversion when the user asks for help, but that is
not feasible for all formats, and I'm not sure how much of the final
implementation will be done before 2.10.0.)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
