Re: [Rd] Default R-3.4.0 RC CXXFLAGS without -O2 on x86_64-linux-gnu with g++-5.4.0 causes WARNING from stl_list.h

[Martyn Plummer]

This is fixed in R-rc_2017-04-19_r72555.tar.gz

If you are affected by this issue then please test the RC tarball. This
is the last chance to detect problems (including those created by the
last-minute patch) before the release of R 3.4.0.

Martyn

On Wed, 2017-04-19 at 12:19 +, Neumann, Steffen wrote:
> Hi r-devel,
> 
> a recent install of R-3.4.0 RC (2017-04-13 r72510) 
> on Linux (Ubuntu 16.04.1 LTS) x86_64-linux-gnu 
> with g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> (see http://bioconductor.org/checkResults/devel/bioc-LATEST/malbec2-N
> odeInfo.html for more) 
> results in CXXFLAGS not containing "-O2" as optimisation flag,
> there is only "   -Wall", while CFLAGS are happy with "-g -O2
> -Wall"
> 
> This has an influence in at least one place
> https://stat.ethz.ch/pipermail/bioc-devel/2017-April/010733.html
> where we have WARNINGS in R CMD check from "Found ‘abort’, 
> possibly from ‘abort’ (C)" in packages xcms/mzR.
> The abort() call is not coming from XCMS, but rather 
> from the C++ code in the STL:
> 
>   [...]
>   # 1770 "/usr/include/c++/5/bits/stl_list.h"
>   void _M_check_equal_allocators(list& __x) {
>    if (_M_get_Node_allocator())
>      __builtin_abort();
>   }
> 
> If we compile with -O2 optimisation, this getting rid of 
> the abort() symbol, as shown 
> in https://github.com/sneumann/xcms/issues/150#issuecomment-293545521
> 
> Martin Morgan created a minimum example that shows that 
> the symbol is indeed deep down in the STL (see below and in:
> https://stat.ethz.ch/pipermail/bioc-devel/2017-April/010837.html )
> 
> This raises several questions:
> 
> 1) is there any way to avoid the WARNING / abort() inside 
>    the STL list implementation ? Or just live with it ?
> 
> 2) If not, is there a reason why the Bioconductor build farm 
>    Ubuntu machine is not using -O2 as default CXXFLAG ?
>    BioC admins are trying to have a vanilla R installation with
> defaults. 
>    According to Herve Pages, CXXFLAGS without -O2 is default 
>    since R-3.4 beta, but I don't know enough about the package 
>    build logic to point to a particular R commit. 
> 
> 3) I thought about cheating the system and add -O2 
>    in the package CXXFLAGS, but Martin Morgan 
>    recommends packages shouldn't mess and override system build
> defaults
>    to mask and paper over the actual issue having a nasty abort() 
>    lurking somewhere.
>    But I couldn't add PKG_CXXFLAGS=-O2 in first place, since that 
>    triggers the different WARNING that -O2 is not portable. 
> 
> => Any help and input would be highly appreciated. 
> 
> Thanks in advance, 
> yours,
> Steffen
> 
> 
> tmp.cpp by Martin Morgan (also in above linked mail thread)
> ---
> #include 
> 
> int foo(int argc, const char *argv[]) {
>  std::list l1, l2;
>  std::list::iterator it;
> 
>  it = l1.begin();
>  l1.splice (it, l2); // mylist1: 1 10 20 30 2 3 4
> 
>  return 0;
> }
> ---
> 
> Test with
> 
>    rm -f tmp.o && R CMD SHLIB tmp.cpp && nm tmp.o | grep abort
> 
> with compiler settings in ~/.R/Makevars with/without -O2 
> -
> CXXFLAGS = -g -O0
> -
> 
> 
> 
> 
> 
> --
> IPB HalleAG Massenspektrometrie &
> Bioinformatik
> Dr. Steffen Neumann  http://www.IPB-Halle.DE
> Weinberg 3                   Tel. +49 (0) 345 5582 - 1470
> 06120 Halle                       +49 (0) 345 5582 - 0           
> sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409
> 
> __
> 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] ask.yes.no() function

[Michael Sumner]

Perhaps worth pointing out "yesno" as a candidate:


https://CRAN.R-project.org/package=yesno


Cheers, Mike



On Wed, 19 Apr 2017 at 21:55 Duncan Murdoch 
wrote:

As described in
, R base
functions are currently inconsistent in asking interactive "yes/no" type
questions. One solution to this is to have a function to do it, and to
use it consistently.




Rather than just writing such a function and possibly missing some
desirable feature, I'd like to ask if anyone can point to an existing
one that is perfect (or nearly perfect, and point out what changes would
be desirable)?

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

[[alternative HTML version deleted]]

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

Re: [Rd] R 3.4 has broken C++11 support

[Angerer, Philipp via R-devel]

indeed. Makeconf isn’t in the right spot, so the correct vars aren’t set. 

thank you all and sorry for the noise! 


Von: "Ista Zahn"  
An: "Angerer, Philipp"  
CC: "Dirk Eddelbuettel" , "Martyn Plummer" , 
"r-devel"  
Gesendet: Mittwoch, 19. April 2017 19:10:20 
Betreff: Re: [Rd] R 3.4 has broken C++11 support 

Hi Philipp, 

Fellow Archlinux user here. I think the problem is with the r-devel 
PKGBUILD file, rather than anything wrong in R itself. The PKGBUILD 
file does this: 

ln -s /etc/R/${i} ${i} 

when it should do 

ln -s /etc/R-devel/${i} ${i} 

You can fix your installed version with 

cd /opt/r-devel/lib/R/etc/ 
sudo rm ./* 
sudo ln -s /etc/R-devel/javaconf 
sudo ln -s /etc/R-devel/ldpaths 
sudo ln -s /etc/R-devel/Makeconf 
sudo ln -s /etc/R-devel/Renviron 
sudo ln -s /etc/R-devel/repositories 

Or (better) fix the PKGBUILD and makepkg/pacman -U 

Best, 
Ista 



On Wed, Apr 19, 2017 at 10:32 AM, Angerer, Philipp via R-devel 
 wrote: 
> Hi Dirk and Martyn, 
> 
>> That looks fine. Can you please give a reproducible example of a package 
>> that compiles correctly on R 3.3.3 but not with R 3.4.0 or R-devel. 
> 
> here you go, it’s pretty much the simplest package possible that needs C++11: 
> 
> https://github.com/flying-sheep/cxx11test 
> 
>> Maybe you can share with us how you configure the build of R-devel? 
> 
> Sure, in the mail you quoted, I already linked exactly that: 
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40 
> 
>> ./configure --prefix=/opt/r-devel \ 
>> --libdir=/opt/r-devel/lib \ 
>> --sysconfdir=/etc/R-devel \ 
>> --datarootdir=/opt/r-devel/share \ 
>> rsharedir=/opt/r-devel/share/R/ \ 
>> rincludedir=/opt/r-devel/include/R/ \ 
>> rdocdir=/opt/r-devel/share/doc/R/ \ 
>> --with-x \ 
>> --enable-R-shlib \ 
>> --with-lapack \ 
>> --with-blas \ 
>> F77=gfortran \ 
>> LIBnn=lib 
> 
> 
> Thanks and cheers, 
> Philipp 
> 
> 
> Helmholtz Zentrum Muenchen 
> Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) 
> Ingolstaedter Landstr. 1 
> 85764 Neuherberg 
> www.helmholtz-muenchen.de 
> Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe 
> Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons 
> Enhsen 
> Registergericht: Amtsgericht Muenchen HRB 6466 
> USt-IdNr: DE 129521671 
> 
> __ 
> R-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-devel 

 


Helmholtz Zentrum Muenchen

Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)

Ingolstaedter Landstr. 1

85764 Neuherberg

www.helmholtz-muenchen.de

Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe

Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen

Registergericht: Amtsgericht Muenchen HRB 6466

USt-IdNr: DE 129521671


[[alternative HTML version deleted]]

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

Re: [Rd] c() documentation after change; 'recursive' in "base" methods

[Martin Maechler]

> Suharto Anggono Suharto Anggono via R-devel 
> on Wed, 19 Apr 2017 22:50:41 + writes:

> In R 3.4.0 RC, argument list of 'c' as S4 generic function has become
> (x, ...) .
> However, "S4 methods" section in documentation of 'c' (c.Rd) is not 
updated yet.

Thank you, I've committed a change (72564 & 72565).

> Also, in R 3.4.0 RC, 'c' method of class "Date" ('c.Date') is still not 
explicitly documented.

yes, but that's true for other S3 methods, see below.

This is a bigger issue.  Thank you for raising it!  Look at

 R code --

(mc <- methods("c"))
## [1] c.bibentry*   c.Datec.difftimec.noquote 
c.numeric_version
## [6] c.person* c.POSIXct c.POSIXlt c.warnings
## and from `lcNSnm` below, you can see that these are from 'base',
## apart from {bibentry, person} which are from 'utils'
lc <- lapply(mc, function(nm) { f <- getAnywhere(nm) })
names(lc) <- sapply(lc, `[[`, "name")
str(lcwh <- lapply(lc, `[[`, "where"))
lcNSnm <- sub("^namespace:", '', sapply(lcwh, function(v) v[length(v)]))
lcNS <- lapply(lcNSnm, asNamespace)
str(lcMeths <-
sapply(names(lcNS), function(n) get(n, envir=lcNS[[n]], inherits=FALSE),
simplify = FALSE))
## $ c.bibentry   :function (..., recursive = FALSE)
## $ c.Date   :function (..., recursive = FALSE)
## $ c.difftime   :function (..., recursive = FALSE)
## $ c.noquote:function (..., recursive = FALSE)
## $ c.numeric_version:function (..., recursive = FALSE)
## $ c.person :function (..., recursive = FALSE)
## $ c.POSIXct:function (..., recursive = FALSE)
## $ c.POSIXlt:function (..., recursive = FALSE)
## $ c.warnings   :function (..., recursive = FALSE)

 .. --

and from these, only the 'noquote' method has a "\usage{ . }"
documentation.

The reason actually is that I had *wanted* to consider
__removing__ the 'recursive' argument from most of these S3 methods,
since all but  c.numeric_version()  completely disregard it and
it would be nicer if they did not have it.

HOWEVER, if it is removed and a user / code has

val <- c(, recursive = r)

then 'recursive' will become part of 'val' which is not desirable.

I had never thought more about this and if we should try or not to
remove it from the S3 methods in all those cases it is unused
... hoping that callers would also *not* set it.

As _one_ consequence I had decided rather *not* documenting it
for the S3 methods where it is (still ?!) part.

Martin

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

Re: [Rd] ask.yes.no() function

[Dirk Eddelbuettel]

On 20 April 2017 at 09:33, Michael Sumner wrote:
| Perhaps worth pointing out "yesno" as a candidate:
| 
| https://CRAN.R-project.org/package=yesno
| 

Not really as

 i)  base R will not have dependencies outside of it

 ii) more importantly, Duncan asked for a good example of a "consistent" (as
 in: predictable) question function yet you submit one which by design
 *varies* answers to be less predictable.

Dirk
 
| Cheers, Mike
| 
| 
| 
| On Wed, 19 Apr 2017 at 21:55 Duncan Murdoch 
| wrote:
| 
| As described in
| , R base
| functions are currently inconsistent in asking interactive "yes/no" type
| questions. One solution to this is to have a function to do it, and to
| use it consistently.
| 
| 
| 
| 
| Rather than just writing such a function and possibly missing some
| desirable feature, I'd like to ask if anyone can point to an existing
| one that is perfect (or nearly perfect, and point out what changes would
| be desirable)?
| 
| Duncan Murdoch
| 
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
| -- 
| Dr. Michael Sumner
| Software and Database Engineer
| Australian Antarctic Division
| 203 Channel Highway
| Kingston Tasmania 7050 Australia
| 
|   [[alternative HTML version deleted]]
| 
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

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

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

Re: [Rd] ask.yes.no() function

[Duncan Murdoch]

On 20/04/2017 9:13 AM, Dirk Eddelbuettel wrote:


On 20 April 2017 at 09:33, Michael Sumner wrote:
| Perhaps worth pointing out "yesno" as a candidate:
|
| https://CRAN.R-project.org/package=yesno
| 

Not really as

 i)  base R will not have dependencies outside of it


Indeed, I'm looking for one that can be copied into base R.  The author 
can retain copyright, but we need to be able to offer it under our GPL 
license.




 ii) more importantly, Duncan asked for a good example of a "consistent" (as
 in: predictable) question function yet you submit one which by design
 *varies* answers to be less predictable.


Yes, there are reasons to have questions that vary randomly, but I think 
they don't apply to the situations where I want to use this.


Duncan Murdoch



Dirk

| Cheers, Mike
|
|
|
| On Wed, 19 Apr 2017 at 21:55 Duncan Murdoch 
| wrote:
|
| As described in
| , R base
| functions are currently inconsistent in asking interactive "yes/no" type
| questions. One solution to this is to have a function to do it, and to
| use it consistently.
|
|
|
|
| Rather than just writing such a function and possibly missing some
| desirable feature, I'd like to ask if anyone can point to an existing
| one that is perfect (or nearly perfect, and point out what changes would
| be desirable)?
|
| Duncan Murdoch
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
| --
| Dr. Michael Sumner
| Software and Database Engineer
| Australian Antarctic Division
| 203 Channel Highway
| Kingston Tasmania 7050 Australia
|
|   [[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

Re: [Rd] system/system2 and open file descriptors

[William Dunlap via R-devel]

In S+ on Unix-alikes we dealt with this issue by using fcntl(fd,
F_SETFD, 1) to set the close-on-exec flag on a file descriptor as soon
as we opened it.
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Wed, Apr 19, 2017 at 8:40 PM, Winston Chang  wrote:
> In addition to the issue of a child process holding onto open files, the
> child process can also manipulate a file descriptor in a way that affects
> the parent process. For example, calling lseek() in the child process will
> move the file offset in the parent process.
>
> Here is a set of commands that demonstrates it. They can be copied and
> pasted in a terminal. What it does:
> - Creates C program that seeks to the beginning of a file descriptor, and
> compiles it to a program named "lseek".
> - Creates a file with some text in it.
> - Starts R. In R:
> - Opens the text file and reads the first line.
> - Runs lseek in a child process.
> - Reads the rest of the lines.
>
>
> echo "#include 
> int main(void) {
>   lseek(3, 0, SEEK_SET);
> }" > lseek.c
>
> gcc lseek.c -o lseek
>
> echo "line 1
> line 2
> line 3" > lines.txt
>
> R
> f <- file('lines.txt', 'r')
> cat(readLines(f, n = 1), sep = "\n")
> system('./lseek')
> cat(readLines(f), sep = "\n")
>
>
> Here's what it outputs:
>> f <- file('lines.txt', 'r')
>> cat(readLines(f, n = 1), sep = "\n")
> line 1
>> system('./lseek')
>> cat(readLines(f), sep = "\n")
> line 2
> line 3
> line 1
> line 2
> line 3
>
> The child process has changed what the parent process reads from the file.
> (I'm guessing that the reason readLines() prints out "line 2" and "line 3"
> before starting over is because it has already buffered the whole file
> before lseek is executed.)
>
> This is obviously a highly contrived case, but it illustrates what's
> possible. The other issue I mentioned, with child processes holding open
> files after the R process exits, is more likely to cause problems in the
> real world. That's actually how I encountered this issue in the first
> place: when restarting R inside of RStudio on a Mac, if there are any
> extant child processes started by system(), they keep some files open, and
> this causes RStudio to hang. (There's a fix in progress for RStudio for
> this particular issue.)
>
> -Winston
>
>
>
> On Tue, Apr 18, 2017 at 3:20 PM, Winston Chang 
> wrote:
>
>> It seems that the system() and system2() functions don't close file
>> descriptors between the fork() and exec() (on Unix platforms, of course).
>> This means that the child processes inherit open files and socket
>> connections.
>>
>> Running this (from a terminal) will result in the child process writing to
>> a file that was opened by R:
>>
>> R
>> f <- file('foo.txt', 'w')
>> system('echo "abc" >&3')
>>
>>
>>
>> You can also see the open files if you run the following:
>>   f <- file('foo.txt', 'w')
>>   system2('sleep', '100', wait=F)
>>
>> And then in another terminal:
>>   lsof -c R -c sleep
>> it will show that both the R and sleep processes have the file open:
>>   ...
>>   R   324 root3w   REG   0,480   4259 /foo.txt
>>   ...
>>   sleep   327 root3w   REG   0,480   4259 /foo.txt
>>
>>
>> This behavior can cause problems if R spawns a child process that outlives
>> the R process, but keeps open some resources.
>>
>> Would it be possible to add an option to close file descriptors for child
>> processes? It would be nice if that were the default, but I suspect that
>> making that change would break a lot of existing code.
>>
>> To take an example from the Python world, subprocess.Popen() has an
>> option, close_fds, which closes all file descriptors except 0, 1, and 2.
>>   https://docs.python.org/2/library/subprocess.html#popen-constructor
>>
>>
>> -Winston
>>
>
> [[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

[Rd] Problems with S4 methods dispatching on `...` (aka dotsMethods)

[Andrzej Oleś]

Hi all,

I recently encountered some unexpected behavior with S4 generics
dispatching on `...`, which I described in
http://stackoverflow.com/questions/43499203/use-callnextmethod-with-dotsmethods

TL;DR: `callNextMethod()` doesn't work in methods dispatching on `...`, and
arguments of such methods are resolved differently than the arguments of
methods dispatching on formal arguments.

Could this indicate a potential problem with the implementation of the
`...` dispatch?

Cheers,
Andrzej

[[alternative HTML version deleted]]

__
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] Problems with S4 methods dispatching on `...` (aka dotsMethods)

[Michael Lawrence]

Thanks for pointing out these issues. I have a fix that I will commit soon.

Btw, I would never have seen the post on Stack Overflow. It's best to
report bugs on the bugzilla.

Michael

On Thu, Apr 20, 2017 at 8:30 AM, Andrzej Oleś  wrote:
> Hi all,
>
> I recently encountered some unexpected behavior with S4 generics
> dispatching on `...`, which I described in
> http://stackoverflow.com/questions/43499203/use-callnextmethod-with-dotsmethods
>
> TL;DR: `callNextMethod()` doesn't work in methods dispatching on `...`, and
> arguments of such methods are resolved differently than the arguments of
> methods dispatching on formal arguments.
>
> Could this indicate a potential problem with the implementation of the
> `...` dispatch?
>
> Cheers,
> Andrzej
>
> [[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