Re: [Rd] Resolving functions using R's namespace mechanism can double runtime

[Romain Francois]

Le 27/04/10 22:16, Dominick Samperi a écrit :

It appears that the runtime for an R script can more than double if a few
references to a function foo() are replaced by more explict references
of the form pkgname::foo().


It would probably help your question if you provide some benchmarks.

a::b is just a shortcut for `::`( a, b ).


The more explicit references are of course required when two
loaded packages define the same function.


Not really. You can :
- resolve once: my_foo <- pkgname::foo
- import the variable into your namespace using the importFrom namespace 
directive.



I can understand why use of this mechanism is not free in an
interpreted environment like R, but the cost seems rather high.

Dominick


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

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

Re: [Rd] RInside & child threads

[Romain Francois]

Hi,

Thank you for your interest in RInside.

We usually engage people to use the Rcpp-devel mailing list for 
questions about RInside.


Could you prepare a small example of what you are trying to achieve and 
repost there. 
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


Romain

Le 30/04/10 19:32, Jaiganesh Balasubramanian a écrit :


Hi Folks,

I am creating a multi-threaded C++ application that initializes RInside in
one of the child thread.

I would also like to access support interfaces like Rcpp::Environment in the
remaining child threads, so that I could access any "R" function associated
with the
environment initialized.

When I run my program, I always get "C Stack limit too huge" errors.

I looked at the "Writing R Extensions" manual, and it pointed to
initializing the R_CStackLimit variable to "-1", and
that this initialization need to be made after the RInside constructor is
called. I did that, but it still does not work.

Can you please let me know how do we accomplish this task?

Thanks very much,
Jai




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

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

Re: [Rd] RInside & child threads

[Romain Francois]

Hi,

Thank you for your interest in RInside.

We usually engage people to use the Rcpp-devel mailing list for 
questions about RInside.


Could you prepare a small example of what you are trying to achieve and 
repost there. 
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


Romain

Le 30/04/10 19:32, Jaiganesh Balasubramanian a écrit :


Hi Folks,

I am creating a multi-threaded C++ application that initializes RInside in
one of the child thread.

I would also like to access support interfaces like Rcpp::Environment in the
remaining child threads, so that I could access any "R" function associated
with the
environment initialized.

When I run my program, I always get "C Stack limit too huge" errors.

I looked at the "Writing R Extensions" manual, and it pointed to
initializing the R_CStackLimit variable to "-1", and
that this initialization need to be made after the RInside constructor is
called. I did that, but it still does not work.

Can you please let me know how do we accomplish this task?

Thanks very much,
Jai




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

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

Re: [Rd] Memory allocation in C/C++ vs R?

[Romain Francois]

o the same applies to any R API call - direct or 
indirect. As a consequence you pretty much cannot call R API function from C++ 
unless you are very, very careful (don't forget that C++ does a lot of things 
behind your back such as initializing objects, exception contexts etc. which 
you technically have no control over).


As I said in my post, you can write safe C++ code, but you have to be very 
careful. But the point about libraries is that you have no control over what 
they do, so you cannot know whether they will interact in a bad way with R or 
not. STL is an example where only the interface is defined, the implementations 
are not and vary by OS, compiler etc. This makes it pretty much impossible to 
use it reliably since the fact that it will work on one implementation doesn't 
mean that it will work on another since it is the implementation details that 
will bite you. (I know that we had reports of things breaking due to STL but I 
don't remember what implementation/OS it was)

[The above issue are only the ones I was pointing out, there may be others that 
are not covered here].

Cheers,
Simon




 R context vs C++ exception example



dyn.load("stl.so")
.Call("bar")

something went wrong somewhere in C++...
Warning: stack imbalance in '.Call', 2 then 4
NULL

-- what happens is that this really corrupts the R call stack since the C++ 
exception mechanism bypassed R's call stack so R is now is an inconsistent 
state. The same can be invoked vice-versa (and is more common - using error in 
C++ will do it) but that's harder to show because you would have to track C++ 
allocations to see that you're leaking objects all over the place. That is also 
the reason why it's hard to find unless it's too late (and things may *appear* 
to work for some time while they are not).


stl.cc:

#include
#include

using namespace std;

extern "C" SEXP foo() {
  vector  a;
  a.resize(-1);
  return R_NilValue;
}

extern "C" SEXP bar() {
  try {
// lots of other C++ code here ...
eval(lang2(install(".Call"),mkString("foo")), R_GlobalEnv);
  } catch (...) {
REprintf("something went wrong somewhere in C++...\n");
  }
  return R_NilValue;
}


The fact that R has a C main may be problematic because C++ static
initializers may not be called properly, but the fact that packages are
usually loaded dynamically complicates this picture. The dynamic
library itself may take care of calling the static initializers (I'm not
sure about this, and this is probably OS-dependent). One possible
work-around would be to compile the first few lines (a stub) of
R main using the C++ compiler, leaving everything else as is
and compiled using the C compiler (at least until CXXR is widely
available).

Since C++ (and STL) are very popular it would be helpful for developers
to have a better idea of the benefits and risks of using these tools
with R.

Thanks,
Dominick

On Fri, Apr 30, 2010 at 9:00 AM, Simon Urbanek
  wrote:

Brian's answer was pretty exhaustive - just one more note that is indirectly 
related to memory management: C++ exception handling does interfere with R's 
error handling (and vice versa) so in general STL is very dangerous and best 
avoided in R. In addition, remember that regular local object rules are broken 
because you are not guaranteed to leave a function the regular way so there is 
a high danger of leaks and inconsistencies when using C++ memory management 
unless you specifically account for that. That said, I have written C++ code 
that works in R but you have to be very, very careful and think twice about 
using any complex C++ libraries since they are unlikely written in R-safe way.

Cheers,
Simon


On Apr 30, 2010, at 1:03 AM, Dominick Samperi wrote:


The R docs say that there are two methods that the C programmer can
allocate memory, one where R automatically frees the memory on
return from .C/.Call, and the other where the user takes responsibility
for freeing the storage. Both methods involve using R-provided
functions.

What happens when the user uses the standard "new" allocator?
What about when a C++ application uses STL and that library
allocates memory? In both of these cases the R-provided functions
are not used (to my knowledge), yet I have not seen any problems.

How is the memory that R manages and garbage collects kept
separate from the memory that is allocated on the C++ side
quite independently of what R is doing?

Thanks,
Dominick


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

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

[Rd] print.data.frame curiosity

[Romain Francois]

Hello,

I made a mistake and passed stringsAsFactors to the wrong function in :

> df <- as.data.frame( list( x = 1:3, y = c("a", "b", "c" ), 
stringsAsFactors = FALSE ) )


But then :

> df
  x y
1 1 a
2 2 b
3 3 c

and :

> df[["y"]]
[1] a b c
Levels: a b c
> str( df )
'data.frame':   3 obs. of  3 variables:
 $ x   : int  1 2 3
 $ y   : Factor w/ 3 levels "a","b","c": 1 2 3
 $ stringsAsFactors: logi  FALSE FALSE FALSE


Somehow, print.data.frame does not want to print a column named 
"stringsAsFactors". (I know this is a bad name for a column, but ...)


Apparently, this line in format.data.frame is responsible for the mismatch:

x <- do.call("data.frame", rval)

Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

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

Re: [Rd] Use of R and Rscript in configure/Makevars in packages

[Romain Francois]

Hello,

Thank you for these clear guidelines.

Given these subtleties, would it make sense to have a "configure.R" that 
would win over configure and configure.win, and have R invoking it 
correctly, as below ?


Romain

Le 20/05/10 08:51, Prof Brian Ripley a écrit :


We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.

(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under which
package installation is being done. So the general form is to use

${R_HOME}/bin/R

to select the right version. And since ${R_HOME} might contain spaces,
you need something like "${R_HOME}/bin/R".

There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.

(b) There are further issues with platforms which use sub-architectures
(mainly Mac OS X and R-devel Windows). On Windows the
architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of

"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe"
"${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe"
"${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe"

On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe do
exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation is
expensive on Windows, this intermediate step is best avoided.

On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so the
issues have been worked around (but not necessarily for user installs).

(c) Calling R in configure.win will typically call 32-bit R with R-devel
Windows. If the result needs to depend on the architecture (and e.g. the
library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for how
to achieve this.

(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)

BDR




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents

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

Re: [Rd] Use of R and Rscript in configure/Makevars in packages

[Romain Francois]

Le 20/05/10 09:40, Prof Brian Ripley a écrit :

On Thu, 20 May 2010, Romain Francois wrote:


Hello,

Thank you for these clear guidelines.

Given these subtleties, would it make sense to have a "configure.R"
that would win over configure and configure.win, and have R invoking
it correctly, as below ?


Only if someone in R-core volunteers to implement it, and this would not
solve the issue until R 2.12.0 and all the packages involved moved to it.


Sure. This leaves plently of time to test it then.

Reading the above literally, I will not work on a patch, but I can offer 
my time to test it if someone in R-core does volunteer.


Romain


Romain

Le 20/05/10 08:51, Prof Brian Ripley a écrit :


We have seen problems with a number of packages which use R/Rscript to
run R code in configure or makefiles.

(a) You must give a full path: there need be no version of R in the
path, and if there is it might not be the version/build of R under which
package installation is being done. So the general form is to use

${R_HOME}/bin/R

to select the right version. And since ${R_HOME} might contain spaces,
you need something like "${R_HOME}/bin/R".

There appear to be bare uses of Rscript in Rcpp RQuantLib bifactorial
mvabund, of bare R in ROracle pgfSweave rcom and many more packages
without quotes.

(b) There are further issues with platforms which use sub-architectures
(mainly Mac OS X and R-devel Windows). On Windows the
architecture-dependent executables will (as from R 2.12.0) be in
subdirectories of ${R_HOME}/bin, so the general form is to use one of

"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe"
"${R_HOME}/bin${R_ARCH_BIN}/Rterm.exe"
"${R_HOME}/bin${R_ARCH_BIN}/Rcmd.exe"

On R-devel Windows ${R_HOME}/bin/R.exe and ${R_HOME}/bin/Rscript.exe do
exist and are 32-bit executables whose sole task is to launch the
appropriate executable from a sub-directory. Since process creation is
expensive on Windows, this intermediate step is best avoided.

On Mac OS X, ${R_HOME}/bin/R is a script that launches the
architecture-dependent executables from a subdirectory, and on CRAN
builds ${R_HOME}/bin/Rscript is a 'fat' (multi-arch) executable, so the
issues have been worked around (but not necessarily for user installs).

(c) Calling R in configure.win will typically call 32-bit R with R-devel
Windows. If the result needs to depend on the architecture (and e.g. the
library dirs may well) then the work needs to be done in
src/Makevars.win: see the R-devel 'Writing R Extensions' manual for how
to achieve this.

(The reason is that configure.win is called once, and then
src/Makevars.win is called for each architecture.)

BDR




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents







--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
|- http://bit.ly/936ck2 : Rcpp 0.8.0
`- http://bit.ly/9aKDM9 : embed images in Rd documents

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

Re: [Rd] R 2.10 and help

[Romain Francois]

Le 27/05/10 09:48, Jamie Love a écrit :


Thanks for the info,

I'm happy to use the new httpd server that serves the help files -
that'd definitely help. My difficulty with this approach is that I'm
not sure how to get the URL -

Say for example I've done help.start(),

then I do:

help(plot)

it will redirect my web browser to the plot page -

How can I stop it touching my web browser and instead return to me the URL.

I tried overriding the browseURL() function, but it seem to do nothing.


Perhaps something like this:

> options( browser = function(url, ...) print( url ) )
> ?plot
[1] "http://127.0.0.1:9000/library/graphics/html/plot.html";

Romain


Ta




It's much more simple since 2.10 as you can simply use the URL (same URL as the 
help system uses). For examples see JGR or the Mac GUI. Or you can do the same 
thing that the Rhttpd server does  actually generating the html - see 
tools:::httpd






--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/cork4b : highlight 0.1-8
|- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
`- http://bit.ly/936ck2 : Rcpp 0.8.0

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

[Rd] require( "foo (>= 2.1)" )

[Romain Francois]

Hello,

I often find myself writing code like :

if( require( "foo" ) && compareVersion( packageDescription( 
"foo")[["Version"]], "2.1" ) < 0 ){


# code that uses version 2.1 of foo
} else {
stop( "could not load version >= 2.1 of foo" )
}



Would it make sense to include something like this in require, library, 
etc ...


require( "foo (>= 2.1)" )
require( "foo", minimal.version = "2.1" )

I know we can use Depends: foo (>= 2.1) in a package DESCRIPTION file, 
but that does not work for loose dependencies, when package "bar" works 
better with "foo" but can still work fine without, or when not making a 
package.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9CQ66r : RMetrics 2010
|- http://bit.ly/cork4b : highlight 0.1-8
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


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

[Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

Hello,

I'm trying to make .DollarNames generic and implement a method for it in 
a package. .DollarNames is the function that is now called to get 
completion possibilities.


My R code looks like this:

setGeneric( ".DollarNames" )

setClass("track",
 representation(x="numeric", y="numeric"))
## A class extending the previous, adding one more slot
setClass("trackCurve",
representation(smooth = "numeric"),
contains = "track")

setMethod( ".DollarNames", signature( x = "track", pattern = "character" 
), function(x, pattern){

grep( pattern, c("foo", "bar"), value = TRUE )  
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :

> require( foo )
> x <- new( "trackCurve", x = 1:10, y = 1:10, smooth = 1:10 )
> .DollarNames( x, "f" )
[1] "foo"

but completion does not work :

> x$f
x$


What do I miss ?

I've uploaded foo here : http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9CQ66r : RMetrics 2010
|- http://bit.ly/cork4b : highlight 0.1-8
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


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

Re: [Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

This seems to do the trick, but it does not feel right:

.onLoad <- function( libname, pkgname ){ 
utils <- asNamespace( "utils" )
unlockBinding( ".DollarNames", utils )
assignInNamespace( ".DollarNames", .DollarNames, utils )
lockBinding( ".DollarNames", utils )
}

Any better idea ?

Romain

Le 29/05/10 13:21, Romain Francois a écrit :


Hello,

I'm trying to make .DollarNames generic and implement a method for it in
a package. .DollarNames is the function that is now called to get
completion possibilities.

My R code looks like this:

setGeneric( ".DollarNames" )

setClass("track",
representation(x="numeric", y="numeric"))
## A class extending the previous, adding one more slot
setClass("trackCurve",
representation(smooth = "numeric"),
contains = "track")

setMethod( ".DollarNames", signature( x = "track", pattern = "character"
), function(x, pattern){
grep( pattern, c("foo", "bar"), value = TRUE )
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :

 > require( foo )
 > x <- new( "trackCurve", x = 1:10, y = 1:10, smooth = 1:10 )
 > .DollarNames( x, "f" )
[1] "foo"

but completion does not work :

 > x$f
x$


What do I miss ?

I've uploaded foo here :
http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain





--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9CQ66r : RMetrics 2010
|- http://bit.ly/cork4b : highlight 0.1-8
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


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

Re: [Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

Le 29/05/10 20:23, Deepayan Sarkar a écrit :

On Sat, May 29, 2010 at 4:21 AM, Romain Francois
  wrote:

Hello,

I'm trying to make .DollarNames generic and implement a method for it in a
package. .DollarNames is the function that is now called to get completion
possibilities.

My R code looks like this:

setGeneric( ".DollarNames" )

setClass("track",
 representation(x="numeric", y="numeric"))
## A class extending the previous, adding one more slot
setClass("trackCurve",
representation(smooth = "numeric"),
contains = "track")

setMethod( ".DollarNames", signature( x = "track", pattern = "character" ),
function(x, pattern){
grep( pattern, c("foo", "bar"), value = TRUE )
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :


require( foo )
x<- new( "trackCurve", x = 1:10, y = 1:10, smooth = 1:10 )
.DollarNames( x, "f" )

[1] "foo"

but completion does not work :


x$f

x$


I guess because


utils:::.DollarNames(x, "f")

character(0)


yes. hence the hack I used when replying which is probably not a good 
idea, specially if two packages want it.



so the S4 generic is not being seen within the utils namespace. I
don't know what the right fix is...

-Deepayan


Perhaps something like the attached ?

defining a generic in methods and use this one when methods dispatch is on.



What do I miss ?

I've uploaded foo here : http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1

Index: src/library/utils/R/completion.R
===
--- src/library/utils/R/completion.R(revision 52140)
+++ src/library/utils/R/completion.R(working copy)
@@ -351,7 +351,8 @@
else
{
## ## suffix must match names(object) (or 
ls(object) for environments)
-   .DollarNames(object, pattern = sprintf("^%s", 
makeRegexpSafe(suffix)))
+   dollarNames <- if( .isMethodsDispatchOn() ) 
methods:::.DollarNames else .DollarNames
+   dollarNames(object, pattern = sprintf("^%s", 
makeRegexpSafe(suffix)))   
## if (is.environment(object))
## {
## ls(object,
Index: src/library/methods/R/makeBasicFunsList.R
===
--- src/library/methods/R/makeBasicFunsList.R   (revision 52140)
+++ src/library/methods/R/makeBasicFunsList.R   (working copy)
@@ -222,7 +222,14 @@
base::sample(x, size, replace=replace, prob=prob, ...),
   signature = c("x", "size"), where = where)
 setGenericImplicit("sample", where, FALSE)
-
+
+setGeneric( ".DollarNames", 
+   function(x, pattern) standardGeneric(".DollarNames"), 
+   useAsDefault = function(x,pattern) utils:::.DollarNames(x,pattern), 
+   signature = "x", 
+   where = where )
+setGenericImplicit(".DollarNames", where, FALSE)
+
 ## not implicitGeneric() which is not yet available "here"
 registerImplicitGenerics(where = where)
 }
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 dispatch for .DollarNames (utils)

[Romain Francois]

Thanks. I'll apply the nice workaround for now.

Romain

Le 29/05/10 23:15, John Chambers a écrit :

The idea of modifying .DollarNames to recognize S4 methods is OK, but
the problem could arise again.

It would be better to have a general solution.  The general problem as
it seems is that an S3 generic called from within its package's
namespace (or from some other 3rd package) will not detect S4 methods.
In a sense, this is a natural consequence of namespace semantics and
therefore not a bug.  We don't really want to fix up each case when it
arises.

I can see two general solutions, one a reasonable fix that could likely
be implemented for 2.12.0, the other a slight hack added to make the
solution work now.

Both solutions start with the idea that we continue to treat the S3
generic as an S3 generic (at least when it's called from the owning
package's namespace).  We then define an S3 method for the S4 class.

Right now, that fails to recognize S4 inheritance (that's the fix that
should be doable for 2.12.0; most of the mechanism needed is already in
the UseMethod implementation).

The workaround/hack that *does* work now, I believe, is to insert a
dummy S3 class into the mix and define the S3 .DollarNames method for it.

Example:
 > setOldClass("foo3")
 > .DollarNames.foo3 <- function(x, pattern)"bar"
 >
 > setClass("foo", contains = "foo3", representation(x = "numeric"))
[1] "foo"
 >
 > ff = new("foo")
 >
 > setClass("fee", contains = "foo")
[1] "fee"
 >
 > fe = new("fee")

Both ff$ and fe$ complete with "bar", running 2.11.0 from the command line.

John





On 5/29/10 12:37 PM, Romain Francois wrote:

Le 29/05/10 20:23, Deepayan Sarkar a écrit :

On Sat, May 29, 2010 at 4:21 AM, Romain Francois
  wrote:

Hello,

I'm trying to make .DollarNames generic and implement a method for
it in a
package. .DollarNames is the function that is now called to get
completion
possibilities.

My R code looks like this:

setGeneric( ".DollarNames" )

setClass("track",
 representation(x="numeric", y="numeric"))
## A class extending the previous, adding one more slot
setClass("trackCurve",
representation(smooth = "numeric"),
contains = "track")

setMethod( ".DollarNames", signature( x = "track", pattern =
"character" ),
function(x, pattern){
grep( pattern, c("foo", "bar"), value = TRUE )
} )


and the NAMESPACE :

import( utils )
exportMethods( .DollarNames )
exportClasses( track, trackCurve )


When I load the package, I can call .DollarNames explicitely :


require( foo )
x<- new( "trackCurve", x = 1:10, y = 1:10, smooth = 1:10 )
.DollarNames( x, "f" )

[1] "foo"

but completion does not work :


x$f

x$


I guess because


utils:::.DollarNames(x, "f")

character(0)


yes. hence the hack I used when replying which is probably not a good
idea, specially if two packages want it.


so the S4 generic is not being seen within the utils namespace. I
don't know what the right fix is...

-Deepayan


Perhaps something like the attached ?

defining a generic in methods and use this one when methods dispatch
is on.



What do I miss ?

I've uploaded foo here :
http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz

Romain



__
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://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


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

Re: [Rd] require( "foo (>= 2.1)" )

[Romain Francois]

Hi,

Sure. I could and I would provide a patch. Since this is more of a "nice 
to have", I wanted to first find out whether others would find it 
useful, and also if such a patch would have chances to get accepted by 
one of R-core members.


Sometimes patches I or others provide upfront are not accepted. I'm not 
complaining about it, it is always an opportunity to learn something ...


Romain

Le 30/05/10 14:49, Wolfgang Huber a écrit :


Hi Romain,

not that I have any authority here, but wouldn't your suggestion (which
I think could be very useful) be more powerful if it were accompanied by
a patch that could be applied to the R sources?

Best wishes
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber




On 28/05/10 19:25, Romain Francois wrote:

Hello,

I often find myself writing code like :

if( require( "foo" ) && compareVersion( packageDescription(
"foo")[["Version"]], "2.1" ) < 0 ){

# code that uses version 2.1 of foo
} else {
stop( "could not load version >= 2.1 of foo" )
}



Would it make sense to include something like this in require, library,
etc ...

require( "foo (>= 2.1)" )
require( "foo", minimal.version = "2.1" )

I know we can use Depends: foo (>= 2.1) in a package DESCRIPTION file,
but that does not work for loose dependencies, when package "bar" works
better with "foo" but can still work fine without, or when not making a
package.

Romain



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


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

Re: [Rd] require( "foo (>= 2.1)" )

[Romain Francois]

Le 31/05/10 10:41, Barry Rowlingson a écrit :


On Sun, May 30, 2010 at 5:50 PM, Romain Francois
  wrote:

Hi,

Sure. I could and I would provide a patch. Since this is more of a "nice to
have", I wanted to first find out whether others would find it useful, and
also if such a patch would have chances to get accepted by one of R-core
members.

Sometimes patches I or others provide upfront are not accepted. I'm not
complaining about it, it is always an opportunity to learn something ...

>

  For starters you could write a function called "requireVersion" that
does what you want. That would help you (since you say you often find
yourself using this paradigm) and also it would help anyone else who
does this. And since it wouldn't be a patch to R it wouldn't need
R-gods to approve it. It would also make you think about how you'd
parameterise the call - I wouldn't want to build something that had to
parse "foo (>=2.1)"


The code already exists, to process DESCRIPTION files with:

Depends: foo (>= 2.1)

but I think I also prefer using another argument anyway. Then there is 
also : what do you do if a lower version is found: warning, error, 
something that is parameterized y another argument, ...



for example, but having a minimum.version
argument makes more sense. Shouldn't be that difficult, you've written
most of it already!

  It might then get included in one of the packages of miscellany on
CRAN, and then maybe become core R functionality (if you sacrifice the
required animal to the R-gods, of course).

Barry


The problem with another function on top of require or library is that 
it either has to copy a lot of code from library or first call library 
and then find out if the loaded version is high enough. I think it is 
better that the package is not loaded at all if the version is not good 
enough (it might load the packages it depends on for nothing, etc ...) 
which is why I think a patch to library makes more sense.




But, library or require currently don't have a ... sink so code like :

require( "foo", min.version = "2.1" )

would only work in, say R 2.12.0.


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/99bz5D : highlight 0.1-9
|- http://bit.ly/9CQ66r : RMetrics 2010
`- http://bit.ly/bklUXt : RcppArmadillo 0.2.1


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

[Rd] using C++ finalizers for external pointers

[Romain Francois]

Hello,

In Rcpp, we use a C++ template to finalizers for external pointers:

template 
void delete_finalizer(SEXP p){
if( TYPEOF(p) == EXTPTRSXP ){
T* ptr = (T*) EXTPTR_PTR(p) ;
delete ptr ;
}
}

This works fine. Or at least it has appeared to work fine for some time.


However, when compiled with suncc, this generates warnings [1] because 
the generated function is of C++ linkage and the finalizer type is 
declared to have C linkage in Rinternals.h


extern "C" {
...
typedef void (*R_CFinalizer_t)(SEXP);
void R_RegisterFinalizer(SEXP s, SEXP fun);
void R_RegisterCFinalizer(SEXP s, R_CFinalizer_t fun);
void R_RegisterFinalizerEx(SEXP s, SEXP fun, Rboolean onexit);
void R_RegisterCFinalizerEx(SEXP s, R_CFinalizer_t fun, Rboolean 
onexit);
...
}

Does anyone know a workaround ?

Would using an R finalizer (with R_RegisterFinalizer) using another 
external pointer to some class be appropriate ?


Romain

[1] : http://article.gmane.org/gmane.comp.lang.r.rcpp/433

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

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

> .Internal(inspect(eg))
@df70e48 25 S4SXP g0c0 [OBJ,NAM(2),gp=0x10,ATT]
ATTRIB:
 @df70ef0 02 LISTSXP g0c0 []
   TAG: @769258 01 SYMSXP g1c0 [MARK] "size"
   @c0f6db8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 4
   TAG: @15b0228 01 SYMSXP g1c0 [MARK,NAM(2)] "id"
   @c0f6178 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
 @12341c80 09 CHARSXP g0c2 [gp=0x20] "id_value"
   TAG: @607ce8 01 SYMSXP g1c0 [MARK,NAM(2),gp=0x4000] "class"
   @c0f6d58 16 STRSXP g0c1 [NAM(2),ATT] (len=1, tl=0)
 @96ed08 09 CHARSXP g1c1 [MARK,gp=0x21] "example"
   ATTRIB:
 @df70fd0 02 LISTSXP g0c0 []
   TAG: @624f70 01 SYMSXP g1c0 [MARK,NAM(2)] "package"
   @c0f6d88 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
 @67f5e0 09 CHARSXP g1c2 [MARK,gp=0x21,ATT] ".GlobalEnv"

that the 'eg' object is an S4SXP with an attribute that is a LISTSXP.
The LISTSXP has elements that are tagged with SYMSXP representing the
slot name, and values that are REALSXP (for 'size') or STRSXP (for
'id'). The LISTSXP attribute itself has an attribute, which contains
information about the package where the class is defined. With these
hints one can see through the S4 interface to the underlying
implementation

> attributes(eg)
$size
[1] 4

$id
[1] "id_value"

$class
[1] "example"
attr(,"package")
[1] ".GlobalEnv"

But probably you have a specific goal in mind, and this is too much
information...

Martin

>
> Thanks, Patrick
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel  r-project.org <mailto:R-devel  r-project.org> mailing 
list
> https://stat.ethz.ch/mailman/listinfo/r-devel


--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793




--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793



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

void set_data(int n, int *y, double *t);
void set_accuracy(int N, int M);
void set_par(double *par);
double loglikelihood(double *z);
};

//void Foo::set_experiment(int mm, double *CC, double *ss)
void Foo::do_foo(int mm)
{
m=mm;
}
void Foo::do_bar(double *CC)
{
C=CC;
}

RCPP_MODULE(mod_foo)
{
using namespace Rcpp;
class_( "Foo" )
.constructor()
.method("do_foo",&Foo::do_foo) // works
.method("do_bar",&Foo::do_bar) // does not work!
;
}


### compile warning with the working version:
** checking whether the name space can be loaded with stated dependencies ... 
WARNING
Error: .onLoad failed in loadNamespace() for 'Foo', details:
   call: value[[3L]](cond)
   error: failed to load module mod_foo from package Foo
Execution halted
A namespace must be able to be loaded with just the base namespace
loaded: otherwise if the namespace gets loaded by a saved object, the
session will be unable to start.
Probably some imports need to be declared in the NAMESPACE file.


### 00install.out
* installing *source* package ‘Foo’ ...
** libs
*** arch - i386
g++-4.2 -arch i386 -I/Library/Frameworks/R.framework/Resources/include 
-I/Library/Frameworks/R.framework/Resources/include/i386  -I/usr/local/include 
-I"/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include"
   -fPIC  -g -O2 -c Foo_mod.cpp -o Foo_mod.o
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/traits/Exporter.h:
 In constructor ‘Rcpp::traits::Exporter::Exporter(SEXPREC*) [with T = 
double*]’:
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/as.h:51:
   instantiated from ‘T Rcpp::internal::as(SEXPREC*, 
Rcpp::traits::r_type_generic_tag) [with T = double*]’
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/as.h:75:
   instantiated from ‘T Rcpp::as(SEXPREC*) [with T = double*]’
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/module/Module_generated_CppMethod.h:122:
   instantiated from ‘SEXPREC* Rcpp::CppMethod1::operator()(Class*, SEXPREC**) [with Class = Foo, U0 = double*]’
Foo_mod.cpp:59:   instantiated from here
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/include/Rcpp/traits/Exporter.h:31:
 error: cannot convert ‘SEXPREC*’ to ‘double*’ in initialization
make: *** [Foo_mod.o] Error 1
ERROR: compilation failed for package ‘Foo’

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


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

 (id and lambda) can change lengths, this is why I need
to reprotect them. I populate the i-th element of L1 by creating the
vectors "id" and "lambda", setting the length of these according to
some rule (that's the part where lengths change)... here is a reduced
form of my code:

 C

const int = length(L0);
SEXP L1;
PROTECT(L1 = allocVector(VECSXP,n));
SEXP id, lambda;

// Fixing size
for(i=0;ihttp://ggvega.cl


2013/11/5 Gabriel Becker :

George,

I don't see the relevance of the stackoverflow post you linked. In the
post,
the author wanted to change the length of an existing "mother list"
(matrix,
etc), while you specifically state that the length of L1 will not
change.

You say that the child lists (vectors if they are INTSXP/REALSXP) are
variable, but that is not what the linked post was about unless I am
completely missing something.

I can't really say more without knowing the details of how the vectors
are
being created and why they cannot just have the right length from the
start.

As for the error, that is a weird one. I imagine it means that a SEXP
thinks
that it has a type other than ones defined in Rinternals. I can't speak
to
how that could have happened from what you posted though.

Sorry I can't be of more help,
~G



On Mon, Nov 4, 2013 at 8:00 PM, George Vega Yon 
wrote:


Dear R-devel,

A couple of weeks ago I started to use the R C API for package
development. Without knowing much about C, I've been able to write
some routines sucessfully... until now.

My problem consists in dynamically creating a list ("L1") of lists
using .Call, the tricky part is that each element of the "mother list"
contains two vectors (INTSXP and REALEXP types) with varying sizes;
sizes that I set while I'm looping over another list's ("L1") elements
  (input list). The steps I've follow are:

FIRST: Create the "mother list" of size "n=length(L0)" (doesn't
change) and protect it as
   PROTECT(L1=allocVector(VECEXP, length(L0)))
and filling it with vectors of length two:
   for(i=0;ihttp://stackoverflow.com/questions/7458364/growing-an-r-matrix-inside-a-c-loop/7458516#7458516
I understood that it was necesary to (1) create the "child lists" and
protecting them with PROTECT_WITH_INDEX, and (2) changing its size
using SETLENGTH (Rf_lengthgets) and REPROTECT ing the lists in order
to tell the GC that the vectors had change.

THIRD: Once my two vectors are done ("id" and "lambda"), assign them
to the i-th element of the "mother list" L1 using
   SET_VECTOR_ELT(VECTOR_ELT(L1,i), 0, duplicate(id));
   SET_VECTOR_ELT(VECTOR_ELT(L1,i), 1, duplicate(lambda));

and unprotecting the elements protected with index: UNPROTECT(2);

}

FOURTH: Unprotecting the "mother list" (L1) and return it to R

With small datasets this works fine, but after trying with bigger ones
R (my code) keeps failing and returning a strange error that I haven't
been able to identify (or find in the web)

   "unimplemented type (29) in 'duplicate'"

This happens right after I try to use the returned list from my
routine (trying to print it or building a data-frame).

Does anyone have an idea of what am I doing wrong?

Best regards,

PS: I didn't wanted to copy the entire function... but if you need it
I can do it.

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

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





--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis





--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis


__
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

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

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

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-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> -- 
> _
> ETH Zürich
> Institute for Transport Planning and Systems
> HIL F 32.2
> Wolfgang-Pauli-Str. 15
> 8093 Zürich
> 
> Phone:   +41 44 633 33 17
> Fax: +41 44 633 10 57
> Secretariat: +41 44 633 31 05
> E-Mail:  kirill.muel...@ivt.baug.ethz.ch
> 
> __
> 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/

[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) {
>>>

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 the Bioconductor repositories:
> we freeze the BioC packages for each version of Bioconductor. But since
> this freezing doesn't happen at the CRAN level, and many BioC packages
> depend on CRAN packages, the freezing is only at the surface. Would be
> much better if the freezing was all the way down to the bottom of the
> sea. (Note that it is already if you install binary packages only.)
> 
> Yes it's technically possible to work around this by also hosting
> frozen versions

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] 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] 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] 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] 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] 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] 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] not a typo in list.Rd

[Romain Francois]

Le 18.08.2006 15:56, Gabor Grothendieck a écrit :
> On 8/18/06, Martin Maechler <[EMAIL PROTECTED]> wrote:
>   
>>>>>>> "Gregor" == Gregor Gorjanc <[EMAIL PROTECTED]>
>>>>>>> on Fri, 18 Aug 2006 14:48:40 +0200 writes:
>>>>>>>   
>>Gregor> Hin-Tak Leung wrote:
>>>> Gregor Gorjanc wrote:
>>>>> Hello!
>>>>>
>>>>> There is a tiny typo in list.Rd.
>>>>>
>>>>> Index: R/src/library/base/man/list.Rd
>>>>> ===
>>>>> --- ../man/list.Rd  (revision 38909)
>>>>> +++ ../man/list.Rd  (working copy)
>>>>> @@ -59,7 +59,7 @@
>>>>> inconsistent with functions such as \code{\link{as.character}}, and is
>>>>> for efficiency since lists can be expensive to copy.)
>>>>>
>>>>> -  \code{is.list} returns \code{TRUE} iff its argument
>>>>> +  \code{is.list} returns \code{TRUE} if its argument
>>>>>
>>>>
>>>> Those are not typo's - (there are two "iff"'s in that paragraph).
>>>> "iff" is a short-hand for "if and only if", in some culture.
>>
>>Gregor> OK, I did not know that and I appologize for making noise on the 
>> list
>>Gregor> for this. However, I wonder how many people know this?
>>
>> I think I'd like to keep fostering a culture where this is
>> known.  It's such a beatiful useful short concise language element.
>> If you don't know,  nowadays there's Wikipedia where you can
>> find it.
>>
>>Gregor> It is fine to have some short-hands (as IMHO, RTFM,
>>Gregor> etc. in e-mails), but these can be an obstacle for
>>Gregor> exact understanding of the documentation, specially
>>Gregor> for non-english users.
>>
>> I knew what 'iff' means many years before I knew any of the
>> above (and any other) e-mail acronyms,  But that just shows
>> how old I am
>>
>> Martin
>> 
>
> I think the documentation should be as clear as possible including
> to non-English speakers and to non-mathematicians and that means
> writing things out in full where there could be confusion.
Hi,

What about an \iff command ?

-- 
+---+
| Romain FRANCOIS   |
| R Graph Gallery : http://addictedtor.free.fr/graphiques   |
`---+

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

[Rd] modifs on ls

[Romain Francois]

Hi all,

It would be great to be able to use a syntax like :

R> ls("grid:::grid\.")

instead of :

R> ls("package:grid", pattern = "^grid\.")

Here is a modified version of `ls` that does the job. [ The only modifs 
are just after the if(!missing(name))  ]
Does that make sense ?

Cheers,

Romain


ls <- objects <-
function (name, pos = -1, envir = as.environment(pos), all.names = 
FALSE,
  pattern)
{


if (!missing(name)) {
   
if(length(grep(":::", name))){
   spl <- strsplit(name, ":::")[[1]] 
   name <- paste("package:", spl[1] , sep="")
   pattern  <- paste("^", spl[2], sep="")
}
   
   
nameValue <- try(name)
if(identical(class(nameValue), "try-error")) {
name <- substitute(name)
if (!is.character(name))
name <- deparse(name)
pos <- name
}
else
pos <- nameValue
}
all.names <- .Internal(ls(envir, all.names))
   
  
   
if (!missing(pattern)) {
   
if ((ll <- length(grep("[", pattern, fixed=TRUE))) > 0 &&
ll != length(grep("]", pattern, fixed=TRUE))) {
if (pattern == "[") {
pattern <- "\\["
warning("replaced regular expression pattern '[' by  
'['")
}
else if (length(grep("[^]\\[<-", pattern) > 0)) {
pattern <- sub("\\[<-", "\\[<-", pattern)
warning("replaced '[<-' by '[<-' in regular 
expression pattern")
}
}
grep(pattern, all.names, value = TRUE)
}
else all.names
}


-- 
*mangosolutions*
/data analysis that delivers/

Tel   +44 1249 467 467
Fax   +44 1249 467 468

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

Re: [Rd] Idea: Testimonials

[Romain Francois]

Gabor Grothendieck wrote:
> It occurred to me that we could have an optional file called TESTIMONIALS
> that comes with each package which could be a list of short testimonials from
> users indicating success with that package and possibly a few details of
> the successful application, e.g. it was used to analyse xyz data.
>
> Users would be encouraged to send in testimonials.
>
> This would give new users an immediate idea of what others have
> done with any given package.
>
> It would be up to the authors and maintainer to solicit the testimonials.
> The author and maintainer could list their own applications in
> that file too if they wished.
>
> Another possibility is to place the testimonials in the vignette if there
> is one.
>   
Hi,

Could that kind of things go to the wiki
http://wiki.r-project.org/rwiki/doku.php?id=packages:packages

Romain

-- 
*mangosolutions*
/data analysis that delivers/

Tel   +44 1249 467 467
Fax   +44 1249 467 468

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

[Rd] generic sample

[Romain Francois]

Hi,

When x is a data frame, sample(x) is not really sensible :

R> sample(iris) # sends back all the iris data set.

What about a generic sample function (from R-devel/src/library/base/R) 
with a method for class `data.frame` that would sample the row indexes 
and then do the subset. See the code below.


Cheers,


Romain


sample <- function(x, ...)
  UseMethod("sample")
 
sample.data.frame <- function(x, ...){
  x[ sample(1:nrow(x), ...), ] 
}


sample.default <- function(x, size, replace=FALSE, prob=NULL)
{
if(length(x) == 1 && x >= 1) {
if(missing(size)) size <- x
.Internal(sample(x, size, replace, prob))
}
else {
if(missing(size)) size <- length(x)
x[.Internal(sample(length(x), size, replace, prob))]
}
}


R> set.seed(4)
R> sample(iris, 5)
Sepal.Length Sepal.Width Petal.Length Petal.WidthSpecies
88   6.3 2.3  4.4 1.3 versicolor
24.9 3.0  1.4 0.2 setosa
44   5.0 3.5  1.6 0.6 setosa
41   5.0 3.5  1.3 0.3 setosa
119  7.7 2.6  6.9 2.3  virginica



-- 
*mangosolutions*
/data analysis that delivers/

Tel   +44 1249 467 467
Fax   +44 1249 467 468

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

[Rd] invert argument in grep

[Romain Francois]

Hello,

What about an `invert` argument in grep, to return elements that are 
*not* matching a regular expression :


R> grep("pink", colors(), invert = TRUE, value = TRUE)

would essentially return the same as :

R> colors() [ - grep("pink", colors()) ]


I'm attaching the files that I modified (against today's tarball) for 
that purpose.


Cheers,

Romain

--
*mangosolutions*
/data analysis that delivers/

Tel   +44 1249 467 467
Fax   +44 1249 467 468

grep <-
function(pattern, x, ignore.case = FALSE, extended = TRUE, perl = FALSE,
 value = FALSE, fixed = FALSE, useBytes = FALSE, invert = FALSE)
{
pattern <- as.character(pattern)
## when value = TRUE we return names
if(!is.character(x)) x <- structure(as.character(x), names=names(x))
## behaves like == for NA pattern
if (is.na(pattern)) {
if(value)
return(structure(rep.int(as.character(NA), length(x)),
 names = names(x)))
else
return(rep.int(NA, length(x)))
}

if(perl)
.Internal(grep.perl(pattern, x, ignore.case, value, useBytes, invert))
else
.Internal(grep(pattern, x, ignore.case, extended, value, fixed,
   useBytes, invert))
}

sub <-
function(pattern, replacement, x, ignore.case = FALSE, extended = TRUE,
 perl = FALSE, fixed = FALSE, useBytes = FALSE)
{
pattern <- as.character(pattern)
replacement <- as.character(replacement)
if(!is.character(x)) x <- as.character(x)
if (is.na(pattern))
return(rep.int(as.character(NA), length(x)))

if(perl)
.Internal(sub.perl(pattern, replacement, x, ignore.case, useBytes))
else
.Internal(sub(pattern, replacement, x, ignore.case,
  extended, fixed, useBytes))
}

gsub <-
function(pattern, replacement, x, ignore.case = FALSE, extended = TRUE,
 perl = FALSE, fixed = FALSE, useBytes = FALSE)
{
pattern <- as.character(pattern)
replacement <- as.character(replacement)
if(!is.character(x)) x <- as.character(x)
if (is.na(pattern))
return(rep.int(as.character(NA), length(x)))

if(perl)
.Internal(gsub.perl(pattern, replacement, x, ignore.case, useBytes))
else
.Internal(gsub(pattern, replacement, x, ignore.case,
   extended, fixed, useBytes))
}

regexpr <-
function(pattern, text, extended = TRUE, perl = FALSE,
 fixed = FALSE, useBytes = FALSE)
{
pattern <- as.character(pattern)
text <- as.character(text)
if(perl)
.Internal(regexpr.perl(pattern, text, useBytes))
else
.Internal(regexpr(pattern, text, extended, fixed, useBytes))
}

gregexpr <-
function(pattern, text, extended = TRUE, perl = FALSE,
 fixed = FALSE, useBytes = FALSE)
{
pattern <- as.character(pattern)
text <- as.character(text)
if(perl)
  .Internal(gregexpr.perl(pattern, text, useBytes))
else
  .Internal(gregexpr(pattern, text, extended, fixed, useBytes))
}

agrep <-
function(pattern, x, ignore.case = FALSE, value = FALSE,
 max.distance = 0.1)
{
pattern <- as.character(pattern)
if(!is.character(x)) x <- as.character(x)
## behaves like == for NA pattern
if (is.na(pattern)){
if (value)
return(structure(rep.int(as.character(NA), length(x)),
 names = names(x)))
else
return(rep.int(NA, length(x)))
}

if(!is.character(pattern)
   || (length(pattern) < 1)
   || ((n <- nchar(pattern)) == 0))
stop("'pattern' must be a non-empty character string")

if(!is.list(max.distance)) {
if(!is.numeric(max.distance) || (max.distance < 0))
stop("'max.distance' must be non-negative")
if(max.distance < 1)# transform percentages
max.distance <- ceiling(n * max.distance)
max.insertions <- max.deletions <- max.substitutions <-
max.distance
} else {
## partial matching
table <- c("all", "deletions", "insertions", "substitutions")
ind <- pmatch(names(max.distance), table)
if(any(is.na(ind)))
warning("unknown match distance components ignored")
max.distance <- max.distance[!is.na(ind)]
names(max.distance) <- table[ind]
## sanity checks
comps <- unlist(max.distance)
if(!all(is.numeric(comps)) || any(comps < 0))
stop("'max.distance' components must be non-negative")
## extract restrictions
if(is.null(max.distance$all))
max.distance$all <- 0.1
max.insertions <- max.deletions <- max.substitutions <-
max.distance$all
if(!is.null(max.distance$deletions))
max.deletions <- max.distance$deletions
if(!is.null(max.distance$insertions))
max.insertions <- max.distance$insertions
if(!is.null(max.distance$substitutions))
max.substitutions <- max.distance$su

Re: [Rd] invert argument in grep

[Romain Francois]

Duncan Murdoch wrote:
> On 11/9/2006 5:14 AM, Romain Francois wrote:
>> Hello,
>>
>> What about an `invert` argument in grep, to return elements that are 
>> *not* matching a regular expression :
>>
>> R> grep("pink", colors(), invert = TRUE, value = TRUE)
>>
>> would essentially return the same as :
>>
>> R> colors() [ - grep("pink", colors()) ]
>>
>>
>> I'm attaching the files that I modified (against today's tarball) for 
>> that purpose.
>
> I think a more generally useful change would be to be able to return a 
> logical vector with TRUE for a match and FALSE for a non-match, so a 
> simple !grep(...) does the inversion.  (This is motivated by the 
> recent R-help discussion of the fact that x[-selection] doesn't always 
> invert the selection when it's a vector of indices.)
>
> A way to do that without expanding the argument list would be to allow
>
> value="logical"
>
> as well as value=TRUE and value=FALSE.
>
> This would make boolean operations easy, e.g.
>
> colors()[grep("dark", colors(), value="logical")
>   & !grep("blue", colors(), value="logical")]
>
> to select the colors that contain "dark" but not "blue". (In this case 
> the RE to select that subset is rather simple because "dark" always 
> precedes "blue", but if that wasn't true, it would be a lot messier.)
>
> Duncan Murdoch
Hi,

It sounds like a nice thing to have. I would still prefer to type :

R> grep ( "dark", grep("blue", colors(), value = TRUE, invert=TRUE), 
value = TRUE )  


What about a way to pass more than one regular expression then be able 
to call :

R> grep( c("dark", "blue"), colors(), value = TRUE, invert = c(TRUE, FALSE)


I usually use that kind of shortcuts that are easy to remember.

vgrep <- function(...) grep(..., value = TRUE)
igrep <- function(...) grep(..., invert = TRUE)
ivgrep <- vigrep <- function(...) grep(..., invert = TRUE, value = TRUE)

What about things like the arguments `after` and `before` in unix grep. 
That could be used when grepping inside a function :

R> grep("plot\\.", body(plot.default) , value= TRUE)
[1] "localWindow <- function(..., col, bg, pch, cex, lty, lwd) 
plot.window(...)"
[2] "plot.new()"
[3] "plot.xy(xy, type, ...)"


when this could be useful  (possibly).

R> # grep("plot\\.", plot.default, after = 2, value = TRUE)
R> tmp <- tempfile(); sink(tmp) ; print(body(plot.default)); sink(); 
system( paste( "grep -A2 plot\\. ", tmp) )
localWindow <- function(..., col, bg, pch, cex, lty, lwd) 
plot.window(...)
localTitle <- function(..., col, bg, pch, cex, lty, lwd) title(...)
xlabel <- if (!missing(x))
--
plot.new()
localWindow(xlim, ylim, log, asp, ...)
panel.first
plot.xy(xy, type, ...)
panel.last
if (axes) {
--
if (frame.plot)
localBox(...)
if (ann)


BTW, if I call :

R> grep("plot\\.", plot.default)
Error in as.character(x) : cannot coerce to vector

What about adding that line at the beginning of grep, or something else 
to be able to do as.character on a function ?

if(is.function(x)) x <- body(x)


Cheers,

Romain
>>
>> Cheers,
>>
>> Romain


-- 
*mangosolutions*
/data analysis that delivers/

Tel   +44 1249 467 467
Fax   +44 1249 467 468

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

Re: [Rd] invert argument in grep

[Romain Francois]

Duncan Murdoch wrote:
> On 11/10/2006 12:52 PM, Romain Francois wrote:
>> Duncan Murdoch wrote:
>>> On 11/9/2006 5:14 AM, Romain Francois wrote:
>>>> Hello,
>>>>
>>>> What about an `invert` argument in grep, to return elements that 
>>>> are *not* matching a regular expression :
>>>>
>>>> R> grep("pink", colors(), invert = TRUE, value = TRUE)
>>>>
>>>> would essentially return the same as :
>>>>
>>>> R> colors() [ - grep("pink", colors()) ]
>>>>
>>>>
>>>> I'm attaching the files that I modified (against today's tarball) 
>>>> for that purpose.
>>>
>>> I think a more generally useful change would be to be able to return 
>>> a logical vector with TRUE for a match and FALSE for a non-match, so 
>>> a simple !grep(...) does the inversion.  (This is motivated by the 
>>> recent R-help discussion of the fact that x[-selection] doesn't 
>>> always invert the selection when it's a vector of indices.)
>>>
>>> A way to do that without expanding the argument list would be to allow
>>>
>>> value="logical"
>>>
>>> as well as value=TRUE and value=FALSE.
>>>
>>> This would make boolean operations easy, e.g.
>>>
>>> colors()[grep("dark", colors(), value="logical")
>>>   & !grep("blue", colors(), value="logical")]
>>>
>>> to select the colors that contain "dark" but not "blue". (In this 
>>> case the RE to select that subset is rather simple because "dark" 
>>> always precedes "blue", but if that wasn't true, it would be a lot 
>>> messier.)
>>>
>>> Duncan Murdoch
>> Hi,
>>
>> It sounds like a nice thing to have. I would still prefer to type :
>>
>> R> grep ( "dark", grep("blue", colors(), value = TRUE, invert=TRUE), 
>> value = TRUE )  
>
> That's good for intersecting two searches, but not for other boolean 
> combinations.
>
> My main point was that inversion isn't the only boolean operation you 
> may want, but R has perfectly good powerful boolean operators, so 
> installing a limited subset of boolean algebra into grep() is probably 
> the wrong approach.

Hi,

Yes, good point. I agree with you that the value = "logical" is probably 
worth having to take advantage of these logical operators.

 but, what about all these functions calling grep and passing 
arguments through the ellipsis. With this invert argument, we could do :

R> history(pattern = "grid\\..*\\(", invert = TRUE)

BTW, why not use ... in ls ? in case someone would like to use perl 
regex to use ls, or to get back at this thread, issue commands like :

R> ls("package:grid", pattern = "^grid\\.|Grob$", invert = TRUE)
 [1] "absolute.size"   "applyEdit"   "applyEdits"
 [4] "arcCurvature""arrow"   "childNames"
 [7] "convertHeight"   "convertNative"   "convertUnit"
[10] "convertWidth""convertX""convertY"
[13] "current.transform"   "current.viewport""current.vpPath"
[16] "current.vpTree"  "dataViewport""downViewport"
[19] "draw.details""drawDetails" "editDetails"
[22] "engine.display.list" "gEdit"   "gEditList"
[25] "get.gpar""getNames""gList"
[28] "gpar""gPath"   "grob"
[31] "grobHeight"  "grobName""grobWidth"
[34] "grobX"   "grobY"   "gTree"
[37] "heightDetails"   "is.unit" "layout.heights"
[40] "layoutRegion""layout.torture"  "layout.widths"
[43] "plotViewport""pop.viewport""popViewport"
[46] "postDrawDetails" "preDrawDetails"  "push.viewport"
[49] "pushViewport""seekViewport""setChildren"
[52] "stringHeight""stringWidth" "unit"
[55] "unit.c"  "unit.length" "unit.pmax"
[58] "unit.pmin"   "uni

Re: [Rd] SVG and tooltips, hyperlinks

[Romain Francois]

Wolfgang Huber wrote:
> Dear all,
>
> is there a good way to create SVG plots with R whose elements have 
> titles (tooltips) or act as hyperlinks?
>
> I am using the RSvgDevice package, which works great - but it doesn't 
> seem to support the notion that plot objects have titles or are act as 
> hyperlinks, so I am helping myself by giving the objects funny unique 
> colors and then postprocessing the .svg file.
>
> I wonder whether somebody has already implemented this in a more elegant 
> way.
>
> Best wishes
>Wolfgang
>   
Tony Plate posted an altered version of RSvgDevice on the finance list a
couple of weeks ago.
https://stat.ethz.ch/pipermail/r-sig-finance/2007q1/001261.html

It does not do hyperlinks yet, but that should not be too difficult to do.

Cheers,

Romain

-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123

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

[Rd] Probem with argument "append" in "Rprof"

[Romain Francois]

Hello,

Appending information to the profiler's output seems to generate
problems. Here is a small example of code :


require(boot)
Rprof( memory.profiling = TRUE)
Rprof(NULL)
for(i in 1:2){
  Rprof( memory.profiling = TRUE, append = TRUE)
  example(boot)
  Rprof(NULL)
}


The problem is that the file Rprof.out contains more than once the
header information:

$ grep "sample.interval=" Rprof.out
memory profiling: sample.interval=2
memory profiling: sample.interval=2
memory profiling: sample.interval=2

and `summaryRprof` or `R CMD Rprof` are not dealing with it

> idx <- grep( "sample", rownames( smp <- summaryRprof()[[1]] ) );
smp[idx, ]
  self.time self.pct total.time total.pct
sample.interval=2 00   0.04   0.1

`sample.interval=2` is incorrectly considered as a function.


This is not too much of a big deal, but then if I ask for memory
profiling information as well, I get nothing:

> summaryRprof( mem = "stats")
Error in tapply(1:1L, list(index = c("sample.interval=2:profiling:",  :
arguments must have same length
> summaryRprof( mem = "tseries")
Error in data.frame(..., check.names = FALSE) :
arguments imply differing number of rows: 1, 1490
> summaryRprof( mem = "both")
Error in apply(sapply(strsplit(memstuff, ":"), as.numeric), 1, diff) :
dim(X) must have a positive length

$ R CMD Rprof Rprof.out

Each sample represents  seconds.
Total run time: 0 seconds.

Total seconds: time spent in function and callees.
Self seconds: time spent in function alone.

   %   total   %   self
 totalseconds selfsecondsname
Illegal division by zero at /usr/local/lib/R/bin/Rprof line 91, <> line
1491.
 
A quick fix could be to ignore all the lines containing sample.interval=
except the first one, but then if someone wants to actually change the
interval argument in Rprof, it would not be correct. I attach a patch
against R-devel/src/library/utils/R/summRprof.R to do that anyway, but I
will look at a better solution.

I am not fluent enough in Perl to do the same in the Rprof script, it
looks like it does not handle the memory profiling information anyway. I
am about to learn Perl, so I guess it could be a useful way to do it. I
also attach a patch against R-devel/src/scripts/Rprof that would at
least get rid of the memory profiling information (if any). This is not
as good as dealing with it, but ... this is the first time I ever touch
a Perl script.


Cheers,

Romain



> version
  
_  
platform  
i686-pc-linux-gnu  
arch  
i686   
os
linux-gnu  
system i686,
linux-gnu
status Under development
(unstable)   
major 
2  
minor  6.0  
year  
2007   
month 
03 
day   
30 
svn rev   
40983  
language  
R  
version.string R version 2.6.0 Under development (unstable) (2007-03-30
r40983)

-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123

--- summRprof.R	2007-03-31 21:10:31.0 +0100
+++ /tmp/R-devel/src/library/utils/R/summRprof.R	2006-10-05 07:54:38.0 +0100
@@ -32,10 +32,8 @@
 repeat({
 
chunk<-readLines(filename,n=chunksize)
-   chunk <- chunk[ -grep("sample\\.interval=", chunk) ] 
if (length(chunk)==0)
break
-   
if (memory.profiling){
memprefix<-attr(regexpr(":[0-9]+:[0-9]+:[0-9]+:[0-9]+:",chunk),"match.length")
if (memory=="both"){
@@ -121,7 +119,6 @@
 repeat({
 
chunk<-readLines(filename,n=chunksize)
-   chunk <- chunk[ -grep("sample\\.interval=", chunk) ] 
if (length(chunk)==0)
break
memprefix<-attr(regexpr(":[0-9]+:[0-9]+:[0-9]+:[0-9]+:",chunk),
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Probem with argument "append" in "Rprof"

[Romain Francois]

[forgot to attach the second patch in the first mail, sorry.]

Hello,

Appending information to the profiler's output seems to generate
problems. Here is a small example of code :


require(boot)
Rprof( memory.profiling = TRUE)
Rprof(NULL)
for(i in 1:2){
  Rprof( memory.profiling = TRUE, append = TRUE)
  example(boot)
  Rprof(NULL)
}


The problem is that the file Rprof.out contains more than once the
header information:

$ grep "sample.interval=" Rprof.out
memory profiling: sample.interval=2
memory profiling: sample.interval=2
memory profiling: sample.interval=2

and `summaryRprof` or `R CMD Rprof` are not dealing with it

> idx <- grep( "sample", rownames( smp <- summaryRprof()[[1]] ) );
smp[idx, ]
  self.time self.pct total.time total.pct
sample.interval=2 00   0.04   0.1

`sample.interval=2` is incorrectly considered as a function.


This is not too much of a big deal, but then if I ask for memory
profiling information as well, I get nothing:

> summaryRprof( mem = "stats")
Error in tapply(1:1L, list(index = c("sample.interval=2:profiling:",  :
arguments must have same length
> summaryRprof( mem = "tseries")
Error in data.frame(..., check.names = FALSE) :
arguments imply differing number of rows: 1, 1490
> summaryRprof( mem = "both")
Error in apply(sapply(strsplit(memstuff, ":"), as.numeric), 1, diff) :
dim(X) must have a positive length

$ R CMD Rprof Rprof.out

Each sample represents  seconds.
Total run time: 0 seconds.

Total seconds: time spent in function and callees.
Self seconds: time spent in function alone.

   %   total   %   self
 totalseconds selfsecondsname
Illegal division by zero at /usr/local/lib/R/bin/Rprof line 91, <> line
1491.

A quick fix could be to ignore all the lines containing sample.interval=
except the first one, but then if someone wants to actually change the
interval argument in Rprof, it would not be correct. I attach a patch
against R-devel/src/library/utils/R/summRprof.R to do that anyway, but I
will look at a better solution.

I am not fluent enough in Perl to do the same in the Rprof script, it
looks like it does not handle the memory profiling information anyway. I
am about to learn Perl, so I guess it could be a useful way to do it. I
also attach a patch against R-devel/src/scripts/Rprof that would at
least get rid of the memory profiling information (if any). This is not
as good as dealing with it, but ... this is the first time I ever touch
a Perl script.


Cheers,

Romain



> version

_
platform
i686-pc-linux-gnu
arch
i686
os
linux-gnu
system i686,
linux-gnu
status Under development
(unstable)
major
2
minor  6.0
year
2007
month
03
day
30
svn rev
40983
language
R
version.string R version 2.6.0 Under development (unstable) (2007-03-30
r40983)

-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123


--- summRprof.R	2007-03-31 21:10:31.0 +0100
+++ /tmp/R-devel/src/library/utils/R/summRprof.R	2006-10-05 07:54:38.0 +0100
@@ -32,10 +32,8 @@
 repeat({
 
chunk<-readLines(filename,n=chunksize)
-   chunk <- chunk[ -grep("sample\\.interval=", chunk) ] 
if (length(chunk)==0)
break
-   
if (memory.profiling){
memprefix<-attr(regexpr(":[0-9]+:[0-9]+:[0-9]+:[0-9]+:",chunk),"match.length")
if (memory=="both"){
@@ -121,7 +119,6 @@
 repeat({
 
chunk<-readLines(filename,n=chunksize)
-   chunk <- chunk[ -grep("sample\\.interval=", chunk) ] 
if (length(chunk)==0)
break
memprefix<-attr(regexpr(":[0-9]+:[0-9]+:[0-9]+:[0-9]+:",chunk),

--- Rprof	2007-03-31 21:23:16.0 +0100
+++ /tmp/R-devel/src/scripts/Rprof	2007-03-31 19:58:29.0 +0100
@@ -57,12 +57,11 @@
 %totalcounts = ();
 
 while (<>) {
-if (/.*sample\.interval=/) {
-	s/.*sample\.interval=//;
+if (/^sample\.interval=/) {
+	s/sample\.interval=//;
 	$sample = $_ / 1e6;
 } else {
 	chomp;
-  s/[^\"]*\"/"/;
 	@line = split(/ /);
 	%names = ();
 	$leaf = @line[0];
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Probem with argument "append" in "Rprof"

[Romain Francois]

 And now I realize I gave the patches in the wrong order, let me try
again

Cheers,

Romain

Romain Francois wrote:
> [forgot to attach the second patch in the first mail, sorry.]
>
> Hello,
>
> Appending information to the profiler's output seems to generate
> problems. Here is a small example of code :
>
> 
> require(boot)
> Rprof( memory.profiling = TRUE)
> Rprof(NULL)
> for(i in 1:2){
>   Rprof( memory.profiling = TRUE, append = TRUE)
>   example(boot)
>   Rprof(NULL)
> }
> 
>
> The problem is that the file Rprof.out contains more than once the
> header information:
>
> $ grep "sample.interval=" Rprof.out
> memory profiling: sample.interval=2
> memory profiling: sample.interval=2
> memory profiling: sample.interval=2
>
> and `summaryRprof` or `R CMD Rprof` are not dealing with it
>
>   
>> idx <- grep( "sample", rownames( smp <- summaryRprof()[[1]] ) );
>> 
> smp[idx, ]
>   self.time self.pct total.time total.pct
> sample.interval=2 00   0.04   0.1
>
> `sample.interval=2` is incorrectly considered as a function.
>
>
> This is not too much of a big deal, but then if I ask for memory
> profiling information as well, I get nothing:
>
>   
>> summaryRprof( mem = "stats")
>> 
> Error in tapply(1:1L, list(index = c("sample.interval=2:profiling:",  :
> arguments must have same length
>   
>> summaryRprof( mem = "tseries")
>> 
> Error in data.frame(..., check.names = FALSE) :
> arguments imply differing number of rows: 1, 1490
>   
>> summaryRprof( mem = "both")
>> 
> Error in apply(sapply(strsplit(memstuff, ":"), as.numeric), 1, diff) :
> dim(X) must have a positive length
>
> $ R CMD Rprof Rprof.out
>
> Each sample represents  seconds.
> Total run time: 0 seconds.
>
> Total seconds: time spent in function and callees.
> Self seconds: time spent in function alone.
>
>%   total   %   self
>  totalseconds selfsecondsname
> Illegal division by zero at /usr/local/lib/R/bin/Rprof line 91, <> line
> 1491.
>
> A quick fix could be to ignore all the lines containing sample.interval=
> except the first one, but then if someone wants to actually change the
> interval argument in Rprof, it would not be correct. I attach a patch
> against R-devel/src/library/utils/R/summRprof.R to do that anyway, but I
> will look at a better solution.
>
> I am not fluent enough in Perl to do the same in the Rprof script, it
> looks like it does not handle the memory profiling information anyway. I
> am about to learn Perl, so I guess it could be a useful way to do it. I
> also attach a patch against R-devel/src/scripts/Rprof that would at
> least get rid of the memory profiling information (if any). This is not
> as good as dealing with it, but ... this is the first time I ever touch
> a Perl script.
>
>
> Cheers,
>
> Romain
>
>
>
>   
>> version
>> 
>
> _
> platform
> i686-pc-linux-gnu
> arch
> i686
> os
> linux-gnu
> system i686,
> linux-gnu
> status Under development
> (unstable)
> major
> 2
> minor  6.0
> year
> 2007
> month
> 03
> day
> 30
> svn rev
> 40983
> language
> R
> version.string R version 2.6.0 Under development (unstable) (2007-03-30
> r40983)
>   
-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123

--- /tmp/R-devel/src/library/utils/R/summRprof.R	2006-10-05 07:54:38.0 +0100
+++ summRprof.R	2007-03-31 21:10:31.0 +0100
@@ -32,8 +32,10 @@
 repeat({
 
chunk<-readLines(filename,n=chunksize)
+   chunk <- chunk[ -grep("sample\\.interval=", chunk) ] 
if (length(chunk)==0)
break
+   
if (memory.profiling){
memprefix<-attr(regexpr(":[0-9]+:[0-9]+:[0-9]+:[0-9]+:",chunk),"match.length")
if (memory=="both"){
@@ -119,6 +121,7 @@
 repeat({
 
chunk<-readLines(filename,n=chunksize)
+   chunk <- chunk[ -grep("sample\\.interval=", chunk) ] 
if (length(chunk)==0)
break
memprefix<-attr(regexpr(":[0-9]+:[0-9]+:[0-9]+:[0-9]+:",chunk),
--- /tmp/R-devel/src/scripts/Rprof	2007-03-31 19:58:29.0 +0100
+++ Rprof	2007-03-31 21:23:16.0 +0100
@@ -57,11 +57,12 @@
 %totalcounts = ();
 
 while (<>) {
-if (/^sample\.interval=/) {
-	s/sample\.interval=//;
+if (/.*sample\.interval=/) {
+	s/.*sample\.interval=//;
 	$sample = $_ / 1e6;
 } else {
 	chomp;
+  s/[^\"]*\"/"/;
 	@line = split(/ /);
 	%names = ();
 	$leaf = @line[0];
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] a taste of regex in `[.data.frame`

[Romain Francois]

Hello,

I am often asked how to filter lines from a data frame, like for example
get all the Mazda cars from mtcars, so that usually does the trick:

R> mtcars[ grep("Mazda", rownames(mtcars)) ,  ]

but, what about using a formula in `[.data.frame` to make that sort of
code meaningful:

# rownames matching "Mazda"
R> mtcars[~Mazda, ]
   mpg cyl  disp  hp dratwt  qsec vs am gear carb
Mazda RX4 21.0   6 160.0 110 3.90 2.620 16.46  0  144
Mazda RX4 Wag 21.0   6 160.0 110 3.90 2.875 17.02  0  144

# two first lines of iris, with the columns matching the regex "Sep"
R> iris[1:2, ~Sep]
  Sepal.Length Sepal.Width
1  5.1 3.5
2  4.9 3.0

# two first lines of iris, with the columns matching the regex "\\."
R> iris[1:2, ~"\\."]
  Sepal.Length Sepal.Width Petal.Length Petal.Width
1  5.1 3.5  1.4 0.2
2  4.9 3.0  1.4 0.2



It is just a matter of adding these lines to `[.data.frame` after the
second line :


if(!missing(j) && inherits(j, "formula")) 
   j <- grep( j[[length(j)]], names(x) )
   
if(!missing(i) && inherits(i, "formula")) 
   i <- grep( i[[length(i)]], if(Narg>=3) rownames(x) else names(x))  


I realize that there are also other places where this could be used, an
obvious one being `[<-.data.frame`, but i wanted to ask first if it can
be interesting, or if it is dangerous, confusing, 

Cheers,

Romain

PS: .. can also imagine to add a minus before the regex to drop
(rows|columns) instead of keeping them.

-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123

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

[Rd] graphic for the R profiler

[Romain Francois]

Hello all,

I just wanted to share a small perl script that generates a dot file 
from the result of the R profiler. The dot file can than be used to 
create a graphical display of the profiling.  You can save this file in 
the bin directory of your R installation and then create a graph, for 
example an SVG by piping the output of the script to dot:

$ R CMD Rprof2dot Rprof.out | dot -Tsvg > test3.svg

Some example graphics are presented in the R wiki here: 
http://wiki.r-project.org/rwiki/doku.php?id=tips:misc:profiling

Cheers,

Romain



#! /usr/bin/perl
 
use Getopt::Long;
 
my $cutoff=5;
GetOptions ('cutoff=s' => \$cutoff );
 
%calltree = ();
%allfun = ();
 
while (<>) {
  if (/^sample\.interval=/) {
s /sample\.interval=//;
$sample = $_ / 1e6;
  } else {
  chomp ;
  @line = reverse 
 split 
(/ /);
  
$caller = shift (@line);
$allfun{$caller}++;
while( $called = shift 
(@line) ){
  $allfun{$called}++;
  $calltree{$caller}{$called} ++ ;
  $caller = $called;
}

  }
}
 
print  "digraph {\n" ;
print  'graph [ rankdir = 
"LR"]; '."\n";
foreach $fun (keys  %allfun){
  $_ = $fun;
  s /"$//;
  $value = $allfun{$fun} ;
  print "$fun [shape=rect,fontsize=6,label=$_\\n(".$value.")\"] \n" if $value > 
($cutoff-1) ;
}
  
foreach $caller (keys  
%calltree){
  for $called ( keys  %{ 
$calltree{$caller} } ) {
$value = $calltree{$caller}{$called} ;
$n1 = $allfun{$called} ;
$n2 = $allfun{$caller} ;

print  " $caller -> 
$called [label=" . $value. ",fontsize=6]\n" if ( $value > $cutoff );

  }
}
print  "}\n



-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123

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

[Rd] graphic for the R profiler

[Romain Francois]

((resent without the generated links, thanks Dirk))

Hello all,

I just wanted to share a small perl script that generates a dot file
from the result of the R profiler. The dot file can than be used to
create a graphical display of the profiling.  You can save this file in
the bin directory of your R installation and then create a graph, for
example an SVG by piping the output of the script to dot:

$ R CMD Rprof2dot Rprof.out | dot -Tsvg > test3.svg

Some example graphics are presented in the R wiki here:
http://wiki.r-project.org/rwiki/doku.php?id=tips:misc:profiling

Cheers,

Romain


#! /usr/bin/perl

use Getopt::Long;

my $cutoff=5;
GetOptions ('cutoff=s' => \$cutoff );

%calltree = ();
%allfun = ();

while (<>) {
   if (/^sample\.interval=/) {
s/sample\.interval=//;
$sample = $_ / 1e6;
   } else {
  chomp;
  @line = reverse split(/ /);

 $caller = shift(@line);
 $allfun{$caller}++;
 while( $called = shift(@line) ){
   $allfun{$called}++;
   $calltree{$caller}{$called} ++ ;
   $caller = $called;
 }

   }
}

print "digraph {\n" ;
print 'graph [ rankdir = "LR"]; '."\n";
foreach $fun (keys %allfun){
   $_ = $fun;
   s/"$//;
   $value = $allfun{$fun} ;
   print "$fun [shape=rect,fontsize=6,label=$_\\n(".$value.")\"] \n" if 
$value > ($cutoff-1) ;
}

foreach $caller (keys %calltree){
   for $called ( keys %{ $calltree{$caller} } ) {
 $value = $calltree{$caller}{$called} ;
 $n1 = $allfun{$called} ;
 $n2 = $allfun{$caller} ;

 print " $caller -> $called [label=" . $value. ",fontsize=6]\n" if ( 
$value > $cutoff );
   }
}
print "}\n"




-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123

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

Re: [Rd] SWF animation method

[Romain Francois]

Hello Mike,

You might want to give "mencoder" a try. It usually comes with mplayer. 
I did play with it a while ago and was fairly happy with the results.
Basically, the idea was to create many jpg files somewhere, which is not 
too hard using the %03d substitution described in ?jpeg.
The rest is described here: 
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-enc-images.html

Cheers,

Romain

PS: You might find some links in this (not really maintained) webpage: 
http://addictedtor.free.fr/movies/

Mike Lawrence wrote:
> Hi all,
>
> Just thought I'd share something I discovered last night. I was 
> interested in creating animations consisting of a series of plots and 
> after finding very little in the usual sources regarding animation in 
> R directly, and disliking the imagemagick method described 
> here(http://tolstoy.newcastle.edu.au/R/help/05/10/13297.html), I 
> discovered that if one exports the plots to a multipage pdf, it is 
> relatively trivial to then use the pdf2swf command in SWFTools 
> (http://www.swftools.org/download.html; mac install instructions here: 
> http://9mmedia.com/blog/?p=7).
>
> pdf2swf seems to generate swf animations with a slow frame rate, but 
> you can increase the framerate using 'swfcombine -r 30 --dummy 
> myslow.swf -o myfast.swf', where the value passed to -r is the framerate.
>
> Unfortunately, this method seems to have limitations with regards to 
> the number of plots it can convert. For example, on my system (17" 
> macbook pro, 2.33GHz, 2GB ram, OSX 10.4.10, R 2.5.1) the maximum 
> number of single point plots I can do is about 5400 (i.e. for(i in 
> 1:5400) plot(runif(1),ylim=c(0,1)) ). Complexity of the plots might 
> matter as well, but I only have rather convoluted examples of this. 
> Also, pdf2swf throws up a lot of errors ('ERROR   Internal error: 
> drawChar.render!=beginString.render'), the origin of which I know not, 
> that might be slowing things down.
>
> Now, if only someone could wrap this process into a single R command 
> (I'm a little too newb to do this myself I think).
>
> Mike
>
> -- 
> Mike Lawrence
> Graduate Student, Department of Psychology, Dalhousie University
>
> Website: http://memetic.ca
>
> Public calendar: http://icalx.com/public/informavore/Public
>
> "The road to wisdom? Well, it's plain and simple to express:
> Err and err and err again, but less and less and less."
> - Piet Hein
>
>
>


-- 
Mango Solutions
data analysis that delivers

Tel:  +44(0) 1249 467 467
Fax:  +44(0) 1249 467 468
Mob:  +44(0) 7813 526 123

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

[Rd] [SoC09-Idea] Integrated debugger

[Romain Francois]

Hello,

Hello,

Here is an idea for a google summer of code project I am willing to mentor.

Romain


Summary: Create an integrated debugger.

Required skills: R skills. Experience of using a debugger. Front-end 
skills depending on the chosen front-end(s).


Description: Debugging R code usually involves a lot of work from the
command line with the use of functions such as browser, debug, trace, 
recover. The debug package provides additional debugging functionalities 
and concepts to R internal debugging capabilities: code display, 
graceful error recovery, line-numbered conditional breakpoints,

access to exit code, flow control, and full keyboard input.

The current front-end used by the debug package is based on tcltk, and
although tcltk offers universal portability wherever R is installed, it 
does not compete with current alternatives in terms of user-experience.


The goal of this project is to create an integrated debugger for R,
based on the debug package but coupled with another front-end. Possible
front-ends are listed below, ordered by current experience of the mentor.

- biocep [java,swing] : http://biocep-distrib.r-forge.r-project.org/
- sciviews-k [mozilla,javascript] 
http://www.sciviews.org/SciViews-K/index.html

- statet [java,eclipse,swt]: http://www.walware.de/goto/statet

If you are interested in the project: I you are coming
from an R standpoint, have a look at the debug package and make a few 
design suggestions about how the package could be modified to support 
alternative front-ends. If you come from a front-end standpoint,

make a few suggestions on how you would present the information.


--
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] Why does the lexical analyzer drop comments ?

[romain . francois]

It happens in the token function in gram.c: 

    c = SkipSpace();
    if (c == '#') c = SkipComment();

and then SkipComment goes like that: 

static int SkipComment(void)
{
    int c;
    while ((c = xxgetc()) != '\n' && c != R_EOF) ;
    if (c == R_EOF) EndOfFile = 2;
    return c;
}

which effectively drops comments.

Would it be possible to keep the information somewhere ? 

The source code says this: 

 *  The function yylex() scans the input, breaking it into
 *  tokens which are then passed to the parser.  The lexical
 *  analyser maintains a symbol table (in a very messy fashion).

so my question is could we use this symbol table to keep track of, say, COMMENT 
tokens. 

Why would I even care about that ? I'm writing a package that will
perform syntax highlighting of R source code based on the output of the
parser, and it seems a waste to drop the comments. 

An also, when you print a function to the R console, you don't get the 
comments, and some of them might be useful to the user.

Am I mad if I contemplate looking into this ? 

Romain

-- 
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr




[[alternative HTML version deleted]]

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

Re: [Rd] Why does the lexical analyzer drop comments ?

[Romain Francois]

Peter Dalgaard wrote:

Duncan Murdoch wrote:

On 3/20/2009 2:56 PM, romain.franc...@dbmail.com wrote:

It happens in the token function in gram.c:
    c = SkipSpace();
    if (c == '#') c = SkipComment();

and then SkipComment goes like that:
static int SkipComment(void)
{
    int c;
    while ((c = xxgetc()) != '\n' && c != R_EOF) ;
    if (c == R_EOF) EndOfFile = 2;
    return c;
}

which effectively drops comments.

Would it be possible to keep the information somewhere ?
The source code says this:
 *  The function yylex() scans the input, breaking it into
 *  tokens which are then passed to the parser.  The lexical
 *  analyser maintains a symbol table (in a very messy fashion).

so my question is could we use this symbol table to keep track of, 
say, COMMENT tokens.

Why would I even care about that ? I'm writing a package that will
perform syntax highlighting of R source code based on the output of the
parser, and it seems a waste to drop the comments.
An also, when you print a function to the R console, you don't get 
the comments, and some of them might be useful to the user.


Am I mad if I contemplate looking into this ? 


Comments are syntactically the same as whitespace.  You don't want 
them to affect the parsing.


Well, you might, but there is quite some madness lying that way.

Back in the bronze age, we did actually try to keep comments attached 
to (AFAIR) the preceding token. One problem is that the elements of 
the parse tree typically involve multiple tokens, and if comments 
after different tokens get stored in the same place something is not 
going back where it came from when deparsing. So we had problems with 
comments moving from one end of a loop the other and the like.

Ouch. That helps picturing the kind of madness ...

Another way could be to record comments separately (similarly to srcfile 
attribute for example) instead of dropping them entirely, but I guess 
this is the same as Duncan's idea, which is easier to set up.


You could try extending the scheme by encoding which part of a 
syntactic structure the comment belongs to, but consider for instance 
how many places in a function call you can stick in a comment.


f #here
( #here
a #here (possibly)
= #here
1 #this one belongs to the argument, though
) #but here as well



If you're doing syntax highlighting, you can determine the whitespace by
looking at the srcref records, and then parse that to determine what 
isn't being counted as tokens.  (I think you'll find a few things 
there besides whitespace, but it is a fairly limited set, so 
shouldn't be too hard to recognize.)


The Rd parser is different, because in an Rd file, whitespace is 
significant, so it gets kept.


Duncan Murdoch

__
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

[Rd] throwing a "condition" when the current working directory changes

[Romain Francois]

Hi,

Would it make sense to throw a condition when the working directory 
changes, so that interested parties (such as guis can act based on the 
change using an appropriate calling handler), and not interested parties 
can just ignore it.


For example, something like this:

setwd <- function (dir) {
  out <- .Internal(setwd(dir))
  setwdCondition <- simpleCondition( paste( "setwd: ", dir)  )
  class( setwdCondition ) <- c("setwd", "condition" )
  setwdCondition$dir <- dir
  signalCondition( setwdCondition )
  invisible( out )
}

which could handled like this to have your prompt responding to changes 
of current directory:


withCallingHandlers( f()  , setwd = function(e) options( prompt = 
sprintf( "[%s]> ", e$dir )  )   )


Beyond the simple example, would it make sense to define a set of 
condition or events, or is this abusing the concept of conditions and 
something else should be used ? hooks ?


Also, is there a way to "register" a calling handler so that it listens 
to every top-level command. Something like options( "error") but for 
handling other kinds of conditions ?


Romain

--
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] Why does the lexical analyzer drop comments ?

[Romain Francois]

Romain Francois wrote:

Peter Dalgaard wrote:

Duncan Murdoch wrote:

On 3/20/2009 2:56 PM, romain.franc...@dbmail.com wrote:

It happens in the token function in gram.c:
    c = SkipSpace();
    if (c == '#') c = SkipComment();

and then SkipComment goes like that:
static int SkipComment(void)
{
    int c;
    while ((c = xxgetc()) != '\n' && c != R_EOF) ;
    if (c == R_EOF) EndOfFile = 2;
    return c;
}

which effectively drops comments.

Would it be possible to keep the information somewhere ?
The source code says this:
 *  The function yylex() scans the input, breaking it into
 *  tokens which are then passed to the parser.  The lexical
 *  analyser maintains a symbol table (in a very messy fashion).

so my question is could we use this symbol table to keep track of, 
say, COMMENT tokens.

Why would I even care about that ? I'm writing a package that will
perform syntax highlighting of R source code based on the output of 
the

parser, and it seems a waste to drop the comments.
An also, when you print a function to the R console, you don't get 
the comments, and some of them might be useful to the user.


Am I mad if I contemplate looking into this ? 


Comments are syntactically the same as whitespace.  You don't want 
them to affect the parsing.


Well, you might, but there is quite some madness lying that way.

Back in the bronze age, we did actually try to keep comments attached 
to (AFAIR) the preceding token. One problem is that the elements of 
the parse tree typically involve multiple tokens, and if comments 
after different tokens get stored in the same place something is not 
going back where it came from when deparsing. So we had problems with 
comments moving from one end of a loop the other and the like.

Ouch. That helps picturing the kind of madness ...

Another way could be to record comments separately (similarly to 
srcfile attribute for example) instead of dropping them entirely, but 
I guess this is the same as Duncan's idea, which is easier to set up.


You could try extending the scheme by encoding which part of a 
syntactic structure the comment belongs to, but consider for instance 
how many places in a function call you can stick in a comment.


f #here
( #here
a #here (possibly)
= #here
1 #this one belongs to the argument, though
) #but here as well

Coming back on this. I actually get two expressions:

> p <- parse( "/tmp/parsing.R")
> str( p )
length 2 expression(f, (a = 1))
- attr(*, "srcref")=List of 2
 ..$ :Class 'srcref'  atomic [1:6] 1 1 1 1 1 1
 .. .. ..- attr(*, "srcfile")=Class 'srcfile' 
 ..$ :Class 'srcref'  atomic [1:6] 2 1 6 1 1 1
 .. .. ..- attr(*, "srcfile")=Class 'srcfile' 
- attr(*, "srcfile")=Class 'srcfile' 

But anyway, if I drop the first comment, then I get one expression with 
some srcref information:


> p <- parse( "/tmp/parsing.R")
> str( p )
length 1 expression(f(a = 1))
- attr(*, "srcref")=List of 1
 ..$ :Class 'srcref'  atomic [1:6] 1 1 5 1 1 1
 .. .. ..- attr(*, "srcfile")=Class 'srcfile' 
- attr(*, "srcfile")=Class 'srcfile' 

but as far as i can see, there is only srcref information for that 
expression as a whole, it does not go beyond, so I am not sure I can 
implement Duncan's proposal without more detailed information from the 
parser, since I will only have the chance to check if a whitespace is 
actually a comment if it is between two expressions with a srcref.


Would it be sensible then to retain the comments and their srcref 
information, but separate from the tokens used for the actual parsing, 
in some other attribute of the output of parse ?


Romain



If you're doing syntax highlighting, you can determine the 
whitespace by
looking at the srcref records, and then parse that to determine what 
isn't being counted as tokens.  (I think you'll find a few things 
there besides whitespace, but it is a fairly limited set, so 
shouldn't be too hard to recognize.)


The Rd parser is different, because in an Rd file, whitespace is 
significant, so it gets kept.


Duncan Murdoch

__
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] Why does the lexical analyzer drop comments ?

[Romain Francois]

Duncan Murdoch wrote:

On 22/03/2009 4:50 PM, Romain Francois wrote:

Romain Francois wrote:

Peter Dalgaard wrote:

Duncan Murdoch wrote:

On 3/20/2009 2:56 PM, romain.franc...@dbmail.com wrote:

It happens in the token function in gram.c:
    c = SkipSpace();
    if (c == '#') c = SkipComment();

and then SkipComment goes like that:
static int SkipComment(void)
{
    int c;
    while ((c = xxgetc()) != '\n' && c != R_EOF) ;
    if (c == R_EOF) EndOfFile = 2;
    return c;
}

which effectively drops comments.

Would it be possible to keep the information somewhere ?
The source code says this:
 *  The function yylex() scans the input, breaking it into
 *  tokens which are then passed to the parser.  The lexical
 *  analyser maintains a symbol table (in a very messy fashion).

so my question is could we use this symbol table to keep track 
of, say, COMMENT tokens.

Why would I even care about that ? I'm writing a package that will
perform syntax highlighting of R source code based on the output 
of the

parser, and it seems a waste to drop the comments.
An also, when you print a function to the R console, you don't 
get the comments, and some of them might be useful to the user.


Am I mad if I contemplate looking into this ? 
Comments are syntactically the same as whitespace.  You don't want 
them to affect the parsing.

Well, you might, but there is quite some madness lying that way.

Back in the bronze age, we did actually try to keep comments 
attached to (AFAIR) the preceding token. One problem is that the 
elements of the parse tree typically involve multiple tokens, and 
if comments after different tokens get stored in the same place 
something is not going back where it came from when deparsing. So 
we had problems with comments moving from one end of a loop the 
other and the like.

Ouch. That helps picturing the kind of madness ...

Another way could be to record comments separately (similarly to 
srcfile attribute for example) instead of dropping them entirely, 
but I guess this is the same as Duncan's idea, which is easier to 
set up.


You could try extending the scheme by encoding which part of a 
syntactic structure the comment belongs to, but consider for 
instance how many places in a function call you can stick in a 
comment.


f #here
( #here
a #here (possibly)
= #here
1 #this one belongs to the argument, though
) #but here as well

Coming back on this. I actually get two expressions:

 > p <- parse( "/tmp/parsing.R")
 > str( p )
length 2 expression(f, (a = 1))
 - attr(*, "srcref")=List of 2
  ..$ :Class 'srcref'  atomic [1:6] 1 1 1 1 1 1
  .. .. ..- attr(*, "srcfile")=Class 'srcfile' 
  ..$ :Class 'srcref'  atomic [1:6] 2 1 6 1 1 1
  .. .. ..- attr(*, "srcfile")=Class 'srcfile' 
 - attr(*, "srcfile")=Class 'srcfile' 

But anyway, if I drop the first comment, then I get one expression 
with some srcref information:


 > p <- parse( "/tmp/parsing.R")
 > str( p )
length 1 expression(f(a = 1))
 - attr(*, "srcref")=List of 1
  ..$ :Class 'srcref'  atomic [1:6] 1 1 5 1 1 1
  .. .. ..- attr(*, "srcfile")=Class 'srcfile' 
 - attr(*, "srcfile")=Class 'srcfile' 

but as far as i can see, there is only srcref information for that 
expression as a whole, it does not go beyond, so I am not sure I can 
implement Duncan's proposal without more detailed information from 
the parser, since I will only have the chance to check if a 
whitespace is actually a comment if it is between two expressions 
with a srcref.


Currently srcrefs are only attached to whole statements.  Since your 
source only included one or two statements, you only get one or two 
srcrefs.  It would not be hard to attach a srcref to every 
subexpression; there hasn't been a need for that before, so I didn't 
do it just for the sake of efficiency.


I understand that. I wanted to make sure I did not miss something.

However, it might make sense for you to have your own parser, based on 
the grammar in R's parser, but handling white space differently. 
Certainly it would make sense to do that before making changes to the 
base R one.  The whole source is in src/main/gram.y; if you're not 
familiar with Bison, I can give you a hand.


Thank you, I appreciate your help. Having my own parser is the option I 
am slowly converging to.
I'll start with reading bison documentation. Besides bison documents, is 
there R specific documentation on how the R parser was written ?




Duncan Murdoch



Would it be sensible then to retain the comments and their srcref 
information, but separate from the tokens used for the actual 
parsing, in some other attribute of the output of parse ?


Romain

If you're doing syntax highlighting, you can determine th

Re: [Rd] [R] "[.data.frame" and lapply

[Romain Francois]

[moving this from R-help to R-devel]

Hi,

Right, so when you call `[`, the dispatch is made internally :

> d <- data.frame( x = 1:5, y = rnorm(5), z = rnorm(5) )
> trace( `[.data.frame` )
> d[ , 1:2]   # ensuring the 1:2 is passed to j and the i is passed as 
missing

Tracing `[.data.frame`(d, , 1:2) on entry
 x   y
1 1  0.98946922
2 2  0.05323895
3 3 -0.21803664
4 4 -0.47607043
5 5  1.23366151

> d[ 1:2] # only on argument, so it goes in i
Tracing `[.data.frame`(d, 1:2) on entry
 x   y
1 1  0.98946922
2 2  0.05323895
3 3 -0.21803664
4 4 -0.47607043
5 5  1.23366151

But that does not explain why this is hapening:

> d[ i = 1:2]
Tracing `[.data.frame`(d, i = 1:2) on entry
 x   y
1 1  0.98946922
2 2  0.05323895
3 3 -0.21803664
4 4 -0.47607043
5 5  1.23366151

> d[ j = 1:2]
Tracing `[.data.frame`(d, j = 1:2) on entry
 x   y  z
1 1  0.98946922 -0.5233134
2 2  0.05323895  1.3646683
3 3 -0.21803664 -0.4998344
4 4 -0.47607043 -1.8849618
5 5  1.23366151  0.6723562

Arguments are dispatched to `[.data.frame` with their names, and 
`[.data.frame` gets confused. I'm not suggesting allowing named 
arguments because it already works, what does not work is how 
`[.data.frame` treats them, and that needs to be changed, this is a bug.


Romain

> version
  _
platform   i686-pc-linux-gnu
arch   i686
os linux-gnu
system i686, linux-gnu
status Under development (unstable)
major  2
minor  9.0
year   2009
month  03
day09
svn rev48093
language   R
version.string R version 2.9.0 Under development (unstable) (2009-03-09 
r48093)





baptiste auguie wrote:

Hi,

I got an off-line clarification from Martin Morgan which makes me 
believe it's not a bug (admittedly, I was close to suggesting it before).


Basically, "[" is a .Primitive, for which the help page says,


The advantage of |.Primitive| over |.Internal 
| functions 
is the potential efficiency of argument passing. However, this is 
done by ignoring argument names and using positional matching of 
arguments (unless arranged differently for specific primitives such 
as |rep 
|), 
so this is discouraged for functions of more than one argument.


This explains why in my tests the argument names i and j were 
completely ignored and only the number and order of arguments changed 
the result. 

I've learnt my lesson here, but I wonder what could be done to make 
this discovery easier for others:


- add a note in the documentation of each .Primitive function (at 
least a link to ?.Primitive)


- add such an example in lapply (all examples are for named arguments)

- echo a warning if trying to pass named arguments to a .Primitive

- allow for named arguments as you suggest

I'm not sure the last two would be possible without some cost in 
efficiency.



Many thanks,

baptiste




On 26 Mar 2009, at 07:46, Romain Francois wrote:



Hi,

This is a bug I think. [.data.frame treats its arguments differently
depending on the number of arguments.


d <- data.frame(x = rnorm(5), y = rnorm(5), z = rnorm(5) )
d[, 1:2]

x   y
1   0.45141341  0.03943654
2  -0.87954548  1.83690210
3  -0.91083710  0.22758584
4   0.06924279  1.26799176
5  -0.20477052 -0.25873225

base:::`[.data.frame`( d, j=1:2)

x   y  z
1   0.45141341  0.03943654 -0.8971957
2  -0.87954548  1.83690210  0.9083281
3  -0.91083710  0.22758584 -0.3104906
4   0.06924279  1.26799176  1.2625699
5  -0.20477052 -0.25873225  0.5228342
but also:

d[ j=1:2]

   x   y  z
1  0.45141341  0.03943654 -0.8971957
2 -0.87954548  1.83690210  0.9083281
3 -0.91083710  0.22758584 -0.3104906
4  0.06924279  1.26799176  1.2625699
5 -0.20477052 -0.25873225  0.5228342

`[.data.frame` only is called with two arguments in the second case, so
the following condition is true:

if(Narg < 3L) {  # list-like indexing or matrix indexing

And then, the function assumes the argument it has been passed is i, and
eventually calls NextMethod("[") which I think calls
`[.listof`(x,i,...), since i is missing in `[.data.frame` it is not
passed to `[.listof`, so you have something equivalent to as.list(d)[].

I think we can replace the condition with this one:

if(Narg < 3L && !has.j) {  # list-like indexing or matrix indexing

or this:

if(Narg < 3L) {  # list-like indexing or matrix indexing
   if(has.j) i <- j


`[.data.frame`(d, j=1:2)

   x   y
1  0.45141341  0.03943654
2 -0.87954548  1.83690210
3 -0.91083710  0.22758584
4  0.06924279  1.26799176
5 -0.20477052 -0.25873225

However, we would still have this, which is expected (same as d[1:2] ):


`[.data.frame`(d, i=1:2)

   x   y
1  0.45141341  0.03943654
2 -0.87954548  1.83690210
3 -0.91083710  0.22758584
4  0.06924279  1.26799176
5 -0.20477052 -0.25873225

Romain

baptist

Re: [Rd] [R] "[.data.frame" and lapply

[Romain Francois]

Wacek Kusnierczyk wrote:

redirected to r-devel, because there are implementational details of
[.data.frame discussed here.  spoiler: at the bottom there is a fairly
interesting performance result.

Romain Francois wrote:
  

Hi,

This is a bug I think. [.data.frame treats its arguments differently
depending on the number of arguments.



you might want to hesitate a bit before you say that something in r is a
bug, if only because it drives certain people mad.  r is a carefully
tested software, and [.data.frame is such a basic function that if what
you talk about were a bug, it wouldn't have persisted until now.
  
I did hesitate, and would be prepared to look the other way of someone 
shows me proper evidence that this makes sense.


> d <- data.frame( x = 1:10, y = 1:10, z = 1:10 )
> d[ j=1 ]
   x  y  z
1   1  1  1
2   2  2  2
3   3  3  3
4   4  4  4
5   5  5  5
6   6  6  6
7   7  7  7
8   8  8  8
9   9  9  9
10 10 10 10

"If a single index is supplied, it is interpreted as indexing the list 
of columns". Clearly this does not happen here, and this is because 
NextMethod gets confused.


I have not looked your implementation in details, but it misses array 
indexing, as in:


> d <- data.frame( x = 1:10, y = 1:10, z = 1:10 )
> m <- cbind( 5:7, 1:3 )
> m
[,1] [,2]
[1,]51
[2,]62
[3,]73
> d[m]
[1] 5 6 7
> subdf( d, m )
Error in subdf(d, m) : undefined columns selected

"Matrix indexing using '[' is not recommended, and barely
supported.  For extraction, 'x' is first coerced to a matrix. For
replacement a logical matrix (only) can be used to select the
elements to be replaced in the same way as for a matrix."

You might also want to look at `[<-.data.frame`.

> d[j=2] <- 1:10
Error in `[<-.data.frame`(`*tmp*`, j = 2, value = 1:10) :
 element 1 is empty;
  the part of the args list of 'is.logical' being evaluated was:
  (i)
> d[2] <- 10:1
> d
   x  y  z
1   1 10  1
2   2  9  2
3   3  8  3
4   4  7  4
5   5  6  5
6   6  5  6
7   7  4  7
8   8  3  8
9   9  2  9
10 10  1 10

This is probably less of an issue, because there is very little chance 
for people to use this construct, but for the first one, if not used 
directly, it still has good chances to be used within some fooapply 
call, as in the original post. Although it might have been preferable to 
use subset as the applied function.


Romain

treating the arguments differently depending on their number is actually
(if clearly...) documented:  if there is one index (the 'i'), it selects
columns.  if there are two, 'i' selects rows.

however, not all seems fine, there might be a design flaw:

# dummy data frame
d = structure(names=paste('col', 1:3, sep='.'),
data.frame(row.names=paste('row', 1:3, sep='.'),
   matrix(1:9, 3, 3)))

d[1:2]
# correctly selects two first columns
# 1:2 passed to [.data.frame as i, no j given

d[,1:2]
# correctly selects two first columns
# 1:2 passed to [.data.frame as j, i given the missing argument
value (note the comma)

d[,i=1:2]
# correctly selects two first rows
# 1:2 passed to [.data.frame as i, j given the missing argument
value (note the comma)

d[j=1:2,]
# correctly selects two first columns
# 1:2 passed to [.data.frame as j, i given the missing argument
value (note the comma)

d[i=1:2]
# correctly (arguably) selects the first two columns
# 1:2 passed to [.data.frame as i, no j given
  
d[j=1:2]

# wrong: returns the whole data frame
# does not recognize the index as i because it is explicitly named 'j'
# does not recognize the index as j because there is only one index

i say this *might* be a design flaw because it's hard to judge what the
design really is.  the r language definition (!) [1, sec. 3.4.3 p. 18] says:

"   The most important example of a class method for [ is that used for
data frames. It is not
be described in detail here (see the help page for [.data.frame, but in
broad terms, if two
indices are supplied (even if one is empty) it creates matrix-like
indexing for a structure that is
basically a list of vectors of the same length. If a single index is
supplied, it is interpreted as
indexing the list of columns—in that case the drop argument is ignored,
with a warning."

it does not say what happens when only one *named* index argument is
given.  from the above, it would indeed seem that there is a *bug*
here:  in the last example above only one index is given, and yet
columns are not selected, even though the *language definition* says
they should.  (so it's not a documented feature, it's a
contra-definitional misfeature -- a bug?)

somewhat on the side, the 'matrix-like indexing' above is fairly
misleading;  just try the same patterns of indexing -- one

Re: [Rd] Why does the lexical analyzer drop comments ?

[Romain Francois]

7 *
i/360)
# pause for a while
Sys.sleep(0.01)
}

Of course this function has some limitations: it does not support
inline comments or comments which are inside incomplete code lines.
Peter's example

f #here
( #here
a #here (possibly)
= #here
1 #this one belongs to the argument, though
) #but here as well

will be parsed as

f
(a = 1)

I'm quite interested in syntax highlighting of R code and saw your
previous discussions in another posts (with Jose Quesada, etc). I'd
like to do something for your package if I could be of some help.

Regards,
Yihui
--
Yihui Xie 
Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
Mobile: +86-15810805877
Homepage: http://www.yihui.name
School of Statistics, Room 1037, Mingde Main Building,
Renmin University of China, Beijing, 100872, China



2009/3/21  :
  

It happens in the token function in gram.c:

    c = SkipSpace();
    if (c == '#') c = SkipComment();

and then SkipComment goes like that:

static int SkipComment(void)
{
    int c;
    while ((c = xxgetc()) != '\n' && c != R_EOF) ;
    if (c == R_EOF) EndOfFile = 2;
    return c;
}

which effectively drops comments.

Would it be possible to keep the information somewhere ?

The source code says this:

 *  The function yylex() scans the input, breaking it into
 *  tokens which are then passed to the parser.  The lexical
 *  analyser maintains a symbol table (in a very messy fashion).

so my question is could we use this symbol table to keep track of, say, COMMENT 
tokens.

Why would I even care about that ? I'm writing a package that will
perform syntax highlighting of R source code based on the output of the
parser, and it seems a waste to drop the comments.

An also, when you print a function to the R console, you don't get the 
comments, and some of them might be useful to the user.

Am I mad if I contemplate looking into this ?

Romain

--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr





  



--
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] Why does the lexical analyzer drop comments ?

[Romain Francois]

hadley wickham wrote:

At the moment, I am concentrating efforts deep down in the parser code, but
there are other challenges:
- once the expressions are parsed, we will need something that investigates
to find evidence about function calls, to get an idea of where the function
is defined (by the user, in a package, ...) . This is tricky, and unless you
actually evaluate the code, there will be some errors made.



Are you aware of Luke Tierney's codetools package?  That would seem to
be the place to start.
  
Yep. Plan to combine the more verbose information out of the modified 
parser with the same guess machine that checkUsage uses.
Another side effect is that we could imagine to link error patterns 
identified by checkUsage (no visible binding for global variable "y", 
...) to actual locations on the file (for example the place where the 
variable y is used in that case ), which at the moment is not possible 
because the parser only locates entire expression (semantic groupings) 
and not tokens.


> f <- function( x = 2) {
+ y + 2
+ }
> checkUsage( f )
: no visible binding for global variable ‘y’


Hadley

  



--
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] top level condition handlers

[Romain Francois]

Hello,

I would like to establish top level condition handlers and restarts, so 
that I don't explicit calls to withCallingHandlers and withRestarts in 
many places:


For example :

> customError
function( message ){
 err <- simpleError( message )
 class( err ) <- c( "customError", class( err) )
  err
}
> withCallingHandlers( { signalCondition(customError( "ouch")) } , 
customError = function(e) cat( "gotcha : ", e$message, "\n" ) )

gotcha :  ouch
NULL

I'd like to be able to do something like this:

> topLevelCallingHandlers( customError = function(e) cat( "gotcha : ", 
e$message, "\n" ) )

> signalCondition( customError( "ouch") )

and the "customError" condition to be caught by the handler I set up 
previously.


I tried modifying withCallingHandlers like this:

topLevelCallingHandlers <- function(...) {
   handlers <- list(...)
   classes <- names(handlers)
   if (length(classes) != length(handlers))
   stop("bad handler specification")
   .Internal(.addCondHands(classes, handlers, .GlobalEnv, .GlobalEnv, 
TRUE))

   invisible( NULL )
}
> withCallingHandlers
function (expr, ...)
{
   handlers <- list(...)
   classes <- names(handlers)
   parentenv <- parent.frame()
   if (length(classes) != length(handlers))
   stop("bad handler specification")
   .Internal(.addCondHands(classes, handlers, parentenv, NULL,
   TRUE))
   expr
}


but it does not work, probably because the handler stack is reset 
somewhere.


Would it work if I poke into the RTopLevel.handlerstack instead of the 
R_HandlerStack as .addCondHands is doing ?


R_Toplevel.handlerstack = R_HandlerStack;
R_Toplevel.restartstack = R_RestartStack;
R_GlobalContext = R_ToplevelContext = &R_Toplevel;

Romain

--
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] HTML help

[Romain Francois]

Hi,

if the system that builds the html help page is latex capable, then it 
would not be too difficult to use the same trick wikipedia is using 
(generating a png file for each equation). Translating latex style 
markup into mathml is another game, see this: 
http://www1.chapman.edu/~jipsen/mathml/asciimath.html for example.


Romain

mnorton52 wrote:

Hi Jack,

I'm not sure about the  tag either, and it didn't work when I tried
it.  I think the approach this web page uses may help in writing
mathematical symbols to HTML:

http://comers.citadel.edu/math_sym2005.htm

Cheers,
Mike


Jack (Zhan, Hua Ping) wrote:
  

HTML help is not right for math formula:
For example:
I got the following formula in help page of ca.jo in urca package:

X_t = Pi_1 X_{t-1} + ... + Pi_k
X_{t-k} + μ + Phi D_t + varepsilon_t
, quad (t = 1, ..., T),


This presentation is just not good, however, in most browser,
with tag , the formula in the tag works well.
such as in wikipedia. please check the same formula:
http://en.wikipedia.org/wiki/Johansen_test

--
with best regards
Jack (Zhan, Hua Ping)
+1-514-8800518



--
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] suggestion for R >= 3.0: computer-readable CHANGELOG

[Romain Francois]

Philippe Grosjean wrote:

Hello,

Here are a few questions that would be useful to get an answer via 
dedicated functions in utils or tools packages:

- When did function foo appeared in R or in a given package?
- When did argument myarg appeared in function foo?
- When did function bar get deprecated or when did it disappeared?
- I wrote a script using functions foo and bar with R 1.9.1. My script 
does not work any more with current version. What were all the changes 
made to foo and/or to bar since then (this could obviously help me to 
update my script for current R version)?


Currently, we have to read NEWS (or perhaps a non official changelog) 
manually to get such answers.


Hi,

I agree with the usefulness of having this available, but there is 
absolutely no way people are going to log such information in a 
systematic fashion. In the other hand, if you have version 1 and version 
2 of some package, then why not do some programmatic investigation of 
the code to get (some of) these answers.


This looks like CRANberries, but working at the object level instead of 
working at the file level, but then you can imagine to parse the 
package, dump each function/object/class in its own file, and cranberry 
that. Is CRANberry an R package ?


Romain

The basic function to retrieve data that would answer to these 
questions would be something like:


> changes(c("foo", "bar"))

That function could, for instance, read information in a 
computer-readable file named CHANGELOG... because the problem is 
there! Changes are currently recorded in NEWS, but ONLY in a 
human-readable form! A quick suggestion for a format for CHANGELOG by 
example:


Date   Object   Action  Value   Message
2009-04-17 package  commit  1.1-0   Enhanced version of my package
2009-04-15 foo  add foo(y)  New function foo in my package
2009-04-14 bar  debug   bar(NULL) returned wrong result
2009-04-01 package  commit  1.0-0   First version of package on CRAN

It should be kept simple. May be an "Author" field in the records 
would be nice too. Also a function to record a new entry in the 
CHANGELOG could look like:


> track("XXX", action = "debug", message = "my comment", file = 
"/somewhere/CHANGELOG")


The file NEWS would not change and should be kept to present the same 
information in a human-readable format.


Also, a function that lists all functions used in a script or a 
package (Romain François is working in this direction with svTools 
package), plus a function to plot one or several "changes" objects as 
returned by changes() on a time axis or "version axis" would be 
welcome additions to further track and plot evolution of R, or of R 
packages for a group of functions of interest. Finally, a function to 
easily record the dependences used and their versions in a script 
would complete the set of tools.


These 4-5 functions are not difficult to write (although I suspect 
that this simplistic proposal would become more complex if one 
consider to interact with subversion, to separate development and 
release versions, ...). But to be really useful, they should be better 
designed and proposed by the R core team, and included in the official 
specifications for writing package. May I suggest to think about such 
a change for R version 3.0?


Things get more complicated for verifying CHANGELOG in R CMD check. At 
least, one could check actions like:

- object or function addition, deprecation or disappearance,
- argument changes in functions, slot changes in objects,
- function refactoring (change in the code from previous version)
but only if we provide also the previous version of a package to R CMD 
check.


I would be happy to contribute, but the concept must certainly be 
further discussed and enhanced (here?), and then, accepted by the R 
core team before going any further.


All the best,

Philippe Grosjean



--
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] speedup for as.matrix.dist

[Romain Francois]

Hello,

I am trying to patch as.matrix.dist to achieve some speedup.

> m <- expand.grid( x = 1:20, y = 1:20, z = 1:20 )
> d <- dist( m )
> system.time( out <- stats:::as.matrix.dist( d ) )
  user  system elapsed
15.355   3.110  19.123
> system.time( out <- as.matrix.dist( d ) )
  user  system elapsed
 3.153   0.480   3.782

The code below works if I deploy it in an additional package, but not 
when I patch the "stats" package, I get that kind of message:

 C symbol name "as_matrix_dist" not in load table

Romain


as.matrix.dist <- function(x, ...) {
   size <- as.integer(attr(x, "Size"))
   if( !is.numeric(x) ){
   storage.mode(x) <- "numeric"
   }
   df <- .External( "as_matrix_dist",
   x = x, size = size, PACKAGE = "stats" )
   labels <- attr(x, "Labels")
   dimnames(df) <- if(is.null(labels)) list(1L:size,1L:size) else 
list(labels,labels)

   df
}



/**
* as.matrix.dist( d )
*/
SEXP as_matrix_dist(SEXP args){
  
   args = CDR( args ) ; SEXP x = CAR( args );

   args = CDR( args ) ; SEXP size = CAR( args );
  
   int i,j,k;

   int s = INTEGER(size)[0];
   SEXP d ;
   PROTECT( d = allocVector( REALSXP, s*s) );
   double element;
   for( i=0,k=0; ihttp://romainfrancois.blog.free.fr

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

[Rd] print.closure at the R level

[Romain Francois]

Hello,

Could the code that auto prints a function/closure be extracted from 
print.c so that there would be a print.closure function.
I would like to be able to mask a print.closure function so that I have 
a custom auto-print. One reason for that is I plan to have syntax 
highlighting within the R console.


Romain

--
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] print.closure at the R level

[Romain Francois]

Duncan Murdoch wrote:

On 18/04/2009 10:12 AM, Romain Francois wrote:

Hello,

Could the code that auto prints a function/closure be extracted from 
print.c so that there would be a print.closure function.
I would like to be able to mask a print.closure function so that I 
have a custom auto-print. One reason for that is I plan to have 
syntax highlighting within the R console.


The class of a closure is "function", so you'd want the method to be 
print.function.  Currently that doesn't work for auto printing, so 
your suggestion is still interesting.  (I'm not sure why auto printing 
is special here...)


Duncan Murdoch
Apparently, auto printing does not use the regular dispatch mechanism. 
See below:


I'll  make a more concrete proposal. This could be an opportunity to 
nail down as.character.function as well.


Romain

(from print.c)

*  print.default()  -> do_printdefault (with call tree below)
*
*  auto-printing   ->  PrintValueEnv
*  -> PrintValueRec
*  -> call print() for objects

and PrintValueRec switches on the typeof :

switch (TYPEOF(s)) {
...
   case CLOSXP:
   case LANGSXP:
   t = getAttrib(s, R_SourceSymbol);
   if (!isString(t) || !R_print.useSource)
   t = deparse1(s, 0, R_print.useSource | DEFAULTDEPARSE);
   for (i = 0; i < LENGTH(t); i++)
   Rprintf("%s\n", CHAR(STRING_ELT(t, i))); /* translated */
#ifdef BYTECODE
   if (TYPEOF(s) == CLOSXP && isByteCode(BODY(s)))
   Rprintf("\n", BODY(s));
#endif
   if (TYPEOF(s) == CLOSXP) {
   t = CLOENV(s);
   if (t != R_GlobalEnv)
   Rprintf("%s\n", EncodeEnvironment(t));
   }
   break;





--
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] print.closure at the R level

[Romain Francois]

Duncan Murdoch wrote:

On 18/04/2009 10:12 AM, Romain Francois wrote:

Hello,

Could the code that auto prints a function/closure be extracted from 
print.c so that there would be a print.closure function.
I would like to be able to mask a print.closure function so that I 
have a custom auto-print. One reason for that is I plan to have 
syntax highlighting within the R console.


The class of a closure is "function", so you'd want the method to be 
print.function.  Currently that doesn't work for auto printing, so 
your suggestion is still interesting.  (I'm not sure why auto printing 
is special here...)


Duncan Murdoch

The attached patch implements exposing the print.function at the R level.

Romain

--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr


Index: src/include/Internal.h
===
--- src/include/Internal.h	(revision 48350)
+++ src/include/Internal.h	(working copy)
@@ -370,6 +370,7 @@
 SEXP do_printdefault(SEXP, SEXP, SEXP, SEXP);
 SEXP do_printDeferredWarnings(SEXP, SEXP, SEXP, SEXP);
 SEXP do_printdf(SEXP, SEXP, SEXP, SEXP);
+SEXP do_printfunction(SEXP, SEXP, SEXP, SEXP);
 SEXP do_prmatrix(SEXP, SEXP, SEXP, SEXP);
 SEXP do_proctime(SEXP, SEXP, SEXP, SEXP);
 SEXP do_psort(SEXP, SEXP, SEXP, SEXP);
Index: src/library/base/R/print.R
===
--- src/library/base/R/print.R	(revision 48350)
+++ src/library/base/R/print.R	(working copy)
@@ -85,3 +85,8 @@
 print(noquote(cbind("_"=unlist(x))), ...)
 
 `[.simple.list` <- `[.listof`
+
+print.function <- function( x, useSource=TRUE, ...){
+	.Internal( print.function( x, useSource, ... ) )
+}
+
Index: src/main/names.c
===
--- src/main/names.c	(revision 48350)
+++ src/main/names.c	(working copy)
@@ -631,6 +631,7 @@
 {"readline",	do_readln,	0,	11,	1,	{PP_FUNCALL, PREC_FN,	0}},
 {"menu",	do_menu,	0,	11,	1,	{PP_FUNCALL, PREC_FN,	0}},
 {"print.default",do_printdefault,0,	111,	9,	{PP_FUNCALL, PREC_FN,	0}},
+{"print.function",do_printfunction,0,	111,	3,	{PP_FUNCALL, PREC_FN,	0}},
 {"prmatrix",	do_prmatrix,	0,	111,	6,	{PP_FUNCALL, PREC_FN,	0}},
 {"invisible",	do_invisible,	0,	101,	1,	{PP_FUNCALL, PREC_FN,	0}},
 {"gc",		do_gc,		0,	11,	2,	{PP_FUNCALL, PREC_FN,	0}},
Index: src/main/print.c
===
--- src/main/print.c	(revision 48350)
+++ src/main/print.c	(working copy)
@@ -154,6 +154,34 @@
 return x;
 }/* do_prmatrix */
 
+
+/* .Internal( print.function( f,useSource,... ) ) */
+SEXP attribute_hidden do_printfunction( SEXP call, SEXP op, SEXP args, SEXP rho){
+	SEXP s,t;
+	Rboolean useSource = TRUE; 
+	s=CAR(args);
+	args = CDR(args);	useSource=asLogical(CAR(args));
+	
+	int i;
+	if( ! (TYPEOF(s) == CLOSXP || TYPEOF(s) == LANGSXP ) ) return R_NilValue;
+	t = getAttrib(s, R_SourceSymbol);
+	if (!isString(t) || !useSource)
+	t = deparse1(s, 0, useSource | DEFAULTDEPARSE);
+	for (i = 0; i < LENGTH(t); i++)
+	Rprintf("%s\n", CHAR(STRING_ELT(t, i))); /* translated */
+#ifdef BYTECODE
+	if (TYPEOF(s) == CLOSXP && isByteCode(BODY(s)))
+	Rprintf("\n", BODY(s));
+#endif
+	if (TYPEOF(s) == CLOSXP) {
+	t = CLOENV(s);
+	if (t != R_GlobalEnv)
+		Rprintf("%s\n", EncodeEnvironment(t));
+	}
+	return R_NilValue;
+}
+
+
 /* .Internal(print.default(x, digits, quote, na.print, print.gap,
 			   right, max, useS4)) */
 SEXP attribute_hidden do_printdefault(SEXP call, SEXP op, SEXP args, SEXP rho)
@@ -646,23 +674,15 @@
 case EXPRSXP:
 	PrintExpression(s);
 	break;
+case LANGSXP:
 case CLOSXP:
-case LANGSXP:
-	t = getAttrib(s, R_SourceSymbol);
-	if (!isString(t) || !R_print.useSource)
-	t = deparse1(s, 0, R_print.useSource | DEFAULTDEPARSE);
-	for (i = 0; i < LENGTH(t); i++)
-	Rprintf("%s\n", CHAR(STRING_ELT(t, i))); /* translated */
-#ifdef BYTECODE
-	if (TYPEOF(s) == CLOSXP && isByteCode(BODY(s)))
-	Rprintf("\n", BODY(s));
-#endif
-	if (TYPEOF(s) == CLOSXP) {
-	t = CLOENV(s);
-	if (t != R_GlobalEnv)
-		Rprintf("%s\n", EncodeEnvironment(t));
+	{
+		SEXP call;
+		PROTECT( call = lang2(install("print.function"), s));
+		eval(call,env);
+		UNPROTECT(1);
+		break;
 	}
-	break;
 case ENVSXP:
 	Rprintf("%s\n", EncodeEnvironment(s));
 	break;
@@ -905,7 +925,13 @@
 	PROTECT(call = lang2(install("print"), s));
 	eval(call, env);
 	UNPROTECT(1);
-} else PrintValueRec(s, env);
+} else if( TYPEOF(s) == CLOSXP || TYPEOF(s) == LANGSXP){
+		SEXP call; 
+		PROTECT(call = lang2(install("print.function"), s));
+		eval(call,env);
+	} else {
+		PrintValueRec(s, env);
+	}
 UNPROTECT(1);
 }
 
@@ -1009,3 +1