Mailing List Archive: Perl: porters

New development release in sight

1 2

View All

Index | Next | Previous | View Threaded

steve.hay at uk

Nov 28, 2006, 9:24 AM

Post #26 of 32 (224 views)
Permalink

Re: New development release in sight [In reply to]

Philip M. Gollucci wrote:
> Rafael Garcia-Suarez wrote:
>> * is anyone aware of severe bugs I've overlooked ? (that is, bugs that
>> don't exist in maint. Old bugs that CPAN is used to work around to
>> aren't severe bugs. Bug #40954 is probably in this category)
>
> Since release 5.6, Perl has had two different threading implementations,
> the newer interpreter-based version (ithreads) with one interpreter per
> thread, and the older 5.005 version (5005threads).
> The 5005threads version is effectively unmaintained and will probably be
> removed in Perl 5.10,

It already has been removed as of #18030, over 4 years ago:

http://public.activestate.com/cgi-bin/perlbrowse?show_patch=Show+Patch&patch_num=18030

> so there should be no need to build a Perl using it
> unless needed for backwards compatibility with some existing 5.005threads
> code.
>
> grep -c USE_5005THREADS *.[ch] | grep -v :0
> intrpvar.h:1
> malloc.c:1
> perl.h:1
> pp_ctl.c:1
> thrdvar.h:3
> uconfig.h:3

I guess that's all just the detritus of #18030 and subsequent changes.
It could probably do with being cleaned up sometime, if only to avoid
any possible further confusion.

--

------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

doughera at lafayette

Nov 28, 2006, 1:32 PM

Post #27 of 32 (214 views)
Permalink

Re: New development release in sight [In reply to]

On Tue, 28 Nov 2006, Steve Hay wrote:

> Philip M. Gollucci wrote:
> > Rafael Garcia-Suarez wrote:
> >> * is anyone aware of severe bugs I've overlooked ? (that is, bugs that
> >> don't exist in maint. Old bugs that CPAN is used to work around to
> >> aren't severe bugs. Bug #40954 is probably in this category)
> >
> > Since release 5.6, Perl has had two different threading implementations,
> > the newer interpreter-based version (ithreads) with one interpreter per
> > thread, and the older 5.005 version (5005threads).
> > The 5005threads version is effectively unmaintained and will probably be
> > removed in Perl 5.10,
>
> It already has been removed as of #18030, over 4 years ago:
>
> http://public.activestate.com/cgi-bin/perlbrowse?show_patch=Show+Patch&patch_num=18030
>
>
> > so there should be no need to build a Perl using it
> > unless needed for backwards compatibility with some existing 5.005threads
> > code.
> >
> > grep -c USE_5005THREADS *.[ch] | grep -v :0
> > intrpvar.h:1
> > malloc.c:1
> > perl.h:1
> > pp_ctl.c:1
> > thrdvar.h:3
> > uconfig.h:3
>
> I guess that's all just the detritus of #18030 and subsequent changes.
> It could probably do with being cleaned up sometime, if only to avoid
> any possible further confusion.

On the flip side, deleting stuff that's just in comments also can
introduce spurious differences with the maintenance track (which does
still have 5.005 threads code). Such differences can make merging changes
back into the maintenance track more tedious. Just something else to
keep in mind if anyone feels the urge to go and clean up those few
remaining spots where 5005threads are mentioned.

--
Andy Dougherty doughera [at] lafayette

h.m.brand at xs4all

Nov 28, 2006, 4:00 PM

Post #28 of 32 (214 views)
Permalink

Re: New development release in sight [In reply to]

On Tue, 28 Nov 2006 16:32:20 -0500 (EST), Andy Dougherty
<doughera [at] lafayette> wrote:

> On Tue, 28 Nov 2006, Steve Hay wrote:
>
> > Philip M. Gollucci wrote:
> > > Rafael Garcia-Suarez wrote:
> > >> * is anyone aware of severe bugs I've overlooked ? (that is, bugs that
> > >> don't exist in maint. Old bugs that CPAN is used to work around to
> > >> aren't severe bugs. Bug #40954 is probably in this category)
> > >
> > > Since release 5.6, Perl has had two different threading implementations,
> > > the newer interpreter-based version (ithreads) with one interpreter per
> > > thread, and the older 5.005 version (5005threads).
> > > The 5005threads version is effectively unmaintained and will probably be
> > > removed in Perl 5.10,
> >
> > It already has been removed as of #18030, over 4 years ago:
> >
> > http://public.activestate.com/cgi-bin/perlbrowse?show_patch=Show+Patch&patch_num=18030
> >
> >
> > > so there should be no need to build a Perl using it
> > > unless needed for backwards compatibility with some existing 5.005threads
> > > code.
> > >
> > > grep -c USE_5005THREADS *.[ch] | grep -v :0
> > > intrpvar.h:1
> > > malloc.c:1
> > > perl.h:1
> > > pp_ctl.c:1
> > > thrdvar.h:3
> > > uconfig.h:3
> >
> > I guess that's all just the detritus of #18030 and subsequent changes.
> > It could probably do with being cleaned up sometime, if only to avoid
> > any possible further confusion.
>
> On the flip side, deleting stuff that's just in comments also can
> introduce spurious differences with the maintenance track (which does
> still have 5.005 threads code). Such differences can make merging changes
> back into the maintenance track more tedious. Just something else to
> keep in mind if anyone feels the urge to go and clean up those few
> remaining spots where 5005threads are mentioned.

With my recent change to Configure, the last visible awareness of 5005threads
to devel has been removed, while still maintaining coherence with maint.

I have done the chainsawing of 5005threads in devel, quite early in the 5.9
track, and I do remember having left a list of watchpoints/things to do in
the far future if this were to be taken to the very end.

I think we've reached a very sensible state now.

--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.1, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/

demerphq at gmail

Nov 28, 2006, 4:07 PM

Post #29 of 32 (224 views)
Permalink

Re: New development release in sight [In reply to]

On 11/26/06, demerphq <demerphq [at] gmail> wrote:
> On 11/25/06, SADAHIRO Tomoyuki <bqw10602 [at] nifty> wrote:
> >
> > On Thu, 23 Nov 2006 22:54:11 +0100, "Dr.Ruud" wrote
> >
> > > SADAHIRO Tomoyuki schreef:
> > > > I think how to number the captures is one of snags to realize it.
> > > > When the pattern which a sub-pattern is merged into has capturing
> > > > parentheses, the numbering of captures in the sub-pattern depends on
> > > > the number of captures before the position of interpolation.
> > > >
> > > > Examples:
> > > >
> > > > my $qr_bar1 = qr/(bar)\1/;
> > > > my $qr_foo_bar1 = qr/(foo${qr_bar1})/;
> > > > my $qr_foo_bar2 = qr/(foo(bar)\2)/;
> > > > my $q_bar2 = q /(bar)\2/;
> > > >
> > > > print "ok 1\n" if "foobarbar" =~ $qr_bar1;
> > > > print "ok 2\n" if "foobarbar" =~ $qr_foo_bar1; # not ok!
> > > > print "ok 3\n" if "foobarbar" =~ $qr_foo_bar2;
> > > > print "ok 4\n" if "foobarbar" =~ /(foo${q_bar2})/;
> > > >
> > > > But we can't create qr/(bar)\2/, since the second group doesn't exist
> > > > when the sub-pattern is compiled.
> > >
> > > my $qr_bar2 = qr/(bar)()\2/;
> > > ;)
> >
> > But $qr_bar2 can work only if the pattern that it's merged into
> > has exactly one group before the position of interpolation.
> >
> > What I want to mean is possibility that the backreference in the
> > sub-pattern always refers to the last group before it, whichever
> > pattern the sub-pattern would be merged into.
> >
> > Recently the relative backreference \R<digit> has come,
> > but it seems to have the limitation that the sub-pattern can't
> > be merged inside nesting perentheses (see tests 5 and 6 below):
> >
> > my $qr_barR1 = qr/(bar)\R1/;
> > print "ok 1\n" if "foobarbarxyz" =~ $qr_barR1;
> > print "ok 2\n" if "foobarbarxyz" =~ qr/foo${qr_barR1}xyz/;
> > print "ok 3\n" if "foobarbarxyz" =~ qr/(foo)${qr_barR1}xyz/;
> > print "ok 4\n" if "foobarbarxyz" =~ qr/(foo)(bar)\R1xyz/;
> > print "ok 5\n" if "foobarbarxyz" =~ qr/(foo${qr_barR1})xyz/; # fail
> > print "ok 6\n" if "foobarbarxyz" =~ qr/(foo(bar)\R1)xyz/; # fail
> > print "end.\n";
> >
> >
> > Two matches following fail, though I have no idea
> > where these \R1 should refer to.
> >
> > print "match 1\n" if "perlfoobarperlxyz" =~ /(perl)(foo(bar)\R1)xyz/;
> > print "match 2\n" if "perlfoobarbarxyz" =~ /(perl)(foo(bar)\R1)xyz/;
>
>
> Shoot. This is my fault.
>
> The issue is that I made /(foo\R1)/ DWIM. Which as you have just
> illustrated is a problem as it means you can not reliably embed

