Re: [pcre-dev] PLEASE NOTE: PCRE2 infrastructure has moved

How do I subscribe to the mailing? Ze'ev Atlas On Sunday, August 22, 2021, 12:11:45 PM EDT, Philip Hazel via Pcre-dev wrote: As per recent postings on this list, the PCRE2 infrastructure has moved, though not quite as previously described, and I still have to tidy up some loose

Re: [pcre-dev] [Bug 2792] \K should not be allowed in lookarounds

We had had a similar discussion a few years back, where I stated that a certain usage is wrong and you answered that changing PCRE will break a few patterns who may rely on the wrong usage.  In the end you've adopted my view after I'd asked to allow me an exception in the z/OS EBCDIC specific

Re: [pcre-dev] [Bug 547] full regular expression support inside lookbehind

Many on the internet suggest emulating variable length lookbehind by using lookaheads (see for example Dr. Regex: Variable-Length Lookbehinds: actually possible in Perl/PCRE!).  Is it possible to implement such a solution by doing the conversion internally? Ze'ev Atlas On Tuesday, January

Re: [pcre-dev] generating ./testdata/testbtables

Thank you Sent from Yahoo Mail on Android On Sun, Nov 29, 2020 at 10:54 AM, Philip Hazel wrote: Use the -b option of dftables. There is some documentation in the pcre2build  document. I implemented this for a user who wanted to ensure identical tables across a number of different

[pcre-dev] generating ./testdata/testbtables

Good Morning PhilAs it is now, the ./testdata/testbtables is a part of the distribution.  Is it possible to compile it from source code using  pcre2_dftables.c.  What would be the parameters and options to build it? Ze'ev Atlas -- ## List details at

Re: [pcre-dev] PCRE2 10.35 testing issues on Windows

Well, the problem is clearly in testinput2 rather than in the program.  I did not see it as I, sort of, expected testinput2 to fail and relied more on my EBCDIC oriented subset of testinput2 (which does not contain #loadtables.)  I will address that issue in the next version (10.36,) but in any

Re: [pcre-dev] Preparation for using JIT under S390

with no corporation sponsors, and have a day job, I had to abandon the effort for now.  Is it possible to contact IBM and have them look at the matter, please.   Ze'ev Atlas On Saturday, November 14, 2020, 06:44:45 PM EST, Ze'ev Atlas via Pcre-dev wrote: Good morningI am aware

Re: [pcre-dev] PCRE2 10.35 testing issues on Windows

Hi PhilI see that this involved an open file command which means that you have to supply the filename, potentially fully qualified filename.  That brings a few questions: 1. Why should the onus of fixing this be on you rather than on the user, who should supply a fully qualified file name? 2.

Re: [pcre-dev] Compile errors

Good day Zoltan  I have contemplated on what has been said in that thread and also looked at the code.   It looks to me that if I would develop a native z/OS allocator and plug it instead of the allocators that are there, everything would compile properly.  I believe that there is nothing Linux

Re: [pcre-dev] Compile errors

.  Without the basic IBM z/OS or z/VM you cannot run Linux. Ze'ev Atlas On Sunday, November 15, 2020, 08:47:54 AM EST, Ze'ev Atlas via Pcre-dev wrote: It looks like we have to determine which allocator is the closest to what I need and put a hook, using the NATIVE_ZOS macro and allow me

Re: [pcre-dev] Compile errors

to develop it. Ze'ev Atlas On Sunday, November 15, 2020, 12:20:26 AM EST, Ze'ev Atlas via Pcre-dev wrote: Hi all I would like to reiterate: I do not use Linux and I do not use gcc.  Rather I am using IBM native C compiler, so anything that is gcc specific or Linux specific is a show

[pcre-dev] Compile errors

Hi all I would like to reiterate: I do not use Linux and I do not use gcc.  Rather I am using IBM native C compiler, so anything that is gcc specific or Linux specific is a show stopper. Please review the attached snippets and provide some advice   Ze'ev Atlas errors compiling

[pcre-dev] Preparation for using JIT under S390

Good morningI am aware that the JIT under S390 (IBM mainframe) is experimental.  However, I am one of the main interested parties as I maintain the port for z/OS.  Which is currently the only port that successfully run on S390.  I would like to begin testing the JIT version in my port.  I won't

Re: [pcre-dev] [Bug 2635] Port PCRE2 JIT to Linux on IBMz (s390x)

at the time it was not available for the hardware.  I ask, if possible that the JIT should also not assume any Unix/Linux specific kernel.  I really want and hope to embellish my port with JIT option Ze'ev Atlas On Monday, August 24, 2020, 08:58:41 AM EDT, Ze'ev Atlas via Pcre-dev wrote

Re: [pcre-dev] [Bug 2635] Port PCRE2 JIT to Linux on IBMz (s390x)

I've just downloaded the PoO. it is SA22-7832-12, published on 2019. It is a massive 16MB, 2000 pagesYou need to register with IBM, go to z/Architecture Principles of Operationregister (it's free) and you will get the access Ze'ev Atlas On Monday, August 24, 2020, 09:32:21 AM EDT,

Re: [pcre-dev] [Bug 2635] Port PCRE2 JIT to Linux on IBMz (s390x)

Th z Series of IBM does have SIMD commandsPlease look at this publication as a starting point:  https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf https://www.ibm.com/downloads/cas/WVPALM0N A key publication: 

Re: [pcre-dev] [Bug 2635] New: Port PCRE2 JIT to Linux on IBMz (s390x)

It is not clear who has initiated this wish.Few years back, when I ported the interpreted version of PCRE to classic z/OS, Zoltan wanted to develop JIT version for the IBM mainframe.  At the time, both Phil and I had discouraged it due to the proprietary nature of that platform.  If anybody

[pcre-dev] PCRE2 10.35 with LE and Rexx API is available

Hi AllPCRE2 10.35 with LE and Rexx API is available in CBTTAPE.org, file939 Please try the Rexx API which really is simple and smooth and bring Regular Expressions to TSO-Rexx Ze'ev Atlas -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

Re: [pcre-dev] Problems and questions about locales

As Phil had mentioned, this is a locale vs. Unicode issue.  My port to z/OS (and thus EBCDIC) deals with such issues as there are many loacales in EBCDIC.  I use iconv (the IBM version) to convert between various locals and developed a whole API to help handle this.  It is available in EBCDIC

[pcre-dev] PCRE2 for z/OS version 10.34a (interim release)

I've just published version 10.34a of PCRE2 (Perl Compatible Regular Expressions)  for z/OS.  This is an interim release, while there is no change in the core library, we've introduced the 'substitute' functionality into the Rexx API. The distribution is available on file939 of the CBTTAPE.org

Re: [pcre-dev] PCRE2 (Perl Compatible Regular Expressions) for z/OS 10.34 is available

I've just published version 10.34 of PCRE2 (Perl Compatible Regular Expressions)  for z/OS. The distribution is available on file939 of the CBTTAPE.org (currently, in the 'UPDATE' page)  http://cbttape.org/ftp/updates/CBT939.zip) and eventually will move to the main page ( 

Re: [pcre-dev] New header file location

I checked and basically had finalized my port.You were correct and the jit modules are in the correct place (i.e. /src) ... and technically, despite the fact that I do not use them, I need their presence since you mention them in some #include statements.The only modules that I really really do

Re: [pcre-dev] New header file location

I can, as I had said, handle the unnecessary files in my process.  Please do not move thwm to a new directoryZe'ev Sent from Yahoo Mail on Android On Mon, Dec 2, 2019 at 11:30 AM, p...@hermes.cam.ac.uk wrote: On Mon, 2 Dec 2019, Ze'ev Atlas wrote: > When I started, Philip had assured me

Re: [pcre-dev] New header file location

When I started, Philip had assured me that pcre2_jit_compile.c is indeed in src but does nothing in my context.  He had also assired me that most of the rest of jit related code would be in src/sljit.  I do not understand why the change of heart.  These headers are not needed when we compile

[pcre-dev] New header file location

I have noticed that pcre2_jit_neon_inc.h and pcre2_jit_simd_inc.h are now in .../src and not in .../src/sljit where they should be.   I use the location of source file to discern whether I need them (even remotely) for my strictly non-jit port for z/OS.  These aforementioned header files are

[pcre-dev] PCRE2 (Perl Compatible Regular Expressions) for z/OS 10.33 is available

I've just published version 10.33 of PCRE2 (Perl Compatible Regular Expressions)  for z/OS.The distribution is available on file939 of the CBTTAPE.org (currently, in the 'UPDATE' page)  http://cbttape.org/ftp/updates/CBT939.zip and eventually will move to the main page

Re: [pcre-dev] [Bug 1830] pcre2posix defines the same names as POSIX

Please consider my less than popular port to classic z/OS.I had a similar problem, and neither I, nor my users, have any control on which actual runtime module would yake precedence.  I resorted to name the pcre2 functions differently than the native posix function names.  It was refreshing to

Re: [pcre-dev] [Bug 1830] pcre2posix defines the same names as POSIX

This sounds good as I had similar issue with porting to z/OS.  I will try to use that instead of my proprietary solution.  Will work on it for the next release. Ze'ev Sent from Yahoo Mail on Android On Wed, Jan 23, 2019 at 8:18 AM, ad...@bugs.exim.org wrote:

Re: [pcre-dev] [Bug 2365] New: check_wordboundary does not explicitly set zero flag

Hello MikeAre you aware that there is a current implementation of the non-jit version for IBM Z series.  I obviously support your efforts to do a jit version.  I am the maintainer of that stuff and would like to work with you so I couldA.  Share with you my experienceB. Coordinate between the

[pcre-dev] PCRE2 10.32 for z/OS is now available.

PCRE2 10.32 for z/OS is now available.  This is a bugfix release.  Note that there is a bugfix also in the Assembler part (i.e. the C14.MACLIB and PCRE2.ASM libraries) pertaining to the REXX API.It is available in the usual place, file 939 on CBTTAPE.ORG Ze'ev Atlas -- ## List details at

Re: [pcre-dev] Unknown C construct

In essence, a non-standard feature is introduced!I could eliminate the offending code with my porting scripts and replace them with standard external macro/value with the equivalent of[code]Dmacro…[/code]But I like to keep intervention in the source code into the absolute minimum. Ze'ev Atlas

[pcre-dev] Unknown C construct

This is NOT a bug per se, but my C compiler does not really recognize this construct /* For the benefit of systems without stdint.h, an alternative is to use inttypes.h. The existence of these headers is checked by configure or CMake. */#define PCRE2_HAVE_STDINT_H   @PCRE2_HAVE_STDINT_H@ #define

Re: [pcre-dev] memmove() vs. bcopy()

Sent from Yahoo Mail on Android On Fri, Aug 10, 2018 at 5:20 PM, Daniel Richard G. wrote: On Fri, 2018 Aug 10 17:36+0100, p...@hermes.cam.ac.uk wrote: > Now the emulation is in a private library function, and both pcre2test > and pcre2grep have their own static versions. It all seems

Re: [pcre-dev] Serialization format versioning

PhilIt might be a good idea to add some id in the serialized object that stores the PCRE2 version and than, any subsequent version would be able to decide whether it is compatible or not. Ze'ev Atlas On Friday, June 22, 2018, 4:12:27 PM EDT, Daniel Richard G. wrote: On Fri, 2018 Jun

[pcre-dev] Announcing PCRE2 10.31 for z/OS

I have just released PCRE2 10.31 for z/OS.  It is in the usual place - file939 in CBTTAPE.ORG.  Currently it is in the updates page. Ze'ev Atlas -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

Re: [pcre-dev] Support for invalid UTF-8 strings?

If you want to hide the gory details from the user then you may provide two methods with similar signatures.  One would handle known valid utf-8 strings and the other would handle suspected strings.  The first one would go straight to PCRE2 and the other would do the suggested verification and

Re: [pcre-dev] [Bug 2245] new operators request for beginning and end of file

Perhaps he is talking about pcre2test or pcre2grep and want to anchor the match to the first or last line where the whole file is viewed as one unit... one huge stringZe'ev Sent from Yahoo Mail on Android On Thu, Feb 22, 2018 at 1:22 PM, ad...@bugs.exim.org wrote:

[pcre-dev] PCRE2 for z/OS 10.30 plus REXX API

Announcing PCRE2 for z/OS 10.30 with REXX API I've just sent to the CBT (file 939) a new interim release of PCRE2 for z/OS 10.30 .  It is the same as the latest PCRE for z/OS 10.30, but with the addition of 1. comprehensive and workable REXX API, contributed by John Gateley2. Support (almost

Re: [pcre-dev] Non-capturing group overhead (100x)

Couldn't we recognize (?:.*) as what it really is, i.e .* ZA Sent from Yahoo Mail on Android On Tue, Dec 5, 2017 at 4:56 AM, p...@hermes.cam.ac.uk wrote: On Tue, 5 Dec 2017, Zoltán Herczeg wrote: > do you use JIT? > > The engine has special single character

Re: [pcre-dev] EBCDIC many faces

You gave me some ideas and directions to look atthank you Ze'ev Atlas From: "p...@hermes.cam.ac.uk" wrote I'm not sure I can help without knowing more about what kind of API you are defining. The ovector in the standard API is provided by the user as part of the

Re: [pcre-dev] EBCDIC many faces

Good Morning Phil I need an adviceIn designing the conversion between EBCDIC code pages for PCRE2 I decided to make the API as simple as possible for the user and reduce overhead as much as possible.  I am asking the user for example to tell me what is the estimated max length of the pattern

Re: [pcre-dev] EBCDIC many faces

I guess that supply a conversion function (and API for non C users) is my only option... yes the second option is too much maintenanceOnce fully recovered I will work on it Ze'ev Atlas From: "p...@hermes.cam.ac.uk" To: Ze'ev Atlas Cc: Pcre

Re: [pcre-dev] EBCDIC many faces

I am weighing my next step after realizing that the special characters for pattern cannot really change in runtime while being the most abused by IBM. IBM supplys a set of function that allow me to convert the input (string and pattern) from whatever EBCDIC codepage to the desired one.  But in

[pcre-dev] EBCDIC many faces

PhilI have encountered this issue.  IBM did really bad job in creating the EBCDIC, especially as far as pattern matching is concerned.  When they adapted EBCDIC to various languages they moved these symbols around like a whirpool.  For example square bracket occupies 3 different possitions in 3

[pcre-dev] PCRE2 10.30 released on CBTTAPE (file 939)

A new version of the PCRE2 regex engine for z/OS was released and would be posted on CBTTAPE (file 939) soon.  1. The main interpreter, pcre2_match(), has been refactored into a    new version that does not use recursive function calls (and    therefore the stack) for remembering backtracking

Re: [pcre-dev] [PATCH] Fix real_pcre and real_pcre16 struct declarations in pcre.h.in

Important for classic z/OS.  Is that patch committed alreadyZA Sent from Yahoo Mail on Android On Fri, Aug 18, 2017 at 1:54 PM, Evgeny Kotkov wrote: Hi all, This patch fixes two outdated declarations in the pcre.h.in file. This file eventually becomes

Re: [pcre-dev] PCRE1 8.41 released

The link for the z/OS version, that resides on cbttape.org is now correct.  I am looking forward to upgrade to 10.30Thank youZe'ev Atlas Sent from Yahoo Mail on Android On Wed, Jul 19, 2017 at 8:37 PM, Andrew Ho wrote: Hello, I updated the z/OS link to point at the

Re: [pcre-dev] PCRE1 8.41 released

Could you please update the page about the z/OS availability to point to the correct link: A PCRE port for z/OS, a mainframe operating system which uses EBCDIC as its default character encoding, can be found here: http://www.cbttape.org/ (File 939) File 882 is for PCRE1 and is not maintained

[pcre-dev] Fw: [Bug 2106] Please add support for parsing POSIX basic & extended regular expressions

I have checked my solution and it is somewhat relevant for the question as asked.  As I've mentioned, I'd struggled with the same issue.  In the z/OS environment I am not required to provide both POSIX and PCRE at the same time.   Also, for technical reasons I have to supply short name (8

Re: [pcre-dev] [Bug 2106] Please add support for parsing POSIX basic & extended regular expressions

I have had a similar problem in my port to z/OS.I am not near my computer but I will try to share my solution tonightZA Sent from Yahoo Mail on Android On Wed, May 17, 2017 at 1:20 PM, ad...@bugs.exim.org wrote: https://bugs.exim.org/show_bug.cgi?id=2106 --- Comment

[pcre-dev] PCRE2 10.23 released on CBTTAPE (file 939)

A new version of the PCRE2 regex engine for z/OS was released and would be posted on CBTTAPE (file 939) soon.  New in this release is Rexx API.  It is implemented as a Rexx function, written in Assembler by John Gateley.  It accepts basic regular expressions and some minimal options and

Re: [pcre-dev] supplying modifiers

Thank you, I've realized it after digging in the documentation farther.  It was the g modifier that threw me off, but now the g is actually implemented and seem to work fine.  We will publish the z/OS Rexx interface in conjunction with the next PCRE2 releaseZeev Atlas Sent from Yahoo Mail on

[pcre-dev] supplying modifiers

Hi PhilWe are preparing an interface for the Rexx language on z/OS.  I was looking for a way to supply the g, x, i modifiers. I cannot find a way to supply such modifiers external to the pattern (I know how to do it within the pattern).  Could you guide me where to look. Thank youZe'ev Atlas

Re: [pcre-dev] named pattern question

Thank you Sent from Yahoo Mail on Android On Sun, Feb 5, 2017 at 11:32 AM, p...@hermes.cam.ac.uk wrote: On Sun, 5 Feb 2017, Ze'ev Atlas wrote: > On the testinput2 file, there is a pattern/(?a|b|c)\g*/ > Trying the same pattern in Perl (5.20 on Windows) generates