Rate a distribution
Find a distribution you would like to review:
Recent reviews (RSS feed)
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.
Might be powerful and flexible, but not convenient to use especially from command-line. (I was searching for something like "strace for Perl function").
One of the more convenient and usable subroutine tracing modules on CPAN. If you're looking for something like "strace for Perl functions", try this.
Good module, but try its derivative Debug::LTrace instead. Debug::Trace doesn't fake caller() yet so traced/wrapped subroutines get caller() results that are "off-by-1" (see Hook::LexWrap). Plus, Debug::LTrace gives more information like timing.
The name and abstract is slightly inaccurate/misleading. This module is supposed to be a general logging framework instead of just subroutine entry/exit tracer. For alternative subroutine tracer, I'd recommend Devel::TraceSubs or Devel::TraceCalls (or even Devel::Trace + variants).
Not very convenient to use. It still requires you to put 'if $App::Trace' clause everytime. For general logging that can be switched on/off upon runtime, I'd recommend using Log::Any instead.
Lastly, this module is tied to App::Options and thus only really usable if you use both.
Very good work, but not clear documentation and a lot of things still not done properly.
$e->ping - give you error and your script died if node not running.
How in the case I can check node is running? It's funny.
Why I have no option check response for command for error without my script died?
The combination of auto-exports, black magic and clearly named functions like ZZZ , YYY and so on makes this the perfect package to encourage writing 90s style unintentionally obfuscated code.
So unless you fancy a trip down the memory lane, do not use this.
Also, try to avoid anything that uses it (yes, that includes Test::Base and YAML) as the first time you will probably hear from this module will be when it breaks your build.
I think XML::Simple is overrated, advertised too much. I started with XML::Simple and soon switced to XML::Smart. It is far easier to create XML files.
And a module maintainer, Madabushi-san, was very nice and quick to respond for my question regarding Moose and XML::Smart!!
This is a very good module. One thing that threw me a bit is that "shape records" and "parts" use 1-based indexes. I assume there is a good (historical, maybe?) reason for this, but you must beware of this. Another thing that might be helpful if you're looking to use this is that you can query the *.dbf files that come with shape dumps using the XBase module. These are just observations from first time use - I happily recommend this module.
I just learned this module is used by the trusty imgsize commandline utility. Good stuff.