Re: [Rd] Linking to the BH package introduces CRAN warnings
Le 5 nov. 2014 à 14:45, Dirk Eddelbuettel e...@debian.org a écrit : On 5 November 2014 at 14:11, Romain Francois wrote: | Le 5 nov. 2014 à 13:43, Dirk Eddelbuettel e...@debian.org a écrit : | You are NOT forced or required to use the Boost distributions header __as R | comes with the equivalent functionality__ via the Rmath.h header file from R. | Which has functionality that Rcpp provides to you in scalar and vector form. | | And there are probably several dozen examples of using the R distribution | functions from Rcpp. | | So this is _precisely_ what I suggested several mails ago: do your homework, | identify which header is causing it. And the obvious next step is then to | not use the header. | | So why these headers are shipped with BH then. The BH builder (ie the script local/scripts/CreateBoost.sh in the repo) actively selects a number of Boost libraries [1], and uses the Boost tool 'bcp' to copy these (header-only) libraries -- plus all their dependencies. The set of selected components grew out of initial requirements, plus requests received since the package was created. [2] Now, just because some files within a library tickle a warning does not seem to imply that all use of said warning is impossible. By my count, over two dozen CRAN packages currently depend on BH [3] indicating some usefulness of BH, including to the dplyr package you work on. Yeah so that’s like « we’ll sell you horticultural bulbs, but only use them for indoor culture of tomatoes, ‘cause you know it’s illegal to grow weed » whatever. Believe me, I’d love for dplyr not to depend on BH, which we use for unordered_map. Policies and requirements do of cause charge, but I am not aware of any of the two dozen package tickling this issue -- their use case is just fine, thank you, and their requirements lead to the inclusion of the header currently comprised in the package. I hope this answers your question. Should you have further questions concerning the BH package, could you be so kind as to bringing them to appropriate list [4] or filing a ticket on GH? This was not really a question, so yes I guess it answers it. Not your fault, just the user’s fault of using something that is shipped yet is unusable. You’re in the clear. Thanks, Dirk [1] components may be a better term so we avoid the association with linking [2] Another one of these requests just came in this week asking for circular_buffer. [3] http://cran.r-project.org/web/packages/BH/index.html [4] http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/boostheaders-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linking to the BH package introduces CRAN warnings
Le 4 nov. 2014 à 15:42, Dirk Eddelbuettel e...@debian.org a écrit : On 4 November 2014 at 14:37, kaveh wrote: | Dear all, | | I'm working on a project that links to the BH package | (http://cran.r-project.org/web/packages/BH/index.html). | | My packages doesn't call entry points which might terminate R nor | write to stdout/stderr instead of to the console. | | However, it seems some of the codes in the BH package | might. At any rate, when I include some boost headers such as | boost/math/distributions/ through BH, I get the following warnings | when submitting to the win-builder page: | | |Found '_ZSt4cerr', possibly from 'std::cerr' (C++) | |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) | |Found '_ZSt4cerr', possibly from 'std::cerr' (C++) | |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) You’re kind of out of luck. These functions are both: - used by the boost headers - forbidden by R, well at least forbidden by CRAN | Furthermore, these warnings disappear when remove the boost | headers and replace the call to boost functions by constants. | | Looking at the CRAN-check diagnostics of some other packages that link to | BH, I do not see similar warnings, so I suppose it is possible to fix | this issue. | Looking at their source code, it is not clear to me how these authors have | managed to do this, but this might be because I'm not that familiar with | boost to begin with. Can someone point me to some solution to this problem? Briefly: i) Your subject line is wrong. You do not link to BH, you use it to include headers at compile time. That may seem like a small difference, but it is not. You generally want to avoid linking as much as you can, if only for cross-OS portability, How would you not expect someone to be confused when « not linking to » BH requires the use of the `LinkingTo: BH` in the DESCRIPTION file. ii) This the R-devel list for R question. You have a package question. You are generally advised to contact __the package authors__ and/or the package mailing list. And yes, BH has one in http://lists.r-forge.r-project.org/pipermail/boostheaders-devel/ though I grant you that it is not as well advertised as it should be. I just opened a ticket at https://github.com/eddelbuettel/bh/issues/3 to remind myself to improve that. iii) As for your problem, only you and some careful bisections can help you there as we do not have your sources. I too have packages including BH headers, but they do not pull in abort() or other things the CRAN gatekeepers prohibit us from deploying. Dirk aka your friendly neighborhood BH maintainer -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ 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
Re: [Rd] Linking to the BH package introduces CRAN warnings
Le 4 nov. 2014 à 21:52, kaveh vakili.kaveh.em...@gmail.com a écrit : Dear Romain, You’re kind of out of luck. These functions are both: - used by the boost headers - forbidden by R, well at least forbidden by CRAN Thanks for conforming my earlier fears. Since I only use this header and would like my package to eventually be on CRAN, I was thinking of bypassing BH and just putting these headers in the /inst directory and modifying them to remove the offending calls. I was wondering what your view on this is. Or perhaps there is a simpler alternative? Thanks in advance, If you go through the hoops of modifying these headers to fulfill R’s requirements, I’m sure it would be of interest to others if you contribute these back to BH. The danger obviously is that this gets out of sync with boost, which would create work for merging your changes to new boost files from the future. Some parts of boost (e.g. uBlas) have macros to control whether or not std::cerr is used at all. https://github.com/eddelbuettel/bh/blob/cb1427c27dc068c8328fd1d2f4b1b8a8da1957c2/inst/include/boost/numeric/ublas/exception.hpp#L215 https://github.com/eddelbuettel/bh/blob/cb1427c27dc068c8328fd1d2f4b1b8a8da1957c2/inst/include/boost/numeric/ublas/exception.hpp#L215 But I don’t think this is of any relevance to the files you want to use. Romain On 2014-11-04 21:46, Romain François wrote: Le 4 nov. 2014 à 15:42, Dirk Eddelbuettel e...@debian.org mailto:e...@debian.org a écrit : On 4 November 2014 at 14:37, kaveh wrote: | Dear all, | | I'm working on a project that links to the BH package | (http://cran.r-project.org/web/packages/BH/index.html http://cran.r-project.org/web/packages/BH/index.html). | | My packages doesn't call entry points which might terminate R nor | write to stdout/stderr instead of to the console. | | However, it seems some of the codes in the BH package | might. At any rate, when I include some boost headers such as | boost/math/distributions/ through BH, I get the following warnings | when submitting to the win-builder page: | | |Found '_ZSt4cerr', possibly from 'std::cerr' (C++) | |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) | |Found '_ZSt4cerr', possibly from 'std::cerr' (C++) | |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran) You’re kind of out of luck. These functions are both: - used by the boost headers - forbidden by R, well at least forbidden by CRAN [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using Rtools with gcc 4.8.3
Le 5 oct. 2014 à 13:14, Gabor Grothendieck ggrothendi...@gmail.com a écrit : On Sun, Oct 5, 2014 at 6:51 AM, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: On 05.10.2014 12:20, Jeroen Ooms wrote: I started working on some R bindings for mongo-c-driver [1]. The C library compiles fine on Ubuntu Trusty (gcc 4.8.2) and osx (clang), however on my windows machine (gcc 4.6.3 from Rtools 3.1) it fails with: 'INIT_ONCE_STATIC_INIT' undeclared. Google suggests that this might be a problem in older versions of mingw-w64. So I grabbed a copy of mingw-w64 version 4.8.3 and indeed, here the library compiles without errors. Now I am unsure how to make mingw 4.8.3 work with Rtools. I extracted the contents of [2] into C:\RBuildTools\3.1\gcc-4.8.3\ and my package Makevars contains CC = c:/RBuildTools/3.1/gcc-4.8.3/bin/gcc However it seems like R still uses the old gcc 4.6.3 for R CMD INSTALL. What am I doing wrong? Is there a recommended setup for building packages on Windows using a Rtools but with another compiler? In addition: will I be able to publish this package to CRAN, or do I have to wait for Rtools to get updated with a more recent gcc? Currently only 4.6.3 is supported and that is the one used to build binary packages on CRAN. Hence you need to wait until it is updated. Best, Uwe Ligges [1] https://github.com/mongodb/mongo-c-driver [2] http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.3/threads-posix/dwarf/ Are there any plans for this? gcc is already up to 4.9.1 and I am sure a lot of people would like to see the latest version available as part of Rtools. +1. Please. I’d like a newer gcc as part of Rtools too. My reason for it is that it would bring actual C++11, rather than unfinished C++0x as gcc 4.6.3 currently ships. That would allow more adoption of the newer C++ standard for packages [*]. Furthermore, a current version of gcc will also give a good support for C++14, the current C++ standard. I said it in the past, I don’t have the skills to make this happen myself but I would consider funding someone’s time (within reason) and offer mine for testing it. Romain *: currently Rcpp11, the best way to connect R and C++11, has to compromise on what C++11 means so that it works on windows. This is bad. The compromise is minimal, but still. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using Rtools with gcc 4.8.3
Le 5 oct. 2014 à 13:56, Romain François rom...@r-enthusiasts.com a écrit : Le 5 oct. 2014 à 13:14, Gabor Grothendieck ggrothendi...@gmail.com a écrit : On Sun, Oct 5, 2014 at 6:51 AM, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: On 05.10.2014 12:20, Jeroen Ooms wrote: I started working on some R bindings for mongo-c-driver [1]. The C library compiles fine on Ubuntu Trusty (gcc 4.8.2) and osx (clang), however on my windows machine (gcc 4.6.3 from Rtools 3.1) it fails with: 'INIT_ONCE_STATIC_INIT' undeclared. Google suggests that this might be a problem in older versions of mingw-w64. So I grabbed a copy of mingw-w64 version 4.8.3 and indeed, here the library compiles without errors. Now I am unsure how to make mingw 4.8.3 work with Rtools. I extracted the contents of [2] into C:\RBuildTools\3.1\gcc-4.8.3\ and my package Makevars contains CC = c:/RBuildTools/3.1/gcc-4.8.3/bin/gcc However it seems like R still uses the old gcc 4.6.3 for R CMD INSTALL. What am I doing wrong? Is there a recommended setup for building packages on Windows using a Rtools but with another compiler? In addition: will I be able to publish this package to CRAN, or do I have to wait for Rtools to get updated with a more recent gcc? Currently only 4.6.3 is supported and that is the one used to build binary packages on CRAN. Hence you need to wait until it is updated. Best, Uwe Ligges [1] https://github.com/mongodb/mongo-c-driver [2] http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.3/threads-posix/dwarf/ Are there any plans for this? gcc is already up to 4.9.1 and I am sure a lot of people would like to see the latest version available as part of Rtools. +1. Please. I’d like a newer gcc as part of Rtools too. My reason for it is that it would bring actual C++11, rather than unfinished C++0x as gcc 4.6.3 currently ships. That would allow more adoption of the newer C++ standard for packages [*]. Furthermore, a current version of gcc will also give a good support for C++14, the current C++ standard. I said it in the past, I don’t have the skills to make this happen myself but I would consider funding someone’s time (within reason) and offer mine for testing it. Romain *: currently Rcpp11, the best way to connect R and C++11, has to compromise on what C++11 means so that it works on windows. This is bad. The compromise is minimal, but still. Those missing features in C++0x from 4.6.3 include: - delegate constructors - template aliases (a more powerful `using` keyword We’ve worked around that, but at the expense of some code clarity, safety and boilerplateness (esp. the delegate constructor feature). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operation on ‘numsels’ may be undefined
Le 23 juin 2014 à 15:20, cstrato cstr...@aon.at a écrit :
Dear all,
Since many years the following C++ code does compile on ALL Bioconductor
servers (Linux, Windows, Mac) without any warnings:
Int_t numsels = 0; //number of selected entries
...
for (Int_t i=0; isize; i++) {
numsels = (arrMask[i] == 1) ? ++numsels : numsels;
}//for_i
This is confusing. I would write the loop body like this:
numsels += (arrMask[i] == 1) ;
or preferably using the STL:
Int_t numsels = std::count( begin(arrMask), end(arrMask), 1 ) ;
or some other variation of this, i.e. perhaps you don’t have a C++11 compiler,
so perhaps one of these depending on what is arrMask:
Int_t numsels = std::count( arrMask.begin(), arrMask.end(), 1 ) ;
Int_t numsels = std::count( arrMask, arrMask + size, 1 ) ;
Romain
Even on the recently added release server 'zin2' Linux (Ubuntu 12.04.4 LTS)
the above code compiles w/o warnings.
However, on the new development server 'zin1' Linux (Ubuntu 12.04.4 LTS) I
get suddenly the following warning message:
Found the following significant warnings:
XPSPreProcessing.cxx:3026:56: warning: operation on ‘numsels’ may be
undefined [-Wsequence-point]
Interestingly, both servers do not only run the same version of Ubuntu, but
also the same version of the C++ compiler, i.e. g++ (Ubuntu/Linaro
4.6.3-1ubuntu5) 4.6.3, and use the same flags, see:
http://bioconductor.org/checkResults/2.14/bioc-LATEST/zin2-NodeInfo.html
http://bioconductor.org/checkResults/devel/bioc-LATEST/zin1-NodeInfo.html
My question is now, why do I suddenly get the compiler warning?
The reason why I ask at R-devel and not Bioc-devel is that it may not only be
a Bioc question, since I found the following links:
http://c-faq.com/expr/seqpoints.html
http://stackoverflow.com/questions/16838884/why-i-got-operation-may-be-undefined-in-statement-expression-in-c
I am not sure if I understand the meaning, but until now I have never got any
warning from any compiler the I have used (including MS Visual C++).
Do I really have to replace '++numsels' with 'numsels+1'?
Best regards,
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
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
Re: [Rd] operation on ‘numsels’ may be undefined
Le 23 juin 2014 à 18:28, cstrato cstr...@aon.at a écrit :
Dear Romain,
Thank you for your suggestions, I like especially the first one.
However, you did not explain why I have never got this warning message on any
compiler, and why only one of the two identical Ubuntu compilers did give
this warning message?
Best regards,
Christian
I don’t know, but this:
numsels = ++numsels ;
seems fishy to me, and so it keeps feeling weird with the addition of the
ternary operator.
There is obviously a difference of setup between these two machines, but I
don’t have time to sherlock that for you. One of the compilers is getting more
careful than the other. Getting warnings you did not get before is a good
thing, as it helps you update the code with that new insight.
Welcome to my world, I’m sometimes thrown all kinds of new warnings from
esoteric compilers, all of them have value .
Romain
On 6/23/14 3:45 PM, Romain François wrote:
Le 23 juin 2014 à 15:20, cstrato cstr...@aon.at a écrit :
Dear all,
Since many years the following C++ code does compile on ALL Bioconductor
servers (Linux, Windows, Mac) without any warnings:
Int_t numsels = 0; //number of selected entries
...
for (Int_t i=0; isize; i++) {
numsels = (arrMask[i] == 1) ? ++numsels : numsels;
}//for_i
This is confusing. I would write the loop body like this:
numsels += (arrMask[i] == 1) ;
or preferably using the STL:
Int_t numsels = std::count( begin(arrMask), end(arrMask), 1 ) ;
or some other variation of this, i.e. perhaps you don’t have a C++11
compiler, so perhaps one of these depending on what is arrMask:
Int_t numsels = std::count( arrMask.begin(), arrMask.end(), 1 ) ;
Int_t numsels = std::count( arrMask, arrMask + size, 1 ) ;
Romain
Even on the recently added release server 'zin2' Linux (Ubuntu 12.04.4 LTS)
the above code compiles w/o warnings.
However, on the new development server 'zin1' Linux (Ubuntu 12.04.4 LTS) I
get suddenly the following warning message:
Found the following significant warnings:
XPSPreProcessing.cxx:3026:56: warning: operation on ‘numsels’ may be
undefined [-Wsequence-point]
Interestingly, both servers do not only run the same version of Ubuntu, but
also the same version of the C++ compiler, i.e. g++ (Ubuntu/Linaro
4.6.3-1ubuntu5) 4.6.3, and use the same flags, see:
http://bioconductor.org/checkResults/2.14/bioc-LATEST/zin2-NodeInfo.html
http://bioconductor.org/checkResults/devel/bioc-LATEST/zin1-NodeInfo.html
My question is now, why do I suddenly get the compiler warning?
The reason why I ask at R-devel and not Bioc-devel is that it may not only
be a Bioc question, since I found the following links:
http://c-faq.com/expr/seqpoints.html
http://stackoverflow.com/questions/16838884/why-i-got-operation-may-be-undefined-in-statement-expression-in-c
I am not sure if I understand the meaning, but until now I have never got
any warning from any compiler the I have used (including MS Visual C++).
Do I really have to replace '++numsels' with 'numsels+1'?
Best regards,
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
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
Re: [Rd] R 3.1.0 and C++11
Le 10 avr. 2014 à 17:58, Martyn Plummer plumm...@iarc.fr a écrit : On Thu, 2014-04-10 at 11:14 -0400, Gabor Grothendieck wrote: On Tue, Oct 29, 2013 at 1:58 AM, rom...@r-enthusiasts.com wrote: Le 2013-10-29 03:01, Whit Armstrong a écrit : I would love to see optional c++0x support added for R. c++0x was the name given for when this was in development. Now c++11 is a published standard backed by implementations by major compilers. people need to stop calling it c++0x If there is anything I can do to help, please let me know. Come here https://github.com/romainfrancois/cpp11_article where I'm writing an article on C++11 and what would be the benefits. Unless you are willing to do it yourself currently Rtools on Windows uses g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x . Ubuntu 12.04 LTS also provides g++ 4.6.3. g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11 More info at: http://gcc.gnu.org/projects/cxx0x.html The R configure script is permissive and will enable C++11 support if your compiler accepts -std=c++0x. Obviously you will only get partial support for the C++11 standard (But this is also true of some compilers that accept -std=c++11). You may be OK if you just want C99 features, which were missing from the C++98 standard, and features previously introduced in the TR1 extension. But there are no guarantees. Cross-platform support for C++11 is going to remain poor for some time to come, I'm afraid. Martyn What would be a good enough motivation for distributing a version of Rtools based on a more recent gcc, e.g. in the 4.8 series, which has much better coverage of the standard. I don’t have the skills to build an Rtools distribution, but if I can help one way or another, please let me know. I could, perhaps with other interested parties sponsor someone’s time for example. Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question regarding lang2 command in C
Hi, This is easy if the gender and age are already vectors of some sort of the same size. SEXP df = PROTECT(allocVector(VECSXP, 2)); SET_VECTOR_ELT(df,0,gender) ; SET_VECTOR_ELT(df,1,age) ; SEXP names = PROTECT(allocVector(STRSXP,2)); SET_STRING_ELT(names,0,mkChar(age)) SET_STRING_ELT(names,0,mkChar(gender)) setAttrib(df, R_NamesSymbol, names ); setAttrib(df, R_ClassSymbol, mkString(data.frame)); SEXP rn = PROTECT(allocVector(INTSXP,2)); INTEGER(rn)[0] = NA_INTEGER ; INTEGER(rn)[1] = -length(gender); setAttrib(df, R_RowNamesSymbol, rn) ; UNPROTECT(3) ; return df ; If you really want to call back to R and make a call as you did before, you can do something like this: SEXP call = PROTECT(lang4(install(data.frame), age, gender, ScalarLogical(FALSE))) ; SET_TAG(CDR(call), install(age)) ; SET_TAG(CDDR(call), install(gender)) ; SET_TAG(CDR(CDDR(call)), install(stringsAsFactors)) ; SEXP df = PROTECT(eval(call, R_GlobalEnv)) ; UNPROTECT(2) ; return df ; Or you can use Rcpp: DataFrame df = DataFrame::create( _[age] = age, _[gender] = gender, _[stringsAsFactors] = FALSE ) ; Romain Le 3 avr. 2014 à 07:40, Sandip Nandi sanna...@umail.iu.edu a écrit : Hi , I am asking too many questions , sorry for that . I am creating a data frame in C itself , reading a table . The data frame calling code looks like this == *PROTECT(dfm=lang2(install(data.frame),df));* *SEXP res = PROTECT(eval(dfm,R_GlobalEnv));* UNPROTECT(2); return res; == It works fine , now the problem is I want to do the below one from C itself ( adding the *stringsAsFactors = FALSE* parameter) df - data.frame(gender, age, *stringsAsFactors = FALSE*); How can I do it from C , adding extra parameters. Anyone has pointer or any example . It will be great help. I find the arguments will always be in pair , i don't find any example. I try to see the source code ,not able to make it Thanks __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] special handling of row.names
Hello,
I think there is an inconsistency in the handling of the compact form of the
row.names attributes.
When n is the number of rows of a data.frame, the compact form is
c(NA_integer_,-n), as in:
d - data.frame(x=1:10)
.Internal(inspect(d))
@104f174a8 19 VECSXP g0c1 [OBJ,NAM(2),ATT] (len=1, tl=0)
@103a7dc60 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,...
ATTRIB:
@104959380 02 LISTSXP g0c0 []
TAG: @100823078 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] names (has value)
@104f17748 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
@10085c678 09 CHARSXP g1c1 [MARK,gp=0x61] [ASCII] [cached] x
TAG: @10082d060 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] row.names (has value)
@104f0e898 13 INTSXP g0c1 [] (len=2, tl=0) -2147483648,-10
TAG: @100823548 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] class (has value)
@104f0e8c8 16 STRSXP g0c1 [NAM(1)] (len=1, tl=0)
@1008a7e60 09 CHARSXP g1c2 [MARK,gp=0x61,ATT] [ASCII] [cached]
data.frame
But then, -10 becomes 10:
d2 - structure( d, class = data.frame )
.Internal(inspect(d2))
@104f08898 19 VECSXP g0c1 [OBJ,NAM(2),ATT] (len=1, tl=0)
@103a7dc60 13 INTSXP g0c4 [NAM(2)] (len=10, tl=0) 1,2,3,4,5,...
ATTRIB:
@104956150 02 LISTSXP g0c0 []
TAG: @100823078 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] names (has value)
@104f087a8 16 STRSXP g0c1 [] (len=1, tl=0)
@10085c678 09 CHARSXP g1c1 [MARK,gp=0x61] [ASCII] [cached] x
TAG: @10082d060 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] row.names (has value)
@104f088c8 13 INTSXP g0c1 [] (len=2, tl=0) -2147483648,10
TAG: @100823548 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] class (has value)
@104f08838 16 STRSXP g0c1 [] (len=1, tl=0)
@1008a7e60 09 CHARSXP g1c2 [MARK,gp=0x61,ATT] [ASCII] [cached]
data.frame
This happens in row_names_gets (attrib.c), here:
if(OK_compact) {
/* we hide the length in an impossible integer vector */
PROTECT(val = allocVector(INTSXP, 2));
INTEGER(val)[0] = NA_INTEGER;
INTEGER(val)[1] = n;
ans = installAttrib(vec, R_RowNamesSymbol, val);
UNPROTECT(1);
return ans;
}
I believe it should be INTEGER(val)[1] = -n; for consistency.
BTW, perhaps structure should be internalized to prevent special handling of
row.names when it does not make sense. Here is structure:
structure
function (.Data, ...)
{
attrib - list(...)
if (length(attrib)) {
specials - c(.Dim, .Dimnames, .Names, .Tsp,
.Label)
replace - c(dim, dimnames, names, tsp, levels)
m - match(names(attrib), specials)
ok - (!is.na(m) m)
names(attrib)[ok] - replace[m[ok]]
if (factor %in% attrib[[class, exact = TRUE]]
typeof(.Data) == double)
storage.mode(.Data) - integer
attributes(.Data) - c(attributes(.Data), attrib)
}
return(.Data)
}
When I do structure( d, class = data.frame ), eventually this line is
executed:
attributes(.Data) - c(attributes(.Data), attrib)
So, first attributes are retrieved, and because of R special handling of
row.names, it gets promoted to 1:n in getAttrib.
Then, we want to set the row.names attribute, special handling again in
setAttrib, leading to row_names_gets, R actually loops over the attribute to
check if it is of the form 1:n, and if it is it brings back the compact form
(making a mistake along the way).
This looks like a waste of resources.
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CXX_STD and configure.ac in packages
Le 31 mars 2014 à 12:20, Martyn Plummer plumm...@iarc.fr a écrit :
On Mon, 2014-03-31 at 07:09 +, Martyn Plummer wrote:
Hi Martin,
Thanks for the patch. I have applied it. I also added CXX1X and friends to
the list of approved variables for R CMD config.
So you can now query the existence of C++11 support with `R CMD config
CXX1X` (It is empty if C++11 support is not available)
and then take appropriate action in your configure script if, in Dirk's
words, you want to do the configure dance.
The philosophy underlying C++ support in R is that there are only two
standards - C++98 and C++11 - and that
you should write to one of those standards.
A should add a clarification. The way I wrote this makes it sound like
an even-handed choice, but only C++98 has cross-platform support. If you
use C++11 then many users will not currently be able to use your code.
OTOH, if nobody goes there, the need for C++11 might not be perceived as
important by people who take care of cross platform support.
Probably not Martin’s fight. One can do the gymnastics to get an unordered_map
with C++98 (through boost, tr1, etc ...), but C++11 brings a great combination
of new features that make it a better language, and I agree that it is almost a
new language. And once you start using it, it is hard to look back.
Nobody should be writing new code that uses TR1 extensions now: they are
superseded by the new standard.
The map and unordered_map classes are a corner case, as they offer the same
functionality but latter has much better
complexity guarantees, so it is tempting to use it when available. But from
a global perspective you should think of
C++98 and C++11 as two different languages.
Martyn
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on
behalf of Romain Francois [rom...@r-enthusiasts.com]
Sent: 31 March 2014 08:22
To: Martin Morgan
Cc: R-devel
Subject: Re: [Rd] CXX_STD and configure.ac in packages
Hi,
My advice would be to use SystemRequirements: C++11
As unordered_map is definitely a part of C++11, assuming this version of
the standard gives it to you. Your package may not compile on platforms
where a C++11 compiler is not available, but perhaps if this becomes a
pattern, then such compilers will start to be available, as in the current
version of OSX and recent enough versions of various linux distributions.
The subset of feature that the version of gcc gives you with Rtools might be
enough.
Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro
which will expand to either unordered_map or tr1::unordered_map, all the
condition compiling is done in Rcpp.
Romain
Le 30 mars 2014 à 21:50, Martin Morgan mtmor...@fhcrc.org a écrit :
In C++ code for use in a R-3.1.0 package, my specific problem is that I
would like to use unordered_map if it is available, or
tr1/unordered_map if not, or map if all else fails.
I (think I) can accomplish this with configure.ac as
AC_INIT(DESCRIPTION)
CXX=`${R_HOME}/bin/R CMD config CXX`
CXXFLAGS=`${R_HOME}/bin/R CMD config CXXFLAGS`
AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT
Use of configure.ac does not seem to be entirely consistent with section
1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see
below) code one should
CXX_STD = CXX11
in Makevars(.win). My code does not require a compiler that supports the
full C++11 feature set. In addition, I do not understand the logic of
setting a variable that influences compiler flags in Makevars --
configure.ac will see a compiler with inaccurate flags.
Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
Some minor typos:
/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi(revision 65339)
+++ doc/manual/R-exts.texi(working copy)
@@ -2250,7 +2250,7 @@
@subsection Using C++11 code
@R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
For full portability across platforms, all
that can be assumed is approximate support for the C++98 standard (the
widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
support a flag @option{-std=c++0x}, but the latter only provides partial
support for the C++11 standard.
-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
file (or @file{Makevars.win} on Windows) should include the line
@example
@@ -2329,7 +2329,7 @@
anything other than the GNU version of C++98 and GNU extensions (which
include TR1). The default
Re: [Rd] internal string comparison (Scollate)
Hello, The use case I have might involve sorting many small such STRSXP vectors. If I have Scollate, I don’t need to materialize the vectors and I can use the sorting algorithm I choose. Here is some made up data: df - data.frame( x = sample( 1:10, 1000, replace = TRUE), y = sample( 1:100, 100, replace = TRUE), z = replicate( 1, paste( sample(letters, sample(1:100, size = 1), replace = TRUE ), collapse = ) ), stringsAsFactors = FALSE ) For which I’d like something like what order( df$x, df$y, df$z ) gives me. For example: system.time( res1 - order( df$x, df$y, df$z) ) utilisateur système écoulé 0.017 0.000 0.017 system.time( res2 - dplyr::order_( df$x, df$y, df$z ) ) utilisateur système écoulé 0.005 0.000 0.005 identical( res1, res2 ) [1] TRUE The way dplyr::order_ is implemented I don’t need to materialize 500 STRSXP vectors and call order or sort on them ( 492 == nrow( unique( df[, c(x, y ) ] ) ) ) I just need to be able to compare two scalars together (either two ints, two doubles, or two CHARSXP SEXP). We already have special code to handle what it means to compare int, double etc in the R world with NA and NaN, etc ... Scollate would give a way to compare two CHARSXP SEXP, the way R would. Of course one has to be careful how it is called, I have read the source. Materialising temporary values into an R vector may be the R way of doing things, but sometimes it is a waste of both memory and time. Yes, this is about performance. We are often asked to choose between performance and correctness when in fact we can have both. Romain Le 27 mars 2014 à 22:12, Duncan Murdoch murdoch.dun...@gmail.com a écrit : On 14-03-27 3:01 PM, Kevin Ushey wrote: I too think it would be useful if R exported some version of its string sorting routines, since sorting strings while respecting locale, and doing so in a portable fashion while respecting the user's environment, is not trivial. R holds a fast, portable, well-tested solution, and I think package developers would be very appreciative if some portion of this was exposed at the C level. It does. You can put your strings in an R STRSXP vector, and call the R sort function on it. The usual objection to constructing an R expression and evaluating it is that it is slow, but if you are talking about sorting, the time spent in the sort is likely to dominate the time spent in the setup. If not `Scollate`, then perhaps other candidates could be the more generic `sortVector`, or the more string-specific (and NA-respecting) `scmp`. Evaluating an R expression gives you sortVector. I can see an argument for Scollate being useful (sorting isn't the only reason to compare strings), but I can see arguments against exposing it too. Take a look at the source: it needs to be used carefully. In particular, it can return a 0 for unequal strings, and users are likely to get messed up by that, or to submit bogus bug reports. And it's not impossible to work around: if you can collect the universe of strings to compare in advance, then just use order() to convert them to integer values, and compare those. Duncan Murdoch I understand that the volunteers at R Core have limited time and resources, and exposing an API imposes additional maintenance burdens on an already thinly stretched team, but this is a situation where the R users and package authors alike could benefit. Or, if there are other reasons why exporting such routines is not possible nor recommended, it would be very informative to know why. Thanks, Kevin On Thu, Mar 27, 2014 at 11:08 AM, Dirk Eddelbuettel e...@debian.org wrote: On 26 March 2014 at 19:09, Romain François wrote: | That's one part of the problem. Indeed I'd rather use something rather than | copy and paste it and run the risk of being outdated. The answer to that is We all would. But they won't let us by refusing to create more API access points. | testing though. I can develop a test suite that can let me know I'm out of Correct. | date and I need to copy and paste some new code, etc ... Done that before, this | is tedious, but so what. | | The other part of the problem (the real part of the problem actually) is that, | at least when R is built with ICU support, Scollate will depend on a the | collator pointer in util.c | https://github.com/wch/r-source/blob/trunk/src/main/util.c#L1777 | | And this can be controlled by the base::icuSetCollate function. Of course the | collator pointer is not public. So the next (and even less pleasant) answer is to build a new package which links to, (or worse yet, embeds) libicu. As you want ICU behaviour, you will need ICU code. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https
[Rd] internal string comparison (Scollate)
Hello, I’d like to compare two strings internally the way R would, so I need Scollate which is not part of the authorized R api. So: - Can Scollate (and perhaps Seql) be promoted to api ? - If not what are the alternatives ? Using strcmp or stroll does not seem as general as Scollate. Romain PS: Here is some context: https://github.com/hadley/dplyr/issues/325 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] internal string comparison (Scollate)
Le 26 mars 2014 à 18:03, Gabriel Becker gmbec...@ucdavis.edu a écrit : On Wed, Mar 26, 2014 at 9:50 AM, Dirk Eddelbuettel e...@debian.org wrote: On 26 March 2014 at 17:22, Romain François wrote: | Id like to compare two strings internally the way R would, so I need Scollate which is not part of the authorized R api. | | So: | - Can Scollate (and perhaps Seql) be promoted to api ? | - If not what are the alternatives ? Using strcmp or stroll does not seem as general as Scollate. I'd add a third option: - Put this in a new package and register the functions you want. That would not achieve what Romain wants. Or rather, it would when he did it, but would not be guaranteed to do so at any point after the next release of R. Thats one part of the problem. Indeed Id rather use something rather than copy and paste it and run the risk of being outdated. The answer to that is testing though. I can develop a test suite that can let me know Im out of date and I need to copy and paste some new code, etc Done that before, this is tedious, but so what. The other part of the problem (the real part of the problem actually) is that, at least when R is built with ICU support, Scollate will depend on a the collator pointer in util.c https://github.com/wch/r-source/blob/trunk/src/main/util.c#L1777 And this can be controlled by the base::icuSetCollate function. Of course the collator pointer is not public. So in short that does not help. My understanding of his request is that he wants something that will behave as R will, not behave as R does now. All that having been said, not every single thing R does internally can be public and of course I'm not privy or a party to discussions on what should and shouldn't be. But freezing and duplicating small pieces of R's non-exported internal code seems like a dangerous move to me. ~G -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help with gotoExitingHandler(R_NilValue, call, entry); . Implementation of error handling internally
Never mind. For my initial question, I can just use: R_curErrorBuf
My current implementation now only depend on R_FunTab and R_GlobalContext which
R does not conceal behind attribute_hidden.
https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Context.h
Romain
Le 27 févr. 2014 à 08:13, Romain François rom...@r-enthusiasts.com a écrit :
Of course one problem is that R hides things that I need for this, such as
R_HandlerStack and R_ReturnedValue.
I understand they have to be hidden, in which case can we have an exposed
mechanism similar to what R_ToplevelExec does, but with the added
functionality of giving access to the condition where R_ToplevelExec would
return TRUE.
Would someone be willing to review a patch to R with this added
functionality. Please.
In any case, I still would like some comments about my initial question about
R_NilValue use in gotoExitingHandler(R_NilValue, call, entry);
Romain
Le 26 févr. 2014 à 09:41, Romain François rom...@r-enthusiasts.com a écrit :
Hello,
I’m trying to leverage R_ToplevelExec to implement C level try/catch.
The way it is implemented allows for running a function in a top level
context. This context gets an empty handler stack, so either the function
runs correctly or it jumps. When it jumps, it does not find a handler, so it
jumps to the top level context.
R does not allow me to call begin context and end context directly, so
instead what I do is call R_ToplevelExec, grab the global context inside the
function, install my own handler that I don’t set to be a calling one,
pretend this context is a CTXT_FUNCTION.
Eventually I get to jump fun, so that I can later on grab the condition from
R_ReturnedValue.
This works well in the « not simple error » case, i.e. if I call stop(
simpleError(...) ), but with simple errors, i.e. calls to Rf_error
internally or bare calls to stop( vvzvz ) I can’t access the error.
And this boils down to this call:
gotoExitingHandler(R_NilValue, call, entry);
inside vsignalError :
static void vsignalError(SEXP call, const char *format, va_list ap)
{
char localbuf[BUFSIZE];
SEXP list, oldstack;
oldstack = R_HandlerStack;
Rvsnprintf(localbuf, BUFSIZE - 1, format, ap);
while ((list = findSimpleErrorHandler()) != R_NilValue) {
char *buf = errbuf;
SEXP entry = CAR(list);
R_HandlerStack = CDR(list);
strncpy(buf, localbuf, BUFSIZE - 1);
/* Rvsnprintf(buf, BUFSIZE - 1, format, ap);*/
buf[BUFSIZE - 1] = 0;
if (IS_CALLING_ENTRY(entry)) {
if (ENTRY_HANDLER(entry) == R_RestartToken)
return; /* go to default error handling; do not reset stack */
else {
SEXP hooksym, hcall, qcall;
/* protect oldstack here, not outside loop, so handler
stack gets unwound in case error is protect stack
overflow */
PROTECT(oldstack);
hooksym = install(.handleSimpleError);
PROTECT(qcall = LCONS(R_QuoteSymbol,
LCONS(call, R_NilValue)));
PROTECT(hcall = LCONS(qcall, R_NilValue));
hcall = LCONS(mkString(buf), hcall);
hcall = LCONS(ENTRY_HANDLER(entry), hcall);
PROTECT(hcall = LCONS(hooksym, hcall));
eval(hcall, R_GlobalEnv);
UNPROTECT(4);
}
}
else gotoExitingHandler(R_NilValue, call, entry); // HERE
}
R_HandlerStack = oldstack;
}
Would it be possible to construct a simple condition instead of passing down
R_NilValue so that I can grab this error and deal with it.
The alternative is to set the handler to be a calling one, but I’d like to
avoid that as much as possible as this means going back to the R side of
things just to get access to the condition.
My code is here: https://gist.github.com/romainfrancois/9225811
I have only tested this on OSX with R-devel. The code only uses R internal
api (not Rcpp*).
So down to what I’d like you to consider please if you are still reading
here. Can we feed gotoExitingHandler with something more interesting than
NULL. please.
The end game is to add one layer of abstraction, e.g. pass to R_ToplevelExec
a function that first deals with contexts, then calls an actual function.
Combining this with lambda functions in C++ will make quite a nice and
elegant way to handle error handling at the C++ level.
I can provide the code that would create the simpleError, this is just
making a simple VECSXP with names and classes, no big trouble here.
Romain
__
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
[Rd] help with gotoExitingHandler(R_NilValue, call, entry); . Implementation of error handling internally
Hello,
I’m trying to leverage R_ToplevelExec to implement C level try/catch.
The way it is implemented allows for running a function in a top level context.
This context gets an empty handler stack, so either the function runs correctly
or it jumps. When it jumps, it does not find a handler, so it jumps to the top
level context.
R does not allow me to call begin context and end context directly, so instead
what I do is call R_ToplevelExec, grab the global context inside the function,
install my own handler that I don’t set to be a calling one, pretend this
context is a CTXT_FUNCTION.
Eventually I get to jump fun, so that I can later on grab the condition from
R_ReturnedValue.
This works well in the « not simple error » case, i.e. if I call stop(
simpleError(...) ), but with simple errors, i.e. calls to Rf_error internally
or bare calls to stop( vvzvz ) I can’t access the error.
And this boils down to this call:
gotoExitingHandler(R_NilValue, call, entry);
inside vsignalError :
static void vsignalError(SEXP call, const char *format, va_list ap)
{
char localbuf[BUFSIZE];
SEXP list, oldstack;
oldstack = R_HandlerStack;
Rvsnprintf(localbuf, BUFSIZE - 1, format, ap);
while ((list = findSimpleErrorHandler()) != R_NilValue) {
char *buf = errbuf;
SEXP entry = CAR(list);
R_HandlerStack = CDR(list);
strncpy(buf, localbuf, BUFSIZE - 1);
/* Rvsnprintf(buf, BUFSIZE - 1, format, ap);*/
buf[BUFSIZE - 1] = 0;
if (IS_CALLING_ENTRY(entry)) {
if (ENTRY_HANDLER(entry) == R_RestartToken)
return; /* go to default error handling; do not reset stack */
else {
SEXP hooksym, hcall, qcall;
/* protect oldstack here, not outside loop, so handler
stack gets unwound in case error is protect stack
overflow */
PROTECT(oldstack);
hooksym = install(.handleSimpleError);
PROTECT(qcall = LCONS(R_QuoteSymbol,
LCONS(call, R_NilValue)));
PROTECT(hcall = LCONS(qcall, R_NilValue));
hcall = LCONS(mkString(buf), hcall);
hcall = LCONS(ENTRY_HANDLER(entry), hcall);
PROTECT(hcall = LCONS(hooksym, hcall));
eval(hcall, R_GlobalEnv);
UNPROTECT(4);
}
}
else gotoExitingHandler(R_NilValue, call, entry); // HERE
}
R_HandlerStack = oldstack;
}
Would it be possible to construct a simple condition instead of passing down
R_NilValue so that I can grab this error and deal with it.
The alternative is to set the handler to be a calling one, but I’d like to
avoid that as much as possible as this means going back to the R side of things
just to get access to the condition.
My code is here: https://gist.github.com/romainfrancois/9225811
I have only tested this on OSX with R-devel. The code only uses R internal api
(not Rcpp*).
So down to what I’d like you to consider please if you are still reading here.
Can we feed gotoExitingHandler with something more interesting than NULL.
please.
The end game is to add one layer of abstraction, e.g. pass to R_ToplevelExec a
function that first deals with contexts, then calls an actual function.
Combining this with lambda functions in C++ will make quite a nice and elegant
way to handle error handling at the C++ level.
I can provide the code that would create the simpleError, this is just making a
simple VECSXP with names and classes, no big trouble here.
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help with gotoExitingHandler(R_NilValue, call, entry); . Implementation of error handling internally
Of course one problem is that R hides things that I need for this, such as
R_HandlerStack and R_ReturnedValue.
I understand they have to be hidden, in which case can we have an exposed
mechanism similar to what R_ToplevelExec does, but with the added functionality
of giving access to the condition where R_ToplevelExec would return TRUE.
Would someone be willing to review a patch to R with this added functionality.
Please.
In any case, I still would like some comments about my initial question about
R_NilValue use in gotoExitingHandler(R_NilValue, call, entry);
Romain
Le 26 févr. 2014 à 09:41, Romain François rom...@r-enthusiasts.com a écrit :
Hello,
I’m trying to leverage R_ToplevelExec to implement C level try/catch.
The way it is implemented allows for running a function in a top level
context. This context gets an empty handler stack, so either the function
runs correctly or it jumps. When it jumps, it does not find a handler, so it
jumps to the top level context.
R does not allow me to call begin context and end context directly, so
instead what I do is call R_ToplevelExec, grab the global context inside the
function, install my own handler that I don’t set to be a calling one,
pretend this context is a CTXT_FUNCTION.
Eventually I get to jump fun, so that I can later on grab the condition from
R_ReturnedValue.
This works well in the « not simple error » case, i.e. if I call stop(
simpleError(...) ), but with simple errors, i.e. calls to Rf_error internally
or bare calls to stop( vvzvz ) I can’t access the error.
And this boils down to this call:
gotoExitingHandler(R_NilValue, call, entry);
inside vsignalError :
static void vsignalError(SEXP call, const char *format, va_list ap)
{
char localbuf[BUFSIZE];
SEXP list, oldstack;
oldstack = R_HandlerStack;
Rvsnprintf(localbuf, BUFSIZE - 1, format, ap);
while ((list = findSimpleErrorHandler()) != R_NilValue) {
char *buf = errbuf;
SEXP entry = CAR(list);
R_HandlerStack = CDR(list);
strncpy(buf, localbuf, BUFSIZE - 1);
/* Rvsnprintf(buf, BUFSIZE - 1, format, ap);*/
buf[BUFSIZE - 1] = 0;
if (IS_CALLING_ENTRY(entry)) {
if (ENTRY_HANDLER(entry) == R_RestartToken)
return; /* go to default error handling; do not reset stack */
else {
SEXP hooksym, hcall, qcall;
/* protect oldstack here, not outside loop, so handler
stack gets unwound in case error is protect stack
overflow */
PROTECT(oldstack);
hooksym = install(.handleSimpleError);
PROTECT(qcall = LCONS(R_QuoteSymbol,
LCONS(call, R_NilValue)));
PROTECT(hcall = LCONS(qcall, R_NilValue));
hcall = LCONS(mkString(buf), hcall);
hcall = LCONS(ENTRY_HANDLER(entry), hcall);
PROTECT(hcall = LCONS(hooksym, hcall));
eval(hcall, R_GlobalEnv);
UNPROTECT(4);
}
}
else gotoExitingHandler(R_NilValue, call, entry); // HERE
}
R_HandlerStack = oldstack;
}
Would it be possible to construct a simple condition instead of passing down
R_NilValue so that I can grab this error and deal with it.
The alternative is to set the handler to be a calling one, but I’d like to
avoid that as much as possible as this means going back to the R side of
things just to get access to the condition.
My code is here: https://gist.github.com/romainfrancois/9225811
I have only tested this on OSX with R-devel. The code only uses R internal
api (not Rcpp*).
So down to what I’d like you to consider please if you are still reading
here. Can we feed gotoExitingHandler with something more interesting than
NULL. please.
The end game is to add one layer of abstraction, e.g. pass to R_ToplevelExec
a function that first deals with contexts, then calls an actual function.
Combining this with lambda functions in C++ will make quite a nice and
elegant way to handle error handling at the C++ level.
I can provide the code that would create the simpleError, this is just making
a simple VECSXP with names and classes, no big trouble here.
Romain
__
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
Re: [Rd] Linking to native routines in other packages
Hello,
The problem is that you have logic in both your mother and child packages. IMO,
you should only have logic in the mother package.
I’ve done this in a number of packages, it requires a bit of work initially,
but not that much.
What I’d do is have something like this in mother/inst/include/mother.h :
#if defined(COMPILING_MOTHER)
// just declare, will be defined in test.c
SEXP fun(SEXP test) ;
#else
inline SEXP fun(SEXP test){
typedef SEXP(*Fun)(SEXP);
static Fun fun = (Fun)R_GetCCallable(mother, fun) ;
return fun(test) ;
}
#endif
In your test.c file, make sure you define COMPILING_MOTHER before you include
mother.h, something like this
#include R.h
#include Rinternals.h
#include R_ext/Rdynload.h
#define COMPILING_MOTHER
#include mother.h
SEXP fun(SEXP);
void R_init_mother(DllInfo *dll) {
R_RegisterCCallable(mother, fun, (DL_FUNC) fun);
}
SEXP fun(SEXP test) {
Rprintf(fun so much fun\n);
return R_NilValue;
}
So that in your child package you only have to use it, something like:
#include Rinternals.h
#include R_ext/Rdynload.h
#include mother.h
SEXP afun(SEXP test) {
fun(test);
return R_NilValue;
}
Note that if you only want the interface between the two packages to be at low
level (not visible from R), then you don’t need to conform to the SEXP(SEXP...)
interface. You can use anything you like.
Romain
Le 22 janv. 2014 à 19:56, Gregor Kastner gregor.kast...@wu.ac.at a écrit :
Hi again,
On Wed, 22 Jan 2014 06:39:17 -0600
Dirk Eddelbuettel e...@debian.org wrote:
| Working examples I know of:
|
|'xts' importing two functions from 'zoo'
|
|'RcppXts' importing approx. ten functions from 'xts'
|
| Maybe by comparing to these you can sort out the missing step at your end.
Thanks Dirk for the hints; I finally got the code running. Important point
is that R_init_PKGNAME() is declared as extern C (or RcppExport, of course)
if using g++ in both the mother and the child package. (Interestingly,
dyn.load() only complains when either the mother or the child package don't
do so, but not if both don't do so = SEGFAULT.) Since it took me almost the
entire afternoon to figure that out, I'll document a working example here.
Scenario: We have a 'mother' package, which wants to make some C/C++ routines
available to the 'child' package to be called directly from C/C++ level.
Thus, mother's 'src' cointains:
* BEGIN test.c *
#include R.h
#include Rinternals.h
#include R_ext/Rdynload.h
SEXP fun(SEXP);
void R_init_mother(DllInfo *dll) {
R_RegisterCCallable(mother, fun, (DL_FUNC) fun);
}
SEXP fun(SEXP test) {
Rprintf(fun so much fun\n);
return R_NilValue;
}
** END test.c **
(Note that no extern C is needed here because it will be compiled with gcc
anyway).
The child uses Rcpp and mother, thus has
* BEGIN DESCRIPTION *
LinkingTo: mother, Rcpp
Depends: mother, Rcpp
Imports: mother, Rcpp
** END DESCRIPTION **
in its DESCRIPTION file, and
* BEGIN test.cpp *
#include Rinternals.h
#include R_ext/Rdynload.h
extern C {
SEXP afun(SEXP);
SEXP(*fun)(SEXP);
void R_init_child(DllInfo *info) {
fun = (SEXP(*)(SEXP)) R_GetCCallable(mother, fun);
}
SEXP afun(SEXP test) {
fun(test);
return R_NilValue;
}
}
** END test.cpp **
(Note that extern C is crucial here.) After installing mother and child, we
have:
library(child)
Loading required package: mother
Loading required package: Rcpp
.Call(afun, 123, PACKAGE=child)
fun so much fun
NULL
Maybe it is of help to someone; please excuse me if I bored anyone with
trivialities.
Best,
Gregor
__
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
Re: [Rd] External pointers and changing SEXPTYPE
Hi,
One solution to protect an object from the GC is to use the R_PreserveObject
and R_ReleaseObject functions.
This way, you are not subject to the stack that PROTECT, UNPROTECT,
UNPROTECT_PTR uses.
Using R_PreserveObject and R_ReleaseObject is one of the best things that has
ever happened to Rcpp.
Romain
Le 16 déc. 2013 à 12:07, Krzysztof Mlynarczyk mitomas...@gmail.com a écrit :
As far as I understood the documentation, external pointer should be
automatically protected from gc when returned to environment. The
solution you've just suggested would cause stack imbalance.
Recently I've been thinking of encapsulating the pointer into a nice
object using Rcpp. This sounds better that telling people to have fun
with an external pointer itself.
KM
2013/12/16 peter dalgaard pda...@gmail.com:
Offhand, I'd say that if all protects get unprotected before return
mydata-ans is not protected against garbage collection, and thus very
likely collected and reused. If mydata is created by Calloc, the GC has no
way of knowing that it might have pointers to things that are intended to
persist.
I haven't played with external pointers for a while, but I'd expect that
you'd need to retain a PROTECT on mydata-ans, and then UNPROTECT_PTR or so
in the finalizer.
-pd
On 16 Dec 2013, at 04:11 , Krzysztof Mlynarczyk mitomas...@gmail.com wrote:
Dear Developers,
I've been struggling through writing R extension in C. I've been using
an external pointer to store my data (please see sample below). I
encountered a very weird erroneous behaviour: when I tried to use my
external pointer to a structure holding several types of data,
including SEXPs, I discovered that SEXPs change their types between
returning from initialization function and another one that uses the
pointer.
sample R code:
# initializing
a - init_my_ptr(fname)
# reading more data: error!
df - read_my_data(a)
data structure in C:
typedef struct {
SEXP ans, ans_nms, R_z, R_a, R_b, R_c;
FTYPE *datafile;
char *fname;
float *a, *b, *c;
int f_type;
float t, p, l;
int st, na, result, bFlags;
XXX z;
} my_data_ptr;
// In a C function initializing the external pointer:
my_data_ptr *mydata = Calloc( 1, my_data_ptr ) ;
SEXP Rdata;
PROTECT(Rdata = R_MakeExternalPtr( mydata, R_fname, R_NilValue ));
...
mydata-a = Calloc(mydata-na, float);
// same for b and c
// initializing names so that I could use e.g. df$a where df is
returned by read_my_data()
PROTECT(mydata-ans_nms = Rf_allocVector(STRSXP, efldNR ));
for( ix = 0; ix efldNR; ix++ )
SET_STRING_ELT(mydata-ans_nms, ix, mkChar(vnames[ix]));
// later I bind values of non-R variables from my data structure to a
proper vector
PROTECT(mydata-ans = Rf_allocVector(VECSXP, efldNR ));
Rf_setAttrib(mydata-ans, R_NamesSymbol, mytraj-ans_nms);
SET_VECTOR_ELT(mydata-ans, 0, mydata-R_a );
SET_VECTOR_ELT(mydata-ans, 1, mydata-R_b );
...
// all protects get unprotected before return
// finalizer is registered as well
return Rdata;
Later on in read_my_data() I read the pointer:
my_data_ptr *mydata = (my_data_ptr*) R_ExternalPtrAddr(Rdata);
// and REAL(mydata-R_a) yields error since TYPEOF(mydata-R_a) is not
REALSXP as it should be but RAWSXP for some reason // (sometimes it's
STRSXP or INTSXP while it should always be REALSXP)
// The error message says:
// REAL() can only be applied to a 'numeric', not a 'raw'
// mydata-ans is the object returned to R where all the data is made
available to R user:
return mydata-ans;
// end of example code
Could you please point the possible reasons for the error along with
the ways of fixing this issue? I've been trying in R-3.0.2, 3.0.1 and
even 2.15 -- the problem happens in each of them.
Regards,
Christopher
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] internal manipulation of ...
Thanks. This works for me. See this gist:
https://gist.github.com/romainfrancois/7959531
Romain
Le 13 déc. 2013 à 01:09, Hadley Wickham h.wick...@gmail.com a écrit :
Could you pass the environment and then look for the object called ... in it?
f - function(...) {
.Call(my_fun, environment())
}
I think (and may well be wrong) that you can use standard tools to
find the DOTSXP object in that environment.
Hadley
On Thu, Dec 12, 2013 at 2:32 PM, Romain François
rom...@r-enthusiasts.com wrote:
Hello,
I’m looking for examples on how to manipulate the ... internally, e.g. in a
.Call or .External function.
I’m particularly interested in accessing the environment in which each
contribution to ... can be evaluated.
So far, I’m using tricks involving passing down the sys.calls() and
sys.frames() down to the C function. The documentation in
http://cran.r-project.org/doc/manuals/R-ints.html#Dot_002ddot_002ddot-arguments
did not help me a lot.
Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] internal manipulation of ...
Hello, I’m looking for examples on how to manipulate the ... internally, e.g. in a .Call or .External function. I’m particularly interested in accessing the environment in which each contribution to ... can be evaluated. So far, I’m using tricks involving passing down the sys.calls() and sys.frames() down to the C function. The documentation in http://cran.r-project.org/doc/manuals/R-ints.html#Dot_002ddot_002ddot-arguments did not help me a lot. Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] internal manipulation of ...
Le 13 déc. 2013 à 00:15, Simon Urbanek simon.urba...@r-project.org a écrit : On Dec 12, 2013, at 3:32 PM, Romain François rom...@r-enthusiasts.com wrote: Hello, I’m looking for examples on how to manipulate the ... internally, e.g. in a .Call or .External function. I’m particularly interested in accessing the environment in which each contribution to ... can be evaluated. Arguments in ... are evaluated *before* being passed down to .Call/.External so there is no ... by the time you enter the C code. AFAIR R doesn't allow you to get at the promises outside of internal code, so you either get the call or the values, but nothing in between. Cheers, Simon Thanks. That confirms what I feared. Back at low level manipulation of call stack and frame stack then. :/ Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] extending the colClasses argument in read.table
Hello,
We've released the int64 package to CRAN a few days ago. The package
provides S4 classes int64 and uint64 that represent signed and
unsigned 64 bit integer vectors.
One further development of the package is to facilitate reading 64 bit
integer data from csv, etc ... files.
I have this function that wraps a call to read.csv to:
- read the int64 and uint64 columns as character
- converts them afterwards to the appropriate type
read.csv.int64 - function (file, ...){
dots - list( file, ... )
if( colClasses %in% names(dots) ){
colClasses - dots[[colClasses]]
idx.int64 - colClasses == int64
idx.uint64 - colClasses == uint64
colClasses[ idx.int64 | idx.uint64 ] - character
dots[[colClasses ]] - colClasses
df - do.call( read.csv, dots )
if( any( idx.int64 ) ){
df[ idx.int64 ] - lapply( df[ idx.int64 ], as.int64 )
}
if( any( idx.uint64 ) ){
df[ idx.uint64 ] - lapply( df[ idx.uint64 ], as.uint64 )
}
df
} else {
read.csv( file, ... )
}
}
I was wondering if it would make sense to extend the colClasses argument
so that other package can provide drivers, so that we could let the
users just use read.csv, read.table, etc ...
Before I start digging into the internals of read.table, I wanted to
have opinions about whether this would be a good idea, etc ...
Best Regards,
Romain
--
Romain Francois
Professional R Enthusiast
http://romainfrancois.blog.free.fr
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
