Re^3: How do you find keys of a Blessed Hash?

[Corion]

... most of my code is tied in with library functions and problems I find are never in simple 1 liners, but buried amongst 2000 other lines of code. Trying to reproduce it in a short example invariably removes the ability to reproduce the bug.

That is the point of debugging your code. By reducing your code to a small snippet, you stepwise eliminate all unrelated parts. And usually, if the symptom goes away between two editions of your program, it is highly likely that the part you changed last is related to the symptom. So the trick is to keep removing parts without changing the symptom until only the core code related to the symptom is left over or until it becomes clear to you what the cause was.

If this sounds like work, that is because it is. This is why you need to do the work of removing all the unrelated cruft from your code, instead of feeling entitled that others wade through your code.

I've submitted programs that caused the perl compiler to dump core. They were closed out because they were too difficult for the developers to figure out. Note: all of my programs were written in pure perl. It shouldn't be possible for them to cause perl to core dump, any more than it should be possible for a normal user program to cause the OS kernel to panic and blue-screen(or dump core)...

Nevertheless, even though clearly a bug was demonstrated...

No. All I've seen from you were programs that could not run on their own because they relied on various other libraries. You demonstrated enough lack of grasp on your environment that it is highly likely that you mixed up compiler versions and Perl versions. Doing so is advised against and will lead to core dumps. Claiming that you have "clearly demonstrated" when you just tell vague tales of an environment that you yourself messed up is misleading.

I'm more than happy to share code... AND have done so in the past. But I didn't sufficiently deconstruct my program into an artificial and thereby, unrelated test case and got chastised for it by 'you'...#985099.

I think you shouldn't feel "chastised". I mean Re^6: Why isn't a fatal error trappable? as solid advice from experience. Debugging a program is not like retelling an epic tale from memory where the minutiae don't matter. Debugging is assiduously going over the program and its output with a fine comb, for as long as it takes. We don't know about your environment and your library versions etc., but for debugging, reproducing your environment is necessary. If you make it difficult for us to reproduce your situation, you are making it difficult for yourself to get help.

I know it's demanding of me, but your tone was spiteful and you even got several votes indicating your spiteful tone to put me down was appreciated. That doesn't come off as a very friendly helping community IMO...but I know my opinion doesn't count for much.

Seriously, I'm not doing this to be "unfriendly". I'm doing this to get results, to get programs debugged. And the only way I know to debug programs together with other people is to enable people to reproduce the situation. I give you that advice to enable others to help you. If this comes across as "unfriendly" to you, and if you feel that you need more hand-holding, then "listening" to the feedback is not enough. You will have to start doing work yourself, as has been outlined several times already - by reducing your problem to a small, self-contained program that exhibits the problem.

[perl-diddler]

That is the point of debugging your code. By reducing your code to a small snippet, you stepwise eliminate all unrelated parts. And usually, if the symptom goes away between two editions of your program, it is highly likely that the part you changed last is related to the symptom.

--- When my code was significantly simpler, that was the case, but having spend enough time in the kernel and in other real-time systems, 9 times out of 10, changing a line of code and seeing a change in behavior were unrelated because the underlying trigger was 1000's of lines away in code that seemed to work perfectly in all other cases.

Case in point was a kernel hang -- would run for up to days w/no problem, then hang, so finding 1 line to change out of 5000 and waiting for days wasn't the most ideal solution for debugging. in fact trying to break apart pieces only led to management thinking that there really was no problem or that the product should be released anyway -- because pieces would work. It was only when all the subsystems were tied together than one subsys relying on annother that called a third didn't release a deeply held lock -- so after the damage was done, only rarely would the locks go that deeply and hit the 'stuck lock'....

I could detail about 10-20 other similar situations, where none of them were simple bugs -- I was given these problems to solve because they weren't easy and couldn't be solved by simplification and simplification was only a waist of my time (not that I didn't try where possible). The one that froze every few days - I optimized the hell out of the code so it froze < 2-3 hours... then finally down to <45 minutes. My manager was pissed at me spending so much time optimizing, but when I got it to happen frequently enough, I was able to catch it in the act and finally solve the problem. Insisted on a full 7-day run-test as proof that the bug was gone...it passed, and I got downgrade my next review for wasting time optimizing the product and requiring too long for testing.

Generally, I've been trying to use perl as a higher order language, but that's when the slightest variance in my understanding and how it really works (right or wrong) leads to big brokenness later on.

Because of such, I try to add in lots of error checking and debug support routines with the result that my programming goes alot slower than most - a recent program in perl of around 2k lines as probably, easily 1k lines dedicated to debugging and error checking -- note I say easily 1k, my gut wants to say about 2/3rds or more went into error checking...boy does that slow down your coding....but it does help in narrowing down the location of problems more quickly, later...

-linda

[Corion]

Feel free to cite situations and war stories where weird practices have worked for you once.

Let me just suggest that most of your problems you've shown here are not of the grand scale of highly complex systems interacting weirdly.

Your problems are because you introduce and keep unnecessary complexity instead of removing it. If you removed stuff instead of adding more, that would help you to spot your problems faster, or at least it would help us to help you in an easier way.

But again, the stories you tell do not match up with the problems you're having here, or at least the practices you claim to have appropriated from these times do not transfer to the problems you're experiencing with Perl programming. I suggest you try a simpler approach to solve the problem at hand instead of introducing complexity you cannot handle to cater for potential problems later.