Re: [R-pkg-devel] using portable simd instructions

[Serguei Sokol]

Le 27/03/2024 à 14:54, jesse koops a écrit :

I tried that but I found the interface awkward and there was really no
performance bonus. It was in the early phase of experimentation and I
didn't save it, so it could very well be that I got the compiler
settings wrong and simd was not used. But if that was the case, there
would still be the problem of using the correct compiler settings
cross platform.

When I compile the example of the cited page with "authorized" flag "-std":

   g++ -std=c++20 stdx_simd.cpp -o tmp.exe

then I do:

   objdump -d tmp.exe > tmp.asm

I do find simd instructions in assembler code, e.g.:

   grep paddd tmp.asm

14a8:   66 0f fe c1 paddd  %xmm1,%xmm0
8f7b:   66 0f fe c1 paddd  %xmm1,%xmm0



Op wo 27 mrt 2024 om 14:44 schreef Serguei Sokol :


Le 26/03/2024 à 15:51, Tomas Kalibera a écrit :


On 3/26/24 10:53, jesse koops wrote:

Hello R-package-devel,

I recently got inspired by the rcppsimdjson package to try out simd
registers. It works fantastic on my computer but I struggle to find
information on how to make it portable. It doesn't help in this case
that R and Rcpp make including Cpp code so easy that I have never had
to learn about cmake and compiler flags. I would appreciate any help,
including of the type: "go read instructions at ...".

I use RcppArmadillo and Rcpp. I currenlty include the following header:

#include 

The functions in immintrin that I use are:

_mm256_loadu_pd
_mm256_set1_pd
_mm256_mul_pd
_mm256_fmadd_pd
_mm256_storeu_pd

and I define up to four __m256d registers. From information found
online (not sure where anymore) I constructed the following makevars
file:

CXX_STD = CXX14

PKG_CPPFLAGS = -I../inst/include -mfma -msse4.2 -mavx

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

(I also use openmp, that has always worked fine, I just included all
lines for completeness) Rcheck gives me two notes:

─  using R version 4.3.2 (2023-10-31 ucrt)
─  using platform: x86_64-w64-mingw32 (64-bit)
─  R was compiled by
 gcc.exe (GCC) 12.3.0
 GNU Fortran (GCC) 12.3.0

❯ checking compilation flags used ... NOTE
Compilation used the following non-portable flag(s):
  '-mavx' '-mfma' '-msse4.2'

❯ checking C++ specification ... NOTE
  Specified C++14: please drop specification unless essential

But as far as I understand, the flags are necessary, at least in GCC.
How can I make this portable and CRAN-acceptable?


I think it the best way for portability is to use a higher-level library
that already has done the low-level business of maintaining multiple
versions of the code (with multiple instruction sets) and choosing one
appropriate for the current CPU. It could be say LAPACK, BLAS, openmp,
depending of the problem at hand.

Talking about libraries, may be the
https://en.cppreference.com/w/cpp/experimental/simd will do the job?

Best,
Serguei.

   In some cases, code can be rewritten

so that the compiler can vectorize it better, using the level of
vectorized instructions that have been enabled.

Unconditionally using GCC-specific or architecture-specific options in
packages would certainly not be portable. Even on Windows, R is now used
also with clang and on aarch64, so one should not assume a concrete
compiler and architecture.

Please note also that GCC on Windows has a bug due to which AVX2
instructions cannot be used reliably - the compiler doesn't always
properly align local variables on the stack when emitting these. See
[1,2] for more information.

Best
Tomas

[1] https://stat.ethz.ch/pipermail/r-sig-windows/2024q1/000113.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412



kind regards,
Jesse

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


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




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

Re: [R-pkg-devel] using portable simd instructions

[Serguei Sokol]

Le 26/03/2024 à 15:51, Tomas Kalibera a écrit :


On 3/26/24 10:53, jesse koops wrote:

Hello R-package-devel,

I recently got inspired by the rcppsimdjson package to try out simd
registers. It works fantastic on my computer but I struggle to find
information on how to make it portable. It doesn't help in this case
that R and Rcpp make including Cpp code so easy that I have never had
to learn about cmake and compiler flags. I would appreciate any help,
including of the type: "go read instructions at ...".

I use RcppArmadillo and Rcpp. I currenlty include the following header:

#include 

The functions in immintrin that I use are:

_mm256_loadu_pd
_mm256_set1_pd
_mm256_mul_pd
_mm256_fmadd_pd
_mm256_storeu_pd

and I define up to four __m256d registers. From information found
online (not sure where anymore) I constructed the following makevars
file:

CXX_STD = CXX14

PKG_CPPFLAGS = -I../inst/include -mfma -msse4.2 -mavx

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

(I also use openmp, that has always worked fine, I just included all
lines for completeness) Rcheck gives me two notes:

─  using R version 4.3.2 (2023-10-31 ucrt)
─  using platform: x86_64-w64-mingw32 (64-bit)
─  R was compiled by
    gcc.exe (GCC) 12.3.0
    GNU Fortran (GCC) 12.3.0

❯ checking compilation flags used ... NOTE
   Compilation used the following non-portable flag(s):
 '-mavx' '-mfma' '-msse4.2'

❯ checking C++ specification ... NOTE
 Specified C++14: please drop specification unless essential

But as far as I understand, the flags are necessary, at least in GCC.
How can I make this portable and CRAN-acceptable?


I think it the best way for portability is to use a higher-level library 
that already has done the low-level business of maintaining multiple 
versions of the code (with multiple instruction sets) and choosing one 
appropriate for the current CPU. It could be say LAPACK, BLAS, openmp, 
depending of the problem at hand.
Talking about libraries, may be the 
https://en.cppreference.com/w/cpp/experimental/simd will do the job?


Best,
Serguei.

 In some cases, code can be rewritten
so that the compiler can vectorize it better, using the level of 
vectorized instructions that have been enabled.


Unconditionally using GCC-specific or architecture-specific options in 
packages would certainly not be portable. Even on Windows, R is now used 
also with clang and on aarch64, so one should not assume a concrete 
compiler and architecture.


Please note also that GCC on Windows has a bug due to which AVX2 
instructions cannot be used reliably - the compiler doesn't always 
properly align local variables on the stack when emitting these. See 
[1,2] for more information.


Best
Tomas

[1] https://stat.ethz.ch/pipermail/r-sig-windows/2024q1/000113.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412



kind regards,
Jesse

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


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


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

Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz

[Serguei Sokol]

Le 07/03/2024 à 11:08, Duncan Murdoch a écrit :

On 07/03/2024 4:16 a.m., Ivan Krylov wrote:

On Wed, 6 Mar 2024 13:46:55 -0500
Duncan Murdoch  wrote:


is this just a more or less harmless error, thinking that
the dot needs escaping


I think it's this one. You are absolutely right that the dot doesn't
need escaping in either TRE (which is what's used inside exportPattern)
or PCRE. In PRCE, this regular expression would have worked as intended:

# We do match backslashes by mistake.
grepl('[\\.]', '\\')
# [1] TRUE

# In PCRE, this wouldn't have been a mistake.
grepl('[\\.]', c('\\', '.'), perl = TRUE)
# [1] FALSE TRUE



Thanks, I didn't realize that escaping in PCRE was optional.
Escaping is optional only in brackets []. Without them it becomes 
mandatory if we want to catch just "." not any character :


grepl('.', c('\\', '.'), perl = TRUE)
#[1] TRUE TRUE

Best,
Serguei.




So the default exportPattern line could be

   exportPattern("^[^.]")

and it would work even if things were changed so that PCRE was used 
instead of TRE.


Duncan Murdoch

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


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

Re: [R-pkg-devel] CRAN uses an old version of clang

[Serguei Sokol]

Not really responding the question, however another way could be to 
consider if your code is in Rcpp and calls to bessel and gamma function 
are not very frequent. These functions are available in base R and as 
such are callable via Function():


> Rcpp::evalCpp('Function("besselK")(1., 0.2)')
[1] 0.42722
> Rcpp::evalCpp('Function("gamma")(4)') # 3!
[1] 6

https://teuder.github.io/rcpp4everyone_en/230_R_function.html#function


Best,
Serguei.

Le 09/02/2024 à 15:59, Marcin Jurek a écrit :

Dear community,

I recently submitted an update to my package. It previous version relied on
Boost for Bessel and gamma functions but a colleague pointed out to me that
they are included in the standard library beginning with the C++17
standard.

I don't have access to a Mac so I tested my package on Rhub and on my local
Linux and everything ran fine. However, it seems like CRAN is using an old
version of Clang (14.03 vs 16 being the newest one) and it complained about
these Bessel functions. I'm pasting the installation log below. I wonder if
this is something I could hope to explain in cran-comments and have my
package accepted as is?

I could also revert to using Boost although I only need it for these
special functions and things are much cleaner without it. In addition, one
of the main reasons for this update was related to some warnings Boost
started throwing.

Really appreciate the help!

* installing *source* package ‘GPvecchia’ ...
** package ‘GPvecchia’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
using C++ compiler: ‘Apple clang version 14.0.3 (clang-1403.0.22.14.1)’
using C++17
using SDK: ‘MacOSX11.3.sdk’
clang++ -arch x86_64 -std=gnu++17
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include'
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include'
-I/opt/R/x86_64/include -fPIC  -falign-functions=64 -Wall -g -O2
-c Esqe.cpp -o Esqe.o
clang++ -arch x86_64 -std=gnu++17
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include'
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include'
-I/opt/R/x86_64/include -fPIC  -falign-functions=64 -Wall -g -O2
-c Matern.cpp -o Matern.o
clang++ -arch x86_64 -std=gnu++17
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include'
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include'
-I/opt/R/x86_64/include -fPIC  -falign-functions=64 -Wall -g -O2
-c MaxMin.cpp -o MaxMin.o
clang++ -arch x86_64 -std=gnu++17
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include'
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include'
-I/opt/R/x86_64/include -fPIC  -falign-functions=64 -Wall -g -O2
-c RcppExports.cpp -o RcppExports.o
clang++ -arch x86_64 -std=gnu++17
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include'
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include'
-I/opt/R/x86_64/include -fPIC  -falign-functions=64 -Wall -g -O2
-c U_NZentries.cpp -o U_NZentries.o
clang++ -arch x86_64 -std=gnu++17
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include'
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include'
-I/opt/R/x86_64/include -fPIC  -falign-functions=64 -Wall -g -O2
-c dist.cpp -o dist.o
clang++ -arch x86_64 -std=gnu++17
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/Rcpp/include'
-I'/Volumes/Builds/packages/big-sur-x86_64/Rlib/4.3/RcppArmadillo/include'
-I/opt/R/x86_64/include -fPIC  -falign-functions=64 -Wall -g -O2
-c fastTree.cpp -o fastTree.o
Matern.cpp:80:68: error: no member named 'cyl_bessel_k' in namespace 'std'
 covmat(j1,j2) = normcon*pow( scaledist, covparms(2)
)*std::cyl_bessel_k(covparms(2),scaledist);
//Rf_bessel_k(scaledist,covparms(2),1.0);
   ~^
1 error generated.
make: *** [Matern.o] Error 1
make: *** Waiting for unfinished jobs
ERROR: compilation failed for package ‘GPvecchia’
* removing 
‘/Volumes/Builds/packages/big-sur-x86_64/results/4.3/GPvecchia.Rcheck/GPvecchia’

[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Native pipe in package examples

[Serguei Sokol]

Le 26/01/2024 à 10:44, Serguei Sokol a écrit :

Le 26/01/2024 à 10:31, Serguei Sokol a écrit :

Le 25/01/2024 à 19:04, Berwin A Turlach a écrit :

On Thu, 25 Jan 2024 09:44:26 -0800
Henrik Bengtsson  wrote:


On Thu, Jan 25, 2024 at 9:23 AM Berwin A Turlach
 wrote:


G'day Duncon,


Uups, apologies for the misspelling of your name Duncan. Fingers were
too fast. :)

[...]

But you could always code your example (not tested :-) ) along lines
similar to:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
   ## code that uses native pipe
}else{
   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}


That will unfortunately not work in this case, because |> is part of
the new *syntax* that was introduced in R 4.1.0.  Older versions of R
simply doesn't understand how to *parse* those two symbols next to
each other, e.g.

{R 4.1.0}> parse(text = "1:3 |> sum()")
expression(1:3 |> sum())

{R 4.0.5}> parse(text = "1:3 |> sum()")
Error in parse(text = "1:3 |> sum()") : :1:6: unexpected '>'
1: 1:3 |>
  ^

In order for R to execute some code, it needs to be able to parse it
first. Only then, it can execute it.  So, here, we're not even getting
past the parsing phase.


Well, not withstanding 'fortune(181)', you could code it as:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
    cat(eval(parse(text="1:3 |> sum()")), "\n")
}else{
   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}

By nitpicking a little bit, this test won't work for v5.0 as minor 
"0" is less then "1". There are a more canonical ways to test the 
version and send a message (or a 'warning()'):


if (getVersion() >= "4.1") {

Oops, it won't work for v10.0. Better would be:

if (utils::compareVersion(getVersion(), "4.1.0") >= 0) {
Sorry for annoyance (not a good day for sending messages), obviously it 
should be 'getRversion()'


Best,
Serguei.



Best,
Serguei.


cat(eval(parse(text="1:3 |> sum()")), "\n")
} else {
   message("You have to upgrade to R >= 4.1.0 to run this example")
}

Best,
Serguei.




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

Re: [R-pkg-devel] Native pipe in package examples

[Serguei Sokol]

Le 26/01/2024 à 10:31, Serguei Sokol a écrit :

Le 25/01/2024 à 19:04, Berwin A Turlach a écrit :

On Thu, 25 Jan 2024 09:44:26 -0800
Henrik Bengtsson  wrote:


On Thu, Jan 25, 2024 at 9:23 AM Berwin A Turlach
 wrote:


G'day Duncon,


Uups, apologies for the misspelling of your name Duncan. Fingers were
too fast. :)

[...]

But you could always code your example (not tested :-) ) along lines
similar to:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
   ## code that uses native pipe
}else{
   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}


That will unfortunately not work in this case, because |> is part of
the new *syntax* that was introduced in R 4.1.0.  Older versions of R
simply doesn't understand how to *parse* those two symbols next to
each other, e.g.

{R 4.1.0}> parse(text = "1:3 |> sum()")
expression(1:3 |> sum())

{R 4.0.5}> parse(text = "1:3 |> sum()")
Error in parse(text = "1:3 |> sum()") : :1:6: unexpected '>'
1: 1:3 |>
  ^

In order for R to execute some code, it needs to be able to parse it
first. Only then, it can execute it.  So, here, we're not even getting
past the parsing phase.


Well, not withstanding 'fortune(181)', you could code it as:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
    cat(eval(parse(text="1:3 |> sum()")), "\n")
}else{
   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}

By nitpicking a little bit, this test won't work for v5.0 as minor "0" 
is less then "1". There are a more canonical ways to test the version 
and send a message (or a 'warning()'):


if (getVersion() >= "4.1") {

Oops, it won't work for v10.0. Better would be:

if (utils::compareVersion(getVersion(), "4.1.0") >= 0) {

Best,
Serguei.


cat(eval(parse(text="1:3 |> sum()")), "\n")
} else {
   message("You have to upgrade to R >= 4.1.0 to run this example")
}

Best,
Serguei.


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

Re: [R-pkg-devel] Native pipe in package examples

[Serguei Sokol]

Le 25/01/2024 à 19:04, Berwin A Turlach a écrit :

On Thu, 25 Jan 2024 09:44:26 -0800
Henrik Bengtsson  wrote:


On Thu, Jan 25, 2024 at 9:23 AM Berwin A Turlach
 wrote:


G'day Duncon,


Uups, apologies for the misspelling of your name Duncan.  Fingers were
too fast. :)

[...]

But you could always code your example (not tested :-) ) along lines
similar to:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
   ## code that uses native pipe
}else{
   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}


That will unfortunately not work in this case, because |> is part of
the new *syntax* that was introduced in R 4.1.0.  Older versions of R
simply doesn't understand how to *parse* those two symbols next to
each other, e.g.

{R 4.1.0}> parse(text = "1:3 |> sum()")
expression(1:3 |> sum())

{R 4.0.5}> parse(text = "1:3 |> sum()")
Error in parse(text = "1:3 |> sum()") : :1:6: unexpected '>'
1: 1:3 |>
  ^

In order for R to execute some code, it needs to be able to parse it
first. Only then, it can execute it.  So, here, we're not even getting
past the parsing phase.


Well, not withstanding 'fortune(181)', you could code it as:

if( with(version, all(as.numeric(c(major, minor)) >= c(4, 1))) ){
cat(eval(parse(text="1:3 |> sum()")), "\n")
}else{
   cat("You have to upgrade to R >= 4.1.0 to run this example\n")
}

By nitpicking a little bit, this test won't work for v5.0 as minor "0" 
is less then "1". There are a more canonical ways to test the version 
and send a message (or a 'warning()'):


if (getVersion() >= "4.1") {
   cat(eval(parse(text="1:3 |> sum()")), "\n")
} else {
   message("You have to upgrade to R >= 4.1.0 to run this example")
}

Best,
Serguei.

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

Re: [R-pkg-devel] How to debug segfault when running build -> document in Rstudio that includes TMB module

[Serguei Sokol]

Le 24/01/2024 à 04:22, Carl Schwarz a écrit :

I'm trying to update my SPAS package to respond to a CRAN check. Before
starting the changes, I tried to rebuild my package, but now get a segfault
when I try to do a devtools::document() or devtools::check(args =
c('--as-cran')). See below for output from the Rstudio "Build" window.

I've
- reinstalled ALL packages
- reinstalled R (4.3.2 on MacOS Intel Chip)
- reinstalled Rstudio

When I try a rebuild/document on a sister package it runs fine, so I
suspect that the problem is related to using a TMB module that is part of
the SPAS package written in Cpp.

How do I start to "debug" this to identify the problem?

Why not simply run devtools::document() from 'R -d gdb' ?

Best,
Serguei.



Thanks
Carl Schwarz




==> devtools::document(roclets = c('rd', 'collate', 'namespace', 'vignette'))
ℹ Updating SPAS documentationℹ Loading SPAS

  *** caught segfault ***
address 0x54e40, cause 'memory not mapped'

Traceback:
  1: dyn.load(dll_copy_file)
  2: library.dynam2(path, lib)
  3: load_dll(path)
  4: pkgload::load_all(path, helpers = FALSE, attach_testthat = FALSE)
  5: load_code(base_path)
  6: roxygen2::roxygenise(pkg$path, roclets)
  7: devtools::document(roclets = c("rd", "collate", "namespace",
"vignette"))
  8: withCallingHandlers(expr, packageStartupMessage = function(c)
tryInvokeRestart("muffleMessage"))
  9: suppressPackageStartupMessages({oldLC <-
Sys.getlocale(category = "LC_COLLATE")Sys.setlocale(category =
"LC_COLLATE", locale = "C")on.exit(Sys.setlocale(category =
"LC_COLLATE", locale = oldLC))devtools::document(roclets = c("rd",
"collate", "namespace", "vignette"))})
An irrecoverable exception occurred. R is aborting now ...

Exited with status 139.

[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Check warning around sprintf: 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

[Serguei Sokol]

Le 19/11/2023 à 02:07, Iris Simmons a écrit :

Yes, the reason for the error is the use of sprintf. You can instead use
snprintf where n is the maximum number of bytes to write, including the
terminating nul character. For example:

char msg[8191];
snprintf(msg, 8191, "criteria: error (%d) -> %s\n", inErr, errStr);

This line should be

snprintf(msg, 8190, "criteria: error (%d) -> %s\n", inErr, errStr);

i.e. 1-less than 'msg' size, leaving a room for the terminal 0-byte.
Otherwise, a recent version of gcc emits a warning caught by CRAN.

Best,
Serguei.



Rf_error(msg);

or however large you made the error string.


On Sat, Nov 18, 2023, 20:01 Iago Giné-Vázquez 
wrote:


Dear all,

I am updating a CRAN-archived R package, so it can get back to CRAN. But
there is a warning produced in Linux OS that I am not sure to understand
and I do not know how to solve, even after looking at ‘Writing portable
packages’ in the ‘Writing R Extensions’ manual and after searching in the
web. The warning is


* checking compiled code ... WARNING
File ‘ccckc/libs/ccckc.so’:
Found ‘sprintf’, possibly from ‘sprintf’ (C)
Object: ‘criteria.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 nor [v]sprintf.
See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.


The package contains both C and Fortran code and in the criteria.c there
is only a sprintf use, as follows:

sprintf(msg,"criteria: error (%d) -> %s\n", inErr, errStr);
Rf_error(msg);
May be the reason of the warning the next line the ‘Writing R Extensions’
manual?


Use ofsprintfandvsprintfis regarded as a potential security risk and

warned about on some platforms.[82](
https://cran.r-project.org/doc/manuals/R-exts.html#FOOT82)R CMD
checkreports if any calls are found.

If that is the reason, is there any alternative to the use of sprintf?
Anyway, what can I do?

Thanks you in advance for your time.

Kind regards,
Iago

Sent with [Proton Mail](https://proton.me/) secure email.
 [[alternative HTML version deleted]]

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



[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Virtual C++ functions

[Serguei Sokol]

Le 15/11/2023 à 10:37, Michael Meyer via R-package-devel a écrit :

Greetings,
Suppose I wanted to develop a package with C++ code that contains virtual 
functions which the package user should define.It's assumed that evaluation is 
expensive so we do not want to define these in R and then call these 
R-functions from C++.
Hm, virtual C++ functions are defined at compilation time. Their binding 
is done at runtime but at compilation time they must be already defined. 
So, how a package user (who already installed and therefor compiled your 
package) could define them? Moreover in R?
Or may be you mean that a user import your C++ code and define his own 
derived function based on your virtual functions in his C++ code?
Or, another option, you call "virtual function" what is usually called 
"callback function" like e.g. a function searching for roots of any user 
defined function and taking it as a parameter. This latter is a callback 
function.


Could you precise what you mean by "virtual function" and "package user 
should define"?


Best,
Serguei.


Is this a reasonable idea with a standard solution?Are there packages that do 
this?
Thanks in advance for all answers,

Michael Meyer
[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Rmarkdown fails if (quote) r (space) is used

[Serguei Sokol]

Le 03/11/2023 à 15:54, J C Nash a écrit :

I've spent a couple of hours with an Rmarkdown document where I
was describing some spherical coordinates made up of a radius r and
some angles. I wanted to fix the radius at 1.

In my Rmarkdown text I wrote

    Thus we have `r = 1` ...
To avoid a confusion between inline code and fixed font typesetting, 
could it be


   Thus we have ` r = 1` ...

(with a space after an opening quote)?

Best,
Serguei.



This caused failure to render with "unexpected =". I was using Rstudio
at first and didn't see the error msg.

If I use "radius R" and `R = 1`, things are fine, or `r=1` with no space,
but the particular "(quote) r (space)" seems to trigger code block 
processing.


Perhaps this note can save others some wasted time.

I had thought (obviously incorrectly) that one needed ```{r something}
to start the code chunk.

JN

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


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

Re: [R-pkg-devel] Link to MKL instead of RBLAS on CRAN

[Serguei Sokol]

Le 27/09/2023 à 14:11, Sameh Abdulah a écrit :

Hi,

Is it possible to link with MKL instead of RBLAS when submitting my package to 
CRAN?
Usually, it's not the business of a package to choose a BLAS to link to. 
Many options exists for this on the user's side. For example, at 
installation of R you can see 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#BLAS or 
https://www.intel.com/content/www/us/en/developer/articles/technical/using-onemkl-with-r.html
Another option for "standard" R which can work, is simply to simlink 
Rblas.so to libopenblas.os or whatever BLAS you want. For MKL it can be 
a little trickier as it requires some additional libraries. It is up to 
you to make them findable at run time.


Best,
Serguei.


Do CRAN support other BLAS libraries?

Best,
--Sameh



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

Re: [R-pkg-devel] [EXTERNAL] Re: Warning: a function declaration without a prototype is deprecated in all versions of C

[Serguei Sokol]

Le 26/09/2023 à 10:50, Iñaki Ucar a écrit :

On Tue, 26 Sept 2023 at 10:29, Sameh Abdulah  wrote:


Thanks for replying!

The main problem that this warning from a C library that I am relying on, I 
have no control to fix the warning there. So, I am still getting this warning 
from R, when building my package.


We don't have a way of knowing for sure, because you didn't provide a
link to the package in question, so I'm just guessing here. From your
description, it seems that you vendor OpenBLAS in your package,
And if you do, it's probably not the best way to proceed. R relies 
already heavily on BLAS. So it is already available and may be it is 
sufficient in your case to add the following lines to Makevars to link 
to the local BLAS and leave the choice of the vendor to a final user 
(OpenBLAS, Atlas, MKL, ...):


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

You can see a demo package of using BLAS/LAPACK in R e.g. at 
https://github.com/cjgeyer/mat


Best,
Serguei.


and
that's why you get a warning. Then you *do* have control to fix that:
just patch your copy appropriately. This is what e.g. the BH package
(and others) do. And in this case it would be nice to send the fix
upstream too.

Iñaki



Best,
--Sameh

From: R-package-devel  on behalf of Jeff 
Newmiller via R-package-devel 
Date: Tuesday, September 26, 2023 at 11:19 AM
To: r-package-devel@r-project.org 
Subject: [EXTERNAL] Re: [R-pkg-devel] Warning: a function declaration without a 
prototype is deprecated in all versions of C
This error arises because you are not declaring the function properly before 
you call it... likely because you have not included the appropriate header file 
or because you have typoed the function call.

If you provide a link to your package someone may point you more precisely to 
your error, but this is a pretty basic C language question rather than an R 
package question so it isn't technically on topic here.

On September 26, 2023 12:58:25 AM PDT, Sameh Abdulah 
 wrote:

Dear Colleagues,


I've encountered a warning in my package that states:

'warning: a function declaration without a prototype is deprecated in all 
versions of C [-Wstrict-prototypes].'

This warning originates from one of the libraries I depend on, specifically 
OpenBLAS. So, I have no control to fix it inside OpenBLAS.

I'm not sure how to resolve this issue.


Best regards,
--Sameh"




--
Sent from my phone. Please excuse my brevity.

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!Nmw4Hv0!yyvWt-qHY4RQENDvneARJTJbYchLTruMwyEmREYaEtV52oUiLbgVqWM1wxJW-ijKGJeNgHq1HWtnHCQ1_CqTIRN9gfJfWX3c1A7nVQ$

--

This message and its contents, including attachments are intended solely
for the original recipient. If you are not the intended recipient or have
received this message in error, please notify me immediately and delete
this message from your computer system. Any unauthorized use or
distribution is prohibited. Please consider the environment before printing
this email.

 [[alternative HTML version deleted]]

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






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

Re: [R-pkg-devel] Check package without suggests

[Serguei Sokol]

Is it possible that you have complicated the task unnecessarily?
Normally, you can just do

if (requireNamespace("", quietly=TRUE)) {
 # do the tests involving 
}

Wasn't that enough?

Best,
Serguei.


Le 18/07/2023 à 16:37, John Harrold a écrit :

Howdy Folks,

I recent had a package start failing because I wasn't checking properly in
my tests to make sure my suggested packages were installed before running
tests. I think this is something new running on CRAN where packages are
tested with only the packages specified as Imports in the DESCRIPTION file
are installed. It took me a bit of back and forth to get all of these
issues worked out.  I was wondering if anyone has a good way to run R CMD
check with only the imports installed?  A github action, or a
specific platform on rhub?

Thank you,

John
:wq

[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Problems with devtools::build() in R

[Serguei Sokol]

Le 16/05/2023 à 18:07, Jarrett Phillips a écrit :

Hi All,

I'm trying to generate a `tar.gz` file on a Mac for R package submission to
CRAN but am having issues.

I'm using `devtools`, specifically `build()` and `install()`.

My package relies on compiled code via `Rcpp/RcppArmadillo`.

 build("HACSim_OO")
 ── R CMD build
─
 ✔  checking for file ‘/Users/jarrettphillips/Desktop/HAC
simulation/HACSim_OO/DESCRIPTION’ ...
 ─  preparing ‘HACSim’:
 ✔  checking DESCRIPTION meta-information ...
 ─  cleaning src
 ─  installing the package to process help pages
  ---
 ─  installing *source* package ‘HACSim’ ...
** using staged installation
** libs
clang++ -arch arm64 -std=gnu++11 -
I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
  
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2  -Wall
-pedantic -fdiagnostics-color=always -c RcppExports.cpp -o RcppExports.o
clang++ -arch arm64 -std=gnu++11
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
  
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
-I/opt/R/arm64/include-fPIC  -falign-functions=64 -Wall -g -O2  -Wall
-pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
clang++ -arch arm64 -std=gnu++11 -dynamiclib
-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
-multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib
-L/opt/R/arm64/lib -o HACSim.so RcppExports.o accumulate.o
-L/Library/Frameworks/R.framework/Resources/lib -lRlapack
-L/Library/Frameworks/R.framework/Resources/lib -lRblas
-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1
-L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath
-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
-Wl,CoreFoundation
ld: warning: directory not found for option
'-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
ld: warning: directory not found for option
'-L/opt/R/arm64/gfortran/lib'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [HACSim.so] Error 1
ERROR: compilation failed for package ‘HACSim’
 ─  removing
‘/private/var/folders/r4/xm5blbcd2tn06tjv00lm1c78gn/T/RtmpN4uaYR/Rinstdf4219594de/HACSim’
  ---
 ERROR: package installation failed
 Error in `(function (command = NULL, args = character(),
error_on_status = TRUE, …`:
 ! System command 'R' failed
  ---
  Exit status: 1
  stdout & stderr: 
  ---
 Type .Last.error to see the more details.

`clang` is installed (since I am able to run the code within my package)
and I've verified by typing `gcc` in the Mac Terminal. I've also installed
`Homebrew` and `gfortran`, verifying via typing in the Terminal.

Any idea on what's going on how to fix the issue(s)?

Try to add in /src/Makevars:

PKG_LIBS=$(FLIBS)

Best,
Serguei.

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

Re: [R-pkg-devel] Error in CHECK caused by dev.off()

[Serguei Sokol]

Le 22/07/2020 à 14:36, Helmut Schütz a écrit :

Dear all,

I have two variables, foo and bar. The first is TRUE if a png should be 
created and the second is TRUE if an already existing one should be 
overwritten.

At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as expected in all versions of my package built in R up to 
v3.6.3. However, when I CHECK the package in v4.0.2 I get:

 > grDevices::dev.off()
Error in grDevices::dev.off() :
   cannot shut down device 1 (the null device)
Execution halted

I tried:
if (foo | (foo & bar)) {
   dev <- dev.list()
   if (!is.null(dev)) {
     if (dev == 2) invisible(dev.off())
   }
}
without success (same error).

Even the more general
if (foo | (foo & bar)) {
   graphics.off()
}
did not work.

The plot is called only in an example of one man-page -- though embedded 
in \donttest{}.
Even if I set both foo and bar to FALSE (i.e., the respective part of 
the code should not be executed at all), I get the same error.
Hmm... I see 2 possibilities for still getting an error while the 
concerned part of code is not supposed to be run:


 - either you are running not updated version of your package;
 - or the error comes from some other place of the code.

Sorry but without a minimal reproducible example I cannot help more.
Best,
Serguei.

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

Re: [R-pkg-devel] seeking help regarding the valgrind error

[Serguei Sokol]

Hi Yang,

Le 14/01/2020 à 17:29, Yang Feng a écrit :

Hi All,

Happy new year! I just joined this mailing list and would like to post my
first question.

I received a message earlier this month regarding an error in my R package
RAMP https://cran.r-project.org/web/packages/RAMP/index.html
I need to update the package by the end of this month to prevent it from
removed from CRAN.

The detailed email message is as follows. Does anyone know how to fix this?
Yep. The default value for gamma parameter in RAMP is NULL. So when you 
do in cd.general.R:


para.in = c(epsilon, max.iter, lambda, gamma)

and later on in .Fortran() call

..., paraIn = as.double(para.in) ...

you obtain a vector of length 3 while it is expected to be of length 4 
in cd_general_lin.f:


double precision, dimension(4) :: paraIn

So that when you read the 4-th element on line 21:

gamma = paraIn(4)

you are caught by valgrid.

Fixing that is left as exercise ;)

Best,
Serguei.



Also, how to reproduce this kind of error on my local mac?

Many thanks!


Checking with valgrind shows:

Still

  > fit1 = RAMP(x, y)
==4663== Invalid read of size 8
==4663==at 0x48A0A51: cd_general_lin_
(/tmp/RAMP.Rcheck/00_pkg_src/RAMP/src/cd_general_lin.f:21)
==4663==by 0x49DDE6: do_dotCode (svn/R-devel/src/main/dotcode.c:1799)
==4663==by 0x4D181C: bcEval (svn/R-devel/src/main/eval.c:7054)
==4663==by 0x4E8197: Rf_eval (svn/R-devel/src/main/eval.c:688)
==4663==by 0x4E9D56: R_execClosure (svn/R-devel/src/main/eval.c:1853)
==4663==by 0x4EAB33: Rf_applyClosure (svn/R-devel/src/main/eval.c:1779)
==4663==by 0x4DB64D: bcEval (svn/R-devel/src/main/eval.c:7022)
==4663==by 0x4E8197: Rf_eval (svn/R-devel/src/main/eval.c:688)
==4663==by 0x4E9D56: R_execClosure (svn/R-devel/src/main/eval.c:1853)
==4663==by 0x4EAB33: Rf_applyClosure (svn/R-devel/src/main/eval.c:1779)
==4663==by 0x4E8363: Rf_eval (svn/R-devel/src/main/eval.c:811)
==4663==by 0x4ECD01: do_set (svn/R-devel/src/main/eval.c:2920)
==4663==  Address 0x1616c100 is 7,600 bytes inside a block of size 7,960
alloc'd
==4663==at 0x483880B: malloc
(/builddir/build/BUILD/valgrind-3.15.0/coregrind/m_replacemalloc/vg_replace_malloc.c:309)
==4663==by 0x5223E0: GetNewPage (svn/R-devel/src/main/memory.c:946)

Please fix and resubmit.

Best wishes,
Yang

[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] suggestion: conda for third-party software

[Serguei Sokol]

Le 08/01/2020 à 08:50, Ivan Krylov a écrit :

On Tue, 7 Jan 2020 15:49:45 +0100
Serguei Sokol  wrote:


Currently, many R packages include TPS as part of them thus bloating
their sizes and often duplicating files on a given system.  And even
when TPS is not included in an R package but is just installed on a
system, it is not so obvious to get the right path to it. Sometimes
pkg-config helps but it is not always present.


I agree that making a package depend on a third-party library means
finding oneself in a bit of a pickle. A really popular library like
cURL could be "just" depended upon (for the price of some problems when
building on Windows). A really small (e.g. 3 source files) and rarely
updated (just once last year) library like liborigin could "just" be
bundled (but the package maintainer would have to constantly watch out
for new versions of the library). Finding that the bundled version of a
network-facing library in an R package (e.g. libuv in httpuv) is several
minor versions out of date is always a bit scary, even if it turns out
that no major security flaws have been found in that version (just a few
low-probability resource leaks, one unlikely NULL pointer dereference
and some portability problems). The road to dependency hell is paved
with intentions of code reuse.


So, the new feature would be to let R package developers to write in
DESCRIPTION/SystemRequirements field something like
'conda:boost-cpp>=1.71' where 'boost-cpp' is an example of a conda
package and '>=1.71' is an optional version requirement.


While I appreciate the effort behind Anaconda, I would hate to see it
being *required* to depend on third-party binaries compiled by a
fourth-party (am I counting my parties right?) when there's already a
copy installed and available via means the user trusts more (e.g. via
GNU/Linux distro package, or Homebrew on macOS, or just a copy sitting
in /usr/local installed manually from source). In this regard, a
separate field like "Config/conda" suggested by Kevin Ushey sounds like
a good idea: if one wants to use Anaconda, the field is there. If one
doesn't, one can just ignore it and provide the necessary dependencies
in a different way.
The same would apply for my proposition: if you want, you use 
conda:something if not you do like before. But anyway, I don't make a 
campaign for 'conda:' tag in SystemRequirements. Kevin's Config/conda 
solution seems to be sufficient for this issue. Just, I was not aware 
that it was already there.


Best,
Serguei.

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

[R-pkg-devel] suggestion: conda for third-party software

[Serguei Sokol]

Best wishes for 2020!

I would like to suggest a new feature for R package management. Its aim 
is to enable package developers and end-users to rely on conda ( 
https://docs.conda.io/en/latest/ ) for managing third-party software 
(TPS) on major platforms: linux64, win64 and osx64. Currently, many R 
packages include TPS as part of them thus bloating their sizes and often 
duplicating files on a given system.  And even when TPS is not included 
in an R package but is just installed on a system, it is not so obvious 
to get the right path to it. Sometimes pkg-config helps but it is not 
always present.


So, the new feature would be to let R package developers to write in 
DESCRIPTION/SystemRequirements field something like 
'conda:boost-cpp>=1.71' where 'boost-cpp' is an example of a conda 
package and '>=1.71' is an optional version requirement. Having this 
could allow install.packages() to install TPS on a testing CRAN machine 
or on an end-user's one. (There is just one line to execute in a shell: 
conda install . It will install the package itself as well as 
all its dependencies).


To my mind, this feature would have the following advantages:
 - on-disk size economy as the same TPS does not have to be included in 
R package itself and can be shared with other language wrappers, e.g. 
Python;
 - an easy flag configuring in Makevars as paths to TPS will be well 
known in advance;
 - CRAN machines could test packages relying on a wide panel of TPS 
without bothering with their manual installation;
 - TPS installation can become transparent for the end-user on major 
platforms;


Note that even R is part of conda ( 
https://anaconda.org/conda-forge/r-base ), it is not mandatory to use 
the conda's R version for this feature. Here, conda is just meant to 
facilitate access to TPS. However, a minimal requirement is obviously to 
have conda itself.


Does it look reasonable? appealing?
Best,
Serguei.

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

Re: [R-pkg-devel] r2sundials submission failure

[Serguei Sokol]

Hi Satya,

Le 16/12/2019 à 14:52, Satyaprakash Nayak a écrit :

Hi Serguei

I apply a similar approach to include the Sundials source code as a part 
of my package (sundialr, on CRAN) which provides an interface for Cvode 
and Cvodes. I didn’t have an issue with the files sizes while submitting 
to CRAN

Good to hear :)


and you can take a look to see if the code would be helpful to you.

https://github.com/sn248/sundialr
I see that you include v4.0.1 of sundials while I included a more recent 
release 5.0.0:

https://github.com/sgsokol/r2sundials

But I think, in the end, the library size must be close to each other.



Although, it would be great if sundials is installed on CRAN machines 
and static libraries for Windows are provided in rtools 4.0
It could be a good thing in general but the end user on other platforms 
will have to install it anyway. Moreover, I see you kept the default 
size for index type:


SUNDIALS_INDEX_TYPE int64_t

while I defined it to int32_t.
It shows that it's hard to satisfy all the tastes in the wild with only 
one library distrubution ;)


Best,
Serguei.



Satya


On Mon, 16 Dec 2019 at 03:54, Serguei Sokol <mailto:serguei.so...@gmail.com>> wrote:


Le 15/12/2019 à 17:59, Uwe Ligges a écrit :
 > Have you tried to write to CRAN@... and ask if thirs party
software can
 > be installed on CRAN?
No, I didn't. I presumed that CRAN team had other things to do than to
install any soft that package authors could need. But if this is an
option, I will try this approach next time. For this one, I
integrated a
subset of sundials soft in the package and it turned out to be far less
then 20 MB (which is the size I had on my system for the whole set of
cvodes library and its dependencies). The tarball is only 270 KB and
compiled libraries on some systems can be up to 7 MB and far less on
others (e.g. on my linux, compiled without "-g" flag, the whole size of
$RHOME/library/r2sundial is under 2 MB). Just now, it is pending a
manual inspection. I hope that library size will not be a problem.

Anyway, I appreciate the hint. Thanks.
Best,
Serguei.

 >
 > Best,
 > Uwe Ligges
 >
 > On 11.12.2019 10:39, Serguei Sokol wrote:
 >> Hi,
 >>
 >> I have tried to submit my new package
 >> https://github.com/sgsokol/r2sundials to CRAN but submission
seems to
 >> be dismissed.
 >> The package needs a third part software
 >> https://computing.llnl.gov/projects/sundials/cvodes so it cannot be
 >> built on CRAN automatically. I explained this (and how the
package was
 >> tested by myself) in the submitter's comment (cf. hereafter) and
 >> second time in the reply to all (as was requested) to automatic
 >> message from CRAN announcing the building failure but to no
avail. The
 >> submission was done on November 25, more than two weeks later I
still
 >> don't have any response and the package is no more in incoming/
dir on
 >> cran ftp site. I conclude that this submission is dismissed.
 >>
 >> My question is: what can be reasonably done to make a package like
 >> this (i.e. depending on third part software not available on
CRAN) to
 >> be accepted? Or may be the current policy: all new package must
 >> automatically build. Period. In my case it can imply ~20 MB
additional
 >> space (source code + libs).
 >>
 >> Thanks in advance for any hint.
 >> Serguei.
 >>
 >> Submitter's comment: Dear CRAN team,
 >>
 >> I submit package r2sundials which
 >>    depends on a third part software
 >>    from
 >> https://computing.llnl.gov/projects/sundials/cvodes
 >> This
 >>    is the reason for which it will not automatically
 >>    build on your test systems. But on my side, I could
 >>    successfully run 'R CMD check --as-cran' on Linux
 >>    (R-3.6.1, gcc8), MacOS Catalina (R-3.6.1, Apple
 >>    clang-1100.0.33.12) and Windows 10 (R-devel r77430,
 >>    gcc-4.9.3). If you wish, I can send you reports from
 >>    these runs. Even if it is improbable, but if you
 >>    decide to run such checks manually by your self,
 >>    installation instructions are available
 >>    on
 >> https://github.com/sgsokol/r2sundials
 >>
 >> Moreover,
 >>    winbuilder signals:
 >> Possibly mis-spelled words in
 >>    DESCRIPTION:
 >>    CVODES (3:34)
 >>    Hindmarsh (9:803)
 >>    Rcpp (3:8, 9:285)
 >>    al (9:816)
 >>    cvodes (9

Re: [R-pkg-devel] r2sundials submission failure

[Serguei Sokol]

Le 15/12/2019 à 17:59, Uwe Ligges a écrit :
Have you tried to write to CRAN@... and ask if thirs party software can 
be installed on CRAN?
No, I didn't. I presumed that CRAN team had other things to do than to 
install any soft that package authors could need. But if this is an 
option, I will try this approach next time. For this one, I integrated a 
subset of sundials soft in the package and it turned out to be far less 
then 20 MB (which is the size I had on my system for the whole set of 
cvodes library and its dependencies). The tarball is only 270 KB and 
compiled libraries on some systems can be up to 7 MB and far less on 
others (e.g. on my linux, compiled without "-g" flag, the whole size of 
$RHOME/library/r2sundial is under 2 MB). Just now, it is pending a 
manual inspection. I hope that library size will not be a problem.


Anyway, I appreciate the hint. Thanks.
Best,
Serguei.



Best,
Uwe Ligges

On 11.12.2019 10:39, Serguei Sokol wrote:

Hi,

I have tried to submit my new package 
https://github.com/sgsokol/r2sundials to CRAN but submission seems to 
be dismissed.
The package needs a third part software 
https://computing.llnl.gov/projects/sundials/cvodes so it cannot be 
built on CRAN automatically. I explained this (and how the package was 
tested by myself) in the submitter's comment (cf. hereafter) and 
second time in the reply to all (as was requested) to automatic 
message from CRAN announcing the building failure but to no avail. The 
submission was done on November 25, more than two weeks later I still 
don't have any response and the package is no more in incoming/ dir on 
cran ftp site. I conclude that this submission is dismissed.


My question is: what can be reasonably done to make a package like 
this (i.e. depending on third part software not available on CRAN) to 
be accepted? Or may be the current policy: all new package must 
automatically build. Period. In my case it can imply ~20 MB additional 
space (source code + libs).


Thanks in advance for any hint.
Serguei.

Submitter's comment: Dear CRAN team,

I submit package r2sundials which
   depends on a third part software
   from
https://computing.llnl.gov/projects/sundials/cvodes
This
   is the reason for which it will not automatically
   build on your test systems. But on my side, I could
   successfully run 'R CMD check --as-cran' on Linux
   (R-3.6.1, gcc8), MacOS Catalina (R-3.6.1, Apple
   clang-1100.0.33.12) and Windows 10 (R-devel r77430,
   gcc-4.9.3). If you wish, I can send you reports from
   these runs. Even if it is improbable, but if you
   decide to run such checks manually by your self,
   installation instructions are available
   on
https://github.com/sgsokol/r2sundials

Moreover,
   winbuilder signals:
Possibly mis-spelled words in
   DESCRIPTION:
   CVODES (3:34)
   Hindmarsh (9:803)
   Rcpp (3:8, 9:285)
   al (9:816)
   cvodes (9:47)
   et (9:813)
   rmumps (9:501)
These all are false
   positives designating software, R packages and
   bibliographic reference.

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


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

[R-pkg-devel] r2sundials submission failure

[Serguei Sokol]

Hi,

I have tried to submit my new package 
https://github.com/sgsokol/r2sundials to CRAN but submission seems to be 
dismissed.
The package needs a third part software 
https://computing.llnl.gov/projects/sundials/cvodes so it cannot be 
built on CRAN automatically. I explained this (and how the package was 
tested by myself) in the submitter's comment (cf. hereafter) and second 
time in the reply to all (as was requested) to automatic message from 
CRAN announcing the building failure but to no avail. The submission was 
done on November 25, more than two weeks later I still don't have any 
response and the package is no more in incoming/ dir on cran ftp site. I 
conclude that this submission is dismissed.


My question is: what can be reasonably done to make a package like this 
(i.e. depending on third part software not available on CRAN) to be 
accepted? Or may be the current policy: all new package must 
automatically build. Period. In my case it can imply ~20 MB additional 
space (source code + libs).


Thanks in advance for any hint.
Serguei.

Submitter's comment: Dear CRAN team,

I submit package r2sundials which
  depends on a third part software
  from
https://computing.llnl.gov/projects/sundials/cvodes
This
  is the reason for which it will not automatically
  build on your test systems. But on my side, I could
  successfully run 'R CMD check --as-cran' on Linux
  (R-3.6.1, gcc8), MacOS Catalina (R-3.6.1, Apple
  clang-1100.0.33.12) and Windows 10 (R-devel r77430,
  gcc-4.9.3). If you wish, I can send you reports from
  these runs. Even if it is improbable, but if you
  decide to run such checks manually by your self,
  installation instructions are available
  on
https://github.com/sgsokol/r2sundials

Moreover,
  winbuilder signals:
Possibly mis-spelled words in
  DESCRIPTION:
  CVODES (3:34)
  Hindmarsh (9:803)
  
  Rcpp (3:8, 9:285)

  al (9:816)
  cvodes (9:47)
  
  et (9:813)

  rmumps (9:501)
These all are false
  positives designating software, R packages and
  bibliographic reference.

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

Re: [R-pkg-devel] No answer from win-builder R-devel. Is it down?

[Serguei Sokol]

Le 26/11/2019 à 11:31, NURIA PEREZ ZANON a écrit :

Dear,

Before submitting my package to CRAN, yesterday I sent it (25th
November) to win-builder R-devel version.

Almost 19 hours later, I haven't received any email from win-builder
with the link to the binaries and the log files. (The email address
specified in the 'Maintainer' field is correct).

Checking the index R-devel in the ftp server, it seems that packages
stoped being tested around 11/25/19, 1:44:00 PM (the oldest package in
the index).

By trying to resubmit the package, I get the error
ERROR: Access to the path
'C:\Inetpub\ftproot\R-devel\CSTools_2.0.0.tar.gz' is denied.

because the package is already in the queue.

Does anyone know how to proceed? Should I contact somebody or this is a
frequent and well-known issue?
We are used to get a response from winbuilder in around 30 minutes but 
these days it seems to be congested. Recently I had to wait 3 days 
before my tarball was proceeded.


So my advice: be patient.
Serguei.

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

Re: [R-pkg-devel] Compiler warning using C versions of base R integrate function

[Serguei Sokol]

Le 21/11/2019 à 19:25, Devin Incerti a écrit :

Hi,

I'm attempting to submit a very minor update to my package where I replaced
a deprecated C++ function with an alternative. However, I'm receiving an
unrelated warning "*array subscript -1 is outside array bounds of ‘double
[52]’ [-Warray-bounds] *" on Debian during the CRAN pre-tests. I do not
receive this warning on my local OS X, Ubuntu 16.04 (on Travis-CI), with
Win-builder, or with R-hub builder. I also did not receive this warning on
previous submissions to CRAN, but it does now show up on the most recent CRAN
checks

.

The warning is related to the header file integrate.h
,
which is just integrate.c

from
R source with function pointers replaced by C++ functors. These integration
functions are needed so that the package can integrate at the C++ level.

I don't know how to avoid this warning.
Kind of brute force solution would be to delete the line --epstab (which 
is rising the warning) and replace any reference to epstab by the same 
with an index decremented by 1, e.g. instead of epstab[*n] write 
epstab[*n - 1].


Best,
Serguei.


Is it perhaps related to the
particular version of GCC used during the CRAN checks. Any thoughts or
suggestions would be much appreciated.

Thank you!

Devin

[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] please help understand an error in openMP statements

[Serguei Sokol]

On 12/09/2019 23:12, Marcin Jurek wrote:

Hello everyone, I'm submitting a package to CRAN which I tested locally, on
Travis CI, R-hub and win builder. It worked no problem in all these
environments. However, after submission, I keep getting the error described
here:


https://win-builder.r-project.org/incoming_pretest/GPvecchia_0.1.0_20190912_201702/Debian/00install.out

One obvious error is pretty well described by the compiler:

U_NZentries.cpp:258:19: error: ‘covparms’ not specified in enclosing 
‘parallel’
  258 |  covmat= MaternFun(dist,covparms) + diagmat(nug) ; // summation 
from arma

  |  ~^~~
U_NZentries.cpp:230:11: error: enclosing ‘parallel’
  230 |   #pragma omp parallel for 
shared(locs,revNNarray,revCondOnLatent,nuggets, nnp,m,Lentries,COV) 
private(k,M,dist,onevec,covmat,nug,n0,inds,revCon_row,inds00,succ,attempt) 
default(none) schedule(static)


It simply stets that you should add 'covparms' either to private() or to 
shared() list on line 230.


I have no idea for other messages complaining about 'none'.

Best Serguei.





I'm not a pro when it comes to openMP but since all previous tests
completed successfully, I thought things were alright. Could you help me
understand what's wrong and how to fix it? Source code of the package can
be found at http://github.com/katzfuss-group/GPvecchia Thanks a lot!


Marcin

[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Serguei Sokol]

On 05/09/2019 12:26, Martin Maechler wrote:

Sameh M Abdulah
 on Fri, 30 Aug 2019 18:50:55 + writes:


 > Hi,
 > I recently asked some questions about my R package which were well 
responded by Dirk.

 > I have another question related to pkg_config path,

 > I am using this command to add the installation path to the 
PKG_CONFIG_PATH   so that all cmake commands can get the required libraries from 
this path,

 > 
Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':'))

 > Is there a simple way to set this path without explicitly calling this 
line before installing my package? OR is there any other path that I can use so 
that all software CMake commands can easily find the required libraries?

 > --Sameh

Not an answer, but a  #METOO   with a hopefull very related
question, also on using 'pkg-config' (Note: "-", not "_" here)
for package configuration.

I'm maintainer of CRAN package Rmpfr (for arbitrary precise arithmetic..),
 https://cran.r-project.org/package=Rmpfr
development & source on R-forge
  http://rmpfr.r-forge.r-project.org/
and  https://r-forge.r-project.org/scm/viewvc.php/pkg/?root=rmpfr
which "down there"  is principally an interface to the GNU MPFR
C library (which also needs the GNU  GMP C library).

I do have a  Rmpfr/configure.ac from which to produce
Rmpfr/configure which then ensures that both libraries (MPFR and GMP)
are found and are "working".
The 'configure' script then (supposedly, but not on Windows?) takes
either src/Makevars.in  (non-Windows)
or src/Makevars.win (Windows)
to produce  src/Makevars
which then is used during compilation of the C sources of my
package.

I have a small marginal remark about this.
Makevars.win is not windows equivalent of Makevars.in but of plain 
Makevars (see
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories 
)
On windows, you can use configure.win which in turn can use 
Makevars.win.in to produce Makevars.win. The latter will be used by make 
on that platform (see 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup 
)


Best,
Serguei.



Notably it will contain   '-lmpfr -lgmp'  among the LDFLAGS in
any case.

Now back to the 'pkg-config' : The compiler *also* needs correct

-I  (the path used  by ' #include <...> ' statement)

and for linking a correct  -L.

Now, my main OS,  Linux Fedora (as all other decent Linux distributions)
does provide MPFR and GMP libraries (and include headers) as OS
packages, installed in  /usr/lib/ (actually /lib64 nowadays)
and /usr/include respectively.

However, for some reasons I don't know the *version* of the MPFR
library that the OS provides is outdate (to my taste), and I'd
really want a newer version of MPFR,  which I easily install in
a version of /usr/local/. *and* I also make sure that

 pkg-config --libs mpfr
and pkg-config --cflags mpfr

list the corresponding LDFLAGS  and CFLAGS

(the first giving

   -L/usr/local.../mpfr/4.0.1/lib -lmpfr -lgmp

  the 2nd

   -I/usr/local.../mpfr/4.0.1/include
)

Now what is the officially / best way to have either 'configure'
or  Makevars.{in,win}  use the 'pkg-config' information
*dynamically*, i.e.,
if I update my MPFR from 4.0.1 to 4.0.2  the newer 4.0.2 is found ?

My current setup would not even work on some platforms to really
end up using my local version of MPFR instead of the system-wide
OS default (using /lib64 and /usr/include/ and then
which even with quite new Fedora 30 is still MPFR 3.1.6 .. much
too old for some of the things I want).

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



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

Re: [R-pkg-devel] third part software dependency

[Serguei Sokol]

On 30/08/2019 15:58, Dirk Eddelbuettel wrote:


On 30 August 2019 at 07:24, Dirk Eddelbuettel wrote:
|
| On 30 August 2019 at 11:10, Serguei Sokol wrote:
| | I am preparing a new package r2sundials for submission to cran. It
| | depends on third part software
| | (https://computing.llnl.gov/projects/sundials). This will be my first
| | submission of the kind so I am wondering how it is supposed to be tested
| | so that I can reliably check the box "tested on R-devel" during
| | submission process?
| | I suppose that sundials is not installed on windev. And even if it was,
| | I need a particular option in this software (index size set to 32 bits)
| | which is probably not activated in the hypothetical installation. So I
| | cannot use win-builder.r-project.org.
| | Am I supposed to install current r-devel version and test my package on
| | it locally?
|
| The builder.r-hub.io service is a good alternative. It offers twelve
| different platforms, including a few r-devel ones.
|
| That said, it won't have sundials either so you may have to pull sundials in
| during configure or via Make dependencies or ...

An alternative is of course to use a Docker image. I have long provided two
different containers within the Rocker Project that have r-devel (to be
invoked as RD).  You can pretty easily fire up the container, install
sundials and then save it again locally.  Ask me off-line about how if you
need help.

Or, of course, do as I and many others do and just keep a local r-devel build
in /usr/local 

Thank Dirk. This was my spare option and I think this is what I'll do.

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

Re: [R-pkg-devel] third part software dependency

[Serguei Sokol]

Hi Ralf,

On 30/08/2019 16:04, Ralf Stubner wrote:

On Fri, Aug 30, 2019 at 11:10 AM Serguei Sokol  wrote:

I am preparing a new package r2sundials for submission to cran. It
depends on third part software
(https://computing.llnl.gov/projects/sundials).


Are you aware of the sundialr package?
https://cran.r-project.org/package=sundialr
Yes, I do. I explain why I created a new package in Readme.md visible 
here https://github.com/sgsokol/r2sundials





This will be my first
submission of the kind so I am wondering how it is supposed to be tested
so that I can reliably check the box "tested on R-devel" during
submission process?
I suppose that sundials is not installed on windev. And even if it was,
I need a particular option in this software (index size set to 32 bits)
which is probably not activated in the hypothetical installation. So I
cannot use win-builder.r-project.org.
Am I supposed to install current r-devel version and test my package on
it locally?


Besides Dirk's suggestions, you can also use a CI service like Travis.
there you can install additional dependencies before testing the
package itself.
Thanks for suggestion but I don't use Travis. Until now I didn't need 
it. Locally, I installed sundials/cvodes and my package. That's enough 
for the tests.




However, the question remains how CRAN will test the package without
having sundials installed.

Right.

Best,
Serguei.

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

[R-pkg-devel] third part software dependency

[Serguei Sokol]

Hi,

I am preparing a new package r2sundials for submission to cran. It 
depends on third part software 
(https://computing.llnl.gov/projects/sundials). This will be my first 
submission of the kind so I am wondering how it is supposed to be tested 
so that I can reliably check the box "tested on R-devel" during 
submission process?
I suppose that sundials is not installed on windev. And even if it was, 
I need a particular option in this software (index size set to 32 bits) 
which is probably not activated in the hypothetical installation. So I 
cannot use win-builder.r-project.org.
Am I supposed to install current r-devel version and test my package on 
it locally?


And another question.
Recently, I had to fix many LTO (link time optimization) related issues 
in a third part software included in one of my old packages. Have I to 
test with LTO activated the new package too given that it is _not_ 
included in the package ?


Thanks to share your experience and wisdom.

Best,
Serguei.

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

Re: [R-pkg-devel] .Rd, LaTeX and Unicode

[Serguei Sokol]

On 18/06/2019 17:10, Georgi Boshnakov wrote:


Since April 2018 'utf8' is the default input encoding in LaTeX, see
http://anorien.csc.warwick.ac.uk/mirrors/CTAN/macros/latex/doc/ltnews.pdf and 
they added some symbols in December.
Interesting ... but still not sufficient. I have a fairly recent latex 
system:

$ latex --version
pdfTeX 3.14159265-2.6-1.40.19 (TeX Live 2018/Mageia)

but unfortunately utf8 alone (and even including
\usepackage[mathletters]{ucs}) cannot compile utf8 math expressions.

I have also tried a full scale test on a tex file obtained with
$ R CMD Rd2pdf --no-clean pkgname
where I replaced

\usepackage[utf8]{inputenc}

by

\usepackage[mathletters]{ucs}
\usepackage[utf8x]{inputenc}

and it did not compile either. In addition, I had to replace every 
occurrence of


\inputencoding{utf8}

by

\inputencoding{utf8x}

after what pdflatex worked like a charm.

Serguei.



-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Martin Maechler
Sent: 18 June 2019 15:01
To: serguei.so...@gmail.com; Hugh Parsonage
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] .Rd, LaTeX and Unicode


Hugh Parsonage
 on Tue, 18 Jun 2019 20:03:41 +1000 writes:


 > utf8x is deprecated
 > 
https://tex.stackexchange.com/questions/13067/utf8x-vs-utf8-inputenc#13070

Hmm... interestingly, I've tried quite a few versions of the
above which started in 2011, but had been updated in April 2016 :
https://tex.stackexchange.com/a/203804/7228
from where it seems that

\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

should be sufficient.  Further, note that from
   https://tex.stackexchange.com/a/238135/7228
the {ucs} package should no longer be needed since ca. 2013,
hence your \usepackage[mathletters]{ucs}  would not be needed either.

HOWEVER:  After losing at least half an hour now, trying many
variants I found that the only version that works correctly for
me (with a teTeX / TeXlive version of 2018) is the version
Serguei Sokol proposes (below), including the use of the 'utf8x'
option *and* the 'ucs' package ...

which is pretty surprising after having read the
tex.statexchange threads ...

 > On Tue, 18 Jun 2019 at 7:52 pm, Serguei Sokol 
 > wrote:

 >> Hi,
 >>
 >> I am preparing a package where I would like to use UTF characters in .Rd
 >> files. When the LaTeX comes to play, I got well known errors e.g.:
 >> ! Package inputenc Error: Unicode character ∂ (U+2202)
 >> (inputenc)not set up for use with LaTeX.
 >>
 >> It is coherent with what is said on this page
 >> https://developer.r-project.org/Encodings_and_R.html :
 >> "Since LaTeX cannot handle Unicode we would have to convert the encoding
 >> of latex help files or use Lambda (and tell it they were in UTF-8)."

That whole document has been very important and crucial, written
by Prof Brian Ripley  who had worked a *LOT* to bring unicode to R,
-- but it has been written 2004-2005  and indeed, I think it is
probably fair to say that the above sentence no longer applies
to current LaTeX engines (including "simple" pdflatex)... though really,
I'm not the expert here, but I think it's a good point in time
to reconsider how much UTF8 should be allowed/supported in *.Rd files.

One problem: This is (slightly) the wrong mailing list; this would have
been a perfect topic for 'R-devel' (discussing about new
features etc for R) instead
( but we'd rather keep it here for now.)

Martin Maechler
ETH Zurich and R Core Team



 >> But LaTeX can support UTF8 as shown with this small example:

  \documentclass{article}
  \usepackage[mathletters]{ucs}
  \usepackage[utf8x]{inputenc}
  
  \begin{document}

  The vorticity ω is defined as $ω = ∇ × u$.
  \end{document}

 >> I can compile it with my LaTeX without problem. May be you too?
 >> So my suggestion would be to place these two lines somewhere in LaTeX
 >> header generated by R doc system:
 >> \usepackage[mathletters]{ucs}
 >> \usepackage[utf8x]{inputenc}
 >>
 >> Note "utf8x" and not just "utf8" which is crucial for this example.
 >> With a hope that it would fix unicode errors from LaTeX.
 >>
 >> Best,
 >> Serguei.

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



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

[R-pkg-devel] .Rd, LaTeX and Unicode

[Serguei Sokol]

Hi,

I am preparing a package where I would like to use UTF characters in .Rd 
files. When the LaTeX comes to play, I got well known errors e.g.:

! Package inputenc Error: Unicode character ∂ (U+2202)
(inputenc)    not set up for use with LaTeX.

It is coherent with what is said on this page 
https://developer.r-project.org/Encodings_and_R.html :
"Since LaTeX cannot handle Unicode we would have to convert the encoding 
of latex help files or use Lambda (and tell it they were in UTF-8)."


But LaTeX can support UTF8 as shown with this small example:

\documentclass{article}
\usepackage[mathletters]{ucs}
\usepackage[utf8x]{inputenc}

\begin{document}
    The vorticity ω is defined as $ω = ∇ × u$.
\end{document}

I can compile it with my LaTeX without problem. May be you too?
So my suggestion would be to place these two lines somewhere in LaTeX 
header generated by R doc system:

\usepackage[mathletters]{ucs}
\usepackage[utf8x]{inputenc}

Note "utf8x" and not just "utf8" which is crucial for this example.
With a hope that it would fix unicode errors from LaTeX.

Best,
Serguei.

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

Re: [R-pkg-devel] try() in R CMD check --as-cran

[Serguei Sokol]

On 07/06/2019 16:47, Duncan Murdoch wrote:

On 07/06/2019 9:46 a.m., J C Nash wrote:

Should try() not stop those checks from forcing an error?


try(stop("msg"))  will print the error message, but won't stop 
execution.  Presumably the printed message is what is causing you 
problems.  If you want to suppress that, use


try(stop("msg"), silent = TRUE)
By curiosity, I tried but to no avail. Moreover, I have tried to trigger 
a similar error in different place by adding to the John's example in 
man/fchk.Rd the following code:


#... the same before
} # very simple, but ...

print(Sys.getenv("_R_CHECK_LENGTH_1_LOGIC2_", unset="unset"))
a=1:3 || 1:3
cat("a=", a, "\n")
y<-1:10
#... the same after.

add failed again. This part of code works without any error signaling 
while fchk()'s situation continue to flag up an error. From 
fchk-Ex.Rout, we can see:

...
+ } # very simple, but ...
>
> print(Sys.getenv("_R_CHECK_LENGTH_1_LOGIC2_", unset="unset"))
[1] "package:_R_CHECK_PACKAGE_NAME_,abort,verbose"
> a=1:3 || 1:3
> cat("a=", a, "\n")
a= TRUE
> y<-1:10
...
Function evaluation returns a vector not a scalar
 --- FAILURE REPORT --
 --- failure: length > 1 in coercion to logical ---
...

While in regular R session:
> Sys.unsetenv("_R_CHECK_LENGTH_1_LOGIC2_")
> (a=1:3 || 1:3)
[1] TRUE
> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_"="")
> (a=1:3 || 1:3)
Error in 1:3 || 1:3 : 'length(x) = 3 > 1' in coercion to 'logical(1)'

So, to my mind, 'a=1:3 || 1:3' should be considered as an error in a 
check with "--as-cran" but for some reason is not.


Both fchk with modified example and corresponding fchk-Ex.Rout are enclosed.

Best,
Serguei.



Duncan Murdoch



I recognize that this is the failure -- it is indeed the check I'm 
trying to

catch -- but I don't want tests of such checks to fail my package.

JN

On 2019-06-07 9:31 a.m., Sebastian Meyer wrote:

The failure stated in the R CMD check failure report is:


  --- failure: length > 1 in coercion to logical ---


This comes from --as-cran performing useful extra checks via setting the
environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:

check if either argument of the binary operators && and || has 
length greater than one.


(see https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools)

The failure report also states the source of the failure:


  --- call from context ---
fchk(x, benbad, trace = 3, y)
  --- call from argument ---
is.infinite(fval) || is.na(fval)


The problem is that both is.infinite(fval) and is.na(fval) return
vectors of length 10 in your test case:


  --- value of length: 10 type: logical ---
  [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE


The || operator works on length 1 Booleans. Since fval can be of length
greater than 1 at that point, the proper condition seems to be:

any(is.infinite(fval)) || any(is.na(fval))

Best regards,

Sebastian


Am 07.06.19 um 14:53 schrieb J C Nash:
Sorry reply not quicker. For some reason I'm not getting anything in 
the thread I started!
I found the responses in the archives. Perhaps cc: nas...@uottawa.ca 
please.


I have prepared a tiny (2.8K) package at
http://web.ncf.ca/nashjc/jfiles/fchk_2019-6.5.tar.gz

R CMD check --> OK

R CMD check --as-cran --> 1 ERROR, 1 NOTE

The error is in an example:


benbad<-function(x, y){
    # y may be provided with different structures
    f<-(x-y)^2
} # very simple, but ...

y<-1:10
x<-c(1)
cat("test benbad() with y=1:10, x=c(1)\n")
tryfc01 <- try(fc01<-fchk(x, benbad, trace=3, y))
print(tryfc01)
print(fc01)


There's quite a lot of output, but it doesn't make much sense to me, as
it refers to code that I didn't write.

The function fchk is attempting to check if functions provided for
optimization do not violate some conditions e.g., character rather than
numeric etc.

JN


On 2019-06-07 8:44 a.m., J C Nash wrote:

Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
Fri Jun 7 11:44:37 CEST 2019

 Previous message (by thread): [R-pkg-devel] try() in R CMD 
check --as-cran
 Next message (by thread): [R-pkg-devel] using package data in 
package code

 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Right, what problem are you talking about? Can you tell us which check
it is and what it actually complained about.
There is no check that looks at the sizes of x and y in exypressions
such as
(x - y)^2.
as far as I know.

Best,
Uwe

On 07.06.2019 10:33, Berry Boessenkool wrote:


Not entirely sure if this is what you're looking for:
https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R 


It does contain --as-cran a few times and there's the change-history:
https://github.com/wch/r-source/commits/trunk/src/library/tools/R/check.R 



Regards,
Berry



From: R-package-devel r-project.org> on behalf of J C Nash 

Sent: Thursday, June 6, 2019 15:03
To: List r-package-devel
Subject: [R-pkg-devel] try() in R CMD check --as-cran

After making a 

Re: [R-pkg-devel] try() in R CMD check --as-cran

[Serguei Sokol]

On 07/06/2019 16:05, Jeff Newmiller wrote:

any(is.infinite(fval)) || any(is.na(fval))


a little typo here: it should be '|', not '||', right ?


Since `any` collapses the vectors to length 1 either will work, but I would 
prefer `||`.
You are right, I missed the second 'any()' at the first glance. I read 
it as 'any(v1 || v2)'. My bad.




On June 7, 2019 6:51:29 AM PDT, Serguei Sokol  wrote:

On 07/06/2019 15:31, Sebastian Meyer wrote:

The failure stated in the R CMD check failure report is:


   --- failure: length > 1 in coercion to logical ---


This comes from --as-cran performing useful extra checks via setting

the

environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:


check if either argument of the binary operators && and || has

length greater than one.


(see

https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools)


The failure report also states the source of the failure:


   --- call from context ---
fchk(x, benbad, trace = 3, y)
   --- call from argument ---
is.infinite(fval) || is.na(fval)


The problem is that both is.infinite(fval) and is.na(fval) return
vectors of length 10 in your test case:


   --- value of length: 10 type: logical ---
   [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE


The || operator works on length 1 Booleans. Since fval can be of

length

greater than 1 at that point, the proper condition seems to be:

any(is.infinite(fval)) || any(is.na(fval))

a little typo here: it should be '|', not '||', right ?

Best,
Serguei.


Am 07.06.19 um 14:53 schrieb J C Nash:

Sorry reply not quicker. For some reason I'm not getting anything in

the thread I started!

I found the responses in the archives. Perhaps cc: nas...@uottawa.ca

please.


I have prepared a tiny (2.8K) package at
http://web.ncf.ca/nashjc/jfiles/fchk_2019-6.5.tar.gz

R CMD check --> OK

R CMD check --as-cran --> 1 ERROR, 1 NOTE

The error is in an example:


benbad<-function(x, y){
 # y may be provided with different structures
 f<-(x-y)^2
} # very simple, but ...

y<-1:10
x<-c(1)
cat("test benbad() with y=1:10, x=c(1)\n")
tryfc01 <- try(fc01<-fchk(x, benbad, trace=3, y))
print(tryfc01)
print(fc01)


There's quite a lot of output, but it doesn't make much sense to me,

as

it refers to code that I didn't write.

The function fchk is attempting to check if functions provided for
optimization do not violate some conditions e.g., character rather

than

numeric etc.

JN


On 2019-06-07 8:44 a.m., J C Nash wrote:

Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
Fri Jun 7 11:44:37 CEST 2019

  Previous message (by thread): [R-pkg-devel] try() in R CMD

check --as-cran

  Next message (by thread): [R-pkg-devel] using package data in

package code

  Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Right, what problem are you talking about? Can you tell us which

check

it is and what it actually complained about.
There is no check that looks at the sizes of x and y in

exypressions

such as
(x - y)^2.
as far as I know.

Best,
Uwe

On 07.06.2019 10:33, Berry Boessenkool wrote:


Not entirely sure if this is what you're looking for:


https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R

It does contain --as-cran a few times and there's the

change-history:



https://github.com/wch/r-source/commits/trunk/src/library/tools/R/check.R


Regards,
Berry



From: R-package-devel 
r-project.org> on behalf of J C Nash 

Sent: Thursday, June 6, 2019 15:03
To: List r-package-devel
Subject: [R-pkg-devel] try() in R CMD check --as-cran

After making a small fix to my optimx package, I ran my usual R

CMD check --as-cran.


To my surprise, I got two ERRORs unrelated to the change. The

errors popped up in

a routine designed to check the call to the user objective

function. In particular,

one check is that the size of vectors is the same in expressions

like (x - y)^2.

This works fine with R CMD check, but the --as-cran seems to have

changed and it

pops an error, even when the call is inside try(). The irony that

the routine in

question is intended to avoid problems like this is not lost on

me.


I'm working on a small reproducible example, but it's not small

enough yet.

In the meantime, I'm looking for the source codes of the scripts

for "R CMD check" and

"R CMD check --as-cran" so I can work out why there is this

difference, which seems

to be recent.

Can someone send/post a link? I plan to figure this out and

provide feedback,

as I suspect it is going to affect others. However, it may be a

few days or even

weeks if past experience is a guide.

JN

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

Re: [R-pkg-devel] try() in R CMD check --as-cran

[Serguei Sokol]

On 07/06/2019 15:31, Sebastian Meyer wrote:

The failure stated in the R CMD check failure report is:


  --- failure: length > 1 in coercion to logical ---


This comes from --as-cran performing useful extra checks via setting the
environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:


check if either argument of the binary operators && and || has length greater 
than one.


(see https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Tools)

The failure report also states the source of the failure:


  --- call from context ---
fchk(x, benbad, trace = 3, y)
  --- call from argument ---
is.infinite(fval) || is.na(fval)


The problem is that both is.infinite(fval) and is.na(fval) return
vectors of length 10 in your test case:


  --- value of length: 10 type: logical ---
  [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE


The || operator works on length 1 Booleans. Since fval can be of length
greater than 1 at that point, the proper condition seems to be:

any(is.infinite(fval)) || any(is.na(fval))

a little typo here: it should be '|', not '||', right ?

Best,
Serguei.


Am 07.06.19 um 14:53 schrieb J C Nash:

Sorry reply not quicker. For some reason I'm not getting anything in the thread 
I started!
I found the responses in the archives. Perhaps cc: nas...@uottawa.ca please.

I have prepared a tiny (2.8K) package at
http://web.ncf.ca/nashjc/jfiles/fchk_2019-6.5.tar.gz

R CMD check --> OK

R CMD check --as-cran --> 1 ERROR, 1 NOTE

The error is in an example:


benbad<-function(x, y){
# y may be provided with different structures
f<-(x-y)^2
} # very simple, but ...

y<-1:10
x<-c(1)
cat("test benbad() with y=1:10, x=c(1)\n")
tryfc01 <- try(fc01<-fchk(x, benbad, trace=3, y))
print(tryfc01)
print(fc01)


There's quite a lot of output, but it doesn't make much sense to me, as
it refers to code that I didn't write.

The function fchk is attempting to check if functions provided for
optimization do not violate some conditions e.g., character rather than
numeric etc.

JN


On 2019-06-07 8:44 a.m., J C Nash wrote:

Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
Fri Jun 7 11:44:37 CEST 2019

 Previous message (by thread): [R-pkg-devel] try() in R CMD check --as-cran
 Next message (by thread): [R-pkg-devel] using package data in package code
 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Right, what problem are you talking about? Can you tell us which check
it is and what it actually complained about.
There is no check that looks at the sizes of x and y in exypressions
such as
(x - y)^2.
as far as I know.

Best,
Uwe

On 07.06.2019 10:33, Berry Boessenkool wrote:


Not entirely sure if this is what you're looking for:
https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R
It does contain --as-cran a few times and there's the change-history:
https://github.com/wch/r-source/commits/trunk/src/library/tools/R/check.R

Regards,
Berry



From: R-package-devel  on behalf of J C 
Nash 
Sent: Thursday, June 6, 2019 15:03
To: List r-package-devel
Subject: [R-pkg-devel] try() in R CMD check --as-cran

After making a small fix to my optimx package, I ran my usual R CMD check 
--as-cran.

To my surprise, I got two ERRORs unrelated to the change. The errors popped up 
in
a routine designed to check the call to the user objective function. In 
particular,
one check is that the size of vectors is the same in expressions like (x - y)^2.
This works fine with R CMD check, but the --as-cran seems to have changed and it
pops an error, even when the call is inside try(). The irony that the routine in
question is intended to avoid problems like this is not lost on me.

I'm working on a small reproducible example, but it's not small enough yet.
In the meantime, I'm looking for the source codes of the scripts for "R CMD 
check" and
"R CMD check --as-cran" so I can work out why there is this difference, which 
seems
to be recent.

Can someone send/post a link? I plan to figure this out and provide feedback,
as I suspect it is going to affect others. However, it may be a few days or even
weeks if past experience is a guide.

JN

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

[[alternative HTML version deleted]]

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





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



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



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

Re: [R-pkg-devel] try() in R CMD check --as-cran

[Serguei Sokol]

On 07/06/2019 14:53, J C Nash wrote:

Sorry reply not quicker. For some reason I'm not getting anything in the thread 
I started!
I found the responses in the archives. Perhaps cc: nas...@uottawa.ca please.

I have prepared a tiny (2.8K) package at
http://web.ncf.ca/nashjc/jfiles/fchk_2019-6.5.tar.gz

R CMD check --> OK

R CMD check --as-cran --> 1 ERROR, 1 NOTE

The error is in an example:


benbad<-function(x, y){
# y may be provided with different structures
f<-(x-y)^2
} # very simple, but ...

y<-1:10
x<-c(1)

The faulty line in fchk() seems to be

if (is.infinite(fval) || is.na(fval)) { ... }

As fval is now allowed to be a vector, it conflicts with '||' operator 
which, as you know, expects scalar logical values. If you replace this 
line with something like:


if (any(is.infinite(fval) | is.na(fval))) { ... }
is gone even with --as-cran option used. In my opinion (even if nobody 
asks for it ;) ), it is fortunate that this option is picky enough about 
such kind of misuse of logical operators.


Best,
Serguei.


cat("test benbad() with y=1:10, x=c(1)\n")
tryfc01 <- try(fc01<-fchk(x, benbad, trace=3, y))
print(tryfc01)
print(fc01)


There's quite a lot of output, but it doesn't make much sense to me, as
it refers to code that I didn't write.

The function fchk is attempting to check if functions provided for
optimization do not violate some conditions e.g., character rather than
numeric etc.

JN


On 2019-06-07 8:44 a.m., J C Nash wrote:

Uwe Ligges ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de
Fri Jun 7 11:44:37 CEST 2019

 Previous message (by thread): [R-pkg-devel] try() in R CMD check --as-cran
 Next message (by thread): [R-pkg-devel] using package data in package code
 Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Right, what problem are you talking about? Can you tell us which check
it is and what it actually complained about.
There is no check that looks at the sizes of x and y in exypressions
such as
(x - y)^2.
as far as I know.

Best,
Uwe

On 07.06.2019 10:33, Berry Boessenkool wrote:


Not entirely sure if this is what you're looking for:
https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R
It does contain --as-cran a few times and there's the change-history:
https://github.com/wch/r-source/commits/trunk/src/library/tools/R/check.R

Regards,
Berry



From: R-package-devel  on behalf of J C 
Nash 
Sent: Thursday, June 6, 2019 15:03
To: List r-package-devel
Subject: [R-pkg-devel] try() in R CMD check --as-cran

After making a small fix to my optimx package, I ran my usual R CMD check 
--as-cran.

To my surprise, I got two ERRORs unrelated to the change. The errors popped up 
in
a routine designed to check the call to the user objective function. In 
particular,
one check is that the size of vectors is the same in expressions like (x - y)^2.
This works fine with R CMD check, but the --as-cran seems to have changed and it
pops an error, even when the call is inside try(). The irony that the routine in
question is intended to avoid problems like this is not lost on me.

I'm working on a small reproducible example, but it's not small enough yet.
In the meantime, I'm looking for the source codes of the scripts for "R CMD 
check" and
"R CMD check --as-cran" so I can work out why there is this difference, which 
seems
to be recent.

Can someone send/post a link? I plan to figure this out and provide feedback,
as I suspect it is going to affect others. However, it may be a few days or even
weeks if past experience is a guide.

JN

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

[[alternative HTML version deleted]]

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





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



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