I upvoted you on the level 2 reply to Corion for having the honesty to express your frustration and because it triggered a superb answer by Corion.

I want to stress and double stress the truth of what Corion is saying: stripping down your code to the smallest bit is time consuming work, but it is still ESSENTIAL. If you have truly found a bug in Perl, then the maintainers need to know the smallest set of circumstances that cause it. This helps them quickly identify where in the Perl codebase the code relevant to creating the bug lives.

Stripping down code without disrupting a bug is an artform and sometimes requires great skill. In a way it is catch-22 for "young" (professionally speaking) Perl coders : if you had the skill and understanding of codeflow and syntax to do the stripping down you might not need help figuring out the bug in the first place.

Sometimes the good monks here can address that issue by asking people to post code, but that only works if they are doing small programs with few outside influences. Even if a newbee can't see where the codeflow or data initialization has gone wrong, a more experienced eye can. That's why we ask people to post code.

But as you point out, this is not the situation for you. Your programs aren't small and they have lots of outside influences (third party libraries). This leaves us with two possibilities: (a) you can strip it down and won't take the time (b) you are trying to write code that outstrips your mastery of Perl.

As a general rule, if one is writing code that is too complex for one to strip down on one's own to the smallest bit that reproduces the bug, then one is probably writing code beyond one's skill level in that particular language. Just as kids shouldn't swim beyond where they can swim back, or climb jungle gyms and trees beyond the point where they can get themselves down, one shouldn't aspire to write and design programs beyond the point one can independently strip down code to the smallest segment that reproduces the bug.

Assuming you are a good soul and not lazy, that leaves me with the thought that perhaps you are overreaching your skill with some of the programs you are trying to write. You may be a top notch C++ coder and can do fancy algorithm dances in C++ or Algol or Ruby or whatever, but each language has its own idiom and debugging assumptions. Perhaps you might want to consider working on more simple programs in Perl until you've become more skilled at isolating and reproducing bugs in small code snippets?

<quote> (b) you are trying to write code that outstrips your mastery of Perl. </quote> ---- As they are my own programs -- I am *CONSTANTLY* pushing against the boundaries of my current knowledge of perl.

Staying within my comfort zone is a good way for me not to grow.

Furthermore, if you do things write...you should rarely have the need nor the opportunity to stay in your comfort zone. I.e. if you have mastered an area, put it in a library, for re-use -- and you won't be re-writing your 'comfort zone code'. The only code left will be code that is outside of your current knowledge domain. Only there can learning occur. <quote> Perhaps you might want to consider working on more simple programs in Perl until you've become more skilled at isolating and reproducing bugs in small code snippets?</quote>

I have a diagnosed mental condition that precludes me working on stuff that is 'simple'. I literally can't focus on it. It's not a choice. Most people don't understand that -- and people with Overfocused ADHD are often told they are lazy, or trouble makers and are often discriminated against in the workplace or on lists and in life. But it's a medically diagnosed condition that is largely untreatable with current technology. But it causes me no end of problems, as my focus is often very different from what others think it is and that results in miscommunications, which virtually no one feels a need to even TRY to understand.

The few that try and succeed, often have great respect for my integrity, and my perseverance in spite of holding unpopular views -- I've been kick off forums for for such, because -- in one person's view, if was too risky to allow me to continue to speak to a group, as my ideas might become understood... and that would undermine the power of those in power who are running their own agenda. Thus they work to shut me away from their power base.

I know I'm likely saying a bit more than I should, but I tend to be a bit too honest for my own good -- so I am told by my friends, when I should just keep quiet. But I feel that only by being earnest, will I authentically "get anywhere". In every case where I'm doing something ahead of the curve -- the curve catches up 2-5 years later. Would it have happened w/o me... probably, eventually, but I can't help but wonder if it would have happened as quickly.

So I will likely continue to program at the edge of my skill -- even if they decline, as it's the only way to keep my brain at it's sharpest and do as much as possible to expand my grown and minimize decay...;-)

Sincerely & Cheers & thanks for your insightful and candid views.,
L Walsh

... 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.

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

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.