similar to: gsub with perl=TRUE results in 'this version of PCRE is not compiled with Unicode property support' in R-devel

Why are you reporting that your PCRE library does not have something which the R-admin manual says it should preferably have? To wit, footnote 37 says 'and not PCRE2, which started at version 10.0. PCRE must be built with UTF-8 support (not the default) and support for Unicode properties is assumed by some R packages. Neither are tested by configure. JIT support is desirable.' That

On 7/24/23 4:10 AM, Duncan Murdoch wrote: > On 23/07/2023 9:01 p.m., Brodie Gaslam wrote: >> >> >> On 7/23/23 4:29 PM, Duncan Murdoch wrote: >>> The help page for `?gsub` says (in the context of performance >>> considerations): >>> >>> >>> "... just one UTF-8 string will force all the matching to be done in >>>

R CMD build fails with recent R-devel because it is looking for texi2dvi in /usr/local/bin, but on this system, MacTex has installed it in /usr/bin. $ R CMD build IRanges * checking for file 'IRanges/DESCRIPTION' ... OK * preparing 'IRanges': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to build vignettes * creating vignettes ... ERROR

I am seeing very strange behaviour in R 3.2.0 patched (r68272) and a new build of R-devel. The sessioninfo() from the former is below. Here's what I see: If I set the locale, and trigger a namespace load, a version comparison gives NA, and I get an error. For example, in a new session started with R --vanilla from the terminal: > Sys.setlocale(locale='en_US.UTF-8');grid::gpar()

The help page for `?gsub` says (in the context of performance considerations): "... just one UTF-8 string will force all the matching to be done in Unicode" However, this thread on SO: https://stackoverflow.com/q/76749529 gives some indication that this is not true for `perl = TRUE`. Specifically: > strings <- c("89 562", "John Smith", "???????

On 07/06/2015 9:14 PM, Dirk Eddelbuettel wrote: > > On 7 June 2015 at 20:46, Duncan Murdoch wrote: > | I am seeing very strange behaviour in R 3.2.0 patched (r68272) and a new > | build of R-devel. The sessioninfo() from the former is below. > | > | Here's what I see: If I set the locale, and trigger a namespace load, a > | version comparison gives NA, and I get an

On 05/24/2015 06:58 AM, Ilia Mirkin wrote: > nv30_validate_clip depends on the rasterizer state. Also we should > upload all the new clip planes on change since next time the plane data > won't have changed, but the enables might. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > src/gallium/drivers/nouveau/nv30/nv30_state_validate.c | 16

Hi everyone, I've noticed new behavior in `regexpr(..., perl = TRUE)` on Windows with R4.0 and above with Unicode characters. Here's a minimal example where I'd expect to see a start value of `5` (as R 3.6.2 and below gives), but R 4.0.0 (and R 4.0.1) now returns: ``` > regexpr("b", "foo\U0001F937bar", perl = TRUE) #> [1] 6 #>

> On 24 May 2015, at 16:03, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > > On 24.05.2015 10:38, Samuel Pitoiset wrote: >> >> >> On 05/24/2015 06:58 AM, Ilia Mirkin wrote: >>> nv30_validate_clip depends on the rasterizer state. Also we should >>> upload all the new clip planes on change since next time the

Using --with-pcre1 to configure the latest R 4.0 (revision 77988) on an Ubuntu 14.04.5 LTS system gives me the following error: ... checking if lzma version >= 5.0.3... yes checking for pcre2-config... no checking for pcre_fullinfo in -lpcre... yes checking pcre.h usability... yes checking pcre.h presence... yes checking for pcre.h... yes checking pcre/pcre.h usability... no checking

Thanks Tomas. Any chance the old version of the error message could be restored? It would definitely be more helpful than the current one. It's confusing to get an error and be told to use --with-pcre1 when you're already using it. H. On 3/18/20 01:08, Tomas Kalibera wrote: > On 3/17/20 8:18 PM, Herv? Pag?s wrote: >> Using --with-pcre1 to configure the latest R 4.0 (revision

On Sun, May 24, 2015 at 10:56 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 24.05.2015 16:15, Pierre Moreau wrote: >>> >>> On 24 May 2015, at 16:03, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>> >>> >>> >>> On 24.05.2015 10:38, Samuel Pitoiset wrote:

Hello, I downloaded R-3.6.0.tar.gz from https://cran.r-project.org/src/base/R-3/. I tried to install R-3.6.0.tar.gz in Ubuntu system. Thanks in advance for any help! yue 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

Since yesterday's r69662, R no longer ./configure[s] on a standard Ubuntu 14.04.3 installation, which ships with PCRE 8.31 (http://packages.ubuntu.com/trusty-updates/libpcre3-dev) I get: > checking if PCRE version >= 8.32, < 10.0 and has UTF-8 support... no > checking whether PCRE support suffices... configure: error: pcre library and headers are required Are there any

Hello, Got some at the time surprising errors some days ago when building a local r-devel installation on a cluster, with apparent outdated or missing dev versions of some files. After reading the r-devel news ( https://developer.r-project.org/blosxom.cgi/R-devel/NEWS), it turned out that " Use of the included versions of ?zlib?, ?bzlib?, ?xz? and PCRE is deprecated: these are frozen and

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

I have the same problem, trying to cross-compile. I'm running Ubuntu Edgy, kernel 2.6.17-10-generic, on an IBM T60. I downloaded the Makefile from CRAN and ran make CrossCompileBuild with the following error messages (also ran each make one at the time and the problem occurs in make R): ../extra/pcre/libpcre.a(pcre_dfa_exec.o):pcre_dfa_exec.c:(.text+0x1703): undefined reference to

What are your opinions on pcre vs regexp for header_, body_, and mime_checks in Postfix? I looked at the regexp_table and prce_table man pages, and see almost no difference other than the available flags. Miark

On Wed, Aug 02, 2017 at 12:33:14PM +0200, Pino Toscano wrote: > Hi, > > (replying here since v2 of the series does not have this explanation.) > > On Tuesday, 1 August 2017 16:00:15 CEST Richard W.M. Jones wrote: > > We'd like to use PCRE instead of the awful Str module. However I > > don't necessarily want to pull in the extra dependency of ocaml-pcre, >

thanks for this guys. I only compiled pcre myself as a last resort, because of the ./configure failure. But AFAICS apt-get reports correct installation: OK~/Downloads/R-devel sudo apt-get install r-base-dev Reading package lists... Done Building dependency tree Reading state information... Done r-base-dev is already the newest version (3.5.2-1cosmic). 0 upgraded, 0 newly installed, 0 to