Posts
I've been following (and even contributing to) the Padre IDE project from very early on. I've watched it grow from very modest beginings into something quite impressive -- usable, even.
Its deep integration with Perl is such a killer feature. There are already a good two-dozen plugins, one of which I've been shepherding: Padre-Plugin-PerlTidy.
In light of Padre's first birthday, I decided I wanted to give something back into the Padre core rather than just an ancillary project.
I tend to use gedit on Ubuntu, and I rather liked the "right margin" option. This option puts a gray vertical line on whichever column you specify. It's an easy visual queue for long lines. It turns out that the Scintilla editor component supports this feature and all I had to do was enable the menus and dialogs to allow users to toggle the method.
...and there you have it. It didn't take very long, and it's not exactly mind blowing, but it's something I've found useful.
Dear Module Author,
When preparing to upload a new release of your module to PAUSE could you please review your Changes file?
Did you remember to update it? Does it contain something meaningful? Here are a couple of examples of Changes entries which mean very little to me at a glance:
- Bug Fixed
- Foo::Bar Fixed
- Fixed RT #12345
Yes, this is old news. This is just a reminder.
This is just a quick note to let y'all know that I now have a twitter account and an identi.ca account.
You have been warned.
As noted in my last post, I was able to get a bit of a speed boost based on observations made as a result of code profiling.
In general, if I want to see if one piece of code is faster than another, I use Benchmark. Benchmark is shipped as part of the core set of modules, so there's no need to load up CPAN to get started. Its simplest usage, and the one i prefer looks something like this:
use Benchmark ();
Benchmark::cmpthese( $count, {
Foo1 => sub {
# code to do Foo1 here
},
Foo2 => sub {
# code to do Foo1 here
},
} );
Of note is that $count can be negative, which will then signify how many seconds to run instead of the number of times. The result looks like this:
Rate Foo1 Foo2
Foo1 108665/s -- -38%
Foo2 175460/s 61% --
It's pretty easy to see that Foo2 was faster. Using the above it was easy for me to test the XS-based ANSI parser vs the pure Perl version.
4k worth of ANSI over 10 seconds yields the following:
Rate PP XS
PP 15.7/s -- -96%
XS 379/s 2316% --
For giggles, i tested it against a 33k ANSI, giving:
Rate PP XS
PP 2.23/s -- -96%
XS 58.7/s 2528% --
Looks like a success to me!
Another week another QA tool.
This week I'm going to talk about Devel::NYTProf (aka NYTProf).
To start, if you're interested in profilers, you should check out the brief history section of the pod, then take a glance at its features. Until recently, I hadn't been very interested in profiling my code. I didn't really have anything that needed the profiling, and the tools just seemed a bit awkward to me. This changed for me when I saw the output from nytprofhtml (1, 2).
While working on Image-TextMode, I noticed that parsing large (~75k) ANSI files was getting to be pretty slow. I decided to run NYTProf on the parsing code, and here's what I got:
The putpixel(), width() and height() methods are called for every character/attribute combo stored for the image. This turns out to be a really big inefficiency. I've had some XS code in my back pocket for ANSI parsing, so I decided to whip up a replacement parser using that code and run the profiler again.
Huge win! By moving _read() to XS (including putpixel, width, and height) I was able to shave over a second off of the total time (_read inclusive goes from 1.3 seconds to 0.03). Although working with XS was a bit of a pain, it was really great to see such a speed improvement.
I recommend everyone take a look at NYTProf if you're looking find speed inefficients in your code.
Holy -- this weekly thing goes by way too fast!
Anyway, as promised, I'm making my first QA tool post. This week, we're chatting about Perl::Critic.
Perl::Critic has been around since late 2005. I was able to resist its icy gaze until last fall. So, why wouldn't I want to jump right in with Perl::Critic early on? Mostly what I imagined was putting a significant amount of time in to bend Perl::Critic policies to my will so I wouldn't have to change how I code. This is, of course, the wrong way to look at it.
There's nothing wrong with having a tool that confirms you're doing the right thing -- but what I really wanted was a tool that showed me the bad habits I've learned and gave me a slap on the wrist every time I tried to use them. The easiest way to get started was to copy someone else's polcy file. RJBS was nice enough to comply.
For the Image::TextMode project, after adding my own tweaks to the policies, this is the result. A simple automated test integrates it into my development cycle.
After running it against my code, it found some issues -- most of my which were pretty tame: 2-arg open, lack of pod, plus a few regex and character matching niggles.
In my policy file, I have two sections: Things I don't agree with and things I've had to disable temporarily. I hope to eventually go back and clean up my code so I can remove the remainder of the temporarily disabled policies. The policies I don't agree with may change over time, but this is my current list of preferences.
I have yet to use this setup in any other project, but I think the tool is useful enough that I could put it into place from the very beginning of a project or go back and run it against all of my old projects over time.
Until next time...
NB: This is my first post in the EPO Iron Man challenge. (Warning: contains some expletives)
First and foremost, the long awaited Catalyst 5.8 is out! My mind-share has primarily been with the 5.7x series so I've been pretty much out of the loop on everything that's going on. Luckily enough, everything is basically backwards compatible (less any necessary module upgrades).
Besides the usual round of bug fixes, this release is built on top of Moose. I'm a big fan of Moose and the ease with which it lets me code, so I'm very excited to see this feature. Be sure to check the Changelog for all of the details.
As far as my personal projects go, I've finally been able to deprecate two of my oldest modules (Image::ANSI and Image::XBin) with the latest release of Image::TextMode. This release now mirrors all features provided by the two before it (and then some). It can now write each format (not 100% complete, but release-worthy) -- I've even included a little bit of naive RLE compression.
Personal projects let me explore some new/different technologies which may not fit in do my daily $work. One of those would be Moose, as mentioned above (which is now part of our standard "toolkit"). Another would be XS. Writing Image::TextMode::Reader::ANSI::XS was very eye opening as far as hooking Perl and C code together and illuminating the Perl internals for me.
Recently, I've been in tune with adding new QA tools to my repertoire, such as: Benchmark (high time I learned more about it), Perl::Critic (again, about time) and Devel::NYTProf.
If I'm going to keep up with this "Iron Man Challenge," then maybe I will save my favorite QA tools for their own post. Stay tuned!
Like so many before me, I have now joined the github cabal.
One of the more interesting parts of github is their breakdown of projects by language. At the time of this post, Perl has 6% of the projects -- tied with C, 1% more than PHP, 3% less than Python and most surprisingly 1% less than "Shell".
Obviously, given the origin of github, Ruby is way in the lead with 30%. But, I have a feeling that as people get more savvy about SCM tools, especially distributed SCM tools, Perl will make a significant dent in that.
Like i said back in July, Catalyst 5.71000 would happen before the moose-ified 5.80 gets shipped. That day is here. Here's the basics on what's new since 5.7015:
- Relatively chained actions
- PathPrefix (I only mentioned that, oh, 2 years ago :)
- $c->go and $c->visit (they do a full dispatch to the action; this should kill the SubRequest plugin)
- Refactored component resolution (which is something else I worked on)
- Documentation improvements
- Misc bug fixes
Enjoy!
I've had a number of people show interest in WebService::Solr since its release last fall. This is really encouraging.
Especially encouraging is seeing Eric Lease Morgan's first article in a series of three dealing with indexing and searching using WebService::Solr. The initial post deals with some basic definitions, setting up Solr and writing a basic set of indexing and searching scripts.
It'll be great to see how the module gets used in a truly practical way.
Neighborhood
Explore friends, family, friends & family, or entire neighborhood.
