•
Table of Contents
•
Index
•
Reviews
•
Reader Reviews
•
Errata
Learning Perl Objects, References & Modules
By
Randal L. Schwartz
if (IsPreview == 'false') IndexFirst = 1;
5.1 Using the Debugger to View Complex DataThe Perl debugger can display complex data easily. For example, let's single-step through one version of the byte-counting program from Chapter 4: my %total_bytes; Here's the data you'll use to test it: professor.hut gilligan.crew.hut 1250 You can do this a number of ways. One of the easiest is to invoke Perl with a -d switch on the command line: myhost% perl -d bytecounts bytecounts-in If you're playing along at home, be aware that each new release of the debugger works differently than any other, so your screen probably won't look exactly like this. Also, if you get stuck at any time, type h for help, or look at perldoc perldebug.Each line of code is shown before it is executed. That means that, at this point, you're about to invoke the autovivification, and you've got your keys established. The s command single-steps the program, while the x command dumps a list of values in a nice format. You can see that $source, $destination, and $bytes are correct, and now it's time to update the data: DB<2> s You've created the hash entries through autovivification. Let's see what you've got: DB<2> x \%total_bytes When x is given a hash reference, it dumps the entire contents of the hash, showing the key/value pairs. If any of the values are also hash references, they are dumped as well, recursively. What you'll see is that the %total_bytes hash has a single key of professor.hut, whose corresponding value is another hash reference. The referenced hash contains a single key of gilligan.crew.hut, with a value of 1250, as expected.Let's see what happens just after the next assignment: DB<3> s Now you've added bytes flowing from professor.hut to lovey.howell.hut. The top-level hash hasn't changed, but the second-level hash has added a new entry. Let's continue: DB<5> s Ah, now it's getting interesting. A new entry in the top-level hash has a key of thurston.howell.hut, and a new hash reference, autovivified initially to an empty hash. Immediately after the new empty hash was put in place, a new key/value pair was added, indicating 1250 bytes transferred from thurston.howell.hut to lovey.howell.hut. Let's step some more: DB<8> s Now you're adding in some more bytes from professor.hut to lovey.howell.hut, reusing the existing value place. Nothing too exciting there. Let's keep stepping: DB<10> s This time, you added a new source, ginger.girl.hut. Notice that the top level hash now has three elements, and each element has a different hash reference value. Let's step some more: DB<12> s Now you've added a second destination to the hash that records information for all bytes originating at ginger.girl.hut. Because that was the final line of data (in this run), a step brings you down to the lower foreach loop: DB<14> s Even though you can't directly examine the list value from inside those parentheses, you can display it: DB<14> x sort keys %total_bytes This is the list the foreach now scans. These are all the sources for transferred bytes seen in this particular logfile. Here's what happens when you step into the inner loop: DB<15> s At this point, you can determine from the inside out exactly what values will result from the list value from inside the parentheses. Let's look at them: DB<15> x $source Note that dumping $total_bytes{$source} shows that it was a hash reference. Also, the sort appears not to have done anything, but the output of keys is not necessarily in a sorted order. The next step finds the data: DB<20> s As you can see, with the debugger, you can easily show the data, even structured data, to help you understand your program. |
لطفا منتظر باشید ...
