In looking through the Rcpp/0.11.3 code, I came across this file:
inst/include/Rcpp/vector/instantiation.h
The file contains the declarations for IntegerVector, NumericVector, etc. It
seems reasonable to assume that these types will be used in basically any code
using Rcpp.
The declarations a
I should clarify: those git gist are the "git clone" links. Here are the
direct links for viewing:
The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353
The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a
___
Kevin Thornton
Associate Professor
Ecol
On 15 October 2014 at 10:28, Kevin Thornton wrote:
| I should clarify: those git gist are the "git clone" links. Here are the
direct links for viewing:
|
| The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353
|
| The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a
Could
If we were to have these vectors as part of the shared object rather
than header-only, wouldn't this imply breakage for existing packages
if newer versions of Rcpp changed the Vector template class
implementation (perhaps it inherits new policies, or gains new
methods, or methods change, or becomes
Yeah, we definitely want to keep things header-only for ABI stability.
This is pretty non-negotiable IMHO.
On Wed, Oct 15, 2014 at 2:14 PM, Kevin Ushey wrote:
> If we were to have these vectors as part of the shared object rather
> than header-only, wouldn't this imply breakage for existing packa
On Oct 15, 2014, at 11:01 AM, Dirk Eddelbuettel wrote:
>
> On 15 October 2014 at 10:28, Kevin Thornton wrote:
> | I should clarify: those git gist are the "git clone" links. Here are the
> direct links for viewing:
> |
> | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353
> |
>
On Oct 15, 2014, at 11:14 AM, Kevin Ushey wrote:
> If we were to have these vectors as part of the shared object rather
> than header-only, wouldn't this imply breakage for existing packages
> if newer versions of Rcpp changed the Vector template class
> implementation (perhaps it inherits new p
It looks like this is beyond me at the moment, and would require the attention
of someone who knows the code base.
Even including Rcpp.h in the .cpp file returns errors, which I find rather
puzzling.
On Oct 15, 2014, at 11:01 AM, Dirk Eddelbuettel wrote:
>
> On 15 October 2014 at 10:28, Kevi
On 15 October 2014 at 11:17, Kevin Thornton wrote:
|
| On Oct 15, 2014, at 11:01 AM, Dirk Eddelbuettel wrote:
|
| >
| > On 15 October 2014 at 10:28, Kevin Thornton wrote:
| > | I should clarify: those git gist are the "git clone" links. Here are the
direct links for viewing:
| > |
| > | The
Dear list,
I have the following weird problem and would be really glad for any input:
The windows binary from CRAN for my package MPTinR, which uses RcppEigen, leads to an
"Assertion failed" error which crashes R with a simple example given below
(which unfortunately is not part of the example
Hi Henrik,
On 15 October 2014 at 20:59, Henrik Singmann wrote:
| Dear list,
|
| I have the following weird problem and would be really glad for any input:
|
| The windows binary from CRAN for my package MPTinR, which uses RcppEigen,
leads to an "Assertion failed" error which crashes R with a s
Hi Henrik,
There seems to be a similar problem here in my package, reported by
https://github.com/yixuan/rARPACK/issues/4.
The reporter said that the runtime error occured when using RStudio, but
disappeared in RGui. Is this the same situation as yours?
Best,
Yixuan
2014-10-15 14:59 GMT-04:00 He
Hi Yixuan,
Unfortunately the problem seems to not be related to RStudio. It also appears
in RGui. The error message is also different.
Cheers,
Henrik
Am 15.10.2014 um 21:13 schrieb Yixuan Qiu:
Hi Henrik,
There seems to be a similar problem here in my package, reported by
https://github.com
Hi Dirk,
I will try to produce a minimal reproducible example, but as I need to resort
on winbuilder to crash it, this could take some time. Furthermore, not all
inputs crash R, as shown in the example in the end.
However, I am not sure how I contributed to the error since the C++ part of th
Hi Dirk and list,
I have now managed to isolate the problem. The cpp file posted below can on both Windows and
Linux crash R if (a) compiled by winbuilder (windows only) or if build via
devtools::load_all() or from within Rstudio ("Build & Reload") and (b) when
using the appropriate input.
(Resending, corrected headers)
Henrik,
The list address is rcpp-de...@r-forge.wu-wien.ac.at Would you mind
using that? The gmane redirector messes up automated filtering. Thank you!
Moreover, it also seems to have swallowed my reply. Please do not create
extra work for us. Thanks.
On 15 O
Hi Kevin,
The easiest way for me to reproduce the issue on Linux was to upload the zip
file containing the R package folder plus the .Rproj file onto my Rstudio
Server. This zip file can be found here:
http://singmann.org/download/teaching/r/mptmin.zip
There I opened a new R script, and enter
Hi Dirk,
I am sorry for using the wrong address, it will not happen again.
Furthermore, I think that back in the day when I programmed my code the
interface I used was the recommended one (at least this is what I thought it
was). It was right around the time when the paper in JStatSoft from Do
Hi Henrik,
R CMD INSTALL defines the NDEBUG macro (as Writing R Extensions sec. 1.7
recommends), which disables eigen_assert. Otherwise your error is triggered
here:
eigen_assert(a_lhs.cols() == a_rhs.rows()
&& "invalid matrix product"
&& "if you wanted a coeff-wise or a dot pro
(Headers once more corrected)
On 15 October 2014 at 14:53, Kevin Ushey wrote:
|
|
|
| Hi Henrik,
|
| Thanks for putting this together. FWIW, I cannot reproduce this error
| (either with `trigger()` or `no_trigger()`) on OS X, nor when building
| from source on a Windows VM (while inside RStud
20 matches
Mail list logo
