Re: [Rcpp-devel] segfault on exit CRAN+Intel only

[Dirk Eddelbuettel]

Hi Murray,

On 4 March 2024 at 07:03, Murray Efford wrote:
| Dirk
| Thanks for a very helpful reply. I'll simplify my return values.
| 
| I mentioned Intel with rhub2 in my earlier post here, but I'm sorry
| that was somewhat buried. Debugging is somewhere between painful and
| impossible when my only check is submitting to CRAN!

It would be *really* helpful to have a path not involving CRAN.

| Also, I had tried valgrind, but that got stuck in Linux on what I
| assumed was an unrelated "unhandled instruction" error wrt OpenBLAS.
| That appeared unrelated, but maybe we need to factor it in as a
| possible interaction with RcppArmadillo. Strangely valgrind sticks on
| this --
| ==2242833== valgrind: Unrecognised instruction at address 0x57d3650.
| ==2242833==at 0x57D3650: dot_compute (in
| /opt/OpenBLAS/lib/libopenblas_skylakexp-r0.3.23.dev.so)
| -- even after I have set options(matprod="internal") in R, so
| something else (RcppArmadillo?) must be trying to use OpenBLAS.

That seems local to your system. I can just do 'R -d valgrind' as expected.

edd@rob:~$ R -q -d valgrind -e 'v <- integer(10)'
==2219911== Memcheck, a memory error detector
==2219911== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2219911== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2219911== Command: /usr/lib/R/bin/exec/R -q -e v~+~\<-~+~integer(10)
==2219911== 
> v <- integer(10)
> 
> 
==2219911== 
==2219911== HEAP SUMMARY:
==2219911== in use at exit: 51,025,490 bytes in 11,017 blocks
==2219911==   total heap usage: 26,520 allocs, 15,503 frees, 78,392,784 bytes 
allocated
==2219911== 
==2219911== LEAK SUMMARY:
==2219911==definitely lost: 0 bytes in 0 blocks
==2219911==indirectly lost: 0 bytes in 0 blocks
==2219911==  possibly lost: 0 bytes in 0 blocks
==2219911==still reachable: 51,025,490 bytes in 11,017 blocks
==2219911==   of which reachable via heuristic:
==2219911== newarray   : 4,264 bytes in 1 blocks
==2219911== suppressed: 0 bytes in 0 blocks
==2219911== Reachable blocks (those to which a pointer was found) are not shown.
==2219911== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2219911== 
==2219911== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
edd@rob:~$ 

valgrind is pretty good and useful. I also enjoy the fact that eg tinytest
testfiles are script so we can test them in the aggregate, or in isolation,
or via their helper function.

edd@rob:~/git/rcpparmadillo/inst/tinytest(master)$ R -q -d valgrind -e 
'tinytest::run_test_file("test_fastLm.R")'
==2243731== Memcheck, a memory error detector
==2243731== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2243731== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==2243731== Command: /usr/lib/R/bin/exec/R -q -e 
tinytest::run_test_file("test_fastLm.R")
==2243731== 
> tinytest::run_test_file("test_fastLm.R")
test_fastLm.R.   30 tests OK 4.3s
All ok, 30 results (4.3s)
> 
> 
==2243731== 
==2243731== HEAP SUMMARY:
==2243731== in use at exit: 58,200,576 bytes in 11,419 blocks
==2243731==   total heap usage: 38,070 allocs, 26,651 frees, 141,466,157 bytes 
allocated
==2243731== 
==2243731== LEAK SUMMARY:
==2243731==definitely lost: 0 bytes in 0 blocks
==2243731==indirectly lost: 0 bytes in 0 blocks
==2243731==  possibly lost: 0 bytes in 0 blocks
==2243731==still reachable: 58,200,576 bytes in 11,419 blocks
==2243731==   of which reachable via heuristic:
==2243731== newarray   : 4,264 bytes in 1 blocks
==2243731== suppressed: 0 bytes in 0 blocks
==2243731== Reachable blocks (those to which a pointer was found) are not shown.
==2243731== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2243731== 
==2243731== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
edd@rob:~/git/rcpparmadillo/inst/tinytest(master)$ 


Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] segfault on exit CRAN+Intel only

[Dirk Eddelbuettel]

And "beauty" (ahem) of discussion scattered over two mailing lists: I now see
you have a testbed via rhub2 (good) even though it does not reproduce (hm...).

So you could still try the suggested simplication.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] segfault on exit CRAN+Intel only

[Dirk Eddelbuettel]

On 3 March 2024 at 20:47, Murray Efford wrote:
| A couple of days ago I posted on R-package-devel about a mysterious
| segfault from R CMD checks of my package secrdesign (see
| https://CRAN.R-project.org/package=secrdesign, and
| https://github.com/MurrayEfford/secrdesign) The issue rises only on
| CRAN and only with the Intel(R) oneAPI DPC++/C++ Compiler:
| 
|  *** caught segfault ***
| address (nil), cause 'unknown'
| 
| As noted by Ivan Krylov and Uwe Ligges, the fault happens at the end
| of the R session (as it quits()). The package passes when checked on
| Intel(R) oneAPI DPC++/C++ Compiler 2023.2.0 (2023.2.0.20230721) with
| rhub2 .
| 
| Now, CRAN via Uwe Ligges has accepted a new version of secrdesign
| despite the continuing error. My reason for raising it here is that
| (i) it is likely to raise its head next time I update,
| (ii) my experience may not be unique,
| (iii) my use of Rcpp, RcppArmadillo and BH in this package is very
| limited (https://github.com/MurrayEfford/secrdesign/tree/main/src),
| and it may therefore be provide clues to an Rcpp pro.
| (iv) I have just noticed a similar 'Additional issue' for
| https://CRAN.R-project.org/package=ipsecr that also uses Rcpp,
| RcppArmadillo and BH.
| Any advice would be welcome. I have no experience with docker, so
| answers in words of one or few syllables, please.

I was about to suggest to run with 'valgrind' and/or 'asan'/'ubsan' as many
folks do when chasing 'spurious' bugs related to memory -- but then CRAN
already does that for you and found nothing!

So it is hard to say anything. It could be a bug on your end, it could be a
bug in the compiler (!!), it could be a bug in the libraries.  Now, Boost and
Armadillo are fairly mature and widely used so that is not likely either.
Given that you spotted another package in the same intersection it could be
an interaction.

But I am afraid you may need to work towards creating a 'workbench' where you
can chip away at this.  Some of us can eyeball, and some are truly excellent
at this, but that may not be a reliable (or scalable) way forward.

[ goes looking ]

So I eyeballed your code. One thing I might do is keep the return object
simpler. Instead of (on-the fly) creation of Rcpp::List with Rcpp::Named that
contain scalars, maybe consider returning a Rcpp::NumericVector(2) and set
the two elements.  You can still set 'names' on that too. A super-pedestrian
version is

> Rcpp::cppFunction('NumericVector myvec() { NumericVector v(2); v[0] = 1.23; 
> v[1] = 2.34; CharacterVector nm(2); nm[0] = "foo"; nm[1] = "bar"; 
> v.attr("names") = nm; return v; }')
> myvec()
 foo  bar 
1.23 2.34 
> 

and a fancier brace-initialization way is

> Rcpp::cppFunction('NumericVector myvec() { NumericVector v{1.23, 2.34}; 
> CharacterVector nm{"foo", "bar"}; v.attr("names") = nm; return v; }')
> myvec()
 foo  bar 
1.23 2.34 
>

Either works and avoids creation of temporaries at return which the (less
widely used !!) Intel compiler may resolve differently from g++ and clang++.
So it could be us, and defensive programming is always good but with repros
it so hard to say anything...

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RcppArmadillo with -fopenmp: Not using all available cores

[Dirk Eddelbuettel]

Hi Robin,

On 2 March 2024 at 16:34, Robin Liu wrote:
| sessionInfo() was the right clue. Indeed the version of R on machine B was not
| linked to OpenBLAS. Switching to a version with OpenBLAS allows the test code
| to use all cores.
| 
| A clear way to check which library is linked is to run the following:
| 
| > extSoftVersion()["BLAS"]

Ah yes -- I keep forgetting about that one. Good reminder!
 
| Thanks for your help!

Always a pleasure. Glad you are all set.

Dirk

 
| On Sat, Feb 24, 2024 at 9:17 AM Dirk Eddelbuettel  wrote:
| 
| 
| On 24 February 2024 at 11:44, Robin Liu wrote:
| | Thank you Dirk for the response.
| |
| | I called RcppArmadillo::armadillo_get_number_of_omp_threads() on both
| machines
| | and correctly see that machine A and B have 20 and 40 cores,
| respectively. I
| | also see that calling the setter changes this value.
| |
| | However, calling the setter does not seem to change the number of cores
| used on
| | either machine A or B. I have updated my code example as below: the
| execution
| | uses 20 cores on machine A and 1 core on machine B as before, despite my
| | setting the number of omp threads to 5. Do you have any further hints?
| 
| I fear you need to debug that on the machine 'B' in question. It's all 
open
| source.  I do not think either Conrad or myself put code in to constrain
| you
| to one core on 'B' (and then doesn't as you see on 'A').
| 
| You can grep around both the RcppArmadillo wrapper code and the include
| Armadillo code, I suggest making a local copy and peppering in some print
| statements.
| 
| Also keep in mind that (Rcpp)Armadillo hands off to computation to the
| actual
| LAPACK / BLAS implementation on that machine. Lots of things can go wrong
| there: maybe R was compiled with its own embedded BLAS/LAPACK sources
| (preventing a call out to OpenBLAS even when the machine has it). Or maybe
| R
| was compiled correctly but a single-threaded set of libraries is on the
| machine.
| 
| You have not supplied any of that information. Many bug report suggestions
| hint that showing `sessionInfo()` helps -- and it does show the 
BLAS/LAPACK
| libraries. You are not forced to show us this, but by not showing us you
| prevent us from being more focussed on suggestions.  So maybe start at 
your
| end by glancing at sessionInfo() on A and B?
| 
| Dirk
| 
| 
| | library(RcppArmadillo)
| | library(Rcpp)
| |
| | RcppArmadillo::armadillo_set_number_of_omp_threads(5)
| | print(sprintf("There are %d threads",
| |       RcppArmadillo::armadillo_get_number_of_omp_threads()))
| |
| | src <-
| | r"(#include 
| |
| | // [[Rcpp::depends(RcppArmadillo)]]
| |
| | // [[Rcpp::export]]
| | arma::vec getEigenValues(arma::mat M) {
| |   return arma::eig_sym(M);
| | })"
| |
| | size <- 1
| | m <- matrix(rnorm(size^2), size, size)
| | m <- m * t(m)
| |
| | # This line compiles the above code with the -fopenmp flag.
| | sourceCpp(code = src, verbose = TRUE, rebuild = TRUE)
| | result <- getEigenValues(m)
| | print(result[1:10])
| |
| | On Fri, Feb 23, 2024 at 12:53 PM Dirk Eddelbuettel 
| wrote:
| |
| |
| |     On 23 February 2024 at 09:35, Robin Liu wrote:
| |     | Hi all,
| |     |
| |     | Here is an R script that uses Armadillo to decompose a large 
matrix
| and
| |     print
| |     | the first 10 eigenvalues.
| |     |
| |     | library(RcppArmadillo)
| |     | library(Rcpp)
| |     |
| |     | src <-
| |     | r"(#include 
| |     |
| |     | // [[Rcpp::depends(RcppArmadillo)]]
| |     |
| |     | // [[Rcpp::export]]
| |     | arma::vec getEigenValues(arma::mat M) {
| |     |   return arma::eig_sym(M);
| |     | })"
| |     |
| |     | size <- 1
| |     | m <- matrix(rnorm(size^2), size, size)
| |     | m <- m * t(m)
| |     |
| |     | # This line compiles the above code with the -fopenmp flag.
| |     | sourceCpp(code = src, verbose = TRUE, rebuild = TRUE)
| |     | result <- getEigenValues(m)
| |     | print(result[1:10])
| |     |
| |     | When I run this code on server A, I see that arma can implicitly
| leverage
| |     all
| |     | available cores by running top -H. However, on server B it can 
only
| use
| |     one
| |     | core despite multiple being available: there is just one process
| entry in
| |     top
| |     | -H. Both processes successfully exit and return an answer. The
| process on
| |     | server B is of course much slower.
| |
| |     It is documented in the package how this is applied and the policy 
is
| to
| |

Re: [Rcpp-devel] Segfault in wrapping code in Rcpp

[Dirk Eddelbuettel]

Hi Nikhil,

Don't post images. I read in a text-based reader. The mailing list software
also scrubs html (I think).

I would simplify. Start with the simplest Rcpp Modules setup. Then add. Check
checking. Eventually on your way towards what you are doing now you may spot
the error.

Hope this helps,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RcppArmadillo with -fopenmp: Not using all available cores

[Dirk Eddelbuettel]

On 24 February 2024 at 11:44, Robin Liu wrote:
| Thank you Dirk for the response.
| 
| I called RcppArmadillo::armadillo_get_number_of_omp_threads() on both machines
| and correctly see that machine A and B have 20 and 40 cores, respectively. I
| also see that calling the setter changes this value.
| 
| However, calling the setter does not seem to change the number of cores used 
on
| either machine A or B. I have updated my code example as below: the execution
| uses 20 cores on machine A and 1 core on machine B as before, despite my
| setting the number of omp threads to 5. Do you have any further hints?

I fear you need to debug that on the machine 'B' in question. It's all open
source.  I do not think either Conrad or myself put code in to constrain you
to one core on 'B' (and then doesn't as you see on 'A').

You can grep around both the RcppArmadillo wrapper code and the include
Armadillo code, I suggest making a local copy and peppering in some print
statements.

Also keep in mind that (Rcpp)Armadillo hands off to computation to the actual
LAPACK / BLAS implementation on that machine. Lots of things can go wrong
there: maybe R was compiled with its own embedded BLAS/LAPACK sources
(preventing a call out to OpenBLAS even when the machine has it). Or maybe R
was compiled correctly but a single-threaded set of libraries is on the
machine.

You have not supplied any of that information. Many bug report suggestions
hint that showing `sessionInfo()` helps -- and it does show the BLAS/LAPACK
libraries. You are not forced to show us this, but by not showing us you
prevent us from being more focussed on suggestions.  So maybe start at your
end by glancing at sessionInfo() on A and B?

Dirk

 
| library(RcppArmadillo)
| library(Rcpp)
| 
| RcppArmadillo::armadillo_set_number_of_omp_threads(5)
| print(sprintf("There are %d threads",
|       RcppArmadillo::armadillo_get_number_of_omp_threads()))
| 
| src <-
| r"(#include 
| 
| // [[Rcpp::depends(RcppArmadillo)]]
| 
| // [[Rcpp::export]]
| arma::vec getEigenValues(arma::mat M) {
|   return arma::eig_sym(M);
| })"
| 
| size <- 1
| m <- matrix(rnorm(size^2), size, size)
| m <- m * t(m)
| 
| # This line compiles the above code with the -fopenmp flag.
| sourceCpp(code = src, verbose = TRUE, rebuild = TRUE)
| result <- getEigenValues(m)
| print(result[1:10])
| 
| On Fri, Feb 23, 2024 at 12:53 PM Dirk Eddelbuettel  wrote:
| 
| 
| On 23 February 2024 at 09:35, Robin Liu wrote:
| | Hi all,
| |
| | Here is an R script that uses Armadillo to decompose a large matrix and
| print
| | the first 10 eigenvalues.
| |
| | library(RcppArmadillo)
| | library(Rcpp)
| |
| | src <-
| | r"(#include 
| |
| | // [[Rcpp::depends(RcppArmadillo)]]
| |
| | // [[Rcpp::export]]
| | arma::vec getEigenValues(arma::mat M) {
| |   return arma::eig_sym(M);
| | })"
| |
| | size <- 1
| | m <- matrix(rnorm(size^2), size, size)
| | m <- m * t(m)
| |
| | # This line compiles the above code with the -fopenmp flag.
| | sourceCpp(code = src, verbose = TRUE, rebuild = TRUE)
| | result <- getEigenValues(m)
| | print(result[1:10])
| |
| | When I run this code on server A, I see that arma can implicitly 
leverage
| all
| | available cores by running top -H. However, on server B it can only use
| one
| | core despite multiple being available: there is just one process entry 
in
| top
| | -H. Both processes successfully exit and return an answer. The process 
on
| | server B is of course much slower.
| 
| It is documented in the package how this is applied and the policy is to
| NOT
| blindly enforce one use case (say all cores, or half, or a magically 
chosen
| value of N for whatever value of N) but to follow the local admin setting
| and
| respecting standard environment variables.
| 
| So I suspect that your machine 'B' differs from machine 'A' in this
| regards.
| 
| Not that this is a _run-time_ and not _compile-time_ behavior. As it is 
for
| multicore-enabled LAPACK and BLAS libraries, the OpenMP library and
| basically
| most software of this type.
| 
| You can override it, see
|   RcppArmadillo::armadillo_set_number_of_omp_threads
|   RcppArmadillo::armadillo_get_number_of_omp_threads
| 
| Can you try and see if these help you?
| 
| Dirk
| 
| | Here is the compilation on server A:
| | /usr/local/lib/R/bin/R CMD SHLIB --preclean -o 'sourceCpp_2.so'
| | 'file197c21cbec564.cpp'
| | g++ -std=gnu++11 -I"/usr/local/lib/R/include" -DNDEBUG -I../inst/include
| | -fopenmp  -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/usr/local/
| lib/R/
| | site-library/RcppArmadillo/include" -I"/tmp/RtmpwhGRi3/
| | sourceCpp-x86_64-pc-linux-gnu-1.0.9" -I/usr/local/in

Re: [Rcpp-devel] RcppArmadillo with -fopenmp: Not using all available cores

[Dirk Eddelbuettel]

On 23 February 2024 at 09:35, Robin Liu wrote:
| Hi all,
| 
| Here is an R script that uses Armadillo to decompose a large matrix and print
| the first 10 eigenvalues.
| 
| library(RcppArmadillo)
| library(Rcpp)
| 
| src <-
| r"(#include 
| 
| // [[Rcpp::depends(RcppArmadillo)]]
| 
| // [[Rcpp::export]]
| arma::vec getEigenValues(arma::mat M) {
|   return arma::eig_sym(M);
| })"
| 
| size <- 1
| m <- matrix(rnorm(size^2), size, size)
| m <- m * t(m)
| 
| # This line compiles the above code with the -fopenmp flag.
| sourceCpp(code = src, verbose = TRUE, rebuild = TRUE)
| result <- getEigenValues(m)
| print(result[1:10])
| 
| When I run this code on server A, I see that arma can implicitly leverage all
| available cores by running top -H. However, on server B it can only use one
| core despite multiple being available: there is just one process entry in top
| -H. Both processes successfully exit and return an answer. The process on
| server B is of course much slower.

It is documented in the package how this is applied and the policy is to NOT
blindly enforce one use case (say all cores, or half, or a magically chosen
value of N for whatever value of N) but to follow the local admin setting and
respecting standard environment variables.

So I suspect that your machine 'B' differs from machine 'A' in this regards.

Not that this is a _run-time_ and not _compile-time_ behavior. As it is for
multicore-enabled LAPACK and BLAS libraries, the OpenMP library and basically
most software of this type.

You can override it, see
  RcppArmadillo::armadillo_set_number_of_omp_threads
  RcppArmadillo::armadillo_get_number_of_omp_threads

Can you try and see if these help you?

Dirk

| Here is the compilation on server A:
| /usr/local/lib/R/bin/R CMD SHLIB --preclean -o 'sourceCpp_2.so'
| 'file197c21cbec564.cpp'
| g++ -std=gnu++11 -I"/usr/local/lib/R/include" -DNDEBUG -I../inst/include
| -fopenmp  -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/usr/local/lib/R/
| site-library/RcppArmadillo/include" -I"/tmp/RtmpwhGRi3/
| sourceCpp-x86_64-pc-linux-gnu-1.0.9" -I/usr/local/include   -fpic  -g -O2
| -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
| -D_FORTIFY_SOURCE=2 -g  -c file197c21cbec564.cpp -o file197c21cbec564.o
| g++ -std=gnu++11 -shared -L/usr/local/lib/R/lib -L/usr/local/lib -o
| sourceCpp_2.so file197c21cbec564.o -fopenmp -llapack -lblas -lgfortran -lm
| -lquadmath -L/usr/local/lib/R/lib -lR
| 
| and here it is for server B:
| /sw/R/R-4.2.3/lib64/R/bin/R CMD SHLIB --preclean -o 'sourceCpp_2.so'
| 'file158165b9c4ae1.cpp'
| g++ -std=gnu++11 -I"/sw/R/R-4.2.3/lib64/R/include" -DNDEBUG -I../inst/include
| -fopenmp  -I"/home/my_username/.R/library/Rcpp/include" -I"/home/ my_username
| /.R/library/RcppArmadillo/include" -I"/tmp/RtmpvfPt4l/
| sourceCpp-x86_64-pc-linux-gnu-1.0.10" -I/usr/local/include   -fpic  -g -O2  -c
| file158165b9c4ae1.cpp -o file158165b9c4ae1.o
| g++ -std=gnu++11 -shared -L/sw/R/R-4.2.3/lib64/R/lib -L/usr/local/lib64 -o
| sourceCpp_2.so file158165b9c4ae1.o -fopenmp -llapack -lblas -lgfortran -lm
| -lquadmath -L/sw/R/R-4.2.3/lib64/R/lib -lR
| 
| I thought that the -fopenmp flag should let arma implicitly parallelize matrix
| computations. Any hints as to why this may not work on server B?
| 
| The actual code I'm running is an R package that includes RcppArmadillo and
| RcppEnsmallen. Server B is the login node to an hpc cluster, but the code does
| not use all cores on the compute nodes either.
| 
| Best,
| Robin
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Wrapping a c++ class with singleton using RCPP Module

[Dirk Eddelbuettel]

On 21 February 2024 at 09:21, Iñaki Ucar wrote:
| Could you please provide more details about what you tried so far and what are
| the issues you found? A link to a public repo with a test case would be even
| better.

Seconded!

I think I also did something like that 'way early' and 'way simply'. In just
one file you can just have.

   class Foo { ... };   // forward declaration, or actual declaration

   static Foo* myfooptr = nullptr;

followed by a few simple Rcpp function to init (ie allocated), set a value,
get a value and maybe destroy at end (even callable via on.exit() from R).

The key really is to differentiate between types Rcpp knows, and those types
or classes you have that it doesn't -- so you have to write accessors in
terms of the types R knows. We must have examples for that somewhere...

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Numerical precision in rotations with Eigen

[Dirk Eddelbuettel]

On 10 January 2024 at 09:52, Rafael Ayala Hernandez wrote:
| Hi,
| 
| I have implemented a function to rotate a 3D vector a given angle around a 
given axis (basically wrapping the functionality provided by Eigen::AngleAxis) 
as an Rcpp function.
| Below is an extract from the source file:
| 
| #include 
| #include 
| #include 
| #include 
| using namespace Rcpp;
| using Rcpp::as;
| using Eigen::Map;
| using Eigen::VectorXd;
| using Eigen::Vector3d;
| using Eigen::Matrix;
| using Eigen::MatrixXd;
| using Eigen::Matrix3d;
| using Eigen::Dynamic;
| using Eigen::AngleAxisd;
| 
| // [[Rcpp::plugins("cpp11")]]
| // [[Rcpp::export]]
| NumericVector rotate3DVectorAngleAxis(NumericVector x, NumericVector axis, 
double angle) {
| // Note: x should be 1 single vector to rotate
| Map xEigen(as >(x));
| Map axisEigen(as >(axis));
| Matrix3d rotation;
| rotation = AngleAxisd(angle, axisEigen.normalized());
| Vector3d rotatedVector;
| rotatedVector = rotation.matrix() * xEigen;
| return wrap(rotatedVector);
| }
| 
| 
| The function executes with no problems and gives the expected output.
| 
| However, I have noticed that there is times where a value of 0 would be 
expected for some vector components, but instead a very small value is 
returned. For example, executing the following on my machine:
| 
| rotate3DVectorAngleAxis(c(0,0,1), c(1,0,0), pi/2)
| 
| Which represents a rotation of 90 degrees around the X axis, and therefore 
the expected output value would be c(0,1,0)
| 
| However, it instead results in an output vector of c(0.00e+00, 
-1.00e+00,  6.123234e-17)
| 
| I.e., the value for the Z component is 6.123234e-17. 
| 
| I guess this is somehow related to machine precision, but is there an exact 
cause that could be possibly fixed?
| Additionally, why does the deviation from 0 only seem to happen for the Z 
component, and not for the X component?
| Varying the amount of rotation also seems to lead to a cumulative error on 
the same component. E.g., rotating by 4001 times pi/2 (i.e., 1000 complete 360 
degrees rotations plus a 90 degree rotation):
| 
| rotate3DVectorAngleAxis(c(0,0,1), c(1,0,0), 14401*pi/2)
| 
| results in c(0.00e+00, -1.00e+00, 4.776933e-13)
| 
| Which seems again to be accumulating in the same Z component.
| 
| Is there anything I could improve in my implementation to avoid these 
numerical errors?
| 
| For reference, .Machine$double.eps on my machine is 2.220446e-16

>From the looks it seems like an instance of R FAQ 7.31:

   
https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f

and the 'classic' referenced therein

   https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

It is probably your responsibility to identify such values and explicitly
round or set them to zero.  I know nothing about the rotation here but in
other field (esp with iterations) a common rule of thumb is 'less than
sqrt(eps) is zero' meaning 1e-8.  Of course that is too general and may be
too broad as "it always depends".

Hope this helps a little. Maybe contact some field experts too.

Cheers, Dirk

| Thanks a lot in advance
| 
| Best wishes,
| 
| Rafa
| 
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rf_error() format string

[Dirk Eddelbuettel]

Sorry for being slow to respond (very busy morning at work and play, got five
such emails myself) but as Inaki and Georgi helpfully pointed out already the
issue is _known_ and has a _fix_ at either the default branch of the Rcpp
repo, or, if you prefer, via the Rcpp drat repo as detailed in this comment
of issue #1287 at the Rcpp repo

   https://github.com/RcppCore/Rcpp/issues/1287#issuecomment-1829886024

from which I quote (and, again, sorry for not posting here sooner)

  Yes, I actually got five such emails myself today for packages of mine
  using Rcpp.

  The fix is simple thanks to PR #1288 we made two days ago. Install Rcpp
  1.0.11.5 from the Rcpp drat repo via, e.g.,

 Rscript -e 'install.packages("Rcpp", \
 repos=c("https://RcppCore.github.io/drat;, getOption("repos")))'

  and then re-run compileAttributes(). That will fix the RcppExports.cpp file
  for you. You then need to upload your updated package to CRAN. It has no
  change in its run-time dependency on Rcpp so you do not need to change
  anything in DESCRIPTION. Just re-run compileAttributes().

Of course, you can also use whichever tool runs `compileAttributes()` for
you. I tend to use `littler` script `compAttr.r` on the command-line. Others
rely on RStudio which automagically does it if it notices you rebuild a
package using Rcpp.  I believe the devtools/usethis nexus has this in
`document_all()` (?), and I am sure someone somewhere cooked something up for
VSCode too.  The key is the provided function Rcpp::compileAttributes() which
remains at your service and is now updated.

I may also push an updated `rocker/drd` container which I recently switched
to being based on ubuntu and r2u (rather than debian).  Then installing your
build dependencies for you packages is trivial (I run `installDeps.r` inside
the container) and it will come with an r-devel build. You "only" need to
create `~/.R/Makevars` to tell the compiler to use extended format warnings.
That allows you to replicate the CRAN warnings, and ensure rebuild
RcppExports.cpp addresses it.  If I find time I'll post an example on my
blog.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Life-cycle of Rcpp::XPtr

[Dirk Eddelbuettel]

PS There is another neat use case where a shared_ptr is allocated.  Now we
cannot wrap a shared_ptr in an XPtr but ... we can stick the shared_ptr into
a struct, and allocate that with new and then make_xptr.  You are then back
to well-understood C++ semantics.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Life-cycle of Rcpp::XPtr

[Dirk Eddelbuettel]

Hi Ralf,

On 23 September 2023 at 08:28, Ralf Stubner wrote:
| I have a question concerning the file-cycle of Rcpp::XPtr: Consider a
| XPtr with the default delete finalizer wrapping some pointer. If I use
| the copy constructor to create another XPtr, this is pointing at the
| same underlying object as expected. What happens if one of these
| pointers goes out of scope and is at some point garbage collected? Is
| the underlying object deleted leaving the other XPtr with a broken
| pointer? Or is the object protected by the existence of the other
| pointer? From my experiments I have the impression that the latter is
| the case, which would be the desired behaviour. But it would be nice
| if one could be sure.

I had done some experiments with 'expanded finalizers' that use more logging
(which I find quite convenient via `spdl` -- same nice spdlog interface now
from R and C++) so you could add some display of the pointer address, check
on nullness etc.

I have done a bit more work using XPtr in the context of the tiledb (and the
related, possibly upcoming tiledbsoma package not yet on CRAN) where I use an
enum (which requires C++17 in the use I have there) to 'type tag' each
external pointer and on each use check I have the correct type. I am not
thinking to a simple unordered_map from enum to string to also make more
informed errors (showing the type as string rather than enum int value) as
well as maybe an enhanced show or print at the R level. I have long been
meaning to farm that out into a new (simple) add-on package (see issue #1212)
and should get on with that.  (The 'still somewhat raw' XPtr extension in
tiledb is eg here:
https://github.com/TileDB-Inc/TileDB-R/blob/1e7bd2fa4e54f3e152c4fec3a65343df49d3f525/src/libtiledb.h#L80-L160
and the check_xptr_tag is then used throughout the files in src/.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp::sourceCpp Problem with R 4.3 update

[Dirk Eddelbuettel]

On 30 May 2023 at 14:27, Dominick Samperi wrote:
| Looks like the recent update to R 4.3 broke Rcpp::sourceCpp.
| 
| Here is a simple example...
| 
| library(Rcpp)
| Rcpp::sourceCpp(code='
|   #include 
|   using namespace Rcpp;
|   // [[Rcpp::export()]]
|   SEXP cpptest(NumericVector v) {
|     return v;
|   }'
| )
| cpptest(1:5)
| 
| This works without problems under R 4.2.3, but under R 4.3 I get...
| 
| using C++ compiler: 'G__~1.EXE (GCC) 12.2.0'
| C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: internal error:
| aborting at ../../binutils-2.40/ld/ldlang.c:527 in compare_section
| C:\rtools43\x86_64-w64-mingw32.static.posix\bin/ld.exe: please report this bug
| collect2.exe: error: ld returned 1 exit status
| g++ -std=gnu++17  -I"c:/PROGRA~1/R/R-43~1.0/include" -DNDEBUG   
-I"C:/PROGRA~1/
| R/R-43~1.0/library/Rcpp/include" -I"C:/Users/djsam/AppData/Local/Temp/
| RtmpKEsaiY/sourceCpp-x86_64-w64-mingw32-1.0.10"   -I"C:/rtools43/
| x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -mfpmath=sse -msse2
| -mstackrealign  -c filebb0108a7dbf.cpp -o filebb0108a7dbf.o
| g++ -std=gnu++17 -shared -s -static-libgcc -o sourceCpp_2.dll tmp.def
| filebb0108a7dbf.o -LC:/rtools43/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/
| rtools43/x86_64-w64-mingw32.static.posix/lib -Lc:/PROGRA~1/R/R-43~1.0/bin/x64
| -lR
| Error in Rcpp::sourceCpp(code = "\n  #include \n  using namespace 
Rcpp;
| \n  // [[Rcpp::export()]]\n  SEXP cpptest(NumericVector v) {\n    return v;\n
|  }") :
|   Error occurred building shared library.

I don't have any access to Windows but note that CRAN of course tests Rcpp
and its 2600+ reverse depends on Windows.

On the OS I use all is well with this (and of course in general)

> R.version
   _   
platform   x86_64-pc-linux-gnu 
arch   x86_64  
os linux-gnu   
system x86_64, linux-gnu   
status 
major  4   
minor  3.0 
year   2023
month  04  
day21  
svn rev84292   
language   R   
version.string R version 4.3.0 (2023-04-21)
nickname   Already Tomorrow
> utils::osVersion
[1] "Ubuntu 22.10"
> Rcpp::cppFunction("SEXP cpptest(NumericVector v) { return v; }")
> cpptest(1:5)
[1] 1 2 3 4 5
> 

So I suspect something is not tied down correctly at your end; maybe new R
and old Rtools so something like that.

One gets 15 h / months free at posit.cloud (formerly rstudio.cloud), that is
good to just run a quick sanity check like this.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Locating an Instance of a Reference Class in the Environment

[Dirk Eddelbuettel]

Hi Matthew,

Thanks for circling back!

On 28 March 2023 at 11:23, Matthew Supernaw - NOAA Federal wrote:
| Hi Dirk,
| Thanks for your attention on this. I was able to find a solution that works 
for
| us.
| Matthew
| 
| https://github.com/NOAA-FIMS/ModularTMBExample/blob/map/src/
| tmb_objective_function.cpp#L133

Ok -- if you want we can maybe offline work on smoothing that over. You have
Rcpp already at your disposal there, you should not need the darn PROTECT and
UNPROTECT that makes my eyes burn.

Total aside:  I needed a finger exercise for turning factor to character and
vice verse and just did this (for now (?) in RcppExamples):

https://github.com/eddelbuettel/rcppexamples/blob/master/src/makeFactor.cpp

and looks like I forgot to rename the file which I may do to FactorExample.cpp

Dirk
 
| On Fri, Mar 24, 2023 at 4:36 PM Jeff Newmiller 
| wrote:
| 
| Well, feel free to ignore my post, but the gist was that anything you have
| access to in R can be passed by your R API code to your Rcpp code. Also,
| due to R's GC you should usually avoid caching references between calls to
| your Rcpp code anyway.
| 
| On March 24, 2023 12:40:43 PM PDT, Matthew Supernaw - NOAA Federal <
| matthew.super...@noaa.gov> wrote:
| >Hi Jeff,
| >I'm not sure I understand your comment. The code is part of a package.
| >We're just trying to sync the declared object name in the R environment 
to
| >the object in the Rcpp module programmatically from c++ for internal use.
| I
| >just wondered if there was a way to access the wrapped object in the
| >Rcpp:::PreserveStorage class and Dirk answered that question.
| >Thanks.
| >Matthew
| >
| >
| >On Fri, Mar 24, 2023 at 2:34 PM Jeff Newmiller 
| >wrote:
| >
| >> Matthew... the normal context for sharing Rcpp code is within a 
package.
| >> It is a no-brainer to have an R API called by the user that calls
| whatever
| >> Rcpp code it needs to, which is why your objection seems inappropriate
| to
|     >> me.
| >>
| >> On March 24, 2023 10:43:34 AM PDT, Dirk Eddelbuettel 
| >> wrote:
| >> >
| >> >On 24 March 2023 at 13:08, Matthew Supernaw - NOAA Federal wrote:
| >> >| I'm sure it's possible to do from the R side, however, the
| requirement
| >> is to
| >> >| hide this from the end user and set the reference objects name to 
the
| >> declared
| >> >| name from the R environment. If I view the environment in RStudio,
| >> there is
| >> >| much more information available. ls() only returns a list of objects
| by
| >> their
| >> >| declared name. I'm wondering how to get more details about elements
| in
| >> the
| >> >| environment.
| >> >
| >> >Thanks for additional color.  That may be a very interesting and
| valuable
| >> >question _for the C API of R_ and youe guess of "maybe Rcpp has a
| helper"
| >> is
| >> >a good one.  Sadly, I fear we may not have anything for you.
| >> >
| >> >Dirk
| >> >
| >> >--
| >> >dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >> >___
| >> >Rcpp-devel mailing list
| >> >Rcpp-devel@lists.r-forge.r-project.org
| >> 
>https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| >> --
| >> Sent from my phone. Please excuse my brevity.
| >>
| >
| >
| 
| --
| Sent from my phone. Please excuse my brevity.
| 
| 
| 
| --
| Matthew Supernaw
| Scientific Software Developer
| National Oceanic and Atmospheric Administration
| Office Of Science and Technology
| NOAA Fisheries | U.S. Department of Commerce
| Phone 248 - 396 - 7797
| 
| 

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Locating an Instance of a Reference Class in the Environment

[Dirk Eddelbuettel]

On 24 March 2023 at 13:08, Matthew Supernaw - NOAA Federal wrote:
| I'm sure it's possible to do from the R side, however, the requirement is to
| hide this from the end user and set the reference objects name to the declared
| name from the R environment. If I view the environment in RStudio, there is
| much more information available. ls() only returns a list of objects by their
| declared name. I'm wondering how to get more details about elements in the
| environment.

Thanks for additional color.  That may be a very interesting and valuable
question _for the C API of R_ and youe guess of "maybe Rcpp has a helper" is
a good one.  Sadly, I fear we may not have anything for you.  

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Locating an Instance of a Reference Class in the Environment

[Dirk Eddelbuettel]

On 22 March 2023 at 13:31, Matthew Supernaw - NOAA Federal wrote:
| I'm trying to get an instance of a reference class (vonBertalanffyInterface)
| from the R environment with the following code:
| 
| void SetName(vonBertalanffyInterface& v) {
| 
|     Rcpp::Environment env = Rcpp::Environment::global_env();
|     Rcpp::List l = Rcpp::as(env.ls(true));
| 
|     for (int i = 0; i < l.size(); i++) {
|         std::cout << typeid (l[i]).name() << std::endl;
|        
|         if( == l[i].get()){
|             v.name Rcpp::as(l[i]);
|         }
|     }
| }
| 
| The problem is that elements in the list are of type 
| N4Rcpp8internal13generic_proxyILi19ENS_15PreserveStorageEEE.
| 
| I'm assuming that PreserveStorage is a wrapper class. Is there a way to
| retrieve the reference class from the PreserveStorage object?

Interesting question.  Can you do it in plain R (once you created the object) ?

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Problem with RCPP Paralell

[Dirk Eddelbuettel]

Hi Roberto,

Very briefly:

1) We spell it Rcpp.  Capital R, lowercase cpp.

2) The package you inquire about is called RcppParallel.

3) You didn't list the repo making it harder for us to help you. As a little
   bit of GitHub searching reveals, it is here

   https://github.com/OVVO-Financial/NNS

4) It clearly compiles in the GitHub Actions but does not pass it
   tests. Maybe you should focus more on the failing tests first?

5) As it compiles the WARNINGs are not critical. ERRORS would be.

6) Small differences and details matters. You may need to look more closely
   and see which warnings come from code _in your package_ and are under your
   control, and which are from _libraries you may call_ over whose content
   you have less control.

7) If you ask for help with a particular example, it is most efficient (not
   to mention polite) to distill it, if possible, into a _small
   self-contained example_ that reproduces the same issue.  It may make
   addressing it easier than working with a full package and its dependencies.

Hope this helps a little,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] CRAN note about std::cout in shared library

[Dirk Eddelbuettel]

Hi Kassel,

On 7 February 2023 at 02:57, Kassel Hingee wrote:
| I'm running into CRAN check notes about std::cout being present in the Cpp 
code of a library I'm using.
| 
| Found ‘_ZSt4cout’, possibly from ‘std::cout’ (C++)
| 
| It looks like Rcpp is automatically redirecting the std::cout stream to 
Rcout, which is very handy and to my (shallow) understanding, solves the CRAN 
concern about where output from the package goes. However, I'm still getting 
the above CRAN check note.
|
| Does anyone know if CRAN will ignore this note, or if there is a way to avoid 
it without modifying the library?

There are two things here.  Years ago Rcpp got a clever pull request adding
Rcpp::Rcout and Rcpp::Rcerr.  We can (mostly) use these in lieu of std::cout
and std::cerr, and output will be redirected to R's as if Rprintf() and
REprintf() had been used as Writing R Extensions demands / suggests. We still
benefit from that PR.

So far so good. But in code you link against, you still need to ensure that
that code does not use std::cout etc either!  And that appears to have
happened here. And more or less the only choice you have is to find where
that use happens and to comment it out or alter it. There is no automated
solution or magic here, sadly.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RInline::repl() issues

[Dirk Eddelbuettel]

Dominick,

On 3 February 2023 at 20:02, Dominick Samperi wrote:
| I'm sorry to say that the RInline::repl() issues are not resolved, and to
| resolve them would likely require help from R core.
| 
| Here's the test case:
| library(sphereplot)
| rgl.sphgrid(longtype="D")
| 
| Under Linux there is no problem, a sphere is drawn, and you can
| rotate with mouse motions.
| 
| Under Windows using R, no problem.
| 
| But under Windows in RInline::repl() when you click on the image it
| freezes up.
| 
| Apparently some kind of graphics
| initialization is required, and perhaps callbacks as well to
| handle mouse events. Just calling run_Rmainloop() is not
| enough.

Maybe you want to talk to Duncan (CC'ed) about this, he just had a thread
about rgl and event loop issues on r-package-devel.

As earlier in this (or the preceding) thread, I am not yet _fully_ convinced
that what you are experiencing are in fact an Rcpp issue.  There is something
(a lot, actually) to be said about _minimally complete verifiable examples_.
As Rcpp maintainer, I am not sure if bringing rgl (a fine package, but also
"complicated" / "ambitious") in does still satisfy "minimally".

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] R_Interactive vs R_NoEcho

[Dirk Eddelbuettel]

On 2 February 2023 at 16:02, Simon Urbanek wrote:
| > On Feb 2, 2023, at 11:41 AM, Dirk Eddelbuettel  wrote:
| > Sounds like an r-devel question to me.  Nothing Rcpp related here.  Simon 
and
| > Tomas both hang out here so if you are lucky they may see it.  Else I'd try
| > over there.
| > 
| 
| We do ;). Well, the prompt is part of the echo - in R you can't have a prompt 
when you are not echoing the command since you'd just see > > > which is not 
very helpful. But I know nothing about RInside so can't comment on what you are 
trying to do.

You should look into RInside! It uses constructors (ie RAII) and destructor
behaviour to ensure proper set-up and wind-down of resources! Which are the
very same Rembedding features that, say, Rserve uses.  Was a great idea 15
years ago, and still is.  Unless you longjmp.

Which R does. So we go around pointing fingers at each other.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] R_Interactive vs R_NoEcho

[Dirk Eddelbuettel]

On 1 February 2023 at 17:23, Dominick Samperi wrote:
| Since I am not aware of an R-internals mailing list, and since this

AFAIK there is no such mailing list. There is a manual of that name:
https://rstudio.github.io/r-manuals/r-ints/  (nicer quarto rendered version)

Or did you mean the r-devel list?

| question is related to the behavior of RInside::repl(), perhaps this is the
| appropriate place to post this question.
| 
| The function Rstd_ReadConsole() in src/unix/sys-std.c results in the
| user command being echoed when R_Interactive = false,
| and R_NoEcho = false.
| 
| But if we set R_NoEcho = true to stop the echo, the prompt is also
| suppressed. Setting R_Interactive = true (with R_NoEcho = false)
| does not suppress the prompt, but it has other side-effects like
| enabling the final confirmation question. Again, if we set R_NoEcho = true
| there is no prompt.
| 
| So my question is: why does setting R_NoEcho=true turn off the prompt?

Sounds like an r-devel question to me.  Nothing Rcpp related here.  Simon and
Tomas both hang out here so if you are lucky they may see it.  Else I'd try
over there.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Package RMD check warning

[Dirk Eddelbuettel]

On 30 January 2023 at 18:11, Zheng, Binghan wrote:
| I’m preparing a package to be released through CRAN for Dr. Jacob Montgomery 
at WUSTL and I’m running into a warning that I can’t seem to resolve.
| 
| The RCMD check is being run in R 4.2.2 on MacOS.
| After running devtools::check() on the labelR package, it returns this 
warning:

I personally (and strongly) prefer the clarity of the R CMD ... commands over
the combination of obfuscations and convenience offered by other wrappers
(but yes I understand they are convenient and powerful--but harder to
debug). I would recommend you try to solve this with base commands.

|  checking dependencies in R code ... WARNING
|   'loadNamespace' or 'requireNamespace' call not declared from: ‘Rcpp’
|   Package in Depends field not imported from: ‘methods’

It's a guess as we cannot see your sources (if there is a GitHub (or alike)
repo, always post a link!) but I suspect you have a Depends: Rcpp when you
should have an Imports: Rcpp *and* also a standard line in NAMESPACE such as

   importFrom(Rcpp,evalCpp)

(where it doesn't matter _which_ function you tag, what matters is that the
package get imported at startup which intializes a few things that are
needed).  You need both.

| These packages need to be imported from (in the NAMESPACE file)
| for when this namespace is loaded but not attached.
| 
| @imports ‘Rcpp’ has been included in all relevant functions

You need  "@importFrom Rcpp sourceCpp"  to create the line above.  Again,
roxygen2 obfuscates here. I always documented it as 'better by hand'.

| It is currently in the scripts as requireNamespace(“Rcpp”) since we are using 
requireNamespace(“rstan”). We have tried loadNamespace(“Rcpp”) which did not 
resolve the issue.
| Imports(‘Rcpp’) is within NAMESPACE.
| Within the DESCRIPTION file, Rcpp is under Imports. We have tried moving it 
to Suggests, but that also did not resolve the issue. It’s unclear what the 
error is stemming from and we would appreciate any input to resolve this 
warning.

If in doubt, also try to look at a working package. For Rcpp you now have
well over 2600 to choose from at CRAN :)  As well as working package creators
that provide this.  You can always start from an empty package that you can
grow to contain your content.

Best, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp_precious_remove again (Windows)

[Dirk Eddelbuettel]

Maintainer of affected package here:

On 23 January 2023 at 12:20, Dominick Samperi wrote:
| On the changes for R 4.2.0, it is not clear how to distinguish
| R API functions from R internal functions (and this probably
| doesn't matter for Rcpp), but you are correct,
| on closer inspection these changes should not have effected
| the way R_DefParams() was used before R_DefParamsEx()
| was introduced.
| 
| It would be helpful if others could test to see if they can reproduce
| the problems I reported. I will submit a pull request when
| ready,

That would be really appreciated! It really sounds like we could do with an
update of some internals, and as seem to have spent some time in that corner
you are likely right now the most qualified person to do this.

| and if there is no objection, ifdefs will be included that
| permit compiling Rcpp and RInside using MSVC (there are only
| a few small changes with most of them applying to RInside.cpp).

I think that is out of scope, and should be not in the pull request, and
RInside repo.

By all means keep them in a branch / fork of yours if that is how you work,
but the RInside package is part of R ecosystem which has a well-established
empty intersection with the MSVC world and toolchains.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp_precious_remove again (Windows)

[Dirk Eddelbuettel]

On 21 January 2023 at 10:53, Dominick Samperi wrote:
| I've attached a version of RInside.cpp with my changes. The
| _MSC_VER ifdefs are for Video Studio, which I am using for
| debugging. I had some problems with gdb.

We would love to take advantage of your hard and diligent work in trying to
improve RInside here, but with all due respect and credit for all you have
done at the very beginning of Rcpp it is no longer 2004 or 2005 -- and
emailed copies of files do not cut it.

Please consider opening a pull request at GitHub so that your code and its
differences to the current version are easily visible, and can be commented
on by others, and get tested automagically.

I know that means work for you, but I very kindly to consider it, and I thank
you in advance for your consideration.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp_precious_remove again (Windows)

[Dirk Eddelbuettel]

On 20 January 2023 at 19:11, Dominick Samperi wrote:
| You are right Dirk, RInside overrides what is specified because the function
| myAskYesNo doesn't actually ask, so this explains why there is to
| termination
| prompt under Windows. This does not change what happens under Linux
| because this function is assigned to a Windows-specific callback. Under
| Linux the confirmation message appears.
| 
| The current status is that the example seems to work using R-devel,
| but not using R-4.2.2.

:-/

If you can narrow it down we'd appreciate it. If not, well, r-devel will be
r-release in the three months time.

And I don't think we have done any changes on the Windows side since before
UCRT with R 4.2.0.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp_precious_remove again (Windows)

[Dirk Eddelbuettel]

On 20 January 2023 at 10:28, Tomas Kalibera wrote:
| Executing then without R_LIBS set gave this error:
| 
| "
| Error: function 'Rcpp_precious_remove' not provided by package 'Rcpp'
| In addition: Warning message:
| In library(package, lib.loc = lib.loc, character.only = TRUE, 
| logical.return = TRUE,  :
|    there is no package called 'Rcpp'
| "
| 
| So I knew I had to set R_LIBS.

Very good catch.  The 'Rcpp_precious_remove' was spurious as I suspected all
along but it was trickily hiding the actual issue.  Any clever thought on how
we could check for missing .libPaths() etc when RInside starts?

On 20 January 2023 at 17:22, Tomas Kalibera wrote:
| On 1/20/23 16:35, Dominick Samperi wrote:
| > After fixing the library issue and getting the app running what 
| > happens when you terminate with q()?
| >
| > You should see the usual "Save workspace image? [y/n/c]:", and under 
| > Linux this is what happens.
| 
| The program just exits without asking.

I think you can control that by setting the 'interactive' toggle. From
memory, there is a global state variable reflecting the command-line choice
(or invocation) and IIRC the ctor may offer it. I have the same behaviour in
littler where we long ago decided to have interactive=false (because hey,
scripting) and that sometimes leads to slightly different outcomes so we have
an override there.  And RInside and littler are pretty close cousins.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp_precious_remove again (Windows)

[Dirk Eddelbuettel]

On 19 January 2023 at 19:41, Dominick Samperi wrote:
| I narrowed the problem down to the call to R_ReplDLLdo1() in RInside, and I
| built R-4.3.0 pre-release version for Windows from source to investigate
| further (online instructions by Tomas Kalibera were very helpful).

Yes Tomas is a master of many tools and deep source of tricks and general help.
 
| But the problem does not occur with this version of R! Note that the problem
| did not occur in some older versions of R either.
| 
| This version-dependence may be related to the fact that this function and
| others used by Rcpp/RInside are not part of the supported API for R, so the
| underlying implementation details for internals like external pointers may
| change.

Well I probably don't agree here.

Because (as per your Subject) 'Rcpp_precious_remove' is in this, as we had a
bit of transition to get to more effortlessly growing internal objects, I
still suspect (as per my first message in this thread) that you may have had
a cross of 'old' and 'new' approaches. A simple consisten recompilation
generally fixes that.  Per the NEWS.Rd we did the finaly clean up (a reset)
in 1.0.9. (We had improved unwind_protect since just after that release.)

But by all means, keep digging and look around if you think something is
suspicious there. It could well that we do something wrong on Windows, or
have another issue somewhere.  But I remain quite confident that things are
generally in good working order -- these RInside examples have all been
working fine more or less unchanged for close to a decade.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp_precious_remove again (Windows)

[Dirk Eddelbuettel]

Hi Dominick,

First reflex: uh-oh as 'Rcpp_precious_remove' created some headaches for some
people when mixing Rcpp and packages built with Rcpp but not the current one.
We think all this got squared away an Rcpp release or two ago so as a first
step please make sure _all_ involved packaes are current with CRAN and
rebuilt.

On 17 January 2023 at 21:15, Dominick Samperi wrote:
| I think I found a problem under Windows with the repl code from RInside.
| The problem appears if I simply compile the code in
| RInside/inst/examples/standard using the Makefile.win there,
| after a few hacks to deal with spaces in file names and the direction of
| slashes.

(A small and focused PR would be appreciated if there is some cleanup needed).
 
| The problem appears with the example rinside_interactive0.cpp, but to keep
| things simple I've stripped out just the repl code into repl.cpp. It is
| attached, along with a Makefile that works under Windows, with g++ from
| Rtool42, specifically,
| 
| set PATH=c:\Rtools42\x86_64-w64-mingw32.static.posic\bin;%PATH%
| 
| When repl.exe is run an extra window pops up, and there are random
| terminations, and sometimes a crash, especially if you try to plot
| something. The program immediately terminates after plotting.
| 
| None of this happens under Linux (Ubuntu), where the program works as
| expected.

Yes it built for me. And runs fine (under Ubuntu 22.10). I don't have Windows
around. 
 
| I tried installing gdb using 'pacman -Sy gdb' (following CRAN docs), and
| there were no apparent problems, but some of the DLL's had the wrong
| version, and gdb could not be started. (Missing DLL's were msys-ffi-8.dll
| and msys-unistring-5.dll.)

I wonder if instead of / in addition to gdb you could instrument your windows
binary to log copiously?

| I was able to build using Visual Studio, and in that case the app crashes
| immediately with a complaint about Rcpp_precious_remove. But here I could
| bring up a debugger and step trough code, and sure enough it crashes soon
| after the call
| GET_CALLABLE("Rcpp_precious_remove"). Stepping into this function leads to
| Microsoft code in thread_safe_statics.cpp that implements a critical
| section, suggesting
| that more than one thread is started.
| 
| I wonder if the problem is related to the fact that R is not thread safe?

That would bite Linux as well as Windows.
 
| Or could it be that the preserved objects are bigger under Windows?

I don't see how because relative to machine memory these objects are
still tiny,
 
| I'm working with Rcpp_1.0.9 and RInside_0.2.17, with R-4.2.2.

All good. Maybe rebuild RInside under that Rcpp just to be sure.

Cheers, Dirk

| 
| Thanks,
| Dominick
| x[DELETED ATTACHMENT repl.cpp, plain text]
| x[DELETED ATTACHMENT Makefile, Untyped binary data]
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Printing intermediate values in C++ code used in Rcpp

[Dirk Eddelbuettel]

Good -- but next time you ask _when you already are N messages in on another
help list_ have the courtesy to cross-reference the other thread.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Printing intermediate values in C++ code used in Rcpp

[Dirk Eddelbuettel]

On 17 December 2022 at 17:29, Christofer Bogaso wrote:
| Hi,
| 
| I am working with a package called
| 
| https://cran.r-project.org/src/contrib/GCPM_1.2.2.tar.gz
| 
| The source code contains C++ codes which are available in the src folder.
| 
| In this folder, the C++ codes are available in cpploss.cpp
| 
| In this cpp file, there is a function like below,
| 
| #ifdef _OPENMP
| #include 
| #endif
| // [[Rcpp::depends(RcppProgress)]]
| #include 
| #include "cpploss.h"
| #include 
| #include 
| #include 
| 
| using namespace Rcpp;
| 
| // [[Rcpp::export]]
| SEXP  GCPM_cpploss(SEXP default_distr_a,SEXP link_function_a, SEXP
| S_a,SEXP Sigma_a, SEXP W_a, SEXP PD_a, SEXP PL_a, SEXP calc_rc_a, SEXP
| loss_thr_a, SEXP max_entries_a){
|   NumericMatrix S(S_a), W(W_a),Sigma(Sigma_a);
|   NumericVector PD(PD_a),
| 
PL(PL_a),max_entries(max_entries_a),default_distr(default_distr_a),link_function(link_function_a),calc_rc(calc_rc_a),loss_thr(loss_thr_a);
|   List ret;
| 
| etc.
| 
| However as I run this C++ codes, I want to print some intermediate
| values generated by underlying C++ codes for some debugging purposes.
| So I added below line (just an example)
| 
| Rcpp::Rcout << "Some Value" << std::endl << 1.23 << std::endl;
| 
| After adding this line, then after re-building the package and
| re-installng it, when I run the R code, I dont get above line printed
| in the R console.

Then you are running a different build of the package. The statement, if
unconditional, _will_ print.  Check your setup.

  > Rcpp::cppFunction('void foo() { Rcpp::Rcout << "boo" << std::endl; }')
  > foo()
  boo
  >

I am currently working a lot with a new package spdl for just this: logging.

  > Rcpp::cppFunction('void spdlfoo() { spdl::debug("Something {} or other {}", 
42, "zing"); }', depends="RcppSpdlog", include="#include ")
  > spdl::setup("demo", "warn")  # new logger 'demo' at level 'warn'
  > spdlfoo()   # not shown as 'debug' < 'warn'
  > spdl::set_level("debug")  # lower the level
  > spdlfoo()   # now shown 
  [2022-12-17 08:13:50.491] [demo] [Process: 3817047] [debug] Something 42 or 
other zing
  > 

Of course you normally want that in a package. Import spdl, and LinkingTo
RcppSpdlog (which came first) does that, more in the vignette of RcppSpdlog.
 
| Could you please help how can I get designated intermadiate values
| printed in my R console when I run the R/C++ code?
| 
| Additionally, what is the meaning of the statements like NumericVector
| PD(PD_a) etc? I understand that PD_a is the function argument. But
| what is the meaning of PD(PD_a)?

Instantiate a new object named 'PD' from an object named 'PD_a'.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] C++ issue only spotted by CRAN and not locally or via rhub

[Dirk Eddelbuettel]

On 5 December 2022 at 16:34, Martyn Plummer wrote:
| That's the good news. The bad news is that you have a lot of memory leaks,
| so this is still not going to pass R CMD check with ASAN. You're going to
| need Dirk's container.

Yes, and I was actually pointing at Winston's container, and it too has
`valgrind` instrumentation.  (But if you are on Linux you can just add the
valgrind invocation to R CMD check: see `--use-valgrind`. It already helps.)

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] C++ issue only spotted by CRAN and not locally or via rhub

[Dirk Eddelbuettel]

On 5 December 2022 at 11:32, Sokol Serguei wrote:
| I don't know what the exact source of this problem is but I can suggest 
| to use Armadillo which has a reputation to be better suited for 
| matrix/vector operation than plain Rcpp.

I second that. Rcpp is great for what it does (easy integration from/to,
extensibility, ...) but the NumericVector / NumericMatrix class are (on
purposes) not built up for fancier higher-level operations such as linear
algebra etc as other packages already do this 'best in class'. RcppArmadillo
is very good and easy to use for all things linear algebra, RcppEigen also
has its fans for related and possibly somewhat broader use.

The other issue is ASAN. This can be tedious to set, so I once created Docker
containers for it (that still exist) but other jumped in and maintain(ed)
daily builds of those. Gabor has some via r-hub, and Winston built a
composite container with several such debug variants:
   https://github.com/wch/r-debug

Make sure you call the various RD* variants of R, and use them to install
your dependencies / test your package. Docker looks a little insurmountable
at first but it is not so bad.  E.g. running

   docker run --rm -ti -v $PWD:/mnt -w /mnt wch/r-debug bash

call this container in your current working directory (say: your repo) and
lets you work with your code and the *SAN debug builds of R. It's worth it!

Hth, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp equivalent for Python?

[Dirk Eddelbuettel]

On 3 December 2022 at 15:08, Sparapani, Rodney wrote:
| I have a tangential question.  We have several R packages
| based on Rcpp to call C++ code.  Rcpp makes it so easy!
| However, I am often asked by Python users: can we make
| similar packages for that platform?  I’m a newb with
| respect to Python (after 30 years with S/R and C++ I am
| still learning!)  So, I have a question.  Is there something
| like an equivalent with respect to Rcpp for Python?
| By that I mean, I want to call C++ code from Python
| with the ability to pass R-like objects, or similar, to C++.
| Exposing the Python RNG to C++ would also be
| extremely helpful.  Please let me know.  Thanks

pybind11 comes to mind but because Python has a richer set of base types (and
other differences) there is no one-to-one match to Rcpp.

The thread is off-topic here so let's maybe try to keep the list focussed.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Unaligned access [Was: Report of CRAN compilation problem and solution with architecture arm64]

[Dirk Eddelbuettel]

Juan,

Further to Simon's comment, why is this on the rcpp-devel list?  We have
exactly zero choice over compiler and architecture use at CRAN.

Maybe try r-devel and/or CRAN and/or R Core, but as Simon hinted that may be
an uphill battle too.

Best, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Something strange with the package check and calls to C abort

[Dirk Eddelbuettel]

On 31 October 2022 at 11:01, Kevin Ushey wrote:
| For posterity, what machine are you compiling the package on? If you're
| using a modern Linux system, it's possible the default compilation flags
| are including stack protection code during compilation that might call
| abort on error. See e.g.
| 
| 
https://developers.redhat.com/articles/2022/06/02/use-compiler-flags-stack-protection-gcc-and-clang

Not to get into distro wars ... but over here where I build I had the benefit
of kernel and compiler savvy people setting up defaults for many years now.

Without ever creating a single issue for my (rather frequent) R package
checking. All this is just to say that Debian and Ubuntu have treated me well.
 
| It might be useful if you could share your package / the code used when
| compiling the C++ code in your package.

Indeed. It generally never hurts to let other people have a peek.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Something strange with the package check and calls to C abort

[Dirk Eddelbuettel]

On 29 October 2022 at 20:41, Juan Domingo Esteve wrote:
|   I am new to this list and I am using Rcpp for my first large and serious 
package, so

No worries. "By construction" we all were at that point at some point in the 
past.

| I apologize if probably this is a naive question, but I have browsed the web 
and looked
| at the stored mail messages of this list from the beginning of this year 
without finding
| an answer.
| 
|   My package passed the checks and I was about to try uploading to CRAN but 
this morning
| I have updated all R packages (including Rcpp and devtools) and now the 
package fails the
| check because of two warnings. These are
| 
| Found ‘abort’, possibly from ‘abort’ (C)
|Objects: ‘RcppExports.o’, ‘fullmatrix.o’, ‘jmatrix.o’,
|  ‘matgetcols.o’, ‘matgetdiag.o’, ‘matgetrows.o’, ‘matmetadata.o’,
|  ‘matwrite.o’, ‘memhelper.o’, ‘sparsematrix.o’,
|  ‘symmetricmatrix.o’, ‘teststop.o’
|  Found ‘printf’, possibly from ‘printf’ (C)
|Objects: ‘RcppExports.o’, ‘fullmatrix.o’, ‘jmatrix.o’,
|  ‘matgetcols.o’, ‘matgetdiag.o’, ‘matgetrows.o’, ‘matmetadata.o’,
|  ‘matwrite.o’, ‘memhelper.o’, ‘sparsematrix.o’,
|  ‘symmetricmatrix.o’, ‘teststop.o’
| 
| I don't call abort, exit or any similar C library function and all my
| interaction are through Rcpp::Rcout, Rcpp::Rcerr, Rcpp::warning and
| Rcpp::stop.
| 
| After some checks, I have found that this happens when I use
| Rcpp::warning and Rcpp::stop. Indeed, with a code like this in testtstop.cpp
| 
| #include 
| 
| void test()
| {
|   Rcpp::Rcout << "This is the standard output\n";
|   Rcpp::Rcerr << "This is the standard error\n";
|   Rcpp::warning("This is a warning\n");
|   Rcpp::stop("This should stop the program.\n");
|   return;
| }
| 
| the object teststop.o disappears from the list of those which annoy
| devtools:check when I comment the lines with Rcpp::warning and Rcpp::stop.

Simplify.  Only use devtools::check() when you are positively sure you know
what it is doing. If in doubt rely only on R CMD build + R CMD check.

A package containing (only) that file above should NOT warn. If it does,
something else is wrong.

Also, using such a minimal package is very good practice. Isolating errors is
the key to debugging.
 
| As a last resort, I have tried to download the sources of the Rcpp
| package itself and compile/check in the same way, to convince myself
| that the failure might be there. And indeed, I have got this:
| 
| W  checking compiled code ...
| File ‘Rcpp/libs/Rcpp.so’:
|   Found ‘abort’, possibly from ‘abort’ (C)
| Objects: ‘attributes.o’, ‘module.o’
|   Found ‘printf’, possibly from ‘printf’ (C)
| Objects: ‘attributes.o’, ‘module.o’
| 
| Compiled code should not call entry points which might terminate R nor
| write to stdout/stderr instead of to the console, nor use Fortran I/O
| nor system RNGs.

Well now if we look at the (official !!) page

   https://cran.r-project.org/web/checks/check_results_Rcpp.html

we see no such warnings. Nor do I here. So you have to be a bot more
forthcoming in how you created those.

| An abort function is effectively called from file inst/include/Rcpp/r_cast.h
| at lines 75 and 129.
| 
| Might this be the cause of the check failure?

No.

| I know that this seems more a problem from devtools:check than from Rcpp, but
| it is much more likely that I am totally misunderstanding the question, since

Yes.

| this would prevent any package done with Rcpp to be uploaded to CRAN and many
| people would have already noticed.
| 
|   So again, I reiterate my apologies and if you are so kind to point me to
| appropriate documentation to solve the issue, I would be very grateful.

Start with simpler, more self contained examples. Use the tested and
prescribed tools (neither 'Writing R Extensions' by R Core nor our
documentation mentions or suggests devtools as far as I know).

Minimal examples *are* helpful. When I needed to be sure I (re-)created UBSAN
or ASAN errors I created the sanitizers package with known *true positives*
ensure I could validate my test case.

Here you will see that simple use of

   std::cout
   std::cerr
   print
   abort
   exit

are all sufficient to create this error. And guess what: you will not find
them in the Rcpp sources.

Good luck, and keep probing. It is worth it.

Cheers, Dirk

|   Sincerely
| 
|Juan
| -- 
| 
| Juan Domingo Esteve
| Dept. of Informatics, School of Engineering
| University of Valencia
| Avda. de la Universidad, s/n.
|  46100-Burjasot (Valencia)
| SPAIN
| 
| Telephone:  +34-963543572
| Fax:+34-963543550
| email:  juan.domi...@uv.es
| 
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| 

Re: [Rcpp-devel] thread safety RNG

[Dirk Eddelbuettel]

Hi Konrad,

I have been meaning to look at ast2ast for some time now but alas no time
yet...

On 21 October 2022 at 12:15, konrad wrote:
| my package ast2ast includes currently some random number generation 
| functions (e.g. R::dunif) within the C++ code.
| 
| So my question is whether the RNG functions in the namespace 'R' are 
| thread safe?

It's been a while since I worked that corner but my initial reactions are
 - nope sadly they are not (AFAIK)
 - have you seen what 'Writing R Extensions' says on RNG state?
 - this is why we have streaming / multi-threaded RNGs on CRAN
 
| Moreover, I would like to know how to handle the functions GetRNGstate() 
| and PutRNGstate(). I guess that these functions modify a global 
| variable. Thus, it is necessary to lock these functions with a mutex.

Don't you need a mutex for all of R anyway? (Depending on whether you can in
or out I guess.) Put differently, 'all of R' is in a mutex as R is
(generally) single-threaded (with a few local threaded overlays in places). 

| As a side note ast2ast translates R to C++ code. This code is thread 
| safe in the sense that no static methods are implemented or that memory 
| is associated with functions or global variables. Therefore, it would 
| also be cool if the RNGs could abe used in parallel.

Maybe start by seeing what Writing R Extension recommends and experiment with
an even narrow layer of just C to exclude any Rcpp side effect (there should
not be any but smaller sandboxen help on exploration I have found).

Lastly, RcppParallel is a little bit in this space to by offering very
explicit use of TBB / tinythread as does RcppThread by Thomas (but I am less
familiar with it).

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] sourceCpp with RcppEigen?

[Dirk Eddelbuettel]

On 10 October 2022 at 09:16, Dirk Eddelbuettel wrote:
| 
| On 10 October 2022 at 14:02, Sparapani, Rodney wrote:
| | I’m wondering what it would take to make RcppEigen functions
| | work wth sourceCpp?  Please let me know.  Thanks
| 
| The standard one line: add`// [[Rcpp::depends(RcppEigen)]]`

I.e. here is (verbatim) what README.md has:



### Examples

