Re: [Rd] Error compiling 87283 on Windows 10 using Rtools4.4 6335-6327

[Prof Brian Ripley via R-devel]

On 31/10/2024 16:30, Avraham Adler wrote:

When compiling R, the build fails after byte compiling grDevices with
the following error:

byte-compiling package 'grDevices'
make[4]: *** [../../../share/make/lazycomp.mk:9:
../../../library/grDevices/R/grDevices.rdb] Error 139
make[3]: *** [Makefile.win:23: all] Error 2
make[2]: *** [Makefile.win:34: R] Error 1
make[1]: *** [Makefile:18: all] Error 2
make: *** [Makefile:392: distribution] Error 2

I restarted the build, as sometimes that allows it to power through,
but it failed at the same point. Any thoughts or suggestions would be
appreciated.

This may be unrelated, but as I was monitoring the compilation, I saw
an warning which I haven't seen before in the 20 or so years I've been
building R on Windows:

In function 'R_chk_memset',
 inlined from 'do_aperm' at ../main/array.c:1754:5:
../main/memory.c:3578:16: warning: 'memset' specified bound between
18446744056529682432 and 18446744073709551608 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
  3578 | return n ? memset(s, c, n) : s;
   |

No idea if it is related but I thought I should mention it.


This is known for an LTO build with gcc 14.2.x -- not normally used on 
Windows though.  It is a over-aggressive warning, one we are working on 
for R-devel.


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

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

Re: [Rd] Consider getNamespaceVersion() returning a numeric_version

[Prof Brian Ripley via R-devel]

On 17/10/2024 13:42, Tim Taylor wrote:
I mean the `numeric_version` object not a numeric (double/int). 
Basically to protect me from myself I'd prefer not to have to remember 
to wrap `getNamespaceVersion()` with `as.package_version()`.


I suspect a grep of CRAN may highlight others who are erroneously 
comparing character objects rather than a comparison between a 
`numeric_version` object and a character.


Perhaps you could do that rather than speculating?  Similarly, try out 
over CRAN the effect of getNamespaceVersion changing its return type.


It seems to be used in less than 40 CRAN packages, many boilerplate code 
from a single author and most use the version as a printable character 
string.  A few are clearly wrong: E.g.


if(getNamespaceVersion("reticulate") >= "1.36.0")

will be false it that package ever reaches "1.100.0".  This is what 
compareVersion() is for 



On 17/10/2024 13:22, Dirk Eddelbuettel wrote:

On 17 October 2024 at 12:38, Tim Taylor wrote:
| Would R-Core be receptive to having getNamespaceVersion() return a
| numeric_version object instead of a named character?

Is this good enough? What's your actual issue a 'numeric' would address?

    > as.package_version(getNamespaceVersion("base")) < "4.5.0"
    [1] TRUE
    >
    > as.package_version(getNamespaceVersion("Rcpp")) > "1.0.11"
    [1] TRUE
    > as.package_version(getNamespaceVersion("Rcpp")) > "1.0.14"
    [1] FALSE


There are differences, e.g.

> (z <- getNamespaceVersion("MASS"))
 version
"7.3-61"
> (zz <- as.package_version(z))
[1] ‘7.3.61’
> as.character(zz)
[1] "7.3.61"

and some uses need the first.  That makes changing the return value too 
disruptive.


If the issue is only comparison, getNamespaceVersion's return value 
could be given a class and an Ops group method, but the existence of 
compareVersion() makes that less compelling.



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

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

Re: [Rd] config.site settings for M3 Mac typo in manual?

[Prof Brian Ripley via R-devel]

On 20/05/2024 09:06, Duncan Murdoch wrote:
I've just upgraded to an M3 Mac laptop, and I'm working through getting 
the right configure settings to build R.


The Installation and Administration manual says to have this in 
config.site:


FFLAGS="-g -O2 -mmacos-version-min=11.0"
FCFLAGS="-g -O2 -mmacos-version-min=11.0"

but those give an error on my system, with it suggesting the FFLAGS and 
FCFLAGS version option should be -mmacosx-version-min=11.0.  I don't 
know if that's a typo or a change.


-mmacos-version-min= is the current Apple option.  However, the gfortran 
build recommended in the manual is quite old and this has apparently 
differed by GCC version (and is not documented in the 'man gfortran' I 
have).


I'll change the manual to mention both forms, and that it is only 
sometimes needed (not on my current setup).


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

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

Re: [Rd] paths capability FALSE on devel?

[Prof Brian Ripley via R-devel]

On 27/03/2024 10:28, Alexandre Courtiol wrote:

Hi all,

I don't know if it is a local issue on my hands or not, but after
installing R-devel the output of grDevices::dev.capabilities()$paths is
FALSE, while it is TRUE for R 4.3.3.
Relatedly, I have issues with plotting paths on devel.

At this stage, I simply would like to know if others running R devel and R
4.3.3 can replicate this behaviour and if there are obvious reasons why the
observed change would be expected.


The help says

 Query the capabilities of the current graphics device.

You haven't told us what that was.  See the posting guide for the "at a 
minimum" information you also did not provide 



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

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

Re: [Rd] Advice debugging M1Mac check errors

[Prof Brian Ripley via R-devel]

On 04/02/2024 19:41, Holger Hoefling wrote:

Hi,

I wanted to ask if people have good advice on how to debug M1Mac package
check errors when you don´t have a Mac? Is a cloud machine the best option
or is there something else?


I presumed this was about a CRAN package, possibly hdf5r which has a 
R-devel-only warning from the Apple clang compiler.  And that is not a 
'check error' and not something to 'debug'.


The original poster had errors for his package flsa until yesterday on 
fedora-clang and M1mac, which were compilation errors with recent LLVM 
and Apple compilers.  Again, not really something to 'debug' -- the 
compiler messages were clear and the CRAN notification contained advice 
on where in our manual to look this up.


The mac-builder service offers checks for R 4.3.0, the 'development' 
option being (last time I tried) the same as the 'release' option. (When 
I asked, Simon said that 'development' checks were only available in the 
run up to a x.y.0 when he starts package building and checks for R-devel.)



We were left to guess, but I doubt this has to do with the lack of 
'extended precision' nor long doubles longer than doubles on arm64 
macOS.  And issues with that are rather rare (much rarer than numerical 
issues for non-reference x86_64 BLAS/LAPACKs).  Of the 20,300 CRAN 
packages just 18 have M1mac-specific errors, none obviously from 
numerical inaccuracy.  A quick look back suggests we get about 20 a year 
with M1mac numerical issues, about half of which were mirrored on the 
x86_64 'noLD' checks.


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

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

Re: [Rd] system()/system2() using short paths of commands on Windows?

[Prof Brian Ripley]

On 30/10/2023 16:18, Yihui Xie wrote:

Hi,

It may have been so for 20+ years but I just discovered today that system()
would always try to use the short path of a command on Windows:
https://github.com/wch/r-source/blob/635a67/src/gnuwin32/run.c#L141 If
that's true, I wonder if it could provide an option to disable this
behavior, because we recently ran into a case in which short paths wouldn't
work. I wonder what the original motivation of using short paths was. If it
was to avoid spaces in paths, wouldn't shQuote() work? Thanks!


No: system on Windows does not use a shell.

The 'original motivation' was to work reliably!  Back in the days of 
Windows 95 when many parts of Windows only supported 8+3 names.




Regards,
Yihui

[[alternative HTML version deleted]]


Please do re-read the posting guide.  It has ' been so for 20+ years '.

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

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

Re: [Rd] FYI: daily R source tarballs from ETH: *.xz instead of *.bz2)

[Prof Brian Ripley]

On 09/09/2023 01:56, Hervé Pagès wrote:

Hi Martin,

Sounds good. Are there any plans to support the xz compression for
package source tarballs?


What makes you think it is not supported?

R CMD INSTALL happily installs .tar.xz files, and the name is not used 
to detect compression so .tar.gz files could be bzip2- or xz-compressed.


Note that tarball compression is pretty much irrelevant where the 
tarball contains large compressed files, for example .rda files or 
vendor.tar.xz files of Rust sources.  You have to arrange that the first 
compression is the bast possible.


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

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

Re: [Rd] Installation of R-4.3.1 with intel 2022

[Prof Brian Ripley]

Note that 'intel 2022' is a bit vague.  The current version is 2023.1.0, 
and that has both the 'classic' (icc/icpc/ifort which it seems you used) 
and new (icx/ixpx/ifx) compilers -- the former are said to be going to 
be discontinued later this year.  R did not know about ifx so did not 
build with the new set.


The parts of the manual Tomas referred to were about the old compilers: 
the manual has now been re-written in R-devel and R-patched to major on 
the newer ones.  We have patched the code to work with both old and new 
compilers, pending a more thorough investigation of matherr.


In our experiments Intel Fortran only worked in conjunction with oneAPI 
MKL -- see the manual.  It seems ifx is still under development, so it 
should pay to use only the latest versions.


This is the first report on Intel compilers since 2015, so they are 
rather low priority for the R developers.



On 21/06/2023 08:10, Tomas Kalibera wrote:


On 6/20/23 18:47, Giuseppe Calò wrote:

Hi all,
I have the issue:

icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I. 
-I../../src/include -I../../src/include  -I/usr/local/include 
-I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -g -O3 -wd188 -ip 
-mp  -c eval.c -o eval.o
arithmetic.c(66): warning #274: declaration is not visible outside of 
function

   int matherr(struct exception *exc)
  ^

arithmetic.c(68): error: pointer to incomplete class type is not allowed
   switch (exc->type) {
   ^

arithmetic.c(69): error: identifier "DOMAIN" is undefined
   case DOMAIN:
    ^

arithmetic.c(70): error: identifier "SING" is undefined
   case SING:
    ^

arithmetic.c(73): error: identifier "OVERFLOW" is undefined
   case OVERFLOW:
    ^

arithmetic.c(76): error: identifier "UNDERFLOW" is undefined
   case UNDERFLOW:
    ^

arithmetic.c(77): error: pointer to incomplete class type is not allowed
   exc->retval = 0.0;

icc -std=c99 -std=gnu11 -I../../src/extra -I../../src/extra/xdr -I. 
-I../../src/include -I../../src/include  -I/usr/local/include 
-I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -g -O3 -wd188 -ip 
-mp  -c flexiblas.c -o flexiblas.o

icc: command line remark #10148: option '-mp' not supported
compilation aborted for arithmetic.c (code 2)
make[3]: *** [../../Makeconf:129: arithmetic.o] Error 2
make[3]: *** Waiting for unfinished jobs
icc: command line remark #10148: option '-mp' not supported
make[3]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
make[2]: *** [Makefile:140: R] Error 2
make[2]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src/main'
make[1]: *** [Makefile:28: R] Error 1
make[1]: Leaving directory '/opt/sources/R/R-4.3.1-intel21/src'
make: *** [Makefile:62: R] Error 1

with oneapi-2022.1.0/compiler-rt/2022.1.0; 
oneapi-2022.1.0/mkl/2022.1.0 while building R-4.3.1 on redhat 8.4 
glibc2.28-189


I followed a workaround proposed:
https://community.intel.com/t5/Intel-C-Compiler/Error-when-compiling-R-from-source-code-ubuntu-18-04/m-p/1176401/thread-id/36575
 


Deactivate  HAVE_MATHERR macro in src/include/config.h


Hi Giuseppe,

thanks for the report. Undefining HAVE_MATHERR seems a valid work-around 
to me, based on reading the thread above and the sources.


We could improve this in R, if keeping this code, at least improve the 
configure check so that it also tests for the presence of the macros.



Using this workaroud I get R with:

BLAS/LAPACK: 
/opt/intel/oneapi_2022.2.0/mkl/2022.1.0/lib/intel64/libmkl_intel_lp64.so.2;  LAPACK version 3.9.0


is correct?

Is these a way to avoid arithmetic issue?

My configure is:

module load intel-2021.6.0/2021.6.0 oneapi-2022.1.0/mkl
MKL="-L${MKLROOT}/lib/intel64 -lmkl_gf_lp64 -lmkl_core 
-lmkl_gnu_thread -dl -fopenmp"

export CC="icc -std=c99"
export CFLAGS="-g -O3 -wd188 -ip -mp"
export FC=ifort
export FLAGS="-g -O3 -mp"
export CXX=icpc
export CXXFLAGS="-g -O3 -mp"
SHLIB_CXXLD=icpc
export MKL_INTERFACE_LAYER=GNU,LP64
export MKL_THREADING_LAYER=GNU
./configure --prefix=/opt/intel-2021.6.0/R/4.3.1 --with-blas="$MKL" 
--with-lapack  --enable-memory-profiling --enable-BLAS-shlib 
--enable-R-shlib --enable-R-static-lib --with-pcre2


AFAIK, neither icc nor MKL is regularly tested with R/CRAN packages, so 
the risk of running into some issues is somewhat higher than for say GCC 
and the reference BLAS/LAPACK.


Some hints on using icc and MKL can be found in the R Admin manual, 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html. Unless 
you have done that already, you might want to check your configuration 
against those, I didn't spot any obvious issue. If you find any other 
problem, please report, so that it could be fixed or the hints updated.


Thanks,
Tomas



Thanks a lot,
Giuseppe.

———
Giuseppe Calò

Re: [Rd] Building R from source always fails on tools:::sysdata2LazyLoadDB

[Prof Brian Ripley]

On 30/05/2023 22:57, Martin Morgan wrote:

Thanks Ivan & Tomas

A simpler way to trigger the problem is library(tools) or library.dynam("tools", "tools", 
".") so I guess it is loading src/tools.so

Ivan, adding -d lldb I need to tell lldb where to find the R library

(lldb) process launch --environment 
DYLD_LIBRARY_PATH=/Users/ma38727/bin/R-devel/lib

And then `library(tools)` works. To run lldb I needed to grant Xcode 
permissions using my local administrator account.

@Thomas I can't see anything in the Console app logs, but this might be partly 
my ineptitude.


Which version of macOS is this?

- Prior to Ventura it is the known behaviour.

- With Ventura the same happens if any R process from the current build 
is in use, even a crashed one. (The latter happened to me this morning: 
there were reports under Crash Reports in the Console App.)


As the R-admin manual says

"Updating an ‘arm64’ build may fail because of the bug described at 
https://openradar.appspot.com/FB8914243 but ab initio builds work. This 
has been far rarer since macOS 13."


Once it happens, you need to rebuild (make clean;make all should suffice).



Martin

From: Tomas Kalibera 
Date: Tuesday, May 30, 2023 at 4:54 PM
To: Martin Morgan , R-devel 
Subject: Re: [Rd] Building R from source always fails on 
tools:::sysdata2LazyLoadDB

On 5/30/23 22:09, Martin Morgan wrote:

I build my own R from source on an M1 mac. I have a clean svn checkout in one 
directory ~/src/R-devel. I switch to ~/bin/R-devel and the first time run

cd ~/bin/R-devel
~/src/R-devel/configure --enable-R-shlib 'CFLAGS=-g -O0' 
CPPFLAGS=-I/opt/R/arm64/include 'CXXFLAGS=-g -O0'
make -j

At some point in the future I svn update src/R-devel, then

cd ~/bin/R-devel
make -j

This always ends with

installing 'sysdata.rda'
/bin/sh: line 1: 99497 Doneecho 
"tools:::sysdata2LazyLoadDB(\"/Users/XXX/src/R-devel/src/library/utils/R/sysdata.rda\",\"../../../library/utils/R\")"
   99498 Killed: 9   | R_DEFAULT_PACKAGES=NULL LC_ALL=C 
../../../bin/R --vanilla --no-echo
make[4]: *** [sysdata] Error 137
make[3]: *** [all] Error 2
make[2]: *** [R] Error 1
make[1]: *** [R] Error 1
make: *** [R] Error 1

what am I doing wrong? Is there a graceful way to fix this (my current solution 
is basically to start over, with `make distclean`)? If I cd into 
~/bin/R-devel/src/library/utils I can start an interactive session and 
reproduce the error

~/bin/R-devel/src/library/utils $   R_DEFAULT_PACKAGES=NULL ../../../bin/R 
--vanilla

tools:::sysdata2LazyLoadDB("/Users/ma38727/src/R-devel/src/library/utils/R/sysdata.rda","../../../library/utils/R")

zsh: killed R_DEFAULT_PACKAGES=NULL ../../../bin/R --vanilla

or simply


tools:::sysdata2LazyLoadDB

zsh: killed R_DEFAULT_PACKAGES=NULL LC_ALL=C R_ENABLE_JIT=0 TZ=UTC 
../../../bin/R


If it is macOS, it might be worth checking the system logs (Console
app). It may be some system security feature.

Tomas


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

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

Re: [Rd] R-4.2.3 build from source on Windows (w Rtools42) - lto1.exe error

[Prof Brian Ripley]

Initial comments

- R 4.2.3 is not current

- -flto does not seem to be the default in src/gnuwin32/MkRules.

- LTO versions in GCC are tied to the compiler version, and in recent 
GCC are the same as the compiler version.  The recommended toolchain for 
R 4.2.x is Rtools42 which according to NEWS is based on GCC 10 not 9.


- LTO mismatches in my experience are most often seen in incremental 
builds, so first do an ab initio build.  (Not so long ago they were not 
detected during linking but gave segfaults.)


Assuming it is important to use LTO, I would first build without LTO to 
isolate the issue.  And be aware of the following in the NEWS for R 4.3.0:


• The Rcomplex definition (in header R_ext/Complex.h) has been
  extended to prevent possible mis-compilation when interfacing
  with Fortran (PR#18430).

AFAIR that "possible mis-compilation" is most likely using LTO.


On 11/05/2023 02:07, Gmail wrote:

Windows 11 PRO Version  10.0.22621 Build 22621
Processor: Intel(R) Core(TM) i7-1065G7 "Icelake-client"
```
​svn info   
Path: .
Working Copy Root Path: /d/R_DEV/R-4/R42/R-4-2-branch
URL: https://svn.r-project.org/R/branches/R-4-2-branch
Relative URL: ^/branches/R-4-2-branch
Repository Root: https://svn.r-project.org/R
Repository UUID: 00db46b3-68df-0310-9c12-caf00c1e9a41
Revision: 84417
Node Kind: directory
Schedule: normal
Last Changed Author: kalibera
Last Changed Rev: 84249
Last Changed Date: 2023-04-13 07:12:24 + (Thu, 13 Apr 2023)
```

Only adaptation done in MkRules.local was adding: `EOPTS = -march=native`  - 
that's why I included the cpu-type info above;
running make all recommended​ fails at/with:
```
gcc -shared -s -static-libgcc -o utils.dll tmp.def init.o io.o size.o sock.o 
stubs.o utils.o hashtab.o windows/dataentry.o windows/dialogs.o 
windows/registry.o windows/util.o windows/widgets.o 
../../../gnuwin32/dllversion.o -lRgraphapp -lversion 
-L/x86_64-w64-mingw32.static.posix/lib/x64 -llzma 
-LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 
-LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -L../../../../bin/x64 -lR

lto1.exe: fatal error: bytecode stream in file 'windows/dataentry.o' generated 
with LTO version 9.3 instead of the expected 9.4
compilation terminated.

lto-wrapper.exe: fatal error: 
C:\rtools42\x86_64-w64-mingw32.static.posix\bin\gcc.exe returned 1 exit status
compilation terminated.
C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: error: lto-wrapper 
failed
collect2.exe: error: ld returned 1 exit status
cp: cannot stat 'utils.dll': No such file or directory
make[4]: *** [Makefile.win:36: shlib] Error 1
make[3]: *** [../../../share/make/basepkg.mk:145: mksrc-win2] Error 1
make[2]: *** [Makefile.win:24: all] Error 2
make[1]: *** [Makefile.win:34: R] Error 1
make: *** [Makefile:18: all] Error 2
```
Any hints/ideas on how to fix this? I guess I could
gcc -c -flto ... windows/dataentry.c -o windows/dataentry.o
with the exact path of that fiile ...
and it hopefully will fix that but I guess it would make sense to add a 
Revision to update that LTO version mismatch there, and I don't know yet if 
this is the only one?

Greetings,
W

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


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

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

Re: [Rd] Let R compile for libcurl8 ?

[Prof Brian Ripley]

On 03/04/2023 15:24, Detlef Steuer wrote:

Am Mon, 3 Apr 2023 15:13:58 +0100
schrieb Prof Brian Ripley :


On 03/04/2023 14:07, Detlef Steuer wrote:

Hi!

The same Inar reported for rawhide
(https://stat.ethz.ch/pipermail/r-devel/2023-March/082482.html)
is true for SuSE's distros.

Right now R does not compile with libcurl8, but SuSE
Tumbleweed/Factory switched to 8 a week ago.

Would be great, if the patch Inar provided could be applied to
main.

Detlef
   


As in

CHANGES IN R 4.3.0:
...
  • libcurl 8.x is now accepted by configure: despite a change in
major version number it changes neither API nor ABI.

?

What version of R are you looking at?  (This has also been backported
to R 4.2.3 patched although possibly untested there.)



I was looking on R-patched, with diff from this morning.

Still fails:

[  260s] checking for curl-config... /usr/bin/curl-config
[  260s] checking libcurl version ... 8.0.1
[  260s] checking for curl/curl.h... yes
[  260s] checking if libcurl is version 7 and >= 7.28.0... no
[  260s] configure: error: libcurl >= 7.28.0 library and headers are
required with support for https [  261s] error: Bad exit status from
/var/tmp/rpm-tmp.PUUqtM (%build) [  261s]
[  261s] RPM build errors:
[  261s] Bad exit status from /var/tmp/rpm-tmp.PUUqtM (%build)
[  261s] ### VM INTERACTION START ###
[  261s] [  234.216368][T1] sysrq: Power Off
[  261s] [  234.218303][  T267] reboot: Power down
[  261s] ### VM INTERACTION END ###
[  261s]
[  261s] cloud124 failed "build R-patched.spec" at Mon Apr  3 10:46:27
UTC 2023. [  261s]

If it should build, I'll take a look, but because of that log it seemed
to me nothing had changed in the meantime.


Again, what exactly is 'R-patched'?  The latest daily tarball

https://stat.ethz.ch/R/daily/R-patched_2023-03-29.tar.bz2

just built for me with

checking for curl-config... /usr/local/bin/curl-config
checking libcurl version ... 8.0.1
checking for curl/curl.h... yes
checking if libcurl is >= 7.28.0... yes
checking if libcurl supports https... yes

and reports itself as

R version 4.2.3 Patched (2023-03-29 r84146) -- "Shortstop Beagle"

Although as I mentioned, I had not tested it against curl 8.0.1 and did 
not know if anyone else had.


See also https://bugs.r-project.org/show_bug.cgi?id=18497

The patch has been in R-4-2-branch since

r84053 2023-03-25 12:37:42 + (Sat, 25 Mar 2023)

At this time of year one has to be very careful about 'R-patched' -- for 
example CRAN check results labelled 'r-patched' are at least mainly for 
4.3.0 alpha.


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

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

Re: [Rd] Let R compile for libcurl8 ?

[Prof Brian Ripley]

On 03/04/2023 14:07, Detlef Steuer wrote:

Hi!

The same Inar reported for rawhide
(https://stat.ethz.ch/pipermail/r-devel/2023-March/082482.html)
is true for SuSE's distros.

Right now R does not compile with libcurl8, but SuSE Tumbleweed/Factory
switched to 8 a week ago.

Would be great, if the patch Inar provided could be applied to
main.

Detlef



As in

CHANGES IN R 4.3.0:
...
• libcurl 8.x is now accepted by configure: despite a change in
  major version number it changes neither API nor ABI.

?

What version of R are you looking at?  (This has also been backported to 
R 4.2.3 patched although possibly untested there.)


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

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

Re: [Rd] CRAN package eaf

[Prof Brian Ripley]

On 01/03/2023 18:33, Manuel López-Ibáñez wrote:

Dear CRAN Team,

I believe those are false positives. All pointers are updated after 
realloc. I have verified that this is the case not only at this point 
but also at every realloc call.


It may be this compiler bug: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215


I believe this warning may eventually get moved out of -Wall because it 
has become too noisy in GCC 12: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=Wuse-after-free


Are you aware that eaf still gives a warning with the latest gcc 13 
snapshot?  There are 3 CRAN packages which no longer warn with gcc 13, 
but yours is not one of them.  And none that warn with gcc 13 but not 
gcc 12.


gcc 13 is in final bug-fixing and was expected to be released by now.

We don't have time to study maintainers' C++ code so have to let this 
pass without accepting that it is the compiler and not your fault.  We 
would like you to file a bug report specifically about your code and get 
agreement from the GCC developers that this is their bug.




Best wishes,

Manuel.





On 01/03/2023 17:02, Prof Brian Ripley wrote:

Dear maintainer,

Please see the problems shown on
<https://cran.r-project.org/web/checks/check_results_eaf.html>.

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

The CRAN Team


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

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

Re: [Rd] Compiling R-devel on older Linux distributions, e.g. RHEL / CentOS 7

[Prof Brian Ripley]

On 08/02/2023 00:13, Gábor Csárdi wrote:

As preparation for the next release, I am trying to compile R devel on
RHEL / CentOS 7, which is still supported by RedHat until 2024 June.
There are two issues.

One is that the libcurl version in CentOS 7 is quite old, 7.29.0, and
R devel now requires 7.32.0, since 83715 about a week ago. This
requirement is here to stay for R 4.3.0, right?


Unless we revert it.  The comment in the manual says

@c libcurl 7.32.0 was released in Aug 2013

and Centos 7 was released in 2014-07-07, 11 months later.  Do they 
really never security-patch libcurl?



The second is that the recommended packages are now installed with R
CMD INSTALL --use-C17, which fails on CentOS 7 with

begin installing recommended package MASS
* installing *source* package 'MASS' ...
** package 'MASS' successfully unpacked and MD5 sums checked
** using non-staged installation
** libs
Error: C17 standard requested but CC17 is not defined
* removing '/root/R-devel/library/MASS'

CentOS 7 has GCC 4.8.5, which does not have a -std=gnu17 option.
However the commit message of this change in commit 83566 hints that
this requirement might be temporary. Hence my questions.


It is temporary -- needed for survival (now updated) and mgcv (awaited). 
 However,


1) You should be able to set

CC17="gcc -std=gnu11"

in config.site, as C17 is a bug-fixed C11.

2) Centos 7 has later compilers available, and people are going to need 
them for C++.  The manual says


... later compilers are available: for RHEL/Centos 7 look for 
‘devtoolset’.



Is the C17 requirement temporary or it will be a requirement for R 4.3.0?
Should I expect any problems if I remove the --use-C17 flag for
installing the recommended packages?


Not with that compiler.



There are a lot of R users still on RHEL 7, so it would be great to
know what to expect for the next release.

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

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

Re: [Rd] A potential POSIXlt->Date bug introduced in r-devel

[Prof Brian Ripley]

Confirmed on Fedora 36 which has a 32-bit time_t for an i686 compile.  I 
was a bit surprised that has not been changed, but gather Linux distros 
are preferring to drop ix86 than fix it.


There is a simple workaround, to configure R with 
--with-internal-tzcode, which always uses a 64-bit time_t.  Given that 
2038 is not that far away, avoiding 32-bit time_t is generally a very 
good idea (not just for people working with dates in 5881580!).


That test should not really be run on platforms with 32-bit time_t, but 
that is not currently known at R level.


On 06/10/2022 13:38, Prof Brian Ripley wrote:

On 06/10/2022 09:41, Berwin A Turlach wrote:

G'day all,

On Thu, 6 Oct 2022 10:15:29 +0200
Martin Maechler  wrote:


Davis Vaughan
 on Wed, 5 Oct 2022 17:04:11 -0400 writes:



 > # Weird, where is the `NA`?
 > as.Date(x)
 > #> [1] "2013-01-31" "1970-01-01" "2013-03-31"
 > ```

I agree that the above is wrong, i.e., a bug in current  R-devel.


I have no intention of hijacking this thread, but I wonder whether this
is a good opportunity to mention that the 32 bit build of R-devel falls
over on my machine since 25 September.  It fails one of the regression
tests in reg-tests-1d.R.  The final lines of reg-tests-1d.Rout.fail
are:


tools::Rd2txt(rd, out <- textConnection(NULL, "w"), fragment = TRUE)
stopifnot(any(as.character(rd) != "\n"),

+   identical(textConnectionValue(out)[2L], "LaTeX"));
close(out)

## empty output in R <= 4.2.x


Yes, known for a few days on the R-core list. I am in the middle of an 
OS upgrade on that machine and won't have time to do more than report 
until that (and all the re-building and re-checking) is complete.



## as.POSIXlt()  gave integer overflow
stopifnot(as.POSIXlt(.Date(2^31 + 10))$year == 5879680L)

Error: as.POSIXlt(.Date(2^31 + 10))$year == 5879680L is not TRUE
Execution halted


I should have reported this earlier, but somehow did not find the time
to do so.  So I thought I mention it here. :)

Cheers,

Berwin

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






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

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

Re: [Rd] A potential POSIXlt->Date bug introduced in r-devel

[Prof Brian Ripley]

On 06/10/2022 09:41, Berwin A Turlach wrote:

G'day all,

On Thu, 6 Oct 2022 10:15:29 +0200
Martin Maechler  wrote:


Davis Vaughan
 on Wed, 5 Oct 2022 17:04:11 -0400 writes:



 > # Weird, where is the `NA`?
 > as.Date(x)
 > #> [1] "2013-01-31" "1970-01-01" "2013-03-31"
 > ```

I agree that the above is wrong, i.e., a bug in current  R-devel.


I have no intention of hijacking this thread, but I wonder whether this
is a good opportunity to mention that the 32 bit build of R-devel falls
over on my machine since 25 September.  It fails one of the regression
tests in reg-tests-1d.R.  The final lines of reg-tests-1d.Rout.fail
are:


tools::Rd2txt(rd, out <- textConnection(NULL, "w"), fragment = TRUE)
stopifnot(any(as.character(rd) != "\n"),

+   identical(textConnectionValue(out)[2L], "LaTeX"));
close(out)

## empty output in R <= 4.2.x


Yes, known for a few days on the R-core list. I am in the middle of an 
OS upgrade on that machine and won't have time to do more than report 
until that (and all the re-building and re-checking) is complete.



## as.POSIXlt()  gave integer overflow
stopifnot(as.POSIXlt(.Date(2^31 + 10))$year == 5879680L)

Error: as.POSIXlt(.Date(2^31 + 10))$year == 5879680L is not TRUE
Execution halted


I should have reported this earlier, but somehow did not find the time
to do so.  So I thought I mention it here. :)

Cheers,

Berwin

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



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

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

Re: [Rd] Making CRAN memory access checks more accessible?

[Prof Brian Ripley]

On 28/02/2022 19:15, Bill Dunlap wrote:
valgrind will detect some of the memory issues that UBSAN does.  


Only very few.  None of the current 43 CRAN packages with UBSAN issues 
have them detected by valgrind ... the valgrind overlap is more with 
ASAN issues (see 
https://github.com/google/sanitizers/wiki/AddressSanitizerComparisonOfMemoryTools).


The UB sanitizer is heavily tied to the compiler.  This has meant that 
new versions of gcc have found more and more issues and (most 
pertinently here) recent versions of clang find about twice as many 
issues as gcc 10/11.


UBSAN in theory runs on quite a range of platforms --- 
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#supported-platforms 
-- which unfortunately does not say for which CPUs on those OS.  (Also, 
that is about LLVM clang and not Apple clang as normally used on macOS. 
 And gcc seems only to point to LLVM documentation for supported 
platforms, but its implementation clearly differs.)



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

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

Re: [Rd] minor CRAN issue

[Prof Brian Ripley]

On 28/02/2022 17:08, Therneau, Terry M., Ph.D. via R-devel wrote:

I just bundled up and submitted the survival package, using R Under development 
(unstable)
(2022-02-28 r81833) -- "Unsuffered Consequences"
The 00-check.log file has a lot of lines like the following:

9a10
  > > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
75a77,78
  > > base::assign(".dptime", (proc.time() - get(".ptime", pos = 
"CheckExEnv")), p
os = "CheckExEnv")
  > > base::cat("Surv", base::get(".format_ptime", pos = 
'CheckExEnv')(get(".dptim
e", pos = "CheckExEnv")), "\n", file=base::get(".ExTimings", pos = 'CheckExEnv')
, append=TRUE, sep="\t")
81a85


One set for every .Rd file.   I don't see those when I do a diff, however:

tmt%  diff survival.Rcheck/survival-Ex.Rout 
survival/tests/Examples/survival-Ex.Rout.save
3926c3926
< Time elapsed:  10.328 0.133 10.461 0 0
---
  > Time elapsed:  10.399 0.08 10.48 0 0

Very minor.



Not a CRAN issue (R CMD check is not from CRAN).  Looks like you did not 
follow the advice in footnote 21 of the manual:


https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#FOOT21


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

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

Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'

[Prof Brian Ripley]

On 16/12/2021 09:13, Stephen Berman wrote:

I just did `svn up' on the R development sources, switched to the build
directory (I build R out of tree), ran make, and got this:


Precisely which version of R-devel updating from which version? -- this 
is an area that has changed frequently in the last several days.


I suspect 'make clean' is not enough -- use 'make distclean' for an ab 
initio build.




make[6]: Entering directory '/home/steve/build/r-devel/src/library/tools/src'
../../../../library/tools/libs/tools.so is unchanged
make[6]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src'
make[5]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src'
make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[4]: Entering directory '/home/steve/build/r-devel/src/library/tools'
installing 'sysdata.rda'
Error: 'hashtab' is not an exported object from 'namespace:utils'
Execution halted
make[4]: *** [/home/steve/src/R/r-devel/share/make/basepkg.mk:151: sysdata] 
Error 1
make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[3]: *** [Makefile:36: all] Error 2
make[3]: Leaving directory '/home/steve/build/r-devel/src/library/tools'
make[2]: *** [Makefile:37: R] Error 1
make[2]: Leaving directory '/home/steve/build/r-devel/src/library'
make[1]: *** [Makefile:28: R] Error 1
make[1]: Leaving directory '/home/steve/build/r-devel/src'
make: *** [Makefile:61: R] Error 1

I then did `make clean', ran configure and make again, and got the same
failure.  Is this a known issue and is there a fix?

Steve Berman

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



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

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

Re: [Rd] Dropping RHS of a formula using NULL assignment

[Prof Brian Ripley]

On 14/12/2021 20:26, Blackwell, Matthew wrote:

Hello all,

In attempting to create a one-sided formula from a two-sided formula,
I discovered that the following syntax will successfully complete this
operation:


f <- y ~ x + z
f[2] <- NULL
f

~x + z

str(f)

Class 'formula'  language ~x + z
   ..- attr(*, ".Environment")=

In searching through the formula documentation, I couldn't find this
technique as documented and wondered whether or not it is expected and
if it makes sense to develop a package against the behavior. I'm using
R 4.1.0, but I see the same on R-devel (r81303). I asked on Twitter,
but someone thought this list might be a better venue.

Apologies if I missed some documentation and thanks in advance.


See ?"~", which says

 A formula has mode ‘call’.  It can be subsetted by ‘[[’: the
 components are ‘~’, the left-hand side (if present) and the
 right-hand side _in that order_.

That would suggest that

f <- y ~ x + z
f[[2]] <- NULL

was the documented way (and the one I would have used).   However, ?"[" says

 ‘[’ and ‘[[’ are sometimes applied to other recursive objects such
 as calls and expressions.  Pairlists are coerced to lists for
 extraction by ‘[’, but all three operators can be used for
 replacement.




Cheers,
Matt

~~
Matthew Blackwell
Associate Professor of Government
Harvard University
https://www.mattblackwell.org


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

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

Re: [Rd] [External] svd For Large Matrix

[Prof Brian Ripley]

On 13/08/2021 15:58, luke-tier...@uiowa.edu wrote:

[copying the list]

svd() does support matrices with long vector data. Your example works
fine for me on a machine with enough memory with either the reference
BLAS/LAPACK or the BLAS/LAPACK used on Fedora 33 (flexiblas backed, I
believe, by a version of openBLAS). Take a look at sessionInfo() to
see what you are using and consider switching to another BLAS/LAPACK
if necessary. Running under gdb may help tracking down where the issue
is and reporting it for the BLAS/LAPACK you are using.


See also 
https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Large-matrices which 
(to nuance Prof Tierney's comment) mentions that svd on long-vector 
*complex* data has been known to segfault (with the reference BLAS/Lapack).


My guess was that this was an out-of-memory condition not handled 
elegantly by the OS.  (There are many reasons why the posting guide asks 
for the output of sessionInfo().)


We do not have the statistical context but it seems unlikely that anyone 
is interested in each of the 45m samples, and for information on the 
proteins a quite small sample of cells would suffice.  And that not all 
45m left singular values are required (most likely none are, in which 
case the underlying Lapack routine can use a more efficient calculation).




Best,

luke

On Fri, 13 Aug 2021, Dario Strbenac via R-devel wrote:


Good day,

I have a real scenario involving 45 million biological cells (samples) 
and 60 proteins (variables) which leads to a segmentation fault for 
svd. I thought this might be a good example of why it might benefit 
from a long vector upgrade.


test <- matrix(rnorm(4500*60), ncol = 60)
testSVD <- svd(test)

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

Traceback:
1: La.svd(x, nu, nv)
2: svd(test)




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

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

Re: [Rd] Double to uint64_t on M1

[Prof Brian Ripley]

On 12/08/2021 04:52, Simon Urbanek wrote:


Dipterix,

this has nothing to do with R. 2^63 is too large to be represented as singed 
integer, so the behavior is undefined - to quote from the C99 specs (6.3.1.4):

"If the value of the integral part cannot be represented by the integer type, the 
behavior is undefined."

Your subject doesn't match your question as the uint64_t conversion is 
well-defined and the same on both platforms, but the conversion to int64_t in 
undefined.


As I was writing a reply to say the same thing, a few more comments.

- the example is actually in C++, but also undefined there.

- R is more careful:
> as.integer(2^31)
[1] NA
Warning message:
NAs introduced by coercion to integer range

- there is a sanitizer for this, on platforms including Linux and macOS 
(at least with clang, 
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#supported-platforms).




Cheers,
Simon



On 12/08/2021, at 10:50 AM, Dipterix Wang  wrote:

Hi,

I was trying to convert REALSXP to int64_t in C, then found that converting 
2^63 is inconsistent across platforms:


On M1 ARM osx, 2^63 (double) bit converting to `int64_t` becomes 
9223372036854775807
On x86_64 ubuntu server, 2^63 (double) bit converting to `int64_t` is 
-9223372036854775808

I was wondering if this is desired behavior to R?

Here's the code to replicate the results above.

print_bit <- Rcpp::cppFunction(r"(
SEXP print_bit(SEXP obj){

  int64_t tmp1 = *REAL0(obj);
  printf("%lld ", tmp1);

  return(R_NilValue);
}
)")

print_bit(2^63)

Thanks,
- Dipterix
[[alternative HTML version deleted]]

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



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




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

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

Re: [Rd] Bracketed paste issues on Linux

[Prof Brian Ripley]

I would have used source("clipboard") on systems which support it (Tomas 
has confirmed it works on Linux).  See ?file.


The macOS equivalent source(pipe("pbpaste")) also works.

On 14/06/2021 11:06, Cesko Voeten wrote:

Making it 1024 times larger gives:

installing 'sysdata.rda'
Error: segfault from C stack overflow

Making it only 4 times larger provides a usable R. In my test case of 
copying&pasting mgcv::gam, I observe the same visual corruption at the 
prompt as before, but when pressing return it has actually been received 
correctly. My real-world problem involved a file 33KiB in size, which - 
as expected, since 16KiB < 33KiB - still has the same problem as before.


I know nothing about readline, but I presume that there is no way for 
this buffer size to be dynamically resized at run time. In that case, 
maybe R should simply force-disable readline's bracketed paste? By the 
way, according to readline's changelog, this does indeed seem to be a 
feature that changed (viz. was enabled in more places) from readline-8.0 
to readline-8.1.


Finally, please disregard my earlier comment about vim and nano working 
just fine. They do, but they don't actually use readline (according to 
ldd), so don't provide a valid comparison.


Thanks for your efforts!
Cesko

On 14-06-2021 at 08:33, Tomas Kalibera wrote:
Thanks, Cesko, for more debugging. As you are already compiling the 
code, could you please try increasing CONSOLE_BUFFER_SIZE in 
./include/Defn.h from 4096 to some very large value (e.g. 1024 times), 
rebuild R and check if the problems (not all bytes received correctly, 
visual corruption) go away for texts of the size you looked at before?



Thanks,
Tomas



On 6/13/21 10:59 AM, Voeten, C.C. wrote:


Thanks for looking into this! I've just compiled today's R-devel 
snapshot, and it shows the same issue. extSoftVersion() from that build:


 zlib
 "1.2.11"
    bzlib
 "1.0.8, 13-Jul-2019"
   xz
  "5.2.5"
 PCRE
   "10.37 2021-05-26"
  ICU
   "69.1"
  TRE
    "TRE 0.8.0 R_fixes (BSD)"
    iconv
 "glibc 2.33"
 readline
    "8.1"
 BLAS
"/home/cesko/r-devel/usr/lib64/R/lib/libRblas.so"

Thanks for your observation that it works on your system - that 
implicates my readline-8.1 as being the culprit. Unfortunately, I 
don't dare attempt to downgrade it on my system to test, and 
regardless we still don't know why other readline-using programs can 
paste in the same text with no issues.



I've made some further progress on debugging: I noticed that text 
<4096 bytes in size arrives fine (although sometimes with visual 
corruption), but text >4096 bytes doesn't. Pasting in the result of 
perl -e 'print ("if(T)cat(\"a\")\n"x292)' works as expected, changing 
the 292 to 293 causes R to print a bunch of a's followed by the 
source code of the cat function.



To still answer your question: with mgcv::gam, pasting in the first 
94 lines (as printed by R with options(width=80)) produces a visual 
corruption of the prompt (it reads "G$family <- 
familyar.summaryintercept = drop.intercept)) control$scalePenalty,") 
but if I press return and type the closing "}" the code has actually 
arrived just fine. The text up to and including that line is 4023 
bytes in size; when trying to add in more, it fails again.



Cesko
-- 


*Van:* Tomas Kalibera 
*Verzonden:* zondag 13 juni 2021 10:00:27
*Aan:* Voeten,

Re: [Rd] Status of "**" operator

[Prof Brian Ripley]

On 21/05/2021 16:01, Marc Schwartz via R-devel wrote:

Hi All,

I was just sent some older R code from circa 2004, which contains the 
use of the "**" operator, which is parsed as "^".


 From looking at ?"**", I see the following in the Note section:

"** is translated in the parser to ^, but this was undocumented for many 
years. It appears as an index entry in Becker et al (1988), pointing to 
the help for Deprecated but is not actually mentioned on that page. Even 
though it had been deprecated in S for 20 years, it was still accepted 
in R in 2008."



In using R 4.1.0:

 > 2**3
[1] 8

the operator is still accepted in 2021.

Thus, has there been any discussion regarding the deprecation of this 
operator, or should the help file at least be updated to reflect the 
status in 2021?


Not really: there is no guarantee that it will be accepted for all of 
2021.  As it is deprecated and AFAIK untested, it could be broken at any 
time.  OTOH, no one has mentioned in my hearing a wish to actually 
remove it.


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

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

Re: [Rd] Apple M1 CRAN checks

[Prof Brian Ripley]

On 22/02/2021 08:30, Travers Ching wrote:

I noticed CRAN is now doing checks against Apple M1, and some packages are
failing including a dependency I use.


I don't know what this refers to: M1 Mac CRAN checks are planned but 
AFAICS not yet included in the main results tables.


OTOH, 'Additional issues' on M1 Mac have been reported on the results 
pages since early December.



Is building on M1 now a requirement, or can the check be ignored? If it's a
requirement, how can one test it out?


'requirement' for what?

I am not aware of any CRAN package for which 'R CMD build' does not work 
on an M1 Mac.


*Checking* might need an M1 Mac machine.  CRAN has only been notifying 
issues which can easily be corrected without access to M1 hardware (such 
as using suggested packages unconditionally or using optional 
capabilities without checking).



Travers

[[alternative HTML version deleted]]


Please do re-read the posting guide (and 'Writing R Extensions').
Also, this is not r-package-devel 

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

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

Re: [Rd] Compression (really about LazyDate)

[Prof Brian Ripley]

On 18/02/2021 18:30, Therneau, Terry M., Ph.D. via R-devel wrote:

This is a CRAN question:

I have taken care to compress files in the data directory using "xz" (and 
checked that it
is the best).  Is there then any impact or use for the LazyDataCompression 
option in the
DESCRIPTION file?



I have difficulty comprehending that, so I will try to answer my guess 
at what you meant to ask.


What LazyDataCompression does is completely separate from the contents 
of the data directory.  As the manual say



Some packages using ‘LazyData’ will benefit from using a form of 
compression other than gzip in the installed lazy-loading database. This 
can be selected by the --data-compress option to R CMD INSTALL or by 
using the ‘LazyDataCompression’ field in the DESCRIPTION file. Useful 
values are bzip2, xz and the default, gzip. The only way to discover 
which is best is to try them all and look at the size of the 
pkgname/data/Rdata.rdb file.



When a package is installed with LazyData (and you neglected to tell us 
if that is the case), the datasets in the data directory are loaded (and 
hence decompressed), and stored in a database.  For a LazyData package 
the compression used in the data directory only affects the source 
package size (I guess your criterion for 'best') and how fast it is 
installed (rarely a consideration but there have been LazyData packages 
where installing the data takes most of the time).  At run-time only the 
compression specified by LazyDataCompression is relevant.


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

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

Re: [Rd] issue with print()ing multibyte characters on R 4.0.4

[Prof Brian Ripley]

On 17/02/2021 04:58, Hiroaki Yutani wrote:

Hi all,

I saw several people on Japanese locale claim that, on R 4.0.4,
print() doesn't display
Japanese characters correctly. This seems to happen only on Windows
and on macOS (I
usually use Linux and I don't see this problem).

For example, in the result below, "鬼" and "外" are displayed in
"\u" format. What's
curious here is that "は" is displayed as it is, by the way.


"鬼は外"

[1] "\u9b3cは\u5916"

But, if I use such functions as message() or cat(), the string is
displayed as it is.


message("鬼は外")

鬼は外


that does not escape non-printable characters, so as expected.


Considering the fact that it seems only Windows and macOS are
affected, I suspect this
is somehow related to this change described in the release note,
(though I have no idea
what change this is):

 The internal table for iswprint (used on Windows, macOS and AIX) has been
 updated to include many recent Unicode characters.
 (https://cran.r-project.org/doc/manuals/r-release/NEWS.html)

Before I'm going to file this issue on Bugzilla, I'd like to confirm
if this is not the intended
change, and, if this is actually intended, I want to discuss how to
improve this behaviour.


I am sorry: this was not intended but it was no one reported in the run 
up to 4.0.4.  It seems to be working in R-devel so I suggest you check 
that or go back to 4.0.3.


It looks like a line in the iswprint table got deleted in the merge from 
R-devel.  I will try to set up some automated checks to see if I can 
find any other problems, but that will take a few days.


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

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

Re: [Rd] Does type raw really have no ordering?

[Prof Brian Ripley]

On 08/02/2021 13:25, Hugh Parsonage wrote:

In the help for Extremes  ?min


Note that all versions fail for raw and complex vectors since these have no 
ordering.


This makes sense for complex vectors, yet `raw` vectors seem to have a
natural order. Indeed:

which.min(as.raw(c(5L, 2L, 1L, 99L)))

works and would identify the minimum.  Similarly comparison operators
work on raw vectors (and fail, expectedly, on complex ones).

Is there something peculiar to min() and friends that make raw vectors
invalid input?


Please re-read the help for which.min: as it says you computed on an 
internal coercion to double.  Doubles do have an ordering.


Like factors, raw vectors have numeric codes, but that does not imply 
that the ordering of the numeric codes is relevant to the original 
object.  And reading the help for comparisons would have informed you


 Raw vectors should not really be considered to have an order, but
 the numeric order of the byte representation is used.

One use case for a raw vector is to store bytes in an unspecified 8-bit 
encoding.  What ordering would be relevant depends on the encoding - 
this is even true for the ASCII subset - some people sort AaBb some 
AB...ab and some locales even sort aAbB (although I have never seen that 
recommended for human usage).


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

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

Re: [Rd] Does parallel::mclapply work under emulation (Rosetta 2) on Apple Silicon?

[Prof Brian Ripley]

On 15/01/2021 05:53, Michael O'Dell via R-devel wrote:

Setting aside the documented problems of running R natively on Apple's M1 
machines 
(https://developer.r-project.org/Blog/public/2020/11/02/will-r-work-on-apple-silicon


That's rather dated: see the more recent reports on this list.

/index.html) and similarly the current lack of native versions of many 
eco-system components (e.g. the discussion 
here:https://github.com/neurolabusc/AppleSiliconForNeuroimaging ), will 
code using parallel::mclapply() run as expected (i.e. on Intel hardware) 
under emulation (Rosetta 2)? Has anyone tested this?


Yes: I have no idea why you would think otherwise.  All mclapply uses is 
forking, and the OS on an M1 Mac is the same as that on a (Big Sur) 
Intel Mac (in many cases literally the same, with the same bi-arch 
executables).


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

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

Re: [Rd] Unicode characters in ISO8859-15 locale

[Prof Brian Ripley]

On 17/12/2020 12:28, Jeroen Ooms wrote:

The hunspell package uses the code below to replace curly quotes (aka


officially these are directional (or right/left) quotes.


fancyquotes) with a regular ascii quotes that are needed for check
spelling:

 chartr("\u2019", "'", input)

As of last week this stopped working on CRAN in the Linux server that
runs in ISO8859-15 locale. From the error message, it seems that R no
longer parses the escaped unique string, which gets turned into
"".


You need to distinguish the string and what gets printed.  I see (for 
the CRAN log from a 2-day-old R)


 Error in chartr("", "'", as.character(add_words)) :

which is what I would expect to be printed in that locale:


x <- "\u2019"
Encoding(x)

[1] "UTF-8"

x

[1] ""


Is this expected?


Changes are expected, as this is an area being worked on (to try to 
remove some system-dependent behaviour).  However, I cannot reproduce 
this easily:



chartr("\u2019", "'", "abc\u2019")

[1] "abc'"

As I say, work in progress.

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

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

Re: [Rd] R-devel crash

[Prof Brian Ripley]

On 18/12/2020 13:39, Gábor Csárdi wrote:

FYI.


tolower, toupper and chartr with non-native chars is work in progress. 
(They were getting things wrong in a platform-dependent way, and it 
seems the replacement code is also flaky, if in general better than what 
went before.)





sessionInfo()

R Under development (unstable) (2020-12-17 r79645)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux bullseye/sid

Matrix products: default
BLAS:   /opt/R-devel/lib/R/lib/libRblas.so
LAPACK: /opt/R-devel/lib/R/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_US.iso885915   LC_NUMERIC=C
  [3] LC_TIME=en_US.iso885915LC_COLLATE=en_US.iso885915
  [5] LC_MONETARY=en_US.iso885915LC_MESSAGES=en_US.iso885915
  [7] LC_PAPER=en_US.iso885915   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.iso885915 LC_IDENTIFICATION=C

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

loaded via a namespace (and not attached):
[1] compiler_4.1.0


## Run this:

fun <- function() {
   ben <- paste0(
 "\u098F\u099F\u09BF \u098F\u0995\u099F\u09BF ",
 "\u09AD\u09BE\u09B7\u09BE \u098F\u0995\u0995 IBM ",
 "\u09B8\u09CD\u0995\u09CD\u09B0\u09BF\u09AA\u09CD\u099F"
   )
   tolower(ben)
}
fun()

## To crash:

free(): invalid next size (fast)

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) fun()
Undefined function command: "()".  Try "help function".
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7fe471fb3537 in __GI_abort () at abort.c:79
#2  0x7fe47200c708 in __libc_message (action=action@entry=do_abort,
 fmt=fmt@entry=0x7fe47211ae31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7fe4720139fa in malloc_printerr
(str=str@entry=0x7fe47211d180 "free(): invalid next size (fast)")
 at malloc.c:5347
#4  0x7fe472014c34 in _int_free (av=0x7fe47214cb80 ,
p=0x2696a30, have_lock=0)
 at malloc.c:4249
#5  0x7fe47245c090 in R_chk_free () from /opt/R-devel/lib/R/lib/libR.so
#6  0x7fe47235c8cc in do_tolower () from /opt/R-devel/lib/R/lib/libR.so
#7  0x7fe4723f466e in bcEval () from /opt/R-devel/lib/R/lib/libR.so
#8  0x7fe4723ed20d in Rf_eval () from /opt/R-devel/lib/R/lib/libR.so
#9  0x7fe472409111 in R_execClosure () from /opt/R-devel/lib/R/lib/libR.so
#10 0x7fe472408cce in Rf_applyClosure () from /opt/R-devel/lib/R/lib/libR.so
#11 0x7fe4723ed884 in Rf_eval () from /opt/R-devel/lib/R/lib/libR.so
#12 0x7fe47240f6b5 in do_begin () from /opt/R-devel/lib/R/lib/libR.so
#13 0x7fe4723ed5cb in Rf_eval () from /opt/R-devel/lib/R/lib/libR.so
#14 0x7fe472409111 in R_execClosure () from /opt/R-devel/lib/R/lib/libR.so
#15 0x7fe472408cce in Rf_applyClosure () from /opt/R-devel/lib/R/lib/libR.so
#16 0x7fe4723ed884 in Rf_eval () from /opt/R-devel/lib/R/lib/libR.so
#17 0x7fe472443550 in Rf_ReplIteration () from
/opt/R-devel/lib/R/lib/libR.so
#18 0x7fe472445766 in R_ReplConsole () from /opt/R-devel/lib/R/lib/libR.so
#19 0x7fe4724456bd in run_Rmainloop () from /opt/R-devel/lib/R/lib/libR.so
#20 0x7fe4724457fe in Rf_mainloop () from /opt/R-devel/lib/R/lib/libR.so
#21 0x00401177 in main ()
#22 0x7fe471fb4d0a in __libc_start_main (main=0x401140 ,
argc=1, argv=0x7ffc058512d8,
 init=, fini=, rtld_fini=, stack_end=0x7ffc058512c8)
 at ../csu/libc-start.c:308
#23 0x0040107a in _start ()

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




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

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

Re: [Rd] UTF-8 characters in Rd files

[Prof Brian Ripley]

On 15/12/2020 23:57, Gábor Csárdi wrote:

Dear list,

I am trying to see if there is a way to expand the set of UTF-8
characters that we can use in Rd files. The main blocker is LaTeX when
building the PDF manual.


You need to explain why this is desirable.

The other limiting factor is availability of the glyphs in fonts 
(especially for PDF and its viewers, and the man pages are rendered in 
PDF on CRAN).  Ten years ago that was a serious limitation and I am 
unaware of much change.



It is possible to use the inputenx LaTeX package, instead of inputenc,
which is an improvement, by setting the RD2PDF_INPUTENC env var before
running R CMD Rd2pdf. However, I don't see a way to make this
automatic for a package, so we cannot use it for CRAN packages, as far
as I can tell.


Also, inputenx.sty is not part of basic TeX environments such example 
BasicTeX on macOS, so it cannot be made the default.



Am I missing something? Would it make sense to have a way to specify
RD2PDF_INPUTENC (and possibly other similar env vars) for packages?

As for the possible implementation, one way would be to have a file
called `environ` or something similar in /man, that could define env
vars, and Rd2pdf would just read it in with readRenviron().


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

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

Re: [Rd] Specifying C Standard in Package's Makevars File

[Prof Brian Ripley]

On 28/09/2020 12:44, Andreas Kersting wrote:

Hi,

what is the correct way to specify a C standard in a package's Makevars file?

Building a package with e.g. PKG_CFLAGS = -std=gnu11 does work but R CMD check 
issues a warning:


for some unstated value of 'work' ...


* checking compilation flags in Makevars ... WARNING
Non-portable flags in variable 'PKG_CFLAGS':
   -std=gnu11

(Same for -std=c11.)

Thanks! Regards,
Andreas Kersting


Those flags are not portable, as 'check' correctly says.  Furthermore, 
on some platforms there may be no flag which can be added -- R documents 
that 'CC' specifies a C99 compiler, and that or CC+CFLAGS are likely to 
specify flags which are incompatible with -std=c11 (true on Solaris 
where -xc99 is used).


So, like all such overrides (see 'Writing R Extensions') you need to 
write a configure script (preferably using autoconf) to


- select an appropriate C compiler+flags
- substitute them into src/Makefile.in

For the new features I have used in C11, all known compilers make them 
available in C99 mode and a configure script could be used to test for 
their presence (as R itself does).  That is, it is rare to actually need 
to specify C11 mode.


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

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

Re: [Rd] Compilation error for R 4.0.2

[Prof Brian Ripley]

On 11/07/2020 11:47, Kurt Hornik wrote:

Wim R Cardoen writes:



Hello,
I experienced a compiler error when I tried to compile the latest version
of R i.e. R4.0.2
making iosupport.d from iosupport.c
making lapack.d from lapack.c
making list.d from list.c
making localecharset.d from localecharset.c
grep.c(74): catastrophic error: cannot open source file "pcre2.h"
   # include
(The pcre2.h header file is actually present!)




I used the following compiler flags:
# PCRE2:
# -
setenv CC gcc
setenv CFLAGS " -O2 -fPIC "
./configure --prefix=/uufs/chpc.utah.edu/sys/installdir/pcre2/10.35 \
 --enable-pcre2-16 --enable-pcre2-32 --with-pic



module purge
module load intel/2019.5.281



# USe a modern version of curl & pcre2 (The current one on Centos 7 is TOO
old)
setenv CURLDIR "/uufs/chpc.utah.edu/sys/installdir/curl/7.65.3"
setenv PCRE2DIR "/uufs/chpc.utah.edu/sys/installdir/pcre2/10.35"



setenv PATH ${PCRE2DIR}/bin:$PATH



  Setting Compiler & linker flags:
setenv CC icc
setenv CXX icpc
setenv F77 ifort
setenv FC ifort
setenv CFLAGS   " -axCORE-AVX512,CORE-AVX2,AVX,SSE4.2 -O3 -qopenmp
-fp-model precise -fPIC -I${MKLROOT}/include -I${CURLDIR}/include
   -I${PCRE2DIR}/include "


What I guess you should do is

  /path/to/configure CPPFLAGS="-I${PCRE2DIR}/include .."
  make


Or use a config.site file for all of these settings.

On some systems (including some Linux systems I have used and current 
macOS), setting too much in the environment (usually caused by long 
values) has caused software to malfunction, including to segfault so it 
is ingrained in me to avoid it.



setenv CXXFLAGS " ${CFLAGS} "
setenv FFLAGS   " ${CFLAGS} "
setenv FCFLAGS  " ${CFLAGS} "
setenv LDFLAGS  " -Wl,-rpath=${MKLROOT}/lib/intel64_lin
-L${MKLROOT}/lib/intel64_lin -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
   -Wl,-rpath=/uufs/
chpc.utah.edu/sys/installdir/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin
-L/uufs/
chpc.utah.edu/sys/installdir/intel/compilers_and_libraries_2019.5.281/linux/compiler/lib/intel64_lin
-liomp5 -lpthread -ldl -Wl,-rpath=${CURLDIR}/lib
-L${CURLDIR}/lib -lcurl
-Wl,-rpath=${PCRE2DIR}/lib -L${PCRE2DIR}/lib
  -lpcre2-8 -lpcre2-posix "



./configure --prefix=/uufs/chpc.utah.edu/sys/installdir/R/4.0.2i
--enable-R-profiling --enable-R-shlib --enable-memory-profiling
--enable-java --enable-shared=yes --with-blas="$LDFLAGS" --with-readline
--with-cairo --with-tcltk --with-libpng --with-jpeglib --with-libtiff
--with-ICU --with-pic --with-x --with-lapack --with-pcre2



I also appended the corresponding config.log:


It did not get through the filters.




Thank you,



Wim



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

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

Re: [Rd] tcltk image reading problem (on a mac?): [tcl] encountered an unsupported criticial chunk type "eXIf"

[Prof Brian Ripley]

On 12/06/2020 03:49, Fox, John wrote:

Dear Simon,


On Jun 11, 2020, at 9:00 PM, Simon Urbanek  wrote:

Wayne,

that one is unrelated, but interesting - you can fix it with

sudo install_name_tool -change \
  /usr/local/lib:/opt/X11/lib/libtk8.6.dylib \
  /usr/local/lib/libtk8.6.dylib \
  /usr/local/bin/wish8.6

There is a bug in tcltk with IDs on the libraries which I have worked-around 
for R, but not for wish.

Back to the original question - do you have any example of a file that doesn't 
work so I could test? Exif chunks are fairly rare in PNG and are a more late 
extension so I couldn't find any examples.


The code in Wayne's original message (copied below) generated the offending 
file:

library(tcltk)

fname <- "Rplot.png"
png(filename = fname, width = 500, height = 500)
hist(rnorm(20))
dev.off()

tkimage.create("photo", file = fname)


There are several png() devices for R.  The default on macOS is to use 
Quartz, and that depends on macOS system functions so might well have 
changed with Mojave -> Catalina.


As a workaround, try e.g. png(type='cairo').  E.g.

fname <- file.path(tempdir(), "Rplot.png")
png(filename = fname, width = 500, height = 500, type="cairo")
hist(rnorm(20))
dev.off()

library(tcltk)
tkimage.create("photo", file = fname)

works for me on Catalina.


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

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

Re: [Rd] CRAN checks and ASAN

[Prof Brian Ripley]

On 11/06/2020 15:57, Therneau, Terry M., Ph.D. via R-devel wrote:

I have a version of R-devel on my development box that has the address 
sanitizer turned
on.   This was instrumental in finding a pair of subtle memory issues.  (I had 
read, but
never written, one element past the end of an array, which caused issues on some
architectures.)

1. I now get a end-of-job messsages from R CMD check survival3.2-3.tar.gz about 
leaks in
main/eval.c.    They don't appear in 00config.out or 00install.out.
   I assume that I can ignore these?

2. When I run my long 'check all packages that depend on survival' job, a lot 
of package
fail with sanitizer leaks.   Again, not my problem?
If so, I just need to recomple R without the ASAN tags and try again.


The manual suggests you disable the Leak Sanitizer (nowadays by default 
enabled by ASAN): valgrind is a better way of detecting memory leaks. 
We know R has 'leaks': it does not release memory in use right up to the 
end (and some OS things do too).



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

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

Re: [Rd] r-project.org SSL certificate issues

[Prof Brian Ripley]

On 10/06/2020 00:39, peter dalgaard wrote:

Yes and no... At least as I understand it (Disclaimer: There are things I am 
pretty sure that I don't understand properly, somewhere in the Bermuda triangle 
beween CA bundles, TLS protocols, and Server-side settings), there are two 
sided to this:

One is that various *.r-project.org servers got hit by a fumble where a 
higher-up certificate in the chain of trust expired before the *.r-project.org 
one. This was fixed by changing the certificate chain on each server.

The other side is that this situation hit Mac users harder than others, because 
Apple's LibreSSL doesn't have the same feature that openSSL has to detect a 
secondary chain of trust when the primary one expired. This was not unique to R 
- svn also failed from the command line - but it did affect download.file() 
inside R.

The upshot is that there might be 3rd party servers with a similar certificate 
setup which have not been updated like *.r-project.org. This is not too 
unlikely since web browsers do not have trouble accessing them, and the whole 
matter may go undetected. For such servers, download.file() would still fail.


A dozen or so packages fail their CRAN checks because of this.  The most 
common problematic site has been reported to its web admins, but not 
resolved.



I.e., there is a case to be made that we might want to link openSSL rather than 
LibreSSL.  On the other hand, I gather that newer versions of LibreSSL contain 
the relevant protocol upgrade, so maybe one can just wait for Apple to update 
it. Or maybe we do want to link R against openSSL, but almost certainly not for 
a hotfix release.


This is not just a macOS issue: most CRAN failures are seen on Debian 
and Solaris as well as macOS (but not Fedora).  And a different one (3 
packages by the same author misusing RCurl to set a <= 2014 root 
certificate bundle) is seen only on Fedora.



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

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

Re: [Rd] valgrind false positive on R startup?

[Prof Brian Ripley]

It is known, with a known workaround, see e.g. 
https://www.stats.ox.ac.uk/pub/bdr/memtests/README.txt .  Set 
suppressions in ~/.valgrindrc, e.g. the CRAN check machine has


--suppressions=/data/blackswan/ripley/wcsrtombs.supp

It is an issue in your OS (glibc), not TRE nor R.

On 10/06/2020 00:21, Toby Hocking wrote:

Hi all,

I'm on Ubuntu 18.04, running R-4.0.0 which I compiled from source, and
using valgrind I am always seeing the following message. Does anybody
else see that? Is that a known false positive? Any ideas how to
fix/suppress? Seems related to TRE, do I need to upgrade that?

(base) tdhock@maude-MacBookPro:~/R/binsegRcpp$ R --vanilla -d valgrind
-e 'extSoftVersion()'
==9565== Memcheck, a memory error detector
==9565== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9565== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9565== Command: /home/tdhock/lib/R/bin/exec/R --vanilla -e extSoftVersion()
==9565==
==9565== Conditional jump or move depends on uninitialised value(s)
==9565==at 0x55AB9E0: __wcsnlen_sse4_1 (strlen.S:147)
==9565==by 0x5598EC1: wcsrtombs (wcsrtombs.c:104)
==9565==by 0x551EB20: wcstombs (wcstombs.c:34)
==9565==by 0x50BAA07: wcstombs (stdlib.h:154)
==9565==by 0x50BAA07: tre_parse_bracket_items (tre-parse.c:336)
==9565==by 0x50BAA07: tre_parse_bracket (tre-parse.c:453)
==9565==by 0x50BAA07: tre_parse (tre-parse.c:1380)
==9565==by 0x50B2498: tre_compile (tre-compile.c:1920)
==9565==by 0x50AFBE0: tre_regcompb (regcomp.c:150)
==9565==by 0x4FA9F42: do_gsub (grep.c:2023)
==9565==by 0x4F79045: bcEval (eval.c:7090)
==9565==by 0x4F8572F: Rf_eval (eval.c:723)
==9565==by 0x4F8754E: R_execClosure (eval.c:1888)
==9565==by 0x4F88316: Rf_applyClosure (eval.c:1814)
==9565==by 0x4F85902: Rf_eval (eval.c:846)
==9565==

R version 4.0.0 (2020-04-24) -- "Arbor Day"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (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.


extSoftVersion()

 zlibbzlib
 "1.2.11" "1.0.6, 6-Sept-2010"
   xz PCRE
  "5.2.2"   "10.31 2018-02-12"
  ICU  TRE
   "60.2""TRE 0.8.0 R_fixes (BSD)"
iconv readline
 "glibc 2.27""7.0"
 BLAS
"/home/tdhock/lib/R/lib/libRblas.so"




==9565==
==9565== HEAP SUMMARY:
==9565== in use at exit: 40,492,919 bytes in 9,170 blocks
==9565==   total heap usage: 19,784 allocs, 10,614 frees, 62,951,535
bytes allocated
==9565==
==9565== LEAK SUMMARY:
==9565==definitely lost: 0 bytes in 0 blocks
==9565==indirectly lost: 0 bytes in 0 blocks
==9565==  possibly lost: 0 bytes in 0 blocks
==9565==still reachable: 40,492,919 bytes in 9,170 blocks
==9565==   of which reachable via heuristic:
==9565== newarray   : 4,264 bytes in 1 blocks
==9565== suppressed: 0 bytes in 0 blocks
==9565== Rerun with --leak-check=full to see details of leaked memory
==9565==
==9565== For counts of detected and suppressed errors, rerun with: -v
==9565== Use --track-origins=yes to see where uninitialised values come from
==9565== ERROR SUMMARY: 46 errors from 1 contexts (suppressed: 0 from 0)
(base) tdhock@maude-MacBookPro:~/R/binsegRcpp$

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




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

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

Re: [Rd] GCC warning

[Prof Brian Ripley]

On 23/05/2020 07:38, Simon Urbanek wrote:

Adrian,

newer compilers are better at finding bugs - you may want to read the full 
trace of the error, it tells you that you likely have a memory overflow when 
using strncpy() in your package. You should check whether it is right. 
Unfortunately we can’t help you more specifically, because I don't see any link 
to what you submitted so can’t look at the code involved.


NB: debian-gcc on CRAN does have the latest version of gcc (10.1) and 
the link would likely have given fuller details (such links are provided 
on CRAN report pages but I do not know for submissions).


gcc does sometimes give false alarms here (there is one for R with gcc 
>= 9 and another for gcc >= 10) but see 
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ 
.  Most can easily be workaround by cleaner code.




Cheers,
Simon




On May 22, 2020, at 7:25 PM, Adrian Dușa  wrote:

I am trying to submit a package on CRAN, and everything passes ok on all platforms but 
Debian, where CRAN responds with an automatic "significant" warning:

* checking whether package ‘QCA’ can be installed ... [35s/35s] WARNING
Found the following significant warnings:
  /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 
‘__builtin_strncpy’ output may be truncated copying 12 bytes from a string of 
length 79 [-Wstringop-truncation]
See ‘/srv/hornik/tmp/CRAN/QCA.Rcheck/00install.out’ for details.


I know the cause of this: using a cursomized version of some external C library, 
coupled with  in the Description.

But I do not know hot to get past this warning, since it refers to a builtin 
GCC function strncpy. As far as I read, this should be solved by a simple GCC 
upgrade to the newest version, but that is something outside my code base, 
since GCC resides on the CRAN servers.

In the meantime, to get the package published, did anyone encountered a similar 
problem? If so, is there a workaround?

—
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu



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

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

Re: [Rd] dbinom link

[Prof Brian Ripley]

On 18/05/2020 09:57, peter dalgaard wrote:

In principle a good idea, but I'm not sure the whereabouts of Catherine Loader 
are known at this point. Last peeps from her on the net seem to be about a 
decade old.


All attempts to contact Dr Loader re the locfit package failed, 
including those earlier this year.



.pd


On 18 May 2020, at 10:31 , Abby Spurdle  wrote:

This has come up before.

Here's the last time:
https://stat.ethz.ch/pipermail/r-devel/2019-March/077478.html

I guess my answer to the following the question...

Perhaps we should ask permission to
nail the thing down somewhere on r-project.org?

...would be, to reproduce it somewhere.
And then update the link in the binom help file.

Given that the article was previously available freely (with no
apparent restrictions on reproducing it), and that the author has
significant published works which are open access, I'd be surprised if
there's any objection to reproducing it.


On Mon, May 18, 2020 at 8:01 PM Koenker, Roger W  wrote:


FWIW the link from ?dbinom to the Loader paper on Binomials is broken but the 
paper seems to be
available here:   
https://octave.1599824.n4.nabble.com/attachment/3829107/0/loader2000Fast.pdf

Roger Koenker
r.koen...@ucl.ac.uk
Honorary Professor of Economics
Department of Economics, UCL
Emeritus Professor of Economics
and Statistics, UIUC



[[alternative HTML version deleted]]

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


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





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

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

Re: [Rd] Rtools and R 4.0.0?

[Prof Brian Ripley]

On 02/04/2020 05:35, Kevin Ushey wrote:

Hello,

Has a decision been made yet as to whether R 4.0.0 on Windows is going
to be built using the new gcc8 toolchain (described at
https://cran.r-project.org/bin/windows/testing/rtools40.html)?


Short answer: 'no'.


From the sidelines, I can see that the toolchain is being used to

build and test packages on CRAN; if there are any remaining issues
that I can help to try and run down (either in R or any CRAN packages)
I'd be happy to try and help.


It is still under consideration, but resource constraints are biting 
hard as people's lives get more complicated.


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

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

Re: [Rd] status of Java & rJava?

[Prof Brian Ripley]

On 29/03/2020 04:07, Simon Urbanek wrote:

Spencer,

you could argue that Java is dead since Oracle effectively killed it by 
removing all public downloads, but if you manage to get hold of a Java 
installation then it works just fine with R. To my best knowledge there has 
never been an issue if you installed rJava from source. macOS Catalina has made 
binary distributions impossible due to additional restrictions on run-time, but 
even that has been how solved with the release of rJava 0.9-12, so please make 
sure you use the latest rJava. In most cases that I have seen issues were 
caused by incorrect configuration (setting JAVA_HOME incorrectly [do NOT set it 
unless you know what you're doing!], not installing Java for the same 
architecture as R etc.). If you have any issues feel free to report them. rJava 
0.9-12 has quite a few changes that try to detect user errors better and report 
them so I strongly suggest users to upgrade.


There is OpenJDK, and https://adoptopenjdk.net provides binaries for 
macOS, including the preferred Java 11 LTS.  I just re-checked that, and 
after


env 
JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home 
R CMD javareconf


I was able to install from source and check rJava 0.9-12 in 4.0.0 alpha. 
 For the CRAN binary of 3.6.3 I had to make sure I was using clang 7: 
'clang' defaults to that in the Apple CLT which does not support 
-fopenmp -- but the binary package just worked.


[All on Catalina.]

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

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

Re: [Rd] ASAN error with R-devel

[Prof Brian Ripley]

This is entirely within your OS's installation of Tcl/Tk and X11: the 
latter both allocated and freed.  We've seen it before (even had it as 
bug report on R). Please check your OS is fully up-to-date and if so 
report it there.


On 01/07/2019 15:55, Therneau, Terry M., Ph.D. via R-devel wrote:

I have an ASAN enabled version of R-devel on my test machine, and can get it to 
relably
crash.  Here is the first part of the session:

tmt-local2434% R --vanilla

R Under development (unstable) (2019-06-28 r76752) -- "Unsuffered Consequences"
Platform: x86_64-pc-linux-gnu (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.
  > install.packages('kinship2')
Installing package into ‘/home/therneau/Rlib’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
=
==21606==ERROR: AddressSanitizer: heap-use-after-free on address 0x60242830 
at pc
0x7f9f834fa0f7 bp 0x7fff24ab9050 sp 0x7fff24ab87f8
READ of size 1 at 0x60242830 thread T0
      #0 0x7f9f834fa0f6 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5a0f6)
      #1 0x7f787837d683 in _XimUnRegisterIMInstantiateCallback
(/usr/lib/x86_64-linux-gnu/libX11.so.6+0x64683)
      #2 0x7f7878364d32 in XUnregisterIMInstantiateCallback
(/usr/lib/x86_64-linux-gnu/libX11.so.6+0x4bd32)
      #3 0x7f787837d566 in _XimRegisterIMInstantiateCallback
(/usr/lib/x86_64-linux-gnu/libX11.so.6+0x64566)
      #4 0x7f7878364cba in XRegisterIMInstantiateCallback
(/usr/lib/x86_64-linux-gnu/libX11.so.6+0x4bcba)
      #5 0x7f78745cddfb in TkpOpenDisplay 
(/usr/lib/x86_64-linux-gnu/libtk8.6.so+0xf2dfb)
      #6 0x7f787453c769 (/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x61769)
      #7 0x7f787453d0ab in TkCreateMainWindow 
(/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x620ab)
      #8 0x7f7874548cc6 (/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x6dcc6)
      #9 0x7f7874546c7a (/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x6bc7a)
      #10 0x7f787453f6c4 (/usr/lib/x86_64-linux-gnu/libtk8.6.so+0x646c4)
      #11 0x7f7874bf0c0b in tcltk_init 
/usr/local/src/R-devel/src/library/tcltk/src/tcltk.c:697
      #12 0x5582e3aa93c1 in do_dotCode 
/usr/local/src/R-devel/src/main/dotcode.c:1743
      #13 0x5582e3b41f79 in bcEval /usr/local/src/R-devel/src/main/eval.c:6775
      #14 0x5582e3b6a5df in Rf_eval /usr/local/src/R-devel/src/main/eval.c:620
      #15 0x5582e3b702b9 in R_execClosure 
/usr/local/src/R-devel/src/main/eval.c:1780
      #16 0x5582e3b72777 in Rf_applyClosure 
/usr/local/src/R-devel/src/main/eval.c:1706
      #17 0x5582e3b4ab0a in bcEval /usr/local/src/R-devel/src/main/eval.c:6743
      #18 0x5582e3b6a5df in Rf_eval /usr/local/src/R-devel/src/main/eval.c:620
      #19 0x5582e3b6c55e in forcePromise 
/usr/local/src/R-devel/src/main/eval.c:516
      #20 0x5582e3b6d22f in FORCE_PROMISE 
/usr/local/src/R-devel/src/main/eval.c:4900
   ...
      #133 0x7f788f5e6b96 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
      #134 0x5582e392b999 in _start (/usr/local/src/R-devel/bin/exec/R+0x135999)

0x60255af0 is located 0 bytes inside of 1-byte region 
[0x60255af0,0x60255af1)
freed by thread T0 here:
      #0 0x7f7891a157b8 in __interceptor_free 
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7b8)
      #1 0x7f7878373d8c in XSetLocaleModifiers 
(/usr/lib/x86_64-linux-gnu/libX11.so.6+0x5ad8c)

previously allocated by thread T0 here:
      #0 0x7f7891a15b50 in __interceptor_malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
      #1 0x7f7878373984 in _XlcDefaultMapModifiers
(/usr/lib/x86_64-linux-gnu/libX11.so.6+0x5a984)

SUMMARY: AddressSanitizer: heap-use-after-free
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5a0f6)

--
The window with a choice of machines never appeared.

Terry T.




[[alternative HTML version deleted]]

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




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

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

Re: [Rd] r-project.org dns

[Prof Brian Ripley]

On 26/06/2019 21:13, Tim Keitt wrote:

Sorry if this was already discussed. I notice that r-project.org is not
found in dns lookups today. (At least for me -- I tried some online web
look services as well.)

THK


We knew, but all the R listservers were also affected.  The name servers 
in Vienna have been restarted and DNS is slowly recovering (including 
delivering your message).


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

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

Re: [Rd] rgl install for R 3.7

[Prof Brian Ripley]

On 02/06/2019 16:28, Koenker, Roger W wrote:

I’ve installed R 3.7.0 on a new laptop running macos 10.14.5 and have managed 
to get most of my usual packages


I presume 'R 3.7.0' is R-devel: it is not released and may never be 
released under that version.



to compile from source with a ~/.R/Makevars file that looks like this:

CC=/usr/local/clang8/bin/clang
CXX=/usr/local/clang8/bin/clang++
LDFLAGS=-L/usr/local/clang8/lib
CPPFLAGS=-I/usr/local/clang8/include -I/opt/X11/include/freetype2


I suspect you don't want the second: if you have pkg-config it should 
find include paths for you.



FC=/usr/local/gfortran/bin/gfortran
FLIBS=-L/usr/local/gfortran/lib -lgfortran

As usual, the last challenge seems to be to get rgl installed.  Compilation 
_seems_ to go
smoothly, but I now see:


Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared object 
'/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so':
   
dlopen(/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so,
 6): Symbol not found: _FT_Attach_File
   Referenced from: 
/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so


Perhaps you should show the linking line.  A similar setup works for me:

configure: Darwin, so ensuring /opt/X11/bin is at the head of the PATH...
checking for pkg-config... yes
...

Do you have pkg-config (it is not a standard part of macOS, but is 
available on SU's site -- see the R-admin manual)?  You may need to set 
its path: for rgl I used


PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

(which should be the default) but for a few packages (Cairo gdtools rsvg)

PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

/usr/local/clang8/bin/clang++ -std=gnu++11 -dynamiclib 
-Wl,-headerpad_max_install_names -undefined dynamic_lookup 
-single_module -multiply_defined suppress -L/Users/ripley/R/R-devel/lib 
-L/usr/local/clang8/lib -L/usr/local/lib -o rgl.so ABCLineSet.o 
BBoxDeco.o Background.o ClipPlane.o Color.o Disposable.o Light.o 
LineSet.o LineStripSet.o Material.o NULLgui.o PlaneSet.o PointSet.o 
PrimitiveSet.o RenderContext.o Shape.o SphereMesh.o SphereSet.o 
SpriteSet.o String.o Surface.o TextSet.o Texture.o Viewpoint.o api.o 
assert.o callbacks.o device.o devicemanager.o fps.o ftgl.o geom.o 
gl2ps.o glErrors.o glgui.o gui.o init.o par3d.o pixmap.o platform.o 
pretty.o render.o rglmath.o rglview.o scene.o select.o subscene.o 
win32gui.o win32lib.o x11gui.o x11lib.o -lGLU -lGL -framework GLKit 
-framework OpenGL -dylib_file 
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 
-L/usr/local/lib -lpng16 -L/usr/X11/lib -lX11 -L/usr/local/lib 
-lfreetype -L/Users/ripley/R/R-devel/lib -lR -Wl,-framework 
-Wl,CoreFoundation


so that is statically linking libfreetype from /usr/local/lib and 
installed from 
https://mac.r-project.org/libs/freetype-2.5.5-darwin.13-x86_64.tar.gz . 
And that provides a freetype2.pc file, so


% pkg-config freetype2 --cflags
-I/usr/local/include/freetype2 -I/usr/local/include/libpng16
% pkg-config freetype2 --libs
-L/usr/local/lib -lfreetype




There is a comment somewhat after this about rgl requiring XQuartz, but I have  
XQuartz 2.7.11 so I don’t
think that this is the problem.  Apparently, there is still a freetype problem, 
however I’m out of my depth at this
point.   Any suggestions would be most welcome.

Roger Koenker
Honorary Professor
Department of Economics, UCL
London  WC1H 0AX.



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

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

Re: [Rd] Feature request: make file.exists interruptable

[Prof Brian Ripley]

The place for feature requests is bugs.r-project.org .

On 15/04/2019 18:44, Christopher Hammill wrote:

Hi R developers,

On slow file systems with large lists of files, file.exists can take a long 
time to run. It would be nice if users could interrupt this function. I think 
it would be simple to add:

https://svn.r-project.org/R/trunk/src/main/platform.c,

at line 1373, add "R_CheckUserInterrupt();" perhaps every some number of 
iterations if performance is a concern here.


It is a concern, and it is (very) unusual to call file.exists() on more 
than one file (as its name implies).  Perhaps you could give us some 
idea of what you are trying to do and how many files take how many 
seconds on what OS/filesystem.


For completeness, dir.exists() can be used with more than one path and 
potentially has the same issue.


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

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

Re: [Rd] Development version of R fails tests and is not installed

[Prof Brian Ripley]

On 05/03/2019 08:54, Berwin A Turlach wrote:

G'day all,

I have daily scripts running to install the patched version of the
current R version and the development version of R on my linux box
(Ubuntu 18.04.2 LTS).

The last development version that was successfully compiled and
installed was "R Under development (unstable) (2019-02-25 r76159)" on
26 February.  Since then the script always fails as a regression test
seems to fail.  Specifically, in the tests/ subdirectory of my build
directory I have a file reg-tests-1d.Rout.fail which ends with:


## checking ar.yw.default() multivariate case
estd <- ar(unclass(y) , aic = FALSE, order.max = 2) ## Estimate VAR(2)
es.d <- ar(unclass(y.), aic = FALSE, order.max = 2, na.action=na.pass)
stopifnot(exprs = {

+ all.equal(est$ar[1,,], diag(0.8, 2), tol = 0.08)# seen 0.0038
+ all.equal(est[1:6], es.[1:6], tol = 5e-3)
+ all.equal(estd$x.mean, es.d$x.mean, tol = 0.01) # seen 0.0023
+ all.equal(estd[c(1:3,5:6)],
+   es.d[c(1:3,5:6)], tol = 1e-3)## seen {1,3,8}e-4
+ all.equal(lapply(estd[1:6],unname),
+   lapply(est [1:6],unname), tol = 2e-12)# almost identical
+ all.equal(lapply(es.d[1:6],unname),
+   lapply(es. [1:6],unname), tol = 2e-12)
+ })
Error: lapply(es.d[1:6], unname) and lapply(es.[1:6], unname) are not equal:
   Component "aic": Mean relative difference: 3.297178e-12
Execution halted

Would it be possible to make this tolerance more lenient?  In case it
matters, I am configuring R to be compiled using Openblas and this test
fails for the 64 bit installation, the 32 bit installation seems to
pass all tests.

Happy to provide any more information/context that might be needed.


The version of OpenBLAS is always helpful (a couple of bugs were fixed 
recently that impacted the checks in R packages).


I have a x86_64 Linux build with OpenBLAS 0.3.5 that I use for the 
'Additional issues' in package checking, and that passes its checks (and 
has ca weekly for years, even with the buggy versions of OpenBLAS).


Some aspects of the RNG were changed in r76160: to isolate change that 
you can (with current R-devel) use


setenv _R_RNG_VERSION_ 3.5.0

and re-check.

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

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

Re: [Rd] svg ignores cex.axis in R3.5.1 on macOS

[Prof Brian Ripley]

On 06/09/2018 10:47, peter dalgaard wrote:

I think this needs to be taken off the bug repository and continued here. By 
now it seems pretty clear that this is not an R bug, but a local problem on 
Spencer's machine, likely connected to font configurations.


Or even on R-sig-Mac.


I poked around a bit on the three Macs that I can access, and found that 
fc-match does different things, including throwing warnings, hanging and even 
crashing my old MB Air...

One possible reason is that it can apparently be installed in multiple 
locations, for reasons lost in the mists of time:

Peters-iMac:BUILD-dist pd$ ls -l /opt/local/bin/fc-*
-rwxr-xr-x  1 root  wheel  44072 Apr  5  2014 /opt/local/bin/fc-cache
-rwxr-xr-x  1 root  wheel  43444 Apr  5  2014 /opt/local/bin/fc-cat
-rwxr-xr-x  1 root  wheel  34480 Apr  5  2014 /opt/local/bin/fc-list
-rwxr-xr-x  1 root  wheel  34928 Apr  5  2014 /opt/local/bin/fc-match
-rwxr-xr-x  1 root  wheel  34480 Apr  5  2014 /opt/local/bin/fc-pattern
-rwxr-xr-x  1 root  wheel  34008 Apr  5  2014 /opt/local/bin/fc-query
-rwxr-xr-x  1 root  wheel  34448 Apr  5  2014 /opt/local/bin/fc-scan
-rwxr-xr-x  1 root  wheel  38780 Apr  5  2014 /opt/local/bin/fc-validate
Peters-iMac:BUILD-dist pd$ ls -l /opt/X11/bin/fc-*
-rwxr-xr-x  1 root  wheel  58128 Oct 26  2016 /opt/X11/bin/fc-cache
-rwxr-xr-x  1 root  wheel  57600 Oct 26  2016 /opt/X11/bin/fc-cat
-rwxr-xr-x  1 root  wheel  48384 Oct 26  2016 /opt/X11/bin/fc-list
-rwxr-xr-x  1 root  wheel  48992 Oct 26  2016 /opt/X11/bin/fc-match
-rwxr-xr-x  1 root  wheel  44256 Oct 26  2016 /opt/X11/bin/fc-pattern
-rwxr-xr-x  1 root  wheel  44000 Oct 26  2016 /opt/X11/bin/fc-query
-rwxr-xr-x  1 root  wheel  44288 Oct 26  2016 /opt/X11/bin/fc-scan
-rwxr-xr-x  1 root  wheel  48608 Oct 26  2016 /opt/X11/bin/fc-validate
Peters-iMac:BUILD-dist pd$ ls -l /usr/local/bin/fc-*
-rwxr-xr-x@ 1 root  wheel  1463900 Oct 21  2008 /usr/local/bin/fc-cache
-rwxr-xr-x@ 1 root  wheel  1459780 Oct 21  2008 /usr/local/bin/fc-cat
-rwxr-xr-x@ 1 root  wheel  1455628 Oct 21  2008 /usr/local/bin/fc-list
-rwxr-xr-x@ 1 root  wheel  1476560 Oct 21  2008 /usr/local/bin/fc-match

Notice that these are all different, no links. I guess that the ones you want 
are in /opt/X11, presumably installed by XQuartz.


Yes, for the device compiled into the CRAN binary R package.  (Other 
builds may differ.)  On that, the cairo-based devices such as svg() are 
linked to (current versions on my machine)


/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.5)
	/opt/X11/lib/libcairo.2.dylib (compatibility version 11403.0.0, current 
version 11403.6.0)
	/opt/X11/lib/libpixman-1.0.dylib (compatibility version 35.0.0, current 
version 35.0.0)
	/opt/X11/lib/libfontconfig.1.dylib (compatibility version 11.0.0, 
current version 11.2.0)

...



So, going out on a limb, I have two ideas:

(A) Rebuild the font cache with

/opt/X11/bin/fc-cache -vf

(B) Check that XQuartz is up to date (possibly reinstall it, even if it is)


(B) is expected to do (A).  My advice was going to be to reinstall 
xquartz: macOS updates can partially break it.




-pd


On 5 Sep 2018, at 21:13 , MacQueen, Don via R-devel  
wrote:

Seems ok on my system. Axis label size changes when cex.axis does.

## tested in the middle of another long session, so many additional packages 
are attached, including some personal packages not available elsewhere


sessionInfo()

R version 3.5.1 (2018-07-02)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.6

Matrix products: default
BLAS: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK: 
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] C

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

other attached packages:
[1] survival_2.42-3 ROracle_1.3-1   DBI_1.0.0   bookdown_0.7knitr_1.20  
rmarkdown_1.10  wdr_3.2 taurus_3.2-4xlsx_0.6.1
[10] rmacq_1.3-8

loaded via a namespace (and not attached):
[1] Rcpp_0.12.17magrittr_1.5splines_3.5.1   lattice_0.20-35 highr_0.7   
stringr_1.3.1   tools_3.5.1 grid_3.5.1  xfun_0.3
[10] tinytex_0.6 htmltools_0.3.6 yaml_2.1.19 rprojroot_1.3-2 
digest_0.6.15   zip_1.0.0   Matrix_1.2-14   rJava_0.9-10xlsxjars_0.6.1
[19] evaluate_0.10.1 openxlsx_4.1.0  stringi_1.2.3   compiler_3.5.1  
backports_1.1.2

--
Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062
Lab cell 925-724-7509



On 8/31/18, 1:02 PM, "R-devel on behalf of Spencer Graves" 
 wrote:



On 2018-08-31 14:21, Spencer Graves wrote:

Plots produced using svg in R 3.5.1 under macOS 10.13.6 ignores
cex.axis=2.  Consider the following:



plot(1:2, cex.axis=2)
svg('svg_ignores_cex.axis.svg')
plot(1:2, cex.axis=2)
dev.off()
sessionInfo()

R version 3.5.1 (2018-07-02)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running und

Re: [Rd] "utils::file.edit" does not understand "editor" with additional arguments

[Prof Brian Ripley]

We do not have the 'at a minimum' information requested by the posting 
guide, and I cannot reproduce anything like this on a Unix-alike.  Both 
file.edit and edit.default call the same underlying C code, and that 
single-quotes the 'editor' argument to allow for spaces in its path/name 
so I would not expect this to work.


Two workarounds:

1) Set an alias in your shell (e.g. in .bashrc) for 'subl -n'.  This is 
something widely needed on macOS where many editors are invoked by 'open 
-a', and I also use it for 'emacsclient -n'.


2) Make use of the ability to specify editor as an R function, invoking 
the external program by system2() etc.



On 28/08/2018 20:07, Randy Lai wrote:

I am using Sublime Text as my editor. If I run `subl -n .Rprofile` in bash, a 
file would be opened in a new window.

Back in R, if I run this


file.edit(".Rprofile", editor="'subl -n'")

sh: 'subl -n': command not found
Warning message:
error in running command

However, the interesting bit happens when I run

edit(1:10, editor="'subl -n’")

It does open Sublime Text. It seems that `file.edit` and `edit` are behaving 
differently when “editor” has additional arguments.

Randy


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

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

Re: [Rd] longint

[Prof Brian Ripley]

On 16/08/2018 18:33, Hervé Pagès wrote:

On 08/16/2018 05:12 AM, Dirk Eddelbuettel wrote:


On 15 August 2018 at 20:32, Benjamin Tyner wrote:
| Thanks for the replies and for confirming my suspicion.
|
| Interestingly, src/include/S.h uses a trick:
|
|     #define longint int
|
| and so does the nlme package (within src/init.c).

As Bill Dunlap already told you, this is a) ancient and b) was 
concerned with

the int as 16 bit to 32 bit transition period. Ie a long time ago. Old C
programmers remember.

You should preferably not even use 'long int' on the other side but 
rely on
the fact that all compiler nowadays allow you to specify exactly what 
size is
used via int64_t (long), int32_t (int), ... and the unsigned cousins 


Well, not all compilers.  Those types were introduced in C99, but are 
optional in that standard and in C11 and C++11.  I have not checked 
C++1[47], but expect they are also optional there.  int_fast64_t is not 
optional in C99, so R uses that if int64_t is not supported.


[It is easy to overlook that they are optional in C99 and at one time R 
assumed them.]



(which R
does not have).  So please receive the value as a int64_t and then 
cast it to
an int32_t -- which corresponds to R's notion of an integer on every 
platform.


Only on Intel platforms int is 32 bits. Strictly speaking int is only
required to be >= 16 bits. Who knows what the size of an int is on
the Sunway TaihuLight for example ;-)


R's configure checks that int is 32 bit and will not compile without it 
(src/main/arithmetic.c) ... so int and int32_t are the same on all 
platforms where the latter is defined.


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

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

Re: [Rd] longint

[Brian Ripley]

> On 15 Aug 2018, at 12:48, Duncan Murdoch  wrote:
> 
>> On 15/08/2018 7:08 AM, Benjamin Tyner wrote:
>> Hi
>> In my R package, imagine I have a C function defined:
>> void myfunc(int *x) {
>>// some code
>> }
>> but when I call it, I pass it a pointer to a longint instead of a
>> pointer to an int. Could this practice potentially result in a segfault?
> 
> I don't think the passing would cause a segfault, but "some code" might be 
> expecting a positive number, and due to the type error you could pass in a 
> positive longint and have it interpreted as a negative int.

Are you thinking only of a little-endian system?  A 32-bit lookup of a pointer 
to a 64-bit area could read the wrong half and get a completely different value.

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

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

Re: [Rd] CRAN: Update protocol buffers on macOS? (for RProtoBuf)

[Prof Brian Ripley]

On 06/07/2018 04:32, Jonathon Love wrote:

Hi,

I notice that the CRAN binary for the macOS version of RProtoBuf is 
built against quite an old version of protocol buffers (from 2014, 
before v3 format support was added).


the windows version is (blessedly) kept up-to-date, but I'd like to 
float the suggestion that the macOS version get an update too.


If you mean the CRAN macOS binary package for RProtoBuf, why did you 
post here?  R-sig-Mac would have been more appropriate, but the CRAN 
policies tell you how to report issues/wishes for binary packages.  Only 
one person can help you with that, and it is most effective to contact 
him directly.


RProtoBuf does not compile on macOS against the current/latest version 
3.6.0 of protobuf (sic), and I have reported to the maintainer.  It did 
compile against 3.5.1, and you could compile from sources yourself.


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

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

Re: [Rd] Building R from source with the PGI compiler

[Prof Brian Ripley]

On 21/12/2017 01:03, Erin Hodgess wrote:

Hello

I would like to build R from source and use the PGI compiler, rather than
the GCC compiler.


On what platform?  AFAIK we have only ever had reports on Linux.


I saw the instructions for the Intel compiler in the R Installation Manual,
but I didn't see the PGI.  I tried a few times without instructions, but
without success.

Any suggestions would be most welcome.  Also, I hope this is the right
group for the question.


It is.  Earlier versions of the  manual did contain info on using the 
PG(I) Linux compilers but as we had no reports for a long time, the 
probably-stale info was removed.  It looks like the info was added in 
late 2005, so you could try grabbing R sources from, say, 2007.




Sincerely,
Erin



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

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

Re: [Rd] R CMD check warning about compiler warning flags

[Prof Brian Ripley]

On 20/12/2017 17:42, Winston Chang wrote:

On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
   https://github.com/wch/r-source/commit/2e80059


That is not the canonical R sources.  And your description seems wrong: 
there is now an _optional_ check controlled by an environment variable, 
primarily for CRAN checks.



I'm working on a package where these compiler warning flags are
present in a Makefile generated by a configure script -- that is, the
configure script detects whether the compiler supports these flags,
and if so, puts them in the Makefile. (The configure script is for a
third-party C library which is in a subdirectory of src/.)

Because the flags are added only if the system supports them, there
shouldn't be any worries about portability in practice.


Please read the explanation in the manual: there are serious concerns 
about such flags which have bitten CRAN users several times.


To take your example, you cannot know what -Werror does on all compilers 
(past, present or future) where it is supported (and -W flags do do 
different things on different compilers).  On current gcc it does


   -Werror
   Make all warnings into errors.

and so its effect depends on what other flags are used (people typically 
use -Wall, and most new versions of both gcc and clang add more warnings 
to -Wall -- I read this week exactly such a discussion about the 
interaction of -Werror with -Wtautological-constant-compare as part of 
-Wall in clang trunk).



Is there a way to get R CMD check to not raise warnings in cases like
this? I know I could modify the C library's configure.ac (which is
used to generate the configure script) but I'd prefer to leave the
library's code untouched if possible.
You don't need to (and most likely should not) use the C[XX]FLAGS it 
generates ... just use the flags which R passes to the package to use.




-Winston


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

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

Re: [Rd] javareconf issue

[Prof Brian Ripley]

On 27/10/2017 04:13, rosseji wrote:

Using a real name and a signature are regarded as polite here.


Hi,

Wasn't able to see a bug report on this issue yet... Hope I'm not doublng
up.


This is a problem on your system.  Also, macOS issues should be reported 
to R-sig-mac ... and you should give the 'at a minimum' information 
requested by the posting guide.



There seems to be little info around for what "R CMD javareconf" does but
it has some deprecation errors seemingly.


See R CMD javareconf --help , and the R-admin manual.



On running cmd in terminal:

Java interpreter : /usr/bin/java

Java version : 9

Java home path   : /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home

Java compiler: /usr/bin/javac

Java headers gen.: /usr/bin/javah

Java archive tool: /usr/bin/jar

System Java on macOS


Try updating your R (as suggested by the posting guide): javareconf did 
not detect Java 9 on macOS until the it was released recently.  You are 
trying to use an obsolete system installation of Java (not Oracle Java).


From the NEWS for R 3.4.2.patched (and R-devel)

• R CMD javareconf has been updated to recognize the use of a Java
  9 SDK on macOS.





*trying to compile and link a JNI program *

*detected JNI cpp flags:
-I/System/Library/Frameworks/JavaVM.framework/Headers*

*detected JNI linker flags : -framework JavaVM*

*clang -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG
-I/System/Library/Frameworks/JavaVM.framework/Headers  -I/usr/local/include
   -fPIC  -Wall -g -O2  -c conftest.c -o conftest.o*

*conftest.c:4:5: warning: 'JNI_CreateJavaVM' is deprecated
[-Wdeprecated-declarations]*

*JNI_CreateJavaVM(0, 0, 0);*

*^*

*/System/Library/Frameworks/JavaVM.framework/Headers/jni.h:1936:39: note:
'JNI_CreateJavaVM' has*

*  been explicitly marked deprecated here*

*_JNI_IMPORT_OR_EXPORT_ __attribute__((deprecated)) jint JNICALL*

*  ^*

*1 warning generated.*

*clang -dynamiclib -Wl,-headerpad_max_install_names -undefined
dynamic_lookup -single_module -multiply_defined suppress
-L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o
conftest.so conftest.o -framework JavaVM
-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
-Wl,CoreFoundation*



*JAVA_HOME:
/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home*

*Java library path: *

*JNI cpp flags: -I/System/Library/Frameworks/JavaVM.framework/Headers*

*JNI linker flags : -framework JavaVM*

*Updating Java configuration in /Library/Frameworks/R.framework/Resources*

*Done.*

[[alternative HTML version deleted]]

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




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

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

Re: [Rd] Incorrect Import by Data for CSV File

[Prof Brian Ripley]

On 25/09/2017 08:00, Dario Strbenac wrote:

Good day,

The data function can import a variety of file formats, one of them being C.S.V. 


That isn't its documented purpose.  It was the original way for packages 
to provide datasets as needed (before lazy data was added).


Problematically, all of the table columns are collapsed into a single 
data frame column. This occurs because "files ending .csv or .CSV are 
read using read.table(..., header = TRUE, sep = ";", as.is=FALSE)". I 
suggest that the semi-colon used as the column separator be changed to a 
comma.


We suggest you read the documentation ... the (non-English-locales) 
version with a semicolon separator is one of four documented formats, 
and the English-language one is not.  Even if it were desirable it would 
not be possible to make a backwards-incompatible change after almost 20 
years.


It really isn't clear why anyone would want to use anything other than 
the second option (.rda) for data() unless other manipulations are 
needed (e.g. to attach a package).  But that option was not part of the 
original implementation.


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

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

Re: [Rd] R and Visual Studio

[Brian Ripley]

> On 19 Sep 2017, at 11:53, lille stor  wrote:
> 
> Hi,
> 
> I am trying to build R using Visual Studio 2010 but without success. My 
> question is if it possible build R with this compiler anyway?

It has been done, in the distant past.  However, none of the attempts produced 
a build which could pass R's checks.
> 
> If not, could someone please tell how to link one's C code against both the 
> static and shared libraries of R for Windows (that comes from the official 
> website found here https://cran.r-project.org/mirrors.html)?

It is not too difficult to make and load a DLL with VS and even link to R 
internals using an import library.  Details are in the manual or linked from 
there (section 5.5).  (There is no static library for R on Windows.)

> 
> Thank you!
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] configure.ac

[Prof Brian Ripley]

On 01/08/2017 17:26, peter dalgaard wrote:

If you check developer.r-project.org, you'll find links to the scripts that we 
use for building releases and pre-releases of R. These are usually run on a 
Mac, but shouldn't require much change for Linux. In particular, notice this 
lead-in in the prerelease script:

rm -rf BUILD-dist
mkdir BUILD-dist
cd R
aclocal -I m4
autoconf
cd ../BUILD-dist
etc


Or there is configure --enable-maintainer-mode, after which 'make' 
remakes 'configure' if necessary.  (That is fairly often tested on 
Linux, and occasionally on macOS with the autoconf tools added.)




-pd


On 1 Aug 2017, at 17:29 , Ramón Fallon  wrote:

Hi,

Just a quick mail to mention that I cannot generate a new configure script
using autoconf or autoreconf. I had edited the configure.ac and thought ...
"oh, that's my fault", but then I tried it on R-patched and R-3.4.1 without
touching configure.ac and had the same problems.

The "building R packages" documentation seems to suggest that "autoconf"
should take care of it, but I must be missing something as I expect it to
be a common task.

I also tried explicit autohell (yes, I know) commands
1) autoreconf --force -v
completes but invoking configure (with no options) gives

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
loading site script './config.site'
loading build-specific script './config.site'
./configure: line 2982: syntax error near unexpected token `blas'
./configure: line 2982: `  withval=$with_blas; R_ARG_USE(blas)'

OK.. there's a recipe that oen can use, starting with:

libtoolize --force

but you get:

A sequence typical found out there, starting withlibtoolize: putting
auxiliary files in AC_CONFIG_AUX_DIR, `tools'.
libtoolize: linking file `tools/ltmain.sh'
libtoolize: You should add the contents of the following files to
`aclocal.m4':
libtoolize:   `/usr/share/aclocal/libtool.m4'
libtoolize:   `/usr/share/aclocal/ltoptions.m4'
libtoolize:   `/usr/share/aclocal/ltversion.m4'
libtoolize:   `/usr/share/aclocal/ltsugar.m4'
libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros
in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.


then:

aclocal
autoheader
automake --force-missing --add-missing

first two go OK, but the third gives

configure.ac: no proper invocation of
was found.
configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
automake: no `Makefile.am' found for any configure output

then the following runs OK
autoconf

but running configure gives the same BLAS error.

But I'm farily sure one shouldn't run to see what's wrong with BLAS,ratehr
it's just the configure options not being read properly. The
AM_INIT_AUTOMAKE
issue definitely seems important.

Is there anything I'm missing?

Cheers and thanks in advance!

[[alternative HTML version deleted]]

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





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

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

Re: [Rd] special latin1 do not print as glyphs in current devel on windows

[Prof Brian Ripley]

You seem confused about Latin-1: those characters are not in Latin-1. 
(MicroSoft code pages are a proprietary encoding, some code pages such 
as CP1252 being extensions to Latin-1.)


You have not given the 'at a minimum information' asked for in the 
posting guide so we have no way to reproduce this, and without showing 
us the output on your system, we have no idea what you saw.


[As a convenience to Windows users, R does in some cases assume that 
they are using Latin-1 encodings. If they use extensions to Latin-1 then 
there are no guarantees that code written for strict Latin-1 will work.]


On 01/08/2017 10:19, Daniel Possenriede wrote:

Upon further inspection, I think these are at least two problems.
First the issue with printing latin1/cp1252 characters in the "80" to "9F"
code range.

x <- c("€", "–", "‰")
Encoding(x)
print(x)

I assume that these are Unicode escapes!? (Given that Encoding(x) shows
"latin1" I'd rather expect latin1/cp1252 escapes here, but these would be 
e.g. "\x80", right? My locale is LC_COLLATE=German_Germany.1252 btw.)
Now I don't know why print tries to convert to Unicode, but if these indeed
are Unicode escapes, then there is something wrong with the conversion from
cp1252 to Unicode.
In general, most cp1252 char codes translate to Unicode like CP1252: "00"
-> Unicode "", "01" -> "0001", "02" -> "0002", etc. see
http://www.cp1252.com/.
The exception is the cp1252 "80" to "9F" code range. E.g. the Euro sign is
"80" in cp1252 but "20AC" in Unicode, endash "96" in cp1252, "2013" in
Unicode.
The same error seems to happen with

enc2utf8(x)

Now with iconv() the result is as expected.

iconv(x, to = "UTF-8")


The second problem IMO is that encoding markers get lost with the enc2*
functions


As you are changing encodings, you do not want to preserve encoding!


x_utf8 <- enc2utf8(x)
Encoding(x_utf8)
x_nat <- enc2native(x_utf8)
Encoding(x_nat)


In an actual Latin-1 locale on Linux

> x_utf8 <- c("éè", "\u20ac", "\u2013")
> Encoding(x_utf8)
[1] "latin1" "UTF-8"  "UTF-8"
> enc2native(x_utf8)
[1] "éè" "" ""
> Encoding(.Last.value)
[1] "latin1"  "unknown" "unknown"

as expected.


Again, this is not the case with iconv()

x_iutf8 <- iconv(x, to = "UTF-8")
Encoding(x_iutf8)
x_inat <- iconv(x_iutf8, from = "UTF-8")
Encoding(x_inat)


iconv is converting from/to the current locale's encoding, presumably 
CP1252, not from the marked encoding (as the help page states explicitly.)


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

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

Re: [Rd] Solaris SPARC testbed

[Prof Brian Ripley]

On 11/07/2017 16:48, Avraham Adler wrote:

I've looked at some package testing results and I'm not seeing Solaris
SPARC. Has that test-bed been deprecated for package testing?


Are you talking about CRAN's check results?

The Sparc hardware used for CRAN died during an unplanned power outage, 
and it seems unlikely it can be resurrected.


But questions about CRAN should be sent to CRAN, and you should give 
credit where it is due if you discuss such services in public fora.


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

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

Re: [Rd] LC_TIME not set correctly by Sys.setlocale() ?

[Prof Brian Ripley]

On 23/06/2017 15:35, Joris Meys wrote:

Related to the following question on Stackoverflow:
https://stackoverflow.com/questions/44723690/unexpected-behavior-of-sys-setlocale#44723690

It appears as if Sys.setlocale() does not update LC_TIME correctly for use
in date formatting. Although R reports that LC_TIME is changed to the new
setting after use of Sys.setlocale(), as.Date() still uses the old
settings. The only way to update this is by specifically using LC_TIME.

Is this a bug or am I overlooking something?


Try setting the LC_TIME category explicitly.  The mapping of day/month 
names used by strptime (not really as.Date, and not taken from LC_TIME) 
is then reset.


Since Windows does not have a usable strptime C function, a substitute 
is used and its handing of non-English names is not done through the 
OS's locale mechanism.



Example:


Sys.setlocale(locale = "French_Belgium")

[1]
"LC_COLLATE=French_Belgium.1252;LC_CTYPE=French_Belgium.1252;LC_MONETARY=French_Belgium.1252;LC_NUMERIC=C;LC_TIME=French_Belgium.1252"


date <- "Dec-11"



as.Date(date, format = "%b-%d")

[1] NA # expected


Sys.setlocale(locale = "English_United Kingdom")

[1] "LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
Kingdom.1252;LC_MONETARY=English_United
Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252"


as.Date(date, format = "%b-%d")

[1] NA # not expected, should be a correct date


Sys.setlocale("LC_TIME", "English_United Kingdom")

[1] "English_United Kingdom.1252"


as.Date(date, format = "%b-%d")

[1] "2017-12-11" # expected


Sys.setlocale(locale = "French_Belgium")

[1]
"LC_COLLATE=French_Belgium.1252;LC_CTYPE=French_Belgium.1252;LC_MONETARY=French_Belgium.1252;LC_NUMERIC=C;LC_TIME=French_Belgium.1252"


as.Date(date, format = "%b-%d")

[1] "2017-12-11" # not expected, should be NA


Sys.setlocale("LC_TIME", "French_Belgium")

[1] "French_Belgium.1252"


as.Date(date, format = "%b-%d")

[1] NA # expected


sessionInfo()

R version 3.4.0 (2017-04-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

Matrix products: default

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

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

other attached packages:
[1] shiny_1.0.3

loaded via a namespace (and not attached):
[1] compiler_3.4.0  R6_2.2.1htmltools_0.3.6 tools_3.4.0
Rcpp_0.12.10
[6] digest_0.6.12   xtable_1.8-2httpuv_1.3.3mime_0.5






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

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

Re: [Rd] v3.4.0-2 incompatible with gcc 7.1

[Prof Brian Ripley]

R is compatible with GCC 7.1 !  New compiler versions are tested, as 
well as those under development for the major compilers.  (A few 
packages still fail with GCC 7.1, but that was reported to their 
maintainers months ago.)


Just follow the instructions in the R-admin manual to install from sources.

OTOH, ' v3.4.0-2 ' is not an R version number, so I think you are 
referring to binary distributions on your Linux distro, which are not 
the responsibility of 'Rcore or Rdevel' (whatever they are).


On 23/06/2017 14:40, Chris Cole wrote:

I'm on Arch Linux kernel version 4.11.6-1 using gcc version 7.1.1:

gcc --version
gcc (GCC) 7.1.1 20170516

I have installed R through the arch package manager pacman and when I
attempt to initiate it, R crashes stating a missing dependency:

/usr/lib64/R/bin/exec/R: error while loading shared libraries:
libgfortran.so.3: cannot open shared object file: No such file or directory

I thought that maybe a symlink was improperly placed in the package so I
looked in /usr/lib to try to find the offending library.

ls -halt /usr/lib/libgfortran.so.*
lrwxrwxrwx 1 root root 20 May 16 03:01 /usr/lib/libgfortran.so.4 ->
libgfortran.so.4.0.0
-rwxr-xr-x 1 root root 7.1M May 16 03:01 /usr/lib/libgfortran.so.4.0.0

Simply symlinking libgfortran.so.4.0.0 to libgfortran.so.3 did not work,
and after some questioning on SO (
https://stackoverflow.com/questions/44658867/r-v3-4-0-2-unable-to-find-libgfortran-so-3-on-arch)
it seems that gfortran 7 has bumped the .so object to version 4.

It seems that a relatively straightforward workaround for the present would
be to install a legacy version of gcc alongside the current version.

I'm wondering if Rcore or Rdevel are moving towards being able to handle
the new compiler version any time soon, and if there are any other
workarounds than having two versions of the compiler.

Thanks.

Chris

[[alternative HTML version deleted]]

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




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

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

Re: [Rd] R history: Why 'L; in suffix character ‘L’ for integer constants?

[Prof Brian Ripley]

On 16/06/2017 20:37, Jim Hester wrote:

The relevant sections of the C standard are
http://c0x.coding-guidelines.com/5.2.4.2.1.html, which specifies that C


There is more than one C standard, but that is none of them.


ints are only guaranteed to be 16 bits, C long ints at least 32 bits in
size, as Peter mentioned. Also http://c0x.coding-guidelines.com/6.4.4.1.html
specifies l or L as the suffix for a long int constants.

However R does define integers as `int` in it's source code, so use of L is
not strictly correct if a compiler uses 16 bit int types. I guess this
ambiguity is why the `int32_t` typedef exists.


However, R checks that the compiler uses 32-bit ints in its build 
(configure and src/main/arithmetic.c) and documents that in R-admin . 
In any case, the C standard does not apply to the R language.


Also, int32_t

- postdates R (it was introduced in C99, a few OSes having it earlier)
- is optional in the C99 and C11 standards (§7.20.1.1 in C11).




On Fri, Jun 16, 2017 at 3:01 PM, William Dunlap via R-devel <
r-devel@r-project.org> wrote:


"Writing R Extensions" says "int":

R storage mode  C type  FORTRAN type
logical  int*  INTEGER
integer  int*  INTEGER
double  double*  DOUBLE PRECISION
complex  Rcomplex*  DOUBLE COMPLEX
character  char**  CHARACTER*255
raw  unsigned char*  none

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Fri, Jun 16, 2017 at 11:53 AM, peter dalgaard  wrote:


Wikipedia claims that C ints are still only guaranteed to be at least 16

bits, and longs are at least 32 bits. So no, R's integers are long.


-pd


On 16 Jun 2017, at 20:20 , William Dunlap via R-devel <

r-devel@r-project.org> wrote:


But R "integers" are C "ints", as opposed to S "integers", which are C
"long ints".  (I suppose R never had to run on ancient hardware with 16

bit

ints.)

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Fri, Jun 16, 2017 at 10:47 AM, Yihui Xie  wrote:


Yeah, that was what I heard from our instructor when I was a graduate
student: L stands for Long (integer).

Regards,
Yihui
--
https://yihui.name


On Fri, Jun 16, 2017 at 11:00 AM, Serguei Sokol <

so...@insa-toulouse.fr



wrote:

Le 16/06/2017 à 17:54, Henrik Bengtsson a écrit :


I'm just curious (no complaints), what was the reason for choosing

the

letter 'L' as a suffix for integer constants?  Does it stand for
something (literal?), is it because it visually stands out, ..., or

no

specific reason at all?


My guess is that it is inherited form C "long integer" type (contrary

to

"short integer" or simply "integer")
https://en.wikipedia.org/wiki/C_data_types


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


   [[alternative HTML version deleted]]

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


--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com











 [[alternative HTML version deleted]]

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



[[alternative HTML version deleted]]

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




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

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

Re: [Rd] Creating a private CRAN with webpages

[Prof Brian Ripley]

On 09/06/2017 07:44, Joshua Bradley wrote:

I'm not trying to create a mirror of the CRAN. I also do not want to create
a "subset" of CRAN packages. Sorry if my explanation was confusing. There
are internal proprietary R packages that I would like to host on a private
repo. I like the CRAN web pages that allow a user to browse the various
packages from a browser without having to first install them. I want to
duplicate the process that CRAN goes through when it generate the webpages.


But for a repository of your own packages, not CRAN's packages? 
Everyone who has replied so far seems to have assumed the latter 


The scripts CRAN uses to make its 'web' area are not public.  If you can 
formulate a crystal-clear message, you could ask them for a copy.




Josh Bradley

[[alternative HTML version deleted]]


Please do follow the posting guide: CRAN too does not appreciate HTML mail.

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

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

Re: [Rd] [R] Somewhat obscure bug in R 3.4.0 building from source

[Prof Brian Ripley]

On 22/05/2017 18:16, Peter Carbonetto wrote:

Hi Peter, Duncan & Bert,

Thank you kindly for the responses.

Indeed, doc/NEWS.pdf is included in the source distribution, and then
removed upon "make clean".

I thought that it might be useful to report this for your benefit, but on
closer inspection it appears that I'm getting errors that arise due to
incompatibilities in my texlive and texinfo installations. This is the
error I get when trying to build NEWS.pdf using "R CMD Rd2pdf":

R CMD Rd2pdf --output=NEWS.pdf NEWS.Rd
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
   Running 'texi2dvi' on 'Rd2.tex' failed.
Messages:
/software/texinfo-6.3-el7-x86_64/bin/texi2dvi: TeX neither supports
-recorder nor outputs \openout lines in its log file
Output:

I'm not sure what to make of this error exactly but perhaps it is
introduced by the latest version of texinfo (which seems to be a recurring
issue based on reading the help for texi2dvi in R):

texi2dvi --version
texi2dvi (GNU Texinfo 6.3) 7353


Please do not speculate (see the posting guide and FAQ).

That version is thoroughly tested.  texinfo troubles were mainly in the 
transition to Perl ca 5.[012], and its slow adoption by distros: another 
holdback has been the transition to GPL-3-only licensing, AFAIR at 6.0.





Peter

On Sun, May 21, 2017 at 5:07 PM, Peter Dalgaard  wrote:


Inline below...


On 21 May 2017, at 20:57 , Duncan Murdoch 

wrote:


On 21/05/2017 10:30 AM, Peter Carbonetto wrote:

Hi,

I uncovered a bug in installing R 3.4.0 from source in Linux, following

the

standard procedure (configure; make; make install). Is this an

appropriate

place to report this bug? If not, can you please direct me to the
appropriate place?


Generally R-devel is better; I've responded there.



The error occurs only when I do "make clean" followed by "make" again;

make

works the first time.

The error is a failure to build NEWS.pdf:

Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet =

quiet,  :

  pdflatex is not available
Calls:  -> texi2pdf -> texi2dvi
Execution halted
make[1]: *** [NEWS.pdf] Error 1
make: [docs] Error 2 (ignored)

and can be reproduced wit the following sequence:

./configure
make
make clean
make


We usually don't build in the source directory; see the second

recommendation in the admin manual section 2.1.  So it's possible there's a
bug triggered when you do that.  Can you try building in a separate
directory?

Notice that the error is that "pdflatex" is missing from your setup. We
do, for the benefit of users with defective TeX installations supply a
pre-built NEWS.pdf (and NEWS.html too) in the source tarballs. However,
they are technically make targets and make clean will wipe them; in that
case, you had better have the tools to rebuild them!

-pd



Duncan Murdoch



This suggests to me that perhaps "make clean" is not working.

I'm happy to provide more details so that you are able to reproduce the

bug.


Thanks,

Peter Carbonetto, Ph.D.
Computational Staff Scientist, Statistics & Genetics
Research Computing Center
University of Chicago

  [[alternative HTML version deleted]]

__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/

posting-guide.html

and provide commented, minimal, self-contained, reproducible code.



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


--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com












[[alternative HTML version deleted]]

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




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

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

Re: [Rd] tempdir() may be deleted during long-running R session

[Prof Brian Ripley]

From the R-admin manual §5:

'Various environment variables can be set to determine where R creates 
its per-session temporary directory. The environment variables TMPDIR, 
TMP and TEMP are searched in turn and the first one which is set and 
points to a writable area is used. If none do, the final default is /tmp 
on Unix-alikes and the value of R_USER on Windows. The path should be an 
absolute path not containing spaces (and it is best to avoid 
non-alphanumeric characters such as +).


Some Unix-alike systems are set up to remove files and directories 
periodically from /tmp, for example by a cron job running tmpwatch. Set 
TMPDIR to another directory before starting long-running jobs on such a 
system.'



On 21/04/2017 11:49, Mikko Korpela wrote:

Temporary files not accessed for a long time are automatically removed
in some Linux distributions and probably other operating systems too,
depending on system configuration. This may affect the per-session
temporary directory, the path of which is returned by tempdir(). I think


Not for those who follow the manual and know that sysadmnins have 
enabled such a script.



it would be nice if R automatically tried to recreate a missing
tempdir() but this could have some performance implications.

I ran the same test (below) on R 3.3.3 patched, R 3.4.0 beta, and
R-devel, all at r72499 (2017-04-09) and compiled by myself. The results
from the test were practically identical on all of those versions, the
test platform being Ubuntu 14.04.5 LTS. This system is configured for a
/tmp cleanup threshold of 7 days of inactivity (which is the default).
After a wait of roughly 10 days, the R temporary directory had been
deleted by an automatic cleanup procedure, and a call to `?` failed.
This StackExchange question has some answers about the Ubuntu /tmp
cleanup practice: https://askubuntu.com/q/20783

a <- print(tempdir())
# [1] "/tmp/user/1069138/RtmpGc9M5z"
dir.exists(a) # TRUE
# [1] TRUE
Sys.time()
# [1] "2017-04-10 16:00:30 EEST"
## Wait for one week (Ubuntu 14.04.5 LTS)
print(Sys.time()); ?regex
# [1] "2017-04-20 14:17:29 EEST"
# Error in file(out, "wt") : cannot open the connection
# In addition: Warning message:
# In file(out, "wt") :
#   cannot open file '/tmp/user/1069138/RtmpGc9M5z/Rtxt3dbb65870ad4': No
such file or directory
b <- print(tempdir())
# [1] "/tmp/user/1069138/RtmpGc9M5z"
identical(a, b)
# [1] TRUE
dir.exists(b)
# [1] FALSE




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

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

Re: [Rd] Intel MKL compiling issue

[Prof Brian Ripley]

There is nothing here indicating any kind of error, so no way to give 
any insights 


And please do follow the posting guide, including not posting HTML.

FWIW, I have tested R 3.4.0 RC (sic) with MKL 11.3, which is later than 
your 2013 ... (on x86_64 Fedora 24).



On 20/04/2017 10:39, jing hua zhao wrote:

Dear R-developers,


I would appreciate any insights over compiling R 3.4 with Intel MKL -- I have 
been successful until R 3.3.3 but now it stops complaining about pcre though it 
worked without Intel MKL as follows,


./configure LDFLAGS=-L/genetics/data/software/lib CFLAGS=-fPIC 
-I/genetics/data/software/include --enable-R-shlib


I have used,


export MKL_NUM_THREADS=15
export MKLROOT=/genetics/data/software/intel/composer_xe_2013.4.183/mkl
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MKLROOT/lib/intel64
/genetics/data/software/intel/composer_xe_2013.4.183/mkl/bin/mklvars.sh intel64
CPPFLAGS="-I/genetics/data/software/include -L/genetics/data/software/lib" \
./configure --prefix=/genetics/data/software --enable-R-shlib 
--enable-threads=posix --with-lapack \
 --with-blas="-fopenmp -m64 -I$MKLROOT/include -L$MKLROOT/lib/intel64 -lmkl_gf_lp64 
-lmkl_gnu_thread -lmkl_core -lpthread -lm"


Many thanks,



Jing Hua

[[alternative HTML version deleted]]

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




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

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

Re: [Rd] Q: Windows/readline: missing history search

[Prof Brian Ripley]

Your error is in your subject line: getline rather than readline is used 
on Windows.  (readline was not written for Windows and depends on a 
'curses' library not available for Windows terminals let alone RGui.  A 
considerable amount of time was spent trying to use it, unsuccessfully.)



On 13/04/2017 07:23, Ulrich Windl wrote:

Hello!

Ever since I used R on Windows (RGui) I am missing the ability to search the 
command history (Cntrl+R (reverse-search-history) in BASH, for example). Is 
there a particular reason for having this function disabled? Another feature 
would be word-wise delete (kill-word, backward-kill-word).

Probably being able to use the Alt-key as Meta key for readline (instead of 
activating menu entries) would be helpful. At least of the console window has 
the input focus.


That's the Windows way.  And users of e.g. Emacs on macOS know how this 
can cause awkward conflicts.



Another nice feature would be PuTTY-like copying of selected text: It's 
sufficient to mark text in the console to have it put into the clipboard. In 
Rgui I need an explicit copy.


That's the Windows way: PuTTY is using an older Unix/X11 standard (not 
so much used on Unix nowadays).



Finally I'd like if Rgui would remember the state of the MDI main window 
(maximized or not, maybe position and size also): Currently it always starts 
maximized.


AFAIR that is part of the configuration you can save.


Regards,
Ulrich




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

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

Re: [Rd] mean(x) != mean(rev(x)) different with x <- c(NA, NaN) for some builds

[Prof Brian Ripley]

From ?NA

 Numerical computations using ‘NA’ will normally result in ‘NA’: a
 possible exception is where ‘NaN’ is also involved, in which case
 either might result.

and ?NaN

 Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’:
 which of those two is not guaranteed and may depend on the R
 platform (since compilers may re-order computations).

fortunes::fortune(14) applies (yet again).

On 01/04/2017 04:50, Henrik Bengtsson wrote:

In R 3.3.3, I observe the following on Ubuntu 16.04 (when building
from source as well as for the sudo apt r-base build):


x <- c(NA, NaN)
mean(x)

[1] NA

mean(rev(x))

[1] NaN


rowMeans(matrix(x, nrow = 1, ncol = 2))

[1] NA

rowMeans(matrix(rev(x), nrow = 1, ncol = 2))

[1] NaN


.rowMeans(x, m = 1, n = 2)

[1] NA

.rowMeans(rev(x), m = 1, n = 2)

[1] NaN


.rowSums(x, m = 1, n = 2)

[1] NA

.rowSums(rev(x), m = 1, n = 2)

[1] NaN


rowSums(matrix(x, nrow = 1, ncol = 2))

[1] NA

rowSums(matrix(rev(x), nrow = 1, ncol = 2))

[1] NaN

I'd expect NA to trump NaN in all cases (with na.rm = FALSE).  sum()
does not have this problem and returns NA in both cases (*).

For the same R version build from source on RHEL 6.6 system
(completely different architecture), I get the expected result (= NA)
for all of the above cases, e.g.


x <- c(NA, NaN)
mean(x)

[1] NA

mean(rev(x))

[1] NA
[...]

Before going insane trying to troubleshoot this, I have a vague memory
that this, or something related to this, has been discussed
previously, but I cannot locate it.

Is the above a bug in R, a FAQ, a build error, overzealous compiler
optimization, and / or ...?

Thanks,

Henrik



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

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

Re: [Rd] Error "Warning in read_symbols_from_dll(so, rarch): this requires 'objdump.exe' to be on the PATH

[Prof Brian Ripley]

On 21/03/2017 17:12, Uwe Ligges wrote:



On 19.03.2017 23:50, Christophe Genolini wrote:

Hi all,

I try to compile my package kml and I get the message


[That will not be 'compiling': it may be from R CMD check, e.g. from 
wuth --as-cran in R-devel.]



Warning in read_symbols_from_dll(so,rarch):
this requires 'objdump.exe' to be on the PATH

I check 'Writing R Extensions' but I did not find any reference to this
error. Does someone know how to fix that?


Yes: Put objdump.exe on the PATH, that executable is part of gcc and in
its bin directoy.


Not quite: it is part of GNU Bintools, hence bundled with gcc in Rtools. 
 So is 'nm', which may appear in a similar message (and on Windows 
means 'nm.exe').


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

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

Re: [Rd] Incompatible change in R-devel

[Prof Brian Ripley]

On 21/03/2017 16:38, Dirk Eddelbuettel wrote:


Hi Brian,

On 21 March 2017 at 07:29, Prof Brian Ripley wrote:
| As of today's commit r72375 all packages with native-routine
| registration of C or Fortran routines need to be reinstalled in R-devel
| (and that include some of the recommended packages in R itself which
| will not be reinstalled via make dependencies, so we advise a clean
| rebuild of R).

I am confused by this.

So in order to test this, I just triggered rebuild of the smaller drd ("daily
r-devel") and r-devel Docker images for R.

Using drd, I used R 3.3.3 to install digest and anytime (also installing Rcpp
and BH). I then launch the R-devel build freshly created, and reported as

 root@b00daf469882:/# RD --version
 R Under development (unstable) (2017-03-21 r72380) -- "Unsuffered Consequences"

yet both digest and anytime loaded fine by R-devel. Despite the fact that
they were installed by R 3.3.3.


None register C/Fortran routines for .C or .Fortran.

My belief is that packages which register more than one .C or more than 
one .Fortran native routine are affected, but that may not be exhaustive 
(and might depend on the compiler).



As I understand your email, that should not have worked.  So I must be
missing something -- can you help set me straight?


All packages should load ... the issue is finding (all of the) 
registered symbols.  Here's an example of what can go wrong, x86_64 Linux;


> library(mgcv, lib = "/usr/local/lib64/R/library") # R 3.3.3
Loading required package: nlme
This is mgcv 1.8-17. For overview type 'help("mgcv-package")'.
> mgcv:::in.out
...
um <- .C(C_in_out, bx = as.double(bnd[, 1]), by = as.double(bnd[,
...
> mgcv:::C_in_out
Error in get(name, envir = asNamespace(pkg), inherits = FALSE) :
  object 'C_in_out' not found

(the last message being found in testing a package which called mgcv).

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

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

[Rd] Incompatible change in R-devel

[Prof Brian Ripley]

As of today's commit r72375 all packages with native-routine 
registration of C or Fortran routines need to be reinstalled in R-devel 
(and that include some of the recommended packages in R itself which 
will not be reinstalled via make dependencies, so we advise a clean 
rebuild of R).


We try to avoid such things, but now is a least bad time (before binary 
packages for pre-3.4.0 are built in earnest, although CRAN Windows ones 
have been available for a while and will be rebuilt now).


Packages aster2 used undocumented/defunct fields and is overdue for 
update: AFIAWK all other CRAN/BioC packages can be reinstalled.


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

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

Re: [Rd] Test suite failures in R-devel_2017-02-25_r72256

[Prof Brian Ripley]

On 27/02/2017 09:30, Peter Simons wrote:

Hi,

I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux
distribution [1], but the build fails during the "make check" phase
because of the following 2 issues:


Hmm, R-devel (your subject line) is not a pre-release of R 3.3.3: it is 
'R Under development' for what is planned as R 3.4.0.  Pre-release 
tarballs for 3.3.3 are things like R-rc_2017-02-26_r72260.tar.gz (and 
were previously labelled R-beta).


Your first point only occurs in R-devel, and was something already 
reported and under investigation.  Note that test does not actually 
depend on network access: it depends on having an accessible CRAN 
mirror.  The latter could be local (and is on the CRAN check farm, for 
example).  So we have been working on a more sophisticated condition to 
run that test.


There are lots of possible check environments: it is very time-consuming 
to check them all and reasonable coverage is only attempted once a 
pre-release reaches 'alpha' status -- 3.4.0 has not done so but is 
planned to be in late March.


I have just re-checked on Linux, and R 3.3.3 RC passed its checks 
without Internet access (which is checked for where needed).


I also re-checked 3.3.3 RC without recommended packages and got the 
expected messages about incomplete testing but no failures except in 
'make check-recommended' (expected!).


Our posting guide does ask you to include the output of sessionInfo(): 
that would have avoided the version confusion (and might even have 
alerted you to it).




1) The "tools" test in "tests/Examples" requires network access, which
   it doesn't have in our build environment. Therefore, it fails as
   follows according to "tools-Ex.Rout.fail":

   | [...]
   | > set.seed(11)
   | > ## End(Don't show)
   | > pdb <- CRAN_package_db()
   | Warning in url(sprintf("%s/%s", cran, path), open = "rb") :
   |   URL 'http://CRAN.R-project.org/web/packages/packages.rds': status was 
'Couldn't resolve host name'
   | Error in url(sprintf("%s/%s", cran, path), open = "rb") :
   |   cannot open the connection to 
'http://CRAN.R-project.org/web/packages/packages.rds'
   | Calls: CRAN_package_db -> as.data.frame -> read_CRAN_object -> gzcon -> url
   | Execution halted

   I'm wondering whether it would be possible to extend the test suite
   with a configure-time flag that disable tests which depend on network
   access? My experience is that most modern Linux distributions run
   their builds in a restricted environment and therefore will run into
   trouble if the suite assumes that it can access the Internet.

2) When R is compiled with the --without-recommended-packages flag
   (which is our preferred configuration), the "base" test in
   "tests/Examples" fails, apparently because it depends on MASS. I'm
   citing from "base-Ex.Rout.fail":

   | >  ## The string "foo" and the symbol 'foo' can be used interchangably 
here:
   | >  stopifnot( identical(isNamespaceLoaded(  "foo"   ), FALSE),
   | + identical(isNamespaceLoaded(quote(foo)), FALSE),
   | + identical(isNamespaceLoaded(quote(stats)), statL))
   | >
   | > hasM <- isNamespaceLoaded("MASS") # (to restore if needed)
   | > Mns <- asNamespace("MASS") # loads it if not already
   | Error in loadNamespace(name) : there is no package called 'MASS'
   | Calls: asNamespace ... tryCatch -> tryCatchList -> tryCatchOne -> 

   | Execution halted

I hope this helps!

Best regards,
Peter



[1] http://nixos.org/

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




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

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

Re: [Rd] Registration of native routines

[Prof Brian Ripley]

On 14/02/2017 16:25, Prof Brian Ripley wrote:

Registration of 'native routines' (entry points in compiled code loaded
into R) has been available for over 14 years,


...


(There are reports that the check in 'R CMD check' on Windows sometimes
fails to detect use of registration.  This is being looked into:
meanwhile say so in a CRAN submission if it happens to you.)


One instance has been resolved: for at least 5 years R CMD check for a 
package with compiled code has assumed commands 'nm' and (on Windows) 
'objdump' were on the PATH: these are also needed to detect use of 
registration.  There is now a warning if they are not found.


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

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

Re: [Rd] Registration of native routines

[Prof Brian Ripley]

On 14/02/2017 17:28, Avraham Adler wrote:

On Tue, Feb 14, 2017 at 11:25 AM, Prof Brian Ripley
 wrote:

Registration of 'native routines' (entry points in compiled code loaded into
R) has been available for over 14 years, but few packages make use of it
(less than 10% of those on CRAN with compiled code).

Registration has similar benefits to name spaces in R code:

- it ensures that the routines used by .C, .Call etc are those in your
package (without needing a PACKAGE argument).

- it avoids polluting the search space for native routines with those from
your package.

- it checks the number of arguments passed to .Call/.External, and the
number and optionally the type for .C/.Fortran.

- it finds native routines faster, especially if 10s of name spaces are
loaded.

Kurt Hornik and I have written a tool to make adding registration much
easier.  From NEWS in R-devel

• Package tools has a new function
  package_native_routine_registration_skeleton() to assist adding
  native-routine registration to a package.  See its help and §5.4.1
  of ‘Writing R Extensions’ for how to use it.  (At the time it was
  added it successfully automated adding registration to over 90%
  of CRAN packages which lacked it.  Many of the failures were
  newly-detected bugs in the packages, e.g. 50 packages called
  entry points with varying numbers of arguments and 65 packages
  called entry points not in the package.)


Hello, Dr., Ripley.

This is fantastic. Is there a way to install this functionality into
an existing 3.3.2 installation, or is it exclusive to
R-deve;/R-3.4-to-be?


You need to run the tool in R-devel to get the skeleton for your 
package.  Everything else will work in any recent version of R.




Thank you,

Avi




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

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

[Rd] Registration of native routines

[Prof Brian Ripley]

Registration of 'native routines' (entry points in compiled code loaded 
into R) has been available for over 14 years, but few packages make use 
of it (less than 10% of those on CRAN with compiled code).


Registration has similar benefits to name spaces in R code:

- it ensures that the routines used by .C, .Call etc are those in your 
package (without needing a PACKAGE argument).


- it avoids polluting the search space for native routines with those 
from your package.


- it checks the number of arguments passed to .Call/.External, and the 
number and optionally the type for .C/.Fortran.


- it finds native routines faster, especially if 10s of name spaces are 
loaded.


Kurt Hornik and I have written a tool to make adding registration much 
easier.  From NEWS in R-devel


• Package tools has a new function
  package_native_routine_registration_skeleton() to assist adding
  native-routine registration to a package.  See its help and §5.4.1
  of ‘Writing R Extensions’ for how to use it.  (At the time it was
  added it successfully automated adding registration to over 90%
  of CRAN packages which lacked it.  Many of the failures were
  newly-detected bugs in the packages, e.g. 50 packages called
  entry points with varying numbers of arguments and 65 packages
  called entry points not in the package.)

Of the 2450 CRAN packages with compiled code but not registration, this 
tool successfully[*] converts all but 220 out-of-the-box.  Another 25 
packages already use R_init_pkgname and so need the registration info to 
be merged.


Most of the rest fail because of errors in the package but some try to 
do tricky things computing names of routines, and this is noted in the 
skeleton output.


A few of you are using the older mechanism of specifying entry points in 
a useDynLib call in the NAMESPACE file. This shares the first and fourth 
benefits (but registration is faster), but not the second and third.


$5.4 of the 'Writing R Extensions' manual has been re-written with a 
worked example of adding registration.


Shortly, R CMD check --as-cran will note if registration is not fully 
used.  Expect to be asked to add registration: as increasingly large 
numbers of packages are used, avoiding polluting the search space is 
becoming important.


(There are reports that the check in 'R CMD check' on Windows sometimes 
fails to detect use of registration.  This is being looked into: 
meanwhile say so in a CRAN submission if it happens to you.)



[*] R CMD check output is unchanged.

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

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

Re: [Rd] Grapics Device Resolution Limits

[Prof Brian Ripley]

On 10/02/2017 19:27, Prof Brian Ripley wrote:

Note that there are at least 5 separate png() devices, so Linux was not
using the (default) device used on Windows.

In general, the device-limits info is not on the help page because we do
not know it.  On Windows the default device limits depend on the OS
version, 32/64-bit, RAM and the graphics hardware.  This sounds like the
last: you were asking for 49 megapixels which is far larger than the
largest screens.  (Or all but the highest-end digital cameras, so one
could well ask what you can usefully do with such an image.)


Scratch that: res is in ppi so the image should be 2755px square: still 
rather large.



Normally you will get warning(s) accompanying that Error, but it might
just be

Warning: unable to allocate bitmap
Warning: opening device failed

The first of those is reporting what the GraphApp toolkit said, talking
directly to Windows GDI (and look at the Windows documentation for e.g.
CreateCompatibleBitmap to see that no limits are mentioned).


Even on Windows you have the option of using other png() devices:

png(filename = "Rplot03d.png",
width = 480, height = 480, units = "px", pointsize = 12,
bg = "white", res = NA, family = "", restoreConsole = TRUE,
type = c("windows", "cairo", "cairo-png"), antialias)

Try the other 2 types: the cairo devices do not use your graphics
hardware nor MicroSoft's GDI. (The other 2 devices are Xlib on a
Unix-alike and Quartz on macOS.)


On 10/02/2017 16:54, Martin Maechler wrote:

Dario Strbenac 
on Fri, 10 Feb 2017 02:00:08 + writes:


> Good day,
> Could the documentation of graphics devices give some
explanation of how big the bitmap limits are? For example,

>> png("Figure1A.png", h = 7, w = 7, res = 1000, units = "cm")

> Results in Error: unable to start png() device,

This is amazing to me.  I see

--


png("Figure1A.png", h = 7, w = 7, res = 1000, units = "cm")
plot(1)
dev.off()

null device
  1

file.info("Figure1A.png")[1:5]

  size isdir mode   mtime   ctime
Figure1A.png 41272 FALSE  644 2017-02-10 17:40:42 2017-02-10 17:40:42



--


in three different versions of R I've tried (all were 64-bit Linux).
Note how *small* the file is.
Now, I've also tried a 32-bit version of Linux (Ubuntu 14.04 LTS) and get
a similar result (not exactly the same number of bytes for the file
size).



but the help page of devices doesn't explain that there are any
limits or how they are determined. The wording of the error message
could also be improved, to explain that the resolution is too high or
the dimensions are too large.


If one/some of those who can reproduce the problem in their
versions of R  provide (concise and not hard to read) patches to
the source of R, we'd probably gratefully accept them..

Martin Maechler

>> sessionInfo()
> R version 3.3.2 Patched (2017-02-07 r72138)
> Platform: i386-w64-mingw32/i386 (32-bit)
> Running under: Windows 7 (build 7601) Service Pack 1

> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia





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

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

Re: [Rd] Grapics Device Resolution Limits

[Prof Brian Ripley]

Note that there are at least 5 separate png() devices, so Linux was not 
using the (default) device used on Windows.


In general, the device-limits info is not on the help page because we do 
not know it.  On Windows the default device limits depend on the OS 
version, 32/64-bit, RAM and the graphics hardware.  This sounds like the 
last: you were asking for 49 megapixels which is far larger than the 
largest screens.  (Or all but the highest-end digital cameras, so one 
could well ask what you can usefully do with such an image.)


Normally you will get warning(s) accompanying that Error, but it might 
just be


Warning: unable to allocate bitmap
Warning: opening device failed

The first of those is reporting what the GraphApp toolkit said, talking 
directly to Windows GDI (and look at the Windows documentation for e.g. 
CreateCompatibleBitmap to see that no limits are mentioned).



Even on Windows you have the option of using other png() devices:

png(filename = "Rplot03d.png",
width = 480, height = 480, units = "px", pointsize = 12,
bg = "white", res = NA, family = "", restoreConsole = TRUE,
type = c("windows", "cairo", "cairo-png"), antialias)

Try the other 2 types: the cairo devices do not use your graphics 
hardware nor MicroSoft's GDI. (The other 2 devices are Xlib on a 
Unix-alike and Quartz on macOS.)



On 10/02/2017 16:54, Martin Maechler wrote:

Dario Strbenac 
on Fri, 10 Feb 2017 02:00:08 + writes:


> Good day,
> Could the documentation of graphics devices give some explanation of how 
big the bitmap limits are? For example,

>> png("Figure1A.png", h = 7, w = 7, res = 1000, units = "cm")

> Results in Error: unable to start png() device,

This is amazing to me.  I see

--

png("Figure1A.png", h = 7, w = 7, res = 1000, units = "cm")
plot(1)
dev.off()

null device
  1

file.info("Figure1A.png")[1:5]

  size isdir mode   mtime   ctime
Figure1A.png 41272 FALSE  644 2017-02-10 17:40:42 2017-02-10 17:40:42



--

in three different versions of R I've tried (all were 64-bit Linux).
Note how *small* the file is.
Now, I've also tried a 32-bit version of Linux (Ubuntu 14.04 LTS) and get
a similar result (not exactly the same number of bytes for the file size).



but the help page of devices doesn't explain that there are any limits or how 
they are determined. The wording of the error message could also be improved, 
to explain that the resolution is too high or the dimensions are too large.


If one/some of those who can reproduce the problem in their
versions of R  provide (concise and not hard to read) patches to
the source of R, we'd probably gratefully accept them..

Martin Maechler

>> sessionInfo()
> R version 3.3.2 Patched (2017-02-07 r72138)
> Platform: i386-w64-mingw32/i386 (32-bit)
> Running under: Windows 7 (build 7601) Service Pack 1

> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia


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

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

Re: [Rd] changes in src/unix/system.c break builds on FreeBSD

[Prof Brian Ripley]

On 09/02/2017 11:44, Rainer Hurling wrote:

Dear R devs,

For some days now (~ February, 4th), I am not able to build the recent
tarballs of R-devel on a FreeBSD test box anymore. The breakage seems to
be related to the newest overhaul of src/unix/system.c:


[..snip..]
gcc49 -std=gnu99 -I. -I../../src/include -I../../src/include
-I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include -isystem
/usr/local/include -DHAVE_CONFIG_H  -fopenmp -fpic  -O2 -pipe
-DLIBICONV_PLUG -fstack-protector -Wl,-rpath=/usr/local/lib/gcc49
-isystem /usr/local/include -fno-strict-aliasing -c system.c -o system.o
system.c: In function 'Rf_initialize_R':
system.c:213:13: error: 'RLIM_SAVED_CUR' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
 ^
system.c:213:13: note: each undeclared identifier is reported only once
for each function it appears in
system.c:213:38: error: 'RLIM_SAVED_MAX' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
  ^
system.c: In function 'R_GetFDLimit':
system.c:509:13: error: 'RLIM_SAVED_CUR' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
 ^
system.c:509:38: error: 'RLIM_SAVED_MAX' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
  ^
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/math/R-devel/work/R-devel/src/unix


Perhaps someone can give me a hint, want to do next?


Let us know (which you have).  This appears to be a lack of POSIX 
compliance on FreeBSD (even POSIX 2004, the current link being 
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getrlimit.html), 
so was unexpected and you ought to file a FreeBSD bug report.


I'll add a workaround in R-devel in r72147: let us know if that does not 
suffice.




Please let me know, if I should provide more information or can test
something.

Many thanks in advance,
Rainer Hurling

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




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

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

Re: [Rd] Subject: Milestone: 10000 packages on CRAN

[Prof Brian Ripley]

On 28/01/2017 02:52, Henrik Bengtsson wrote:

Continuing the tradition to post millennia milestones on CRAN:

So, it happened. Today (January 27, 2017 PCT) CRAN reached 10,000 packages [1].


I predicted (rather tongue-in-check) at UseR! 2011 that we would have 
this 'for Christmas 2016', at a time when there were 3200 CRAN packages. 
 My expectation was to be much farther off 


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

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

Re: [Rd] Definition of uintptr_t in Rinterface.h

[Prof Brian Ripley]

On 29/12/2016 15:55, Simon Urbanek wrote:

The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with 
HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now 
fixed in R-devel - please check if that works for you.


Rconfig.h would be appropriate if Rinterface.h is being included from C 
code using the same compiler as used for R.  But as Rinterface.h is 
intended for use by alternative front ends there is no guarantee that 
they use the same compiler (and some use C++).


This was documented in the manual:

'Note that uintptr_t is a C99 type for which a substitute is defined in 
R, so your code needs to define HAVE_UINTPTR_T appropriately.'


AFAICS if you comply, there will not be a conflict.

Also note that is only an issue if CSTACK_DEFNS is defined, not the 
default and not mentioned here.





Thanks,
Simon




On Dec 26, 2016, at 11:25 PM, Laurent Gautier  wrote:

Hi,

I was recently pointed out that a definition in Rinterface.h can be conflicting
with a definition in stdint.h:

/usr/include/R/Rinterface.h has:
typedef unsigned long uintptr_t;

/usr/include/stdint.h has:
typedef unsigned int uintptr_t;
(when 32bit platform complete definition is:

#if __WORDSIZE == 64
# ifndef __intptr_t_defined
typedef long intintptr_t;
#  define __intptr_t_defined
# endif
typedef unsigned long int   uintptr_t;
#else
# ifndef __intptr_t_defined
typedef int intptr_t;
#  define __intptr_t_defined
# endif
typedef unsigned intuintptr_t;
#endif

)

Is this expected ? Shouldn't R rely on the definition in stdint.h


But there need not be one in stdint.h, as the type is optional in 
C99/C11/C++11 and likely not present in C++98.



rather than define its own ?


(report for the issue:
https://bitbucket.org/rpy2/rpy2/issues/389/failed-to-compile-with-python-360-on-32
)


Laurent




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

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

Re: [Rd] syntax difference clusterExport in parallel and snow

[Prof Brian Ripley]

On 13/12/2016 17:05, Paul Johnson wrote:

We got some errors and eventually figured out that
parallel::clusterExport second argument is "varlist" while in
snow::clusterExport it is "list".

The user had loaded parallel first, but did something else which
inadvertently loaded snow, then clusterExport failed because we had
"varlist" and not "list".

Are these different on purpose?


Yes.

('list' is an unhelpful name for an argument that is not a list.)


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

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

Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

[Prof Brian Ripley]

Please note that you need to report your platforms (as per the posting 
guide), as the C function starts


#ifdef HAVE_COSPI
#elif defined HAVE___COSPI
double cospi(double x) {
return __cospi(x);
}

And AFAICS the system versions on Solaris and OS X behave the same way 
as R's substitute.




On 01/12/2016 09:12, Martin Maechler wrote:

Martin Maechler 
on Thu, 1 Dec 2016 09:36:10 +0100 writes:



Ei-ji Nakama 
on Thu, 1 Dec 2016 14:39:55 +0900 writes:


>> Hi,
>> i try sin, cos, and tan.

>>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
>> [1] 0.5444181 0.8388140 1.5407532

>> However, *pi results the following

>>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
>> [1] 1 0 0

>> Please try whether the following becomes all right.

> [..]

> Yes, it does  -- the fix will be in all future versions of R.

oops not so quickly, Martin!

Of course, the results then coincide,  by sheer implementation.

*BUT* it is not at all clear which of the two results is better;
e.g., if you replace '1.23' by '1' in the above examples, the
result of the unchnaged  *pi() functions is 100% accurate,
whereas

 R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi))
 [1] -0.8847035 -0.4661541  0.5269043

is "garbage".  After all,  1e45 is an even integer and so, the
(2pi)-periodic functions should give the same as for 0  which
*is*  (1, 0, 0).

For such very large arguments, the results of all of sin() ,
cos() and tan()  are in some sense "random garbage" by
necessity:
Such large numbers have zero information about the resolution modulo
[0, 2pi)  or (-pi, pi]  and hence any (non-trivial) periodic
function with such a "small" period can only return "random noise".


> Thank you very much Ei-ji Nakama, for this valuable contribution
> to make R better!

That is still true!  It raises the issue to all of us and will
improve the documentation at least!

At the moment, I'm not sure where we should go.
Of course, I could start experiments using my own 'Rmpfr'
package where I can (with increasing computational effort!) get
correct values (for increasingly larger arguments) but at the
moment, I don't see how this would help.

Martin



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

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

Re: [Rd] [parallel-package] feature request: set default cluster type via environment variable

[Prof Brian Ripley]

On 24/11/2016 07:30, Christian Krause wrote:

Dear all,

I’m working as an administrator of a High-Performance Computing (HPC) Cluster 
which runs on Linux. A lot of people are using R on this Linux cluster and, of 
course, the *parallel* package to speed up their computations.

It has been our collective experience, that using |makeForkCluster| yields an 
overall better experience /on Linux/ than the |makePSOCKcluster|, for whatever 
definition of better. Let me just summarize that it works smoother. I believe, 
other people working with *parallel* on Linux can share this experience


Usually, but not always.  And the differences are mainly in 
initialization time, so small once workers are given a reasonable amount 
of work (tens of seconds each).  However, as forked workers have a copy 
of the whole master process, forking workers can lead to excessive 
memory usage.



Also, we did really welcome the environment variable |MC_CORES|, to be able to 
specify (in job submit scripts) the amount of CPU cores a user has been 
granted, most importantly for /dynamic resource requests/ (see below for an 
example).


Hmm, MC_CORES is primarily for mclapply() and friends, not 
makeCluster().  makeForkCluster() is a 'friend' so uses it, but 
makePSOCKcluster() was designed for distributing across a cluster of 
machines (whereas makeForkCluster is restricted to a single multicore 
machine).



What we would also appreciate - and now we finally get to the feature request - 
is another environment variable to choose the used cluster, as in:

|export MC_CLUSTER_TYPE=FORK |

Do you think something like this could be implemented in future releases?


No.  (Not least as 'MC_' refers to the former 'multicore' package.)

PSOCK and Fork clusters are not interchangeable, and the author of the 
code has to check if Fork can be substituted for PSOCK (which starts 
with a clean R environment, and that may well be assumed).


So rather, you need to ask your users to implement this in their calls 
to parallel::makeCluster.







  Parallel R job submit script

This works with the Univa Grid Engine and should work with other * Grid Engine 
products:

|#!/bin/bash # request a "parallel environment" with 2 to 20 cores #$ -pe smp 
2-20 # set number of cores for the R cluster to the granted value (between 2 and 20) 
export MC_CORES=$NSLOTS # we want this: export MC_CLUSTER_TYPE=FORK Rscript 
/path/to/script.R |

Best Regards

​




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

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

Re: [Rd] grep

[Prof Brian Ripley]

On 02/10/2016 17:54, Pi wrote:

Hello.

It would be great if the grep function in R had the option to use the -m
parameter as the linux command does.


I guess you mean the non-standard flag of the GNU version of grep 
(probably but not necessarily as used by Linux).


That the POSIX standard for grep does not have this (nor any other 
commonly used implementation I am aware of) indicates that your 
enthusiasm for this is not shared by grep experts.



That would allow to stop a grep search as soon as something is found.
It would make many operations much faster.


Those who would have to do the work to implement this will not be taking 
your word for that, but would expect convincing examples of real 
problems where it was so and grep was the bottleneck.


Your 'case' seems to be for a shortcut for any(grepl()) along the lines 
of anyDuplicated().



[[alternative HTML version deleted]]


This is a non-HTML list, as the posting guide told you.  And using a 
real name adds credibility.


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

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

Re: [Rd] library() asks user to accept license of some built-in packages

[Prof Brian Ripley]

On 27/09/2016 10:49, Mikko Korpela wrote:

When 'getOption("checkPackageLicense")' is 'TRUE' and the user calls
'library(grid)' for the first time, R asks the user to either accept or
decline the package license. This should not be necessary as the package
license is "Part of R ..." with "..." denoting the R version number, and
R is free and open source.

The unnecessary license question is asked for the built-in packages
"compiler", "grid" and "parallel".

The source file where the checks happen is
"src/library/base/R/library.R". I think one solution could be to add
something like

if(identical(pkgInfo$DESCRIPTION[["Priority"]], "base")) return()

to the beginning of checkLicense(), or add more packages to the
hard-coded exemption list checked before calling checkLicense().


Rather, the analysis code has been told about the current licence for 
standard packages.



Also, in find.package(), the shortcut list of standard packages is
missing "compiler".


Which was intentional when the code was written (it is just a shortcut) 
but as 'compiler' is getting used more, it has been added.



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

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

Re: [Rd] R without graphics

[Prof Brian Ripley]

On 24/05/2016 00:54, Simon Urbanek wrote:

Um... any reason why you don't simply disable aqua? That file is only compiled 
if you enable aqua - it has really nothing to do with grDevices ...


Also, you can specify a compiler for Objective-C separately and the 
manual advises you to do so (to specify Apple's clang).



On May 23, 2016, at 7:44 PM, Mick Jordan  wrote:


Is it possible to configure and build an R without any graphics support. I..e 
no grDevices or graphics packages?

I tried "--with-x=no  --with-cairo=no --with-grDevices=no --with-graphics=no"


Inventing flags does not help you: use configure --help to see what is 
supported (as the manual says).


Reading the manual is faster than posting (and posting Mac-specific Qs 
to R-sig-mac is more likely to get an informed response).



but it is still building grDevices.

My problem is that I am using experimenting with a compiler that cannot compile 
the Objective-C file, qdCocoa.m, and I don't need graphics for this experiment.

Max OS X El Capitan, R-3.2.4.

Thanks
Mick Jordan



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

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

Re: [Rd] Submitting an updated package version to CRAN (Warning: non-ASCII characters)

[Prof Brian Ripley]

On 21/05/2016 21:25, Luck Buttered wrote:

Dear all:

I am updating the version of an R package I submitted last year on CRAN and
came across two questions that I would be grateful to seek any input about:

1) In the updated version of the package, I am adding a second example
dataset. This example dataset is a subset of a public database that
contains thousands of names. Upon running devtools::check(), I am only
getting one warning. ("Warning: found non-ASCII strings").

It seems this warning is coming from special characters in some of the
names. As it is ideal that the names should not be altered, I did not know
what approach to take. Should I simply include a note in my CRAN submission
indicating that the non-ASCII characters are meaningfully inherent to the
example data? Or, should I convert the names to ASCII characters (if that
is easily possible for so many cases), and indicate to users that names
have been altered (special characters removed)?


You should follow the advice of the manual: 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Encoding-issues 
.  There is not enough detail here to know what you currently do (let 
alone what you should do), but that message indicates that the encoding 
of non-ASCII stings (what you call 'special characters') has not been 
declared (and to be portable they should be in UTF-8).



2) I have never submitted an updated version of a package to CRAN. I am
considering following a similar process to what I did to submit my original
version of the package to CRAN. That is, using devtools::release() and
including a note in a file called cran-comments.md to indicate that this is
not an original version submission, but rather, an updated version
submission. I found these advice on Hadley Wickhams site (
http://r-pkgs.had.co.nz/release.html), but could not determine if this was
appropriate for version update submissions as well.


There is a list for discussing package preparation, r-package-devel.


Thank you for sharing any advice!




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

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

Re: [Rd] Max OSX 3.3.0 and lzma

[Prof Brian Ripley]

On 05/05/2016 19:40, Mick Jordan wrote:

I have lzma installed (in /usr/local) but R-3.3.0 configure doesn't like
something about it:

checking for lzma_version_number in -llzma... yes
checking lzma.h usability... no
checking lzma.h presence... no
checking for lzma.h... no
configure: error: "liblzma library and headers are required"

bash-3.2$ ls /usr/local/lib/*lzma*
ls /usr/local/lib/*lzma*
/usr/local/lib/liblzma.5.dylib/usr/local/lib/liblzma.a
/usr/local/lib/liblzma.dylib
bash-3.2$ ls /usr/local/include/*lzma*
ls /usr/local/include/*lzma*
/usr/local/include/lzma.h

/usr/local/include/lzma:
base.hblock.hcontainer.hfilter.hindex.h
lzma12.hversion.h
bcj.hcheck.hdelta.hhardware.h index_hash.h
stream_flags.hvli.h

I'm no configure wizard so would appreciate a hint.


Look at config.log.

And please follow the posting guide and give at least the OS, preferably 
full details of your setup.  It looks like this is OS X (so this is not 
the right list and did you get liblzma from r.reseach.att.com?), and 
I've just scrubbed an explanation I wrote about an Oracle OS called 
Solaris 




Thanks
Mick Jordan

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



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

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

Re: [Rd] R process killed when allocating too large matrix (Mac OS X)

[Prof Brian Ripley]

On 05/05/2016 10:11, Uwe Ligges wrote:



On 05.05.2016 04:25, Marius Hofert wrote:

Hi Simon,

... all interesting (but quite a bit above my head). I only read
'Linux' and want to throw in that this problem does not appear on
Linux (it seems). I talked about this with Martin Maechler and he
reported that the same example (on one of his machines; with NA_real_
instead of '0's in the matrix) gave:

  Error: cannot allocate vector of size 70.8 Gb
Timing stopped at: 144.79 41.619 202.019

... but no killer around...


Well, with n=1. ;-)

Actually this also happens under Linux and I had my R processes killed
more than once (and much worse also other processes so that we had to
reboot a server, essentially). That's why we use job scheduling on
servers for R nowadays ...


Yes, Linux does not deal safely with running out of memory, although it 
is better than it was.  In my experience, only commercial Unices do that 
gracefully.


Have you tried setting a (virtual) memory limit on the process using the 
shell it is launched from?  I have found that to be effective on most 
OSes, at least in protecting other processes from being killed. 
However, some things do reserve excessive amounts of VM that they do not 
use and so cannot be run under a sensible limit.


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

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

Re: [Rd] Is it possible to increase MAX_NUM_DLLS in future R releases?

[Prof Brian Ripley]

On 04/05/2016 08:44, Martin Maechler wrote:

Qin Zhu 
 on Mon, 2 May 2016 16:19:44 -0400 writes:


 > Hi,
 > I’m working on a Shiny app for statistical analysis. I ran into this "maximal 
number of DLLs reached" issue recently because my app requires importing many other 
packages.

 > I’ve posted my question on stackoverflow 
(http://stackoverflow.com/questions/36974206/r-maximal-number-of-dlls-reached 
).

 > I’m just wondering is there any reason to set the maximal number of DLLs 
to be 100, and is there any plan to increase it/not hardcoding it in the future? 
It seems many people are also running into this problem. I know I can work around 
this problem by modifying the source, but since my package is going to be used by 
other people, I don’t think this is a feasible solution.

 > Any suggestions would be appreciated. Thanks!
 > Qin

Increasing that number is of course "possible"... but it also
costs a bit (adding to the fixed memory footprint of R).


And not only that.  At the time this was done (and it was once 50) the 
main cost was searching DLLs for symbols.  That is still an issue, and 
few packages exclude their DLL from symbol search so if symbols have to 
searched for a lot of DLLs will be searched.  (Registering all the 
symbols needed in a package avoids a search, and nowadays by default 
searches from a namespace are restricted to that namespace.)


See 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Registering-native-routines 
for some further details about the search mechanism.



I did not set that limit, but I'm pretty sure it was also meant
as reminder for the useR to "clean up" a bit in her / his R
session, i.e., not load package namespaces unnecessarily. I
cannot yet imagine that you need > 100 packages | namespaces
loaded in your R session. OTOH, some packages nowadays have a
host of dependencies, so I agree that this at least may happen
accidentally more frequently than in the past.


I am not convinced that it is needed.  The OP says he imports many 
packages, and I doubt that more than a few are required at any one time. 
 Good practice is to load namespaces as required, using requireNamespace.



The real solution of course would be a code improvement that
starts with a relatively small number of "DLLinfo" structures
(say 32), and then allocates more batches (of size say 32) if
needed.


The problem of course is that such code will rarely be exercised, and 
people have made errors on the boundaries (here multiples of 32) many 
times in the past.  (Note too that DLLs can be removed as well as added, 
another point of coding errors.)



Patches to the R sources (development trunk in subversion at
https://svn.r-project.org/R/trunk/ ) are very welcome!

Martin Maechler
ETH Zurich  &  R Core Team




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

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

Re: [Rd] R-exts update for new *check* argument in R 3.3.0

[Prof Brian Ripley]

On 19/04/2016 23:53, Jan Górecki wrote:

Hello dear dev team,

In the recent devel R-exts manual I cannot find any information about new
option `--ignore-vignettes` to `R CMD check`. I would expect it to be
mentioned somewhere in "1.4.2 Non-Sweave vignettes".


Which is a subsection of §1.4 'Writing package vignettes', so your 
expectations are misplaced: it is nothing to do with *writing*.



Checked on https://cran.r-project.org/doc/manuals/r-devel/R-exts.html and
https://github.com/wch/r-source/blob/trunk/doc/manual/R-exts.texi


Where does it say that all the possible arguments to 'check' are 
documented in the manual?  It says otherwise in §1.3.1:


'Use R CMD check --help to obtain more information about the usage of 
the R package checker.  A subset of the checking steps can be selected 
by adding command-line options.'


R CMD check --help includes

  --ignore-vignettesskip all tests on vignettes

[This is really intended for those doing automated checking, not end users.]

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

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

Re: [Rd] Building R-patched and R-devel fails

[Prof Brian Ripley]

On 17/04/2016 07:25, Berwin A Turlach wrote:

G'day all,

probably you have noticed this by now, but I thought I ought to report
it. :)


Already fixed for Unix by the time this reached me.  Since that version 
of Survival has been put into 3.2 patched, that also needed its 
Makefile.in updated.


I've left Windows changes to those with a Windows build system.



My scripts that update the SVN sources for R-patched and R-devel, run
`tools/rsync-recommended' (for both) and then install both these
versions from scratch failed this morning.  Apparently the new version
of the recommended package `survival' depends on the recommended
package `Matrix', but the makefile does not ensure that Matrix is build
before survival.  So my log files had entries:

   [...]
   ERROR: dependency ‘Matrix’ is not available for package ‘survival’
   * removing ‘/opt/src/R-devel-build/library/survival’
   Makefile:51: recipe for target 'survival.ts' failed
   make[2]: *** [survival.ts] Error 1
   make[2]: *** Waiting for unfinished jobs
   [...]

Presumably, in both branches, the files Makefile.in and Makefile.win in
src/library/Recommended have to be adapted to contain the following
line at the end among the "Hardcoded dependencies":

survival.ts: Matrix.ts

Cheers,

Berwin

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




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

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

[Rd] Avoid texinfo 6.1

[Prof Brian Ripley]

There are problems with the texi2dvi in the recently released texinfo 
6.1.  (The bug has been reported.)  Avoid 6.1 if you can, but if not 
setting the environment variable


R_TEXI2DVICMD=emulation

will enable R to build, including NEWS.pdf and all the vignettes.

We are working on a more complete workaround for R-devel and 3.2.4.

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

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

Re: [Rd] R Package Installation Ignores libPaths Setting

[Prof Brian Ripley]

You misunderstand what .libPaths does: it changes the path in the 
current session only.  Installation uses a different R process.


Set R_LIBS to change the library path for new sessions: see ?.libPath .


On 18/02/2016 07:00, Dario Strbenac wrote:

Good day,

If the library path is changed with .libPaths, the command

install.packages("/nb/dario/Biostrings_2.39.9.tar.gz", repos=NULL)

fails with

** testing if installed package can be loaded
Error : package ‘S4Vectors’ required by ‘Biostrings’ could not be found

However,

running library(S4Vectors) followed by sessionInfo() after the error shows that 
the package can indeed be found by R

R version 3.2.3 Patched (2016-02-14 r70170)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)
 ......
other attached packages:
[1] S4Vectors_0.9.34BiocGenerics_0.17.3

The new library path is being ignored when the package is attempted to be 
loaded at the end of the installation process. How can the installation be 
successful ?

--
Dario Strbenac
PhD Student
University of Sydney
Camperdown NSW 2050
Australia



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

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

Re: [Rd] R-devel no longer supports Ubuntu 14.04 LTS (insufficient PCRE version)

[Prof Brian Ripley]

I think you have it backwards: Ubuntu 14.04 does not support R-devel 

PCRE 8.32 is 3 years old, so Ubuntu 14.04 shipped an already quite old 
version 19 months ago.


R has long said that its requirement was

   PCRE (version 8.10 or later, preferably 8.32 or later)

and 8.32 is indeed preferable: the aim is that all the current PCRE 
regex syntax be usable on all platforms.


Given that you appear to be installing R from the sources, PCRE is no 
more difficult to install from source 


R-devel is 'under development' and months off release: if this proves to 
be too restrictive we can postpone the aim to 3.4.x.



On 20/11/2015 15:14, Sebastian Meyer wrote:

Since yesterday's r69662, R no longer ./configure[s] on a standard
Ubuntu 14.04.3 installation, which ships with PCRE 8.31
(http://packages.ubuntu.com/trusty-updates/libpcre3-dev)

I get:


checking if PCRE version >= 8.32, < 10.0 and has UTF-8 support... no
checking whether PCRE support suffices... configure: error: pcre library and 
headers are required


Are there any workarounds for this except for manually compiling and
installing a more recent version of PCRE from source?

Thanks!

Sebastian





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK

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

Re: [Rd] Outdated information in regex.Rd

[Brian Ripley]

On 19 Nov 2015, at 10:05, Martin Maechler  wrote:

>> Mikko Korpela 
>>on Wed, 18 Nov 2015 11:35:14 +0200 writes:
> 
>> The NEWS for R-devel has the following item:
>>> The previously included versions of zlib, bzip2, xz and PCRE have
>>> been removed, so suitable external (usually system) versions are
>>> required (see the ‘R Installation and Administration’ manual).
> 
>> Therefore I believe the following information in
>> 'src/library/base/man/regex.Rd' is no longer valid:
> 
>>> If PCRE support was compiled from the sources within R, the PCRE
>>> version is 8.36 as described here.
> 
> Not quite.  It is still *valid* : every statement about the
> elements of the empty set are true, in the same sense that
> 
>   if (FALSE)
> "something or other"
> 
> is never invalid, but of course, that information should still
> be removed because indeed, it is empty.

Help pages are not intended to be just about the current version of R but also 
recent versions, and most builds of 3.2.x will meet the condition.

However, as from 3.2.0 a user can find the version of PCRE in use by 
extSoftVersion, and I have added a comment about that, including for 3.2.3.

> 
> Thank you Mikko!
>(and excuse the completely unnecessary pickyness ;-)
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Package integrity check via SHA256 or OpenPGP possible?

[Brian Ripley]

> On 15 Oct 2015, at 08:11, Philip Gillißen  wrote:
> 
> Dear list,
> 
> I'm using R in a corporate environment and was interested how R checks 
> integrity of packages during an installation.
> I saw (and verified my suspicion in the code[1]) that the verification purely 
> relies on MD5.
>> From an IT security perspective, this can be improved.

Maybe, but 'IT security' was not the point.  MD5 sums were added first as a way 
to check for corrupted downloads/unpacking (which used to be common on 
Windows), and second to reinforce the version number of a package as sometimes 
the source package is altered without changing the version, and less rarely 
binary packages are re-built.


> 
> My question is: Is is possible to force R to verify integrity via SHA256 or 
> even OpenPGP signatures?
> If not are there any plans to support better hashes than MD5?
> As the source code looks, an extension to support other (optional) hash 
> values would be quite easy.
> 
> Thanks in advance!
> 
> Kind regards,
> Philip
> 
> [1] see from line 594 on in src/library/tools/R/install.R in R-latest.tar.gz
> 
> 
> 
> 
> 
> 
> ---
> Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! 
> http://email.freenet.de/basic/Informationen
> 
> 
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Building R for AIX in 64-bit mode

[Prof Brian Ripley]

On 15/10/2015 13:32, Michael Felt wrote:

Hi.

Just wanted to let you know I am getting close to packaging R for AIX in
64.bit mode.


Which version? (You mentioned 3.1.3 and 3.2.2 far below.)  There is 
little value in reporting on frozen branches, and most value in 
reporting on R-devel where all the current changes have been incorporated.



One comment - the libtool.m4 I see used is quite old. The one I have on my
system is 2.4.6, and what I see in R says:


R-devel has 2.4.6 .


I am hoping a new libtool will clean up most of the manual work now needed.


But libtool is hardly used in building R.


# Which release of libtool.m4 was used?
macro_version=2.2.6
macro_revision=1.3012

This may be all that is needed to cleanup what I am doing manually.

working with gcc I have done the following for 64-bit building

export OBJECT_MODE=64
export CFLAGS="-maix64 -O2"
export FFLAGS="-maix64 -O2"


See the manual: flags such as -maix64 should be part of CC, not CFLAGS. 
 That explains a lot of what was reported.
Specifically, 
https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Essential-programs-and-libraries 
and https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#AIX .


It is safer to put such things on the configure command line or in a 
config.site file (they will be found when updating if you do).


[Lots of test output removed.]

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK

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

Re: [Rd] gcc ubsan alignement test --minimal gcc version?

[Prof Brian Ripley]

On 13/10/2015 14:46, kaveh wrote:

   Dear All,

   I'm trying to implement the section of the manual pertaining to the
gcc-ubsan test
   carried by CRAN on my local computer (ubuntu 14.04):

   http://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/README.txt

   I was wondering whether someone could tell what the minimal version
of the gcc tool chain needed to run the gcc-ASAN and gcc-UBSAN
alignment
   tests on ones local computer is. CRAN seems to use gcc 5.2.0 to do
these tests,
but the current version of gcc shipped with ubuntu is 4.9.2 (to be
updated to
5.1.0 with the 15.10 release latter this month).

  I hope this is the correct list to post this.


The correct thing to do is to read the manual (either the R manual or 
your gcc manual).  The R manual says


'AddressSanitizer (‘ASan’) is a tool with similar aims to the memory 
checker in valgrind. It is available with suitable builds of gcc 4.8.0 
or clang 3.1 and later on common Linux and OS X platforms.'


'‘UBSanitizer’ is a tool for C/C++ source code selected by 
-fsanitize=undefined in suitable builds of clang, and GCC as from 4.9.0.'


Note that including these capabilities and their runtimes is optional at 
least for clang (until recently Apple omitted them), so you need to 
check your own system's documentation.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK

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