Ratings and Reviews for CPAN
Find a distribution you would like to review:
Requires perl 5.20 for no particular reason. Claims to be replacement of smart match but only covers string comparison. Just use List::Util's first() which is more flexible and part of the core Perl distribution, or match::smart which covers more cases.
Mostly unnecessary because this is just a glorified form of a widely known Perl idiom. Requires perl 5.20 for no particular reason. Re-sorts the list which is 99% not what user wants. Just use List::Util's uniq() which is faster and part of core distribution.
Well written module, does exactly what I need it to do. Documentation is clear, and provides a link to the JSONPath specification. Author is receptive and responsive to issues, and has been able to turn around the few problems I've encountered very quickly. I appreciate the time and energy you've put into maintaining this.
Update 2017: Due to library issues in CentOS 6 I am no longer using Data::GUID but writing against the supported rpm packaged version of Data::UUID in uuid-perl-1.6.1-10.el6.x86_64
It uses a very fast algorithm to match an array of possible prefixes to an array of strings.
On the other hand, having examined the source code, it is very messy with lots of dangling unused items like the completely unused structure txs_vtbl or the unevaluated "len" in loops like "for (len;", there is a C function without a declared return value, there are misused Perl internal functions like misuse of "die" or "Newxz", and there are many failed tests due to simple causes like not including necessary files such as
The documentation is very patchy, so I would probably rather not use this, regardless of whether it is very fast or not.
By far the easiest-to-use progress bar module. Does the right thing by default, and can be added to any script in just 3 lines of code.
Works great until some (even external) common dependency starts to output warnings, then all the tests starts to "fail". That's the point it gets really annoying instead of helpful. Warnings are there to warn that there *may* be something wrong and should not be test fails.
Has some problems, e.g. it uses InstallTool phase so it conflicts with DZP:StaticInstall when wanting to produce a static install distro. Use alternatives like the simpler DZP:Pod2Readme or the more complex DZP:ReadmeAnyFromPod.
Great for debugging. Just whip up some code in dist.ini to e.g. dump & print some stuffs, etc.
This might have been the bee's knees at one point but it's not been updated since 2001 and it has a tendency to break on modern versions of Perl. I suggest trying out Test::More rather than this.
This seems to work well. Users should note that the "is_uri" function given in the synopsis is probably not really what you want, use the "is_web_uri" function instead.
The failed tests at CPAN testers are due to the use of a very old module from 2001 called ExtUtils::TBone to do the testing. If the author has time it would be great if this could be upgraded to use Test::More.
In my tests, this is about the same speed as using a regular expression generated by list2re from Data::Munge or make_regex from my own module Convert::Moji, sometimes faster and sometimes slower. Here are a few typical results:
Data::Munge::list2re time: 0.188953876495361 #matches: 3365
Algorithm::AhoCorasick::XS time: 0.0855789184570312 #matches: 3365
Search::WuManber time: 0.353510141372681 #matches: 3365
Data::Munge::list2re time: 0.191490888595581 #matches: 3734
Algorithm::AhoCorasick::XS time: 0.0873630046844482 #matches: 3751
Search::WuManber time: 0.339526176452637 #matches: 3751
Data::Munge::list2re time: 2.37025308609009 #matches: 303173
Algorithm::AhoCorasick::XS time: 0.353744029998779 #matches: 308464
Search::WuManber time: 1.25165987014771 #matches: 308464
The script is available here:
The output search results are the same as those of Algorithm::AhoCorasick::XS, but that module is much faster than this one.
So far I've reported four bugs in the module and got no response so it may not be being maintained any more.
Given that it doesn't beat regexes, it has memory-related bugs, and has not been updated for years, I can't endorse this module.
It claims to be "Fast search for very large numbers of keys in a body of text", but this module is about three times slower than just using a regular expression like the one formed by list2re in Data::Munge, and it does not tell the position of the words in the string or the number of times they were found.
The interface is baffling. You put in a hash with keys and then it sends you back a hash with the same keys, except the keys of the return value are only for the words which matched. Why not just use a list, or return something useful like the position of the text in the string?
It also, for some reason, duplicates Perl's hash function within itself, complete with a keys and a values method.
Although it was last updated in 2010, the module claims that at one point a lot of people were using it. Maybe Perl regular expressions were slower in 2001 or whenever this module's heyday was, but in 2017 this module may no longer be relevant or useful.
In my tests, this module ran about three or more times faster than a regular expression formed using list2re from Data::Munge, and it gets the same results as Algorithm::AhoCorasick, so I would say this is a useful contribution, but the namespacing seems rather odd. It may be early days for this module, but I don't understand why this is called Algorithm::AhoCorasick::XS since it does not make any effort to implement a similar interface to Algorithm::AhoCorasick. This does basically the same thing as Text-Match-FastAlternatives except that, unlike that module, it covers the fairly obvious usage cases of telling the user the actual results obtained.
One other point to make: at the moment this seems to fail a lot of testing on CPAN testers but it installed correctly on my setup.
This module tells me whether a line matches a list of words, but not what specific word it matches. From inspecting the source code, a huge amount of work seems to have gone into making the module, yet it's missing the two most obvious usage cases. First it has no way of telling me what word actually matched, out of the input list of words, and secondly it does not have the ability to scan text to find the words in multiple places.
The only possible time this module is at all useful is for scanning for a list of words when we don't care which of the words matched, like the "obscenity detector" given in the synopsis. Other than that, I can't see what this is for, so I cannot endorse it.
Compared to "list2re" from Data::Munge or my own "make_regex" from Convert::Moji, this module is quite slow. This example code compares a search of 1000 random dictionary words over the complete works of Shakespeare:
Here are two typical output runs:
Data::Munge::list2re time: 0.198212146759033 #matches: 3844
Algorithm::AhoCorasick time: 29.4100480079651 #matches: 3866
Data::Munge::list2re time: 0.205715894699097 #matches: 4799
Algorithm::AhoCorasick time: 29.3638379573822 #matches: 4800
Algorithm::AhoCorasick finds a few extra substring matches, so if you absolutely do need to find every single match possible, you might want to use Algorithm::AhoCorasick, but for almost every normal use case, something like Data::Munge::list2re will do the same job in about 1/100 of the total time.
You might also want to note that the time using list2re gets much faster the second time around.
Nice idea, however it would be more useful if detect were to take two strings (let it to the tokenizing itself)
and if 'my $templates = $tt2->Convert($parts);' were to return
'I am [% value1 %] and [% value2 %]'
['I am [% value %] and ', ' and [% value %]']
This can be accomplished in a one-liner. It simply takes a list and converts it into a hash. The author is a bit disingenuous claiming it "converts the given list to internal structure to find the element fast" without mentioning this.
Excellent! Does what it claims! Trying to use Inotify2 or similar for recursive directories is sort of involved, this module solves that problem.
I've been using AnyEvent for about seven years now, and I am very glad that I toughed out the relatively steep learning curve and got my head wrapped around it. Though I can't honestly put a five in any of the given categories, I have to give it a five overall because it brings so much power and performance to bear.
great application. Very useful for any network and discovering devices! Will definitely recommend.
Does what it says on the tin simply and well, with the added bonus of a helpful and responsive developer.