John Anderson will be giving a talk at YAPC::NA 2012 described as:

Have you ever spent most of a day getting your editor set up “just right”? Have you justified the time spent on customizing your configuration in terms of the overall productivity gains that are going to result once you remember what key binding you put that new tweak on? Or maybe, whenever you see a tweak described for that _other_ editor, you can’t rest until you’ve duplicated and maybe even expanded upon it for the clearly superior editor you use? If the above hit too close to home — particularly if you’ve ever written a program specifically to allow you to more easily deploy your editor configuration on a new machine — this talk is for you.

We’re going to talk about editor tweaks that make writing, testing, running, and otherwise working with Perl faster and easier, so you can focus on the stuff that really matters: beer, go karts, and cool new editor color themes…

[From the YAPC::NA Blog.]

I know, I know ... it exists a powerfull tool called perlbrew

but

there is more than a way to do it :-)

read Install your own Perl with your own CPAN

every feedback is welcome

After (IMO) elegantly solving an SO question using my Tie::Array::CSV, I thought I might share it here to give you all an idea of when you might want to use it. This example is only reading the file, but remember that T::A::CSV gives you full row/column read/write access to the underlying CSV file in place.

The OP needed to find the column with a certain identifier which was 7 chars starting with a letter (in the example data below, this is the fouth column (i.e. index 3)). Then extract the number of repetitions of that identified in that column. Here was the solution that I posted.

I wrote the followup to my last article on estimating - you can see it here: Estimating like an Adult - What to Steal from Agile

YAPC::NA 2012 is going to be great. Nope, not because of all the talks, or activities we have planned. It’s because this sculpture adorns the lobby of the Pyle Center (aka the conference facility for YAPC::NA 2012). This place was made for Perl. =)

[From the YAPC::NA Blog.]

Perl is somewhat broken as language as it autovivifies symbol values when accessing them.

Clarification because this post has technical errors:

The following is from a naive understanding of the hypothetical defined operator as it is known from other computer languages or the C preprocessor. Perl's defined was invented to check for the undef value, but is often and falsely used to check for definedness of a symbol.

My understanding coming from a CS background was that defined should check for the existence of the symbol type slot, without creating the symbol and slot. "This this symbol exists?" This is wrong. To check for the symbol being defined, use exists in the symbol hash, the "stash".

My source directories tend to collect cruft, and it can be a pain to separate the real ack hits from the crufty ones. I am ashamed to say how long it took me to think of the following:

function ackx {
    if [ -f MANIFEST ];
    then ack "$@" `sed 's/[[:space:]].*//' MANIFEST`;
    else ack "$@";
    fi
}

Yes, this could equally well have been a small Perl script involving ExtUtils::Manifest, as a more portable implementation, and a cleaner way to get rid of any comments.

By now most people who would be reading my blog are aware of the kerfuffle going on about people being pushy about strict (and other Modern Perlisms).

As a relatively new Perler (my first scripts are dated 2009) I believe I have an underrepresented opinion on the matter. I was lucky to have had StackOverflow and the community around me as I was learning Perl. Someone, I don’t remember who or with what tone, told me that I should use strict and warnings on my code. Not knowing any better, I did.

Then Perl was easier. Simple as that.

I have learned a lot since then. I know when I need to no strict 'refs' or no warnings 'once'. Personally I wish these pragmas were default. In fact, I have had so little problem with Perl that I’m horrendous at the debugger; I really haven’t needed it. Of course I know that one of Perl’s best assets is its compatibility, and therefore strict/warnings is not default.

If you want to a reserve a hotel room at the YAPC::NA 2012 conference facilities then you need to do so now. Reservations close on May 1. 

[From the YAPC::NA Blog.]

Since I often do:

sub some_func {
    require Some::CPAN::Module;
    ....
}

to delay loading of modules, I am interested in how much overhead this introduces.

After first successful require(), the subsequent require()'s of the same module is very fast (around 0.08µ on my PC) because all Perl does is just convert Some::CPAN::Module to Some/CPAN/Module.pm and check this against %INC. This kind of overhead is comparable to that of an empty subroutine call.

If we change the require line to

load "Some::CPAN::Module";

I have just uploaded a late stage draft of a Theory of Computation paper on Marpa to github. The paper contains pseudocode, a correctness proof, and proofs of my complexity claims. (Marpa, for those unfamiliar, is a new, powerful and fast parser and parsing algorithm. To learn more, check out its web page.)

Progress in software follows two avenues -- implementation (aka "running code") and theory. With Marpa, it was my intention to pursue both. This is not the usual practice, but it's a natural choice in Marpa's case, because the two feed each other. It would have been simply impossible to write the code for Marpa without a theory of WHY the code worked, what kind of speed I expected in which cases, and WHY the code I was writing would be able to deliver that kind of speed.

Lately I've been having weird sleeping hours. I sleep for 5 hours here, then 2 hours there, I stay up till 4am. I know, it sounds like I'm back in school, but really, I'm not.

Yesterday at 1:50am I had the opportunity to actually go to sleep. Should I? Yes! Will I? Hmm... well... maybe I'll just watch another episode of a TV series and hack a bit.

I recently read the "about" page of xkcd and saw there is now (or has been for a while?) a proper JSON output for the comics. This means you don't have to scrape the website to get the comics. This also means you can get a lot of data right away that you might not necessarily get by scrapping. Definitely not as easy, at least.

Early-Bird Pricing for YAPC::NA 2012 ends on May 1. Register today before the prices go up!

[From the YAPC::NA Blog.]

What if I didn't have to install distributions, but instead just dropped the entire archive into a directory, much like a Java JAR file? I don't have a complete idea for this, but I have enough that I want to have public notes on it.

This is something that I think about when I can't do anything else. I'm on a bus or train in Chicago where any sign of Apple technology will get you jacked (the CTA even has signs telling people to be careful with their iPhones. Not Blackberrys or Samsung, or whatever, just iPhones). There's that time between finishing the in-flight magazine and reaching 10,000 feet, or waiting in line for passport control after I wonder if the guys with the guns would really shoot me if I took out my cell phone.

My idea is the confluence of several problems:

Steffen from modules@perl.org responded to my email yesterday and made me a co-maintainer of String::Strip. I've applied the 64 bit bug fix to it, and pushed 1.02 to CPAN. Thanks for everyone who responded to my thread yesterday about requesting co-maintainer. This is how open source is supposed to work!

Edit: orginially rchomp, but Aristotle’s suggestion of chomped is perfect!

brian d foy posed an interesting interview question: “What five things do you hate most about language X?” positing that an experienced user of X should know 5 things (s)he hates about it.

In my list is the return value of chomp. Yes I understand why it works as it does

print "chomped" if chomp $input;

but I find that use case happens far less often than the usual

chomp( my $input = <> );

It looks bad, and it is not intuitive, especially to the new user. Just today another one popped up on StackOverflow. This has got to be one of the most common questions on the site.

We’re exactly two months out from YAPC::NA. Can you believe it’s that close already? 

If you haven’t already, then it’s time to get serious about making your travel arrangements for YAPC::NA 2012. 

Remember, YAPC::NA 2012 will be in Madison, WI from June 13-15. Book your flights, your hotel rooms, buy your badge to the conference, and bring your spouse along to enjoy our amazing Spouse’s Program.

[From the YAPC::NA Blog.]

In a month an a half, we'll once more have the QA hackathon. Before going to Paris, I'm going to blog about the things that I want to do. I have a fairly packed list of things I'd like to do there; definitely more than I can do in 3 days, but fortunately there will be free-floating helpers that will hopefully help me out.

Also things that require feedback from other people.

Metadata now

Currently, there are three pieces of metadata that may be installed during a cpan install. They are neither complete, nor can one rely on their presence

.packlist

The packlist files contain a list of files that were installed. It's a very simple format, essentially just being a list of files and their types. Pretty much only useful for uninstalling distributions.

However, this is probably also why it's often absent. Many distributions, most notably Debian, remove them from their packages as they don't want the perl toolchain to uninstall files from debs.

I've made some progress in getting ccv to compile under Windows. Now I can start with opening up the API and writing some XS for it. Soon, the below image can be created completely from within Perl instead of using a shell call out to the executable to find "interesting" points in the object and the scene and match them together.

The SIFT algorithm seems to be quite a useful tool to do feature recognition without any prior training. I hope to (ab)use this to recognize objects and how they move around in movies. Also, I imagine this can be used to automatically stitch images together.

If you don't know it, Archive::Tar is SLOW; it even says so. Running NYTProf recently on a project revealed that the major part of the program was taking a little more than 27 seconds to run and a little over 24 seconds of this was Archive::Tar reading the archive into memory. Since I did not need the in memory feature, I switched to Archive::Tar::Wrapper. That sub now takes about 2.5 seconds to run and the equivalent portion to Archive::Tar->new($file); is now Archive::Tar::Wrapper->new; $arch->read($file); now takes 631 ms.