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
[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] 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
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] 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] 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
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
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
[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
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
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: [...] 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
