v5.17.9-80-g9f351b4 breaks SARTAK/Path-Dispatcher-1.04.tar.gz #12846

p5pRT · 2013-03-12T06:06:25Z

Migrated from rt.perl.org#117135 (status was 'resolved')

Searchable as RT117135$

p5pRT · 2013-03-12T06:06:25Z

From @andk

git bisect

commit 9f351b4
Author: David Mitchell <davem@iabyn.com>
Date: Sat Mar 2 23:31:13 2013 +0000

Disable by default the new Copy-on-Write for 5.18

sample fail report

http://www.cpantesters.org/cpan/report/16f730a6-840d-11e2-b7d1-6ff133fcb185

perl -V

Summary of my perl5 (revision 5 version 17 subversion 10) configuration:
Commit id: 9f351b4
Platform:
osname=linux, osvers=3.2.0-4-amd64, archname=x86_64-linux-ld
uname='linux k83 3.2.0-4-amd64 #1 smp debian 3.2.39-2 x86_64 gnulinux '
config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/v5.17.9-80-g9f351b4/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=define
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.7.2', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8
alignbytes=16, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.13'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_SAWAMPERSAND
PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT
USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LONG_DOUBLE
USE_PERLIO USE_PERL_ATOF
Built under linux
Compiled at Mar 10 2013 03:13:51
@INC:
/home/src/perl/repoperls/installed-perls/perl/v5.17.9-80-g9f351b4/127e/lib/site_perl/5.17.10/x86_64-linux-ld
/home/src/perl/repoperls/installed-perls/perl/v5.17.9-80-g9f351b4/127e/lib/site_perl/5.17.10
/home/src/perl/repoperls/installed-perls/perl/v5.17.9-80-g9f351b4/127e/lib/5.17.10/x86_64-linux-ld
/home/src/perl/repoperls/installed-perls/perl/v5.17.9-80-g9f351b4/127e/lib/5.17.10
.

--
andreas

p5pRT · 2013-03-14T02:23:26Z

From @jkeenan

On Mon Mar 11 23:06:25 2013, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:

git bisect
----------
commit 9f351b4
Author: David Mitchell <davem@iabyn.com>
Date: Sat Mar 2 23:31:13 2013 +0000
Disable by default the new Copy\-on\-Write for 5\.18
sample fail report
------------------
http://www.cpantesters.org/cpan/report/16f730a6-840d-11e2-b7d1-
6ff133fcb185

When a non-core module fails when run against blead, is the module's
author notified automatically by cpantesters.org?

Thank you very much.
Jim Keenan

p5pRT · 2013-03-14T02:23:27Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2013-03-14T07:05:10Z

From @andk

"James E Keenan via RT" <perlbug-followup@perl.org> writes:

When a non-core module fails when run against blead, is the module's
author notified automatically by cpantesters.org?

Cpantesters.org has its own private mechanisms which can be configured
by each author according to their taste. I can only explain my reasoning
how I deal with BBCs (Bleadperl breaks CPAN) cases.

Usually I CC the committer to blead and the maintainer of the broken
module. Only in rare cases I decide differently:

(1) I do not CC the cpan author if I believe that it's obvious that the
commit is a mistake and if not much time has passed since the commit. In
this case I hope that the mistake will be corrected before too many
people get involved and blead comes back on track.

(2) I bring the issue directly to rt.cpan.org when I believe that it's
obvious that the module is doing something wrong. If I choose this route
I CC the committer found in the bisect.

These two deviations from the normal process are rare cases because they
both have a risk that somebody does not get informed who should be. So I
only make these exceptions when things look very obvious to me. But most
of the time they don't.

--
andreas

p5pRT · 2013-03-14T10:10:48Z

From @timbunce

On Thu, Mar 14, 2013 at 08:04:15AM +0100, Andreas Koenig wrote:

"James E Keenan via RT" <perlbug-followup@perl.org> writes:

When a non-core module fails when run against blead, is the module's
author notified automatically by cpantesters.org?

Cpantesters.org has its own private mechanisms which can be configured
by each author according to their taste. I can only explain my reasoning
how I deal with BBCs (Bleadperl breaks CPAN) cases.

Usually I CC the committer to blead and the maintainer of the broken
module. Only in rare cases I decide differently:

(1) I do not CC the cpan author if I believe that it's obvious that the
commit is a mistake and if not much time has passed since the commit. In
this case I hope that the mistake will be corrected before too many
people get involved and blead comes back on track.

(2) I bring the issue directly to rt.cpan.org when I believe that it's
obvious that the module is doing something wrong. If I choose this route
I CC the committer found in the bisect.

These two deviations from the normal process are rare cases because they
both have a risk that somebody does not get informed who should be. So I
only make these exceptions when things look very obvious to me. But most
of the time they don't.

I, for one, am very grateful for this service and the care with which
you execute it.

Thank you Andreas!

Tim.

p5pRT · 2013-03-14T11:36:43Z

From @iabyn

On Mon, Mar 11, 2013 at 11:06:26PM -0700, Andreas J. Koenig via RT wrote:

git bisect
----------
commit 9f351b4
Author: David Mitchell <davem@iabyn.com>
Date: Sat Mar 2 23:31:13 2013 +0000
Disable by default the new Copy\-on\-Write for 5\.18

tl;dr: the module's handling of $' needs a bit of reworking (as I describe
below) to handle changes in implementation in perl.

This issue is due to the delayed $' in Path/Dispatcher/Rule/Regex.pm:

# only provide leftover if we need it. $' is slow, and it may be undef
if ($self->prefix) {
$extra{leftover} = eval q{$'};
delete $extra{leftover} if !defined($extra{leftover});
}

The test code in t/031-structured-match.t requires that C<eval q{$'}>
return a string.

Traditionally in perl a pattern match would make a copy of the complete
string if it contained any captures, or any of $', $&, $' had been seen in
compiled code *before* the regexp was executed,

$ perl5100 -le"'abc' =~ /a/; print eval q{\$'}"

$ perl5100 -le"'abc' =~ /a/; \$';print eval q{\$'}"
bc
$ perl5100 -le"'abc' =~ /(a)/; print eval q{\$'}"
bc
$

But once one of those vars had been seen, or if the pattern contained a
capture, then since the whole match string was copied, this made all of
$`,$&,$& available for use, even if not all three of those vars had been
seen.

5.17.4 changed this so that only the needed parts of the match string were
copied: so for example if only $& had been seen, the $' part of the string
still wouldn't be captured:

$ perl5173 -le"'abc' =~ /a/; \$&;print eval q{\$'}"
bc
$ perl5174 -le"'abc' =~ /a/; \$&;print eval q{\$'}"

$

This avoided an O(N^2) slowdown on code like

$&; while ($megabyte_string =~ /./g) { ...}

Then in 5.17.7, the new Copy-on-Write mechanism was introduced, which
*always* copied the string (at essentially zero cost), so $`,$&,$' were
always available for free, regardless of whether any of the special vars
had been seen or whether the pattern contained captures:

$ perl5177 -le"'abc' =~ /a/; print eval q{\$'}"
bc
$

Now in blead, we have disabled the new COW by default for 5.18, due to
too many issues; so the behaviour has reverted to the 5.17.4-5.17.6 era.

I'd suggest the following workaround for Path/Dispatcher/Rule/Regex.pm:

do an 'eval q{$'}' just *before* the regex is executed; then when the regex is
executed it will capture $' on all versions of perl. This means that you
still don't enable capturing just by the act of 'use Path::Dispatcher',
but it will be permanently enabled after the first match (whereas before it was
enabled after the first *successful* match). Later on when 5.20 is out,
this could be made conditional on perl version.

--
"Foul and greedy Dwarf - you have eaten the last candle."
-- "Hordes of the Things", BBC Radio.

p5pRT · 2013-03-14T12:09:28Z

From @demerphq

On 14 March 2013 12:35, Dave Mitchell <davem@iabyn.com> wrote:

On Mon, Mar 11, 2013 at 11:06:26PM -0700, Andreas J. Koenig via RT wrote:
git bisect
----------
commit 9f351b4
Author: David Mitchell <davem@iabyn.com>
Date: Sat Mar 2 23:31:13 2013 +0000
Disable by default the new Copy\-on\-Write for 5\.18
tl;dr: the module's handling of $' needs a bit of reworking (as I describe
below) to handle changes in implementation in perl.

This issue is due to the delayed $' in Path/Dispatcher/Rule/Regex.pm:
\# only provide leftover if we need it\. $' is slow\, and it may be undef
if $$self\->prefix$ \{
    $extra\{leftover\} = eval q\{$'\};
    delete $extra\{leftover\} if \!defined$$extra\{leftover\}$;
\}
The test code in t/031-structured-match.t requires that C<eval q{$'}>
return a string.

Traditionally in perl a pattern match would make a copy of the complete
string if it contained any captures, or any of $', $&, $' had been seen in
compiled code *before* the regexp was executed,
$ perl5100 \-le"'abc' =~ /a/; print eval q\{\\$'\}"

$ perl5100 \-le"'abc' =~ /a/; \\$';print eval q\{\\$'\}"
bc
$ perl5100 \-le"'abc' =~ /$a$/; print eval q\{\\$'\}"
bc
$
But once one of those vars had been seen, or if the pattern contained a
capture, then since the whole match string was copied, this made all of
$`,$&,$& available for use, even if not all three of those vars had been
seen.

5.17.4 changed this so that only the needed parts of the match string were
copied: so for example if only $& had been seen, the $' part of the string
still wouldn't be captured:
$ perl5173 \-le"'abc' =~ /a/; \\$&;print eval q\{\\$'\}"
bc
$ perl5174 \-le"'abc' =~ /a/; \\$&;print eval q\{\\$'\}"

$
This avoided an O(N^2) slowdown on code like
$&; while $$megabyte\_string =~ /\./g$ \{ \.\.\.\}
Then in 5.17.7, the new Copy-on-Write mechanism was introduced, which
*always* copied the string (at essentially zero cost), so $`,$&,$' were
always available for free, regardless of whether any of the special vars
had been seen or whether the pattern contained captures:
$ perl5177 \-le"'abc' =~ /a/; print eval q\{\\$'\}"
bc
$
Now in blead, we have disabled the new COW by default for 5.18, due to
too many issues; so the behaviour has reverted to the 5.17.4-5.17.6 era.

I'd suggest the following workaround for Path/Dispatcher/Rule/Regex.pm:

do an 'eval q{$'}' just *before* the regex is executed; then when the regex is
executed it will capture $' on all versions of perl. This means that you
still don't enable capturing just by the act of 'use Path::Dispatcher',
but it will be permanently enabled after the first match (whereas before it was
enabled after the first *successful* match). Later on when 5.20 is out,
this could be made conditional on perl version.

What about using the /p variants instead?

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-03-14T12:55:34Z

From @iabyn

On Thu, Mar 14, 2013 at 01:08:50PM +0100, demerphq wrote:

What about using the /p variants instead?

There's currently a bug with /p, in that it applies to the pattern, not
the match, so when passed an re object $re, this:

$str =~ /$r/p

sets ${^POSTMATCH} etc based on whether $r was compiled with /p, and
ignores the /p flag on the match.

--
Red sky at night - gerroff my land!
Red sky at morning - gerroff my land!
-- old farmers' sayings #14.

p5pRT · 2013-03-14T13:16:13Z

From @demerphq

On 14 March 2013 13:53, Dave Mitchell <davem@iabyn.com> wrote:

On Thu, Mar 14, 2013 at 01:08:50PM +0100, demerphq wrote:

What about using the /p variants instead?

There's currently a bug with /p, in that it applies to the pattern, not
the match, so when passed an re object $re, this:
$str =~ /$r/p
sets ${^POSTMATCH} etc based on whether $r was compiled with /p, and
ignores the /p flag on the match.

But that would be a bug with /$regex/ and not with /p right?

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-03-14T14:12:32Z

From @iabyn

On Thu, Mar 14, 2013 at 02:15:34PM +0100, demerphq wrote:

On 14 March 2013 13:53, Dave Mitchell <davem@iabyn.com> wrote:
On Thu, Mar 14, 2013 at 01:08:50PM +0100, demerphq wrote:

What about using the /p variants instead?

There's currently a bug with /p, in that it applies to the pattern, not
the match, so when passed an re object $re, this:
$str =~ /$r/p
sets ${^POSTMATCH} etc based on whether $r was compiled with /p, and
ignores the /p flag on the match.
But that would be a bug with /$regex/ and not with /p right?

well, that's probably a nicety of semantics. I *think* (without having
looked too closely at it yet), that /p sets a flag on the regexp, when it
should be setting a flag on the PMOP, c.f. /g, etc.

--
Now is the discount of our winter tent
-- sign seen outside camping shop

p5pRT · 2013-03-14T14:18:09Z

From p5p@sartak.org

Dave Mitchell wrote:

I'd suggest the following workaround for Path/Dispatcher/Rule/Regex.pm:

do an 'eval q{$'}' just *before* the regex is executed; then when the regex is
executed it will capture $' on all versions of perl. This means that you
still don't enable capturing just by the act of 'use Path::Dispatcher',
but it will be permanently enabled after the first match (whereas before it was
enabled after the first *successful* match). Later on when 5.20 is out,
this could be made conditional on perl version.

Hi Dave,

Thanks very much for your thorough description of the problem (and for
your copy-on-write work!). I've released Path::Dispatcher 1.05 which
does exactly as you've suggested: eval q{$'} before the regex match. The
2013 me is surprised that he was ever able to get away with eval q{$'}
after the regex match!

Cheers!
Shawn

p5pRT · 2013-03-14T14:30:39Z

@iabyn - Status changed from 'open' to 'resolved'

p5pRT · 2013-03-14T14:33:39Z

From @iabyn

On Thu, Mar 14, 2013 at 10:17:36AM -0400, Shawn M Moore wrote:

he 2013 me is surprised that he was ever able to get away
with eval q{$'} after the regex match!

I think the big difference in bleadperl is that just having a capture in
a regex is no longer enough to automatically set $' as a side-effect.

--
In my day, we used to edit the inodes by hand. With magnets.

p5pRT · 2013-03-14T14:42:12Z

From @khwilliamson

On 03/14/2013 04:09 AM, Tim Bunce wrote:

On Thu, Mar 14, 2013 at 08:04:15AM +0100, Andreas Koenig wrote:

"James E Keenan via RT" <perlbug-followup@perl.org> writes:

When a non-core module fails when run against blead, is the module's
author notified automatically by cpantesters.org?

Cpantesters.org has its own private mechanisms which can be configured
by each author according to their taste. I can only explain my reasoning
how I deal with BBCs (Bleadperl breaks CPAN) cases.

Usually I CC the committer to blead and the maintainer of the broken
module. Only in rare cases I decide differently:

(1) I do not CC the cpan author if I believe that it's obvious that the
commit is a mistake and if not much time has passed since the commit. In
this case I hope that the mistake will be corrected before too many
people get involved and blead comes back on track.

(2) I bring the issue directly to rt.cpan.org when I believe that it's
obvious that the module is doing something wrong. If I choose this route
I CC the committer found in the bisect.

These two deviations from the normal process are rare cases because they
both have a risk that somebody does not get informed who should be. So I
only make these exceptions when things look very obvious to me. But most
of the time they don't.

I, for one, am very grateful for this service and the care with which
you execute it.

Thank you Andreas!

Tim.

++

Me too

p5pRT · 2013-03-14T14:56:42Z

From @demerphq

On 14 March 2013 15:11, Dave Mitchell <davem@iabyn.com> wrote:

On Thu, Mar 14, 2013 at 02:15:34PM +0100, demerphq wrote:
On 14 March 2013 13:53, Dave Mitchell <davem@iabyn.com> wrote:
On Thu, Mar 14, 2013 at 01:08:50PM +0100, demerphq wrote:

What about using the /p variants instead?

There's currently a bug with /p, in that it applies to the pattern, not
the match, so when passed an re object $re, this:
$str =~ /$r/p
sets ${^POSTMATCH} etc based on whether $r was compiled with /p, and
ignores the /p flag on the match.
But that would be a bug with /$regex/ and not with /p right?
well, that's probably a nicety of semantics. I *think* (without having
looked too closely at it yet), that /p sets a flag on the regexp, when it
should be setting a flag on the PMOP, c.f. /g, etc.

But it shouldn't (just) be. The whole idea is that /p "moves" with the pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-03-14T15:03:37Z

From @iabyn

On Thu, Mar 14, 2013 at 08:41:04AM -0600, Karl Williamson wrote:

I, for one, am very grateful for this service and the care with which
you execute it.
++

+1

--
More than any other time in history, mankind faces a crossroads. One path
leads to despair and utter hopelessness. The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
-- Woody Allen

p5pRT · 2013-03-14T15:54:50Z

From @iabyn

On Thu, Mar 14, 2013 at 03:56:00PM +0100, demerphq wrote:

On 14 March 2013 15:11, Dave Mitchell <davem@iabyn.com> wrote:
On Thu, Mar 14, 2013 at 02:15:34PM +0100, demerphq wrote:
On 14 March 2013 13:53, Dave Mitchell <davem@iabyn.com> wrote:
On Thu, Mar 14, 2013 at 01:08:50PM +0100, demerphq wrote:

What about using the /p variants instead?

There's currently a bug with /p, in that it applies to the pattern, not
the match, so when passed an re object $re, this:
$str =~ /$r/p
sets ${^POSTMATCH} etc based on whether $r was compiled with /p, and
ignores the /p flag on the match.
But that would be a bug with /$regex/ and not with /p right?
well, that's probably a nicety of semantics. I *think* (without having
looked too closely at it yet), that /p sets a flag on the regexp, when it
should be setting a flag on the PMOP, c.f. /g, etc.
But it shouldn't (just) be. The whole idea is that /p "moves" with the pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

I think that's where we disagree. I see /p as related to the use of the
pattern, rather than affecting what the pattern matches, so like /g, not
/i.

Treating it like /i makes no sense to me. Can you suggest any use cases?
Also, what would /..(?p:...)...(?-p:....).../ mean?

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit."
-- Lady Croom, "Arcadia"

p5pRT · 2013-03-14T16:45:53Z

From @khwilliamson

On 03/14/2013 09:53 AM, Dave Mitchell wrote:

On Thu, Mar 14, 2013 at 03:56:00PM +0100, demerphq wrote:
On 14 March 2013 15:11, Dave Mitchell <davem@iabyn.com> wrote:
On Thu, Mar 14, 2013 at 02:15:34PM +0100, demerphq wrote:
On 14 March 2013 13:53, Dave Mitchell <davem@iabyn.com> wrote:
On Thu, Mar 14, 2013 at 01:08:50PM +0100, demerphq wrote:

What about using the /p variants instead?

There's currently a bug with /p, in that it applies to the pattern, not
the match, so when passed an re object $re, this:
 $str =~ /$r/p
sets ${^POSTMATCH} etc based on whether $r was compiled with /p, and
ignores the /p flag on the match.
But that would be a bug with /$regex/ and not with /p right?
well, that's probably a nicety of semantics. I *think* (without having
looked too closely at it yet), that /p sets a flag on the regexp, when it
should be setting a flag on the PMOP, c.f. /g, etc.
But it shouldn't (just) be. The whole idea is that /p "moves" with the pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;
I think that's where we disagree. I see /p as related to the use of the
pattern, rather than affecting what the pattern matches, so like /g, not
/i.

Treating it like /i makes no sense to me. Can you suggest any use cases?
Also, what would /..(?p:...)...(?-p:....).../ mean?

This warning gets raised for your final example:
Useless use of (?-p) in regex.

The first one turns on /p globally for the regex

p5pRT · 2013-03-15T09:54:34Z

From @ap

* demerphq <demerphq@gmail.com> [2013-03-14 16:00]:

But it shouldn't (just) be. The whole idea is that /p "moves" with the
pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

What sense does that make? How can the declaration site of the regex
know ahead of time whether these variables will be of interest at the
use site?

If anything, qr/.../p should be an error, same as qr/.../g is.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

p5pRT · 2013-03-15T09:58:33Z

From @demerphq

On 15 March 2013 10:53, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

* demerphq <demerphq@gmail.com> [2013-03-14 16:00]:

But it shouldn't (just) be. The whole idea is that /p "moves" with the
pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

What sense does that make? How can the declaration site of the regex
know ahead of time whether these variables will be of interest at the
use site?

$ perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'
a
ab
abc
abcd
abcdc
abcdcb
abcdcba

If anything, qr/.../p should be an error, same as qr/.../g is.

I beg to differ.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-03-15T10:09:51Z

From @mauke

On 15.03.2013 10:57, demerphq wrote:

On 15 March 2013 10:53, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

* demerphq <demerphq@gmail.com> [2013-03-14 16:00]:

But it shouldn't (just) be. The whole idea is that /p "moves" with the
pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

What sense does that make? How can the declaration site of the regex
know ahead of time whether these variables will be of interest at the
use site?

$ perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'
a
ab
abc
abcd
abcdc
abcdcb
abcdcba

If anything, qr/.../p should be an error, same as qr/.../g is.

I beg to differ.

FWIW I agree with Aristotle that /p should only be valid on the match
itself, not on random subpatterns in a regex.

--
Lukas Mai <l.mai@web.de>

p5pRT · 2013-03-15T11:15:46Z

From @demerphq

On 15 March 2013 11:09, Lukas Mai <l.mai@web.de> wrote:

On 15.03.2013 10:57, demerphq wrote:

On 15 March 2013 10:53, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

* demerphq <demerphq@gmail.com> [2013-03-14 16:00]:

But it shouldn't (just) be. The whole idea is that /p "moves" with the
pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

What sense does that make? How can the declaration site of the regex
know ahead of time whether these variables will be of interest at the
use site?

$ perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'
a
ab
abc
abcd
abcdc
abcdcb
abcdcba

If anything, qr/.../p should be an error, same as qr/.../g is.

I beg to differ.

FWIW I agree with Aristotle that /p should only be valid on the match
itself, not on random subpatterns in a regex.

As I said to Aristotle, A) you are wrong, and B) you are about 5 years
too late to advance an opinion on the subject.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-03-15T16:03:54Z

From @rjbs

* demerphq <demerphq@gmail.com> [2013-03-15T07:15:15]

FWIW I agree with Aristotle that /p should only be valid on the match
itself, not on random subpatterns in a regex.

As I said to Aristotle, A) you are wrong, and B) you are about 5 years
too late to advance an opinion on the subject.

(B) is not a great argument, regardless of (A), if we want to act like we can
ever change established behavior. ;)

Anyway, I had a look into this. Regardless of where /p and (?p: belong, I
think something else is up.

For example, you gave us this program:

perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'

That prints 7 blank lines since 5.17.4, inclusive. With /p, it works. I don't
think is exactly covered by Dave M.'s summary above about the "$& always
available," because there is no post-5.17.4 version in which the code prints
anything without the "p" flag. Or, if it's related to the "bug with /p" that
he mentioned, it seems substantially different than the problem he
demonstrated.

Further, do we agree that d78f32f needs to be reverted?

--
rjbs

p5pRT · 2013-03-15T16:20:24Z

From @demerphq

On 15 March 2013 17:03, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

* demerphq <demerphq@gmail.com> [2013-03-15T07:15:15]

FWIW I agree with Aristotle that /p should only be valid on the match
itself, not on random subpatterns in a regex.

As I said to Aristotle, A) you are wrong, and B) you are about 5 years
too late to advance an opinion on the subject.

(B) is not a great argument, regardless of (A), if we want to act like we can
ever change established behavior. ;)

I admit, I was frustrated by Lukas'es mail. I posted an example of
code that clearly would not work if you cannot put the /p inside of
the pattern. The example was "toy", but I assumed readers of this list
would see the deeper implication that perfectly legitimate things that
might go in a qr// might need the /p behavior to be "sticky". To
receive in reply to such a post a mail that basically ignores what I
said, and repeats the incorrect assertion that there is no point in
supporting /(?p:...)/ was to me quite frustrating.

As for the 5 years comment, at the time /p was introduced there was
heavy discussion about this and other aspects of its use, and as far
as I know no one suggested that /p should be like /g, so if they
wanted to argue that then they are doing it after 5 years worth of
people using it as is. And if they want to argue about it they should
do more than say "that makes no sense", especially when i posted code
where it DOES make sense. Ill just add that I vaguely remember that
supporting this particular use case is the reason that it works like
it does.

Anyway, I had a look into this. Regardless of where /p and (?p: belong, I
think something else is up.

For example, you gave us this program:

perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'

That prints 7 blank lines since 5.17.4, inclusive. With /p, it works. I don't
think is exactly covered by Dave M.'s summary above about the "$& always
available," because there is no post-5.17.4 version in which the code prints
anything without the "p" flag. Or, if it's related to the "bug with /p" that
he mentioned, it seems substantially different than the problem he
demonstrated.

This is a regression. It should definitely print out stuff. I cant say
what caused the regression, but it is one.

Further, do we agree that d78f32f needs to be reverted?

At a very quick glance yes.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-03-15T22:53:53Z

From @ap

* demerphq <demerphq@gmail.com> [2013-03-15 17:25]:

And if they want to argue about it they should do more than say "that
makes no sense", especially when i posted code where it DOES make
sense.

I _asked_ what sense it makes; _before_ you posted your counterexample;
which convinced me on sight; so I shut up. Leave me out of this please.
:-)

p5pRT · 2013-03-18T14:36:30Z

From @iabyn

On Fri, Mar 15, 2013 at 10:57:47AM +0100, demerphq wrote:

On 15 March 2013 10:53, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

* demerphq <demerphq@gmail.com> [2013-03-14 16:00]:

But it shouldn't (just) be. The whole idea is that /p "moves" with the
pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

What sense does that make? How can the declaration site of the regex
know ahead of time whether these variables will be of interest at the
use site?

$ perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'

Ah, I see, yes.

My remaining question is whether $r = qr/a/; /$r/p;
should set ${^MATCH} . I doesn't currently, and I think it should.

(Of course this will all become academic once COW is made the default
again).

--
Thank God I'm an atheist.....

p5pRT · 2013-03-18T14:57:55Z

From @demerphq

On 18 March 2013 15:35, Dave Mitchell <davem@iabyn.com> wrote:

On Fri, Mar 15, 2013 at 10:57:47AM +0100, demerphq wrote:

On 15 March 2013 10:53, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

* demerphq <demerphq@gmail.com> [2013-03-14 16:00]:

But it shouldn't (just) be. The whole idea is that /p "moves" with the
pattern.

$str=~/(?p:....)/;

should be the same as

$str=~/..../p;

Should be the same as:

$re= qr/..../p;

$str=~/$re/;

What sense does that make? How can the declaration site of the regex
know ahead of time whether these variables will be of interest at the
use site?

$ perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'

Ah, I see, yes.

My remaining question is whether $r = qr/a/; /$r/p;
should set ${^MATCH} . I doesn't currently, and I think it should.

Yep agreed. The match should occur in /p mod IFF the actual match
operator has a /p on it, or if the pattern contains (?p:...) anywhere
inside of it.

Thanks for looking into this. Sorry if I was a bit crusty about this
one last week.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-05-03T16:18:32Z

From @iabyn

On Fri, Mar 15, 2013 at 05:19:49PM +0100, demerphq wrote:

On 15 March 2013 17:03, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

Anyway, I had a look into this. Regardless of where /p and (?p: belong, I
think something else is up.

For example, you gave us this program:

perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'

That prints 7 blank lines since 5.17.4, inclusive. With /p, it works. I don't
think is exactly covered by Dave M.'s summary above about the "$& always
available," because there is no post-5.17.4 version in which the code prints
anything without the "p" flag. Or, if it's related to the "bug with /p" that
he mentioned, it seems substantially different than the problem he
demonstrated.

This is a regression. It should definitely print out stuff. I cant say
what caused the regression, but it is one.

(it bisects to 2c7b5d7).

But looking at the issue now, I think there's a bigger problem with
(?p:...) generally. Which if any of the following behaviours do people
think is wrong?

"a" =~ /(?p)a/ or die; print "[${^MATCH}]\n";

5.17.3: [a]
5.17.4: [a]

"a" =~ /(?p:a)/ or die; print "[${^MATCH}]\n";

5.17.3: []
5.17.4: []

"a" =~ /(?p)a(?{ print "[${^MATCH}]\n" })/ or die;

5.17.3: [a]
5.17.4: [a]

"a" =~ /(?p:a(?{ print "[${^MATCH}]\n" }))/ or die;

5.17.3: [a]
5.17.4: []

--
In economics, the exam questions are the same every year.
They just change the answers.

p5pRT · 2013-05-03T19:38:27Z

From @demerphq

On Friday, 3 May 2013, Dave Mitchell wrote:

On Fri, Mar 15, 2013 at 05:19:49PM +0100, demerphq wrote:

On 15 March 2013 17:03, Ricardo Signes <perl.p5p@rjbs.manxome.org<javascript:;>>
wrote:

Anyway, I had a look into this. Regardless of where /p and (?p:
belong, I
think something else is up.

For example, you gave us this program:

perl -le'"abcdcba"=~ /(?p:[abcd](?{ print ${^MATCH} }))+/'

That prints 7 blank lines since 5.17.4, inclusive. With /p, it works.
I don't
think is exactly covered by Dave M.'s summary above about the "$&
always
available," because there is no post-5.17.4 version in which the code
prints
anything without the "p" flag. Or, if it's related to the "bug with
/p" that
he mentioned, it seems substantially different than the problem he
demonstrated.

This is a regression. It should definitely print out stuff. I cant say
what caused the regression, but it is one.

(it bisects to 2c7b5d7).

But looking at the issue now, I think there's a bigger problem with
(?p:...) generally. Which if any of the following behaviours do people
think is wrong?

"a" =~ /(?p)a/ or die; print "[${^MATCH}]\n";
5\.17\.3&#8203;: \[a\]
5\.17\.4&#8203;: \[a\]
"a" =~ /(?p:a)/ or die; print "[${^MATCH}]\n";
5\.17\.3&#8203;: \[\]
5\.17\.4&#8203;: \[\]

both wrong.

"a" =~ /(?p)a(?{ print "[${^MATCH}]\n" })/ or die;
5\.17\.3&#8203;: \[a\]
5\.17\.4&#8203;: \[a\]
"a" =~ /(?p:a(?{ print "[${^MATCH}]\n" }))/ or die;
5\.17\.3&#8203;: \[a\]
5\.17\.4&#8203;: \[\]

second one is wrong.

what does 510 do?

cheers
yves

--
In economics, the exam questions are the same every year.
They just change the answers.

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-05-03T22:07:36Z

From @iabyn

On Fri, May 03, 2013 at 09:37:48PM +0200, demerphq wrote:

both wrong.
second one is wrong.
...

Ah good. Glad I wasn't going mad then.

what does 510 do?

5[1246]0 all do the same as 5.17.3; blead does the same as 5.17.4.

--
I thought I was wrong once, but I was mistaken.

p5pRT · 2013-05-05T07:53:33Z

From @demerphq

On 4 May 2013 00:06, Dave Mitchell <davem@iabyn.com> wrote:

On Fri, May 03, 2013 at 09:37:48PM +0200, demerphq wrote:

both wrong.
second one is wrong.
...

Ah good. Glad I wasn't going mad then.

what does 510 do?

5[1246]0 all do the same as 5.17.3; blead does the same as 5.17.4.

Oh fudge, More fallout from my patches. Sorry about this. Can I help at all?

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-05-05T14:03:42Z

From @iabyn

On Sun, May 05, 2013 at 09:52:41AM +0200, demerphq wrote:

On 4 May 2013 00:06, Dave Mitchell <davem@iabyn.com> wrote:

On Fri, May 03, 2013 at 09:37:48PM +0200, demerphq wrote:

both wrong.
second one is wrong.
...

Ah good. Glad I wasn't going mad then.

what does 510 do?

5[1246]0 all do the same as 5.17.3; blead does the same as 5.17.4.

Oh fudge, More fallout from my patches. Sorry about this. Can I help at all?

It's ok for now. I'll let you know if I get stuck, thanks.

--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.

p5pRT · 2013-05-06T11:33:46Z

From @iabyn

On Sun, May 05, 2013 at 03:03:05PM +0100, Dave Mitchell wrote:

On Sun, May 05, 2013 at 09:52:41AM +0200, demerphq wrote:

On 4 May 2013 00:06, Dave Mitchell <davem@iabyn.com> wrote:

On Fri, May 03, 2013 at 09:37:48PM +0200, demerphq wrote:

both wrong.
second one is wrong.
...

Ah good. Glad I wasn't going mad then.

what does 510 do?

5[1246]0 all do the same as 5.17.3; blead does the same as 5.17.4.

Oh fudge, More fallout from my patches. Sorry about this. Can I help at all?

It's ok for now. I'll let you know if I get stuck, thanks.

Now fixed by 1e1a634

The other issue,

My remaining question is whether $r = qr/a/; /$r/p;
should set ${^MATCH} . I doesn't currently, and I think it should.

I'll leave till after 5.18, since its not a regression.

--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.

p5pRT · 2013-05-06T11:49:10Z

From @demerphq

On 6 May 2013 13:33, Dave Mitchell <davem@iabyn.com> wrote:

On Sun, May 05, 2013 at 03:03:05PM +0100, Dave Mitchell wrote:

On Sun, May 05, 2013 at 09:52:41AM +0200, demerphq wrote:

On 4 May 2013 00:06, Dave Mitchell <davem@iabyn.com> wrote:

On Fri, May 03, 2013 at 09:37:48PM +0200, demerphq wrote:

both wrong.
second one is wrong.
...

Ah good. Glad I wasn't going mad then.

what does 510 do?

5[1246]0 all do the same as 5.17.3; blead does the same as 5.17.4.

Oh fudge, More fallout from my patches. Sorry about this. Can I help at all?

It's ok for now. I'll let you know if I get stuck, thanks.

Now fixed by 1e1a634

Cool thanks.

The other issue,

My remaining question is whether $r = qr/a/; /$r/p;
should set ${^MATCH} . I doesn't currently, and I think it should.

Agreed.

I'll leave till after 5.18, since its not a regression.

Make sense.
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT closed this as completed Mar 14, 2013

p5pRT added Severity Low distro-Linux sendToCPAN labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v5.17.9-80-g9f351b4 breaks SARTAK/Path-Dispatcher-1.04.tar.gz #12846

v5.17.9-80-g9f351b4 breaks SARTAK/Path-Dispatcher-1.04.tar.gz #12846

p5pRT commented Mar 12, 2013

p5pRT commented Mar 12, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

p5pRT commented Mar 15, 2013

p5pRT commented Mar 15, 2013

p5pRT commented Mar 15, 2013

p5pRT commented Mar 15, 2013

p5pRT commented Mar 15, 2013

p5pRT commented Mar 15, 2013

p5pRT commented Mar 15, 2013

p5pRT commented Mar 18, 2013

p5pRT commented Mar 18, 2013

p5pRT commented May 3, 2013

p5pRT commented May 3, 2013

p5pRT commented May 3, 2013

p5pRT commented May 5, 2013

p5pRT commented May 5, 2013

p5pRT commented May 6, 2013

p5pRT commented May 6, 2013

v5.17.9-80-g9f351b4 breaks SARTAK/Path-Dispatcher-1.04.tar.gz #12846

v5.17.9-80-g9f351b4 breaks SARTAK/Path-Dispatcher-1.04.tar.gz #12846

Comments

p5pRT commented Mar 12, 2013

p5pRT commented Mar 12, 2013

From @andk

p5pRT commented Mar 14, 2013

From @jkeenan

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

From @andk

p5pRT commented Mar 14, 2013

From @timbunce

p5pRT commented Mar 14, 2013

From @iabyn

p5pRT commented Mar 14, 2013

From @demerphq

p5pRT commented Mar 14, 2013

From @iabyn

p5pRT commented Mar 14, 2013

From @demerphq

p5pRT commented Mar 14, 2013

From @iabyn

p5pRT commented Mar 14, 2013

From p5p@sartak.org

p5pRT commented Mar 14, 2013

p5pRT commented Mar 14, 2013

From @iabyn

p5pRT commented Mar 14, 2013

From @khwilliamson

p5pRT commented Mar 14, 2013

From @demerphq

p5pRT commented Mar 14, 2013

From @iabyn

p5pRT commented Mar 14, 2013

From @iabyn

p5pRT commented Mar 14, 2013

From @khwilliamson

p5pRT commented Mar 15, 2013

From @ap

p5pRT commented Mar 15, 2013

From @demerphq

p5pRT commented Mar 15, 2013

From @mauke

p5pRT commented Mar 15, 2013

From @demerphq

p5pRT commented Mar 15, 2013

From @rjbs

p5pRT commented Mar 15, 2013

From @demerphq

p5pRT commented Mar 15, 2013

From @ap

p5pRT commented Mar 18, 2013

From @iabyn

p5pRT commented Mar 18, 2013

From @demerphq

p5pRT commented May 3, 2013

From @iabyn

p5pRT commented May 3, 2013

From @demerphq

p5pRT commented May 3, 2013

From @iabyn

p5pRT commented May 5, 2013

From @demerphq

p5pRT commented May 5, 2013

From @iabyn

p5pRT commented May 6, 2013

From @iabyn

p5pRT commented May 6, 2013

From @demerphq