Thank you, with the fix the test cases run flawlessly:
F:\work\svn\oorexx\incubator\regex>rexx Parser.testGroup
Interpreter: REXX-ooRexx_5.0.0(MT)_32-bit 6.05 4 May 2020
OS Name: WindowsNT
SysVersion: Windows 10.0.18363
Tests ran: 9
Assertions: 674
Failures: 0
Errors: 0
Test execution: 00:00:00.015000
F:\work\svn\oorexx\incubator\regex>rexx regex.testGroup
Interpreter: REXX-ooRexx_5.0.0(MT)_32-bit 6.05 4 May 2020
OS Name: WindowsNT
SysVersion: Windows 10.0.18363
Tests ran: 83
Assertions: 127908
Failures: 0
Errors: 0
Test execution: 00:00:02.962000
Will try to get an idea/overview, but will have to refresh the (Java) grep
rules first, and then try
to relate them to regex.cls by studying the test cases in the two testGroup
files, which are already
at an impressive amount of tests and assertions as one can see!
---rony
On 09.06.2020 13:54, Rony G. Flatscher wrote:
>
> Saw the update and ran the testGroups first which exhibit a problem in the
> testemail test:
>
> F:\work\svn\oorexx\incubator\regex>rexx Parser.testGroup
> Interpreter: REXX-ooRexx_5.0.0(MT)_32-bit 6.05 4 May 2020
> OS Name: WindowsNT
> SysVersion: Windows 10.0.18363
>
> Tests ran: 9
> Assertions: 674
> Failures: 0
> Errors: 0
>
> Test execution: 00:00:00.006000
>
>
> F:\work\svn\oorexx\incubator\regex>rexx regex.testGroup
> Interpreter: REXX-ooRexx_5.0.0(MT)_32-bit 6.05 4 May 2020
> OS Name: WindowsNT
> SysVersion: Windows 10.0.18363
>
> Tests ran: 83
> Assertions: 127904
> Failures: 0
> Errors: 2
>
> [error] 20200609 13:50:33.796000
> svn: runknown Change date: unknown
> Test: TESTEMAIL
> Class: regex.mutable.testGroup
> File: ...\oorexx\incubator\regex\regex.testGroup
> Event: [SYNTAX 97.1] raised unexpectedly.
> Object "a GroupMatchResult" does not understand message "MATCHTEXT".
> Program: ...\oorexx\incubator\regex\regex.cls
> Line: 2122
> 5233 *-* text = group~matchText
> 2122 *-* self~assertEquals("postmas...@oorexx.org", r[])
> *-* Compiled method "SEND" with scope "Message".
> 1561 *-* .message~new(self, methodName)~send
> 1536 *-* self~doTheTest(fName, aTestResult) -- carry out the testmethod
> 552 *-* test~execute(testResult, verbose)
> 552 *-* test~execute(testResult, verbose)
> 46 *-* testResult = group~suite~execute~~print
>
> [error] 20200609 13:50:34.925000
> svn: runknown Change date: unknown
> Test: TESTEMAIL
> Class: regex.testGroup
> File: ...\oorexx\incubator\regex\regex.testGroup
> Event: [SYNTAX 97.1] raised unexpectedly.
> Object "a GroupMatchResult" does not understand message "MATCHTEXT".
> Program: ...\oorexx\incubator\regex\regex.cls
> Line: 2122
> 5233 *-* text = group~matchText
> 2122 *-* self~assertEquals("postmas...@oorexx.org", r[])
> *-* Compiled method "SEND" with scope "Message".
> 1561 *-* .message~new(self, methodName)~send
> 1536 *-* self~doTheTest(fName, aTestResult) -- carry out the testmethod
> 552 *-* test~execute(testResult, verbose)
> 552 *-* test~execute(testResult, verbose)
> 46 *-* testResult = group~suite~execute~~print
>
> Test execution: 00:00:02.273000
>
> ---rony
>
>
> On 08.06.2020 14:24, Rick McGuire wrote:
>>
>>
>> On Mon, Jun 8, 2020 at 8:06 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at
>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> On 08.06.2020 13:39, Rick McGuire wrote:
>>> My incubator version has named captures, and also has a new feature
>>> I've not seen other
>>> regex packages, reusable named patterns. For example, one of the
>>> standard patterns is a
>>> URL: pattern that has named elements like protocol, port, domain name,
>>> etc. Rather than
>>> having to copy and paste one of these patterns into your own, you can
>>> refer to them by name.
>>> I'm a bit stalled on the design of user pattern libraries at the
>>> moment, but this is a
>>> very powerful concept.
>>>
>>> While a regex can be incorporated into the PARSE instruction, it would
>>> only be in a very
>>> simplistic way. My implementation has a parsing context class that
>>> supports everything the
>>> PARSE instruction does and quite a bit more beyond what PARSE can do.
>>
>> Went into incubator/regex and loaded the programs: *wow*!
>>
>> Overwhelming from the functionality that is there already (currently
>> there are 87 classes in
>> regex.cls)!!
>>
>> Would it be already possible to parse xml elements (supplying the tag
>> name and having the
>> parser parse everything to the matching end tag, independently whether
>> the tag name gets
>> recursively used) with a single pattern?
>>
>> If such a thing is possible with a regex, then it should be possible with
>> this version.
>>
>> What would you suggest to study first in order to understand what you
>> have created so far?
>>
>> No docs written for this at all. This was originally based on the Java
>> version, so it follows
>> that for most of the patterns. Probably the best place to start would be to
>> look at what the test
>> cases are doing.
>>
>> Rick
>>
>>
>>
>> ---rony
>>
>>
>>>
>>> On Mon, Jun 8, 2020 at 7:16 AM Rony G. Flatscher
>>> <rony.flatsc...@wu.ac.at
>>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>
>>> Just an interesting mail thread from a mainframe Rexx mailing list.
>>>
>>> Are there any ongoing projects in this area? I seem to remember
>>> that Rick started to
>>> work on a
>>> regular expression package with name captures, and independently,
>>> Erich mentioned to
>>> make the
>>> regular expression features of the latest C++ standard available
>>> (not sure whether there
>>> would be
>>> something like name captures available).
>>>
>>> There was an idea of incorporating such a feature also into the
>>> PARSE keyword statement,
>>> if some
>>> (human-oriented) easy syntax would be suggested for it (which is
>>> dependent on the
>>> feature-set
>>> implemented in such an extension library, of course, so a little
>>> bit of a chicken-egg
>>> problem there).
>>>
>>> ---rony
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: Re: PCRE2 10.35 for z/OS
>>> Date: 7 Jun 2020 07:05:37 -0700
>>> From: Paul Gilmartin <paulgboul...@aim.com
>>> <mailto:paulgboul...@aim.com>>
>>> Reply-To: TSO REXX Discussion List <tso-r...@vm.marist.edu
>>> <mailto:tso-r...@vm.marist.edu>>
>>> Organization: None
>>> Newsgroups: bit.listserv.tsorexx
>>> References: <1271218775.429747.1591498456491....@mail.yahoo.com
>>> <mailto:1271218775.429747.1591498456491....@mail.yahoo.com>>
>>> <1271218775.429747.1591498456...@mail.yahoo.com
>>> <mailto:1271218775.429747.1591498456...@mail.yahoo.com>>
>>>
>>> <bl0pr05mb5156c5ee0273a84de9f867f599...@bl0pr05mb5156.namprd05.prod.outlook.com
>>>
>>> <mailto:bl0pr05mb5156c5ee0273a84de9f867f599...@bl0pr05mb5156.namprd05.prod.outlook.com>>
>>>
>>> On 2020-06-07, at 04:56:19, Seymour J Metz wrote:
>>> >
>>> > For those not familiar with Perl, its regex syntax includes named
>>> captures, which
>>> properly used can make it much easier to write maintainable code.
>>> PCRE is much more
>>> powerful the the regexen in, e.g., oorexx.
>>> >
>>> Ooh! Sorta like SNOBOL4! Does the Rexx API provide named captures
>>> to Rexx variables (another case of quoting symbol names?)
>>>
>>> > ________________________________________
>>> > From: Ze'ev Atlas
>>> > Sent: Saturday, June 6, 2020 10:54 PM
>>> >
>>> > Hi AllI would like to encourage all of you to use the PCRE2
>>> library with the new and
>>> improved Rexx API. In some previous conversation somebody had
>>> mentioned the package (in
>>> a previous release and much more primitive state, and pointed to
>>> some issues. The
>>> current release is an up to date version and, basically, perfected
>>> the Rexx API. Again.
>>> please try it.As opposed to other mentioned products which are not
>>> Perl compatible, this
>>> one is Perl Compatible and Perl has the golden standard of Regular
>>> Expression usage.
>>> > Ze'ev Atlas
>>>
>>> -- gil
>>>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
