Re: [Rd] compiling Rcpp with 3.0.1 on Solaris 10

[romain]

Hello,

Rcpp has its own mailing list (Rcpp-devel, see 
http://lists.r-forge.r-project.org/mailman/listinfo/rcpp-devel).


We lack man power for solaris, and typically we realize there are 
issues when it is too late.

If you can help, that would be huge help. To compile Rcpp, you can do:

$ svn checkout svn://svn.r-forge.r-project.org/svnroot/rcpp/pkg/Rcpp
$ R CMD INSTALL Rcpp

or

$ R CMD build Rcpp
$ R CMD INSTALL Rcpp_*.tar.gz

If you can suggest us a few fixes related to your findings, then we can 
attempt to fix them and get a better solaris support. I already see a 
few items below that are worth looking at.


Best regards,

Romain

Le 2013-06-21 14:25, MAYER Hans a écrit :

Hello

My colleagues asked me to install "R" with module "shiny".
R version 3.0.1 compiled fine on Solaris 10 and is running well.

I tried to install "shiny". With the dependencies "Rcpp" should be
installed before. But the compile step did fail. See below.
The initial error message is "Error in dyn.load(file, DLLpath =
DLLpath, ...) :"
Before there are some warning. The final problem is, that the shared
library Rcpp.so was not generated.

I am not familiar with R but I  could manage to compile a lot of
source code on Solaris. Very often it's only a small change in
Makefile or source code.
Is there a way to compile "Rcpp" manually ?
Or how-to fix this problem. I am sure, it's not a major issue.

Kind regards
Hans




# R

R version 3.0.1 (2013-05-16) -- "Good Sport"
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: sparc-sun-solaris2.10 (32-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and 'citation()' on how to
cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.


install.packages('Rcpp')

--- Please select a CRAN mirror for use in this session --- trying
URL 'http://cran.rstudio.com/src/contrib/Rcpp_0.10.3.tar.gz'
Content type 'application/x-gzip' length 2395986 bytes (2.3 Mb)
opened URL ==
downloaded 2.3 Mb

* installing *source* package 'Rcpp' ...
** package 'Rcpp' successfully unpacked and MD5 sums checked
** libs
g++ -I/usr/local/lib/R/include -DNDEBUG -I../inst/include/
g++ -I/usr/local/include -I/usr/sfw/include -I/opt/sfw/include    
-fPIC 

g++ -g -O2  -c Date.cpp -o Date.o
Date.cpp: In member function `void Rcpp::Date::update_tm()':
Date.cpp:108: warning: converting to `time_t' from `double'
Date.cpp: In member function `double Rcpp::Date::mktime00(tm&) 
const':

Date.cpp:134: warning: converting to `int' from `double'
Date.cpp:137: warning: converting to `int' from `double'
Date.cpp: In function `Rcpp::Date Rcpp::operator+(const Rcpp::Date&, 
int)':

Date.cpp:164: warning: converting to `time_t' from `double'
Date.cpp: In function `int Rcpp::operator-(const Rcpp::Date&, const
Rcpp::Date&)':
Date.cpp:170: warning: converting to `int' from `double'
Date.cpp: In function `tm* Rcpp::timesub(const time_t*, long int,
const Rcpp::state*, tm*)':
Date.cpp:1523: warning: converting to `long int' from `double'
g++ -I/usr/local/lib/R/include -DNDEBUG -I../inst/include/
g++ -I/usr/local/include -I/usr/sfw/include -I/opt/sfw/include    
-fPIC 

g++ -g -O2  -c Module.cpp -o Module.o
gcc -std=gnu99 -I/usr/local/lib/R/include -DNDEBUG -I../inst/include/
-I/usr/local/include -I/usr/sfw/include -I/opt/sfw/include    -fPIC 
-g -O2  -c Rcpp_init.c -o Rcpp_init.o
g++ -I/usr/local/lib/R/include -DNDEBUG -I../inst/include/
g++ -I/usr/local/include -I/usr/sfw/include -I/opt/sfw/include    
-fPIC 
g++ -g -O2  -c Timer.cpp -o Timer.o -I/usr/local/lib/R/include 
-DNDEBUG

g++ -I../inst/include/ -I/usr/local/include -I/usr/sfw/include
g++ -I/opt/sfw/include    -fPIC  -g -O2  -c api.cpp -o api.o
g++ -I/usr/local/lib/R/include -DNDEBUG -I../inst/include/
g++ -I/usr/local/include -I/usr/sfw/include -I/opt/sfw/include    
-fPIC 

g++ -g -O2  -c attributes.cpp -o attributes.o
attributes.cpp: In member function
`std::vector >
Rcpp::attributes::SourceFileAttributesParser::parseParameters(const
std::string&)':
attributes.cpp:986: warning: converting of negative value
`-0x1' to `size_t'
g++ -I/usr/local/lib/R/include -DNDEBUG -I../inst/include/
g++ -I/usr/local/include -I/usr/sfw/include -I/opt/sfw/include    
-fPIC 

g++ -g -O2  -c barrier.cpp -o barrier.o -I/usr/local/lib/R/include

Re: [Rd] Get the tail of a list in C

[romain]

Le 2013-07-05 07:15, maxpar a écrit :

Hi,

I am write R extensions in C. Now I have a VECSXP variable, so how 
can I get
the tail of it (all but the first one) as a new VECSXP. I tried 
CDR(), but

it gives error.

Thanks.


Hello,

A VECSXP is actually an array of pointers, not a linked list. If you 
want the tail, you have to allocate new data.
For a simplistic version that does not deal with attributes, names, etc 
..., try something like this:


int n = length( x ) - 1  ;
SEXP taildata = PROTECT( allocVector( VECSXP, n ) ) ;
for( int i=0; ihttps://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Using long long types in C++

[romain]

Hello,

In Rcpp we'd like to do something useful for types such as long long 
and unsigned long long.


For example, supporting our usual wrap construct. We'd like to be able 
to "wrap" a long long, or perhaps a std::vector so that it is 
returned to the R side in something meaningful (we are considering 
several options like loosing some precision and returning an int, 
loosing a bit less precision and returning a double or use bit shifting 
tricks and do something compatible with the bit64 package).


To do this, we try to be careful and hide the code behind these two PP 
tests:


#if defined(__GNUC__) &&  defined(__LONG_LONG_MAX__)

which tests for gcc compatible (includes clang) compiler and the 
availability of the long long type.



Now this is not enough and we also have to use __extension__ to disable 
warnings that are emitted by -pedantic. So we have something like this:


#if defined(__GNUC__) &&  defined(__LONG_LONG_MAX__)
__extension__ typedef long long int rcpp_long_long_type;
__extension__ typedef unsigned long long int rcpp_ulong_long_type;
#define RCPP_HAS_LONG_LONG_TYPES
#endif

and for the rest of what we do with these types, we use 
rcpp_long_long_type and rcpp_ulong_long_type and hide the code behind 
#if defined(RCPP_HAS_LONG_LONG_TYPES)



But apparently this is still not enough and on some versions of gcc 
(e.g. 4.7 something), -pedantic still generates the warnings unless we 
also use -Wno-long-long



Dirk tells me that the fact that these warnings show up means that it 
would not be accepted in CRAN. I understand that -pedantic is useful for 
finding potential portability problems, but in that case I believe 
everything is done to isolate the use of long long to a situation where 
we know we can use it given that we test for a compiler (gcc) and its 
known way to check for existence of long long: __LONG_LONG_MAX__


What are my options here ?

Romain

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R 3.1.0 and C++11

[romain]

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.


Romain


Sincerely,
Whit

On Mon, Oct 7, 2013 at 5:47 PM, Dirk Eddelbuettel  
wrote:




Hi Martyn,

On 7 October 2013 at 21:18, Martyn Plummer wrote:
| I don't see any harm in allowing optional C++11 support,

That would be a nice step forward.

| and it is no trouble to update the documentation to acknowledge 
the

| existence of C++11 conforming compilers.

Indeed.

| However, the questions of what is possible, what is recommended, 
and what

|  is required for CRAN submissions are distinct.

You may be aware of the difficulties we as R package developers have 
with

discussions involving CRAN maintainers.

| I have a couple of comments on the macro:
| a) Your version implies mandatory C++11 support. One needs
| AX_CXX_COMPILE_STDCXX_11(noext,optional) for optional support.

I used an existing macros from the GNU autoconf archive. It can 
certainly

be
tweaked. R's stack of configure logic is an impressive piece of work 
and I
wasn't expecting this to flow through. It was meant to start a 
discussion.


My principal points are that

   i)  we do have compilers now that can support this, and

   ii) we can test for their capabilities when R itself is compiled.

| b) I find it unhelpful that the macro picks up the partial C++11 
support

in
| gcc 4.7 via the -std=c++0x flag, so I would edit (and rename) the 
macro

to
| remove this.

Of course. All this can and should be discussed. I just wanted to 
get the
ball rolling and had a choice between just emailing Kurt (as the 
configure

and m4 point man) and emailing here.

To the extent that c++0x support is also widely available, I do not 
see why
one could not allow it either.  But that is a minor issue: I would 
really
like us to (eventually) move beyond what is going to become a more 
and more

constraining C++ standard.

Optional support for deployments where C++11 is indeed available 
seems

like a
step in the right direction.

Thanks for your feedback!

Dirk

| Martyn
| 
| From: r-devel-boun...@r-project.org 
[r-devel-boun...@r-project.org] on

behalf of Dirk Eddelbuettel [e...@debian.org]
| Sent: 07 October 2013 01:54
| To: R-devel org
| Subject: [Rd] R 3.1.0 and C++11
|
| I would like to bring up two issues concerning C++11.
|
|
| First, the R-devel manuals contain incorrect statements regarding 
C++11:

|
|   i)   R-exts.texi:
|
|Although there is a 2011 version of the C++ standard, it is 
not

yet
|fully implemented (nor is it likely to be widely available 
for

some
|years) and portable C++ code needs to follow the 1998 
standard

|(and not use features from C99).
|
|   ii)  R-ints.texi:
|
|The type `R_xlen_t' is made available to packages in C 
header

|`Rinternals.h': this should be fine in C code since C99 is
|required.  People do try to use R internals in C++, but 
C++98
|compilers are not required to support these types (and 
there are

|currently no C++11 compilers).
|
| But since the summer we have g++ and clang with working C++11
implementations:
|
|   iii) g++ implements C++11:
|

http://isocpp.org/blog/2013/05/gcc-4.8.1-released-c11-feature-complete
|
|   iv)  llvm/clang++ implements C++11:
|http://isocpp.org/blog/2013/06/llvm-3.3-is-released
|
| I would suggest to change the wording prior to the release of R 
3.1.0

next
| year as it is likely that even Microsoft will by then have a
fully-conformant
| compiler (per Herb Sutter at a recent talk in Chicago). If it 
helped, I

would
| be glad to provide minimal patches to the two .texi files.
|
| Moreover, the C++ Standards Group is working towards closing the 
delta
| between standards being adopted, and compilers being released. 
They

expect
| corresponding compilers for C++14 (a "patch" release for C++11 
expected

to be
| ready next spring) to be available within a year---possibly during 
2014.

|
|
| Second, the current R Policy regarding C++11 is unnecessarily 
strict. I

would
| propose to treat the availability of C++11 extensions more like 
the
| availability of OpenMP: something which configure can probe at 
build

time,
| and which can be deployed later via suitable #ifdef tests.
|
| As a proof of concept, I added this macro from the autoconf 
archive to

the
| m4/ directory of R-devel:
|
|

http://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html
|
| and made a one-line change to configure.ac (indented two spaces 
just

for em

Re: [Rd] extending the colClasses argument in read.table

[romain]

Thanks gabor, 

I will implement this and publish an updated package later. 

Cheers, 

Romain



Le 21 nov. 2011 à 16:31, Gabor Grothendieck  a écrit :

> 2011/11/21 Romain François :
>> 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
>> 
> 
> Try this:
> 
>> library(int64)
>> Lines <- "A\n12\n"
>> 
>> setAs("character", "int64", function(from) as.int64(from))
>> 
>> DF <- read.csv(textConnection(Lines), colClasses = "int64")
>> 
>> str(DF)
> 'data.frame':   1 obs. of  1 variable:
> $ A:Formal class 'int64' [package "int64"] with 2 slots
>  .. ..@ .Data:List of 1
>  .. .. ..$ : int  0 12
>  .. ..@ NAMES: NULL
> 
> To convince ourselves that its translating from character to int64:
> 
>> setAs("character", "int64", function(from) {print(class(from)); 
>> as.int64(from)})
>> DF <- read.csv(textConnection(Lines), colClasses = "int64")
> [1] "character"
> 
> 
> -- 
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] reinterpreting externalptr in R

[romain]

Andre,

For Rcpp, you can use the XPtr class template. Say you want to deal 
with pointers to Foo. You can create an R external pointer like this:


SEXP create_xp_foo(){
Foo* foo = new Foo ;
XPtr xp( foo ) ;
return xp ;
}

Now, "xp" is an R external pointer, i.e. a SEXP of type EXTPTRSXP, that 
you can send back to the R side. This constructor assumes ownership of 
the pointer, so when the SEXP is no longer protected, it becomes 
candidate for garbage collection, and then the finalizer deletes the 
object using C++ delete operator. The XPtr template lets you control 
these finalizers. We can discuss further if you want to know more.




If you then send it back to the C++ side, you can get back the Foo 
pointer like this:


SEXP use_foo( SEXP xp ){
XPtr foo(xp);
// conversion operator
Foo* p_foo = foo ;
do_whatever( p_foo ) ;
return R_NilValue ;
}

The XPtr template defines C++ operators so that the XPtr object 
can be converted to a Foo*.


You can find details about the XPtr template in Rcpp documentation or 
perhaps just reading the source at r-forge:

https://r-forge.r-project.org/scm/viewvc.php/pkg/Rcpp/inst/include/Rcpp/XPtr.h?view=markup&root=rcpp

This simply builds on the macros that the R api offers, so perhaps 
"writing R extensions" or "R internals" are good sources of information.


Romain


Le 2012-12-25 18:15, Simon Urbanek a écrit :

On Dec 25, 2012, at 6:39 AM, andre__ wrote:


Hi,

I am using swig to build a wrapper for an c-function to use it in R. 
I would
like to define a generic function, which gives back a void pointer. 
On the R
side, I know what this pointer is pointing to, whether it is an 
integer or
an string, or something else... but I need to somehow reinterpret 
the

resulting "externalptr" into another form...

a function that looks like the following:

*void* test(){
   std::string str="test";
   return str.c_str();
}*

when I call this from R:

*str <- test()
typeof(str) % result is: "externalptr"*

how could I reinterpret this to a charcterarray, to a numeric, to 
list, or

...



The simple answer is you can't. External pointers are entirely opaque
to R, so *you* have to write that code that interprets them. 
Obviously

it's then up to you to create the corresponding R object from the
external pointer.

You may want to have a look at interface packages like Rcpp, rJava,
Rserve, ... to understand how objects are converted to/from other
languages.

Cheers,
Simon




Thanks for any suggestions ;)


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] hello World problem

[Romain Francois]

Hi,

I'm trying to build a simple R package 'helloWorld' with just one 
function that prints 'hello World' on the C side.
I agree that it is completely useless, but I just start mixing R and C.

My C file is as follows :

#include 
void helloWorld() {
  printf("hello world !\n") ;
}

When I call it from R, here is what happens :
R> .C("helloWorld", PACKAGE = "helloWorld")
hello world !
list()

is it normal that 'list()' is printed ?

Thanks.

Romain

-- 
visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
mixmod 1.7 is released : http://www-math.univ-fcomte.fr/mixmod/index.php
+---+
| Romain FRANCOIS - http://francoisromain.free.fr   |
| Doctorant INRIA Futurs / EDF  |
+---+

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] generate Rd file from R file

[Romain Francois]

Hi,

Is there something similar to javadoc or doxygen for R, ie ability to 
create a first draft of an Rd file reading the comments that are in a 
script file?

For example, for the weighted.mean function in base, one could write the 
source as :

weighted.mean <- function(
x, #@ a numeric vector containing the values whose mean is to be 
computed. 
w, #@ a vector of weights the same length as |x| giving the weights 
to use for each element of |x|.
na.rm = FALSE  #@ a logical value indicating whether |NA |values in |x| should 
be stripped before the computation proceeds.
)
#e wt <- c(5,  5,  4,  1)/15
#e x <- c(3.7,3.3,3.5,2.8)
#e xm <- weighted.mean(x,wt)


and get a draft file more full than what may be created with prompt.
Of course, I do not ask for a way to not write all the information in 
one file ... but some can be shared between R and Rd

Romain



-- 
visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
mixmod 1.7 is released : http://www-math.univ-fcomte.fr/mixmod/index.php
+-------+
| Romain FRANCOIS - http://francoisromain.free.fr   |
| Doctorant INRIA Futurs / EDF  |
+---+

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] What about a bib file

[Romain Francois]

Hi,

Doing the following command on the freshest R-devel i get 223 entries :

$ grep  "The New S Language" */man/*.Rd | wc -l

Would it make sense to add a bib file (or another format) such that one 
could do something like :

\cite{blueBook}

or even :

\cite[base]{blueBook}

What do you think ?

Romain

-- 
visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
mixmod 1.7 is released : http://www-math.univ-fcomte.fr/mixmod/index.php
+---+
| Romain FRANCOIS - http://francoisromain.free.fr   |
| Doctorant INRIA Futurs / EDF  |
+---+

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] javascript device for R

[Romain Francois]

Hi,

Has anyone started a javascript device for R.
I don't see something like that googling or at on 
http://www.stat.auckland.ac.nz/~paul/R/devices.html
For example, using that graphics library : 
http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm
(I cc that message to the author.)

ps : this is not a feature request, i will do it. But if someone has 
started that, let me know.

Romain

-- 
visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
mixmod 1.7 is released : http://www-math.univ-fcomte.fr/mixmod/index.php
+---+
| Romain FRANCOIS - http://francoisromain.free.fr   |
| Doctorant INRIA Futurs / EDF  |
+---+

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] NAMESPACE Q: does import as exist?

[Romain Francois]

Le 08.02.2006 04:26, Seth Falcon a écrit :

>On  7 Feb 2006, [EMAIL PROTECTED] wrote:
>
>  
>
>>>On 2/7/2006 8:48 PM, Seth Falcon wrote:
>>>  
>>>
>>>>Is there a way to rename a function when importing it?  I 
>>>>
>>>>
>>>want to say, 
>>>  
>>>
>>>>"import yourFunc from Foo as myFunc" in the NAMESPACE file.
>>>>
>>>>
>>I don't think Seth's facility exists yet, but it has occurred to me
>>previously that it would be useful when you need to import two
>>different functions with the same name from two different
>>packages. (Rare but does happen.) Duncan's solution won't get around
>>that. So it would be nice to be able to do this
>>
>>ImportFromAs( 'pack1', 'funca', 'pack1.funca')
>>ImportFromAs( 'pack2', 'funca', 'different.name.altogether')
>>
>>in a NAMESPACE file. Useful-- yes. Possible-- I don't know!
>>    
>>
>
>Yes, this is along the lines of what I was thinking.  
>
>An unpleasant work around would be to create a translation package
>that does something along the lines of Duncan M.'s suggestion,
>importing, renaming, exporting.
>  
>
What about :

bar <- pack::foo
kok <- otherpack::foo


Romain

-- 
visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
mixmod 1.7 is released : http://www-math.univ-fcomte.fr/mixmod/index.php
+---+
| Romain FRANCOIS - http://francoisromain.free.fr   |
| Doctorant INRIA Futurs / EDF  |
+---+

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_ext/Altrep.h should be more C++-friendly

[Romain Francois]

I successfully use this workaround in this package: 
https://github.com/romainfrancois/altrepisode

(which is just my way to get familiar with altrep, nothing serious)

> Le 9 oct. 2018 à 17:00, Gabe Becker  a écrit :
> 
> Michael,
> 
> Thanks for reaching out. This was brought up by Romaine Francois offline to 
> me as well. What he does as a workaround is 
> 
> 
> #define class klass
> extern "C" {
>   #include 
> }
> #undef class
> 
> While we consider changing Altrep.h, the above should work for you  in the 
> immediate term.
> 
> Let me know if it doesn't.
> 
> ~G
> 
> 
> 
> 
> 
>> On Mon, Oct 8, 2018 at 4:17 PM, Michael Sannella via R-devel 
>>  wrote:
>> I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think
>> it needs two changes:
>> 
>> 1. add the same __cplusplus check as most of the other header files:
>> #ifdef  __cplusplus
>> extern "C" {
>> #endif
>> ...
>> #ifdef  __cplusplus
>> }
>> #endif
>> 
>> 2. change the line
>> R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
>>  to
>> R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
>>  since C++ doesn't like an argument named 'class'
>> 
>>   ~~ Michael Sannella
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> 
> 
> -- 
> Gabriel Becker, Ph.D
> Scientist
> Bioinformatics and Computational Biology
> Genentech Research

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_ext/Altrep.h should be more C++-friendly

[Romain Francois]

Thank you, 

I updated my example package so that it works with both. 
https://github.com/romainfrancois/altrepisode/blob/96af0548a9ecc08701d119ea427e16940a82882b/src/altrepisode.h
 
<https://github.com/romainfrancois/altrepisode/blob/96af0548a9ecc08701d119ea427e16940a82882b/src/altrepisode.h>

We have to do something like this unless we depend on R 3.6.0: 

#if R_VERSION < R_Version(3, 6, 0)
  #define class klass
  extern "C" {
#include 
  }
  #undef class
#else
  #include 
#endif

Romain

> Le 9 oct. 2018 à 05:09, Tierney, Luke  a écrit :
> 
> Thanks for the suggestion. Committed in R_devel.
> 
> Best,
> 
> luke
> 
> On Mon, 8 Oct 2018, Michael Sannella wrote:
> 
>> I am not able to #include "R_ext/Altrep.h" from a C++ file.  I think
>> it needs two changes:
>> 
>> 1. add the same __cplusplus check as most of the other header files:
>> #ifdef  __cplusplus
>> extern "C" {
>> #endif
>> ...
>> #ifdef  __cplusplus
>> }
>> #endif
>> 
>> 2. change the line
>> R_new_altrep(R_altrep_class_t class, SEXP data1, SEXP data2);
>>  to
>> R_new_altrep(R_altrep_class_t cls, SEXP data1, SEXP data2);
>>  since C++ doesn't like an argument named 'class'
>> 
>>   ~~ Michael Sannella
>> 
>> 
>> 
> 
> -- 
> Luke Tierney
> 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


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Use of C++ in Packages

[Romain Francois]

tl;dr: we need better C++ tools and documentation. 

We collectively know more now with the rise of tools like rchk and improved 
documentation such as Tomas’s post. That’s a start, but it appears that there 
still is a lot of knowledge that would deserve to be promoted to actual 
documentation of best practices. 

I think it is important to not equate C++ as a language, and Rcpp. 

Also, C++ is not just RAII. 

RAII is an important part of how Rcpp was conceived for sure, but it’s not the 
only thing C++ can bring as a language. Templates, lambdas, the stl are 
examples of things that can be used for expressiveness when just accessing data 
without interfering with R, calling R api functions ... 

It would be nice that the usual « you should do that only if you know what 
you’re doing » be transformed to precise documentation, and maybe become part 
of some better tool. If precautions have to be taken before calling such and 
such functions: that’s ok. What are they ? Can we embed that in some tool.

 It is easy enough to enscope code that uses potentially jumpy code into a c++ 
lambda. This could be together with recommendations such as the body of the 
lambda shall only use POC data structures. 

This is similar to precautions you’d take when writing concurrent code. 

Romain

> Le 30 mars 2019 à 00:58, Simon Urbanek  a écrit :
> 
> Kevin,
> 
> 
>> On Mar 29, 2019, at 17:01, Kevin Ushey  wrote:
>> 
>> I think it's also worth saying that some of these issues affect C code
>> as well; e.g. this is not safe:
>> 
>>   FILE* f = fopen(...);
>>   Rf_eval(...);
>>   fclose(f);
> 
> I fully agree, but developers using C are well aware of the necessity of 
> handling lifespan of objects explicitly, so at least there are no surprises.
> 
> 
>> whereas the C++ equivalent would likely handle closing of the file in the 
>> destructor. In other words, I think many users just may not be cognizant of 
>> the fact that most R APIs can longjmp, and what that implies for cleanup of 
>> allocated resources. R_alloc() may help solve the issue specifically for 
>> memory allocations, but for any library interface that has a 'open' and 
>> 'close' step, the same sort of issue will arise.
> 
> Well, I hope that anyone writing native code in package is well aware of that 
> and will use an external pointer with finalizer to clean up native objects in 
> any 3rd party library that are created during the call.
> 
> 
>> What I believe we should do, and what Rcpp has made steps towards, is make 
>> it possible to interact with some subset of the R API safely from C++ 
>> contexts. This has always been possible with e.g. R_ToplevelExec() and 
>> R_ExecWithCleanup(), and now things are even better with R_UnwindProtect(). 
>> In theory, as a prototype, an R package could provide a 'safe' C++ interface 
>> to the R API using R_UnwindProtect() and friends as appropriate, and client 
>> packages could import and link to that package to gain access to the 
>> interface. Code generators (as Rcpp Attributes does) can handle some of the 
>> pain in these interfaces, so that users are mostly insulated from the nitty 
>> gritty details.
> 
> I agree that we should strive to provide tools that make it safer, but note 
> that it still requires participation of the users - they have to use such 
> facilities or else they hit the same problem. So we can only fix this for the 
> future, but let's start now.
> 
> 
>> I agree that the content of Tomas's post is very helpful, especially since I 
>> expect many R programmers who dip their toes into the C++ world are not 
>> aware of the caveats of talking to R from C++. However, I don't think it's 
>> helpful to recommend "don't use C++"; rather, I believe the question should 
>> be, "what can we do to make it possible to easily and safely interact with R 
>> from C++?". Because, as I understand it, all of the problems raised are 
>> solvable: either through a well-defined C++ interface, or through better 
>> education.
> 
> I think the recommendation would be different if such tools existed, but they 
> don't. It was based on the current reality which is not so rosy.  Apparently 
> the post had its effect of mobilizing C++ proponents to do something about 
> it, which is great, because if this leads to some solution, the 
> recommendation in the future may change to "use C++ using tools XYZ".
> 
> 
>> I'll add my own opinion: writing correct C code is an incredibly difficult 
>> task. C++, while obviously not perfect, makes things substantially easier 
>> with tools like RAII, the STL, smart pointers, an

Re: [Rd] What is the best way to loop over an ALTREP vector?

[Romain Francois]

Thanks for these comments. I should alter the blog post or write some follow 
up. 

This was a weekend blog post that only benefited from a short time of research 
research. I’m glad people find it useful, but I’m sure a detailed documentation 
of the features from the authors would be more useful. 

Romain

> Le 24 sept. 2019 à 07:48, Gabriel Becker  a écrit :
> 
> Hi Bob,
> 
> Thanks for sending around the link to that. It looks mostly right and looks
> like a useful onramp. There are a few things to watch out for though (I've
> cc'ed Romain so he's aware of these comments). @romain I hope you taake the
> following comments as they are intended, as help rather than attacks.
> 
> The largest issue I see is that the contract for Get_region is that it
> *populates the
> provided buffer with a copy of the data. *That buffer is expected to be
> safe to destructively modify, shuffle, etc though I don't know if we are
> actually doing that anywhere. As such, if I understand his C++ correctly,
> that Get_region method  is not safe and shouldn't be used.
> 
> The other point is that Dataptr_or_null is not actually *guaranteed *not to
> allocate. The default method returns NULL, but we have no way of preventing
> an allocation in a user-defined method, and probably (?) no easy way of
> detecting that it is occurring before it causes a bug. That said, Romain is
> correct that when you are writing Dataptr_or_null methods you should write
> them so that they don't allocate, generally. Basically your methods for
> Dataptr_or_null shouldn't allocate, but you also should not write code that
> relies on hard assumptions that no one's ever will.
> 
> Also, a small nitpick, R's internal mean function doesn't hit Dataptr, it
> hits either INTEGER_ELT (which really should probably be a
> ITERATE_BY_REGION) or ITERATE_BY_REGION.
> 
> Anyway, I hope that helps.
> ~G
> 
> 
> 
> 
> 
> 
> On Mon, Sep 23, 2019 at 6:12 PM Bob Rudis mailto:b...@rud.is>> 
> wrote:
> 
>> Not sure if you're using just C++ or Rcpp for C++ access but
>> https://purrple.cat/blog/2018/10/14/altrep-and-cpp/ has some tips on
>> using C++ w/ALTREP.
>> 
>>> On Sep 23, 2019, at 3:17 PM, Wang Jiefei  wrote:
>>> 
>>> Sorry for post a lot of things, for the first part of code, I copied my
>> C++
>>> iter macro by mistake(and you can see an explicit type casting). Here is
>>> the macro definition from R_exts/Itermacros.h
>>> 
>>> #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
>>> 
>>>strt, nfull, expr) do { \
>>> 
>>> *   const** etype *px = DATAPTR_OR_NULL(sx);   *
>> \
>>> 
>>>  if (px != NULL) {  \
>>> 
>>>  R_xlen_t __ibr_n__ = strt + nfull;\
>>> 
>>>  R_xlen_t nb = __ibr_n__;  \
>>> 
>>>  for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) {   \
>>> 
>>> expr\
>>> 
>>>   } \
>>> 
>>>  }  \
>>> 
>>>  else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype, vtype,
>>> \
>>> 
>>> strt, nfull, expr);\
>>> 
>>>   } while (0)
>>> 
>>> 
>>> Best,
>>> 
>>> Jiefei
>>> 
>>> On Mon, Sep 23, 2019 at 3:12 PM Wang Jiefei  wrote:
>>> 
>>>> Hi Gabriel,
>>>> 
>>>> I have tried the macro and found a small issue, it seems like the macro
>> is
>>>> written in C and does an implicit type conversion(const void * to const
>> int
>>>> *), see below. While it is allowed in C, C++ seems not happy with it.
>> Is it
>>>> possible to add an explicit type casting so that it can be compatible
>> with
>>>> both language?
>>>> 
>>>> 
>>>> #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
>>>> 
>>>>strt, nfull, expr) do { \
>>>> 
>>>>  *const etype *px = (const** etype *)DATAPTR_OR_NULL(sx);  *
>>>> \
>>>> 
>>>>  if (px != NULL) {  \
>>>> 
>>>>  R_xlen_t __ibr_n__ = strt +

Re: [Rd] help with rchk warnings on Rf_eval(Rf_lang2(...))

[Romain Francois]

> Le 23 mars 2020 à 22:55, Dirk Eddelbuettel  a écrit :
> 
> On 23 March 2020 at 17:07, Ben Bolker wrote:
> | Or is there a way I can use Shield() since this an Rcpp-based project
> | anyway?
> 
> Yes you can, and I would recommend it.
> 
> Example from Rcpp itself, file Environment.h:
> 
>  Shield res(Rcpp_fast_eval(Rf_lang2(asEnvironmentSym, x), R_GlobalEnv));

This is not safe. The call made by Rf_lang2() needs to be protected here. 

> For Rcpp_fast_eval, you may still need to #define RCPP_USE_UNWIND_PROTECT
> before including Rcpp.h; as I recall we were seeing too many side effects in
> other packages when globally enabling it.  Or you can play it safe and simply
> use Rcpp_eval.
> 
> This really was more of a rcpp-devel question.
> 
> Dirk
> 
> -- 
> 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

[Rd] nchar( NA )

[Romain Francois]

Hello,

Is this expected ?

> nchar( c( "", NA ) )
[1] 0 2

Should not the second one be NA ?

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] nchar( NA )

[Romain Francois]

Le 18/06/10 22:58, Sarah Goslee a écrit :

Hi Romain,

Did you read the help for nchar?

Value:

  For ‘nchar’, an integer vector giving the sizes of each element,
  currently always ‘2’ for missing values (for ‘NA’).

It may be unexpected behavior, but it's *well-documented* unexpected behavior.


Oops. My scan of the help page was too quick. I did not see it.

Sorry for the noise.


Sarah

On Fri, Jun 18, 2010 at 4:52 PM, Romain Francois
  wrote:

Hello,

Is this expected ?


nchar( c( "", NA ) )

[1] 0 2

Should not the second one be NA ?

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
|- http://bit.ly/c6YnCi : graph gallery collage
`- http://bit.ly/bZ7ltC : inline 0.3.5

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Defining a method that behaves like '$'?

[Romain Francois]

Le 09/07/10 14:18, Renaud Gaujoux a écrit :


Hi,

is there a way to define a method say '$$' that would behave like '$'
and allow calls like 'a$$name'?
Thanks.

Renaud


No. This is not grammatically valid syntax:

> parse( text = 'a$$name' )
Erreur dans parse(text = "a$$name") : '$' inattendu(e) dans "a$$"


But you can define custom methods for $.

setClass( "Foo", representation( n = "integer" ) )
setMethod( "$", "Foo", function(x, name ){
function( ) rnorm( x...@n )
} )
foo <- new( "Foo", n = 10L )
foo$bla( )


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/aJHNLV : Rmetrics slides
|- http://bit.ly/98Uf7u : Rcpp 0.8.1
`- http://bit.ly/c6YnCi : graph gallery collage

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C or Java code generation

[Romain Francois]

Le 20/08/10 10:32, Vyacheslav Karamov a écrit :

Dirk Eddelbuettel пишет:

No, what you describe in the next few hundred lines would _build the
examples
if the package is already installed_
Also, building these examples (once you have the package is installed)
does
"Work For Me (TM)" in the sense that the compiles and linking steps
succeed
(WinXP, Rtools with gcc/g++ 4.2.x, R 2.11.0) yet it, as noted above,
leads to
a seg.fault which Romain and I have found neither time nor motivation
to fix.

You would be very welcome to help out -- our discussions around Rcpp and
RInside take place on the rcpp-devel list off R-Forge.


| 1) First I added R_HOME environment variable.
| 2) Then modified c:\Program |
Files\R\R-2.11.1\library\RInside\examples\standard\Makefile.win by |
surrounding "$(R_HOME)/bin/R" with the quotation marks.
| 3) And finally
| C:\Program Files\R\R-2.11.1\library\RInside\examples\standard>make
-f | Makefile.win
| g++ -Ic:/PROGRA~1/R/R-211~1.1/include |
-Ic:/PROGRA~1/R/R-211~1.1/library/Rcpp/include |
-I"c:/PROGRA~1/R/R-211~1.1/library/RInside/include" -O2 -Wall -Wall -s
| rinside_callbacks0.cpp -Lc:/PROGRA~1/R/R-211~1.1/bin -lR |
-Lc:/PROGRA~1/R/R-211~1.1/bin -lRblas -Lc:/PROGRA~1/R/R-211~1.1/bin |
-lRlapack "c:/PROGRA~1/R/R-211~1.1/library/RInside/lib/libRInside.a" |
c:/PROGRA~1/R/R-211~1.1/library/Rcpp/lib/libRcpp.a -o rinside_callbacks0
|
c:/PROGRA~1/R/R-211~1.1/library/RInside/lib/libRInside.a(RInside.o):RInside.cpp:(.text+0x10b):
| undefined reference to `__gxx_personality_sj0'

[ Hundreds of similar lines removed. ]


Thanks, Dirk


Hi all!

Could you help me to install Rinside in Ubuntu Jaunty?
I've installed R and Rcpp but I have no idea how to deal with Rinside.
I couldn't find any makefile.

WBR,
Vyacheslav.


Hi,

It installs just like any other R package, there is no need for a Makefile.

$ R CMD RInside_0.2.3.tar.gz

or from R:

> install.packages( "RInside" )

We usually encourage people to use the Rcpp-devel mailing list for 
questions about RInside :

http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bzoWrs : Rcpp svn revision 2000
|- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th
`- http://bit.ly/aAyra4 : highlight 0.2-2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] list2env( list() )

[Romain Francois]

Hello,

list2env generates an error on empty lists.

> l <- list()
> list2env( l )
Erreur dans list2env(l) : names(x) must be valid character(length(x)).


This is consistent with the requirement that the list must be a 
__named__ list, so this works:


> names(l) <- character(0)
> list2env( l )



But I was wondering if it would make sense to make a special case of 
zero sized lists, with this:


Index: src/main/envir.c
===
--- src/main/envir.c(revision 52910)
+++ src/main/envir.c(working copy)
@@ -1555,7 +1555,7 @@
 x = CAR(args); args = CDR(args);
 n = LENGTH(x);
 xnms = getAttrib(x, R_NamesSymbol);
-if (TYPEOF(xnms) != STRSXP || LENGTH(xnms) != n)
+if (n && (TYPEOF(xnms) != STRSXP || LENGTH(xnms) != n) )
error(_("names(x) must be valid character(length(x))."));
 envir = CAR(args);  args = CDR(args);
     if (TYPEOF(envir) == NILSXP) {


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/cCmbgg : Rcpp 0.8.6
|- http://bit.ly/bzoWrs : Rcpp svn revision 2000
`- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Possible bug or annoyance with library.dynam.unload()

[Romain Francois]

Le 22/09/10 17:31, Duncan Murdoch a écrit :


On 22/09/2010 11:22 AM, Karl Forner wrote:

Thanks Duncan for your suggestion.

I could not find any package using dynamic library, namespaces and not
the
useDynLib pragma so
I created a minimalistic package to demonstrate the problem.
Please find attached a very small package foo (8.8k)


Your package depends on Rcpp, so I didn't try it in the alpha version of
2.12.0 (Rcpp isn't available there in a Windows binary at the moment)


(This might be moot given Karl's answer), but:

We are working on having Rcpp to work with R 2.12.0, we have currently a 
few issues to deal with due to the use of a newer compiler for R 2.12.0.


We hope we can make this happen before R 2.12.0 is out next month.

Romain


but I did try it in R-patched. With one minor change to your script (the
lib.loc needs to be "local", not "local/" on Windows), I can reproduce
the problem, and it looks like a bug to me. Thanks for the report, I'll
put it on the bugs page, and hopefully it will be fixed before the
2.12.0 release.

Duncan Murdoch


Steps to reproduce the problem:

* unarchive it ( tar zxvf foo_0.1.tar.gz )
* cd foo
* install it locally ( mkdir local; R CMD INSTALL -l local . )
* R
> library(foo, lib.loc="local/")
>.dynLibs()
# there you should be able to see the foo.so lib, in my case
/x05/people/m160508/workspace/foo/local/foo/libs/foo.so

> unloadNamespace("foo")
.onUnload, libpath= local/fooWarning message:
.onUnload failed in unloadNamespace() for 'foo', details:
call: library.dynam.unload("foo", libpath)
error: shared library 'foo' was not loaded

#The libpath that the .onUnload() gets is "local/foo".

#This fails:
>library.dynam.unload("foo", "local/foo")
Error in library.dynam.unload("foo", "local/foo") :
shared library 'foo' was not loaded

# but if you use the absolute path it works:
>library.dynam.unload("foo",
"/x05/people/m160508/workspace/foo/local/foo")

Karl

On Tue, Sep 21, 2010 at 5:33 PM, Duncan
Murdochwrote:

> On 21/09/2010 10:38 AM, Karl Forner wrote:
>
>> Hello,
>>
>> I got no reply on this issue.
>> It is not critical and I could think of work-around, but it really
looks
>> like a bug to me.
>> Should I file a bug-report instead of posting in this list ?
>>
>
> I'd probably post instructions for a reproducible example first.
Pick some
> CRAN package, tell us what to do with it to trigger the error, and
then we
> can see if it's something special about your package or Roxygen or a
general
> problem.
>
> Duncan Murdoch
>
> Thanks,
>>
>> Karl
>>
>> On Thu, Sep 16, 2010 at 6:11 PM, Karl Forner
>> wrote:
>>
>> > Hello,
>> >
>> > I have a package with a namespace. Because I use Roxygen that
>> overwrites
>> > the NAMESPACE file each time it is run, I use a R/zzz.R file with
>> > an .onLoad() and .onUnload() functions to take care of loading and
>> > unloading my shared library.
>> >
>> > The problem: if I load my library from a local directory, then the
>> > unloading of the package fails, e.g:
>> >
>> > # loads fine
>> > >library(Foo, lib.loc=".Rcheck")
>> >
>> > >unloadNamespace("Foo")
>> > Warning message:
>> > .onUnload failed in unloadNamespace() for 'Foo', details:
>> > call: library.dynam.unload("Foo", libpath)
>> > error: shared library 'Foo' was not loaded
>> >
>> > # I traced it a little:
>> > >library.dynam.unload("Foo", ".Rcheck/Foo")
>> > Error in library.dynam.unload("Foo", ".Rcheck/Foo") :
>> > shared library 'Foo' was not loaded
>> >
>> > # using an absolute path works
>> > >library.dynam.unload("Foo", "/home/toto/.Rcheck/Foo")
>> >
>> >
>> > So from what I understand, the problem is either that the relative
>> libpath
>> > is sent to the .onUnload() function instead of the absolute one,
>> > or that library.dynam.unload() should be modified to handle the
>> relative
>> > paths.
>> >
>> > Am I missing something ? What should I do ?
>> >
>> > Thanks,
>> >
>> >
>> > Karl



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/cCmbgg : Rcpp 0.8.6
|- http://bit.ly/bzoWrs : Rcpp svn revision 2000
`- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] SEXP and slots

[Romain Francois]

Hello,

Since people have whisperred about Rcpp, I'd like to play too.


On 11/15/2010 07:45 AM, Patrick Leyshock wrote:

Very helpful, thank you.

A couple other questions, please:

1.  I've got a function written in C, named "my_c_function".  In my R
code I call this function, passing to it an INTSXP and a STRSXP,
respectively:

   result <- .Call("my_c_function", int_vector, str_vector)

The prototype of "my_c_function" is:

   SEXP my_c_function(SEXP int_vec, SEXP str_vec);

Within my_c_function I am able to extract the values within the integer
vector, e.g. I can grab the first value with these lines of code:

   int extracted_value;
   extracted_value = *INTEGER(int_vec);

What I cannot figure out how to do is extract the value from the
STRSXP.  I'm assuming that I can create a pointer to a character array,
then malloc enough memory to hold the value.  Is there an analogous
operation on "INTEGER" for STRSXPs?


STRING_ELT(str_vec, 0)

gets the 0th component of str_vec, which is a CHARSXP, i.e., an SEXP for
a character string. The char* can be retrieved with CHAR, so the usual
paradigm is

  const char *x = CHAR(STRING_ELT(str_vec, 0));

note the const-ness of the char* -- it's not mutable, because R is
managing char * memory.

The converse action, of assigning to an element, is

  SET_STRING_ELT(str_vec, 0, mkChar("foo"));

mkChar() is creating a copy (if necessary) of "foo", managing it, and
returning a CHARSXP. Working through protection (which will likely be
your next obstacle ;) in this last example is a good exercise.


In Rcpp, you would wrap up the STRSXP into a CharacterVector and then 
pull things in and out using indexing:


Rcpp::CharacterVector aladdin(str_vec) ;
std::string first = aladdin[0] ;
aladdin[0] = "foobar" ;


There is a parallel operation VECTOR_ELT / SET_VECTOR_ELT for lists.


Same thing for lists:

Rcpp::List yasmine( some_vec_sxp ) ;
double x = yasmine[0] ;
yasmine[0] = "bla" ;


2.  Any good references/resources for developing R?  Nearly all the
documents I've found are for programming R as a user, not as a
developer.  I have copies of the documentation, which are very helpful,
but it'd be helpful to have additional resources to fill in their gaps.


Chambers, 2008, Software for Data Analysis: Programming with R chapters
11 & 12,

Gentleman, 2008, R Programming for Bioinformatics chapter 6

might be helpful, but by the time they arrive you might find that you're
most of the way through the material covered...

I guess my opinion is that Rcpp would not be useful for understanding
R's C layer, whatever its merits for 'getting the job done'.


Right, but we try to put a positive spin on this.

Rcpp hides the C API on purpose, so that users can concentrate on 
solving their problem rather than deal/fight with the C API.




Back to the original question, Rcpp also has (although it is less used) 
an Rcpp::S4 class that can be used to deal with slots. Here is a 
complete example using Rcpp and inline:


require( Rcpp)
require( inline )

setClass("example",
   representation  (
  size = "numeric",
  id= "character"
   )
)

fx <- cxxfunction( signature(x = "example"),
'
S4 obj(x) ;
obj.slot( "size" ) = 10 ;
obj.slot( "id"   ) = "foo" ;
return obj ;
', plugin = "Rcpp" )

str( fx( new("example", size=4, id="id_value") ) )

But as Martin says, it all depends on what your goal is: getting the job 
done or learn about the internal C API.


Romain



Martin



Thank you,

Patrick


On Fri, Nov 12, 2010 at 4:36 PM, Martin Morgan  fhcrc.org
<mailto:mtmorgan  fhcrc.org>> wrote:

On 11/12/2010 02:31 PM, Patrick Leyshock wrote:
> Hello,
>
> I've created this class:
>
> setClass("example",
>representation  (
>   size = "numeric",
>   id= "character"
>)
> )
>
> Suppose I create a new instance of this class:
>
>> x <- new("example", 4, "id_value")
>
> This creates an S4 object with two slots.  Am I correct in
thinking that
> slots are "filled" by SEXPs?

Hi Patrick --

If I

> eg = new("example", size=4, id="id_value")

(note the named arguments) and take a peak at the str'ucture of eg,
I see

> str(eg)
Formal class 'example' [package ".GlobalEnv"] with 2 slots
 ..@ size: num 4
 ..@ id  : chr "id_value"

so the @size slot is a numeric vector of length 1 containing the value
4. One doesn't really have to know the detailed representation, but one
can find out from

Re: [Rd] SEXP and slots

[Romain Francois]

Le 15/11/10 21:15, Romain Francois a écrit :


Hello,

Since people have whisperred about Rcpp, I'd like to play too.


On 11/15/2010 07:45 AM, Patrick Leyshock wrote:

Very helpful, thank you.

A couple other questions, please:

1. I've got a function written in C, named "my_c_function". In my R
code I call this function, passing to it an INTSXP and a STRSXP,
respectively:

result <- .Call("my_c_function", int_vector, str_vector)

The prototype of "my_c_function" is:

SEXP my_c_function(SEXP int_vec, SEXP str_vec);

Within my_c_function I am able to extract the values within the integer
vector, e.g. I can grab the first value with these lines of code:

int extracted_value;
extracted_value = *INTEGER(int_vec);

What I cannot figure out how to do is extract the value from the
STRSXP. I'm assuming that I can create a pointer to a character array,
then malloc enough memory to hold the value. Is there an analogous
operation on "INTEGER" for STRSXPs?


STRING_ELT(str_vec, 0)

gets the 0th component of str_vec, which is a CHARSXP, i.e., an SEXP for
a character string. The char* can be retrieved with CHAR, so the usual
paradigm is

const char *x = CHAR(STRING_ELT(str_vec, 0));

note the const-ness of the char* -- it's not mutable, because R is
managing char * memory.

The converse action, of assigning to an element, is

SET_STRING_ELT(str_vec, 0, mkChar("foo"));

mkChar() is creating a copy (if necessary) of "foo", managing it, and
returning a CHARSXP. Working through protection (which will likely be
your next obstacle ;) in this last example is a good exercise.


In Rcpp, you would wrap up the STRSXP into a CharacterVector and then
pull things in and out using indexing:

Rcpp::CharacterVector aladdin(str_vec) ;
std::string first = aladdin[0] ;
aladdin[0] = "foobar" ;


As it was pointed out to me offlist, the code above fails to compile. 
This is what you get when you reply to emails while watching a Woody 
Allen movie ...


Anyway, the reason for this is that the line:

std::string first = aladdin[0] ;

uses the __constructor__ of std::string and not the assignment operator. 
The code below does work :


std::string first ;
Rcpp::CharacterVector aladdin(str_vec) ;
first = aladdin[0] ;
aladdin[0] = "foobar" ;


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R5 reference classes: how to initialize exactly?

[Romain Francois]

Le 17/11/10 11:39, Janko Thyson a écrit :



-Ursprüngliche Nachricht-
Von: Simon Urbanek [mailto:simon.urba...@r-project.org]
Gesendet: Mittwoch, 17. November 2010 11:35
An: Janko Thyson
Cc: 'r-de...@r-project. org'
Betreff: Re: [Rd] R5 reference classes: how to initialize exactly?

Just a clarification for posterity - R5 has nothing to do with the new
reference classes. It's not even an official name, but informally it's a
collection of ideas for an entirely new object system that can replace
both S3 and S4 (not that it will but it should be seen as having the
capability to do so technically). Reference classes are just an addition
to S4.

Cheers,
Simon


Thanks for that clarification. I picked that name up from the Google
TechTalks presentation of Dirk and Romain. So I refer to them as S4
reference classes in future posts?

Regards,
Janko


Sorry about that. It was meant as a sort of private joke. (we do say in 
the talk that this is not an official name).



On Nov 16, 2010, at 12:30 AM, Janko Thyson wrote:


Sorry, I was stupid:



MyRefObj<- setRefClass("Blabla", .)



One can always get the generator object of an defined class with
'getRefClass()'. So:



g<- getRefClass("Blabla")

x<- g$new(.)



Regards,

Janko





Von: Janko Thyson [mailto:janko.thy...@ku-eichstaett.de]
Gesendet: Dienstag, 16. November 2010 00:27
An: 'r-de...@r-project. org'
Betreff: R5 reference classes: how to initialize exactly?



Dear List,



So far, I really like those new R5 classes. But what kind of puzzles

me is

that it's not just enough to define the actual reference class, I also

have

to assign it to an object (e.g. 'MyRefObj') in order to fire
'MyRefObj$new(.)'.



S4:

setClass("Blabla", .)

x<- new("Blabla")



R5:

MyRefObj<- setRefClass("Blabla", .)

x<- MyRefObj$new(.)



But then how do I define a reference class in a package that should be
available after the package is loaded via 'library(my_pkg)' as there

is no

'MyRefObj' at startup yet? Do I have to call the script where the

definition

lives?



Thanks for any comments,

Janko



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Reference classes: accessor functions via 'getRefClass(...)$accessors(...)'

[Romain Francois]

Le 17/11/10 13:07, Janko Thyson a écrit :


Hi there,



I'd like to choose between an "static" and "dynamic" access of a reference
class field, say 'a'.



myObj<- getRefClass("Blabla")$new()



Static:   myObj$a

Dynamic: myObj$a.get() where the function retrieves the data
from a database (or some other location), stores it to a buffer and
optionally updates the static field value 'a'.



I've set up such a method 'a.get()' where I can actually decide between
static and dynamic runmode (so the method also wraps the call 'myObj$a' for
the static runmode).



Now I saw that setting up such accessor methods (get/set) is already done
for me if I use 'getRefClass("Blabla")$accessors(.)'. I just don't
understand what exactly I have to do there, because this results in an
error: 'getRefClass("Blabla")$accessors("a")'



Can anyone point me to the correct use of 'getRefClass(.)$accessors(.)'?



Thanks a lot,

Janko


Hi,

fields can either be data or active binding functionss. See 
?makeActiveBinding for some example of active binding functions in their 
original context.


Here is an example of a reference class that keeps its data in a file.

require( methods )

Foo <- setRefClass( "Foo",
fields = list(
file = "character",
x = function(value){
if( missing( value ) ){
read.table( file )
} else{
write.table( value, file = file )
}
    }
    )
)

foo <- Foo$new( file="/tmp/iris.txt" )
foo$x <- iris
foo$x

write.table( subset( iris, Petal.Length < 2), file = "/tmp/iris.txt" )
foo$x


Does that help ?


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] How to call R from C

[Romain Francois]

Le 22/11/10 17:24, 이원재 a écrit :


Hi all!
I read R Extensions manual.
But still I am not sure how to call R functions from C.
Would any of you give me a sample C code to show how to call R functions - for 
instance, time series functions - from C in the embedded way of C code?


As Brian said, there are plenty of examples to follow.

The basic idea is to create a call and evaluate it.

txt <- '
#include 
#include 

SEXP callrnorm(){
SEXP call = PROTECT( lang2( install( "rnorm"), ScalarInteger(10) ) ) ;
SEXP res = PROTECT( eval( call, R_GlobalEnv ) ) ;
UNPROTECT(2) ;
return res ;
}
'
writeLines( txt, "test.c" )
system( "R CMD SHLIB test.c" )
dyn.load( "test.so" )
.Call( "callrnorm" )



or using the inline package :

require(inline)
fx <- cfunction( , '
SEXP call = PROTECT( lang2( install( "rnorm"), ScalarInteger(10) ) ) ;
SEXP res = PROTECT( eval( call, R_GlobalEnv ) ) ;
UNPROTECT(2) ;
return res ;
' , verbose = TRUE)
fx()



And now for the Rcpp plug ;-) calling R functions is dramatically easy 
with Rcpp with the Rcpp::Function class.


require(inline)
fx <- cxxfunction( , '
// grab the function
Function rnorm("rnorm") ;

    // call it
return rnorm(10, _["sd"] = 10) ;

' , plugin = "Rcpp" )
fx()


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] faster base::sequence

[Romain Francois]

Hello,

Based on yesterday's R-help thread (help: program efficiency), and 
following Bill's suggestions, it appeared that sequence:


> sequence
function (nvec)
unlist(lapply(nvec, seq_len))


could benefit from being written in C to avoid unnecessary memory 
allocations.


I made this version using inline:

require( inline )
sequence_c <- local( {
fx <- cfunction( signature( x = "integer"), '
int n = length(x) ;
int* px = INTEGER(x) ;
int x_i, s = 0 ;
/* error checking */
for( int i=0; i x <- 1:1
> system.time( a <- sequence(x ) )
utilisateur système  écoulé
  0.191   0.108   0.298
> system.time( b <- sequence_c(x ) )
utilisateur système  écoulé
  0.060   0.063   0.122
> identical( a, b )
[1] TRUE



> system.time( for( i in 1:1) sequence(1:10) )
utilisateur système  écoulé
  0.119   0.000   0.119
>
> system.time( for( i in 1:1) sequence_c(1:10) )
utilisateur système  écoulé
  0.019   0.000   0.019


I would write a proper patch if someone from R-core is willing to push it.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] faster base::sequence

[Romain Francois]

Le 28/11/10 10:30, Prof Brian Ripley a écrit :

Is sequence used enough to warrant this? As the help page says

Note that ‘sequence <- function(nvec) unlist(lapply(nvec,
seq_len))’ and it mainly exists in reverence to the very early
history of R.


I don't know. Would it be used more if it were more efficient ?


I regard it as unsafe to assume that NA_INTEGER will always be negative,
and bear in mind that at some point not so far off R integers (or at
least lengths) will need to be more than 32-bit.


sure. updated and dressed up as a patch.

I've made it a .Call because I'm not really comfortable with .Internal, 
etc ...


Do you mean that I should also use something else instead of "int" and 
"int*". Is there some future proof typedef or macro for the type 
associated with INTSXP ?




On Sun, 28 Nov 2010, Romain Francois wrote:


Hello,

Based on yesterday's R-help thread (help: program efficiency), and
following Bill's suggestions, it appeared that sequence:


sequence

function (nvec)
unlist(lapply(nvec, seq_len))


could benefit from being written in C to avoid unnecessary memory
allocations.

I made this version using inline:

require( inline )
sequence_c <- local( {
fx <- cfunction( signature( x = "integer"), '
int n = length(x) ;
int* px = INTEGER(x) ;
int x_i, s = 0 ;
/* error checking */
for( int i=0; i
x <- 1:1
system.time( a <- sequence(x ) )

utilisateur système écoulé
0.191 0.108 0.298

system.time( b <- sequence_c(x ) )

utilisateur système écoulé
0.060 0.063 0.122

identical( a, b )

[1] TRUE




system.time( for( i in 1:1) sequence(1:10) )

utilisateur système écoulé
0.119 0.000 0.119


system.time( for( i in 1:1) sequence_c(1:10) )

utilisateur système écoulé
0.019 0.000 0.019


I would write a proper patch if someone from R-core is willing to push
it.

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

Index: src/library/base/R/seq.R
===
--- src/library/base/R/seq.R(revision 53680)
+++ src/library/base/R/seq.R(working copy)
@@ -85,4 +85,6 @@
 }
 
 ## In reverence to the very first versions of R which already had sequence():
-sequence <- function(nvec) unlist(lapply(nvec, seq_len))
+# sequence <- function(nvec) unlist(lapply(nvec, seq_len))
+sequence <- function(nvec) .Call( "sequence", as.integer(nvec), PACKAGE = 
"base" )
+
Index: src/main/registration.c
===
--- src/main/registration.c (revision 53680)
+++ src/main/registration.c (working copy)
@@ -245,6 +245,8 @@
 CALLDEF(bitwiseOr, 2),
 CALLDEF(bitwiseXor, 2),
 
+/* sequence */
+CALLDEF(sequence,1),
 {NULL, NULL, 0}
 };
 
Index: src/main/seq.c
===
--- src/main/seq.c  (revision 53680)
+++ src/main/seq.c  (working copy)
@@ -679,3 +679,28 @@
 
 return ans;
 }
+
+SEXP attribute_hidden sequence(SEXP x)
+{
+   R_len_t n = length(x), s = 0 ;
+   int *px = INTEGER(x) ;
+   int x_i ;
+   /* error checking */
+   for( int i=0; i__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] faster base::sequence

[Romain Francois]

Le 28/11/10 11:30, Prof Brian Ripley a écrit :

On Sun, 28 Nov 2010, Romain Francois wrote:


Le 28/11/10 10:30, Prof Brian Ripley a écrit :

Is sequence used enough to warrant this? As the help page says

Note that ‘sequence <- function(nvec) unlist(lapply(nvec,
seq_len))’ and it mainly exists in reverence to the very early
history of R.


I don't know. Would it be used more if it were more efficient ?


It is for you to make a compelling case for others to do work (maintain
changed code) for your wish.


No trouble. The patch is there, if anyone finds it interesting or 
compelling, they will speak up I suppose.


Otherwise it is fine for me if it ends up in no man's land. I have the 
code, if I want to use it, I can squeeze it in a package.



I regard it as unsafe to assume that NA_INTEGER will always be negative,
and bear in mind that at some point not so far off R integers (or at
least lengths) will need to be more than 32-bit.


sure. updated and dressed up as a patch.

I've made it a .Call because I'm not really comfortable with
.Internal, etc ...



Do you mean that I should also use something else instead of "int" and
"int*". Is there some future proof typedef or macro for the type
associated with INTSXP ?


Not yet. I was explaining why NA_INTEGER might change.


sure. thanks for the reminder.


On Sun, 28 Nov 2010, Romain Francois wrote:


Hello,

Based on yesterday's R-help thread (help: program efficiency), and
following Bill's suggestions, it appeared that sequence:


sequence

function (nvec)
unlist(lapply(nvec, seq_len))


could benefit from being written in C to avoid unnecessary memory
allocations.

I made this version using inline:

require( inline )
sequence_c <- local( {
fx <- cfunction( signature( x = "integer"), '
int n = length(x) ;
int* px = INTEGER(x) ;
int x_i, s = 0 ;
/* error checking */
for( int i=0; i
x <- 1:1
system.time( a <- sequence(x ) )

utilisateur système écoulé
0.191 0.108 0.298

system.time( b <- sequence_c(x ) )

utilisateur système écoulé
0.060 0.063 0.122

identical( a, b )

[1] TRUE




system.time( for( i in 1:1) sequence(1:10) )

utilisateur système écoulé
0.119 0.000 0.119


system.time( for( i in 1:1) sequence_c(1:10) )

utilisateur système écoulé
0.019 0.000 0.019


I would write a proper patch if someone from R-core is willing to push
it.

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube







--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9VOd3l : ZAT! 2010
|- http://bit.ly/c6DzuX : Impressionnism with R
`- http://bit.ly/czHPM7 : Rcpp Google tech talk on youtube

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Enough (was: Terminology clarification (Re: GPL and R Community Policies (Rcpp))

[Romain Francois]

Dear Dominick,

Thank you so much for the numerous reminders about this request of yours.

You will be pleased to know that as part of our ongoing search for 
quality, the current development version of the Rcpp package no longer 
contains code from what we call the `classic Rcpp' API. We owe this 
classic API to your contribution and for that we are grateful. It will 
be released as another package outside of Rcpp as a courtesy to R users 
and CRAN package maintainers who still want to use this API which we 
consider deprecated.


As of the current svn status of Rcpp (rev 2711 on r-forge), your name 
appears in several places, detailed below. Feel free to take whatever 
actions you find appropriate if this does not suit your needs.


Lastly, please do not take R-devel hostage of this thread anymore. Feel 
free to send your questions and remarks to the place where it belongs: 
the Rcpp-devel mailing list.



Regards,

Romain




$ grep -R Samperi * | grep -v .svn
DESCRIPTION: 'classic Rcpp API' was written during 2005 and 2006 by 
Dominick Samperi.
debian/copyright:R / C++ interface package. Rcpp was written by Dominick 
Samperi,

debian/copyright:   2005 and 2006 by Dominick Samperi
inst/announce/ANNOUNCE-0.6.0.txt:Rcpp was initially written by Dominick 
Samperi as part of his contributions
inst/doc/Rcpp-introduction.Rnw:\pkg{Rcpp} first appeared in 2005 as a 
contribution (by Samperi) to the
inst/doc/Rcpp-introduction.Rnw:in early 2006. Several releases (all by 
Samperi) followed in quick succession

inst/doc/Rcpp.bib:  author = {Dominick Samperi},
inst/doc/Rcpp.bib:@Manual{Samperi:2009:RcppTemplate,
inst/doc/Rcpp.bib:  author = {Dominick Samperi},
inst/README:Rcpp continues and extends earlier work by Dominick Samperi 
which he initially
inst/THANKS:Dominick Samperifor starting what we now call the 
Classic Rcpp
man/Rcpp-package.Rd:  The initial versions of Rcpp were written by 
Dominick Samperi during 2005 and
src/Makevars.win:# (C) Dominick Samperi and Uwe Ligges and gratefully 
acknowledged



* In the DESCRIPTION file [1] in the Description field
* In the debian/copyright file [2]
* in the ANNOUNCE-0.6.0.txt file which records the announcement that was 
made about the relauch of Rcpp. The file is a plain text copy of the 
email that was sent to the R-pkgs mailing list on 2008/12/03 [3].
* In the Rcpp-introduction.Rnw file [4]. In the Historical context 
subsection.

* In the Rcpp.bib file [5] that we use to reference to creations of yours.
* In the README file [6] where we acknowledge that Rcpp initiated from you.
* In the THANKS file [7] where we acknowledge your involvment.
* In the Makevars.win file [8]

[1] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/DESCRIPTION?root=rcpp
[2] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/debian/copyright?root=rcpp

[3] https://stat.ethz.ch/pipermail/r-packages/2008/000980.html
[4] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/doc/Rcpp-introduction.Rnw?root=rcpp
[5] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/doc/Rcpp.bib?root=rcpp
[6] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/README?root=rcpp
[7] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/inst/THANKS?root=rcpp
[8] 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/Rcpp/src/Makevars.win?root=rcpp




Le 03/12/10 00:28, Dominick Samperi a écrit :
>
> On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettel  wrote:
>
>>
>> On 2 December 2010 at 17:23, Dominick Samperi wrote:
>> | OK, since you are so accomodating, then please remove all reference to
>> | my name from Rcpp as I do not want to be subject to arbitrary 
revisions

>> of
>> | my status. I may not have the right to say how my prior work will be
>> used,
>> | but I think I have the right to ask that my name not be used in 
the way

>> | it is used in the recent update.
>>
>> As I pointed out, you change your mind on this every 12 months, 
limiting my
>> patience and willingness for these dances.  It has also been 
suggested by

>> other than attribution is clearer if you listed as the maintainer of the
>> 2005/2006 code that we started from in 2008.
>>
>
> The change that this thread is a reaction to happened a few days ago, not
> 12 months ago. If I wavered in the past it was because I was being
> forced to compete with my own work, not a pleasant place to be.
>
> Are you telling me that you refuse to stop using my name
> in Rcpp (except in copyright notices)?
>
> Are you telling me that you will continue to use my name and
> update the associated status as you see fit, whether or not I
> approve or consent to those changes?
>
> Please answer yes or no.
>
> Thanks,
> Dominick


--
Romain Francois
Professional R Enthusiast
+33(0

[Rd] embed Sweave driver in .Rnw file

[Romain Francois]

Hello,

Sweave lets you use alternative drivers through the driver argument, and 
several packages take advantage of that and define custom Sweave driver 
for various purposes. Most of them are listed on the Reproducible 
Research CTV: 
(http://cran.r-project.org/web/views/ReproducibleResearch.html)


The next natural step is for package developpers to take advantage of 
this in their vignettes. In Rcpp we work around the way package building 
works and we do:

- let R build a dummy vignette
- then use the inst/doc/Makefile to replace it with a vignette that is 
processed by the driver from the highlight package (giving syntax 
highlighting).


I played with Sweave so that it would be able to create the driver from 
some text included in the text of the .Rnw file:


$ svn diff
Index: src/library/utils/R/Sweave.R
===
--- src/library/utils/R/Sweave.R(revision 53846)
+++ src/library/utils/R/Sweave.R(working copy)
@@ -20,6 +20,16 @@
 # We don't need srclines for code, but we do need it for text, and 
it's easiest

 # to just keep it for everything.

+SweaveGetDriver <- function(file){
+txt <- readLines(file)
+line <- grep( "\\SweaveDriver", txt, value = TRUE )
+if( length(line) ){
+txt <- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
+driver <- try( eval( parse( text = txt ) ), silent = TRUE )
+if( !inherits( driver, "try-error") ) driver
+}
+}
+
 Sweave <- function(file, driver=RweaveLatex(),
syntax=getOption("SweaveSyntax"), ...)
 {
@@ -28,7 +38,9 @@
 else if(is.function(driver))
 driver <- driver()

-
+drv <- SweaveGetDriver(file)
+if( !is.null(drv) ) driver <- drv
+
 if(is.null(syntax))
 syntax <- SweaveGetSyntax(file)
 if(is.character(syntax))



This allows one to write something like this in their file:

%\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }

So that when calling :

> Sweave( "somefile.Rnw" )

the highlight driver is used instead of the default driver.

Could something like that be added to Sweave ?

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] embed Sweave driver in .Rnw file

[Romain Francois]

Le 14/12/10 13:21, Friedrich Leisch a écrit :

On Tue, 14 Dec 2010 12:40:04 +0100,
Romain Francois (RF) wrote:


   >  Hello,
   >  Sweave lets you use alternative drivers through the driver argument, and
   >  several packages take advantage of that and define custom Sweave driver
   >  for various purposes. Most of them are listed on the Reproducible
   >  Research CTV:
   >  (http://cran.r-project.org/web/views/ReproducibleResearch.html)

   >  The next natural step is for package developpers to take advantage of
   >  this in their vignettes. In Rcpp we work around the way package building
   >  works and we do:
   >  - let R build a dummy vignette
   >  - then use the inst/doc/Makefile to replace it with a vignette that is
   >  processed by the driver from the highlight package (giving syntax
   >  highlighting).

   >  I played with Sweave so that it would be able to create the driver from
   >  some text included in the text of the .Rnw file:

   >  $ svn diff
   >  Index: src/library/utils/R/Sweave.R
   >  ===
   >  --- src/library/utils/R/Sweave.R   (revision 53846)
   >  +++ src/library/utils/R/Sweave.R   (working copy)
   >  @@ -20,6 +20,16 @@
   ># We don't need srclines for code, but we do need it for text, and
   >  it's easiest
   ># to just keep it for everything.

   >  +SweaveGetDriver<- function(file){
   >  +txt<- readLines(file)
   >  +line<- grep( "\\SweaveDriver", txt, value = TRUE )
   >  +if( length(line) ){
   >  +txt<- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
   >  +driver<- try( eval( parse( text = txt ) ), silent = TRUE )
   >  +if( !inherits( driver, "try-error") ) driver
   >  +}
   >  +}
   >  +
   >Sweave<- function(file, driver=RweaveLatex(),
   >   syntax=getOption("SweaveSyntax"), ...)
   >{
   >  @@ -28,7 +38,9 @@
   >else if(is.function(driver))
   >driver<- driver()

   >  -
   >  +drv<- SweaveGetDriver(file)
   >  +if( !is.null(drv) ) driver<- drv
   >  +
   >if(is.null(syntax))
   >syntax<- SweaveGetSyntax(file)
   >if(is.character(syntax))



   >  This allows one to write something like this in their file:

   >  %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }

   >  So that when calling :

   >>  Sweave( "somefile.Rnw" )

   >  the highlight driver is used instead of the default driver.

   >  Could something like that be added to Sweave ?

Yes, sure!

Will have a look at the patch later this week and apply it if it
passes the tests.


Great. Let me know if I can expand on it (documentation, etc ...)


The patch is against a current r-devel?


yes. rev 53846.


Best,
Fritz




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] as.environment.list provides inconsistent results under torture

[Romain Francois]

Hello,

Using R-devel (rev 53950), I get inconsistent results with 
as.environment( VECSXP ) when gctorture is on.


Consider:

a <- list( aa = rnorm, bb = runif )
gctorture(TRUE)
as.environment( a )

The last line sometimes produces the correct environment, but sometimes 
I get errors. Here are the three situations:


# good
> as.environment( a )


# not good
> as.environment( a )
Erreur dans length(x) : 'x' est manquant

# not good either
> as.environment( a )
Erreur dans list(NULL, list(aa = function (n, mean = 0, sd = 1)  :
  correspondance partielle de chaînes de caractères incorrecte


Is it because the call made by lang4 is not protected while evaluated in 
this line :


case VECSXP: {
/* implement as.environment.list() {isObject(.) is false for a list} */
return(eval(lang4(install("list2env"), arg,
  /*envir = */R_NilValue, /* parent = */R_EmptyEnv),
rho));
}


(BTW, this was detected in a long Rcpp-devel thread. See 
http://comments.gmane.org/gmane.comp.lang.r.rcpp/1336)


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Create and access several instances of a C++ class from R

[Romain Francois]

Hello,

Try having do_bar with this signature:

void do_bar(NumericVector data);

And my advice would probably also to have your C field either as a 
NumericVector. NumericVector is just a thin wrapper around the internal 
R data structure.


Having data members as direct pointers is dangerous and not a very C++ 
way of doing things.


If you want to learn about the STL, there are many books that cover it 
and plenty of online resources. I use this : 
http://cplusplus.com/reference/stl/. Using the STL is easier than 
dealing with pointers and stuff.


If your game is to pass down a double* to some api you use, you can use 
the begin method of NumericVector, this will give you the array pointer 
(as would REAL do on the underlying SEXP):


Here's an example:

require( Rcpp )
require( inline )

inc <- '

// some third party api function
double foo( double* data, int n){
double sum = 0.0 ;
for( int i=0; iI hope this helps, please send other Rcpp questions to the Rcpp-devel 
mailing list, where you have more chances to have replies. As an 
example, I don't follow R-devel as much as I would like to these days.


Romain

Le 07/05/11 10:41, soeren.vo...@uzh.ch a écrit :


Hello

Thanks again for help!

We have attached version info, code, and contents of 00install.out at the end 
of the message. The package can be found here:

http://sovo.md-hh.com/files/Foo.tar.gz

We had followed Dirks explanation in the Rcpp modules vignette and the presentation of 
Rcpp modules. The steps there and the ones Dirk listed here are basically the same, and 
all worked fine for us, so far. Even more, we have adapted some of the example code to a 
class Foo with two methods of interest, do_foo() and do_bar(). We have played around with 
various combinations of which method to expose in the module. In the end, exposing 
do_foo() works, R CMD CHECK does not complain. (Except for some namespacing error, but 
the same happens when I compile the example "simple", see below.)

Anyway, if we want the method do_bar() to expose, R CMD CHECK Foo stops with an error that says: "cannot 
convert ‘SEXPREC*’ to ‘double*’ in initialization". We *guess* that it is pointers as arguments in 
methods exposed that cause errors, because there is no wrappers "as()" and "wrap()" for 
pointers in Rcpp. Indee, we know that our crystal ball may fool us.

Summarising so far, principally, Rcpp modules works for us and coding with this 
module is very easy, especially with the help files provided in the package. 
However, Rcpp modules does not work if you want to expose methods with pointers 
as exposed methods' arguments (we assume). Yet, we have to use pointers, and 
rewriting the complete class is no option.

Recently, Dirk gave us the advice to have a look at STL containers. We have googled and found some 
information, and "looking at it" works fine, however, working with it is somewhat 
"beyond" our C++ skills. If the "STL things" *are* our *only* solution, could some reader 
here provide us with a specific solution to exposing do_bar()? Or what else can we do to (1) use the class as 
is (because it works with dyn.load as well as in other software outside R) and (2) incorporate things into 
Rcpp modules (or other code) anyway?

Thanks for all help!

Sören and Carlo


On 07.05.2011, at 02:39, Dirk Eddelbuettel wrote:


Sören and Carlo,

On 6 May 2011 at 19:24, soeren.vo...@uzh.ch wrote:
| Hello
|
| We have a C++ class with several methods that manipulate an object. How is
| it possible to create several instances of that class *from R* in the C++
| realm, which can then be accessed via a given name character?

Yes it is, and even somewhat easily given Rcpp modules as we tried to explain
over at the Rcpp-devel list when you asked there.  As a real quick
proof-of-concept, I did the following:


1) Make sure you have a recent Rcpp such as 0.9.3 or 0.9.4


2) Let Rcpp create a complete 'stub' of a working package with Rcpp modules
   support for you via the Rcpp.package.skeleton.function() with the
   module=TRUE argument:


   R>  library(Rcpp)
   R>  Rcpp.package.skeleton("simple", module=TRUE)
   Creating directories ...
   Creating DESCRIPTION ...
   Creating NAMESPACE ...
   Creating Read-and-delete-me ...
   Saving functions and data ...
   Making help files ...
   Done.
   Further steps are described in './simple/Read-and-delete-me'.

   Adding Rcpp settings

added RcppModules: yada
added Depends: Rcpp
added LinkingTo: Rcpp
added useDynLib directive to NAMESPACE
added Makevars file with Rcpp settings
added Makevars.win file with Rcpp settings
added example header file using Rcpp classes
added example src file using Rcpp classes
added example R file calling the C++ example
added Rd file for rcpp_hello_world
copied the example module

   R>


3) As you are keen to see that we get actual new objects

Re: [Rd] Recursively parsing srcrefs

[Romain Francois]

Le 12/05/11 21:59, Hadley Wickham a écrit :



Is it possible to "recursively" parse srcrefs to match the recursive
structure of the underlying code?  I'm interested in this because it's


I don't understand what you mean by that.  It is certainly possible to walk
through nested srcrefs, to zoom in on a particular location; that's what
findLineNum() does.


Does the example below not help?  Given the whole function, I want to
be able to walk down the call tree, finding the matching src refs as I
go.  i.e. given f, how do I get f_inside?

f<- function(x = T) {
   # This is a comment
   if (x)  return(4)
   if (emergency_status()) return(T)
}

f_inside<- parse(text = "
   # This is a comment
   if (x)  return(4)
   if (emergency_status()) return(T)
")

findLineNum doesn't quite do what I want - it works on the text of the
srcref, not on the parse tree.

Here's another go at explaining what I want:

h<- quote(
   1 # one
   + # plus
   2 # two
)

h[[1]] extracts +.  What can I do to extract "+ # plus" (on an object
created in the appropriate manner to keep the srcref)?  Is that even
possible?


Maybe the parser package can help you.

> x <- parser( "/tmp/test.R" )
> attr( x, "data" )
   line1 col1 byte1 line2 col2 byte2 token id parent top_level 
  token.desc terminal   text
1  10 0 11 1   263  1  3 0 
 SYMBOL TRUE  h
2  11 1 13 3   265  2 32 0 
LEFT_ASSIGN TRUE <-
3  10 0 11 177  3 32 0 
   exprFALSE
4  14 4 19 9   296  5  7 0 
SYMBOL_FUNCTION_CALL TRUE  quote
5  19 9 1   101040  6 30 0 
'(' TRUE  (
6  14 4 19 977  7 30 0 
   exprFALSE
7  23 3 24 4   261 10 11 0 
  NUM_CONST TRUE  1
8  23 3 24 477 11 27 0 
   exprFALSE
9  25 5 2   1010   289 13 27 0 
COMMENT TRUE  # one
10 33 3 34 443 16 27 0 
'+' TRUE  +
11 35 5 3   1111   289 18 27 0 
COMMENT TRUE # plus
12 43 3 44 4   261 21 22 0 
  NUM_CONST TRUE  2
13 43 3 44 477 22 27 0 
   exprFALSE
14 45 5 4   1010   289 24 30 0 
COMMENT TRUE  # two
15 50 0 51 141 26 30 0 
')' TRUE  )
16 23 3 44 477 27 30 0 
   exprFALSE
17 14 4 51 177 30     32 0 
   exprFALSE
18 10 0 51 177 32  0 0 
   exprFALSE


Romain


My eventual goal is something like

f<- function(x) {
   # This is my function
   T
}

g<- fix_logical_abbreviations(f)

which would be equivalent to

g<- function(x) {
   # This is my function
   TRUE
}



That last display looks like a bug indeed.  I'll take a look.


The key seems to be a leading newline:

parse(text = "\nx")
parse(text = "x")

Hadley





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] serialization of external pointers

[Romain Francois]

Le 26/05/11 17:04, Simon Urbanek a écrit :



On May 26, 2011, at 10:40 AM, Romain Francois wrote:


Hello,

I'm looking for examples of how to handle serialization of external pointers.

We use external pointers intensively in Rcpp for modules and one popular 
request is to have persistence. And I guess we need to be able to 
serialize/deserialize external pointers for this.

Also, module objects are all instances of reference classes, so maybe that can 
be handled at the R level ?



Reference classes have nothing to do with EXTPTR - they are simply built around 
environments and as such have no issues with serialization.


Sure. I understand that.

It just happens that our classes end up encapsulating an external 
pointer, so I figured instead of dealing with this at the xp level, I 
could deal with it higher up.


Sort of looking for a class specific serialization. But the comments in 
serialize.c sounds like a "maybe later" answer to my question.



As for EXTPTR, well, you can perform custom serialization (see refhook in 
serialize() and unserialize()), so to answer your question, yes it's easy to 
serialize EXPPTRs - you just have to provide functions that convert them to 
some string representation and back.

So far, so good, but if you were thinking of using save()/save.image()/load() 
to automatically serialize references in a workspace then the bad new is you 
can't since there is no way to provide the hooks (that's why rJava caches 
serialized representation inside the object so that you can restore the 
pointers on load when you see a NULL pointer with a serialized cache - less 
ideal solution, but doable).


Yes. That's what I'm looking for. I'll check what rJava does. Thanks.


Cheers,
Simon



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] assignInNamespace and new bindings

[Romain Francois]

Le 31/05/11 12:01, Prof Brian Ripley a écrit :

On Tue, 31 May 2011, Prof Brian Ripley wrote:


On Tue, 31 May 2011, Romain Francois wrote:


Hello,

assignInNamespace refuses to assign an object to a name that is not
already used in the namespace.


That's intentional, and as documented:

‘assignInNamespace’ and ‘fixInNamespace’ are invoked for their
side effect of changing the object in the name space.


I very much doubt we want to allow adding objects.


Even clearer, the Note says

They can only be used to change the values of objects in the name
space, not to create new objects.


Sure.

I'll just keep using this small workaround, unexported from the next Rcpp:

# just like assignInNamespace but first checks that the binding exists 


forceAssignInNamespace <- function( x, value, env ){
is_ns <- isNamespace( env )
if( is_ns && exists( x, env ) && bindingIsLocked(x, env ) ){
unlockBinding( x, env )
}

assign( x, value, env )

if( is_ns ){
lockBinding( x, env )
}
}

I find this useful for when a package wants to assign in its own namespace.

Romain


Something like this would make it possible:

--- src/library/utils/R/objects.R (revision 56024)
+++ src/library/utils/R/objects.R (working copy)
@@ -252,8 +252,9 @@
stop("environment specified is not a package")
ns <- asNamespace(substring(nm, 9L))
} else ns <- asNamespace(ns)
- if(bindingIsLocked(x, ns)) {
- unlockBinding(x, ns)
+ new_binding <- !exists(x,ns)
+ if( new_binding || bindingIsLocked(x, ns)) {
+ if(!new_binding) unlockBinding(x, ns)
assign(x, value, envir = ns, inherits = FALSE)
w <- options("warn")
on.exit(options(w))

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
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, UK Fax: +44 1865 272595




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Interfacing a C++ class

[Romain Francois]

Le 04/06/11 16:31, soeren.vo...@uzh.ch a écrit :


Hello

Apologies for cross-posting, the discussion should (if) go to R-devel, but I 
also want to reach the rcpp-devel people.

My C++ class FOO is a module available through Rcpp, and it works fine and is 
-- so far -- bug free. With trying to further develop my R package, I thought 
it was a good idea to interface my C++ workhorse FOO with an S4 class Foo. 
After some long and not always insightful trip through S4 classes and methods, 
I am not sure if I am on the right way of thinking and designing. Since there 
is no local assistance available, could you help to make things clearer?

Just a brief outline:

FOO is the C++ object, and Foo should be the S4 class. If the user creates an object, say bar, from 
class Foo, the creation process automatically makes a new FOO object relating to bar in that a 
unique name of the FOO instance is stored in a slot of bar. All the user then has to do is modify 
bar by simple assignments. The getters and setters ("$", "[") are set up and 
work. Each modification goes in hand with assigning new values to bar as well as updating the FOO 
object through available setters from FOO.

So far, this way has brought me to about 100 lines, but now I read about 
ReferenceClasses and was wondering, if there is a much easier way of achieving 
my goals. Moreover, I was not sure any longer if my goals make sense or if a 
more advanced programmer would do it totally different (and could share some 
structural thinking on their approach).

The idea behind my way of doing was based upon several considerations. First, a 
"classical" R object would not confuse users, as I assume users of my package 
to be rather non-skilled (and not willing to change that). Second, I want to create a 
properly programmed package for distribution on CRAN and publication, eventually. Third, 
I want to save objects across sessions. So if a user restores a session, a simple 
command, say, restore(), would do the trick to build all the related C++ objects again. 
However, I admit that I still have not figured out how to automatically clean up the 
workspace correctly before leaving a session, wanted or unwanted, that is, clean up 
memory before leaving home. Fourth, pure arithmetic check is done in C++, however, 
semantic check *should* be left to R, and the validity and class routines seem to be 
perfect for this. Fifth, some work should be done in R, such as the passing of data 
frames or samples from distributions.

I hope to get some structured ideas and hints how to start and/or proceed.

Thank you in advance,
Sören


Hello,

A C++ class that is exposed through an Rcpp module is already a 
reference class, and so you can add methods, etc ...


Consider this example :

require(inline)
require(Rcpp)

fx <- cxxfunction( , '', includes = '

class FOO{
public:
FOO( double x_, double y_): x(x_), y(y_){}

double x ;
double y ;

void move( double dx, double dy){
x += dx ;
y += dy ;
}
} ;

RCPP_MODULE(mod){

class_("FOO" )

.constructor()

.field( "x", &FOO::x )
.field( "y", &FOO::y )

.method( "move", &FOO::move )
;
}


', plugin = "Rcpp" )
mod <- Module( "mod", getDynLib(fx),mustStart = TRUE )

# grab the exposed C++ class
FOO <- mod$FOO

# add R methods
FOO$methods(
bla = function() x+y,
reset = function() {
x <<- 0.0
y <<- 0.0
}
)
# create an instance
f <- new( FOO, 2.0, 3.0 )

# call an R method
f$reset()

# call a C++ method
f$move( 2.0, 2.0 )

# call an R method
f$bla()


Hope this helps.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Calling an array in a struct in C to R

[Romain Francois]

Hello,

I would use external pointers for something like this.

If c++ is an option, you can take advantage of Rcpp classes to deal with 
external pointers. Put the following in a .cpp and sourceCpp() it.


#include 
using namespace Rcpp ;

class Array {
public:
Array( ) : size(10), used(0){
array = new float[10] ;
}

~Array(){
delete[] array ;
}

size_t get_used(){ return used ; }
// other methods doing stuff with the data

private:
float *array;
size_t used;
size_t size;
} ;
typedef XPtr ArrayPointer ;

// [[Rcpp::export]]
ArrayPointer create_ptr( ){
return ArrayPointer( new Array ) ;
}

// [[Rcpp::export]]
size_t Array_get_used(ArrayPointer obj){
// here we use ArrayPointer just like an Array*
return obj->get_used() ;
}

Now, this is very raw and at the R level you get opaque external pointers:

> a <- create_ptr()

> str(a)


> Array_get_used(a)
[1] 0



You can go further than this and use Rcpp modules so that you don't need 
to worry about external pointers, which you can consider as 
implementation details. For example:


#include 
using namespace Rcpp ;

class Array {
public:
Array( ) : size(10), used(0){
array = new float[10] ;
}

~Array(){
delete[] array ;
}

size_t get_used(){ return used ; }
// other methods doing stuff with the data

private:
float *array;
size_t used;
size_t size;
} ;

// the module code, this is where you declare what of
// your class you expose to the R level
RCPP_MODULE(ArrayModule){
class_("Array")
.constructor()
.method( "get_used", &Array::get_used)
;
}

With this, the R code looks like this:

# we should get rid of the need to call populate.
# for now let us just assume it is a way to copy
# the content of the module
# into the global environment
> populate(ArrayModule, globalenv())

> b <- new(Array)

> str(b)
Reference class 'Rcpp_Array' [package ".GlobalEnv"] with 0 fields
 list()
 and 15 methods, of which 3 are possibly relevant:
   finalize, get_used, initialize

> b$get_used()
[1] 0

Romain

Le 19/06/13 16:14, Tee-Jay-Ardie a écrit :

Hi there,

Although I'm a quite experienced R user and know my ways in C, I stumbled
upon a problem I don't know how to solve. Therefore, I hope someone can
provide me with the information or pointers I need in order to understand
the way in which the communication between R and C occurs. I have the
following C code which basicallly reflects what I want:

typedef struct
{
float *array;
size_t used;
size_t size;
} Array;

void main2R()
{
   Array a;
   examplefunction(&a);   /*fills and dynamically grows a->array*/
}

Now I would want to return a.array or a->array to R. According to the R
manuals, the compiled C code should not return anything except through its
arguments. The problem here is, I have a dynamically growing array, and I
have no idea what to pass on to C from R in order to let that work.
The word 'should' indicates that the compiled code may return something in
special circumstances, but I have no idea how to get a.array in R.

So my question is simply this: How on earth do I get the information in the
float array 'a.array' in R? Is it even possible or should I rewrite my C
code using Call in R?

Another, not preferred, options is to pre-allocate the array/vector in R on
a fixed (large-enough) size? Or do I miss something here?

Regards.


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

R Graph Gallery: http://gallery.r-enthusiasts.com

blog:http://blog.r-enthusiasts.com
|- http://bit.ly/13SrjxO : highlight 0.4.2
`- http://bit.ly/10X94UM : Mobile version of the graph gallery

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Using long long types in C++

[Romain Francois]

Le 20 sept. 2013 à 02:31, Patrick Welche  a écrit :

> On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
>> In Rcpp we'd like to do something useful for types such as long long
>> and unsigned long long.
> ...
>> But apparently this is still not enough and on some versions of gcc
>> (e.g. 4.7 something), -pedantic still generates the warnings unless
>> we also use -Wno-long-long
> 
> Can you also add -std=c++0x or is that considered as bad as adding
> -Wno-long-long?

IIRC, a package on CRAN is not allowed to change -std, there is or at least was 
barriers to forbid this. 

Plus, some of us use the default settings on OSX, this is still (simili) gcc 
4.2.1 which has long long but does not implement c++11

> (and why not use autoconf's AC_TYPE_LONG_LONG_INT and
> AC_TYPE_UNSIGNED_LONG_LONG_INT for the tests?)

Because no matter how many precautions we take, if at the end of the day we end 
up having mentions of long long in the code, even behind sufficient test, it 
will still generate warnings which i'm told would prevent the cran distribution 
of the package. 

I'd really like to hear from cran maintainers on this. 

> Cheers,
> 
> Patrick

Because
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Using long long types in C++

[Romain Francois]

Karl, 

Brian gave some insights already. 

I'm also reluctant to use int64_t because there does not seem to be a standard 
version of what the type is. Eg on OSX, int64_t is a typedef to long long. IIRC 
there are cases where it is a typedef to long ... 

At least with long an long long they are guaranteed to be different types and i 
dont need to resort to configure voodoo, i can just rely on the compiler and 
its preprocessor. 

Romain

Le 20 sept. 2013 à 04:04, Karl Millar  a écrit :

> Romain,
> 
> Can you use int64_t and uint_t64 instead?  IMHO that would be more useful 
> than long long anyway.
> 
> Karl
> 
> On Sep 19, 2013 5:33 PM, "Patrick Welche"  wrote:
>> On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
>> > In Rcpp we'd like to do something useful for types such as long long
>> > and unsigned long long.
>> ...
>> > But apparently this is still not enough and on some versions of gcc
>> > (e.g. 4.7 something), -pedantic still generates the warnings unless
>> > we also use -Wno-long-long
>> 
>> Can you also add -std=c++0x or is that considered as bad as adding
>> -Wno-long-long?
>> 
>> (and why not use autoconf's AC_TYPE_LONG_LONG_INT and
>> AC_TYPE_UNSIGNED_LONG_LONG_INT for the tests?)
>> 
>> Cheers,
>> 
>> Patrick
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C++ debugging help needed

[Romain Francois]

Le 02/10/13 17:05, Duncan Murdoch a écrit :

A quick addition:

If I add

#define Shape rglShape

near the top of my Shape.hpp header file, the bug goes away.  But I
can't believe that would be necessary.  These are in separate packages,
don't they have separate namespaces in C++?  How can I avoid clashes
with types declared in other packages in the future?

Duncan Murdoch


That is weird indeed and should not happen. But I don't know much 
linkers ...


I'd advise to scope code in some rgl namespace. At the moment (reading 
the code on r-forge) it's all in the global namespace.


This might be more involved than the macro trick you used above but this 
will be safer. It would have been more problematic if other packages 
needed to compile code against rgl headers, but apparently that is not 
what happens (you don't have inst/include and I don't see 
R_RegisterCCallable either) ...


Romain


On 02/10/2013 10:50 AM, Duncan Murdoch wrote:

I've had reports lately about segfaults in the rgl package.  I've only
been able to reproduce these on Linux.   I am not so familiar with C++
details, so I have a couple of questions way down below. But first some
background info.

   One recipe to recreate the crash works with a new version 5.0-1 of the
mixOmics package:

  > library(mixOmics)
  > example(pca)

This crashes with messages like this:

Program received signal SIGSEGV, Segmentation fault.
0x728aafd9 in __exchange_and_add (__mem=0x7f7f7f77,
  __val=) at /usr/include/c++/4.7/ext/atomicity.h:48
48{ return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }

The call stack ends with this:

#0  0x728aafd9 in __exchange_and_add (__mem=0x7f7f7f77,
  __val=) at /usr/include/c++/4.7/ext/atomicity.h:48
#1  __exchange_and_add_dispatch (__mem=0x7f7f7f77,
  __val=) at /usr/include/c++/4.7/ext/atomicity.h:81
#2  _M_dispose (__a=..., this=0x7f7f7f7fffe7)
  at /usr/include/c++/4.7/bits/basic_string.h:242
#3  ~basic_string (this=0x15f8770, __in_chrg=)
  at /usr/include/c++/4.7/bits/basic_string.h:536
#4  Shape::~Shape (this=0x15f8760, __in_chrg=) at
Shape.cpp:13
#5  0x722df50b in ~Background (this=0x15f8760,
  __in_chrg=) at Background.hpp:15
#6  Background::~Background (this=0x15f8760, __in_chrg=)
  at Background.hpp:15

Up to entry #4 this all looks normal.  If I go into that stack frame, I
see this:


(gdb) up
#4  Shape::~Shape (this=0x15f8760, __in_chrg=) at
Shape.cpp:13
warning: Source file is more recent than executable.
13blended(in_material.isTransparent())
(gdb) p this
$9 = (Shape * const) 0x15f8760
(gdb) p *this
$10 = {_vptr.Shape = 0x72d8e290, mName = 6, mType = {
  static npos = ,
  _M_dataplus = {> =
{<__gnu_cxx::new_allocator> =
{}, },
_M_p = 0x7f7f7f7f }},
mShapeColor = {mRed = -1.4044474254567505e+306,
  mGreen = -1.4044477603031902e+306, mBlue = 4.24399170841135e-314,
  mTransparent = 0}, mSpecularReflectivity = 0.0078125,
mSpecularSize = 1065353216, mDiffuseReflectivity =
0.007812501848093234,
mAmbientReflectivity = 0}

The things displayed in *this are all wrong.  Those field names come
from the Shape object in the igraph package, not the Shape object in the
rgl package.   The mixOmics package uses both.

My questions:

- Has my code somehow got mixed up with the igraph code, so I really do
have a call out to igraph's Shape::~Shape instead of rgl's
Shape::~Shape, or is this just bad info being given to me by gdb?

- If I really do have calls to the wrong destructor in there, how do I
avoid this?

Duncan Murdoch


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C++ debugging help needed

[Romain Francois]

Duncan,

extern "C" just means that the function(s) below it have C calling 
conventions, so that .Call, .External, ... can find them. Without this, 
your function names would be c++ mangled to disambiguate different 
overloads.


What is inside can use namespace without any issue. You'd have something 
like:


extern "C" SEXP dot_call_function(){
rgl::Whatever object(1, 2 ) ;
object.do_something() ;
return R_NilValue ;
}

IIRC, if you register your functions (see WRE #5.4), you don't need 
those extern "C" because you directly give the function pointer so you 
don't have to search for it with its name.


Romain

Le 02/10/13 19:45, Duncan Murdoch a écrit :

Thanks Dirk, Martyn and Romain.  I'm planning to do a temporary
workaround release with the Shape class renamed to rglShape, but over
the longer term I'll put everything that's supposed to be local inside
an rgl namespace.  First I need to learn how namespaces interact with
extern "C" declarations; pointers to any readable tutorials would be
appreciated.

Duncan Murdoch

On 02/10/2013 11:52 AM, Dirk Eddelbuettel wrote:

On 2 October 2013 at 15:45, Martyn Plummer wrote:
| In C++, everything goes in the global namespace unless the programmer
| explicitly creates one. So when you dynamically load two dynamic shared
| libraries with a "Shape" object they clash.
|
| The solution here is to put
|
| namespace rgl {
| ...
| }
|
| around your class definitions in the rglm package, and
|
| using rgl::Shape

Exactly.
| at the top of any source file that refers to rgl Shape. Likewise, the
| igraph package should declare shape in the "igraph" namespace.

And as I wrote to Duncan off-list, igraph doesn't, even though it
otherwise
uses an igraph namespace:

/** Shape.h
 */
#ifndef SHAPE_H
#define SHAPE_H
#include 
#include "Color.h"
#include "Ray.h"
#include "Point.h"
class Shape
[]

So the clash is due to two packages simulatenously failing to make use of
namespaces.

And at that point the linker appears to pick in search (link ?) order.

Dirk


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] C++ debugging help needed

[Romain Francois]

Le 02/10/13 22:15, Duncan Murdoch a écrit :

On 02/10/2013 4:01 PM, Ross Boylan wrote:

On Wed, Oct 02, 2013 at 11:05:19AM -0400, Duncan Murdoch wrote:

>> Up to entry #4 this all looks normal.  If I go into that stack
frame, I
>> see this:
>>
>>
>> (gdb) up
>> #4  Shape::~Shape (this=0x15f8760, __in_chrg=) at
>> Shape.cpp:13
>> warning: Source file is more recent than executable.

That warning looks suspicious.  Are your sure gdb is finding the right
source files, and that the object code has been built from them?


I'm pretty sure that's a warning about the fact that igraph also has a
file called Shape.cpp, and the Shape::~Shape destructor was in that
file, not in my Shape.cpp file.


>> 13blended(in_material.isTransparent())
>> (gdb) p this
>> $9 = (Shape * const) 0x15f8760
>> (gdb) p *this
>> $10 = {_vptr.Shape = 0x72d8e290, mName = 6, mType = {
>>   static npos = ,
>>   _M_dataplus = {> =
>> {<__gnu_cxx::new_allocator> =
>> {}, },
>> _M_p = 0x7f7f7f7f > bounds>}},
>> mShapeColor = {mRed = -1.4044474254567505e+306,
>>   mGreen = -1.4044477603031902e+306, mBlue =
4.24399170841135e-314,
>>   mTransparent = 0}, mSpecularReflectivity = 0.0078125,
>> mSpecularSize = 1065353216, mDiffuseReflectivity =
0.007812501848093234,
>> mAmbientReflectivity = 0}
>>
>> The things displayed in *this are all wrong.  Those field names come
>> from the Shape object in the igraph package, not the Shape object
in the
>> rgl package.   The mixOmics package uses both.
>>
>> My questions:
>>
>> - Has my code somehow got mixed up with the igraph code, so I
really do
>> have a call out to igraph's Shape::~Shape instead of rgl's
>> Shape::~Shape, or is this just bad info being given to me by gdb?
>>

I don't know, but I think it's possible to give fully qualified type
names to gdb to force it to use the right definition.  That's assuming
that both Shape's are in different namespaces.  If they aren't, that's
likely the problem.


Apparently they aren't, even though they are in separately compiled and
linked packages.  I had been assuming that the fact that rgl knows
nothing about igraph meant I didn't need to worry about it. (igraph does
list rgl in its "Suggests" list.)  On platforms other than Linux, I
don't appear to need to worry about it, but Linux happily loads one,
then loads the other and links the call to the wrong .so rather than the
local one, without a peep of warning, just an eventual crash.

Supposing I finish my editing of the 100 or so source files and put all
of the rgl stuff in an "rgl" namespace, that still doesn't protect me
from what some other developer might do next week, creating their own
"rgl" namespace with a clashing name.   Why doesn't the linking step
resolve the calls, why does it leave it until load time?


That makes it less likely though.

You could also use an unnamed namespace to sort of scope your code in 
your translation unit. See 
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/unnamed_namespaces.htm



- If I really do have calls to the wrong destructor in there, how do I
avoid this?


Are you invoking the destructor explicitly?  An object should know
it's type, which should result in the right call without much effort.


No, this is an implicit destructor call.  I'm deleting an object whose
class descends from Shape.

Duncan Murdoch



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R 3.1.0 and C++11

[Romain Francois]

Le 03/11/2013 22:45, Michael Kane a écrit :

I'd like to echo Whit's sentiment and hopefully warm up this thread.
C++11's new features and functionality give R users low-level tools (like
threads, mutexes, futures, date-time, and atomic types) that work across
platforms and wouldn't require other external libraries like boost.


+1

portability is really important. One of the points is that by giving 
means to assume a certain standard, we can write more portable code.


There has been lots of discussion about Boost.Thread, etc ... no need 
for that if you have C++11.



Romain, will you be taking pull requests?


Yes. Definitely. I will carefully review them.
Can give you write access too.

I'm getting a good feel of what C++11 brings while developping Rcpp11. 
But I think it makes a lot of sense to write such an article with other 
people as well.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dynamic list creation (SEXP in C) returns error "unimplemented type (29) in 'duplicate'"

[Romain Francois]

Hello,

Any particular reason you're not using Rcpp? You would have access to 
nice abstraction instead of these MACROS all over the place.


The cost of these abstractions is close to 0.

Looping around and SET_LENGTH is going to be quite expensive. I would 
urge you to accumulate data in data structures that know how to grow 
efficiently, i.e. a std::vector and then convert that to an R vector 
when you're done with them.


Romain

Le 07/11/2013 14:03, George Vega Yon a écrit :

Hi!

I didn't wanted to do this but I think that this is the easiest way
for you to understand my problem (thanks again for all the comments
that you have made). Here is a copy of the function that I'm working
on. This may be tedious to analyze, so I understand if you don't feel
keen to give it a time. Having dedicated many hours to this (as a new
user of both C and R C API), I would be very pleased to know what am I
doing wrong here.

G0 is a Nx2 matrix. The first column is a group id (can be shared with
several observations) and the second tells how many individuals are in
that group. This matrix can look something like this:

id_group  nreps
1  3
1  3
1  3
2  1
3  1
4  2
5  1
6  1
4  2
...

L0 is list of two column data.frames with different sizes. The first
column (id) are row indexes (with values 1 to N) and the second column
are real numbers. L0 can look something like this
[[1]]
id  lambda
3  0.5
15  0.3
25  0.2
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
80  1

TE0 is a int scalar in {0,1,2}

T0 is a dichotomous vector of length N that can look something like this
[1] 0 1 0 1 1 1 0 ...
[N] 1

L1 (the expected output) is a modified version of L0, that, for
instance can look something like this (note the rows marked with "*")

[[1]]
id  lambda
3  0.5
*15  0.15 (15 was in the same group of 50, so I added this new row and
divided the value of lambda by two)
25  0.2
*50  0.15
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
*80  0.333 (80 shared group id with 30 and 100, so lambda is divided by 3)
*30  0.333
*100 0.333

That said, the function is as follows

SEXP distribute_lambdas(
   SEXP G0,  // Groups ids (matrix of Nx2). First column = Group Id,
second column: Elements in the group
   SEXP L0,  // List of N two-column dataframes with different number of rows
   SEXP TE0, // Treatment effect (int scalar): ATE(0) ATT(1) ATC(2)
   SEXP T0   // Treat var (bool vector, 0/1, of size N)
)
{

   int i, j, l, m;
   const int *G = INTEGER_POINTER(PROTECT(G0 = AS_INTEGER(G0 )));
   const int *T = INTEGER_POINTER(PROTECT(T0 = AS_INTEGER(T0 )));
   const int *TE= INTEGER_POINTER(PROTECT(TE0= AS_INTEGER(TE0)));
   double *L, val;
   int *I, nlambdas, nreps;

   const int n = length(T0);

   PROTECT_INDEX pin0, pin1;
   SEXP L1;
   PROTECT(L1 = allocVector(VECSXP,n));
   SEXP id, lambda;

   // Fixing size
   for(i=0;i 1)
   {
 /* Changing the length of the object */
 REPROTECT(SET_LENGTH(id,length(lambda) + G[n+I[l]-1] -1), pin0);
 REPROTECT(SET_LENGTH(lambda,length(lambda) + G[n+I[l]-1] -1), pin1);

 // Getting the new value
 val = L[l]/G[n+I[l] - 1];
 REAL(lambda)[l] = val;

 // Looping over the full set of groups
 m = -1,j = -1;
 while(m < (G[n+I[l]-1] - 1))
 {
   // Looking for individuals in the same group
   if (G[++j] != G[I[l]-1]) continue;

   // If it is the current lambda, then do not asign it
   if (j == (I[l] - 1)) continue;

   INTEGER(id)[length(id) - (G[n+I[l]-1] - 1) + ++m] = j+1;
   REAL(lambda)[length(id) - (G[n+I[l]-1] - 1) + m] = val;
 }

 nreps+=1;
   }
 }

 if (nreps)
 {
   // Replacing elements from of the list (modified)
   SET_VECTOR_ELT(VECTOR_ELT(L1, i), 0, duplicate(id));
   SET_VECTOR_ELT(VECTOR_ELT(L1, i), 1, duplicate(lambda));
 }
 else {
   // Setting the list with the old elements
   SET_VECTOR_ELT(VECTOR_ELT(L1, i), 0,
 duplicate(VECTOR_ELT(VECTOR_ELT(L0,i),0)));
   SET_VECTOR_ELT(VECTOR_ELT(L1, i), 1,
 duplicate(VECTOR_ELT(VECTOR_ELT(L0,i),1)));
 }

 // Unprotecting elements
 UNPROTECT(4);
   }

   Rprintf("Exito\n") ;
   UNPROTECT(4);

   return L1;
}

Thanks again in advanced.

George Vega Yon
+56 9 7 647 2552
http://ggvega.cl

2013/11/5 George Vega Yon :

Either way, understanding that it may not be the best way of do it, is
there anything wrong in what I'm doing??
George Vega Yon
+56 9 7 647 2552
http://ggvega.cl


2013/11/5 Gabriel Becker :

George,

My point is you don't need to create them and then grow them


for(i=0;i wrote:


Gabriel,

While the length (in terms of number of SEXP elements it stores) of L1
doesn't changes, the vectors within L1 do (sorry if I didn't explained
it well before).

The post was about a SEXP object that grows, in my case, every pair of
vectors in L1

Re: [Rd] Dynamic list creation (SEXP in C) returns error "unimplemented type (29) in 'duplicate'"

[Romain Francois]

Le 07/11/2013 14:30, George Vega Yon a écrit :

Romain,

Thanks for your quick response. I've already received that suggestion,
but, besides of haven't ever used C++, I wanted to understand first
what am I doing wrong.


For that type of code, it is actually quite simpler to learn c++ than it 
is to learn the macros and loose typing of the R interface.



Still, would you give me a small example, in R
C++, of:

   - Creating a generic vector "L1" of size N
   - Creating a data.frame "D" and increasing its the number of rows of it
   - Storing the data.frame "D" in the first element of "L1"

I would be very gratefull if you can do that.


#include 
using namespace Rcpp ;

// [[Rcpp::export]]
List example(int N){
List out(N) ;

// let's first accumulate data in these two std::vector
std::vector x ;
std::vector y ;
for( int i=0; i<30; i++){
x.push_back( sqrt( i ) ) ;
y.push_back( i ) ;
}

// Now let's create a data frame
DataFrame df = DataFrame::create(
_["x"] = x,
_["y"] = y
) ;

// storing df as the first element of out
out[0] = df ;

return out ;
}

You can also do it like this acknowleding what a data frame really is 
(just a list of vectors):


List df = List::create(
_["x"] = x,
_["y"] = y
) ;
df.attr( "class" ) = "data.frame" ;
df.attr( "row.names") = IntegerVector::create(
IntegerVector::get_na(), -30 ) ;


The key thing here is that we accumulate data into std::vector 
and std::vector which know how to grow efficiently. Looping around 
with SET_LENGTH will allocate and copy data at each iteration of the 
loop which will lead to disastrous performance.


Romain


Thanks again!

George Vega Yon
+56 9 7 647 2552
http://ggvega.cl


2013/11/7 Romain Francois :

Hello,

Any particular reason you're not using Rcpp? You would have access to nice
abstraction instead of these MACROS all over the place.

The cost of these abstractions is close to 0.

Looping around and SET_LENGTH is going to be quite expensive. I would urge
you to accumulate data in data structures that know how to grow efficiently,
i.e. a std::vector and then convert that to an R vector when you're done
with them.

Romain

Le 07/11/2013 14:03, George Vega Yon a écrit :


Hi!

I didn't wanted to do this but I think that this is the easiest way
for you to understand my problem (thanks again for all the comments
that you have made). Here is a copy of the function that I'm working
on. This may be tedious to analyze, so I understand if you don't feel
keen to give it a time. Having dedicated many hours to this (as a new
user of both C and R C API), I would be very pleased to know what am I
doing wrong here.

G0 is a Nx2 matrix. The first column is a group id (can be shared with
several observations) and the second tells how many individuals are in
that group. This matrix can look something like this:

id_group  nreps
1  3
1  3
1  3
2  1
3  1
4  2
5  1
6  1
4  2
...

L0 is list of two column data.frames with different sizes. The first
column (id) are row indexes (with values 1 to N) and the second column
are real numbers. L0 can look something like this
[[1]]
id  lambda
3  0.5
15  0.3
25  0.2
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
80  1

TE0 is a int scalar in {0,1,2}

T0 is a dichotomous vector of length N that can look something like this
[1] 0 1 0 1 1 1 0 ...
[N] 1

L1 (the expected output) is a modified version of L0, that, for
instance can look something like this (note the rows marked with "*")

[[1]]
id  lambda
3  0.5
*15  0.15 (15 was in the same group of 50, so I added this new row and
divided the value of lambda by two)
25  0.2
*50  0.15
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
*80  0.333 (80 shared group id with 30 and 100, so lambda is divided by 3)
*30  0.333
*100 0.333

That said, the function is as follows

SEXP distribute_lambdas(
SEXP G0,  // Groups ids (matrix of Nx2). First column = Group Id,
second column: Elements in the group
SEXP L0,  // List of N two-column dataframes with different number of
rows
SEXP TE0, // Treatment effect (int scalar): ATE(0) ATT(1) ATC(2)
SEXP T0   // Treat var (bool vector, 0/1, of size N)
)
{

int i, j, l, m;
const int *G = INTEGER_POINTER(PROTECT(G0 = AS_INTEGER(G0 )));
const int *T = INTEGER_POINTER(PROTECT(T0 = AS_INTEGER(T0 )));
const int *TE= INTEGER_POINTER(PROTECT(TE0= AS_INTEGER(TE0)));
double *L, val;
int *I, nlambdas, nreps;

const int n = length(T0);

PROTECT_INDEX pin0, pin1;
SEXP L1;
PROTECT(L1 = allocVector(VECSXP,n));
SEXP id, lambda;

// Fixing size
for(i=0;i 1)
{
  /* Changing the length of the object */
  REPROTECT(SET_LENGTH(id,length(lambda) + G[n+I[l]-1] -1),
pin0

Re: [Rd] Dynamic list creation (SEXP in C) returns error "unimplemented type (29) in 'duplicate'"

[Romain Francois]

Le 07/11/2013 14:43, Romain Francois a écrit :

Le 07/11/2013 14:30, George Vega Yon a écrit :

Romain,

Thanks for your quick response. I've already received that suggestion,
but, besides of haven't ever used C++, I wanted to understand first
what am I doing wrong.


For that type of code, it is actually quite simpler to learn c++ than it
is to learn the macros and loose typing of the R interface.


Still, would you give me a small example, in R
C++, of:

   - Creating a generic vector "L1" of size N
   - Creating a data.frame "D" and increasing its the number of rows
of it
   - Storing the data.frame "D" in the first element of "L1"

I would be very gratefull if you can do that.


#include 
using namespace Rcpp ;

// [[Rcpp::export]]
List example(int N){
 List out(N) ;

 // let's first accumulate data in these two std::vector
 std::vector x ;
 std::vector y ;
 for( int i=0; i<30; i++){
 x.push_back( sqrt( i ) ) ;
 y.push_back( i ) ;
 }

 // Now let's create a data frame
 DataFrame df = DataFrame::create(
 _["x"] = x,
 _["y"] = y
 ) ;

 // storing df as the first element of out
 out[0] = df ;

 return out ;
}


Forgot to mention. You would just put the code above in a .cpp file and 
call sourceCpp on it.


sourceCpp( "file.cpp" )
example( 3 )


You can also do it like this acknowleding what a data frame really is
(just a list of vectors):

 List df = List::create(
 _["x"] = x,
 _["y"] = y
 ) ;
 df.attr( "class" ) = "data.frame" ;
 df.attr( "row.names") = IntegerVector::create(
 IntegerVector::get_na(), -30 ) ;


The key thing here is that we accumulate data into std::vector
and std::vector which know how to grow efficiently. Looping around
with SET_LENGTH will allocate and copy data at each iteration of the
loop which will lead to disastrous performance.

Romain


Thanks again!

George Vega Yon
+56 9 7 647 2552
http://ggvega.cl


2013/11/7 Romain Francois :

Hello,

Any particular reason you're not using Rcpp? You would have access to
nice
abstraction instead of these MACROS all over the place.

The cost of these abstractions is close to 0.

Looping around and SET_LENGTH is going to be quite expensive. I would
urge
you to accumulate data in data structures that know how to grow
efficiently,
i.e. a std::vector and then convert that to an R vector when you're done
with them.

Romain

Le 07/11/2013 14:03, George Vega Yon a écrit :


Hi!

I didn't wanted to do this but I think that this is the easiest way
for you to understand my problem (thanks again for all the comments
that you have made). Here is a copy of the function that I'm working
on. This may be tedious to analyze, so I understand if you don't feel
keen to give it a time. Having dedicated many hours to this (as a new
user of both C and R C API), I would be very pleased to know what am I
doing wrong here.

G0 is a Nx2 matrix. The first column is a group id (can be shared with
several observations) and the second tells how many individuals are in
that group. This matrix can look something like this:

id_group  nreps
1  3
1  3
1  3
2  1
3  1
4  2
5  1
6  1
4  2
...

L0 is list of two column data.frames with different sizes. The first
column (id) are row indexes (with values 1 to N) and the second column
are real numbers. L0 can look something like this
[[1]]
id  lambda
3  0.5
15  0.3
25  0.2
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
80  1

TE0 is a int scalar in {0,1,2}

T0 is a dichotomous vector of length N that can look something like
this
[1] 0 1 0 1 1 1 0 ...
[N] 1

L1 (the expected output) is a modified version of L0, that, for
instance can look something like this (note the rows marked with "*")

[[1]]
id  lambda
3  0.5
*15  0.15 (15 was in the same group of 50, so I added this new row and
divided the value of lambda by two)
25  0.2
*50  0.15
[[2]]
id  lambda
15  0.8
40  0.2
...
[[N]]
id  lambda
*80  0.333 (80 shared group id with 30 and 100, so lambda is divided
by 3)
*30  0.333
*100 0.333

That said, the function is as follows

SEXP distribute_lambdas(
SEXP G0,  // Groups ids (matrix of Nx2). First column = Group Id,
second column: Elements in the group
SEXP L0,  // List of N two-column dataframes with different
number of
rows
SEXP TE0, // Treatment effect (int scalar): ATE(0) ATT(1) ATC(2)
SEXP T0   // Treat var (bool vector, 0/1, of size N)
)
{

int i, j, l, m;
const int *G = INTEGER_POINTER(PROTECT(G0 = AS_INTEGER(G0 )));
const int *T = INTEGER_POINTER(PROTECT(T0 = AS_INTEGER(T0 )));
const int *TE= INTEGER_POINTER(PROTECT(TE0= AS_INTEGER(TE0)));
double *L, val;
int *I, nlambdas, nreps;

const int n = length(T0);

PROTECT_INDEX pin0, pin1;
SEXP L1;
PROTECT(L1 = allocVec

[Rd] Linking to native routines in other packages

[Romain Francois]

Hello,

I'm currently working on making Rcpp use the feature described here more:
http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages

To give more context, Rcpp has for a long time built what we called "the 
Rcpp user library", i.e. a library we could link against user the 
linker. We were then producing appropriate linker flag with 
Rcpp:::LdFlags(), ...


Now, I'm moving away from this and the intention is that a package using 
Rcpp would only have to use


LinkingTo: Rcpp

This sets the -I flag as before to find headers from Rcpp, but this also 
now takes advantage of what is described in writing R extensions:

http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages

I'm doing this in a way that, when we are not compiling Rcpp, for 
example the "type2name" function is defined in Rcpp's headers as an 
inline function that grabs the registered function from Rcpp.


inline const char* type2name(SEXP x){
typedef const char* (*Fun)(SEXP) ;
static Fun fun = GET_(Fun) R_GetCCallable( "Rcpp", "type2name") ;
return fun(x) ;
}


This works great.


Now for the question. The documentation says:

"It must also specify ‘Imports’ or ‘Depends’ of those packages, for they 
have to be loaded prior to this one (so the path to their compiled code 
has been registered)."


Indeed if I don't have Depends or Imports, the R_init_Rcpp is not 
called, and so the function is not registered.


But now if I do Depends: Rcpp or Imports: Rcpp for the sole purpose of 
this LinkingTo mechanism, I'm getting


* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘Rcpp’
  All declared Imports should be used.
See the information on DESCRIPTION files in the chapter ‘Creating R
packages’ of the ‘Writing R Extensions’ manual.

It would be simple enough to require of our users that they have 
Imports: Rcpp and import(Rcpp) or less in their NAMESPACE, but I was 
wondering if we could make this more transparent, i.e. having LinkingTo: 
Rcpp mean loading Rcpp.


I'm also curious about this sentence from the doc:

"In the future R may provide some automated tools to simplify exporting 
larger numbers of routines."


Is there a draft of something ?

Romain



For details on how we will be using LinkingTo. Please see:

https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/routines.h

where depending
- when we are compiling Rcpp, we just have a declaration of the 
function, which is then defined in any of our .cpp files.
- when we are using Rcpp from another package, we are retrieving the 
function


https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp

where the functions are registered with the RCPP_REGISTER macro.

This way of using it moves all the logic to the package exposing its 
functions. I find this nicer to use than other tactics I've seen, such 
as the sub technique from Matrix ...


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Linking to native routines in other packages

[Romain Francois]

Le 16/11/2013 11:02, Romain Francois a écrit :

Hello,

I'm currently working on making Rcpp use the feature described here more:
http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages


To give more context, Rcpp has for a long time built what we called "the
Rcpp user library", i.e. a library we could link against user the
linker. We were then producing appropriate linker flag with
Rcpp:::LdFlags(), ...

Now, I'm moving away from this and the intention is that a package using
Rcpp would only have to use

LinkingTo: Rcpp

This sets the -I flag as before to find headers from Rcpp, but this also
now takes advantage of what is described in writing R extensions:
http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages


I'm doing this in a way that, when we are not compiling Rcpp, for
example the "type2name" function is defined in Rcpp's headers as an
inline function that grabs the registered function from Rcpp.

inline const char* type2name(SEXP x){
 typedef const char* (*Fun)(SEXP) ;
 static Fun fun = GET_(Fun) R_GetCCallable( "Rcpp", "type2name") ;
 return fun(x) ;
 }


This works great.


Now for the question. The documentation says:

"It must also specify ‘Imports’ or ‘Depends’ of those packages, for they
have to be loaded prior to this one (so the path to their compiled code
has been registered)."

Indeed if I don't have Depends or Imports, the R_init_Rcpp is not
called, and so the function is not registered.

But now if I do Depends: Rcpp or Imports: Rcpp for the sole purpose of
this LinkingTo mechanism, I'm getting

* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘Rcpp’
   All declared Imports should be used.
See the information on DESCRIPTION files in the chapter ‘Creating R
packages’ of the ‘Writing R Extensions’ manual.

It would be simple enough to require of our users that they have
Imports: Rcpp and import(Rcpp) or less in their NAMESPACE, but I was
wondering if we could make this more transparent, i.e. having LinkingTo:
Rcpp mean loading Rcpp.

I'm also curious about this sentence from the doc:

"In the future R may provide some automated tools to simplify exporting
larger numbers of routines."

Is there a draft of something ?

Romain



For details on how we will be using LinkingTo. Please see:

https://github.com/RcppCore/Rcpp/blob/master/inst/include/Rcpp/routines.h

where depending
- when we are compiling Rcpp, we just have a declaration of the
function, which is then defined in any of our .cpp files.
- when we are using Rcpp from another package, we are retrieving the
function

https://github.com/RcppCore/Rcpp/blob/master/src/Rcpp_init.cpp

where the functions are registered with the RCPP_REGISTER macro.

This way of using it moves all the logic to the package exposing its
functions. I find this nicer to use than other tactics I've seen, such
as the sub technique from Matrix ...


Typo alert. Of course here I meant the "stub" technique.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] serialization for external pointers

[Romain Francois]

Hello,

Are there any recipe to handle serialization / deserialization of 
external pointers.


I'm thinking about something similar in spirit to the way we handle 
finalization of external pointers.


Currently, if we create an external pointer, save the session, quit R, 
then load the session, we get a null pointer.


One way I'm thinking of is to have an environment in the "protected" 
part of the xp, then have an active binding there, since apparently 
active bindings:

 - are "get" during serialization
 - lose their active ness when reloaded:

$ R
[...]
> f <- local( {
+ x <- 1
+ function(v) {
+if (missing(v))
+cat("get\n")
+else {
+cat("set\n")
+x <<- v
+}
+x
+ }
+ })
> makeActiveBinding("fred", f, .GlobalEnv)
> bindingIsActive("fred", .GlobalEnv)
[1] TRUE
>
> q("yes")
get
get


romain@naxos /tmp $ R
[..]
> fred
[1] 1
> bindingIsActive("fred", .GlobalEnv)
[1] FALSE

Is this possible ? Is there any other hook to handle serialization, 
unserialization of external pointers ?


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] serialization for external pointers

[Romain Francois]

Le 16/11/2013 14:30, Romain Francois a écrit :

Hello,

Are there any recipe to handle serialization / deserialization of
external pointers.

I'm thinking about something similar in spirit to the way we handle
finalization of external pointers.

Currently, if we create an external pointer, save the session, quit R,
then load the session, we get a null pointer.

One way I'm thinking of is to have an environment in the "protected"
part of the xp, then have an active binding there, since apparently
active bindings:
  - are "get" during serialization
  - lose their active ness when reloaded:


This will not work. Apparently the active feature is kept on other 
environments:


$ R
[...]
> f <- local( {
+ x <- 1
+ function(v) {
+if (missing(v))
+cat("get\n")
+else {
+cat("set\n")
+x <<- v
+}
+x
+ }
+ })
> makeActiveBinding("fred", f, .GlobalEnv)
> bindingIsActive("fred", .GlobalEnv)
[1] TRUE
>
> e <- new.env()
> makeActiveBinding("fred", f, e)
> bindingIsActive("fred", e)
[1] TRUE
>
> q()
Save workspace image? [y/n/c]: y
get
get

Then:

$ R
[...]
> e

> bindingIsActive("fred", .GlobalEnv)
[1] FALSE
> bindingIsActive("fred", e)
[1] TRUE

Is this the expected behavior ?

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Linking to native routines in other packages

[Romain Francois]

Le 06/12/2013 22:29, Hadley Wickham a écrit :

But now if I do Depends: Rcpp or Imports: Rcpp for the sole purpose of this
LinkingTo mechanism, I'm getting

* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘Rcpp’
   All declared Imports should be used.
See the information on DESCRIPTION files in the chapter ‘Creating R
packages’ of the ‘Writing R Extensions’ manual.


This is just a note, so perhaps it's spurious, and can be ignored as
long as you provide an explanation when submitting to CRAN.

Hadley


The problem is that I'd have to ask every package maintainer to 
negociate that when they release a package that depends on Rcpp.


Perhaps that's alright.

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] internal manipulation of ...

[Romain François]

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 ...

[Romain François]

Le 13 déc. 2013 à 00:15, Simon Urbanek  a écrit :

> 
> On Dec 12, 2013, at 3:32 PM, Romain François  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

Re: [Rd] Strategies for keeping autogenerated .Rd files out of a Git tree

[Romain Francois]

Pushing back to github is not so difficult. See e.g 
http://blog.r-enthusiasts.com/2013/12/04/automated-blogging.html

You can manage branches easily in travis. You could for example decide to do 
something different if you are on the master branch ...

Romain

Le 13 déc. 2013 à 12:03, Kirill Müller  a 
écrit :

> Gabor
> 
> I agree with you. There's Travis CI, and r-travis -- an attempt to integrate 
> R package testing with Travis. Pushing back to GitHub is possible, but the 
> setup is somewhat difficult. Also, this can be subject to race conditions 
> because each push triggers a test run and they can happen in parallel even 
> for the same repository. How do you handle branches?
> 
> It would be really great to be able to execute custom R code before building. 
> Perhaps in a PreBuild: section in DESCRIPTION?
> 
> 
> Cheers
> 
> Kirill
> 
> 
> On 12/12/2013 02:21 AM, Gábor Csárdi wrote:
>> Hi,
>> 
>> this is maybe mostly a personal preference, but I prefer not to put
>> generated files in the vc repository. Changes in the generated files,
>> especially if there is many of them, pollute the diffs and make them
>> less useful.
>> 
>> If you really want to be able to install the package directly from
>> github, one solution is to
>> 1. create another repository, that contains the complete generated
>> package, so that install_github() can install it.
>> 2. set up a CI service, that can download the package from github,
>> build the package or the generated files (check the package, while it
>> is at it), and then push the build stuff back to github.
>> 3. set up a hook on github, that invokes the CI after each commit.
>> 
>> I have used this setup in various projects with jenkins-ci and it
>> works well. Diffs are clean, the package is checked and built
>> frequently, and people can download it without having to install the
>> tools that generate the generated files.
>> 
>> The only downside is that you need to install a CI, so you need a
>> "server" for that. Maybe you can do this with travis-ci, maybe not, I
>> am not familiar with it that much.
>> 
>> Best,
>> Gabor
>> 
>> On Wed, Dec 11, 2013 at 7:39 PM, Kirill Müller
>>  wrote:
>>> Hi
>>> 
>>> Quite a few R packages are now available on GitHub long before they appear
>>> on CRAN, installation is simple thanks to devtools::install_github().
>>> However, it seems to be common practice to keep the .Rd files (and NAMESPACE
>>> and the Collate section in the DESCRIPTION) in the Git tree, and to manually
>>> update it, even if they are autogenerated from the R code by roxygen2. This
>>> requires extra work for each update of the documentation and also binds
>>> package development to a specific version of roxygen2 (because otherwise
>>> lots of bogus changes can be added by roxygenizing with a different
>>> version).
>>> 
>>> What options are there to generate the .Rd files during build/install? In
>>> https://github.com/hadley/devtools/issues/43 the issue has been discussed,
>>> perhaps it can be summarized as follows:
>>> 
>>> - The devtools package is not the right place to implement
>>> roxygenize-before-build
>>> - A continuous integration service would be better for that, but currently
>>> there's nothing that would be easy to use
>>> - Roxygenizing via src/Makefile could work but requires further
>>> investigation and an installation of Rtools/xcode on Windows/OS X
>>> 
>>> Especially the last point looks interesting to me, but since this is not
>>> widely used there must be pitfalls I'm not aware of. The general idea would
>>> be:
>>> 
>>> - Place code that builds/updates the .Rd and NAMESPACE files into
>>> src/Makefile
>>> - Users installing the package from source will require infrastructure
>>> (Rtools/make)
>>> - For binary packages, the .Rd files are already generated and added to the
>>> .tar.gz during R CMD build before they are submitted to CRAN/WinBuilder, and
>>> they are also generated (in theory) by R CMD build --binary
>>> 
>>> I'd like to hear your opinion on that. I have also found a thread on package
>>> development workflow
>>> (https://stat.ethz.ch/pipermail/r-devel/2011-September/061955.html) but
>>> there was nothing on un-versioning .Rd files.
>>> 
>>> 
>>> Cheers
>>> 
>>> Kirill
>>> 
>>> __
>>> R-dev

Re: [Rd] internal manipulation of ...

[Romain François]

Thanks. This works for me. See this gist: 
https://gist.github.com/romainfrancois/7959531

Romain

Le 13 déc. 2013 à 01:09, Hadley Wickham  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
>  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

Re: [Rd] External pointers and changing SEXPTYPE

[Romain François]

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  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 :
>> 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  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] Linking to native routines in other packages

[Romain François]

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 
#include 
#include 
#define COMPILING_MOTHER
#include 

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 
#include 
#include 

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  a écrit :

> Hi again,
> 
> On Wed, 22 Jan 2014 06:39:17 -0600
> Dirk Eddelbuettel  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 
> #include 
> #include 
> 
> 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 
> #include 
> 
> 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

[Rd] LinkingTo self

[Romain Francois]

Hello, 

Shipping header files for a package in inst/include and let other packages use 
it with LinkingTo is popular. 

Unfortunately for the package itself, we still need to use something like :

PKG_CPPFLAGS+=-I../inst/include/

in the Makevars and Makevars.win files. 

Could this become automatic ? 

So if a package has src/ and inst/include/ can we have it so that a -I flag is 
set accordingly. 

Would anyone be interested in reviewing a patch against R-devel for such 
feature ?

Romain

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] getting environment from "top" promise

[Romain Francois]

Hello, 

We have something very similar to your while loop in dplyr. 
https://github.com/hadley/dplyr/blob/02a609310184d003c2ae9e0c013bfa69fa4d257a/inst/include/tools/DataDots.h#L15

because we need to know exactly in which environment a promise is supposed to 
be evaluated, even though we might combine standard R evaluation with an 
alternative faster engine. this is the basis of what we called hybrid 
evaluation. 


For future work, I also have the while loop in the Promise class in Rcpp11, so 
that when you create a Promise in Rcpp11, its .environment() method gives you 
what you expect. 
https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Promise.h#L14
 

So, this is something I find useful, although I’m not sure we are supposed to 
mess with promises. 

Romain

Le 11 févr. 2014 à 19:02, Michael Lawrence  a écrit :

> Hi all,
> 
> It seems that there is a use case for obtaining the environment for the
> "top" promise. By "top", I mean following the promise chain up the call
> stack until hitting a non-promise.
> 
> S4 data containers often mimic the API of base R data structures. This
> means writing S4 methods for functions that quote their arguments, like
> with() and subset(). The methods package directly forwards any arguments
> not used for dispatch, so substitute(subset) is able to resolve the
> original quoted argument (this is not the case for naively written
> wrappers).  The problem then becomes figuring out the environment in which
> to evaluate the expression.
> 
> Consider:
> 
> setClass("A", representation(df = "data.frame"))
> 
> setMethod("subset", "A", function(x, subset) {
>  env <- parent.frame(2)
>  x@df <- x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
>  x
> })
> 
> dropLowMpg <- function(x, cutoff=20) {
>  invisible(subset(x, mpg > cutoff))
> }
> 
> a <- new("A", df=mtcars)
> dropLowMpg(a)
> 
> The above works just fine, because we figured out that we need to evaluate
> in the grand-parent frame to avoid the frame of the generic call. But now
> let's assume A has a subclass B, and subset,B delegates to subset,A via
> callNextMethod(). The call stack is different, and our assumption is
> invalid.
> 
> setClass("B", representation(nrow="integer"), contains="A")
> setMethod("subset", "B", function(x, ...) {
>  ans <- callNextMethod()
>  ans@nrow <- nrow(ans@df)
>  ans
> })
> b <- new("B", df=mtcars)
> dropLowMpg(b)
> Error in eval(expr, envir, enclos) (from #3) : object 'cutoff' not found
> 
> We can fix this with a simple C function:
> SEXP top_prenv(SEXP nm, SEXP env)
> {
>  SEXP promise = findVar(nm, env);
>  while(TYPEOF(promise) == PROMSXP) {
>env = PRENV(promise);
>promise = PREXPR(promise);
>  }
>  return env;
> }
> 
> With R wrapper:
> top_prenv <- function(x) {
>  .Call2("top_prenv", substitute(x), parent.frame())
> }
> 
> Then this works (need to set subset,B again to reset cache):
> 
> setMethod("subset", "A", function(x, subset) {
>  env <- top_prenv(subset)
>  x@df <- x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
>  x
> })
> setMethod("subset", "B", function(x, ...) {
>  ans <- callNextMethod()
>  ans@nrow <- nrow(ans@df)
>  ans
> })
> 
> b <- new("B", df=mtcars)
> dropLowMpg(b)
> 
> Would this be a useful addition to R? Is there a better way to solve this
> issue? We're using this successfully in the IRanges package now, but we'd
> like to avoid dealing with the internal details of R, and this is something
> that could be of general benefit.
> 
> Thanks,
> Michael
> 
>   [[alternative HTML version deleted]]
> 
> __
> 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] getting environment from "top" promise

[Romain Francois]

Le 14 févr. 2014 à 16:40, luke-tier...@uiowa.edu a écrit :

> On Tue, 11 Feb 2014, Romain Francois wrote:
> 
>> Hello,
>> 
>> We have something very similar to your while loop in dplyr.
>> https://github.com/hadley/dplyr/blob/02a609310184d003c2ae9e0c013bfa69fa4d257a/inst/include/tools/DataDots.h#L15
>> 
>> because we need to know exactly in which environment a promise is supposed 
>> to be evaluated, even though we might combine standard R evaluation with an 
>> alternative faster engine. this is the basis of what we called hybrid 
>> evaluation.
>> 
>> 
>> For future work, I also have the while loop in the Promise class in Rcpp11, 
>> so that when you create a Promise in Rcpp11, its .environment() method gives 
>> you what you expect.
>> https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Promise.h#L14
>> 
>> So, this is something I find useful, although I’m not sure we are supposed 
>> to mess with promises.
> 
> No you are not :-)

Most of what we do with them is consult them. So whenever the better approach 
you mention becomes available in R, we can update the Promise class and change 
how to get access to the expression and the environment in which it will be 
eventually evaluated. 

Not the first time I get « you are not supposed to use that because we might 
change it ». Experience is that that sort of changes are relatively slow to 
happen, so are easy to adapt to. 

Romain

> Promises are an internal mechanism for implementing lazy
> evaluation. They are convenient but also very inefficient, so they may
> very well go away when a better approach becomes available.  What will
> not go away is the functionality they provide -- bindings with
> deferred evaluations, an expression/code for the evaluation, and an
> environment (until the evaluation happens). If you build on those
> concepts you will be more future proof than if you assume there will
> be an internal promise object.
> 
> Best,
> 
> luke
> 
>> 
>> Romain
>> 
>> Le 11 févr. 2014 à 19:02, Michael Lawrence  a 
>> écrit :
>> 
>>> Hi all,
>>> 
>>> It seems that there is a use case for obtaining the environment for the
>>> "top" promise. By "top", I mean following the promise chain up the call
>>> stack until hitting a non-promise.
>>> 
>>> S4 data containers often mimic the API of base R data structures. This
>>> means writing S4 methods for functions that quote their arguments, like
>>> with() and subset(). The methods package directly forwards any arguments
>>> not used for dispatch, so substitute(subset) is able to resolve the
>>> original quoted argument (this is not the case for naively written
>>> wrappers).  The problem then becomes figuring out the environment in which
>>> to evaluate the expression.
>>> 
>>> Consider:
>>> 
>>> setClass("A", representation(df = "data.frame"))
>>> 
>>> setMethod("subset", "A", function(x, subset) {
>>> env <- parent.frame(2)
>>> x@df <- x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
>>> x
>>> })
>>> 
>>> dropLowMpg <- function(x, cutoff=20) {
>>> invisible(subset(x, mpg > cutoff))
>>> }
>>> 
>>> a <- new("A", df=mtcars)
>>> dropLowMpg(a)
>>> 
>>> The above works just fine, because we figured out that we need to evaluate
>>> in the grand-parent frame to avoid the frame of the generic call. But now
>>> let's assume A has a subclass B, and subset,B delegates to subset,A via
>>> callNextMethod(). The call stack is different, and our assumption is
>>> invalid.
>>> 
>>> setClass("B", representation(nrow="integer"), contains="A")
>>> setMethod("subset", "B", function(x, ...) {
>>> ans <- callNextMethod()
>>> ans@nrow <- nrow(ans@df)
>>> ans
>>> })
>>> b <- new("B", df=mtcars)
>>> dropLowMpg(b)
>>> Error in eval(expr, envir, enclos) (from #3) : object 'cutoff' not found
>>> 
>>> We can fix this with a simple C function:
>>> SEXP top_prenv(SEXP nm, SEXP env)
>>> {
>>> SEXP promise = findVar(nm, env);
>>> while(TYPEOF(promise) == PROMSXP) {
>>>   env = PRENV(promise);
>>>   promise = PREXPR(promise);
>>> }
>>> return env;
>>> }
>>> 
>>> With R wrapper:
>>> top_prenv <- function(x) {
>>>

[Rd] help with gotoExitingHandler(R_NilValue, call, entry); . Implementation of error handling internally

[Romain François]

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

[Romain François]

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  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] help with gotoExitingHandler(R_NilValue, call, entry); . Implementation of error handling internally

[Romain François]

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  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  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. 
>> 
>> 
>

Re: [Rd] [RFC] A case for freezing CRAN

[Romain Francois]

Weighting in. FWIW, I find the proposal conceptually quite interesting. 

For package developers, it does not have to be a frustration to have to wait a 
new version of R to release their code. Anticipated frustration was my initial 
reaction. Thinking about this more, I think this could be changed into 
opportunity. 

Since the pattern here is to use Rcpp as an example of something causing 
compatibility headaches, and I have some responsibility there, maybe I can 
comment on this. I would find it extremely valuable if there was only one 
unique version of Rcpp for a given released version of R. 

Users would have to wait longer to have the new stuff, but one can argue that 
at least they get something that is more tested. 

Would it be helpful for authors of package that have lots of dependency to 
start having stricter depends declarations in their DESCRIPTION files, e.g. : 

Depends: R (== 3.1.0)

?

Romain


For example, personally I’m waiting for 3.1.0 for releasing Rcpp11 because I 
want to leverage some C++11 support that has been included in R. It has been 
frustrating to have to wait, but it does change the way I make changes to the 
codebase. Perhaps it is a good habit to take. And it does not need « more work 
» for others, just more discipline and self control from people implementing 
this pattern. 

also, declaring a strict dependency requirement against a released version of R 
perhaps could resume the drama of « you were asked to test this against a very 
recent version of R-devel, and guess what a few hours ago I’ve just added a new 
test that makes your package non R CMD check worthy ». So less work for CRAN 
maintainers then. 

Le 19 mars 2014 à 23:57, Hervé Pagès  a écrit :

> 
> 
> On 03/19/2014 02:59 PM, Joshua Ulrich wrote:
>> On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms  
>> wrote:
>>> On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich 
>>> wrote:
>>>> 
>>>> The suggested solution is not described in the referenced article.  It
>>>> was not suggested that it be the operating system's responsibility to
>>>> distribute snapshots, nor was it suggested to create binary
>>>> repositories for specific operating systems, nor was it suggested to
>>>> freeze only a subset of CRAN packages.
>>> 
>>> 
>>> IMO this is an implementation detail. If we could all agree on a particular
>>> set of cran packages to be used with a certain release of R, then it doesn't
>>> matter how the 'snapshotting' gets implemented. It could be a separate
>>> repository, or a directory on cran with symbolic links, or a page somewhere
>>> with hyperlinks to the respective source packages. Or you can put all
>>> packages in a big zip file, or include it in your OS distribution. You can
>>> even distribute your entire repo on cdroms (debian style!) or do all of the
>>> above.
>>> 
>>> The hard problem is not implementation. The hard part is that for
>>> reproducibility to work, we need community wide conventions on which
>>> versions of cran packages are used by a particular release of R. Local
>>> downstream solutions are impractical, because this results in
>>> scripts/packages that only work within your niche using this particular
>>> snapshot. I expect that requiring every script be executed in the context of
>>> dependencies from some particular third party repository will make
>>> reproducibility even less common. Therefore I am trying to make a case for a
>>> solution that would naturally improve reliability/reproducibility of R code
>>> without any effort by the end-user.
>>> 
>> So implementation isn't a problem.  The problem is that you need a way
>> to force people not to be able to use different package versions than
>> what existed at the time of each R release.  I said this in my
>> previous email, but you removed and did not address it: "However, you
>> would need to find a way to actively _prevent_ people from installing
>> newer versions of packages with the stable R releases."  Frankly, I
>> would stop using CRAN if this policy were adopted.
>> 
>> I suggest you go build this yourself.  You have all the code available
>> on CRAN, and the dates at which each package was published.  If others
>> who care about reproducible research find what you've built useful,
>> you will create the very community you want.  And you won't have to
>> force one single person to change their workflow.
> 
> Yeah we've already heard this "do it yourself" kind of answer. Not a
> very productive one honestly.
> 
> Well actually that's what we've done for 

[Rd] internal string comparison (Scollate)

[Romain François]

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)

[Romain François]

Le 26 mars 2014 à 18:03, Gabriel Becker  a écrit :

> On Wed, Mar 26, 2014 at 9:50 AM, Dirk Eddelbuettel  wrote:
> 
> On 26 March 2014 at 17:22, Romain François wrote:
> | 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.
> 
> 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.

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 
testing though. I can develop a test suite that can let me know I’m 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] CXX_STD and configure.ac in packages

[Romain Francois]

Hi, 

My advice would be to use SystemRequirements: C++11

As  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  a écrit :

> In C++ code for use in a R-3.1.0 package, my specific problem is that I would 
> like to use  if it is available, or  if 
> not, or  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 compiler on Windows is GCC 4.6.x and supports
> the @option{-std=c++0x} flag and some C++11 features (see
> -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
> +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
> platforms, it is necessary to select a different compiler for C++11, as
> described above, @emph{via} personal @file{Makevars} files.  For
> example, on OS X 10.7 or later one could select @command{clang++}.
> 
> -- 
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
> 
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
> 
> __
> 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] CXX_STD and configure.ac in packages

[Romain François]

Le 31 mars 2014 à 12:20, Martyn Plummer  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  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  a écrit :
>> 
>>> In C++ code for use in a R-3.1.0 package, my specific problem is that I 
>>> would like to use  if it is available, or 
>>>  if not, or  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
>>&g

Re: [Rd] internal string comparison (Scollate)

[Romain François]

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  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  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 th

[Rd] special handling of row.names

[Romain François]

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] question regarding lang2 command in C

[Romain François]

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  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

Re: [Rd] R 3.1.0 and C++11

[Romain François]

Le 10 avr. 2014 à 17:58, Martyn Plummer  a écrit :

> On Thu, 2014-04-10 at 11:14 -0400, Gabor Grothendieck wrote:
>> On Tue, Oct 29, 2013 at 1:58 AM,   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] Is it possible to shrink an R object in place?

[Romain Francois]

Hello, 

I’ve been using shrinking in 
https://github.com/hadley/dplyr/blob/master/inst/include/tools/ShrinkableVector.h

This defines a ShrinkableVector of some R type (INTSXP, ...) given the maximum 
number of elements it will hold. Then, I reset with SETLENGTH when needed. The 
constructor protects the SEXP, and the destructor restores the original length 
before removing the protection. With this I only have to allocate the data 
once, and I can make R believe a vector is of a different size. As long as I 
restore the correct size eventually. 

Kevin, when you start using parallelism, you have to change the way you 
approach the sequence of things that go on. Particularly it is less of a 
problem to do a double pass, i.e. one to figure out the appropriate size and 
one to handle part of the data. And guess what, there is lots of that to come 
in next versions of Rcpp11. 

Romain

Le 11 avr. 2014 à 17:08, Simon Urbanek  a écrit :

> Kevin,
> Kevin,
> 
> On Apr 10, 2014, at 4:57 PM, Kevin Ushey  wrote:
> 
>> Suppose I generate an integer vector with e.g.
>> 
>>   SEXP iv = PROTECT(allocVector(INTSXP, 100));
>> 
>> and later want to shrink the object, e.g.
>> 
>>   shrink(iv, 50);
>> 
>> would simply re-set the length to 50, and allow R to reclaim the
>> memory that was previously used.
>> 
>> Is it possible to do this while respecting how R manages memory?
>> 
> 
> The short answer is, no.
> 
> There are several problems with this, one of the main ones being that there 
> is simply no way to release the "excess" memory, so the vector still has the 
> full length in memory. There is the SETLENGTH() function, but it's not part 
> of the API and it has been proposed for elimination because of the inherent 
> issues it causes (discrepancy in allocated and reported length).
> 
> 
>> The motivation: there are many operations where the length of the
>> output is not known ahead of time, and in such cases one typically
>> uses a data structure that can grow efficiently. Unfortunately, IIUC
>> SEXPRECs cannot do this; however, an alternative possibility would
>> involve reserving extra memory, and then shrinking to fit after the
>> operation is complete.
>> 
>> There have been some discussions previously that defaulted to answers
>> of the form "you should probably just copy", e.g.
>> https://stat.ethz.ch/pipermail/r-devel/2008-March/048593.html, but I
>> wanted to ping and see if others had ideas, or if perhaps there was
>> code in the R sources that might be relevant.
>> 
>> Another reason why this is interesting is due to C++11 and
>> multi-threading: if I can pre-allocate SEXPs that will contain results
>> in the main thread, and then fill these SEXPs asynchronously (without
>> touching R, and hence not getting in the way of the GC or otherwise),
>> I can then fill these SEXPs in place and shrink-to-fit after the
>> computations have been completed. With C++11 support coming with R
>> 3.1.0, functionality like this is very attractive.
>> 
> 
> I don't see how this is related to the question - it was always possible to 
> fill SEXPs from parallel threads and has been routinely used even in R itself 
> (most commonly via OpenMP).
> 
> 
>> The obvious alternatives are to 1) determine the length of the output
>> first and hence generate SEXPs of appropriate size right off the bat
>> (potentially expensive), and 2) fill thread-safe containers and copy
>> to an R object (definitely expensive).
>> 
> 
> In most current OSes, it is impossible to shrink allocated memory in-place, 
> so if you really don't know the size of the object, it will be copied anyway. 
> As mentioned above, the only case where shrinking may work is if you only 
> need to strip a few elements of a large vector so that keeping the same 
> allocation has no significant effect.
> 
> Cheers,
> Simon
> 
> 
> 
> 
>> I am probably missing something subtle (or obvious) as to why this may
>> not work, or be recommended, so I appreciate any comments.
>> 
>> Thanks,
>> Kevin
>> 
>> __
>> 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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] operation on ‘numsels’ may be undefined

[Romain François]

Le 23 juin 2014 à 15:20, cstrato  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; 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

[Romain François]

Le 23 juin 2014 à 18:28, cstrato  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  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; 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] using C code to create data frame but always return as list

[Romain Francois]

Hi, 

Can you give us what str on the returned object gives you? 

I think you need : 

SET_OBJECT(and, 1) ; 

at the end. 

Romain

Le 24 juin 2014 à 08:57, Yu Gong  a écrit :

> there is my code,  expect return value  is a data frame but R say it is list:
> 
> SEXP Julia_R_MD_NA_DataFrame(jl_value_t* Var)
> {
>  SEXP ans,names,rownames;
>  char evalcmd[4096];
>  int i;
>  const char* dfname="DataFrameName0tmp";
>  jl_set_global(jl_main_module, jl_symbol(dfname), (jl_value_t*)Var);
>  //Get Frame cols 
>  sprintf(evalcmd,"size(%s,2)",dfname);
>  jl_value_t* cols=jl_eval_string(evalcmd);
>  int collen=jl_unbox_long(cols);
>  jl_value_t* eachcolvector;
>  //Create VECSXP
> 
>  //Create SEXP for Each Column and assign
>  PROTECT(ans=allocVector(VECSXP,collen));
>  for (i=0;i  {
>   sprintf(evalcmd,"%s[%d]",dfname,i+1);
>   eachcolvector=jl_eval_string(evalcmd);
>   SET_VECTOR_ELT(ans,i,Julia_R_MD_NA(eachcolvector));
>  }
>  //set names attribute
>  sprintf(evalcmd,"names(%s)",dfname);
>  jl_value_t* ret=jl_eval_string(evalcmd);
>  jl_value_t* onesymbol;
>  if (jl_is_array(ret))
>  {
>   PROTECT(names=allocVector(STRSXP,collen));
>   for (i=0;i   { 
>onesymbol=jl_arrayref((jl_array_t*)ret,i);
>if (jl_is_symbol(onesymbol))
> SET_STRING_ELT(names,i,mkChar(((jl_sym_t*)onesymbol)->name));
>   }
>   setAttrib(ans,R_NamesSymbol,names);
>   UNPROTECT(1);
>  } 
>  //set row names
>  sprintf(evalcmd,"size(%s,1)",dfname);
>  jl_value_t* rows=jl_eval_string(evalcmd);
>  int rowlen=jl_unbox_long(rows);
>  PROTECT(rownames=allocVector(INTSXP,rowlen));
>  for (i=0;i   INTEGER(rownames)[i]=i+1;
>  setAttrib(ans,R_RowNamesSymbol,rownames);
>  UNPROTECT(1);
>  //set class as data frame
>  setAttrib(ans,R_ClassSymbol,mkString("data.frame"));
>  UNPROTECT(1);
>  return ans;
> }

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] using C code to create data frame but always return as list

[Romain François]

Le 24 juin 2014 à 14:58, Simon Urbanek  a écrit :

> On Jun 24, 2014, at 9:21 AM, Romain Francois  wrote:
> 
>> Hi, 
>> 
>> Can you give us what str on the returned object gives you? 
>> 
>> I think you need : 
>> 
>> SET_OBJECT(and, 1) ; 
>> 
>> at the end. 
>> 
> 
> SET_OBJECT should not be used by user code in normal circumstances, it is set 
> by R automatically as part of the handling of the "class" attribute.

Ah ok, thanks. I vaguely recall that I had to use it at some point, perhaps in 
conjunction with a direct SET_ATTRIB call, but I guess I’m not supposed to use 
this either. 

Romain
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Romain Francois]

I'll pick up operators. 

Le 7 sept. 2014 à 18:03, Uwe Ligges  a écrit :

> 
> 
> On 05.09.2014 20:25, Greg Snow wrote:
>> Uwe,
>> 
>> Have all of these packages found new maintainers? if not, which ones
>> are still looking to be adopted?
> 
> Thanks for asking, the ones still looking to be adaopted are:
> SemiPar cghseg monreg operators
> 
> Best,
> Uwe Ligges
> 
> 
>> 
>> thanks,
>> 
>> On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges  wrote:
>>> Dear maintainers and R-devel,
>>> 
>>> Several orphaned CRAN packages are about to be archived due to outstanding
>>> QC problems, but have CRAN and BioC packages depending on them which would
>>> be broken by the archival (and hence need archiving alongside).
>>> Therefore we are looking for new maintainers taking over maintainership for
>>> one or more of the following packages:
>>> 
>>> R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr
>>> 
>>> Package maintainers whose packages depend on one of these may be natural
>>> candidates to become new maintainers.
>>> Hence this messages is addressed to all these maintainers via BCC and to
>>> R-devel.
>>> 
>>> See
>>> 
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>>   
>>> 
>>> for information on the QC issues and the reverse dependencies.
>>> 
>>> Best wishes,
>>> Uwe Ligges
>>> (for the CRAN team)
>>> 
>>> __
>>> 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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Using Rtools with gcc 4.8.3

[Romain François]

Le 5 oct. 2014 à 13:14, Gabor Grothendieck  a écrit :

> On Sun, Oct 5, 2014 at 6:51 AM, Uwe Ligges
>  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

[Romain François]

Le 5 oct. 2014 à 13:56, Romain François  a écrit :

> 
> Le 5 oct. 2014 à 13:14, Gabor Grothendieck  a écrit :
> 
>> On Sun, Oct 5, 2014 at 6:51 AM, Uwe Ligges
>>  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] Linking to the BH package introduces CRAN warnings

[Romain François]

> Le 4 nov. 2014 à 15:42, Dirk Eddelbuettel  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

[Romain François]

> Le 4 nov. 2014 à 21:52, kaveh  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  
>>> <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] Linking to the BH package introduces CRAN warnings

[Romain Francois]

Envoyé de mon iPhone

> Le 5 nov. 2014 à 13:43, Dirk Eddelbuettel  a écrit :
> 
> 
> On 5 November 2014 at 00:55, kaveh wrote:
> | Dear all,
> | 
> | 
> | the simple code in below, when send to the
> | win-builder returns the following (and no other)
> | warning:
> | 
> | 
> | * checking compiled code ... WARNING
> | File 'quicky/libs/i386/quicky.dll':
> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> |  Object: 'quicky.o'
> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> |  Object: 'quicky.o'
> | File 'quicky/libs/x64/quicky.dll':
> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> |  Object: 'quicky.o'
> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> |  Object: 'quicky.o'
> | 
> | Compiled code should not call entry points which might terminate R nor
> | write to stdout/stderr instead of to the console, nor the C RNG.
> | 
> | See 'Writing portable packages' in the 'Writing R Extensions' manual.
> | 
> | 
> | Here is the source:
> | 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | #include 
> | 
> | #include 
> | #include 
> | 
> | #include 
> | 
> | using namespace std;
> | using namespace Eigen;
> | using Eigen::MatrixXd;
> | using Eigen::VectorXd;
> | using Eigen::VectorXi;
> | using Eigen::RowVectorXd;
> | 
> | 
> | using boost::math::chi_squared;
> | using boost::math::quantile;
> | using boost::math::complement;
> | using boost::math::normal_distribution;
> | using namespace boost::math::policies;
> | 
> | typedef policy<
> |promote_double
> |> my_policy_norm;
> | typedef policy<
> |promote_double
> |> my_policy_chi2;
> | 
> | typedef boost::math::normal_distribution my_norm;
> | typedef boost::math::chi_squared_distribution 
> | my_chi2;
> | 
> | 
> | VectorXd GetQs(const VectorXd& x){
> |  const int n=x.size();
> |  double mytol=1e-8;
> |  double the_max=x.maxCoeff();
> |  double the_min=x.minCoeff();
> |  double the_rag=(the_max-the_min);
> |  if(the_rag |  if(1.0-the_max |  if(the_min |  VectorXd y=x.array();
> |  for(int i=0;i | y(i)=sqrt(quantile(complement(my_chi2(1.0),x(i;
> |  return(y);
> | }
> | extern "C"{
> |  void quicky(int* rn,double* xi,double* yi){
> |  const int n=*rn;
> |  VectorXd x=Map(xi,n);
> |  Map(yi,n)=GetQs(x);
> |  }
> | }
> | 
> | 
> | So I guess, I should fill a bug report with the
> | BH maintainer?
> 
> Err, why? BH does nothing wrong. 

Calls to these forbidden fruits come from the BH tree so ...

> 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. 

> Dirk
> 
> 
> | Best regards,
> | 
> | 
> | On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
> | > Gentlemen,
> | >
> | > On 4 November 2014 at 23:36, kaveh wrote:
> | > | Dear Hadley,
> | > |
> | > | Thank you for this information, maybe the CRAN gods
> | > | will look favourably on this case too,
> | >
> | > You seemed to have missed a point my earlier email tried to stress: 
> Inclusion
> | > of BH does not lead to the warning.
> | >
> | > All this depends on WHICH headers are included, and the OP will need to 
> sort
> | > this out by modifying his code.
> | >
> | > Dirk
> | >   
> | > | Best regards,
> | > |
> | > | On 2014-11-04 23:32, Hadley Wickham wrote:
> | > | >>> | 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
> | > | > Mybe - I had this note in RSQLite, and CRAN seemed ok with my 
> explanation:
> | > | >
> | > | > * checking compiled code ... NOTE
> | > | >File 
> ‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
> | 

Re: [Rd] Linking to the BH package introduces CRAN warnings

[Romain François]

> Le 5 nov. 2014 à 14:45, Dirk Eddelbuettel  a écrit :
> 
> 
> On 5 November 2014 at 14:11, Romain Francois wrote:
> | > Le 5 nov. 2014 à 13:43, Dirk Eddelbuettel  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

[Rd] extending the colClasses argument in read.table

[Romain François]

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

Re: [Rd] Problem using raw vectors with inline cfunction

[Romain Francois]

Hello,

That is a bug in inline indeed. I just commited a fix in r-forge.

The fix is to obviously replace this as.character by an as.raw.

Thanks for teh report.

Romain

Le 01/02/13 10:25, Karl Forner a écrit :

Hello,


From what I understood from the documentation I found, when using the

inline cfunction with convention=".C",
R raw vectors should be given as unsigned char* to the C function.

But consider the following script:

library(inline)

testRaw <- cfunction(signature(raw='raw', len='integer')
 , body='
 int l = *len;
 int i = 0;
 Rprintf("sizeof(raw[0])=%i\\n", sizeof(raw[0]));
 for (i = 0; i < l; ++i) Rprintf("%i, ", (int)raw[i]);
 for (i = 0; i < l; ++i) raw[i] = i*10;
 '
 , convention=".C", language='C', verbose=TRUE
)

tt <- as.raw(1:10)
testRaw(tt, length(tt))


When I execute it:

$ R --vanilla --quiet < work/inline_cfunction_raw_bug.R

sizeof(raw[0])=1
192, 216, 223, 0, 0, 0, 0, 0, 224, 214,
  *** caught segfault ***
address (nil), cause 'unknown'

Traceback:
  1: .Primitive(".C")(, raw =
as.character(raw), len = as.integer(len))
  2: testRaw(tt, length(tt))
aborting ...
Segmentation fault (core dumped)


I was expecting to get in the C function a pointer on a byte array of
values (1,2,3,4,5,6,7,8,9,10).
Apparently that is not the case. I guess that the "raw =
as.character(raw)," printed in the traceback is responsible for the
observed behavior.

If it is expected behavior, how can I get a pointer on my array of bytes ?


Thanks.

Karl



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

R Graph Gallery: http://gallery.r-enthusiasts.com

blog:http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] invalid operands of types ‘SEXPREC*’ and ‘R_len_t’ to binary ‘operator/’ with Rcpp.

[Romain Francois]

Please use the appropriate mailing list (Rcpp-devel) for Rcpp questions. 

Romain

Le 14 mai 2013 à 06:42, Xiao He  a écrit :

> Dear R-Developers,
> 
> I just started learning how to use Rcpp. Earlier while using it, I
> encountered an error as shown below:
> 
> file74d8254b96d4.cpp: In function ‘Rcpp::NumericVector
> foo(Rcpp::NumericVector, Rcpp::NumericVector, Rcpp::NumericVector,
> Rcpp::Function, Rcpp::Function)’:
> file74d8254b96d4.cpp:10: error: invalid operands of types ‘SEXPREC*’ and
> ‘R_len_t’ to binary ‘operator/’
> make: *** [file74d8254b96d4.o] Error 1
> 
> Below is a mock function that can reproduce this error. I wonder if anyone
> can tell me what is the problem here. Thank you in advance!!
> 
> foo<-cppFunction('
>   NumericVector foo(NumericVector q, NumericVector shape1, NumericVector
> shape2, Function pbeta, Function sequence){
> NumericVector output(q.size());
> output=pbeta(sequence(q.size())/q.size(), shape1, shape2);
>return output;
> }
> ')
> 
> 
> Best,
> Xiao
> 
>[[alternative HTML version deleted]]
> 
> __
> 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] proposed changes to RSiteSearch

[Romain Francois]

About this:

gmaneSearch <- function( string,
   group = "gmane.comp.lang.r.*", author = "", sort = c("relevance", 
"date", "revdate"),

   op = c("and", "or") ){
  
   sort <- match.arg(sort)

   op <- match.arg( op )
  
   url <- sprintf(
   
'http://search.gmane.org/?query=%s&author=%s&group=%s&sort=%s&DEFAULTOP=%s', 


   gsub( ' +', '+', string),  author,  group,  sort, op )
   url <- URLencode( url )
   browseURL( url )
}


Liaw, Andy wrote:
From: Duncan Murdoch 
  

On 5/7/2009 10:18 AM, Jonathan Baron wrote:


On 05/07/09 10:05, Liaw, Andy wrote:
  

Can someone in R Core please take a look at the attached patches to
RSiteSearch() and its help page?  I guess Jon is planning 


some changes


on his site.  Jon:  could you elaborate on what the patch does?

The idea is simply to remove the mail archives, so the 
  

search will be


only of functions' help pages.  Eventually I will also add package
vignettes, but I don't think we need anything special for that.  I
can't imagine that someone would want to search just 
  

vignettes and not


help pages, or the reverse.

The reasons are: 1. The mail archives are becoming increasingly
difficult and time consuming for me to maintain.  2. There are now
three other ways of searching mail archives, all of which seem much
better than mine, but there seem to be no other good ways to search
help pages for functions, and, indeed, the new RSiteSearch packages
does only functions.  3. With only functions it would be much easier
for someone to set up a complete mirror of my site, which 
  

seems like a


good idea.
  
I'll incorporate the changes if you like.  What do you think 
of the idea 
of adding a gmane (or other archive) search to your results 
page?  Then 
if someone doesn't like what the man pages show, you can send them 
somewhere else, rather than leaving them to find out the 
other resources 
themselves.


gmane has sample code for this on their search page 
search.gmane.org, so 
it looks reasonably easy.  I'd suggest following their last example, 
with a drop-down box to select mailing lists, with 
comp.lang.r.* as an 
option for "all lists".


Duncan Murdoch



Actually, I was thinking about a possible RHelpSearch() in addition, if
Jon is no longer going to include the R-help archive in the search.  I
used the current RSiteSearch() a lot more for searching R-help archive
than functions in packages.  Ideas?  comments?

Andy 
Notice:  This e-mail message, together with any attachme...{{dropped:12}}


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


  



--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] proposed changes to RSiteSearch

[Romain Francois]

We could have a few functions similar to RSiteSearch or gmaneSearch I 
just posted and then cook a summary html page with R ...


Here is a function that grabs relevant groups from gmane:

gmaneGroups <- function( prefix = "gmane.comp.lang.r." ){
   url <- URLencode( sprintf( 
"http://dir.gmane.org/index.php?prefix=%s";, prefix) )
   txt <- grep( '^TRUE )
  
   rx <- '^.*?(.*?).*(.*?).*$'

   out <- data.frame(
   url = gsub( rx, "\\1", txt ),
   group = gsub( rx, "\\2", txt ),
   description = gsub( rx, "\\3", txt ),
   stringsAsFactors = FALSE
   )
   out$group <- sub( "...", ".*", out$group, fixed = TRUE )
   out
}

I'll clean this up and write a man page if there is interest in adding 
this to R, but this might be more appropriate in a package, for example: 
http://r-forge.r-project.org/projects/rsitesearch/


Romain

Liaw, Andy wrote:

From: Jonathan Baron
  

On 05/07/09 13:48, Liaw, Andy wrote:

From: Duncan Murdoch 
  

I'll incorporate the changes if you like


Yes.  Please do.  I understand that it won't take effect for a while.
When it does, I'll change my site.

  What do you think 

of the idea 
of adding a gmane (or other archive) search to your results 
page?  Then 
if someone doesn't like what the man pages show, you can 

send them 

somewhere else, rather than leaving them to find out the 
other resources 
themselves.


gmane has sample code for this on their search page 
search.gmane.org, so 
it looks reasonably easy.  I'd suggest following their 

last example, 

with a drop-down box to select mailing lists, with 
comp.lang.r.* as an 
option for "all lists".


Duncan Murdoch


Good idea.  I will do this.  But there are also two other good search
engines.  Maybe I'll add all three search alternatives.  But then,
according to Sheena Iyengar, people won't choose any!  Hmm.


Actually, I was thinking about a possible RHelpSearch() in 
  

addition, if

Jon is no longer going to include the R-help archive in the 
  

search.  I

used the current RSiteSearch() a lot more for searching 
  

R-help archive


than functions in packages.  Ideas?  comments?
  

This is OK with me, but I don't want to do it.  I guess it would
search gmane.  MarkMail is also pretty good, as is
http://tolstoy.newcastle.edu.au/R/ All these are much better than
Namazu for searching the R-help list.
    


Sorry I didn't make it clear:  I meant something like the gmaneSearcg()
that Romain posted, not hitting your site.

Best,
Andy
 
  

Jon




--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] proposed changes to RSiteSearch

[Romain Francois]

Jonathan Baron wrote:

After reading all this, I favor doing one of two things:

1. Put all the search stuff, including the proposed gmane function, in
   Spencer's new package but make it one of the default packages, like
   utils, etc., or,

2. Put everything in utils, including Spencer's new package and the
   gmane function.

I do not know enough to choose between these.
  
I would tend to prefer #1 so that the functionality can incubate in a 
separate package, and then when it is mature enough, we can make a call 
about what to do with it.


Something like this:
- a generic abstract function that sets up the interface to query a 
search engine.


- implementations of this, here are what I can think of:
+ jon's RSiteSearch for help pages
+ r graphical manuals
+ gmane, markmail for mail archives
+ classic help.search
+ R news (not clear how to do this right now)
+ vignettes (not clear how to do this right now)
+ JSS articles (not clear how to this right now)
+ FAQ (not clear how to this right now)
+ ... add your own by simply register your implementation

The point about having some sort of central generic function is that it 
can be responsible for asking all engines and bring all results back in 
a single format.


This somehow duplicates work I have been doing with the rsitesearch 
firefox extension, but doing it in R has several advantages.


This I think is enough design to be a separate package.

I am not sure what are the requirements for a package to be shipped with 
the distribution of R (QA, documentation, ...), but I am sure whoever 
steps me (maybe me) can make it compliant.


There is precedent for functionality that was in a package and was 
merged into utils afterwards (rcompgen), but I think it was included 
because this was necessary, don't think these search engines __have__ to 
be in utils.



On 05/07/09 14:42, spencerg wrote:
  
  1.  Whatever we do with the "RSiteSearch" function, it should 
still be available every time R starts.  If we put it in its own 
package, it should still be autoloaded with "base", "utils", "stats", etc. 



Good point.

  
  2.  Sundar indicated to me that, "if Jonathan would like to remove 
the search capability, it would be rather simple to move RSiteSearch to 
nabble" for the listserve archives.  The "RSiteSearch" function could be 
modified to combine that with a separate search of only the help pages 
on Jonathan's server. 



I do not understand "rather simple" at all.  For those who are
interested, I've put my notes on how to manage my site (which still
need a bit of revision, but this will give you some idea of what is
involved) in

http://finzi.psych.upenn.edu/~baron/notes.namazu.txt

The problem is that I have not found a way to automate this, so I
still spend several hours each month doing it by hand.  Too many
little glitches come up along the way, and the main problem is the
mailing lists.  Moreover, Namazu just doesn't work all that well for
mailing lists of this size, because of the page footers in each post.
(Now I remove them.  That was a bad idea.  But if we're going to get
rid of this anyway I will not take the time to figure out how to put
them back properly.)

Also, Liviu Androic argued that vignettes should be searchable
separately from help pages.  This makes sense, but I would strongly
prefer to move ahead on other changes and leave this until later.
The need for this sort of modification is what makes me favor option
#1 at the beginning (separate package) on the theory that it would be
easier for me to make changes than if it were part of utils, but I
don't know how this works.

So, if someone can make a decision about how to proceed, I'll do what
I can, as soon as I can.

Jon
  



--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] proposed changes to RSiteSearch

[Romain Francois]

strapply in package gsubfn brings elegance here:

> txt <- 'bar'
> rx <- "<(.*?)>(.*?)"
> strapply( txt, rx, c , perl = T )
[[1]]
[1] "foo" "bar" "foo"

Too bad you have to pay this on performance:

> txt <- rep( 'bar', 1000 )
> rx <- "<(.*?)>(.*?)"
> system.time( out <- strapply( txt, rx, c , perl = T ) )
  user  system elapsed
 2.923   0.005   3.063
> system.time( out2 <- sapply( paste('\\', 1:3, sep=''), function(x){
+ gsub(rx, x, txt, perl=TRUE)
+ } ) )
  user  system elapsed
 0.011   0.000   0.011

Not sure what the right play is


Wacek Kusnierczyk wrote:

Romain Francois wrote:
  

   txt <- grep( '^(.*?).*(.*?).*$'
   out <- data.frame(
   url = gsub( rx, "\\1", txt ),
   group = gsub( rx, "\\2", txt ),
   description = gsub( rx, "\\3", txt ),



looking at this bit of your code, i wonder why gsub is not vectorized
for the pattern and replacement arguments, although it is for the x
argument.  the three lines above could be collapsed to just one with a
vectorized gsub:

gsubm = function(pattern, replacement, x, ...)
   mapply(USE.NAMES=FALSE, SIMPLIFY=FALSE,
   gsub, pattern=pattern, replacement=replacement, x=x, ...)

for example, given the sample data

txt = 'foobar'
rx = '<(.*?)>(.*?)'

the sequence

open = gsub(rx, '\\1', txt, perl=TRUE)
content = gsub(rx, '\\2', txt, perl=TRUE)
close = gsub(rx, '\\3', txt, perl=TRUE)

print(list(open, content, close))
   
could be replaced with


data = structure(names=c('open', 'content', 'close'),
gsubm(rx, paste('\\', 1:3, sep=''), txt, perl=TRUE))

print(data)

surely, a call to mapply does not improve performance, but a
source-level fix should not be too difficult;  unfortunately, i can't
find myself willing to struggle with r sources right now.


note also that .*? does not work as a non-greedy .* with the default
regex engine, e.g.,

txt = "foo='FOO' bar='BAR'"
gsub("(.*?)='(.*?)'", '\\1', txt)
# "foo='FOO' bar"
gsub("(.*?)='(.*?)'", '\\2', txt)
# "BAR"

because the first .*? matches everyithng up to and exclusive of the
second, *not* the first, '='.  for a non-greedy match, you'd need pcre
(and using pcre generally improves performance anyway):

txt = "foo='FOO' bar='BAR'"
gsub("(.*?)='(.*?)'", '\\1', txt, perl=TRUE)
# "foo bar"
gsub("(.*?)='(.*?)'", '\\2', txt, perl=TRUE)
# "FOO BAR"

vQ


  



--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] proposed changes to RSiteSearch

[Romain Francois]

yes, and r graph gallery. those two would be easy to implement once the 
system is up.


Philippe Grosjean wrote:

Don't forget R wiki in the list.
Best,

Philippe
..<°}))><
 ) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (Numerical Ecology of Aquatic Systems
 ) ) ) ) )   Mons-Hainaut University, Belgium
( ( ( ( (
......

Romain Francois wrote:

Jonathan Baron wrote:

After reading all this, I favor doing one of two things:

1. Put all the search stuff, including the proposed gmane function, in
   Spencer's new package but make it one of the default packages, like
   utils, etc., or,

2. Put everything in utils, including Spencer's new package and the
   gmane function.

I do not know enough to choose between these.
  
I would tend to prefer #1 so that the functionality can incubate in a 
separate package, and then when it is mature enough, we can make a 
call about what to do with it.


Something like this:
- a generic abstract function that sets up the interface to query a 
search engine.


- implementations of this, here are what I can think of:
+ jon's RSiteSearch for help pages
+ r graphical manuals
+ gmane, markmail for mail archives
+ classic help.search
+ R news (not clear how to do this right now)
+ vignettes (not clear how to do this right now)
+ JSS articles (not clear how to this right now)
+ FAQ (not clear how to this right now)
+ ... add your own by simply register your implementation

The point about having some sort of central generic function is that 
it can be responsible for asking all engines and bring all results 
back in a single format.


This somehow duplicates work I have been doing with the rsitesearch 
firefox extension, but doing it in R has several advantages.


This I think is enough design to be a separate package.

I am not sure what are the requirements for a package to be shipped 
with the distribution of R (QA, documentation, ...), but I am sure 
whoever steps me (maybe me) can make it compliant.


There is precedent for functionality that was in a package and was 
merged into utils afterwards (rcompgen), but I think it was included 
because this was necessary, don't think these search engines __have__ 
to be in utils.



On 05/07/09 14:42, spencerg wrote:
 
  1.  Whatever we do with the "RSiteSearch" function, it should 
still be available every time R starts.  If we put it in its own 
package, it should still be autoloaded with "base", "utils", 
"stats", etc. 


Good point.

 
  2.  Sundar indicated to me that, "if Jonathan would like to 
remove the search capability, it would be rather simple to move 
RSiteSearch to nabble" for the listserve archives.  The 
"RSiteSearch" function could be modified to combine that with a 
separate search of only the help pages on Jonathan's server. 


I do not understand "rather simple" at all.  For those who are
interested, I've put my notes on how to manage my site (which still
need a bit of revision, but this will give you some idea of what is
involved) in

http://finzi.psych.upenn.edu/~baron/notes.namazu.txt

The problem is that I have not found a way to automate this, so I
still spend several hours each month doing it by hand.  Too many
little glitches come up along the way, and the main problem is the
mailing lists.  Moreover, Namazu just doesn't work all that well for
mailing lists of this size, because of the page footers in each post.
(Now I remove them.  That was a bad idea.  But if we're going to get
rid of this anyway I will not take the time to figure out how to put
them back properly.)

Also, Liviu Androic argued that vignettes should be searchable
separately from help pages.  This makes sense, but I would strongly
prefer to move ahead on other changes and leave this until later.
The need for this sort of modification is what makes me favor option
#1 at the beginning (separate package) on the theory that it would be
easier for me to make changes than if it were part of utils, but I
don't know how this works.

So, if someone can make a decision about how to proceed, I'll do what
I can, as soon as I can.

Jon
  









--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] proposed changes to RSiteSearch

[Romain Francois]

Philippe Grosjean wrote:


..<°}))><
 ) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (Numerical Ecology of Aquatic Systems
 ) ) ) ) )   Mons-Hainaut University, Belgium
( ( ( ( (
......

Romain Francois wrote:

strapply in package gsubfn brings elegance here:


Don't! If you write functions to be used in a package to be included 
somehow in the base or recommended packages, then, your package should 
only depends on... base (preferably), or recommended packages itself!


Definitely.



So, forget about gsubfn, unless it is itself incorporated in base or 
utils.

Best,

Philippe


 > txt <- 'bar'
 > rx <- "<(.*?)>(.*?)"
 > strapply( txt, rx, c , perl = T )
[[1]]
[1] "foo" "bar" "foo"

Too bad you have to pay this on performance:

 > txt <- rep( 'bar', 1000 )
 > rx <- "<(.*?)>(.*?)"
 > system.time( out <- strapply( txt, rx, c , perl = T ) )
  user  system elapsed
 2.923   0.005   3.063
 > system.time( out2 <- sapply( paste('\\', 1:3, sep=''), function(x){
+ gsub(rx, x, txt, perl=TRUE)
+ } ) )
  user  system elapsed
 0.011   0.000   0.011

Not sure what the right play is


Wacek Kusnierczyk wrote:

Romain Francois wrote:
 

   txt <- grep( '^(.*?).*(.*?).*$'
   out <- data.frame(
   url = gsub( rx, "\\1", txt ),
   group = gsub( rx, "\\2", txt ),
   description = gsub( rx, "\\3", txt ),



looking at this bit of your code, i wonder why gsub is not vectorized
for the pattern and replacement arguments, although it is for the x
argument.  the three lines above could be collapsed to just one with a
vectorized gsub:

gsubm = function(pattern, replacement, x, ...)
   mapply(USE.NAMES=FALSE, SIMPLIFY=FALSE,
   gsub, pattern=pattern, replacement=replacement, x=x, ...)

for example, given the sample data

txt = 'foobar'
rx = '<(.*?)>(.*?)'

the sequence

open = gsub(rx, '\\1', txt, perl=TRUE)
content = gsub(rx, '\\2', txt, perl=TRUE)
close = gsub(rx, '\\3', txt, perl=TRUE)

print(list(open, content, close))
   could be replaced with

data = structure(names=c('open', 'content', 'close'),
gsubm(rx, paste('\\', 1:3, sep=''), txt, perl=TRUE))

print(data)

surely, a call to mapply does not improve performance, but a
source-level fix should not be too difficult;  unfortunately, i can't
find myself willing to struggle with r sources right now.


note also that .*? does not work as a non-greedy .* with the default
regex engine, e.g.,

txt = "foo='FOO' bar='BAR'"
gsub("(.*?)='(.*?)'", '\\1', txt)
# "foo='FOO' bar"
gsub("(.*?)='(.*?)'", '\\2', txt)
# "BAR"

because the first .*? matches everyithng up to and exclusive of the
second, *not* the first, '='.  for a non-greedy match, you'd need pcre
(and using pcre generally improves performance anyway):

txt = "foo='FOO' bar='BAR'"
gsub("(.*?)='(.*?)'", '\\1', txt, perl=TRUE)
# "foo bar"
gsub("(.*?)='(.*?)'", '\\2', txt, perl=TRUE)
# "FOO BAR"

vQ


  









--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] package level connection API

[Romain Francois]

Hello,

In 2006 Jeffrey Horner proposed [1,2] a patch to allow package level 
access to the connection API from C code. As I'm involved in a few 
packages that would benefit from this exposure, I felt I would warm the 
discussion up.


Does this stand a chance of happening ?

Romain

[1] http://tolstoy.newcastle.edu.au/R/e2/devel/06/10/0565.html

[2] http://wiki.r-project.org/rwiki/doku.php?id=developers:r_connections_api


--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] step by step debugger in R?

[Romain Francois]

[moving this to r-devel]

Robert Gentleman wrote:

Hi,

Romain Francois wrote:
  

Duncan Murdoch wrote:


On 5/22/2009 10:59 AM, Michael wrote:
  

Really I think if there is a Visual Studio strength debugger, our
collective time spent in developing R code will be greatly reduced.


If someone who knows how to write a debugger plugin for Eclipse wants
to help, we could have that fairly easily.  All the infrastructure is
there; it's the UI part that's missing.

Duncan Murdoch
  

[I've copied Mark Bravington and Robert Gentleman to the list as they
are likely to have views here, and I am not sure they monitor R-help]

Hello,

Making a front-end to debugging was one of the proposed google summer of
code for this year [1], it was not retained eventually, but I am still
motivated.

Pretty much all infrastructure is there, and some work has been done
__very recently__ in R's debugging internals (ability to step up). As I
see it, the ability to call some sort of hook each time the debugger
waits for input would make it much easier for someone to write



 I have still not come to an understanding of what this is supposed to do? When
you have the browser prompt you can call any function or code you want to. There
is no need for something special to allow you to do that.
  
Sure. What I have in mind is something that gets __automatically__ 
called, similar to the task callback but happening right before the user 
is given the browser prompt.



front-ends. A recent post of mine (patch included) [2] on R-devel
suggested a custom prompt for browser which would do the trick, but I
now think that a hook would be more appropriate. Without something
similar to that, there is no way that I know of for making a front-end,
unless maybe if you embed R ... (please let me know how I am wrong)



 I think you are wrong. I can't see why it is needed. The external debugger has
lots of options for handling debugging. It can rewrite code (see examples in
trace for how John Chambers has done this to support tracing at a location),
which is AFAIK a pretty standard approach to writing debuggers. It can figure
out where the break point is (made a bit easier by allowing it to put in pieces
of text in the call to browser).  These are things the internal debugger can't 
do.

  

Thanks. I'll have another look into that.


There is also the debug package [3,4] which does __not__ work with R
internals but rather works with instrumenting tricks at the R level.
debug provides a tcl/tk front-end. It is my understanding that it does
not work using R internals (do_browser, ...) because it was not possible
at the time, and I believe this is still not possible today, but I might
be wrong. I'd prefer to be wrong actually.



  I don't understand this statement. It has always been possible to work with
the internal version - but one can also take the approach of rewriting code.
There are some difficulties supporting all the operations that one would like by
rewriting code and I think a combination of external controls and the internal
debugger will get most of the functionality that anyone wants.

  There are somethings that are hard and once I have a more complete list I will
be adding this to the appropriate manual. I will also be documenting the changes
that I have been making, but that project is in flux and won't be done until the
end of August, so people who want to look at it are welcome (it is in R-devel),
but it is in development and could change pretty much without notice.
  Romain noted that we now support stepping out from one place to another
function.  We also have a debugonce flag that lets you get close to step in, but
step in is very hard in R.

  I am mostly interested in writing tools in R that can be used by anyone that
wants to write an external debugger and am not that interested in any particular
external debugger. I would be happy to listen to feature requests or issues that
arise - but the discussion should probably be on R-devel mailing list.

  best wishes
Robert


  

Romain

[1] : http://www.r-project.org/soc09/ideas.html#p5
[2] : https://stat.ethz.ch/pipermail/r-devel/2009-April/053128.html
[3] : http://cran.r-project.org/web/packages/debug/index.html
[4] : http://cran.r-project.org/doc/Rnews/Rnews_2003-3.pdf




  



--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] step by step debugger in R?

[Romain Francois]

Robert Gentleman wrote:

Hi,
  I stripped the cc's as I believe that all read this list.

Romain Francois wrote:
  

[moving this to r-devel]

Robert Gentleman wrote:


Hi,

Romain Francois wrote:
 
  

Duncan Murdoch wrote:
   


On 5/22/2009 10:59 AM, Michael wrote:
 
  

Really I think if there is a Visual Studio strength debugger, our
collective time spent in developing R code will be greatly reduced.



If someone who knows how to write a debugger plugin for Eclipse wants
to help, we could have that fairly easily.  All the infrastructure is
there; it's the UI part that's missing.

Duncan Murdoch
  
  

[I've copied Mark Bravington and Robert Gentleman to the list as they
are likely to have views here, and I am not sure they monitor R-help]

Hello,

Making a front-end to debugging was one of the proposed google summer of
code for this year [1], it was not retained eventually, but I am still
motivated.

Pretty much all infrastructure is there, and some work has been done
__very recently__ in R's debugging internals (ability to step up). As I
see it, the ability to call some sort of hook each time the debugger
waits for input would make it much easier for someone to write



 I have still not come to an understanding of what this is supposed to
do? When
you have the browser prompt you can call any function or code you want
to. There
is no need for something special to allow you to do that.
  
  

Sure. What I have in mind is something that gets __automatically__
called, similar to the task callback but happening right before the user
is given the browser prompt.



 I am trying to understand the scenario you have in mind. Is it that the user is
running R directly and your debugger is essentially a helper function that gets
updated etc as R runs?
  
yes. there are now several ui toolkits that could be use to give some 
sort of graphical representation of what is being debugged.


I agree with you that and IDE should command R and not the other way 
around, but I am not (yet) here talking about a fully featured IDE, but 
simply a debugger.


I need to read more about embedding R (as in section 8 of WRE). I know 
you can supply your own implementation of the REPL, but I am not sure 
this includes the one that goes on once trapped into the browser. For 
example littler ships its own REPL, but this does not seem to fool/deal 
with browser:


$ r -e "print(1:10); browser(); print(1:5) "
[1]  1  2  3  4  5  6  7  8  9 10
Called from: NULL
c
[1]  1  2  3  4  5

Not sure this is an omission of Jeffrey and Dirk or something else.


 If so, then I don't think that works very well and given the constraints we
have with R I don't think it will be able to solve many of the problems that an
IDE should.  The hook you want will give you some functionality, but no where
near enough.
  


In the long run, I do agree. In the short run, I'd prefer taking the bus 
to the airport rather than walk.



 Let me suggest instead that the IDE should be running the show. It should
initialize an instance of R, but it controls all communication and hence
controls what is rendered on the client side.  If that is what you mean by
embedding R, then yes that is what is needed. There is no way that I can see to
support most of the things that IDE type debuggers support without the IDE
controlling the communication with R.

 And if I am wrong about what your debugger will look like please let me know.

 best wishes
   Robert


  

front-ends. A recent post of mine (patch included) [2] on R-devel
suggested a custom prompt for browser which would do the trick, but I
now think that a hook would be more appropriate. Without something
similar to that, there is no way that I know of for making a front-end,
unless maybe if you embed R ... (please let me know how I am wrong)



 I think you are wrong. I can't see why it is needed. The external
debugger has
lots of options for handling debugging. It can rewrite code (see
examples in
trace for how John Chambers has done this to support tracing at a
location),
which is AFAIK a pretty standard approach to writing debuggers. It can
figure
out where the break point is (made a bit easier by allowing it to put
in pieces
of text in the call to browser).  These are things the internal
debugger can't do.

  
  

Thanks. I'll have another look into that.



There is also the debug package [3,4] which does __not__ work with R
internals but rather works with instrumenting tricks at the R level.
debug provides a tcl/tk front-end. It is my understanding that it does
not work using R internals (do_browser, ...) because it was not possible
at the time, and I believe this is still not possible today, but I might
be wrong. I'd prefer to be wrong actually.



  I don't understand this statement. It has always been possible to
work 

Re: [Rd] Can a function know what other function called it?

[Romain Francois]

Duncan Murdoch wrote:

On 23/05/2009 4:55 PM, Robert Gentleman wrote:

Kynn Jones wrote:


[snip]


  and you have a breakpoint in bar, you could not (easily) 
distinguish which of
the two calls to bar was active. There is no line counter or anything 
of that

sort available.


The evaluator doesn't pay any attention to srcref records, so this is 
still true, but it would be possible to keep the srcref on the stack 
as well as all the other info there.


Please



I've written code (and I think I sent it to you last year) that can do 
things like replacing the statement coming from a particular line of a 
file with whatever code you like; this could be used in writing a nice 
source-level debugger.


yes



Duncan Murdoch



 best wishes
   Robert






--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel