Re: [Rd] pcre problems
On 2/25/19 6:25 AM, robin hankin wrote: Hi there, ubuntu 18.04.2, trying to compile R-devel 3.6.0, svn 76155. I am having difficulty compiling R. I think I have pcre installed correctly: You can use apt-get build-dep r-base to install binary Ubuntu packages needed to build R from source, including PCRE, so there should be no need to compile PCRE from source. If you need for some special reason to compile PCRE from source, please see R Admin Manual, section A.1 on how to configure PCRE. The manual also says how to set compilation flags for R to look for headers in other directories. Sometimes it helps to search the config.log when configure fails. If still in trouble, please report how you built PCRE and how you told R where to find it, and the relevant part of config.log, to maximize chances people could offer useful advice. Best, Tomas OK~/Downloads/R-devel pcretest -C PCRE version 8.41 2017-07-05 Compiled with 8-bit support UTF-8 support No Unicode properties support No just-in-time compiler support Newline sequence is LF \R matches all Unicode newlines Internal link size = 2 POSIX malloc threshold = 10 Parentheses nest limit = 250 Default match limit = 1000 Default recursion depth limit = 1000 Match recursion uses stack OK~/Downloads/R-devel But ./configure gives me this: [snip] checking for pcre.h... yes checking pcre/pcre.h usability... no checking pcre/pcre.h presence... no checking for pcre/pcre.h... no checking if PCRE version >= 8.20, < 10.0 and has UTF-8 support... no checking whether PCRE support suffices... configure: error: pcre >= 8.20 library and headers are required OK~/Downloads/R-devel can anyone advise? hankin.ro...@gmail.com __ 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] Is libtiff >= 4.0.0 now required by R for TIFF support?
We recently discovered that since R 3.3.0, on our CentOS 6 based
cluster, R gets built without TIFF support. The last version where TIFF
support was built, was 3.2.5.
We have libtiff 3.9.4 installed:
$ rpm -q libtiff-devel
libtiff-devel-3.9.4-21.el6_8.x86_64
(Since CentOS 6 is so old, we have manually installed newer versions of
some dependencies: curl 7.46.0, zlib 1.2.8, bzip2 1.0.6, xz 5.2.2 and
pcre 8.38.)
We configure R like this:
BLAS=--with-blas='-mkl=parallel'
LAPACK=--with-lapack
./configure --prefix=$destdir "$BLAS" "$LAPACK" --enable-BLAS-shlib
--enable-R-shlib
(and build with Intel compilers.)
The tiff-related output of the configure script in R 3.2.5 was
$ grep -i tiff _log_3.2.5
checking tiffio.h usability... yes
checking tiffio.h presence... yes
checking for tiffio.h... yes
checking for TIFFOpen in -ltiff... yes
Additional capabilities: PNG, JPEG, TIFF, NLS, cairo
Beginning with R 3.3.0, it was just
$ grep -i tiff _log_3.3.0
Capabilities skipped: TIFF, ICU
(This has been the output for all versions we've installed since 3.3.0.)
I looked at the configure script, and in 3.2.5, the tests for libtiff
starts like this (I've adjusted the indentation):
if test "${use_libtiff}" = yes; then
for ac_header in tiffio.h
do :
ac_fn_c_check_header_mongrel "$LINENO" "tiffio.h"
"ac_cv_header_tiffio_h" "$ac_includes_default"
if test "x$ac_cv_header_tiffio_h" = xyes; then :
cat >>confdefs.h <<_ACEOF
#define HAVE_TIFFIO_H 1
_ACEOF
From 3.3.0 on, it starts like this (with indentation adjusted):
if test "${use_libtiff}" = yes; then
mod=
## pkg-config support was introduced in libtiff 4.0.0
## I guess the module name might change in future, so
## program defensively here.
if "${PKGCONF}" --exists libtiff-4; then
mod=libtiff-4
fi
if test -n "${mod}"; then
save_CPPFLAGS=${CPPFLAGS}
TIF_CPPFLAGS=`"${PKGCONF}" --cflags ${mod}`
CPPFLAGS="${CPPFLAGS} ${TIF_CPPFLAGS}"
for ac_header in tiffio.h
do :
ac_fn_c_check_header_mongrel "$LINENO" "tiffio.h"
"ac_cv_header_tiffio_h" "$ac_includes_default"
if test "x$ac_cv_header_tiffio_h" = xyes; then :
cat >>confdefs.h <<_ACEOF
#define HAVE_TIFFIO_H 1
_ACEOF
And all the rest of the tests for libtiff are within the "if test -n
"${mod}"; then" branch. As I read it, this means that if you don't have
libtiff >= 4.0.0 installed, the tests for libtiff will not be run, and
support for TIFF disabled.
On the other hand, Appendix A.2 "Useful libraries and programs" in
https://cran.r-project.org/doc/manuals/r-release/R-admin.html says
"The bitmapped graphics devices jpeg(), png() and tiff() need the
appropriate headers and libraries installed: jpeg (version 6b or later,
or libjpeg-turbo) or libpng (version 1.2.7 or later) and zlib or libtiff
(any recent version – 3.9.[4-7] and 4.0.[2-10] have been tested)
respectively."
which seems to imply that libtiff 3.9.4 should be fine.
Is there a bug in the configure script, is the "R Installation and
Administration" not up to date, or is it me that misunderstands
something here?
--
Regards,
Bjørn-Helge Mevik
signature.asc
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pcre problems
On 25 February 2019 at 18:25, robin hankin wrote: | Hi there, ubuntu 18.04.2, trying to compile R-devel 3.6.0, svn 76155. | | I am having difficulty compiling R. I think I have pcre installed correctly: | | OK~/Downloads/R-devel pcretest -C | PCRE version 8.41 2017-07-05 | Compiled with | 8-bit support | UTF-8 support | No Unicode properties support | No just-in-time compiler support | Newline sequence is LF | \R matches all Unicode newlines | Internal link size = 2 | POSIX malloc threshold = 10 | Parentheses nest limit = 250 | Default match limit = 1000 | Default recursion depth limit = 1000 | Match recursion uses stack | OK~/Downloads/R-devel That is a front-end tool. I don't even have it installed :) | But ./configure gives me this: | | [snip] | checking for pcre.h... yes | checking pcre/pcre.h usability... no | checking pcre/pcre.h presence... no | checking for pcre/pcre.h... no | checking if PCRE version >= 8.20, < 10.0 and has UTF-8 support... no | checking whether PCRE support suffices... configure: error: pcre >= | 8.20 library and headers are required | OK~/Downloads/R-devel | | can anyone advise? Ensure you have the corresponding -dev package. My system is now at the current Ubuntu 18.10, not the Ubuntu LTS 18.04 you have -- but I have been building R-devel on it about once every week or other week for years: edd@rob:~$ COLUMNS=100 dpkg -l libpcre*dev | cut -c-100 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersionArchitecture Description +++-===-==-==-=== ii libpcre3-dev:amd64 2:8.39-11 amd64 Old Perl 5 Compatible Regular Expression Li edd@rob:~$ 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] Is libtiff >= 4.0.0 now required by R for TIFF support?
On Mon, Feb 25, 2019 at 11:11 AM Bjørn-Helge Mevik wrote: > > We recently discovered that since R 3.3.0, on our CentOS 6 based > cluster, R gets built without TIFF support. The last version where TIFF > support was built, was 3.2.5. It looks like the official R from EPEL6 also lacks tiff support: yum install epel-release yum install R-devel R -e 'capabilities()' > capabilities() jpeg pngtiff tcltk X11aqua TRUETRUE FALSETRUE FALSE FALSE http/ftp sockets libxmlfifo cledit iconv TRUETRUETRUETRUE FALSETRUE NLS profmem cairo ICU long.double libcurl TRUE FALSETRUETRUETRUETRUE So your hypothesis that autoconf doesn't find libtiff < 4 is probably correct. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.5.3 scheduled for March 11
Full schedule available on developer.r-project.org (pending auto-update from SVN) -- 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 __ 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] Bugzilla down?
Hi Martin (who I believe manages bz?) et al., I'm getting 503 Service Unavailable from bugzilla currently ( https://bugs.r-project.org/bugzilla/ and direct links to specific bugs, both). Is this a known issue? Thanks, ~G [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bugzilla down?
I do. The server ran out of disk earlier today and it seems that it killed bugzilla somehow. I'll have a look. Thanks, Simon > On Feb 25, 2019, at 2:07 PM, Gabriel Becker wrote: > > Hi Martin (who I believe manages bz?) et al., > > I'm getting 503 Service Unavailable from bugzilla currently ( > https://bugs.r-project.org/bugzilla/ and direct links to specific bugs, > both). Is this a known issue? > > Thanks, > ~G > > [[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] Bugzilla down?
Ok, fixed. Simon > On Feb 25, 2019, at 2:45 PM, Simon Urbanek > wrote: > > I do. The server ran out of disk earlier today and it seems that it killed > bugzilla somehow. I'll have a look. > Thanks, > Simon > > >> On Feb 25, 2019, at 2:07 PM, Gabriel Becker wrote: >> >> Hi Martin (who I believe manages bz?) et al., >> >> I'm getting 503 Service Unavailable from bugzilla currently ( >> https://bugs.r-project.org/bugzilla/ and direct links to specific bugs, >> both). Is this a known issue? >> >> Thanks, >> ~G >> >> [[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] Bugzilla down?
Ah, I was inferring from Martin being the one who generally makes new accounts for people afaik, sorry about that. Thanks for thr quick fix! ~G On Mon, Feb 25, 2019, 12:07 PM Simon Urbanek wrote: > Ok, fixed. > Simon > > > > > On Feb 25, 2019, at 2:45 PM, Simon Urbanek > wrote: > > > > I do. The server ran out of disk earlier today and it seems that it > killed bugzilla somehow. I'll have a look. > > Thanks, > > Simon > > > > > >> On Feb 25, 2019, at 2:07 PM, Gabriel Becker > wrote: > >> > >> Hi Martin (who I believe manages bz?) et al., > >> > >> I'm getting 503 Service Unavailable from bugzilla currently ( > >> https://bugs.r-project.org/bugzilla/ and direct links to specific bugs, > >> both). Is this a known issue? > >> > >> Thanks, > >> ~G > >> > >> [[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] bias issue in sample() (PR 17494)
Gabe
As mentioned on Twitter, I think the following behavior should be fixed
as part of the upcoming changes:
R.version.string
## [1] "R Under development (unstable) (2019-02-25 r76160)"
.Machine$double.digits
## [1] 53
set.seed(123)
RNGkind()
## [1] "Mersenne-Twister" "Inversion" "Rejection"
length(table(runif(1e6)))
## [1] 999863
I don't expect any collisions when using Mersenne-Twister to generate a
million floating point values. I'm not sure what causes this behavior,
but it's documented in ?Random:
"Do not rely on randomness of low-order bits from RNGs. Most of the
supplied uniform generators return 32-bit integer values that are
converted to doubles, so they take at most 2^32 distinct values and long
runs will return duplicated values (Wichmann-Hill is the exception, and
all give at least 30 varying bits.)"
The "Wichman-Hill" bit is interesting:
RNGkind("Wichmann-Hill")
length(table(runif(1e6)))
## [1] 100
length(table(runif(1e6)))
## [1] 100
Mersenne-Twister has a much much larger periodicity than Wichmann-Hill,
it would be great to see the above behavior also for Mersenne-Twister.
Thanks for considering.
Best regards
Kirill
On 20.02.19 08:01, Gabriel Becker wrote:
Luke,
I'm happy to help with this. Its great to see this get tackled (I've cc'ed
Kelli Ottoboni who helped flag this issue).
I can prepare a patch for the RNGkind related stuff and the doc update.
As for ???, what are your (and others') thoughts about the possibility of
a) a reproducibility API which takes either an R version (or maybe
alternatively a date) and sets the RNGkind to the default for that
version/date, and/or b) that sessionInfo be modified to capture (and
display) the RNGkind in effect.
Best,
~G
On Tue, Feb 19, 2019 at 11:52 AM Tierney, Luke
wrote:
Before the next release we really should to sort out the bias issue in
sample() reported by Ottoboni and Stark in
https://www.stat.berkeley.edu/~stark/Preprints/r-random-issues.pdf and
filed aa a bug report by Duncan Murdoch at
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17494.
Here are two examples of bad behavior through current R-devel:
set.seed(123)
m <- (2/5) * 2^32
x <- sample(m, 100, replace = TRUE)
table(x %% 2, x > m / 2)
##
##FALSE TRUE
## 0 300620 198792
## 1 200196 300392
table(sample(2/7 * 2^32, 100, replace = TRUE) %% 2)
##
## 0 1
## 429054 570946
I committed a modification to R_unif_index to address this by
generating random bits (blocks of 16) and rejection sampling, but for
now this is only enabled if the environment variable R_NEW_SAMPLE is
set before the first call.
Some things still needed:
- someone to look over the change and see if there are any issues
- adjustment of RNGkind to allowing the old behavior to be selected
- make the new behavior the default
- adjust documentation
- ???
Unfortunately I don't have enough free cycles to do this, but I can
help if someone else can take the lead.
There are two other places I found that might suffer from the same
issue, in walker_ProbSampleReplace (pointed out bu O & S) and in
src/nmath/wilcox.c. Both can be addressed by using R_unif_index. I
have done that for walker_ProbSampleReplace, but the wilcox change
might need adjusting to support the standalone math library and I
don't feel confident enough I'd get that right.
Best,
luke
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
