I've skimmed the posting rules beforehand but this is my very first post here so excuse me if there is any mistake in my interpretation of them.

I've already posted this question in another Perl related forum without success and PerlMonks has eventually been pointed out.

I have the following snippet of code (the code is not as pedantic as I'd like it to be, but it's not mine and I'll dump it as-is in case I've overlooked something):

18: sub getPasswordStatus {
18:     my ($login, $password) = @_;
20:     my$quotedLogin = quotemeta($login);
21:     my $Passwd;
22: 
23:     if( $password && $password !~ /\?{7,7}/ ) {
24:        if ($password =~ m/^NO PASSWORD$/i){
25:             $Passwd = 'empty';
26:         } elsif ($password =~ /^PASSWORD$/i){
27:             $Passwd = 'password';
28:         } elsif ($password =~ /^$quotedLogin$/i){
29:             $Passwd = 'login';
30:         } else {
31:             $Passwd = 'weak';
32:         }
33:     } else {
34:         $Passwd = 'ok';
35:     }
36:     return $Passwd;
37: }
[download]

As you can see, this is not a very tricky piece of code. But I have a very weird behaviour though. For some passwords, I get the following message:

        Use of uninitialized value in string eq at lib/Pwc/Policy.pm line 24.

It's worth noting that it always happens for the same 7 or 8 passwords among more than 20000. Interestingly, the guilty passwords don't seem to differ from the others. All I can say is they are always using the same scheme: an upper case letter, then a few lower case letters and finally some numbers. But this doesn't mean that passwords matching this scheme will trigger the warning! For instance the password "Alcatel1" generates an error but the password "Algerie1" doesn't.

Even more interestingly, the error is only generated for the first test line 24, not for the others on line 26 and 28, although the passwords causing this error obviously don't match the first test and thus should go through the others.

I'm really puzzled on this bug. My leaning goes toward a Perl bug... Any idea to prove me I'm wrong?

For what it's worth, this error happens on ActivePerl:

        This is perl, v5.8.8 built for MSWin32-x86-multi-thread

Thank you very much for you help.

Best regards,

One idea i have is using File::Find and displaying something like dots on the screen after each copy operation has taken place, but this does not give a realistic progress bar as one file might be in the size of 1 gig in size and the user might be unsure of whether or not the copying is in progress.

Any ideas? :)

There's a nasty bug in the latest development version of Test::Differences. By applying a patch which allows this to pass (it currently won't):

It also allows this to pass:

Ow, ow, ow. This is terrible. Fortunately, that's what development versions are for.

I'm thinking about rewriting Test::Differences to use &Test::More::is_deeply for the test and only diff if there are differences. Currently it uses Data::Dumper or its own internal flattening and and compares the string outputs.

There are two side-effects I can think of. First, the string/numeric value comparison will work correctly. Second, the 'Array of HashRef' diff output will change dramatically. There's an internal hack which assumes an AoH is a table (likely pulled from DBI, I assume), and this:

  eq_or_diff [ { name => 'Bob', id => 1 } ],
             [ { name => 'Bob', id => 2 } ], 'aoh';

Generates this:

  #   Failed test 'aoh'
  #   at eq_or_diff.t line 13.
  # +----+---------+----------+
  # | Elt|Got      |Expected  |
  # +----+---------+----------+
  # |   0|id,name  |id,name   |
  # *   1|1,Bob    |2,Bob     *
  # +----+---------+----------+

I find this much harder to read, but others may appreciate the hash keys being pulled out as headers.

Does anyone object to me breaking this? Are there any problems that I haven't thought of? (There usually are).

The testing survey results are fascinating and, in some ways, discouraging. There is, as always, a bias in online surveys (you have to both know about the survey and have a desire to take it). For example, fully 66% of respondents claimed that their primary code base has a test suite but it's been my experience that the number is far smaller.

I originally posted this to my LiveJournal account, but brian_d_foy offered to put this on Polldaddy under his account. He also expanded a number of areas in the poll and generally made it more useful. Thanks brian.

Also, I would love to expand this survey and post it to my O'Reilly blog to get a better cross-section of programmers, but most of the free survey software out there is limited in the number of responses and/or features. Anyone have any suggestions?

