This module only works if your OS has /proc. This restriction isn't mentioned in the docs, or checked for during installation, nor is there even a test to see if the module actually works.
There are much better, and cross-platform, alternatives to this module.
Supposedly this was written to be faster and fix some api niggles in the venerable File::Slurp. But the documentation doesn't even mention any of this. And it doesn't even try to maintain any compatibility with the majority of the File::Slurp api that was perfectly fine. So I'll stick with the original File::Slurp for ease of use over the minor performance gain and annoying api changes of this one.
Completely useless. The author didn't do his research. HTTP::Response inherits from HTTP::Message which provides methods for converting the response to strings: as_string, and dump.
This is specifialized tool specific to linux, and the namespace chosen is inappropriately generic. This should be renamed to something like Linux::sparse or similar. It should also specify during the build phase that linux is required, using something like Devel::AssertOS.
This was fixed over a month ago, so your module isn't needed. From HTML::Parser Changes file:
2013-05-09 Release 3.71
Gisle Aas (1):
Transform ':' in headers to '-' [RT#80524]
2 years out of date, doesn't even include Moo.
great idea, but it's unmaintained
Whenever I need to do a lot of complicated image processing, I use Image::Magick; simpler stuff I typically use Imager. Although GraphicsMagick claims to be superior to ImageMagick, they're perl support is lacking. One of the developers claims that the GraphicsMagick module "is one of the most complicated PERL modules in existence" and therefore will never be submitted to CPAN:
Still broken on OS X 10.7. Author was notified and given patch to make it work, but instead of fixing, he tells users to manually install using a different compiler.
Update: it now builds fine on on OS X.
Completely superfluous. If you're using a modern version of perl you can use the smart match operator, or you can use List::Util::first().
Avoid using because the author appears to have abandoned it and there exists long-standing bugs.
The stated rationale for this module is to have a version of Object::Tiny with writable accessors. The author apparently didn't bother to do any research as that is the purpose of Object::Tiny::RW. There are many, many reviews of the the different worthwhile class builders. This low rating is intended to steer new users away from a pointlessly reinvented wheel and to seek a more widely used (hence vetted) module.
This fails to build and is unmaintained.
Documentation is lacking on the rationale for this module and why it should be used over the many, many other alternatives. Also, the source code is unreadable line noise.
Although Andy might have been mistaken in his review that the newer versions are using pure perl, I believe he has good reason. I just benchmarked 1.52 against 2.015, and 1.52 is a little more than twice as fast in both compression and decompression as 2.015.
Parse::CPAN::Packages::Fast is about an order of magnitude faster and uses only 40% as much memory. Neither, however, offer a way to iterate through the list without first creating the entire list in memory.
Interface doesn't ever stabilize. The author keeps breaking backwards compatibility. The author also freaks out if anybody asks about benchmarks and badmouths other projects.
Another useless module from a newbie. Use Object::Tiny instead.
According to the docs this is just a fork of Geo::Coder::Google that offers no addional functionality or bugfixes. It simply interfaces with Google via JSON, instead of XML. It also behaves differently than all the other Geo::Coder modules- instead of returning a simple hashref, it returns an object.
This shouldn't be a top-level namespace. Stick it under Locale::
The moronic new CPAM::TWW!
purge this from cpan, please.
Did you even make a request for the YAML::Any authors to make the order user-customizable? Or submit a patch?
Definitely not a Modern Perler (TM).
Similar interface as XML::Generator, but benchmarked as 3 times slower and no docs.
Completely broken and unmaintained.
FYI, the Yahoo Search API is now deprecated in favor of the Yahoo BOSS API, for which no perl interface currently exists.
Yeah, it's maintained again!
This is just horrible namespace pollution. It should live under the Acme namespace, where the rest of the pointless modules go to die. Seeing poor choices like this make me less inclined to use any of the author's other modules.
It might be fast, but frequently it will segfault when encoding.
I'd really like this to be a drop-in replacement for Tie::IxHash.