That should say that I made /(foo)(\R1)/ do what I thought made sense,
but I obviously didnt think it through fully.

Attached fixes the behaviour so all of your tests pass, and updates
the documentation to be more clear on the behaviour.

Cheers,
Yves

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

Attachments:

embeded_r.patch (4.65 KB)

rgarciasuarez at gmail

Nov 29, 2006, 1:30 AM

Post #30 of 32 (211 views)
Permalink

Re: New development release in sight [In reply to]

On 29/11/06, demerphq <demerphq [at] gmail> wrote:
> >
> > Shoot. This is my fault.
> >
> > The issue is that I made /(foo\R1)/ DWIM. Which as you have just
> > illustrated is a problem as it means you can not reliably embed
>
> That should say that I made /(foo)(\R1)/ do what I thought made sense,
> but I obviously didnt think it through fully.
>
> Attached fixes the behaviour so all of your tests pass, and updates
> the documentation to be more clear on the behaviour.

Thanks, applied.

rjk-perl-p5p at tamias

Nov 29, 2006, 7:41 AM

Post #31 of 32 (218 views)
Permalink

Re: New development release in sight [In reply to]

On Wed, Nov 29, 2006 at 01:07:43AM +0100, demerphq wrote:

> +
> + /
> + (Y) # buffer 1
> + ( # buffer 2
> + (X) # buffer 3
> + \R1 # backref to buffer 3
> + \R3 # backref to buffer 1
> + )
> + /x
> +
> +and would match the same as C</(Y) ( (X) $3 $1 )/x>.
> +

Shouldn't that be C</(Y) ( (X) \3 \1 )/x>?

Ronald

demerphq at gmail

Nov 29, 2006, 7:54 AM

Post #32 of 32 (222 views)
Permalink

New development release in sight [In reply to]

On 11/29/06, Ronald J Kimball <rjk-perl-p5p [at] tamias> wrote:
> On Wed, Nov 29, 2006 at 01:07:43AM +0100, demerphq wrote:
>
> > +
> > + /
> > + (Y) # buffer 1
> > + ( # buffer 2
> > + (X) # buffer 3
> > + \R1 # backref to buffer 3
> > + \R3 # backref to buffer 1
> > + )
> > + /x
> > +
> > +and would match the same as C</(Y) ( (X) $3 $1 )/x>.
> > +
>
> Shouldn't that be C</(Y) ( (X) \3 \1 )/x>?

Yes it should. Ill follow up with a patch. Thanks.

Yves

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

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads