Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

New development release in sight

 

 

First page Previous page 1 2 Next page Last page  View All Perl porters RSS feed   Index | Next | Previous | View Threaded


rgarciasuarez at gmail

Nov 21, 2006, 9:35 AM

Post #1 of 32 (944 views)
Permalink
New development release in sight

I would like to release 5.9.5 soon.

I know it's not quite stable, but it's reasonably feature-complete.

The Plan is then to stabilize the stuff and sort out the smoke
failures, plus try a good chunk of the CPAN against it (that's why I
want a new release out), and then release 5.9.6 (a.k.a. 5.10.0-beta.)

So, what's missing ?

* Yves, are you working on further patches ? can you post a point on
your plans ?

* Jos, what's the remaining of the list of new modules to integrate
for CPANPLUS ?

* missing features ? notably for "six on five-ten". Like, support for
lexical aliases. (should this wait for a version > 5.10.0 ?)

* 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)

--
rgs
(*) bug #40954 is titled: 'Aho-Corasick' regex patch (28373) not thread-safe


davem at iabyn

Nov 21, 2006, 9:47 AM

Post #2 of 32 (931 views)
Permalink
Re: New development release in sight [In reply to]

On Tue, Nov 21, 2006 at 06:35:16PM +0100, 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)

There are a couple of things I know I've broken:
* some of my "leak-fixing on parse error" stuff can SEGV
* my reworking of the regex engine will leak on /(?{die})/ type stuff

The latter can be easily remedied; the former may be fixable, or if
necessary I could revert the relevant changes.

I'm unlikely to find time for the next couple of weeks however.

--
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole edifice won't collapse as a
result.
-- Nicholas Clark, restating an insight of Simon Cozens


steve at fisharerojo

Nov 21, 2006, 10:33 AM

Post #3 of 32 (929 views)
Permalink
Re: New development release in sight [In reply to]

On Tue, Nov 21, 2006 at 06:35:16PM +0100, Rafael Garcia-Suarez wrote:
> I would like to release 5.9.5 soon.
>
> I know it's not quite stable, but it's reasonably feature-complete.
>
> The Plan is then to stabilize the stuff and sort out the smoke
> failures, plus try a good chunk of the CPAN against it (that's why I
> want a new release out), and then release 5.9.6 (a.k.a. 5.10.0-beta.)
>
> So, what's missing ?
>
> * Yves, are you working on further patches ? can you post a point on
> your plans ?
>
> * Jos, what's the remaining of the list of new modules to integrate
> for CPANPLUS ?
>
> * missing features ? notably for "six on five-ten". Like, support for
> lexical aliases. (should this wait for a version > 5.10.0 ?)
>
> * 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)
>

I have a couple of changes to make to finish the work of making dirhandles a
bit more useful in bleadperl, but I should be able to complete that work over
the next few days.

The bigger issue I'm working is that doing an

open my $pipe, "|-";

on OpenBSD 4.0/ppc with a threaded bleadperl running with -T hangs, leaving
zombie processes littered about when interupted. It appears to be hanging
somewhere on a poll() called internally by the OpenBSD libc. OpenBSD's man
pages seem to hint that this may be a problem within the kernel itself,
but I'd like to definitively rule Perl out before filing a bug report
with the OpenBSD folks.

This problem will take some more time to diagnose, and I am skipping the
tests, so if it misses the next development release, that should be OK.

Steve Peters
steve[at]fisharerojo.org


h.m.brand at xs4all

Nov 21, 2006, 11:39 AM

Post #4 of 32 (932 views)
Permalink
Re: New development release in sight [In reply to]

On Tue, 21 Nov 2006 18:35:16 +0100, "Rafael Garcia-Suarez"
<rgarciasuarez[at]gmail.com> wrote:

> I would like to release 5.9.5 soon.
>
> I know it's not quite stable, but it's reasonably feature-complete.
>
> The Plan is then to stabilize the stuff and sort out the smoke
> failures, plus try a good chunk of the CPAN against it (that's why I
> want a new release out), and then release 5.9.6 (a.k.a. 5.10.0-beta.)
>
> So, what's missing ?

Only (Configure-related) thing on my agenda is looking deeper into
64bit Linux builds (Tels' problem). My problem is that the 64bit
Linux box I had available for tests is taken away and degraded to
be a winblows box :(

I still hope to see README/INSTALL/README.* patches to improve the
Schwern complaint ...

There is a second (minor) thing: I've seen problems in environments
with both proprietary make and GNU make, where GNU make is named
gmake. Clear testcases welcome. So far I have not been able to
reproduce. Will look like

autosplit_lib_modules(@ARGV)' lib/*/*.pm
gmake lib/re.pm
gmake[1]: Entering directory `/var/adm/crash/tmp/build/perl-5.8.8'
makefile:954: *** missing separator. Stop.
gmake[1]: Leaving directory `/var/adm/crash/tmp/build/perl-5.8.8'

> * Yves, are you working on further patches ? can you post a point on
> your plans ?
>
> * Jos, what's the remaining of the list of new modules to integrate
> for CPANPLUS ?
>
> * missing features ? notably for "six on five-ten". Like, support for
> lexical aliases. (should this wait for a version > 5.10.0 ?)
>
> * 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)

--
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/


doughera at lafayette

Nov 21, 2006, 1:40 PM

Post #5 of 32 (927 views)
Permalink
Re: New development release in sight [In reply to]

On Tue, 21 Nov 2006, H.Merijn Brand wrote:

> On Tue, 21 Nov 2006 18:35:16 +0100, "Rafael Garcia-Suarez"
> <rgarciasuarez[at]gmail.com> wrote:

> There is a second (minor) thing: I've seen problems in environments
> with both proprietary make and GNU make, where GNU make is named
> gmake. Clear testcases welcome. So far I have not been able to
> reproduce. Will look like
>
> autosplit_lib_modules(@ARGV)' lib/*/*.pm
> gmake lib/re.pm
> gmake[1]: Entering directory `/var/adm/crash/tmp/build/perl-5.8.8'
> makefile:954: *** missing separator. Stop.
> gmake[1]: Leaving directory `/var/adm/crash/tmp/build/perl-5.8.8'

There used to be problems mixing SysV-style make and gmake, but (at least
according to the comments in ext/util/make_ext) I think that's been fixed
since 5.004_03 or so. I wasn't able to reproduce this problem mixing
Sun's make and gmake.

The only other thing I recall is Jarkko's comment in
ext/Time/HiRes/Makefile.PL, which appears to point a finger at the utf
locale. I don't know any more details, and don't have the appropriate
locales installed on my Solaris system to test it.

Fortunately, there's likely a simple workaround -- use the native 'make'.

--
Andy Dougherty doughera[at]lafayette.edu


demerphq at gmail

Nov 21, 2006, 2:08 PM

Post #6 of 32 (929 views)
Permalink
Re: New development release in sight [In reply to]

On 11/21/06, Rafael Garcia-Suarez <rgarciasuarez[at]gmail.com> wrote:
> I would like to release 5.9.5 soon.
>
> I know it's not quite stable, but it's reasonably feature-complete.
>
> The Plan is then to stabilize the stuff and sort out the smoke
> failures, plus try a good chunk of the CPAN against it (that's why I
> want a new release out), and then release 5.9.6 (a.k.a. 5.10.0-beta.)
>
> So, what's missing ?
>
> * Yves, are you working on further patches ? can you post a point on
> your plans ?

My current works in progress are: (and in roughly this level of priority):

1. Close Bug #4095. Whether its low impact or not I really want to see
this fixed before 5.10.

2. Close the \G and /g issues. I am tantalizingly close to making them
work properly and sanely.

3. Add a hook for instrumenting specialized regex engines. Currently
if we need extra data then we change struct regexp. This isnt viable
once 5.10 comes out. We need a void pointer in there that perl
promises never to mess with that would be purely for creating
specialized regexp engine derivatives. For instance Devel::Cover could
use such a derivative to do regexp code coverage, or a specialized app
like Spamassassin could provide a hand tweaked derivative for doing
their stuff. Bascially I want to get it such that when the 5.10 code
freeze comes in its possible to extend the regex engine without
needing to rebuild perl or affect binary compatibility of the 5.10
line.

I think this is a question that deserves a bit more thought from other
besides myself. Is the framework as currently set up sufficient that
we can make improvements in the regex engine without requiring
rebuilding perl? I feel like my level of experience insufficient to
make such a judgement call. What sugar could we add to make things
more flexible in the future?

4. Fix some issues associated with $REGMARK and EVAL.

5. Fix some issues associated with implicity BOL (/^.*/) and EVAL. (we
shouldn't implicit BOL if we have seen an eval code.)

6. Add one more regop for doing an efficient exhaustive search of a pattern.

7. Review the offsets code.

I guess most of these will get closed off pretty quick.

Uh, I think thats about it. For me personally, I do think however we
need to document the shared memory routines and document that the rest
dont allow memory to be safely shared.

Cheers,
Yves

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


steve at fisharerojo

Nov 21, 2006, 2:49 PM

Post #7 of 32 (929 views)
Permalink
Re: New development release in sight [In reply to]

On Tue, Nov 21, 2006 at 04:40:26PM -0500, Andy Dougherty wrote:
> On Tue, 21 Nov 2006, H.Merijn Brand wrote:
>
> > On Tue, 21 Nov 2006 18:35:16 +0100, "Rafael Garcia-Suarez"
> > <rgarciasuarez[at]gmail.com> wrote:
>
> > There is a second (minor) thing: I've seen problems in environments
> > with both proprietary make and GNU make, where GNU make is named
> > gmake. Clear testcases welcome. So far I have not been able to
> > reproduce. Will look like
> >
> > autosplit_lib_modules(@ARGV)' lib/*/*.pm
> > gmake lib/re.pm
> > gmake[1]: Entering directory `/var/adm/crash/tmp/build/perl-5.8.8'
> > makefile:954: *** missing separator. Stop.
> > gmake[1]: Leaving directory `/var/adm/crash/tmp/build/perl-5.8.8'
>
> There used to be problems mixing SysV-style make and gmake, but (at least
> according to the comments in ext/util/make_ext) I think that's been fixed
> since 5.004_03 or so. I wasn't able to reproduce this problem mixing
> Sun's make and gmake.
>
> The only other thing I recall is Jarkko's comment in
> ext/Time/HiRes/Makefile.PL, which appears to point a finger at the utf
> locale. I don't know any more details, and don't have the appropriate
> locales installed on my Solaris system to test it.
>
> Fortunately, there's likely a simple workaround -- use the native 'make'.
>

I think I've seen the problem on my OpenSolaris box, but I think only
certain targets seemed to be effected, like "make distclean". I'd have to
try again to see for certain.

Steve Peters
steve[at]fisharerojo.org


steve.hay at uk

Nov 22, 2006, 12:50 AM

Post #8 of 32 (923 views)
Permalink
Re: New development release in sight [In reply to]

Rafael Garcia-Suarez wrote:
> I would like to release 5.9.5 soon.
>
> I know it's not quite stable, but it's reasonably feature-complete.
>
> The Plan is then to stabilize the stuff and sort out the smoke
> failures, plus try a good chunk of the CPAN against it (that's why I
> want a new release out), and then release 5.9.6 (a.k.a. 5.10.0-beta.)
>
> So, what's missing ?

I haven't finished VC++ 8 support yet. Remaining things to do:

- change Module-Build to embed manifest files as per the change to
MakeMaker in #29266
- fix the two failing tests ()
- address the various CRT function deprecation warnings emitted by the
compiler (POSIX/ISO names and secure CRT names)
- update the README.win32 and Makefile comments to say that VC8 is now
supported ;-)


>
> * Yves, are you working on further patches ? can you post a point on
> your plans ?
>
> * Jos, what's the remaining of the list of new modules to integrate
> for CPANPLUS ?
>
> * missing features ? notably for "six on five-ten". Like, support for
> lexical aliases. (should this wait for a version > 5.10.0 ?)
>
> * 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)

Bug #40681 currently stops mod_perl-1.x from working with blead (on
Win32, at least, probably other OS's too). (It works fine with maint,
of course.) I'm not sure if it's perl or mod_perl that needs changing
to sort it out, though.

--


------------------------------------------------
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.


kane at xs4all

Nov 22, 2006, 1:23 AM

Post #9 of 32 (917 views)
Permalink
Re: New development release in sight [In reply to]

Greetings,

> * Jos, what's the remaining of the list of new modules to integrate
> for CPANPLUS ?

The modules to be integrated are as follows, in order of integration:

* Module::Pluggable - Patch pending on p5p
* IPC::Cmd - Cross platform ipc
* File::Fetch - Cross platform file fetching
* Archive::Extract - Cross platform file extraction
* CPANPLUS - Core of CPANPLUS
* CPANPLUS::Dist::Build - CPANPLUS bindings to Module::Build

The one snag we're going to hit is that the last 3 modules include binary
files, most notably in their test suite (.tgz files, to simulate archives
from CPAN),
which aren't welcome by perl's VCS. We have several ways to work around this,
and i'll make sure i'll agree with you upon which to pick.

-- Jos


nospam-abuse at bloodgate

Nov 22, 2006, 8:37 AM

Post #10 of 32 (918 views)
Permalink
Re: New development release in sight [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

>I would like to release 5.9.5 soon.

Cool :)

