Perl::Shell is limited compared to the other Perl REPLs, notably Devel::REPL. Some omitted features that stand out out are the lack of a plugin system and the lack of a feature for remembering lexicals between lines. It's nice to say:
>>> my $foo = 42;
>>> $foo / 6;
Devel::REPL does this out of the box, but it's not currently possible with Perl::Shell.
Anyway, I'm aware that the author wrote this because Devel::REPL's re.pl script causes problems on w32... but I think a patch to D::R would be a more acceptable response to that problem. Devel::REPL already has quite a few authors (notably mst and Sartak), so it's not like the project is avoiding external contribution. I think I even have some code in there :)
Anyway, by patching Devel::REPL, everyone could immediately benefit -- w32 users would instantly have all of Devel::REPL's neat plugins. Instead they are stuck with this half-assed attempt at a REPL for the foreseeable future. Better than nothing, but pretty anti-social.
This is a reply to BKB's post fon 2008-06-23 00:55:33.
BKB: There are plenty of things other than CGI.pm. CGI.pm is not for new apps, it's for keeping legacy apps working. New Perl web applications use frameworks like Catalyst, Jifty, Continuity, CGI::Application, Mason, etc. You should take a look at one of those (Catalyst is the most popular) instead.
I'm not sure why the reviews for this module are so negative. First of all, there is no requirement that you install, require, or use this module to have a machine-readable Changes file. You just write it, and this module processes it on the toolchain end.
The possibilities a machine-readable Changes file opens up are enormous. Have you ever installed YAML? You'll notice that it warns you that it is incompatible above 0.60 *every time you install it*. If the toolchain was aware of tags in the Changes file, then CPAN.pm could warn you, and you could set an "I don't care option". Or, you could set a "log whenever I upgrade something marked as incompatible". Then when your app breaks, you can review the log and see which module changed something. Or, you could simply refuse to install that module.
Finally, I had no trouble installing this module. "cpanp install Module::Changes" and there it was. I'm not sure what was wrong with the other reviewers' machines, but the problem is probably on their end.
Anyway, the other reviewers seem pretty clueless (about this module, and in general), so I would take their reviews with a very large grain of salt.
This is a nice way to merge hashes. It has a few advantages over Dan's Hash::Merge. Firstly, it wasn't written by him. Secondly, the code in question has proven itself in thousands of production Catalyst applications. Finally, sometimes ::Simple is the way to do things. I don't want to devote thought to merging hashes, I just want it to happen.
This module works exactly as advertised. I'm not sure why someone gave it one star.
Actually, I do know why. People seem to think "I don't understand this, so it must be bad" and then give the module a 1-star rating.
If someone like Ovid releases a testing module, you should probably think twice before giving it one star. Your dislike of the module is probably related to your own ignorance, not that of the author. (Basically, there are a lot people that I've never heard of telling the best Perl developers in the world that their modules suck. While this is true from time to time, you should probably be careful and give these folks the benefit of the doubt. If you're not sure, keep your thoughts to yourself.)
Before you upload another module to the CPAN, could you do one of the following two things:
1) learn Perl
2) learn English
Reading your Perl is pretty painful, but this module shows that your English skills could also use ... improvement. Rarely do I read something and simultaneously want to kill myself, kill the author, and throw up all over my desk. Seriously, documentation is not AIM. Please do not use the same writing style.
Finally, this module is redundant. Nothing::Tiny does exactly the same thing. If you think it could be more efficient, you should have sent a patch instead of uploading this monstrosity.
Edited to add:
This comment hurts the Perl community? Your modules are inflicting much more pain, my good friend. Take a step back and consider collaborating with someone sane on your next module. You need a bit of hand-holding before we can allow you to upload anything else.
I calculated that I spent more than 38 seconds a week typing the words "Object::Tiny". Now I've switched over to Moose::Tiny, and saved about 3 seconds a week! Over the course of my life, that will end up adding about 3 hours of not typing to my life. Yay.
Rating your own module 5 stars is in very poor taste. I'm giving this module 1 star until the author removes his own rating.
I'd say a 3 star rating would be accurate, based on the general lack of documentation for the internals; not everyone just wants to use the script from the command line. However, the application itself appears useful.
The new C::Auth architecture is excellent. It supports using multiple authenticators (password, openid, plus lots of others), and it supports getting user objects from various backends (DBIx::Class, LDAP, a hash, etc.) with a clean API for adding more.
The API is easy to use, the docs are great, everything works, and the code you write to use it is clean and easily extensible.
Pretty useful module. I often find myself writing can_ok and isa_ok tests for everything in my app. This module will automate that testing by accepting a quick textual description of what your app's API should look like and seeing if your classes live up to the spec.
XP advocates should like this, since it makes writing the basic use ok, isa_ok, and can_ok tests trivial. One more reason to use Perl instead of Java for agile/XP :)
This module is incredibly helpful. I've been tracking down a memory leak in Angerwhale for a while now, and wasn't satisfied with the existing tools (so I started writing my own). I saw this module on use perl, loaded it into my application like:
Turns out that scalar::defer::lazy was closing over my Catalyst model on each request and never freeing itself. So I was leaking basically my whole application on every request. Ouch. (In case you want to know how it ends, I rewrote the deferred evaluation bit with my own code, because Scalar::Defer was A Bit Too Magical For Me (tm)).
Anyway, this module gave me a good idea on what was leaking and how badly, and pointed me at the problem almost immediately. Highly recommended.
What is relevant is that the Build.PL is completely broken. It's a subclass of Module::Build, but totally breaks installing into a directory other than the default. That makes this module unusable on systems where you don't have root. Too bad.
Module::Build sucks. I wish people would get a clue and stop using it.
I'm not sure I like this module. The XML folks spent a lot of time worrying about things like character encodings (that's why <?xml has to be at the beginning of the file; the parser uses it to determine enough charset information to be able to parse the charset= part), escaping, etc. It is really useful to parse an RSS feed when all the entries containing '&' are going to read '&' instead? Is ignoring CDATA really going to work on any real RSS feeds?
This is not XML -- it's tag soup.
[Edit: increasing rating; the module does what it claims to]
Great module. I've been wanting to add syntax highlighting support to my blog software, but didn't want to require the end user to have vim installed. This module works much better (and faster) than Text::VimColor, and supports many more languages. The only disadvantage is that there's no reasonable default color scheme, you have to build it all yourself. Small price to pay for a great highlighting engine, though. Highly recommended.
I would consider this module harmful. I looked at the code expecting that these functions all called the appropriate modules for the task. Unfortunately, everything is written from scratch and contains the usual "I haven't thought about this for more than 5 minutes" varieties of bugs. The CSV parser is just wrong, for example.
I'm sorry that the author had to waste his time writing all of these functions. All of them are available in modules like DateTime, Text::CSV, etc. The difference is that those modules handle (and have tests) for the various corner-cases you're likely to encounter once in a while. Reinventing the wheel sucks -- what looks simple never is.
This is a great program. I haven't tried using it as a module, but that's because the included svnnotify program does everything I need. The best feature is that you can easily send mulitpart messages -- so developers using mutt to read their e-mail get legible text, and the managers using Thunderbird or Outlook get beautifully-formatted HTML mail.
Plagger is a great package for doing anything related to RSS (feed) processing. If you need to create a "planet" site, like planet.catalystframework.org/, you can do it in 10 lines of YAML. If you want to have plagger e-mail you whenever the weather forecast says it's going to rain, you can do that too. If you want to merge your 10 favorite non-fulltext, ad-encrusted, tracking-image-encumbered feeds into one ad-free fulltext Atom feed, Plagger makes it simple.
To get started, it's best to look at the examples:
Exactly what I've been looking for. XML::Feed::Atom doesn't support everything I want to do (and the output doesn't validate), but this module works great. It lets you use all standard output tags, and doesn't try to be smart about munging your input.
5 stars, becuase it does exactly what it should; no more, no less.
The documentation and code aren't consistent. In the Gnuplot module, the documentation states that you can specify (for example) "extra_opts" as extra options. If you actually use this, though, the module prints an error message and ignores the options.
I worked around this by specifying:
"y-axis label" => 'y-axis"\n<code to run>\n<code to run>\n#"'
This works fine but is a dirty hack. I hope the author fixes this.