blogs.perl.org

It's officially been 4 months since we launched the Perl based MMO: The Lacuna Expanse, so I wanted to take this opportunity to update you on its progress.

First, thank you. Without you Lacuna wouldn't exist. Many of you are playing it, and many others of you have built modules, techniques, and technologies that we used to build it. So thanks!

Three new jobs were created after launch to help serve the community. One of them was even a Perl job! So Lacuna has already started helping increase the Perl-based economy. This may not matter much to you, but it tickles me.

Today we launched our second server. This one is a tournament server, where the speed is greatly increased, the map is greatly decreased, and there is an end game.

Padre has hit version 0.80. I guess it's not a big deal, but you need to lead with something.

Adam Kennedy is by far the most prolific contributor for this release, clearly there are a few things that need scratching.

It seems though that this release was rolled out just in time for him to injure his wrist skating, not sure if it was roller skating or roller blading, so we may see a slow down from Adam for a while. Time will tell of course:

I asked on the vim mailing list how to see the name of Perl's current sub/method in the status line and Alan Young, the author of PPIx::IndexLines has a great suggestion which unfortunately relied on PPI. I'm working with very large modules and PPI ground to a halt for me. As a result, I took his suggestion and worked out the following.

First, make sure that your .vimrc has set laststatus=2 in it. That will ensure that you always get a status line, even if you only have one window (i.e., don't have split windows). Then drop the following into your .vim/ftplugin/perl.vim:

Several years ago at OSDC::AU I was lucky enough to run into Rusty Russel three breakfasts in a row. He was at the conference to deliver a keynote on why C is awesome and all us scripter types should learn it.

I mentioned that I'd tried a few times to switch to C but I'd found the lack of any kind of CPAN pretty much crushed my soul each time I tried, because I kept wanting to make one because C and Perl are very similar languages (to me at least, compared to things like Python or Java or Haskell).

By the end of the conference he was hooked on the idea, had taken over development of libtap and written 8 or 9 patches for it. A week later we had mailing lists, and a basic design.

Today, CCAN represents what I consider to be the closest cousin of the CPAN.

while (0..25) {

$x++;

$d[$t++]=\$x;

until ($x < 25) {
lable:
print "hello::","\n";

$in = STDIN;

print ${$d[$in]};

goto lable;
}

}

## now this should print 1 when i type 1
## and 2 when I type 2 at
## and 3 when I type 3 instead it types 25
## for 1 to 25 typed in

## plese help

I like to read. Over time, I've become quite a rapid reader - I remember a project at school where you would get a dignoria (star) for writing a book review during the summer holidays... and I had read 26 books.

During my short commute on the tube I like to read something. I used to bring paperback books and magazine on the tube. Before going on a weight-restricted holiday I had bought.a Sony Reader PRS-600 e-book reader.

This was quite neat, fairly small. Not a great screen or battery life and it would only charge on a computer's USB socket, not a generic USB one. There are a wide range of public domain e-books or you can create books with your own content and the useful Calibre e-book management software can scrape news sites.

Seems that DateTime module thinks 29.2.1900 didn't exist while Excel 2008 does. Which one is correct ? Well DateTime is OpenSource while Excel is payware. Think payware would be correct ? nope, DateTime is !

So the correct DateTime object for dates starting 1.3.1900 when using values from Excel is :

DateTime->new(year=>1900, month =>1, day => 1)
        ->add(days=>$THEVALUEFROMEXCEL-2)

Excel-- !

This week I’ve been trying to switch us over to using mod_perl2. I wanted to cache database handles as much as possible so one of the first things that I did was edit my startup.pl and add:

use Apache::DBI;

Most stuff just works. When I find something that is only slightly broken, I fix it. When I find something that is horribly broken, I just create a Location in httpd.conf to tell Apache to run that as plain CGI and I’ll update them later.

The entire application suite feels faster. I suspect much of the speed up is due to caching database handles but I’d like to profile it. I have no problems profiling CGI with Devel::NYTProf. When I configure httpd.conf to use Devel::NYTProf::Apache like this I get issues.

PerlSetEnv NYTPROF trace=2:file=/tmp/mm-nytprof.out:addpid=1:start=begin:use_db_sub=1
PerlModule Devel::NYTProf::Apache

This is very brief review of a marvellous book on JS, JavaScript: The Good Parts, by Douglas Crockford.

It’s a somewhat thin book, given that JS has quite a few features, but the author’s contention is that you should stick to a small subset of those features.

Some extracts from the Preface:

• This is not a reference book.
• It is not exhaustive…
• This is not a book for beginners.

These mean he’s not trying to teach JS, but rather to guide us readers as to what components of the language we should restrict ourselves to, that we may write programs of much higher quality than would otherwise be the case.

For your entertainment, he’s called the appendices (which are worth the price of the book):

• Awful Parts
• Bad Parts
• JSLint
• Syntax Diagrams
• JSON

Regrettably, JS has many parts which are very badly designed indeed, and the so author steers the reader away from those.

Highly recommended for all of us who sail on the JS Titanic.

Perl 5.12.3 is now live...

http://dev.perl.org/perl5/

Full announcement.

Over the weekend I overhauled my personal project Fennec. Fennec is a testing framework for Perl that was originally meant to solve the shortcomings of Perl's other solutions. This release is a major simplification of Fennec, largely as a nod to the fact that Test::Builder2 will solve a majority of the "results should be objects" problems that Fennec formerly addressed.

Catalyst 5.9 is coming up, and the big change is a wholesale switch to PSGI, completely dropping Catalyst’s own engine system (outside of compatibility shims). This is bound to bring in new people wondering what PSGI and Plack are all about and what you can do with them.

I’ve been using Catalyst on top of Plack for a while now (with the aid of Catalyst::Engine::PSGI) and have gotten around to some nifty things with it. So here is my app.psgi for inspiration:

Lastly I tried to access files on a Samba share (running on a Debian machine) from Carbon Emacs running on Snow Leopard. The files where in a git-repo, so vc-git tried to do his stuff. This made Carbon Emacs hang while creating .#file.pm linked files. flymake had the same issue. So instead of disabling vc-git and flymake, I searched the internet.

unix extensions = no

I have uploaded the source code for Yenta, our highly-available key-value store to CPAN.

Yentas operate as a peer-to-peer network (there is no "master" node). Nodes use gossip based protocols for distributing membership + status information. Put() operations distribute data in a network-topology aware manner. Eventual consistency is achieved by data versioning and gossiping merkle-tree hash values.

At Solve Media, our web-site partners depend on our technology. If we go down, they go down. Yenta is one of the technologies we use to ensure our high availability at scale.

Sorry. No Perl in this post, but this appears to be such a common problem that I've decided to write up a simple description of how to convert FLAC to run in iTunes.

FLAC is the "Free Lossless Audio Codec". It's a fantastic file format, but there are a couple of issues. First, songs typically run 25 to 40 megs per song. This means that they take up roughly 10 times the hard disk space as a corresponding MP3. For extremely large music collections this could be a problem.

The other problem is that Apple has chosen not to support FLAC for iTunes. I tried many solutions listed online, including Xiph and Fluke and got nowhere. Finally I decided it was time to go "old-school" and fall back to the command line.

I downloaded the FLAC tools and installed them. That gave me access to the flac program. Then I installed the LAME MP3 encoder. I used MacPorts for the latter, but you can get it from the Sourceforge link I provided.

Having had Plack on my 'to looking to list' for a long time we've finally started using it at work. Yet again here is another of the 'modern perl' pieces of software that once you start using you'll wonder how you ever coped without it.

As first it doesn't seem like you have much that wasn't done in Apache (or what ever web server you are using). The moment you realise that you can put everything that was in Apache (rewrite rules, expiry headers, serving static content) into your app.psgi (web application configuration) file and that this will then run under any of the many supported web servers the light bulb goes on.

You can then try Starman or run everything using plackup in your development environment.

The simplicity of Plack's structure $ENV in, [ status, [ headers ], [ content ] ] out makes writing middleware easy and adapting your code to use this standard very clean (even if you don't use one of the many frameworks which already directly support Plack).

I've also added a white paper on Plack to Perl.org.

I've just read a very thoughtful description of why one Perl programmer switched to Python. In this blog post, I'll explain why I did not.

When I started on the Marpa project, Perl was not an automatic choice. In fact it looked like it might be the wrong one. There was as much buzz for Python then as now. Maybe more. I'd had my own experience with Python, and it was excellent. I'd used Python to create a threaded mail client for testing purposes. I found Python to be easy to learn, fun to use, and an effective way to accomplish my task.

Perl had another problem. An important audience for Marpa, my new parser, is academia. Academics certainly use Perl. My experience is that they even respect it in a certain sense. But Perl does not fit neatly into the minimalist paradigms which still rule academia. If you speak Perl to academics, you are not talking their language. That means you run a great risk that nobody will listen.

So, FOSDEM is approaching. If you don't know what FOSDEM is, it's a very big European technology conference, taking place in Brussels, Belgium. Usually it deals with generic topics, such as "systems administration", "BSD", "GNU", "accessibility" and such, but this time Gabor Szabo was able to secure a devroom specifically for Perl!

This is a great opportunity in presenting Perl both to more mongers, but also to the external geek community (outside of Perl Mongers, CPAN authors, and other Perl community members) and showcase some of our stuff.

People have volunteered and we're going to have a few really cool talks: Moose, Dancer, PEG, Packing Perl, Tracing Perl with DTrace/SystemTap, Template::Zoom, SPORE and Padre are just some of the talks you'll see.

However, we still have a few slots open, so please do submit a talk if you're coming!

And remember, if you see me there, don't be afraid to step up and say hi, because I'll probably be too shy to do it! :)

Update: to submit a talk, contact me via xsawyerx AT cpan DOTT org.

What's a good book about programming for Unix? In Learning Perl, while showing the file test operators, we say:

Don't worry if you don't know what some of the other file tests mean--if you've never heard of them, you won't be needing them. But if you're curious, get a good book about programming for Unix.

But, we then leave the reader hanging without giving them an idea which book they might. I guess Chapter 4 of Stevens's Advanced Programming in the UNIX Environment might be the answer, but is there something else?

I've added a new White paper to Perl.org: Perl load balancer - which is really there to make people aware of Perlbal.

Thanks to a TPF Grant there is now actual Documentation which really makes using it a whole lot easier! I've had this in production for about 4 years now and it's very stable. Being able to change which servers (or ports) your entire sites traffic goes to make gradual rollouts (and quick rollbacks!) very easy. It also makes upgrading your servers far less complex.

If your not already using a web load balancer infront of your web server check it out!