On Fri, Jan 02, 2009, Jeff Johnson wrote:
> On Jan 2, 2009, at 4:46 AM, Ralf S. Engelschall wrote:
>>
>> # STEP 2: Assemble <E,V,R,D> tuple from regex parts
>> # <E,V,R,D> case 1: case 2: case 3: case 4: case 5: case
>> 6:
>> # X:X-X:X X:X-X X:X X: X-X X
>> %evr_tuple_select 2357 237_ 23__ 2___ _23_ __5_
>
> This macro determines the mapping from sub-patterns to the tuple
> {E,V,R,D}.
Right.
> The scatter/gather operation in the mapping is necessary for more
> general support than what is currently implemented, where E=1, V=2,
> R=3, D=4 is assumed.
This I don't quite understand, I think. The idea is that the
%evr_tuple_select contains one or more four-character strings. Each
string's character represents one element of tuple <E,V,R,D> (and
in this order!). The character is either "1".."9" (meaning that the
capturing parenthesis with the same number should be used to derive
the value) or "_" (meaning that the corresponding element of the tuple
should be set to undefined (or NULL in C). The program has to walk
through the %evr_tuple_select strings. The first string where _not
a single_ "1"..."9" reference results in an empty/undefined result
(meaning the regex capturing parenthesis really matched) stops the whole
selection process.
AFAIK this scheme is fully generic. It allows an arbitrary complex regex
(to match whatever EVRD syntax we want) and still allows us to create
the <E,V,R,D> tuple from it. So, what "more general support" do you
think of, Jeff?
> But perhaps an alternative syntax, using the implicit position to hide
> the sub-pattern index, and having an explicit (and opaque, there's
> nothing particularly holy about "E", "V", "R", and "D" tokens as long
> as the same characters appear in the %evr_tuple_order precedence
> permutation) single character identifier for a sub-pattern match.
>
> Here's an explicit example, permutations, like daylight savings time,
> is difficult to discuss unambiguously (implicit positional example based
> on 1 rather than 0 as first index):
>
> # STEP 2: Assemble <E,V,R,D> tuple from regex parts
> # <E,V,R,D> case 1: case 2: case 3: case 4: case 5: case
> 6:
> # X:X-X:X X:X-X X:X X: X-X X
> %evr_tuple_select _EV_R_D _EV___R _EV_____ _E_____ __VR___
> __V____
This I do not understand. Your %evr_tuple_select strings are 7
characters long but your tuple still seems to be just a 4-element tuple
<E,V,R,D>. Why? What are you trying to achieve. It is still not clear to
me.
> Hmmm, case 5 "_23_" might be incorrect, I would have naively expected
> "E" in position 2. Not looked (you likely have), will check and
> correct.
Ah, yes, you're right. Here is the fixed version:
# STEP 1: Match the string and capture regex parts
# 2 3 5 7
# X ":" X "-"X ":"X
%evr_tuple_match ^(([^:-]+):)?([^:-]+)(-([^:-]+))?(:([^:-]+))?$
# STEP 2: Assemble <E,V,R,D> tuple from regex parts
# <E,V,R,D> case 1: case 2: case 3: case 4: case 5: case 6:
# X:X-X:X X:X-X X:X X: X-X X
%evr_tuple_select 2357 235_ 23__ 2___ _35_ __5_
# STEP 3: Configure the comparison order of the <E,V,R,D> tuple elements
%evr_tuple_order EVRD
> There's also a (possible) ambiguity in case 3 "X:X" or a missing case 7
> candidate as "X::X". yawn ...
Yes, "X:X" is actually "E:V", the "X::X" for "E::D" (if this is wished
by you to be supported) then has to be case 7. Here it is:
# STEP 1: Match the string and capture regex parts
# 2 3 5 7
# X ":" X "-"X ":"X
%evr_tuple_match ^(([^:-]+):)?([^:-]+)(-([^:-]+))?(:([^:-]+))?$
# STEP 2: Assemble <E,V,R,D> tuple from regex parts
# <E,V,R,D> case 1: case 2: case 3: case 4: case 5: case 6:
case 7:
# X:X-X:X X:X-X X:X X: X-X X X::X
%evr_tuple_select 2357 235_ 23__ 2___ _35_ __5_ 2__7
# STEP 3: Configure the comparison order of the <E,V,R,D> tuple elements
%evr_tuple_order EVRD
This is now the non-PCRE, case-5-fixed and case-7-added version.
Please take this one now...
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
