I tested in R-GUI and RStudio.
Did not check Terminal.
Can check variable tomorrow - sorry but it's already quite late here in
Vienna.
Am Freitag, 21. Dezember 2012 schrieb JJ Allaire :
> Walter,
>
> Are you running Terminal, R GUI, or RStudio? (there might be a
> difference in the way dynamic li
Walter,
Are you running Terminal, R GUI, or RStudio? (there might be a
difference in the way dynamic libraries are located in each which
could cause this).
Also, what's the value of the environment variable DYLD_LIBRARY_PATH?
Thanks,
J.J.
___
Rcpp-dev
I am not sure about the R-forge build, but at least the CRAN Mac binaries (R
and packages) are built with toolchains no longer exists in recent Mac OS X
(such as 10.8.2, well there are ways to get them though not from Apple). That
may cause issues I guess.
Best,
Yan
On Dec 21, 2012, at 8:26 A
So perhaps there's an issue with the way Mac binaries are built on R-forge?
Perhaps a divergent set of headers or some difference in the way the C++
standard library is linked to?
Glad things are working for you. We'll investigate further to see if we can
figure out how and why this crops up. Than
Ok.
I have to step one step back. When installing from source - everything green!
Installing binary packages seemed to cause that issue.
Thank you very much for the assistance.
W
On Dec 21, 2012, at 1:00 AM, JJ Allaire wrote:
> Walter,
>
> I am unable to reproduce locally -- could you send
Walter,
I am unable to reproduce locally -- could you send along all of the details
of your case (filename, file contents if possible, directory names, etc.
Thanks!
JJ
On Dec 20, 2012, at 6:43 PM, Walter Gmail wrote:
I updated to 0.10.1.5 (from r-forge)
Sorry to disappoint but still the same
On 21 December 2012 at 00:43, Walter Gmail wrote:
| I updated to 0.10.1.5 (from r-forge)
| Sorry to disappoint but still the same behaviour …
|
| BUT … when "downgrading" to 0.10.1 I get expected behaviour i.e. command
| results in:
| Error in sourceCpp("source-file.cpp") : file not found: 'sou
I updated to 0.10.1.5 (from r-forge)
Sorry to disappoint but still the same behaviour …
BUT … when "downgrading" to 0.10.1 I get expected behaviour i.e. command
results in:
Error in sourceCpp("source-file.cpp") : file not found: 'source-file.cpp'
Cheers, W
On Dec 20, 2012, at 11:57 PM, JJ Al
Hi Walter,
I believe this has been fixed but it would be great if you could verify in
your setup. Could you try with the very latest Rcpp from either svn or
R-forge (http://r-forge.r-project.org/R/?group_id=155)
Thanks!
J.J.
On Thu, Dec 20, 2012 at 5:37 PM, Walter Gmail wrote:
> I would like t
I would like to report a "bug". I am not sure, if I am right here.
But …
The command
sourceCpp("source-file.cpp")
causes R to crash, when (by mistake) your current working directory is not the
one that holds this source file.
When the working directory or is set to the directory containing th
On 20 December 2012 at 13:25, Alon Honig wrote:
| Thank you for providing a point of reference with regards to speed. Dirk's
| examples have ratios of 60:1 causing me to rethink my approach.
That is __obviously__ problem dependent.
We have seen anything from more than 10k (for somewhat degenera
Hi Volker,
On 20 December 2012 at 19:19, "Volker Steiß" wrote:
| Hello,
|
| first of all: Thanks for creating Rcpp. It is great in interconnecting R
| and C++.
|
| I am currently working on a project written in C++ using the Boost library
| and Bjam as build system. C++ code is called from R us
On 20 December 2012 at 12:35, Alon Honig wrote:
| My current RCPP program is only 4 times faster than its R byte code compiled
| equivalent. I am trying to speed up my code and from what I understand using
| pointers prevents an external function from copying the entire object when
| executing its
Thank you JJ, that makes sense. I had no idea that R could be so taxing
when bench-marking.
On Thu, Dec 20, 2012 at 1:27 PM, JJ Allaire wrote:
> It's possible that the overhead of making R function calls is swamping all
> of the other performance data here. I've re-written the example w/
> sourc
Thank you for providing a point of reference with regards to speed. Dirk's
examples have ratios of 60:1 causing me to rethink my approach.
On Thu, Dec 20, 2012 at 1:18 PM, H Xiong wrote:
> Hi Alon,
>
> I am only a user, not a developer, of Rcpp, so I will offer some
> observations only.
>
> On T
Hello,
first of all: Thanks for creating Rcpp. It is great in interconnecting R
and C++.
I am currently working on a project written in C++ using the Boost library
and Bjam as build system. C++ code is called from R using Rcpp. The
RCPP_MODULE directive is used to export some classes.
Development
My current RCPP program is only 4 times faster than its R byte code
compiled equivalent. I am trying to speed up my code and from what I
understand using pointers prevents an external function from copying the
entire object when executing its methods. I am having difficulty finding
salient exampl
17 matches
Mail list logo
