[Rd] Package Version Checking

2017-04-19 Thread Richard Barnes 
This is a feature suggestion.

My apologies if it's already been raised.

I recently noticed that dplyr's behaviour has changed:
> *dplyr 0.4.0*
> df <- data_frame(x = c(1, 1, 1, 2, 2), y = 1:5)
> result <- df %>% dplyr::distinct(x) %>% sum
> *# result == 8*
>
> *dplyr 0.5.0*
> df <- data_frame(x = c(1, 1, 1, 2, 2), y = 1:5)
> result <- df %>% dplyr::distinct(x) %>% sum
> *# result == 3*
That's fine. It's nice to see package maintainers fixing bugs and
improving functionality.

What's not fine is that for most users, myself included, this change was
essentially silent.

I would suggest amending the `library` and `require` functions as
follows, e.g.:
> library(dplyr, version='0.4.0', versioning='semantic')
> library(dplyr, version='0.4.0', versioning='exact')
If the version check indicates the package has been updated in a way
which doesn't maintain backwards compatibility, a warning message would
be generated or, possibly, the code would halt.

This would provide R users a way of specifying the conditions under
which their scripts produced the results they obtain.

Best regards,
Richard

[[alternative HTML version deleted]]

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

Re: [Rd] Crash after (wrongly) applying product operator on object from LIMMA package

2017-04-19 Thread Hilmar Berger 

Hi,

following up on my own question, I found smaller example that does not 
require LIMMA:


setClass("FOOCLASS",
 representation("list")
)
ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))

> ma * ma$M
Error: C stack usage  7970512 is too close to the limit

> library(xlsx)
Loading required package: rJava
Loading required package: xlsxjars
> ma * ma$M
---> Crash

xlsx seems to act like a catalyst here, with the product operator 
running in a deep nested iteration, exhausting the stack. Valgrind shows 
thousands of invalid stack accesses when loading xslx, which might 
contribute to the problem. Package xlsx has not been updated since 2014, 
so it might fail with more current versions of R or Java (I'm using 
Oracle Java 8).


Still, even if xlsx was the package to be blamed for the crash, I fail 
to understand what exactly the product operator is trying to do in the 
multiplication of the matrix with the object.


Best regards,
Hilmar

On 18/04/17 18:57, Hilmar Berger wrote:

Hi,

this is a problem that occurs in the presence of two libraries (limma, 
xlsx) and leads to a crash of R. The problematic code is the wrong 
application of sweep or the product ("*") function on an LIMMA MAList 
object. To my knowledge, limma does not define a "*" method for MAList 
objects.


If only LIMMA is loaded but not package xlsx, the code does not crash 
but rather produces an error ("Error: C stack usage  7970512 is too 
close to the limit"). Loading only package rJava instead of xlsx does 
also not produce the crash but the error message instead. Note that 
xlsx functions are not explicitly used.


It could be reproduced on two different Linux machines running 
R-3.2.5, R-3.3.0 and R-3.3.2.


Code to reproduce the problem:
-
library(limma)
library(xlsx)

# a MAList
ma = new("MAList", list(A=matrix(rnorm(300), 30,10), 
M=matrix(rnorm(300), 30,10)))


# This should actually be sweep(ma$M, ...) for functional code, but I 
omitted the $M...

#sweep(ma, 2, c(1:10), "*")
# sweep will crash when doing the final operation of applying the 
function over the input matrix, which in this case is function "*"


f = match.fun("*")
# This is not exactly the same as in sweep but it also tries to 
multiply the MAList object with a matrix of same size and leads to the 
crash

f(ma, ma$M)
# ma * ma$M has the same effect
-

My output:

R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 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.

> library(limma)
> library(xlsx)
Loading required package: rJava
Loading required package: xlsxjars
>
> sessionInfo()
R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8  LC_NUMERIC=C LC_TIME=en_US.UTF-8
 [4] LC_COLLATE=en_US.UTF-8LC_MONETARY=en_US.UTF-8 
LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8  LC_NAME=en_US.UTF-8 
LC_ADDRESS=en_US.UTF-8
[10] LC_TELEPHONE=en_US.UTF-8  LC_MEASUREMENT=en_US.UTF-8 
LC_IDENTIFICATION=en_US.UTF-8


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

other attached packages:
[1] xlsx_0.5.7 xlsxjars_0.6.1 rJava_0.9-8limma_3.30.7

loaded via a namespace (and not attached):
[1] tools_3.3.0
>
> ma = new("MAList", list(A=matrix(rnorm(300), 30,10), 
M=matrix(rnorm(300), 30,10)))

> #sweep(ma, 2, c(1:10), "*")
>
> f = match.fun("*")
> f
function (e1, e2)  .Primitive("*")

> f(ma, ma$M)

> crash to command line with segfault.

Best regards,
Hilmar



--
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charitéplatz 1
D-10117 Berlin
GERMANY

Phone:  + 49 30 28460 430
Fax:+ 49 30 28460 401
 
E-Mail: ber...@mpiib-berlin.mpg.de

Web   : www.mpiib-berlin.mpg.de

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

Re: [Rd] Crash after (wrongly) applying product operator on S4 object that derives from list

2017-04-19 Thread Wolfgang Huber 

Dear Hilmar

Perhaps this gives an indication of why the infinite recursion happens:

## after calling `*` on ma and a matrix:


showMethods(classes=class(ma), includeDefs=TRUE, inherited = TRUE)


Function: * (package base)
e1="FOOCLASS", e2="matrix"
(inherited from: e1="vector", e2="structure")
(definition from function "Ops")
function (e1, e2)
{
value <- callGeneric(e1, e2@.Data)
if (length(value) == length(e2)) {
e2@.Data <- value
e2
}
else value
}




is(ma, "vector")

[1] TRUE

I got that in a fresh session of

sessionInfo()

R Under development (unstable) (2017-04-18 r72542)
Platform: x86_64-apple-darwin16.5.0 (64-bit)
Running under: macOS Sierra 10.12.4

Best wishes
Wolfgang

19.4.17 10:01, Hilmar Berger scripsit:

Hi,

following up on my own question, I found smaller example that does not
require LIMMA:

setClass("FOOCLASS",
 representation("list")
)
ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))


ma * ma$M

Error: C stack usage  7970512 is too close to the limit


library(xlsx)

Loading required package: rJava
Loading required package: xlsxjars

ma * ma$M

---> Crash

xlsx seems to act like a catalyst here, with the product operator
running in a deep nested iteration, exhausting the stack. Valgrind shows
thousands of invalid stack accesses when loading xslx, which might
contribute to the problem. Package xlsx has not been updated since 2014,
so it might fail with more current versions of R or Java (I'm using
Oracle Java 8).

Still, even if xlsx was the package to be blamed for the crash, I fail
to understand what exactly the product operator is trying to do in the
multiplication of the matrix with the object.

Best regards,
Hilmar

On 18/04/17 18:57, Hilmar Berger wrote:

Hi,

this is a problem that occurs in the presence of two libraries (limma,
xlsx) and leads to a crash of R. The problematic code is the wrong
application of sweep or the product ("*") function on an LIMMA MAList
object. To my knowledge, limma does not define a "*" method for MAList
objects.

If only LIMMA is loaded but not package xlsx, the code does not crash
but rather produces an error ("Error: C stack usage  7970512 is too
close to the limit"). Loading only package rJava instead of xlsx does
also not produce the crash but the error message instead. Note that
xlsx functions are not explicitly used.

It could be reproduced on two different Linux machines running
R-3.2.5, R-3.3.0 and R-3.3.2.

Code to reproduce the problem:
-
library(limma)
library(xlsx)

# a MAList
ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
M=matrix(rnorm(300), 30,10)))

