Re: [Rd] possible bug in R's configure check for C++11 features
I'm sorry, I'm an idiot for not noticing this. That's what happens when you
have been stuck in configure/make hell for a while.
Best,
Kasper
On Tue, Sep 3, 2019 at 10:54 PM Simon Urbanek
wrote:
> Kasper,
>
> I haven’t checked in depth, so just to clarify: you *are* setting
> CXX11=g++ so it is doing what you asked it to. Since the settings are
> inherited upwards, this implies that you are setting both CXX14 and CXX17
> to g++. So I’m not quite sure I understand your concern.
>
> Cheers,
> Simon
>
>
>
> > On Sep 3, 2019, at 9:02 PM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> >
> > I am trying to compile R under a new setup, and frankly, I have had a lot
> > of problems, but I think the stuff below points to a possible bug in R's
> > (custom) configure checks for C++11/14/17, but not for C++98.
> >
> > This is a report about R from the R-3-6 branch, with a svn checkout from
> > today, revision r77135.
> >
> > In my case the compiler name is x86_64-conda_cos6-linux-gnu-g++, not
> g++. I
> > denote this in my configure call, using the CC variable. A snippet of the
> > full configure is
> >
> > ../${SRCDIR}/configure SHELL='/bin/bash' \
> > --prefix="${CONDA_PREFIX}/R/${R_VERSION}" \
> > CC="x86_64-conda_cos6-linux-gnu-gcc" \
> > CXX="x86_64-conda_cos6-linux-gnu-g++" \
> > F77="x86_64-conda_cos6-linux-gnu-gfortran" \
> > FC="$F77" \
> > CFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include"\
> > CXXFLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
> > F77FLAGS="-Wall -g -O2 -mtune=amdfam10 -I${CONDA_PREFIX}/include" \
> > CXX11="g++" \
> > CXX11STD="-std=c++11" \
> > CXX11FLAGS="-Wall -mtune=amdfam10 -g -O2 -I${CONDA_PREFIX}/include" \
> > CXX11PICFLAGS="-fPIC" \
> >
> > Where $CONDA_PREFIX is given in my script.
> >
> > The output in config.log is given below. Note that in the test for c++98,
> > it uses the "right" CC, but in the test for c++11 it uses g++. This looks
> > wrong to me:
> >
> > configure:28111: checking whether x86_64-conda_cos6-linux-gnu-g++
> supports
> > C++98 features with -std=gnu++98
> > configure:28130: x86_64-conda_cos6-linux-gnu-g++ -std=gnu++98 -c -Wall
> > -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > -fpic -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cp
> > p >&5
> > configure:28130: $? = 0
> > configure:28139: result: yes
> > configure:28315: checking whether g++ -std=c++11 supports C++11 features
> > configure:28607: g++ -std=c++11 -c -Wall -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > -fPIC -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 conftest.cpp >&5
> > ../R-3.6-src/configure: line 2355: g++: command not found
> > configure:28607: $? = 127
> > configure: failed program was:
> >
> > I have similar issues (wrong CC using when compiling the test program)
> with
> > the test for c++14, whereas the test for c++17 has empty space where the
> CC
> > variable should be?
> >
> > I can fix this issue by adding a soft link in my PATH from g++ to my
> > compiler of choice. In this case configure finishes and reports that I
> have
> > full C++17 capabilities. Weirdly, in the output, note that the C++
> compiler
> > is "wrong" again, despite my configure call:
> >
> > Source directory:../R-3.6-src
> > Installation directory:
> > /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/R/3.6
> >
> > C compiler: x86_64-conda_cos6-linux-gnu-gcc -Wall
> > -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > Fortran fixed-form compiler:
> >
> /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/bin/x86_64-conda_cos6-linux-gnu-gfortran
> > -fno-optimize-sibling-calls -fopenmp -march=nocona -mtune=haswell
> > -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> > -ffunction-sections -pipe
> >
> > Default C++ compiler:g++ -std=c++11 -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > C++98 compiler: x86_64-conda_cos6-linux-gnu-g++
> -std=gnu++98
> > -Wall -mtune=amdfam10 -g -O2
> > -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > C++11 compiler: g++ -std=c++11 -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > C++14 compiler: g++ -std=gnu++14 -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > C++17 compiler: g++ -std=gnu++17 -Wall -mtune=amdfam10 -g
> > -O2
> -I/jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/include
> > Fortran free-form compiler:
> >
> /jhpce/shared/jhpce/core/conda/miniconda3-4.6.14/envs/svnR-3.6/bin/x86_64-conda_cos6-linux-gnu-gfortran
> > -fno-optimize-sibling-calls
> > Obj-C compiler:
> >
> >
> >
> > --
[Rd] '==' operator: inconsistency in data.frame(...) == NULL
Dear all, I just stumbled upon some behavior of the == operator which is at least somewhat inconsistent. R version 3.6.1 (2019-07-05) -- "Action of the Toes" Copyright (C) 2019 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit) > list(a=1:3, b=LETTERS[1:3]) == NULL logical(0) > matrix(1:6, 2,3) == NULL logical(0) > data.frame(a=1:3, b=LETTERS[1:3]) == NULL # same for == logical(0) Error in matrix(if (is.null(value)) logical() else value, nrow = nr, dimnames = list(rn, : length of 'dimnames' [2] not equal to array extent > data.frame(NULL) == 1 <0 x 0 matrix> > data.frame(NULL) == NULL <0 x 0 matrix> > data.frame(NULL) == logical(0) <0 x 0 matrix> I wonder if data.frame() == NULL should also return a value instead of an error. R help reads: "At least one of |x| and |y| must be an atomic vector, but if the other is a list *R* attempts to coerce it to the type of the atomic vector: this will succeed if the list is made up of elements of length one that can be coerced to the correct type. If the two arguments are atomic vectors of different types, one is coerced to the type of the other, the (decreasing) order of precedence being character, complex, numeric, integer, logical and raw." It is not clear from the help what to expect for NULL or empty atomic vectors. It is also strange that for list() there is no error but for data.frame() with the same data an error is thrown. I can see that there might be reasons to return logical(0) instead of FALSE, but I do not fully understand why there should be differences between e.g. matrix() and data.frame(). Also, It is at least somewhat strange that data.frame(NULL) == NULL and similar expressions return an empty matrix, while comparing a normal filled matrix to NULL returns logical(0). Even if this behavior is expected, the error message shown by data.frame(...) == NULL is not very informative. Thanks and best regards, Hilmar [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?
Hi,
I've found the answers to my questions:
1. For sort function, here are some macros defined in Rinternal.h:
/* ALTREP sorting support */
enum {SORTED_DECR_NA_1ST = -2,
SORTED_DECR = -1,
UNKNOWN_SORTEDNESS = INT_MIN, /*INT_MIN is NA_INTEGER! */
SORTED_INCR = 1,
SORTED_INCR_NA_1ST = 2,
KNOWN_UNSORTED = 0};
The macro names are pretty self-explanatory. The current implementation
only supports the ascending sort.
2. For anyNA, it goes to(Real SEXP)
===coerce.c===
if(REAL_NO_NA(x))
return FALSE;
ITERATE_BY_REGION(x, xD, i, nbatch, double, REAL, {
for (int k = 0; k < nbatch; k++)
if (ISNAN(xD[k]))
return TRUE;
});
===altrep.c===
int REAL_NO_NA(SEXP x)
{
return ALTREP(x) ? ALTREAL_DISPATCH(No_NA, x) : 0;
}
If the argument x is not an ALTREP, the function will return 0, and a
default method will be used, so there is no way to return true without loop
over the argument x right now. I hope this could be changed in the future.
Best,
Jiefei
On Tue, Sep 3, 2019 at 2:49 PM Wang Jiefei wrote:
> Hi,
>
>
>
> I would like to figure out the meaning of the return value of these two
> functions. Here are the default definitions I find from R source code:
>
>
>
> static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS;
> }
>
> static int altreal_No_NA_default(SEXP x) { return 0; }
>
> I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA *simply
> means
> unknown sorted/NA status of the vector, so R will loop over the vector and
> find the answer. However, what should we return in these functions to
> indicate whether the vector has been sorted/ contains NA? My initial guess
> is 0/1 but since *NA_NA *uses 0 as its default value so it will be
> ambiguous. Are there any macros to define yes/no return values for these
> functions? I would appreciate any thought here.
>
>
>
> Best,
>
> Jiefei
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reverse dependency checks
https://builder.r-hub.io/ El martes, 3 de septiembre de 2019, Therneau, Terry M., Ph.D. via R-devel < r-devel@r-project.org> escribió: > I remember there was advice about a server that one could use for reverse > dependency > checks, but I forgot to write it down. (Or I did save the info and forgot > where I saved > it...) I have been doing the checks for survival myself, but the count > is getting out of > hand (663, not counting bioconductor). > > Any pointers? > > Terry Therneau > > > [[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
Re: [Rd] reverse dependency checks
On Tue, 3 Sep 2019 at 14:53, Therneau, Terry M., Ph.D. via R-devel wrote: > > I remember there was advice about a server that one could use for reverse > dependency > checks, but I forgot to write it down. (Or I did save the info and forgot > where I saved > it...) I have been doing the checks for survival myself, but the count is > getting out of > hand (663, not counting bioconductor). > > Any pointers? You could try Yihui's crandalf [1]. Locally, I don't know what you are using, but there are a few alternatives. Notably, Dirk's prrd [2] (the only one that I tried myself and I can thus recommend), Gabor's revdepcheck [3] and R's brand new tools::check_packages_in_dir(). [1] https://github.com/yihui/crandalf [2] https://github.com/eddelbuettel/prrd [3] https://github.com/r-lib/revdepcheck Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
