"you'd have to be insane to use a module called Cache::Moustache, wouldn't you?"
Or to use anything by The Inkster. FAIL.
This module saves you 1-2 characters while typing in hash- and array-ref literals. It probably belongs in Acme::.
It's kind of like LWP::Simple, but with 141 non-core dependencies, including Acme::24. Why, God, why?!
If this kind of trivial silliness belongs on CPAN at all, it should be in Acme::.
Another Inkster turd, this one providing awkward syntax for an if-statement in a closure, with some weird RDF thing to obscure its prereqs. Do not want.
This claims to be "an awesome collection of syntax extensions." What a farce. It should really be put somewhere in Acme::.
I would just like to echo Ben Bullock's review of this module. It could have been useful, but it adds a bunch of garbage the user has to delete. It's a waste of time.
As the author of Pod::Server (not Perldoc::Server) says: "Why didn't Perl have anything like this? Well, apparently it did. If I had searched through CPAN, I might have found Pod::Webserver which does the same thing this module does. After more searching, I might have discovered Pod::POM::Web. And then just recently, Pod::Browser was uploaded to CPAN. (It's getting kinda crowded here.)" Except Pod::Webserver has 0 prereqs compared to Perldoc::Server's 115 (!). Your call.
While I haven't used it for a big project, this seems like a good web-stuff module, with generally sane syntax (though the page template language hasn't grown on me yet), and no sprawling dependency chain.
Two annoyances: (1) It "helpfully" forces strict and warnings on your code. This seems to be a popular thing to do these days, but it's obnoxious for an unrelated module to enforce coding practices, especially warnings.
(2) It "requires" 5.10.1 in the Makefile.PL, even though it passes all of its tests on 5.10.0.
WTF is this? I know Moose has beaucoup prereqs, and think some of the things in this bundle are even among them, but then it takes a detour to crazy-town and installs all kinds of unrelated modules. I suppose that it will work with any CPAN client, since it installs Moose, but it is really just a poor reimplementation of Bundle::CPAN.
Speaking as the author: (1) LOL; (2) you're welcome to write a VI interface to Sepia (there's already a readline-based shell, "sepl"); (3) or you can just use one of the 3-4 VI emulators that come with Emacs ;-).
Their homepage says: "As of July 2011, Mt. Gox handles over 80% of all Bitcoin trade."
This "fleece the libtards" operation has almost run its course. Note to suckers: it's not a currency; it's a speculative bubble.
It's kind of like the built-in open() function, but less useful. It also allows you to write "$argument->function(@other_arguments)" instead of function($argument, @other_arguments)" if that floats your boat.
There was no reason -- other than pathetic self-promotion -- to add a naive implementation of edit distance to CPAN. Don't use this.
Too bad the author doesn't know about <code>kill(0, $pid)</code> -- thanks to a pointless dependency on Proc::ProcessTable, this module fails to build on most platforms.
Docs are much better now -- it looks like this module is actually turning into something interesting and (perhaps) useful.
This module provides a single function: export the documentation of an emacs lisp file to a directory. That should be its interface. Instead, it provides a weirdo "OO" interface which is far more verbose than a simple "system '...'".
Trolls should at least be clever. This one isn't.
Great if you develop modules with optional dependencies, since you usually have them all installed. Just run "perl -Mblib -MTest::Without::Module=$whatever $test".
This module looks like it might achieve sliced-bread levels of cool, but for now it's pale and half baked. It looks like this mechanism hooks into the Perl parser to give some of the advantages of macros, but you'll have to study the C code (and know some perlguts) to figure out exactly what can be done.
For next release, would you mind adding a "motivation" section and/or some pointers into perlguts?
Simple, works as advertised, wish it were core. It's great for mapping in a huge chunk of text and screaming through it with a regex. I haven't benchmarked it, but this is almost certainly much faster than slurping a file when you need read-only access.
Just what the doctor ordered! I'd previously been frustrated by Mac::PropertyList's performance and used a hand-rolled SAX parser, but no longer. Thanks.
Awkward interface, O(n^2) performance where you don't expect it... Try to roll your own before using this module.
This is not a review, but a plea to module authors. Please don't require Module::Build (especially via the execrable Module::Build::Compat waiting in ambush in an innocent Makefile.PL) unless you absolutely must. While it may be helpful for complicated Makefiles, in many cases it is simply a reinvented wheel and an annoyance.