# This should actually be sweep(ma$M, ...) for functional code, but I
omitted the $M...
#sweep(ma, 2, c(1:10), "*")
# sweep will crash when doing the final operation of applying the
function over the input matrix, which in this case is function "*"

f = match.fun("*")
# This is not exactly the same as in sweep but it also tries to
multiply the MAList object with a matrix of same size and leads to the
crash
f(ma, ma$M)
# ma * ma$M has the same effect
-

My output:

R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 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.

> library(limma)
> library(xlsx)
Loading required package: rJava
Loading required package: xlsxjars
>
> sessionInfo()
R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8  LC_NUMERIC=C LC_TIME=en_US.UTF-8
 [4] LC_COLLATE=en_US.UTF-8LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8  LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
[10] LC_TELEPHONE=en_US.UTF-8  LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8

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

other attached packages:
[1] xlsx_0.5.7 xlsxjars_0.6.1 rJava_0.9-8limma_3.30.7

loaded via a namespace (and not attached):
[1] tools_3.3.0
>
> ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
M=matrix(rnorm(300), 30,10)))
> #sweep(ma, 2, c(1:10), "*")
>
> f = match.fun("*")
> f
function (e1, e2)  .Primitive("*")

> f(ma, ma$M)

> crash to command line with segfault.

Best regards,
Hilmar





__
R-devel@r-project.org mailing list

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

2017-04-19 Thread Angerer, Philipp via R-devel 
Hi!

Well, my linux distribution has very recent versions
of everything, so a working C++11 compiler exists:

$ gcc --version | head -n1
gcc (GCC) 6.3.1 20170306

Could wrong ./configure options be at fault here? See:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40

My sessionInfo():

$ R-devel --slave -e 'sessionInfo()' | head -n3
R Under development (unstable) (2017-04-18 r72542)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

Thanks, 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

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

2017-04-19 Thread Martyn Plummer 
On Wed, 2017-04-19 at 12:42 +0200, Angerer, Philipp wrote:
> Hi!
> 
> Well, my linux distribution has very recent versions
> of everything, so a working C++11 compiler exists:
> 
> $ gcc --version | head -n1
> gcc (GCC) 6.3.1 20170306

I am on Fedora 25 which also uses gcc 6.3.1. The default standard for
6.3.1 is C++14. The output from configure should contain these lines:

  Default C++ compiler:  g++   
  C++98 compiler:g++ -std=gnu++98 
  C++11 compiler:g++ -std=gnu++11 
  C++14 compiler:g++  
  C++17 compiler:  

Please check.

Martyn

> Could wrong ./configure options be at fault here? See:
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40
> 
> My sessionInfo():
> 
> $ R-devel --slave -e 'sessionInfo()' | head -n3
> R Under development (unstable) (2017-04-18 r72542)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Arch Linux
> 
> Thanks, 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

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

2017-04-19 Thread Martyn Plummer 
On Wed, 2017-04-19 at 13:17 +0200, Angerer, Philipp wrote:
> Hmm, doesn’t look like my R was configured incorrectly:

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.

Martyn

> 
> 
> R is now configured for x86_64-pc-linux-gnu
> 
>   Source directory:  .
>   Installation directory:/opt/r-devel
> 
>   C compiler:gcc  -march=x86-64 -mtune=generic -O2 -pipe 
> -fstack-protector-strong --param=ssp-buffer-size=4
>   Fortran 77 compiler:   gfortran  -g -O2
> 
>   Default C++ compiler:  g++   -march=x86-64 -mtune=generic -O2 -pipe 
> -fstack-protector-strong --param=ssp-buffer-size=4
>   C++98 compiler:g++ -std=gnu++98 -march=x86-64 -mtune=generic 
> -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
>   C++11 compiler:g++ -std=gnu++11 -march=x86-64 -mtune=generic 
> -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
>   C++14 compiler:g++  -march=x86-64 -mtune=generic -O2 -pipe 
> -fstack-protector-strong --param=ssp-buffer-size=4
>   C++17 compiler:  
>   Fortran 90/95 compiler:gfortran -g -O2
>   Obj-C compiler: 
> 
>   Interfaces supported:  X11, tcltk
>   External libraries:readline, BLAS(generic), LAPACK(generic), curl
>   Additional capabilities:   PNG, JPEG, TIFF, NLS, cairo, ICU
>   Options enabled:   shared R library, R profiling
> 
>   Capabilities skipped:  
>   Options not enabled:   shared BLAS, memory profiling
> 
>   Recommended packages:  yes
> 
> - Ursprüngliche Mail -
> Von: "Angerer, Philipp" 
> An: "Martyn Plummer" 
> CC: "r-devel" 
> Gesendet: Mittwoch, 19. April 2017 12:42:33
> Betreff: Re: [Rd] R 3.4 has broken C++11 support
> 
> Hi! 
> 
> Well, my linux distribution has very recent versions 
> of everything, so a working C++11 compiler exists: 
> 
> $ gcc --version | head -n1 
> gcc (GCC) 6.3.1 20170306 
> 
> Could wrong ./configure options be at fault here? See: 
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40 
> 
> My sessionInfo(): 
> 
> $ R-devel --slave -e 'sessionInfo()' | head -n3 
> R Under development (unstable) (2017-04-18 r72542) 
> Platform: x86_64-pc-linux-gnu (64-bit) 
> Running under: Arch Linux 
> 
> Thanks, 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

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

2017-04-19 Thread Dirk Eddelbuettel 

On 19 April 2017 at 12:42, Angerer, Philipp via R-devel wrote:
| Well, my linux distribution has very recent versions
| of everything, so a working C++11 compiler exists:
| 
| $ gcc --version | head -n1
| gcc (GCC) 6.3.1 20170306
| 
| Could wrong ./configure options be at fault here? See:
| 
| https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40
| 
| My sessionInfo():
| 
| $ R-devel --slave -e 'sessionInfo()' | head -n3
| R Under development (unstable) (2017-04-18 r72542)
| Platform: x86_64-pc-linux-gnu (64-bit)
| Running under: Arch Linux

Maybe you can share with us how you configure the build of R-devel?  I tend
to locally build every week or so and I have the following on Ubuntu 16.10:

  CXX = ccache g++ 
  CXXCPP = $(CXX) -E
  CXXFLAGS = -ggdb -pipe -Wall -pedantic $(LTO)
  CXXPICFLAGS = -fpic
  CXX98 = ccache g++
  CXX98FLAGS = -ggdb -pipe -Wall -pedantic
  CXX98PICFLAGS = -fpic
  CXX98STD = -std=gnu++98
  CXX11 = ccache g++
  CXX11FLAGS = -ggdb -pipe -Wall -pedantic
  CXX11PICFLAGS = -fpic
  CXX11STD = -std=gnu++11
  CXX14 = ccache g++
  CXX14FLAGS = -ggdb -pipe -Wall -pedantic
  CXX14PICFLAGS = -fpic
  CXX14STD = 
  CXX17 = 
  CXX17FLAGS = 
  CXX17PICFLAGS = 
  CXX17STD = 

I call configure in build shell script (which has not changed in years) with 

  R_PAPERSIZE=letter\
  R_BATCHSAVE="--no-save --no-restore"  \
  R_BROWSER=xdg-open\
  PAGER=/usr/bin/pager  \
  PERL=/usr/bin/perl\
  R_UNZIPCMD=/usr/bin/unzip \
  R_ZIPCMD=/usr/bin/zip \
  R_PRINTCMD=/usr/bin/lpr   \
  LIBnn=lib \
  AWK=/usr/bin/awk  \
  CC="ccache gcc"   \
  CFLAGS="-ggdb -pipe -std=gnu99 -Wall -pedantic" \
  CXX="ccache g++"  \
  CXXFLAGS="-ggdb -pipe -Wall -pedantic"\
  FC="ccache gfortran"  \
  F77="ccache gfortran" \
  MAKE="make -j4"   \
  ./configure   \
  --prefix=/usr/local/lib/R-devel   \
  --enable-R-shlib  \
  --without-blas\
  --without-lapack  \
  --without-recommended-packages

Works here ...

Dirk

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

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

[Rd] ask.yes.no() function

2017-04-19 Thread Duncan Murdoch 
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

[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

2017-04-19 Thread Neumann, Steffen 
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-NodeInfo.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

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

2017-04-19 Thread Angerer, Philipp via R-devel 
Hmm, doesn’t look like my R was configured incorrectly:



R is now configured for x86_64-pc-linux-gnu

  Source directory:  .
  Installation directory:/opt/r-devel

  C compiler:gcc  -march=x86-64 -mtune=generic -O2 -pipe 
-fstack-protector-strong --param=ssp-buffer-size=4
  Fortran 77 compiler:   gfortran  -g -O2

  Default C++ compiler:  g++   -march=x86-64 -mtune=generic -O2 -pipe 
-fstack-protector-strong --param=ssp-buffer-size=4
  C++98 compiler:g++ -std=gnu++98 -march=x86-64 -mtune=generic -O2 
-pipe -fstack-protector-strong --param=ssp-buffer-size=4
  C++11 compiler:g++ -std=gnu++11 -march=x86-64 -mtune=generic -O2 
-pipe -fstack-protector-strong --param=ssp-buffer-size=4
  C++14 compiler:g++  -march=x86-64 -mtune=generic -O2 -pipe 
-fstack-protector-strong --param=ssp-buffer-size=4
  C++17 compiler:  
  Fortran 90/95 compiler:gfortran -g -O2
  Obj-C compiler: 

  Interfaces supported:  X11, tcltk
  External libraries:readline, BLAS(generic), LAPACK(generic), curl
  Additional capabilities:   PNG, JPEG, TIFF, NLS, cairo, ICU
  Options enabled:   shared R library, R profiling

  Capabilities skipped:  
  Options not enabled:   shared BLAS, memory profiling

  Recommended packages:  yes

- Ursprüngliche Mail -
Von: "Angerer, Philipp" 
An: "Martyn Plummer" 
CC: "r-devel" 
Gesendet: Mittwoch, 19. April 2017 12:42:33
Betreff: Re: [Rd] R 3.4 has broken C++11 support

Hi! 

Well, my linux distribution has very recent versions 
of everything, so a working C++11 compiler exists: 

$ gcc --version | head -n1 
gcc (GCC) 6.3.1 20170306 

Could wrong ./configure options be at fault here? See: 

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=r-devel#n40 

My sessionInfo(): 

$ R-devel --slave -e 'sessionInfo()' | head -n3 
R Under development (unstable) (2017-04-18 r72542) 
Platform: x86_64-pc-linux-gnu (64-bit) 
Running under: Arch Linux 

Thanks, 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

Re: [Rd] Crash after (wrongly) applying product operator on S4 object that derives from list

2017-04-19 Thread Michael Lawrence 
I think this is a known issue with Java messing with the stack, see
e.g. 
http://r.789695.n4.nabble.com/Error-memory-exhausted-limit-reached-td4729708.html.

I'll fix the infinite recursion caused by the methods package.

Michael

On Wed, Apr 19, 2017 at 1:12 AM, Wolfgang Huber  wrote:
> Dear Hilmar
>
> Perhaps this gives an indication of why the infinite recursion happens:
>
> ## after calling `*` on ma and a matrix:
>
>> showMethods(classes=class(ma), includeDefs=TRUE, inherited = TRUE)
>
>
> Function: * (package base)
> e1="FOOCLASS", e2="matrix"
> (inherited from: e1="vector", e2="structure")
> (definition from function "Ops")
> function (e1, e2)
> {
> value <- callGeneric(e1, e2@.Data)
> if (length(value) == length(e2)) {
> e2@.Data <- value
> e2
> }
> else value
> }
>
>
>
>> is(ma, "vector")
>
> [1] TRUE
>
> I got that in a fresh session of
>>
>> sessionInfo()
>
> R Under development (unstable) (2017-04-18 r72542)
> Platform: x86_64-apple-darwin16.5.0 (64-bit)
> Running under: macOS Sierra 10.12.4
>
> Best wishes
> Wolfgang
>
> 19.4.17 10:01, Hilmar Berger scripsit:
>>
>> Hi,
>>
>> following up on my own question, I found smaller example that does not
>> require LIMMA:
>>
>> setClass("FOOCLASS",
>>  representation("list")
>> )
>> ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))
>>
>>> ma * ma$M
>>
>> Error: C stack usage  7970512 is too close to the limit
>>
>>> library(xlsx)
>>
>> Loading required package: rJava
>> Loading required package: xlsxjars
>>>
>>> ma * ma$M
>>
>> ---> Crash
>>
>> xlsx seems to act like a catalyst here, with the product operator
>> running in a deep nested iteration, exhausting the stack. Valgrind shows
>> thousands of invalid stack accesses when loading xslx, which might
>> contribute to the problem. Package xlsx has not been updated since 2014,
>> so it might fail with more current versions of R or Java (I'm using
>> Oracle Java 8).
>>
>> Still, even if xlsx was the package to be blamed for the crash, I fail
>> to understand what exactly the product operator is trying to do in the
>> multiplication of the matrix with the object.
>>
>> Best regards,
>> Hilmar
>>
>> On 18/04/17 18:57, Hilmar Berger wrote:
>>>
>>> Hi,
>>>
>>> this is a problem that occurs in the presence of two libraries (limma,
>>> xlsx) and leads to a crash of R. The problematic code is the wrong
>>> application of sweep or the product ("*") function on an LIMMA MAList
>>> object. To my knowledge, limma does not define a "*" method for MAList
>>> objects.
>>>
>>> If only LIMMA is loaded but not package xlsx, the code does not crash
>>> but rather produces an error ("Error: C stack usage  7970512 is too
>>> close to the limit"). Loading only package rJava instead of xlsx does
>>> also not produce the crash but the error message instead. Note that
>>> xlsx functions are not explicitly used.
>>>
>>> It could be reproduced on two different Linux machines running
>>> R-3.2.5, R-3.3.0 and R-3.3.2.
>>>
>>> Code to reproduce the problem:
>>> -
>>> library(limma)
>>> library(xlsx)
>>>
>>> # a MAList
>>> ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
>>> M=matrix(rnorm(300), 30,10)))
>>>
>>> # This should actually be sweep(ma$M, ...) for functional code, but I
>>> omitted the $M...
>>> #sweep(ma, 2, c(1:10), "*")
>>> # sweep will crash when doing the final operation of applying the
>>> function over the input matrix, which in this case is function "*"
>>>
>>> f = match.fun("*")
>>> # This is not exactly the same as in sweep but it also tries to
>>> multiply the MAList object with a matrix of same size and leads to the
>>> crash
>>> f(ma, ma$M)
>>> # ma * ma$M has the same effect
>>> -
>>>
>>> My output:
>>>
>>> R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
>>> Copyright (C) 2016 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.
>>>
>>> > library(limma)
>>> > library(xlsx)
>>> Loading required package: rJava
>>> Loading required package: xlsxjars
>>> >
>>> > sessionInfo()
>>> R version 3.3.0 (2016-05-03)
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>> Running under: Ubuntu 14.04.5 LTS
>>>
>>> locale:
>>>  [1] LC_CTYPE=en_US.UTF-8  LC_NUMERIC=C LC_TIME=en_US.UTF-8
>>>  [4] LC_COLLATE=en_US.UTF-8LC_MONETARY=en_US.UTF-8
>>> LC_MESSAGES=en_US.UTF-8
>>>  [7] L

Re: [Rd] Crash after (wrongly) applying product operator on S4 object that derives from list

2017-04-19 Thread Tomas Kalibera 


We're working on a workaround for the JVM issue, it should be available 
in rJava soon.
(the JVM issue is only on Linux and it turns infinite/deep recursion 
into a crash of R; it also effectively reduces the R stack size)


Best
Tomas

On 04/19/2017 02:56 PM, Michael Lawrence wrote:

I think this is a known issue with Java messing with the stack, see
e.g. 
http://r.789695.n4.nabble.com/Error-memory-exhausted-limit-reached-td4729708.html.

I'll fix the infinite recursion caused by the methods package.

Michael

On Wed, Apr 19, 2017 at 1:12 AM, Wolfgang Huber  wrote:

Dear Hilmar

Perhaps this gives an indication of why the infinite recursion happens:

## after calling `*` on ma and a matrix:


showMethods(classes=class(ma), includeDefs=TRUE, inherited = TRUE)


Function: * (package base)
e1="FOOCLASS", e2="matrix"
 (inherited from: e1="vector", e2="structure")
 (definition from function "Ops")
function (e1, e2)
{
 value <- callGeneric(e1, e2@.Data)
 if (length(value) == length(e2)) {
 e2@.Data <- value
 e2
 }
 else value
}




