Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

How to get Perlmonks to report bugs?

by schwern (Scribe)
on Jul 30, 2007 at 21:54 UTC ( #629675=monkdiscuss: print w/replies, xml ) Need Help??

I've done my semi-annual bitch at Perlmonks for not reporting bugs. Here's the last one and my personal favorite, the Ungrateful Fucks speech. These usually occur after I find out, third hand and three weeks later, that there was a big discussion on PM about some major bug or another in my code and nobody thought to tell me.

I will now take me own advice. Bitching is not doing. I have bitched, now I will do. The problem is Perlmonks folks forgetting that many CPAN authors do not read Perlmonks and so never see their complaints. Even if they do read it, complaints are easily lost in a twisty maze of replies that each individual author does not have the time to search over and over again.

A solution? Perhaps somewhere on the posting page can be a simple "are you writing about a bug in a CPAN module? Why don't you send a bug report about it?" with a link to RT. It could even get fancy and give you a single textarea box to type in the module's name and send you straight to their RT page.

Replies are listed 'Best First'.
Re: How to get Perlmonks to report bugs?
by Limbic~Region (Chancellor) on Jul 30, 2007 at 23:41 UTC
    There was a time when I read every single post at PerlMonks. My personal experience has been that the majority of folks are either happy to find out that the problem is not in their code or to use what ever work around results in their posting. No matter how easy you make it, most folks will just not report the bugs.

    So how can PerlMonks help? It would be a start for regulars to encourage posters to file bug reports in their replies. Some already do. We could add a shortcut to [RT://Module::Name]. I think this is a fine idea. We could open the ticket on the behalf of the person asking the question if our gentle encouragement falls on deaf ears. I think this is unrealistic.

    The problem exists in all perl forums that I visit regularly (PerlMonks, #perl on freenode, use.perl, the perl community on LiveJournal, etc). I hope your education extends elsewhere as well. I will try and be better at encouraging folks to file bug reports.

    Cheers - L~R

Re: How to get Perlmonks to report bugs?
by Corion (Patriarch) on Jul 31, 2007 at 06:37 UTC

    Usually, it only becomes apparent after some discussion and analysis of the user-code and the module-code that there is a bug in a module. And then we encourage the original poster to open a ticket on RT.

    In the case of long standing bugs, there either are already open RT tickets (see Problem with Archive::Tar created archives and Winzip for example) or the bugs will never be fixed due to P5P (see Problem with Find for example) and people have given up.

    It's rare that people come here with a bug report. It's even rare that people come here with self-contained code and data on the first try. People often blame modules for faults in their own code. If people opened bug reports for every question they have, you would be here bitching about how people misuse RT to ask questions. I think opening an RT bug is at the end of a discussion at best, and not at the beginning.

      Thanks, Corion.

      schwern, if you are reading this and are hopelessly committed to keeping your attitude problem, then jump to the "horizontal rule" below. :)

      I didn't file a bug report on because I never had a problem with it. I also never had a clear picture of why it would (infamously) fail (I quite recently filed a bug report in RT based on a thread at PerlMonks just because I saw what the real problem was even though I'd never run into the problem -- I don't think I had ever even used the module).

      So I did a quick search because I was curious why so many of us just knew that was no longer to be trusted. I didn't find it, but the second item I did find was me telling a poster complaining about a problem with that they needed to file a bug report with a module author (though, in this case, it was the author of Quantum::Superpositions, which was using in a way that was incompatible with older versions of and this was in 2000 so I'm not surprised that I said "tell the author" rather than "file it in RT").

      So where do a I file a bug report for schwern ? This author shouldn't be so disconnected that he doesn't realize that for years it has become common knowledge that his module can't be trusted. (:

      I've applied jdporter's patch implementing his excellent idea of supporting [rt://base] for easy linking to RT queues. That will help with encouraging things that should go to RT getting to RT.

      I was so glad to see Re: 'base' versus @ISA, why? because it included...

      Thank you all for your bug reports regarding which came out of this discussion.

      ...a reply suggesting that a bug report should be filed...

      I particularly enjoyed the well written test cases

      ...a clear test case. No, it wasn't all neatly wrapped up in a pretty package with a nice bow, but it was quite clearly described and included the exact line of code that triggered the bug by its mere presence.

      Although not necessary it makes identifying and debugging your problems a pleasure for the overworked author to fix your problem for free.

      I "fixed my problem for free", already, you ungrateful bozo. I fixed it by no longer using the module that you broke with your repeated, sloppy addition of features without much apparent regard for, well, for avoiding breaking things. My heart just bleeds for how over-worked you are. I personally have so much free time that I'm often at a loss for what to do with it. I feel awful that I didn't take the time to research and wordsmith and primp and test so that I could provide for you upon a silver platter the complete solution to everything that is wrong with your module that I don't use.

      Thank you for making use of the centralized bug tracker which many people labor to keep running and useful for free.

      And thank you for thanking PerlMonks for providing you with this valuable information. Although those who keep it running are paid lavishly, your gratitude makes their leisure-filled days that much more blissful. I'm terribly embarrassed that it took nearly a week from the time that these details were published before the information reached you. We'll try to aleviate your ignorance much more quickly in the future.

      which came with your patch

      You can't fix reckless featuritis with a patch. Not all problems with modules can be turned into a patch. And not all problems with modules are appropriate to send to RT. One of my big problems with producing patches to things is figuring out what would be acceptable to those with the power to apply the patch. Usually a module author has some guiding design principles / vision that means that not all ways to fix it are equally acceptable (though that may not be the case with so perhaps just any old patch would just be blindly applied so long as it fixed the immediate problem here).

      When I first or second heard of failing to require the requested module, I took a quick look at the source code. Part of my motivation for this was that it seemed nearly pointless to me to have a module whose purpose was to replace just push @ISA, qw( Foo ); with use base qw( Foo );. So the idea of sometimes not doing the require seemed like a dumb feature and I wanted to know what motivated it. And looking at the source code told me that what used to be a very simple, elegant module had become a very complex module that did a bunch of stuff with %FIELDS (?). Clearly, the purpose of had changed from "a nice shortcut that lets you avoid typing in the module name twice and thus tells you (because the require fails quite informatively) when you make a typo in the module name" to something much more complex that was way beyond that original scope.

      And such a basic bug being released and not quickly corrected told me that there wasn't being effort put into even keeping good support for the original purpose so I knew that was no longer appropriate for its original purpose and I stopped using it for that purpose (which meant I stopped using it completely since I've never used %FIELDS).

      No, I didn't file an RT bug report for "the purpose of has changed". I deeply regret that I didn't provide a patch to fix that. q-: The benefit of the original purpose was rather small so I figured (hoped) that there was more benefit in this new purpose and that some people had considered the situation and concluded that usurping the name "base" for this new purpose was worth the small loss.

      Now that I've spent too much of my vast expanse of leisure time dealing with someone's attitude problem, I can move on to dealing with their poor sense of design.

      If the intent is for to continue to serve its original purpose, then require failing must be reported. is a horrid idea if "use base qw( Foo::Bar );" silently ignores that I haven't installed the Foo::Bar module (which also means that it silently ignores that I meant to type "Food::Barf"). (update: This also means that it silently ignores that I've introduced a syntax error in (thanks again, Corion) or that I've set the permissions wrong on the Foo directory, etc. etc.)

      I realize that its support for %FIELDS means that "needs" to be able to deal with being given a module name for which require would fail because the module code is actually in-lined in some other file.'s two-faced way of dealing with this [ 1) don't bother to require if $VERSION exists, 2) don't complain if require fails ] is misguided. Do step (1) well so that step (2) isn't needed. Step (2) is completely unacceptable. To be clear, step (2) invalidates (IMO) the original purpose of ("a nice shortcut that lets you avoid typing in the module name twice and thus tells you (because the require fails quite informatively) when you make a typo in the module name").1

      1 And adding a step [ 3) complain if the package is empty after the require ] doesn't improve that problem. If $VERSION exists then the package isn't empty so step (3) doesn't compensate for problems with step (1) in the least. Leaving step (3) in place would be handy for systems with case-ignoring file systems, however. It'd even be nice if Perl's own require issued a warning for such.

      So step (1) needs to be improved. Clearly $VERSION needs to be defined, not merely exist. It is possible that even that may not be quite enough of a check. Someone needs to do some work / checking / monitoring to determine how well that works and to come up with better criteria. It appears clear that the module maintainer won't be doing that, however, so I hope someone else will volunteer (I still won't be using the module so my hand isn't up).

      People who use but don't bother to define $VERSION in their in-lined module code will just have to define $VERSION (or stop using or do the work to come up with a better criterion for when require isn't needed). The documentation needs to be very clear on this. should probably augment the error message from require failing by also noting that $VERSION was not defined so people who run into this problem will immediately be directed toward how to fix it.

      Perhaps if $VERSION isn't defined and then require fails, could search for any subroutines being defined in the requested package and, if there are some, produce a much more verbose message about how they now need to define $VERSION for the in-lined module to work with this fixed release of

      Anyway, I'm tired now and need to lay about for a few hours before phoning my accountant about my PerlMonks stock options.

      - tye        

        Perhaps if $VERSION isn't defined and then require fails, could search for any subroutines being defined in the requested package and, if there are some, produce a much more verbose message about how they now need to define $VERSION for the in-lined module to work with this fixed release of
        A failed require can have created subs, so the check would have to have preceeded the require. I know it's a trivial added inefficiency, but it's just one more reason to hate using base just as syntactic sugar.

      Right on. One thing I want to add is that sometimes people just want to bitch. When they come to PerlMonks to bitch about a (perceived) problem in a module, they generally do so with the conscious understanding that this is not a place to file bug reports and that no bug fixes are likely to come from their bitching here. I'd put it another way: you know the conventional wisdom that you shouldn't go snooping in your teenager's bedroom or your spouse's email unless you're certain you are really prepared for anything you might find. Well it's kinda the same here: don't go trawling through PerlMonks posts about your module unless you're prepared to do the hard work of translating bitches into bug reports yourself.

      A word spoken in Mind will reach its own level, in the objective world, by its own weight
Re: How to get Perlmonks to report bugs?
by jdporter (Chancellor) on Jul 30, 2007 at 22:45 UTC

    Nice idea, but if we implement it, you're just going to get your hopes up that much more, and be that much more disappointed. Look - we have a hard enough time just getting people to put [mod:// ] markup around module names!

    My counter-proposal is education (yes, a training issue) — add some verbiage in the "how do I post effectively" section of the site docs saying "if you have complaints/requests about a CPAN module, please consider opening an RT ticket", and so on.

    A word spoken in Mind will reach its own level, in the objective world, by its own weight
      [mod:// ] around module names? I always use [cpan:// ]. Is there any difference?

      DBIx::Class or DBIx::Class

      Ah, now I see, [mod:// ] brings you straight to the module's documentation page and [cpan:// ] goes to the search result page!


      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: How to get Perlmonks to report bugs?
by Anonymous Monk on Jul 31, 2007 at 06:09 UTC
    you need an account to report bugs, too much trouble

      I agree that requiring a login to report a bug is a pain. Reporting via e-mail is a different kind of pain. PerlMonks could get an RT login and provide a link for "submit this thread as an RT bug report" that would prompt for a distribution name and text to go in the bug report below the boiler-plate text + link to the thread in question. Then some vetting would be required to prevent duplicates or invalid submissions. Perhaps just require some PerlMonks-cabal-subset-member approval for the submission to be sent (which would post a reply noting this submission and linking to the generated bug).

      Heh, perhaps we should just have an e-mail-based RT/PerlMonks gateway server similar to the usenet gateway theorbtwo wrote (only for selected and vetted threads, of course).

      Well, I'm not going to write any of this so it'd require a pmdevil's dedication to make it happen so I won't hold my breath, but I like the idea. :)

      - tye        

      You can report bugs via email, as suggested in the Home Page:
      To submit a bug report for a given distribution by email, send mail to bug-<distribution-name>, where "<distribution-name>" is something like DBIx-SearchBuilder or Class-DBI or Acme-Current-Forever.

      perl -ple'$_=reverse' <<<ti.xittelop@oivalf

      Don't fool yourself.

      Perhaps perlmonks should become an openid provider.

Re: How to get Perlmonks to report bugs?
by Steve_p (Priest) on Aug 04, 2007 at 20:42 UTC

    Oh, if it were only limited to CPAN modules. Once upon a time, there was a thread about favorite Perl core dumps. If I hadn't bumped into that thread, there would still be an additional five core dumps that would not yet have been fixed.

    Test your modules with bleadperl!

      rsync -avz rsync:// .
      ./Configure -des -Dusedevel -Dprefix=/path/to/test/perl
      make test
      make install

    Now, please test you modules! If you have test failures that don't happen with Perl 5.8.8, send a simplified test case to

    perlbug at

Re: How to get Perlmonks to report bugs?
by Anonymous Monk on Jul 31, 2007 at 06:11 UTC
    Has this been resolved yet? Could you test the new version?

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://629675]
Approved by ikegami
Front-paged by ikegami
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2022-01-17 15:50 GMT
Find Nodes?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:

    Results (51 votes). Check out past polls.