Re: [R-pkg-devel] winUCRT failures

[Tomas Kalibera]

On 4/25/21 2:49 PM, Duncan Murdoch wrote:
The current CRAN release of rgl fails on winUCRT because of missing 
dependencies:


'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr', 
'crosstalk', 'manipulateWidget'.


Tracing `htmlwidgets` shows it also fails because of missing 
dependencies:


'htmltools', 'jsonlite', 'yaml'

and 'htmltools' fails because of missing dependencies

'digest', 'base64enc', 'rlang'

but 'digest' only gets a warning (congratulations, Dirk!), 'base64enc' 
gets a NOTE (hurray Simon!).  'rlang' is failing a test because of a 
missing suggested dependency on 'glue'.  At that point I stopped 
searching.


Does anyone have a list of packages that actually need fixes?  I'd 
like to help those maintainers with the necessary updates.


Hi Duncan,

thanks for helping with the fixes to packages needed for this toolchain 
(and for having UTF-8 as native encoding on Windows). Fixing packages to 
properly declare their dependencies will be useful in general.


And thanks for asking about the missing dependencies, it turns out that 
the checks broke during transition of R-devel to 4.2. I've fixed my 
scripts now and if I got it right, correct results should appear in 
about 1.5 days from now. The numbers were about 10x better before this 
happened.


A number of packages will still need fixing. I can help searching the 
logs for the root issues (packages failing for other reasons than 
missing dependencies) once the results are correct again. And I can also 
make the logs downloadable in tarball etc (rather than one-by-one).


Best
Tomas



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] Passing CRAN checks for a package linking to a system library on CRAN machines

[Tomas Kalibera]

On 5/13/21 7:06 AM, SN248 wrote:

I am working on a package which provides an interface to the libsbml C++
library (http://sbml.org/Software/libSBML) in R. The source code of this
package (r2sbml) can be found at the following link

https://github.com/sn248/r2sbml

The package passes CRAN checks with `R CMD check` on my machine, but I do
have dependency (libsbml library) installed on my machine (OSX) with
headers and static libs at the usual locations, i.e., /usr/local/include
and /usr/local/lib. The package also passes CRAN check on a Windows machine
with libsbml installed using Rtools40 and msys2. The DESCRIPTION file lists
libsbml in SystemRequirements but `R CMD check` obviously fails on rhub
machines because there are no instructions to install libsbml first. As I
understand, I have the following options to pass checks on CRAN

1. Bundle the source code of libsbml into the package and make the static
libs on the fly. I don't really want to try this approach even though I
have used this approach before in another package as I think creating the
static lib is not as straightforward for this library because of the large
number of files and complex dependency chart.

2. Include header files in the `inst` folder and pull the static libs from
rwinlib github (assuming the libs can be posted there). I am not sure if
this approach will work on all platforms on which CRAN checks take place.

3. Somehow include instructions to install libsbml on CRAN machines (I have
no idea how to do this), or request CRAN maintainers to install libsbml
with header files and libs at usual locations (i.e., /usr/local/include and
/usr/local/lib).

I am sure some version of this question has been asked before as there are
many packages which interface with C/C++ libraries listed as
SystemRequirements, but I could not find a clear answer to this aspect,
i.e., passing checks on CRAN machines.

Any guidance here and pros/cons of the above mentioned approaches will be
very helpful.


I think the best way for maintenance and end users is when the libraries 
are part of common software distributions R is used with on each 
platforms, which are also installed on CRAN machines. For Linux these 
are popular distributions including Debian, Ubuntu, Fedora. For Windows 
this is customized msys2 (rtools) and customized mxe. For macOS this is 
a custom distribution ("recipes").


So, if your library is already present in those distributions, but not 
installed on some of the CRAN machines, I'd simply ask for it to be 
installed - the installation is trivial in that case, this is what the 
distributions are for.


If the library is not present in those distributions, the next best I 
think is to contribute it to them. In case of Windows, ideally 
contribute also to the upstream vanilla distributions, not just to the 
customized versions for R. This would allow most people to benefit from 
your contribution, and the additional burden on CRAN maintainers (who 
have to deal with many thousands of packages) would be minimized.


If all that failed, and the license allows, one can include the source 
code of the library into the package, but that creates burden on users 
as well as maintainers (of the package, but also the repository). It may 
create confusion about the configuration due to duplication between 
packages. It creates burden for repository maintainers. It takes 
additional time on installation (particularly some libraries heavily 
using C++ take forever to build, and repository maintainers do that very 
often).


Downloading pre-compiled binaries (static libraries) at installation 
time is the worst option in my view. It is non-transparent, 
non-repeatable, and the binaries may be incompatible (e.g. on Windows 
all object files have to be built for the same C runtime). It makes 
maintenance of R much harder, currently the transition from MSVCRT to 
UCRT on Windows.


Best
Tomas



Thanks
Satya

[[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] Fwd: Passing CRAN checks for a package linking to a system library on CRAN machines

[Tomas Kalibera]

On 5/13/21 7:29 AM, Sokol Serguei wrote:

Le 13/05/2021 à 07:06, SN248 a écrit :

I am working on a package which provides an interface to the libsbml C++
library (http://sbml.org/Software/libSBML) in R. The source code of this
package (r2sbml) can be found at the following link

https://github.com/sn248/r2sbml

The package passes CRAN checks with `R CMD check` on my machine, but 
I do

have dependency (libsbml library) installed on my machine (OSX) with
headers and static libs at the usual locations, i.e., /usr/local/include
and /usr/local/lib. The package also passes CRAN check on a Windows 
machine
with libsbml installed using Rtools40 and msys2. The DESCRIPTION file 
lists

libsbml in SystemRequirements but `R CMD check` obviously fails on rhub
machines because there are no instructions to install libsbml first. 
As I

understand, I have the following options to pass checks on CRAN

1. Bundle the source code of libsbml into the package and make the 
static

libs on the fly. I don't really want to try this approach even though I
have used this approach before in another package as I think creating 
the
static lib is not as straightforward for this library because of the 
large

number of files and complex dependency chart.

2. Include header files in the `inst` folder and pull the static libs 
from

rwinlib github (assuming the libs can be posted there). I am not sure if
this approach will work on all platforms on which CRAN checks take 
place.


3. Somehow include instructions to install libsbml on CRAN machines 
(I have

no idea how to do this), or request CRAN maintainers to install libsbml
with header files and libs at usual locations (i.e., 
/usr/local/include and

/usr/local/lib).


I faced the same problem for my package r2sundials and in the end, I 
have opted for including the third-party source code into the package. 
However, a CRAN team member told me later that such kind of request 
(i.e. install third-party software on CRAN machines) can be sent to 
the CRAN team. Not sure that they accept but I think you can start by 
asking it and if the request is rejected, you can try other options.


I think that sundials is a good example why trying the other options 
first is a good suggestion. It is now included in three CRAN packages 
(paropt, r2sundials, sundialr). Apart from the duplication (build time), 
it has a problem of multiply defined symbols (tentative definitions, 
issues with -fno-common, which is the default in GCC 10), which now has 
to be handled in the three packages separately.


Best
Tomas


Best,
Serguei.



I am sure some version of this question has been asked before as 
there are

many packages which interface with C/C++ libraries listed as
SystemRequirements, but I could not find a clear answer to this aspect,
i.e., passing checks on CRAN machines.

Any guidance here and pros/cons of the above mentioned approaches 
will be

very helpful.

Thanks
Satya

[[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


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

Re: [R-pkg-devel] Passing CRAN checks for a package linking to a system library on CRAN machines

[Tomas Kalibera]

On 5/14/21 4:19 AM, SN248 wrote:
> Thank you Tomas and Sokol for your suggestions.
>
> Based on Tomas' suggestion, it seems the best way forward would be to 
> first request CRAN maintainers to install libsbml on the CRAN 
> machines. It is quite straightforward to install the library from the 
> instructions provided online. If the installation fails on a 
> particular architecture, I should try bundling the source code and 
> creating the static libraries.

Please let me clarify, I am not suggesting that you ask CRAN team to 
create the distribution packages for you, but only to install an 
existing distribution package (in case they are not doing that already).

The distribution package is usually a script which automatically 
downloads the software, builds it, picks up the results, adds some 
meta-data about dependencies, and archives them in a supported format. 
Someone has to create the distribution package, and I am suggesting that 
you as R package maintainer should do that, possibly getting help from 
other volunteers e.g even on the R-devel mailing list. The CRAN team 
would only add that package name to their list of installed packages (in 
case it is not there implicitly, i.e. they possibly won't have to do 
anything).

So first, I would should check for existing distribution packages. Most 
distributions have their own indexing/search support, but you can also 
look online as follows.

For Linux distributions, there is e.g. pkgs.org for the first quick 
search (libsml-devel, libsbml-dev might be what you are looking for).

For Windows, msys2 packages are here 
https://github.com/msys2/MINGW-packages/, rtools packages are here 
https://github.com/r-windows/rtools-packages (so there is 
mingw-w64-libsbml). MXE packages are here 
https://github.com/mxe/mxe/tree/master/src and the customized version 
for R is here 
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/
 
(so upstream MXE doesn't have sbml, but the customized has libsbml).

For macOS, recipes for R are here 
https://github.com/R-macos/recipes/tree/master/recipes and it does not 
have sbml library as far as I can see.

So, if you wanted your package to use sbml, the best way would be to 
test it with the sbml package from all the distributions mentioned above 
(from Linux, at least the ones used by CRAN - Debian/Ubuntu, Fedora). 
Then, you would create a recipe (distribution package) for macOS, test 
it with your package, and contribute to the "recipes" above. When 
creating the recipe, look at other recipes to get the form, and look at 
sbml in the previously mentioned distributions to see how to 
download/build it (in addition to the online manual you mentioned).

Once that is in, you could submit your package to CRAN, following the 
usual checks you do when submitting packages. And then, in case it 
failed on some of the CRAN machines, you could contact the individual 
maintainer and ask for installing that distribution package of the given 
name. In some cases it won't be necessary (the machines would already 
have the package, they may be installing all available packages 
automatically).

This may sound like a bit of work, but that is the price for adding 
dependencies on native libraries, and someone has to do this work. 
Installing libraries manually on the check machines is not going to 
scale and may be too much burden for many end users, apart from 
difficulties with repeatability, maintenance, etc.

Best
Tomas

>
> Thanks again for your help.
> Satya
>
> On Thu, May 13, 2021 at 2:28 AM Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>> wrote:
>
>
> On 5/13/21 7:06 AM, SN248 wrote:
> > I am working on a package which provides an interface to the
> libsbml C++
> > library (http://sbml.org/Software/libSBML
> <http://sbml.org/Software/libSBML>) in R. The source code of this
> > package (r2sbml) can be found at the following link
> >
> > https://github.com/sn248/r2sbml <https://github.com/sn248/r2sbml>
> >
> > The package passes CRAN checks with `R CMD check` on my machine,
> but I do
> > have dependency (libsbml library) installed on my machine (OSX) with
> > headers and static libs at the usual locations, i.e.,
> /usr/local/include
> > and /usr/local/lib. The package also passes CRAN check on a
> Windows machine
> > with libsbml installed using Rtools40 and msys2. The DESCRIPTION
> file lists
> > libsbml in SystemRequirements but `R CMD check` obviously fails
> on rhub
> > machines because there are no instructions to install libsbml
> first. As I
> > understand, I have the following options to pass checks on CRAN
> >
> > 1. Bundle the source code of libsb

Re: [R-pkg-devel] Valgrind warning: invalid size of 4, is it due to a simple overrun?

[Tomas Kalibera]

On 6/2/21 3:01 AM, Hugh Parsonage wrote:

Hello,

I received a valgrind warning about my package, hutilscpp, from CRAN
(thank you).  I believe I've tracked down and fixed the problem, but I
wasn't able to reproduce the error on rhub (including with
--leak-check=full etc) so I'd like to know if I'm missing something.

The valgrind warning is "Invalid write of size 4" and refers to this
line 
https://github.com/HughParsonage/hutilscpp/blob/508f134b3f388653985eca372ed5f4f8b8eb3471/src/Cwhich_even.c#L43

the context for this line is:

const double * xp = REAL(xx);
for (R_xlen_t i = 0, j = 0; i < N; ++i) {
   int is_even = R_finite(xp[i]) && (fmod(xp[i], 2) == 0);
   ansp[j] = (int)(i + 1);// # < line 43
   j += is_even;
}
I would simply use an explicit branch, store the index into ansp only 
when the element is even, and increment an index for ansp in that case. 
That would make the code clearer and easy to see potential errors in it.

where ansp is a pointer to an integer vector whose length is the
number of "even" doubles in xx.  I can see that the problem arises
when the last even number occurs before the end of the vector xx, at
which point j == length(ansp), yet the loop continues.  I've amended
the i < N in the for loop to (i < N && j < n_even) which I believe is
sufficient, but obviously I thought it was ok before.

I'd rather not resubmit only to discover that I've overlooked something else.

As a supplementary question, does the valgrind check depend on the
runtime values in the test suite or does it perform fuzz testing?  In
other words, do I need to add tests to reproduce?


With valgrind, the code is ran deterministically.

I would not worry about trying to reproduce if the code is rewritten in 
the way suggested, because that's easy to validate visually.


In principle, if you wanted still to reproduce, you could add an 
explicit runtime check that the identified write is in bounds, run the 
original code, hopefully see it fail. And then do the same with the 
fixed code and see it pass. And then remove the runtime check and submit.


Best
Tomas



Best,


Hugh.

__
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] speeding up package code/build/test cycle

[Tomas Kalibera]

On 6/24/21 11:31 PM, Duncan Murdoch wrote:

On 24/06/2021 4:52 p.m., Dirk Eddelbuettel wrote:


On 24 June 2021 at 16:31, Duncan Murdoch wrote:
| This does the full compile again, so it's slow.

ccache fixes that (as it has its own cache). It also works on macOS.


I haven't tried ccache:  shouldn't "make" handle that kind of thing?


In principle, yes, and I think one should not need ccache for package 
development when make files are designed well.


But there is a case for ccache. If for whatever reason one decides to do 
a "clean" build in "make" sense often, ccache can help. For example when 
you are working on the build system itself, on the make file or 
compilation options.


MXE (used to build the experimental UCRT toolchain for Windows) uses 
ccache when building external software, there clean re-builds are a 
common task (newer versions of that software, slightly changed build 
configuration) and some builds take forever when the projects are large.


ccache could help also when switching between code versions in the same 
workspace (via a versioning system), or when building same files in 
different directories (and not handled by the build system).


Tomas



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] UX for "WARNING unable to translate to native encoding"?

[Tomas Kalibera]

On 8/16/21 12:42 PM, Ivan Krylov wrote:

On Mon, 16 Aug 2021 09:05:54 +
David Norris  wrote:


Unicode U+00d7 (times), U+00b1 (plus-minus) and U+03bc (mu) have
equivalents in Latin-1 encoding, and I have used these without
difficulty in strings, neither U+2206 (INCREMENT) nor U+0394 (Greek
Delta) does

But not in some other locale encodings on Windows (e.g. CP-1251), nor
in some single-byte locale encodings on *nix-like systems (e.g.
ru_RU.KOI8-R), which are admittedly used much rarer nowadays than on
Windows. Unless I'm mistaken, the "\u2206t" in your example needs to
become a symbol, and symbols are always translated into the locale
encoding [1] [2].

I would expect this warning to be a problem for CRAN, but I'm just
another package developer, so I could be wrong.

Yes, this is a problem. Only ASCII characters should be used in symbol 
names (in R packages), as they can be represented in every (supported) 
locale.


Some characters would be best-fitted by Windows (replaced by other 
similar characters) during translation to native encoding, if they are 
not representable directly, but that can produce surprising results and 
should not be relied on, definitely not in packages.


Best
Tomas

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

Re: [R-pkg-devel] Unicode Name Warnings for Package Constant

[Tomas Kalibera]

In the current R releases, R symbol names are in the native encoding, 
which on Windows in R (the normal MSVCRT builds up to R 4.1) cannot be 
UTF-8 nor any other Unicode encoding. So you can't portably use such 
characters e.g. in names of vector elements or of bindings in an 
environment, so not even as keys in a hash map implemented using an 
environment.


This works in UCRT builds of Windows on recent Windows 10 (and on Unix 
and macOS for many years), but before that becomes the norm, it might be 
easiest to give up on this feature in your package. But, in principle, 
you can work with UTF-8 strings, sometimes (one needs to check the 
docs), but they cannot be R symbols. So you can do some operations e.g. 
with a vector like


c(mu = "\u00b5")

where the UTF-8 string is a value, not a name.

Best
Tomas


On 9/2/21 5:24 PM, b...@denney.ws wrote:

Hello,

  


In the janitor package, we want to optionally support conversion from
Unicode characters that visually map to mu or micro to the character "u".
For that, we were thinking to create an unexported character vector constant
with names of all the Unicode mu/micro characters and values of "u".  As a
work-around, I was able to fix the issue using setNames(), but it was a
non-intuitive fix, and I would prefer to just use create the named character
vector directly.

  


Is there a good way to prevent the warnings below?

  


When running the following (on Windows 10 with R 4.1.0) either during a
normal R session or while checking the package (via devtools::check()), we
get several warnings:

  


mu_to_u <-

   c(

 "\u00b5"="u", "\u03bc"="u", "\u3382"="u", "\u338c"="u", "\u338d"="u",

 "\u3395"="u", "\u339b"="u", "\u33b2"="u", "\u33b6"="u", "\u33bc"="u"

   )

  


   Warnings in file 'R/clean_names.R':

 unable to translate '' to native encoding

 unable to translate '' to native encoding

 unable to translate '' to native encoding

 unable to translate '' to native encoding

 unable to translate '' to native encoding

 unable to translate '' to native encoding

 unable to translate '' to native encoding

 unable to translate '' to native encoding

  


I tried wrapping this in suppressWarnings(), but the warnings still
occurred.

  


Thanks,

  


Bill


[[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] (R-devel unknown warning: 'memory.limit()' is no longer supported)

[Tomas Kalibera]

Dear Cristhian,

memory.limit() is called by package "ff" when it is loaded. Your new 
package uses "ff" via "propagate". Perhaps the easiest option for you is 
to re-try the submission once "ff" is adapted to this change in R-devel.


Best
Tomas

On 9/3/21 7:10 PM, Cristhian Paredes Cardona wrote:

Dear Brodie Gaslam,

Thank you for your quick reply.
Do you maybe know how could I avoid the use of  'memory.limit()' during
package installation?
Best,
Cristhian Paredes

El vie, 3 sept 2021 a las 11:21, brodie gaslam ()
escribió:


Or you might need to make their use conditional on the R
version.  It is possible that the call is still needed if your
package is run on older versions of R.  I am not familiar with
the general use of this though.  I only noticed the change
in R-devel and linked it to your question.

Best,

B.


On Friday, September 3, 2021, 12:18:35 PM EDT, brodie gaslam <
brodie.gas...@yahoo.com> wrote:


There was a recent changed made to R to remove that option.
There is documentation visible in the patch that explains it:


https://github.com/r-devel/r-svn/commit/795fb3fe60d35734750afbc34cc7d36b19290b9c

Presumably you would have to remove any uses of the now
unsupported functions.  After the patch, the only thing those
functions do is issue the warning.

Best,

B.


On Friday, September 3, 2021, 11:39:03 AM EDT, Cristhian Paredes Cardona <
craparede...@unal.edu.co> wrote:



Dear All,

I'm trying to submit an R package to CRAN and there is a new warning that
did not use to appear a few days ago when checking with winbuilder (R under
development version):

Found the following significant warnings:
   Warning: 'memory.limit()' is no longer supported
See 'd:/RCompile/CRANincoming/R-devel/masscor.Rcheck/00install.out' for
details.

Package build is attached and Check results when the warning did not
appear are at: https://win-builder.r-project.org/2zQe5ZnEci31/

I would appreciate if someone could please provide me with some guide
on how to solve this issue.

Thanks in advance.

Sincerely,

Cristhian Paredes

--
*Aviso legal:* El contenido de este mensaje y los archivos adjuntos son
confidenciales y de uso exclusivo de la Universidad Nacional de Colombia.
Se encuentran dirigidos sólo para el uso del destinatario al cual van
enviados. La reproducción, lectura y/o copia se encuentran prohibidas a
cualquier persona diferente a este y puede ser ilegal. Si usted lo ha
recibido por error, infórmenos y elimínelo de su correo. Los Datos
Personales serán tratados conforme a la Ley 1581 de 2012 y a nuestra
Política de Datos Personales que podrá consultar en la página web
www.unal.edu.co .* *Las opiniones,
informaciones,
conclusiones y cualquier otro tipo de dato contenido en este correo
electrónico, no relacionados con la actividad de la Universidad Nacional
de
Colombia, se entenderá como personales y de ninguna manera son avaladas
por
la Universidad.
__
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] LaTeX issues on r-devel-windows-x86_64-gcc10-UCRT?

[Tomas Kalibera]

Dear Stephan,

On 9/21/21 3:31 PM, Stephan Struckmann wrote:
> Dear all,
>
> lately, an error and two warnings occurred for our package dataquieR on the 
> platform r-devel-windows-x86_64-gcc10-UCRT 
> (https://cran.r-project.org/web/checks/check_results_dataquieR.html).
>
> Unfortunately, error messages/warnings are likely related to the test 
> system’s configuration/setup:
>
>- Missing file 
> /msys64/home/tomas/ucrt3/svn/ucrt3/r_packages/patches_idx.rds

thanks for the report. This is due to a problem that prevented building 
the patch index (so yes, the test system), I've fixed it earlier today 
and new results should appear in about a day.

>- "LaTeX errors“ without further specification, rather unspecific.
>
> I have now re-built this environment as close as I could according to the 
> platform description and given my infrastructure. In this setup, I had a 
> missing font in the end in my test installation.
>
> After I had applied this: https://tex.stackexchange.com/a/129523 (setup 
> configuration for the font ts1-zi4r), the pdf could be created. The warning 
> about missing patches_idx.rds, I could not reproduce, but this may be less 
> relevant anyway.

Thanks, I will try this out when the current run finishes, if the LaTeX 
error still appears.

The machine uses the latest MiKTeX (21.8), which crashes e.g. when 
running "texify --version segfaults". I've reported this (and it may 
well be an error that has been reported before - 
https://github.com/MiKTeX/miktex/issues/921). I will have a look in the 
logs when the new results appear, it may be related.

> The setup, I used (hopefully close to r-devel-windows-x86_64-gcc10-UCRT) was
>
>- Microsoft Windows 10 Enterprise LTSC, 10.0.17763 Build 17763
>- R 4.2.0 Pre Release UCRT3 downloaded today from r-project.org as the 
> only R installation
>- Rtools 4.0.2.0.1 downloaded today from r-project.org as the only Rtools 
> installation
>- For TeX, I installed MiKTeX 21.6 as the only TeX installation.
>- all binaries were put on the PATH environment variable
>
> ——
>
> Now my question: Is this related to CRAN’s r-devel-windows-x86_64-gcc10-UCRT 
> and can that be fixed there? Whom should I contact at CRAN?

In principle, you can always write to the CRAN address and your email 
will be forwarded to the right person. Currently I am running these checks.

Best
Tomas

>
> Thank you in advance,
>
> Stephan
>
>
>
> --
> Dr. Stephan Struckmann
> stephan.struckm...@uni-greifswald.de
> Biomathematiker/Informatiker/Apotheker
> Tel. +49 (0) 3834 - 86 77 83
>
> Institut für Community Medicine
> Walther-Rathenau-Str. 48
> 17475 Greifswald
>
>
> __
> 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

Re: [R-pkg-devel] LaTeX issues on r-devel-windows-x86_64-gcc10-UCRT?

[Tomas Kalibera]

Dear Stephan,

On 9/21/21 8:10 PM, Struckmann, Stephan wrote:

Dear Thomas,

thank you for your quick reply. I'll consider then writing to the CRAN address 
earler, if I have strong hints that the build/check system may cause a 
warning/error.
So, I'll wait for the next check-run then. If I can help you in any way with 
fixing the pipelines, just ask... CRAN is doing a great job and we definitley 
benefit strongly from it, so I should be able to find some time to help.


thanks. The new results are now available and the patches issue was 
resolved.


These results are still with MiKTeX 21.8, with some crashes (e.g. when 
building the documentation for R), but it seems dataquieR is not 
affected. I will downgrade to 21.6, which should resolve these - I've 
tested that in the automated VM setup at

https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/vm.html

Best
Tomas


Thank you again, hope we can get this fixed soon,

Greetings

Stephan




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

Re: [R-pkg-devel] socketConnection, delay when reading from

[Tomas Kalibera]

On 11/27/21 5:24 PM, Ben Engbers wrote:

Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-terminated message protocol [1]. It has to be 
processed one byte at a time.


[1] https://docs.basex.org/wiki/Server_Protocol

The message may contain embedded 0x00's. To distinguish these embedded 
0x00's (and 0xFF's) from a terminating 0x00, embedded 0x00's and 
0xFFare prefixed with a 0xFF byte. This means that when you process 
one byte at a time you have to perform a check on every byte. This 
results in totally unacceptable response times (My first version of 
this client was based on this approach)


The only alternative solution I can think off is to use C++ to create 
a socket and a function that reads from the socket. But since I have 
hardly any experience with C++ programming nor using the rcpp package



I think you could use non-blocking read. Read what is available in 
chunks (e.g. up to 1024 bytes long). And based on what is read already, 
figure out whether it is all data or not. Something along the lines as 
the demo below. The demo, though, is polling too much (re-running 
readBin to only find out no data is available yet). It should be 
possible to improve with socketSelect().


Best
Tomas

# the client

con2 <- socketConnection("localhost", port = 6011, open = "rb")
cat("Connected...\n")
total <- 0

done <- function(n) {
  n >= 1e8
}

while(!done(total)) {
   r <- readBin(con2, "raw", 1024)
   total <- total + length(r)
   cat("Read", length(r), "bytes (total ", total, ").\n")
}
close(con2)

# the server

n <- 1e8
w <- as.raw(runif(n, 0, 255))
con1 <- socketConnection(port = 6011, blocking = TRUE, server = TRUE, 
open="a+b")

cat("Connected...\n")
writeBin(w, con1)
cat("Data sent to client...\n")
close(con1)



Ben

__
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] socketConnection, delay when reading from

[Tomas Kalibera]

On 11/27/21 8:05 PM, Tomas Kalibera wrote:


On 11/27/21 5:24 PM, Ben Engbers wrote:

Op 27-11-2021 om 17:03 schreef Jeff Newmiller:
This is a null-terminated message protocol [1]. It has to be 
processed one byte at a time.


[1] https://docs.basex.org/wiki/Server_Protocol

The message may contain embedded 0x00's. To distinguish these 
embedded 0x00's (and 0xFF's) from a terminating 0x00, embedded 0x00's 
and 0xFFare prefixed with a 0xFF byte. This means that when you 
process one byte at a time you have to perform a check on every byte. 
This results in totally unacceptable response times (My first version 
of this client was based on this approach)


The only alternative solution I can think off is to use C++ to create 
a socket and a function that reads from the socket. But since I have 
hardly any experience with C++ programming nor using the rcpp 
package



I think you could use non-blocking read. Read what is available in 
chunks (e.g. up to 1024 bytes long). And based on what is read 
already, figure out whether it is all data or not. Something along the 
lines as the demo below. The demo, though, is polling too much 
(re-running readBin to only find out no data is available yet). It 
should be possible to improve with socketSelect().


This is an extended demo with socketSelect() used to wait on the client 
for some data to be available, to avoid consuming too much CPU by 
polling. To be pasted into two R sessions running on the same computer.
You would have to replace the function done() with something figuring 
out from the data whether it is complete or not, based on the protocol.


Best
Tomas


# the client

con2 <- socketConnection("localhost", port = 6011, open = "rb")
cat("Connected...\n")
total <- 0

done <- function(n) {
  n >= 2e8
}

while(!done(total)) {
   cat("Waiting for data to become ready...\n")
   socketSelect(list(con2))
   cat("Reading data...\n")
   r <- readBin(con2, "raw", 1024)
   total <- total + length(r)
   cat("Read", length(r), "bytes (total ", total, ").\n")
}
close(con2)

# the server

n <- 1e8
w <- as.raw(runif(n, 0, 255))
con1 <- socketConnection(port = 6011, blocking = TRUE, server = TRUE, 
open="a+b")

cat("Connected...\n")
writeBin(w, con1)
cat("Sent data the first time, sleeping...\n")
Sys.sleep(10)
cat("Sending data the second time...\n")
writeBin(w, con1)
cat("Data sent to client...\n")
close(con1)



Best
Tomas

# the client

con2 <- socketConnection("localhost", port = 6011, open = "rb")
cat("Connected...\n")
total <- 0

done <- function(n) {
  n >= 1e8
}

while(!done(total)) {
   r <- readBin(con2, "raw", 1024)
   total <- total + length(r)
   cat("Read", length(r), "bytes (total ", total, ").\n")
}
close(con2)

# the server

n <- 1e8
w <- as.raw(runif(n, 0, 255))
con1 <- socketConnection(port = 6011, blocking = TRUE, server = TRUE, 
open="a+b")

cat("Connected...\n")
writeBin(w, con1)
cat("Data sent to client...\n")
close(con1)



Ben

__
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] socketConnection, delay when reading from

[Tomas Kalibera]

On 11/28/21 5:10 PM, Ben Engbers wrote:
Searching Google seems easy. But finding reaully usefull information 
is often very difficult.

I alreay found hint #1. Thankfs for #2 and #3


Perhaps people who teach these things could give best recommendations 
(and those may not be reading this list).


It would be useful to learn the basics of sockets. The wikipedia might 
work if you wanted something short: 
https://en.wikipedia.org/wiki/Berkeley_sockets.


And then you could read the online R help for the R-level socket 
functions used in the demo program. For the parallel package (e.g. PSOCK 
clusters), you might also read the vignette of that package. And to look 
for usage patterns of the R socket API, one could look into the sources 
of the parallel package (the part implemented in R).


Tomas



Op 28-11-2021 om 00:03 schreef Jeff Newmiller:

Google?

https://developer.r-project.org/Blog/public/2020/03/17/socket-connections-update/ 



https://www.digitalocean.com/community/tutorials/understanding-sockets

https://developer.ibm.com/tutorials/l-sockpit/

On November 27, 2021 2:36:48 PM PST, Ben Engbers 
 wrote:

Hi,

Looks promising! Where can I find more information or tutorials about
psock or parallel computing?


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

Re: [R-pkg-devel] socketConnection, delay when reading from

[Tomas Kalibera]

On 12/8/21 12:20 PM, Ben Engbers wrote:

Op 07-12-2021 om 23:49 schreef Ben Engbers:

After a long nightly session, I ended up with inserting a wait between 
sending the authentication nonce and reading the status byte.


