I was reading an interesting discussion on python-dev, and it made me think about the analogous situation in Perl. I've long been in the habit of putting each package into its own file, no matter what. Now I'm starting to consider combining related packages into one file, and only breaking things up along lines of reuse.

I initially thought there was consensus in Perl circles to have a single file per package, but on further reflection, I started to doubt myself. I don't actually have much confidence that this is true. I don't usually look at the file structure of distributions I use from CPAN. Maybe there is more combining than I realized. Any thoughts?

I have been using git and Github off and on for a while now but I’ve never really learned much about it.

Today, I mistakenly added a tag with the same name as a branch and pushed it to Github. I was able to get rid of it locally but I was pulling my hair out trying to figure out to remove it from Github. I finally stumbled on the solution so here is what I learned.

Removing a git tag:

git tag -d <tag>

Removing a git branch:

git branch -d <branch>

Deleting a tag or branch from Github:

git push origin :<tag or branch>

Deleting a tag (with the same name as a branch) from Github:

git push origin :refs/tags/<tag>

Deleting a branch (with the same name as a tag) from Github:

git push origin :refs/heads/<branch>

As the Statistics site wasn't being regularly updated for the past couple of weeks, the latest milestone on the Interesting Stats page of the CPAN Testers Statistics site was way down the watch list. So I was surprised to see that we now have over 9 million test reports in the CPAN Testers eco-system. Many thanks to all the testers who have help to contribute to the milestone.

Congratulations once again go to Andreas for posting the 9 millionth report. It was a PASS for Log-Report-0.28.

Over the last couple of months, a startling array of events have transpired, and hence conspired to delay progress, but finally I have App::Office::CMS working at home.

I’ll shortly release a dev version (V < 1.00), so you can check the installation instructions, if you wish, and the docs.

I just have to finish off the POD, which is mostly written.

The dev versions will start by using textareas for input, not TinyMCE, the editor I’ll activate for V 1.00. After all, these versions are just for playing with.

Also, I have not yet integrated revision history, so there is no roll-back capability. I’m looking at Git::Repository for that. Only 1 copy of the data is stored, in a database via DBI.

Recently a friend of mine back in the US mentioned an art project she was working on. She was looking for words which are composites of two words. She didn't necessarily want obvious composites like "bluebird", but less obvious composites that can be worked into her art project. For example, "homeless" could be "home less", or "garbage" to "garb age". A few people struggled to come up with examples. I came up with /usr/share/dict/words and a few lines of Perl. I use a few nifty idioms that every Perler should be familiar with.

Several people have asked about the chat system in The Lacuna Expanse and whether it is something they could use in their own sites. Indeed it is, though until today it was anonymous only. Read on for the details.

I originally wrote a very long post about this but somehow it wasn't probably saved while restarting so you'll have the benefit of a shorter version.

I've decided to stop focusing on Perl for Android for now. This is not to say I'll never get back to it, but that I definitely won't be involved with it in the near future.

I assume many are wondering about the current status of Perl on Android. Starting with "there is Perl for Android already" and ending with "it probably isn't the Perl you wish you had" seems like a good summarize. There is a patched-but-not-documented Perl 5.10.1 cross-compiled for Android. It might be relatively old and missing some very useful core modules, but it works for most uses. Also, you could hack around what's missing.

Until a few days ago I have a lovely tool, which I wrote in perl (of course), which would visit several of Amazon's websites and download my wishlists. But it stopped working. Apparently, Amazon decided to just turn that particular part of their API off. Does anyone know of an alternative to Net::Amazon::Request::Wishlist that still works?

Doesn't particularly have to be in perl.

Last week The Linux Journal published this excellent article written by Carl Lundstedt of the University of Nebraska, Lincoln which details many ways Linux / open source is used around the world by scientists working on cutting edge physics.

The computer cluster he details is the same cluster I ran large stacks of Perl on for my "mutation grid" project whose name I stole when I formed Mutation Grid, Inc. A little trip down memory lane for me, and a good read for curious minds. :)

I've been working on a restructured perlvar and I think I've mostly got it right, but at the moment I'm almost wishing that I never have to see it again. Have a look for yourself. It's in the perl git repo in the briandfoy/perlvar branch (if you're looking at the github mirror, realize it's several hours behind).

The new version notes when each variable appeared in the Perl 5 series of releases if it wasn't there at the start.

I still have to ensure that nothing breaks the perldoc -v stuff. I've tried it on several variables without problems but I don't know if some of the restructuring affected the odd variable.

I expect to merge this for the next development release, so I have a couple works to sort out whatever is left.

My brother finally created his first GitHub account to try and work on public code and even forked and asked for a pull request on a module I'm working on.

He's now converting yet another CGI website to Dancer.

Here's hoping this will lead to a fun and joyful career.

At first I was excited that Microsoft had created PowerShell -- a usable command-line shell for Windows. (I always have 4 Cygwin Bash windows up on my XP PC at work, and before Cygwin got stable I ran the MKS Toolkit version of the Korn Shell.)

