Hi all,
Could someone help me on compilation of the
RInside/inst/examples/standard/rinside_sample0.cpp. This example is the project
Rinside0 created by eclipse.
And here is the error message for build.
Build of configuration Debug for project Rinside0
make all
Building file: ../src/
Yes! Adding the using namespace Rcpp line did the trick. Thank you.
Might I suggest adding this trick to the documentation? Many (most? just me?)
R users are simply looking for ways to do statistics faster, and just don't
have the same skills or experience as professional software developers.
On 7 April 2011 at 00:31, Michael Braun wrote:
| A couple of weeks ago, I posted a problem in compiling and running one of the
| examples from the Rcpp-quickref pdf. There were two suggestions: one was to
| upgrade my compiler, and the other was to find Linux on "another account
| somewhere at m
Thank you, Romain. Looks like your simple workaround fixes all my problems.
Günter
On Apr 6, 2011, at 6:22 AM, Romain Francois wrote:
> H. I'm afraid I can't fix this.
>
> Here is the story: both wrap(X) and wrap(X) create a new SEXP and allocate
> memory. When wrap(Y) is called, s
On 6 April 2011 at 21:30, Davor Cubranic wrote:
| On April 6, 2011 08:17:47 pm Dirk Eddelbuettel wrote:
| > For what it is worth, g++ 4.6.1 works perfectly fine on (Debian) Linux
| > (which is why CRAN already uses it for tests on the incoming/ directory)
| > but g++ 4.4 is still the default on Ub
I've tried the MacPorts route, and it takes forever. Perhaps this is a
MacPorts problem, but I've found that it consumes all available system
resources as it compiles all possible dependencies before even getting to the
compilation of gcc.
On Apr 7, 2011, at 12:34 AM, Davor Cubranic wrote:
>
On April 6, 2011 07:49:32 pm Michael Braun wrote:
> I've been able to upgrade my compiler to g++ 4.6 on the Mac, and I also
> checked this on a Red Hat Linux system with g++ 4.4. In both cases, the
> OpenMP code does compile and run, so I agree that it must have been a
> compiler issue. However,
Hello, again.
A couple of weeks ago, I posted a problem in compiling and running one of the
examples from the Rcpp-quickref pdf. There were two suggestions: one was to
upgrade my compiler, and the other was to find Linux on "another account
somewhere at my large-enough university." I have do
On April 6, 2011 08:17:47 pm Dirk Eddelbuettel wrote:
> For what it is worth, g++ 4.6.1 works perfectly fine on (Debian) Linux
> (which is why CRAN already uses it for tests on the incoming/ directory)
> but g++ 4.4 is still the default on Ubuntu 10.10. It will be a while til
> 4.6 becomes the def
Hi Michael,
On 6 April 2011 at 22:49, Michael Braun wrote:
| Dirk:
|
| I've been able to upgrade my compiler to g++ 4.6 on the Mac, and I also
checked
| this on a Red Hat Linux system with g++ 4.4. In both cases, the OpenMP code
| does compile and run, so I agree that it must have been a compi
> The issue is that when calling wrap it creates an unprotected SEXP, and
> Rcpp is not responsible for these. If the programmer passes an
> unprotected SEXP to ::create, it is his responsability to protect it.
Just to clarify -- in the case of a naive user who's not protecting
objects: a single w
Dirk:
I've been able to upgrade my compiler to g++ 4.6 on the Mac, and I also checked
this on a Red Hat Linux system with g++ 4.4. In both cases, the OpenMP code
does compile and run, so I agree that it must have been a compiler issue.
However, 4.6 appears to be an experimental version, with
Le 06/04/11 17:12, Davor Cubranic a écrit :
To make it harder for users to shoot themselves in the foot with 'List::create(Named("x") =
wrap(X), ...', is it possible to make it simply illegal to assign an explicit "wrap" to a
"Named"? This would force everyone to use implicit wraps, which as yo
To make it harder for users to shoot themselves in the foot with
'List::create(Named("x") = wrap(X), ...', is it possible to make it simply
illegal to assign an explicit "wrap" to a "Named"? This would force everyone to
use implicit wraps, which as you said are safe.
Davor
On 2011-04-06, at 4:
H. I'm afraid I can't fix this.
Here is the story: both wrap(X) and wrap(X) create a new SEXP and
allocate memory. When wrap(Y) is called, since the created object is
large, R calls the GC to collect unprotected SEXP to free some space. So
my guess is that at that point the SEXP that i
Good news. I can reproduce it.
Bas news. This is likely a PROTECT problem with the Rcpp::List constructor.
Wearing my bugbuster costume, and getting ready for a fight.
Romain
Le 07/03/11 23:03, "Günter J. Hitsch" a écrit :
I'm new to Rcpp and RcppArmadillo---so far I like it a lot! Thanks to
Hi Romain,
Thanks for your quick response. It works fine, now. I simply needed to
add LinkingTo: Rcpp to my DESCRIPTION file, and using
PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"`
Thanks again,
Cedric
On 06/04/11 09:43, Romain Francois wrote:
Hello,
First, you don't need PKG_C
Hello,
First, you don't need PKG_CPPFLAGS at all, just add:
LinkingTo: Rcpp
to your DESCRIPTION file.
Then, please be specific about what you mean by "does not work".
PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"`
is what the documentation prescribes, so it should work.
Romain
L
18 matches
Mail list logo
