Ideas that I’ve got floating around, but which I haven’t gotten to yet:
- Like Pod::Coverage, but rather than looking at the symbol table, uses PPI to discover
subs that need documenting.
- Like Pod::Coverage, but, in addition to regular subroutines requiring documentation, reports on Moose generated accessors, delegations, etc. that are undocumented.
- Combines the two others.
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?
I previously wrote about what I wanted out of the Parrot workshop. So, here’s what I actually got.
Forgetting all the type constraint, role, and attribute handling that Moose does, I like it simply for what it’s contributed to documentation.
I’ve been using the constraint syntax for describing complicated data structures in POD and comments in cases where Moose isn’t actually involved. It’s nice to be able to simply state that a subroutine returns “ArrayRef[HashRef[Maybe[Str|HashRef[Foo::Bar]]]”. That’s a lot more comprehensible than a paragraph of description.
I’m going to the Parrot virtual machine workshop next weekend. The suggestion has been made that “anyone who is coming from out of town to attend the Parrot talks is already involved with Parrot” and the schedule is too introductory. I beg to differ.
I am not presently involved with Parrot, nor do I expect to be in the future; I’m already behind on the projects that I’m involved with or want/need to start. At most, I expect that I’ll be filing bug reports.
I’m expecting that I’ll be using things running on Parrot. I want to understand what’s going on underneath in order to make my life in understanding higher level things easier. As a point of comparison, there are some edge cases in Java’s behavior that you cannot understand without knowing how the Java virtual machine works.
I want to know how to drop to a lower level, if the higher level code running on the VM isn’t working out for some reason.
When dealing with Perl 6 specifically, I want to know what I can get at the Parrot bytecode level and what I need to do with STD.pm. I’m probably going to be involved in a Perl 6 version of Perl Critic and I’d like to know what would be possible in terms of a generic higher-level-language-running-on-Parrot critic. (Yes, I don’t know how to use a programming language that’s still not finished being designed and I’m already planning on to tell you that you’re using it wrong.)
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.