>So, what's missing ?

* A new Math::BigInt etc. released is long overdue. Please kick me into
gear.
* I want to spur Yves into looking into why qr// is slower than it should,
the slowdown makes assembling regexps from dynamically created parts much
less usefull than it could be.

Best wishes,

Tels

- --
Signed on Wed Nov 22 17:35:49 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.

I'm a Sis-sis-sis-sis-sis-sis-sis-sinnahr...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRWR80XcLPEOTuEwVAQIHfQf/S0Opn83nVXy8OIdUhVWLy5P5+IhSFOlF
Mcr1teQQ+99Srmn4TuZaPpK0lZq/1wZ/imlAo37HRUvr1sMUS9vCrRNbfC3mlDP1
WvOx1TPEbuA1aEJJx3O5isCrxQMggTKliSqswSy5z6helLT1PP2wMZmCgLrJbYPS
fZ1Zj6V1Y9itNqhc5z/FLsXMAGvVbB1cf0FOcXQ7xsXoWsnjVt1Ppbq9s5mEJHIO
64mNuUMz0ktwcV7Jzh7aqgSF0UjHEZNQLBNdisVsFcQT3Gz5qQuiSHnnD9/tMWd9
HeVLdQGNbxfu1GsaFFg4ycBnIWmJFIGTeuFEQ5wmQLWOexnSrk5Rjg==
=eGx6
-----END PGP SIGNATURE-----


demerphq at gmail

Nov 22, 2006, 8:55 AM

Post #11 of 32 (922 views)
Permalink
Re: New development release in sight [In reply to]

On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> * I want to spur Yves into looking into why qr// is slower than it should,
> the slowdown makes assembling regexps from dynamically created parts much
> less usefull than it could be.

Its because there is no easy way to merge a compiled regex into one
that is being compiled. Its not impossible its just not easy. I dont
see this happening in time for 5.10 if we want 5.10 coming out around
the new year.

Yves

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


nospam-abuse at bloodgate

Nov 22, 2006, 11:59 AM

Post #12 of 32 (918 views)
Permalink
Re: New development release in sight [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

offlist because I accidentily replied to myself, then resent it but forgot
to add p5p. So, repost to list:

On Wednesday 22 November 2006 19:23, you wrote:
> On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > Moin,
> > On Wednesday 22 November 2006 17:55, you wrote:
> > > On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> > > > * I want to spur Yves into looking into why qr// is slower than it
> > > > should, the slowdown makes assembling regexps from dynamically
> > > > created parts much less usefull than it could be.
> > >
> > > Its because there is no easy way to merge a compiled regex into one
> > > that is being compiled. Its not impossible its just not easy. I dont
> > > see this happening in time for 5.10 if we want 5.10 coming out around
> >
> > Okay on the time frame. Just some small followup question for me to
> > understand:
> >
> > As far as I understood Dave's message,
> >
> > $qr_foo = qr/foo/; $qr_foobar = qr/bar$qr_foo/;
> >
> > results in $qr_foobar merely containing:
> >
> > (?-xism:bar(?-xism:foo))
> >
> > as a string. Why aren't the "inner" (?-xism:...) cut away when the
> > content of the xism doesn't contain any variables or is "simple" or
> > whatever? (I know that probably sounds much easier than it is :)
>
> They have to be wrapped in (?: ) so they are self contained.
>
> Think about:
>
> $p=qr/a|b|c/;
> $x=qr/foo$p/;
>
> you dont want $x to be: fooa|b|c. You want it to be (?:foo(?:a|b|c)).

Good point. (That was exactly the point I was waiting for since I couldn't
come up with an example).

So
qr/foo/ => foo
qr/a|b/ => (?:a|b)
qr/(foo)/ => (foo)
etc.

Maybe a simple heuristic is that if it contans only [a-z0-9\[\]],
interpolate as it is, otherwise interpolate as "(?:" $qr .")", unless it
already has "(" at the start. Hm, but the regexp engine would surely know
much better which case could be handled as which.

> > I want the result to be:
> >
> > (?-xism:barfoo)
> >
> > and actually not a bunch of pointers to the little parts.
>
> That would be nice. I dont know if its that easy to do. We have some
> of the information on hand to make it happen tho.
>
> > The reason is
> > because it can become unwieldingly large and complicated:
> >
> > perl -le '$f = qr/f/; for (0..3) { $f = qr/$f$f/; } print
> > $f,"\n"'
> >
> > I already have written a parser that nestes about 3 layers of multiple
> > qr// objects and a simple debug printout of the resulting regexp start
> > to spam the screen with xisms :-)
>
> Yeah, well you could post process the regex with a regex. :-) remove
> all the unnecessary wrappers. Or you could use something like the
> tools in the latest version of the re module that allow you to get
> access to the pattern unwrapped.

Well, if I had some free time lying around here somewhere :/

> > Plus, everytime you use that string to match
> > something, the regexp compiler seems to goes crazy.
>
> IN what way?

Parsing & processing all these (?-xism:) every match takes time :) Not much,
but needless time anyway.

> > Maybe someone should write RegExp::Optimize::qr? :-D
> Heh.
> BTW, why offlist?
>
> Cheers,
> Yves

- --
Signed on Wed Nov 22 20:54:46 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.

This email violates U.S. patent #5,978,791 <http://tinyurl.com/5t6ft>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRWSsEHcLPEOTuEwVAQLQyQf9HPq78BzY68q5xLdsF5tS499q0PWk+dB2
EW4k9DuFpWk59h86igOmfsDjJH3Fl/GPc6WiyIVmjEPr0GAB7OSHlCa6cIul4BGR
CF+0mCzmEPODGim9TCLhprtb19l7qfmiG4PT6zsP+qpeF3yVHianjjdHWfLfLRp9
MjO/96EulOI3/GRBfFdAA01SAAJDanqwbz9TPVIWUfQltq/9i8G10cTU3fi8XnMY
Q572lOfjM6TYLfAyAsTE1XcHJ5gfSOJGazgMKtt84JFViocIZ2WdnWXwfCp7GYAp
XoeI79qkJ4nEjItJUgDPmWovZcJz2TMQnu5PY4xKDhw4AmMeLlXxpg==
=gf83
-----END PGP SIGNATURE-----


twists at gmail

Nov 22, 2006, 1:39 PM

Post #13 of 32 (919 views)
Permalink
Re: New development release in sight [In reply to]

On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Moin,
>
> offlist because I accidentily replied to myself, then resent it but forgot
> to add p5p. So, repost to list:
>
> On Wednesday 22 November 2006 19:23, you wrote:
> > On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > Moin,
> > > On Wednesday 22 November 2006 17:55, you wrote:
> > > > On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> > > > > * I want to spur Yves into looking into why qr// is slower than it
> > > > > should, the slowdown makes assembling regexps from dynamically
> > > > > created parts much less usefull than it could be.
> > > >
> > > > Its because there is no easy way to merge a compiled regex into one
> > > > that is being compiled. Its not impossible its just not easy. I dont
> > > > see this happening in time for 5.10 if we want 5.10 coming out around
> > >
> > > Okay on the time frame. Just some small followup question for me to
> > > understand:
> > >
> > > As far as I understood Dave's message,
> > >
> > > $qr_foo = qr/foo/; $qr_foobar = qr/bar$qr_foo/;
> > >
> > > results in $qr_foobar merely containing:
> > >
> > > (?-xism:bar(?-xism:foo))
> > >
> > > as a string. Why aren't the "inner" (?-xism:...) cut away when the
> > > content of the xism doesn't contain any variables or is "simple" or
> > > whatever? (I know that probably sounds much easier than it is :)
> >
> > They have to be wrapped in (?: ) so they are self contained.
> >
> > Think about:
> >
> > $p=qr/a|b|c/;
> > $x=qr/foo$p/;
> >
> > you dont want $x to be: fooa|b|c. You want it to be (?:foo(?:a|b|c)).
>
> Good point. (That was exactly the point I was waiting for since I couldn't
> come up with an example).
>
> So
> qr/foo/ => foo
> qr/a|b/ => (?:a|b)
> qr/(foo)/ => (foo)
> etc.
>
> Maybe a simple heuristic is that if it contans only [a-z0-9\[\]],
> interpolate as it is, otherwise interpolate as "(?:" $qr .")", unless it
> already has "(" at the start. Hm, but the regexp engine would surely know
> much better which case could be handled as which.

You're losing the regexp flags this way. Stringification *must*
include the /xism flags or the pattern can't be understood. You could
opt to do some alternate stringification just for pp_concat when
called by pp_regcomp and there you'd know what flags the containing
regexp had and could compare that against your about-to-be-stringified
regexp and omit the flags if you know there's no potential bleed from
other interpolated patterns, etc.

# must set /s on $x
$x = qr/.../s/;
$y = /...$x.../; => "(?-xism:...(?s:...)...)" to reduce the flags
as much as possible.

# *must* set /i on FOO.
$a = qr/(?-i)/;
$b = qr/FOO/i;
$c = qr/$a$b/; => "(?-i)(?i:FOO)"

With all the potential interpolation of flags from one regexp
component to the next you've got to be really careful to copy those
along or you're just assembling garbage.

Josh


bqw10602 at nifty

Nov 22, 2006, 8:35 PM

Post #14 of 32 (920 views)
Permalink
Re: New development release in sight [In reply to]

On Wed, 22 Nov 2006 17:55:47 +0100, demerphq <demerphq[at]gmail.com> wrote

> On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> > * I want to spur Yves into looking into why qr// is slower than it should,
> > the slowdown makes assembling regexps from dynamically created parts much
> > less usefull than it could be.
>
> Its because there is no easy way to merge a compiled regex into one
> that is being compiled. Its not impossible its just not easy. I dont
> see this happening in time for 5.10 if we want 5.10 coming out around
> the new year.

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.

Regards,
SADAHIRO Tomoyuki


nick at ccl4

Nov 23, 2006, 9:17 AM

Post #15 of 32 (918 views)
Permalink
Re: New development release in sight [In reply to]

On Wed, Nov 22, 2006 at 08:50:57AM +0000, Steve Hay wrote:

> Bug #40681 currently stops mod_perl-1.x from working with blead (on
> Win32, at least, probably other OS's too). (It works fine with maint,
> of course.) I'm not sure if it's perl or mod_perl that needs changing
> to sort it out, though.

Nor am I really, but I changed the core in change 29364 so that assigning
to a PVCV sets the prototype.

Nicholas Clark


rvtol+news at isolution

Nov 23, 2006, 1:54 PM

Post #16 of 32 (903 views)
Permalink
Re: New development release in sight [In reply to]

SADAHIRO Tomoyuki schreef:
> demerphq:
>> Tels:

>>> * I want to spur Yves into looking into why qr// is slower than it
>>> should, the slowdown makes assembling regexps from dynamically
>>> created parts much less usefull than it could be.
>>
>> Its because there is no easy way to merge a compiled regex into one
>> that is being compiled. Its not impossible its just not easy. I dont
>> see this happening in time for 5.10 if we want 5.10 coming out around
>> the new year.
>
> 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/;
;)

--
Affijn, Ruud

"Gewoon is een tijger."


nick at ccl4

Nov 23, 2006, 3:07 PM

Post #17 of 32 (900 views)
Permalink
Re: New development release in sight [In reply to]

On Wed, Nov 22, 2006 at 08:50:57AM +0000, Steve Hay wrote:

> Bug #40681 currently stops mod_perl-1.x from working with blead (on
> Win32, at least, probably other OS's too). (It works fine with maint,
> of course.) I'm not sure if it's perl or mod_perl that needs changing
> to sort it out, though.

Then you get past that. Then you get past the conditional call of PERL_INIT.
Then you get to

3134 DIE(aTHX_ "Compilation failed in require");
(gdb) p svp
$4 = (struct sv * const * const) 0x182b264
(gdb) call Perl_sv_dump(svp)
SV = UNKNOWN(0x8c) (0x307860) at 0x182b264
REFCNT = 25465100
FLAGS = (OBJECT,NOK,ROK,FAKE,pIOK,pPOK)

(I find that failing tests are due to this.
Resume tomorrow on Linux rather than OS X, and throw valgrind at it)

I have a suspicion that it's another strange reaction to the SV body changes.

Nicholas Clark


steve.hay at uk

Nov 24, 2006, 2:26 AM

Post #18 of 32 (897 views)
Permalink
Re: New development release in sight [In reply to]

Nicholas Clark wrote:
> On Wed, Nov 22, 2006 at 08:50:57AM +0000, Steve Hay wrote:
>
>> Bug #40681 currently stops mod_perl-1.x from working with blead (on
>> Win32, at least, probably other OS's too). (It works fine with maint,
>> of course.) I'm not sure if it's perl or mod_perl that needs changing
>> to sort it out, though.
>
> Nor am I really, but I changed the core in change 29364 so that assigning
> to a PVCV sets the prototype.

Thanks for the fix!


>
> Then you get past that. Then you get past the conditional call of PERL_INIT.
> Then you get to
>
> 3134 DIE(aTHX_ "Compilation failed in require");
> (gdb) p svp
> $4 = (struct sv * const * const) 0x182b264
> (gdb) call Perl_sv_dump(svp)
> SV = UNKNOWN(0x8c) (0x307860) at 0x182b264
> REFCNT = 25465100
> FLAGS = (OBJECT,NOK,ROK,FAKE,pIOK,pPOK)
>
> (I find that failing tests are due to this.
> Resume tomorrow on Linux rather than OS X, and throw valgrind at it)
>
> I have a suspicion that it's another strange reaction to the SV body changes.

What versions of mod_perl and apache are you using?

I'm running 1.29 and 1.3.36 and I find that mod_perl now builds fine and
passes all tests (with blead at 29370).

--


------------------------------------------------
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.


rick at bort

Nov 24, 2006, 5:10 PM

Post #19 of 32 (901 views)
Permalink
Re: New development release in sight [In reply to]

On Nov 23 2006, Nicholas Clark wrote:
> On Wed, Nov 22, 2006 at 08:50:57AM +0000, Steve Hay wrote:
>
> > Bug #40681 currently stops mod_perl-1.x from working with blead (on
> > Win32, at least, probably other OS's too). (It works fine with maint,
> > of course.) I'm not sure if it's perl or mod_perl that needs changing
> > to sort it out, though.
>
> Then you get past that. Then you get past the conditional call of PERL_INIT.
> Then you get to
>
> 3134 DIE(aTHX_ "Compilation failed in require");

This rings a bell; it is the code executed when an already failed
require is attempted again. It happens when $INC{$file} is undef. A
quick scan of the mod_perl source finds this code in perl_reload_inc()
in src/modules/perl/perl_util.c:

if (!(entry = hv_fetch_ent(hash, keysv, FALSE, 0))) {
MP_TRACE_g(fprintf(stderr,
"%s not found in %%INC\n", elts[i].key));
continue;
}
SvREFCNT_dec(HeVAL(entry));
HeVAL(entry) = &sv_undef;
MP_TRACE_g(fprintf(stderr, "reloading %s\n", HeKEY(entry)));
perl_require_pv(HeKEY(entry));

*hash is %INC so you can see that the code is setting the value to undef
before requiring the file again. This used to trick pp_require into
reloading the file; now it just confuses the failed-load-caching
mechanism into thinking that the file was already required (and failed
to load). The correct thing for mod_perl to do now would be to delete
the key from %INC.

I don't know if this helps in any way with the rest of your
conversation but it does look like something mod_perl needs to change to
work with 5.10.

> (gdb) p svp
> $4 = (struct sv * const * const) 0x182b264
> (gdb) call Perl_sv_dump(svp)
> SV = UNKNOWN(0x8c) (0x307860) at 0x182b264
> REFCNT = 25465100
> FLAGS = (OBJECT,NOK,ROK,FAKE,pIOK,pPOK)
>
> (I find that failing tests are due to this.
> Resume tomorrow on Linux rather than OS X, and throw valgrind at it)
>
> I have a suspicion that it's another strange reaction to the SV body changes.
>
> Nicholas Clark

--
Rick Delaney
rick[at]bort.ca


bqw10602 at nifty

Nov 24, 2006, 6:07 PM

Post #20 of 32 (898 views)
Permalink
Re: New development release in sight [In reply to]

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/;

Regards,
SADAHIRO Tomoyuki


rvtol+news at isolution

Nov 25, 2006, 6:25 AM

Post #21 of 32 (895 views)
Permalink
Re: New development release in sight [In reply to]

SADAHIRO Tomoyuki schreef:
> Dr.Ruud:
>> SADAHIRO Tomoyuki:

>>> 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.

I understood.

> 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/;

My understanding is that "match 2" should be printed. I'll try and look
into it the coming week, if it is still open then of course.

--
Affijn, Ruud

"Gewoon is een tijger."


demerphq at gmail

Nov 26, 2006, 3:33 AM

Post #22 of 32 (889 views)
Permalink
Re: New development release in sight [In reply to]

On 11/25/06, SADAHIRO Tomoyuki <bqw10602[at]nifty.com> 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

/(foo)\R1/

into a pattern. In hindsight the ability to embed is far far more
important than the ability to do /(foo\R1)/ so the latter will have to
go. (Actually, I feel a bit of a prat for not noticing this in the
first place...)

Thanks for the catch. When I get back from my holiday I will post a
patch to fix it up.

cheers,
Yves









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


demerphq at gmail

Nov 26, 2006, 3:37 AM

Post #23 of 32 (892 views)
Permalink
Re: New development release in sight [In reply to]

On 11/25/06, SADAHIRO Tomoyuki <bqw10602[at]nifty.com> 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

/(foo)\R1/

into a pattern. In hindsight the ability to embed is far far more
important than the ability to do /(foo\R1)/ so the latter will have to
go. (Actually, I feel a bit of a prat for not noticing this in the
first place...)

Thanks for the catch. When I get back from my holiday I will post a
patch to fix it up.

cheers,
Yves









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


demerphq at gmail

Nov 26, 2006, 3:45 AM

Post #24 of 32 (893 views)
Permalink
Re: New development release in sight [In reply to]

On 11/23/06, SADAHIRO Tomoyuki <bqw10602[at]nifty.com> wrote:
>
> On Wed, 22 Nov 2006 17:55:47 +0100, demerphq <demerphq[at]gmail.com> wrote
>
> > On 11/22/06, Tels <nospam-abuse[at]bloodgate.com> wrote:
> > > * I want to spur Yves into looking into why qr// is slower than it should,
> > > the slowdown makes assembling regexps from dynamically created parts much
> > > less usefull than it could be.
> >
> > Its because there is no easy way to merge a compiled regex into one
> > that is being compiled. Its not impossible its just not easy. I dont
> > see this happening in time for 5.10 if we want 5.10 coming out around
> > the new year.
>
> 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.

Actually this wouldnt be too big an issue to deal with IMO. All we
have to do is teach the appropriate regops how to deal with an offset
to determine which startp/endp buffers to populate during the match.
Then when we launch an embedded pattern we would set the offset as
appropriate.

Note that relative backrefs dont use such an approach, the \R1
notation is compile time resolved to an absolute paren.

What I think will be an issue wil be handling absolute addressing in
the engine, although off the top of my head I cant think where we use
absolute addressing Im fairly sure there still is some around.

Cheers,
Yves


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


pgollucci at p6m7g8

Nov 27, 2006, 11:50 PM

Post #25 of 32 (884 views)
Permalink
Re: New development release in sight [In reply to]

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, 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

cat .patch
29397



--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci[at]p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F

I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.

First page Previous page 1 2 Next page Last page  View All Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.