writeBin(auth, private$conn)
Sys.sleep(.1)
Accepted <- readBin(conn, what = "raw", n = 1)

The new code, which now uses a non-blocking socket, takes less than 4 
seconds to execute the 53 tests. Compared to the 120 seconds when 
using a blocking socket, this was worth the effort.


Ok, this confirms there is a race condition, but the next step should be 
removing it, so that it works reliably. Actually, one way to test that 
such programs are race-free is to actually on purpose insert sleeps at 
various locations - the programs then should still work.


I am not able to give more specific advice based on the code snippet you 
sent yesterday, but in principle, you can use socketSelect() to wait for 
the connection to become ready to be read from. In either case, there 
needs to be some way to tell whether the received data is complete. 
Either you know the length, or there is some special mark in the data, 
there has to be something.


If you need more help from people on the list, it might be better to 
send a small, but full complete example, so also with a server, so that 
it is something people could run and reproduce.


Best
Tomas



Ben



Hi Tomas,

I have implemented your suggestions as follows: (I'm not certain yet 
if the first check in done - total_length == 0 is realy needed)


Creating the socket:

CreateSocket = function(host, port = 1984L, username, password) {
   tryCatch(
 {conn <- private$conn <- socketConnection(
   host = "localhost", port,
   open = "w+b", server = FALSE, blocking = FALSE, encoding = 
"UTF-8")

 }, error = function(e) {
   stop("Cannot open the connection")
  }
   )

 Authenticating

response <- readBin_(conn) %>% rawToChar()
===> # browser()
splitted <-strsplit(response, "\\:")
ifelse(length(splitted[[1]]) > 1,
   { realm <- splitted[[1]][1]
 code  <- paste(username, realm, password, sep=":")
 nonce <- splitted[[1]][2] },
   { code  <- password
 nonce <- splitted[[1]][1]}
   )
code <- md5(paste(md5(code), nonce, sep = "")) %>% charToRaw()
# send username + code
auth <- c(charToRaw(username), as.raw(0x00), code, as.raw(0x00))
writeBin(auth, private$conn)
Accepted <- readBin(conn, what = "raw", n = 1) == 0x00
if (!Accepted) {
close(private$conn)
stop("Access denied")
}



The first time readBin is used is while authenticating a new session.
This code fails ;-(

But when I insert a  call to browser() after the first authentication 
line, I can execute all the following code without problems. This 
results in a fully functional session. And all the other following 
calls to readBin_ return the correct data.
This means that 'done' and 'readBin' do exactly what they are 
intended to do.


Question
Why does creating and authenticating fail when a call to browser() is 
missing? (Or why does authentication succeed after I have used the 
debugger?


Best,
Ben


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

[R-pkg-devel] R/CRAN switch to UCRT on Windows

[Tomas Kalibera]

(My apologies for cross-posting to those reading also the R-devel 
mailing list)


Please note an update concerning the support of UTF-8 as native encoding 
on Windows, which may at this point be of interest particularly to 
developers of packages with native code and to R users using R-devel 
(the development version of R) on Windows:



https://developer.r-project.org/Blog/public/2021/12/07/upcoming-changes-in-r-4.2-on-windows/

The key part is that CRAN will switch the incoming checks of R packages 
on Windows to a new toolchain targeting UCRT on Monday, December 13.


It may take up to several days for all systems to synchronize and during 
this time, it may be difficult to build R-devel on Windows from source 
or to install packages.  After the switch, the snapshot R-devel builds 
and binary package builds provided by CRAN will be built using the new 
toolchain for UCRT. These new builds will use UTF-8 as the native 
encoding on recent Windows.


These builds will be incompatible with the previous builds for MSVCRT 
and installed/binary packages will be incompatible as well. The 
recommended/simplest course of action for R-devel users is to uninstall 
the old build of R-devel, RTools, delete the old package libraries, and 
then install the new versions.


Checks of CRAN packages with the new toolchain have been running since 
March with results available on CRAN pages. By now, most packages are 
working, but some packages using native (C, C++, Fortran) code still 
have to be updated. The Winbuilder service and R-hub support the new 
toolchain, there is also support/example for using github actions. The 
builds of R-devel and CRAN (and recommended binary packages) with the 
new toolchain are available regularly since March.


I've created patches for CRAN (and required Bioconductor packages) which 
are installed automatically at package installation time by R. This 
feature will be also in R-devel after the switch and will be used 
temporarily to give package authors more time to fix their packages. Uwe 
Ligges, other CRAN team members and I have also been in touch with some 
package authors, providing advice how to fix their packages, when the 
issues required more explanation. I am prepared to help the remaining 
authors as well if needed.


Please see the blog post and materials linked from there for more 
details and feel free to ask questions.


Thanks
Tomas

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

Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

[Tomas Kalibera]

On 12/16/21 4:17 PM, Hiroaki Yutani wrote:

This would be an empty character vector on my Alpine Linux server as
well.

I see, thanks for the information. Sorry for my lack of consideration on this.


So there are 127 *.ttf files installed, but systemfonts::system_fonts()
does not find any of these.

Thanks for investigating quickly! Then, it seems I should wait for the
problem to be solved on systemfonts' side. I'm curious what's the
difference between r-devel-windows-x86_64-new-TK, on which the check
doesn't fail, by the way.


It is also Windows Server 2022 with GUI, a quite fresh installation. The 
checks run in a docker container (also WS2022, 
mcr.microsoft.com/windows/server:ltsc2022, without any manually 
installed fonts).


Actually there is no manually installed software there, all that is 
installed is (in this order):


https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1

plus R and R packages.

I assume you can reproduce on Winbuilder, and so perhaps you could 
create a version of your package with a lot of instrumentation/print 
messages and submit there to find the cause? Possibly also an 
instrumented variant of systemfonts.


Best
Tomas



Best,
Hiroaki Yutani

2021年12月16日(木) 23:57 Uwe Ligges :



On 16.12.2021 15:34, Sebastian Meyer wrote:

Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:

Hi,

My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.

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

It seems the problem is that there is no available font that meets the
condition in the following code. Is it irrational to assume at least
one TrueType or OpenType font is installed in the system?

  available_fonts <- systemfonts::system_fonts()$path

  # string2path supports only TrueType or OpenType formats
  ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$",
available_fonts)]


The machine that is running " r-devel-windows-x86_64-new-UL" is a
freshly installed Windows Server 2022 with GUI. The standard fonts are
available, but no extra fonts isntalled.

To confirm:

  > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts")))

dat fon ini ttc ttf xml
1 192   1  16 127   1


So there are 127 *.ttf files installed, but systemfonts::system_fonts()
does not find any of these.

Best,
Uwe Ligges






This would be an empty character vector on my Alpine Linux server as
well. The system_fonts() there only contain ".pcf.gz" files from
"/usr/share/fonts/misc/".

Note that the "systemfonts" package on which you rely currently also
fails on that CRAN check flavour for a similar reason
(https://cran.r-project.org/web/checks/check_results_systemfonts.html).
On my Alpine Linux system, from example("register_font",
package="systemfonts"):

fonts <- system_fonts()
plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
## Error in sample.int(length(x), size, replace, prob) :
##   invalid first argument

(as there are no italic fonts).

HTH,

  Sebastian Meyer


I'm wondering if I need to release a new version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.

Any suggestions?

Best,
Hiroaki Yutani

__
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


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

Re: [R-pkg-devel] New CRAN checks on r-devel-windows-x86_64-new-UL and the installed fonts

[Tomas Kalibera]

On 12/16/21 5:16 PM, Hiroaki Yutani wrote:

Thanks for the details and the suggestions. My package uses
systemfonts package for illustration purposes only in the examples, so
I'm not that desperate to find the root cause this time. I'll try
using winbuilder in case I need to.


I see. Maybe best then making the example more robust when no fonts are 
found, on different platforms.


Best
Tomas



Best,
Hiroaki Yutani

2021年12月17日(金) 0:52 Tomas Kalibera :



On 12/16/21 4:17 PM, Hiroaki Yutani wrote:

This would be an empty character vector on my Alpine Linux server as
well.

I see, thanks for the information. Sorry for my lack of consideration on this.


So there are 127 *.ttf files installed, but systemfonts::system_fonts()
does not find any of these.

Thanks for investigating quickly! Then, it seems I should wait for the
problem to be solved on systemfonts' side. I'm curious what's the
difference between r-devel-windows-x86_64-new-TK, on which the check
doesn't fail, by the way.

It is also Windows Server 2022 with GUI, a quite fresh installation. The
checks run in a docker container (also WS2022,
mcr.microsoft.com/windows/server:ltsc2022, without any manually
installed fonts).

Actually there is no manually installed software there, all that is
installed is (in this order):

https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt/r/setup_miktex_standalone.ps1
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r/setup.ps1
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/setup_checks.ps1

plus R and R packages.

I assume you can reproduce on Winbuilder, and so perhaps you could
create a version of your package with a lot of instrumentation/print
messages and submit there to find the cause? Possibly also an
instrumented variant of systemfonts.

Best
Tomas


Best,
Hiroaki Yutani

2021年12月16日(木) 23:57 Uwe Ligges :


On 16.12.2021 15:34, Sebastian Meyer wrote:

Am 16.12.21 um 15:06 schrieb Hiroaki Yutani:

Hi,

My package is failing on CRAN check on r-devel-windows-x86_64-new-UL.

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

It seems the problem is that there is no available font that meets the
condition in the following code. Is it irrational to assume at least
one TrueType or OpenType font is installed in the system?

   available_fonts <- systemfonts::system_fonts()$path

   # string2path supports only TrueType or OpenType formats
   ttf_or_otf <- available_fonts[grepl("\\.(ttf|otf)$",
available_fonts)]


The machine that is running " r-devel-windows-x86_64-new-UL" is a
freshly installed Windows Server 2022 with GUI. The standard fonts are
available, but no extra fonts isntalled.

To confirm:

   > table(gsub(".*\\.(.{3})$", "\\1", dir("c:/WIndows/fonts")))

dat fon ini ttc ttf xml
 1 192   1  16 127   1


So there are 127 *.ttf files installed, but systemfonts::system_fonts()
does not find any of these.

Best,
Uwe Ligges






This would be an empty character vector on my Alpine Linux server as
well. The system_fonts() there only contain ".pcf.gz" files from
"/usr/share/fonts/misc/".

Note that the "systemfonts" package on which you rely currently also
fails on that CRAN check flavour for a similar reason
(https://cran.r-project.org/web/checks/check_results_systemfonts.html).
On my Alpine Linux system, from example("register_font",
package="systemfonts"):

fonts <- system_fonts()
plain <- sample(which(!fonts$italic & fonts$weight <= 'normal'), 1)
bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
## Error in sample.int(length(x), size, replace, prob) :
##   invalid first argument

(as there are no italic fonts).

HTH,

   Sebastian Meyer


I'm wondering if I need to release a new version to avoid this test
failure. Note that, the other Windows r-devel machine
(r-devel-windows-x86_64-new-TK) doesn't fail. So, it might be just
that something is wrong with r-devel-windows-x86_64-new-UL.

Any suggestions?

Best,
Hiroaki Yutani

__
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


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

Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Tomas Kalibera]

On 12/21/21 5:40 PM, Ezra Tucker wrote:

Hi R package developers,


I'm developing an R package that wraps NREL's SSC library
(https://sam.nrel.gov/), which involves including one header file and
linking to one dll. Thus far it is only tested in linux (works just fine
there) but I am having trouble building/installing on Windows.


The package name is "ssc", after it is all done compiling it says:


  > * DONE (ssc)
  > Error in inDL(x, as.logical(local), as.logical(now), ...) :
  >   unable to load shared object
'C:/Users/EZRATU~1/AppData/Local/Temp/RtmpSaKZH0/pkgload13b41ff33604/ssc.dll':
  >   LoadLibrary failure:  The specified procedure could not be found.
  > Calls: suppressPackageStartupMessages ...  -> load_dll ->
library.dynam2 -> dyn.load -> inDL
  > Execution halted
  >
  > Exited with status 1.


My Makevars.win file, if useful, looks like:

PKG_CPPFLAGS=-I. -I"$C:/SAM/2021.12.02/runtime"
PKG_LIBS=-Wl,-rpath,$C:/SAM/2021.12.02/x64 -L"$C:/SAM/2021.12.02/x64" -lssc

the second includes is to pick up sscapi.h which is a necessary header
file for using this library,

The package relies heavily on Rcpp; My full sessionInfo() is:

R version 4.1.2 (2021-11-01)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
   [1] Rcpp_1.0.7    rstudioapi_0.13   magrittr_2.0.1 usethis_2.1.5
   [5] devtools_2.4.3    pkgload_1.2.4 R6_2.5.1 rlang_0.4.12
   [9] fastmap_1.1.0 fansi_0.5.0   tools_4.1.2 pkgbuild_1.3.0
[13] sessioninfo_1.2.2 utf8_1.2.2    cli_3.1.0 withr_2.4.3
[17] ellipsis_0.3.2    remotes_2.4.2 rprojroot_2.0.2 tibble_3.1.6
[21] lifecycle_1.0.1   crayon_1.4.2  processx_3.5.2 purrr_0.3.4
[25] callr_3.7.0   vctrs_0.3.8   fs_1.5.2 ps_1.6.0
[29] testthat_3.1.1    memoise_2.0.1 glue_1.6.0 cachem_1.0.6
[33] pillar_1.6.4  compiler_4.1.2    desc_1.4.0 prettyunits_1.1.1
[37] pkgconfig_2.0.3

and I have rtools40 installed in C:\rtools40. --no-multiarch is

I read on the internet in various places that this could have something
to do with 64 vs 32-bit architecture, but everything looks like it's
targeting a 64-bit architecture and the DLL I'm linking to is 64-bit.


I see these potential problems:

You cannot have your package named "ssc" if ssc.dll is also the name of 
the external DLL you are linking, because you cannot have two different 
DLLs with the same name linked to a process.


-rpath does not work on Windows. You need to have the directory with the 
external DLL on PATH for Windows to find that DLL.


Then I am not sure why you have the dollar sign in the paths, why not 
"C:/...".


You can have a look at CRAN package Rblpapi which is using an external DLL.

Best
Tomas





Any ideas? Thanks so much!

-Ezra

__
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] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Tomas Kalibera]

On 12/23/21 4:52 PM, Ezra Tucker wrote:

Hi Tomas and Dirk,


Thanks for your suggestions! Between the two, got it working. I didn't
know Windows didn't do rpath, I think that you're right that setting the
PATH would have helped. I haven't seen that in an R package before, so I
did what was in the Rblpapi package, which was creating a couple of
copies of the dll in question.
Well it is very exceptional that packages link to an external DLL, only 
very few CRAN packages do (another example is packages linking to JAGS). 
I know about these as some of them caused trouble with staged 
installation and other with the switch to UCRT, they certainly make 
maintaining and improving R harder. They typically won't work correctly 
with encodings on Windows. The C++ interface is particularly tricky and 
fragile. So, one thing is getting this to work in your package you need 
another question is whether at all it should be published on CRAN, and 
if that was your plan that'd be best discussed with the CRAN repository 
maintainers. In some cases there is no other way thank linking to an 
external DLL, but the question is always whether such package should be 
on CRAN.

On a related note, in Rblpapi Makevars.win line 47 it's downloading and
extracting the compiled library from GitHub. My understanding is that
one shouldn't include pre-compiled libraries in R packages for security
reasons, at least not for submitting to CRAN. Is doing it this way a
good way around that?


No, those concerns apply and are unrelated in principle to using an 
external DLL. My understanding is that this was also an exception 
discussed with the CRAN repository maintainers, but I don't know the 
case specifically.


Best
Tomas





Thanks again!

-Ezra


On 12/23/21 09:34, Dirk Eddelbuettel wrote:

On 23 December 2021 at 11:07, Tomas Kalibera wrote:
| You can have a look at CRAN package Rblpapi which is using an external DLL.

Yes with one big caveat: You have to make sure the library follows what is
the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
library covering the wider underlying library and offered via a wider header.

Only C linkage works across different compiler families. You just cannot use
a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.

But you can use C linkage.  So some libraries (such as the Bloomberg API used
in Rblpapi and the TileDB API used in the tiledb package (when not using a
local build) can use a library following the hourglass pattern:

   - "wide" bottom layer (may be C++ or C) with the core implementation

   - "narrow" C layer accessing the bottom and priving an API providing via C
 which profits from C's portable foreign function interface

   - "wide" layer on top via a header-only C++ file accesssing the C and
 which the C++ compiler optimizes away so that the C API is used for linking

Sounds complicated, but works great.

Good detail is in a hour-long but not-too-technical talk here

   https://www.youtube.com/watch?v=PVYdHDm0q6Y

and slides etc are here

   
https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs

Dirk

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


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

Re: [R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Tomas Kalibera]

On 12/27/21 4:04 PM, Ezra Tucker wrote:

Hi Tomas,


Thanks again for all your great info. One last question- and maybe it's
a stupid one. You mention the JAGS package-- I've been using xml2 as my
kind-of template. Installing it on linux for example will fail unless
you have the libxml2-dev package installed (at least for debian-based),
whereas for windows it just goes and downloads the dll as part of the
install process. Why would/should this package NOT just perform this
action for linux as well (namely, automatically download the precompiled
.so from somewhere else and package it in so you don't need root
privileges to install the package)? Is this just a difference in install
philosophy between linux and windows?


Hi Ezra,

Dirk responded in detail re Unix.

On Windows, static libraries (not dynamic) are used by R and are part of 
the toolchain (Rtools42 for R-devel and R 4.2), you just link the 
libraries from there via PKG_LIBS in your Makevars.ucrt or Makevars.win 
file. See for example rgdal for the recommended way how to do this, and 
[1] for a description.


Best
Tomas

[1] https://developer.r-project.org/WindowsBuilds/winutf8/ucrt3/howto.html




Thanks again!

-Ezra

On 12/23/21 17:20, Tomas Kalibera wrote:

On 12/23/21 4:52 PM, Ezra Tucker wrote:

Hi Tomas and Dirk,


Thanks for your suggestions! Between the two, got it working. I didn't
know Windows didn't do rpath, I think that you're right that setting the
PATH would have helped. I haven't seen that in an R package before, so I
did what was in the Rblpapi package, which was creating a couple of
copies of the dll in question.

Well it is very exceptional that packages link to an external DLL, only
very few CRAN packages do (another example is packages linking to JAGS).
I know about these as some of them caused trouble with staged
installation and other with the switch to UCRT, they certainly make
maintaining and improving R harder. They typically won't work correctly
with encodings on Windows. The C++ interface is particularly tricky and
fragile. So, one thing is getting this to work in your package you need
another question is whether at all it should be published on CRAN, and
if that was your plan that'd be best discussed with the CRAN repository
maintainers. In some cases there is no other way thank linking to an
external DLL, but the question is always whether such package should be
on CRAN.

On a related note, in Rblpapi Makevars.win line 47 it's downloading and
extracting the compiled library from GitHub. My understanding is that
one shouldn't include pre-compiled libraries in R packages for security
reasons, at least not for submitting to CRAN. Is doing it this way a
good way around that?

No, those concerns apply and are unrelated in principle to using an
external DLL. My understanding is that this was also an exception
discussed with the CRAN repository maintainers, but I don't know the
case specifically.

Best
Tomas



Thanks again!

-Ezra


On 12/23/21 09:34, Dirk Eddelbuettel wrote:

On 23 December 2021 at 11:07, Tomas Kalibera wrote:
| You can have a look at CRAN package Rblpapi which is using an external DLL.

Yes with one big caveat: You have to make sure the library follows what is
the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
library covering the wider underlying library and offered via a wider header.

Only C linkage works across different compiler families. You just cannot use
a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.

But you can use C linkage.  So some libraries (such as the Bloomberg API used
in Rblpapi and the TileDB API used in the tiledb package (when not using a
local build) can use a library following the hourglass pattern:

 - "wide" bottom layer (may be C++ or C) with the core implementation

 - "narrow" C layer accessing the bottom and priving an API providing via C
   which profits from C's portable foreign function interface

 - "wide" layer on top via a header-only C++ file accesssing the C and
   which the C++ compiler optimizes away so that the C API is used for 
linking

Sounds complicated, but works great.

Good detail is in a hour-long but not-too-technical talk here

 https://www.youtube.com/watch?v=PVYdHDm0q6Y

and slides etc are here

 
https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs

Dirk

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


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

Re: [R-pkg-devel] cmake, Windows

[Tomas Kalibera]

Dear Matthias,

On 3/13/22 16:31, Matthias Gondan wrote:
>
> Dear Tomas,
>
> ok, I’ve seen it now; the cmake is a bit of a mess. I used the one 
> that is found on r-hub, but it points to gcc.exe in 
> c:/strawberry/perl/ etc., so using cmake just brings trouble at this 
> stage.
>
> I have now followed your advice and prepared an R package that 
> connects to an existing Installation of SWI-Prolog on the system.
>
> https://github.com/mgondan/rologlite
>
> [note that currently, it only works properly with the development tree 
> of SWI-Prolog, but they update quite often]
>
> Is is possible to submit such a package to CRAN at all? What is the 
> next step? Your advice is greatly appreciated.
>
Yes. I would say that ideally your package would work even with older 
versions of Prolog (yet possibly without lacking some features only 
available in recent versions). I don't know whether that makes sense for 
what you are doing, but that would be ideal for R users, who could then 
install SWI Prolog the usual way on their system (e.g. via Debian 
package manager, simply swi-prolog, when on Debian, and similarly on 
other systems). On Windows, they can install SWI Prolog from the 
official installer, which can be recent, but it is not good requiring 
them to update. On Linux distributions it would take longer for the 
updates to propagate.

So the package should be able to use an existing installation of SWI 
Prolog for base functionality at least and pass checks using it. Users 
wanting recent functionality requiring newer SWI Prolog could then be 
instructed to install that manually/pointer to SWI Prolog installation 
manual.

See Writing R Extensions and CRAN Repository policy for more on how to 
specify external dependencies. In short, there is SystemRequirements 
field of the package, it needs to be documented how to install the 
software, the package should not depend on a specific version of SWI 
Prolog, the package once installed should not depend on a specific 
version of SWI Prolog (so that binary R packages can be provided).

If this is not possible and you need a new version of SWI Prolog on all 
systems, newer than normally available, perhaps best to write to CRAN 
and ask there about this specific case.

Best
Tomas

> Best wishes,
>
> Matthias
>
> *Von: *Tomas Kalibera <mailto:tomas.kalib...@gmail.com>
> *Gesendet: *Montag, 7. März 2022 10:45
> *An: *Simon Urbanek <mailto:simon.urba...@r-project.org>; 
> matthias-gondan <mailto:matthias-gon...@gmx.de>
> *Cc: *r-package-devel@r-project.org
> *Betreff: *Re: [R-pkg-devel] cmake, Windows
>
> On 3/6/22 21:46, Simon Urbanek wrote:
>
> > BTW: one option I forgot to mention would be to add SWI-Prolog to 
> the toolchain instead so you don't need to build it. However, I don't 
> know how tied you are to the development branch that you're using. 
> There is also the official SWI release Windows binary which may be 
> another option, but I didn't look at the details if that fits your 
> bill. I would suggest setting up the UCRT environment locally and 
> testing the different options so you can decide which is the best path 
> forward.
>
> Right, primarily the package should use an existing installation of SWI
>
> Prolog in the system. This is also required by the CRAN repository
>
> policy, see "Using external C/C++/Fortran libraries.").
>
> So if SWI Prolog official release for Windows has the necessary headers
>
> and DLLs, your R package could link to them. One example of R package
>
> doing this is rjags, dynamically linking to JAGS (though when there is a
>
> plain C interface, it is preferable as it is easier to maintain, see
>
> WRE). This would be the simplest option and you could use dynamically
>
> linked SWI Prolog.
>
> Adding a complete language runtime into an R package feels a bit odd to
>
> me, but in principle is possible. If Rtools42 libraries included a
>
> static library of SWI Prolog, your package could link to that. Rtools42
>
> doesn't include it, but in principle it could be added (Rtools42
>
> libraries themselves are built on Linux and indeed cmake is available
>
> there, some of those use it), I could help with that. This wouldn't work
>
> well if you needed to use dynamic linking.
>
> Building SWI Prolog from source included in the R package should not be
>
> needed and it won't be any easier than adding it to Rtools42. Rtools42
>
> currently doesn't have cmake ready for use (adding it is trivial via
>
> pacman, but some work and documentation would be needed to make it find
>
> the libraries).
>
> Best
>
> Tomas
>
> >
>
> > Cheers,
>
> > Simon
>
> >
>
> >

Re: [R-pkg-devel] handling of byte-order-mark on r-devel-linux-x86_64-debian-clang machine

[Tomas Kalibera]

On 4/6/22 00:02, Jeff Newmiller wrote:

Thanks to the ubiquity of Excel and its misguided inclusion of BOM codes in its UTF-8 CSV 
format, this optimism about encoding being a corner case seems premature. There are 
actually multiple options in Excel for writing CSV files, and only one of them (not the 
first one fortunately) has this "feature", but I (and various beginners I end 
up helping) seem to encounter these silly files far more frequently than seems reasonable.


I was rather referring to encoding marks in R which declare an encoding 
of an R string, that is what you see by Encoding(). And to other 
measures to avoid the problem when the native encoding in R cannot 
represent all characters users need to work with (when the native 
encoding cannot be UTF-8). From R 4.2, the native encoding will be UTF-8 
also on (recent) Windows systems; on most Unix systems, it has been 
UTF-8 for years. But this change will not impact the handling of BOMs in 
input.


Is the problem reading CSV files from Excel (even when Excel is at 
fault) reported anywhere? If not, please report, maybe there is 
something that could be done to help processing those files on the R 
side. R handles BOMs in the "connections" code, ?connections, and it 
uses iconv for input conversion.


Thanks
Tomas



On April 5, 2022 11:20:37 AM PDT, Tomas Kalibera  
wrote:

On 3/28/22 13:16, Ivan Krylov wrote:

On Mon, 28 Mar 2022 09:54:57 +0200
Tomas Kalibera  wrote:


Could you please clarify which part you found somewhat confusing,
could that be improved?

Perhaps "somewhat confusing" is an overstatement, sorry about that. All
the information is already there in both ?file and ?readLines, it just
requires a bit of thought to understand it.


When reading from a text connection, the connections code, after
re-encoding based on the ‘encoding’ argument, returns text that is
assumed to be in native encoding; an encoding mark is only added by
functions that read from the connection, so e.g.  ‘readLines’ can
be instructed to mark the text as ‘"UTF-8"’ or ‘"latin1"’, but
‘readLines’ does no further conversion.  To allow reading text in
‘"UTF-8"’ on a system that cannot represent all such characters in
native encoding (currently only Windows), a connection can be
internally configured to return the read text in UTF-8 even though
it is not the native encoding; currently ‘readLines’ and ‘scan’ use
this feature when given a connection that is not yet open and, when
using the feature, they unconditionally mark the text as ‘"UTF-8"’.

The paragraph starts by telling the user that the text is decoded into
the native encoding, then tells about marking the encoding (which is
counter-productive when decoding arbitrarily-encoded text into native
encoding) and only then presents the exception to the native encoding
output rule (decoding into UTF-8). If I'm trying to read a
CP1252-encoded file on a Windows 7 machine with CP1251 as the session
encoding, I might get confused by the mention of encoding mark between
the parts that are important to me.

It could be an improvement to mention that exception closer to the
first point of the paragraph and, perhaps, to split the "encoding mark"
part from the "text connection decoding" part:


Functions that read from the connection can add an encoding mark
to the returned text. For example, ‘readLines’ can be instructed
to mark the text as ‘"UTF-8"’ or ‘"latin1"’, but does no further
conversion.

When given a connection that is not yet open and has a non-default
‘encoding’ argument, ‘readLines’ and ‘scan’ internally configure the
connection to read text in UTF-8. Otherwise, the text after decoding
is assumed to be in native encoding.

(Maybe this is omitting too much and should be expanded.)

It could also be helpful to mention the fact that the encoding argument
to readLines() can be ignored right in the description of that
argument, inviting the user to read the Details section for more
information.

Thanks for the suggestions, I've rewritten the paragraphs, biasing
towards users who have UTF-8 as the native encoding as this is going to
be the majority. These users should not have to worry much about the
encoding marks anymore, nor about the internal UTF-8 mode of the
connections code. But the level of detail I think needs to remain as
long as these features are supported - the level of detail is based on
numerous questions and bug reports.

Best
Tomas

__
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] Changing optimization level when building package?

[Tomas Kalibera]

On 7/5/22 16:11, Ivan Krylov wrote:

On Tue, 5 Jul 2022 09:35:05 -0400
Duncan Murdoch  wrote:


I see the -O0 option that I added, but afterwards -O2 coming from
somewhere in R.

It seems to come from the CXXFLAGS macro defined in /etc/R/Makeconf.
It's the last to be added to ALL_CXXFLAGS, so you probably have to
overwrite it in ~/.R/Makevars.

Yes. I set both CFLAGS and CXXFLAGS in my Makevars_dbg0 file and let R 
use it via R_MAKEVARS_USER.

See R-Admin, 6.3.3, Customizing package compilation, for more.

Tomas

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

Re: [R-pkg-devel] package stuck in CRAN 'pretest' for a day

[Tomas Kalibera]

On 7/15/22 14:50, Georgi Boshnakov wrote:

Submitted package 'fGarch' has been stuck in CRAN 'pretest' for about 24 hours 
now. The same seems to hold for several other packages. Is this something that 
can be expected normally?

The pretest service seems to work normally in that other packages come and go.


My guess is it is because of a problem in R-devel, the development 
version of R, which has been fixed/reverted but it may take some time 
for systems to recover (82587+82589, the former tested on 
CRAN/Bioconductor packages, the latter being a hot-fix of the former, 
which unfortunately made a very large number of CRAN packages to fail). 
It is part of an attempt to fix semantics of useBytes=TRUE ([1] is 
somewhat related). Sorry for the inconvenience.


Tomas

[1] 
https://blog.r-project.org/2022/07/12/speedups-in-operations-with-regular-expressions




Thanks,
Georgi Boshnakov

[[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] About the CRAN policy on downloading pre-compiled binary

[Tomas Kalibera]

On 7/27/22 09:03, Hiroaki Yutani wrote:
> Thank you. I'll read the policy again more carefully.
>
> > but you are not downloading sources.
>
> The case is that, I include the Rust source code, but since the CRAN's 
> Windows & macOS machines don't have the Rust compiler installed, 
> there's no choice but to download the pre-compiled binary (other than 
> downloading the Rust compiler).

I'd say at least check whether the compiler is present (during package 
installation), and use it if it is. Only if you want to download 
binaries as a last resort when it isn't, consult that first with the 
CRAN team. Perhaps it could also be a hard dependency for installing the 
package, and perhaps Rust compiler would be installed on the CRAN machines.

I think it is better not to hard-code which software is installed on the 
CRAN systems, because that may change and because different software may 
be installed on user machines. However, on Windows, it is ok to expect 
that say Rtools42 is available when building packages for R 4.2 (yet 
Rtools42 don't have a rust compiler, so it doesn't help you here).

Right, downloading the source code of the Rust compiler and building it 
seems a bit too resource intensive and then, a bit too much if multiple 
R packages need it. Ideally the compiler will be installed and the R 
source packages will really be source packages (no binaries).

>
> > In either case, of course if there is anything unclear in an email from
> > CRAN, you can simply respond to that and ask.
>
> Thanks, I already responded with what I wrote above, so I hope I can 
> get the reply.
> But, since the CRAN team might be on vacation now, I wanted to get 
> some advice on this mailing list.
> Thanks for your help!

No problem, just please only regard it as my advice.

Best
Tomas

>
> Best,
> Yutani
>
> 2022年7月27日(水) 15:08 Tomas Kalibera :
>
>
> On 7/27/22 00:30, Hiroaki Yutani wrote:
> > Hi,
> >
> > Recently I got the following email from the CRAN maintainer about my
> > package, string2path[1].
> >
> > However, I do ensure the binary is the pinned version and verify
> if the
> > hash matches with the embedded one in the DESCRIPTION [2][3]. In
> case of a
> > mismatch, the build fails. So, this mechanism should ensure that
> I (or
> > anyone) cannot change the version of the binary without actually
> > resubmitting to CRAN.
>
> Please see the policy cited. Ensuring that the download is of a fixed
> version refers to the sources (which can be downloaded under the
> conditions mentioned).
>
> Downloading binaries are only a last resort option and requires the
> agreement of the CRAN team in the first place.
>
> > I believe this complies with the CRAN policy (except for not
> clearing the
> > authorship and copyright). Is there anything I have to address
> to prove I
> > do "ensure that the download is of a fixed version"? Any
> suggestions are
> > welcome.
>
> My understanding from your email is you are ensuring a fixed version
> download, and with most projects you could probably do even less
> (simply
> hardcode a URL which includes a specific version of the sources if
> that
> is stable for the project), but you are not downloading sources.
>
> In either case, of course if there is anything unclear in an email
> from
> CRAN, you can simply respond to that and ask.
>
> Best
> Tomas
>
> >
> > The CRAN policy stipulates
> >> "Where a package wishes to make use of a library not written
> solely for
> >> the package, the package installation should first look to see
> if it is
> >> already installed and if so is of a suitable version. In case
> not, it is
> >> desirable to include the library sources in the package and
> compile them
> >> as part of package installation. If the sources are too large,
> it is
> >> acceptable to download them as part of installation, but do
> ensure that
> >> the download is of a fixed version rather than the latest. Only
> as a
> >> last resort and with the agreement of the CRAN team should a
> package
> >> download pre-compiled software."
> >>
> >> and we have recently seen an instance of a rust-using package whose
> >> check output changed because what it downloaded had changed.  CRAN
> >> checking is not set up for that (for example, macOS checks are
> done once
> &g

Re: [R-pkg-devel] About the CRAN policy on downloading pre-compiled binary

[Tomas Kalibera]

On 7/27/22 08:08, Tomas Kalibera wrote:


On 7/27/22 00:30, Hiroaki Yutani wrote:

Hi,

Recently I got the following email from the CRAN maintainer about my
package, string2path[1].

However, I do ensure the binary is the pinned version and verify if the
hash matches with the embedded one in the DESCRIPTION [2][3]. In case 
of a

mismatch, the build fails. So, this mechanism should ensure that I (or
anyone) cannot change the version of the binary without actually
resubmitting to CRAN.


Please see the policy cited. Ensuring that the download is of a fixed 
version refers to the sources (which can be downloaded under the 
conditions mentioned).


Downloading binaries are only a last resort option and requires the 
agreement of the CRAN team in the first place.


I believe this complies with the CRAN policy (except for not clearing 
the
authorship and copyright). Is there anything I have to address to 
prove I

do "ensure that the download is of a fixed version"? Any suggestions are
welcome.


My understanding from your email is you are ensuring a fixed version 
download, and with most projects you could probably do even less 
(simply hardcode a URL which includes a specific version of the 
sources if that is stable for the project), but you are not 
downloading sources.


I take back the comment about doing less to ensure a fixed version - it 
is good to use a hash always when having to download sources, as 
software distributions do (of course including MXE and Msys2, so Rtools 
on Windows, etc). It is better as a guard against that the content is in 
fact not stable for the project (I've been told it sometimes happens and 
may be surprising to package authors), but of course also for security 
reasons.


Tomas


In either case, of course if there is anything unclear in an email 
from CRAN, you can simply respond to that and ask.


Best
Tomas



The CRAN policy stipulates

"Where a package wishes to make use of a library not written solely for
the package, the package installation should first look to see if it is
already installed and if so is of a suitable version. In case not, 
it is
desirable to include the library sources in the package and compile 
them

as part of package installation. If the sources are too large, it is
acceptable to download them as part of installation, but do ensure that
the download is of a fixed version rather than the latest. Only as a
last resort and with the agreement of the CRAN team should a package
download pre-compiled software."

and we have recently seen an instance of a rust-using package whose
check output changed because what it downloaded had changed. CRAN
checking is not set up for that (for example, macOS checks are done 
once

only for each version).

Whilst investigating, the Windows' maintainers found that binary libs
were being downloaded.  And subsequently I found that salso, 
string2path

and ymd are downloading compiled code on Intel macOS.

Also. make sure that the authorship and copyright of code you download
(and hence include in the package) is clear from the DESCRIPTION file.
as required by the CRAN policy.


Best,
Hiroaki Yutani

[1]: https://cran.r-project.org/package=string2path
[2]:
https://github.com/cran/string2path/blob/46020296410cd78e2021bff86cb6f17c681d13a6/DESCRIPTION#L29-L40 


[3]:
https://github.com/cran/string2path/blob/46020296410cd78e2021bff86cb6f17c681d13a6/tools/configure.R#L177-L295 



[[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] Unable to create manual

[Tomas Kalibera]

On 9/16/22 20:17, Edward Wei wrote:

That is an interesting thought. I don't think I have downloaded LaTex
explicitly, however, I do have MikTex and I added that file to PATH
manually.

This is what my current PATH calls:
"c:/rtools42/x86_64-w64-mingw32.static.posix/bin;c:/rtools42/usr/bin;C:\\Program
Files\\R\\R-4.2.0\\bin\\x64;C:\\Program Files (x86)\\Common
Files\\Oracle\\Java\\javapath;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\WINDOWS\\System32\\OpenSSH\\;C:\\Program
Files\\Wolfram Research\\WolframScript\\;C:\\Program
Files\\Git\\cmd;C:\\Users\\edmon\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\edmon\\AppData\\Local\\GitHubDesktop\\bin;C:\\Users\\edmon\\AppData\\Local\\Programs\\MiKTeX\\miktex\\bin\\x64\\;C:/Program
Files/RStudio/bin/quarto/bin"

I have been able to generate a PDF of my package by entering :
tools::texi2pdf(file = "avfintools.Rcheck/avfintools-manual.tex")
on the console.

Is there a way to submit the manual manually rather than have it compiled?
Or is it a requirement for the manual to be able to be compiled from the
package?

Thanks for your help,


MikTeX is fine and common choice and works with R.

R Admin manual has "Installing R under Windows" with more details there 
and in the linked documents, including

Howto: Building R 4.2 and packages on Windows.

There must be something special set up on your system that probably only 
debugging could reveal. Possibly some customization in any of the R 
startup files. Or some conflicting tool on the PATH (e.g. in Git?).


Tomas



On Wed, Sep 14, 2022 at 3:14 PM Uwe Ligges 
wrote:



On 14.09.2022 23:54, Duncan Murdoch wrote:

On 12/09/2022 9:09 a.m., Edward Wei wrote:

This is the following error message I get from R CMD check:

LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without index ... ERROR
Re-running with no redirection of stdout/stderr.
Hmm ... looks like a package
Converting parsed Rd's to LaTeX ...
Creating pdf output from LaTeX ...
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet =
quiet,  :
pdflatex is not available

This looks like a problem in the way tools::texi2dvi detects pdflatex.
If you have a valid LaTeX file, try running

tools::texi2dvi(filename, pdf = TRUE)

If that gives the same message, then debug(tools::texi2dvi), and repeat,
single stepping through the function to see what test it uses, and
figure out why it fails on your system.

Or the env var PATH is overwritten once R get started, perhaps you have
it in one of the files R process it at startup?
Does Sys.getenv("PATH") show the pat to the LaTeX binary?

Best,
Uwe Ligges



Duncan Murdoch



Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet =
quiet,  :
pdflatex is not available
Error in running tools::texi2pdf()
You may want to clean up by 'rm -Rf
C:/Users/edmon/AppData/Local/Temp/RtmpWkD7Iy/Rd2pdf35d81e3e188c'
* DONE

Status: 1 ERROR, 1 WARNING, 2 NOTEs


Then, I tried debugging by isolating errors from the Rd to PDF
conversion.


C:\Users\edmon\Documents\R\RFIN> R CMD Rd2pdf avfintools --no-clean
Hmm ... looks like a package
Converting Rd files to LaTeX ...
Creating pdf output from LaTeX ...
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet =
quiet,  :
pdflatex is not available
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet =
quiet,  :
pdflatex is not available
Error in running tools::texi2pdf()
You may want to clean up by 'rm -Rf .Rd2pdf27964'


In this folder is the file Rd2.tex which I tried to complie into a
pdf. But
this error returns and PDF cannot be compiled. :


LaTeX Error: File `Rd.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name:
! Emergency stop.


l.4 \usepackage
 {makeidx}^^M
==> Fatal error occurred, no output PDF file produced!


Thanks for your help,

 [[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

[[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] R-devel cannot install my package

[Tomas Kalibera]

On 9/28/22 00:50, Bailey, Paul wrote:

Hi,

I'm trying to update WeMix on CRAN and when I use R-devel (2022-09-26 r82921 
ucrt) to R CMD check --as-cran R-devel will not install the package. This is 
the log file

[snip]
** testing if installed package can be loaded from temporary location
*** arch - i386
Error in .makeMessage(..., domain = domain) :
   3 arguments passed to .Internal(gettext) which requires 2
Calls: .OptRequireMethods
Execution halted
[snip]

This looks like not a problem with my package. Is this a known problem? Also, I 
get this with R-devel on my currently on CRAN version and CRAN itself does not 
show this.


Right, doesn't seem like a problem with your package, but probably with 
your setup. To be sure the package is ok, you can use the Winbuilder 
service first to check the package, and if it checks fine, only then 
start debugging your setup.


For me checking the CRAN version of your package on R-devel on Windows 
works fine, using "R CMD check" all with defaults.


R-devel (as well as R 4.2) no longer supports 32-bit targets so the 
"arch - i386" above looks suspicious. A mismatch in the number of 
arguments to an internal function may suggest that some parts of your 
installation are outdated. Perhaps if you start with an empty package 
library, the problem would go away?


Best,
Tomas



Best,
Paul Bailey

__
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] Rcmd check skip example

[Tomas Kalibera]

On 1/19/23 05:00, mai zhou wrote:

Hi,

In the process of adding examples to the .RD file, I noticed
Rcmd check seems to skip certain example code.

I put my example code  x%*%y%*%z  (matrix multiplication) in the
RD file. After running Rcmd check
(on windows) and look into the xxx.Rcheck directory,
   xxx-EX.ROUT  file, it seems that the example check stopped
  at x (i.e. everything after % sign is ignored, like LaTeX).

That seems like a bug. Can anyone confirm on newer version?

Mine:


sessionInfo()

R version 4.1.2 (2021-11-01)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 22621)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.1.2emplikAUC_0.3 rootSolve_1.8.2.3 emplik2_1.32

Mm... I have Win11, why the sessionInfo() say W10 ?  (but that is something
else)


R 4.1.0 was released before Windows 11, but even in R-devel, 
sessionInfo() reports "Windows 10" on "Windows 11". The problem is that 
the information comes from win.version()/GetVersionEx() and, as also 
documented in ?win.version, this may return "compatibility version".


With the already released versions of R and current R-devel, one can 
tell Windows 11 from the build number (your 22621 is Windows 11 22H2, 
22000 is Windows 11 21H2).


Thanks for spotting and reporting this.

Tomas



best,

Mai Zhou

[[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] strange errors (non-ascii symbols) on win-builder R-devel

[Tomas Kalibera]

On 1/23/23 17:30, Maxim Nazarov wrote:

Hello all,

I am submitting a minor update to one of my CRAN package (BIGL), and get 
strange errors on R-devel on win-builder - 
https://win-builder.r-project.org/incoming_pretest/BIGL_1.6.7_20230119_225109/Windows/00check.log
 and https://win-builder.r-project.org/o339zPAR6pWG/00check.log (different 
symbols)

It shows strange output like "`1Y���hA�..." before tests and cryptic error-messages like "unable to 
translate '(m' to a wide string"
I can also see similar output in examples - 
https://win-builder.r-project.org/o339zPAR6pWG/examples_and_tests/BIGL-Ex.Rout


These are errors and warnings in regex operations (grep, gsub) due to 
that the input data is not a valid string (validly encoded string). 
Because it is not valid, it cannot be converted to a wide string, which 
is needed for the regex operation, as this uses TRE.


So, you need to find out why the input strings are invalid. Common 
causes of such problems are that they are in a different encoding from 
the one told to R or to some other software on the way. Also the data 
may be corrupted.



I don't get any isses on debian R-devel, on R-release on windows, and also 
can't reproduce the errors locally on a windows machine with R-devel, so I am a 
bit lost.
Would anyone have any idea of what goes wrong?


It should be fairly easy from the error output to find out which 
operations have failed in the vignette. Perhaps you could find out how 
their inputs were generated.


If you have a Windows machine with R running in UTF-8 as the native 
encoding, with recent R-devel, and the error is still not reproducible, 
try to confirm that the inputs for the failing operations are correct.


Best
Tomas



Kind regards,
Maxim Nazarov

__
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] If you had to choose one binary to preserve for a pkg, which would it be?

[Tomas Kalibera]

On 1/22/23 22:36, Uri Simonsohn wrote:

This is not a perfect list for this question, but possibly a good list.

I think this is a good match.

I maintain 'groundhog', a package that seeks to simplify reproducibility
of R code based on R packages.
It has so far relied on MRAN  for binaries of older/archived versions of
packages, but MRAN is shutting down.
Posit (R Studio) also has archived binaries, but they are less
transparent about it,  they do not have Mac binaries, and I am a little
uncomfortable relying on a 3rd party again, specially because their
archive is more difficult to navigate and this is part of a for-profit
venture so access is far from guaranteed. So...

I will create an independent archive of all binaries for packages for
Windows and Mac machines.

Instead of having daily backups like MRAN does/did, i will keep just one
binary per combination of package, version, R version, operating system.
So a single 'rio' 0.5.0 binary for Windows for R-4.2.x, for example
(MRAN keeps a daily copy of such file instead, possibly with 100+
identical or nearly identical copies).

I need to decide whether to keep the first binary that was uploaded to
CRAN, the last one, or one in the middle, etc.
In  concept binaries should work regardless of which file is chosen, but
there is a reason, i guess they are rebuilt so often so it may make a
difference in the margin which of the many builts available in MRAN is
chosen to be preserved. I think it has to do with changes in underlying
packages used to build them, but am not sure.
This decision will also guide future archiving, which of the many
versions of to be uploaded to CRAN binaries are preserved.


I think the date-based snapshots made sense, that corresponded to how 
packages were tested and built together. I am afraid you cannot get 
close to that by choosing a single version. If you really must use only 
one, probably the latest.


If I wanted some reasonably reliable repeatability of computations, I 
would though keep a virtual machine snapshot with the matching OS, 
matching version of R, the packages installed (probably from source in 
case debugging became needed), and all external dependencies. Ideally 
with disconnected network to make sure the computation works fully 
locally, and as I would not be updating the OS, for security as well. I 
would keep that snapshot intact - never save the machine state again to 
it. And if possible convert it to several image formats just in case the 
virtualization software stops being supported or no longer can read 
certain formats.


Tomas



So, if you have experience or knowledge on this, which of the many
previously created binaries for a given package version would you choose
to archive long-term?
Groundhog will always attempt to install from source if a binary fails,
so a certain error rate is tolerable.

Uri

--

Uri Simonsohn (urisohn.com)

Professor of Behavioral Science, ESADE, Barcelona

Senior Fellow, Wharton School, University of Pennsylvania

Blog at:  DataColada.org 

Easy data sharing: ResearchBox.org

Twitter: @uri_sohn




[[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] Inconsistent R CMD Check results

[Tomas Kalibera]

On 1/23/23 17:51, Ying Li via R-package-devel wrote:

Dear all,

Hope you are well! Recently, in the check before a re-submission, I got an unexpected note 
when doing R CMD Check using rhub::check_for_cran(), saying that "Examples with CPU 
(user + system) or elapsed time > 5s".

I didn't expect this note to appear because the same examples didn't cause this 
note in the previous submission last December. Compared with the previous 
submission, we only edited documentation, there was no change in the R code for 
functions of our package.

To double-check, I downloaded our previous submission from CRAN and checked it 
again. It's strange that this current CRAN version also has this note now. 
However, when submitting it last December, there were no such notes. Do you 
have any idea why the R CMD Check results are inconsistent?


You could check on Winbuilder as that is a concrete setup used for 
incoming checks. But in principle, the computation may take longer 
because of changes in dependencies, external software and R. Which can 
be due to a performance regression, a bugfix, etc. Only 
debugging/profiling could reveal the true cause.



Since the examples caused no note in the last submission and were successfully 
submitted to CRAN, I'm not sure whether I should change the examples in this 
re-submission to eliminate this sudden note. Any suggestions will be 
appreciated!
If you were close to the limit last time, it may be a coincidence and 
you might simply reduce the examples to be on the safe side.


Tomas



Thank you!
Ying

[[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] Unable to load Windows NETIO.SYS and WINSPOOL.DRV DLLs

[Tomas Kalibera]

On 2/12/23 17:37, David Sterratt wrote:

On Sat, 2023-02-11 at 18:11 +0300, Ivan Krylov wrote:

On Sat, 11 Feb 2023 11:19:42 +
David Sterratt  wrote:


WinDbg output reveals errors loading "NETIO.SYS" and "WINSPOOL.DRV"
when running "library(RGtk2)":

0c64:0640 @ 44312812 - LdrpProcessWork - ERROR: Unable to load
DLL:
"NETIO.SYS", Parent Module: "C:\Users\David
Sterratt\AppData\Local\R\win-library\4.3\RGtk2\libs\x64\RGtk2.dll",
Status: 0xc135
...
0c64:1e5c @ 44312812 - LdrpProcessWork - ERROR: Unable to load
DLL:
"WINSPOOL.DRV", Parent Module: "C:\Users\David
Sterratt\AppData\Local\R\win-library\4.3\RGtk2\libs\x64\RGtk2.dll",
Status: 0xc135

The failure to load WINSPOOL.DRV is perplexing (it should normally be
possible to load as it's a system DLL that applications are supposed
to
link against in order to be able to print), but NETIO.SYS should
probably be absent from the import list. At least it seems to be
linked
against some kernel-related stuff that shouldn't be reachable from
userspace applications.

By removing -lnetio from PKG_LIBS, I was able to load the package and
run some example code from the JSS article, but then Rgui.exe crashed
on exit. I'm running R-4.2.2 and Rtools43 on a Windows 7 machine,
which
could also be a source of the difference.

Thank you for looking at this. I tried removing -lnetio, but package
didn't install at all on Windows 10.


For reference, there is an old patch for RGtk2 package that I had 
created when working on Rtools42, though I am not very optimistic it 
will help in this case:


https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/old_patches/CRAN/RGtk2.diff

I've added gtk2 libraries to Rtools42 as they were needed by a CRAN 
package (RGtk2) at that time and available in MXE. Now MXE has gtk3, but 
not gtk4.


If there is a need for gtk4 in a CRAN package, the best way forward 
would be to contribute gtk4 build configuration to MXE, ideally also 
after testing it builds as part of Rtools43 (which is a subset of MXE 
but with some updates not yet upstream). We could then replace gtk2 by 
gtk4 in Rtools. CRAN servers will then get gtk4 simply via updating Rtools.


This is only what would be needed for Windows. For macOS, gtk4 would 
have to be added to the recipes. For Linux, the package should work with 
gtk4 distributions available in main distributions.


If you wanted to use gtk from a package, perhaps it would be easier to 
try directly, not via the archived RGtk2 package.


Best
Tomas



Does the Dependency Walker  provide
you
any useful information about the package DLL besides what you already
know? (Some warnings deep in the dependency tree are to be expected.
R.DLL is not on the PATH so won't be automatically found, but other
dependencies should exist.)

I looked at the Dependency Walker, but it was giving me many messages
about missing DLLs with names like:

   API-MS-WIN-CORE-STRING-L2-1-0.DLL  Error opening file. The system
cannot find the file specified (2).

These libraries seem to be part of the UCRT system. However, when
looked at the DLL of a package that *did* load in Dependency Walker, I
got the same messages, so I think the path to the UCRT files may be
missing.

Dependency Walker did seem to find:

   c:\windows\system32\WINSPOOL.DRV

For NETIO.SYS it gave the " Error opening file. The system cannot find
the file specified (2)." There was also this table in the output.

  [ ? ] NETIO.SYS

   Import  Ordinal  Hint  FunctionEntry
Point
   --  ---    --  --
-
   [CE ]   N/A4 (0x0004)  CancelMibChangeNotify2  Not
Bound
   [CE ]   N/A   79 (0x004F)  GetIpForwardTable2  Not
Bound
   [CE ]   N/A  364 (0x016C)  NotifyRouteChange2  Not
Bound
   [CE ]   N/A  529 (0x0211)  if_nametoindex  Not
Bound

If you're really interested, I can send you the output, but from what
Uwe says, I'm wondering if this is a lost cause!

Best wishes,

David.


--
David Sterratt, Lecturer https://www.ed.ac.uk/profile/sterratt
Institute for Adaptive and Neural Computation tel: +44 131 651 1739
School of Informatics, University of Edinburgh
Appleton Tower, 11 Crichton Street, Edinburgh EH8 9LE, Scotland
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
BOOK: Principles of Computational Modelling in Neuroscience
Sterratt, Graham, Gillies & Willshaw (CUP, 2011).
http://www.compneuroprinciples.org



The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh 
Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


__
R-pack

Re: [R-pkg-devel] Unable to load Windows NETIO.SYS and WINSPOOL.DRV DLLs

[Tomas Kalibera]

On 2/14/23 13:26, David Sterratt wrote:

On Mon, 2023-02-13 at 19:08 +0100, Tomas Kalibera wrote:

For reference, there is an old patch for RGtk2 package that I had
created when working on Rtools42, though I am not very optimistic it
will help in this case:

https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/old_patches/CRAN/RGtk2.diff

Many thanks. I've not tried this patch yet, but it looks like it's not
made the development version of RGtk2, which is what I had been working
with. I will try out the archived RGtk2_2.20.36.3.tar.gz


Yes, it was for the CRAN version (when it was still on CRAN). It is very 
likely you would have to manually update the list of libraries to link 
in this complicated case, after what you get from the script. As it was 
well illustrated also by Ivan's findings.



I've added gtk2 libraries to Rtools42 as they were needed by a CRAN
package (RGtk2) at that time and available in MXE. Now MXE has gtk3,
but
not gtk4.

If there is a need for gtk4 in a CRAN package, the best way forward
would be to contribute gtk4 build configuration to MXE, ideally also
after testing it builds as part of Rtools43 (which is a subset of MXE
but with some updates not yet upstream). We could then replace gtk2
by
gtk4 in Rtools. CRAN servers will then get gtk4 simply via updating
Rtools.

This is only what would be needed for Windows. For macOS, gtk4 would
have to be added to the recipes. For Linux, the package should work
with
gtk4 distributions available in main distributions.

This is helpful to know, as it suggests that if RGtk2 could be updated
to work with Gtk4, installed into MXE, and if the Mac recipies could be
updated, the changes RTools might be accepted, and then RGtk2 (perhaps
renamed RGtk4) might be uploadable to CRAN.

 From this message, and Uwe's it's clear that the long-term future of
RGtk2 depends on an update to Gtk4, and I've asked the maintainer about
what the prospects of that might be:
https://github.com/lawremi/RGtk2/issues/12


In principle it is easy to add any open-source software with a 
compatible license, but someone has to volunteer to do the work of 
adding it to and maintaining it in the software distributions used, and 
of persuading the maintainers of those distributions to accept it.


Tomas



Best wishes,

David
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh 
Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.


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

Re: [R-pkg-devel] Sanitize Input Code for a Shiny App

[Tomas Kalibera]

On 3/1/23 07:35, Matthias Gondan wrote:

For the record, here's the documentation of the Prolog sandbox,

https://www.swi-prolog.org/pldoc/doc/_SWI_/library/sandbox.pl

You get an idea of the implementation by clicking at the ":-" icons. It does 
not seem too complicated, but I might be too optimistic. It would be very nice to have 
such a thing in R, and I would be willing to help if someone takes the lead.


From my (very quick) look at the page, my understanding is that it is 
analyzing Prolog code to decide whether it is safe to execute or not. If 
my reading is correct, please let me reiterate that this would not be a 
good strategy for R. As Simon already wrote, R is a very dynamic 
language allowing to change almost anything at runtime. It is not 
possible to correctly and effectively reason about what an R program 
could do. Trying to do this would be a waste of effort which might only 
provide false sense of security. R cannot be made safe for such uses 
this way. While enough as a show stopper, it is more than that, R 
doesn't have a specification, any such tools would have to be written 
against a specific R release. Also, in practice one would probably also 
want to use some extension packages, which may again do anything (in 
native code).


With R, I would only think of ensuring security at the machine level, as 
discussed already - via virtual machines, containers (with care, not all 
are sandboxes), etc. That would be much safer, much less work, and could 
re-use existing technologies.


Tomas




Best regards,

Matthias


Am 01.03.2023 um 01:52 schrieb Bill Denney :

Hi Simon and Ivan,

Thanks for confirming my suspicions.  The most common case for our code
would be generally trusted users within an organization.  So, the main
threat is lower.  But, there may be scenarios that also allow use outside
organizations.

I think that in the end, we will likely do some minimal sanitization of the
input, but then we will also ensure that we do anything in a container with
limits applied from the outside, too.

Thanks,

Bill

On Sun, Feb 26, 2023, 4:57 PM Simon Urbanek 
wrote:


Bill,

the short answer is you can't limit anything at R level. Any attempts to
create a list of "bad" commands are trivial to circumvent since you can
compute on the language in R, so you can construct and call functions with
trivial operations. Similarly, since R allows the loading of binary code
the same applies for arbitrary code. So if you give users access to R, you
should assume that is equivalent to allowing arbitrary code execution.
Therefore all you can do is limit the resources and reach - as you pointed
out using a container is a good idea so each session is only limited to a
single container that goes away when the session ends. Similarly you can
restrict main parts of R and the system to be read-only in the container.

In practice, that's why real analytic systems are about provenance rather
than prevention. For example, in RCloud all code is first committed to a
git repository outside of the container before it can be executed, so
malicious users can do whatever they want, but they cannot hide the
malicious code they used as the container cannot manipulate the history.

As for package installation - again, it's impossible to prevent it in
general unless you make everything read-only which also prevents the users
from doing meaningful work. So the real question what do you want to allow

[[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] How to identify what flags "Additional Issues" for UBSAN

[Tomas Kalibera]

On 3/22/23 16:51, Kenny, Christopher wrote:

Hi folks,

I'm the maintainer of the redist package 
(https://cran.r-project.org/web/checks/check_results_redist.html) which was flagged for 
additional issues with clang-UBSAN and gcc-UBSAN. Both of the 00check.log files say that 
the status is "OK" at the bottom.

Is there an easy way to identify what is causing the flag? I see things that it 
could be, for example in the tests Rout files, there are sanitizer errors like:
wilson.cpp:165:34: runtime error: signed integer overflow: -2147483648 * -1 
cannot be represented in type 'int'
However, my understanding is that these errors should be expected, as the input 
is controlled from within the package and checking for these types of errors in 
every loop would push against the purpose of using C++ for performance here.


UBSAN reports runtime errors, which means that the overflow has really 
happened, so this clearly should be narrowed down and fixed. I would 
restructure the code to avoid the overflow and only worry about a 
possible slowdown if that happens.


In the code pointed to by the stacktrace

    int max_try = 50 * remaining * ((int) std::log(remaining));
    while (remaining > 0) {

perhaps the problem is when "remaining" is 0 (but I am guessing, I don't 
know the code). Right, the overflow is benign because the value isn't 
used, but one should fix this anyway and it should be easy, e.g.


if (remaining > 0) {

  int max_try = ...
  while(remaining > 0)

}

this extra condition would not have a measurable overhead in this code.


That leads me to believe that either I'm looking past the seriousness of one of these 
sanitizer warnings or I am missing something else that is being flagged.  I've looked at 
Writing R Extensions part 4.3, but do not see any specific additional information on 
this. Does anyone have advice or any guidance on figuring out exactly what causes the 
"Additional Issues" flag and subsequent email about fixing it?


From the stack traces these are all instances of the same problem. If I 
were you I would simply fix that and submit.


Best
Tomas



Thank you,
Chris

cke...@g.harvard.edu - christopherke...@fas.harvard.edu
V.O. Key Fellow - Department of Government - Harvard University
Ashford Fellow - Graduate School of Arts and Sciences - Harvard University


[[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] Feedback on "Using Rust in CRAN packages"

[Tomas Kalibera]

On 7/13/23 05:08, Hiroaki Yutani wrote:

I actually use cargo vendor.

https://github.com/yutannihilation/string2path/blob/main/src/rust/vendor.sh

One thing to note is that, prior to R 4.3.0, the vendored directories hit
the Windows' path limit so I had to put them into a TAR file. I haven't
tested on R 4.3.0, but probably this problem is solved by this improvement.
So, if you target only R >= 4.3, you can just cargo vendor.

https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html


I wouldn't rely on that long paths on Windows are supported even in R >= 
4.3, because it requires at least Windows 10 1607, and it needs to be 
enabled system-wide in Windows - so, users/admins have to do that, and 
it impacts also other applications. The blog post has more details and 
recommendations.


Best
Tomas



Best,
Yutani

2023年7月13日(木) 11:50 Kevin Ushey :


Package authors could use 'cargo vendor' to include Rust crate sources
directly in their source R packages. Would that be acceptable?

Presumedly, the vendored sources would be built using the versions
specified in an accompanying Cargo.lock as well.

https://doc.rust-lang.org/cargo/commands/cargo-vendor.html


On Wed, Jul 12, 2023, 7:35 PM Simon Urbanek 
wrote:


Yutani,

I'm not quite sure your reading fully matches the intent of the policy.
Cargo.lock is not sufficient, it is expected that the package will provide
*all* the sources, it is not expected to use cargo to resolve them from
random (possibly inaccessible) places. So the package author is expected to
either include the sources in the package *or* (if prohibitive due to
extreme size) have a release tar ball available at a fixed, secure,
reliable location (I was recommending Zenodo.org for that reason - GitHub
is neither fixed nor reliable by definition).

Based on that, I'm not sure I fully understand the scope of your proposal
for improvement. Carlo.lock is certainly the first step that the package
author should take in creating the distribution tar ball so you can fix the
versions, but it is not sufficient as the next step involves collecting the
related sources. We don't want R users to be involved in that can of worms
(especially since the lock file itself provides no guarantees of
accessibility of the components and we don't want to have to manually
inspect it), the package should be ready to be used which is why it has to
do that step first. Does that explain the intent better? (In general, the
downloading at install time is actually a problem, because it's not
uncommon to use R in environments that have no Internet access, but the
download is a concession for extreme cases where the tar balls may be too
big to make it part of the package, but it's yet another can of worms...).

Cheers,
Simon




On 13/07/2023, at 12:37 PM, Hiroaki Yutani 

wrote:

Hi,

I'm glad to see CRAN now has its official policy about Rust [1]!
It seems it probably needs some feedback from those who are familiar

with

the Rust workflow. I'm not an expert, but let me leave some quick

feedback.

This email is sent to the R-package-devel mailing list as well as to

cran@~

so that we can publicly discuss.

It seems most of the concern is about how to make the build

deterministic.

In this regard, the policy should encourage including "Cargo.lock" file
[2]. Cargo.lock is created on the first compile, and the resolved

versions

of dependencies are recorded. As long as this file exists, the

dependency

versions are locked to the ones in this file, except when the package
author explicitly updates the versions.

Cargo.lock also records the SHA256 checksums of the crates if they are

from

crates.io, Rust's official crate registry. If the checksums don't

match,

the build will fail with the following message:

error: checksum for `foo v0.1.2` changed between lock files

this could be indicative of a few possible errors:

* the lock file is corrupt
* a replacement source in use (e.g., a mirror) returned a

different

checksum
* the source itself may be corrupt in one way or another

unable to verify that `foo v0.1.2` is the same as when the lockfile

was

generated

For dependencies from Git repositories, Cargo.lock records the commit
hashes. So, the version of the source code (not the version of the

crate)

is uniquely determined. That said, unlike cargo.io, it's possible that

the

commit or the Git repository itself has disappeared at the time of
building, which makes the build fail. So, it might be reasonable the

CRAN

policy prohibits the use of Git dependency unless the source code is
bundled. I have no strong opinion here.

Accordingly, I believe this sentence


In practice maintainers have found it nigh-impossible to meet these

conditions whilst downloading as they have too little control.

is not quite true. More specifically, these things


The standard way to download a Rust ‘crate’ is by its version number,

and

these have been changed without changi

Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons

[Tomas Kalibera]

On 11/1/23 12:15, Alberto Garre wrote:

Dear community,

I feel dismay for having to write this email, but the issue must be brought
up. On the 20th of October, I received an email from CRAN warning me of an
issue with one of the packages I maintain (bioOED). The package depended on
MEIGOR, a package that was no longer available in Bioconductor. I was given
until 2023-11-03 to fix the issue.

I contacted the MEIGOR maintainers and they told me they were migrating to
CRAN. Yesterday, they contacted me again, telling me they needed more time
for the migration. Hence, I responded to the email I received from CRAN,
asking for an extension of the previous deadline (2023-11-03).

To my surprise, it is not just that the extension was not granted, but the
package has been removed from CRAN today (2023-11-01). Two days before the
deadline (2023-11-03): https://cran.r-project.org/package=bioOED

Then, I checked my inbox and I saw an email from one of the CRAN
maintainers, showing that the package was removed because he had felt
offended by my email. I copy-paste the email below.


I don't think this is true. The reason is that your package depends on 
an unavailable package, so cannot be installed. See 
https://cran.r-project.org/web/packages/bioOED/index.html where the 
reason is publicly stated.


If I were you I'd simply wait once MEIGOR is on CRAN and then publish 
the archived package again.


Best,
Tomas



I understand that maintaining CRAN must be a huge work. I also work in
academia, so I am totally aware of all the extra work that is required from
us. But it is unreasonable that a package can be removed just because a
maintainer throws a tantrum

Again, I am really sorry I had to write this email, but CRAN cannot work if
we allow this type of situation.

Kind regards,
Alberto Garre

## Mail from rip...@stats.ox.ac.uk on 2023-11-01 8:28

On 31/10/2023 17:21, Alberto Garre wrote:

Dear Brian,

Do be respectful whoever you are (you lack the manners to use a
signature block but send HTML when you agreed not to!).  What exactly
have you done for me that would allow you treat me as if I were your peer?

Your ingratitude (for CRAN and R) is deafening.


I have talked to the MEIGOR developers and they need a bit more time to
update their package. Would it be possible to get a 4 weeks extension for
the update of bioOED?

No one can even install it in current R, so it has been removed.

"The time of the volunteers is CRAN’s most precious resource"

Professor Ripley


Thank you very much,
Alberto


El vie, 20 oct 2023 a las 9:24, Alberto Garre ()
escribió:


Thank you very much, Brian.

I have just contacted the developers of MEIGOR because I think they were
planning a migration to CRAN. I will update the package asap.

Best,
Alberto


El vie, 20 oct 2023 a las 9:22, Prof Brian Ripley (
)

escribió:


On 20/10/2023 08:17, Prof Brian Ripley wrote:

Dear maintainer,

Please see the problems shown on
.

Please correct before 2023-11-03 to safely retain your package on CRAN.

The CRAN Team


This requires package MEIGOR which is not part of BioC 3.18 and has been
deprecated so it very unlikely to be part of the final release next

week.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford



[[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] Package submission issue - OMP reduction (flang-new)

[Tomas Kalibera]

On 11/13/23 16:39, Romain Pierlot wrote:

Hi everyone,

I sent a first message a few weeks ago. I'm still in trouble for sending a 
package (Frailtypack) on the CRAN. It was removed because of reinforcement in 
CRAN requirements.
We corrected the few issues, but more appeared, and one that I'm still enable 
to correct.

Here is the error message, and the adequate code part is joint in the mail :

error: 
loc("/data/gannet/ripley/R/packages/incoming/frailtypack.Rcheck/00_pkg_src/frailtypack/src/Integrale_mult_scl.f90":1811:17):
 'omp.reduction' op must be used within an operation supporting reduction clause interface
error: verification of lowering to FIR failed

I've already received precious help, that indicated me that the error probably 
comes from the flang-new compiler used by the CRAN (He replicated the error, I 
send you the code he made in attachment too : test_fortran.f90).
I tried the code portion with other compilers (gfortran), and the error didn't 
appear.

Nevertheless, It may be a compiler error, the CRAN keeps denying the package.

Does anyone have a solution, to avoid this error please ?


If you are sufficiently confident this is a compiler bug, it would be 
great if you could submit a bug report for LLVM/flang-new, so that it 
could be fixed. You would also likely get feedback this way confirming 
whether it really is a compiler bug or a problem in your code. And if it 
is a confirmed bug, you might even get an advice for a work-around for 
older compilers.


Tomas



Thanks a lot for your answers !

Romain Pierlot





__
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] Package submission issue - OMP reduction (flang-new)

[Tomas Kalibera]

On 11/13/23 19:18, Ivan Krylov wrote:

On Mon, 13 Nov 2023 16:39:45 +0100 (CET)
Romain Pierlot  wrote:


Here is the error message, and the adequate code part is joint in the
mail :

error:
loc("/data/gannet/ripley/R/packages/incoming/frailtypack.Rcheck/00_pkg_src/frailtypack/src/Integrale_mult_scl.f90":1811:17):
'omp.reduction' op must be used within an operation supporting
reduction clause interface error: verification of lowering to FIR
failed

Have you tried explaining this in the package submission comment? What
was the response? Does the reviewer need more evidence? Linking to the
LLVM issue on GitHub and/or the previous R-package-devel thread may
help.

(LLVM giveth and LLVM taketh away. While I'm sure that their
diagnostics helped improve many packages, I have encountered a few
places in the R code where clang suggested to replace boolean
expressions && and || with bitwise operations & and |. The code still
works, but now relies on boolean constants having certain exact bits
set. Replace a 1 with a 2 and things will break.)

It might be the case that CRAN cannot afford to make an exception for
this compiler bug. I can imagine a number of workarounds:

1. In your ./configure script, check for the Fortran compiler being
flang-new version 17. If the check succeeds, disable OpenMP altogether.

2. Rewrite your Fortran code so that a variable is never touched before
it is used in an OpenMP reduction. You may have to declare a new
variable for every OpenMP reduction loop inside a function.

If you don't succeed in convincing CRAN regarding the compiler bug,
which one of the two workarounds would you prefer?


I would definitely look for a work-around. In the end we want to give 
users software that works, rather than something that doesn't, but 
telling them, possibly with good evidence, than it is not our fault.


Tomas

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

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 21:50, Henrik Bengtsson wrote:

Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.


Please let me clarify. %td works in R on Windows in R 4.3 and R-devel, 
when using the recommended toolchain, which is Rtools43. It also worked 
with R 4.2 and Rtools42. It works since R has switched to UCRT on 
Windows. I assume you are not using a recommended toolchain and this is 
why you are getting the warning - please let me know if this is not the 
case and I will try to help.


There is a bug in GCC, still present in gcc 12 and gcc 10, due to which 
gcc displays warnings about the format even when it is supported. The 
details are complicated, but in short, it accidentally applies both 
Microsoft format and C99/GNU format checks to printf functions with UCRT 
- so you get a warning whenever the two formats disagree, which includes 
printing a 64 bit integer.  Also for %td which is not supported by 
Microsoft format. Or say %zu (size_t) or %Lf (long double). I've been 
patching GCC in Rtools42 and Rtools43 to avoid this problem, so you 
don't get the warning there. My patch has been picked up also by Msys2, 
I didn't check whether it is still there or not. Finally a new 
implementation of the patch was accepted to GCC trunk, so eventually 
this will no longer be needed. But regardless which version of GCC 
Rtools44 will use, I will make sure it will accept C99 printf formats 
without warnings. An unpatched GCC 10 or 12 with UCRT will print a 
warning for %td but will support it.


Best
Tomas


FYI, https://builder.r-hub.io/ is a great, free service for testing on
various platforms in the cloud.  Also, if you host your package code
on GitHub, it's a small step to configure GitHub Actions to check your
packages across platforms on their servers.  It's free and fairly
straightforward.  There should be plenty of tutorials and examples
online for how to do that with R packages.  So, no need to mock around
with Linux containers etc.

/Henrik

On Tue, Nov 28, 2023 at 12:30 PM Daniel Kelley  wrote:

To HB: I also maintain a package that has this problem.  I do not have access 
to a linux machine (or a machine with the C++ version in question) so I spent 
quite a while trying to get docker set up. That was a slow process because I 
had to install R, a bunch of packages, some other software, and so forth.  
Anyway, the docker container I had used didn't seem to have a compiler that 
gave these warnings.  But, by then, I saw that the machine used by

devtools::check_win_devel()

was giving those warnings :-)

So, now there is a way to debug these things.

PS. I also tried using rhub, but it takes a long time and often results in a 
PREPERROR.

On Nov 28, 2023, at 3:58 PM, Henrik Bengtsson  
wrote:

CAUTION: The Sender of this email is not from within Dalhousie.

"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] WARNING
Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format [-Wformat-extra-args]
binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on Linux. Because of this, I resorted to the coercion
strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
int'.

/Henrik

On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov  wrote:


On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:

Rprintf("%lld", (long long) xlength(x));


This is fine. long longs are guaranteed to be at least 64 bits in size
and are signed, just like lengths in R.

Rprintf("%td, xlength(x));


Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
to fail on an (increasingly rare) 32-bit

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 20:51, Ivan Krylov wrote:

On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:


Rprintf("%lld", (long long) xlength(x));

This is fine. long longs are guaranteed to be at least 64 bits in size
and are signed, just like lengths in R.
Right, this has been my choice for R-devel, at least for now. It still 
has downsides. In principle, it is not guaranteed that ptrdiff_t won't 
become bigger than long long at some point (but it is extremely unlikely 
anyone would run into that in R ever with array indexes). Then, on the 
other hand, it may be a waste in some cases, ptrdiff_t is smaller and in 
theory the generated code may be faster in some cases (that of course 
wouldn't matter for errors or I/O, but maybe in theory it could with 
purely string operations).



Rprintf("%td, xlength(x));

Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
(which is an implementation detail).

In my opinion, ptrdiff_t is just the right type for array lengths if
they have to be signed (which is useful for Fortran interoperability),
so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
for now. By definition of ptrdiff_t, you can be sure [*] that there
won't be any vectors on your system longer than PTRDIFF_MAX.


Yes, that is fine, too, with the cast, as long as R_xlen_t is not bigger 
than ptrdiff_t. You would have a problem if it ever changed in R. I 
don't think it is likely, but, technically, the formal guarantees in the 
C standard about for which array indexing ptrdiff_t are somewhat weak, 
maybe we might need to change this to support bigger arrays or maybe use 
the type R_xlen_t also for something slightly different that needs to be 
bigger.



using the string macro found in Mr Kalibera's commit of r85641:
R_PRIdXLEN_T

I think this will be the best solution once we can afford
having our packages depend on R >= 4.4.


Yes, the goal was to allow most C99 way using this macro, so e.g.

Rprintf("my index %" R_PRIdXLEN_T "\n", xlength(x));

(note the space before and after the macro in concatenation to be C++ 
friendly). This doesn't have the limitations described before, but, 
there is a problem with translations. I am still looking into that, but 
from what I can tell, gettext doesn't make this possible. A good support 
would allow strings described this way and also translated this way, 
using the symbolic name of the macro, not the expansion.


But, unless you use gettext/translations, this last option is probably 
best. Yet you would have to define the macro if not defined to support R 
4.3 and older versions.


Tomas





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

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 21:55, Daniel Kelley wrote:

I hope it's okay to ask this on the present thread, rather than starting a new 
one...

On this issue of the C format for various integer-type items, I am finding that 
checks made with devtools::check_win_devel() give different results than those 
made with the github R-CMD-check action named ubuntu-latest-devel.  Which (if 
either) might be best for someone trying to fix up code for a CRAN release?

# Details

The code

NumericVector a;
::R_error("size %ld", a.size());

does not lead to warnings with R-CMD-check/ubuntu-latest-devel compilation, but 
it does with devtools::check_win_devel().  And the reverse is true with the code

NumericVector a;
::R_error("size %lld", a.size());

so one of these two methods must not be a good way to know if I'm doing the 
right thing.  I don't want to submit an update to CRAN that will lead to 
problems there, so I am keen to find a way to test this aspect without making a 
new submission (and thereby wasting time for the kind folks who run CRAN).


I think the best way to deal with these is to look at the lines and 
arguments identified by any of the compilers on any of the test 
platforms you have, and then based on reading the code and learning what 
the types really are (or are guaranteed to be) decide on how to fix. The 
presence and wording of the warnings may be compiler specific. In some 
cases even platform specific, because some C types have different size 
on different platforms, or map to different underlying types.


So, if the line above was identified by the compiler, check the 
documentation for NumericVector::size(), which type does it guarantee to 
return. The compiler warning may give a hint (what the type is in your 
build), but indeed it wouldn't consult the documentation. If the type is 
R_xlen_t (I didn't check if it is), then you could do e.g.


::R_error("size %lld", (long long)a.size());

or better

::R_error("size %" R_PRIdXLEN_T ", a.size());

as discussed elsewhere in this thread.

It is not a good idea to just use the type given in the warning, because 
that may not be portable. In this case, your compiler warning (on Linux) 
may have said "long int", which may have been how "ptrdiff_t" is defined 
on the platform by the compiler, which is probably how R_xlen_t is 
defined on your platform. But, it may be different elsewhere. On your 
second platform, the compiler warning may have said "long long int" (on 
Windows), which may have been how "ptrdiff_t" is defined there by the 
compiler, and on that platform, "long int" is different from "long long 
int", so the former didn't work.


If you use the Winbuilder service maintained by Uwe Ligges, you will 
have the same setup as one of the platforms used for CRAN incoming checks.


Best
Tomas



Thanks.

Dan.


On Nov 28, 2023, at 4:30 PM, Reed A. Cartwright  wrote:

CAUTION: The Sender of this email is not from within Dalhousie.

If I have read the R's change log correctly, C99 printf format is now
supported on Windows. I think the change was made in the last week.

On Tue, Nov 28, 2023, 13:01 Henrik Bengtsson 
wrote:


"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory
'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] WARNING
Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format
[-Wformat-extra-args]
binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on Linux. Because of this, I resorted to the coercion
strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
int'.

/Henrik

On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov 
wrote:

On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:


Rpri

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 22:21, Tomas Kalibera wrote:


On 11/28/23 21:50, Henrik Bengtsson wrote:

Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.


Please let me clarify. %td works in R on Windows in R 4.3 and R-devel, 
when using the recommended toolchain, which is Rtools43. It also 
worked with R 4.2 and Rtools42. It works since R has switched to UCRT 
on Windows. I assume you are not using a recommended toolchain and 
this is why you are getting the warning - please let me know if this 
is not the case and I will try to help.


I forgot to say that one needs R-devel 85640 or newer. You could get the 
warning for %td etc also with R-devel between 85639 and R-devel 85619, 
even with the recommended toolchain, because these versions used 
"printf" format in the header, but on Windows it needs to use 
"gnu_printf" (which is the C99/UCRT format). I've fixed that in 85640.


Best
Tomas



There is a bug in GCC, still present in gcc 12 and gcc 10, due to 
which gcc displays warnings about the format even when it is 
supported. The details are complicated, but in short, it accidentally 
applies both Microsoft format and C99/GNU format checks to printf 
functions with UCRT - so you get a warning whenever the two formats 
disagree, which includes printing a 64 bit integer.  Also for %td 
which is not supported by Microsoft format. Or say %zu (size_t) or %Lf 
(long double). I've been patching GCC in Rtools42 and Rtools43 to 
avoid this problem, so you don't get the warning there. My patch has 
been picked up also by Msys2, I didn't check whether it is still there 
or not. Finally a new implementation of the patch was accepted to GCC 
trunk, so eventually this will no longer be needed. But regardless 
which version of GCC Rtools44 will use, I will make sure it will 
accept C99 printf formats without warnings. An unpatched GCC 10 or 12 
with UCRT will print a warning for %td but will support it.


Best
Tomas


FYI, https://builder.r-hub.io/ is a great, free service for testing on
various platforms in the cloud.  Also, if you host your package code
on GitHub, it's a small step to configure GitHub Actions to check your
packages across platforms on their servers.  It's free and fairly
straightforward.  There should be plenty of tutorials and examples
online for how to do that with R packages.  So, no need to mock around
with Linux containers etc.

/Henrik

On Tue, Nov 28, 2023 at 12:30 PM Daniel Kelley  wrote:
To HB: I also maintain a package that has this problem.  I do not 
have access to a linux machine (or a machine with the C++ version in 
question) so I spent quite a while trying to get docker set up. That 
was a slow process because I had to install R, a bunch of packages, 
some other software, and so forth.  Anyway, the docker container I 
had used didn't seem to have a compiler that gave these warnings. 
But, by then, I saw that the machine used by


devtools::check_win_devel()

was giving those warnings :-)

So, now there is a way to debug these things.

PS. I also tried using rhub, but it takes a long time and often 
results in a PREPERROR.


On Nov 28, 2023, at 3:58 PM, Henrik Bengtsson 
 wrote:


CAUTION: The Sender of this email is not from within Dalhousie.

"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory 
'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'

* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] 
WARNING

Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format 
[-Wformat-extra-args]

binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 
'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'

for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/29/23 19:30, Henrik Bengtsson wrote:

On Tue, Nov 28, 2023 at 1:21 PM Tomas Kalibera  wrote:


On 11/28/23 21:50, Henrik Bengtsson wrote:

Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.

Please let me clarify. %td works in R on Windows in R 4.3 and R-devel,
when using the recommended toolchain, which is Rtools43. It also worked
with R 4.2 and Rtools42. It works since R has switched to UCRT on
Windows. I assume you are not using a recommended toolchain and this is
why you are getting the warning - please let me know if this is not the
case and I will try to help.

Thank you.

I was getting those compiler warnings on %td when using the widely
used https://github.com/r-lib/actions tool chain.  It was using
gcc.exe (GCC) 12.2.0 two-three days ago.  I reran it yesterday, and it
seems to have been fixed now.  It is now reporting on gcc.exe (GCC)
12.3.0.  Not sure if that was the fix, or there was something else.

Thanks. I don't know what that service uses, it is not maintained by R Core.



There is a bug in GCC, still present in gcc 12 and gcc 10, due to which
gcc displays warnings about the format even when it is supported. The
details are complicated, but in short, it accidentally applies both
Microsoft format and C99/GNU format checks to printf functions with UCRT
- so you get a warning whenever the two formats disagree, which includes
printing a 64 bit integer.  Also for %td which is not supported by
Microsoft format. Or say %zu (size_t) or %Lf (long double). I've been
patching GCC in Rtools42 and Rtools43 to avoid this problem, so you
don't get the warning there. My patch has been picked up also by Msys2,
I didn't check whether it is still there or not. Finally a new
implementation of the patch was accepted to GCC trunk, so eventually
this will no longer be needed. But regardless which version of GCC
Rtools44 will use, I will make sure it will accept C99 printf formats
without warnings.

Interesting. Thanks for this work and pushing this upstreams.


An unpatched GCC 10 or 12 with UCRT will print a warning for %td but will 
support it.

It sounds like '%td' is supported, and it's just that there's a false
warning. Do you happen to know we can assume '%td' is compatible with
much older versions of GCC too? My question is basically, can I safely
use '%td' with older version of GCC, e.g. for older versions of R, and
assume it'll compile on MS Windows?  In my case, we're trying to keep
'matrixStats' backward quite far back, and I can imagine there are
other packages doing that too.


No, %td would not work with R < 4.2 built using the then recommended 
toolchains, because MSVCRT was used, which did not support %td. The 
runtime library would not be able to print such value.


For such old versions of R, you would have to do something else. I think 
PRId64 from inttypes.h and a cast to "(long long)" should work. The 
macro would expand to the Microsoft format pattern in the older 
versions. Or depending on what you want to do, also you could simply 
cast to double and print that way.


CRAN only tests and builds R-devel, R-release and R-oldrelease (4.2 at 
this point).


Best
Tomas



Thanks,

Henrik


Best
Tomas


FYI, https://builder.r-hub.io/ is a great, free service for testing on
various platforms in the cloud.  Also, if you host your package code
on GitHub, it's a small step to configure GitHub Actions to check your
packages across platforms on their servers.  It's free and fairly
straightforward.  There should be plenty of tutorials and examples
online for how to do that with R packages.  So, no need to mock around
with Linux containers etc.

/Henrik

On Tue, Nov 28, 2023 at 12:30 PM Daniel Kelley  wrote:

To HB: I also maintain a package that has this problem.  I do not have access 
to a linux machine (or a machine with the C++ version in question) so I spent 
quite a while trying to get docker set up. That was a slow process because I 
had to install R, a bunch of packages, some other software, and so forth.  
Anyway, the docker container I had used didn't seem to have a compiler that 
gave these warnings.  But, by then, I saw that the machine used by

devtools::check_win_devel()

was giving those warnings :-)

So, now there is a way to debug these things.

PS. I also tried using rhub, but it takes a long time and often results in a 
PREPERROR.

On Nov 28, 2023, at 3:58 PM, Henrik Bengtsson  
wrote:

CAUTION: The Sender of this email is not from within Dalhousie.

"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3

Re: [R-pkg-devel] Update timing of machines on CRAN?

[Tomas Kalibera]

On 12/4/23 15:44, SHIMA Tatsuya wrote:

Thanks for your answer.

Unlike Windows Server, which has a long support period, Fedora's 
support period is usually about one year, so it is surprising that the 
old Fedora continues to be used.
And, unlike Windows, Linux uses the distribution standard packages for 
builds, which causes problems like the current Fedora machine that 
continues to use the old Rust.


The configuration currently at different CRAN machines is just a sample 
of what your users might have, just an example of a setting packages 
should be able to deal with. Some users might also still have FC36, some 
might have another Linux distribution (possibly still supported), which 
has older software than that.


I wouldn't recommend spending time tracking which version of which 
software CRAN systems currently happen to have, but rather making sure 
packages can deal with different versions (possibly with some in a 
restricted way, possibly making some hard requirements when necessary).


Best
Tomas


Hope to see an update soon. Thanks to the staff for maintaining the 
infrastructure.


Best,
Tatsuya

On 2023/12/01 23:43, Uwe Ligges wrote:



On 01.12.2023 13:28, SHIMA Tatsuya wrote:

Hi,

I maintain the prqlr package that uses rustc for compiling, so I 
regularly check the version of Rust on CRAN.
And I have noticed that the Rust version of Fedora has been stagnant 
for the past few months and was wondering why, but upon 
investigation I realized that this is because Fedora on CRAN is 
currently Fedora 36 (out of support in May).



It was quite a surprise to me that out of support Fedora is being 
used, but what is the normal cycle for machines on CRAN to be 
updated? And do we have any way of knowing that schedule?


It depends on the maintainer who cares about these machine, the 
institution where it is hosted, the availability of technical staff, 
and the technical pressure.


I could not even say when the machines I maintain will be updated.
On one version of the retired winbuilder severs we kept the same OS 
version for almost 10 years.


Best,
Uwe Ligges







Best,
Tatsuya

__
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] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Tomas Kalibera]

On 12/13/23 14:56, McGrath, Justin M wrote:

Thanks. Pursuing this a bit further, from ?tar "Known problems":

 > The handling of file paths of more than 100 bytes.  These
 > were unsupported in early versions of ‘tar’, and supported in
 > one way by POSIX ‘tar’ and in another by GNU ‘tar’ and yet
 > another by the POSIX ‘pax’ command which recent ‘tar’
 > programs often support.  The internal implementation warns on
 > paths of more than 100 bytes, uses the ‘ustar’ way from the
 > 1998 POSIX standard which supports up to 256 bytes (depending
 > on the path: in particular the final component is limited to
 > 100 bytes) if possible, otherwise the GNU way (which is
 > widely supported, including by ‘untar’).

R CMD check --as-cran gives a WARNING if a path is not ustar compatible, and 
gives the same message as a NOTE if it is not v7 compatible.

The path in the example below is ustar compatible, but not v7 compatible.

***
* checking for portable file names ... NOTE
Found the following non-portable file path:
   
BioCro/inc/boost/numeric/odeint/stepper/generation/generation_controlled_adams_bashforth_moulton_really_long_file_name_one_two_three.hpp

Tarballs are only required to store paths of up to 100 bytes and cannot
store those of more than 256 bytes, with restrictions including to 100
bytes for the final component.
***

The code is in library/tools/R/check.R. An equivalent test is performed by R 
CMD build in library/tools/utils/tar.R.

AFAIK, CRAN rejects a package regardless whether the message is given as a NOTE 
or a WARNING. ustar is 35 years old and is older than R itself, and thus anyone 
using R in the last several decades will have ustar support. Any path stored by 
ustar will be suitable for any common file system in use for the last several 
decades. Overall, if a path is supported by ustar, there is no reason to 
generate any message, even if that path is not v7 compatible. If the NOTE about 
v7 incompatibility is still desired, then could CRAN not reject packages for 
which the check reports a NOTE?


Please don't forget about what has been correctly mentioned on this 
thread already: there is essentially a 260 character limit on Windows 
(see 
https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html 
for more). Even if the relative path length limit for a CRAN package was 
no longer regarded important for tar compatibility, it would still make 
sense for compatibility with Windows. It may still be a good service to 
your users if you keep renaming the files to fit into that limit.


Also please do not share private emails on the list.

Thanks
Tomas



Best wishes,
Justin


_


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

Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Tomas Kalibera]

On 12/13/23 15:59, Dirk Eddelbuettel wrote:

On 13 December 2023 at 15:32, Tomas Kalibera wrote:
| Please don't forget about what has been correctly mentioned on this
| thread already: there is essentially a 260 character limit on Windows
| (see
| https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/index.html
| for more). Even if the relative path length limit for a CRAN package was
| no longer regarded important for tar compatibility, it would still make
| sense for compatibility with Windows. It may still be a good service to
| your users if you keep renaming the files to fit into that limit.

So can lift the limit from 100 char to 260 char ?


The 260 char limit is for the full path. A package would be extracted in 
some directory, possibly also with a rather long name.


Tomas



Dirk



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

Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Tomas Kalibera]

On 12/14/23 19:39, McGrath, Justin M wrote:

At this point, the policy appears to have nothing to do with tar, contrary to 
the error message. Thus, replacing tar with zip wouldn't address CRAN's 
concern. The policy given in this thread (and seemingly unstated anywhere 
public) is that CRAN wants to allow someone on Windows to unpack an R package 
in a directory with a path length of 160 characters, given the 260 limit on 
Windows.


The CRAN repository policy is a publicly accessible document at [1]. If 
you are unsure what is acceptable or not, or if you think you a have 
strong case to ask for an exception for your package, or possibly for 
completely ignoring this warning from R, contact the CRAN team [2].


On this list you may receive help and advice from individual people, but 
that doesn't constitute the CRAN policy nor what CRAN "wants", even when 
from people who individually are members of the CRAN team. You may still 
find such advice useful for making your packages better.


If you wanted R tar() to stop issuing warnings in certain cases, you can 
suggest that on R bugzilla. If that happens and instead say a new check 
is added to R to warn when a different limit is reached (e.g. to protect 
users on Windows), you can then file another bug report.


I don't think you can get any more help with this on this list.

1. https://cran.r-project.org/web/packages/policies.html
2. https://cran.r-project.org

Tomas



The implication here is that developers of public libraries needs to get their 
act together because they have *total path lengths* of 85 characters, that one 
needs to rename to include in an R package,  in order to accommodate someone 
who is unpacking R packages in directories with lengths of 160 characters (just 
the directory length!). I doubt such people exist, so we are accommodating a 
myth. I don't even have directories that long on my computer, and I certainly 
wouldn't be unpacking R packages in them if I did.

Path lengths in packages of 130 to 150 characters would allow unpacking in 
directories of 130 to 110 characters. Anything in that range would likely 
result in no or very few problems for either the people creating or the people 
unpacking packages. The claim that people need to use sensible naming schemes 
goes both ways. One can't expect unreasonably long path in packages, and people 
making packages can't expect people try to unpack into unreasonably long 
directories. Yet, it's impossible to miss the great disparity in the current 
split of 100 character total path vs 160 characters for just a directory path.


From: Steven Scott 
Sent: Thursday, December 14, 2023 12:11 PM
To: Vladimir Dergachev
Cc: McGrath, Justin M; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length 
limit be lifted?

Compiled code is another source of long names.  Some libraries are produced by companies 
with style restrictions that demand LongDescriptiveNames for functions and classes, and 
which expect file names to match the name of the class contained within.  If you've got 
Models/SpecificModelFamily/PosteriorSamplers/SpecificTypeOfPosteriorSampler.hpp it leaves 
very little room (20 characters) for "C:\Users\..." etc up front.

I solved my 'tar' problems with 'sed'.  In human readable code I keep the long 
names.  In the code that gets submitted to CRAN I pass specific file names 
through sed to rename the long files.  I have an install script with lines like:

hdr="MvStateSpaceRegressionPosteriorSampler.hpp"
new_hdr="MVSSRPS.hpp"
mv "$ibase/$dbase/$hdr" "$ibase/$dbase/$new_hdr"
echo "replacing $dbase/$hdr with $dbase/$new_hdr"
grep -rl "$dbase/$hdr" "$BOOM_DIR/src/Models" | xargs $SED -i 
"s|$dbase/$hdr|$dbase/$new_hdr|g"

This renames the files, and uses sed to replace #include references to file 
names with the shorter file names.  The SED macro is because on mac 'sed' is 
spelled 'gsed'.

I agree the system sucks.  It would be nice if one of the steps in winbuilder took 
non-windows compliant TAR files and replaced them with ZIP files or something 
similar.  We'd still have the Win32 character limit, but 256 > 100 so the 
problem wouldn't bite so hard.

On Thu, Dec 14, 2023 at 6:19 AM Vladimir Dergachev 
mailto:volo...@mindspring.com>> wrote:


On Wed, 13 Dec 2023, McGrath, Justin M wrote:


On Windows, packages will be in "C:\Users\[User Name]\Documents\R\win-library\[R 
version]\[Package Name]".

With a 150 byte limit, that leaves 70 bytes for the user name, R version
and package name. That seems more than sufficient. If people are
downloading the source files, that also leaves plenty of space
regardless where they choose to extract the files.


70 bytes ?? My name is 18 characters long and there are plenty of people
with longer names. I also saw practice on Windows systems to append the
name of organization or department.

Also, this restricts the length of package name which is arguabl

Re: [R-pkg-devel] Issue with flang-new (segfault from C stack overflow)

[Tomas Kalibera]

On 12/18/23 15:09, Ivan Krylov wrote:

В Mon, 18 Dec 2023 11:06:16 +0100
Jisca Huisman  пишет:


I isolated the problem in a minimal working example available here:
https://github.com/JiscaH/flang_segfault_min_example . All that does
is pass a vector of length N*N back and forth between R and Fortran.
It works fine for very long vectors (tested up to length 5e8), but
throws a segfault when I reshape a large array in Fortran to a vector
to pass to R, both when using RESHAPE() and when using loops.

You've done an impressive amount of investigative work. Thank you for
reducing your problem to such a small example! My eyes are drawn to
these two lines:


  integer, intent(IN) :: N
  integer :: M(N,N)

If this was C, such a declaration would mean a variable-length array
that would have to be placed on the (limited-size) stack and eventually
overflow it. gfortran places the array on the heap, so the program
works:

   integer, intent(IN) :: N
   integer, intent(INOUT) :: V(N*N)
   integer :: M(N,N)
 1205:   48 63 dbmovslq %ebx,%rbx
 1208:   b8 00 00 00 00  mov$0x0,%eax
 120d:   48 85 dbtest   %rbx,%rbx
 1210:   49 89 c4mov%rax,%r12
 1213:   4c 0f 49 e3 cmovns %rbx,%r12
 1217:   48 89 dfmov%rbx,%rdi
 121a:   49 0f af fc imul   %r12,%rdi
 121e:   48 85 fftest   %rdi,%rdi
 1221:   48 0f 48 f8 cmovs  %rax,%rdi
 1225:   48 c1 e7 02 shl$0x2,%rdi
 1229:   b8 01 00 00 00  mov$0x1,%eax
 122e:   48 0f 44 f8 cmove  %rax,%rdi
 1232:   e8 19 fe ff ff  callq  1050 
 1237:   48 89 c5mov%rax,%rbp
 123a:   4c 89 e7mov%r12,%rdi
 123d:   48 f7 d7not%rdi

(Looking at the address of M in GDB and comparing it with the output
of info proc mappings, I can confirm that it lives on the heap.)

flang-new makes M into a C-style VLA:

   integer, intent(IN) :: N
   integer, intent(INOUT) :: V(N*N)
   integer :: M(N,N)
 74ec:   48 63 17movslq (%rdi),%rdx
 74ef:   89 d1   mov%edx,%ecx
 74f1:   31 c0   xor%eax,%eax
 74f3:   48 85 d2test   %rdx,%rdx
 74f6:   48 0f 49 c2 cmovns %rdx,%rax
 74fa:   48 89 85 b0 fe ff ffmov%rax,-0x150(%rbp)
 7501:   48 89 c2mov%rax,%rdx
 7504:   48 0f af d2 imul   %rdx,%rdx
 7508:   48 8d 34 95 0f 00 00lea0xf(,%rdx,4),%rsi
 750f:   00
 7510:   48 83 e6 f0 and$0xfff0,%rsi
 7514:   48 89 e2mov%rsp,%rdx
 7517:   48 29 f2sub%rsi,%rdx
 751a:   48 89 95 b8 fe ff ffmov%rdx,-0x148(%rbp)
 7521:   48 89 d4mov%rdx,%rsp

(Looking at the value of the stack pointer in GDB after M(N,N) is
declared, I can see it way below the end of the stack and the loaded
shared libraries according to info proc mappings. GDB doesn't let me
see the address of M. The program crashes in `M = 42`, trying to
overwrite the code from the C standard library.)

Are Fortran processors allowed to place such "automatic data objects"
like integer :: M(N,N) on the stack?


From my reading, yes, they are allowed to do that. Local arrays can be 
put on the stack or the heap. Even the "allocatable" could be placed on 
the stack. But I am not a fortran expert.


Allocating on the stack has the problem that it is not possible to have 
a portable test whether there is enough space, hence the crash when it 
isn't. This is not specific to fortran. Some systems try to still detect 
such cases (like R), but it is not portable. There are OS-specific ways 
to increase the stack size limit, but that cannot be relied on with R, 
it would be rather too much asking R users to do that.


You might perhaps submit a bug report for flang-new, asking whether 
their heuristics for these cases are as intended, showing that they 
differ from gfortran.


You might get more help on mailing lists discussing Fortran language, 
specifically - this is not an R issue.


But in practice, yes, using "allocatable" should work much better for 
large arrays.


Best
Tomas



The Fortran standard doesn't seem
to give an answer to this question, but if you make your M allocatable,
you won't have to worry about stack usage:

subroutine dostuff(N,V)
   implicit none

   integer, intent(IN) :: N
   integer, intent(INOUT) :: V(N*N)
   integer, allocatable :: M(:,:) ! <-- here

   allocate(M(N,N))   ! <-- and here
   M = 42
   V = RESHAPE(M, (/N*N/))
end subroutine dostuff

No leaks or crashes observed with these two changes and either
compiler. The Fortran standard requires that l

Re: [R-pkg-devel] Issue with flang-new (segfault from C stack overflow)

[Tomas Kalibera]

On 12/18/23 16:41, Jisca Huisman wrote:

Hello Ivan & Tomas,

Thank you for your time and helpful suggestions!

The finer details of memory use and heap vs stack are still outside my 
comfort zone, but some trial and error shows that using an allocatable 
does indeed solve the issue. When using the largest value I expect 
users to use before running into Out Of Memory issues at other points 
in the code, I get


==3154== Warning: set address range perms: large range [0xd0ff3070, 
0x14834c470) (undefined)
==3154== Warning: set address range perms: large range [0x14834d040, 
0x1bf6a6440) (undefined)
==3154== Warning: set address range perms: large range [0x14834d028, 
0x1bf6a6458) (noaccess)


but no valgrind errors. So I'm happy with this fairly straightforward 
solution, thanks Ivan!





You might perhaps submit a bug report for flang-new, asking whether 
their heuristics for these cases are as intended, showing that they 
differ from gfortran.

Will do; I suspect gfortran may have some trick to make it work somehow.

Thanks.


You might get more help on mailing lists discussing Fortran language, 
specifically - this is not an R issue.


Since the original error was "segfault from C stack overflow" I was 
not convinced that this was a Fortran issue, but thanks for the 
suggestion - I will try to find those for future issues.


The segfault handler belongs to R, but it is triggered by the overflow 
in the fortran function. If you ran the example outside R, it would use 
the default segfault handler, which would simply terminate the program 
(possibly creating a core dump, depending on the OS/setup).


Best
Tomas





But in practice, yes, using "allocatable" should work much better for 
large arrays.


Good to know!




Best
Tomas 


Thanks,

Jisca



On 18-12-2023 16:06, Tomas Kalibera wrote:


On 12/18/23 15:09, Ivan Krylov wrote:

В Mon, 18 Dec 2023 11:06:16 +0100
Jisca Huisman  пишет:


I isolated the problem in a minimal working example available here:
https://github.com/JiscaH/flang_segfault_min_example . All that does
is pass a vector of length N*N back and forth between R and Fortran.
It works fine for very long vectors (tested up to length 5e8), but
throws a segfault when I reshape a large array in Fortran to a vector
to pass to R, both when using RESHAPE() and when using loops.

You've done an impressive amount of investigative work. Thank you for
reducing your problem to such a small example! My eyes are drawn to
these two lines:


  integer, intent(IN) :: N
  integer :: M(N,N)

If this was C, such a declaration would mean a variable-length array
that would have to be placed on the (limited-size) stack and eventually
overflow it. gfortran places the array on the heap, so the program
works:

   integer, intent(IN) :: N
   integer, intent(INOUT) :: V(N*N)
   integer :: M(N,N)
 1205:   48 63 db    movslq %ebx,%rbx
 1208:   b8 00 00 00 00  mov    $0x0,%eax
 120d:   48 85 db    test   %rbx,%rbx
 1210:   49 89 c4    mov    %rax,%r12
 1213:   4c 0f 49 e3 cmovns %rbx,%r12
 1217:   48 89 df    mov    %rbx,%rdi
 121a:   49 0f af fc imul   %r12,%rdi
 121e:   48 85 ff    test   %rdi,%rdi
 1221:   48 0f 48 f8 cmovs  %rax,%rdi
 1225:   48 c1 e7 02 shl    $0x2,%rdi
 1229:   b8 01 00 00 00  mov    $0x1,%eax
 122e:   48 0f 44 f8 cmove  %rax,%rdi
 1232:   e8 19 fe ff ff  callq  1050 
 1237:   48 89 c5    mov    %rax,%rbp
 123a:   4c 89 e7    mov    %r12,%rdi
 123d:   48 f7 d7    not    %rdi

(Looking at the address of M in GDB and comparing it with the output
of info proc mappings, I can confirm that it lives on the heap.)

flang-new makes M into a C-style VLA:

   integer, intent(IN) :: N
   integer, intent(INOUT) :: V(N*N)
   integer :: M(N,N)
 74ec:   48 63 17    movslq (%rdi),%rdx
 74ef:   89 d1   mov    %edx,%ecx
 74f1:   31 c0   xor    %eax,%eax
 74f3:   48 85 d2    test   %rdx,%rdx
 74f6:   48 0f 49 c2 cmovns %rdx,%rax
 74fa:   48 89 85 b0 fe ff ff    mov %rax,-0x150(%rbp)
 7501:   48 89 c2    mov    %rax,%rdx
 7504:   48 0f af d2 imul   %rdx,%rdx
 7508:   48 8d 34 95 0f 00 00    lea 0xf(,%rdx,4),%rsi
 750f:   00
 7510:   48 83 e6 f0 and $0xfff0,%rsi
 7514:   48 89 e2    mov    %rsp,%rdx
 7517:   48 29 f2    sub    %rsi,%rdx
 751a:   48 89 95 b8 fe ff ff    mov %rdx,-0x148(%rbp)
 7521:   48 89 d4    mov    %rdx,%rsp

(Looking at the value of the stack pointer in GDB after M(N,N) is
declared, I c

Re: [R-pkg-devel] Additional Issues: Intel

[Tomas Kalibera]

On 1/17/24 09:41, Ivan Krylov via R-package-devel wrote:

В Wed, 17 Jan 2024 10:30:36 +1100
Hugh Parsonage  пишет:


I am unable to immediately see where in the test suite this error has
occurred.

Without testthat, you would have gotten a line by line printout of the code, 
letting you pinpoint the (top-level) place of the crash. With
testthat, you will need a more verbose reporter that would print tests
as they are executed to find out which test causes the crash.


The only hunch I have is that the package uses C code and includes
structs with arrays on the stack, which perhaps are excessive for the
Intel check machine, but am far from confident that's the issue.

According to GNU cflow, your only recursive C functions are
getListElement (from getListElement.c) and nthOffset (from Offset.c),
but the recursion seems bounded in both cases.

I've tried looking for variable-length arrays in your code using a
Coccinelle patch, but found none. If you had variable-bounded recursion
or variable-length stack arrays (VLA or alloca()), it would be prudent
to use R_CheckStack() or R_CheckStack2(size_of_VLA), but your C code
contains neither, so there's no obvious culprit. If you know about
R-level recursion happening in your code and have a way to reduce it,
that might help too.

Otherwise, it's time to install Intel Everything and reproduce and
debug the problem the hard way.


You could also try debugging using your toolchain, but with reduced 
stack size (e.g. ulimit -s). If you can make the error appear with a 
smaller but still reasonable stack size, chances are it is due to the 
same underlying problem.


Tomas





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

Re: [R-pkg-devel] CMake on CRAN Systems

[Tomas Kalibera]

On 1/17/24 08:37, Sameh Abdulah wrote:

Hi All,

We recently encountered an installation issue with our package on CRAN. We've 
been depending on CMake, assuming it is readily available by default, but it 
appears to be only available on the M1mac system but not on the others. Should 
we include the CMake installation within our package?


Re Windows, see the documentation:

https://cran.r-project.org/bin/windows/base/howto-R-devel.html
https://cran.r-project.org/bin/windows/base/howto-R-4.3.html

cmake executable is available. But another issue is how well maintained 
are the cmake configuration files to find the software, etc.


You have most control when you specify the libraries for linking 
explicitly by yourself (and use just make/Makevars files), even though 
this can sometimes require manual changes for newer versions of Rtools 
(some libraries change linking often, most don't). This is the common 
way to do it (see the documentation).


You can also use pkg-config with the latest Rtools, and pkg-config is 
used internally by MXE, which provides some testing, and I've manually 
fixed a number of issues not detected by that testing. The advantage of 
pkg-config is that you don't have to specify the libraries yourself and 
it should reduce the need for updating your Makevars on Rtools updates. 
At the same time, it is much more likely to work than cmake, yet you 
could still easily run to issues, typically some dependency omitted.


I would not use cmake for an R package on Windows.

Tomas



We encountered another issue with OpenMP, but we managed to resolve it by 
consulting the manual.

https://urldefense.com/v3/__https://cran-archive.r-project.org/web/checks/2024/2024-01-12_check_results_MPCR.html__;!!Nmw4Hv0!1cg5mCeLOB9fBslqbEGB1S0_MEcOLMjk6m4hpfWDyXErAlWtm82xz9ZUU3aQ3q6jkXZBM2tNhUp3EI3JmigE4EvCLlrC$



Best,
--Sameh



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

Re: [R-pkg-devel] ERROR building MixAll on Windows platform

[Tomas Kalibera]

On 1/19/24 15:18, Serge wrote:
This post is a continuation of the post *[R-pkg-devel] Does 
dependencies up to date on the pretest CRAN infrastructure*


I made more (unsuccessful) tries:

- I installed a Windows 11 version in a VM on my compuiter and try to 
buid the MixAll package using Rtools42 and Rtools43 (it's quite easy, 
and funny, to do it on windows: you have just to rename C:\rtools42 as 
C:\rtools43).
There should be no renaming, instead, one should use R 4.2.x with 
Rtools42 and R 4.3.x (or current R-devel) with Rtools43. All of these 
can co-exist (be installed at the same time). Mixing the two could lead 
to different failures. I understand you want to test different versions 
of GCC, but to do that reliable you would have to rebuild the rest of 
Rtools with that, or just the part that is needed by the package.


The result is that MixAll is build using the 4.2 version and the buid 
failed using the 4.3 version.

Please make sure to use Rtools43 (the real one) with R 4.3.


- I installed the version 12.3 of gcc on ubuntu (the same version used 
on windows) and could build the package without problem


- Inspecting the log of the Rtools4.3 
(https://cran.r-project.org/bin/windows/Rtools/rtools43/news.html) and 
g++12..3 (https://gcc.gnu.org/gcc-12/changes.html) does not give insight.


- The package is dependent of the rtkore package which use extensive 
use of templated class. As rtkore is a port for R of stk++, I try to 
compile the stk++ library on windows (using g++12). All tests are 
compiled without any troubles.


These attempts eliminate some causes, but don't give me any insight 
why MixAll (and blockcluster) failed to be build on the Windows-devel 
platform. It seems related to Rtools43. Does anyone else (using for 
exemple Rcppeigen) is experiencing this problem ?


If this is GCC running out of memory on Windows but not Linux, when 
there really should be enough of memory available (i.e. due to the 
problem that Uwe described, maybe the internal GC in GCC is asking for 
too much memory for its heap given that the OS is not overcomiting), you 
can try narrowing it down to a standalone C++ program (independent on R, 
Rtools, R packages, compilable on both Windows and Linux with disabled 
optimizations, etc) that still exhibits the problem and then submitting 
it in a bug report to GCC bugzilla.


In such case, it could be that some heuristics in the collector could be 
improved.


If you have such standalone example, it would be easier to test 
different versions of GCC or even bisect to a concrete GCC version. You 
might also compare memory usage when compiling and cross-compiling.


You might also be able to find a work-around for your package by 
disabling some compiler optimizations. Also if you can narrow this down 
to a concrete GCC optimization then it would help to mention that in the 
bug report.


Certainly all of this would be out of scope of R-(pkg)-devel, this would 
rather be a GCC/Windows thing.


Tomas



Serge



Le 14/01/2024 à 18:50, Uwe Ligges a écrit :



On 13.01.2024 15:01, Uwe Ligges wrote:
Fascinating, now it worked with the latest winbuilder submission 3 
times in a row when I checked it manually. So maybe Ivan was right 
and there was a very demanding set of other packages compiling at 
the same time?

I don't know.

Serge, Can you somply submit your latest winbuilder upload to CRAN?


Really, I inspected some more. The underlying issue is simple:
The C++ compiler used under Windows asks for precomitted memory. If 
several processes are running at the same time, a lot of memory is 
precomitted. And Windows does not use it for other processes, even if 
almost nothing is actually used.
So while the used memory may be around 50GB, all of the rest (of 756 
GB including swap space) may have been precomitted (but unused) and 
new processes failed to start correctly. G.


Best,
Uwe Ligges






Best,
Uwe Ligges



On 13.01.2024 14:12, Uwe Ligges wrote:

I can take a look, but not sure if I get to it before monday.
I haven't seen it for any other packages recently.

My suspicion is currently a strange mix of cmd.exe and sh.exe 
calls. But this is a very wild guess.


Best,
Uwe

On 13.01.2024 14:08, Uwe Ligges wrote:



On 13.01.2024 10:10, Ivan Krylov via R-package-devel wrote:

В Fri, 12 Jan 2024 21:19:00 +0100
Serge  пишет:

After somme minor midficiations, I make a try on the winbuilder 
site.

I was able to build the archive with the static library
but I get again a Bad address error. You can have a look to

https://win-builder.r-project.org/bw47qsMX3HTd/00install.out


I think that Win-Builder is running out of memory. It took some
experimenting, but I was able to reproduce something like this using
the following:

1. Set the swap file in the Windows settings to minimal recommended
size and disable its automatic growth

2. Write and run a program that does malloc(LARGE_NUMBER); 
getchar();

so that almost all physical memory is allocated

3. Run gcc -DFO

Re: [R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols

[Tomas Kalibera]

On 1/21/24 09:44, Ivan Krylov via R-package-devel wrote:

В Sat, 20 Jan 2024 20:28:00 -0500
Johann Gaebler  пишет:


most likely there’s some error on my part in how I’ve set up cpp11,
but it also seems possible that cpp11 should have detected that that
header needs to be included and added it automatically

Upon further investigation, it's more complicated than a missing
#include.

cpp11::cpp_register() uses
tools::package_native_routine_registration_skeleton() to generate these
declarations. This function works by scanning the R code for calls to
.Call(), .C(), .Fortran(), and others and then trying to come up with
appropriate prototypes for the native functions being called. For
.Call()s, the function must output the correct type of SEXP for every
argument in the generated declaration.

This works the right way, for example, in R-4.2.2 (2022-11-10) and
today's R-devel, but was broken for a while (e.g. in R-4.3.1 and
R-4.3.2), and the fix, unfortunately, hasn't been backported (not to
R-patched either): https://bugs.r-project.org/show_bug.cgi?id=18585

Thanks, ported now to R-patched.
Tomas


I can suggest three workarounds.

1. Edit src/cpp11.cpp on a separate "for-CRAN" branch and rebase it on
top of the main branch every time you update the package.

2. Install R-devel and use it to generate the source package. Strictly
speaking, this would go against the letter of the CRAN policy
(builds "should be done with current R-patched or the current
release of R"), but would at least follow its spirit (use the
version of R where the known package-building-related bug was fixed).

3. Add a configure script that would modify src/cpp11.cpp while the
package is being installed. This way, the only thing modifying
generated code would be more code, which is considered
architecturally pure by some developers.

Lots of ways to implement it, too: you can do it in a single shell
script (using sed or patch -- are these tools guaranteed to be
available?), delegate to tools/configure.R (that you would also
write yourself), or go full GNU Autoconf and generate a
megabyte-sized ./configure from some m4 macros just to replace one
line.

There is definitely a lot of performance art value if you go this
way, but extra code means extra ways for it to go wrong. For more
style points, make it a Makevars target instead of a configure
script.



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

Re: [R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols

[Tomas Kalibera]

On 1/22/24 15:42, Ivan Krylov via R-package-devel wrote:

On Mon, 22 Jan 2024 12:30:46 +0100
Tomas Kalibera  wrote:


Thanks, ported now to R-patched.

Thank you!

Is it fine to mention problems like this one in the middle of an
e-mail, or should I have left a note in the Bugzilla instead?

In this case a comment on bugzilla would have been well justified: it 
was a regression, fixed many months ago, with a simple fix, so something 
quite clearly intended to be ported. In other cases the decision what to 
port and when may be harder.


Yes, inside a bigger email, reports can get overlooked, particularly 
when in a thread with a rather different subject. It wasn't overlooked 
this time thanks to Martin.


Tomas

__
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

[Tomas Kalibera]

On 2/12/24 01:35, Simon Urbanek wrote:

Just to include the necessary details: macOS CRAN build uses Apple clang-14, so 
you cannot assume anything higher. Also the target is macOS 11 SDK.

That said, LLVM does not support the special math functions at all according to 
the status report (see Mathematical Special Functions for C++17 at 
https://libcxx.llvm.org/Status/Cxx17.html) so Boost is your best bet.

BTW: this is not a Mac thing - you can replicate it on any other system, eg. in 
Linux:

$ clang++-17 -std=c++17 -stdlib=libc++  bes.cc
bes.cc:11:49: error: no member named 'cyl_bessel_k' in namespace 'std'
11 | std::cout << "K_.5(" << x << ") = " << std::cyl_bessel_k(.5, x) << 
'\n'
   |~^
bes.cc:13:35: error: no member named 'cyl_bessel_i' in namespace 'std'
13 |   << (pi / 2) * (std::cyl_bessel_i(-.5, x)
   |  ~^
bes.cc:14:25: error: no member named 'cyl_bessel_i' in namespace 'std'
14 |  - std::cyl_bessel_i(.5, x)) / std::sin(.5 * pi) << 
'\n';
   |~^
3 errors generated.


And on Windows with LLVM 17, the experimental build of Rtools43 for 
Windows/aarch64.


Tomas



Cheers,
Simon



On 10/02/2024, at 8:04 AM, Marcin Jurek  wrote:

All this makes sense, thanks for your tips, everyone!

Marcin

On Fri, Feb 9, 2024 at 9:44 AM Dirk Eddelbuettel  wrote:


On 9 February 2024 at 08:59, Marcin Jurek wrote:
| 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.

There is an often overlooked bit of 'fine print': _compiler support_ for a
C++ standard is not the same as the _compiler shipping a complete library_
for that same standard. This can be frustrating. See the release notes for
gcc/g++ and clang/clang++, IIRC they usually have a separate entry for C++
library support.

In this case, can probably rely on LinkingTo: BH which has been helping
with
Boost headers for over a decade.

Writing R Extensions is also generally careful in reminding us that such
language standard support is always dependent on the compiler at hand. So
package authors ought to check, just like R does via its extensive
configure
script when it builds.

Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


[[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


__
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

[Tomas Kalibera]

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. 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

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

[Tomas Kalibera]

On 3/27/24 08:39, jesse koops wrote:

Of course you are correct about the portability. But since at ;least
one other CRAN package by a renowned author does it succesfully, I
figured I'd experiment first on my machine and learn about portability
later. Thank you for the links and the warning about the bug. I was
aware of that, however I am careful to only use the "loadu" and
"storeu" variants, so I thought this would not bite me. Do you know if
my assumption is in error?


My advice is please do not publish any packages doing this low level 
stuff unless you fully understand the details yourself. If you don't, 
please work at a higher level abstraction and use existing code for the 
low-level things, to avoid adding to the maintenance costs. These things 
can take very long to debug.


The GCC bug on Windows I've ran into only affects instructions that 
require aligned operands (on the stack), aligned at 32-byte boundary.


Tomas



Op di 26 mrt 2024 om 15:51 schreef Tomas Kalibera :


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. 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

Re: [R-pkg-devel] Flex missing in win-builder

[Tomas Kalibera]

On 5/28/24 06:18, drc via R-package-devel wrote:

Is it possible to get flex in the win-builder windows environment? It's present 
in the debian environment. My package depends on cmake, bison, and flex. Each 
of these are listed in the `SystemRequirments` field of my DESCRIPTION file but 
flex is the only one that cmake can't find.


Please see CRAN repository policy and contacts included there:
https://cran.r-project.org/web/packages/external_libs.html

But if possible I would include the generated parsers in the source code 
of your package. This is also how R itself does it.



The win-builder home page (https://win-builder.r-project.org/) doesn't say much 
about foreign dependencies other than we have what's available in Rtools plus a 
small list of others. But neither cmake or bison are available by default in 
Rtools, they both have to be explicitly installed with `pacman`. Flex can also 
be installed via `pacman`, so why are the other two available?


cmake is part of Rtools, please see
https://cran.r-project.org/bin/windows/base/howto-R-devel.html

Best Tomas

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

Re: [R-pkg-devel] "Writing R Extensions" manual needs update [was: Error handling in C code]

[Tomas Kalibera]

On 6/24/24 08:25, Agner Fog wrote:

Jarrod Hadfield wrote:


Using Rf_error() rather than error() fixed the problem. Not sure why the 
problem was only flagged on Debian, but it
seems to have been triggered by R_NO_REMAP being defined (which will be default 
in R 4.5.0).

I had the same problem. A lot of functions in my package 'BiasedUrn' had
to be changed to the Rf_ prefix names. It took me a long time to figure
out because I couldn't find proper documentation anywhere.

Apparently, the remapped function names can no longer be used. The
consequences of this change are far-reaching: /all /existing packages
containing C++ code must be modified to use the Rf_ function names for
/all /R API function calls.

This change is not properly documented. The "Writing R Extensions"
manual still lists the remapped function names without Rf_ prefix. This
manual needs to be updated to replace all remapped function names with
the Rf_ prefix names. I also think that it needs to add instructions on
how to fix legacy C++ code, including a list of the function names that
need to be changed. I cannot see where the change in R_NO_REMAP  is
documented.

I don't know why R_NO_REMAP is currently defined in Debian but not in
Windows, but the consequence is that the "Writing R Extensions" manual
must be updated now, and not wait for R version 4.5.0.

I think there should be a way to enable the remapped function names for
the sake of compatibility with legacy code. What should we do with old
packages where the maintainer is no longer contactable or is somebody
less competent than the original programmer?

Does it work to  #undef R_NO_REMAP  before  #include  ?

Let me suggest a simple solution: Define a preprocessing macro
R_FORCE_REMAP which can override R_NO_REMAP. Legacy C++ code can then be
fixed by adding a Makevars file with -DR_FORCE_REMAP

You may also reconsider the decision to add R_NO_REMAP as standard.

I have written to the maintainers and asked them to change the "Writing
R Extensions" manual, but got no reponse.


In principle it is the NEWS file that gives hints about important 
changes and then one can find the details in Writing R Extensions.  The 
NEWS file as of mid-April says that "R CMD check --as-cran" will compile 
C++ code with -DR_NO_REMAP. And then in Writing R Extensions, one can 
read about what is R_NO_REMAP and that this has been planned to become 
the default in the future. It is an important thing to do for the 
maintainability of the package space: the situation with name clashes 
with system headers (typically appearing just on some platforms) has 
only been getting worse.


Best
Tomas



- Agner
[[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] "Writing R Extensions" manual needs update [was: Error handling in C code]

[Tomas Kalibera]

On 6/24/24 09:45, Agner Fog wrote:

On 24/06/2024 08.56, Tomas Kalibera wrote:


In principle it is the NEWS file that gives hints about important 
changes and then one can find the details in Writing R Extensions.  
The NEWS file as of mid-April says that "R CMD check --as-cran" will 
compile C++ code with -DR_NO_REMAP. And then in Writing R Extensions, 
one can read about what is R_NO_REMAP and that this has been planned 
to become the default in the future. It is an important thing to do 
for the maintainability of the package space: the situation with name 
clashes with system headers (typically appearing just on some 
platforms) has only been getting worse.


Thanks, but I couldn't find it when I searched for help, and I still 
can't find the news you are mentioning. The "Writing R Extensions" 
guide does not list the required Rf_ function names. This manual 
definitely has to be changed.


The NEWS file is part of the source tree, e.g. 
https://svn.r-project.org/R/trunk/doc/NEWS.Rd


You can find a rendered version here:

https://cran.r-project.org/doc/manuals/r-release/NEWS.html
https://cran.r-project.org/doc/manuals/r-devel/NEWS.html



I predict chaos when you add R_NO_REMAP to the Windows compilation: A 
large number of old packages containing C++ code will fail. Mails will 
be sent to the maintainers. Some maintainers will be uncontactable. 
Some packages are maintained by somebody less competent than the 
original programmers. Some maintainers will be too busy to react, or 
they have forgotten how to submit a package. You will be bombarded 
with help requests. In the end, somebody will have to help update the 
packages when the maintainers fail to do so.


I am not the one working specifically on these changes, so I don't have 
the exact details, but in principle, what you describe is daily business 
of maintaining R and CRAN. All of what you describe has been considered 
and changes like this are carefully tuned and planned based on actually 
running checks of all CRAN packages on patched versions of R-devel, 
usually outside the master repository. There is a lot of effort behind 
such changes that may not be immediately visible.




This mess is a consequence of a bad decision many years ago when 
somebody used non-unique function names like "error" and "warning". 
But the world looked very different back then, and now we are facing 
the consequences.


It would be useful to do a test to see how many packages need to be 
changed.


As above, this is something being done routinely. And it is a moving 
target, too, in this case, as many packages run into naming conflicts 
and are being fixed. Often the package authors receive patches or hints 
how to fix from R Core or the CRAN team.


Tomas


- Agner



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

Re: [R-pkg-devel] Properly referencing copied code

[Tomas Kalibera]

On 7/13/24 12:24, Simon Urbanek wrote:



On 12 Jul 2024, at 10:07, Ivan Krylov via R-package-devel 
 wrote:

В Thu, 11 Jul 2024 20:58:53 +
DRC via R-package-devel  пишет:


1. How does linking to external libs differ from providing the source
of a library and linking against that?

I think that the author information in the DESCRIPTION is about what your package 
provides by itself, not everything that may end up in the address space once the 
package is loaded. Since CRAN prefers self-contained packages, we end up including them 
in our packages (unless the third-party library is already very common and present in 
RTools & macOS recipes & common GNU/Linux distros), which requires us to 
specify their authors.



To clarify: as far as CRAN is concerned you only need to include sources that 
are otherwise not commonly available - or if you need to modify them for the 
purpose of the package, so it should be quite rare. In fact the CRAN policy 
states that a package should always look for an available library first. If we 
just are talking about libraries then a very rough rule of thumb is that if 
your dependent library is in Debian then you don't need to ship it as sources.

That said, if you are using something that is not in the current Rtools/recipes 
then you have to tell CRAN so we can be add it to macOS and Windows toolchains 
(assuming both are supported by the library you need) - but that doesn't mean 
you should ship them yourself (in fact that tends to cause a lot more problems).


And you can indeed help with adding such library to Rtools/recipes. In 
case of Rtools, ideally first add it upstream to MXE.


Best
Tomas



Cheers,
Simon

__
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] Re: try() in R CMD check --as-cran

[Tomas Kalibera]

The advantage of "abort" (R_Suicide) over the default (R error) is that 
it cannot be caught accidentally, so that one can detect more errors, 
and it may be easier to find where the error happened. To make the 
default behavior less surprising/more user friendly, and to allow 
intentional catching of these errors, the default for R CMD check 
--as-cran was changed in R-devel so that the normal R error is thrown, 
and the documentation in R Internals updated accordingly. One thus has 
to set the variable explicitly to get the stricter checks.


Best
Tomas

On 6/7/19 8:51 PM, Tierney, Luke wrote:

A simplified version without a package:

Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_"="abort,verbose")
tryCatch(1:3 || 1, error = identity)

Running this aborts the session since it calls R_Suicide without first
signaling a condition to try any available handlers. Should be easy to
change, but I don't know if there are any downsides for the CRAN
workflow. I'll look into it.

Best,

luke


On Fri, 7 Jun 2019, William Dunlap wrote:


I've attached a package, ppp_0.1.tar.gz, which probably will not get
through to R-help, that illustrates this.
It contains one function which, by default, triggers a condition-length>1
issue:
   f <- function(x = 1:3)
   {
   if (x > 1) {
   x <- -x
   }
   stop("this function always gives an error")
   }
and the help file example is
   try(f())

Then
   env _R_CHECK_LENGTH_1_CONDITION_=abort,verbose R-3.6.0 CMD check
--as-cran ppp_0.1.tar.gz
results in
* checking examples ... ERROR
Running examples in ‘ppp-Ex.R’ failed
The error most likely occurred in:


base::assign(".ptime", proc.time(), pos = "CheckExEnv")
### Name: f
### Title: Cause an error
### Aliases: f
### Keywords: error

### ** Examples

try(f())

--- FAILURE REPORT --
--- failure: the condition has length > 1 ---
--- srcref ---
:
--- package (from environment) ---
ppp
--- call from context ---
f()
--- call from argument ---
if (x > 1) {
x <- -x
}
--- R stacktrace ---
where 1: f()
where 2: doTryCatch(return(expr), name, parentenv, handler)
where 3: tryCatchOne(expr, names, parentenv, handlers[[1L]])
where 4: tryCatchList(expr, classes, parentenv, handlers)
where 5: tryCatch(expr, error = function(e) {
call <- conditionCall(e)
if (!is.null(call)) {
if (identical(call[[1L]], quote(doTryCatch)))
call <- sys.call(-4L)
dcall <- deparse(call)[1L]
prefix <- paste("Error in", dcall, ": ")
LONG <- 75L
sm <- strsplit(conditionMessage(e), "\n")[[1L]]
w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w")
if (is.na(w))
w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L],
type = "b")
if (w > LONG)
prefix <- paste0(prefix, "\n  ")
}
else prefix <- "Error : "
msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))
if (!silent && isTRUE(getOption("show.error.messages"))) {
cat(msg, file = outFile)
.Internal(printDeferredWarnings())
}
invisible(structure(msg, class = "try-error", condition = e))
})
where 6: try(f())

--- value of length: 3 type: logical ---
[1] FALSE  TRUE  TRUE
--- function from context ---
function (x = 1:3)
{
if (x > 1) {
x <- -x
}
stop("this function always gives an error")
}


--- function search by body ---
Function f in namespace ppp has this body.
--- END OF FAILURE REPORT --
Fatal error: the condition has length > 1
* checking PDF version of manual ... OK
* DONE

Status: 1 ERROR, 1 NOTE
See
  ‘/tmp/bill/ppp.Rcheck/00check.log’
for details.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Jun 7, 2019 at 10:21 AM Duncan Murdoch 
wrote:


On 07/06/2019 12:32 p.m., William Dunlap wrote:

The length-condition-not-equal-to-one checks will cause R to shutdown
even if the code in a tryCatch().

That's strange.  I'm unable to reproduce it with my tries, and John's
package is no longer online.  Do you have an example I could look at?

Duncan Murdoch


Bill Dunlap
TIBCO Software
wdunlap tibco.com 


On Fri, Jun 7, 2019 at 7:47 AM Duncan Murdoch mailto:murdoch.dun...@gmail.com>> 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)

 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 ---
 >>
  

Re: [R-pkg-devel] access is denied

[Tomas Kalibera]

If you have not already done so, I'd check the package directory (and 
its parent) is not opened in any application, including Windows 
Explorer, including current working directory in any command prompt. I'd 
also make sure the package is not loaded in any R session. The error 
message may be caused by that the file or directory is locked.


Best
Tomas

On 6/20/19 5:49 PM, Dennis Boos wrote:

Developers,

I recently was successful getting a package into CRAN with your help.
But now I'm working on a second package and am stuck immediately.  Here
is what I have done.

1. Created the base package using http://r-pkgs.had.co.nz/package.html
to get started.
2. Then


library(devtools) > document() Updating fsr documentation First time

using roxygen2. Upgrading automatically... Error in
normalizePath(path.expand(path), winslash, mustWork) :
path[1]="\\wolftech.ad.ncsu.edu\cos\stat\Redirect\boos\Documents\srcis\fsr.package\fsr":
Access is denied In addition: Warning messages: 1: In
normalizePath(path.expand(path), winslash, mustWork) :
path[1]="\\wolftech.ad.ncsu.edu\cos\stat\Redirect\boos\Documents\srcis\fsr.package\fsr":
Access is denied 2: In normalizePath(path.expand(path), winslash,
mustWork) :
path[1]="\\wolftech.ad.ncsu.edu\cos\stat\Redirect\boos\Documents\srcis\fsr.package\fsr/DESCRIPTION":
Access is denied


What am I missing?  I didn't have this problem before.  I have
re-downloaded RStudio and Rtools, but get the same results.

Dennis



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

Re: [R-pkg-devel] implications of staged install for data processing packages

[Tomas Kalibera]

On 6/28/19 5:16 PM, Florian Oswald wrote:

oh ok i see: so i will always be able to do

clean(path = "~/data.csv")

for example? in that case I completely misunderstood this and there must
indeed be some system.file call buried somewhere. will check. thanks!


In case it is hard to find manually, there is a script at 
https://github.com/kalibera/rstagedinst (described also in the blog post 
about staged install), which finds variables holding hard-coded paths to 
the temporary installation directory. Please give a reproducible example 
(e.g. the package, output from the script, output from the installation 
with the error, etc) if you needed more help.


Best
Tomas



Florian

On Fri, 28 Jun 2019 at 17:11, Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:


You need to give details what exactly gets you into trouble and about your
use case, since any advice would be conditional on making assumptions about
that. It is usually a bad a idea to have a function working on a hardcoded
full filename. You will thank yourself later if you at least make it
argument to your function(s). It can have for default value the one that is
currently hardcoded.

Please note that your use case does not seem inherently related to staged
installation.
"Hardcoded" in the context of staged installation does not refer to any
hardcoded path
but to those paths that contain the temporary installation directory. Such
paths can be obtained,
for example, with calls to system.path(), as illustrated by Tomas.

Georgi Boshnakov



-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of Florian Oswald
Sent: 28 June 2019 09:17
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] implications of staged install for data processing
packages

Hi all

I ran into trouble with the changes starting to come in with R3.6 stemming
from the new staged installation, which checks and errors on hard coded
paths in R code. I understand there is an opt out, but still want to know.
here's the blog post:
https://developer.r-project.org/Blog/public/2019/02/14/staged-install/

I have several packages which look like that:

1. large messy dataset stored on disk as `filename`, maybe a csv.
2. R package has a function `clean(filename)` which reads the data and
brings it into useable form
3. R package does analysis
4. R package exports results

`filename` is hard coded. What is the proper way to do this instead? Should
I store the inital raw data inside the R package in `/inst`? These things
are typically very large, so I like to decouple the raw data from the
package (easier to share).

thanks for any suggestions!

 [[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] Warning about "serialize/load".

[Tomas Kalibera]

On 7/15/19 2:06 AM, Travers Ching wrote:

I think the major change was saving of alt-rep objects efficiently.
Example save(1:1e8, file=...) is very efficient.

I'm not sure if that is all that changed it, but I couldn't find
documentation on the differences.


Yes, format version 3 provides custom serialization for altrep objects, 
so that it can e.g. serialize efficiently integer sequences. In 
addition, it keeps record of the current native encoding when 
serializing strings, so that it can convert strings with unflagged 
encoding when de-serializing them with different native encoding. So for 
example if a string with current native encoding X (not being latin1, 
and indeed not UTF-8) on Windows gets serialized, and then de-serialized 
on Linux running UTF-8 as current native encoding, it would be converted 
to UTF-8. In previous versions, it would be misinterpreted.


Best
Tomas



For maximum compatibility in a package, personally I would use version 2.


On Sun, Jul 14, 2019 at 4:52 PM Rolf Turner  wrote:


In a package (say "clyde") that I am building I save a number of
datasets in clyde/data via something like:

save(melvin,file="~//clyde/data/melvin.rda")

When I build "clyde" I now get warnings like unto:


uWARNING: Added dependency on R >= 3.5.0 because serialized objects in
serialize/load version 3 cannot be read in older versions of R.
File(s) containing such objects: 'clyde/data/melvin.rda'

If I put the argument "version=2" into my save() call, the warnings go
away.

What are the implications of this?

What are the consequences/what is the downside of setting version=2?

What are the consequences/what is the downside of adding the dependency
on R >= 3.5.0 into my DESCRIPTION file?

Who gets shafted by each of these two possibilities?

Which is recommended?

Grateful for any pearls of wisdom.

cheers,

Rolf Turner

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

__
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] Single character in Fortran function and FCONE and FCLEN macros

[Tomas Kalibera]

On 9/3/19 3:07 PM, Benjamin Christoffersen wrote:
> Dear Sirs,
>
> I have tried to update my 'dynamichazard' package on CRAN but I have
> had some issues with the '-Wlto-type-mismatch' checks. In particular,
> I have tried to follow "Writing R Extensions" section "Fortran
> character strings" and defined a C++ header file
> (https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/Rconfig-wrap.h)
> with the following content
>
>> #ifndef RCONFIG_WRAP_H
>> #define RCONFIG_WRAP_H
>> #define USE_FC_LEN_T
>> #include 
>>
>> #ifndef FCLEN
>> #define FCLEN
>> #endif
>> #ifndef FCONE
>> #define FCONE
>> #endif
>>
>> #endif

I'd try following WRE on this exactly: include R_ext/BLAS.h and only 
after that define FCONE (if not defined) - and FCLEN if you need it as 
well.

> which I include before including 'R_ext/BLAS.h' and 'R_ext/Lapack.h'
> files. I then make the following C declaration of the Fortran
> subroutine that causes the issue
> (https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/BLAS_LAPACK/R_BLAS_LAPACK.cpp#L2-L29)
>
>> extern "C"
>>{
>>  void F77_NAME(dchur)(
>>  const char*,   // UPLO
>>  const char*,   // TRANS
>>  int*,// N
>>  int*,// M
>>  double*, // R
>>  int*,// LDR
>>  double*, // X
>>  double*, // Z
>>  int*,// LDZ
>>  double*, // Y
>>  double*, // RHO
>>  double*, // C
>>  double*, // S
>>  int* // INFO,
>>  FCLEN FCLEN
>>  );
>>}
> Lastly, I use the 'FCONE' macro when calling the function. The Fortran
> subroutine (a LINPACK subroutine) is defined in this file:
> https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/BLAS_LAPACK/dchur.f#L7
>
> I gather the above is as done in the BLAS and LAPACK header in R. Yet,
> I still got a mail in the CRAN submission stating that
>
>> We see
>>
>> * checking whether package ‘dynamichazard’ can be installed ...
>> [207s/211s] WARNING
>> Found the following significant warnings:
>> BLAS_LAPACK/R_BLAS_LAPACK.cpp:12:10: warning: type of ‘dchur_’ does
>> not match original declaration [-Wlto-type-mismatch]
>>
>> and there's also
>>
>> BLAS_LAPACK/R_BLAS_LAPACK.cpp:12:10: warning: type of ‘dchur_’ does not
>> match original declaration [-Wlto-type-mismatch]
>>  12 | void F77_NAME(dchur)(
>> |  ^
>> BLAS_LAPACK/dchur.f:7:1: note: type mismatch in parameter 15
>>   7 |   SUBROUTINE DCHUR(UPLO,TRANS,N,M,R,LDR,X,Z,LDZ,Y,RHO,C,S,INFO)
>> | ^
>> BLAS_LAPACK/dchur.f:7:1: note: type ‘long int’ should match type ‘void’
>> BLAS_LAPACK/dchur.f:7:1: note: ‘dchur’ was previously declared here
> I am not sure how to handle the issue. I am sorry if I am doing
> something which is obviously wrong.
I'd try debugging this with gcc -E, checking whether the FCLEN and FCONE 
macros work as intended. If the build process of the package seemed too 
complicated for that, you could also look at the disassembly for the 
calls, or compile with -fdump-tree-all  and look at the gfortran/gcc 
diagnostic files to see if the calls include the hidden 1s. The output 
seems to suggest that the macros have not been defined properly.||
> I also got some messages about the declarations in RcppArmadillo but I
> gather these are upstream issues which I cannot do anything about
>> /home/Hornik/tmp/R-d-gcc-LTO/include/R_ext/Lapack.h:1584:1: warning: 
>> ‘dtrtri_’ violates the C++ One Definition Rule [-Wodr]
>>   1584 | F77_NAME(dtrtri)(const char* uplo, const char* diag,
>>| ^
>> /home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8:
>>  note: type mismatch in parameter 7
>>421 |   void arma_fortran(arma_dtrtri)(const char* uplo, const char* 
>> diag, const blas_int* n, double* a, const blas_int* lda, blas_int* info, 
>> blas_len uplo_len, blas_len diag_len);
>>|^
>> /home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8:
>>  note: type ‘blas_len’ should match type ‘void’
>> /home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8:
>>  note: ‘dtrtri_’ was previously declared here
>> /home/Hornik/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:242:1: warning: ‘dsyrk_’ 
>> violates the C++ One Definition Rule [-Wodr]
>>242 | F77_NAME(dsyrk)(const char *uplo, const char *trans,
>>| ^
>> /home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_blas.hpp:110:8:
>>  note: type mismatch in parameter 11
>>110 |   void arma_fortran(arma_dsyrk)(const char* uplo, const char* 
>> transA, const blas_int* n, const blas_int* k, const double* alpha, const 
>> double* > A, const blas_int* ldA, const double* beta, double* C, const 
>> blas_int* ldC, blas_len uplo_len, blas_len transA_len);
>>   

Re: [R-pkg-devel] Linking with OpenBLAS complains lapacke not found

[Tomas Kalibera]

Please refer to BLAS_LIBS, LAPACK_LIBS in Writing R Extensions. For an 
example package that uses BLAS/LAPACK, see e.g. "stats" or "Matrix". The 
package will then use the BLAS/LAPACK implementation as chosen by the 
user/system administrator at dynamic linking time (see R Installation 
and Administration Manual for the defailts) - be it say reference BLAS, 
OpenBLAS, MKL or other; as a package author, one does not have to care 
which one it is.


Best
Tomas

On 9/8/19 2:22 PM, Sameh M. Abdulah wrote:

Brian,

This is the code I am using to linking with BLAS using MKL or OpenBLAS

#MKL
if [ -n "$MKLROOT" ] && [ -d "$MKLROOT" ]; then
 echo "mkl_dir directory exists!"
 echo "Great... continue set-up"
 source ${MKLROOT}/bin/mklvars.sh intel64
 DEFINE_BLAS_LIBS_CMAKE="-DBLAS_LIBRARIES='-L${MKLROOT}/lib 
-Wl,-rpath,${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lpthread -lm 
-ldl'"
 #DEFINE_BLAS_LIBS_CMAKE="-DBLAS_LIBRARIES='-L${MKLROOT}/lib\ 
-Wl,-rpath,${MKLROOT}/lib\ -lmkl_intel_lp64\ -lmkl_sequential\ -lmkl_core\ -lpthread\ 
-lm\ -ldl'"
 XFLAG="-DBLA_VENDOR=Intel"
else
 echo "MKL not found, trying to compile and use OpenBLAS"
 XFLAG="-DBLA_VENDOR=Open"
 USE_OPENBLAS='true'
fi

# openblas
if [ "true" == "$USE_OPENBLAS" ]
then
 if pkg-config --exists openblas
 then
 _LOCATION=`pkg-config --variable=libdir openblas`
 echo "OpenBLAS FOUND in [$_LOCATION]"
 else
 if [ "$BUILD_DEPENDENCIES" == "true" ]
 then
 echo "Building OpenBLAS..."
 cd $TMPDIR
 wget https://github.com/xianyi/OpenBLAS/archive/v0.3.3.tar.gz -O - 
| tar -zx
 cd OpenBLAS-0.3.3
 $MAKE -j  >/dev/null|| $MAKE || { echo 'OpenBLAS installation 
failed' ; exit 1; }
 $MAKE install PREFIX=$PREFIX
 export CPATH=$CPATH:$PREFIX/include
 else
 echo ""
 echo "OpenBLAS NOT FOUND"
 echo "Please download it from: 
https://github.com/xianyi/OpenBLAS/releases";
 echo "After installing it, set the proper PKG_CONFIG_PATH variable"
 echo ""
 err=1
 fi
 fi
fi


It works great but when OpenBLAS is using, my application cannot find lapacke 
library.



On 9/8/19, 2:28 PM, "Brian G. Peterson"  wrote:

 On Sun, 2019-09-08 at 10:04 +, Sameh M. Abdulah wrote:
 > I am linking my package against openblas but it complains that
 > lapacke is not found which I need for the installation.
 >
 > I have another alternative to linking against MKL but I cannot find
 > it using MKLROOT variable on CRAN servers.
 
 It isn't entirely clear what your question is, but shouldn't you just

 be linking to the BLAS and leave the choice of BLAS to the individual
 installation?  In most cases you should probably not be statically
 linking to the BLAS.
 
 Here is an old paper by Dirk with more information that might help you

 sort it out.
 
 https://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf
 
 Regards,
 
 Brian
 
 --

 Brian G. Peterson
 ph: +1.773.459.4973
 im: bgpbraverock
 
 


__
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] R, BLAS, and FCLEN (solved)

[Tomas Kalibera]

Dear Göran,

I can reproduce the problem with eha version 2.6.0. The reason for the 
type mismatch, and hence the LTO warning, is _not_ the calls to dgemv 
from Fortran code, but the calls to dgemv from the C code from the other 
source files in your package. There is no need to go through wrappers 
when calling dgemv from Fortran (as long as both modules are compiled 
with the same compiler, or with compatible compilers).


When you fix all the calls to dgemv in your C source files to use 
"FCONE", as documented in WRE, the warning about the call to dgemv from 
geomsup.f will go away (yes, the warnings from the LTO linker/compiler 
are confusing). There is no need for creating any wrappers for 
BLAS/LAPACK calls.


One can check that the generated calls from the Fortran are correct e.g. 
via compiling with -fdump-tree-all and then dumping

$ egrep -e '(^;;)|(dgemv)' eha.so.ltrans0.232t.optimized | grep dgemv -B1
(the file name above will depend on the exact version of your compiler)

;; Function d2_loglik_ph (d2_loglik_ph, funcdef_no=77, decl_uid=4474, 
cgraph_uid=103, symbol_order=990)
  dgemv_ (&trans, mb_497(D), nn_499(D), &alf, z_502(D), mb_497(D), 
b_503(D), &one, &Rf_beta, ezb_501, &one);

--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87, 
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
  dgemv_ (&trans, mb_253(D), nn_255(D), &alf, z_258(D), mb_253(D), 
b_259(D), &one, &Rf_beta, ezb_257, &one);

--
;; Function gmlfun (gmlfun_, funcdef_no=98, decl_uid=4484, 
cgraph_uid=108, symbol_order=874)
  dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_68(D), antcov_63(D), &C.7966, 
covar_83(D), nn_68(D), beta_84(D), &C.7965, &C.7964, score_81(D), 
&C.7963, 1);

--
;; Function geomsup (geomsup_, funcdef_no=116, decl_uid=4498, 
cgraph_uid=117, symbol_order=823)
  dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_55(D), antcov_51(D), &C.9626, 
covar_89(D), nn_55(D), startbeta_83(D), &C.9625, &C.9624, score_87(D), 
&C.9623, 1);

--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph_uid=7, 
symbol_order=1772)
  dgemv_ (&trans, &nn, &p, &one, covar_281(D), &nn, beta_340(D), &ione, 
&one, score_230, &ione);


You can see that the calls to dgemv from gmlfun and geomsup are fine 
(from Fortran code), the other are bad (from C code).  Indeed, one would 
have found out also by creating a minimal reproducible example - it is 
always useful, even when not attempting to report a bug.


Best
Tomas

On 9/13/19 12:07 AM, Göran Broström wrote:



On 2019-09-12 09:13, Martin Maechler wrote:

Göran Broström
 on Wed, 11 Sep 2019 13:36:40 +0200 writes:


 > A followup question: Is it possible to call a BLAS/LAPACK 
subroutine,
 > where one parameter is character, from FORTRAN (77) code 
called by

 > .Fortran? (No problem "in the past".)

[as there wasn't a reply till now : ]

Yes, that should continue to be possible.

 > And if yes, how?

I'm sorry I don't know (and currently lack the time to try to find 
out)...


I solved it by writing a C wrapper (for the BLAS subroutine dgemv) 
cdgemv:


#define USE_FC_LEN_T
#include 
#include 
#ifndef FCONE
# define FCONE
#endif
#include 
#include "cdgemv.h"

void F77_SUB(cdgemv)(const int *trans, const int *m, const int *n,
 const double *alpha, const double *a,
 const int *lda,
 const double *x, const int *incx,
 const double *beta,
 double *y, const int *incy){
   char trams;

   if (*trans == 1){
  trams = 'N';
  F77_CALL(dgemv)(&trams, m, n, alpha, a, lda, x, incx, beta, y,
  incy FCONE);
   }else
  Rprintf("trans has wrong value\n");
   }
}

which I call from Fortran. Curiously, a Fortran wrapper also seems to 
work.


G,


Martin

 >   Documentation describes calls from C to Fortran and
 > vice versa, but not this situation (AFAICS).

 > Yes, I know that .Fortran is not well seen these days, but my 
fortran
 > code is ancient, from the before-R era, and I would like to 
leave it as-is.


 > G,

 > Den 2019-09-01 kl. 21:46, skrev Göran Broström:
 >>
 >>
 >> On 2019-08-31 18:47, Göran Broström wrote:
 >>> I'm having difficulties updating my package eha: When I run 
standard
 >>> checks 'at home' everything is fine, but 'CRAN-submissions' 
reports

 >>> (among other things):
 >>>
 >>> geomsup.f:324:9: warning: type of ‘dgemv’ does not match 
original

 >>> declaration [-Wlto-type-mismatch]
 >>>    324 |  & one, score, ione)
 >>>    | ^
 >>> /home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type 
mismatch

 >>> in parameter 12
 >>>    107 | F77_NAME(dgemv)(const char *trans, const int *m, 
const int *n,

 >>>    | ^
 >>>
 >>> This is odd since the LAPACK subroutine dgemv takes only 11
 >>> parameters. However, in include/R_ext/BLAS.h we have
 >>>
 >>> F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 >>>  const do

Re: [R-pkg-devel] My test passes in OSx on Travis, but not in OSx on CRAN

[Tomas Kalibera]

The error seems to be because you are trying to write to the user's home 
directory. This is not allowed. Probably by accident your test creates 
"~/testcsv4.csv" (the same problem is present for other test files).


Best
Tomas

On 9/13/19 1:21 PM, Vincent van Hees wrote:

Dear all,

I have a test in my R package that passes in OSx on Travis-CI, but it does
not pass in OSx on CRAN. What does pass on both CRAN and Travis are the
Linux tests. Also, on CRAN the Windows flavor passes. So, there seems to be
an issue specific to the combination OSx and CRAN.

The easiest solution for me would be to add 'skip_on_cran()' at the top of
the test, but that would blind me for serious issues (if any). I already
made sure that the seeds are set before random number generators and that
value checks are limited to 3 decimal places to deal machine precision
issues. Does anyone have suggestions for me on what else I can do to
investigate this?

Link

to the specific test on GitHub. The function that is being tested first
creates dummy csv-files with random data and then checks that my wrapper
function around data.table() is able to read and interpret those dummy
files.
Link  to
CRAN results
Link  to Travis-CI page for the package

I have a local Windows and Linux machine, but for OSx testing I depend on
Travis-CI.

Thanks,
Vincent

[[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] Warning in system2(..., stdout = FALSE, stderr = FALSE) :, '"pdflatex"' not found

[Tomas Kalibera]

On 9/19/19 6:29 AM, Spencer Graves wrote:
Update: A web search for 'installing pdflatex for "R CMD" on Windows 
10?' suggested I install MiKTeX.  I did that from miktex.org, and it 
got me past that error.  Spencer


Please note these things are documented in R Installation and 
Administration Manual (see Appendix D)


Best
Tomas



On 2019-09-19 01:50, Spencer Graves wrote:

Hello, All:


  What's the recommended way to get pdflatex installed on Windows
10 to run "R CMD"?


  I ask, because "R CMD build bssm" under Windows 10 produced
'Warning in system2(..., stdout = FALSE, stderr = FALSE) : '"pdflatex"'
not found'.


  This was after installing Rtools using the following (recommended
by
"https://thecoatlessprofessor.com/programming/cpp/installing-rtools-for-compiled-code-via-rcpp/";): 





install.packages("installr")
library("installr")
install.Rtools()


  Below please find the output in a commands window including
"sessionInfo()".


      Thanks,
      Spencer Graves


>R CMD build bssm
* checking for file 'bssm/DESCRIPTION' ... OK
* preparing 'bssm':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... ERROR
--- re-building 'bssm.Rmd' using rmarkdown
[WARNING] Note with key '1' defined at line 318 column 1 but not used.
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
  '"pdflatex"' not found
Error: processing vignette 'bssm.Rmd' failed with diagnostics:
Failed to compile bssm.tex. See https://yihui.name/tinytex/r/#debugging
for debugging tips.
--- failed re-building 'bssm.Rmd'

--- re-building 'growth_model.Rmd' using rmarkdown
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
  '"pdflatex"' not found
Error: processing vignette 'growth_model.Rmd' failed with diagnostics:
Failed to compile growth_model.tex. See
https://yihui.name/tinytex/r/#debugging for debugging tips.
--- failed re-building 'growth_model.Rmd'

SUMMARY: processing the following files failed:
  'bssm.Rmd' 'growth_model.Rmd'

Error: Vignette re-building failed.
Execution halted

C:\Users\spenc\Documents\R\bssm\bssm>
C:\Users\spenc\Documents\R\bssm\bssm>pdflatex
'pdflatex' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\spenc\Documents\R\bssm\bssm>r

R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
[1] compiler_3.6.1

[[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


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

Re: [R-pkg-devel] Fwd: Reproducing CRAN pre-tests

[Tomas Kalibera]

On 9/20/19 2:43 AM, Aravind J. wrote:

Hi,

I was able to fix the issue and submit my package successfully to CRAN.

However, the question remains, is there any way to replicate the CRAN
pre-tests locally for future debugging, particularly in a windows
environment?

I had tried rhub platforms without any success.


As this is in a recurring question I am offering a bit more detailed 
advice. In summary the setups of the CRAN systems are documented, so one 
can create easily a similar setup in a container or use those say from 
r-hub. But if that doesn't help to reproduce for whatever reason, my 
advice is don't focus too much on trying to replicate exactly the CRAN 
checking system, often it does not help to find the problem. The CRAN 
outputs have been tuned to include all necessary information.


https://cran.r-project.org/web/checks/check_flavors.html describes the 
architectures/compilers used and more information in "Details".


https://cran.r-project.org/web/checks/check_issue_kinds.html describes 
setups for additional checks (valgrind, asan, ubsan, ..).


If you can't reproduce in a container that tries to mimic some of these 
configurations, it does not necessarily mean that the container is not 
configured properly - some errors are non-deterministic or depend 
(deterministically) on things you can't control. This should not be the 
case of compiler warnings, though, I usually can reproduce these with 
the specific compiler with the same or newer version, usually even on a 
different Linux distribution or even on Windows, but rarely the 
distribution matters where it also depends say on system headers. With 
most warnings from the compiler one should be able to fix without being 
able to reproduce, only in a few cases (including -Wstringop-overflow 
though) it can be hard. Of course one has to enable the warnings that 
are not normally enabled by default.


With other kinds of errors one gets sufficiently detailed output that 
there is no need trying to reproduce the checking process. E.g. for 
memory errors with asan/ubsan/valgrind/rchk, one always has to read the 
code around the locations mentioned, no matter what, until one finds the 
error manually and fixes it. It is easy to see that something is an 
error in this case once found, and as soon as it is plausible the error 
fixed is the one reported in the CRAN outputs, I'd just check the 
package using usual means and submit a new version of the package. 
Iterating on the code, making inconsequential changes until the tool is 
happy, might lead and often does to hiding the error instead of fixing 
it, also one does not learn much from that. When one does not run the 
tool locally, the temptation is not there.


With say segfaults being able to reproduce is very important, but there 
running in a container even carefully set up to mimic the check system 
often will not help, the result is often non-deterministic. One needs to 
provoke the error on whatever system, gctorture often helped me in such 
cases, but often one has to experiment with different variants of say 
the R code example during which the segfault happened, or with different 
external libraries (say LAPACK), or with slightly different inputs. This 
is hard work, success rate increases with experience - there is no 
simple trick around it. Trying to literally mimic the test system beyond 
some point to which it is easy is often a waste of time here, I often 
instead intentionally run on many different platforms from the tested 
one, often getting in the end a reproducible crash in a different 
configuration from the one used by CRAN.  With segfaults one can also 
already switch to debug-friendly build (debug symbols, I prefer with no 
compiler optimizations) before trying the process of provoking the bug; 
if you provoke it in an optimized build, but then switch to a 
debug-friendly build, it often scares the bug away, especially the type 
of bugs that are hard to find. With segfaults and other bugs that 
require debugging, running in an external service, modifying the code to 
add checks and assertions, or even in a stripped down container, is not 
always helpful (one has to install tools for the debugging, sometimes 
this means also upgrading packages, one cannot easily do some kind of 
debugging in Docker in the default security setup). It is best to try to 
provoke the error first on the system where one normally does all 
development and debugging.


Tomas



Warm Regards


On Thu, 19 Sep 2019 at 16:45, Duncan Murdoch 
wrote:


On 19/09/2019 6:51 a.m., Aravind J. wrote:

Hi,

I am trying to submit an updated version of my package PGRdup to CRAN.

The

package has compiled code in C.

I do development in a windows environment.

The update was to fix issues in
https://cran.r-project.org/web/checks/check_results_PGRdup.html.

I have successfully fixed PCRE2 compatability issues and the issue with "
‘strncpy’ specified bound depends on the length of the source argument".

For 

Re: [R-pkg-devel] unicode WARNING on solaris?

[Tomas Kalibera]

On 9/24/19 1:57 AM, Toby Hocking wrote:

Hi all,

is there a known fix for this WARNING which I am getting on solaris for my
newly submitted nc package?
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html


It seems that deparse() came across some non-printable characters. Such 
characters would be replaced by \U or \u escapes. This is implemented 
using wide characters in R, but on that platform __STDC_ISO_10646__ is 
not defined, so wchar_t has unknown representation (not known to be 
Unicode), hence the warning.


Best
Tomas



A quick google search for "it is not known that wchar_t is Unicode on this
platform cran" shows that many other packages have this WARNING as well.

I searched r-devel and r-pkg-devel for the warning text but I did not find
any messages discussing a fix.

Thanks for any help
Toby

[[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] Package or namespace load failed: undefined symbol

[Tomas Kalibera]

On 9/25/19 1:00 PM, Ralf Stubner wrote:

On Wed, Sep 25, 2019 at 10:29 AM Sameh M. Abdulah
 wrote:

I am installing OpenBLAS because I need LAPACKE libraries which I cannot find 
on the current version of OpenBLAS on CRAN.

I add the libraries directory in my package to the PKG_CONFIG_PATH. Is this 
enough for the system to use my OpenBLAS library?

I seem to be missing some context here. I might be able to help you if
provide a higher level description of what you are trying to achieve.
For example, why do you need LAPACKE instead of the C interface to
LAPACK provided by R_ext/Lapack.h? And if you really need LAPACKE, why
not include only that in your package and link with the BLAS/LAPACK
used by R?


Also with LAPACKE you will have the problem of (in)compatibility in 
calls from C to Fortran with the hidden length arguments for character 
arguments. It would be better to use LAPACK directly, passing the hidden 
length arguments as described in Writing R Extensions (the R-devel 
version of it, section 6.6.1). Or, if you wanted a standards-based 
solution, use iso_c_binding (also described in WRE). You would use the 
LAPACK already provided in the system (either reference from R, or any 
other as selected by administrator/user), not include it with your package.


Best
Tomas



cheerio
ralf

__
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] unicode WARNING on solaris?

[Tomas Kalibera]

On 9/25/19 7:59 PM, Toby Hocking wrote:
> Hi Tomas thanks for the explanation. Does that mean that there is no 
> known fix? i.e. it is OK to re-submit a new version of my package 
> without fixing these WARNINGS?

One way to fix would be to remove non-ASCII characters from the 
examples. I see \u4e8c \u4e09 \U0001F60E.
Tomas

>
> On Tue, Sep 24, 2019 at 1:38 AM Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 9/24/19 1:57 AM, Toby Hocking wrote:
> > Hi all,
> >
> > is there a known fix for this WARNING which I am getting on
> solaris for my
> > newly submitted nc package?
> >
> 
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html
>
> It seems that deparse() came across some non-printable characters.
> Such
> characters would be replaced by \U or \u escapes. This is implemented
> using wide characters in R, but on that platform
> __STDC_ISO_10646__ is
> not defined, so wchar_t has unknown representation (not known to be
> Unicode), hence the warning.
>
> Best
> Tomas
>
> >
> > A quick google search for "it is not known that wchar_t is
> Unicode on this
> > platform cran" shows that many other packages have this WARNING
> as well.
> >
> > I searched r-devel and r-pkg-devel for the warning text but I
> did not find
> > any messages discussing a fix.
> >
> > Thanks for any help
> > Toby
> >
> >       [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org
> <mailto: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

Re: [R-pkg-devel] How reproduce CRAN check

[Tomas Kalibera]

On 9/17/19 6:17 PM, Cristiane Hayumi Taniguti wrote:

Hello, thanks for all the answers.

I did the new tests with all suggestions.

I included the Rprintf in my script, however it did not show any NaN when
running with my examples (the same that CRAN check pointed the error)


The approach of adding a runtime check looking for NaNs should work. You 
can reproduce the problem (extracted from the vignette for which the 
CRAN checks report NaNs, tested on the CRAN version of the package):


---

library(onemap)
data("onemap_example_f2")
data("vcf_example_f2")
comb_example <- combine_onemap(onemap_example_f2, vcf_example_f2)
twopts_f2 <- rf_2pts(comb_example)
mark_all_f2 <- make_seq(twopts_f2, "all")

CHR_mks <- group_seq(input.2pts = twopts_f2, seqs = "CHROM", unlink.mks 
= mark_all_f2,

  repeated = FALSE)

---

With a smaller example like this, it is easier to iterate using added 
runtime checks. Also it is easier to debug as one can have it in an 
interactive R session.


Now one can check the "geno" vector before passed to the range 
constructor of std::vector, you will see it has "NaNs" as reported 
by UBSAN. One way to check is just add a function to the code that 
searches the vector and prints a message, and call it before the line 
indicated in the UBSAN reports


std::vector k_sub(&geno[i*n_ind],&geno[i*n_ind+n_ind]);

It turns out that when there is an NaN in the vector, all values are 
NaN. So it is natural to continue debugging in the surrounding R code. 
It turns out that  est_rf_f2 in cpp_utils.R sometimes gets called with a 
vector of integers (not doubles) and this vector has NAs, which are 
later converted to NaN.


So perhaps you could continue debugging from there using the R debugger 
and in an interactive session, and it might make sense to add some 
diagnostics to the C code to make it easier to debug similar problems 
later if they appear. At least it would be worth checking the type of 
the argument, this is fast and would detect that the type is integer 
instead of double. But perhaps it might make sense to check validity 
even of the individual elements.


Best
Tomas




The check in r-hub Debian Linux, R-devel, GCC ASAN/UBSAN
(linux-x86_64-rocker-gcc-san) did not show the error.

The r-debug seems to be a good tool, but I had problems to build my package
on it. First, the library libglu1-mesa-dev was missing for rgl package
installation, then, I installed it, but I  found the following errors when
trying to install the required MDSMap package:

"Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING."
and
"/usr/bin/ld: cannot find -lgfortran"

I did the modifications in rcpp files (update here<
https://github.com/Cristianetaniguti/onemap/commit/8d90eab994c9c5cc56202c2c15c5eae7c639315b>),
but I still can not test the package with it. Would be a problem if I
submit anyway?

On Fri, Sep 13, 2019 at 12:35 PM Iñaki Ucar  wrote:


On Fri, 13 Sep 2019 at 16:16, Cristiane Hayumi Taniguti
 wrote:

...twopts_f2.cpp:101:7: runtime error: nan is
outside the range of representable values of type 'int'
onemap.Rcheck/onemap-Ex.Rout:twopts_f2.cpp:101:26: runtime error: nan is
outside the range of representable values of type 'int'

Here:
https://github.com/augusto-garcia/onemap/blob/master/src/twopts_f2.cpp#L101
-> k1=segreg_type(i); k2=segreg_type(j);

k1 and k2 are vectors of integers, but segreg_type is a NumericVector
(double), which may contain NaN.

Iñaki


[[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] invalid multibyte string on solaris?

[Tomas Kalibera]

On 10/31/19 12:58 AM, Toby Hocking wrote:

Hi all, I am getting an "invalid multibyte string" error from one of my
examples when it is run on solaris, which results in check FAILURE:
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html

To fix this I guess I could just delete this example, but is there any
easy/known fix? I searched the r-devel and r-package-devel lists and I did
not find any relevant threads.

I also see that the same package on r-hub solaris is a check PASS:
https://builder.r-hub.io/status/nc_2019.10.19.tar.gz-8b46d2a02a6340bcb313eeec96e404f3

I was expecting that CRAN and r-hub solaris builds should report the same
results. What could be the difference? is this a bug in CRAN or in r-hub?


The configuration of the CRAN check machine is given at 
https://cran.r-project.org/web/checks/check_flavors.html#r-patched-solaris-x86 
(see the Details section). I cannot reproduce the problem on a Solaris 
machine I have access to (but it is yet a different configuration, so I 
am not surprised). The problem is that during substring(), the C library 
function mbrtowc() fails to convert a multi-byte coded string to a wide 
character, which is needed to know how many bytes are used. I am not 
sure why it fails without being able to reproduce, maybe the runtime 
library does not support Emoji, but of course there can be a bug in R, 
too. From the previous issue you have run into with Emoji, we know that 
the machine (compiler runtime) does not declare that wchar_t is Unicode.


Clearly, by using Emoji you are stress-testing R, packages, external 
libraries and the OS libraries, because these characters need surrogate 
pairs in UTF-16 but a lot of old code was written before they even 
existed, with all the problems of wchar_t.


Pragmatically, I would avoid using Emoji for these reasons in production 
systems. If you, instead, wanted to stress test R or libraries to find 
out where surrogate pairs were still not handled properly, it would be 
better to look for reproducible examples on systems you have access to 
and you can debug on your end. Some of these problems could be found 
simply by code inspection as well, though. We could then fix at places 
where it is easy or at least document in the code.


Best
Tomas


[[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] install.R running out of memory

[Tomas Kalibera]

On 11/3/19 1:05 PM, Viktor Gal wrote:

ah yeah i forgot to mention. it’s the same, i.e. it’s not the byte code 
compilation that causes this behaviour but the preparation for lazy loading.


R is not optimized for these cases (generated code, source file with 
>100,000 lines of code), but R has bindings for a large number of 
external libraries - it should be possible to make the bindings several 
orders of magnitude smaller and then they'd likely work well.


Making R work well on files like shogun.R would probably require a large 
amount of non-trivial work on R internals. I would be surprised if it 
were just say a memory leak we could fix and solve the issue quickly, it 
may well be that some data structures and algorithms simply won't scale 
to this extent. If you want to find out, you can debug using the usual R 
means (R profiler ?Rprof, run the script using ?source, perhaps 
disabling source references), but to interpret the results you may have 
to go deep into the implementation of R and in this case of S4.


Preparation for lazy loading starts by sourcing the file - with some 
details you can find out in the source code of installation and the 
documentation. I tried quickly and saw a lot of time spent in S4, which 
is not surprising as the generated file stresses S4 well beyond what is 
normally the case with R. But I would not be surprised if there were 
other bottlenecks to be seen later and even if you managed to prepare 
the package for lazy loading, there would probably be significant 
overheads at runtime. Still you could experiment with modifying the code 
generator to avoid the bottlenecks you identify.


If your primary goal is to create R bindings for an external library, 
I'd recommend having a look at how other packages do it to see what is 
scalable (there should be a way to make the code way smaller, and easily 
written by hand in most cases, even though some interfaces are 
generated, too).


Best
Tomas

cheers,
viktor


On 3 Nov 2019, at 06:53, Uwe Ligges  wrote:

What happens if you disable byte code compilation?

Best,
Uwe Ligges

On 02.11.2019 19:37, Viktor Gal wrote:

Hi Dirk,
no worries, thnx for the feedback!
cheers,
viktor

On 2 Nov 2019, at 13:58, Viktor Gal  wrote:

Hi Dirk,

so the project is open source, you can reproduce the error yourself (but note 
it’ll take a long time to actually compile it). steps for reproducing:
git clone https://github.com/shogun-toolbox/shogun.git
cd shogun
git checkout feature/shared_ptr
mkdir build
cd build
cmake -DINTERFACE_R=ON ..
make
make install

(it requires tons of dependencies… if you have docker you can docker pull 
shogun/shogun-dev and run things inside the container)

the make install part runs the R CMD INSTALL so that’ll cause the problem.

but i’ve just uploaded the generated R code that causes the problem here, note 
the script is 7Mb i.e. 175k LoC, so you better wget/curl it:
http://maeth.com/shogun.R

cheers,
viktor


On 2 Nov 2019, at 13:52, Dirk Eddelbuettel  wrote:


Hi Viktor,

On 2 November 2019 at 13:09, Viktor Gal wrote:
| I’m developing an ML library that has R bindings… when installing the library 
with R CMD INSTALL the R process is running out of memory (50G+ ram) when doing:
| ** byte-compile and prepare package for lazy loading
|
| any ideas how i could debug this part of code, to figure out what is actually 
happening and why is there a memory leak?

Easiest for us to help if we can see code -- so if you have a public repo
somewhere please the link.

I suspect you have some sort of recursion or circular dependency
somewhere. It would be very hard for R to run out of 50gb. But we cannot say
more.

So maybe triage. In a situation like this when a (supposedly complete)
package draft of mine fails "top-down" I often re-validate the toolchain
"bottom-up" with a minimal package. If that works, keep adding pieces step by
step from the 'not-working large package' to the 'small working' package
while continuously ensuring that it still builds.

Hope this helps, Dirk

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

__
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


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

Re: [R-pkg-devel] netcdf question

[Tomas Kalibera]

On 11/4/19 8:40 PM, Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:

Hi All:

I am wondering if it is possible to find out when packages that use the netcdf 
libraries are built on the CRAN machines (such as ncdf4) what versions of the 
netcdf library are being used on at least Mac and Windows?


Some libraries have that information included and available via their 
API and then the package API, e.g. ncdf4::nc_version()


Best
Tomas


If this is the wrong place to ask,  please point me to where I should ask.

Thanks,

-Roy

**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] Updating package with a dependency (rJava) that doesn't build on all flavours

[Tomas Kalibera]

On 11/13/19 10:19 AM, Tomáš Kliegr wrote:

Hello,

This question has not stirred much discussion ... If this is the wrong place to 
ask,  I was wondering if some one point me to where I should ask, or who to 
approach?  If I understand this issue correctly, it does not affect only my 
package, but also the maintainers of 50+ other packages that depend on rJava 
when they will try to update the package.

So far I tried putting the explanation to the comment field when submitting the 
update, and I also tried emailing cran-submissi...@r-project.org, but that was 
also without response so far.


This is probably a temporary Java installation problem on a CRAN Windows 
machine, cran-submissi...@r-project.org is the right place to report 
this, please be patient.


Thanks
Tomas



Thanks for any pointers,

Tomas

Od: R-package-devel  za uživatele Tomáš Kliegr 

Odesláno: pondělí 11. listopadu 2019 11:09
Komu: r-package-devel@r-project.org 
Předmět: [R-pkg-devel] Updating package with a dependency (rJava) that doesn't 
build on all flavours

Hi,

I maintain a package in CRAN, for which I am struggling to push the latest 
updates.

The problem is as follows:
My package passes tests without error or notice on all flavors but one, where 
the install fails due to an installation error of a dependency package (package 
rJava on r-devel-windows-ix86+x86_64). This installation error was already 
there in the past submissions of my package to CRAN, and was not previously 
considered as a blocker to the package (or its updates) being accepted (Current 
CRAN status: ERROR: 1, OK: 10)

Now, the package updates are automatically rejected:



package qCBA_0.4.tar.gz does not pass the incoming checks automatically, please 
see the following pre-tests:
Windows: 

Status: 1 ERROR
Debian: 

Status: OK



I cannot fix the problem with the dependency (rJava), and I also cannot remove 
rJava from my package.

More details:
Installation of  rJava package fails on 32-bit Windows, as can be seen here:
https://win-builder.r-project.org/incoming_pretest/qCBA_0.4_20191106_094406/Windows/00install.out
 ("keine zul�ssige Win32-Anwendung" error)
This problem seems to apply generally to the rJava package, not just to its use 
in my package: https://cran.r-project.org/web/checks/check_results_rJava.html.

I've also described this in the "Optional comment" field.

Any help is appreciated,

Tomas



 [[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] Compiler warning using C versions of base R integrate function

[Tomas Kalibera]

On 11/21/19 7:25 PM, Devin Incerti wrote:

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. 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!


The warning is generated by GCC when inlining the function rdqelg(), I 
can reproduce it with the integrate.c we have in R, but only if I add 
"inline" to rdqelg() definition (GCC 6 and newer - on Ubuntu but that 
should not matter). The inliner knows the callsite, so it knows that 
what is being passed is an array (and not an arbitrary pointer), and 
hence it emits the warning. It is not smart enough to know that the 
first element of the new "array" will (unless there is a bug) never be 
used. When not inlining and the function is compiled independently from 
its callsites, it assumes it is a pointer, and hence there is no warning.


The code is automatically converted from Fortran, maybe these pointer 
decrements in function prologues are to adjust to Fortran 1-based array 
indexing. If you must use this modified copy of integrate.c from R, 
perhaps a quick hack to get rid of the warning would be to avoid the 
"inline" keywords in declarations of functions like rdqelg(). In a 
perfect world, the code would be rewritten to more idiomatic C (not just 
to avoid these decrements). Or perhaps the Fortran original could be used.


Tomas


()

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] Help on Windows CRAN Check

[Tomas Kalibera]

On 3/5/20 4:26 AM, John Lawson wrote:
> I see this error on the CRAN Check report
>
>> ### ** Examples
>>
>> #Definitive Screening Design
>> library(daewr)
>> set.seed(1234)
>> x <- DefScreen(m=5,c=0)
>> colnames(x) <- paste("x",1:5,sep="")
>> x$y <- 3*x$x1 + 2*x$x2 + 2*x$x4*x$x5 + x$x3^2 + 2*x$x1^2 + rnorm(nrow(x),0,1)
>> (z <- HierAFS(x$y,x[,-6],m=5,c=0,step=4,nm1=FALSE ))
>   --- FAILURE REPORT --
>   --- failure: the condition has length > 1 ---
>   --- srcref ---
> :
>   --- package (from environment) ---
> daewr
>   --- call from context ---
> ihstep(y, x, m, c)
>   --- call from argument ---
> if (t1 == "I" & t2 == "(") {
>  iquad = TRUE
> }
>   --- R stacktrace ---
> where 1: ihstep(y, x, m, c)
> where 2: eval(expr, pf)
> where 3: eval(expr, pf)
> where 4: withVisible(eval(expr, pf))
> where 5: evalVis(expr)
> where 6: capture.output(res <- ihstep(y, x, m, c))
> where 7: withCallingHandlers(expr, warning = function(w)
> invokeRestart("muffleWarning"))
> where 8: suppressWarnings(invisible(capture.output(res <- ihstep(y, x,
>  m, c
> where 9: HierAFS(x$y, x[, -6], m = 5, c = 0, step = 4, nm1 = FALSE)
>
>   --- value of length: 3 type: logical ---
> [1] FALSE FALSE FALSE
>   --- function from context ---
> function (y, des, m, c)
> {
>  lin <- colnames(des)
>  values <- c("A", "B", "C", "D", "E", "F", "G", "H", "I",
>  "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T",
>  "U", "V", "W", "X", "Y", "Z")
>  repl <- c("I(A^2)", "I(B^2)", "I(C^2)", "I(D^2)", "I(E^2)",
>  "I(F^2)", "I(G^2)", "I(H^2)", "I(I^2)", "I(J^2)", "I(K^2)",
>  "I(L^2)", "I(M^2)", "I(N^2)", "I(O^2)", "I(P^2)", "I(Q^2)",
>  "I(R^2)", "I(S^2)", "I(T^2)", "I(U^2)", "I(V^2)", "I(W^2)",
>  "I(X^2)", "I(Y^2)", "I(Z^2)")
>  repl.tab <- cbind(values, repl)
>  if (m == 0) {
>  quad <- character()
>  }
>  else {
>  indx <- rep(0, m)
>  for (i in 1:m) {
>  indx[i] <- match(lin[i], repl.tab[, 1], nomatch = 0)
>  }
>  quad <- rep("A", m)
>  for (i in 1:m) {
>  quad[i] <- lin[i]
>  }
>  quad[indx != 0] <- repl.tab[indx, 2]
>  quad <- paste(quad, collapse = "+")
>  }
>  dat <- data.frame(y = y, des)
>  lm1 <- lm(y ~ (.)^2, data = dat)
>  mm <- model.matrix(lm1)
>  fact <- colnames(mm)
>  fact <- fact[-1]
>  fact <- paste(fact, collapse = "+")
>  mod <- paste(c(fact, quad), collapse = "+")
>  lm2 <- lm(reformulate(termlabels = mod, response = "y"),
>  data = dat)
>  mm <- model.matrix(lm2)
>  mm <- mm[, 2:ncol(mm)]
>  trm <- firstm(y, mm)
>  d1 <- data.frame(y = y, mm[, trm])
>  t1 <- substr(trm, 1, 1)
>  t2 <- substr(trm, 2, 2)
>  t3 <- substr(trm, 3, 3)
>  iquad = FALSE
>  if (t1 == "I" & t2 == "(") {
>  iquad = TRUE
>  }
>  hmt <- trm
>  if (t2 == "") {
>  nms <- names(d1)
>  nms[2] <- hmt
>  names(d1) <- nms
>  }
>  m1 <- lm(y ~ (.), data = d1)
>  result <- summary(m1)
>  print(result)
>  return(trm)
> }
> 
> 
>   --- function search by body ---
> Function ihstep in namespace daewr has this body.
>   --- END OF FAILURE REPORT --
> Fatal error: the condition has length > 1

The problem is that the condition t1 == "I" & t2 == "(" of the if 
statement in the code is not a scalar. Even though this has been allowed 
in R historically, the first element has been used, it is almost always 
a sign of coding error, so it is going to become a runtime error.

So what one should do is fix the code to only use scalar conditions - 
ensure t1, t2 are scalar, replace & by &&.

You can enable these checks on your end using an environment variable 
(more details are in R Internals, _R_CHECK_LENGTH_1_CONDITION_ and 
related is _R_CHECK_LENGTH_1_LOGIC2_).|||
|

Best
Tomas


>
>
> However on my own computer or on Rforge
>
> I see this:
>
> * checking examples ... OK
> * DONE
>
> Status: OK
>
> -- R CMD check results  daewr 1.1-9 
> 
> Duration: 1m 1.8s
>
> 0 errors v | 0 warnings v | 0 notes v
>
> R CMD check succeeded
>
>
> I am not sure what the error is or how to correct it. Any help would
> be greatly appreciated,
>
> John Lawson
>
>   [[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

Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check

[Tomas Kalibera]

On 3/5/20 9:45 AM, Rolf Turner wrote:


On 5/03/20 9:04 pm, Tomas Kalibera wrote:


On 3/5/20 4:26 AM, John Lawson wrote:

I see this error on the CRAN Check report





Fatal error: the condition has length > 1


The problem is that the condition t1 == "I" & t2 == "(" of the if
statement in the code is not a scalar. Even though this has been allowed
in R historically, the first element has been used, it is almost always
a sign of coding error, so it is going to become a runtime error.

So what one should do is fix the code to only use scalar conditions -
ensure t1, t2 are scalar, replace & by &&.


Perhaps I'm being even thicker than usual (imagine that!) but I don't 
grok that last recommendation:  "replace & by &&".  It's usually 
harmless but indicates a lack of understanding.  The "&&" operator 
evaluates the second condition only if the first condition is TRUE.  
It is useful (only) in setting where the second condition is 
meaningful only when the first condition is TRUE.


Things like:

   if(!is.null(x) && x > 0)

If "x" were null then the second  condition would cause an error to be 
thrown if you used "&" rather than "&&".


In all (???) situations where "&&" works, then "&" works as well. 
However it's a Good Idea to use the language as intended.


&& has short-circuit evaluation but also is intended for scalars. This 
is reflected by that non-scalar arguments lead to a runtime error with 
_R_CHECK_LENGTH_1_LOGIC2_=TRUE.


I use && in the code to indicate that I expect a scalar, and I want the 
short-circuit evaluation for scalars as I am used to if from other 
programming languages. I only use & when want element-wise operation on 
vectors, when & is for computation (e.g. of indices).


Best
Tomas


It I'm missing some point here, please enlighten me.



cheers,

Rolf



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

Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS

[Tomas Kalibera]

Hi Erin,

this comes from examples in ?str. Could you please try to find a minimal 
example to reproduce on your system based on that? I would look for 
"line needs" in ?str and experiment with reducing the example there 
while still getting the error. Once it is minimal, could you please try 
also on the official build of R on your machine?


Also it would be nice to have a session info. If it works in the 
official build but not your custom build, then one would have to look 
also into how the custom build is done.


Thanks
Tomas


On 3/19/20 8:02 AM, Erin Hodgess wrote:

Hello everyone:

I have built the latest version of the OpenBLAS on my Windows 10 machine.
When I run make distribution in R, everything is fine.

However, when I run make check all,  I get the following error:

C:\newtimeR\R-3.6.3\src\gnuwin32>make check-all
Testing examples for package 'base'
Testing examples for package 'tools'
   comparing 'tools-Ex.Rout' to 'tools-Ex.Rout.save' ... OK
Testing examples for package 'utils'
Error: testing 'utils' failed
Execution halted
make[3]: *** [Makefile.win:29: test-Examples-Base] Error 1
make[2]: *** [Makefile.common:185: test-Examples] Error 2
make[1]: *** [Makefile.common:171: test-all-basics] Error 1
make: *** [Makefile:324: check-all] Error 2

And here is the section from the .Rout.fail for utils:


## Multibyte characters in strings (in multibyte locales):
oloc <- Sys.getlocale("LC_CTYPE")
mbyte.lc <- if(.Platform$OS.type == "windows")

+  "English_United States.28605" else "en_GB.UTF-8"

try(Sys.setlocale("LC_CTYPE", mbyte.lc))

[1] "English_United States.28605"

## Truncation behavior (<-> correct width measurement) for "long"

non-ASCII:

idx <- c(65313:65338, 65345:65350)
fwch <- intToUtf8(idx) # full width character string: each has width 2
ch <- strtrim(paste(LETTERS, collapse="._"), 64)
(ncc <- c(c.ch = nchar(ch),   w.ch = nchar(ch,   "w"),

+   c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
c.ch w.ch c.fw w.fw
   64   64   32   64

stopifnot(unname(ncc) == c(64,64, 32, 64))
## nchar.max: 1st line needs an increase of  2  in order to see  1  (in

UTF-8!):

invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))

Error in strtrim(x.lrg, nchar.max - nc) :
   unsupported conversion from 'UTF-8' in codepage 28605
Calls: lapply ... FUN -> str -> str.default -> maybe_truncate -> strtrim
Execution halted

Has anyone run into this before, please?

If I run this line-by-line starting at the "idx <-", things are fine.

I also compiled R from source without the OpenBLAS, and it was fine.

Thanks for any suggestions.

Sincerely,
Erin



Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com

[[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] Strange leftovers after check by CRAN

[Tomas Kalibera]

On 3/19/20 6:03 PM, Max Turgeon wrote:
> Is there perhaps a typo in the environment variable name? This line suggests 
> there should be an underscore at the beginning too:
>
> https://github.com/wch/r-source/blob/trunk/src/library/tools/R/check.R#L6028

Also the correct name is in R Internals, where the variable is documented.

Tomas

>
> Max Turgeon
> Assistant Professor
> Department of Statistics
> Department of Computer Science
> University of Manitoba
> maxturgeon.ca
>
>
> 
> From: R-package-devel  on behalf of 
> Rainer M Krug 
> Sent: March 19, 2020 11:21:08 AM
> To: R Package Devel
> Subject: [R-pkg-devel] Strange leftovers after check by CRAN
>
> Hi
>
> My package dmdScheme gets always one note after submission to CRAN:
>
>
> ...
> * checking for detritus in the temp directory ... NOTE
> Found the following files/directories:
>�calibre_4.99.4_tmp_8yyefjbo� �calibre_4.99.4_tmp_ft15_af5�
>�calibre_4.99.4_tmp_jy4e07d6� �calibre_4.99.4_tmp_oxx_azo2�
>�runtime-hornik�
> * DONE
>
> These leftovers are only reported from CRAN, and locally everything is fine. 
> Uwe recommended to set the environmental variable
>
> R_CHECK_THINGS_IN_CHECK_DIR_=true
>
> But this does not change anything, I get the report back
>
> ...
> * checking for detritus in the temp directory ... OK
> * DONE
>
> Any suggestions how I can track down the where these are coming from? Each 
> time my package has to go through a manual check at CRAN�
>
> Thanks,
>
> Rainer
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
> UCT), Dipl. Phys. (Germany)
>
> Orcid ID: -0002-7490-0066
>
> Department of Evolutionary Biology and Environmental Studies
> University of Z�rich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Z�rich
> Switzerland
>
> Office: +41 (0)44 635 47 64
> Cell:+41 (0)78 630 66 57
> email:  rainer.k...@uzh.ch
>  rai...@krugs.de
> Skype: RMkrug
>
> PGP: 0x0F52F982
>
> __
> 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



[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS

[Tomas Kalibera]

    > c.ch <http://c.ch> w.ch <http://w.ch> c.fw w.fw
>      > 64   64   32   64
>     >> stopifnot(unname(ncc) == c(64,64, 32, 64))
>     >> ## nchar.max: 1st line needs an increase of  2 in order to
> see  1  (in
>      > UTF-$
>     >> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
>      > chr " __truncated__
>      > chr " __truncated__
>      > chr " __truncated__
>      > chr " __truncated__
>      > chr " __truncated__
>      > chr ""|
> __truncated__
>      > chr "<"|
> __truncated__
>     >> invisible(lapply(60:66, function(N) str( ch , nchar.max =
> N))) # "1 is 1"
>      > he$
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P."|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._"|
> __truncated__
>      > chr
> "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._Q._R._S._T._U._V"
>     >>
>
>      > Running the str example WITH changing the locale:
>
>      > oloc <- Sys.getlocale("LC_CTYPE")
>     >> mbyte.lc <http://mbyte.lc> <- if(.Platform$OS.type ==
> "windows")
>      > +  "English_United States.28605" else "en_GB.UTF-8"
>     >> try(Sys.setlocale("LC_CTYPE", mbyte.lc <http://mbyte.lc>))
>      > [1] "English_United States.28605"
>     >> ## Truncation behavior (<-> correct width measurement) for
> "long"
>      > non-ASCII:
>     >> idx <- c(65313:65338, 65345:65350)
>     >> fwch <- intToUtf8(idx) # full width character string: each
> has width 2
>     >> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
>     >> (ncc <- c(c.ch <http://c.ch> = nchar(ch), w.ch
> <http://w.ch> = nchar(ch,   "w"),
>      > +           c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
>      > c.ch <http://c.ch> w.ch <http://w.ch> c.fw w.fw
>      > 64   64   32   64
>     >> stopifnot(unname(ncc) == c(64,64, 32, 64))
>     >> ## nchar.max: 1st line needs an increase of  2 in order to
> see  1  (in
>      > UTF-$
>     >> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
>      > Error in strtrim(x.lrg, nchar.max - nc) :
>      > unsupported conversion from 'UTF-8' in codepage 28605
>     >> invisible(lapply(60:66, function(N) str( ch , nchar.max =
> N))) # "1 is 1"
>      > he$
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P."|
> __truncated__
>      > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._"|
> __truncated__
>      > chr
> "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._Q._R._S._T._U._V"
>
>      > This is pretty strange.
>
> It is strange indeed  that  strtrim() fails in this situation.
>
> From what you wrote previously, this only happens when you link
> with OpenBLAS but not when you use R's own BLAS.
> Are you sure that that was the only difference, but not rather
> the difference in the locales you used in your two versions of R
> on Windows?
>
> Martin
>
>      > Thanks for any help.
>
>      > Sincerely,
>      > Erin
>
>      > Erin Hodgess, PhD
>      > mailto: erinm.hodg...@gmail.com
> <mailto:erinm.hodg...@gmail.com>
>
>
>      > On Thu, Mar 19, 2020 at 2:29 AM Tomas Kalibera
> mailto:tomas.kalib...@gm

Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS

[Tomas Kalibera]

Thanks, so the problem is that your custom build uses GNU libiconv, 
which does not support codepage 28605. win_iconv, the one shipped with 
R, supports that code page. win_iconv is a wrapper for the Windows API. 
Unless you had a special reason not to, I would just recommend to use 
win_iconv. The "experience" will match the C library conversion calls, 
which may be used directly in some code at some places, and it is most 
tested as people normally use it. Still, the problem is not specific to 
strtrim, just to the example.

Best
Tomas


On 3/20/20 3:27 PM, Erin Hodgess wrote:
> Here are the results.
>
> Looks like enc2native and the iconv settings are different.
>
>
> > #output from custom build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
> States.1252;LC_MONETARY=English_United 
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] ""
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > enc2native("\u4e2d")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > extSoftVersion()[c("iconv","BLAS")]
>               iconv                BLAS
> "GNU libiconv 1.14"                  ""
>
>
> > #output from regular build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
> States.1252;LC_MONETARY=English_United 
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > extSoftVersion()[c("iconv","BLAS")]
>       iconv        BLAS
> "win_iconv"          ""
> >
>
> Thanks!
>
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com <mailto:erinm.hodg...@gmail.com>
>
>
> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> Hi Erin,
>
> when you are building from sources, you can always uncomment the
> example in str.Rd. But it would be good first to find out why it
> is failing on your system/build.
>
> Please run the example in Rgui of the official R 3.6.3 build on
> your machine. Does it work there?
>
> Please run the following commands in Rgui of the official R 3.6.3
> build on the machine and on your custom build. What do you get?
>
> Sys.getlocale()
> enc2native("\uff21")
> enc2native("\u4e2d")
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
> enc2native("\uff21")
> enc2native("\u4e2d")
> extSoftVersion()[c("iconv","BLAS")]
>
> Thanks,
> Tomas
>
> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>> I was wondering if there is a way to either skip the utilities
>> check and continuing, in order to test the other packages, please.
>>
>> Thanks!
>>
>>
>> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler
>> mailto:maech...@stat.math.ethz.ch>>
>> wrote:
>>
>> >>>>> Erin Hodgess    on Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>
>>      > Hi Tomas and others:
>>      > Here is the session Info.  I also used the str example
>> both without and
>>      > with changing the locale.
>>
>>      > sI <- sessionInfo()
>>     >> str(sI)
>>      > List of 10
>>      > $ R.version :List of 14
>>      > ..$ platform      : chr "x86_64-w64-mingw32"
>>      > ..$ arch          : chr "x86_64"
>>      > ..$ os            : chr "mingw32"
>>      > ..$ system        : chr "x86_64, mingw32"
>>      > ..$ status        : chr ""
>>      > ..$ major         : chr "3"
>>      > ..$ minor         : chr "6.3"
>>      > ..$ yea

Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS

[Tomas Kalibera]

Maybe the created Riconv.dll is copied over by libiconv at some point 
during your custom build.

Tomas


On 3/21/20 3:58 PM, Erin Hodgess wrote:
> Hello again.
>
> So I'm trying to find the place where the GNU iconv comes from.  
> However, I looked at output from both the regular build and the 
> custom, and I'm not seeing any differences in how win_iconv is generated.
>
> Any suggestions, please?
>
> Custom:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99  -I../../include  -O3 -Wall 
> -pedantic -march=native -pipe   -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99  -shared   -o Riconv.dll 
> Riconv.def win_iconv.o
>
> Regular:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99  -I../../include  -O3 -Wall 
> -pedantic -mtune=core2   -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99  -shared   -o Riconv.dll 
> Riconv.def win_iconv.o
>
> Just the  -march=native -pipe
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com <mailto:erinm.hodg...@gmail.com>
>
>
> On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> Thanks, so the problem is that your custom build uses GNU
> libiconv, which does not support codepage 28605. win_iconv, the
> one shipped with R, supports that code page. win_iconv is a
> wrapper for the Windows API. Unless you had a special reason not
> to, I would just recommend to use win_iconv. The "experience" will
> match the C library conversion calls, which may be used directly
> in some code at some places, and it is most tested as people
> normally use it. Still, the problem is not specific to strtrim,
> just to the example.
>
> Best
> Tomas
>
>
> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>> Here are the results.
>>
>> Looks like enc2native and the iconv settings are different.
>>
>>
>> > #output from custom build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United
>> States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] ""
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > enc2native("\u4e2d")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > extSoftVersion()[c("iconv","BLAS")]
>>               iconv                BLAS
>> "GNU libiconv 1.14"                  ""
>>
>>
>> > #output from regular build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United
>> States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > extSoftVersion()[c("iconv","BLAS")]
>>       iconv        BLAS
>> "win_iconv"          ""
>> >
>>
>> Thanks!
>>
>>
>> Erin Hodgess, PhD
>> mailto: erinm.hodg...@gmail.com <mailto:erinm.hodg...@gmail.com>
>>
>>
>> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
>> mailto:tomas.kalib...@gmail.com>> wrote:
>>
>> Hi Erin,
>>
>> when you are building from sources, you can always uncomment
>> the example in str.Rd. But it would be good first to find out
>> why it is failing on your system/build.
>>
>> Please 

Re: [R-pkg-devel] Problem with Check --as-cran

[Tomas Kalibera]

The problem is with

if (class(data) != "matrix") stop("The data field should be an array or 
a data frame")


Please use inherits() instead of checking class(), see this for more details
https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again

Best
Tomas



On 3/23/20 3:30 PM, LUIS ALFONSO PEREZ MARTOS wrote:



El 23 mar 2020, a las 15:05, LUIS ALFONSO PEREZ MARTOS  
escribió:

Good morning, everyone,

I am developing an R-package and when I check package I get this right. 
Attached image.



But when I upload the package to cran they tell me the next error and I don't 
know how to fix it.

https://win-builder.r-project.org/incoming_pretest/Clustering_1.0.0_20200322_181919/Windows/00check.log
 


Best regards

__
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] use of getNativeSymbolInfo

[Tomas Kalibera]

On 2/9/20 5:14 PM, Benjamin Tyner wrote:

Hello,

Using package nlme as an example, where there is a registered routine 
fit_gnls:


> library(nlme)
> getDLLRegisteredRoutines("nlme")$.C$fit_gnls
$name
[1] "fit_gnls"

$address

attr(,"class")
[1] "RegisteredNativeSymbol"

$dll
DLL name: nlme
Filename: /home/btyner/R-77784/lib/R/library/nlme/libs/nlme.so
Dynamic lookup: FALSE

$numParameters
[1] 10

attr(,"class")
[1] "CRoutine" "NativeSymbolInfo"

However when I tried this,

> getNativeSymbolInfo(name = "fit_gnls", PACKAGE = "nlme")

it says:

Error in FUN(X[[i]], ...) : no such symbol fit_gnls in package nlme

so I am wondering what I'm doing wrong...


This is because it is not allowed by the package: nlme calls 
R_forceSymbols(,TRUE) in its init function.


Tomas



Regards,
Ben

__
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] how to prevent a small package from yielding a large installed size?

[Tomas Kalibera]

On 6/15/20 6:52 PM, Duncan Murdoch wrote:

On 15/06/2020 12:30 p.m., Daniel Kelley wrote:
Duncan, thanks very much for that very helpful hint.  I got as 
follows.   My guess is that the first column in rdx$variables is an 
address offset, and so it seems that the lion's share of the storage 
is dedicated to items with names starting with a decimal point.  For 
example, the "[[" item is at offset of nearly 4M.  I may try fiddling 
with my code in which I specialize that method, to see whether I can 
reduce the memory footprint.  From what I can gather, both linux and 
windows build argoFloats into a package with R directory of about 
2.5M size, which is a lot better than what I get in macOS but still 
over the warning threshold (I think) and therefore I worry about CRAN 
acceptance.


The second column is the size, so actually the lion's share is 
dedicated to things that are not being shown.  They are indexed in the 
rdx$references list, and are probably going to be harder to track 
down, because they probably don't have names assigned by you.


For example, in the rgl package, I see

> rdx$references
$`env::1`
[1]  661 1037

$`env::10`
[1] 123952    221

$`env::11`
[1] 126378    224

$`env::12`
[1] 128575    226

[ many more deleted ]

Presumably `env::1` is an environment which might be referenced by 
several of the functions, and I'm guessing that one of yours is really 
big.  This can happen accidentally:  you have a temporary local 
variable in a function and create and save another function, or a 
formula, or some other environment-using object, and save the useless 
local variable along with it.


I don't have a good suggestion for figuring out what's in the bad 
environment; maybe someone else can suggest how to read an object from 
the .rdb file using R code.  Internally R uses C code for this.


I think this can be done using lazyLoadDBfetch(key, file, compressed, 
hook). "key" is c(128575L, 226L) for "env::12" above. See 
library/base/R/lazyload.R. "file" is the .RDB file, "compressed" is 
TRUE, "envhook" for this can be "function(x) NULL"


Tomas



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] data and load version 3

[Tomas Kalibera]

On 6/30/20 11:48 AM, Göran Broström wrote:



On 2020-06-30 01:07, Jeff Newmiller wrote:
Your choice. Do you want to support people using older versions of R, 
or not?


Is that all? No point at all with version 3 in packages? Why was it 
introduced? I have seen an argument for version 2: "... needed ... to 
support name spaces", but version 3 ...


Format 3 supports efficient serialization of ALTREP objects, that is why 
it was introduced. It also saves the session native encoding and 
converts string on de-serialization when running in different native 
encoding. Documented also in R 3.5 NEWS, in R Internals.


Tomas




Göran



On June 29, 2020 1:55:02 PM PDT, "Göran Broström" 
 wrote:

I added two data sets (.rda) to my package eha, but when I build the
new
version I get:

WARNING: Added dependency on R >= 3.5.0 because serialized objects in
serialize/load version 3 cannot be read in older versions of R.
File(s)
containing such objects: ‘eha/data/swedeaths.rda’
‘eha/data/swepop.rda’

In DESCRIPTION I have 'Depends: R (>= 3.0.0)'

After googling for a while (found nothing relevant in 'WRE'), I
understand that I have two options: (i) Change 'Depends' in DESCRIPTION

as suggested, and (ii) using save with 'version = 2' for the new files.

And, if I am recommended to choose (i), should I recreate the old data
files with 'version = 3'?

My guess is go for (i) and version = 3 for all data files, but I feel
that I need advise.

Thanks, Göran

__
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] warning: type of ‘zhpevx_’ does not match original declaration [-Wlto-type-mismatch]

[Tomas Kalibera]

My recommendation would be to try to minimize the example (package) as 
much as possible so that it still has the problem, and then try to 
investigate why exactly/where is the type mismatch. This is what helped 
me debug similar issues - sometimes it was hard to tell from the Fortran 
warnings where exactly the mismatched declarations were and why they 
were mismatched.

This process of minimization can already reveal the true source of the 
problem, and if not, others may try to debug for you using the minimal 
example. A useful tool is the Fortran option -fc-prototypes-external 
(see WRE for more details) and I've also used dumps of the compiler tree 
before (-fdump-tree-all, more in GCC documentation).

Best
Tomas

On 7/7/20 5:00 AM, Pierre Lafaye de Micheaux wrote:
> My file myzhpevx.cpp starts with:
>
> 
> #define USE_FC_LEN_T
> #include 
> #include "Rmath.h"
>
> #ifdef FC_LEN_T
> extern "C" {
>
>void zhpevxC(char **jobz, char **range, char **uplo, int *n, Rcomplex *ap,
>   double *vl, double *vu, int *il, int *iu, double *abstol, int *m,
>   double *w, Rcomplex *z, int *ldz, Rcomplex *work, double *rwork,
>   int *iwork, int *ifail, int *info) {
>
>void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
>const int *n, Rcomplex *ap, const double *vl,
>const double *vu, const int *il, const int *iu,
>const double *abstol, int *m, double *w,
>Rcomplex *z, const int *ldz, Rcomplex *work, double *rwork,
>int *iwork, int *ifail, int *info,
>FC_LEN_T jobz_len,  FC_LEN_T range_len,  FC_LEN_T uplo_len);
> 
>
> So if I understand correctly what you are saying, you suggest that FC_LEN_T 
> was not correctly defined by the CRAN team?
>
> Should I just write something like (adding the middle instruction below to my 
> existing code above)?:
>
> 
> #ifdef FC_LEN_T
> typedef long long int FC_LEN_T;
> extern "C" {
> 
>
> Thank you
> Pierre
> 
> From: William Dunlap 
> Sent: Tuesday, 7 July 2020 11:46
> To: Pierre Lafaye de Micheaux 
> Cc: Ivan Krylov ; r-package-devel@r-project.org 
> 
> Subject: Re: [R-pkg-devel] warning: type of �zhpevx_� does not match original 
> declaration [-Wlto-type-mismatch]
>
> With gcc 8.3.0, gfortran 8.3.0, and ld 2.33.1 from the mingw64 part of
> rtools40 on Windows, if I misdefine the typedef FC_LEN_T and use the
> -flto flag I get the sort of error messages that you report.
>
> c:\tmp\fortran>cat main.c
> #include 
> #include 
>
> #ifdef USE_INT
> typedef int FC_LEN_T;
> #endif
> #ifdef USE_LONG
> typedef long int FC_LEN_T;
> #endif
> #ifdef USE_LONG_LONG
> typedef long long int FC_LEN_T;
> #endif
>
> extern void sub_(char* word, double *ret, FC_LEN_T word_len);
>
> int main(int argc, char* argv[])
> {
>  if (argc == 2) {
>  double ret = 3. ;
>  FC_LEN_T word_len = strlen(argv[1]);
>  sub_(argv[1], &ret, word_len);
>  printf("sizeof(FC_LEN_T)=%d, ret=%g\n", (int)(sizeof(FC_LEN_T)), 
> ret);
>  return 0;
>  } else {
>  return -1;
>  }
> }
>
> c:\tmp\fortran>gcc  -flto -DUSE_INT main.c sub.f -lgfortran
> main.c:14:13: warning: type of 'sub_' does not match original
> declaration [-Wlto-type-mismatch]
>   extern void sub_(char* word, double *ret, FC_LEN_T word_len);
>   ^
> sub.f:1:1: note: type mismatch in parameter 3
> subroutine sub(word, ret)
>   ^
> sub.f:1:1: note: type 'long long int' should match type 'FC_LEN_T'
> sub.f:1:1: note: 'sub' was previously declared here
> sub.f:1:1: note: code may be misoptimized unless -fno-strict-aliasing is used
>
> c:\tmp\fortran>gcc  -flto -DUSE_LONG main.c sub.f -lgfortran
> main.c:14:13: warning: type of 'sub_' does not match original
> declaration [-Wlto-type-mismatch]
>   extern void sub_(char* word, double *ret, FC_LEN_T word_len);
>   ^
> sub.f:1:1: note: type mismatch in parameter 3
> subroutine sub(word, ret)
>   ^
> sub.f:1:1: note: type 'long long int' should match type 'FC_LEN_T'
> sub.f:1:1: note: 'sub' was previously declared here
> sub.f:1:1: note: code may be misoptimized unless -fno-strict-aliasing is used
>
> c:\tmp\fortran>gcc  -flto -DUSE_LONG_LONG main.c sub.f -lgfortran
> 
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Mon, Jul 6, 2020 at 4:39 PM Pierre Lafaye de Micheaux
>  wrote:
>> Hello Bill,
>>
>> Thank you for your insight.
>>
>> First, my impression, is that the problem comes from how I declare the type 
>> of the function itself (and not its parameters), since the first (and only 
>> warning they seen on the CRAN) message is:
>>
>> 
>> myzhpevx.cpp:13:16: warning: type of �zhpevx_� does not match original 
>> declaration [-Wlto-type-mismatch]
>> void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
>> 
>>
>> What I did is the following:
>>
>> 
>> void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
>>const int *n, Rcomplex *ap, const double *vl,
>>const doubl

Re: [R-pkg-devel] Anyone Know How To Setup Wine for Windows Testing?

[Tomas Kalibera]

On 7/16/20 7:57 PM, Steve Bronder wrote:

On Wed, Jul 15, 2020 at 2:22 PM Neal Fultz  wrote:


If you don't mind multi-gig docker containers, this can be helpful:

https://github.com/scottyhardy/docker-wine

It doesn't work with 64 bit versions of R as far as I could tell, but 32
bit did install and start correctly in a few clicks when I tried last year.


Thanks! I'm hoping if I can get this all working locally I can put
everything into a docker container for other folks. At this point I have R
up and running and it can install binary packages, but there are some
terrible terrible Cygwin/Rtools errors I can't figure out. In particular
this warning / message seems worrisome

Cygwin WARNING:
   Couldn't compute FAST_CWD pointer.  This typically occurs if you're using
   an older Cygwin version on a newer Windows.  Please update to the latest
   available Cygwin version from https://cygwin.com/.  If the problem
persists,
   please see https://cygwin.com/problems.html

If anyone has interest I can post a script for setting up the wine instance
as far as I can get atm.


Did you have any update on this? If there is a problem with MinGW-w64 
version, you can (just for experimentation) try UCRT demo build, which 
uses a newer version of MinGW-w64 than RTools 4:


https://developer.r-project.org/Blog/public/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/index.html
(reference at very bottom)


On Wed, Jul 15, 2020 at 10:56 AM J C Nash  wrote:


Are you sure you want to try to run R etc. under Wine?


Do I want to? No :-). But we (Stan) want to use flto and are seeing errors
on windows I want to be able to debug locally.


Please note Brian Ripley has added/improved support for cross-compiling 
on Linux for Windows, so that it can be used for diagnosing LTO warnings 
(see NEWS in R-devel and src/gnuwin32/README.compilation). The 
cross-compilers and needed cross-compiled libraries for R itself are 
part of at least some Linux distributions (he tested on Fedora).



- If you have Windows running, either directly or in a VM, you can run R
there.


Sadly I don't have access to a windows machine. If I can't figure this out
then I'll probably just get a windows aws instance. But it would be nice
for people to have a wine setup they could test locally on.


Microsoft is giving for free time-limited VMs primarily for testing 
Edge/MSIE, you can run them in e.g. in Virtualbox. As instructed in the 
VM, take snapshots often.



- If you have Windows and want to run R under some other OS, then set up a

VM
e.g., Linux Mint, for that. I sometimes test R for Windows in a
VirtualBox VM
for Win10, but generally run in Linux Mint. I've also run R in some Linux
VMs
to test for specific dependencies in some distros.

I rather doubt R will run very well in Linux under Wine. My experience
with Wine
is that a few apps (e.g. Irfanview) run well, but many give lots of
trouble.


Yes I'm 80/20 on whether compilation with Rtools will totally work on wine.
But if I can get this all setup and put it into a docker file I think it
will be useful for other people as well so it's worth spending a bit of
time on.


Being able to test R on Wine may be useful, if you figure it out, I 
would be interested to learn more. It is easier to obtain, may be easier 
to automate, and some low-level bugs may be easier to diagnose. Of 
course, for the price of sometimes seeing errors not present on real 
Windows.


Best
Tomas


JN


On 2020-07-15 1:17 p.m., Steve Bronder wrote:

Does anyone know of a setup guide for getting R and Rtools 4.0 up and
running on Wine with the Windows Server 2008 R2 VM? Do other maintainers
with more knowhow think that would be useful for debugging purposes?

I've been trying to test out some flto gcc things for windows by

setting up

a local wine VM on my ubuntu box. Wine has an option for Windows Server
2008 R2 (which I believe is the windows session CRAN uses?) If anyone

has

done this before and knows of a guide somewhere that would be very

helpful!

Regards,

Steve Bronder

   [[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



- Steve Bronder

[[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] Compiling 32-bit on Windows using 64-bit gcc and -m32

[Tomas Kalibera]

On 9/7/20 7:07 PM, b...@denney.ws wrote:

Hello,

  


My question is:

Can I use the 64-bit gcc to build a 32-bit package with the -m32 command
line option with Rtools?  And, can that work for CRAN?  Or more generally,
is there a work-around for needing lots of RAM during compilation with the
32-bit compiler?

The background is:

I'm trying to compile a the development version of RxODE
(https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm hitting
32-bit memory limits (using >3GB and possibly >4GB RAM during compilation)
using the 32-bit version of gcc.  Specifically,


I think this is too much memory to be used for compilation. I think it 
would be best to simplify the code, possibly split it, or just reduce 
the optimization level, as I read you have done already anyway. Maybe it 
doesn't have to be -O0, maybe you can enable some. In the past I've seen 
similar cases when inlining too aggressively in large files, maybe you 
could just reduce that a bit. It may very well be that reducing the 
optimization level just a little bit will provide about the same 
performance, but require far less memory at compile time (in the past 
there have been cases when -O3 did not produce faster code than -O2 on a 
set of standard benchmarks, of course that may be different in today's 
compilers).


Spending much more time for optimizing of the 32-bit builds may not be 
worth the effort (and neither on the R/CRAN side).


Best
Tomas




  


"C:/rtools40/mingw32/bin/"gcc [etc., see the link above for the full command
line]

  


yields the error

  


cc1.exe: out of memory allocating 65536 bytes

  


There is no problem building with mingw64, and I played around to confirm
that by using:

  


Sys.setenv(BINPREF="c:/rtools40/mingw64/bin/")

  


And compilation completed successfully (though installation failed as
expected because the compiled .dll couldn't load on 32-bit R).

  


Thanks,

  


Bill


[[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] Anyone Know How To Setup Wine for Windows Testing?

[Tomas Kalibera]

On 9/18/20 11:56 PM, Steve Bronder wrote:
> inline
>
>
> On Wed, Sep 9, 2020 at 3:35 AM Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 7/16/20 7:57 PM, Steve Bronder wrote:
> > On Wed, Jul 15, 2020 at 2:22 PM Neal Fultz  <mailto:nfu...@gmail.com>> wrote:
> >
> >> If you don't mind multi-gig docker containers, this can be helpful:
> >>
> >> https://github.com/scottyhardy/docker-wine
> >>
> >> It doesn't work with 64 bit versions of R as far as I could
> tell, but 32
> >> bit did install and start correctly in a few clicks when I
> tried last year.
> >>
> > Thanks! I'm hoping if I can get this all working locally I can put
> > everything into a docker container for other folks. At this
> point I have R
> > up and running and it can install binary packages, but there are
> some
> > terrible terrible Cygwin/Rtools errors I can't figure out. In
> particular
> > this warning / message seems worrisome
> >
> > Cygwin WARNING:
> >    Couldn't compute FAST_CWD pointer.  This typically occurs if
> you're using
> >    an older Cygwin version on a newer Windows.  Please update to
> the latest
> >    available Cygwin version from https://cygwin.com/. If the problem
> > persists,
> >    please see https://cygwin.com/problems.html
> >
> > If anyone has interest I can post a script for setting up the
> wine instance
> > as far as I can get atm.
>
> Did you have any update on this? If there is a problem with MinGW-w64
> version, you can (just for experimentation) try UCRT demo build,
> which
> uses a newer version of MinGW-w64 than RTools 4:
>
>
> So this worked with a patched version of wine. that fixed the above 
> error. I'm waiting for that patch to go in and for the next wine 
> release to try this again.
Thanks!
>
>
> 
> https://developer.r-project.org/Blog/public/2020/07/30/windows/utf-8-build-of-r-and-cran-packages/index.html
> (reference at very bottom)
>
> > On Wed, Jul 15, 2020 at 10:56 AM J C Nash  <mailto:profjcn...@gmail.com>> wrote:
> >
> >>> Are you sure you want to try to run R etc. under Wine?
> >>>
> > Do I want to? No :-). But we (Stan) want to use flto and are
> seeing errors
> > on windows I want to be able to debug locally.
>
> Please note Brian Ripley has added/improved support for
> cross-compiling
> on Linux for Windows, so that it can be used for diagnosing LTO
> warnings
> (see NEWS in R-devel and src/gnuwin32/README.compilation). The
> cross-compilers and needed cross-compiled libraries for R itself are
> part of at least some Linux distributions (he tested on Fedora).
>
>
> Yes very exciting!
>
>
> >>> - If you have Windows running, either directly or in a VM, you
> can run R
> >>> there.
> >>>
> > Sadly I don't have access to a windows machine. If I can't
> figure this out
> > then I'll probably just get a windows aws instance. But it would
> be nice
> > for people to have a wine setup they could test locally on.
>
> Microsoft is giving for free time-limited VMs primarily for testing
> Edge/MSIE, you can run them in e.g. in Virtualbox. As instructed
> in the
> VM, take snapshots often.
>
>
> We have a Jenkins box that we use to spinup AWS windows sessions when 
> we need to thoroughly debug now but ty for the info!
>
>
> >> - If you have Windows and want to run R under some other OS,
> then set up a
> >>> VM
> >>> e.g., Linux Mint, for that. I sometimes test R for Windows in a
> >>> VirtualBox VM
> >>> for Win10, but generally run in Linux Mint. I've also run R in
> some Linux
> >>> VMs
> >>> to test for specific dependencies in some distros.
> >>>
> >>> I rather doubt R will run very well in Linux under Wine. My
> experience
> >>> with Wine
> >>> is that a few apps (e.g. Irfanview) run well, but many give
> lots of
> >>> trouble.
> >>>
> > Yes I'm 80/20 on whether compilation with Rtools will totally
> work on wine.
> > But if I can get this all setup and put it into a docker file I
> think it
> > will be useful fo

Re: [R-pkg-devel] Check: for detritus in the temp directory, Result: NOTE

[Tomas Kalibera]

This is was a bug in R-devel, already fixed.
Sorry for the inconvenience,

Tomas

On 10/17/20 12:06 AM, John Mount wrote:

I am trying to move the wrapr package from RUnit to tinytest. All seemed well 
on my tests, but when I submitted to CRAN I got:

Flavor: r-devel-linux-x86_64-debian-gcc
Check: for detritus in the temp directory, Result: NOTE
   Found the following files/directories:
 'Rscript2be2.9jpLCF' 'Rscript2be3.i3ORSI' 'Rscript2bff.JJwTqS'
 'Rscript2c00.PBV2DW'

Does anybody know what this is a symptom of, or how to fix it?

Thanks,
   John


---
John Mount
http://www.win-vector.com/
Our book: Practical Data Science with R
http://practicaldatascience.com






[[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] detritus in temp

[Tomas Kalibera]

This was a bug in R-devel, already fixed.
(specific to Unix, and only 3 R-devel revisions)

Sorry for the inconvenience,
Tomas

On 10/20/20 4:48 PM, Cristoforo Simonetto wrote:

Dear all,

last week I tried to upload for the first time a package to CRAN but 
my submission was refused:


Flavor: r-devel-linux-x86_64-debian-gcc
Check: for detritus in the temp directory, Result: NOTE
  Found the following files/directories:
    'Rscript2a22.5sWrxM' 'Rscript2a30.B2JkNS'

On the Windows machine of CRAN this error did not occur, nor did it 
occur on my ubuntu PC, and I was also not able to reproduce it on 
R-hub. The CRAN output can be found at:


https://win-builder.r-project.org/incoming_pretest/msce_1.0.0_20201016_101418/ 



I have no idea about possible sources of this error. Could anybody 
please give me a hint?


Thanks

Cristoforo

Helmholtz Zentrum München

Helmholtz Zentrum München

__
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