It forms a long-lived tree, with a large widespreading head of rugged
branches. While it may naturally live to an age of a few centuries, many
of the oldest trees are pollarded or coppiced, both pruning techniques
that extend the tree's potential lifespan, if not its health.
Within its native range it is valued for its importance to insects and
other wildlife. Numerous insects live on the leaves, buds, and in the
acorns. The acorns form a valuable food resource for several small
mammals and some birds, notably Jays Garrulus glandarius.
It is planted for forestry, and produces a long-lasting and durable
heartwood, much in demand for interior and furniture work.
Abridged slightly from the Wikipedia entry.
Get it now from
http://opensource.fotango.com/~nclark/perl-5.8.5-RC1.tar.bz2
(or s/bz2$/gz/ if you really want a 25% larger download.)
coming soon to a CPAN mirror near you soon as
ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NW/NWCLARK/perl-5.8.5-RC1.tar.bz2
Once it's propagated round the CPAN mirrors I'll make an announcement
on use.perl
Whilst there are quite a few species of trees native to Britain, I wasn't
planning on making a release candidate for each of them. All being well there
won't need to be another release candidate, and the real thing will arrive in
about eight days.
Nicholas Clark
All is well on Win2k and XP using Visual Studio dotNet. At least with
regards to 5.8.5's test suites.
I did some tests on processing large files, where 5.6.1 ran in an average of
14 minutes to process approximately 2.5 gigs of data, 5.8.5 ran in about 10
minutes for the same data set. This code involves lots of closures and
hybrid Inline::C code and it all worked very nicely. Nice one.
Regarding modules I tried installing....
Libwin installed ok, as did most of my standard modules. However libwin
reported a LARGE number of type mismatch warnings when being installed.
Since most Win32 authors consider this library to be "standard" I wonder if
or when it will be absored by p5p instead of lagging behind all of the time.
(For someone like me its hard to decide how serious these warnings are...)
Anyway, more serious issues were that I could NOT get IPC::Run to build
under 5.8.5 but I could get it to run under 5.6.1, and this meant that
CPANPLUS wouldn't build. Likewise with Module::Build. It appears that
both/all have problems with using a versioned perl executable for building
with.
Cheers,
Yves
Attached are some minor patches from the Debian 5.8.4 package not
included in this RC.
The only other patch I have is a roll-back of DynaLoader to 1.04 to
preserve backward compatability. I'm guessing that you may not want to
apply that one :)
--bod
What kind of compatibility was broken ?
> diff -Naur --exclude=debian perl-5.8.4.orig/lib/ExtUtils/instmodsh perl-5.8.4/lib/ExtUtils/instmodsh
> --- perl-5.8.4.orig/lib/ExtUtils/instmodsh 2004-01-06 09:34:59.000000000 +1100
> +++ perl-5.8.4/lib/ExtUtils/instmodsh 2004-05-02 06:57:25.000000000 +1000
> @@ -137,3 +137,28 @@
> toplevel();
Not really a question for Brendan. How come there are both
lib/ExtUtils/instmodsh and utils/instmodsh? The latter is generated from
utils/instmodsh.PL
Nicholas Clark
Anything which embeds perl links to DynaLoader.a statically, so any such
program will fail when loading DynaLoader.pm due to the mismatch in
XS_VERSION_BOOTCHECK.
See http://bugs.debian.org/247291 for an example.
--bod
This XSUB reproduces the bug :
int
myprint (title)
SV * title
CODE:
char *t;
sv_utf8_upgrade(ST(0)); /* remove this and it works */
t = (char *)SvPV_nolen(ST(0));
RETVAL = 1;
PerlIO_printf(Perl_debug_log,"#%s#\n",t);
OUTPUT:
RETVAL
If called with undef, it produces "Modification of a read-only value
attempted".
I've committed this to blead:
Change 23063 by rgs@valis on 2004/07/07 17:48:29
Make Perl_sv_utf8_upgrade_flags tolerate PL_sv_undef
as an argument.
Affected files ...
... //depot/perl/sv.c#752 edit
Differences ...
==== //depot/perl/sv.c#752 (text) ====
@@ -3937,6 +3937,8 @@
U8 *s, *t, *e;
int hibit = 0;
+ if (sv == &PL_sv_undef)
+ return 0;
if (!SvPOK(sv)) {
STRLEN len = 0;
(void) SvPV_force(sv,len);
Not 100% sure whether this is the Right Thing to do. (tests do pass, however.)
Seems more sensible than testing for SvOK, though. Anyhow I think this is a
showstopper for 5.8.5 currently.
Nicholas> Whilst there are quite a few species of trees native to
Nicholas> Britain, I wasn't planning on making a release candidate for
Nicholas> each of them. All being well there won't need to be another
Nicholas> release candidate, and the real thing will arrive in about
Nicholas> eight days.
"perldoc perldelta" still says 5.8.3 to 5.8.4, even though there
*is* a "perldoc perl583delta" properly.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
> ==== //depot/perl/sv.c#752 (text) ====
>
> @@ -3937,6 +3937,8 @@
> U8 *s, *t, *e;
> int hibit = 0;
>
> + if (sv == &PL_sv_undef)
> + return 0;
> if (!SvPOK(sv)) {
> STRLEN len = 0;
> (void) SvPV_force(sv,len);
>
> Not 100% sure whether this is the Right Thing to do. (tests do pass, however.)
> Seems more sensible than testing for SvOK, though. Anyhow I think this is a
> showstopper for 5.8.5 currently.
Which implies that RC1 was not release worthy, which means that it's time
for a new release candidate.
So, is there a better solution to this?
Nicholas Clark
Well spotted. It's consistent with me failing to change the text in
perl585delta.pod. However, it turns out this wasn't my mistake - the
problem actually is that perl584delta.pod still thinks that it's the
"perldelta". Now fixed.
Nicholas Clark
IMHO, as the API document for sv_utf8_upgrade (even in Perl 5.8.[0-4])
states the followings:
Convert the PV of an SV to its UTF-8-encoded form.
Forces the SV to string form if it is not already.
Always sets the SvUTF8 flag to avoid future validity checks
even if all the bytes have hibit clear.
people could avoid to call sv_utf8_upgrade(ST(0)) if ST(0) is readonly.
I think hiding the error ("Modification of a read-only...") is not good,
though I don't know what is wrong when sv_utf8_upgrade(&PL_sv_undef) is
to be accepted.
At least, &PL_sv_undef should not be extended to other !SvOK values.
Provided that the conditional is (!SvOK(sv)) instead
of (sv == &PL_sv_undef), sv_catsv(dsv, utf8) will fail to set UTF8 flag
in the case of original dsv is undefined.
cf. in a pseudo-perl code:
$a = undef; sv_catsv($a, chr 0x1234); ok($a, chr 0x1234);
Regards,
SADAHIRO Tomoyuki
Agreed.
> I think hiding the error ("Modification of a read-only...") is not good,
> though I don't know what is wrong when sv_utf8_upgrade(&PL_sv_undef) is
> to be accepted.
At most something subtle. It used to be accepted in 5.8.4 and earlier.
Hence the major breakage experienced with Gtk2.
> At least, &PL_sv_undef should not be extended to other !SvOK values.
Agreed (that's why I didn't put the SvOK case in it.)
>> "perldoc perldelta" still says 5.8.3 to 5.8.4, even though there
>> *is* a "perldoc perl583delta" properly.
Nicholas> Well spotted. It's consistent with me failing to change the text in
Nicholas> perl585delta.pod. However, it turns out this wasn't my mistake - the
Nicholas> problem actually is that perl584delta.pod still thinks that it's the
Nicholas> "perldelta". Now fixed.
I just installed RC2. Still looks broken.
"man perldelta" should be the differences from 5.8.4 to 5.8.5.
Yet it still claims to be 5.8.3 to 5.8.4.
"man perl585delta" should not exist, yet it does. (it's the what
"perldelta" should be)
So, it sounds like you have to move perl585delta to perldelta,
and delete perl585delta.
Both, mod_perl 1.0 and 2.0 pass all their tests fine with RC1 on linux.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:st...@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Gah. I didn't test this well enough. I really fixed something that was
broken. There was something else too - Makefile is hard coded as to which
perl58?delta.pod file to copy.
Thanks for testing.
I should write a review the debugging book I have sitting here on my desk,
given that I violated one of its rules ("If you didn't fix it, it ain't
fixed")
This fix is in the RC2 that got uploaded to PAUSE.
Nicholas Clark
> Anyway, more serious issues were that I could NOT get IPC::Run to build
> under 5.8.5 but I could get it to run under 5.6.1, and this meant that
> CPANPLUS wouldn't build. Likewise with Module::Build. It appears that
> both/all have problems with using a versioned perl executable for building
> with.
Do you know whether the same failures occur with IPC::Run on 5.8.4 on Windows?
I'd not consider any of this release critical if there is no change from 5.8.4
If there is, I have to work out what to do.
Nicholas Clark
Thanks. I've applied the second. I've sent the first further upstream to
the makemaker list. :-)
Nicholas Clark