[ANNOUNCE] Test::Simple/More/Builder 0.61
http://www.pobox.com/~schwern/src/Test-Simple-0.61.tar.gz or http://svn.schwern.org/CPAN/Test-Simple/trunk or a CPAN mirror near you. A small raft of small fixes have happened between 0.60 and 0.61 as well as a few new features. New Features: * Test::Builder::Module has been added to help test module authors. It implements the oft requested import() method to parse plan information on the use line just as Test::More does. If you base your testing module on Test::Builder::Module it will no longer need to rely on Test::More to set the plan. * Added the oft requested BAIL_OUT() function to Test::More. * Added a no_diag() method to Test::Builder. * The standard failure diagnostics now include the name of the test for easier recognition when run through Test::Harness. * cmp_ok(), like() and unlike() will now warn if given uninitialized values. * cmp_ok() will now throw warnings if the given comparison warrents it. For example, cmp_ok(2, '==', 'foo') will warn about 'foo' not being numeric. * Test will now report *both* the number of tests failed and if the wrong number of tests was run. Previously if both occured it would only report the latter. * For the purposes of calculating the exit code, missing or extra tests are not considered failures. Should there be no failures but the wrong number of tests the exit code will be 254. Deprecations: * The no_diag option to Test::More has been deprecated. Use Test::More-builder-no_diag(1) instead. * Test::Builder-BAILOUT is now BAIL_OUT to match all the other naming conventions. BAILOUT has been deprecated. Bug fixes: * A large number of bugs related to overloaded objects have been fixed. See the change log below for details. 0.61 Fri Sep 23 23:26:05 PDT 2005 - create.t was trying to read from a file before it had been closed (and thus the changes may not have yet been written). * is_deeply() would call stringification methods on non-object strings which happened to be the name of a string overloaded class. [rt.cpan.org 14675] 0.60_02 Tue Aug 9 00:27:41 PDT 2005 * Added Test::Builder::Module. - Changed Test::More and Test::Simple to use Test::Builder::Module - Minor Win32 testing nit in fail-more.t * Added no_diag() method to Test::Builder and changed Test::More's no_diag internals to use that. [rt.cpan.org 8655] * Deprecated no_diag() as an option to use Test::More. Call the Test::Builder method instead. 0.60_01 Sun Jul 3 18:11:58 PDT 2005 - Moved the docs around a little to better group all the testing functions together. [rt.cpan.org 8388] * Added a BAIL_OUT() function to Test::More [rt.cpan.org 8381] - Changed Test::Builder-BAILOUT to BAIL_OUT to match other method's naming conventions. BAILOUT remains but is deprecated. * Changed the standard failure diagnostics to include the test name. [rt.cpan.org 12490] - is_deeply() was broken for overloaded objects in the top level in 0.59_01. [rt.cpan.org 13506] - String overloaded objects without an 'eq' or '==' method are now handled in cmp_ok() and is(). - cmp_ok() will now treat overloaded objects as numbers if the comparison operator is numeric. [rt.cpan.org 13156] - cmp_ok(), like() and unlike will now throw uninit warnings if their arguments are undefined. [rt.cpan.org 13155] - cmp_ok() will now throw warnings as if the comparison were run normally, for example cmp_ok(2, '==', 'foo') will warn about 'foo' not being numeric. Previously all warnings in the comparison were supressed. [rt.cpan.org 13155] - Tests will now report *both* the number of tests failed and if the wrong number of tests were run. Previously if tests failed and the wrong number were run it would only report the latter. [rt.cpan.org 13494] - Missing or extra tests are not considered failures for the purposes of calculating the exit code. Should there be no failures but the wrong number of tests the exit code will be 254. - Avoiding an unbalanced sort in eq_set() [bugs.perl.org 36354] - Documenting that eq_set() doesn't deal well with refs. - Clarified how is_deeply() compares a bit. * Once again working on 5.4.5. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
Re: lib/test/simple/t/create.t help with VMS issue needed.
On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote: Test 7 is failing because normally on VMS, unless you specify otherwise, you get exclusive access to the file, so the second open is failing. The logical name DECC$FILE_SHARING defined as ENABLE will change VMS behavior to that of UNIX which will allow test 7 to pass. I can probably come up with some code to have the script on VMS make sure that that value is set and to clear it on exit. Test 8 is more of a problem. The issue is that the buffers for the other stream written by the new_tb-output(some_file) have not made it to disk, so they can not yet be read by the new input stream to pass the test. There does not seem to be a method of explicitly closing or flushing the output stream being written to by Test::Builder. I was about to commit the test fix for this and then I realized that Test::Builder unbuffers its newly created output filehandles. Everything should be written to disk immediately. If not then there's a bug either in Test::Builder's autoflush logic or in Perl. Could you have another look at this? Test::Builder _new_fh() and _autoflush() will be of some interest. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Stabbing you in the face so you don't have to.
Re: BUG: MAKEMAKER 6.30_01 and blead in MM_UNIX.pm for VMS
On Tue, Sep 20, 2005 at 07:15:41AM -0400, Peter Prymmer wrote: perl -e 'exit 1' On VMS the construct shown is true since exit 1 is the way to say exit 0. I thought this only happens with use vmsish 'exit' on. I note the following behavior from the shell on Solaris 10: /home/user/pprymmer false /home/user/pprymmer echo $? 255 Solaris is Weird. -- 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: BUG: MAKEMAKER 6.30_01 and blead in MM_UNIX.pm for VMS
On Tue, Sep 20, 2005 at 08:09:56AM -0400, John E. Malmberg wrote: A VMS exit 44 will also cause MMS/MMK by default to abort the makefile with MMS/MMK also exiting with an error. I believe this is the desired behavior. If you want a VMS exit code that UNIX programs should interpret as an EXIT 1, then the following (mostly undocumented) hack will work. VMS status code = %x35a000 + (UNIX status * 8), and if this is a success status, add 1, otherwise VMS will interpret it as a warning. EAGLE exit %x35A000 + (1 * 8) + 1 EAGLE x = %x35A000 + (1 * 8) + 1 EAGLE show sym x X = 3514377 Hex = 0035A009 Octal = 00015320011 I have no idea what any of this means. Anyhow, I don't need to wedge together a single command line for both VMS and Unix. Its easy to have different commands for each. Unless you're talking about that wacky VMS with Unix semantics thing again. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ...they shared one last kiss that left a bitter yet sweet taste in her mouth--kind of like throwing up after eating a junior mint. -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest by Tami Farmer
Re: BUG: MAKEMAKER 6.30_01 and blead in MM_UNIX.pm for VMS
On Tue, Sep 20, 2005 at 02:02:24PM -0400, Peter Prymmer wrote: By the way, why is `false` desirable to have in a Makefile? Why does MakeMaker need to know how to do it? It appears it wants to make sure certain targets fail when the commands themselves don't necessarily exit with non-zero. Its the make equivalent of return 0. There's only three occurances of this. One is specific to OS/2. One is in MM_Unix-perldepend which appears to be unused. Only this one is actually used in day-to-day Makefiles but it only happens if the Makefile.PL is newer than the Makefile, so its not critical code. # --- MakeMaker makefile section: # We take a very conservative approach here, but it's worth it. # We move Makefile to Makefile.old here to avoid gnu make looping. $(FIRST_MAKEFILE) : Makefile.PL $(CONFIGDEP) $(NOECHO) $(ECHO) Makefile out-of-date with respect to $? $(NOECHO) $(ECHO) Cleaning current config before rebuilding Makefile... -$(NOECHO) $(RM_F) $(MAKEFILE_OLD) -$(NOECHO) $(MV) $(FIRST_MAKEFILE) $(MAKEFILE_OLD) - $(MAKE) $(USEMAKEFILE) $(MAKEFILE_OLD) clean $(DEV_NULL) $(PERLRUN) Makefile.PL $(NOECHO) $(ECHO) == Your Makefile has been rebuilt. == $(NOECHO) $(ECHO) == Please rerun the $(MAKE) command. == false -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
Re: BUG: MAKEMAKER 6.30_01 and blead in MM_UNIX.pm for VMS
On Tue, Sep 20, 2005 at 02:02:31PM -0700, Michael G Schwern wrote: One is in MM_Unix-perldepend which appears to be unused. I lied, its not unused. Its used when building perl and XS modules so that's probably important. But it only happens when config.h is out of date. And VMS has its own version which doesn't use false. However, MakeMaker using false is not new so I don't know why this is only now an issue. -- 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: bleadperl MakeMaker problems building DynaLoader
On Wed, Aug 24, 2005 at 01:11:36AM -0700, Yitzchak Scott-Thoennes wrote: I just tried to build bleadperl and got this: Is this still a problem? -- 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: lib/test/simple/t/create.t help with VMS issue needed.
On Fri, Sep 16, 2005 at 08:47:42PM -0400, John E. Malmberg wrote: Anything happening with this for the 5.8.8 timeframe? I guess I can kick 0.61 out the door. -- 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: BUG: MAKEMAKER 6.30_01 and blead in MM_UNIX.pm for VMS
On Sun, Sep 18, 2005 at 11:52:20PM -0400, John E. Malmberg wrote: As there is no false command on VMS, this is causing rerunning a make to fail. Would adding the following line before the return $m be the fix for this? Or is something else needed to make sure only the last line is removed? $m =~ s/false\n// if $IsVMS; I see a number of uses of false in MM_Unix. Rather than throw in more VMS exceptions (blech) I'll make a $(FALSE) which can be something safe like perl -e 'exit 1' -- 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!
Upgrade MakeMaker in maint
Maint is still using MakeMaker 6.17 which is now TWO YEARS OLD! Last I checked there was some VMS failure or another possibly tied to File::Find but I don't have details. I really rather 5.8.8 not go out with 6.17 again, 6.30 is good and stable. Can we just take the plunge, put 6.30 into maintperl and work out the glitches? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
Re: [perl #37101] my $v if (0); leaves $v around
On Wed, Sep 07, 2005 at 05:19:55PM -0700, brucer @ gsg-lnx-bld1. cisco. com wrote: The following program invokes beta once instead of twice. Extremely non-intuitive. moving the #' down one line fixes it. 1) seems like it shouldn't compile. 2) $c is static and keeps its value between invocations if one instead of if (0) one has if ($b) This is boiled down from a real program, of course. The short answer is don't do that. Cmy $v if 0; has already been deprecated in the development version of Perl because its behavior is too confusing. The behavior cannot be changed because too many people rely on it. $ bleadperl -wle 'my $v if 0;' Deprecated use of my() in false conditional at -e line 1. -- 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
Stop fiddling with the bloody grammar (was Re: exempli gratia is e.g.)
On Wed, Sep 07, 2005 at 01:04:00PM -0400, Mark Jason Dominus wrote: I was struck by one of my own: exempli gratia being abbreviated to eg or eg., rather than e.g. I would like to suggest that Latin is obscure, and latin abbreviations are doubly obscure. There is no space constraint that should require us to use e.g. in place of for example. Using i.e. in place of that is is even sillier. (57% sillier, in fact.) If you're going to do the work of locating these locutions, can I suggest that you get rid of the unnecessary abbreviations entirely? I'm going to come at this from a different angle. One that says leave it as ie/eg or perhaps simply who cares? because the effort to correct all the ie's and eg's and it's and [ae]ffects just doesn't seem worth the effort. I will quote Donald Norman. What about noon: How shall it be labeled, AM or PM? In a clever essay on the topic, the engineer Henry Petroski argues that 12 noon should be labeled 12M, for after all, the history of AM and PM is that they mean Ante Meridiem (before the middle of the day) and Post Meridiem (after midday). Noon is the meridiem, the midday, so it is neither before nor after. It should be labeled M: 12M. Yikes! That is putting principle first, and damn the consequences. I hate to disagree so strongly with one of my favorite authors, but I splutter at the thought of using M to mark noon in order to distinguish it from midnight! In English, if any letter is to be used to denote noon, it should be N. M ought to stand for midnight. The mark of M for noon makes historical sense, but it makes practical sense only if the everyday user of time understands the original meanings of the terms AM and PM. How Long Is Noon? published in Turn Signals Are The Facial Expressions Of Automobiles p 89 The point being, most people don't know that P.M., i.e. and e.g. are abbreviations for Latin phrases so it doesn't matter one bit to the reader of the Perl documentation whether its ie or i.e.. While neither option causes confusion, as 12M for 12 noon does, neither one adds anything over the other except perhaps niggling grammatical correctness. What it does add is MAINTENANCE COST. Maintaining an extreme level of grammatical correctness and consistency over a large collection with multiple authors takes time and effort not just from the person doing the initial grammar fix but from all the CPAN authors who now have to reapply that patch and retrain their writing style. Not to mention all the mailing list noise it inevitably generates (remember the [ae]ffect thread?) Effort is spent with a near 0 benefit to the user. While I thank you very much for the effort to scan the documentation to find grammar nits, and I realize Open Source is about scratching an itch, software is about change management. Which is why I say to stop fiddling with the (ie/i.e.)'s, the (eg/e.g.)'s, the (its/it's)'s and the ([ae]ffects). There's FAR more important things to be done in the Perl documentation. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: PathTools 3.10 released
On Sun, Sep 11, 2005 at 07:39:46PM -0500, Ken Williams wrote: I thought I supplied an implementation with that. Yes - your implementation worked for everything except /.. - /, so I just added one line that did that. The rest of the implementation is yours verbatim. Oh, ok. The wording of your original post made it sound like you had to implement the whole thing. I'm not sure why I needed to add that case you didn't see a failure on your side, though. Cuz I didn't check for it? :) -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
Re: no 6;
On Mon, Sep 05, 2005 at 08:29:00PM +0100, Nicholas Clark wrote: It's not valid perl 4: $ perl4 -e 'no 5; print [EMAIL PROTECTED]' syntax error in file /tmp/perl-em47tij at line 1, next 2 tokens no 5 Execution of /tmp/perl-em47tij aborted due to compilation errors. $ perl1 -e 'no 4; print Happy New Year, 1988!\n' syntax error in file /tmp/perl-eE52cHQ at line 1, next token string Execution aborted due to compilation errors. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
Re: PathTools 3.10 released
On Sun, Sep 11, 2005 at 08:25:24AM -0500, Ken Williams wrote: On Thu, Aug 25, 2005 at 10:31:03PM -0500, Ken Williams wrote: I finally found time to implement the code for the prospective tests that Schwern added to File::Spec, so I uploaded 3.10 to CPAN. Should be hitting mirrors now. Which prospective tests were those? The canonpath(foo/..) stuff on Win32, I guess. I thought I supplied an implementation with that. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
Re: [perl #7615] (if|unless) ( local ... ) not undone
On Fri, Aug 26, 2005 at 09:06:50AM -0700, Steve Peters via RT wrote:
$a = 10;
if (local $a = 1){
}
print $a; # Should be 10, not 1
Still busted in 5.8.6 and blead.
$ bleadperl -wle '$a = 10; if( local $a = 1 ) {} print $a'
Found = in conditional, should be == at -e line 1.
1
$ bleadperl -wle '$a = 10; if( my $a = 1 ) {} print $a'
Found = in conditional, should be == at -e line 1.
10
--
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 #37029] Perl bug - help
On Tue, Aug 30, 2005 at 06:51:22AM -0700, Yeoman, Dave wrote: I'm by no means an expert with perl, but I need some Perl help. We have one x440 server with RH 3.0.5 and perl v5.8.0 built for i386-linux-thread-multiand and another server x445 upgraded with RH 4.0 perl v5.8.5 built for i386-linux-thread-multi. The server with Perl v5.8.5 produces different results from the pop (line 458 below) and I'm not sure why. Can you help answer my question? RedHat seriously mangled its release of 5.8.0. Amongst other things, its not really 5.8.0 but 5.8.0 + a pile of Unicode patches from the development branch of Perl at the time. There are many, many problems with it. I don't know if your pop() issue is due to this but I would suggest you save yourself some future pain and not use it at all. -- 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
Re: PathTools 3.10 released
On Thu, Aug 25, 2005 at 10:31:03PM -0500, Ken Williams wrote: I finally found time to implement the code for the prospective tests that Schwern added to File::Spec, so I uploaded 3.10 to CPAN. Should be hitting mirrors now. Which prospective tests were those? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
[PATCH lib/CPAN.pm] Make curl follow redirects
curl won't follow redirects unless specificly told to do so with the -L
flag. CPAN.pm currently doesn't give it this flag so it can't load from
things like http://search.cpan.org/CPAN/
Patch attached.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml
--- lib/CPAN.pm 2005/08/21 07:12:45 1.1
+++ lib/CPAN.pm 2005/08/21 07:13:37
@@ -2653,7 +2653,9 @@
$src_switch = -c;
} elsif ($f eq wget){
$src_switch = -O -;
- }
+ } elsif ($f eq 'curl'){
+$src_switch = ' -L';
+ }
my($chdir) = ;
my($stdout_redir) = $asl_ungz;
Re: resolving methods at compile time
On Wed, Aug 17, 2005 at 12:00:18PM -0700, Philippe M. Chiasson wrote: This somewhat simplistic benchmark seems to indicate there actually is a performance hit to using that form of my statement snip $ perl-5.8.6 bench-my.pl declared 127166/s -- -6% normal 134590/s 6% -- $ perl5.8.6 ~/tmp/foo.plx Rate declared normal declared 162068/s -- -1% normal 163959/s 1% -- $ perl5.8.6 ~/tmp/foo.plx Rate declared normal declared 162444/s -- -0% normal 162474/s 0% -- $ perl5.8.6 ~/tmp/foo.plx Rate declared normal declared 162103/s -- -0% normal 162893/s 0% -- $ perl5.6.2 ~/tmp/foo.plx Benchmark: running declared, normal, each for at least 15 CPU seconds... declared: 19 wallclock secs (15.56 usr + 0.00 sys = 15.56 CPU) @ 119003.86/s (n=1851700) normal: 18 wallclock secs (15.35 usr + 0.09 sys = 15.44 CPU) @ 121247.47/s (n=1872061) Rate declared normal declared 119004/s -- -2% normal 121247/s 2% -- $ perl5.6.2 ~/tmp/foo.plx Benchmark: running declared, normal, each for at least 15 CPU seconds... declared: 18 wallclock secs (14.92 usr + 0.09 sys = 15.01 CPU) @ 124462.43/s (n=1868181) normal: 18 wallclock secs (15.55 usr + 0.03 sys = 15.58 CPU) @ 116665.02/s (n=1817641) Rate normal declared normal 116665/s -- -6% declared 124462/s 7% -- $ perl5.6.2 ~/tmp/foo.plx Benchmark: running declared, normal, each for at least 15 CPU seconds... declared: 17 wallclock secs (15.94 usr + 0.00 sys = 15.94 CPU) @ 120326.35/s (n=1918002) normal: 16 wallclock secs (15.62 usr + 0.03 sys = 15.65 CPU) @ 120341.15/s (n=1883339) Rate declared normal declared 120326/s -- -0% normal 120341/s 0% -- No significant difference from where I'm sitting. Different OSs, different compilers, different versions of Perl and a heavy dose of Benchmark.pm flutter. -- 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: [EMAIL PROTECTED] Constant.t fix for VMS.
On Thu, Aug 18, 2005 at 08:49:52PM -0400, John E. Malmberg wrote: This test script was not using the same names for the VMS specific files descrip.mms and descrip.mms_old that the rest of Makemaker was doing. ExtUtils::Constant is not part of MakeMaker. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Re: lib/test/simple/t/create.t help with VMS issue needed.
On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote:
There does not seem to be a method of explicitly closing or flushing the
output stream being written to by Test::Builder.
Any ideas on how to resolve this?
I can change the test to write to a tied filehandle or I can make sure the
new Test::Builder object which outputs to some_file is destroyed before I
read from some_file. The later has the nice side effect of testing that
destroying a Test::Builder object closes any open filehandles.
Try the attached patch and let me know.
--
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
=== t/create.t
==
--- t/create.t (revision 2525)
+++ t/create.t (local)
@@ -16,22 +16,24 @@
use Test::Builder;
my $more_tb = Test::More-builder;
-my $new_tb = Test::Builder-create;
-
-isa_ok $new_tb, 'Test::Builder';
isa_ok $more_tb, 'Test::Builder';
-isnt $more_tb, $new_tb, 'Test::Builder-create makes a new object';
-
is $more_tb, Test::More-builder, 'create does not interfere with -builder';
is $more_tb, Test::Builder-new, ' does not interfere with -new';
-$new_tb-output(some_file);
-END { 1 while unlink some_file }
+{
+my $new_tb = Test::Builder-create;
-$new_tb-plan(tests = 1);
-$new_tb-ok(1);
+isa_ok $new_tb, 'Test::Builder';
+isnt $more_tb, $new_tb, 'Test::Builder-create makes a new object';
+$new_tb-output(some_file);
+END { 1 while unlink some_file }
+
+$new_tb-plan(tests = 1);
+$new_tb-ok(1);
+}
+
pass(Changing output() of new TB doesn't interfere with singleton);
ok open FILE, some_file;
Re: [EMAIL PROTECTED] bninfnan.t setting include path to file.
On Fri, Aug 12, 2005 at 05:05:47PM -0400, John E. Malmberg wrote:
--- lib/bignum/t/bninfnan.t Fri Aug 12 16:52:35 2005
+++ lib/bignum/t/bninfnan.t_25289 Fri Aug 12 16:58:21 2005
@@ -8,7 +8,7 @@
BEGIN
{
$| = 1;
- my $location = $0; $location =~ s/bninfnan.t//i;
+ my $location = $0; $location =~ s/biinfnan.t//i;
if ($ENV{PERL_CORE})
{
@INC = qw(../lib ../lib/bignum/t); # testing with the core distribution
I think your patch is backwards.
To avoid these sort of mistakes in the future I'd suggest using RCS on the
files you edit rather than diffing copies.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer
Re: VMS patch for Test::Harness
On Thu, Aug 11, 2005 at 12:50:39PM -0400, John E. Malmberg wrote: The explicit call for the MCR shell is not needed in this case on OpenVMS. The VMS.C code will add it in if needed when it actually runs the child, and the VMS.C code knows to automatically vmsify() the command. Is this a recent feature? ie. Will this break on somewhat older Perls or older VMSes? -- 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: is $[ really deprecated?
On Thu, Aug 04, 2005 at 12:26:32AM +0200, Abigail wrote: What would the gain be if you remove $[? The ponie guys might find it useful not having to implement it. Nick? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [PATCH] POD typos
On Mon, Aug 01, 2005 at 10:42:46AM +0200, Rafael Garcia-Suarez wrote: Piotr Fusik wrote: I've extracted a list of words from all the PODs and spell-checked it. The result is in the attachment. Thanks, applied, except bits that touch dual-live modules. I've applied the fixes from both his spell check packages to Test-Simple and ExtUtils-MakeMaker. -- 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
Re: pp_negate
On Fri, Jul 29, 2005 at 08:36:10AM +0200, Piotr Fusik wrote: 2. [#36675] Strings starting with '-' or '+' are treaded as strings, even when they represent numbers. Now I doubt this should be changed, but at least it should be clearly documented in perlop and probably perltrap. (imagine someone extracts numbers with a regular expression or split, and expects -100 to be treated the same way as 100) I guess the upshot of this is: $ perl -wle '$f = -100; print -$f' +100 $ perl -wle '$f = -100; print -$f' 100 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [PATCH] perlfunc.pod grammar fixes
On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote: Note that the $year element is Inot simply the last two digits of -the year. If you assume it is, then you create non-Y2K-compliant +the year. If you assume it is and then you create non-Y2K-compliant programs--and you wouldn't want to do that, would you? The original looks more correct. Maybe its using a comma wrong, but it has the proper meaning. Note that a block by itself is semantically identical to a loop -that executes once. Thus Clast can be used to effect an early +that executes once. Thus Clast can be used to affect an early exit out of such a block. effect is a noun. affect is a verb so I think this change is correct. Sets the current position for the Creaddir routine on DIRHANDLE. POS -must be a value returned by Ctelldir. Has the same caveats about -possible directory compaction as the corresponding system library +must be a value returned by Ctelldir. Cseekdir also Has the same caveats +about possible directory compaction as the corresponding system library routine. s/Has/has/ -You can effect a sleep of 250 milliseconds this way: +You can affect a sleep of 250 milliseconds this way: This is correct. the original quicksort was faster. 5.8 has a sort pragma for limited control of the sort. Its rather blunt control of the -underlying algorithm may not persist into future perls, but the +underlying algorithm may not persist into future Perls, but the ability to characterize the input or output in implementation independent ways quite probably will. See Lsort. Perl is the language. perl is the program. Its a bit hazy which this is talking about but I think it makes sense that the behavior of a module is in a future version of the language. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [PATCH] perlfunc.pod grammar fixes
On Thu, Jul 28, 2005 at 03:50:57AM -0400, Randy W. Sims wrote: Usage Note: Affect and effect have no senses in common. As a verb affect is most commonly used in the sense of ?to influence? (how smoking affects health). Effect means ?to bring about or execute?: layoffs designed to effect savings. Thus the sentence These measures may affect savings could imply that the measures may reduce savings that have already been realized, whereas These measures may effect savings implies that the measures will cause new savings to come about. Forget it. I'm learning an easier language, like Finnish. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: Perl 64bit
On Thu, Jul 28, 2005 at 05:06:52PM +0200, Jorge Schrauwen wrote: 32bit compiler just fails with perl. 64bit compiler works but gives and error about DynaLoader.pm not being found and then quits. It would be very helpful to see the actual error messages. -- 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]
Y2K docs in the 21st century (was Re: [PATCH] perlfunc.pod grammar fixes)
On Thu, Jul 28, 2005 at 02:55:10PM -0500, David Nicol wrote: I like the fact that the perl documentation is peppered with correct uses of effect as a verb. I doubt the wisdom of continuing to talk about Y2K compliance, here in Y2K+5. We could talk about Y2100 compliance. I think folks understand that Y2K is not just about the year 2000 but about using truncated years in general and its not necessary to coin a new term. Same problem, different century. Also... Note that the $year element is lnot simply one hundered plus the last two digits of the year. By assuming that it is you will create non-Y2100-compliant code and guarantee your grandchildren careers in computer maintenance. I can understand people in 1998 assuming 98 is the last two digits of the year and never bothering to look at the docs, but someone mistaking 105 as being one hundred plus the last two digits of the year... that seems a bit contrived. Possibly the best solution I've seen to this problem was the one employed in Clinton Pierce's surprisingly well written Learn Perl In 24 Hours. Its not a year, stop calling it that. Its years offset from 1900. His book always refers to it as $year_offset or $year_off but never $year. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [ANNOUNCE] Test::Simple/More/Builder 0.60_01
On Thu, Jul 28, 2005 at 05:48:58PM -0500, Peter wrote: So, the way I would go about using this would be something like this? my $obj=new SomeObj(); isa($obj, SomeObj) or BAIL_OUT(It wasn't my object :(); isa_ok() but you get the idea. You call it when you think the code is so busted that its not worth continuing any testing, that means halting the current test and not running any further test files. -- 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: Y2K docs in the 21st century (was Re: [PATCH] perlfunc.pod grammar fixes)
On Thu, Jul 28, 2005 at 06:58:35PM -0400, Horsley, Tom wrote: And therefore only Linux will have the 2039 bug. s/Linux/Unix/ Please let's not start confusing Linux with Unix or Redhat with Linux or Windows with computers on p5p, too. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: RFC: index core pods with X
On Wed, Jul 27, 2005 at 04:14:02PM +0100, Nicholas Clark wrote: So this is a bit of a bikeshed issue. Can be summed up as follows: Use good English. -- 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 #36674] -undef() eq '-0'
On Wed, Jul 27, 2005 at 03:43:19PM -0700, Piotr Fusik wrote: The result of the unary minus operator, when applied to an undefined value (e.g. undefined variable) is unexpected: perl -le 'print for -0,-,-0.0,-undef' 0 0 -0 -0 In my opinion, -undef should be identical to -, i.e. 0, not -0.0. I'd say -0 but same end result. -0 and -undef should probably produce the same thing. $ perl -MDevel::Peek -wle 'print Dump -undef' Use of uninitialized value in negation (-) at -e line 1. SV = NV(0x80de00) at 0x801270 REFCNT = 1 FLAGS = (PADTMP,NOK,pNOK) NV = -0 $ perl -MDevel::Peek -wle 'print Dump -0'SV = IV(0x80b520) at 0x801270 REFCNT = 1 FLAGS = (PADBUSY,PADTMP,IOK,READONLY,pIOK) IV = 0 Not that it really makes much difference but its curious why undef is being numerified as an NV. -- 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
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Tue, Jul 26, 2005 at 12:37:03AM -0400, John E. Malmberg wrote: The zlib module would not build. I had to change the makefile.pl to fix that. What was needed is a space between the @ and a macro which expanded to MCR imagename. With out that space, MMK interprets the @ to run MCR.COM. I do not know if the makemaker code should have fixed this, or if it is a bug in the makefile.pl. Its a bug in the Makefile.PL. That section is all raw make code tacked onto the end of the generated Makefile. --- ext/compress/zlib/makefile.pl_blead Mon Jul 25 21:33:47 2005 +++ ext/compress/zlib/makefile.pl Mon Jul 25 21:32:52 2005 If possible, try to preserve case on filenames. Otherwise the pumpkings will have to hand twiddle the patch files to make them apply. -- 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: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Mon, Jul 25, 2005 at 03:30:52PM -0400, John L. Allen wrote: I thinks this last piece is confusing: The Lcrypt|/crypt function is unsuitable for hashing large quantities of data, not least of all because you can't get the information back. Look at the LDigest module for more robust algorithms. Hashing is not done with the intent to get the data back, so that can't be the reason why crypt() is unsuitable. Either state another reason - perhaps because it is too slow or doesn't easily allow hashing of an arbitrarily long string - or leave it unspecified. Good point. Originally that said unsuitable for encrypting so the explaination made a bit more sense. I'd assume crypt() is unsuitable for large amounts of text because the hash size is too small and there's a significant risk of collision, espcially if its DES. Anyone care to confirm? -- 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 lib/Pod/Perldoc.pm] search perlvar with perldoc -a
On Tue, Jul 26, 2005 at 10:53:40AM -0400, Ivan Tubert-Brohman wrote: Using long options sounds like a good idea. However, I'm not sure if we should be removing or changing the meaning of some of existing one-letter options. You know, backward compatibility and all that... Fortunately the perldoc interface is intended for humans who have a much better time of adapting to change than computer programs. For precedent, the perl debugger interface was recently overhauled in an incompatible way. -- 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-5.8.7] Perl regression tests fail when lib directory is present
On Tue, Jul 26, 2005 at 07:51:48PM +0200, Gerrit P. Haase wrote:
Yep, the example with the delete( $ENV ...) shows clearly that there
is a problem with forked/spawned processes which should be resolved.
In the first place I would be glad if someone (petdance?) could fix TH
for Cygwin so that it works to install modules (well, to run the test
suites) on Cygwin.
I wonder why I got no errors when running the testsuite during the build
of perl-5.8.7, maybe some more tests are needed to cover this issue?
5.8.7 ships with Test::Harness 2.48 which doesn't have this code.
Otherwise, there appears to be no specific test of delete $ENV{...}.
There's something in t/op/local.t which dances around the issue.
There probably should be a t/op/env.t, I'm kind of surprised there isn't.
--
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
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Tue, Jul 26, 2005 at 08:23:03PM +0200, Gerrit P. Haase wrote: 5.8.7 ships with Test::Harness 2.48 which doesn't have this code. It fails to run the tests from the command line with the default installation of perl-5.8.7 for Cygwin? Huh? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Tue, Jul 26, 2005 at 10:57:08PM +0200, Gerrit P. Haase wrote: Andrew found relevant cahnges and you replied: Oh yeah. Huh. Good question. -- 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: wantarray() description in perlfunc as of v5.8.7
On Wed, Jul 27, 2005 at 12:07:57AM +0200, Abigail wrote: It would be helpful to have a term which means 'block from which one can return', i.e. a sub or eval. Suppose we use the word 'frame'. Then I'd propose the statement above except with 'frame' instead of 'subroutine or method'. This whole exercise started because people found the current documentation unclear. I don't think that introducing the concept frame is going to make the documentation any more clear. Perhaps less. If there are several places in the documentation where we refer to this odd sort of lexical/subroutine/eval... thing that's not really just a lexical scope and not really just a subroutine scope it would be nice to give it a name and a definition somewhere rather than having to repeat the awkward scoping rules every time. Or maybe the issue is its not entirely obvious that eval STRING establishes a new lexical scope. I know I didn't realize it until recently. -- 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
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Tue, Jul 26, 2005 at 03:27:17PM -0700, Andrew Ho wrote: So I think the next step is to figure out who can help look at that latter problem. Is there a bug I or someone else should file somewhere? To make sure it isn't completely forgotten you can put it into the bug tracker with perlbug. -- 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: RFC: index core pods with X
On Tue, Jul 26, 2005 at 08:54:48PM -0400, Ivan Tubert-Brohman wrote: However, another potential use of this index could be to create an actual printed index using latex, or an index file in POD, which then can be converted to HTML and other formats. In such an index, it would look much better with proper capitalization. So I guess you are right, and the real answer is for perldoc to handle that. It could try a case-sensitive search first, and if it returns no results, try a case-insensitive search. More importantly, make your source data as exact as possible so the maximum amount of information is available to the user. Case is information. Users of the data (ie. perldoc) can add their own fuziness as desired. One of the more common failure modes for that sort of predictively adjusting the data based on expected use is having data with HTML in it because its only intended to go to a web page. And then a year down the road living in pain because someone asks you to generate XML. Strange, I ended up debating myself! Just try not to do it on crowded street corners. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Mon, Jul 25, 2005 at 11:21:24AM +0200, H.Merijn Brand wrote: On Sun, Jul 24, 2005 at 02:03:31PM -0400, Ronald J Kimball wrote: Personally, I don't like the new documentation in this patch. It seems to put the focus more on correcting the issue about encryption, rather than actually documenting what crypt() does. I have applied the combo of these two as change #25220 In the future I'd prefer a *new* patch that would overrule the first (unless that was already applied and acknowledged to the list). Now I had to apply the first before applying the second. Ooops, I thought the second one was a combo. -- 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: File::Path's rmtree - CAN-2005-0448
On Mon, Jul 25, 2005 at 08:07:11AM -0700, Gisle Aas wrote: This is how our File::Path now differs from the one found at rsync://ftp.linux.activestate.com/perl-5.8.x: That's a whole lotta code change. Is any of it whitespace? Can it be reduced using -b? Any chance we could see this as a set of patches pulled from your repo? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: [PATCH lib/Pod/Perldoc.pm] search perlvar with perldoc -a
On Mon, Jul 25, 2005 at 05:58:06PM -0400, Ivan Tubert-Brohman wrote:
The effect of this patch is that you can now use
perldoc -a '$_'
to look for $_ in perlvar.
I'm not entirely happy with the letter I chose ('a'). Obviously -v or -V
would be easier to remember, but they were both taken, and they are
frequently associated with verbosity and version anyway. I chose 'a'
because its the next letter in vAriable, but if you can come up with
something better I'm all ears. I also considered making -f look at both
perlfunc and perlvar, but that is questionable because, of course,
variables are not functions. ;-)
--var?
This cracks open --foo style configs in perldoc, but if its getting that
hard to wedge in new features maybe its time they did so and recovered some
of the less used single letter options, like -w -n -d -o -M and -X, by
moving them to --foo style.
perldoc is currently using over half the alphabet as switches.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
Re: perlfunc sez crypt() encrypts... but it doesn't.
On Sun, Jul 24, 2005 at 12:59:06PM +0200, Rafael Garcia-Suarez wrote: On 7/24/05, Michael G Schwern [EMAIL PROTECTED] wrote: More importantly for the purposes of documentation, at least on my system, I see this: Just because someone else does something poorly doesn't mean we have to, too. perlfunc says : =item crypt PLAINTEXT,SALT Encrypts a string exactly like the crypt(3) function in the C library And the C function is a wrapper around the libc function. That's one of the many C/UNIX legacies that are present in the perl core... I'm not sure I understand. Nobody's saying that crypt() isn't or shouldn't be a wrapper around crypt(3) or that its behavior should change, just that we don't have to parrot their documentation inadequacies. -- 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: What's holding up mainperl from upgrading MakeMaker?
On Sun, Jul 24, 2005 at 12:58:57PM -0500, Craig A. Berry wrote: At 4:27 PM +0100 7/23/05, Nicholas Clark wrote: However, VMS is currently failing to build even miniperl, due to its C compiler being more stringent about const consistency than anything else on the planet. It's the same compiler as the Tru64 compiler, but the default options on the build tools reflect the assumption that all warnings will be fixed before proceeding. Wow, it treats warnings as errors? That's... ummm-- can you turn that off? I'm testing a patch against blead that should get it building again. -- 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: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Sun, Jul 24, 2005 at 02:03:31PM -0400, Ronald J Kimball wrote: Personally, I don't like the new documentation in this patch. It seems to put the focus more on correcting the issue about encryption, rather than actually documenting what crypt() does. There's much less change then there seems from the patch. Most of it is whitespace movement. The 2nd and 3rd paragraphs are mostly new, expanding on points made in the original 2nd paragraph. Everythig below paragraph #3 is all but untouched. The password example has been expanded to show how having a one way crypt that doesn't work well with with large chunks of data is useful. It adds the particularly important points about crypt() that: * The same PLAINTEXT and SALT will always return the same value * You cannot recover the PLAINTEXT from the digest * Small changes to the PLAINTEXT or SALT will result in large changes in the digest. * The SALT is visible in the digest. * Its primarily used to check the equality of two strings when you don't want to transmit those strings. I think this better documents what crypt() does and how its useful without assuming the reader already understands hashing. Furthermore, extirpated and munition in the opening paragraph? The perl documentation should be readable to people with various levels of experience with programming and with English. (Don't use a long word where a diminutive one will do.) Don't blame me, that was already there. Its been there since 5.002. I had to look up extirpated, too. In CS terms, I always thought of digest as a noun; as a verb it suggests to me the intestines. :) I would write something like Creates a digest instead. My verbing the digest noun results from trying to avoid hashing. The first paragraph is the only place that happens so I'll change it per your suggestion. The second paragraph in the existing documentation seems to explain the issue clearly anyway. Sure it does, you have a CS background and already know what a digest is and how crypt works. :) Attached is a patch with some improvements after reading it through again. * Move the mentioning of Crypt modules on CPAN up to the point where we explain crypt() is not about cryptography instead of at the end. * Mention Digest.pm rather than Crypt:: modules in the section about how crypt() isn't a particuarly robust hashing algorithm because A) Digest comes with Perl and B) we're talking about more robust digesting algorithms, not encryption. * Explain why you feed the digest in as the salt a little better. * Stop verbing digest. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml --- pod/perlfunc.pod2005/07/24 02:57:16 1.2 +++ pod/perlfunc.pod2005/07/24 20:39:44 @@ -885,31 +885,35 @@ =item crypt PLAINTEXT,SALT -Digests a string exactly like the crypt(3) function in the C library -(assuming that you actually have a version there that has not been -extirpated as a potential munition). +Creates a digest string exactly like the crypt(3) function in the C +library (assuming that you actually have a version there that has not +been extirpated as a potential munition). crypt() is a one-way hash function. The PLAINTEXT and SALT is turned -into a short, fixed length string, called a digest, which is returned. -The same PLAINTEXT and SALT will always return the same string, but -there is no (known) way to get the original PLAINTEXT from the hash. -The SALT is visible as part of the digest. Small changes in the -PLAINTEXT will result in large changes in the hash. +into a short string, called a digest, which is returned. The same +PLAINTEXT and SALT will always return the same string, but there is no +(known) way to get the original PLAINTEXT from the hash. Small +changes in the PLAINTEXT or SALT will result in large changes in the +digest. There is no decrypt function. This function isn't all that useful for -cryptography (for that, see your nearby CPAN mirror) and the name -crypt is a bit of a misnomer. Instead it is primarily used to check -if two pieces of text are the same without having to transmit or store -the text itself. An example is checking if a correct password is -given. The digest of the password is stored, not the password itself. -The user types in a password which is crypt()'d with the same salt as -the stored digest. If the two digests match the password is correct. +cryptography (for that, look for FCrypt modules on your nearby CPAN +mirror) and the name crypt is a bit of a misnomer. Instead it is +primarily used to check if two pieces of text are the same without +having to transmit or store the text itself. An example is checking +if a correct password is given. The digest of the password is stored, +not the password itself. The user types in a password which is +crypt()'d with the same salt as the stored digest. If the two
Re: [PATCH] blead help for VMS
On Sun, Jul 24, 2005 at 03:31:55PM -0500, Craig A. Berry wrote: The attached patch (plus one additional step) gets bleadperl building on VMS again. The additional step is renaming the directory ext/Compress/Zlib/zlib-src-1.2.3 to ext/Compress/Zlib/zlib-src which I assume needs to be done in Perforce. The related changes to MANIFEST and ext/Compress/Zlib/config.in are in the patch. The dot is the directory delimiter on VMS, and although newer versions of VMS have ways to escape the dots when the non-default features for doing so are enabled, it's a heck of a lot easier to just avoid dots in directory names. It'll also make version history spelunking a lot easier to not have the directory name changing all the time. -- 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
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Sun, Jul 24, 2005 at 07:58:27PM -0400, John E. Malmberg wrote: Has VMS.C changed any from Perl 5.8.7? Between bleadperl and 5.8.7? Yes. Looks like mostly elimination of 5.005threads and consting and some of that char * casting you don't like. You can get a copy of bleadperl via FTP, rsync is just more convenient. ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-current/ -- 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
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Sun, Jul 24, 2005 at 08:57:52PM -0400, John E. Malmberg wrote: What I do not have locally is an unpacked copy of unmodified 5.8.6 or 5.8.7. The local copies on this system already have my ODS-5, UNIX, and POSIX fixes, so I do not have a quick way to do a diff, and vms.c got significant changes. And since then I have discovered a small buffer highwater mark overrun in the original code. That fix is also only on my work copy. Might I suggest you check your local copies of Perl into a local version control system? I usually use RCS for small changes to small groups of files or I dump the whole thing into darcs for larger changes. Otherwise just keep a clean copy of the source code around to diff against. Disk is cheap. -- 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: perlfunc sez crypt() encrypts... but it doesn't.
On Sun, Jul 24, 2005 at 09:59:32PM -0500, David Nicol wrote:
How about using the word obfuscate? It's a nice word
They don't mean the same thing.
From The Collaborative International Dictionary of English v.0.44 [gcide]:
Extirpate \Extir*pate\ (?; 277), v. t. [imp. p. p.
{Extirpated}; p. pr. vb. n. {Extirpating}.] [L. extirpatus,
exstirpatus, p. p. of extirpare, exstirpare; ex out + strips
stock, stem, root.]
To pluck up by the stem or root; to root out; to eradicate,
literally or figuratively; to destroy wholly; as, to
extirpate weeds; to extirpate a tumor; to extirpate a sect;
to extirpate error or heresy.
Syn: To eradicate; root out; destroy; exterminate;
annihilate; extinguish.
[1913 Webster]
I think crippled or removed would be fine.
Or we could delete the mention entirely as nobody considers crypt to be a
munition anymore... I hope. IANAL.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Insulting our readers is part of our business model.
http://somethingpositive.net/sp07122005.shtml
Re: perlfunc sez crypt() encrypts... but it doesn't.
On Sun, Jul 24, 2005 at 09:59:32PM -0500, David Nicol wrote: How about using the word obfuscate? It's a nice word Or were you talking about a word to use instead of encrypt? In that case definately not. While obfuscation might be seen as a really weak form of encryption, its certainly not hashing. For one thing you can recover the original data from obfuscation. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Sun, Jul 24, 2005 at 11:09:12PM -0400, Ronald J Kimball wrote: Cool. I apologize for complaining about the parts that were already there. You only have to apologize if you don't provide a patch. ;) -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [perl #36622] y/// at end of file
On Thu, Jul 21, 2005 at 11:45:30AM -0700, Piotr Fusik wrote:
Among perl golf players, it is widely known that perl doesn't like
y/// at the very end of a file. So, we put an extra space or newline
just to make perl happy. Fortunately trailing whitespace doesn't
count to the score. :-)
First let me say how bonkers I went to get either vim or emacs to stop
putting a newline on the end of a file. For those emacs out there
the variable is require-final-newline, set it to nil. Unfortunately all
sorts of modes seem to think they know better and set it to true so even if
you shut it off in your confir you often have to manually set it off.
If you forget to add something after y///, the error messages are very
misleading. For example, this program:
#!/usr/bin/perl -0
INIT{$A{$a}=1while$a=pop}1while@A{/[a-z]+/ig}=~/\B/y/B-ZA-Gb-za/B-ZA
b-za/
when syntax-checked by perl -c gives the following error message:
Unrecognized character \x81 at deroter.pl line 2.
(do you see any \x81 here?)
Bleadperl appears to have this fixed. A test is attached. Ironically
the fresh_perl test function would always append a newline to the code
being tested. I've whacked that out, it was a hold over from the original
code in t/run/kill_perl.t.
--
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!
--- t/test.pl 2005/07/22 18:43:05 1.1
+++ t/test.pl 2005/07/22 18:43:09
@@ -579,7 +579,7 @@
{if (-e _ and -f _)}
}
-print TEST $prog, \n;
+print TEST $prog;
close TEST or die Cannot close $tmpfile: $!;
my $results = runperl(%$runperl_args);
--- t/op/tr.t 2005/07/22 18:37:29 1.1
+++ t/op/tr.t 2005/07/22 18:42:16
@@ -6,7 +6,7 @@
require './test.pl';
}
-plan tests = 99;
+plan tests = 100;
my $Is_EBCDIC = (ord('i') == 0x89 ord('J') == 0xd1);
@@ -383,3 +383,7 @@
$x = \foo;
is( $x =~ tr/A/A/, 2, 'non-modifying tr/// on a scalar ref' );
is( ref $x, 'SCALAR', doesn't stringify its argument );
+
+# rt.perl.org 36622. Perl didn't like a y/// at end of file. No trailing
+# newline allowed.
+fresh_perl_is(q[$_ = foo; y/A-Z/a-z/], '');
[PATCH fresh_perl.t] Being more careful about newlines
Removing the auto-newline appending in fresh_perl_is() exposed some newline
sloppiness in t/run/fresh_perl.t.
* When switches were stripped from test code a blank line was left.
This confused attempts by fresh_perl to display the first line of the
program as a default name.
* Some programs have no expected output, we only care that they don't
segfault. These would warn as the expected output was undef.
* Tests with no switches generated undef warnings.
* Separating the test into the program and the expected part stripped
the trailing newline off the program causing a test to fail which
ended in a here-doc separator.
--
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
--- run/fresh_perl.t2005/07/22 19:39:34 1.1
+++ run/fresh_perl.t2005/07/22 19:47:35
@@ -35,11 +35,13 @@
my($raw_prog, $name) = @$prog;
my $switch;
-if ($raw_prog =~ s/^\s*(-\w.*)//){
+if ($raw_prog =~ s/^\s*(-\w.*)\n//){
$switch = $1;
}
my($prog,$expected) = split(/\nEXPECT\n/, $raw_prog);
+$prog .= \n;
+$expected = '' unless defined $expected;
if ($prog =~ /^\# SKIP: (.+)/m) {
if (eval $1) {
@@ -50,7 +52,7 @@
$expected =~ s/\n+$//;
-fresh_perl_is($prog, $expected, { switches = [$switch] }, $name);
+fresh_perl_is($prog, $expected, { switches = [$switch || ''] }, $name);
}
__END__
@@ -383,7 +385,7 @@
-w
sub testme { my $a = test; { local $a = new test; print $a }}
EXPECT
-Can't localize lexical variable $a at - line 2.
+Can't localize lexical variable $a at - line 1.
package X;
sub ascalar { my $r; bless \$r }
@@ -510,7 +512,7 @@
if ($x == 0) { print } else { print $x }
}
EXPECT
-Use of uninitialized value $x in numeric eq (==) at - line 4.
+Use of uninitialized value $x in numeric eq (==) at - line 3.
$x = sub {};
foo();
@@ -651,8 +653,9 @@
close STDERR; die;
EXPECT
+# core dump in 2716.007
-w
-x =~ /(\G?x)?/; # core dump in 2716.007
+x =~ /(\G?x)?/;
# Bug 20010515.004
my @h = 1 .. 10;
[perl #2744] [BUG] perlcc bugs (about seven or eight of them)
[EMAIL PROTECTED] - Tue Mar 28 03:39:04 2000]:
% cat bad
#!/usr/bin/perl
sub fn {
local $key = I am the key!;
print Have: $key\n;
}
fn();
% perl bad
Have: I am the key!
% perlcc bad
Compiling bad:
ERROR: 'bad' does not have a proper extension!
This silly behavior appears to have been fixed. 5.6.2 and 5.8.6 both
take perlcc bad fine.
I can also compile the program. 5.6.2 and 5.8.0 compile with no
problem. 5.8.6 warns:
0 windhund ~/tmp$ perlcc bad
pccM2diy.c: In function `perl_init_':
pccM2diy.c:1205: warning: this decimal constant is unsigned only in ISO C90
bleadperl is downright boisterous. Its output is attached. I'm leaving
this ticket open because of all the warnings.
perlcc.out
Description: Binary data
[perl #2741] [BUG] version checking doesn't work per apparent docs
[EMAIL PROTECTED] - Tue Mar 28 03:38:58 2000]: From perldata: A literal of the form `v1.20.300.4000' is parsed as a string composed of characters with the specified ordinals. Such literals are accepted by both `require' and `use' for doing a version check. This is not true, however. Witness: % perl -MIO::File -le 'print IO::File::-VERSION 1.08 % perl -e 'use IO::File 1.08' % perl -e 'use IO::File v1.08' Octal number in vector unsupported at -e line 1, at end of line BEGIN not safe after errors--compilation aborted at -e line 1. # vector? qu'est-ce que c'est qu'un vector? # did I vec() something for select()? % perl -e 'use IO::File 1.8' IO::File version 1.8 required--this is only version 1.08 at -e line 1. BEGIN failed--compilation aborted at -e line 1. % perl -e 'use IO::File v1.8' % perl -e 'use IO::File 1.8.2' % perl -e 'use IO::File v1.8.2' % perl -e 'use IO::File 1.9.2.20' % perl -e 'use IO::File v1.9.2.20' % perl -e 'use IO::File 1.9.9' % perl -e 'use IO::File 1.9..999' % perl -e 'use IO::File v1.9.9' % perl -e 'use IO::File v1.9..999' ### Ick ick ick! Something sure smells pretty icthy around here. # And here's some naive stuff. Remember: version were always numbers # before. So one expects numbers to continue to work. But they don't. # And produce very odd msgs. % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION 1.8' 0 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION v1.8' 1 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION 1.8' 1 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION v1.8' 0 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION == 1.08' 1 % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION == v1.08' Octal number in vector unsupported at -e line 1, at end of line Execution of -e aborted due to compilation errors. # octal huh? % perl -MIO::File -e 'printf %d\n, IO::File::-VERSION == v1.80' Octal number in vector unsupported at -e line 1, at end of line Execution of -e aborted due to compilation errors. % perl -MIO::File -we 'printf %d\n, IO::File::-VERSION == v1.80' Argument ^AP isn't numeric in numeric eq (==) at -e line 1. 0 # That's disgusting. Run it through uncontrol! v1.2.3 style version strings are being phased out and should be replaced by the various options presented by version.pm. All the above now works in 5.8.6 with the exception of the final Argument ^AP isn't numeric warning which is still there. As version strings are going bye-bye will that ever be fixed?
[perl #2900] B::CC cannot sort
[EMAIL PROTECTED] - Thu Mar 30 11:30:55 2000]:
This simple program:
for $k (sort { length $ENV{$b} = length $ENV{$a} } keys %ENV) {
print $k=$ENV{$k}\n;
}
Under B::Bytecode, produces correct results, then SEGVs
Now working in 5.8.6.
Under B::C, produces correct results, then exits correctly.
Still working in 5.8.6.
Under B::CC, produces no results, but goes into recursive
doom in the sort, eventually SEGVing for lack of memory
in stack death.
$ perlcc -O foo
/sw/bin/perlcc: foo did not compile, which can't happen:
Can't locate object method _save_common_middle via package B::FAKEOP
at /sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/B/C.pm line 389.
CHECK failed--call queue aborted.
Same for bleadperl.
[perl #2898] some reports on byteloaded modules
[EMAIL PROTECTED] - Thu Mar 30 10:31:39 2000]:
You can kind create byteloaded modules and use them like
regular ones.
Can we compile it?
% perlcc -b -o /tmp/Carp.pm `perl -MCarp -le 'print
$INC{Carp.pm}'`
[random noises deleted]
[Exit 0]
That would be a yes. Can we uncompile it?
% perl -MO=Deparse /tmp/Carp.pm
/tmp/Carp.pm syntax OK
% perl -MO=Deparse,-p /tmp/Carp.pm
/tmp/Carp.pm syntax OK
5.8.6 and blead both fail with:
0 windhund ~/tmp$ perl -MO=Deparse Carp.pm
Can't locate object method sibling via package B::NULL at
/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/B/Deparse.pm line 1188.
CHECK failed--call queue aborted.
Well, yes and no. We can uncompile other things. This one
seems unwillling, however.
May we run it?
% perl /tmp/Carp.pm
[Exit 0]
Yes, we can! Can we do anything cool with it?
% perl -e 'require /tmp/Carp.pm; Carp::carp(wow)'
wow at -e line 1
require /tmp/Carp.pm called at -e line 1
Not a CODE reference at -e line 1.
perl in free(): warning: chunk is already free.
Segmentation fault
Exit 139
This now works in 5.8.6 and blead.
0 windhund ~/tmp$ perl -I. -wle 'use Carp; print $INC{Carp.pm};
carp(wow)'Carp.pm
wow at -e line 1
[perl #4687] UNIVERSAL::isa can report incorrect results
[EMAIL PROTECTED] - Mon Nov 13 00:10:45 2000]: If one package (say, Bar) is declared to be a subclass of another package (say, Foo) by assigning to the first package's @ISA array, UNIVERSAL::isa denies that Bar is a subclass of Foo unless Foo's stash has been created. This prints nothing: perl -le '@Bar::ISA = Foo; print Bar-isa(Foo)' This prints 1: perl -le '@Bar::ISA = Foo; $Foo::var = 1; print Bar-isa(Foo)' This bug is still present in 5.8.6 and bleadperl.
[perl #4990] CORE::GLOBAL support broken in 5.6.0
[EMAIL PROTECTED] - Wed Dec 20 04:02:32 2000]: Importing subroutines into the CORE::GLOBAL package does not work. The perlsub documentation makes reference to the File::DosGlob module. I've tested that the GLOBAL_glob export option for this module does not work. Although I don't have a 5.6.0 to check with, 5.6.2 seems to work as advertised. $ perl5.6.2 -dwe ' use File::DosGlob 'GLOBAL_glob'; print glob *' Default die handler restored. Loading DB routines from perl5db.pl version 1.07 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): use File::DosGlob GLOBAL_glob; print glob * DB1 As does 5.5.4, 5.8.6 and bleadperl.
[perl #5070] Inconsistent arithmetic with % and * operators
[EMAIL PROTECTED] - Thu Jan 04 10:10:18 2001]: # The following complete four-line perl script produces unexpected # results on my machine. The multiplication in the second line of # code below produces a negative result where a positive number is # expected, presumably because an integer multiplication was used # internally where a floating point operation was needed. If the # expression is broken up and evaluated piece by piece then the # correct result is produced (line 4). (The difference between the two # results is, naturally, 2**32.) The same results were produced under # perl v5.6.0. my ($p, $x, $y) = (65537, 64645, 34463); print (($x % $p) * ($y % $p), \n); # produces -2067106661 (incorrect) my ($a, $b) = ($x % $p, $y % $p); print $a * $b, \n; # produces 2227860635 (correct) Confirmed broken in 5.6.2. Confirmed fixed in 5.8.0. 0 windhund ~/tmp$ perl5.6.2 test -2067106661 2227860635 0 windhund ~/tmp$ perl5.5.4 test -2067106661 2227860635 0 windhund ~/tmp$ perl5.8.6 test 2227860635 2227860635 0 windhund ~/tmp$ perl5.8.0 test 2227860635 2227860635 0 windhund ~/tmp$ perl5.8.1 test 2227860635 2227860635
[perl #5087] used only once warning for lexicals?
[EMAIL PROTECTED] - Fri Jan 05 01:38:47 2001]: Maybe there's a reason for it, but... ~ 12:35:18$ perl -wce '$count = 1;' Name main::count used only once: possible typo at -e line 1. -e syntax OK BUT... ~ 12:35:52$ perl -wce 'my $count = 1;' -e syntax OK Shouldn't that warning be raised, regardless of scope? I agree. In fact the argument for the warning is even stronger for a lexical. A global seen only once... well maybe some other package grabs at it. But a lexical declared but never used is useless. About the only counter argument I can see is that issuing the warning for lexicals will cause a lot of existing code to start yelping. But that's what warnings are for. I for one would like to know about unused lexicals.
What's holding up mainperl from upgrading MakeMaker?
I see maintperl is still using MakeMaker 6.17. What's keeping it from using 6.30? -- 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
perlfunc sez crypt() encrypts... but it doesn't.
crypt() doesn't really encrypt, it hashes or digests. Yet perlfunc/crypt talks about encryption. This seems misleading. I discovered this while explaining that passwords aren't stored encrypted, they are hashed. This not-encryption is done with the crypt() function--erk. So I think it makes sense for the crypt docs to stop saying it encrypts. I'm no expert in cryptographic terminology, can anyone confirm or verify this? -- 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: perlfunc sez crypt() encrypts... but it doesn't.
On Sat, Jul 23, 2005 at 07:34:02PM -0400, John Peacock wrote: Michael G Schwern wrote: crypt() doesn't really encrypt, it hashes or digests. encrypt is a generic term. hash or digest are specific methods. ... So I think that trying to discuss the actual method used in the Perl documentation is really going beyond what we need to do. We could mention that DES isn't all that secure, but trying to differentiate between different encryption methods is outside of our scope (IMNSHO)... crypt() doesn't do generic encryption, its specificly a digest/hash function. While its not so important that the user knows what hashing algorithm is used it is important to make it clear that it is a non-reversable digest and not two-way encryption. Most folks, when they hear encryption think lossless, reversable encryption. Not a digest. More importantly for the purposes of documentation, at least on my system, I see this: Just because someone else does something poorly doesn't mean we have to, too. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
[PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
Attached is a patch which replaces the term encrypt in the perlfunc/crypt
documentation with digest or hash which more accurately describes what
crypt does. I also added in some better explaination of what crypt does and
what one-way hashing is useful for.
I tried to avoid hash where possible to avoid confusion with the hash
data structure. Even though they are related it would just confuse things.
Below is the new documentation after patching.
=item crypt PLAINTEXT,SALT
Digests a string exactly like the crypt(3) function in the C library
(assuming that you actually have a version there that has not been
extirpated as a potential munition).
crypt() is a one-way hash function. The PLAINTEXT and SALT is turned
into a short, fixed length string, called a digest, which is returned.
The same PLAINTEXT and SALT will always return the same string, but
there is no (known) way to get the original PLAINTEXT from the hash.
The SALT is visible as part of the digest. Small changes in the
PLAINTEXT will result in large changes in the hash.
There is no decrypt function. This function isn't all that useful for
cryptography (for that, see your nearby CPAN mirror) and the name
crypt is a bit of a misnomer. Instead it is primarily used to check
if two pieces of text are the same without having to transmit or store
the text itself. An example is checking if a correct password is
given. The digest of the password is stored, not the password itself.
The user types in a password which is crypt()'d with the same salt as
the stored digest. If the two digests match the password is correct.
When verifying an existing digest string you should use the digest as
the salt (like Ccrypt($plain, $digest) eq $digest). This allows
your code to work with the standard Lcrypt|/crypt and with more
exotic implementations. In other words, do not assume anything about
the returned string itself, or how many bytes in the digest matter.
Traditionally the result is a string of 13 bytes: two first bytes of
the salt, followed by 11 bytes from the set C[./0-9A-Za-z], and only
the first eight bytes of the digest string mattered, but alternative
hashing schemes (like MD5), higher level security schemes (like C2),
and implementations on non-UNIX platforms may produce different
strings.
When choosing a new salt create a random two character string whose
characters come from the set C[./0-9A-Za-z] (like Cjoin '', ('.',
'/', 0..9, 'A'..'Z', 'a'..'z')[rand 64, rand 64]). This set of
characters is just a recommendation; the characters allowed in
the salt depend solely on your system's crypt library, and Perl can't
restrict what salts Ccrypt() accepts.
Here's an example that makes sure that whoever runs this program knows
their own password:
$pwd = (getpwuid($))[1];
system stty -echo;
print Password: ;
chomp($word = STDIN);
print \n;
system stty echo;
if (crypt($word, $pwd) ne $pwd) {
die Sorry...\n;
} else {
print ok\n;
}
Of course, typing in your own password to whoever asks you
for it is unwise.
The Lcrypt|/crypt function is unsuitable for hashing large quantities
of data, not least of all because you can't get the information
back. Look at the Fby-module/Crypt and Fby-module/PGP directories
on your favorite CPAN mirror for a slew of potentially useful
modules.
If using crypt() on a Unicode string (which Ipotentially has
characters with codepoints above 255), Perl tries to make sense
of the situation by trying to downgrade (a copy of the string)
the string back to an eight-bit byte string before calling crypt()
(on that copy). If that works, good. If not, crypt() dies with
CWide character in crypt.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
--- pod/perlfunc.pod2005/07/24 00:04:05 1.1
+++ pod/perlfunc.pod2005/07/24 00:24:01
@@ -885,31 +885,38 @@
=item crypt PLAINTEXT,SALT
-Encrypts a string exactly like the crypt(3) function in the C library
+Digests a string exactly like the crypt(3) function in the C library
(assuming that you actually have a version there that has not been
-extirpated as a potential munition). This can prove useful for checking
-the password file for lousy passwords, amongst other things. Only the
-guys wearing white hats should do this.
-
-Note that Lcrypt|/crypt is intended to be a one-way function, much like
-breaking eggs to make an omelette. There is no (known) corresponding
-decrypt function (in other words, the crypt() is a one-way hash
-function). As a result, this function isn't all that useful for
-cryptography. (For that, see your nearby CPAN mirror.)
-
-When verifying an existing encrypted string you should use the
-encrypted text as the salt (like Ccrypt($plain, $crypted) eq
-$crypted). This allows your code to work
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
So it sounds like the resolution for this bug is to document that sort uses aliases like grep does. I've stolen the wording from grep. -- 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 --- pod/perlfunc.pod2005/07/24 02:57:16 1.2 +++ pod/perlfunc.pod2005/07/24 02:58:42 @@ -4926,6 +4926,12 @@ When Cuse locale is in effect, Csort LIST sorts LIST according to the current collation locale. See Lperllocale. +sort returns aliases into the original list, much as a for loop's +index variable aliases the list elements. That is, modifying an +element of a list returned by sort (for example, in a foreach, map +or grep) actually modifies the element in the original list. This +is usually something to be avoided when writing clear code. + Perl 5.6 and earlier used a quicksort algorithm to implement sort. That algorithm was not stable, and Icould go quadratic. (A Istable sort preserves the input order of elements that compare equal. Although
[perl #36621] /\pL/ breaks -0
[EMAIL PROTECTED] - Thu Jul 21 10:31:16 2005]: While playing perlgolf I noticed a strange thing: perl -0e print while $_=pop||,/\pL/ foo This first prints foo (that's okay). But then if you type bar, it immediately outputs bar. It shouldn't do so, because should read until \0 (notice the -0 option), not until \n. Just try /\w/ instead of /\pL/. Confirmed a bug in 5.8.0. Confirmed fixed in 5.8.6 and bleadperl. Thank you for your bug reports but please try a newer verison of Perl before reporting bugs.
Re: base pragma (was: Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give masked warning)
On Wed, Jul 20, 2005 at 11:33:01PM -0400, Randy W. Sims wrote: use base sucks. It uses horrible heuristics to do its thing and gets things wrong disturbingly often. IMO its much preferable to avoid it. As an example play around with it with multiple packages in a single file, likewise play around with evaling packages into existance at run time, and watch use base act like its been smoking crack. What do you expect it to do in these cases? use base happens at compile time. In the case of the eval your class comes into existence at run time. In the multi package one I assume you're thinking of this: package Foo; use base 'Bar'; package Bar; $bar = 42; Where, similar problem, use base 'Bar' happens at compile time so Bar does not yet exist. The only solution I can think of is to remove the checks that the base class exists. Or if there was some way for base to defer its checks until after its caller has finished compiling, but I don't think that's possible. What would break if base.pm checked %:: to see if the package is defined /after/ it fails the Ceval require $base ? That would seem to solve a large class of problems. It does do that. -- 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-5.8.7] Perl regression tests fail when lib directory is present
On Wed, Jul 20, 2005 at 06:54:13PM -0700, Andrew Ho wrote:
Here are the diffs between 2.42 and 2.44, the next most recent version:
http://www.zeuscat.com/tmp/test_harness_diff.txt
http://www.zeuscat.com/tmp/test_harness_diff.html (colorized)
I haven't peeked through the diff yet to figure out what the cuplrit is.
DING DING DING DING!
@@ -446,9 +464,21 @@
s/[\\\/+]$// foreach @inc;
}
-my %dupes;
-@inc = grep !$dupes{$_}++, @inc;
+my %seen;
+$seen{$_}++ foreach $self-_default_inc();
+@inc = grep !$seen{$_}++, @inc;
+
+return @inc;
+}
+
+
+sub _default_inc {
+my $self = shift;
+local $ENV{PERL5LIB};
+my $perl = $self-_command;
+my @inc =`$perl -le print join qq[\n], [EMAIL PROTECTED]`;
+chomp @inc;
return @inc;
}
Its gotta be something about _default_inc(). Nothing looks wrong from
here. My only guess is that local $ENV{PERL5LIB} is ineffective. That
would account for the alternation.
The algorithm is this. Test::Harness has to make sure it runs tests with
the same @INC Test::Harness ran with. To do this it could just shove all of
@INC into PERL5LIB before running the test but there's various reasons why
this is a bad idea. So it only puts into PERL5LIB that which perl does not
already have in its @INC by default.
_default_inc() figures out what the normal Perl @INC is without any -Is or
PERL5LIB by localizing PERL5LIB (thus temporarily clearing it) and running
the shell command:
perl -le print join qq[\n], @INC
to get perl to list its pristine @INC. I think the localization of PERL5LIB
is failing. This means blib/lib is still on it and it thinks its part of
the default so it strips it off. Next time around its not there so it puts
it back on. And so on.
Try printing out the value of $ENV{PERL5LIB} before and after the localization
inside _default_inc(). Finally, see what _default_inc returns.
sub _default_inc {
my $self = shift;
print STDERR P5LIB Before: $ENV{PERL5LIB}\n;
local $ENV{PERL5LIB};
print STDERR P5LIB After: $ENV{PERL5LIB}\n;
my $perl = $self-_command;
my @inc =`$perl -le print join qq[\\n], [EMAIL PROTECTED]`;
chomp @inc;
print STDERR Default @INC: @inc\n;
return @inc;
}
And then try changing local $ENV{PERL5LIB} to local $ENV{PERL5LIB} = ''.
--
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
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
On Thu, Jul 21, 2005 at 10:20:22AM -0400, Shiping Zhang wrote:
But shouldn't the alias be to the elements of the list returned by sort,
not to the elements of the original list? Should sort sort a copy of its
argument and return the sorted copy?
That's what I'm thinking, that this is a sort/foreach optimization gone
wrong. foreach $_ works on aliases of the array its looping over but sort
does NOT sort in place. foreach (sort @a) should not loop over aliases
to @a any more than foreach (map {$_} @a) should.
Its a bug.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml
Re: Circular dependency prevents installation of Scalar-List-Utils on 5.004
On Wed, Jul 20, 2005 at 11:40:59AM +0100, Paul Marquess wrote: Well, assuming you can actually build them, I find it just as easy to test modules with *all* official Perl releases. That's what I've been doing with my modules for years. Its bad enough having to work around bugs in 5.5.4 that have been fixed in later Perls. Do I also want to work around bugs in 5.5.2 that have been fixed in 5.5.4 just because someone can't be arsed to do a minor upgrade? Not particularly. A glimpse of this sort of thing can be had in all the threads bug work arounds inside Test::Builder (a module which doesn't even use threads!) to deal with 5.8.0 bugs. I'm sure XS authors have a similarly hard time. -- 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-5.8.7] Perl regression tests fail when lib directory is present
On Tue, Jul 19, 2005 at 09:16:03PM -0500, Scott Bolte wrote: It is not a perl bug. It is something in the TH module. I tested with perl 5.8.7 and the previous 5.8.6. I also, through -I, tried both the old and new modules. It clearly is the new Test::Harness module. It could be that something a new TH is doing triggers a perl bug. I really don't see how its otherwise. Here is the test matrix. Modules 5.8.6 5.8.7 - - Perl5.8.6: worked failed 5.8.7: worked failed The Test::Harness.pm version packaged by cygwin went from 2.42 to 2.52. I'll try to carve out some time tomorrow or the next day to dig in further. I would suggest working backwards though the CPAN versions of Test::Harness until it works. Then we can better spot the change which caused this bug. http://search.cpan.org/dist/Test-Harness/ -- 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: [PATCH] perlfunc.pod
On Mon, Jul 18, 2005 at 02:41:30PM -0400, Scott R. Godin wrote: FAR better would be to use HTML 4.01 Strict instead of XHTML unless you (because of MathML or some other such) know WHY you need it. Ok, is there a decent POD - HTML 4.01 Strict module out there? -- 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: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give masked warning
On Tue, Jul 19, 2005 at 12:17:43PM +0200, Rafael Garcia-Suarez wrote: I think the our variable redeclared warning can be extended to the case our $x; our $x; but specifically not to the case our $x; package X; our $x; since in this latest case the 2nd $x is bound to $X::x and not $main::x. Agreed ? Yep. -- 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: [perl-5.8.7] Perl regression tests fail when lib directory is present
Try the same Test::Harness with an older perl. See if its a perl bug. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
Re: [PATCH] perlfunc.pod
On Tue, Jul 19, 2005 at 11:31:01AM -0400, Scott R. Godin wrote: I've had this itch to rip Pod::Html to shreds for a while now, and refactor it to do the job more cleanly. Would anyone object to my taking a whack at it? It would probably be better to evaluate the existing POD - HTML converters and wrap POD::Html around them, or just leave POD::Html alone and convert installhtml to use the better module, than to write Yet Another POD - HTML Module. -- 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
Re: Circular dependency prevents installation of Scalar-List-Utils on 5.004
On Tue, Jul 19, 2005 at 05:32:30PM +0100, Paul Marquess wrote: This raises the question (which I think you yourself brought up a couple of weeks ago) about support for ancient-perl. Should module authors continue to support 5.004* at all? There's supporting the 5.4.x tree and then there's supporting old versions of that tree. There's only so far I'd expect module authors to bend over for old versions. Supporting the latest version of an old 5.x tree should be far enough. If nothing else, some of the older versions won't even compile with modern build tools. I had to do some fiddling to even get 5.4.5 compiled on OS X. Dealing with old versions is bad enough. Dealing with old releases of old versions is going well beyond the call of duty. I guess another way to look at this is to ask why has nobody else noticed the problem with these modules? Scalar-Util/Cwd/File-Spec are all fairly common modules. Could the lack of problem reports imply that nobody actually uses 5.004* anymore? That's been my conclusion, unless there's some vast Silent Majority of 5.4 users out there and in that case its their fault for keeping quiet. I think one machine at the job I just started here still runs 5.4 and its an old Dynix box that's being phased out. I few other people have mentioned machines they know of that are still running 5.4. There's really no good reason anyone should still be actively developing with 5.4, though they might be keeping it around to run old code, and I'm really not that interested in doing extra work to support sloppy sysadmins that can't be bothered to install two versions of Perl: one for active development and one for old, unsupported code. I haven't even heard from a 5.5.x user in a while. That said, here's how far back the CPAN versions of the critical modules can go which effectively sets a backwards compatibility limit for any module author not wanting to completely reinvent the wheel. Module Ships With Latest Version Installs On ExtUtils::MakeMaker 5.0 5.5.3 (with Pod::Man) Test::More 5.8.0 5.4.5 (maybe further) Test::Harness 5.0 5.5.3 (5.4.5 with a pending patch) File::Spec 5.5.0/5.4.5 5.4.5 (I think) Cwd 5.0 5.4.5 (I think) Module::Build 5.5.3 (I think) Test5.5.0/5.4.5 5.4.5 (I think) NOTE: 5.4.4 is probably equivalent to 5.4.5 in the above list but I don't have a copy to check and Module::CoreList doesn't list 5.4.4. So I'd say for most modules supporting 5.6.2 == good. Supporting 5.5.4 == excellent. Supporting 5.4.5 == if you really want to. Don't bother with intermediate versions (ie. 5.4.0, 5.5.3, etc...). If somebody really wants a module to work on an old Perl they can pay the author to backport it. Why should they do work they don't want to do, is of no benefit to them, and deals with a self-inflicted pathological mess, for Free? -- 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 #36594] ActivePerl splits arguments passed to exec() on whitespace
On Tue, Jul 19, 2005 at 10:45:34AM -0700, Piotr Fusik wrote:
The problem is that the arguments passed to exec() are not passed
as they are to the called program, but instead are split on whitespace.
Example:
perl -e exec$^X,'-e','print+join+q{,},@ARGV','foo boo bar'
prints:
foo,boo,bar
system() works fine:
perl -e system$^X,'-e','print+join+q{,},@ARGV','foo boo bar'
prints:
foo boo bar
snip
Configured by ActiveState at Mon Mar 31 00:45:28 2003.
Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
Thank you for your report.
That's an old version of Perl. Try upgrading and see if the bug is still
present.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Insulting our readers is part of our business model.
http://somethingpositive.net/sp07122005.shtml
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Mon, Jul 18, 2005 at 12:31:36AM +0200, Gerrit P. Haase wrote: Maybe a cygwin problem, I'll fetch a snapshot. With the latest snapshot I see the same behaviour. Are there other modules involved besides MM and TH? MakeMaker is not involved, just Test::Harness. All the action is in or called from Test::Harness::Straps-analyze_file. -- 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: Circular dependency prevents installation of Scalar-List-Utils on 5.004
On Mon, Jul 18, 2005 at 02:30:27PM +0100, Paul Marquess wrote: Is there any way out of this maze of twisty little passages? Install File::Spec by hand? Use 5.004_05 which comes with File::Spec? I think the assumption that Perl will come with File::Spec and Cwd is a fairly safe one these days except for pathologically old versions of Perl. -- 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 #22312] Another self-modifyingloop bug
On Mon, Jul 18, 2005 at 08:37:14PM +0100, Dave Mitchell wrote: The only question is whether it's worth the small slowdown of testing the refcnt of $_ at each iteration? A good rule of thumb is Perl should never kill perl and any marginal slow down is worth hanging onto that. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: [perl #36586] $1 gets mysteriously unset when leaving 'for' block
On Mon, Jul 18, 2005 at 01:41:52AM -0700, avised @ kbcfp. com wrote:
This test program:
my $foo = 'foo';
for ($foo) {
m!(\w+)! or die;
print \$1 has been set to: $1\n;
}
print \$1 is now: $1\n;
gives the output:
$1 has been set to: foo
$1 is now:
Somehow, although $1 was set it has been changed back to undef on
exiting the 'for' block. I don't see anything in perlre or perlvar
documenting this.
Feature, not bug.
From perlre:
The numbered match variables ($1, $2, $3, etc.) and the related punctu-
ation set ($+, $, $`, $', and $^N) are all dynamically scoped until
the end of the enclosing block or until the next successful match,
whichever comes first. (See Compound Statements in perlsyn.)
$1 and friends have an implicit local on them so they are localized to
a block. Its been this way for a long time.
$ perl5.4.5 -wle '$_ = foo; { /(\w)/; print $1 } print $1'
f
Use of uninitialized value at -e line 1.
--
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 #36576] ExtUtils::Manifest 1.46 manicopy bug
On Sat, Jul 16, 2005 at 02:51:14PM -0700, Earl Hood wrote: It appears that cp_if_diff() was supposed to be coded to only warn about non-existent file do to the initial -f $from check. But all that is printed is a warning from the check, and the following open() call fails. As it is coded, the -f $from is basically an expensive noop. What follows is a patch that if -f $from fails, a warning is printed, and the routine returns without aborting execution. Thanks, I'll patch that in. NOTE: All this came about due to the metafile target for MakeMaker is dependent on create_distdir (which is something added in later releases). The problem is if META.yml does not exist (since the developer knows that MakeMaker will do it automatically), metafile target always fails due to create_distdir failing since META.yml is in the MANIFEST which metafile target is supposed to create. The solution for this is to delete META.yml from your MANIFEST and let MakeMaker add it to the copy in the distdir. -- 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 #36577] Help
Sorry, WWW::Search is not maintained by perl5-porters. Bugs should be reported to the author, Martin Thurn ([EMAIL PROTECTED]), or via http://rt.cpan.org. I've taken the liberty of forwarding this report to the author. On Sat, Jul 16, 2005 at 06:51:51PM -0700, Jack Michigan wrote: # New Ticket Created by Jack Michigan # Please include the string: [perl #36577] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36577 Error while install WWW:Search from CPAN cpan install WWW::Search::Null::Count Running install for module WWW::Search::Null::Count Running make for M/MT/MTHURN/WWW-Search-2.476.tar.gz Is already unwrapped into directory /root/.cpan/build/WWW-Search-2.476 Has already been processed within this session Running make test /usr/bin/perl -MExtUtils::Command -e rm_f t/embedded-*.t make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) make: [testifypods] Error 1 (ignored) PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'inc', 'blib/lib', 'blib/arch') t/*.t t/0_versions# # Module Version # File::Find 1.04 # File::Spec 0.83 # Getopt::Long 2.34 # HTML::Parser 3.26 # HTML::TreeBuilder 3.13 # HTTP::Cookies 1.25 # LWP::UserAgent 2.001 # Net::Domain2.19 # Pod::Parser1.13 # Pod::Tests 0.12 # Pod::Usage 1.14 # Test::Inline 0.16 # URI1.35 # User 1.6 # perl 5.8.0 t/0_versionsok t/autosearch# t/autosearchok 2/0blib/script/AutoSearch version 2.135; WWW::Search version 2.534 t/autosearchok t/embedded-WWW-Search-Null-Countok t/embedded-WWW-Search-Null-EmptyUnquoted string end may clash with future reserved word at TempFname line 22. Semicolon seems to be missing at TempFname line 21. syntax error at TempFname line 22, near end ok Execution of t/embedded-WWW-Search-Null-Empty.t aborted due to compilation error s. # Looks like your test died before it could output anything. t/embedded-WWW-Search-Null-Emptydubious Test returned status 255 (wstat 65280, 0xff00) t/embedded-WWW-Search-Null-ErrorUnquoted string end may clash with future reserved word at TempFname line 21. Semicolon seems to be missing at TempFname line 20. syntax error at TempFname line 21, near end is Execution of t/embedded-WWW-Search-Null-Error.t aborted due to compilation error s. # Looks like your test died before it could output anything. t/embedded-WWW-Search-Null-Errordubious Test returned status 255 (wstat 65280, 0xff00) t/pod...ok t/test..ok t/use...# FYI the following backends are already ins talled (including ones in this distribution): AltaVista, Dice, Monster, Null, Nu ll::Count, Null::Empty, Null::Error, Null::NoVersion, Scraper, Simple t/use...ok Failed Test Stat Wstat Total Fail Failed List of Failed --- t/embedded-WWW-Search-Null-Empty. 255 65280?? ?? % ?? t/embedded-WWW-Search-Null-Error. 255 65280?? ?? % ?? Failed 2/8 test scripts, 75.00% okay. 0/105 subtests failed, 100.00% okay. make: *** [test_dynamic] Error 29 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Sun, Jul 17, 2005 at 12:57:17PM +0200, Gerrit P. Haase wrote: we are on Cygwin: 1.5.18(0.132/4/2) 2005-07-02 20:30, perl is the latest stable release: This is perl, v5.8.7 built for cygwin-thread-multi-64int We have a problem building modules, i.e. make test fails if a .pm file in the source package is located below the root in a subdirectory called 'lib'. Hmm. That's very strange. Particularly the oscilating nature. The reason its failing only when in lib/ is because '.' is in @INC so it can find the module. If you run the tests under taint mode (which removes the .) they should fail. I'm going to guess somethign wacky is going on inside Test::Harness. What version is being used? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: [perl #35847] File::Find not performing as documented
On Sun, Jul 17, 2005 at 06:42:40PM +0100, Dave Mitchell wrote: Perhaps the best approrach would be to document that an lstat is no longer guaranteed, but add a new option to the find() options hash, 'lstat', that if true, reinstates the guarantee. Sounds good to me. Seems like a waste to guarantee it if you're not going to use it anyway. -- 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
[perl #17765] UTF-8 in the debugger
[EMAIL PROTECTED] - Sun Jul 17 12:00:05 2005]: The problem is not the wide character in print warning. The problem is that $_ is not 'o' as it is when run outside the debugger. Seems to be fixed in 5.8.7 and bleed. Confirmed and resolved.
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Sun, Jul 17, 2005 at 10:39:05PM +0200, Gerrit P. Haase wrote: Hmm. That's very strange. Particularly the oscilating nature. The reason its failing only when in lib/ is because '.' is in @INC so it can find the module. If you run the tests under taint mode (which removes the .) they should fail. Simply running the command with -t, like so: /usr/bin/perl.exe -t -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t or is this not the right way to activate taint mode? Full on taint mode is -T and -t is just warnings. Anyhow, it serves the purpose. $ /usr/bin/perl.exe -t -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t [...] t/test5Insecure dependency in `` while running with -t switch at /usr/lib/perl5/5.8/Test/Harness/Straps.pm line 478. Oh yeah, TH isn't taint safe. Nevermind. -- 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-5.8.7] Perl regression tests fail when lib directory is present
On Sun, Jul 17, 2005 at 10:16:40PM +0200, Gerrit P. Haase wrote: I'm going to guess somethign wacky is going on inside Test::Harness. What version is being used? The dafault Test::Harness which is included with perl-5.8.7: $ perl -e 'use Test::Harness; print $Test::Harness::VERSION\n;' 2.48 Try upgrading TH and see if that fixes it. -- 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: [perl #36521] perlbug AutoReply: Deep recursion on subroutine CGI::Carp::warn
On Sun, Jul 17, 2005 at 09:41:58PM +0100, Dave Mitchell wrote:
+# [perl #36521] goto foo in warn handler could defeat recursion avoider
+
+{
+my $r = runperl(
+ stderr = 1,
+ prog = 'my $d; my $w = sub { return if $d++; warn q(bar)};
local $SIG{__WARN__} = sub { goto $w; }; warn q(foo);'
+);
+like($r, qr/bar/, goto foo in warn);
This program does not segfault, it does nothing.
0 ~$ perl5.8.6 -wle 'my $d; my $w = sub { return if $d++; warn q(bar)}; local
$SIG{__WARN__} = sub { goto $w; }; warn q(foo);'
0 ~$
I think the problem is you have code to deliberately avoid the recursion in
the subroutine. return if $d++. Get rid of that and it segfaults.
0 ~$ perl5.8.6 -wle 'my $d; my $w = sub { warn @_}; $SIG{__WARN__} = sub { goto
$w; }; warn q(foo);'
Bus error
0 ~$
--
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: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Sun, Jul 17, 2005 at 11:43:39PM +0200, Gerrit P. Haase wrote: Nope, Teat::Harness now at version 2.52: $ make test /usr/bin/perl.exe -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t Ok, see if MakeMaker has anything to do with this by running: perl -MTest::Harness -Iblib/lib -Iblib/arch -wle 'runtests @ARGV' t/*.t If it still fails then we know MakeMaker is not involved. I don't think it is. Then try: perl -MTest::Harness -Iblib/lib -Iblib/arch -wle '$Test::Harness::Debug = 1; $Test::Harness::Verbose = 1; runtests @ARGV' t/*.t The lines we're looking for are # PERL5LIB=... from THS-analyze_file() telling us how TH is setting @INC. You'll probably also want to look at the output of THS-_command_line(). Unfortunately there's not a $Debug print for that so you should put one in. Do any of these tests have -T in the #! line? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Mon, Jul 18, 2005 at 12:27:31AM +0200, Gerrit P. Haase wrote:
perl -MTest::Harness -Iblib/lib -Iblib/arch -wle '$Test::Harness::Debug =
1; $Test::Harness::Verbose = 1; runtests @ARGV' t/*.t
The lines we're looking for are # PERL5LIB=... from THS-analyze_file()
telling us how TH is setting @INC.
t/test0# Running: /usr/bin/perl -w t/test0.t
# PERL5LIB=blib/lib:blib/arch
1..1
# Running under perl version 5.008007 for cygwin
# Current time local: Mon Jul 18 00:14:08 2005
# Current time GMT: Sun Jul 17 22:14:08 2005
# Using Test.pm version 1.25
ok 1
ok
t/test1# Running: /usr/bin/perl -w t/test1.t
# PERL5LIB=
At this point I'd suspect there's something broken about %ENV. Try replacing
this in THS-analyze_file:
local $ENV{PERL5LIB} = $self-_INC2PERL5LIB;
if ( $Test::Harness::Debug ) {
local $^W=0; # ignore undef warnings
print # PERL5LIB=$ENV{PERL5LIB}\n;
}
with this:
my $libs = $self-_INC2PERL5LIB;
local $ENV{PERL5LIB} = $libs;
if ( $Test::Harness::Debug ) {
local $^W=0; # ignore undef warnings
print STDERR # PERL5LIB=$ENV{PERL5LIB}\n;
print STDERR # libs=$libs\n;
}
to determine if _INC2PERL5LIB() is acting properly.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Mon, Jul 18, 2005 at 12:38:51AM +0200, Gerrit P. Haase wrote: I have installed M/MS/MSCHWERN/ExtUtils-MakeMaker-6.30.tar.gz now, still the same, every second test fails because blib/lib isn't present in @INC (every second test). MakeMaker isn't involved. Its something inside Test::Harness::Straps-analyze_file. -- 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
[perl #22312] Another self-modifyingloop bug
[EMAIL PROTECTED] - Sat May 24 14:07:05 2003]: perl -e '[EMAIL PROTECTED]($_+=0)[EMAIL PROTECTED]/\B./g for 1100..2000' Segmentation fault (core dumped) A bit different from the normal ones which mostly involve modifying a for loop variable. map usually can take these abuses. Confirmed segfaulting in 5.8.6 and [EMAIL PROTECTED] 5.6.2, 5.5.4 and 5.4.5 don't segfault.
[perl #22336] shellwords.pl is not Shell compatible
[EMAIL PROTECTED] - Tue May 27 01:34:44 2003]: Perl still contains a Perl 4 library, that purports to emulate the way the Shell parses a command. But it can't handle backquotes or variable interpolation. And it gets backslash wrong. Could you provide an example? I can't find a case where shellwords deviates from bash's behavior. Also I don't think shellwords promises to do variable interpolation. In fact, it doesn't promise much at all. Perl make http://dapfy.bei.t-online.de/make.pl/ now contains a similar function shellparse, which corrects these bugs. Welcome to use it as you please, if you give me the credit. Unfortunately that URL is unavailable.
