search for: pcre2

Hello, I experienced a compiler error when I tried to compile the latest version of R i.e. R4.0.2 making iosupport.d from iosupport.c making lapack.d from lapack.c making list.d from list.c making localecharset.d from localecharset.c grep.c(74): catastrophic error: cannot open source file "pcre2.h" # include<pcre2.h> (The pcre2.h header file is actually present!) I used the following compiler flags: # PCRE2: # ----- setenv CC gcc setenv CFLAGS " -O2 -fPIC " ./configure --prefix=/uufs/chpc.utah.edu/sys/installdir/pcre2/10.35 \ --enable-pcre2-16 --enable-...

? Wed, 1 Feb 2023 14:16:54 +1100 Michael Milton <ttmigueltt at gmail.com> ?????: > Is this a bug in the `dyn.load` implementation for R? If not, why is > it behaving like this? What should I do about it? On Unix-like systems, dyn.load forwards its arguments to dlopen(). It should be possible to confirm with a debugger that R passes RTLD_NOW to dlopen() when calling dyn.load(now =

...piler error when I tried to compile the latest version > of R i.e. R4.0.2 > making iosupport.d from iosupport.c > making lapack.d from lapack.c > making list.d from list.c > making localecharset.d from localecharset.c > grep.c(74): catastrophic error: cannot open source file "pcre2.h" > # include<pcre2.h> > (The pcre2.h header file is actually present!) > I used the following compiler flags: > # PCRE2: > # ----- > setenv CC gcc > setenv CFLAGS " -O2 -fPIC " > ./configure --prefix=/uufs/chpc.utah.edu/sys/installdir/pcre2/10.35 \...

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 pcre/pcre.h presence... no checking for pcre/pcre.h... no checking if PCRE1 version >= 8.32 and has U...

...bera wrote: > On 3/17/20 8:18 PM, Herv? Pag?s wrote: >> 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 pcre/pcre.h presence... no >> checking for p...

...erl = TRUE does *not* give the documented result on at least one >> system (which is "123456789", because "{,5}" is documented to not be >> a quantifier, so it should only match the literal string "{,5}"). This is a change in documented behavior in PCRE. PCRE2 10.43 (share/man/man3/pcre2pattern.3) says: "If the first number is omitted, the lower limit is taken as zero; in this case the upper limit must be present. X{,4} is interpreted as X{0,4}. In earlier versions such a sequence was not interpreted as a quantifier. Other regular expression en...

...el: posix Supported LTO compression algorithms: zlib zstd gcc version 11.4.1 20230605 (Red Hat 11.4.1-2) (GCC) I have been building R 4.4.0 and 4.4.1 with Flexiblas and with the built in R BLAS/LAPACK. R BLAS: ./configure --prefix=/tools/R/$RVER --enable-R-shlib --enable-memory-profiling --with-pcre2=/tools/pcre2/10.42 Flexiblas: PKG_CONFIG_PATH=/tools/flexiblas/3.4.2/lib64/pkgconfig ./configure --prefix=/tools/R/flexiblas/4.4.1 --enable-R-shlib --enable-memory-profiling --with-pcre2=/tools/pcre2/10.42 --with-blas="-lflexiblas -L/tools/flexiblas/3.4.2/lib64" --with-lapack I realis...

Thanks Tomas. Do note that my original post also mentioned a bug or doc error in the PCRE docs for this regexp: > - perl = TRUE does *not* give the documented result on at least one > system (which is "123456789", because "{,5}" is documented to not be a > quantifier, so it should only match the literal string "{,5}"). Duncan On 2024-08-01 6:49 a.m.,

Dear Miguel Esteva, I couldn't get a Red Hat "ubi9" container to install enough dependencies to build R. Is there a way to reproduce your setup on a virtual machine somewhere? On Fri, 3 May 2024 00:42:43 +0000 Miguel Esteva via R-help <r-help at r-project.org> wrote: > *** caught segfault *** > > address 0x1801fa8f70, cause 'memory not mapped' > >

On 3/17/20 8:18 PM, Herv? Pag?s wrote: > 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 pcre/pcre.h presence... no > checking for pcre/pcre.h... no > checki...

.../20 8:18 PM, Herv? Pag?s wrote: >>> 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 pcre/pcre.h presence... no...

...need for copying in some cases and should allow further optimizations in the future. It should help make the internal code easier to maintain. This change is expected to have almost no impact on packages using supported coding practices in their C/C++ code. MIGRATION TO PCRE2: * This version of R is built against the PCRE2 library for Perl-like regular expressions, if available. (On non-Windows platforms PCRE1 can optionally be used if PCRE2 is not available at build time.) The version of PCRE in use can be obtained _via_ extSoftVersion():...

...need for copying in some cases and should allow further optimizations in the future. It should help make the internal code easier to maintain. This change is expected to have almost no impact on packages using supported coding practices in their C/C++ code. MIGRATION TO PCRE2: * This version of R is built against the PCRE2 library for Perl-like regular expressions, if available. (On non-Windows platforms PCRE1 can optionally be used if PCRE2 is not available at build time.) The version of PCRE in use can be obtained _via_ extSoftVersion():...

...need for copying in some cases and should allow further optimizations in the future. It should help make the internal code easier to maintain. This change is expected to have almost no impact on packages using supported coding practices in their C/C++ code. MIGRATION TO PCRE2: * This version of R is built against the PCRE2 library for Perl-like regular expressions, if available. (On non-Windows platforms PCRE1 can optionally be used if PCRE2 is not available at build time.) The version of PCRE in use can be obtained _via_ extSoftVersion():...

...is means I've been misreading this line all along. My eyes zoomed in on "N exec/s" and I assumed that was the throughput (and I just ignored the "suffix" entry). So it's "cov X" / "bits Y" / "units Z" / "exec/s W" ? I guess the PCRE2 use case in the docs explains some of this -- I should've read this more closely. ... Aha, of course. > I run non-async-signal-safe code in the signal handler, bummer. > Let me try to fix this (no promises for a quick fix, I'll be out for a > while). > >> Ok, no proble...

...> In my (biased) opinion libFuzzer is particularly well suited for this task (fuzzing individual libraries, as opposed to fuzzing the whole postgress). I've played with a dozen of regular expression libs and found bugs in all of them (e.g. search for "Fuzzer" in http://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup&pathrev=360) >> To do this effectively I think it would be best to invoke the fuzzer >> from inside Postgres. > > Never tied this. Can't you just link libFuzzer with a part of the code you want to test? > Essentially provide binding...

...ue 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 #> attr(,"match.length") #> [1] 1 ``` Perhaps this change in behavior could be explained by R4.0's migration to PCRE2? Here is some relevant output from my R4.0 session: ``` > pcre_config() #> UTF-8 Unicode properties JIT stack #> TRUE TRUE TRUE FALSE ``` ``` > extSoftVersion() #> zlib bzlib xz PCRE #> "1.2.11"...

...hether the range expression is valid, or on the set of collating elements matched. A range expression shall be expressed as the starting point and the ending point separated by a <hyphen-minus> ( '-' )." If you really want to know why the current implementation of R, TRE and PCRE2 works in a certain way, you can check the code, but I don't think it would be a good use of the time given what is written above. It may be that TRE has a bug, maybe it doesn't do what was intended (see comment "XXX - Should use collation order instead of encoding values in charact...

...-w64-clang-aarch64-mlir 16.0.5-1 mingw-w64-clang-aarch64-nettle 3.9.1-1 mingw-w64-clang-aarch64-nghttp2 1.55.1-1 mingw-w64-clang-aarch64-openblas 0.3.23-1 mingw-w64-clang-aarch64-openmp 16.0.5-1 mingw-w64-clang-aarch64-openssl 3.1.2-1 mingw-w64-clang-aarch64-p11-kit 0.25.0-1 mingw-w64-clang-aarch64-pcre2 10.42-1 mingw-w64-clang-aarch64-readline 8.2.001-6 mingw-w64-clang-aarch64-rtmpdump 2.4.r99.f1b83c1-1 mingw-w64-clang-aarch64-tcl 8.6.12-2 mingw-w64-clang-aarch64-termcap 1.3.1-6 mingw-w64-clang-aarch64-tk 8.6.12-2 mingw-w64-clang-aarch64-wineditline 2.206-1 mingw-w64-clang-aarch64-winpthreads-git...

The following code: res <- gsub("(*UCP)\\b(i)\\b", "", "nhgrimelanomaclass", perl = TRUE) results in: Error in gsub(sprintf("(*UCP)\\b(%s)\\b", "i"), "", "nhgrimelanomaclass", : invalid regular expression '(*UCP)\b(i)\b' In addition: Warning message: In gsub(sprintf("(*UCP)\\b(%s)\\b",