Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Peter Dalgaard wrote: > Herve Pages wrote: [...] >> So everybody seems to assume that SET_ELEMENT(), SET_STRING_ELT(), >> SET_NAMES(), etc... can't (and will never) trigger garbage collection. >> But what about defineVar()? More generally, how do I know this for the >> functions/macros listed in Rdefines.h and Rinternals.h? >> > Yes, that point was well taken. You can't know unless we write it > somewhere. You can read the sources, but that is no guarantee that it > won't change in future versions. We should be better at documenting that > stuff, if for no other reason then to be able to distinguish between > YOUR bugs and OUR bugs. > If you grep through the sources, you'll find a number of instances of > things like > > defineVar(name, mkPromise(...), ...) > > which would break along with your case, but that is of course only an > indication, not proof that you can actually leave the value unprotected. > Agreed. Thanks for your reply! H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Herve Pages wrote: > Peter Dalgaard wrote: >> >> That's not the problem you raised (argument evaluation order), but >> there's a CONS inside defineVar, and as far as I can see, it doesn't >> protect its arguments, so you could well be right. >> > > This problem is related to my original problem since it would cause the same > disaster: garbage collection on my unprotected SEXP. > Sure, I just wasn't looking there because you told me to look elsewhere > The more general problem I'm facing is to know whether or not it is safe to > use a function like mkans() (that returns an unprotected SEXP) like this: > > SET_ELEMENT(ans, 0, mkans(x)); > > In the case of SET_ELEMENT() or SET_STRING_ELT() it seems to be safe. For > example I've seen this > > SET_STRING_ELT(ans, 0, mkChar(buf)); > > in many places. So I'm using it too, even if the SEXP returned by mkChar() > is not protected. > Same here: > > SET_ELEMENT(ans, 0, duplicate(x)); > > The SEXP returned by duplicate() is not protected. > > So everybody seems to assume that SET_ELEMENT(), SET_STRING_ELT(), > SET_NAMES(), etc... can't (and will never) trigger garbage collection. > But what about defineVar()? More generally, how do I know this for the > functions/macros listed in Rdefines.h and Rinternals.h? > > Yes, that point was well taken. You can't know unless we write it somewhere. You can read the sources, but that is no guarantee that it won't change in future versions. We should be better at documenting that stuff, if for no other reason then to be able to distinguish between YOUR bugs and OUR bugs. If you grep through the sources, you'll find a number of instances of things like defineVar(name, mkPromise(...), ...) which would break along with your case, but that is of course only an indication, not proof that you can actually leave the value unprotected. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Peter Dalgaard wrote: > Herve Pages wrote: >> Hi Peter, >> >> Peter Dalgaard wrote: >> >>> Herve Pages wrote: >>> Hi, I'm wondering if this code from the "Writing R Extensions" manual is really safe: SEXP mkans(double x) { SEXP ans; PROTECT(ans = allocVector(REALSXP, 1)); REAL(ans)[0] = x; UNPROTECT(1); return ans; } double feval(double x, SEXP f, SEXP rho) { defineVar(install("x"), mkans(x), rho); return(REAL(eval(f, rho))[0]); } In C, the order in which function arguments are evaluated before the function itself is called is undefined. Hence there is no guarantee that install("x") will be evaluated before mkans(x). What happens if mkans(x) is evaluated first? Then install("x") will be called and eventually trigger garbage collection while the SEXP returned by mkans(x) is still unprotected. I'm asking because I'm getting all sorts of problems with defineVar(install(somekey), mkans(x), rho); In my code this line is inside a big loop (hundred of thousands of iterations) so I end up with a lot of symbols in the rho environment. The problems I've seen are hard to reproduce: sometimes it's a segfault, sometimes a "cons memory exhausted" error, or sometimes everything looks fine except that, later, when I retrieve values from the rho environment with findVar(), some of them are altered! But if I replace the above line by: PROTECT(ans = mkans(x)); defineVar(install(somekey), ans, rho); UNPROTECT(1); then everything works fine :-) >>> Sounds like you are right. You don't really have the "smoking gun", but >>> it doesn't seem to be worth trying to catch the actual bug in action >>> with hardware watchpoints and whatnot. >>> >>> The opposite fix should work too (does it?): >>> >>> { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);} >>> >> So now you are protected against install(somekey) eventually triggering >> garbage collection but you are still not protected against defineVar() itself >> triggering garbage collection. Maybe defineVar() does not do that, and will >> never do it, but isn't it risky to rely on this kind of assumption? >> >> Thanks! >> H. >> > That's not the problem you raised (argument evaluation order), but > there's a CONS inside defineVar, and as far as I can see, it doesn't > protect its arguments, so you could well be right. This problem is related to my original problem since it would cause the same disaster: garbage collection on my unprotected SEXP. The more general problem I'm facing is to know whether or not it is safe to use a function like mkans() (that returns an unprotected SEXP) like this: SET_ELEMENT(ans, 0, mkans(x)); In the case of SET_ELEMENT() or SET_STRING_ELT() it seems to be safe. For example I've seen this SET_STRING_ELT(ans, 0, mkChar(buf)); in many places. So I'm using it too, even if the SEXP returned by mkChar() is not protected. Same here: SET_ELEMENT(ans, 0, duplicate(x)); The SEXP returned by duplicate() is not protected. So everybody seems to assume that SET_ELEMENT(), SET_STRING_ELT(), SET_NAMES(), etc... can't (and will never) trigger garbage collection. But what about defineVar()? More generally, how do I know this for the functions/macros listed in Rdefines.h and Rinternals.h? Thanks! H. > >> >>> (I don't think you need to PROTECT elements in the symbol table) >>> >>> >> > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Just-in-time compiler for R
Greetings R developers! I have been working on a just-in-time compiler for R arithmetic expressions. An example: jit(1) # turn on just-in-time compilation for(i in 1:na)# example convolution code for(j in 1:nb) ab[i + j] <- ab[i + j] + a[i] * b[j] The loop will run about 30% faster. That's not much of a speedup, but the code is still in early development and the figure will get much better. If you are interested there is more information at www.milbo.users.sonic.net/ra. Stephen Milborrow www.milbo.users.sonic.net __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Luke Tierney wrote: > On Wed, 16 Jan 2008, Peter Dalgaard wrote: > >> Herve Pages wrote: >> Hi Peter, >> >> Peter Dalgaard wrote: >> >>> Herve Pages wrote: >>> Hi, I'm wondering if this code from the "Writing R Extensions" manual is really safe: SEXP mkans(double x) { SEXP ans; PROTECT(ans = allocVector(REALSXP, 1)); REAL(ans)[0] = x; UNPROTECT(1); return ans; } double feval(double x, SEXP f, SEXP rho) { defineVar(install("x"), mkans(x), rho); return(REAL(eval(f, rho))[0]); } In C, the order in which function arguments are evaluated before the function itself is called is undefined. Hence there is no guarantee that install("x") will be evaluated before mkans(x). What happens if mkans(x) is evaluated first? Then install("x") will be called and eventually trigger garbage collection while the SEXP returned by mkans(x) is still unprotected. I'm asking because I'm getting all sorts of problems with defineVar(install(somekey), mkans(x), rho); In my code this line is inside a big loop (hundred of thousands of iterations) so I end up with a lot of symbols in the rho environment. The problems I've seen are hard to reproduce: sometimes it's a segfault, sometimes a "cons memory exhausted" error, or sometimes everything looks fine except that, later, when I retrieve values from the rho environment with findVar(), some of them are altered! But if I replace the above line by: PROTECT(ans = mkans(x)); defineVar(install(somekey), ans, rho); UNPROTECT(1); then everything works fine :-) >>> Sounds like you are right. You don't really have the "smoking gun", but >>> it doesn't seem to be worth trying to catch the actual bug in action >>> with hardware watchpoints and whatnot. >>> >>> The opposite fix should work too (does it?): >>> >>> { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);} >>> >> >> So now you are protected against install(somekey) eventually triggering >> garbage collection but you are still not protected against >> defineVar() itself >> triggering garbage collection. Maybe defineVar() does not do that, >> and will >> never do it, but isn't it risky to rely on this kind of assumption? >> >> Thanks! >> H. >> > That's not the problem you raised (argument evaluation order), but > there's a CONS inside defineVar, and as far as I can see, it doesn't > protect its arguments, so you could well be right. > CONS itself protects its arguments though. > > luke > Ah, right! (and one of them is "value"). That explains why we haven't seen crashes left right and center from this How about the hashed environment case? R_Newhashpjw and R_HashSet wouldn't need allocation, and R_HashResize is after the assignment, so I suppose it is OK. We should make this sort ot convention more explicit somehow. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
On Wed, 16 Jan 2008, Peter Dalgaard wrote: Herve Pages wrote: Hi Peter, Peter Dalgaard wrote: Herve Pages wrote: Hi, I'm wondering if this code from the "Writing R Extensions" manual is really safe: SEXP mkans(double x) { SEXP ans; PROTECT(ans = allocVector(REALSXP, 1)); REAL(ans)[0] = x; UNPROTECT(1); return ans; } double feval(double x, SEXP f, SEXP rho) { defineVar(install("x"), mkans(x), rho); return(REAL(eval(f, rho))[0]); } In C, the order in which function arguments are evaluated before the function itself is called is undefined. Hence there is no guarantee that install("x") will be evaluated before mkans(x). What happens if mkans(x) is evaluated first? Then install("x") will be called and eventually trigger garbage collection while the SEXP returned by mkans(x) is still unprotected. I'm asking because I'm getting all sorts of problems with defineVar(install(somekey), mkans(x), rho); In my code this line is inside a big loop (hundred of thousands of iterations) so I end up with a lot of symbols in the rho environment. The problems I've seen are hard to reproduce: sometimes it's a segfault, sometimes a "cons memory exhausted" error, or sometimes everything looks fine except that, later, when I retrieve values from the rho environment with findVar(), some of them are altered! But if I replace the above line by: PROTECT(ans = mkans(x)); defineVar(install(somekey), ans, rho); UNPROTECT(1); then everything works fine :-) Sounds like you are right. You don't really have the "smoking gun", but it doesn't seem to be worth trying to catch the actual bug in action with hardware watchpoints and whatnot. The opposite fix should work too (does it?): { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);} So now you are protected against install(somekey) eventually triggering garbage collection but you are still not protected against defineVar() itself triggering garbage collection. Maybe defineVar() does not do that, and will never do it, but isn't it risky to rely on this kind of assumption? Thanks! H. That's not the problem you raised (argument evaluation order), but there's a CONS inside defineVar, and as far as I can see, it doesn't protect its arguments, so you could well be right. CONS itself protects its arguments though. luke (I don't think you need to PROTECT elements in the symbol table) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Herve Pages wrote: > Hi Peter, > > Peter Dalgaard wrote: > >> Herve Pages wrote: >> >>> Hi, >>> >>> I'm wondering if this code from the "Writing R Extensions" manual >>> is really safe: >>> >>> SEXP mkans(double x) >>> { >>> SEXP ans; >>> PROTECT(ans = allocVector(REALSXP, 1)); >>> REAL(ans)[0] = x; >>> UNPROTECT(1); >>> return ans; >>> } >>> >>> double feval(double x, SEXP f, SEXP rho) >>> { >>> defineVar(install("x"), mkans(x), rho); >>> return(REAL(eval(f, rho))[0]); >>> } >>> >>> In C, the order in which function arguments are evaluated before the >>> function itself is called is undefined. Hence there is no guarantee >>> that install("x") will be evaluated before mkans(x). What happens if >>> mkans(x) is evaluated first? Then install("x") will be called and >>> eventually trigger garbage collection while the SEXP returned by >>> mkans(x) is still unprotected. >>> >>> I'm asking because I'm getting all sorts of problems with >>> >>> defineVar(install(somekey), mkans(x), rho); >>> >>> In my code this line is inside a big loop (hundred of thousands of >>> iterations) so I end up with a lot of symbols in the rho environment. >>> >>> The problems I've seen are hard to reproduce: sometimes it's a segfault, >>> sometimes a "cons memory exhausted" error, or sometimes everything looks >>> fine except that, later, when I retrieve values from the rho environment >>> with findVar(), some of them are altered! >>> >>> But if I replace the above line by: >>> >>> PROTECT(ans = mkans(x)); >>> defineVar(install(somekey), ans, rho); >>> UNPROTECT(1); >>> >>> then everything works fine :-) >>> >>> >>> >> Sounds like you are right. You don't really have the "smoking gun", but >> it doesn't seem to be worth trying to catch the actual bug in action >> with hardware watchpoints and whatnot. >> >> The opposite fix should work too (does it?): >> >> { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);} >> > > So now you are protected against install(somekey) eventually triggering > garbage collection but you are still not protected against defineVar() itself > triggering garbage collection. Maybe defineVar() does not do that, and will > never do it, but isn't it risky to rely on this kind of assumption? > > Thanks! > H. > That's not the problem you raised (argument evaluation order), but there's a CONS inside defineVar, and as far as I can see, it doesn't protect its arguments, so you could well be right. > >> (I don't think you need to PROTECT elements in the symbol table) >> >> > > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Hi Peter, Peter Dalgaard wrote: > Herve Pages wrote: >> Hi, >> >> I'm wondering if this code from the "Writing R Extensions" manual >> is really safe: >> >> SEXP mkans(double x) >> { >> SEXP ans; >> PROTECT(ans = allocVector(REALSXP, 1)); >> REAL(ans)[0] = x; >> UNPROTECT(1); >> return ans; >> } >> >> double feval(double x, SEXP f, SEXP rho) >> { >> defineVar(install("x"), mkans(x), rho); >> return(REAL(eval(f, rho))[0]); >> } >> >> In C, the order in which function arguments are evaluated before the >> function itself is called is undefined. Hence there is no guarantee >> that install("x") will be evaluated before mkans(x). What happens if >> mkans(x) is evaluated first? Then install("x") will be called and >> eventually trigger garbage collection while the SEXP returned by >> mkans(x) is still unprotected. >> >> I'm asking because I'm getting all sorts of problems with >> >> defineVar(install(somekey), mkans(x), rho); >> >> In my code this line is inside a big loop (hundred of thousands of >> iterations) so I end up with a lot of symbols in the rho environment. >> >> The problems I've seen are hard to reproduce: sometimes it's a segfault, >> sometimes a "cons memory exhausted" error, or sometimes everything looks >> fine except that, later, when I retrieve values from the rho environment >> with findVar(), some of them are altered! >> >> But if I replace the above line by: >> >> PROTECT(ans = mkans(x)); >> defineVar(install(somekey), ans, rho); >> UNPROTECT(1); >> >> then everything works fine :-) >> >> > Sounds like you are right. You don't really have the "smoking gun", but > it doesn't seem to be worth trying to catch the actual bug in action > with hardware watchpoints and whatnot. > > The opposite fix should work too (does it?): > > { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);} So now you are protected against install(somekey) eventually triggering garbage collection but you are still not protected against defineVar() itself triggering garbage collection. Maybe defineVar() does not do that, and will never do it, but isn't it risky to rely on this kind of assumption? Thanks! H. > > (I don't think you need to PROTECT elements in the symbol table) > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data types / numerative system
On Wed, 16 Jan 2008, Duncan Murdoch wrote: > On 1/16/2008 10:30 AM, [EMAIL PROTECTED] wrote: >> hello all, >> >> well it is a general question, surely this is written somewhere but I cannot >> find it. >> where is the full list of 'shortcuts' for numerative systems? >> (so 0x123 : hex, 123L : dec(?... or is it for a... long datatype?)) >> are there in R 'shortcuts' for data types? > > You want to look in the section on "Constants" of the R Language > References (Section 3.1.1 in the PDF version in 2.6.1). Or ?NumericConstants, linked from ?Syntax. (The online help tends to be more up-to-date then that _draft_ reference manual.) > > In summary: the 0x prefix indicates hex, the L suffix indicates the > integer type. > > Duncan Murdoch > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data types / numerative system
On 1/16/2008 10:30 AM, [EMAIL PROTECTED] wrote: > hello all, > > well it is a general question, surely this is written somewhere but I cannot > find it. > where is the full list of 'shortcuts' for numerative systems? > (so 0x123 : hex, 123L : dec(?... or is it for a... long datatype?)) > are there in R 'shortcuts' for data types? You want to look in the section on "Constants" of the R Language References (Section 3.1.1 in the PDF version in 2.6.1). In summary: the 0x prefix indicates hex, the L suffix indicates the integer type. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] data types / numerative system
hello all, well it is a general question, surely this is written somewhere but I cannot find it. where is the full list of 'shortcuts' for numerative systems? (so 0x123 : hex, 123L : dec(?... or is it for a... long datatype?)) are there in R 'shortcuts' for data types? thanks, Alex -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] %s in filename when opening device causes crash (PR#10571)
On Wed, 16 Jan 2008, Richard Cotton wrote: > > > > Prof Brian Ripley wrote: >> >>> Yes. The problem is of course that we do want a sprintf() format there >>> for "Rplot%03d.pdf" et al. One option would be to escape "%" except >>> when in (regexp) "%[0-9]*d", which seems nontrivial, but not impossible. >> >> But there are other integer formats (%i, %u, %x, %X), and other flags (# >> might be useful). So the list of valid inputs is also rather long. It >> would be tedious to do at C level, but a check in the R-level wrapper >> would be easier (if not 'simple'). >> > > Having just worked my way through the alphabet, I can say that it is only > the letters 's' and 'n' that cause any problems. Thus, if you do decide to > handle the error in the R wrapper functions, the regex for bad inputs is > fairly straightforward "%[#[:blank:]\\+\\-]*[[:digit:]]*[sn]". Thanks: but %% (escaped %) should be allowed (and only ASCII blank is allowed as a flag, and only ASCII digits). We decided to do the opposite and test for an allowed format (you are only allowed to have one). So the current check is ### Check for a single valid integer format checkIntFormat <- function(s) { ## OK if no unescaped %, so first remove those s <- gsub("%%", "", s) if(length(grep("%", s)) == 0) return(TRUE) ## now remove at most one valid(ish) integer format s <- sub("%[#0 +-]*[0-9.]*[diouxX]", "", s) length(grep("%", s)) == 0 } The set of flags is debatable, and not yet final. Not all strings that pass that test are valid formats, but hopefully the exceptions are - rare - will not crash R. Empirical testing of crashing is not comprehensive and machine-dependent even if you use a tool like valgrind to detect violations (32- vs 64-bit issues, for example). Unfortunately there *is* a C-level call to the postscript driver, so some C-level checking is needed. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] %s in filename when opening device causes crash (PR#10571)
Richard Cotton wrote: > > Prof Brian Ripley wrote: > >>> Yes. The problem is of course that we do want a sprintf() format there >>> for "Rplot%03d.pdf" et al. One option would be to escape "%" except >>> when in (regexp) "%[0-9]*d", which seems nontrivial, but not impossible. >>> >> But there are other integer formats (%i, %u, %x, %X), and other flags (# >> might be useful). So the list of valid inputs is also rather long. It >> would be tedious to do at C level, but a check in the R-level wrapper >> would be easier (if not 'simple'). >> >> > > Having just worked my way through the alphabet, I can say that it is only > the letters 's' and 'n' that cause any problems. Thus, if you do decide to > handle the error in the R wrapper functions, the regex for bad inputs is > fairly straightforward "%[#[:blank:]\\+\\-]*[[:digit:]]*[sn]". > Not quite. The floating point formats are also problematic; you may fetch 8 bytes where only 4 was allocated. Also, %%s should not be forbidden. Anyways, I believe Brian has this in hand. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] %s in filename when opening device causes crash (PR#10571)
Prof Brian Ripley wrote: > >> Yes. The problem is of course that we do want a sprintf() format there >> for "Rplot%03d.pdf" et al. One option would be to escape "%" except >> when in (regexp) "%[0-9]*d", which seems nontrivial, but not impossible. > > But there are other integer formats (%i, %u, %x, %X), and other flags (# > might be useful). So the list of valid inputs is also rather long. It > would be tedious to do at C level, but a check in the R-level wrapper > would be easier (if not 'simple'). > Having just worked my way through the alphabet, I can say that it is only the letters 's' and 'n' that cause any problems. Thus, if you do decide to handle the error in the R wrapper functions, the regex for bad inputs is fairly straightforward "%[#[:blank:]\\+\\-]*[[:digit:]]*[sn]". -- View this message in context: http://www.nabble.com/-s-in-filename-when-opening-device-causes-crash-%28PR-10571%29-tp14806982p14877649.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual
Herve Pages wrote: > Hi, > > I'm wondering if this code from the "Writing R Extensions" manual > is really safe: > > SEXP mkans(double x) > { > SEXP ans; > PROTECT(ans = allocVector(REALSXP, 1)); > REAL(ans)[0] = x; > UNPROTECT(1); > return ans; > } > > double feval(double x, SEXP f, SEXP rho) > { > defineVar(install("x"), mkans(x), rho); > return(REAL(eval(f, rho))[0]); > } > > In C, the order in which function arguments are evaluated before the > function itself is called is undefined. Hence there is no guarantee > that install("x") will be evaluated before mkans(x). What happens if > mkans(x) is evaluated first? Then install("x") will be called and > eventually trigger garbage collection while the SEXP returned by > mkans(x) is still unprotected. > > I'm asking because I'm getting all sorts of problems with > > defineVar(install(somekey), mkans(x), rho); > > In my code this line is inside a big loop (hundred of thousands of > iterations) so I end up with a lot of symbols in the rho environment. > > The problems I've seen are hard to reproduce: sometimes it's a segfault, > sometimes a "cons memory exhausted" error, or sometimes everything looks > fine except that, later, when I retrieve values from the rho environment > with findVar(), some of them are altered! > > But if I replace the above line by: > > PROTECT(ans = mkans(x)); > defineVar(install(somekey), ans, rho); > UNPROTECT(1); > > then everything works fine :-) > > Sounds like you are right. You don't really have the "smoking gun", but it doesn't seem to be worth trying to catch the actual bug in action with hardware watchpoints and whatnot. The opposite fix should work too (does it?): { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);} (I don't think you need to PROTECT elements in the symbol table) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel