Mon, 21 Aug 2006 09:53:32 +0200, demerphq wrote
8/21/06, demerphq <demerphq (AT) gmail (DOT) comwrote:
8/21/06, Andreas J. Koenig <andreas.koenig.gmwojprw (AT) franz (DOT) ak.mind.dewrote:
Sun, 20 Aug 2006 19:50:07 +0900, SADAHIR Tomoyuki <bqw10602 (AT) nifty (DOT) comsaid:
As loading utf8.pm for utf8::SWASHNEW() in utf8_heavy.pl is necessary
to compile a Unicode character class, swash_init() in utf8.c tried to
load utf8.pm if SWASHNEW is not defined, but (perhaps) wrongly assumed
it to be encoded in UTF-16, and then failed in loading it.
It seems this is fixed in Perl 5.9.4, though I'm not sure what
changed it.
I suspect
Subject: [PATCH] optimize /[x]/ to /x/.
From: demerphq <demerphq (AT) gmail (DOT) com>
Date: Sat, 20 May 2006 23:16:33 +0200
Message-Id: <@mail.gmail.com>
Yeah, that probably did it. The thing is, id expect the bug to return
if instead of
$text =~ m![t]*!;
we use
$text =~ m![tT]*!;
And a quick check shows the bug is truely gone. Which means my patch
wasnt involved
I think something other did it, too, since this issue isn't limited
to /[ ]/. As commented in utf8_heavy.pl,
cf.
instead of $text =~ m![t]*!,
(1) case-insensitive matching, like $text =~ /t/i
(2) case mapping operation for utf8, like $text = uc($text)
(3) transliteration for utf8, like $text =~ tr/t\x{100}//
(4) matching unicode properties, like $text =~ /\p{Latin}/
also trigger internal calling utf8::SWASHNEW.
And in all cases the bug seems to be gone.
Probably the change of $^H and %^H might concern it, though I must
admit I'm not sure how open.pm does with load_module().
Regards,
SADAHIR Tomoyuki