Rate a distribution
Find a distribution you would like to review:
Recent reviews (RSS feed)
Great module; I use it a lot for sysadmin scripts.
The only thing missing is a way to detect the number of logical cpu's in a system, but that's probably out of scope for this module.
An excellent module.
Powerful data validation library, that can be used in several different languages (in theory, though the Perl implementation is the most complete.)
I've been using Data::Rx to parse inputs and validate outputs for the Open311 spec, and the process has been mostly great. I didn't want to just use an XML validation library, as the spec allows output in both XML and JSON format, so this really hit the spot. Most concepts are quite easy to model, though some complex schemas can't be modelled with the basic building blocks, and need to be written as plugins in Perl (which turns out to be easier than expected, and quite good fun.)
The documentation is a weak point, given how sophisticated this kind of recursive typechecking can be, but hopefully latest release's contributed docs/examples help a little with that.
There's not much to say that hasn't already been said (ease of use, Plack integration). But I have been using Kelp for the past few weeks and enjoyed it so far. The fact you get a bare bones web framework with just the right amount of defaults is refreshing. If you need something else, it's easy to tack on with a module. If a module doesn't exist, it's very easy to write your own (I did in 25 lines of code) that added flash type functionality to my app.
Documentation is informative and nicely laid out. It's also available on the Kelp website with code highlighting.
Just remember the Kelp command line tool will not create the directory for you, only the structure. I fell for that one a couple of times and had to do a bit of cleaning up!
Having worked for quite some time with option processing and several other similar modules, I have to say that most of the time you probably want to use Getopt::Long instead of the other alternatives. Or at least pick the alternatives which are based on Getopt::Long, instead of those that reinvent the wheel and do their own option parsing.
Most other modules that reinvent option parsing either don't bother to do short option bundling (-abc instead of -a -b -c), or abbreviation (--long-o instead --long-option-name), or the choice to (dis)allow mix-mashing options and arguments, or support '--' to end option processing, or respect ordering, or support multiple options (--verbose --verbose), or support '--foo=val' *as well as* '--foo val', and so on. These are features and conveniences that are taken for granted by people working daily in Unix command-line.
Justin Case for the version '0.01' had termed it as useless (which was completely true then!!), but later versions (now 2.05) is DIFFERENT.
MOBI is not the easiest EBook format to use. It has a limit on the size of attached graphics, so that means you need to downsize any document images, and have the Imlib2 software installed to do this. I find ePub a much easier format to work with.
But if you need to create eBooks in this format, then this is a useful module. It works best at converting POD to MOBI format, but is flexible enough to let you add HTML elements individually such as headers and paragraph blocks. Boris is active in responding to bugs and feature requests.
I've been using Moops for my own tools for some time now. While not necessarily suitable for libraries you are uploading to CPAN it makes application development much more pleasant.
If you find your self using things like: Moo/Moose, Moo..::Types, Method::Signatures, Try::Tiny then this will fit your workflow and save you a lot of boiler-plate.
Documentation is good. Occasionally a syntax error will result in a confusing eval-based error message but apart from that it's all good!
If you experience any problems installing, check your version of "Import::Into" - my Debian-packaged one seemed to cause problems that an update fixed. Probably a non-problem by the time you read this.
I found a nice interface and great documentation here, but unfortunately, I couldn't get the most basic of US address formats to parse (with country_code set to 'US', as specified):
my $address = new Lingua::EN::AddressParse();
my $error = $address->parse("1 17th Street, Denver, CO USA");
Instead of returning an error as I would expect, this code throws several warnings and then crashes:
Use of uninitialized value $country_or_code in numeric eq (==) at /usr/local/share/perl/5.18.2/Locale/SubCountry.pm line 537.
Use of uninitialized value $country_or_code in hash element at /usr/local/share/perl/5.18.2/Locale/SubCountry.pm line 554.
Use of uninitialized value $country_or_code in concatenation (.) or string at /usr/local/share/perl/5.18.2/Locale/SubCountry.pm line 561.
Invalid country name: chosen, names must be in title case at /usr/local/share/perl/5.18.2/Locale/SubCountry.pm line 561.
Can't call method "country_code" on an undefined value at /usr/local/share/perl/5.18.2/Lingua/EN/AddressParse/Grammar.pm line 912.
Perhaps it is excellent for other kinds of use cases, but it fails at the kind of address parsing that I need.
I needed to create a simple static website but didn't want to hand-craft every file ... Wallflower came to the rescue - I generated the static site files from a Dancer2 application. It worked great!
Very fast, several times faster than Text::TabularDisplay or Text::Table (and many times faster than the other slower table-generator modules). It uses sprintf() to format a whole row instead of formatting each cell separately using sprintf() and joining cells together with join().
I did a comparison in: blogs.perl.org/users/steven_haryanto/...
A great alternative when Moo is a bit too much for you. Useful for scripts that must start really fast. Mind you, Moo loads about 5K lines of code and more than a dozen files, all of which takes +- 10ms on my computer. Mo on the other hand is only a single line of +-500 characters, and it's inlinable. It loads in under 1ms. If a script must be executed thousands of times a day, that 9ms difference will matter more.
I use this for a very lightweight parent class. A richer subclass then uses Moo.
Isn't it great that we have the choices and upgrade path from the very minimal Mo, to Moo for normal cases, to Moos and Moose for even richer (but heavier) alternatives. Truly TIMTOWTDI!
XML::Smart is the best way to work with xml files for me.
The only thing I would appreciate is more examples how to create
little more complex structure.
Thank you for incurred effort and sharing.
Given that the name of this module/app is "change shebang" (instead of "change shebang to samedir perl") perhaps this app can be made more generic? For example, I've had to change all shebangs from "#!/usr/bin/env perl" to "#!perl" and vice versa. Perhaps this module/app can become a tool to easily switch between shebangs.
Overall looks ok, with the exception that it does not look and feel like a regular Perl hash at all. Now someone just needs to create a tie interface on top of this :)
From the description: "App::whatthecommit is just another lazy-to-lazy line command utility." I'd thought the definition of laziness would be something like 'alias gc=git commit --allow-empty-message'. This is more like hubris. Or whatever. :)
Very nifty for short scripts and some clever design inside (all options are stored as arrayref, but there is some overloading to make getting boolean/flag and normal scalar value convenient).
For more "proper" scripts though (anything above say 20-30 lines) I'd recommend using something like Getopt::Long with a real spec. Some of the features I like in G::L not in Opt::Imistic: the ability to get --noOPT for free for flag options, the ability to configure permute/no_permute (mix mashing options with arguments), some data validation, and of course: autoabbreviation of long option names, which requires a spec after all.
The doc looks promising, it really looks like it could be the "strace for Perl functions", but the usage is awkward (you have to open two terminals, one for running your program and producing trace file, and another for reading this file). And I'm probably an idiot, but I can't get this module to work for me.
One alternative if you're looking for a similar module is Debug::LTrace.
For an alternative, try Debug::LTrace, which roughly provides the same basic feature but is more convenient to use from the command-line and give extra information like timing.