is(ma, "vector")

[1] TRUE

I got that in a fresh session of

sessionInfo()

R Under development (unstable) (2017-04-18 r72542)
Platform: x86_64-apple-darwin16.5.0 (64-bit)
Running under: macOS Sierra 10.12.4

Best wishes
Wolfgang

19.4.17 10:01, Hilmar Berger scripsit:

Hi,

following up on my own question, I found smaller example that does not
require LIMMA:

setClass("FOOCLASS",
  representation("list")
)
ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))


ma * ma$M

Error: C stack usage  7970512 is too close to the limit


library(xlsx)

Loading required package: rJava
Loading required package: xlsxjars

ma * ma$M

---> Crash

xlsx seems to act like a catalyst here, with the product operator
running in a deep nested iteration, exhausting the stack. Valgrind shows
thousands of invalid stack accesses when loading xslx, which might
contribute to the problem. Package xlsx has not been updated since 2014,
so it might fail with more current versions of R or Java (I'm using
Oracle Java 8).

Still, even if xlsx was the package to be blamed for the crash, I fail
to understand what exactly the product operator is trying to do in the
multiplication of the matrix with the object.

Best regards,
Hilmar

On 18/04/17 18:57, Hilmar Berger wrote:

Hi,

this is a problem that occurs in the presence of two libraries (limma,
xlsx) and leads to a crash of R. The problematic code is the wrong
application of sweep or the product ("*") function on an LIMMA MAList
object. To my knowledge, limma does not define a "*" method for MAList
objects.

