In the network administration field, there's an old saying that goes, "physical layer first". You might very well have a corruption in a network stack on some server somewhere, but you'll feel awfully silly if you debug that and find out you just had a bad Ethernet cable. People tend to look for the obvious source of the problem. Sometimes it pays better to look where it's simple to spot a problem even if that's not where you expect to find it.
Update: Another lesson that "physical layer first" saying tries to teach is that debugging by starting at the lowest level of dependencies and going up the stack from there is quicker than going from the top of the pyramid down. That's not as helpful with software as it might seem, but it is still helpful. Keep in mind, though, that the OS, the OS libraries, and perl have had much more debugging than your code that depends on them. If though, for example, you have your own module and then code on top of it that doesn't behave as you expect, don't be afraid to test and debug your module. Assuming the module works and focusing on the code that uses it can cause one heck of a headache.
In reply to Re^3: GD @data array question
by mr_mischief
in thread GD @data array question
by andy_7t
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |