[Rd] problem in compililng c code using R CMD SHLIB
Hello all, I was trying to compile a simple C program hello.c using R CMD SHLIB hello.c. MY R software residing in C:\Program Files\R\R-2.15.0, and also I have downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in E:\R_dir. I have followed the procedures given below 1. In a new CMD.exe window I have set the path as c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin 2. I have changed the directory to E:\ where my file(hello.c) is residing E:\cd \R_dir then I have given the command like this E:\cd \R_dir R CMD SHLIB hello.c Then I am getting the following message cygwin warning: MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ i386/Makeconf Preferred POSIX equivalent is: /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Even though I have gone through several discussions in the same topic I am not able to resolve my problem. It would be a great help if somebody knows what exactly the problem and its solution and favorable suggestions. Thank you [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tcltk wish: Add tclObj.raw method for converting raw vectors to tclObj
Greetings, I have submitted a bug report / wish to the R Bug tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14939), but I'd like to make this request here as well. Essentially, I was wondering if it would be possible to add another c routine to be called by as.TclObj for raw vectors. Right now, as.raw() is supported for objects of type tclObj (IIRC this change was made in 2.9 after someone requested it), however there is no corresponding C routine for converting raw vectors into tclObj. I suppose the best way to do this is to create a new C routine in the tcltk package analogous to the other RObject to Tcl object routines: RTcl_ObjFromRawVector. Create a new tclObj pointer, use Tcl_NewByteArrayObj() from the Tcl C API to create a byte array of the same length as the input raw vector, and then loop through the RAWSXP object assigning each element in the vector to the Tcl byte array. I'd be happy to submit code for this patch if requested. This would be extremely helpful. I am using tcl binary sockets and this functionality would allow me to both read and write raw vectors directly from/to Tcl. I can only read raw vectors directly at the moment and have to use strings to get a raw vector into Tcl. There's also the possibility that this has been attempted and for some reason it didn't work, but I don't know why that would be the case. Thank you for your consideration! Regards, Charlie __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem in compililng c code using R CMD SHLIB
On Jun 6, 2012, at 6:16 AM, Arathy Ram wrote: Hello all, I was trying to compile a simple C program hello.c using R CMD SHLIB hello.c. MY R software residing in C:\Program Files\R\R-2.15.0, and also I have downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in E:\R_dir. I have followed the procedures given below 1. In a new CMD.exe window I have set the path as c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin 2. I have changed the directory to E:\ where my file(hello.c) is residing E:\cd \R_dir then I have given the command like this E:\cd \R_dir R CMD SHLIB hello.c Then I am getting the following message cygwin warning: MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ i386/Makeconf Preferred POSIX equivalent is: /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Even though I have gone through several discussions in the same topic I am not able to resolve my problem. It would be a great help if somebody knows what exactly the problem and its solution and favorable suggestions. There is no problem in what you posted - all you posted is merely a note from cygwin that it prefers different path style, but it's perfectly ok and doesn't affect anything. So what exactly is the problem you're having? Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stumped on re-building package vignette
[Env: Win Xp / StatET 2.0 / R 2.15.0] In my heplots package I extended the HE-examples.Rnw vignette under inst/doc. The package passes R CMD check on my machine: * using log directory 'C:/eclipse-3.7/heplots.Rcheck' * using R version 2.15.0 (2012-03-30) * using platform: i386-pc-mingw32 (32-bit) ... * checking sizes of PDF files under 'inst/doc' ... OK * checking installed files from 'inst/doc' ... OK * checking examples ... OK * checking for unstated dependencies in vignettes ... OK * checking package vignettes in 'inst/doc' ... OK * checking running R code from vignettes ... 'HE-examples.Rnw' ... OK 'repeated.Rnw' ... OK ... However, on R-Forge and on CRAN, the following error/warning is generated: Mon Jun 4 20:18:22 2012: Checking package heplots (SVN revision 136) ... * using log directory ‘/mnt/building/build_2012-06-04-20-02/RF_PKG_CHECK/PKGS/heplots.Rcheck’ * using R version 2.15.0 Patched (2012-06-03 r59505) * using platform: x86_64-unknown-linux-gnu (64-bit) ... * checking for unstated dependencies in vignettes ... OK * checking package vignettes in ‘inst/doc’ ... OK * checking running R code from vignettes ... ‘HE-examples.Rnw’ ... [4s/4s] OK ‘repeated.Rnw’ ... [4s/4s] OK [9s/9s] OK * checking re-building of vignette PDFs ... NOTE Error in re-building vignettes: ... Loading required package: car Loading required package: MASS Loading required package: nnet Error: processing vignette 'HE-examples.Rnw' failed with diagnostics: cannot open file 'fig/plot-plastic1.pdf' Execution halted * checking PDF version of manual ... OK I am unable to determine why the file fig/plot-plastic1.pdf cannot be opened. It is in my inst/doc/fig directory is regenerated by the .Rnw file. What could cause this? Second, I have tried manually running tools::compactPDF(HE-examples.pdf) on the .pdf file under inst/doc in the package, but no change is made to the .pdf file. I can't see any way to correct this. -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. York University Voice: 416 736-5115 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem in compililng c code using R CMD SHLIB
On Wed, Jun 6, 2012 at 8:20 AM, Simon Urbanek simon.urba...@r-project.org wrote: On Jun 6, 2012, at 6:16 AM, Arathy Ram wrote: Hello all, I was trying to compile a simple C program hello.c using R CMD SHLIB hello.c. MY R software residing in C:\Program Files\R\R-2.15.0, and also I have downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in E:\R_dir. I have followed the procedures given below 1. In a new CMD.exe window I have set the path as c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin 2. I have changed the directory to E:\ where my file(hello.c) is residing E:\cd \R_dir then I have given the command like this E:\cd \R_dir R CMD SHLIB hello.c Then I am getting the following message cygwin warning: MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ i386/Makeconf Preferred POSIX equivalent is: /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Even though I have gone through several discussions in the same topic I am not able to resolve my problem. It would be a great help if somebody knows what exactly the problem and its solution and favorable suggestions. There is no problem in what you posted - all you posted is merely a note from cygwin that it prefers different path style, but it's perfectly ok and doesn't affect anything. So what exactly is the problem you're having? Probably has something to do with PATH not being set correctly because the Cygwin warning points to R-2.14.0 on E:, not R-2.15.0 on C:. Cheers, Simon Best, -- Joshua Ulrich | FOSS Trading: www.fosstrading.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem in compililng c code using R CMD SHLIB
On 06/06/2012 18:12, Joshua Ulrich wrote: On Wed, Jun 6, 2012 at 8:20 AM, Simon Urbanek simon.urba...@r-project.org wrote: On Jun 6, 2012, at 6:16 AM, Arathy Ram wrote: Hello all, I was trying to compile a simple C program hello.c using R CMD SHLIB hello.c. MY R software residing in C:\Program Files\R\R-2.15.0, and also I have downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in E:\R_dir. I have followed the procedures given below 1. In a new CMD.exe window I have set the path as c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin 2. I have changed the directory to E:\ where my file(hello.c) is residing E:\cd \R_dir then I have given the command like this E:\cd \R_dir R CMD SHLIB hello.c Then I am getting the following message cygwin warning: MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ i386/Makeconf Preferred POSIX equivalent is: /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Even though I have gone through several discussions in the same topic I am not able to resolve my problem. It would be a great help if somebody knows what exactly the problem and its solution and favorable suggestions. There is no problem in what you posted - all you posted is merely a note from cygwin that it prefers different path style, but it's perfectly ok and doesn't affect anything. Or put another way, the problem is a user read failure: see below. So what exactly is the problem you're having? Probably has something to do with PATH not being set correctly because the Cygwin warning points to R-2.14.0 on E:, not R-2.15.0 on C:. But as for the note, it *is* discussed in the appropriate manual. Search for 'nodosfilewarning' in http://cran.r-project.org/doc/manuals/R-admin.html#The-command-line-tools . You most likely will need to set that environment variable. See what the posting guide has to say about doing your own homework. fortunes::fortune(14) applies. The author of the docs you discourteously ignored (and much else you are using). -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] 7 arguments passed to .Internal(identical) which requires 6
Dan Tenenbaum dtenenba at fhcrc.org writes: I know this has come up before on R-help (http://r.789695.n4.nabble.com/7-arguments-passed-to-Internal-identical-which- requires-6-td4548460.html) but I have a concise reproducible case that I wanted to share. Also, please note the Bioconductor scenario which is potentially seriously impacted by this. The issue arises when a binary version of a package (like my example package below) is built under R 2.15.0 Patched but then installed under R 2.15.0. Our package AnnotationDbi (which hundreds of other packages depend on) is impacted by this issue to the extent that calling virtually any function in it will return something like this: Error in ls(2) : 7 arguments passed to .Internal(identical) which requires 6 My concern is that when R 2.15.1 is released and Bioconductor starts building all its packages under it, that R 2.15.0 users will start to experience this problem. We can ask all users to upgrade to R 2.15.1 if we have to, but it's not usually the case that a minor point release MUST be installed in order to run packages built under it (please correct me if I'm wrong). We would much prefer a workaround or fix to make an upgrade unnecessary. I'm seeing the same issue. Installing the latest R-Forge .zip of data.table built using 2.15.0 patched, on R 2.15.0 (or 2.14.1 same issue), then running data.table(a=1:3) produces the 7 arguments passed to .Internal(identical) which requires 6 error. traceback() and debugger() just display the top level call. debug(data.table) and stepping through reveals it is a call to identical () but just a regular one. No .Internal() call in the package, let alone passing 6 or 7 arguments to .Internal. Not sure how else to debug or trace it. R-Forge is byte compiling data.table using R 2.15.0 patched (iiuc), would that make a difference when the byte code is loaded into 2.15.0 which doesn't have the new argument in identical()? Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 7 arguments passed to .Internal(identical) which requires 6
On Wed, 6 Jun 2012, Matthew Dowle wrote: Dan Tenenbaum dtenenba at fhcrc.org writes: I know this has come up before on R-help (http://r.789695.n4.nabble.com/7-arguments-passed-to-Internal-identical-which- requires-6-td4548460.html) but I have a concise reproducible case that I wanted to share. Also, please note the Bioconductor scenario which is potentially seriously impacted by this. The issue arises when a binary version of a package (like my example package below) is built under R 2.15.0 Patched but then installed under R 2.15.0. Our package AnnotationDbi (which hundreds of other packages depend on) is impacted by this issue to the extent that calling virtually any function in it will return something like this: Error in ls(2) : 7 arguments passed to .Internal(identical) which requires 6 My concern is that when R 2.15.1 is released and Bioconductor starts building all its packages under it, that R 2.15.0 users will start to experience this problem. We can ask all users to upgrade to R 2.15.1 if we have to, but it's not usually the case that a minor point release MUST be installed in order to run packages built under it (please correct me if I'm wrong). We would much prefer a workaround or fix to make an upgrade unnecessary. I'm seeing the same issue. Installing the latest R-Forge .zip of data.table built using 2.15.0 patched, on R 2.15.0 (or 2.14.1 same issue), then running data.table(a=1:3) produces the 7 arguments passed to .Internal(identical) which requires 6 error. traceback() and debugger() just display the top level call. debug(data.table) and stepping through reveals it is a call to identical () but just a regular one. No .Internal() call in the package, let alone passing 6 or 7 arguments to .Internal. Not sure how else to debug or trace it. R-Forge is byte compiling data.table using R 2.15.0 patched (iiuc), would that make a difference when the byte code is loaded into 2.15.0 which doesn't have the new argument in identical()? Yes it would. luke Matthew __ 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: luke-tier...@uiowa.edu 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] 7 arguments passed to .Internal(identical) which requires 6
FYI, Brian has backed out the changes to identical() in r59533 of R-patched. Please retry your test codes with the new version. (Due to some ISP mess-up, Brian is temporarily unable to reply in detail himself.) -pd On Jun 6, 2012, at 20:29 , luke-tier...@uiowa.edu luke-tier...@uiowa.edu wrote: On Wed, 6 Jun 2012, Matthew Dowle wrote: Dan Tenenbaum dtenenba at fhcrc.org writes: I know this has come up before on R-help (http://r.789695.n4.nabble.com/7-arguments-passed-to-Internal-identical-which- requires-6-td4548460.html) but I have a concise reproducible case that I wanted to share. Also, please note the Bioconductor scenario which is potentially seriously impacted by this. The issue arises when a binary version of a package (like my example package below) is built under R 2.15.0 Patched but then installed under R 2.15.0. Our package AnnotationDbi (which hundreds of other packages depend on) is impacted by this issue to the extent that calling virtually any function in it will return something like this: Error in ls(2) : 7 arguments passed to .Internal(identical) which requires 6 My concern is that when R 2.15.1 is released and Bioconductor starts building all its packages under it, that R 2.15.0 users will start to experience this problem. We can ask all users to upgrade to R 2.15.1 if we have to, but it's not usually the case that a minor point release MUST be installed in order to run packages built under it (please correct me if I'm wrong). We would much prefer a workaround or fix to make an upgrade unnecessary. I'm seeing the same issue. Installing the latest R-Forge .zip of data.table built using 2.15.0 patched, on R 2.15.0 (or 2.14.1 same issue), then running data.table(a=1:3) produces the 7 arguments passed to .Internal(identical) which requires 6 error. traceback() and debugger() just display the top level call. debug(data.table) and stepping through reveals it is a call to identical () but just a regular one. No .Internal() call in the package, let alone passing 6 or 7 arguments to .Internal. Not sure how else to debug or trace it. R-Forge is byte compiling data.table using R 2.15.0 patched (iiuc), would that make a difference when the byte code is loaded into 2.15.0 which doesn't have the new argument in identical()? Yes it would. luke Matthew __ 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: luke-tier...@uiowa.edu 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] suggest that as.double( something double ) not make a copy
I've been playing with passing arguments to .C(), and found that replacing as.double(x) with if(is.double(x)) x else as.double(x) saves time and avoids one copy, in the case that x is already double. I suggest modifying as.double to avoid the extra copy and just return x, when x is already double. Similarly for as.integer, etc. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggest that as.double( something double ) not make a copy
On Jun 6, 2012, at 6:53 PM, Tim Hesterberg wrote: I've been playing with passing arguments to .C(), and found that replacing as.double(x) with if(is.double(x)) x else as.double(x) saves time and avoids one copy, in the case that x is already double. No, it doesn't: x=rnorm(10) tracemem(x) [1] 0x100c59cb0 invisible(.C(foo,x)) tracemem[0x100c59cb0 - 0x100c59c30]: .C tracemem[0x100c59c30 - 0x100ca4298]: .C x=rnorm(10) tracemem(x) [1] 0x100ca41f0 invisible(.C(foo,as.double(x))) tracemem[0x100ca41f0 - 0x102cdc980]: .C tracemem[0x102cdc980 - 0x102cdca00]: .C or rather more easily: x=rnorm(10) tracemem(x) [1] 0x102ae0ff0 as.double(x) [1] -0.1027767 0.4018732 -1.3412045 0.8153615 1.8245356 -0.2147280 [7] 1.1298404 1.1026897 -1.1340612 -0.2346464 as.double(x) is not stupid and doesn't copy if not needed. However, it is a very common mistake to forget about the fact that as.double() has to strip attributes, so if you pass a matrix, you are always forcing a copy: x=matrix(0,2,2) tracemem(x) [1] 0x100b0f098 as.double(x) tracemem[0x100b0f098 - 0x1008b52c8]: [1] 0 0 0 0 That is not the fault of as.double() but rather of the user since you don't really need to strip attributes when calling .C as it doesn't care. As usual, I can only say don't use .C() ... ;) Cheers, Simon I suggest modifying as.double to avoid the extra copy and just return x, when x is already double. Similarly for as.integer, etc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggest that as.double( something double ) not make a copy
Tim Hesterberg timhesterberg at gmail.com writes:
I've been playing with passing arguments to .C(), and found that replacing
as.double(x)
with
if(is.double(x)) x else as.double(x)
saves time and avoids one copy, in the case that x is already double.
I suggest modifying as.double to avoid the extra copy and just
return x, when x is already double. Similarly for as.integer, etc.
But as.double() already doesn't copy if its argument is already double. Unless,
your double has attributes?
From coerce.c :
if(TYPEOF(x) == type) {
if(ATTRIB(x) == R_NilValue) return x;
ans = NAMED(x) ? duplicate(x) : x;
CLEAR_ATTRIB(ans);
return ans;
}
quick test :
x=1
.Internal(inspect(x))
@03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
.Internal(inspect(as.double(x))) # no copy
@03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
x=c(foo=1) # give x some attributes, say names
x
foo
1
.Internal(inspect(x))
@03E234D0 14 REALSXP g0c1 [NAM(1),ATT] (len=1, tl=0) 1
ATTRIB:
@03D54910 02 LISTSXP g0c0 []
TAG: @00380088 01 SYMSXP g0c0 [MARK,gp=0x4000] names
@03E234A0 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
@03E23560 09 CHARSXP g0c1 [gp=0x21] foo
.Internal(inspect(as.double(x))) # strips attribs returning new obj
@03E233B0 14 REALSXP g0c1 [] (len=1, tl=0) 1
as.double(x)
[1] 1
Attribute stripping is documented in ?as.double. Rather than as.double() on the
R side, you could use coerceVector() on the C side, which might be easier to
use via .Call than .C since it takes an SEXP. Looking at coerceVector in
coerce.c its first line returns immediately if type is already the desired
type, with no attribute stripping, so that seems like the way to go?
If your double has no attributes then I'm barking up the wrong tree.
Matthew
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggest that as.double( something double ) not make a copy
Check if this is the same as what was done in R v2.6.0 (2007) - from
http://cran.r-project.org/bin/windows/base/old/2.6.0/NEWS.R-2.6.0:
o as.vector() and the default methods of as.character(),
as.complex(), as.double(), as.expression(), as.integer(),
as.logical() and as.raw() no longer duplicate in most cases
where the object is unchanged. (Beware: some code has been
written that invalidly assumes that they do duplicate, often
when using .C/.Fortran(DUP=FALSE).)
See also R-devel '[Rd] Suggestion for memory optimization and
as.double() with friends', March 28-29 2007
[https://stat.ethz.ch/pipermail/r-devel/2007-March/045109.html].
/Henrik
On Wed, Jun 6, 2012 at 6:12 PM, Matthew Dowle mdo...@mdowle.plus.com wrote:
Tim Hesterberg timhesterberg at gmail.com writes:
I've been playing with passing arguments to .C(), and found that replacing
as.double(x)
with
if(is.double(x)) x else as.double(x)
saves time and avoids one copy, in the case that x is already double.
I suggest modifying as.double to avoid the extra copy and just
return x, when x is already double. Similarly for as.integer, etc.
But as.double() already doesn't copy if its argument is already double.
Unless,
your double has attributes?
From coerce.c :
if(TYPEOF(x) == type) {
if(ATTRIB(x) == R_NilValue) return x;
ans = NAMED(x) ? duplicate(x) : x;
CLEAR_ATTRIB(ans);
return ans;
}
quick test :
x=1
.Internal(inspect(x))
@03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
.Internal(inspect(as.double(x))) # no copy
@03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
x=c(foo=1) # give x some attributes, say names
x
foo
1
.Internal(inspect(x))
@03E234D0 14 REALSXP g0c1 [NAM(1),ATT] (len=1, tl=0) 1
ATTRIB:
@03D54910 02 LISTSXP g0c0 []
TAG: @00380088 01 SYMSXP g0c0 [MARK,gp=0x4000] names
@03E234A0 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
@03E23560 09 CHARSXP g0c1 [gp=0x21] foo
.Internal(inspect(as.double(x))) # strips attribs returning new obj
@03E233B0 14 REALSXP g0c1 [] (len=1, tl=0) 1
as.double(x)
[1] 1
Attribute stripping is documented in ?as.double. Rather than as.double() on
the
R side, you could use coerceVector() on the C side, which might be easier to
use via .Call than .C since it takes an SEXP. Looking at coerceVector in
coerce.c its first line returns immediately if type is already the desired
type, with no attribute stripping, so that seems like the way to go?
If your double has no attributes then I'm barking up the wrong tree.
Matthew
__
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
