Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
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(),
Looks good, off-hand. (Feel free to quote me on haggis, though.)
which was calling to_utf8_fold() without first converting the char to
utf8.
The second case fails in S_find_byclass() in regexec.c:
while (s = e) {
if ( (*(U8*)s == c1 || *(U8*)s == c2)
(ln == 1 || !(OP(c) == EXACTF
? ibcmp(s, m, ln)
: ibcmp_locale(s, m, ln)))
(norun || regtry(prog, s)) )
goto got_it;
s++;
}
where it calls ibcmp() but s is a pointer to a latin1 while m is pointer
to a utf8 char. I don't really understand this code well enough to feel
confident fixing it.
I won't have time to look into this anytime soon, but I think the fix
for the second case shouldn't be too hard to find. First of all, if
either the matcher or the matchee are UTF-8, we should never ever ever
end up calling the bare ibcmp(), but instead ibcmp_utf8() with the right
combination of flags to indicate which or both is UTF-8.
You might want to extend the tests also to run-time:
my $utf8 = \x{e9}\x{100}; chop $utf8;
my $latin1 = \x{e9};
ok($utf8 =~ /\xe9/i);
ok(\xe9 =~ /$utf8/i);
ok($utf8 =~ /$latin1/i);
ok($latin1 =~ /$utf8/i);
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
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 start byte 0xe9) in pattern match (m//) at -e line 1.
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 in blead, does it also fail there? I seem to recall
that I put in tests for this, but possibly im wrong. Im flying on
holiday in less than 24 hours and i doubt Ill be able to check until i
return at the end of the month.
cheers,
yves
--
perl -Mre=debug -e /just|another|perl|hacker/
Re: Scalar leaked in 'local $0' under ithreads + taint mode
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). :-( Fortunately, release builds on Win32 have debugging symbols anyway (since they are stored in separate files), so I am able to get a stack trace: win32_checkTLS(interpreter * 0x73204441) line 57 PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string') line 454 + 19 bytes PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494, clone_params * 0x0140fc80) line 643 perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem * 0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv * 0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir * 0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383 perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67 bytes perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes Perl_ithread_create(interpreter * 0x, sv * 0x, char * 0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes XS_threads_new(interpreter * 0x0002, cv * 0x018a83f4) line 687 + 32 bytes Perl_pp_entersub(interpreter * 0x01234494) line 2789 Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes perl_run(interpreter * 0x00234494) line 2160 + 10 bytes RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes PERL! mainCRTStartup + 227 bytes KERNEL32! 77e8141a() threads-new() tries to clone an intepreter; this calls PerlIO_clone(), which calls PerlIO_debug(), which tries to get the value (if any) of the env var PERLIO_DEBUG. At this point it jumps into windows-specific code, where it then crashes. Does it still fail after change 25094? I'm pretty much clutching at straws here, but that does hapen to fix an unrelated bug associated with doing 'local $0' No, it still crashes with much the same stack trace. The crash is deliberately forced by win32_checkTLS(), but I don't understand for what reason. PerlEnvGetenv() takes an IPerlEnv* and uses the IPERL2HOST() macro (which is set to IPerlEnv2Host()) to locate the CPerlHost* which that IPerlEnv* is a member of. It then calls win32_checkTLS() to check that the host_perl in the CPerlHost* that has been found is my_perl. Evidently, in this case host_perl != my_perl, so it bombs out. Does anyone know what this my_perl is? What is the purpose of the host_perl != my_perl check, and why might it be failing? 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.
Re: [perl #36477] File::Basename basename() bug
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 traditional Unixy system available answer that one. Its a bug. Patch attached. Thanks - applied as change 25096. 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.
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
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. The bugs are actually subtle in that they are in the mixed bytes (mumble Latin 1)/UTF-8 code. People could be quite happily using the Unicode support, where all their input data is already in UTF-8, or is in (say) Shift-JIS and hence has to be converted on input, and hence never have cause to go down these code paths. Nicholas Clark
[perl #35847] File::Find not performing as documented
[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 = $ARGV[0];
my @files;
find sub { push @files, $File::Find::name if -f _ /\.pm$/ }, @INC;
print join \n, @files,'';
linux% perl ../temp.pl 0 | wc -l
434
linux% perl ../temp.pl 1 | wc -l
943
linux% perl -v
This is perl, v5.8.3 built for i586-linux
I am unable to replicate this problem with either 5.8.1, 5.8.6 or
[EMAIL PROTECTED] I don't have a 5.8.3 handy to try.
Re: [PATCH] basename() and suffixes
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) [basename (GNU sh-utils) 2.0.15] simply says: SYNOPSIS basename NAME [SUFFIX] DESCRIPTION Print NAME with any leading directory components removed. If specified, also remove a trailing SUFFIX. which implies that trailing suffices will be stripped regardless, but in fact it does honour the special behaviour described in BSD: C:\p5p\bleadperl\cygwin\bin\basename .foo .foo .foo so I've applied your patch as change 25097. Thanks. I updated the docs to mention this change too since otherwise the docs were lying that @suffixes work as in fileparse() (except for the regex metacharacter quoting). I also thought that it was worth mentioning since my basename(1) docs don't actually mention this behaviour, so simply referring the user to them wouldn't have helped. 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.
blead: the format %_ to % Svf change
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. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Pod::Html - correctly link to =item's on the same page
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: On Tue, Jul 05, 2005 at 06:22:02PM +0100, Steve Hay wrote: So I've applied your patch, together with my test (marked as TODO since it currently fails) as change 25083. Note that it is all one test, though, so the newly fixed bit isn't actually being tested until the TODO gets resolved :-( Thanks! Here's a patch to switch the links in perlglossary back to L instead of C, plus some other minor corrections, and restoring some of Larry's original prose where I'd fiddled with it to make the C links work. podchecker emits tons of warnings and errors after applying the patch. There were no warnings or errors before :-( Any chance you could fix it up and resend? Argg. Forgot that Pod::Html is more permissive than podchecker. I'm guessing these are Lfoo where there should be L/foo. I'll fix them and resend in a while. Here's another try; passes podchecker this time :) And now with attachment :) Thanks - applied as change 25098. I still had couple of warnings from podchecker -warnings -warnings ;-) They all related to unescaped , which I think I've sorted out. There is also one warning left about multiple occurrence of link target 'C', which I think arises from the =head2 C and the =item C. Couldn't think how to get out of that one so I left it. 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.
[patch hv.h doc] HvNAME
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* stash -Returns the package name of a stash. See CSvSTASH, CCvSTASH. +Returns the package name of a stash (may return 0). See +CSvSTASH, CCvSTASH. =for apidoc Am|void*|HeKEY|HE* he Returns the actual pointer stored in the key slot of the hash entry. The -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [patch hv.h doc] HvNAME
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) 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.
blead: new entry in the interperter for storing special contexts like ithreads?
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 want to significantly slow down the performance for 5.10 users in the threaded environment. I believe since we have at least 2 projects that require this functionality, the perl interpreter should have this functionality, instead of relying on the unused slots which can go away any moment as it was the case with HvPMROOT. Again the requirements is to have a plain pointer entry which is attached to each interpreter, but not touched by perl: 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 then apply that to mod_perl2 as well. The solution is to just add a new entry to my_perl. The question is what happens if more than one project wants to use that entry? There is no collision at the moment since mod_perl2's interpeters aren't touched by ithreads and the other way around, but may be in the future there will be such a need? Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RES: [perl #27764] Out Of Memory Problem
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) {
#
# CALCS #
#
$hash {$key} = $value;
};
close FILE;
Thanks for your attention!
ATT
Eduardo Mattos Ramos Murad
Telemar - TI - Data Warehouse
* 031 (21) 3131-9120
* [EMAIL PROTECTED]
-Mensagem original-
De: Michael G Schwern via RT [mailto:[EMAIL PROTECTED]
Enviada em: sexta-feira, 8 de julho de 2005 07:37
Para: Eduardo Mattos Ramos Murad
Assunto: [perl #27764] Out Of Memory Problem
[EMAIL PROTECTED] - Fri Mar 19 05:13:55 2004]:
Everytime I try to work with Large Files I get the message Out Of
Memory, is
there anyway to configure
Perl in my server Unix Aix ver 5.2 not to give this messages anymore?
Are you, perhaps, attempting to read in the entire file into memory at
once? Something like:
my @lines = LARGE_FILE;
would likely consume all memory. You should read one line at a time.
while(my $line = LARGE_FILE) {
...
}
Esta mensagem, incluindo seus anexos, pode conter informações privilegiadas
e/ou de caráter confidencial, não podendo ser retransmitida sem autorização do
remetente. Se você não é o destinatário ou pessoa autorizada a recebê-la,
informamos que o seu uso, divulgação, cópia ou arquivamento são proibidos.
Portanto, se você recebeu esta mensagem por engano, por favor, nos informe
respondendo imediatamente a este e-mail e em seguida apague-a.
blead: no longer supports %vd format
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, PL_patchlevel)); but again, why '%vd' is not documented that it's not there anymore. and in general where do I find a pod which documents all the supported extensions to the printf/form format? Thanks -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [patch hv.h doc] HvNAME
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)) \
? HEK_KEY(HvAUX(hv)-xhv_name) : 0)
I was expecting that it'll return not 0, but Nicholas says it should be 0.
I had to change the mod_perl code:
-modperl_mgv_new_name(handler-mgv_obj, p, HvNAME(stash));
+char *name = HvNAME(stash);
+if (!name) {
+name = ;
+}
+modperl_mgv_new_name(handler-mgv_obj, p, name);
as the compiler was emitting warnings about strlen(HvNAME(stash)) getting
an argument of 0 (only in blead perl)
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
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 in blead, does it also fail there? I seem to recall
that I put in tests for this, but possibly im wrong. Im flying on
holiday in less than 24 hours and i doubt Ill be able to check until i
return at the end of the month.
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if $x=~/(abc|\xe9)/i'
1
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if \xe9=~/(abc|$x)/i'
Malformed UTF-8 character (unexpected non-continuation byte 0x00, immediately
after start byte 0xe9) in pattern match (m//) at -e line 1.
--
Never do today what you can put off till tomorrow.
Smoke [5.9.3] 25095 FAIL(F) bsd/os 4.1 (i386/1 cpu)
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 report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25095 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: blead: new entry in the interperter for storing special contexts like ithreads?
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 then apply that to mod_perl2 as well. The solution is to just add a new entry to my_perl. But my_perl is just aTHX, so you *would* require aTHX (or dTHX). The question is what happens if more than one project wants to use that entry? There is no collision at the moment since mod_perl2's interpeters aren't touched by ithreads and the other way around, but may be in the future there will be such a need? How about (by analogy to mg), the new field in my_perl is a pointer to a linked list of structs that have 3 fields: data, fn, next data is a void * where you can put your private data; fn is a pointer to a function that is is called by perl_clone to clone the structure; it is also used as an identifier to disambiguate different users of the list. It would be wrapped in a simple API to add/delete an entry, or retrieve the data, eg PERL_INTERPRETER_DATA_ADD(data,my_func); data = PERL_INTERPRETER_DATA_GET(my_func); PERL_INTERPRETER_DATA_DELETE(my_func); -- I do not resent critisism, even when, for the sake of emphasis, it parts for the time with reality. -- Winston Churchill, House of Commons, 22nd Jan 1941.
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
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 /(foo|bar)/ is handled by a totally
different codepath in blead, does it also fail there? I seem to recall
that I put in tests for this, but possibly im wrong. Im flying on
holiday in less than 24 hours and i doubt Ill be able to check until i
return at the end of the month.
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if $x=~/(abc|\xe9)/i'
1
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if \xe9=~/(abc|$x)/i'
Malformed UTF-8 character (unexpected non-continuation byte 0x00,
immediately after start byte 0xe9) in pattern match (m//) at -e line 1.
Well, i guess half wrong is better than all wrong but that still
sucks. Maybe ill get some time to put together a patch on the plane.
thanks tho.
--
perl -Mre=debug -e /just|another|perl|hacker/
Re: blead: new entry in the interperter for storing special contexts like ithreads?
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 Perl_ithread_set/get functions and then apply that to mod_perl2 as well. The solution is to just add a new entry to my_perl. But my_perl is just aTHX, so you *would* require aTHX (or dTHX). sorry, I was talking about the interprter, not how it's accessed. e.g. Perl_Imodglobal_ptr(thx) requires no live perl context, all I need is a pointer to it. The question is what happens if more than one project wants to use that entry? There is no collision at the moment since mod_perl2's interpeters aren't touched by ithreads and the other way around, but may be in the future there will be such a need? How about (by analogy to mg), the new field in my_perl is a pointer to a linked list of structs that have 3 fields: data, fn, next data is a void * where you can put your private data; fn is a pointer to a function that is is called by perl_clone to clone the structure; it is also used as an identifier to disambiguate different users of the list. will it work w/o needing PERL_SET_CONTEXT(aTHX)? It would be wrapped in a simple API to add/delete an entry, or retrieve the data, eg PERL_INTERPRETER_DATA_ADD(data,my_func); data = PERL_INTERPRETER_DATA_GET(my_func); PERL_INTERPRETER_DATA_DELETE(my_func); Sounds good. Most of the time we won't want perl_clone to do any cloning on it, since every new interpreter will want to set an explicit new value. so I'd think that perl_clone should always NULL it, no? in which case there is no need for a function (besides the identifier to find the entry in the linked list). -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: RES: [perl #27764] Out Of Memory Problem
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 meant also to process each line at a time, giving
the opportunity to Perl let go the bits that it don't need anymore.
For example,
my ($key, $value);
while (FILE) {
($key, $value) = $_ =~ /(\w+): (.*)/;
print key: $key, value: $value\n
};
does not have such problem, because as soon the print is done, it is
time to replace the objects in $_, $key, $value by others, with few
objects at memory at all times. The same with:
my $maxkey = '';
my $sum = 0;
while (FILE) {
my ($key, $value) = $_ =~ /(\w+): (.*)/;
$sum += $value;
$maxkey = $key if $maxkey $key
};
because the information is being aggregated into few variables (in
this case, $maxkey and $sum). (Of course, the two examples above may
not resemble a real-world application, but they illustrate the issue.)
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 well,
which is common when the input data grows at a fast pace. Maybe you
should consider alternative approaches to break your calculations into
manageable bits that fit the computer memory. If it runs in another OS
version, differences may be blamed to different memory comsuption
between these versions, differences between the compiled Perl
interpreters, and whatever else. Try to look to the patterns of memory
requirements of the Perl script at the two machines. ETL scripts can
be hogs and database issues can also come into scene.
Regards,
Adriano.
On 7/8/05, Eduardo Mattos Ramos Murad [EMAIL PROTECTED] wrote:
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) {
#
$hash {$key} = $value;
};
close FILE;
De: Michael G Schwern via RT [mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED] - Fri Mar 19 05:13:55 2004]:
Everytime I try to work with Large Files I get the message Out Of
Memory, is
Are you, perhaps, attempting to read in the entire file into memory at
once? Something like:
RE: [PATCH] Further lies in the File::Basename docs
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 intelligent check to make sure that A.a and a.a aren't both there as different files, I guess? Otherwise a case sensitive directory would be misdiagnosed as insensitive. I suppose if the file found in step 1 is A.a, a glob could be done on [Aa].a and the result count checked... -- Mike Giroux rmgiroux (at) acm (point) org
Re: blead: no longer supports %vd format
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 object (sort of), so I need to make sure that still works the way you expect it to. I didn't remove %vd support (though I did alter it so that for version objects, it is equivalent to %s). I just realized that may not work on PL_patchlevel, however, since that is a version object in form, but not in name. It happens that at the time that PL_patchlevel is created, there is no name stash in existence, and hence the bless into the version class has no effect. It just occurred to me that I can actually go back to storing PL_patchlevel as a v-string and just elevate it to a version object when needed (during output for $^V and $] or comparing). I'll work on a patch (I'm syncing blead right now). John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: blead: no longer supports %vd format
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 blead is a version object (sort of), so I need to make sure that still works the way you expect it to. I didn't remove %vd support (though I did alter it so that for version objects, it is equivalent to %s). I just realized that may not work on PL_patchlevel, however, since that is a version object in form, but not in name. It happens that at the time that PL_patchlevel is created, there is no name stash in existence, and hence the bless into the version class has no effect. It just occurred to me that I can actually go back to storing PL_patchlevel as a v-string and just elevate it to a version object when needed (during output for $^V and $] or comparing). I'll work on a patch (I'm syncing blead right now). so those might be two different issues. In any case I'm now using the following workaround: #if PERL_REVISION == 5 PERL_VERSION 9 #define MP_PERL_VERSION_STAMP Perl/v%vd #else #define MP_PERL_VERSION_STAMP Perl/% SVf #endif [...] Perl_form(aTHX_ MP_PERL_VERSION_STAMP, PL_patchlevel)); -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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 the right file when the input is foo\\..\\bar? On Unix, it's
not.
I've never disputed the bug. The current behavior is obviously wrong.
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.
Win32::GetFullPathName() is the one i have in mind when I say this.
perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]);
outputs CWD\bar.
So if you strip off the CWD from the result of
Win32::GetFullPathName() you get the OS'es solution of this problem,
which should bypass all of these issues. Ie, crudely:
use Win32;
use Cwd qw(cwd);
sub canonpath {
my $path=shift;
$ret=Win32::GetFullPathName($path);
if ($path!~/^\w:/) {
(my $cwd=cwd()./)=~s!/!\\!g;
while (substr($cwd,0,1) eq substr($ret,0,1)) {
substr($cwd,0,1,);
substr($ret,0,1,);
}
}
return $ret;
}
print canonpath(foo/../../../bar/baz);
BTW, i say crudely, because I dont think that canonpath is very well
defined. Is it a relative path or not? Should it function differently?
Likewise, File::Spec::rel2abs() should be rewritten to be a
passthrough to Win32::GetFullPathName().
Anyway, the point is that using Win32::GetFullPathName() is available
to resolve a bunch of these issues (at least as far as Win32 goes).
Yves
--
perl -Mre=debug -e /just|another|perl|hacker/
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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. However, the Win32 docs say that GetFullPathName() first appeared in perl 5.6, so before that we'd still need to emulate. Alternatively, we could add an XS implementation of it for 5.005 on Windows, since the underlying C API should be available. BTW, i say crudely, because I dont think that canonpath is very well defined. Is it a relative path or not? If the input is relative, the output is relative. If the input is absolute, the output is absolute. Likewise, File::Spec::rel2abs() should be rewritten to be a passthrough to Win32::GetFullPathName(). True. The only problem is that it'll make it harder for me to test, because I don't test on Windows. Your basic point is well-taken, though - we should indeed use Win32::* stuff whenever appropriate. -Ken
Re: [perl #36207] UTF8/Latin 1/i regexp Malformed character warning
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 /(foo|bar)/ is handled by a totally
different codepath in blead, does it also fail there? I seem to recall
that I put in tests for this, but possibly im wrong. Im flying on
holiday in less than 24 hours and i doubt Ill be able to check until i
return at the end of the month.
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if $x=~/(abc|\xe9)/i'
1
$ ./perl -Ilib -wle '$x=\xe9\x{100};chop$x; print 1 if \xe9=~/(abc|$x)/i'
Malformed UTF-8 character (unexpected non-continuation byte 0x00, immediately
after start byte 0xe9) in pattern match (m//) at -e line 1.
Attached patch fixes it in the TRIE(FL?)? code afaict.
D:\dev\perl\liveperl -Ilib -wle $x=qq[\xe9\x{100}]; chop $x; print 1
if qq[\xe9]=~/(abc|$x)/i
1
D:\dev\perl\liveperl -Ilib -wle $x=qq[\xe9\x{100}]; chop $x; print 1
if $x=~/(abc|\xe9)/i
1
Yves
--
perl -Mre=debug -e /just|another|perl|hacker/
--- regexec.c.bak 2005-07-08 17:02:45.171875000 +0200
+++ regexec.c 2005-07-08 17:03:02.15625 +0200
@@ -2612,7 +2612,7 @@
if ( base ) {
- if ( do_utf8 || UTF ) {
+ if ( do_utf8 ) {
if ( foldlen0 ) {
uvc = utf8n_to_uvuni( uscan, UTF8_MAXLEN, len, uniflags );
foldlen -= len;
@@ -2678,7 +2678,7 @@
if ( base ) {
- if ( do_utf8 || UTF ) {
+ if ( do_utf8 ) {
uvc = utf8n_to_uvuni( (U8*)uc, UTF8_MAXLEN, len, uniflags );
} else {
uvc = (U32)*uc;
Re: janitorial work ? [patch]
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. But isn't that what Devel::PPPort is for? Providing edible cake. Yes. :-) Marcus heres that patch again, in 2 pieces. 1. bzipped changes New - Newx, New? - Newx? also includes macros for old x-less New, so that XS code continues to work wo src changes. Theres XS out there that doesnt package ppport.h 2. patch to API pod in handy.h docs the x-less version, adds 3 lines explaining the x-version. I dont much care whether the 3 lines survive peer-review, it looks like I can just truncate the patch and it will still apply. Thanks - applied both patches as change 25101. I reverted all the changes to the dual-lived modules since they must still work with older perls too. It is best to wait for Marcus to release a new Devel::PPPort and then those modules that use ppport.h can update after that. 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.
Re: blead: no longer supports %vd format
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 (indeed if I take it out of cflags and OPTIMIZE, the warning is not emitted). This isn't bleadperl's problem so much as GCC being too smart for its own good... John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: blead: no longer supports %vd format
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 turned on, AFAICT (indeed if I take it out of cflags and OPTIMIZE, the warning is not emitted). This isn't bleadperl's problem so much as GCC being too smart for its own good... I don't think so. It doesn't happen with any perl 5.9.3. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: blead: no longer supports %vd format
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 constification? John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: blead: no longer supports %vd format
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 do with the constification? Because perl doesn't take care of substituting it. It's the same problem as %_ (the warning is the same), which no longer works (see my other post). perl used to kick in and handle %_ and %vd, it no longer does that. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problem building latest perl (24978) on win32
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. Compress::Zlib is a perl extension. It is linked against libz.a/libz.so on UNIX or zlib.lib/zlib.dll on Win32. If the application which embeds perl _already_ links to libz.so then when Compress::Zlib is loaded into the embedded perl there are two copies of libz.so (or zlib.dll) referenced and that is harmless (except on old BSD SunOS4). But if Compress::Zlib links to private zlib code or libz.a then there are two copies of code and associated symbols in the application and that can cause confusion at best and bugs at worst.
Re: Date::Parse (Time::Local?) choking on years between1956-1938 and wrong below, on FC4/5.8.6
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 somehow. I posted up some proof-of-concept code for that to be done in Config.pm, determine the range limitations of localtime() during the Perl build and use that to generate sensible localtime() warnings when trying to process dates outside its acceptable range. And then there's a crazier idea of incorporating our own date handling code which doesn't have the cramped range of the system's localtimes, but I don't know how to do that. Stuff it in an NV (at least double?) Gets you 53-bit mantissa in IEEE form and degrades nicely to handle geological times ;-)
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returnswrong value for Win 32
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'.
Hey Ken, want to have a look at this? There's a patch and everything!
If Win32 is going to be handled like Unix, then it should return the
input verbatim (.. is not cleaned up). Is there a reason it should
be different on Win32?
Without (sym)links Win32 has simpler .. semantics than Unix.
But there are still pitfalls crossing mount points.
-Ken
Re: [PATCH] Further lies in the File::Basename docs
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 there.
RE: blead: no longer supports %vd format
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 different hack. Previously -DCHECK_FORMAT defined VDf + SVf differently, to avoid the warnings and allow -Wformat to check the formats. Robin -Original Message- From: Stas Bekman To: John Peacock Cc: The Perl5 Porters Mailing List Sent: 08/07/05 20:01 Subject: Re: blead: no longer supports %vd format 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 do with the constification? Because perl doesn't take care of substituting it. It's the same problem as %_ (the warning is the same), which no longer works (see my other post). perl used to kick in and handle %_ and %vd, it no longer does that. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com --- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY ---
Re: data written on ebcdic
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 \xFE \xF1 or should it be \xFF \xFE \x31 ? If you run that on an EBCDIC machine the 1 will know it is 0xF1 in bytes mode. But encoding(utf16be) should upgrade from EBCDIC to Unicode before writing to disk. So IMO you _should_ get octents \xFF \xFE \x31 in the file.
Re: blead: no longer supports %vd format
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 compiling under 4.0 on multiple platforms. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [PATCH] Further lies in the File::Basename docs
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 or directory with [A-Za-z] in it. 2. Change the case of a few of those letters. In which CTYPE do you change the case ;-) 3. Check to see if it exists.
Re: blead: no longer supports %vd format
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? The warning can be safely ignored and the %vd code works fine. Perhaps it is something to do with the constification? John
Re: blead: no longer supports %vd format
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 Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [PATCH] Further lies in the File::Basename docs
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 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 there. 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 both cases are quite likely if OS yields CPU on system calls. Thanks for pointing out a statistical weakness in the algorithm.
[perl #17650] [PATCH] DESTROY can prevent propagation of die
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 letter away from not working
diff -ru perl-current/pp_ctl.c perl-patched/pp_ctl.c
--- perl-current/pp_ctl.c 2005-07-08 13:03:02.0 -0400
+++ perl-patched/pp_ctl.c 2005-07-08 15:39:59.0 -0400
@@ -1432,6 +1432,7 @@
else {
sv_setpvn(ERRSV, message, msglen);
}
+ message = SvPV_const(ERRSV, msglen);
}
while ((cxix = dopoptoeval(cxstack_ix)) 0
@@ -1471,6 +1472,12 @@
* minimal fix --GSAR */
PL_curcop = cx-blk_oldcop;
+ /* Leaving the block could run DESTROY blocks which might
+ * have altered $@; reset it here just in case */
+ if (message) {
+ sv_setpvn(ERRSV, message, msglen);
+ }
+
if (optype == OP_REQUIRE) {
const char* msg = SvPVx_nolen_const(ERRSV);
SV * const nsv = cx-blk_eval.old_namesv;
diff -ru perl-current/t/op/die.t perl-patched/t/op/die.t
--- perl-current/t/op/die.t 2005-07-06 16:38:38.0 -0400
+++ perl-patched/t/op/die.t 2005-07-08 15:42:12.0 -0400
@@ -1,6 +1,6 @@
#!./perl
-print 1..15\n;
+print 1..16\n;
$SIG{__DIE__} = sub { print ref($_[0]) ? (ok ,$_[0]-[0]++,\n) : @_ } ;
@@ -72,3 +72,27 @@
print not unless $ok;
print ok 15\n;
}
+
+# [perl #17650] DESTROY can unset $@
+{
+ package SomeClass;
+
+ sub new {
+my $self = {};
+bless $self;
+ }
+
+ sub DESTROY {
+eval { 1; };
+ }
+}
+
+{
+ local $SIG{__DIE__};
+ eval {
+my $x = new SomeClass;
+die;
+ };
+ print($@ ? ok 16\n : not ok 16\n);
+}
+
Re: RES: [perl #27764] Out Of Memory Problem
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 well,
which is common when the input data grows at a fast pace. Maybe you
should consider alternative approaches to break your calculations into
manageable bits that fit the computer memory.
Another alternative is to use a hash-on-disk DBM file, such as DB_File.
The hash will be stored on disk and not in memory.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
Smoke [5.9.3] 25098 FAIL(F) linux 2.6.12-3-686 [debian] (i686/1 cpu)
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 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25098 Configuration (common) none --- - F F F F F F F F F F F F -Duseithreads F F F F F F -DPERL_DEBUG_COW F F F F F F -DPERL_DEBUG_COW -Duseithreads | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING | | | | +--- PERLIO = perlio -DDEBUGGING | | | +- PERLIO = stdio -DDEBUGGING | | +--- LC_ALL = en_US.utf8 | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio/perlio/en_US.utf8] [stdio/perlio/en_US.utf8] -DDEBUGGING [stdio/perlio/en_US.utf8] -Duseithreads [stdio/perlio/en_US.utf8] -DDEBUGGING -Duseithreads [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW -Duseithreads [stdio/perlio/en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW -Duseithreads ../t/op/groups.tFAILED 1 -- Report by Test::Smoke v1.19#716 running on perl 5.8.7 (Reporter v0.016 / Smoker v0.015)
Re: [PATCH] Further lies in the File::Basename docs
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 both cases are quite likely if OS yields CPU on system calls. Write style probes would happen in their own subdirectory to minimize the possibilities of interference. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- Witches Abroad by Terry Prachett
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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. Win32::GetFullPathName() is the one i have in mind when I say this. perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]); outputs CWD\bar. So if you strip off the CWD from the result of Win32::GetFullPathName() you get the OS'es solution of this problem, which should bypass all of these issues. Does it? It still leaves us asking the question: can we assume foo\..\bar == bar on Windows? Just because a system call does it that way doesn't mean its right. Anyhow, should this discussion drag on any longer without resolution there's a simple yardstick to use: Which retains the most information? Not collapsing .. does. So given that the current implementation is clearly wrong, and if we can't decide between the two right implementations, pick the one that's safest to at least give a correct answer. Then we can discuss some more and maybe have switch to the other one. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- Witches Abroad by Terry Prachett
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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 behaviour could take advantage of this API. Win32::GetFullPathName() is the one i have in mind when I say this. perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]); outputs CWD\bar. So if you strip off the CWD from the result of Win32::GetFullPathName() you get the OS'es solution of this problem, which should bypass all of these issues. Does it? It still leaves us asking the question: can we assume foo\..\bar == bar on Windows? Just because a system call does it that way doesn't mean its right. Well, i suppose you are correct. Im not entirely sure what scenario I 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. D:\dev\junctjunction foo Junction v1.03 - Win2K junction creator and reparse point viewer Copyright (C) 2000-2002 Mark Russinovich Systems Internals - http://www.sysinternals.com D:\dev\junct\foo: JUNCTION Substitute Name: d:\dev\test D:\dev\junctecho Test1 foo\..\test.echo D:\dev\juncttype test.echo Test1 D:\dev\junctcd .. D:\devecho test2 test\..\test.echo D:\devtype test.echo test2 Anyhow, should this discussion drag on any longer without resolution there's a simple yardstick to use: Which retains the most information? Not collapsing .. does. So given that the current implementation is clearly wrong, and if we can't decide between the two right implementations, pick the one that's safest to at least give a correct answer. Then we can discuss some more and maybe have switch to the other one. Sure. My comment was mostly that by using the Win32 API's one can do this type of stuff more reliably than with File::Spec. With the emphasis intended to be more on this type of stuff than on the particular problem that lead to this thread. To be honest i would really like to see the expected behaviour of canonpath when called on a relative path explicitly defined. IMO canonpath should act more like rel2abs, insofar as it should support an optional $base argument to use instead of CWD when trying to clean up a relative path. -- perl -Mre=debug -e /just|another|perl|hacker/
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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 that there's an argument to be made here, but I never fully understood the symlinks vs .. cannonpath argument so I'll hope someone else jumps in and makes it. To be honest i would really like to see the expected behaviour of canonpath when called on a relative path explicitly defined. IMO canonpath should act more like rel2abs, insofar as it should support an optional $base argument to use instead of CWD when trying to clean up a relative path. 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. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- Witches Abroad by Terry Prachett
Re: [PATCH] Further lies in the File::Basename docs
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 existing name, including the timestamp and a random number in the name to make uniqueness highly probable, stat the result, alter the name by case of one or more alphabetic characters, stat that, and if the results are the same, then conclude that it is a case insensitive file name. The chances of picking at random the same name that a read style probe would pick are extremely unlikely. 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 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: Smoke [5.9.3] 25093 FAIL(F) openbsd 3.7 (macppc/1 cpu)
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 smoke script directly, they only show up when the smoke-scripts are run
from a shell-script that loops over them.
Is this a BSD issue or a perl issue?
Beside a few initial bumps with OpenBSD 3.7, I've not had any major issues
with the smokes. In fact, my last failed smoke was about three weeks ago.
Looking at the failures, they involve dup'ing STDIN into another filehandle.
Would it be possible for you to smoke with the following patch to see
what the exact error is? I'm hoping STDERR isn't snuffed out completely in
smoke testing, so hopefully these warnings will give us some answers.
Steve Peters
[EMAIL PROTECTED]
--- t/io/open.t.old Tue Oct 19 12:07:33 2004
+++ t/io/open.t Fri Jul 8 16:33:19 2005
@@ -234,7 +234,7 @@
}
# used to try to open a file [perl #17830]
-ok( open(my $stdin, , fileno STDIN), 'dup fileno(STDIN) into
lexical fh');
+ok( open(my $stdin, , fileno STDIN), 'dup fileno(STDIN) into
lexical fh') || _diag $!;
}
SKIP: {
--- t/io/dup.t.old Sun Sep 14 09:54:11 2003
+++ t/io/dup.t Fri Jul 8 16:34:46 2005
@@ -96,7 +96,7 @@
isnt(fileno(F), fileno(STDOUT));
close F;
-ok(open(F, =STDIN));
+ok(open(F, =STDIN)) || _diag $!;
is(fileno(F), fileno(STDIN));
close F;
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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 case yes, foo\..\bar == bar. I have the creeping feeling that there's an argument to be made here, but I never fully understood the symlinks vs .. cannonpath argument so I'll hope someone else jumps in and makes it. Me too. Not being all that familiar with *nix file systems I made my best stab at an answer as it seems to pertain to Win32. I think John Peacock also said something to this effect. To be honest i would really like to see the expected behaviour of canonpath when called on a relative path explicitly defined. IMO canonpath should act more like rel2abs, insofar as it should support an optional $base argument to use instead of CWD when trying to clean up a relative path. 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 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 but if we are in \bar\baz\bat then its not the same as either as it maps to \bar\foo. yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: [PATCH] Further lies in the File::Basename docs
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 Well, now, multiple processes running the same program doing the same thing wouldn't qualify as perl doing both styles of probes in the same directory at the same time... because if it uses a read probe to determine case sensitivity, then it doesn't need to do a write probe to determine case sensitivity. And while even those probes shouldn't use the same sorts of names, other probes for other information, would surely use even different names. Yes, CGI programs are prolific, and do the same thing repeatedly for the same and different users. And what did you say about caching results? It was really more your oh, that could never happen style response of two processes doing different things in the same directory without being aware of each other. Anyhow, this is all moot as any write probes will happen in a unique, temporary subdirectory. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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
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.
Win32::GetFullPathName() is the one i have in mind when I say this.
perl -e use Win32; print Win32::GetFullPathName(qq[foo\\..\\bar]);
outputs CWD\bar.
So if you strip off the CWD from the result of
Win32::GetFullPathName() you get the OS'es solution of this problem,
which should bypass all of these issues.
Does it? It still leaves us asking the question: can we assume foo\..\bar
==
bar on Windows? Just because a system call does it that way doesn't mean
its right.
In the presence of junction points, I think not. The system call would
have the opportunity to understand and check for the existance of
junction points, but whether it does or not, is anyone's guess, without
trying it.
Doesn't look like there is a problem with this. I guess .. is
resolved by the OS relative to ., and not a hard link to a specific
directory. (But that is pure speculation.)
D:\dev\junct\fooperl -MWin32 -eprint Win32::GetFullPathName('.');
D:\dev\junct\foo
D:\dev\junct\foocd ..\..\test
D:\dev\testperl -MWin32 -eprint Win32::GetFullPathName('.');
D:\dev\test
D:\dev\testcd ..
D:\devjunction junct\foo
Junction v1.03 - Win2K junction creator and reparse point viewer
Copyright (C) 2000-2002 Mark Russinovich
Systems Internals - http://www.sysinternals.com
D:\dev\junct\foo: JUNCTION
Substitute Name: d:\dev\test
--
perl -Mre=debug -e /just|another|perl|hacker/
RE: blead: no longer supports %vd format
-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 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 ;-) - Not guilty! 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. Later patches (relating to the consting work) added attributes everywhere, not hidden by CHECK_FORMAT, and it became possible to remove %_ and have all kinds of gcc warnings work by default. To reiterate, as far as I know, %vd still works - it just warns. The warnings can be silenced with gcc -Wall -Wno-format or with C#define __attribute__(x) Or Csprintf(%vd,x) can be replaced by Csprintf(%SVf, vstring(x)) Robin --- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY ---
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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 yes, foo\..\bar == bar. I have the creeping feeling that there's an argument to be made here, but I never fully understood the symlinks vs .. cannonpath argument so I'll hope someone else jumps in and makes it. It's been in the File::Spec docs for a couple versions now, because it's widely misunderstood: http://search.cpan.org/~kwilliams/PathTools-3.09/lib/File/Spec/Unix.pm -Ken
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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 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 but if we are in \bar\baz\bat then its not the same as either as it maps to \bar\foo. Reason #982983 to leave .. alone. Your proposed cleanup is actually changing the meaning of the path. ..\..\foo means go up two levels and then down into foo. ..\foo means go up one level and then down into foo. They represent different things. canonpath() is about producing filepaths with the same meaning and NOT about determining if they might point to the same file given the current CWD. For that you can just run it through rel2abs(). Would would be nice is some sort of collapse() method which does collapse .. so that canonpath(foo/../bar) == 'foo/../bar' but collapse(canonpath(foo/../bar)) == 'bar'. I like this solution. canonpath() can remain strict and work the same across platforms. The user can decide if they want .. collapsed or not. We stop having to second guess the user's needs. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in [EMAIL PROTECTED]
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns w rong value for Win 32
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 but if we are in \bar\baz\bat then its not the same as either as it maps to \bar\foo. The current working directory is not considered in canonpath(), period. canonpath(../../foo) is ../../foo. -Ken
File::Spec-collapse() proof of concept
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'
../bar
0 ~$ perl -w ~/tmp/foo.plx '../foo/../../bar'
../../bar
0 ~$ perl -w ~/tmp/foo.plx '/../../../bar'
/bar
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,
File::Spec::Win32-catdir(, .., .., )'
It should be the root dir as it is on Unix.
0 ~$ perl -MFile::Spec::Unix -wle 'print join \n,
File::Spec::Unix-catdir(, .., .., )'
/
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick
#!/usr/bin/perl -lw
use File::Spec;
use File::Spec::Unix;
package File::Spec::Unix;
sub collapse {
my($fs, $path) = @_;
my $updir = $fs-updir;
my $curdir = $fs-curdir;
my($vol, $dirs, $file) = $fs-splitpath($path);
my @dirs = $fs-splitdir($dirs);
my @collapsed;
push @collapsed, $curdir unless $fs-file_name_is_absolute($path);
foreach my $dir (@dirs) {
if( $dir eq $updir and # if we have an updir
@collapsed and # and something to collapse
length $collapsed[-1] and # and its not the rootdir
$collapsed[-1] ne $updirand # nor another updir
$collapsed[-1] ne $curdir # nor the curdir
)
{ # then
pop @collapsed; # collapse
}
else {# else
push @collapsed, $dir;# just hang onto it
}
}
return $fs-catpath($vol,
$fs-catdir(@collapsed),
$file
);
}
package main;
my($path, $os) = @ARGV;
$os ||= '';
my $class = 'File::Spec';
$class .= ::$os if $os;
eval qq{require $class};
print $class-collapse($path);
sv_setuv bug
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 if you do it
on a clean build the build will fail)
This is a bug. There should be no difference.
More investigation reveals that the problem is actually stranger - things
pass provided you *don't* set SvIsUV_on() for the value 0. If you do, then
tests fail. The problem is the pure-perl Data::Dumper implementation, and
it manifests itself as extra spaces in lines that end with commas and
semicolons.
not ok 1
--Expected--
#$a = [
# 1,
# {
# 'a' = $a,
# 'b' = $a-[1],
# 'c' = [
# 'c'
#]
# },
# $a-[1]{'c'}
# ];
#$b = $a-[1];
#$c = $a-[1]{'c'};
--Got--
#$a = [
# 1,
# {
# 'a' = $a,
# 'b' = $a-[1],
# 'c' = [
# 'c'
#]
# },
# $a-[1]{'c'}
# ];
#$b = $a-[1];
#$c = $a-[1]{'c'};
ok 2
(etc)
This makes little sense to me. Does anyone have any hunches as to what's
going wrong here?
Nicholas Clark
Re: File::Spec-collapse() proof of concept
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, File::Spec::Win32-catdir(, .., .., )' It should be the root dir as it is on Unix. 0 ~$ perl -MFile::Spec::Unix -wle 'print join \n, File::Spec::Unix-catdir(, .., .., )' / I just sent off a patch to Ken to fix this. http://rt.cpan.org/NoAuth/Bug.html?id=13606 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: blead: no longer supports %vd format
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 XS writers still need to be able to use %vd or the VDf macro in their own code. Just because it isn't in the core any longer doesn't mean we can stop supporting it completely (and several of the format macros need to be in ppperl.h for just this reason). In fact, I think that I like the idea of making PL_patchlevel a readonly v-string by default, instead of having to scatter upg_version()'s all over the source code (and I've got a patch to do it). To reiterate, as far as I know, %vd still works - it just warns. Yes, it definitely works from the Perl and XS levels, but it warns when compiling the XS/C code. The warnings can be silenced with gcc -Wall -Wno-format or with C#define __attribute__(x) You mean stubbing out the attribute checking? What't the point of that? Or Csprintf(%vd,x) can be replaced by Csprintf(%SVf, vstring(x)) There is no macro or function called vstring() that will translate a v-string like the %vd format does. Can we just revert the bits of 23824 which eliminated the %vd handling only make it non-conditional on CHECK_FORMAT? John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Smoke [5.9.3] 25098 FAIL(XF) openbsd 3.7 (i386/1 cpu)
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 = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25098 Configuration (common) none --- - O O O O O O O O -Duse64bitint O O O O -Duseithreads X O O F -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio] -Duseithreads -Duse64bitint Inconsistent test results (between TEST and harness): ../ext/B/t/bytecode.t...FAILED at test 6 [perlio] -DDEBUGGING -Duseithreads -Duse64bitint ../t/io/dup.t...FAILED 15-16 ../t/io/open.t..FAILED 93 -- Report by Test::Smoke v1.19#716 running on perl 5.8.6 (Reporter v0.016 / Smoker v0.015)
Smoke [5.9.3] 25101 FAIL(M) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
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 = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25101 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - M M M M -Dusemymalloc M M -Duselargefiles M M -Duselargefiles -Dusemymalloc M M -Duseithreads -Uuseimpsys M M -Duseithreads -Uuseimpsys -Dusemymalloc M M -Duseithreads -Uuseimpsys -Duselargefiles M M -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' M M -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc | +- -DDEBUGGING +--- no debugging Failures: (common-args) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist [minitest] [minitest] -DDEBUGGING [minitest] -Dusemymalloc [minitest] -DDEBUGGING -Dusemymalloc [minitest] -Duselargefiles [minitest] -DDEBUGGING -Duselargefiles [minitest] -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 op/magic..dubious DIED. FAILED tests 43-58 op/utftaint...dubious [minitest] -Duseithreads -Uuseimpsys [minitest] -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 op/magic..dubious DIED. FAILED tests 43-58 op/threadsdubious DIED. FAILED tests 1-3 op/utftaint...dubious [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious 13/111 unexpectedly
[perl #22051] segfault (deep recursion?) in regex match
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 first
regex.
for(;;) {
$data =~ /\G([:?])((?:[^]+|[^:?])*)/xgcs or last;
$data =~ /\G([:?])((?:[^:?]+|[:?][^])*)/gcs or last;
}
when I run this program I get a segfault because of a very deep
recursion:
#0 S_regmatch (prog=0x81252a8) at regexec.c:2237
#1 0x080e605e in S_regmatch (prog=0x8125318) at regexec.c:3244
#2 0x080e5068 in S_regmatch (prog=0x81252a8) at regexec.c:3789
#3 0x080e605e in S_regmatch (prog=0x81252a8) at regexec.c:3244
#4 0x080e605e in S_regmatch (prog=0x8125318) at regexec.c:3244
#5 0x080e5068 in S_regmatch (prog=0x81252a8) at regexec.c:3789
#6 0x080e605e in S_regmatch (prog=0x81252a8) at regexec.c:3244
...
#18941 0x080e5068 in S_regmatch (prog=0x81252a8) at regexec.c:3789
#18942 0x080e605e in S_regmatch (prog=0x8125318) at regexec.c:3244
#18943 0x080e5cef in S_regmatch (prog=0x8125250) at regexec.c:3079
#18944 0x080e2c4f in S_regtry (prog=0x812520c, startpos=0x8431819
?\n!DOCTYPE PLAY SYSTEM \play.dtd\\n\nPLAY\nTITLEThe Tragedy
of Macbeth/TITLE\n\nFM\nPText placed in th
Confirmed still a bug in 5.8.1, 5.8.6 and [EMAIL PROTECTED]
?{ } block in regexes?
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;
if $try_this_pattern fails, undo_it() is called to undo
do_something().
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me sneaks up from another MIME part: neeyah!
pgpk19QbPRmXW.pgp
Description: PGP signature
Smoke [5.9.3] 25101 FAIL(F) linux 2.6.12-3-686 [debian] (i686/1 cpu)
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 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25101 Configuration (common) none --- - F F F F F F F F F F F F -Duseithreads F F F F F F -DPERL_DEBUG_COW F F F F F F -DPERL_DEBUG_COW -Duseithreads | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING | | | | +--- PERLIO = perlio -DDEBUGGING | | | +- PERLIO = stdio -DDEBUGGING | | +--- LC_ALL = en_US.utf8 | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio/perlio/en_US.utf8] [stdio/perlio/en_US.utf8] -DDEBUGGING [stdio/perlio/en_US.utf8] -Duseithreads [stdio/perlio/en_US.utf8] -DDEBUGGING -Duseithreads [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW -Duseithreads [stdio/perlio/en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW -Duseithreads ../t/op/groups.tFAILED 1 -- Report by Test::Smoke v1.19#716 running on perl 5.8.7 (Reporter v0.016 / Smoker v0.015)
