Skip Menu |

This queue is for tickets about the YAPE-Regex CPAN distribution.

Report information
The Basics
Id: 65042
Status: resolved
Priority: 0/
Queue: YAPE-Regex

People
Owner: Nobody in particular
Requestors: smueller [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 3.04
Fixed in: 4.00



Subject: Compatibility with the upcoming perl 5.14
Hi Jeff, I know YAPE::Regex is deprecated in favour of Regexp::Parser, but there is real-world code depending on YAPE::Regex, so it would be great if you could update it to support Perl 5.14. There are several changes to the regex engine, but the only one that I know of to break YAPE::Regex big time is that the default modifiers are now stringified to ^. The perl5136delta gives this example: The stringification of regular expressions now uses this notation. E.g., before, C<qr/hlagh/i> would be stringified as C<(?i-xsm:hlagh)>, but now it's stringified as C<(?^i:hlagh)>. The main purpose of this is to allow tests that rely on the stringification to not have to change when new modifiers are added. See L<perlre/Extended Patterns>. This means that the ^ will be VERY common even in old code that doesn't magically start using new features. This is why I think it would be very important to support it even in case YAPE::Regex doesn't support some other features of, say 5.10, the big regexp overhaul. I expect the necessary change to be small (for someone who understands the code base) and to be more of a special case hack than any kind of big modification. Any chance to get this done before 5.14 is released? If not, a lot of code using YAPE::Regex to parse regexes will simply not work on 5.14. Best regards, Steffen
Subject: Re: [rt.cpan.org #65042] Compatibility with the upcoming perl 5.14
Date: Sun, 23 Jan 2011 10:45:01 -0500
To: bug-YAPE-Regex [...] rt.cpan.org
From: Jeffrey Pinyan <japhy.734 [...] gmail.com>
On Sun, Jan 23, 2011 at 10:07 AM, Steffen Mueller via RT < bug-YAPE-Regex@rt.cpan.org> wrote: Show quoted text
> I expect the necessary change to be small (for someone who understands > the code base) and to be more of a special case hack than any kind of > big modification. Any chance to get this done before 5.14 is released? > If not, a lot of code using YAPE::Regex to parse regexes will simply not > work on 5.14. >
Do you know when that is expected to be? I haven't had a lot of time for serious Perl module development in a few years, but I'll see what I can do to get YAPE::Regex up to code. -- Jeffrey Pinyan (*@PrayingTheMass* <http://twitter.com/PrayingTheMass/> on Twitter) Author of *Praying the Mass <http://www.PrayingTheMass.com/>*, a series of books on the new English translation of the Mass Blogger at *The Cross Reference* <http://thecrossreference.blogspot.com/><http://thecrossreference.blogspot.com> [Mary said,] "Do whatever he tells you." ~ John 2:5
Subject: Re: [rt.cpan.org #65042] Compatibility with the upcoming perl 5.14
Date: Sun, 23 Jan 2011 18:26:54 +0100
To: bug-YAPE-Regex [...] rt.cpan.org
From: Steffen Mueller <smueller [...] cpan.org>
Hi Jeff, On 01/23/2011 04:45 PM, japhy.734@gmail.com via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=65042> > > On Sun, Jan 23, 2011 at 10:07 AM, Steffen Mueller via RT< > bug-YAPE-Regex@rt.cpan.org> wrote: >
>> I expect the necessary change to be small (for someone who understands >> the code base) and to be more of a special case hack than any kind of >> big modification. Any chance to get this done before 5.14 is released? >> If not, a lot of code using YAPE::Regex to parse regexes will simply not >> work on 5.14. >>
> > Do you know when that is expected to be?
April 2011. Show quoted text
> I haven't had a lot of time for serious Perl module development in a few > years, but I'll see what I can do to get YAPE::Regex up to code.
I know you've been busy. All the more, I appreciate your looking into this in due time. Best regards, Steffen
I believe I may have a solution, although I can't prove it yet because I do not have access to perl version 5.13.6 (or later). However, if I upload this fix to CPAN, the CPAN testers can prove if my fix works. The approach is to make the qr stringification introduced in 5.14 look like the old qr stringification. In the Regex.pm "new" sub, I check the stringified regex for the new "(?^:" syntax. If present, I would replace it with the old syntax. For example, (?^i:foo) would be replaced with (?i-xsm:foo). This should work with perl versions before and after 5.13.6. I have tested this change locally on perl 5.12.2, and it does not break the existing YAPE::Regex test. Please let me know if I have grossly overlooked something. My patch is probably not very elegant. If you can think of a way to improve it, please let me know. Gene
Subject: diff-u.txt
--- Regex.pm.orig 2011-01-25 15:25:58.000000000 -0500 +++ Regex.pm 2011-01-25 15:23:52.000000000 -0500 @@ -7,7 +7,7 @@ use vars '$VERSION'; -$VERSION = '3.04'; +$VERSION = '4.00'; my $valid_POSIX = qr{ @@ -97,6 +97,23 @@ $regex = "(?-imsx:$regex)" if $@; + # Make the qr stringification introduced in 5.14 look like the old + # qr stringification. + if ($regex =~ / ^ \( \? \^ ([imsx]+) (: .*) $ /x) { + my $switches = $1; + my $rest = $2; + my $inverted = invert($switches); + if (length $inverted) { + $regex = "(?$switches-$inverted$rest"; + } + else { + $regex = "(?imsx$rest"; + } + } + elsif ($regex =~ / ^ \( \? \^ : /x) { + $regex =~ s/\^/-imsx/; + } + my $self = bless { TREE => [], TREE_STACK => [], @@ -110,6 +127,16 @@ } +sub invert { + # Given an input string which looks like modifiers (ismx), + # return the inverse string. + # For example, if the input is 'ix', return 'ms'. + my %mods = map { $_ => 1 } qw(i m s x); + delete $mods{$_} for (split //, shift); + return join '', keys %mods; +} + + sub state { $_[0]{STATE} } sub error { $_[0]{ERROR} } sub depth { $_[0]{DEPTH} }
I have applied my patch and released a new version of YAPE-Regex (4.00). The new CPAN Tester results look better now. There are no more error messages in the test reports for post-5.13.6 versions of perl. So far, it has been tested on 5.13.8 and 5.13.9.