If only LIMMA is loaded but not package xlsx, the code does not crash
but rather produces an error ("Error: C stack usage  7970512 is too
close to the limit"). Loading only package rJava instead of xlsx does
also not produce the crash but the error message instead. Note that
xlsx functions are not explicitly used.

It could be reproduced on two different Linux machines running
R-3.2.5, R-3.3.0 and R-3.3.2.

Code to reproduce the problem:
-
library(limma)
library(xlsx)

# a MAList
ma = new("MAList", list(A=matrix(rnorm(300), 30,10),
M=matrix(rnorm(300), 30,10)))

# This should actually be sweep(ma$M, ...) for functional code, but I
omitted the $M...
#sweep(ma, 2, c(1:10), "*")
# sweep will crash when doing the final operation of applying the
function over the input matrix, which in this case is function "*"

f = match.fun("*")
# This is not exactly the same as in sweep but it also tries to
multiply the MAList object with a matrix of same size and leads to the
crash
f(ma, ma$M)
# ma * ma$M has the same effect
-

My output:

R version 3.3.0 (2016-05-03) -- "Supposedly Educational"
Copyright (C) 2016 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.


library(limma)
library(xlsx)

Loading required package: rJava
Loading required package: xlsxjars

sessionInfo()

R version 3.3.0 (2016-05-03)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

locale:
  [1] LC_CTYPE=en_US.UTF-8  LC_NUMERIC=C LC_TIME=en_US.UTF-8
  [4] LC_COLLATE=en_US.UTF-8LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=en_US.UTF-8  LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
[10] LC_TELEPHONE=en_US.UTF-8  LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8

a

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

2017-04-19 Thread Angerer, Philipp via R-devel 
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

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

2017-04-19 Thread Martyn Plummer 
On Wed, 2017-04-19 at 16:32 +0200, Angerer, Philipp 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

This works for me (See below). Make sure you are not overwriting some
key variables in a personal Makevars file or a site-wide Makevars.site
file.

[plummerm@D-160182 temp]$ ~/R-devel/r-devel/build/bin/R CMD INSTALL 
cxx11test_1.0.tar.gz 
* installing to library ‘/home/plummerm/R-devel/r-devel/build/library’
* installing *source* package ‘cxx11test’ ...
** libs
g++ -std=gnu++11 -I/home/plummerm/R-devel/r-devel/build/include -DNDEBUG  
-I"/home/plummerm/R-devel/r-devel/build/library/Rcpp/include" 
-I/usr/local/include   -fpic  -g -O2 -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++11 -I/home/plummerm/R-devel/r-devel/build/include -DNDEBUG  
-I"/home/plummerm/R-devel/r-devel/build/library/Rcpp/include" 
-I/usr/local/include   -fpic  -g -O2 -c test.cpp -o test.o
g++ -std=gnu++11 -shared -L/usr/local/lib64 -o cxx11test.so RcppExports.o test.o
installing to /home/plummerm/R-devel/r-devel/build/library/cxx11test/libs
** R
** preparing package for lazy loading
** help
No man pages found in package  ‘cxx11test’ 
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (cxx11test)

Martyn

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

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

2017-04-19 Thread Dirk Eddelbuettel 

FWIW works for me too, with or without my ~/.R/Makevars

edd@max:~/git$ git clone https://github.com/flying-sheep/cxx11test
Cloning into 'cxx11test'...
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 13 (delta 0), reused 13 (delta 0), pack-reused 0
Unpacking objects: 100% (13/13), done.
Checking connectivity... done.
edd@max:~/git$ cd cxx11test/
edd@max:~/git/cxx11test(master)$ RD CMD INSTALL .
* installing to library ‘/usr/local/lib/R/site-library’
* installing *source* package ‘cxx11test’ ...
** libs
ccache g++ -std=gnu++11 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG
-I"/usr/local/lib/R/site-library/Rcpp/include" -I/usr/local/include   -fpic
-ggdb -pipe -Wall -pedantic -c RcppExports.cpp -o RcppExports.o
ccache g++ -std=gnu++11 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG
-I"/usr/local/lib/R/site-library/Rcpp/include" -I/usr/local/include   -fpic
-ggdb -pipe -Wall -pedantic -c test.cpp -o test.o
ccache g++ -std=gnu++11 -shared -L/usr/local/lib/R-devel/lib/R/lib
-L/usr/local/lib -o cxx11test.so RcppExports.o test.o
-L/usr/local/lib/R-devel/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/cxx11test/libs
** R
** preparing package for lazy loading
** help
No man pages found in package  ‘cxx11test’
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (cxx11test)
edd@max:~/git/cxx11test(master)$

Dirk

-- 
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] R 3.4 has broken C++11 support

2017-04-19 Thread Ista Zahn 
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

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

[Rd] c documentation after change

2017-04-19 Thread Suharto Anggono Suharto Anggono via R-devel 
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.

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

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

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

2017-04-19 Thread Winston Chang 
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