Ratings and Reviews for CPAN
Find a distribution you would like to review:
Extensively well documented, and I'm sure it works great, but it's an incredibly overcomplicated and magical solution that still relies on the awkward implementation of FindBin, so I cannot recommend this approach. In my opinion you should always declare exactly what directories you wish to include rather than leaving it up to magic libraries - this is how you get vulnerabilities. See lib::relative for a straightforward method that relies only on the location of the file it's used in, and use Carton for installing project-local modules.
I should have been writing this rating for a long time.
This is unique tool that converts description of layout into GDS format and it makes my project moving forward successfully.
This tool can work with very large amount of datas.
Ken is very nice person and gave me much help in bring up it successfully. With his help and clear document, even an hardward engineer who had little software experience can make it valid.
There are two points that I want to mention here that may help newcomers.
First, the data description MUST be orthogonal.
Second,AREF usage is a bit of complicate. I put an example here .
$gds2File -> printAref(
-name=>string, ## Name of structure
-columns=>#, ## Default is 1
-rows=>#, ## Default is 1
-xy=>\@array, ## ref to array of reals
-xyInt=>\@array, ## ref to array of internal ints (optional -wks better if you are modifying an existing GDS2 file)
-angle=>#.#, ## (optional) Default is 0.0
-mag=>#.#, ## (optional) Default is 1.0
-reflect=>0|1 ## (optional)
best not to specify angle or mag if not needed
xyList: 1st coord: origin, 2nd coord: X of col * xSpacing + origin, 3rd coord: Y of row * ySpacing + origin
Thanks Ken for this very good job!!!
Our test framework was written in Perl but then we needed to run Python code from Perl. So you know, Inline::Python helped us a lot. And again, it turns out to be true that Perl can do anything.
It's rather annoying that the author makes all of his modules depend on this. Every other module by MSCHILLI depends on Log::Log4perl, even though the module may not be actually used to any real extent. It also increases the likelihood of some problem occurring in other CPAN modules which depend on that. It's for these reasons that I avoid using MSCHILLI's modules as much as possible.
MCE is brilliant. It makes it easy to speed up a wide variety of applications just by wrapping them in a simple of lines of code. The interfaces are sometimes a little non-obvious, but it's infinitely simpler to use MCE than handling parallel processing by hand. Now that I know about it, I find myself using MCE in all sorts of applications.
It seems to be a lot faster than Image::Size:
Rate is ijs
is 615/s -- -98%
ijs 30236/s 4816% --
(Here "is" is Image::Size and "ijs" is Image::JPEG::Size)
See gist.github.com/benkasminbullock/cf25... for the source code.
Simple API works great for Geo::Google::StaticMaps::V2::Path
I am a fan of this module. It has worked with no issues at all. performance is great. even runs multi instances of browers smoothly. Documentation is great.
Use it all the time, but unfortunately it's poorly maintained and in pull-request-only mode. So reporting bugs or requesting features is useless unless the user provides a patch.
Currently the best game in town it appears for parsing xlsx files using perl. However it's slow and a huge memory pig when the file size starts getting big. Also, the API is quite complex I think compared to the python "openpyxl" module. Maybe someone can write an "openplxl" version of that module someday...
I first started learning OO programming in perl around a year ago. I read up on the Moo vs Moose issue and decided Moo was the way to go. My first attempt resulted in a very cryptic error message coming from Moo which was impossible to decipher. So I changed to "use Moose" instead, and got a nice human readable error message telling me what I did wrong. So my recommendation is to get your code up and running with Moose first, and then switch to Moo if desired.
Uses simple regex instead of properly parses Perl source code (PPI, Compiler::Lexer) so potentially lots of false positives. Better use existing solutions like Perl::PrereqScanner or Perl::PrereqScanner::Lite, which already come with their own CLI's.
What does this offer over the established module WWW::Mechanize::SpamCop?
Also, shouldn't this module be called App::SpamcupNG?
Currently the only "real" module to create FTP servers in Perl. My suggestion would be to separate the Perl API documentation vs using the ftpd*.pl script, as the Net::FTPServer documentation currently mixes the two.
Eveybody who gives comment for this module has already told everything about the module. What I can only say that if you are not able to do something about XML, just try XML::LibXML before you give up, you will see that what you try to do is not imposible. Thanks for this great module and thanks for everybody in CPAN for their effort to keep Perl still one of the most usable and promising language...