it turns out perl is totally borked for
That bugs of this level are found only now is telling something about
how much people actually use the Unicode support of Perl. Well, and
something about how suckily I tested it.
The patch below fixes the first case: the fault was in ibcmp_utf8(),
On 7/8/05, Dave Mitchell [EMAIL PROTECTED] wrote:
On Tue, Jun 07, 2005 at 04:28:08PM -, Nicholas Clark wrote:
./perl -Ilib -we '$term = \xe9; $target = \xe9\x{100}; chop $target;
$target =~ /$term/i'
Malformed UTF-8 character (unexpected non-continuation byte 0x00,
immediately after
Dave Mitchell wrote:
On Thu, Jul 07, 2005 at 01:56:39PM +0100, Steve Hay wrote:
Hmm. I just retried this with current blead and I find that it
(apparently) works OK with a debug build, but crashes with a release build.
I can't get it to crash on either type of build (Linux).
:-(
Michael G Schwern wrote:
On Thu, Jul 07, 2005 at 04:17:50PM -, Steve Hay via RT wrote:
Is there genuinely still a bug in File::Basename::basename(), or is it
just that Cygwin's basename(1) isn't entirely representative of what
basename(1) typically does? I'll let someone with a more
On Fri, Jul 08, 2005 at 09:45:32AM +0300, Jarkko Hietaniemi wrote:
it turns out perl is totally borked for
That bugs of this level are found only now is telling something about
how much people actually use the Unicode support of Perl. Well, and
something about how suckily I tested it.
[EMAIL PROTECTED] - Tue May 17 03:40:07 2005]:
Not in all cases. lstat() does not always occur in directories
that don't have any subdirectories.
linux% cd ~/bin # Do not run test with . = dir-with-too-many-files
linux% cat ../temp.pl
use File::Find;
$File::Find::dont_use_nlink =
Michael G Schwern wrote:
basename(1) sez:
The suffix is not stripped if it is identical to the remaining characters
in string.
Which our basename() does not do. This patch makes it do.
As the comments in your code say, the above is what BSD basename(1)
says. However, Cygwin's basename(1)
As Nicholas tells me the format %_ is no longer working in blead, now
one needs to use: % SVf, which is fine but:
1) this change needs to be documented (where?)
2) PPPort.h needs to define:
#define SVf _
so older perls will support it as well
Thank you.
--
Yitzchak Scott-Thoennes wrote:
On Thu, Jul 07, 2005 at 03:05:00PM -0700, Yitzchak Scott-Thoennes wrote:
On Thu, Jul 07, 2005 at 09:45:51AM -0700, Yitzchak Scott-Thoennes wrote:
On Thu, Jul 07, 2005 at 01:07:13PM +0100, Steve Hay wrote:
Yitzchak Scott-Thoennes wrote:
Must document the fact that HvNAME may return 0 (Though I think it'd be
cleaner to return NULL).
--- hv.h.orig 2005-07-08 13:48:31.0 +0300
+++ hv.h2005-07-08 13:49:02.0 +0300
@@ -156,7 +156,8 @@
=head1 Hash Manipulation Functions
=for apidoc Am|char*|HvNAME|HV*
Stas Bekman wrote:
Must document the fact that HvNAME may return 0
It would be nice also to include a description of the situation in which
0 is returned. Can you make sense of it?
#define HvNAME_get(hv)((SvOOK(hv) (HvAUX(hv)-xhv_name)) \
? HEK_KEY(HvAUX(hv)-xhv_name) : 0)
At the moment ithreads.xs store the special ithreads struct in modglobal's
magic, which is slow to get/set and it requires aTHX (setting of which
again slows things down). mod_perl2 has the same needs and so far was
using the unused HvPMROOT entry in HV which was recently nuked, and we
don't
Michael,
I´m not attempting to read in the entire file
In an older version of my AIX O.S. this message Out Of Memory wasn´t
ocurring, with the same machine, with the same program
It happens when:
open (FILE, file.txt);
while (FILE) {
blead complains about Perl_form(aTHX_ Perl/v%vd, PL_patchlevel));
mod_perl.c:700: warning: unknown conversion type character `v' in format
why doesn't it work anymore? what format should I use instead? SVf?
I see:
PL_patchlevel = Perl_newSVpvf(...)
so may be:
Perl_form(aTHX_ Perl/v% SVf,
Steve Hay wrote:
Stas Bekman wrote:
Must document the fact that HvNAME may return 0
It would be nice also to include a description of the situation in which
0 is returned. Can you make sense of it?
#define HvNAME_get(hv)((SvOOK(hv) (HvAUX(hv)-xhv_name)) \
?
On Fri, Jul 08, 2005 at 09:24:42AM +0200, demerphq wrote:
it turns out perl is totally borked for
$utf8 =~ /latin1/i
and
$latin1 =~ /$utf8/i
unless all the chars happen to be 0x7f.
The case where the pattern is /(foo|bar)/ is handled by a totally
different codepath
Automated smoke report for 5.9.3 patch 25095
fixit.xs4all.nl: Pentium II (i386/1 cpu)
onbsd/os - 4.1
using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
smoketime 3 hours 56 minutes (average 1 hour 58 minutes)
Summary: FAIL(F)
O = OK F = Failure(s), extended
On Fri, Jul 08, 2005 at 02:07:13PM +0300, Stas Bekman wrote:
1) it should be set/get-able w/o requiring aTHX (or global context)
2) it must be not touched by perl (e.g. make perl_clone not touch it)
we can start working with ithreads.xs to replace its Perl_ithread_set/get
functions and
On 7/8/05, Dave Mitchell [EMAIL PROTECTED] wrote:
On Fri, Jul 08, 2005 at 09:24:42AM +0200, demerphq wrote:
it turns out perl is totally borked for
$utf8 =~ /latin1/i
and
$latin1 =~ /$utf8/i
unless all the chars happen to be 0x7f.
The case where the pattern is
Dave Mitchell wrote:
On Fri, Jul 08, 2005 at 02:07:13PM +0300, Stas Bekman wrote:
1) it should be set/get-able w/o requiring aTHX (or global context)
2) it must be not touched by perl (e.g. make perl_clone not touch it)
we can start working with ithreads.xs to replace its
If you are reading the entire file and stuffing it into a hash (or
other data structure, even after transformations), it still consumes
memory proportional to the file size (or at least to the final size of
$key and $value in your example). When Michael said read one line at
a time, I think he
Michael G Schwern wrote:
Yitzak outlined a way to determine case-sensitivity in a read-only fashion.
It basically boils down to:
1. Find a file or directory with [A-Za-z] in it.
2. Change the case of a few of those letters.
3. Check to see if it exists.
Hmmm, with some
Stas Bekman wrote:
blead complains about Perl_form(aTHX_ Perl/v%vd, PL_patchlevel));
mod_perl.c:700: warning: unknown conversion type character `v' in format
why doesn't it work anymore? what format should I use instead? SVf?
I'm investigating. However PL_patchlevel in blead is a version
John Peacock wrote:
Stas Bekman wrote:
blead complains about Perl_form(aTHX_ Perl/v%vd, PL_patchlevel));
mod_perl.c:700: warning: unknown conversion type character `v' in format
why doesn't it work anymore? what format should I use instead? SVf?
I'm investigating. However PL_patchlevel in
On 7/6/05, Ken Williams [EMAIL PROTECTED] wrote:
On Jul 6, 2005, at 4:00 PM, Dinger, Tom wrote:
To be perfectly honest, I don't care which way it is fixed, as long
as the
result still points to the right file.
Of course. That's what I'm asking: is bar guaranteed on Windows to
be
On Jul 8, 2005, at 8:51 AM, yves orton via RT wrote:
Im not sure if this is useful, but many of the things that File::Spec
tries to do on win32 are actually supported directly by the Win32 API.
IMO at least some of File::Spec's behaviour could take advantage of
this API.
Yeah, very true.
On 7/8/05, Dave Mitchell [EMAIL PROTECTED] wrote:
On Fri, Jul 08, 2005 at 09:24:42AM +0200, demerphq wrote:
it turns out perl is totally borked for
$utf8 =~ /latin1/i
and
$latin1 =~ /$utf8/i
unless all the chars happen to be 0x7f.
The case where the pattern is
Jim Cromie wrote:
Marcus Holland-Moritz wrote:
On 2005-06-23, at 14:42:21 +0100, Nicholas Clark wrote:
On Fri, Jun 17, 2005 at 09:55:37PM -0600, Jim Cromie wrote:
I left the api-pod as is, since folks shouldnt be encouraged to choose
5.9 over compatibility.
Stas Bekman wrote:
blead complains about Perl_form(aTHX_ Perl/v%vd, PL_patchlevel));
mod_perl.c:700: warning: unknown conversion type character `v' in format
Now, wait a second! That error is being thrown by _GCC_, not Perl.
That has been emitted ever since '-Wall' was turned on, AFAICT
John Peacock wrote:
Stas Bekman wrote:
blead complains about Perl_form(aTHX_ Perl/v%vd, PL_patchlevel));
mod_perl.c:700: warning: unknown conversion type character `v' in format
Now, wait a second! That error is being thrown by _GCC_, not Perl. That
has been emitted ever since '-Wall' was
Stas Bekman wrote:
I don't think so. It doesn't happen with any perl 5.9.3.
I can't explain why gcc would suddenly take such a keen interest in
Perl's internal format strings. The warning can be safely ignored and
the %vd code works fine. Perhaps it is something to do with the
John Peacock wrote:
Stas Bekman wrote:
I don't think so. It doesn't happen with any perl 5.9.3.
I can't explain why gcc would suddenly take such a keen interest in
Perl's internal format strings. The warning can be safely ignored and
the %vd code works fine. Perhaps it is something to
Rafael Garcia-Suarez [EMAIL PROTECTED] writes:
On 7/5/05, Nick Ing-Simmons [EMAIL PROTECTED] wrote:
Probing for existing libz (shared or not) would help those of us
the embed perl in other things which already link zlib.
But IIUC zlib is embedded in a shared extension, not in perl itself.
Michael G Schwern [EMAIL PROTECTED] writes:
On Wed, Jul 06, 2005 at 11:12:03AM -0400, Scott R. Godin wrote:
I was surprised to find that Date::Parse actually had these value limits
hard-coded into itself and wasn't utilizing the underlying library
functions to determine its acceptable ranges
Ken Williams [EMAIL PROTECTED] writes:
On Jul 6, 2005, at 11:29 AM, Michael G Schwern via RT wrote:
[tomdinger - Tue Feb 24 10:15:24 2004]:
Under Windows (using File::Spec::Win32), the call
File::Spec-canonpath('a\\..\\..\\b\\c') returns the wrong value:
'b\\c'.
It should return '..\\b\\c'.
Glenn Linderman [EMAIL PROTECTED] writes:
5. verify that an entry with that modification doesn't already exist
attempt to stat the entry with the modified name, if it works as with
the unmodified name, then the file system is case insensitive.
Or someone created it since you verified it wasn't
gcc -Wall (or gcc -Wformat) complain about %vd and %_ because the
functions they are used in now have an attribute that says they
expect format strings. This attribute used to be conditional on
-DCHECK_FORMAT but that was removed: when VDf (='vd') was
removed and SVf was changed from '_' to a
Rajarshi Das [EMAIL PROTECTED] writes:
I run the following on an ebcdic platform
(perl-5.8.6),
$BOM = chr(0xFEFF);
open(UTF_PL, :raw:encoding(utf16le), utf.pl)
or die utf.pl($enc,$tag): $!;
print UTF_PL $BOM;
print UTF_PL 1;
should the data that is written using PerlLIO_write,
be \xFF
Robin Barker wrote:
Previously -DCHECK_FORMAT defined VDf + SVf differently, to
avoid the warnings and allow -Wformat to check the formats.
Patches welcome??? I'm already fighting a difference between how GCC
3.x and 4.x deal with multiple '-I' directives that is keeping
version.pm from
Michael G Schwern [EMAIL PROTECTED] writes:
On Fri, Jul 08, 2005 at 12:12:44AM +0200, Abigail wrote:
That's not going to work on a file system that's mounted read-only.
Yitzak outlined a way to determine case-sensitivity in a read-only fashion.
It basically boils down to:
1. Find a file
John Peacock [EMAIL PROTECTED] writes:
Stas Bekman wrote:
I don't think so. It doesn't happen with any perl 5.9.3.
I can't explain why gcc would suddenly take such a keen interest in
Perl's internal format strings.
Because someone went round putting in __attribute__((printf,...))
in?
Robin Barker wrote:
Previously -DCHECK_FORMAT defined VDf + SVf differently, to avoid the
warnings and allow -Wformat to check the formats.
Ah ha, that's why you know what's going on! It's your fault...
http://public.activestate.com/cgi-bin/perlbrowse?patch=23767
;-)
John
--
John
Glenn Linderman [EMAIL PROTECTED] writes:
On approximately 7/8/2005 12:22 PM, came the following characters from
the keyboard of Nick Ing-Simmons:
Glenn Linderman [EMAIL PROTECTED] writes:
5. verify that an entry with that modification doesn't already exist
attempt to stat the entry with the
Heya,
I got bitten by this bug today. I'm not altogether satisfied by the
last and only comment on the bug, which summarizes to but there's a
workaround, so it's not perl's fault!
Attached is a patch which restores $@ after any DESTROY blocks have
run.
- Alex
--
Networking -- only one
On Fri, Jul 08, 2005 at 09:35:42AM -0300, Adriano Ferreira wrote:
If your algorithm needs the $hash constructed by
$hash {$key} = $value;
to hold considerable amounts of the info provided in the original
file, you need memory anyway. Some simple algorithms don't scale
Automated smoke report for 5.9.3 patch 25098
kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu)
onlinux - 2.6.12-3-686 [debian]
using cc version 4.0.1 20050701 (prerelease) (Debian 4.0.0-12ubuntu2)
smoketime 5 hours 18 minutes (average 39 minutes 46
On Fri, Jul 08, 2005 at 08:57:37PM +0100, Nick Ing-Simmons wrote:
Yes, and you could reverify that it still isn't there, and then of
course, that could mean that someone deleted it since you discovered it
was there.
And if the someone else was perl doing a write style probe
that becomes
On Fri, Jul 08, 2005 at 03:50:49PM +0200, demerphq wrote:
Im not sure if this is useful, but many of the things that File::Spec
tries to do on win32 are actually supported directly by the Win32 API.
IMO at least some of File::Spec's behaviour could take advantage of
this API.
On 7/8/05, Michael G Schwern [EMAIL PROTECTED] wrote:
On Fri, Jul 08, 2005 at 03:50:49PM +0200, demerphq wrote:
Im not sure if this is useful, but many of the things that File::Spec
tries to do on win32 are actually supported directly by the Win32 API.
IMO at least some of File::Spec's
On Fri, Jul 08, 2005 at 11:07:22PM +0200, demerphq wrote:
should be testing here, but i beleive the problem you are thinking of
is due to symlinks to a directory? If so then the win32 equivelent
would be a junction I think and in that case yes, foo\..\bar == bar.
I have the creeping feeling
On Fri, Jul 08, 2005 at 02:03:33PM -0700, Glenn Linderman wrote:
And if the someone else was perl doing a write style probe
that becomes both cases are quite likely if OS yields CPU on system calls.
No, I disagree there. A write style probe should create a new name,
unequal to any other
On Thu, Jul 07, 2005 at 07:56:39PM -0500, Steve Peters wrote:
On Fri, Jul 08, 2005 at 12:33:21AM +0200, Abe Timmerman wrote:
Op een mooie zomerdag (Friday 08 July 2005 01:03),schreef Abe Timmerman:
...
The t/io/*.t failures (on all mij bsd/darwin systems) do not show up if I
run
the
On 7/8/05, Michael G Schwern [EMAIL PROTECTED] wrote:
On Fri, Jul 08, 2005 at 11:07:22PM +0200, demerphq wrote:
should be testing here, but i beleive the problem you are thinking of
is due to symlinks to a directory? If so then the win32 equivelent
would be a junction I think and in that
On Fri, Jul 08, 2005 at 02:46:37PM -0700, Glenn Linderman wrote:
And why would perl be doing both styles of probes in the same directory
at the same time anyway?
Multiple processes running the same program doing the same thing. Only
happens very, very rarely, like say in a CGI program. :P
On 7/8/05, Glenn Linderman [EMAIL PROTECTED] wrote:
On approximately 7/8/2005 1:53 PM, came the following characters from
the keyboard of Michael G Schwern:
On Fri, Jul 08, 2005 at 03:50:49PM +0200, demerphq wrote:
Im not sure if this is useful, but many of the things that File::Spec
-Original Message-
From: John Peacock
Cc: Robin Barker; 'The Perl5 Porters Mailing List '
Sent: 08/07/05 20:43
Subject: Re: blead: no longer supports %vd format
Robin Barker wrote:
Previously -DCHECK_FORMAT defined VDf + SVf differently, to avoid the
warnings and allow -Wformat
On Jul 8, 2005, at 4:26 PM, Michael G Schwern wrote:
On Fri, Jul 08, 2005 at 11:07:22PM +0200, demerphq wrote:
should be testing here, but i beleive the problem you are thinking of
is due to symlinks to a directory? If so then the win32 equivelent
would be a junction I think and in that case
On Fri, Jul 08, 2005 at 11:49:59PM +0200, demerphq wrote:
canonpath() should never be inserting the CWD when cleaning up. ./bar is
the same as bar but $CWD/bar is not! Its important that cannonical
relative paths remain relative.
Sorry, i guess I didnt express myself properly. You cant
On Jul 8, 2005, at 4:50 PM, yves orton via RT wrote:
Sorry, i guess I didnt express myself properly. You cant clean up a
relative path properly without knowing where it is relative to.
Consider the following path:
..\..\foo
If we are in \bar then ..\..\foo is the same as ..\foo and \foo
I'm not wedded to the name, but attached is a proof-of-concept of a routine
which collapses updirs. This is a solution to the problem whether or not
canonpath() should collapse them. Let the user decide.
0 ~$ perl -w ~/tmp/foo.plx '../../bar'
../../bar
0 ~$ perl -w ~/tmp/foo.plx 'foo/../../bar'
If in sv_setuv, I take this out:
if (u = (UV)IV_MAX) {
sv_setiv(sv, (IV)u);
return;
}
so that everything ends up here:
sv_setiv(sv, 0);
SvIsUV_on(sv);
SvUV_set(sv, u);
Then Data::Dumper's tests fail.
(This is doing the change after building perl. I think that
On Fri, Jul 08, 2005 at 03:30:26PM -0700, Michael G Schwern wrote:
There are some problems in Win32 and they look like they're due to
File::Spec bugs.
0 ~$ perl -w ~/tmp/foo.plx 'C:\foo\..\..\..\bar' Win32
C:bar
This is because:
0 ~$ perl -MFile::Spec::Win32 -wle 'print join \n,
Robin Barker wrote:
My 23767 (and a few later patches) kept the -Wformat checking hacks hidden
behind -DCHECK_FORMAT. The only change relevant to %vd is the
final hack which removed the VDf macro (usually defined as vd)
because your patches had removed all appearances from the sources.
But
Automated smoke report for 5.9.3 patch 25098
mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB
L2 cache) (i386/1 cpu)
onopenbsd - 3.7
using cc version 3.3.5 (propolice)
smoketime 8 hours 28 minutes (average 1 hour 3 minutes)
Summary: FAIL(XF)
O
Automated smoke report for 5.9.3 patch 25101
TANGAROA.uk.radan.com: Intel(R) Pentium(R) 4 CPU 2.00GHz(~1992 MHz) (x86/1 cpu)
onMSWin32 - WinXP/.Net SP1
using cl version 12.00.8804
smoketime 2 hours 44 minutes (average 5 minutes 9 seconds)
Summary: FAIL(M)
O = OK F =
Here is the program that segfaults with both perl-5.8.0 from debian as
well as with my own perl-5.8.1 MAINT19040:
# just get the test data into $data
use LWP::Simple;
$data = get http://data.plan9.de/macbeth.xml;;
# the segfault occurs on the second round (i think) in the
How trivial is it to add a ?{ } block that is executed with the
same semantics as ?{ }, except that instead of running when the
engine matches over it, it gets run as the engine backtracks over
it?
my $thing = qr/
?{ do_something() }
?{ undo_it() }
$try_this_pattern
/x;
Automated smoke report for 5.9.3 patch 25101
kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu)
onlinux - 2.6.12-3-686 [debian]
using cc version 4.0.1 20050701 (prerelease) (Debian 4.0.0-12ubuntu2)
smoketime 5 hours 10 minutes (average 38 minutes 45
68 matches
Mail list logo
