On Wed, Apr 10, 2019 at 5:06 AM, Tomas Kalibera <tomas.kalib...@gmail.com> wrote: >> This is my first post here. I came across the very same problem. >> It can be reproduced within modified tests/Embedding/RParseEval.c > > Please check https://www.r-project.org/posting-guide.html and update > your post if you still need to get help here - from your current post > I am not sure what you did, what was the error you got and from which > tool, why you think the error was a result of something not working > correctly/as documented, etc. The original post with the same subject > you are probably referring to had the same problem.
The original post is linked via e-mail headers however it goes back a decade. It shows up linked as a thread alright in Gnus. Hence I thought it would be alright to jump straight to the matter. Here is the link to original discussion https://stat.ethz.ch/pipermail/r-devel/2008-August/050332.html At this point, I would like to report two bugs in "Writing R Extensions" documentation. From that document it is not clear why line feeds (0x0A) have to be removed from the input string to be parsed. Also nowhere in that document it mentions R_TopLevelExec if parsing needs to be done in the outer context. That is not when our C function is called from R, but when we are trying to parse R code in C directly outside of main loop. These are big show stoppers for newcomers. The barely modified test code I had in my previous post, does not parse what would seem a legit sample string "\r\n ls()". However, it does parse alright "\n ls()". Nowhere in the docs the intolerance to line feeds is mentioned. It is reproducible from R console as well. ,----[ R console session ] | > parse(text="\r\n ls()") | Error in parse(text = "\r\n ls()") : <text>:1:1: unexpected input | 1: | ^ | > `---- Another problem with the aforementioned documentation is parsing erroneous expressions like "deadbeef<-function(,bad){}" in top level context. Instead of returning an error from parsing, it crashes (with R_suicide) unless the call is wrapped in R_TopLevelExec. > Please also note that "tests" (tests/Embedding/RParseEval.c) are not > examples - if they do not catch R errors in some cases that is > perfectly ok, they also may use internal API that is indeed not > documented e.g. in Writing R Extensions. Where would be a good example on top level context parsing then? I have no problems skipping error checks and/or with the use of undocumented functions. However I would rather prefer to avoid major unexpected crashes. That example does NOT use any of the undocumented API and therefore is misleading. I believe it SHOULD include R_TopLevelExec and that function SHOULD be in the docs. > Note Writing R Extensions has a section on embedding R and on cleanup > handlers. I have no problems with the rest of the document on embedding and clean up in general. >> Actually this example has another issue, namely it doesn't wrap >> everything in R_ToplevelExec . This is a major show stopper for >> newcomers as that function is barely mentioned anywhere and longjmp into >> terminated setuploop function followed by R_suicide look like a mystery. >> >> Error: bad value >> Fatal error: unable to initialize the JIT >> >> >> That aside, here is the code with newlines that fails to parse. I hope >> it will paste alright here. >> >> >> #include "embeddedRCall.h" >> #include <R_ext/Parse.h> >> >> int >> main(int argc, char *argv[]) >> { >> SEXP e, tmp; >> int hadError; >> ParseStatus status; >> >> init_R(argc, argv); >> >> PROTECT(tmp = mkString("\n\r ls()")); >> PROTECT(e = R_ParseVector(tmp, 1, &status, R_NilValue)); >> if (status != PARSE_OK) >> { >> printf("boo boo\n"); >> } >> else >> { >> PrintValue(e); >> R_tryEval(VECTOR_ELT(e,0), R_GlobalEnv, &hadError); >> } >> UNPROTECT(2); >> >> end_R(); >> return(0); >> } -- Mikhail ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel