Different results using while/each and for/key when processing a dbm while running Perl 5.16.3 under Windows 7 #13124
Comments
From josephwall99@comcast.netHi, Sincerely, |
From josephwall99@comcast.netCreated by josephwall99@comcast.netI have a simple script that reads through the ITunes music library looking for duplicate songs. 01 - Time Spent In Los Angeles.mp3 The code that processes this input is -- #! /usr/bin/perl my $total_count = 0; chdir('i:/') || die "Failed to change drive to I $!"; while (my $song_name = (<SAMPLE>)) { dbmclose(%COUNT); # while (my ($song_name, $song_count) = each(%COUNT)) { print "Total number of songs = $total_count\n"; closedir(MUSIC); If I run the script with the for/keys code operative, I get the following correct output -- jerry jeff walker _ my old man has a count of 2 If I run the script with the while/each code operative, I consistenly get the following incorrect output -- jerry jeff walker _ my old man has a count of 2 Note that the number of records read back from the dbm is the same in both instances. When run under Linux, the two methods get identical results eqaul to what for/key returns under Windows. A further complication is that the following code -- # usr/bin/perl -w my $preferred_dbm = $AnyDBM_File::ISA[0]; if (%COUNT) { untie(%COUNT); when run against the closed dbm, always yields "COUNT IS EMPTY". This code also works as expected under Linux. Sincerely, Perl Info |
From @apAnd what happens when you comment out the line that says $COUNT{$song_name} = 0; ? And what is the output of this on all your machines? perl -MAnyDBM_File -E "say for @AnyDBM_File::ISA" -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From josephwall99@comcast.netHi, Aristotle, thanks for your reply. When I remove the line that resets each count to 0, the "Total number of duplicates" increases by 7 with each run. When I enter perl -MAnyDBM_File -E "say for @AnyDBM_File::ISA", I get SDBM_File. Thanks again, ----- Original Message ----- And what happens when you comment out the line that says $COUNT{$song_name} = 0; ? And what is the output of this on all your machines? perl -MAnyDBM_File -E "say for @AnyDBM_File::ISA" -- |
From @apOn Tue Jul 30 20:11:28 2013, josephwall99@comcast.net wrote:
Yes, obviously…
Apparently writing to that tied hash at all, even just changing stored values, messes up its key Do you get the same bug on your Linux system if you put the following line near the top of the BEGIN { @AnyDBM_File::ISA = 'SDBM_File' } -- |
From josephwall99@comcast.netAristotle, Are you able to replicate my results? Because I found - much to my amazement - that when I exited Linux and rebooted into Windows, the problem disappeared. I'm wondering what this says about the stability of Perl under Windows. And I use NDBM_File under Linux, a module that was not available under Windows, which led me to use AnyDBM_File::ISA[0], a construct which I used without understanding it. Sincerely, ----- Original Message ----- On Tue Jul 30 20:11:28 2013, josephwall99@comcast.net wrote:
Yes, obviously…
Apparently writing to that tied hash at all, even just changing stored values, messes up its key Do you get the same bug on your Linux system if you put the following line near the top of the BEGIN { @AnyDBM_File::ISA = 'SDBM_File' } -- |
From josephwall99@comcast.netOk.... ----- Original Message ----- Aristotle, Are you able to replicate my results? Because I found - much to my amazement - that when I exited Linux and rebooted into Windows, the problem disappeared. I'm wondering what this says about the stability of Perl under Windows. And I use NDBM_File under Linux, a module that was not available under Windows, which led me to use AnyDBM_File::ISA[0], a construct which I used without understanding it. Sincerely, ----- Original Message ----- On Tue Jul 30 20:11:28 2013, josephwall99@comcast.net wrote:
Yes, obviously…
Apparently writing to that tied hash at all, even just changing stored values, messes up its key Do you get the same bug on your Linux system if you put the following line near the top of the BEGIN { @AnyDBM_File::ISA = 'SDBM_File' } -- |
From josephwall99@comcast.netAristotle, jerry jeff walker _ my old man has a count of 2 Once again, christmas wrapping is not processed as a duplicate. Again, sorry for the confusion, ----- Original Message ----- Ok.... ----- Original Message ----- Aristotle, Are you able to replicate my results? Because I found - much to my amazement - that when I exited Linux and rebooted into Windows, the problem disappeared. I'm wondering what this says about the stability of Perl under Windows. And I use NDBM_File under Linux, a module that was not available under Windows, which led me to use AnyDBM_File::ISA[0], a construct which I used without understanding it. Sincerely, ----- Original Message ----- On Tue Jul 30 20:11:28 2013, josephwall99@comcast.net wrote:
Yes, obviously…
Apparently writing to that tied hash at all, even just changing stored values, messes up its key Do you get the same bug on your Linux system if you put the following line near the top of the BEGIN { @AnyDBM_File::ISA = 'SDBM_File' } -- |
From @apI have run the script now. I do not have a Windows machine, certainly not one with an I: partition, Then I had to fix the dbmopen permissions, which you gave as 644 when Then it ran, and yes it works with the `foreach` loop. Then I tried the `while` loop version. That one *never terminates*, on Then I tried it without the `$COUNT{$song_name} = 0` line and it worked I repeated this with every DBM implementation I have on this machine Then I commented out all of the dbmopen and dbmclose lines, and as In other words, this has to do with your use of DBM-tied hashes and has So all the signs point to a “don’t do that then” situation – that is, do This might be a bug in every single DBM implementation shipped by As a workaround you could reset your database by doing a $COUNT{$_} = 0 for keys %COUNT; *after* the dupe-counting loop. But then I am baffled why you are using a DBM hash in the first place if (For that matter, your careful gyrations with $song_count are ++$COUNT{$_}; Unless, that is, this hits another DBM implementation peculiarity. But of course that too seems easily solved, in your case, by simply not -- |
From josephwall99@comcast.netThanks for your time and reply, Aristotle. So..... to summarize -- The critical line of code here is $COUNT{$song_name} = 0, which updates the dbm values within the read loop. Thus --
So the undocumented error is attempting to update dbm values while reading a dbm with while/each under Windows. The answer to why I'm using a dbm when a hash would suffice is just because, I guess. Thanks, once again, ----- Original Message ----- I have run the script now. I do not have a Windows machine, certainly not one with an I: partition, Then I had to fix the dbmopen permissions, which you gave as 644 when Then it ran, and yes it works with the `foreach` loop. Then I tried the `while` loop version. That one *never terminates*, on Then I tried it without the `$COUNT{$song_name} = 0` line and it worked I repeated this with every DBM implementation I have on this machine Then I commented out all of the dbmopen and dbmclose lines, and as In other words, this has to do with your use of DBM-tied hashes and has So all the signs point to a “don’t do that then” situation – that is, do This might be a bug in every single DBM implementation shipped by As a workaround you could reset your database by doing a $COUNT{$_} = 0 for keys %COUNT; *after* the dupe-counting loop. But then I am baffled why you are using a DBM hash in the first place if (For that matter, your careful gyrations with $song_count are ++$COUNT{$_}; Unless, that is, this hits another DBM implementation peculiarity. But of course that too seems easily solved, in your case, by simply not -- |
Migrated from rt.perl.org#119007 (status was 'open')
Searchable as RT119007$
The text was updated successfully, but these errors were encountered: