Ignoring warnings

Replies are listed 'Best First'.
Re: Ignoring warnings by brian_d_foy (Abbot) on Dec 11, 2006 at 17:56 UTC
Well, you certainly set him off, but you probably could have approached it a bit more friendly too: Hey, thanks for Module::Foo. I made this change to your module to get rid of the warnings. Tone is a difficult thing to convey in email. Honestly, you've probably worsened your position by publically implying defects in his character. That's not the way to move forward (even if you hide it behind "a CPAN developer"). Post the technical details of the patch and let shame do the rest. If the author doesn't want to change the module for whatever reason, then life sucks. Maybe he'll think about it more later and make the change, but don't push the issue to get immediate gratification. There's really nothing you can do. -- brian d foy <brian@stonehenge.com> Subscribe to The Perl Review	[reply]
Re^2: Ignoring warnings by jdhedden (Deacon) on Dec 11, 2006 at 18:11 UTC
My initial posting was quite neutral in tone - just one professional conveying information to another - unless you consider the (proper) use of the word 'improper' as being unfriendly. However, your advice is good, and I'll try to be more ingratiating in my future bug reports. Regardless, I suppose the following is also apropos: Never argue with an idiot. They will only pull you down to their level, then beat you with experience. -- Brad Slipiec Remember: There's always one more bug.	[reply]
Re^3: Ignoring warnings by Errto (Vicar) on Dec 11, 2006 at 23:23 UTC
If we're going to delve into detail, I would agree that you are right about the initial posting, though it might (or might not) have helped to explain why the cast was improper. But the follow up: Is there some reason why you think the developers of Perl are wrong in providing the INT2PTR macro? Do you have some justification for not wanting to use it? That is both confrontational and sarcastic, which is not a good strategy if you want to influence someone to do something. Now, as it happens, you're right as far as I can tell: in particular the argument that "you should not enable warnings until you really understand them" strikes me as a bit absurd. And furthermore, your correspondent falls into the rather frustrating pattern of throwing around terms like "logical fallacy" without apparently understanding what they mean. That said, he's the maintainer of the module and you're not, and as a result you're now stuck.	[reply]
Re^4: Ignoring warnings by chromatic (Archbishop) on Dec 12, 2006 at 22:05 UTC
Re: Ignoring warnings by GrandFather (Saint) on Dec 11, 2006 at 19:05 UTC
Warnings are tricky. I fully agree that they should be cleaned up. But some times that is hard to achieve without introducing code that is obscure or fragile. That is not true in this case! There is a clear clean appropriate and informative fix. Applying it should be a no brainer. People are tricker than warnings. At least warnings don't vacilate as their mood changes. It may be that the only way to get your (very desirable) patch applied is to eat copious quantities of humble pie, appologise profusely, and send a link to this thread. If "typemap" is a header I would consider it essential that it "compiles clean". One of the worst things about warnings of this nature is that they hide other more important warnings by drowning them out, and that can waste a huge amount of time. Good luck with following this issue up! DWIM is Perl's answer to Gödel	[reply]
Re: Ignoring warnings by swampyankee (Parson) on Dec 11, 2006 at 18:19 UTC
How do you convince someone that warnings are there for a reason? You don't have to convince him; you just have to get him to change his behavior. Isn't there a quality rating system for CPAN modules? I don't know how thorough or how effective it is, but if "build warnings" are considered unacceptable, that may get his attention. My personal feeling, which may be similar to yours, is that compile-time warnings are unacceptable. My experience is that they are usually the result of code that is either potentially dangerous or is not standard-compliant. emc At that time [1909] the chief engineer was almost always the chief test pilot as well. That had the fortunate result of eliminating poor engineering early in aviation. —Igor Sikorsky, reported in AOPA Pilot magazine February 2003.	[reply]
Re^2: Ignoring warnings by jdhedden (Deacon) on Dec 11, 2006 at 19:58 UTC
You don't have to convince him; you just have to get him to change his behavior. Isn't there a quality rating system for CPAN modules? I don't know how thorough or how effective it is, but if "build warnings" are considered unacceptable, that may get his attention. Well, it is possible to write a review against a module and rate it. However, I have seen that venue become a vehicle for retaliatory activities. Then there is CPANTS. However, they don't build modules, leaving that activity to CPAN testers. As to CPAN testers, there is no criteria related to build warnings - just 'make test' results. So AFAIK, there is no feedback mechanism for build warnings other than reporting them to the developer (as I did, along with a patch) with RT being the most effective method for that purpose. Remember: There's always one more bug.	[reply]
Re: Ignoring warnings by Anonymous Monk on Dec 13, 2006 at 09:11 UTC
You should argue costs/benefits. It costs nothing to change, and changing makes your code more portable (on some os/compilers they might be errors). and less warnings make you look more competent.	[reply]