Some of the results I found particularly interesting are as follows (I present hard numbers, but it's worth remembering that they are all in relation to those who took the survey):

• Almost 40% of the test suites take over 10 minutes to run. This suggests that exploring more ways of improving test suite performance is worthwhile. My Test::Aggregate and the parallel testing added to the new Test::Harness seem to be the main contenders in this area.
• Around 40% of the test suites have 500 or more tests. I've found that many suites of this nature are poorly organized and it can be difficult to figure out which tests cover what you're working on. Maybe a test suite organization article should be written.
• About half of the test suites have poor (< 50%) or no test coverage data.
• Fully 1 in 5 test suites don't pass! This is terrible. I knew this wasn't uncommon, but 20% is far higher than I expected.
• Most people (97%) who plan to add test suites aren't planning on doing it soon (in the coming month). This might not seem like a big deal, but the longer it's delayed, the less likely it is to happen.

I am using the following order on permutations. If the list to be permuted consists of increasing digits, then the permutations are numbered such that the concatenated digits of each permutation would give monotonically increasing values.

Like that:

$ perl -w permute_n.pl 3                    
0: 1,2,3
1: 1,3,2
2: 2,1,3
3: 2,3,1
4: 3,1,2
5: 3,2,1

More control compared to an iterator is given by the 'random-access' permutation 'accessor' that can generate the n-th ordered permutation directly (thus 'random access').

For example you might want to use every n-th permutation or simply step backwards through the permutations. Maybe you are interested only in permutations on prime number positions...

For such purposes the following program allows flexible access. If the list of elements is large, it can avoid a lot wasteful calculating.

For example generate the first, third, fifth, and then the fifth last, third last, and the last permutation of the list of numbers 1..18:

$ perl -w permute_n.pl 18 0 2 4 -5 -3 -1
0: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18
2: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,17,16,18
4: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,18,16,17
6402373705727995: 18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,1,3,2
6402373705727997: 18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,2,3,1
6402373705727999: 18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1

On the other hand, if all permutations are needed, any iterator would probably outperform this generator.

Enjoy.

Today I'm just sadly happy or happily sad, I don't know, I only know that I need to code in Perl, so I've written my first Perl poem:

#!/usr/pkg/bin/perl

require 5.8.8 and my $heart;

join $her and $love or die "alone\n";

Please don't take this poem too seriously. :-)

Following a nice thread in perl5 porters (where you can find the explanation):

perl -lap -0777 -e'BEGIN{close STDIN;require Text::CSV_XS}$F[$#F/6-$=]=~s/=b/h/;$_="@F[257,679,435,791]er"'

My usual "work flow" with PM in the morning is that I use 'Nodes you wrote' to locate the threads I posted in the last one or two days. Either to answer further questions of the thread poster or to read and learn from suggestions made by others in the thread. And (with shame I confess) look at the xp to see if my node meets approval or not. At the moment this means open up my nodes of the last one or two days in separate tabs and then go through each tab and click the root node link "in thread ...". Obviously I'm not interested in what I wrote but the rest of the thread.

I might be wrong, but this seems to me to be the main use for 'nodes you wrote'. The only other use that comes to mind is 'Didn't I write about this already, lets find that node', but that would not be something you'd need to do every day.

A similar suggestion (587896) was already posted at the end of 2006 (at least that was the only one I found with Super Search). The scripts posted there by ikegami and tye seem redundant by now. I suspect the root node link on every sub-node came after that(!?), maybe inspired by that node. But the basic suggestion was not implemented obviously

Now my proposal would be to either:

1) Change 'nodes you wrote' to have a root node link on every line and show fewer lines per default (20 or less). If I'm right about the main use of 'nodes you wrote' then this would be overall less strain on the servers because of fewer node lines to display and fewer web server accesses

2) even better a new node similar to 'nodes you wrote' but showing only the threads where you posted to in the last 2 days. This node could be called 'My recently active threads'.

2a) Maybe even with a list of nodes that were posted after your node (similar to 'recently active threads') so you can see immediately which nodes in these threads you haven't seen yet (courtesy of browser link highlighting).

I often see that a thread in SoPW becomes stale quickly and followup questions often get no answers. Such a cross between 'nodes you wrote' and 'recently active threads' as proposed in 2a could improve that a little because monks can keep track of changes/care for/look after those threads they know something about and ignore others where the question is about module Obscure::Never::Used::It.