what resources are available for obscure modules

Foxpond Hollow has asked for the wisdom of the Perl Monks concerning the following question:

I'm working with a somewhat obscure module right now, and I'm coming up against the age old "what's supposed to happen isn't happening and I can't find any reason why" problem. I've RTFD, googled the error code, performed normal debugging procedures, etc., and I can't figure out the problem. Part of this is because, as I said, it's an obscure module so there aren't a lot of resources on the possible issues.

My first instinct was to post here with some sample code and the error I'm getting and hope someone could help. But then I realized I'd rather learn to fish. As I start to work more with Perl, I'm sure I'll be using more obscure modules. I'm wondering what resources the more seasoned Perl coders use when the module's documentation isn't any help, and there isn't much of a robust community behind the module providing secondary support.

What would you do? E-mail the module's author? Keep testing and debugging until you get lucky and figure it out? Post on Perl Monks? Some other resource? Thanks.

Comment on what resources are available for obscure modules

Replies are listed 'Best First'.
Re: what resources are available for obscure modules by GrandFather (Saint) on Aug 25, 2009 at 01:35 UTC
First off, ask the monks. At least mention the module - many of us are interested in poking around code in dusty corners we haven't visited before. Part of learning to fish is watching others fish: it's not something you figure out so well from first principles! When I'm faced with an issue of this sort I debug through the module using Komodo's integrated debugger. That gives a pretty good picture of how the module goes about business. The command line debugger allows the same sort of investigation, but at a far greater investment in hair pulling and time. Obscure doesn't mean the author has lost interest and the cost of sending an email is generally pretty low. If you don't hear back then you don't hear back, but it didn't cost much and you can pursue other avenues of investigation mean time anyway. True laziness is hard work	[reply]
Re^2: what resources are available for obscure modules by toolic (Bishop) on Aug 25, 2009 at 01:44 UTC
At least mention the module And the monks are great for offering alternate solutions -- perhaps a monk has more working experinece with a simliar module.	[reply]
Re: what resources are available for obscure modules by toolic (Bishop) on Aug 25, 2009 at 01:39 UTC
You can take a look through the test suite and examples (if any) which are part of the module's distribution. Perhaps you can get better clues on the author's usage model from actual example code than from the POD. Each CPAN module has a link to its own 'Discussion Forum' -- and some even have activity on them! Each module also has links to Bug Reports, test results, ratings/reviews and a Changes file. These may provide more details regarding the code's stability/maturity, and may even mention symptoms similar to what you are observing. By all means, post issues here at the Monastery. If you can post a complete working example, with input and actual vs. expected output, all the better.	[reply]
Re: what resources are available for obscure modules by JavaFan (Canon) on Aug 25, 2009 at 01:11 UTC
Beside mailing the author (which I usually won't do, it's going to take time to get an answer, and you don't know how long, or if you get a usable answer at all - after all, it's an obscure module), there's always the source. And sometimes, it's more efficient to rewrite it from scratch.	[reply]
Re: what resources are available for obscure modules by hangon (Deacon) on Aug 25, 2009 at 06:01 UTC
To start with I'll assume you've also Searched CPAN for a newer or alternate version. So, now look at the upper right side (unless you've changed your settings) of this page for Super Search. You'll be surprised how much obscure stuff you can uncover here.	[reply]
Re: what resources are available for obscure modules by Anonymous Monk on Aug 25, 2009 at 01:55 UTC
Keep testing and debugging until you get lucky and figure it out? I will first determine if I am following the documentation (examples, testsuite...). If I am familiar with the subject (say HTTP), I will trace the code execution and compare against the RFC (what is supposed to happen, what actually happens. Eventually (an hour) I will find where the error lies(which code is responsible, what assumptions were made...). If I can narrow it down to a few function calls, I will search for related bug reports. If I can find none dealing with my problem, I will submit a bug report, and ask for help (on perlmonks, or a dedicated mailing list). I will usually keep working on it while waiting for help. Sometimes this means learning a new protocol (reading RFC), though I try to do that only under under deadline (unless its really fun). Luck only determines how fast I finish (fix, circumvent, wait, or yield).	[reply]