Acme-CPANModules-Import-CPANRatings-User-stevenharyanto
view release on metacpan or search on metacpan
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. <br><br>
Devel::TraceCalls
Author: COSIMO <https://metacpan.org/author/COSIMO>
Might be powerful and flexible, but not convenient to use especially
from command-line. (I was searching for something like "strace
for Perl function"). <br>
Debug::LTrace
Author: KOORCHIK <https://metacpan.org/author/KOORCHIK>
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. <br>
Debug::Trace
Author: JV <https://metacpan.org/author/JV>
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. <br><br>
App::Trace
Author: SPADKINS <https://metacpan.org/author/SPADKINS>
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). <br><br>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. <br><br>Lastly, this module is
tied to App::Options and thus only really usable if you use both.
Tie::Hash::Identity
Author: CINDY <https://metacpan.org/author/CINDY>
Hash::Identity has a use case of convenience when embedding
expression in double-quote strings. I fail to see the point of
Tie::Hash::Identity though. Can't you just say: <br><br>'abc' eq
'abc'; # true <br><br>(1+2+3) eq '6'; # true <br>
Hash::Identity
Author: CINDY <https://metacpan.org/author/CINDY>
At first I thought, hey, cute trick. But then Perl already has:
<br><br>print "You could use expr like this:
${(2**3)}.\n"; <br><br>print "Or you could use ident ${(
'a' . 'b' )} as well.\n"; <br><br>So you're trading a backslash
and a couple of parentheses against having to depend on a non-core
module and making your code reader raise her eyebrow when she first
sees your code. Pick your poison :-) <br><br>I wonder if this
belongs in Acme:: <br><br>On the other hand and slightly off-topic,
a module that can do Perl6-style interpolation (lexically) would be
cool, I think: <br><br>$s = "perl${(6-1)}-style
interpolation"; <br> { <br><br>use v6str; <br><br>$s =
"perl{ 5+1 }-style interpolation"; <br> } <br>
Data::Structure::Util
Author: ANDYA <https://metacpan.org/author/ANDYA>
@Tom Browder: If you just need unblessing, there's also another
module Acme::Damn which is more minimalist. You can also create a
shallow copy to unbless a reference, if you want to do it without
the help of any module (Both Acme::Damn and Data::Structure::Util
are XS modules, JFYI). <br><br>Re Data::Structure::Util: nifty
module that provides speedy alternative for several things like
checking for circular references, weaken them, unblessing a
reference, etc. You can do many of the routines in pure Perl. This
module lets you do them in C. <br>
Fsdb
Author: JOHNH <https://metacpan.org/author/JOHNH>
An interesting tool that has been developed since 1991 (which is
roughly around the time the WWW and Linux was born, whew). Kudos to
the author for the dedication and consistency. <br><br>Since
nowadays SQL is pretty much ubiquitous, users might also want to
check out an alternative tool, App::fsql. For example (taking a
similar example from the module's doc), to select entries in
/etc/passwd where UID is between 1000 and 2000: <br><br>$ ( echo -e
"login\tpassword\tuid\tgid\tgecos\thome\tshell"; sed
's/:/\t/g' /etc/passwd ) | fsql --add-tsv - 'SELECT * FROM stdin
WHERE uid >= 1000 AND uid <= 2000' --format text --aoh
Date::Tie
Author: FGLOCK <https://metacpan.org/author/FGLOCK>
Cool, but personally I'd rather have something like JavaScript's
properties (since Perl does have lvalue subroutine support):
<br><br>$date->year = 2014; <br>
File::Slurp::Tiny
Author: LEONT <https://metacpan.org/author/LEONT>
More effort needs to be made with regards to documentation,
especially for File::Slurp users looking for alternatives. Why is
this module needed? What are the differences with File::Slurp? How
do the functions behave on I/O errors (since err_mode option is not
supported)? <br>
Clone::PP
Author: NEILB <https://metacpan.org/author/NEILB>
Thanks for providing a pure-Perl alternative for deep cloning.
Otherwise we are stuck with core module Storable's dclone, which
cannot handle Regexp objects out of the box, must use deparse to
handle coderefs, and not to mention is not as fast as it should be
because it's a marshall+unmarshall algrorithm (ab)used for deep
cloning. <br><br>Of course, there are faster XS-based cloning
modules on CPAN (all currently non-core, believe it or not there are
no core modules for cloning except Storable). I'd recommend
Data::Clone. But it's nice to have a pure-Perl implementation, e.g.
for creating a dependency-free script using App::FatPacker.
IPC::System::Simple
Author: JKEENAN <https://metacpan.org/author/JKEENAN>
over 100MB of packages on my Debian. <br>
Rating: 8/10
Syntax::Highlight::Engine::Kate
Author: MANWAR <https://metacpan.org/author/MANWAR>
Highlighter engine doesn't seem updated (for example, defined-or is
not yet interpreted correctly by this module but already correctly
by Kate itself). Does not provide default theme (must specify all
colors). Seem to be very slow (takes 1.5s for a 18K Perl .pm file
while Pygments only takes 0.2s). <br><br>
Rating: 2/10
Syntax::Highlight::JSON
Author: MART <https://metacpan.org/author/MART>
No documentation. Combines formatting and syntax-highlighting, so
you cannot preserve original formatting. Only outputs to HTML and no
default "theme" (CSS) provided. <br>
Rating: 2/10
Syntax::Highlight::Engine::Simple
Author: AKHUETTEL <https://metacpan.org/author/AKHUETTEL>
Output looks decent. However, it currently only formats to HTML/CSS
(no ANSI, LaTeX, etc). Also, it needs more languages support. <br>
Rating: 6/10
Syntax::Highlight::Universal
Author: PALANT <https://metacpan.org/author/PALANT>
Only targets (X)HTML (i.e. no alternative output like ANSI or
LaTeX). Supposedly slow. But it doesn't matter because code no
longer builds (last updated in 2005).
Rating: 2/10
text::highlight
Outdated (no longer updated), poor capability (even for some simple
Perl code, the output is atrocious), few languages supported. A far
cry from Pygments or coderay.
Rating: 2/10
SemVer
Author: DWHEELER <https://metacpan.org/author/DWHEELER>
Good for semantic versioning scheme like 1.2.3 vs 1.2.3alpha vs
1.2.3rc (1.2.3 should be the latest, not the alpha or rc). However,
does not accept e.g. 1.0beta (at least three components are needed).
Perhaps relax this requirement? <br><br>Also take a look at
Debian::Dpkg::Version. <br>
Sort::Versions
Author: NEILB <https://metacpan.org/author/NEILB>
Good for Perl-style versioning scheme (1.2.3) but does not work as
people expect for semantic versioning scheme like 1.2.3 vs
1.2.3alpha vs 1.2.3rc (1.2.3 should be the latest, not the alpha or
rc). For handling the latter case, use SemVer. Also take a look at
Debian::Dpkg::Version.
App::Countdown
Author: SHLOMIF <https://metacpan.org/author/SHLOMIF>
Nice idea, though I'd probably just write a shell function for this.
<br>
Rating: 8/10
Data::Compare
Author: DCANTRELL <https://metacpan.org/author/DCANTRELL>
Pros: handle hashes as well as arrays, handle nested and cyclic
structure, plugins. <br><br>Cons: No cmp-like functionality
(returning -1, 0, 1), slow (even slower than Array::Compare).
<br><br>See also: Array::Compare, JSON/YAML/Storable. <br>
Rating: 6/10
Array::Compare
Author: DAVECROSS <https://metacpan.org/author/DAVECROSS>
Pros: has a perm() function to check whether the two arrays contain
the same things but in different order (although you can simply just
run sort() over the arrays first). Allow skipping some elements from
comparison. <br><br>Cons: no cmp-like functionality (returning -1,
0, 1), slow (for equality test, you might as well compare the
json_encode() result of the arrays, which is way faster), no nested
comparison. No procedural interface. <br><br>See also:
Data::Compare, JSON/YAML/Storable.
Rating: 4/10
Mozilla::Mechanize
Author: SLANNING <https://metacpan.org/author/SLANNING>
No longer builds (tested on a current Debian). A pity, since drop-in
replacements for WWW::Mechanize (using different backend like curl,
IE, Mozilla, Chrome, etc) might be handy. <br><br>
LWP::Curl
Author: LORN <https://metacpan.org/author/LORN>
Those looking for LWP drop-in replacement might want to take a look
at the recently released LWP::Protocol::Net::Curl instead, which
supports WWW::Mechanize. <br><br>
LWP::Protocol::Net::Curl
Author: SYP <https://metacpan.org/author/SYP>
Shows great promise. I personally need this for HTTPS proxy support.
After testing, the module still doesn't work to login to my internet
banking sites. But I'll still check in from time to time. <br>
Devel::SizeMe
Author: TIMB <https://metacpan.org/author/TIMB>
dependency on Class::MethodMaker not yet specified <br><br>*
Documentation: Synopsis contains mistake (class name is
DateTime::BusinessHours not BusinessHours), the name '$testing' is
not very suitable, there are typos. <br><br>* Style-wise, method
naming is "joinedwords", while in DateTime families it's
"separated_words" (not a big deal though). <br><br>
Rating: 6/10
Bundle::Dpchrist
Every once in a while everyone of us encounters a programmer that
disregards existing reusable code and creates his/her own
"standard library" for everything, from trimming string to
creating random number to cleaning the kitchen sink. We all might
have been one too, at one time or another. I'm not saying that this
bundle is a case of the above, but it's giving me a similar feeling.
:-) <br><br>A commendable effort, David. But there really are a lot
of wheels being reinvented here.
Net::BitTorrent::File
Author: ORCLEV <https://metacpan.org/author/ORCLEV>
I mass download stuffs by putting a bunch of torrent files in a
directory on the server and let rtorrent takes care of them. With
this module I can quickly whip up a short script to calculate the
total size of the downloadable files so I can be pretty sure that
when I leave my server for days/weeks, I don't run out of disk space
because I put in too many torrent files. <br>
Module::CoreList
Author: BINGOS <https://metacpan.org/author/BINGOS>
Wow, I was thinking the same exact "godsend" too and turns
out some other reviewer already said so. Very very helpful to assist
deployment and pick modules to use. I personally made a couple of
command-line scripts like pm-in-core or core-since-when to save some
typing. <br>
WWW::Mechanize
Author: SIMBABQUE <https://metacpan.org/author/SIMBABQUE>
WWW::Mechanize is of course one of the indispensable tools for any
web programmer or admin. The current problem is the proliferation of
3rd party subclasses, the functionalities of which cannot be used
together. So you want a polite Mechanize which does
self-rate-limiting and uses the Firefox or IE engine? A subclass
exists for each feature, but how do you use them together?
WWW::Mechanize needs to be more role/plugin-oriented instead of
inheritance-oriented. <br>
Mail::Sendmail
Author: NEILB <https://metacpan.org/author/NEILB>
I used Mail::Sendmail and a few others "older" modules
back from the days when it didn't support setting envelope sender
different from RFC From, and when the test hung on some dead host.
<br><br>If it's still working for you, great. I personally have
moved on to other modules like Email::Sender::Simple, which
abstracts sending mechanism (transport) and support SMTP auth, for
two. Also, many of the guide/documentation for Mail::Sendmail are
not quite up to date in style (though they still might work), for
example the low level way of building HTML email. Also, the
Changelog file doesn't seem to be maintained?
Rating: 6/10
autodie
Author: TODDR <https://metacpan.org/author/TODDR>
I started using autodie in almost all of my applications a few
months ago. It's somewhat of a mixed blessing. For existing
applications, it can break things and making things less robust,
solely because old code are not built with autodie in mind.
<br><br>But the best thing about it is that it's lexically scoped,
so for sections of code that you're not sure about, just sprinkle
'no autodie' to get the old behaviour. <br><br>It should be used on
probably 95% of code out there. For the rest of the cases, where you
need to report the status of each I/O operation, it's obviously more
convenient to check $? instead of trapping exception everytime.
<br><br>+1 for getting it into core. <br>
App::FileTools::BulkRename
Disclaimer: I maintain a "competitor" module, App::perlmv.
Apparently a lot of people, like me, likes to rename files using
Perl. And the examples in the documentation are about renaming movie
files too, something which I do a lot :) <br><br>I applaud Stirling
Westrup for taking a legacy script and improving it. May we have a
lot of ideas to borrow from each other. <br><br>This is an early
release, there are quite a few things I find lacking. Most
importantly, I suggest adding a test suite as soon as possible. The
filesystem differences can be tricky, and CPAN Testers can help
providing feedback. <br><br>Keep up the good work.
Rating: 8/10
Script::State
Author: MOTEMEN <https://metacpan.org/author/MOTEMEN>
Nice idea, straight and simple interface. A better name could
perhaps be chosen? Documentation should be expanded, e.g. to warn
users about security, since Data::Dumper a.k.a. eval() is used to
load variable content. Also, the implementation does not yet
consider file locking.
PathTools
I guess File::Spec's API is sane enough, but I suspect not a lot of
people are using it because there's not enough incentive for it.
When 99% population of the world use Unix/Linux/Windows (even Macs
been technically Unix for a number of years), "/" works
everywhere and using File::Spec does not gain you anything except
lots of typing exercise. <br><br>That's why I think Path::Class
might have a better chance of succeeding. It gives niceties like a
few more convenience methods, a shortcut of getting dir & file
object from each other, etc. It gives users more incentive of using
a proper path manipulation library because it gives extra stuff
along with that. It should also be in core to accompany File::Spec.
Rating: 8/10
File::Slurp
Author: CAPOEIRAB <https://metacpan.org/author/CAPOEIRAB>
Log::Fast
Author: POWERMAN <https://metacpan.org/author/POWERMAN>
This logging framework is also minimalistic: no
categories/hierarchiecal loggers, no custom levels, no config file,
or other whistles and bells. And the interface & default levels
are rather syslog-oriented. But it's fast alright. The POD doesn't
mention a comparison to Log::Log4perl, but a casual benchmark shows
that it's at least 10x faster. <br><br>So this module will certainly
come handy if you have a performance critical application.
<br><br>Btw, note that the benchmarks are done for actual logging to
output. For log statements that do not actually get logged (e.g.
because the level is below the desired output level), I don't find
that extreme differences in overhead between logging frameworks. For
example, on my Athlon64 X2 5600+ PC, Log::Fast's overhead is roughly
around 3mils/sec, while Log::Log4perl is around 1,5mils/sec.
Log::Minimal
Author: KAZEBURO <https://metacpan.org/author/KAZEBURO>
Log::Minimal's slogan is "minimal but customizable". It's
minimal alright, probably only suitable for simple scripts as the
moment you organize your application/library into separate modules,
you'll want/need categories instead of just level, which is not
provided by Log::Minimal. <br><br>Also, only formats is
customizable, there is currently no way to customize level. And the
levels are "not standard" (not that there is an official
authoritative standard, but the popular convention is
TRACE/DEBUG/INFO/WARN/ERROR/FATAL and NONE). Log::Minimal's levels
are <br> DEBUG/INFO/WARN/CRITICAL and NONE). Surely most people
would expect another level between WARN and CRITICAL, for
non-critical errors? But that is actually just a matter of taste.
<br>
Rating: 4/10
Log::Fine
Author: CFUHRMAN <https://metacpan.org/author/CFUHRMAN>
Log::Fine is touted as a framework for those who "need a
fine-grained logging mechanism in their program(s)". But apart
from the emphasis on custom levels, to me there is nothing extra
fine-grained about it. The other thing it provides is
categories/namespace, which is also supported by a lot of other
frameworks. So I fail to see the benefit/uniqueness of Log::Fine.
<br><br>Btw regarding custom levels, this practice is long
deprecated by log4j (and thus also by Log4perl, although Log4perl
can do custom levels). I can understand this decision as I sometimes
already have trouble managing the popular convention of 6 levels
(FATAL/ERROR/WARN/INFO/DEBUG/TRACE) as it is, much less with custom
levels!
Rating: 6/10
Config::IniFiles
Author: SHLOMIF <https://metacpan.org/author/SHLOMIF>
This module has been developed for more than a decade and seen
different maintainers over the years. The codebase is indeed showing
these, with different capitalization and indentation styles, among
other things. <br><br>However, among more than a dozen or so of INI
modules in CPAN, ironically there seems to be few other choices if
you go beyond the most basic feature set. Some INI modules can only
simplistically rewrite/dump the whole INI structure and thus lose
comments/orders, while others can't even write INI files.
<br><br>Config::IniFiles by far offers the most options and
features, like dealing with line continuation, case sensitivity,
default section, multiline/array, deltas, etc. So for now, despite
all of its quirks, this module is still hard to beat.
<br><br>There's another nice little INI module that can do
read/set/delete/unset (instead of just read/dump): Prima::IniFile,
but it is included in a totally unrelated distribution.
Rating: 8/10
DateTime
Author: DROLSKY <https://metacpan.org/author/DROLSKY>
Amidst all the glowing reviews may I add a reminder that, as with
everything, there's a catch: runtime performance. On my PC, the
speed of creating a DateTime object is just around 6000/sec. If you
use DateTime intensively, it can quickly add up. <br><br>Imagine
serving a web page that fetches 50 rows from database, where for
convenience you convert each date column to a DateTime object, and
you have 120 requests/sec coming in... That's already 6000 objects
(an extra second!). <br><br>Which is unfortunate because DateTime is
so wonderful, convenient, correct, complete and all that. So one
approach you can use might be to delay converting to DateTime object
until necessary.
Date::Manip
Author: SBECK <https://metacpan.org/author/SBECK>
Wow, there are surely a lot of negative reviews ... <br><br>First of
all, Date::Manip has a long history. I used this module back in
2001-2002, IIRC. Back then it was *the* swiss army of date/time
manipulation, something you use when you want the most
flexible/complete thing in Perl. True, it's slow, but it works.
<br><br>But then things change. DateTime project was started, and
now it is somewhat the de facto standard. It's more modern and far
more modular than the monolithic Date::Manip (every timezone and
language support and parsing/formatting modules shipped in one
single distribution). <br><br>And then there's the 5.x -> 6.x
debacle. As someone who also sprinkle Perl 5.10 requirements to his
CPAN modules, I can feel for the author. But the difference is, most
of my modules are not that widely used/known, and also many start
its life already requiring 5.10 right from its first released
version. While in Date::Manip's case, this happens to a very widely
used module. Surely backwards compatibility should be considered
more. <br><br>All in all, you are free to use or not use
Date::Manip. There are other alternatives. Pick wisely. <br>
Rating: 6/10
App::pmuninstall
Author: XAICRON <https://metacpan.org/author/XAICRON>
One would wonder why CPAN clients still don't have this crucial
feature Though you see Miyagawa listed in the Credits so maybe
cpanminus or its sister will end up having this functionality? One
( run in 2.152 seconds using v1.01-cache-2.11-cpan-0fb53d1c279 )