Re: [Rd] .Call - applying setAttrib(x, R_DimSymbol, s) to a matrix being an element of a list
Dear Simon,
> you gave us only a fragment of your code, so I can only guess what
the problem is:
> What is imgSize? The behavior you describe seems as if you re-using
the imgSize SEXP in all elements.
> AFAIR in your case setAttrib doesn't copy the value, so you need to
do so yourself (or alloc new dim array
> for each element).
Sorry, it is always a tradeoff - either to explain or put a relatively
large code, which also uses non-standard libraries making the code
difficult to read. imgSize values are reset in between: see the full
code below. The SEXP pointer imgSize stays in tact, that's true, but its
values are changed (the problem is, they are always the last in the
row). I.e. if I have 3 images 40x20, 200x100 and 150x75 I will get three
matrices of 150x75, but if I omit setAtrib and return vectors I get
vectors of different length.
Oleg
SEXP load2DImages(SEXP fileNames) {
int nFiles = LENGTH(fileNames);
std::cout << "Loading " << nFiles << " files..." << std::endl;
// SEXP result = allocList(nFiles);
SEXP result = allocVector(VECSXP, nFiles);
PROTECT(result);
SEXP imgSize = allocVector(INTSXP, 2);
PROTECT(imgSize);
TRGB2DImage::Pointer image;
TRGB2DReader::Pointer reader = TRGB2DReader::New();
TRGB2DImage::SizeType size;
TRGB2DImage::IndexType pixIndex;
for (int i = 0; i < nFiles; i++) {
try {
char *filename = CHAR(asChar(VECTOR_ELT(fileNames, i)));
std::cout << std::endl << "Loading image file " << filename
<< "... ";
reader->SetFileName(filename);
reader->Update();
image = reader->GetOutput();
} catch(...) {
std::cout << "failed!";
continue;
}
std::cout << std::endl;
size = image->GetLargestPossibleRegion().GetSize();
INTEGER(imgSize)[0] = size[1];
INTEGER(imgSize)[1] = size[0];
std::cout << size[0] << " x " << size[1] << std::endl;
SET_VECTOR_ELT(result, i, allocVector(INTSXP, size[0] * size[1]));
SEXP element = VECTOR_ELT(result, i);
for (int ix = 0; ix < size[0]; ix++) {
pixIndex[0] = ix;
for (int iy = 0; iy < size[1]; iy++) {
pixIndex[1] = iy;
INTEGER(element)[size[1] * ix + iy] =
getIntRGBColour(image->GetPixel(pixIndex));
}
}
setAttrib(element, R_DimSymbol, imgSize);
}
UNPROTECT(2);
if (nFiles == 1)
return VECTOR_ELT(result, 0);
else
return result;
}
Dr Oleg Sklyar
European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
England
phone/fax +44(0)1223 49 4478/4468
e-mail [EMAIL PROTECTED]
Simon Urbanek wrote:
Oleg,
you gave us only a fragment of your code, so I can only guess what the
problem is:
On Mar 16, 2005, at 12:40 PM, Oleg Sklyar wrote:
// converting element into a matrix
setAttrib(element, R_DimSymbol, imgSize);
What is imgSize? The behavior you describe seems as if you re-using
the imgSize SEXP in all elements. AFAIR in your case setAttrib doesn't
copy the value, so you need to do so yourself (or alloc new dim array
for each element).
Cheers,
Simon
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] authentication support question
I need to obtain username and password strings from the user of a certain process running in R. scan() can be used to get the strings, but the password will be echoed back as the user types it. Is there any way to load keyboard input to a variable without echoing the input back to the screen? Thanks __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: Write Barrier: was: [Rd] function-like macros undefined
On Wed, 16 Mar 2005, Vadim Ogranovich wrote: My actual problem was with the RAW() macro, it is not available as a function. I used INTEGER as an illustration because it was in the same group of macros, I guess I shouldn't have. It *is* available in R-devel, soon to be 2.1.0: the function was overlooked for 2.0.x. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: Write Barrier: was: [Rd] function-like macros undefined
Luke, My actual problem was with the RAW() macro, it is not available as a function. I used INTEGER as an illustration because it was in the same group of macros, I guess I shouldn't have. Thank you for your other comments. I was confused, somehow I thought that in 2.0.x ALL access, even to the atomic vectors, should be done via macros/functions. Thanks, Vadim > -Original Message- > From: Luke Tierney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 16, 2005 11:08 AM > To: Vadim Ogranovich > Cc: r-devel@stat.math.ethz.ch > Subject: Re: Write Barrier: was: [Rd] function-like macros undefined > > Your original question was about macro-like functions. > INTEGER is available to internal R code as a macro; it is > also available as a function. Code in packages that uses > standard hearders will see the function, which is declared as > > int *(INTEGER)(SEXP x); > > I have no idea why you wanted to check whether INTEGER is a > macro or not. The value returned is a pointer to the raw int > data which you can (ab)use like any other such pointer. > > On Wed, 16 Mar 2005, Vadim Ogranovich wrote: > > > Hi, > > > > Thank you to Duncan Murdoch for pointing to > > http://www.stat.uiowa.edu/~luke/R/barrier.html. > > I have a couple of questions in this regard: > > > > * suppose that inside a C function I have a SEXP vector x > of integers > > and I want to increment each element by one. I understand that > > > > int * xIPtr = INTEGER(x); > > int i; > > > > for (i=0; i > SET_VECTOR_ELT(x, i, xIPtr[i]+1); > > > > The declaration of SET_VECTOR_ELT is > > SEXP (SET_VECTOR_ELT)(SEXP x, int i, SEXP v); > > Your compiler had better complain about your third argument. > > > is the recommended way of doing it. However it seems that only the > > very first call to SET_VECTOR_ELT, i.e. the one that corresponds to > > i=0, is strictly necessary. For example, and this is my > question, the > > following should be perfectly safe: > > > > SET_VECTOR_ELT(x, 0, xIPtr[0]); > > > > for (i=0; i > ++xIPtr[i]; > > > > > Admittedly this looks a bit odd and breaks if LENGTH(x) is > zero, but > > it illustrates the point. > > > > * Now, if the above variation is safe, maybe there is a macro that > > simply marks atomic SEXP-s, i.g. integers and doubles, for > modification? > > Vectors of non-SEXP objects are not a problem--that is why > REAL, INTEGER, etc are available as functions to access the > raw data pointers. Only vectors of SEXP's (i.e. generic and > character vector > objects) need to go through the write barrier. > > > * The "Write Barrier" document has a section "Changing the > > Representation of String Vectors". Is this something which is in > > works, or planned, for future versions? It would be great > if it were, > > this should give R considerable speed boost. > > This was considered at the time but is not on the table now. > > luke > > > -- > 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: Write Barrier: was: [Rd] function-like macros undefined
Your original question was about macro-like functions. INTEGER is available to internal R code as a macro; it is also available as a function. Code in packages that uses standard hearders will see the function, which is declared as int *(INTEGER)(SEXP x); I have no idea why you wanted to check whether INTEGER is a macro or not. The value returned is a pointer to the raw int data which you can (ab)use like any other such pointer. On Wed, 16 Mar 2005, Vadim Ogranovich wrote: Hi, Thank you to Duncan Murdoch for pointing to http://www.stat.uiowa.edu/~luke/R/barrier.html. I have a couple of questions in this regard: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that int * xIPtr = INTEGER(x); int i; for (i=0; i The declaration of SET_VECTOR_ELT is SEXP (SET_VECTOR_ELT)(SEXP x, int i, SEXP v); Your compiler had better complain about your third argument. is the recommended way of doing it. However it seems that only the very first call to SET_VECTOR_ELT, i.e. the one that corresponds to i=0, is strictly necessary. For example, and this is my question, the following should be perfectly safe: SET_VECTOR_ELT(x, 0, xIPtr[0]); for (i=0; i Admittedly this looks a bit odd and breaks if LENGTH(x) is zero, but it illustrates the point. * Now, if the above variation is safe, maybe there is a macro that simply marks atomic SEXP-s, i.g. integers and doubles, for modification? Vectors of non-SEXP objects are not a problem--that is why REAL, INTEGER, etc are available as functions to access the raw data pointers. Only vectors of SEXP's (i.e. generic and character vector objects) need to go through the write barrier. * The "Write Barrier" document has a section "Changing the Representation of String Vectors". Is this something which is in works, or planned, for future versions? It would be great if it were, this should give R considerable speed boost. This was considered at the time but is not on the table now. luke -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: Write Barrier: was: [Rd] function-like macros undefined
On Mar 16, 2005, at 1:34 PM, Vadim Ogranovich wrote: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that Please correct me if I'm wrong, but I thought that the write barrier applies to assignments of SEXP values only (from the doc: "... must be used for all assignments of SEXP pointers ..." - note it says "of", not "to"). When dealing with REAL/INTEGER, I believe it's still safe to use INTEGER(x)[0]=... IMHO that's logical, too, because primitive types have no 'age' to be inherited when using ggc. Cheers, Simon __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Write Barrier: was: [Rd] function-like macros undefined
Hi, Thank you to Duncan Murdoch for pointing to http://www.stat.uiowa.edu/~luke/R/barrier.html. I have a couple of questions in this regard: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that int * xIPtr = INTEGER(x); int i; for (i=0; ihttps://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call - applying setAttrib(x, R_DimSymbol, s) to a matrix being an element of a list
Oleg, you gave us only a fragment of your code, so I can only guess what the problem is: On Mar 16, 2005, at 12:40 PM, Oleg Sklyar wrote: // converting element into a matrix setAttrib(element, R_DimSymbol, imgSize); What is imgSize? The behavior you describe seems as if you re-using the imgSize SEXP in all elements. AFAIR in your case setAttrib doesn't copy the value, so you need to do so yourself (or alloc new dim array for each element). Cheers, Simon __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Call - applying setAttrib(x, R_DimSymbol, s) to a matrix being an element of a list
Dear R developers, I am writing some C code that loads multiple images into a list of R matrices. The whole R object is created within the C code. To simplify coding, elements of the list are first created as vectors and then converted to corresponding matrices using setAttrib(x, R_DimSymbol, s). Generally the code works fine except for one detail. Applying setAttrib sets ALL elements (matrices) in the list to the same size, namely to the one last applied, doesn't matter if other matrices are larger or smaller. The command is applied to an element, not to the whole list in the following way, see below. Is there any way to change the dims of an element without altering other elements in this example? Furthermore, if I skip the last command and return a list of vectors instead of a list of matrices - all vectors have different lengths corresponding to the respective image sizes. // creating the list to hold matrices SEXP result = allocVector(VECSXP, nFiles); // creating a vector for the list element i SET_VECTOR_ELT(result, i, allocVector(INTSXP, size[0] * size[1])); // getting a pointer to the element to simlify coding SEXP element = VECTOR_ELT(result, i); // writing some values to the element // converting element into a matrix setAttrib(element, R_DimSymbol, imgSize); Thanks in advance for help Oleg Dr Oleg Sklyar European Bioinformatics Institute Wellcome Trust Genome Campus Hinxton, Cambridge, CB10 1SD England phone/fax +44(0)1223 49 4478/4468 e-mail [EMAIL PROTECTED] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor iconvlist() bug in r-devel
On Wed, 16 Mar 2005, Deepayan Sarkar wrote: On Wednesday 16 March 2005 10:57, Prof Brian Ripley wrote: On Wed, 16 Mar 2005, Deepayan Sarkar wrote: On Wednesday 16 March 2005 10:11, Prof Brian Ripley wrote: That file is created by $(top_builddir)/library/$(pkg)/iconvlist: most @iconv -l > $@ 2> /dev/null || touch $@ What version of iconv -l is that produces such a list? That in glibc 2.3.4 does not produce the header when redirected. I have version '2.3.2.ds1-20' on Debian testing. '--silent' doesn't help. I found an old RH9 system that did the same thing. Your fix is not safe: iconv in libiconv produces items separated by space or newline. Looks like we will have to work harder to distinguish the two. Can anything with a lowercase letter be safely rejected? That would bring the spurious names down to 2 (FROM and TO). No. I think what we can do is to look to see if most lines end in //, and if so assume glibc format. Yes, that should be good enough. Actually, the matches intended by the glibc version seems to be those that look like "^.*/.*/$". In particular, there are names like ISO-10646/UCS2/ ISO-10646/UCS4/ ISO-10646/UTF-8/ ISO-10646/UTF8/ which should end up as ISO-10646/UCS2, ISO-10646/UCS4, ISO-10646/UTF-8, ISO-10646/UTF8 but currently end up as [545] "ISO-10646/UCS2/""ISO-10646/UCS4/" [547] "ISO-10646/UTF-8/" "ISO-10646/UTF8/" I don't think so, and neither variant is in the human-readable list. The only documentation I have seen (a comment which said this, and `don't ask') suggests that only those ending in // are valid, and indeed that is all that gets through the most recent change. The libiconv equivalents look like ISO-10646-UCS-2 ISO-10646-UCS-4 You only need UCS-2 and UCS-4, with LE and BE variants. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor iconvlist() bug in r-devel
On Wednesday 16 March 2005 10:57, Prof Brian Ripley wrote: > On Wed, 16 Mar 2005, Deepayan Sarkar wrote: > > On Wednesday 16 March 2005 10:11, Prof Brian Ripley wrote: > >> That file is created by > >> > >> $(top_builddir)/library/$(pkg)/iconvlist: most > >> @iconv -l > $@ 2> /dev/null || touch $@ > >> > >> What version of iconv -l is that produces such a list? That in > >> glibc 2.3.4 does not produce the header when redirected. > > > > I have version '2.3.2.ds1-20' on Debian testing. '--silent' doesn't > > help. > > I found an old RH9 system that did the same thing. > > >> Your fix is not safe: iconv in libiconv produces items separated > >> by space or newline. Looks like we will have to work harder to > >> distinguish the two. > > > > Can anything with a lowercase letter be safely rejected? That would > > bring the spurious names down to 2 (FROM and TO). > > No. I think what we can do is to look to see if most lines end in > //, and if so assume glibc format. Yes, that should be good enough. Actually, the matches intended by the glibc version seems to be those that look like "^.*/.*/$". In particular, there are names like ISO-10646/UCS2/ ISO-10646/UCS4/ ISO-10646/UTF-8/ ISO-10646/UTF8/ which should end up as ISO-10646/UCS2, ISO-10646/UCS4, ISO-10646/UTF-8, ISO-10646/UTF8 but currently end up as [545] "ISO-10646/UCS2/""ISO-10646/UCS4/" [547] "ISO-10646/UTF-8/" "ISO-10646/UTF8/" The libiconv equivalents look like ISO-10646-UCS-2 ISO-10646-UCS-4 which should be fine as they are. Deepayan __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor iconvlist() bug in r-devel
On Wed, 16 Mar 2005, Deepayan Sarkar wrote:
On Wednesday 16 March 2005 10:11, Prof Brian Ripley wrote:
That file is created by
$(top_builddir)/library/$(pkg)/iconvlist: most
@iconv -l > $@ 2> /dev/null || touch $@
What version of iconv -l is that produces such a list? That in glibc
2.3.4 does not produce the header when redirected.
I have version '2.3.2.ds1-20' on Debian testing. '--silent' doesn't
help.
I found an old RH9 system that did the same thing.
Your fix is not safe: iconv in libiconv produces items separated by
space or newline. Looks like we will have to work harder to
distinguish the two.
Can anything with a lowercase letter be safely rejected? That would
bring the spurious names down to 2 (FROM and TO).
No. I think what we can do is to look to see if most lines end in //, and
if so assume glibc format.
Brian
Deepayan
Brian
On Wed, 16 Mar 2005, Deepayan Sarkar wrote:
This is on r-devel from 2005-03-15. iconvlist() uses (at least some
of the time)
icfile <- system.file("iconvlist", package = "utils")
which looks like
"""
The following list contain all the coded character sets known.
This does not necessarily mean that all combinations of these names
can be used for the FROM and TO command line parameters. One coded
character set can be listed with several different names (aliases).
437//
500//
.
.
.
"""
which leads to
tail(iconvlist(), n = 40)
[1] "WS2" "YU" "all" "all"
"and" [6] "be" "be" "can" "can"
"character" [11] "character""coded""coded"
"combinations" "command" [16] "contain" "different""does"
"following""for" [21] "known." "line"
"list" "listed" "mean" [26] "names""names"
"necessarily" "not" "of" [31] "parameters." "set"
"sets" "several" "that" [36] "the"
"the" "these""used" "with"
A possible fix seems to be to replace
ext <- readLines(icfile)
by
ext <- grep("/$", readLines(icfile), value = TRUE)
but I don't know if that's guaranteed to work.
-Deepayan
__
R-devel@stat.math.ethz.ch 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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor iconvlist() bug in r-devel
On Wednesday 16 March 2005 10:11, Prof Brian Ripley wrote:
> That file is created by
>
> $(top_builddir)/library/$(pkg)/iconvlist: most
> @iconv -l > $@ 2> /dev/null || touch $@
>
> What version of iconv -l is that produces such a list? That in glibc
> 2.3.4 does not produce the header when redirected.
I have version '2.3.2.ds1-20' on Debian testing. '--silent' doesn't
help.
> Your fix is not safe: iconv in libiconv produces items separated by
> space or newline. Looks like we will have to work harder to
> distinguish the two.
Can anything with a lowercase letter be safely rejected? That would
bring the spurious names down to 2 (FROM and TO).
Deepayan
> Brian
>
> On Wed, 16 Mar 2005, Deepayan Sarkar wrote:
> > This is on r-devel from 2005-03-15. iconvlist() uses (at least some
> > of the time)
> >
> > icfile <- system.file("iconvlist", package = "utils")
> >
> > which looks like
> >
> > """
> > The following list contain all the coded character sets known.
> > This does not necessarily mean that all combinations of these names
> > can be used for the FROM and TO command line parameters. One coded
> > character set can be listed with several different names (aliases).
> >
> > 437//
> > 500//
> > .
> > .
> > .
> > """
> >
> > which leads to
> >
> >> tail(iconvlist(), n = 40)
> >
> > [1] "WS2" "YU" "all" "all"
> > "and" [6] "be" "be" "can" "can"
> > "character" [11] "character""coded""coded"
> > "combinations" "command" [16] "contain" "different""does"
> >"following""for" [21] "known." "line"
> > "list" "listed" "mean" [26] "names""names"
> > "necessarily" "not" "of" [31] "parameters." "set"
> > "sets" "several" "that" [36] "the"
> > "the" "these""used" "with"
> >
> > A possible fix seems to be to replace
> >
> >ext <- readLines(icfile)
> >
> > by
> >
> >ext <- grep("/$", readLines(icfile), value = TRUE)
> >
> > but I don't know if that's guaranteed to work.
> >
> > -Deepayan
> >
> > __
> > R-devel@stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor iconvlist() bug in r-devel
That file is created by
$(top_builddir)/library/$(pkg)/iconvlist: most
@iconv -l > $@ 2> /dev/null || touch $@
What version of iconv -l is that produces such a list? That in glibc
2.3.4 does not produce the header when redirected.
Your fix is not safe: iconv in libiconv produces items separated by space
or newline. Looks like we will have to work harder to distinguish the
two.
Brian
On Wed, 16 Mar 2005, Deepayan Sarkar wrote:
This is on r-devel from 2005-03-15. iconvlist() uses (at least some of
the time)
icfile <- system.file("iconvlist", package = "utils")
which looks like
"""
The following list contain all the coded character sets known. This
does not necessarily mean that all combinations of these names can be
used for the FROM and TO command line parameters. One coded character
set can be listed with several different names (aliases).
437//
500//
.
.
.
"""
which leads to
tail(iconvlist(), n = 40)
[1] "WS2" "YU" "all" "all" "and"
[6] "be" "be" "can" "can" "character"
[11] "character""coded""coded" "combinations" "command"
[16] "contain" "different""does" "following""for"
[21] "known." "line" "list" "listed" "mean"
[26] "names""names""necessarily" "not" "of"
[31] "parameters." "set" "sets" "several" "that"
[36] "the" "the" "these""used" "with"
A possible fix seems to be to replace
ext <- readLines(icfile)
by
ext <- grep("/$", readLines(icfile), value = TRUE)
but I don't know if that's guaranteed to work.
-Deepayan
__
R-devel@stat.math.ethz.ch 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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] minor iconvlist() bug in r-devel
This is on r-devel from 2005-03-15. iconvlist() uses (at least some of
the time)
icfile <- system.file("iconvlist", package = "utils")
which looks like
"""
The following list contain all the coded character sets known. This
does not necessarily mean that all combinations of these names can be
used for the FROM and TO command line parameters. One coded character
set can be listed with several different names (aliases).
437//
500//
.
.
.
"""
which leads to
> tail(iconvlist(), n = 40)
[1] "WS2" "YU" "all" "all" "and"
[6] "be" "be" "can" "can" "character"
[11] "character""coded""coded" "combinations" "command"
[16] "contain" "different""does" "following""for"
[21] "known." "line" "list" "listed" "mean"
[26] "names""names""necessarily" "not" "of"
[31] "parameters." "set" "sets" "several" "that"
[36] "the" "the" "these""used" "with"
A possible fix seems to be to replace
ext <- readLines(icfile)
by
ext <- grep("/$", readLines(icfile), value = TRUE)
but I don't know if that's guaranteed to work.
-Deepayan
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] function-like macros undefined
On Tue, 15 Mar 2005 18:58:32 -0800, "Vadim Ogranovich"
<[EMAIL PROTECTED]> wrote :
>Hi,
>
>Somehow function-like macros from Rinternals.h are not defined when I
>include the file.
>
>foo.c
>##
>#include
>#include
>
>
>#ifndef NILSXP
>#error("NILSXP")
>#endif
>
>
>#ifndef INTEGER
>#error("INTEGER")
>#endif
>###
>
>
>When compiled:
>vor/src% gcc -I/usr/local/lib/R/include -g -O2 -c foo.c -o foo.o
>foo.c:11:2: #error ("INTEGER")
>
>Note that NILSXP is defined. This is true for some other function-like
>macros, e.g. RAW()
The definition of INTEGER is wrapped in
#ifdef USE_RINTERNALS
and there's this comment in Defn.h:
/* To test the write barrier used by the generational collector,
define TESTING_WRITE_BARRIER. This makes the internal structure of
SEXPRECs visible only inside of files that explicitly define
USE_RINTERNALS, and all uses of SEXPREC fields that do not go
through the appropriate functions or macros will become compilation
errors. Since this does impose a small but noticable performance
penalty, code that includes Defn.h (or code that explicitly defines
USE_RINTERNALS) can access a SEXPREC's fields directly. */
To read about the reasons for the write barrier, see
http://www.stat.uiowa.edu/~luke/R/barrier.html
Duncan Murdoch
>
>
>Did anyone come across such a problem?
>
>> version
> _
>platform x86_64-unknown-linux-gnu
>arch x86_64
>os linux-gnu
>system x86_64, linux-gnu
>status
>major2
>minor0.1
>year 2004
>month11
>day 15
>language R
>
>
>OS: suse.9.2_64
>
>Note also that R doesn't recognize this is Suse, it says
>x86_64-unknown-linux-gnu. Hope this is not a problem.
>
>Thanks,
>Vadim
>
> [[alternative HTML version deleted]]
>
>__
>R-devel@stat.math.ethz.ch mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Documentation: add link from "::" to "get" (PR#7729)
Full_Name: Dirk Koschuetzki Version: 2.0.1 OS: Linux (Debian Sarge) Submission from: (NULL) (194.94.136.34) Please add a link from the page for "::" (accessing from name spaces) to the more general "get". Reason: Some package do not provide a name space add via "get" a (seoncd) method exists to call a masked function. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trigonometric functions (PR#7728)
On Mar 15, 2005, at 11:26 pm, Thomas Lumley wrote: On Wed, 16 Mar 2005, Peter Kleiweg wrote: Thomas Lumley schreef op de 15e dag van de lentemaand van het jaar 2005: x<-sqrt(2) asin(x^2-1) result in: NaN The way I would deal with this would be to force asin() to work in complex mode: > x <- sqrt(2) > asin(x^2-1+0i) [1] 1.570796+2.980232e-08i > (the error is large because the derivative of arcsin is infinite at x=1). -- Robin Hankin Uncertainty Analyst Southampton Oceanography Centre European Way, Southampton SO14 3ZH, UK tel 023-8059-7743 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