Once I started using Powershell, I quickly became disappointed. There wasn't anything in PowerShell that I wanted to do that did not exist in an easily-consumable form in Perl. That would have been acceptable -- if it hadn't been for how slow PowerShell was compared to Perl or Cygwin Bash. As someone whose bread'n'butter for several years has been .NET programming, I am still not sure why PowerShell is so much slower than Perl or Bash (if anyone knows, please tell me). (I don't have problems getting a sane level of performance out of .NET.)

I may be out of touch for a bit as I'm moving to Amsterdam tomorrow night, but in the meantime, tell me what you would like to see for "Perl 101" blog posts. Every time I post something with the newbies tag (which I'm going to change to the friendlier "perl101"), I get a fair number of comments and the post shows up a few times on Twitter. Since I'm getting a good response, I'm assuming that people actually like these posts and want to see more of them.

So tell me what you want and I'll see what I can do.

Resolving Branches and Calculating Merges

The most important part of the repository conversion I did was resolving all of the branches and calculating the merge points. The majority of the rest of the process is easily automated with other tools.

The main part of this section was determining what had happened to all of the branches. One of the important differences between Git and SVN is that if a branch is deleted in Git, any commits that only existed in that branch are permanently lost. With SVN, the deleted branches still exist in the repository history. git-svn can't delete branches when importing them, because that would be losing information. So all of the branches that existed throughout the history of the repository will exist in a git-svn import and must be dealt with.

ElasticSearch version 0.12 is out today along with some nice new features.

However, the thing I'm most excited about is that ElasticSearch.pm v 0.26 is also out and has support for bulk indexing and pluggable backends, both of which add a significant performance boost.

Pluggable backends

I've factored out the parts which actually talk to the ElasticSearch server into the ElasticSearch::Transport module, which acts as a base class for ElasticSearch::Transport::HTTP (which uses LWP), ::HTTPLite (which uses, not surprisingly, HTTP::Lite) and ::Thrift, which uses the Thrift protocol

I expected Thrift to be the big winner, but it turns out that the generated code is dog-slow. However, HTTP::Lite is about 20% faster than LWP:

   httplite   :  63 seconds, 951 tps
   http       :  79 seconds, 759 tps
   thrift     :  690 seconds, 87 tps

Bulk indexing

Since version 0.11, ElasticSearch has had a bulk operation, which can take a stream of index, create and delete statements in a single request.

I have moved my blog to here from use.perl.org (Mark Leighton Fisher).

A couple of days ago, I posted about my answer to a Stackoverflow question asking about the speed of the smart match operator. Smart matches looking for a scalar in an array, can short circuit, so they are pretty speedy.

The trick, however, is if this sort of smart match is faster than a hash lookup. Yes they are and no they aren't. I've updated my Stackoverflow answer with additional benchmarks and a new plot.

Smart matches are faster if you have to create the hash, but slower if you already have the hash.

There's a middle ground in between that I don't care to find. For some number of searches of the hash, the cost of creating the hash amortizes enough that it's faster than a smart match.

It depends on what you are doing, but that's the rub with every benchmark. The numbers aren't the answers to your real question, in this case "Which technique should I use?". They only support a decision once you add context.

I was doing a code review and discovered that one of our developers wrote code using Storable's freeze() function. This turned out to be a bug because we store objects in memcache with nfreeze() instead. Storable's docs have only this to say about nfreeze().

If you wish to send out the frozen scalar to another machine, use "nfreeze" instead to get a portable image.

Since people generally use freeze() instead, I decided to dig around and figure out what was going on. After all, if nfreeze() is portable, there must be a price to pay, right?

I'm doing lots of work with representing stuff stored in the file system as trees at the moment as part of my toolkit for open source qualitative research software.

One of the things I need to do (for making reports) is to transform this:

 [ [qw/foo bar/],
   [qw/a b /],
   [qw/x y/], ];

into this tree structure:

 {
   'foo' => {
       'some_data' => 'lvl0',
       'children' => {'a' => {
           'some_data' => 'lvl1',
           'children' => { 'y' => 'leaf', 'x' => 'leaf' } },
                      'b' => {
                          'some_data' => 'lvl1',
                          'children' => {
                              'y' => 'leaf', 'x' => 'leaf' }}}}};

Being a nice golf problem I thought I'd ask on irc if there was a hacker better than me who felt like taking a look at this. ribasushi++ obviously had a little procrastination time available and wrote me a nice solution which I needed to make into a closure via a recursive subref:

After "What Weird Al and Larry have in common" and "some thoughts about Pearls" comes here the showdown of our little trilogy about the meaning of the name of our favorite language.

Some people asked me, why I don't use more words to explain some terms like binah and give more links. I try to do it this time a bit more. Some Jews may even say thats not good to talk about such things at all in the open, but i prefer to orient myself on the baal shem tov who said otherwise. to some this may be completely of the top, but on other hand you not might get so easily to that kind of information. :)