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

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

...XFLAGS="-g -O3 -mp" SHLIB_CXXLD=icpc export MKL_INTERFACE_LAYER=GNU,LP64 export MKL_THREADING_LAYER=GNU ./configure --prefix=/opt/intel-2021.6.0/R/4.3.1 --with-blas="$MKL" --with-lapack --enable-memory-profiling --enable-BLAS-shlib --enable-R-shlib --enable-R-static-lib --with-pcre2 Thanks a lot, Giuseppe. ??????????????????????????????????????? Giuseppe Cal? Fondazione CMCC Centro Euro-Mediterraneo sui Cambiamenti Climatici presso Complesso Ecotekne Universit? del Salento - Strada Prov.le Lecce - Monteroni 73100 Lecce IT http://www.cmcc.it <http://www.cmcc.it/> htt...

...mmended-packages 5. Interestingly, this picks up OpenBLAS: configure: searching for an external BLAS configure: searching for BLAS in default libraries checking for dgemm_... no configure: searching for OpenBLAS and R is now configured for x86_64-pc-linux-gnu (...) External libraries: pcre2, readline, BLAS(OpenBLAS), LAPACK(in blas), curl Options enabled: shared R library, R profiling (...) Options not enabled: shared BLAS, memory profiling 6. After make is finished, ldd: libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f01b1ac2000) libatlas.so.3...

...ult might occur in a worker process when using HTTP/2 without SSL; the bug had appeared in 1.25.1. *) Bugfix: the "Status" backend response header line with an empty reason phrase was handled incorrectly. *) Bugfix: memory leak during reconfiguration when using the PCRE2 library. Thanks to ZhenZhong Wu. *) Bugfixes and improvements in HTTP/3. -- Maxim Dounin http://nginx.org/

...ог произойти segmentation fault; ошибка появилась в 1.25.1. *) Исправление: строка "Status" в заголовке ответа бэкенда с пустой поясняющей фразой обрабатывалась некорректно. *) Исправление: утечки памяти во время переконфигурации при использовании библиотеки PCRE2. Спасибо ZhenZhong Wu. *) Исправления и улучшения в HTTP/3. -- Maxim Dounin http://nginx.org/