Ideas that I’ve got floating around, but which I haven’t gotten to yet:
subs that need documenting.In chromatic’s session this morning, there was a comment that Perl::Critic didn’t support autodie. It actually has supported it since New Year’s day of this year.
Let me say emphatically that one of the core Perl::Critic developers (i.e. me) loves autodie. If he could, he would marry it.
If you aren’t using autodie, please do so.
Please use autodie. PLEASE use autodie. PLEASE “use autodie;”!!!
(Or, even better “use autodie qw< :all >;”.)
At YAPC::NA this morning, chromatic answered my question about Modern::Perl, “What happens when perl 5.12 comes out?”, with what I think is a good solution.
The proposed answer is for Modern::Perl to take a date parameter to indicate what “modern” means. This is brilliant because it explains to even the unknowledgeable programmer when the code was current. Say the syntax is like:
use Modern::Perl as_of => '2009-06-23';
What could be more clear?
Mr. Bunce is asking for examples of how NYTProf told you what to fix with poorly performing code.
Instead, I’m going to give an example of how NYTProf told me why I shouldn’t fix something a particular way.
I’ve got an app that needs to analyze a bunch of logs. Having used NYTProf in the past to identify that creation of DateTime objects is my biggest issue, I was thinking of ways to improve the situation. One thing I thought of is being able to create a DateTime based upon an epoch time instead of individual date components (year, month, etc.), with the idea that the cost of deriving the epoch time from the date components was what was expensive (I can affect the format of some of the logs, and thus could get the epoch time emitted). So, I quickly threw together a little Benchmark program that compared the costs of constructing DateTimes from each type of data. I was shocked to discover that creating objects based upon epoch times was over 20% more expensive than creating them out of date components.
What was going on? NYTProf provided me with the answer. I created two simple programs that created 100,000 DateTime objects, one for each kind of constructor arguments. I profiled both of them and compared the NYTProf output for them. This led me to looking at the from_epoch() code in the NYTProf generated HTML, and finding that DateTime passes the epoch time to gmtime to get the date components and then calls the regular constructor with those. The extra cost isn’t really in the gmtime calls, but a good part of it is in the use of Params::Validate in all of the public methods to check arguments and the epoch time path takes the code path through an additional public method.
Benchmark told me that I shouldn’t make a change and NYTProf allowed me to understand why that that result was correct and there wasn’t something wrong with my Benchmark use.
Modern::Perl has laudable goals. I agree with chromatic. This is why I use 5.10.0 at work. This is why I will be upgrading to 5.10.1 almost as soon as it is released. I even plan on testing our code with the 5.10.1 release candidates. The first significant line in all our modules is “use 5.010;“. (The second is “use utf8;“.) As I said in a prior post, I upgrade all the modules that we use from the CPAN every three months.
However, as a practical matter, Modern::Perl is broken. What happens when perl 5.12 comes out? Does chromatic upgrade the module to add “use feature qw/ :5.12 /;“? Are all of the modules that use Modern::Perl suddenly broken? Someone requested that TestingAndDebugging::RequireUseStrict include Modern::Perl in the default set of modules that are treated as equivalent to “use strict;“. (You can add to that list yourself via the “equivalent_modules” option.) I don’t want to do that; I want to discourage the use of Modern::Perl. Maybe if there was a Modern::Perl_5_10 I’d think differently.
I’m setting up a DarkPAN at work.
CPAN::Site does most of what I want with maintaining it. Unfortunately, it has some bugs with parsing module versions (in particular Test::Object, which is a blocker for PPI); in particular, it can’t distinguish between namespace declarations in actual code and in code examples in documentation. I thought that it could be worked around, but in reading source, it’s doing some pretty incredible stuff.
It’s reading perl code straight out of raw tar files. It ungzips the tarballs, but doesn’t untar them. It simply tries to find perl code in the middle of the tar stream and grab the versions out that. Yech.
So, looks like I’m going to be forced to go back to CPAN::Mini::Inject, taking advantage of parse_version() in ExtUtils::MakeMaker. I’m going to have to have a look at brian d foy’s MyCPAN::Indexer work.
Elliot Loves Perl 