A few examples are over at the [Rcpp 
Gallery](https://gallery.rcpp.org/tags/eigen/). A simple one is

```c++
#include 

// [[Rcpp::depends(RcppEigen)]]

using Eigen::Map;   // 'maps' rather than copies
using Eigen::MatrixXd;  // variable size matrix, double 
precision
using Eigen::VectorXd;  // variable size vector, double 
precision
using Eigen::SelfAdjointEigenSolver;// one of the eigenvalue solvers

// [[Rcpp::export]]
VectorXd getEigenValues(Map M) {
SelfAdjointEigenSolver es(M);
return es.eigenvalues();
}
```

which can be turned into a function callable from R via a simple

```
sourceCpp("eigenExample.cpp")
```

due to the two Rcpp directives to use headers from the RcppEigen package, and 
to export
the `getEigenValues()` function -- but read [the full
post](https://gallery.rcpp.org/articles/eigen-eigenvalues/) for details.


Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] sourceCpp with RcppEigen?

[Dirk Eddelbuettel]

On 10 October 2022 at 14:02, Sparapani, Rodney wrote:
| I’m wondering what it would take to make RcppEigen functions
| work wth sourceCpp?  Please let me know.  Thanks

The standard one line: add`// [[Rcpp::depends(RcppEigen)]]`

We have been doing this in that very documented and visible way for about a
decade (!!) since Rcpp Attributes was added, and overall pretty much since
the very beginning because plugins (via the `inline` package) have been a
part of Rcpp much longer.  Just look around at existing examples.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Use cholmod modify module in an Rcpp / RcppEigen package

[Dirk Eddelbuettel]

Salut Etienne,

Sorry for missing this email yesterday.

On 5 October 2022 at 12:35, etienne.c...@univ-eiffel.fr wrote:
| I want to use the cholmod functions from the modify module 
https://github.com/PetterS/SuiteSparse/tree/master/CHOLMOD/Modify inside an 
Rcpp/RcppEigen R package. 
| 
| >From my understanding, these functions are not exposed by Rcpp or RcppEigen 
but RcppEigen expose a subset of cholmod functionalities via the 
RcppEigenCholmod header 
(https://github.com/RcppCore/RcppEigen/blob/master/inst/include/RcppEigenCholmod.h)
 and the actual sources come from the Matrix package 
https://github.com/cran/Matrix/tree/master/src/CHOLMOD. 

Right. All this goes back to careful work by Doug back when his hierarchical
model code predominantly relied on (Rcpp)Eigen.

| I've checked that the modify module is present in the src folder of the 
Matrix package https://github.com/cran/Matrix/tree/master/src/CHOLMOD/Modify 
but I'm lost on how to proceed in order to be able to use it. 
| Any help on the best way to achieve this will be greatly welcome. 

Well that is a different package, namely Matrix.

We have some examples of sharing / exporting code between packages.  But to a
very first approximation ... if you just want to get going, maybe make a copy
of Modify/ in your package?  Assumming, of course, there are no conflicts
with the other exported interfaces from Matrix and RcppEigen.

Best regards,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] cost of .Call

[Dirk Eddelbuettel]

Hi Konrad,

On 10 August 2022 at 08:22, konrad wrote:
| I have a question regarding the cost of .Call. If I implement the 
| rosenbrock function in R and in Rcpp. The R version is substentially 
| faster then the C++ version. The Rcpp function is basically an R 
| function which calls the C++ function using .Call. Which part of the 
| code generates this overhead of the Rcpp function. Is it the .Call 
| itself or the conversion of the types from R to Rcpp? Or have I done 
| something wrong?

It's just a not a meaningful benchmark as there are essentially no operations
on the R side either.

And Rcpp, by making it _convenient_ injects some extra code and tests and
state keeping all of which is documented and for which you have some toggles
to suppress at least parts.

But in short, it's a non-question. By all means keep exploring Rcpp but you
will need something meatier for it to make sense. You should have no problem
finding examples.

Cheers, Dirk

| 
| library(Rcpp)
| library(microbenchmark)
| 
| 
| fr <- function(x) {   ## Rosenbrock Banana function
|    x1 <- x[1]
|    x2 <- x[2]
|    100 * (x2 - x1 * x1)^2 + (1 - x1)^2
| }
| 
| sourceCpp(code = "
| #include 
| 
| // [[Rcpp::export]]
| double fr_rcpp(Rcpp::NumericVector x) {
|    double x1 = x[0];
|    double x2 = x[1];
|    return 100 * (x2 - x1 * x1)*(x2 - x1 * x1) + (1 - x1)*(1 - x1);
| }
| ")
| 
| x <- c(1, 2)
| identical(fr(x), fr_rcpp(x))
| 
| r <- microbenchmark(fr(x), fr_rcpp(x))
| boxplot(r)
| 
| 
| Thank you very much for your help!
| 
| 
| All the best,
| 
| 
| Konrad
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Help reading libzma file

[Dirk Eddelbuettel]

On 23 June 2022 at 20:46, Roberto Spadim wrote:
| Uhm, yes I see
| I testd with package, and linux, it works
| But with Windows it don't find the liblzma

"Par for the course" as they say -- Windows has not standard library location
so you will need an 'extra convention' as either the CRAN rules of installing
a bunch of library in one jointly accessed directory, or by following
per-library environment variables. Here is what RcppGSL does for GSL:

PKG_CPPFLAGS= -I../windows/gsl-2.7/include -I../inst/include
PKG_LIBS= -L../windows/gsl-2.7/lib${R_ARCH}${CRT} -lgsl -lgslcblas

all: clean winlibs

winlibs:
"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" "../tools/winlibs.R"

clean:
rm -f $(SHLIB) $(OBJECTS)

ie it can just assume GSL is present. CRAN documents somewhere what libraries
yu can expect; I cannot from the top of my head recall if LZMA is part of
that set.

Portable development is hard for a reason. Operating systems are idiosyncratic.

Dirk

| 
| Em qui., 23 de jun. de 2022 às 07:59, Dirk Eddelbuettel 
| escreveu:
| 
| >
| > On 23 June 2022 at 10:05, Serguei Sokol wrote:
| > | Le 23/06/2022 à 04:07, Roberto Spadim a écrit :
| > | > Hi folks
| > | >
| > | > I have a .xz file and need to read it and "convert" to a DataFrame
| > using
| > | > Rcpp if possible.
| > | >
| > | > But... I'm with a problem (first time testing this) using liblzma with
| > | > Rcpp, I already know how to do this with CMakeLists.txt, but I don't
| > | > know how to do with RCpp
| > | >
| > | > Anyone have an idea?
| > | You have to use Makevars file, either in src/ or in $HOME/.R/ dir.
| > | In this file you have to add something like:
| > |
| > |PKG_CPPFLAGS += -I
| > |PKG_LDFLAGS += -L -llzma
| > |
| > | To make this solution portable, you can want to use configure script
| > | which usage is described in WRE
| > |
| > 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
| > |
| > | Best,
| > | Serguei.
| > |
| > | >
| > | > Output from compile time:
| > | >
| > | >  > sourceCpp("D:/Trabalho/FTDB-R/FTDB/src/ftdbR.cpp")
| >
| > And you want to look into using a package, not `sourceCpp()` which is
| > designed for more one-off interactive work.
| >
| > You can start a package with the `Rcpp.package.skeleton()` function, and
| > then
| > add a src/Makevars as correctly suggested by Serguei.  There are also many
| > example Rcpp on CRAN, GitHub and other places to look at.  The `qs` and
| > `fst`
| > packages both cover compression too (but do a lot more...), I can't right
| > now
| > think of a simpler package adding just one compressor but there may well
| > be one.
| >
| > Regards, Dirk
| >
| > | > /mingw64/bin/g++ -std=gnu++11  -I"C:/PROGRA~1/R/R-41~1.2/include"
| > | > -DNDEBUG
| > -I"C:/Users/rspadim/Documents/R/win-library/4.1/Rcpp/include"
| > | > -I"D:/Trabalho/FTDB-R/FTDB/src"
| > -I"D:/Trabalho/FTDB-R/FTDB/inst/include"
| > | > -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c
| > | > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.cpp -o
| > | > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.o
| > | > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.cpp:5:10: fatal error:
| > lzma.h:
| > | > No such file or directory
| > | >   #include 
| > | >^~~~
| > | > compilation terminated.
| > | > make: *** [C:/PROGRA~1/R/R-41~1.2/etc/x64/Makeconf:245:
| > | > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.o] Error 1
| > | > Error in sourceCpp("D:/Trabalho/FTDB-R/FTDB/src/ftdbR.cpp") :
| > | >Error 1 occurred building shared library.
| > | > In addition: Warning message:
| > | > In normalizePath(path.expand(path), winslash, mustWork) :
| > | >path[1]="D:/Trabalho/FTDB-R/FTDB/src/../inst/include": O sistema
| > não
| > | > pode encontrar o caminho especificado
| > | >
| > | >
| > | > ___
| > | > Rcpp-devel mailing list
| > | > Rcpp-devel@lists.r-forge.r-project.org
| > | >
| > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| > |
| > | ___
| > | Rcpp-devel mailing list
| > | Rcpp-devel@lists.r-forge.r-project.org
| > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| > --
| > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >
| 
| 
| -- 
| Roberto Spadim
| SPAEmpresarial - Software ERP/Scada
| Eng. Automação e Controle, Eng. Financeira

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp shared libraries (?)

[Dirk Eddelbuettel]

One belated follow-up:  one can in general control visibility so

- a function can be in C(++) and used by other C(++) functions
  (and we have examples)

- a function can be exported to R easily via [[Rcpp::export()]] thanks to
  magic of Rcpp::compileAttributes()

- a function can also be "privatedly" exported to R using a name starting
  with a dot such as [[Rcpp::export(.myfunc)]]

- once at the R level we have the usual NAMESPACE control, also via roxygen2
  and its @export tag

When something like this seems to 'stumble' with a larger package, it is
sometimes worthwhile to experient quickly with a minimal throw-away package
as the mechanism is strictly the same and when it works for one...

Cheers, Dirk


-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Help reading libzma file

[Dirk Eddelbuettel]

On 23 June 2022 at 10:05, Serguei Sokol wrote:
| Le 23/06/2022 à 04:07, Roberto Spadim a écrit :
| > Hi folks
| > 
| > I have a .xz file and need to read it and "convert" to a DataFrame using 
| > Rcpp if possible.
| > 
| > But... I'm with a problem (first time testing this) using liblzma with 
| > Rcpp, I already know how to do this with CMakeLists.txt, but I don't 
| > know how to do with RCpp
| > 
| > Anyone have an idea?
| You have to use Makevars file, either in src/ or in $HOME/.R/ dir.
| In this file you have to add something like:
| 
|PKG_CPPFLAGS += -I
|PKG_LDFLAGS += -L -llzma
| 
| To make this solution portable, you can want to use configure script 
| which usage is described in WRE 
| 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
| 
| Best,
| Serguei.
| 
| > 
| > Output from compile time:
| > 
| >  > sourceCpp("D:/Trabalho/FTDB-R/FTDB/src/ftdbR.cpp")

And you want to look into using a package, not `sourceCpp()` which is
designed for more one-off interactive work.

You can start a package with the `Rcpp.package.skeleton()` function, and then
add a src/Makevars as correctly suggested by Serguei.  There are also many
example Rcpp on CRAN, GitHub and other places to look at.  The `qs` and `fst`
packages both cover compression too (but do a lot more...), I can't right now
think of a simpler package adding just one compressor but there may well be one.

Regards, Dirk

| > /mingw64/bin/g++ -std=gnu++11  -I"C:/PROGRA~1/R/R-41~1.2/include" 
| > -DNDEBUG   -I"C:/Users/rspadim/Documents/R/win-library/4.1/Rcpp/include" 
| > -I"D:/Trabalho/FTDB-R/FTDB/src" -I"D:/Trabalho/FTDB-R/FTDB/inst/include" 
| >         -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c 
| > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.cpp -o 
| > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.o
| > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.cpp:5:10: fatal error: lzma.h: 
| > No such file or directory
| >   #include 
| >            ^~~~
| > compilation terminated.
| > make: *** [C:/PROGRA~1/R/R-41~1.2/etc/x64/Makeconf:245: 
| > D:/Trabalho/FTDB-R/FTDB/src/xz/xz/decode.o] Error 1
| > Error in sourceCpp("D:/Trabalho/FTDB-R/FTDB/src/ftdbR.cpp") :
| >    Error 1 occurred building shared library.
| > In addition: Warning message:
| > In normalizePath(path.expand(path), winslash, mustWork) :
| >    path[1]="D:/Trabalho/FTDB-R/FTDB/src/../inst/include": O sistema não 
| > pode encontrar o caminho especificado
| > 
| > 
| > ___
| > Rcpp-devel mailing list
| > Rcpp-devel@lists.r-forge.r-project.org
| > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| 
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Assertion error in ud_ep.c, when running with MPI

[Dirk Eddelbuettel]

On 14 June 2022 at 09:38, Serguei Sokol wrote:
| Hi,
| 
| Probably, this issue would be better posted here 
| https://github.com/openucx/ucx/issues

Seconded. I don't have much to add: these MPI examples are ten years old,
worked all the time as far as we know, and haven't changed. Maybe some base
assumption in the libraries is different.

And if I may, I am not sure how much you are gaining here. You are fitting
each time series individually with R. That won't be fast.  You will not gain
something -- but maybe not_that_ much -- by spreading MPI around it. If speed
is of the essence, maybe you need an equivalent of auto.arima in compiled code.

As a debugging measure, I'd also try to see if the issue goes away when you
call less demaning R code: maybe auto.arima leads to multithreaded code
inside each call which may upset the R stack called from MPI?

Also, rinside_mpi_sample4.cpp is (per the one-commit in its history) a
contributed example. Maybe its authors can help.

Sorry, no smoking gun or immediate help.

Dirk

| Best,
| Serguei.
| 
| Le 14/06/2022 à 07:24, Maddegedara Lalith a écrit :
| > Hello,
| > 
| > I want to use RInside in my C++ based MPI application to do time series 
| > forecasting using the auto.arima library of R. The RInside instance in 
| > each MPI rank is expected to do an independent calculation (e.g. time 
| > series forecast).
| > 
| > With one MPI rank, it always completes without producing any error.  
| > However, with more than 1 mpi ranks, it produces the following error. 
| > Depending on the run, different numbers of mpi ranks produce the same 
| > error. On rare occasions, all the ranks successfully complete the 
| > execution. Further, I found that even your example 
| > "rinside_mpi_sample4.cpp" produces the same error.
| > 
| > I am using the Intel MPI library (version 2021.1). I tried 
| > compiling with icpc and g++. Both produced the same error.
| > Could you please help me to solve this problem.
| > 
| > With best regards
| > Lal
| > 
| > [ibis:14878:0:14992]       ud_ep.c:565  Assertion `ep->dest_ep_id == 
| > UCT_UD_EP_NULL_ID || ep->dest_ep_id == ctl->conn_rep.src_ep_id' failed
| > 
| >  backtrace (tid:  14994) 
| >   0 0x0004d455 ucs_debug_print_backtrace()  ???:0
| >   1 0x00042b5f uct_ud_ep_process_rx()  ???:0
| >   2 0x000471cd uct_ud_mlx5_ep_t_delete()  ???:0
| >   3 0x0003ebdf uct_ud_iface_release_desc()  ???:0
| >   4 0x00040436 ucs_cpu_get_memcpy_bw()  ???:0
| >   5 0x0004050b ucs_cpu_get_memcpy_bw()  ???:0
| >   6 0x00041343 ucs_async_dispatch_handlers()  ???:0
| >   7 0x00041488 ucs_async_dispatch_timerq()  ???:0
| >   8 0x00043c34 ucs_async_pipe_drain()  ???:0
| >   9 0x7ea5 start_thread()  pthread_create.c:0
| > 10 0x000fe96d __clone()  ???:0
| > =
| > 
| > ___
| > Rcpp-devel mailing list
| > Rcpp-devel@lists.r-forge.r-project.org
| > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| 
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] [R-pkg-devel] moving from C to C++ with Rcpp in R package

[Dirk Eddelbuettel]

On 2 June 2022 at 19:27, Jean Thioulouse wrote:
| 
| But it seems that the C_ prefix must be added to _myPackage_myFunctionName 
(to get for example C__ade4_RVrandtestCpp) in the RcppExports.R file. So where 
should I modify the Rcpp::export tag ?

Just how I wrote it below: inside the parens of the Rcpp::export tag.

A full worked example is

   #include 

   // [[Rcpp::export(C_foo)]]
   bool foo() {
 return true;
   }

   /*** R
   C_foo()
   */


which when I sourceCpp() it does indeed do as it is told:

   > Rcpp::sourceCpp("/tmp/foo.cpp")

   > C_foo()
   [1] TRUE
   > 

A quick grep here did not reveal an actual example of where I prefix with C_
but for example in the RcppSimdJson package we use this a little bit to
massage function names and control what is, or isn't, visible and exported on
the R side:

   edd@rob:~/git$ grep Rcpp::export rcppsimdjson/src/*cpp
   rcppsimdjson/src/deserialize.cpp:// [[Rcpp::export(.deserialize_json)]]
   rcppsimdjson/src/deserialize.cpp:// [[Rcpp::export(.load_json)]]
   rcppsimdjson/src/deserialize.cpp:// [[Rcpp::export(.exceptions_enabled)]]
   rcppsimdjson/src/exported-utils.cpp:// [[Rcpp::export(is_valid_json)]]
   rcppsimdjson/src/exported-utils.cpp:// [[Rcpp::export(is_valid_utf8)]]
   rcppsimdjson/src/exported-utils.cpp:// [[Rcpp::export(fminify)]]
   rcppsimdjson/src/internal-utils.cpp:// [[Rcpp::export(.is_valid_json_arg)]]
   rcppsimdjson/src/internal-utils.cpp:// [[Rcpp::export(.is_valid_query_arg)]]
   rcppsimdjson/src/internal-utils.cpp:// [[Rcpp::export(.diagnose_input)]]
   rcppsimdjson/src/rcppsimdjson_utils_check.cpp:// 
[[Rcpp::export(.check_int64)]]
   rcppsimdjson/src/simdjson_example.cpp:// [[Rcpp::export(.validateJSON)]]
   rcppsimdjson/src/simdjson_example.cpp:// [[Rcpp::export]]
   rcppsimdjson/src/simdjson_example.cpp:// [[Rcpp::export(.cppVersion)]]
   rcppsimdjson/src/simdjson_example.cpp:// 
[[Rcpp::export(.unsupportedArchitecture)]]
   edd@rob:~/git$ 

Hope this helps,  Dirk


| Thanks
| Jean
| 
| 
| > Le 2 juin 2022 à 15:49, Dirk Eddelbuettel  a écrit :
| > 
| > 
| > On 2 June 2022 at 08:32, Dirk Eddelbuettel wrote:
| > | 
| > | (Removed CC to r-package-devel)
| > | 
| > | On 2 June 2022 at 16:24, Ivan Krylov wrote:
| > | | Unfortunately, this means editing RcppExports.R, which (I think)
| > | | prevents you from enjoying the way Rcpp::compileAttributes() sets
| > | | everything up for you.
| > | 
| > | Yes. I think that is the best I came up with once too in a time of need 
in a
| > | package actively mixing C and C++.  It simply is easier to have just C++, 
and
| > | I think you generally can just convert your C files.
| > 
| > PS  One thing that works is to rename in the Rcpp::export tag ie
| > 
| >   // [[Rcpp::export(C_my_func_name)]]
| > 
| > can be used to prefix C_ to a function my_func_name().
| > 
| > Dirk
| > 
| > -- 
| > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > ___
| > Rcpp-devel mailing list
| > Rcpp-devel@lists.r-forge.r-project.org
| > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| 

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] [R-pkg-devel] moving from C to C++ with Rcpp in R package

[Dirk Eddelbuettel]

On 2 June 2022 at 08:32, Dirk Eddelbuettel wrote:
| 
| (Removed CC to r-package-devel)
| 
| On 2 June 2022 at 16:24, Ivan Krylov wrote:
| | Unfortunately, this means editing RcppExports.R, which (I think)
| | prevents you from enjoying the way Rcpp::compileAttributes() sets
| | everything up for you.
| 
| Yes. I think that is the best I came up with once too in a time of need in a
| package actively mixing C and C++.  It simply is easier to have just C++, and
| I think you generally can just convert your C files.

PS  One thing that works is to rename in the Rcpp::export tag ie

   // [[Rcpp::export(C_my_func_name)]]

can be used to prefix C_ to a function my_func_name().

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] [R-pkg-devel] moving from C to C++ with Rcpp in R package

[Dirk Eddelbuettel]

(Removed CC to r-package-devel)

On 2 June 2022 at 16:24, Ivan Krylov wrote:
| Unfortunately, this means editing RcppExports.R, which (I think)
| prevents you from enjoying the way Rcpp::compileAttributes() sets
| everything up for you.

Yes. I think that is the best I came up with once too in a time of need in a
package actively mixing C and C++.  It simply is easier to have just C++, and
I think you generally can just convert your C files.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Doubt about best pratices

[Dirk Eddelbuettel]

This is not a well-posed Rcpp question as

- matrix and data.frame are _fundamentally_ two different data types

- matrix being _one_ and only one storage type, or class, stored
  as one vector with dimension attribute of size two for rows and cols;
  this makes it _efficient_ and you will see a matrix type used quite a bit
  in internal R functions

- data.frame being a special case of the catch-all type list with each
  column being of same length but possibly different types -- and for that
  reason we do not have too much tooling for this 'list of vectors' in Rcpp
  besides the basics

So in short you may want to work out first what you want you algorithm to be
and maybe use higher-level converters in R to accomodate.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] help with data.frame and numericvector

[Dirk Eddelbuettel]

On 27 April 2022 at 20:58, Roberto Spadim wrote:
| Hello folks,
| I'm converting some R functions to RCpp at
| https://github.com/OVVO-Financial/NNS/
| 
| My problem is with a R "cast" function
| 
| 
https://github.com/OVVO-Financial/NNS/blob/d3f37c6f217a41ce15b31f7a840b6b1ad63e5f36/R/Partial_Moments.R#L20
| 
| basically this line:
| 
| ---
| LPM <- function(degree, target, variable){
| if(any(class(variable)%in%c("tbl","data.table"))) variable <-
| as.vector(unlist(variable))
| ...
| }
| ---
| 
| My Rcpp version don't accept data.table type, it return an error of
| type not allow:
| 
| Error in LPM(2, 0, tail(appended_returns, 1)) :
|   Not compatible with requested type: [type=list; target=double].
| 
| Is there some way to accept a "anytype" at Rcpp, and convert it to
| numericvector when need?

In a way. We have a more-or-less FAQ about how to accomodate 'different
run-time types' (think: int vector vs double vector) at compile time. The
easiest is to use a SEXP which *is* already your "anytype" as it (most
literally) covers "any" type in R.  See for example

   https://gallery.rcpp.org/articles/rcpp-wrap-and-recurse/

which shows the basic pattern of switching on TYPEOF().

Otherwise, a tip: decompose compound expressions

 if(any(class(variable)%in%c("tbl","data.table"))) variable <- 
as.vector(unlist(variable))

into more basic assignments (on the C++ side).  We are getting some wonderful
help from the compiler but the template meta-programming driving this is
finicky. Do NOT assume you can stack expressions as you might in R. No shame
in doing multiple basic expressions -- the compiler (once it knows what to
do) may well optimise temporaries away.

Dirk

| My Rcpp version is:
| 
| 
https://github.com/OVVO-Financial/NNS/blob/NNS-Beta-Version/src/partial_moments_rcpp.cpp#L68
| 
| and fucntion signature is:
| NumericVector LPM_CPv(const double degree, const NumericVector target,
| const NumericVector variable) {
| 
| i think i should use SEXP as "anytype" and at function body check if I
| should "cast" to NumericVector
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RCPP_USE_UNWIND_PROTECT by default

[Dirk Eddelbuettel]

On 7 February 2022 at 00:12, Jeroen Ooms wrote:
| I have pushed a new version of V8 to CRAN that wraps the R callbacks
| in another tryCatch() such that we do not make any assumptions on the
| sort of exception handing provided by Rcpp. This should unblock you if
| you want to move forward on this change.

Thank you!

No rush from our end. By our standard release process we have five months to
debate (or ignore) this.  But appreciate the proactive help!

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RCPP_USE_UNWIND_PROTECT by default

[Dirk Eddelbuettel]

To sum up:

   ¯\_(ツ)_/¯

I have no bone in this fight.  Leaving it as is works for me too.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RCPP_USE_UNWIND_PROTECT by default

[Dirk Eddelbuettel]

On 6 February 2022 at 18:18, Jeroen Ooms wrote:
| Well not really, this kind of misses my point that it the
| unwind-protect makes it impossible to meaningfully catch the R error
| in C++, handle it, and continue running the C++ code, without aborting
| the entire mission and throwing the user back in the console.

I see. Well if we wanted to catch an R error on the R side, adding tryCatch
still works. Here are your initial R function, renamed, and a new one:

  callbackWithoutTry <- function() {
stop("Ouch from R")
  }
  
  callback <- function() {
  tryCatch(stop("Ouch from R"),
   error = function(e) { cat("Well that went south\n") },
   finally = function(e) { cat("Normal end\n") } )
  }

This (under UNWIND_PROTECT) behaves:

  edd@rob:/tmp/uptest(master)$ install.r .
  * installing *source* package ‘uptest’ ...
  ** using staged installation
  ** libs
  rm -f uptest.so RcppExports.o callback.o
  ccache g++-11 -I"/usr/share/R/include" -DNDEBUG -DRCPP_USE_UNWIND_PROTECT 
-I'/usr/local/lib/R/site-library/Rcpp/include'-fpic  -g -O3 -Wall -pipe 
-pedantic  -c RcppExports.cpp -o RcppExports.o
  ccache g++-11 -I"/usr/share/R/include" -DNDEBUG -DRCPP_USE_UNWIND_PROTECT 
-I'/usr/local/lib/R/site-library/Rcpp/include'-fpic  -g -O3 -Wall -pipe 
-pedantic  -c callback.cpp -o callback.o
  ccache g++-11 -Wl,-S -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions 
-flto=auto -Wl,-z,relro -o uptest.so RcppExports.o callback.o -L/usr/lib/R/lib 
-lR
  installing to /usr/local/lib/R/site-library/00LOCK-uptest/00new/uptest/libs
  ** R
  ** byte-compile and prepare package for lazy loading
  ** help
  *** installing help indices
  ** building package indices
  ** testing if installed package can be loaded from temporary location
  ** checking absolute paths in shared objects and dynamic libraries
  ** testing if installed package can be loaded from final location
  ** testing if installed package keeps a record of temporary installation path
  * DONE (uptest)
  edd@rob:/tmp/uptest(master)$ R -q
  > uptest::uptest()
  Well that went south
  [1] 42
  > 

So this catches the stop(), enters a designates block and resumes in the C++
function that called it all still returning the 42 we desired as The Answer.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RCPP_USE_UNWIND_PROTECT by default

[Dirk Eddelbuettel]

On 6 February 2022 at 17:40, Jeroen Ooms wrote:
| We can try to take V8 out of the equation, and see what actually
| causes the change. V8 uses (and tests!) the Rcpp feature to call an R
| function from C++. This behaves quite differently when using
| RCPP_UNWIND_PROTECT.
| 
| Here is a dummy package to demonstrate this: https://github.com/jeroen/uptest
| 
| The use case is simple: we want to call some R function from C++, and
| if it fails, catch the error message and deal with it in C++. I
| suspect there are more packages doing this, but perhaps they are not
| testing this case.
| 
| The example from uptest above show that when we compile with
| RCPP_UNWIND_PROTECT, any R error is always printed directly to the
| console. Even if we catch the Rcpp::LongjumpException in C++, the R
| error still seems to bubble up (as Iñaki also noted). I think this is
| at least surprising.
| 
| Then I am not sure what we do in C++ now with this
| Rcpp::LongjumpException if we catch it. We certainly don't want to
| unwind all the way in the middle of running the javascript code. The
| JavaScript code should be able to catch the R error, and continue
| running the script.
| 
| Anyway if you want to make RCPP_UNWIND_PROTECT the default, I can
| obviously opt-out in V8, but as an Rcpp user I am not convinced this
| is an improvement.

Thanks for the feedback. I think there is an easy-to-understand, easy-to-make
error in a sample package (but kudos for creating one!).  Because Rcpp will
always wrap try/catch around the function you create with its mechanism, the
layer inside is redundant.  So I suggest the C++ function file becomes this
simpler / shorter variant:

  #include 
  using namespace Rcpp;

  // [[Rcpp::export]]
  Rcpp::NumericVector call_r_from_rcpp() {
Rcpp::Function callback = 
Rcpp::Environment::namespace_env("uptest")["callback"];
callback();
return Rcpp::NumericVector::create(42);
  }

which behaves fine for me in both cases.

First, "as I found the repo" so with the new RCPP_UNWIND_PROTECT added:

  edd@rob:/tmp/uptest(master)$ install.r .  # the usual wrapper 
from littler
  * installing *source* package ‘uptest’ ...
  ** using staged installation
  ** libs   



   
  rm -f uptest.so RcppExports.o callback.o  

   
  ccache g++-11 -I"/usr/share/R/include" -DNDEBUG -DRCPP_USE_UNWIND_PROTECT 
-I'/usr/local/lib/R/site-library/Rcpp/include'-fpic  -g -O3 -Wall -pipe 
-pedantic  -c RcppExports.cpp -o RcppExports.o
  ccache g++-11 -I"/usr/share/R/include" -DNDEBUG -DRCPP_USE_UNWIND_PROTECT 
-I'/usr/local/lib/R/site-library/Rcpp/include'-fpic  -g -O3 -Wall -pipe 
-pedantic  -c callback.cpp -o callback.o
  ccache g++-11 -Wl,-S -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions 
-flto=auto -Wl,-z,relro -o uptest.so RcppExports.o callback.o -L/usr/lib/R/lib 
-lR
  installing to /usr/local/lib/R/site-library/00LOCK-uptest/00new/uptest/libs   


   
  ** R  
   
  ** byte-compile and prepare package for lazy loading 
  ** help
  *** installing help indices
  ** building package indices
  ** testing if installed package can be loaded from temporary location
  ** checking absolute paths in shared objects and dynamic libraries
  ** testing if installed package can be loaded from final location
  ** testing if installed package keeps a record of temporary installation path
  * DONE (uptest)
  edd@rob:/tmp/uptest(master)$ R -q
  > library(uptest)
  > uptest()
  Error in (function ()  : Ouch from R
  > qn
  edd@rob:/tmp/uptest(master)$

Second, after editing src/Makevars and removing of object files:


  edd@rob:/tmp/uptest(master)$ be src/Makevars  # an alias 
for emacsclient inside byobu
  edd@rob:/tmp/uptest(master)$ rm src/*.o src/*.so
  edd@rob:/tmp/uptest(master)$ install.r .
  * installing *source* package ‘uptest’ ...
  ** using staged installation
  ** libs
  rm -f uptest.so RcppExports.o callback.o
  ccache g++-11 -I"/usr/share/R/include" -DNDEBUG  
-I'/usr/local/lib/R/site-library/Rcpp/include'-fpic  -g -O3 -Wall -pipe 
-pedantic  -c RcppExports.cpp -o RcppExports.o
  ccache g++-11 -I"/usr/share/R/include" -DNDEBUG  
-I'/usr/local/lib/R/site-library/Rcpp/include'-fpic  -g -O3 -Wall -pipe 
-pedantic  -c 

Re: [Rcpp-devel] RCPP_USE_UNWIND_PROTECT by default

[Dirk Eddelbuettel]

Lionel,

Thanks a bunch for the prompt and detailed reply. CCing Jeroen now, I think I
had poked him over DM on this but not followed. Easy for us to delegate to V8 :)
That is of course a complicated (and toolchain-dependent) package too so we
shall see what we can do there.  But the good news on our end is that we can
likely just enable RCPP_UNWIND_PROTECT and everybody (apart from V8) may
indeed be better off.

Cheers, Dirk

On 1 February 2022 at 12:08, Lionel Henry wrote:
| Hi Iñaki,
| 
| IIRC, at the time I was concerned it might be undefined behaviour (from R's
| viewpoint) to catch a longjump exception (wich wraps an R unwind token) 
without
| rethrowing it. I think this is why I didn't have `LongjumpException` inherit
| from `std::exception` because there seemed to be an assumption that an 
exception
| inheriting from that class can be arbitrarily caught, and perhaps reported in
| some way to users or callers via the `what()` method.
| 
| A longjump token may represent different kinds of long jumps. If it represents
| an error, it might be reasonable to catch the token and recover. However it 
can
| also represent a restart invokation, a condition being caught by another 
handler
| upstack, or a long return (see `base::callCC()`). For these cases the R 
language
| does not provide a way of interrupting the unwinding. Except, maybe, through
| `on.exit()` expressions on the stack which can throw or long-return, and thus
| overtake the current jump.
| 
| Whether it's UB or not could be checked with Luke. That said, even if well
| defined, I would generally not recommand catching a longjump token and 
transform
| it to an unknown exception. In general it'd be better to resume the unwinding
| with the token. As mentioned above, it does not necessarily represent an error
| or abnormal situation.
| 
| I'm not familiar with V8 but I took a quick look. IIUC R is called back from 
JS
| through Rcpp? E.g. via `console.r.call()`? And it looks like throwing 
exceptions
| (or longjumping) over the JS stack is UB. So I think the proper thing to do is
| to catch `Rcpp::LongjumpException()`, then unwind the JS stack, probably with
| `v8::ThrowException()`, but the longjump exception (or at least the unwind 
token
| it wraps) needs to be somehow communicated to the other side. Once back in a
| safe Rcpp context with no JS on the stack, resume the longjump with the
| exception or token.
| 
| Of course it's easier to just disable unwind-protection in V8. But 
implementing
| the approach above would not only improve performance, it would also improve 
the
| semantics of V8 callbacks to R.
| 
| Best,
| Lionel
| 
| 
| On 1/31/22, Iñaki Ucar  wrote:
| > Hi Lionel,
| >
| > I've been setting this for years in my own packages, and particularly
| > in a simulator that greatly benefits from this due to its heavy usage
| > of R calls from the C++ simulation loop. Now, we're looking into
| > setting this feature on by default in the next release of Rcpp to
| > improve the performance of other packages, such as httpuv [1], as
| > well.
| >
| > Dirk has run a full revdep check that looks very promising, with just
| > one new failure (the V8 package), and it would be great if you could
| > take a look when you have time. It seems that the UNWIND_PROTECT
| > mechanism somehow collides with v8's exception handling:
| >
| >> test_check("V8")
| >   terminate called after throwing an instance of 'Rcpp::LongjumpException'
| >   Aborted
| >
| > V8 sees this exception, doesn't know what to do with it, and then the
| > program is aborted. This is kind of a Russian Doll, and probably an
| > extreme case, but we are wondering whether we can do something on the
| > Rcpp side to support v8's engine. V8 can always undefine
| > UNWIND_PROTECT if we ship this by default, but this is clearly one of
| > those packages that could benefit from the improved performance that
| > this feature enables.
| >
| > So far, I found that Rcpp::LongjumpException is the only exception in
| > Rcpp that doesn't inherit from std::exception (which is what V8
| > expects). Is this intended/required? I checked that, if
| > LongjumpException inherits from std::exception, V8 doesn't crash there
| > (the exception is recognized), but then two errors are shown in the R
| > console, which is not ideal either:
| >
| >> ctx <- V8::v8()
| >> ctx$eval("console.r.eval('doesnotexists')")
| > Error in eval(ei, envir) : object 'doesnotexists' not found
| > Error: std::exception
| >> x <- try(ctx$eval("console.r.eval('doesnotexists')"))
| > Error : std::exception
| >> x
| > [1] "Error : std::exception\n"
| > attr(,"class")
| > [1] "try-error"
| > attr(,"condition")
| > 
| >
| > Please let us know if you have some time for this. Any help would be
| > appreciated.
| >
| > Cheers,
| > Iñaki
| >
| > [1] https://github.com/rstudio/httpuv/issues/244
| >
| > --
| > Iñaki Úcar
| >

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: [Rcpp-devel] Detecting Singular Matrices in RcppArmadillo

[Dirk Eddelbuettel]

On 31 January 2022 at 11:25, Alex Ilich wrote:
| Thank you Zé and Dirk! That helped clarify exactly what solve is doing
| which I was having trouble tracking down in just the standard docs page.

The `solve()` function in Armadillo does exactly what it sets out to do.

Yet what Prof Bates has been hammering home for years is that how we use it
(and related functions) to fit linear models may have issues. See his code
here for alternatives:
  https://github.com/RcppCore/RcppEigen/blob/master/src/fastLm.h
  https://github.com/RcppCore/RcppEigen/blob/master/src/fastLm.cpp

Now, as I said, in practice you may get by if you're reasonably
careful. Double precision is hard to trick. But hey, it may happend, and we
all warned you :)

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Detecting Singular Matrices in RcppArmadillo

[Dirk Eddelbuettel]

On 31 January 2022 at 09:13, Zé Vinícius wrote:
| Yes, quoting the paper on which ‘solve’ is based on (
| http://arma.sourceforge.net/armadillo_solver_2020.pdf):
| 
| “The SVD-based solver uses the xGELSD set of functions, which find a
| minimum-norm solution to a linear least squares problem.”

Yes. A longer story though on how this is not what may matter. I should start
by saying that I never found really decent documentation describing this
'split' in the world view as this problem is, in essence, seen differently by
numerical analysis specialists (as for example the LAPACK authors of the
*GELSD functions) and the statistical users which differs in what they focus
on. Which is why R uses a modified version of LINPACK (as I recall going back
to by Ross Ihaka) when computing lm(). And not the LAPACK routines.

Doug was always adamant about this when I wrote the different simple fastLm()
approaches (in RcppGSL, RcppArmadillo, ...) which do _not_ properly account
for rank-deficiency (as R's lm() would) -- Doug also wrote the nicest fastLm
example in RcppEigen.

There is a little bit more in the help pages for the various lmFast()
versions as well as an explicit example (also due to Doug).

Now, I should add that whenever I tried to construct an example on a more
real-world-alike regression problem, I could not come anywhere close to
actually seeing the rank deficiency. But it is unmistakenly there is the
appropriately created case. So buyer beware.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Detecting Singular Matrices in RcppArmadillo

[Dirk Eddelbuettel]

On 28 January 2022 at 13:25, Alex Ilich wrote:
| Thank you Neal and Dirk. Based on these comments I think using arma::rcond

Ah, yes, of course. Should have remembered arma::rcond.

| to get the reciprocal of the condition factor, and checking if that is zero
| rather than the determinant may be the route to go. At least for this
| example that works.
| 
| library(Rcpp)
| 
| cppFunction(depends="RcppArmadillo", "NumericVector C_OLS(arma::mat X,
| arma::mat Y){
|   arma::mat Xt = trans(X);
|   arma::mat XtX = Xt * X;
|   double rcf = rcond(XtX);
|   Rcout << rcf; //print reciprocal of condition factor
|   if(rcf==0){

Re-read Neal's first email.  You probably do not want zero (apart from all
the R FAQ 7.31 reasons to not compare a double with equality :wink: )

Dirk

| NumericVector B2(X.n_cols, NA_REAL);
| return B2;
|   } else{
| arma::mat XtX_inv= inv(XtX);
| NumericVector B = Rcpp::as(wrap(XtX_inv * (Xt *
| Y)));
| return B;
|   }}")
| 
| X<- matrix(data=c(-250, -250, -250, -250, -250, -250, 250, 200, 150,
|   100, 50, 0, 1, 1, 1, 1, 1, 1), ncol=3, nrow=6)
| 
| 
| X2<- X
| 
| X2[1,2]<- X[1,2] + 5.684342e-14 #Add a slight numeric precision issue
| 
| Y<- matrix(1:6, ncol=1)
| 
| C_OLS(X,Y)
| # 0[1] NA NA NA
| 
| C_OLS(X2,Y)
| # 0[1] NA NA NA
| 
| 
| 
| On Fri, Jan 28, 2022 at 11:53 AM Alex Ilich  wrote:
| 
| > Hi, I have some code I've written to calculate regression parameters using
| > ordinarily least squares using RcppArmadillo. This is meant to be performed
| > iteratively over many small subsets (sliding window over spatial raster
| > data) so I'd like to automatically detect when the regression can't be
| > performed and just return a vector of NA's. Currently I check to see if the
| > determinant is 0 in order to see if the XtX matrix can be inverted and it
| > seems to work in the vast majority of cases but I did run into a case where
| > a small amount of precision error was introduced and for some reason this
| > causes the determinant to be non-zero in C++ however, the matrix still is
| > considered singular (uninvertible) leading to an error. I was wondering if
| > anyone had any suggestions? Maybe there's a minimum value non-zero value
| > where it's considered essentially singular that I could use instead of 0,
| > or maybe there's a way to return a vector of NAs if an error is detected
| > rather than stopping execution and printing an error message. I've also
| > seen that pinv can be used, but from some tests I ran it's substantially
| > slower, so I'd like to avoid using that. I've included some example code
| > below. Any suggestions would be greatly appreciated.
| >
| > Thanks,
| > Alex
| >
| > library(Rcpp)
| > cppFunction(depends="RcppArmadillo", "NumericVector C_OLS(arma::mat X,
| > arma::mat Y){
| >   arma::mat Xt = trans(X);
| >   arma::mat XtX = Xt * X;
| >   double d = det(XtX);
| >   Rcout << d; //print determinant
| >   if(d==0){
| > NumericVector B2(X.n_cols, NA_REAL);
| > return B2;
| >   } else{
| > arma::mat XtX_inv= inv(XtX);
| > NumericVector B = Rcpp::as(wrap(XtX_inv * (Xt *
| > Y)));
| > return B;
| >   }}")
| >
| > X<- matrix(data=c(-250, -250, -250, -250, -250, -250, 250, 200, 150,
| >   100, 50, 0, 1, 1, 1, 1, 1, 1), ncol=3, nrow=6)
| >
| >
| > X2<- X
| >
| > X2[1,2]<- X[1,2] + 5.684342e-14 #Add a slight numeric precision issue
| >
| > Y<- matrix(1:6, ncol=1)
| >
| > #Determinant of XtX in R is 0 for both
| > det(t(X) %*% X) ==0 #TRUE
| > det(t(X2) %*% X2) ==0 #TRUE
| >
| > C_OLS(X,Y) #Determinant is 0 in C++ and correctly returns a vector of NA's
| > #0[1] NA NA NA
| >
| > C_OLS(X2,Y) #Determinant is not 0 in C++ so the if statement is not
| > triggered but the matrix is still uninvertible
| > # 4.57764e-05
| > # error: inv(): matrix is singular
| > # Error in C_OLS(X2, Y) : inv(): matrix is singular
| >
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Detecting Singular Matrices in RcppArmadillo

[Dirk Eddelbuettel]

On 28 January 2022 at 09:16, Neal Fultz wrote:
| There's an R object that has the machine precision, which could be a
| reasonable threshold.
| 
| .Machine$double.eps
| 
| I believe there is a similar constant in the C++ standard library.
| 
| You might also try checking the condition of the matrix instead of the
| determinant, but you might take a performance hit. EG:
| 
https://www.quora.com/Why-is-a-condition-number-more-useful-than-a-determinant-for-spotting-problems-with-the-solution-to-ax-b

Exactly -- here is an old SO answer of mine featuring the condition
number and kappa (its inverse):

https://stackoverflow.com/questions/3042117/screening-multicollinearity-in-a-regression-model/3042262#3042262

I don't have an implementation of either 'from C++ / Armadillo basics' handy
but it is likely not hard, and possibly a nice exercise.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] violates the C++ One Definition Rule ?

[Dirk Eddelbuettel]

On 25 January 2022 at 10:49, Toby Hocking wrote:
| That worked! Thanks Dirk.

Splendid.

Now that you have it working again, if you feel curious and have a few
minutes maybe you can drill down how/where it breaks. Because the general
ability to link, say, "interface files" that deal with R/C++ interchange (and
include RcppArmadillo.h) and pure "client library files" (that include the
armadillo header, and may be used elsewhere) is a nice advanced use case we
do not want to drop. But we need to document what needs to be turned on to
enable LTO support.

Dirk
 
| On Mon, Jan 24, 2022 at 1:14 PM Dirk Eddelbuettel  wrote:
| 
| >
| > On 24 January 2022 at 12:55, Toby Hocking wrote:
| > | Hi Rcpp Devs,
| > | Does anyone know how to fix this warning in a package with LinkingTo:
| > | RcppArmadillo? My package plotHMM
| > | https://www.stats.ox.ac.uk/pub/bdr/LTO/plotHMM.out got this message on
| > CRAN
| >
| > Worth stressing that this happens under link-time optimziation (lto) which
| > I
| > am not yet that familiar with.
| >
| > From _really briefly_ glancing at your package I see that you include
| > RcppArmadillo.h in some files (good !) but also include armadillo
| > directly. It's just a hunch and guess at this point but that may lead to
| > different 'settings' and #define values.  Maybe try using only
| > RcppArmadillo.h ?
| >
| > Dirk
| >
| > | Additional Checks LTO flavor,
| > | https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt
| > |
| > | g++ -std=gnu++14 -shared -L/usr/local/lib64 -o plotHMM.so
| > | RcppExports.o backward.o eln.o forward.o interface.o multiply.o
| > | pairwise.o transition.o viterbi.o
| > |
| > 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:84:10:
| > | warning: type ‘struct opts’ violates the C++ One Definition Rule
| > | [-Wodr]
| > |84 |   struct opts
| > |   |  ^
| > |
| > 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:84:10:
| > | note: a different type is defined in another translation unit
| > |84 |   struct opts
| > |   |  ^
| > |
| > 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:86:17:
| > | note: the first difference of corresponding definitions is field
| > | ‘flags’
| > |86 | const uword flags;
| > |   | ^
| > |
| > 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:86:17:
| > | note: a field of same name but different type is defined in another
| > | translation unit
| > |86 | const uword flags;
| > |   | ^
| > | ___
| > | Rcpp-devel mailing list
| > | Rcpp-devel@lists.r-forge.r-project.org
| > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| > --
| > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] violates the C++ One Definition Rule ?

[Dirk Eddelbuettel]

On 24 January 2022 at 12:55, Toby Hocking wrote:
| Hi Rcpp Devs,
| Does anyone know how to fix this warning in a package with LinkingTo:
| RcppArmadillo? My package plotHMM
| https://www.stats.ox.ac.uk/pub/bdr/LTO/plotHMM.out got this message on CRAN

Worth stressing that this happens under link-time optimziation (lto) which I
am not yet that familiar with.

From _really briefly_ glancing at your package I see that you include
RcppArmadillo.h in some files (good !) but also include armadillo
directly. It's just a hunch and guess at this point but that may lead to
different 'settings' and #define values.  Maybe try using only RcppArmadillo.h ?

Dirk

| Additional Checks LTO flavor,
| https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt
| 
| g++ -std=gnu++14 -shared -L/usr/local/lib64 -o plotHMM.so
| RcppExports.o backward.o eln.o forward.o interface.o multiply.o
| pairwise.o transition.o viterbi.o
| 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:84:10:
| warning: type ‘struct opts’ violates the C++ One Definition Rule
| [-Wodr]
|84 |   struct opts
|   |  ^
| 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:84:10:
| note: a different type is defined in another translation unit
|84 |   struct opts
|   |  ^
| 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:86:17:
| note: the first difference of corresponding definitions is field
| ‘flags’
|86 | const uword flags;
|   | ^
| 
/data/gannet/ripley/R/test-4.2/RcppArmadillo/include/armadillo_bits/glue_solve_bones.hpp:86:17:
| note: a field of same name but different type is defined in another
| translation unit
|86 | const uword flags;
|   | ^
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] RcppArmadillo 0.10.8.0.0

[Dirk Eddelbuettel]

Happy New Year to all!

Conrad released version 10.8 Armadillo (and I had prepared two pre-releases
which passed reverse dependency checks just fine so not expecting surprises).

Given that 0.10.7.5.0, the final RcppRelease for the 10.7.* series with his
last release 10.7.5, only got to CRAN on December 17 I will wait a little
(even when CRAN is reopened, scheduled tomorrow) to release it.  But you can
always get it from the Rcpp drat repo via

  install.packages("RcppArmadillo",
   repos=c("https://RcppCore.github.io/drat;,
   "https://cloud.r-project.org;))

(and/or update or set the drat repo via the drat helper functions). See
https://RcppCore.github.io/drat for more.

Cheers, Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Limit of 20

[Dirk Eddelbuettel]

On 16 December 2021 at 06:38, Joseph Park wrote:
| As R itself has no practical limit, and, large, ugly parameter lists are
| sometimes unavoidable in API's, I respectfully request consideration to
| relax the limit as design and resources allow.

Please keep in mind that this project is provided by unpaid volunteers. So
you are truly more than welcome 'to request' features, but there simply
cannot be any guarantees of follow-up.  I am sure you understand, I just want
to clarify this, and this seemed to be a good moment to reiterate.

The "Be the change you want to see in the world" mantra applies.  The best
way to ensure something happens is to lead a careful pull request (or set of
pull requests). Or, if one is lucky, get someone else interested in (maybe
chiefly the technical chops of) the project.

Open source is a fantastic way to build software such as this. But it has
limitations to deliverables and timelines. 

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] R Session Sometimes Aborts

[Dirk Eddelbuettel]

On 15 December 2021 at 12:30, Robert J. Hijmans wrote:
| Dirk thanks very much for the help. And sorry, Alex, I misspoke. I meant to
| say that Rcpp will coerce a R "numeric" (vector) to an
| "Rcpp::IntegerVector" if you ask it to do so (and that is what happened in
| the context we were discussing).

Exactly. And it will be no comfort to Alex who has to chase this by hand but
for those of us old enough to C/C++ time in (whole) decades, it really just
smells *very much* like an old-fashioned indexing error.  Which is why
valgrind was already a good idea.

Minor hint:
   Rcpp::stop("Something here including %d or %s or ... formatting", a, b);
is a tad more Rcpp-idiomatic, and errors.  We now have Rcpp::message(...) to
just do the printing (in a suppressable way). C API of R of course still holds.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Limit of 20

[Dirk Eddelbuettel]

On 15 December 2021 at 20:10, Balamuta, James Joseph wrote:
| For those interested, the few other instances can be found by looking under 
the inst/include/Rcpp/generated/ folder:
| 
| https://github.com/RcppCore/Rcpp/tree/master/inst/include/Rcpp/generated 

Yup, I mentioned the dir, but thanks for spelling it out.  The generated
code, sadly, is a tad hard to read at times.
 
| In the case of Vector__create.h, one would need to do some varidic templating 
to abstract away from the current generated approach:
| 
| 
https://github.com/RcppCore/Rcpp/blob/940fb23868bf442e587994451e85263baa302d9c/inst/include/Rcpp/generated/Vector__create.h
 
| 
| This approach has been used previously In the exception/error message update: 
| https://github.com/RcppCore/Rcpp/tree/master/inst/include/Rcpp/exceptions 

Excellent reminder!

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Limit of 20

[Dirk Eddelbuettel]

On 15 December 2021 at 10:19, Kevin Ushey wrote:
| I assume we're talking about Vector::create()? Anyone curious poking at it
| can start by looking here:
| 
| 
https://github.com/RcppCore/Rcpp/blob/940fb23868bf442e587994451e85263baa302d9c/inst/include/Rcpp/vector/Vector.h#L1122-L1126

There is more than one as we have a few auto/macro-generated interfaces in
the generated/ directory this points to. But the logic is probably similar.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Limit of 20

[Dirk Eddelbuettel]

Joseph,

Sorry, can't quote your message as whatever you used confused my mail
handler. (Maybe try text-only next time if you remeber? I have had this
before, albeit very rarely.)

But it is a good idea.  Someone with a bit of time should sit down and could do
this as we now have C++11 / C++14 as a base in current R.

Maybe even a possible Google Summer of Code project if we find a motivated
and qualified student (and one or two mentors, I could be fine I suppose).

Best, Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] R Session Sometimes Aborts

[Dirk Eddelbuettel]

8d8, shiftSEXP=0x92cc468, na_optSEXP=0xa313398,
| >> niSEXP=0xb655560, nwSEXP=0x1aeec7d0)
| >> at RcppExports.cpp:94
| >> #3  0x001f6b02 in R_doDotCall (
| >> ofun=0x1c1a0732 <_GLCMTextures_C_glcm_textures_helper2(SEXP, SEXP,
| >> SEXP, SEXP, SEXP, SEXP, SEXP)>, nargs=7,
| >> cargs=0x1ffeff6830, call=0x15ed3c88) at
| >> /mnt/c/R/R-svn/trunk/src/main/dotcode.c:622
| >> #4  0x002637ca in bcEval (body=0x15ed4078, rho=0x19023210,
| >> useCache=TRUE)
| >> at /mnt/c/R/R-svn/trunk/src/main/eval.c:7695
| >>
| >> Line 73 is
| >> GLCM(neighbor_val,focal_val) = GLCM(neighbor_val,focal_val)+1;
| >> where GLCM is a 16 x 16 IntegerMatrix and focal_val is 16:
| >>(gdb) print neighbor_val
| >>$1 = 9
| >>(gdb) print focal_val
| >>$2 = 16
| >>(gdb) print i
| >>$3 = 2
| >>(gdb) print j
| >>$4 = 1
| >>
| >> -Bill
| >>
| >> On Mon, Dec 13, 2021 at 11:37 AM Bill Dunlap 
| >> wrote:
| >>
| >>> Thanks, I hadn't noticed the --use-valgrind option to check.
| >>>
| >>> I often run R under valgrind with the command line:
| >>>   $ R --quiet --no-save --debugger=valgrind
| >>> --debugger-args="--track-origins=yes --vgdb=full --vgdb-error=0"
| >>> then in another window start a debugger process with
| >>>   $ gdb RHOME/bin/exec/R
| >>>   ...
| >>>(gdb) target remote | vgdb
| >>>(gdb) cont
| >>> You may need to supply a complete path to vgdb, valgrind's interface to
| >>> gdb.
| >>> Then gdb will set breakpoints where valgrind reports memory misuse and
| >>> you can inspect variables, etc., where an error occurs.
| >>> You can check for memory leaks from gdb with
| >>>(gdb) monitor leak_check full
| >>>
| >>> -Bill
| >>>
| >>>
| >>> On Mon, Dec 13, 2021 at 10:29 AM Dirk Eddelbuettel 
| >>> wrote:
| >>>
| >>>>
| >>>> On 13 December 2021 at 09:15, Bill Dunlap wrote:
| >>>> | I ran your example under valgrind on Linux (Ubuntu 20.04)
| >>>>
| >>>> Excellent call, as usual!  Thanks for doing that.
| >>>>
| >>>> R actually makes is so easy to run with valgrind by calling
| >>>>
| >>>>R CMD check --use-valgrind somePkg_1.2-3.tar.gz
| >>>>
| >>>> that I started to add it to some CI setups.
| >>>>
| >>>> Dirk
| >>>>
| >>>> | and valgrind found some memory misuse:
| >>>> |
| >>>> | $ R --quiet --no-save --debugger=valgrind
| >>>> | --debugger-args="--track-origins=yes"
| >>>> | ==1533== Memcheck, a memory error detector
| >>>> | ==1533== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et
| >>>> al.
| >>>> | ==1533== Using Valgrind-3.15.0 and LibVEX; rerun with -h for
| >>>> copyright info
| >>>> | ==1533== Command: /home/bill/R-devel/R-build/bin/exec/R --quiet
| >>>> --no-save
| >>>> | ==1533==
| >>>> | > library(terra)
| >>>> | terra version 1.5.2
| >>>> | > library(raster)
| >>>> | Loading required package: sp
| >>>> | > library(GLCMTextures)
| >>>> | >
| >>>> | > r1a<- raster::raster(volcano)
| >>>> | > r2a<- glcm_textures(r1a, w=c(3,7), n_levels = 16, quantization =
| >>>> "equal
| >>>> | prob", shift=c(0,1))
| >>>> | >
| >>>> | > r1b<- terra::rast(volcano)
| >>>> | > r2b<- glcm_textures2(r1b, w=c(3,7), n_levels = 16, quantization =
| >>>> "equal
| >>>> | prob", shift=c(0,1)) #Often leads to Rsession Aborted
| >>>> | ==1533== Invalid read of size 4
| >>>> | ==1533==at 0x1C1ADA01: C_make_glcm(Rcpp::Matrix<13,
| >>>> | Rcpp::PreserveStorage>, int, Rcpp::Vector<13, Rcpp::PreserveStorage>,
| >>>> | Rcpp::String) (glcm_cpp_functions.cpp:73)
| >>>> | ==1533==by 0x1C1B2237: C_glcm_textures_helper2(Rcpp::Vector<13,
| >>>> | Rcpp::PreserveStorage>, Rcpp::Vector<13, Rcpp::PreserveStorage>, int,
| >>>> | Rcpp::Vector<13, Rcpp::PreserveStorage>, Rcpp::String, unsigned long,
| >>>> | unsigned long) (glcm_cpp_functions.cpp:218)
| >>>> | ==1533==by 0x1C1A098D: _GLCMTextures_C_glcm_textures_helper2
| >>>> | (RcppExports.cpp:94)
| >>>> | ==1533==by 0x1F6B01: R_

Re: [Rcpp-devel] R Session Sometimes Aborts

[Dirk Eddelbuettel]

On 13 December 2021 at 09:15, Bill Dunlap wrote:
| I ran your example under valgrind on Linux (Ubuntu 20.04)

Excellent call, as usual!  Thanks for doing that.

R actually makes is so easy to run with valgrind by calling

   R CMD check --use-valgrind somePkg_1.2-3.tar.gz

that I started to add it to some CI setups.

Dirk

| and valgrind found some memory misuse:
| 
| $ R --quiet --no-save --debugger=valgrind
| --debugger-args="--track-origins=yes"
| ==1533== Memcheck, a memory error detector
| ==1533== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
| ==1533== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
| ==1533== Command: /home/bill/R-devel/R-build/bin/exec/R --quiet --no-save
| ==1533==
| > library(terra)
| terra version 1.5.2
| > library(raster)
| Loading required package: sp
| > library(GLCMTextures)
| >
| > r1a<- raster::raster(volcano)
| > r2a<- glcm_textures(r1a, w=c(3,7), n_levels = 16, quantization = "equal
| prob", shift=c(0,1))
| >
| > r1b<- terra::rast(volcano)
| > r2b<- glcm_textures2(r1b, w=c(3,7), n_levels = 16, quantization = "equal
| prob", shift=c(0,1)) #Often leads to Rsession Aborted
| ==1533== Invalid read of size 4
| ==1533==at 0x1C1ADA01: C_make_glcm(Rcpp::Matrix<13,
| Rcpp::PreserveStorage>, int, Rcpp::Vector<13, Rcpp::PreserveStorage>,
| Rcpp::String) (glcm_cpp_functions.cpp:73)
| ==1533==by 0x1C1B2237: C_glcm_textures_helper2(Rcpp::Vector<13,
| Rcpp::PreserveStorage>, Rcpp::Vector<13, Rcpp::PreserveStorage>, int,
| Rcpp::Vector<13, Rcpp::PreserveStorage>, Rcpp::String, unsigned long,
| unsigned long) (glcm_cpp_functions.cpp:218)
| ==1533==by 0x1C1A098D: _GLCMTextures_C_glcm_textures_helper2
| (RcppExports.cpp:94)
| ==1533==by 0x1F6B01: R_doDotCall (dotcode.c:622)
| ==1533==by 0x2637C9: bcEval (eval.c:7695)
| ==1533==by 0x240653: Rf_eval (eval.c:748)
| ==1533==by 0x243223: R_execClosure (eval.c:1918)
| ==1533==by 0x242EFD: Rf_applyClosure (eval.c:1844)
| ==1533==by 0x240E06: Rf_eval (eval.c:871)
| ==1533==by 0x246CD6: do_set (eval.c:2990)
| ==1533==by 0x240A8C: Rf_eval (eval.c:823)
| ==1533==by 0x2457DA: do_begin (eval.c:2538)
| ==1533==  Address 0xa59c0c4 is 28 bytes before a block of size 64 in arena
| "client"
| ==1533==
| ==1533== Invalid write of size 4
| ==1533==at 0x1C1ADA44: C_make_glcm(Rcpp::Matrix<13,
| Rcpp::PreserveStorage>, int, Rcpp::Vector<13, Rcpp::PreserveStorage>,
| Rcpp::String) (glcm_cpp_functions.cpp:73)
| ==1533==by 0x1C1B2237: C_glcm_textures_helper2(Rcpp::Vector<13,
| Rcpp::PreserveStorage>, Rcpp::Vector<13, Rcpp::PreserveStorage>, int,
| Rcpp::Vector<13, Rcpp::PreserveStorage>, Rcpp::String, unsigned long,
| unsigned long) (glcm_cpp_functions.cpp:218)
| ==1533==by 0x1C1A098D: _GLCMTextures_C_glcm_textures_helper2
| (RcppExports.cpp:94)
| ==1533==by 0x1F6B01: R_doDotCall (dotcode.c:622)
| ==1533==by 0x2637C9: bcEval (eval.c:7695)
| ==1533==by 0x240653: Rf_eval (eval.c:748)
| ==1533==by 0x243223: R_execClosure (eval.c:1918)
| ==1533==by 0x242EFD: Rf_applyClosure (eval.c:1844)
| ==1533==by 0x240E06: Rf_eval (eval.c:871)
| ==1533==by 0x246CD6: do_set (eval.c:2990)
| ==1533==by 0x240A8C: Rf_eval (eval.c:823)
| ==1533==by 0x2457DA: do_begin (eval.c:2538)
| ==1533==  Address 0xa59c0c4 is 28 bytes before a block of size 64 in arena
| "client"
| ==1533==
| --1533-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
| exiting
| --1533-- si_code=1;  Faulting address: 0x10A59C138;  sp: 0x10090e2e20
| 
| valgrind: the 'impossible' happened:
|Killed by fatal signal
| 
| host stacktrace:
| ==1533==at 0x580505C4: ??? (in
| /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
| ==1533==by 0x58004EBB: ??? (in
| /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
| ==1533==by 0x58005DA7: ??? (in
| /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
| ==1533==by 0x580A7204: ??? (in
| /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
| ==1533==by 0x580F5FD4: ??? (in
| /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
| 
| sched status:
|   running_tid=1
| 
| Thread 1: status = VgTs_Runnable (lwpid 1533)
| ==1533==at 0x483BE63: operator new(unsigned long) (in
| /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
| ==1533==by 0x6E92D3C: void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag) (in
| /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
| ==1533==by 0x1C1B2377: C_glcm_textures_helper2(Rcpp::Vector<13,
| Rcpp::PreserveStorage>, Rcpp::Vector<13, Rcpp::PreserveStorage>, int,
| Rcpp::Vector<13, Rcpp::PreserveStorage>, Rcpp::String, unsigned long,
| unsigned long) (glcm_cpp_functions.cpp:221)
| ==1533==by 0x1C1A098D: _GLCMTextures_C_glcm_textures_helper2
| (RcppExports.cpp:94)
| ==1533==by 0x1F6B01: R_doDotCall (dotcode.c:622)
| ==1533==by 0x2637C9: bcEval (eval.c:7695)
| 

Re: [Rcpp-devel] R Session Sometimes Aborts

[Dirk Eddelbuettel]

On 13 December 2021 at 11:14, Alexander Ilich wrote:
| Hi, I'm upgrading one of my R packages to rely on the terra package instead
| of the raster package for the handling of spatial raster data. Previously
| when relying on the raster package I had to convert the data to a matrix
| and send it to C++ to loop through the cells manually, but with the new
| features in the terra package I can supply a C++ function that returns
| multiple values directly to terra::focalCpp to perform focal operations
| 
.
| I get the same values using both the old and new versions of the functions,
| but the new version often causes the R session to abort, especially at
| larger window sizes. For example, a 3x3 or a 3x5 window seems to always
| run, but a 3x7 window will often cause the R session to abort. However,
| when it doesn't, I get the correct values. Functions followed by 2 are the
| terra versions of the function. By commenting out things and rebuilding I
| was able to determine the line that causes the crash in the terra version
| is "NumericMatrix curr_GLCM = C_make_glcm(curr_window, n_levels, shift,
| na_opt); //Tabulate the GLCM"; however, this line is also included in the
| raster version of the function so I'm not sure why this would happen. Any
| help would be greatly appreciated. Here is the github repository
| , and I've added some
| sample code below to illustrate the issue.

As frustrating as it is, sometimes the only fix is a rebuild so that all
components use the same ABI/API and headers. I wish we had better diagnostics
for this.  


| Thanks,
| Alex
| 
| install.packages('raster', repos='https://rspatial.r-universe.dev')
| #install development version of raster
| install.packages('terra', repos='https://rspatial.r-universe.dev') #install
| development version of terra

That risks mixing newer and older builds which, for binaries, can have issues.

I know little about the innards of terra and raster so I may be off here.

Dirk

| remotes::install_github("ailich/GLCMTextures", ref = "terra") #Install
| branch of my package testing terra versions of functions
| 
| library(terra)
| library(raster)
| library(GLCMTextures)
| 
| r1a<- raster::raster(volcano)
| r2a<- glcm_textures(r1a, w=c(3,7), n_levels = 16, quantization = "equal
| prob", shift=c(0,1))
| 
| r1b<- terra::rast(volcano)
| r2b<- glcm_textures2(r1b, w=c(3,7), n_levels = 16, quantization = "equal
| prob", shift=c(0,1)) #Often leads to Rsession Aborted
| 
| all.equal(values(r2a),values(r2b)) #TRUE
| 
| 
| 
| #System Information
| #OS: Windows 10
| R.version
| # platform   x86_64-w64-mingw32
| # arch   x86_64
| # os mingw32
| # system x86_64, mingw32
| # status
| # major  4
| # minor  0.4
| # year   2021
| # month  02
| # day15
| # svn rev80002
| # language   R
| # version.string R version 4.0.4 (2021-02-15)
| # nickname   Lost Library Book
| 
| packageVersion("terra")
| # ‘1.5.2’
| packageVersion("raster")
| # ‘3.5.10’
| packageVersion("Rcpp")
| # ‘1.0.7’
| packageVersion("RcppArmadillo")
| # ‘0.10.7.3.0’
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp::plugins - Unwinding protection

[Dirk Eddelbuettel]

On 3 December 2021 at 12:06, Kevin Ushey wrote:
| I'm a fan. I think we could just have a single header RcppLite.h which
| would turn off the "heaviest" pieces of Rcpp; that is, modules + sugar
| + (maybe?) RTTI.

Yep. That's where I started. I may make that a PR then.

But I also still lean to allowing the differentiation.  With a new directory
it is easy to accomodate.

Another part of that plan is that if we (eventually) get most users to hook
into a standard file or set of files (like today's Rcpp.h) we can move some
things around and clean up a little.  The directory structure is ... somewhat
random. 
 
| Or, we could allow for #define RCPP_LEAN_AND_MEAN ... ;-)

Always the implicit default ;-)

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp::plugins - Unwinding protection

[Dirk Eddelbuettel]

On 3 December 2021 at 19:47, Iñaki Ucar wrote:
| Mmmh, no strong opinions here. I think it doesn't matter much whether
| it's an include or a define. What matters most is whether this is
| discoverable and the user understands what it does.

That was my motivation -- by pointing to such a top-level directory (and also
cleaning up some of the sprawling header mess :) ) it may easier.
 
| In this particular case, Víthor is interested in runtime performance.
| Disabling modules and RTTI (and Sugar if he's not using that) will
| save some compilation time, but won't help with runtime performance.

Understood. But it is a compile-time switch like these.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp::plugins - Unwinding protection

[Dirk Eddelbuettel]

On 3 December 2021 at 17:03, Iñaki Ucar wrote:
| On Fri, 3 Dec 2021 at 15:44, Víthor Rosa  wrote:
| >
| > Thank you for your response. Adding my functions to an R package and 
changing the Makevars file as suggested reduced the runtime by half. Excited 
for Rcpp 1.0.8! :)
| 
| Excellent! Glad it helped.

I have been sitting on a branch at GitHub that defines new / easier /
alternate header files as entry points. So instead of starting with Rcpp.h
(possibly combined with #define statements) one could now pick exactly one
off these three

   #include 

   #include 

   #include 

which turn off, respectively, Modules, RTTI and Sugar. See the commit at [1]
for more and full code, it's essentially a define each and simple nesting.

Each of these shaves a little bit of the compile times.  (I need to rebase it
to current master, it's a few months old.)

But I had not yet convinced myself it would be useful / of interest.  But as
this thread shows, there may be interest.  Any comments? Yay? Nay?

(And as discussed turning UNWIND_PROTECT on globally is also a good idea but
may need a proper transition, and is hence for now outside the scope of this
branch.) 

Dirk


[1] 
https://github.com/RcppCore/Rcpp/commit/5cf57ff663d06acf42124feae51d469f3f77be52#diff-05c80375618a46d399d73e4f32a3006aa698b9bb293a37c6d2e431a1c541b7bb

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp::plugins - Unwinding protection

[Dirk Eddelbuettel]

On 2 December 2021 at 17:48, Iñaki Ucar wrote:
| My simulation package makes heavy use of calls to R user functions from a
| C++ simulation loop, and therefore greatly benefits from this feature too,
| which I think we should promote to default.

I agree and believe I looked into it once before -- but found 'shrapnel' from
other packages being affected. We are eight months into the (simpler !!)
transition to default to STRICT_R_HEADERS which will go in with Rcpp 1.0.8 in
January (and yay, yesterday brought several updates, so my thanks to
everybody who folded patches or PRs I sent in and uploaded; current score is
now 70 out 92 done, see https://github.com/RcppCore/Rcpp/issues/1158 )

So maybe in 2022...

| Meanwhile, take a look at this
| Makevars file to see how to activate it:
| https://github.com/r-simmer/simmer/blob/master/src/Makevars

Yep.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Package does not compile on MAC when running R-CMD-check github action

[Dirk Eddelbuettel]

Simon,

Your Makevars [1] is very standard so I would suspect it may be the actions
setup for macOS.  Rcpp is still used by a large number of packages all of
which appear to build just fine on macOS (as eg evidenced by the CRAN checks)
if and when everything is setup correctly.

Dirk

[1] https://github.com/simonsays1980/finmix/blob/documentation/src/Makevars

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Any recent change that would remove Rcpp_precious_remove?

[Dirk Eddelbuettel]

Howdy,

Somone (on r-help which I don't really follow for lack of time) called [3]
this a 'quasi-FAQ':

  This problem is pratically a StackOverflow FAQ [1], with link to the 
  Rcpp-devel mailing list [2].

  [1] 
https://stackoverflow.com/questions/68416435/rcpp-package-doesnt-include-rcpp-precious-remove
  [2] 
https://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg10226.html

With Rcpp 1.0.7 (July 2021) we made one cleanup. But it required you to
upgrade Rcpp itself _if you used any package compiled against 1.0.7_. So the
simple fix as in all those posts ... is to simply ensure that along with
updated packages uses Rcpp you also use the most recent Rcpp version. Then
(generally speaking) everything just as works as usual.

Hope this helps,  Dirk

[3] https://stat.ethz.ch/pipermail/r-help/2021-September/472416.html

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp function results are different on different systems

[Dirk Eddelbuettel]

On 19 August 2021 at 10:04, Naeem Khoshnevis wrote:
| Thank you so much, everyone, for responding to this email.

Thanks for circling back!  This was a pretty impressive thread as you got
three distinct answers that all added some value :)

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Rcpp function results are different on different systems

[Dirk Eddelbuettel]

Naeem,

I would simplify, simplify, simplify -- as 'Rcpp FAQ 7.31' reminds us all,
testing _equality_ of doubles is challenging anyway.

Besides, it may make sense to would ascertain first you get what you want in
_purely serial modes_ and then move to OpenMP.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Using Rcpp with results in "shared object 'nloptC.so' not found"

[Dirk Eddelbuettel]

On 18 August 2021 at 16:36, Simon Zehnder wrote:
| I am using R 4.0.5 on a Fedora 34 System, Rcpp 1.0.6 and nloptr 1.2.2.2.

Works here (Ubuntu 21.04, Rcpp 1.0.7) (see [1] below)

Works at CRAN (see [2] below)

Works at universe (see [3] below)

I would suspect the error is at your end.

Dirk

[1] Running via rcc.r from littler wrapping rcmdcheck

edd@rob:~/git/rcppnloptexample(master)$ rcc.r RcppNLoptExample_0.1.0.tar.gz 
── R CMD check 
─
─  using log directory ‘/tmp/file2b4b7523aee48f/RcppNLoptExample.Rcheck’
─  using R version 4.1.1 (2021-08-10)   
 
─  using platform: x86_64-pc-linux-gnu (64-bit)
─  using session charset: UTF-8   
✔  checking for file ‘RcppNLoptExample/DESCRIPTION’ ...
─  checking extension type ... Package
─  this is package ‘RcppNLoptExample’ version ‘0.1.0’
─  package encoding: UTF-8
✔  checking package namespace information ...
✔  checking package dependencies (803ms)
✔  checking package namespace information ...
✔  checking package dependencies (803ms)
✔  checking if this is a source package
✔  checking if there is a namespace
✔  checking for executable files ...
✔  checking for hidden files and directories
✔  checking for portable file names
✔  checking for sufficient/correct file permissions
✔  checking whether package ‘RcppNLoptExample’ can be installed (6.3s)
✔  checking installed package size ...
✔  checking package directory
✔  checking DESCRIPTION meta-information ...
✔  checking top-level files
✔  checking for left-over files
✔  checking index information
✔  checking package subdirectories ...
✔  checking R files for non-ASCII characters ...
✔  checking R files for syntax errors ...
✔  checking whether the package can be loaded ...
✔  checking whether the package can be loaded with stated dependencies ...
✔  checking whether the package can be unloaded cleanly ...
✔  checking whether the namespace can be loaded with stated dependencies ...
✔  checking whether the namespace can be unloaded cleanly ...
✔  checking loading without being on the library search path ...
✔  checking dependencies in R code ...
✔  checking S3 generic/method consistency (430ms)
✔  checking replacement functions ...
✔  checking foreign function calls ...
✔  checking R code for possible problems (931ms)
✔  checking Rd files ...
✔  checking Rd metadata ...
✔  checking Rd cross-references ...
✔  checking for missing documentation entries ...
✔  checking for code/documentation mismatches (679ms)
✔  checking Rd \usage sections (549ms)
✔  checking Rd contents ...
✔  checking for unstated dependencies in examples ...
✔  checking line endings in C/C++/Fortran sources/headers
✔  checking line endings in Makefiles
✔  checking compilation flags in Makevars ...
✔  checking for GNU extensions in Makefiles
✔  checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS)
✔  checking use of PKG_*FLAGS in Makefiles
✔  checking compilation flags used
✔  checking compiled code ...
✔  checking examples (424ms)
✔  checking PDF version of manual (2.5s)
   
   
edd@rob:~/git/rcppnloptexample(master)$ 

[2] https://cloud.r-project.org/web/checks/check_results_RcppNLoptExample.html

[3] https://eddelbuettel.r-universe.dev/ui#builds and also 
https://github.com/r-universe/eddelbuettel/actions/runs/1047649769


| 
| Thanks for any time and efforts you spent on my problem.
| Simon
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Apply Defined Rcpp Functions In Parallel

[Dirk Eddelbuettel]

On 18 August 2021 at 01:26, Dillon Hammill wrote:
| Thanks for your help Dirk, I think I have everything I need to get things 
working now. I just needed a push in the right direction to discover wrap and 
as from Rcpp - they are awesome!

They are indeed.  (And, if I may, feature prominently in the 'Introduction to
Rcpp' and other documents we offer. But I acknowledge that there are lots of
those.)
 
| I am just beginning to explore the power Rcpp and PcppParallel.
| 
| Keep up the great work!

Thanks, we try :)

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Apply Defined Rcpp Functions In Parallel

[Dirk Eddelbuettel]

On 17 August 2021 at 19:19, Dillon Hammill wrote:
| What is the easiest way to perform this conversion (say for vector to RVector 
or vector of vectors to matrix)?

I always find that the existing RcppParallel that JJ and Kevin set up years
ago excels there.  Study them, they do it right, they work, and they should
give you leads.

For concrete follow-up questions we will be all ears, but I have the feeling
that what you are after now is in fact covered over there.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Apply Defined Rcpp Functions In Parallel

[Dirk Eddelbuettel]

Dillon,

The point of RMatrix and RVector in RcppParallel is to shield objects inside
the RcppParallel blocks using Intel TBB from any interaction with the outer R
process which may, or may not, run a gc() to rearrange its memory.

Where they work, you should not use Rcpp's own NumericMatrix and alike. As for

   Is there a way to write generic functions that will work in both cases?

Yes, with care. Standard C++ should work. You have to 'arrange' functionality
in such a way that you have "clean" internal functions (using STL objects
and/or RMatrix and RVector) plus a wrapper making them callable from R).

Is it safe to create new objects on each thread

Yes, but they have to standard C++ objects. At the once, your sums or
reductions or ... have completed, converted to something you can return to R.

The golden rule simply is 'no R objects in the inner core'.

Hope this helps and was clear enough, I am still on my first coffee.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Package using Rcpp+openmp - fatal error: 'omp.h' file not found

[Dirk Eddelbuettel]

(I replied earlier but that seems to have gotten lost. Apologies to anybody
who may receive two copies, and thanks to Simon for his answer.  -- Dirk)


On 9 August 2021 at 17:04, Naeem Khoshnevis wrote:
| Do you know a workaround for this issue?

Wrap the #include by #ifdef _OPENMP and #endif

Test for presence of OpenMP (for example via a configure script). 

Use the standard R compilation flags. RcppArmadillo uses

  PKG_CXXFLAGS = -I../inst/include @OPENMP_FLAG@
  PKG_LIBS= @OPENMP_FLAG@ $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

where @OPENMP_FLAG@ gets set if OpenMP is found.  Other packages just use

  PKG_CXXFLAGS = $(SHLIB_OPENMP_CXXFLAGS) 
  PKG_LIBS = $(SHLIB_OPENMP_CXXFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

relying on R which sets SHLIB_OPENMP_CXXFLAGS.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Troubleshooting dependency issues

[Dirk Eddelbuettel]

On 15 July 2021 at 15:44, Naeem Khoshnevis wrote:
| Thanks, Simon and Dirk,
| 
| I can install the packages normally on macOS. However, I want to install it
| in a conda environment.

That is (for all intents and purposes) a different use case than what we
support (for free) so I suggest you rely on the Conda volunteers (or
commercial supporters) to help you.

We support software on CRAN, which tends to "just work" if used as intended.

But we are volunteers in this, so there are limits to what we can cover.

Dirk

| Thanks for sharing the link. I really appreciate
| it.
| 
| Here is a reproducible example, in case you have time to try.
| 
| On macOS:
| 
| Step 1: create a conda environment and install R
| 
| conda create -n r-environment r-essentials r-base
| 
| Step 2: activate the environment
| 
| conda activate r-environment
| 
| Step 3: Install rstudio
| 
| conda install -c r rstudio
| 
| Step 4: Install some required packages
| 
| conda install -c r r-devtools
| conda install -c r r-wcorr
| conda install -c r r-ranger
| conda install -c conda-forge r-rcpparmadillo
| conda install -c r r-testthat
| conda install -c conda-forge r-superlearner
| conda install -c conda-forge r-polycor
| conda install -c conda-forge r-logger
| 
| Step 6:
| According to this page, download dependencies:
| https://mac.r-project.org/openmp/
| 
| And copied them into the environment include and lib directory.
| 
| 
| Step 7:
| According to this page, I exported variables in step 6.
| 
https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html#set-env-vars
| 
| #!/bin/sh
| 
| export PKG_CPPFLAGS='-Xclang -fopenmp'
| export PKG_LIBS='-lomp'
| 
| Step 8:
| Reactivated the conda environment
| 
| Step 9:
| run: rstudio
| 
| Step 10:
| inside rstudio
| library(devtools)
| install_github("fasrc/CausalGPS")
| 
| I get the following error:
| 
| Downloading GitHub repo fasrc/CausalGPS@master
| Error: Could not find tools necessary to compile a package
| 
| I think something is wrong with Step 7. Because apparently, I lost the path
| to Xcode. Without Step 7, I get the following error:
| 
| In file included from ColorSpace.cpp:1:
| In file included from ./ColorSpace.h:4:
| In file included from env/bin/../include/c++/v1/typeinfo:60:
| In file included from env/bin/../include/c++/v1/exception:81:
| In file included from env/bin/../include/c++/v1/cstdlib:85:
| In file included from env/bin/../include/c++/v1/stdlib.h:100:
| env/bin/../include/c++/v1/math.h:773:12: error: no member named 'labs' in
| the global namespace; did you mean 'abs'?
|   return ::labs(__x);
|  ~~^
| ~/env/bin/../include/c++/v1/math.h:772:39: note: 'abs' declared here
| inline _LIBCPP_INLINE_VISIBILITY long abs(long __x) _NOEXCEPT {
|   ^
| ~/env/bin/../include/c++/v1/math.h:777:12: error: no member named 'llabs'
| in the global namespace
|   return ::llabs(__x);
|  ~~^
| ~/env/bin/../include/c++/v1/math.h:785:12: error: no member named 'fabsf'
| in the global namespace
|   return ::fabsf(__lcpp_x);
|  ~~^
| ~/env/bin/../include/c++/v1/math.h:789:12: error: no member named 'fabs' in
| the global namespace; did you mean 'abs'?
|   return ::fabs(__lcpp_x);
|  ~~^
| ~/env/bin/../include/c++/v1/math.h:772:39: note: 'abs' declared here
| inline _LIBCPP_INLINE_VISIBILITY long abs(long __x) _NOEXCEPT {
|   ^
| ~/env/bin/../include/c++/v1/math.h:794:12: error: no member named 'fabsl'
| in the global namespace
|   return ::fabsl(__lcpp_x);
|  ~~^
| 
| Best regards,
| Naeem
| 
| On Thu, Jul 15, 2021 at 3:25 AM Simon Urbanek 
| wrote:
| 
| > Naeem,
| >
| > I'm not sure which issues are you talking about specifically. If your
| > package is well written, the instructions at
| > https://mac.r-project.org/openmp/ should be sufficient with regular CRAN
| > installation of R and standard tools.
| >
| > Cheers,
| > Simon
| >
| >
| >
| > > On Jul 15, 2021, at 02:41, Naeem Khoshnevis 
| > wrote:
| > >
| > > Hi,
| > >
| > > I hope this email finds you well.
| > > I wondered what the best approaches to troubleshooting C++ dependencies
| > issues in general and specifically in R are; specifically, those packages
| > which are using OpenMP and we want to install on macOS.
| > > So far, I am just googling the error and finding out what the problem
| > is. However, it is hard to address issues and come up with long-term
| > solutions without internalizing the concepts.
| > > One example is creating a conda environment for each R package project
| > and installing llvm, clang, etc into each environment.
| > > I talked to several software engineers; however, I could not find a
| > convincing answer. I think I do not know what I do not know about this
| > topic, which prevents me from asking good questions. I would be grateful if
| > you could let me know your thoughts about these questions.
| > >
| > > Where is a good place to start learning about this 

Re: [Rcpp-devel] Any recent change that would remove Rcpp_precious_remove?

[Dirk Eddelbuettel]

On 15 July 2021 at 14:41, Iñaki Ucar wrote:
| On Thu, 15 Jul 2021 at 10:27, ma wh  wrote:
| > Error in C_valid_tz(tzone): Function 'Rcpp_precious_remove' not provided by 
package 'Rcpp'
| 
| TL;DR: update your library.

Good catch by Inaki. I had overlooked the C_valid_tz() handle. You are trying
to _run_ code, I had assumed you had tried to compile code.

The only situation that is supportable and testable under the CRAN model is
in fact the CRAN model: _all_ your packages need to be current as they are
tested jointly.  Nobody has the ability to test all random cross-products of
old and new versions.  Usually, it just works, when it doesn't you need to
really make sure everything is current.

And in general, we work really hard to not modify interfaces, and we have
done so only a very few times in the nearly fifteen year history of Rcpp. As
this particular change is an important one, we went ahead with this change.
And would likely do so again.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Any recent change that would remove Rcpp_precious_remove?

[Dirk Eddelbuettel]

On 15 July 2021 at 08:24, ma wh wrote:
| Colleague of mine wrote some R last week that was working OK, and hasn't been 
changed in itself since that time. This week it's ceased working( I've tried it 
on my machine and also see a fail, the following error is encountered:
| 
| Error in C_valid_tz(tzone): Function 'Rcpp_precious_remove' not provided by 
package 'Rcpp'
| 
| Searching around there aren't many hits. Those I do find seem quite recent 
(stackoverflow questions or GitHub issues logged in various projects, dates of 
posting are within the last few days). None of the posted queries seem to have 
a solution, one person said restarting RStudio helped, but not in my case. The 
SO question I found was marked as deleted. The GitHub issue I found was "I 
solved it" but no mention of how. The SO question was asking about svg export: 
https://stackoverflow.com/questions/68345118/exporting-a-ggplot-in-svg-call-a-non-esixting-function
| The GitHub were also asking about packages I don't use -
| https://github.com/r-spatial/spdep/issues/60
| https://github.com/drizopoulos/JMbayes2/issues/5
| 
| Anyone on the list have any pointers? Thanks

Packages following a the GNU style often have a file ChangeLog which "details
changes made to the code". Rcpp follows this convention, see 2021-07-05 and
2021-01-017.

Packages following the R packaging conventions often have a file inst/NEWS.rd
(also rendered as NEWS at CRAN). Rcpp follow this conventions, see the Rcpp
1.0.7 release (even if the functions is not named).

Packages have source code you can search.I like `ag` aka "the
silversearcher":

  edd@rob:~/git/rcpp(master)$ ag -c Rcpp_precious_remove
  ChangeLog:2
  inst/include/Rcpp/routines.h:3
  inst/include/RcppCommon.h:2
  src/rcpp_init.cpp:1
  src/barrier.cpp:1
  edd@rob:~/git/rcpp(master)$ 

It is still there, and available via the standard export mechanism.

I recommend your friend take a look. The function is a) still there yet has
also b) been supplanted by a more sufficient alternative.

Otherwise, a reproducible example would be the only way to make this
concrete.

Hope this helps, Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Troubleshooting dependency issues

[Dirk Eddelbuettel]

Hi Naeem,

On 14 July 2021 at 11:03, Naeem Khoshnevis wrote:
| Thank you so much for your response. Rcpp is excellent, and I am using it
| (with OpenMP), and it significantly improved the package (Thank you!). I
| have tried it on macOS and centos.

Ok, as stated, I do not work on or know macOS. Others may be of help, there
are tutorials (often by @coatless) which got a lot people going. Give that a
shot, ask here when you get stuck.

CentOS can be iffy. When I had to use in the past the setup in the distro was
so old that we went the "devtoolset" (IIRC) route: a semi- or fully official
newer compiler set a few versions ahead of what is in the distro. That should
include OpenMP.

| I was trying to set up a conda
| environment. There are many HPC clusters that are using old versions of R
| as well as rstudio. In the past, using conda env helped me to install an

HPC can indeed be tricky. Best to liaise with your local sysadmins. One
difficulty once you load the 'modules' (or however the scheme is called at
your end) you have to align it with R. Use 'R CMD config --all' to see what R
uses, you be able to tweak via your ~/.R/Makevars

| updated version of R., But I understand why you do not recommend it. I will
| prepare a reproducible example and will let you know. Thank you so much.

Sounds good. Hopefully we get that squared away in a few controlled steps.

Dirk

| Best regards,
| Naeem
| 
| On Wed, Jul 14, 2021 at 9:55 AM Dirk Eddelbuettel  wrote:
| 
| >
| > Hi Naeem,
| >
| > On 14 July 2021 at 09:41, Naeem Khoshnevis wrote:
| > | Hi,
| > |
| > | I hope this email finds you well.
| > | I wondered what the best approaches to troubleshooting C++ dependencies
| > | issues in general and specifically in R are; specifically, those packages
| > | which are using OpenMP and we want to install on macOS.
| >
| > Is this dependencies (plural) or a single core dependency (singular) on a
| > single OS (macOS) ?  Those are different issues. (And Rcpp has no incluence
| > over what Cupertino (macOS) or Auckland (macOS deployment for R does) -- we
| > have to play the card we are dealt, and that have always been "issues" and
| > some HOWTOs and duct tape.  On the margin, if this is your question, it may
| > also be one for r-sig-mac.
| >
| > Also, and to make this concrete: Do you have a minimally reproducible
| > issue?
| >
| > | So far, I am just googling the error and finding out what the problem is.
| > | However, it is hard to address issues and come up with long-term
| > solutions
| > | without internalizing the concepts.
| > | One example is creating a conda environment for each R package project
| > and
| > | installing llvm, clang, etc into each environment.
| >
| > As an R developer, I have a simple rule: Just say No to conda. Mixing and
| > matching between standard / core builds (using the recommended R toolchain)
| > and conda appears to mostly end in tears.
| >
| > | I talked to several software engineers; however, I could not find a
| > | convincing answer. I think I do not know what I do not know about this
| > | topic, which prevents me from asking good questions. I would be grateful
| > if
| > | you could let me know your thoughts about these questions.
| >
| > Again, a reproducible example would help.
| >
| > Rcpp is used by over 2300 packages on CRAN. Many use OpenMP. You can search
| > at GitHub within the mirroring 'cran' organisation to see what other
| > packages
| > do. Given that you can also see the outcome (the package 'status' pages at
| > CRAN) that is not a bad approach.
| >
| > Dirk
| >
| > | Where is a good place to start learning about this topic?
| > | Is a professional C++ developer necessarily good at troubleshooting
| > | problems with compilers and linkers? Or these are two different topics.
| > |
| > | Best regards,
| > | Naeem Khoshnevis
| > | ___
| > | Rcpp-devel mailing list
| > | Rcpp-devel@lists.r-forge.r-project.org
| > | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| > --
| > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Troubleshooting dependency issues

[Dirk Eddelbuettel]

Hi Naeem,

On 14 July 2021 at 09:41, Naeem Khoshnevis wrote:
| Hi,
| 
| I hope this email finds you well.
| I wondered what the best approaches to troubleshooting C++ dependencies
| issues in general and specifically in R are; specifically, those packages
| which are using OpenMP and we want to install on macOS.

Is this dependencies (plural) or a single core dependency (singular) on a
single OS (macOS) ?  Those are different issues. (And Rcpp has no incluence
over what Cupertino (macOS) or Auckland (macOS deployment for R does) -- we
have to play the card we are dealt, and that have always been "issues" and
some HOWTOs and duct tape.  On the margin, if this is your question, it may
also be one for r-sig-mac.

Also, and to make this concrete: Do you have a minimally reproducible issue?

| So far, I am just googling the error and finding out what the problem is.
| However, it is hard to address issues and come up with long-term solutions
| without internalizing the concepts.
| One example is creating a conda environment for each R package project and
| installing llvm, clang, etc into each environment.

As an R developer, I have a simple rule: Just say No to conda. Mixing and
matching between standard / core builds (using the recommended R toolchain)
and conda appears to mostly end in tears.

| I talked to several software engineers; however, I could not find a
| convincing answer. I think I do not know what I do not know about this
| topic, which prevents me from asking good questions. I would be grateful if
| you could let me know your thoughts about these questions.

Again, a reproducible example would help.

Rcpp is used by over 2300 packages on CRAN. Many use OpenMP. You can search
at GitHub within the mirroring 'cran' organisation to see what other packages
do. Given that you can also see the outcome (the package 'status' pages at
CRAN) that is not a bad approach.

Dirk

| Where is a good place to start learning about this topic?
| Is a professional C++ developer necessarily good at troubleshooting
| problems with compilers and linkers? Or these are two different topics.
| 
| Best regards,
| Naeem Khoshnevis
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] Rcpp 1.0.7 now on CRAN

[Dirk Eddelbuettel]

Rcpp 1.0.7 is now on CRAN.  As emailed here on Saturday, we actually needed
to make one change relative to how Modules code from earlier builds is
handled. (And with that I replaced the 1.0.7 version in the drat repo; if you
installed it earlier than today, and "experience symptoms", consider an
update to get the one-line change).

Overall, this release should be fine as you have come to expect from our
releases. Out of over 2300 packages in a reverse depends check, CRAN (and I
earlier) found segfaults in four packages in circumstances that are
suggestive of local issues. I will reach out to the package maintainers,
likely tomorrow, and try to help but I cannot debug each failing package.

A few more comments on the release (and a big "Welcome to Iñaki" ;-) are in
the standard blog post announcing it at

  http://dirk.eddelbuettel.com/blog/2021/07/07#rcpp_1.0.7

Thanks,  Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] Rcpp 1.0.7

[Dirk Eddelbuettel]

Rcpp 1.0.7 was uploaded to CRAN; it may take a few days to sort the release
out as it the weekend and as the number of reverse dependencies may throw up
an issue or two.  In the mean time you can get the release from the usual
drat repo.

See the NEWS.Rd for a summary of changes.  Thanks to everybody who helped
with the release, especially Inaki.

Cheers, Dirk


[1] Which should all be false positives as we did a fair amount of testing
leading up to this release.
-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] template argument deduction/substitution failed

[Dirk Eddelbuettel]

On 13 June 2021 at 11:40, Joseph Park wrote:
| Thank you.
| 
| Changing the function argument limit to 20 variables resolves the error.

Excellent.
 
| If this limit can be relaxed, that would be helpful for future development.

For that to happen someone will have to sit down and do it.
 
| Thank you for Rcpp, and your patience with my ill-formed posts.

Our pleasure, and glad you found the plain text switch :)

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] template argument deduction/substitution failed

[Dirk Eddelbuettel]

On 12 June 2021 at 16:02, Kevin Ushey wrote:
| I think you're bumping into the 20 argument limit for our (now rather old)
| Vector::create() implementation. I thought we also had a variadic C++11
| version for this, but apparently I am mistaken...

Hm. We have a few header files that are similarly macro-generated (and
sometimes the macro code is behind ...) but I also thought we had this
generalized with variadic arguments. Maybe not.
 
| A workaround is to use something like the ListBuilder class I put together
| a while back here:
| 
| 
https://stackoverflow.com/questions/27371543/how-many-vectors-can-be-added-in-dataframecreate-vec1-vec2/27371771#27371771

Maybe we can carry that over now that C++11 is the minimum standard for R ?

| but on our side, it would be nice to have a variadic create for when C++11
| and above is supported / enabled by the compiler.

I have been mulling an idea regarding a top-level header file choice also
signaling minimal language standards opening the door a little to C++14,
C++17, C++20, ... . I should open an issue ticket one of these days.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Exporting rcpp-based function into parLapply workers in an R package

[Dirk Eddelbuettel]

This is getting off topic but as you James saw fit to advertise his package
(as he should, it is clearly helpful to some, himself included), here are my
$0.02 of why it is not for me:

On 14 May 2021 at 20:54, Balamuta, James Joseph wrote:
| For code searches, consider using the {searcher} package: 
https://github.com/r-assist/searcher 
| 
| In particular, the search_github() function handles the query formatting. As 
an example, try:

I keep the R prompt(s) (in Emacs, generally) to data work, and do more work
like this on the shell. Where this is less useful (though I sometimes wrap R
commands in littler script). Here I particularly dislike
| 
| searcher::search_github("clusterEvalQ ")
| 
| This opens a web browser with:
| 
| 
https://github.com/search?q=clusterEvalQ%20%20language:r%20type:issue=Issues

the shell-to-browser pivot. I have some "permanent tabs" dedicated to GH, I
prefer to search therein.  Also, why default to issues when the query didn't
have it? Anyway ...
 
| Lastly, there is an R-specific Google search engine available at: 
https://rseek.org/ It's not quite google code search, but it's useful! Plus, 
there is a {searcher} function for that as well, e.g. searcher::search_rseek().
| (Thanks Alex Rossell Hayes for that contribution.)

Yes that's been around for a while, but codesearch.google.com was still
better and is missed.  One of the other code aggregators that (AFAIK is also
gone now) had a different search engine too.

This whole thread is highly off-tocpic and likely answered by some SO answers
as has bee pointed out as well as possibly some discussions in the r-sig-hpc
list (which is mostly dormant these days).

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Exporting rcpp-based function into parLapply workers in an R package

[Dirk Eddelbuettel]

On 14 May 2021 at 14:07, Michael Weylandt wrote:
| The CRAN organization / mirror on GitHub (github.com/cran) is very
| useful for this sort of thing.
| 
| Searching for "library(" and "clusterEvalQ"
| (https://github.com/search?q=org%3Acran+library%28+clusterEvalQ=code)
| in that organization yields the following result (chosen at random):

Yes! I actually do these type of searches all the time myself (and am old
enough to bemoan the disappearance the Google code search tool that preceded
it ages ago).

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Posting question's guidelines

[Dirk Eddelbuettel]

On 14 May 2021 at 11:12, Naeem Khoshnevis wrote:
| Hope this email finds you well.  Can I post Rcpp related questions (as a
| user) on this mailing list?

Yes please -- that is *exactly* for it is for: doing 'Rcpp devel'opment
by which we also mean using it in your packages and work.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] efficient ingestion of "sparse csv"

[Dirk Eddelbuettel]

Vincent,

In the broad terms of the question the best answer may be a simple "sure".
More seriously, there have been many approaches.  Consider for example the
recent Rcpp Gallery post lead by Zach (with some edits by me):
  https://gallery.rcpp.org/articles/sparse-matrix-class/

It's focus on not copying  again if we already have them as R vectors,
which is a fair point. If the goal is to get to SuperLU via (Rcpp)Armadillo
then I do not think you can avoid the (internal) copies.  As always, the
answer may be "it depends".

Hope this helps, happy to refine,  Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Help with R CMD CHECK for rtree package

[Dirk Eddelbuettel]

On 6 May 2021 at 19:05, Kent Johnson wrote:
| I'm not sure how to proceed. I can try submitting to CRAN with an explanation 
of the warnings. ISTM it would be better for {BH} to be submitted with the 
#pragmas in place; then there is just one fix and one exception, rather than 
the possibility of multiple packages having this issue. Dirk, do you have any 
recommendation?

The #pragmas are deactivated because CRAN explicitly says so.
 
Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Help with R CMD CHECK for rtree package

[Dirk Eddelbuettel]

On 6 May 2021 at 10:45, Iñaki Ucar wrote:
| Hi Kent,
| 
| On Wed, 5 May 2021 at 17:54, Kent Johnson  wrote:
| >
| > Hi,
| >
| > I am a maintainer of this package - https://github.com/akoyabio/rtree - 
originally inspired by this example - 
https://gallery.rcpp.org/articles/Rtree-examples/. This package wraps the rtree 
implementation from BH 1.7.2.0-3 to provide fast methods for finding points 
nearby to other points in large data sets.
| >
| >  I want to submit the package to CRAN but I have a CMD CHECK warning on 
Windows that I can't resolve.
| >
| > Running CMD CHECK from GitHub Actions, on Microsoft Windows Server 2019 
10.0.17763, I get this error message:
| >
| > -- R CMD check results  rtree 0.2.0 

| > Duration: 1m 42.7s
| >
| > > checking whether package 'rtree' can be installed ... WARNING
| >   See below...
| >
| > 0 errors v | 1 warning x | 0 notes v
| > Error: Error: R CMD check found WARNINGs
| > Execution halted
| > Error: Process completed with exit code 1.
| >
| > The full output is here: 
https://github.com/akoyabio/rtree/runs/2502841486?check_suite_focus=true
| > The message says "See below..." but there is nothing below?
| 
| Below I see this:
| 
| * checking whether package 'rtree' can be installed ... WARNING
| Found the following significant warnings:
| 
|   
D:/a/_temp/Library/BH/include/boost/geometry/index/detail/varray_detail.hpp:544:13:
| warning: 'void* memcpy(void*, const void*, size_t)' writing to an
| object of type 'struct std::pair, unsigned int>' with no trivial
| copy-assignment; use copy-assignment or copy-initialization instead
| [-Wclass-memaccess]
| 
|   
D:/a/_temp/Library/BH/include/boost/geometry/index/detail/varray_detail.hpp:578:13:
| warning: 'void* memcpy(void*, const void*, size_t)' writing to an
| object of type 'struct std::pair, unsigned int>,
| boost::geometry::index::quadratic<16>,
| boost::geometry::model::box >,
| 
boost::geometry::index::detail::rtree::allocators, unsigned int> >,
| std::pair, unsigned int>,
| boost::geometry::index::quadratic<16>,
| boost::geometry::model::box >,
| boost::geometry::index::detail::rtree::node_variant_static_tag>,
| boost::geometry::index::detail::rtree::node_variant_static_tag>,
| 
boost::geometry::index::detail::rtree::variant_internal_node, unsigned int>,
| boost::geometry::index::quadratic<16, 4>,
| boost::geometry::model::box >,
| 
boost::geometry::index::detail::rtree::allocators, unsigned int> >,
| std::pair, unsigned int>,
| boost::geometry::index::quadratic<16, 4>,
| boost::geometry::model::box >,
| boost::geometry::index::detail::rtree::node_variant_static_tag>,
| boost::geometry::index::detail::rtree::node_variant_static_tag> >*>'
| with no trivial copy-assignment; use copy-assignment or
| copy-initialization instead [-Wclass-memaccess]
| 
|   
D:/a/_temp/Library/BH/include/boost/geometry/index/detail/varray_detail.hpp:237:13:
| warning: 'void* memcpy(void*, const void*, size_t)' writing to an
| object of type 'struct std::pair, unsigned int>' with no trivial
| copy-assignment; use copy-assignment or copy-initialization instead
| [-Wclass-memaccess]
| 
| See 'D:/a/rtree/rtree/check/rtree.Rcheck/00install.out' for details.
| 
| And even more details if you download the artifacts of your build and
| review that file. So it's a Boost thing, and there's probably nothing
| you can do about it beyond talking to CRAN. There are packages on CRAN
| with these warnings.

But for me it actually failed to build at
 - RHub
 - win-builder r-release
 - win-builder r-devel
when I submitted an unchanged tarball (with me as maintainer to get the 
result). 

So there may be more going on.  Could just be a setup issue which happens at
RHub and win-builder.  But Boost Geometry may be a more dicey part of Boost.

| > Running on my local Windows 10 PC I get this warning and a note:
| >
| > -- R CMD check results  rtree 0.2.0 

| > Duration: 1m 2.2s
| >
| > > checking whether package 'rtree' can be installed ... WARNING
| >   See below...
| >
| > > checking compiled code ... NOTE
| >   Note: information on .o files for x64 is not available
| >   File 'C:/Research/rtree.Rcheck/rtree/libs/x64/rtree.dll':
| > Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| > Found 'exit', possibly from 'exit' (C), 'stop' (Fortran)
| > Found 'printf', possibly from 'printf' (C)
| 
| This is problably a false positive.

Maybe. Maybe not. It does not seem to reproduce on Linux.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Help with R CMD CHECK for rtree package

[Dirk Eddelbuettel]

On 5 May 2021 at 22:49, Kent Johnson wrote:
| Thanks for your suggestion. I updated to build with latest BH and get the 
same errors:
| https://github.com/akoyabio/rtree/runs/2513098433?check_suite_focus=true

Yes, as I said, it doesn't even work for me at all on RHub or Win-Builder.
Might be compiler-related as it does build for me on Linux.

| (I was using BH 1.72 because in 1.75 boost::geometry requires C++ 14 which 
IIUC is not fully supported in R 3.6 on Windows.)

Well R 4.0.0 was released a year ago so I don't care too too much about 3.6.0.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Help with R CMD CHECK for rtree package

[Dirk Eddelbuettel]

On 5 May 2021 at 15:54, Kent Johnson wrote:
| I am a maintainer of this package - https://github.com/akoyabio/rtree - 
originally inspired by this example - 
https://gallery.rcpp.org/articles/Rtree-examples/. This package wraps the rtree 
implementation from BH 1.7.2.0-3 to provide fast methods for finding points 
nearby to other points in large data sets.
| 
|  I want to submit the package to CRAN but I have a CMD CHECK warning on 
Windows that I can't resolve.
| 
| Running CMD CHECK from GitHub Actions, on Microsoft Windows Server 2019 
10.0.17763, I get this error message:
| -- R CMD check results  rtree 0.2.0 

| Duration: 1m 42.7s
| 
| > checking whether package 'rtree' can be installed ... WARNING
|   See below...
| 
| 0 errors v | 1 warning x | 0 notes v
| Error: Error: R CMD check found WARNINGs
| Execution halted
| Error: Process completed with exit code 1.

It actually failed for me on RHub and on Win-Builder once I removed the
hard-equality constraint on a BH version no longer on CRAN:

  LinkingTo: Rcpp, BH (== 1.72.0-3)

That makes in unbuildable in most situations, I fear.
 
| The full output is here: 
https://github.com/akoyabio/rtree/runs/2502841486?check_suite_focus=true
| The message says "See below..." but there is nothing below?
| 
| Running on my local Windows 10 PC I get this warning and a note:
| -- R CMD check results  rtree 0.2.0 

| Duration: 1m 2.2s
| 
| > checking whether package 'rtree' can be installed ... WARNING
|   See below...
| 
| > checking compiled code ... NOTE
|   Note: information on .o files for x64 is not available
|   File 'C:/Research/rtree.Rcheck/rtree/libs/x64/rtree.dll':
| Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| Found 'exit', possibly from 'exit' (C), 'stop' (Fortran)
| Found 'printf', possibly from 'printf' (C)

We would have to find out where this comes from.  But for starters, can you
make it work at your end with the currently released BH version, 1.75.0-0 ?

Dirk

|   Compiled code should not call entry points which might terminate R nor
|   write to stdout/stderr instead of to the console, nor use Fortran I/O
|   nor system RNGs. The detected symbols are linked into the code but
|   might come from libraries and not actually be called.
| 
|   See 'Writing portable packages' in the 'Writing R Extensions' manual.
| 
| 0 errors v | 1 warning x | 1 note x
| Error: R CMD check found WARNINGs
| Execution halted
| 
| Exited with status 1.
| 
| Again I have the "See below..." message and a confusing NOTE - I do not have 
any calls to abort, exit or printf in my code.
| 
| Any help in fixing the warning and note is much appreciated. If this is not 
an appropriate place to ask, please let me know what would be better. I'm 
perplexed.
| 
| Thank you,
| Kent Johnson
| Principal Software Developer
| Akoya Biosciences
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel