I can't make it to Iceland for the Nordic Perl Workshop, which I think is all but officially cancelled now while Eyjafjallajökull does its thing. NPW might reschedule for later in the year. Maybe we can turn this into a virtual conference, though. I'll see what I can do to give my talk here and upload the audio and video. Maybe other people can do the same, or at least upload their slides.
Most of the problem in the re-routings of airlines. I was flying from Boston to Keflavík on IcelandAir, but now those direct flights are cancelled. The reroutings are through Glasgow and other odd places with extremely long transfers. By the time I got to Reykjavík, it would be time to come home again. Curiously, I think this would have affected my travel to anywhere in Europe since the backlog of passengers is clogging planes, and flights from the US to anywhere in the Nordic area are still affected.
IcelandAir is offering full refunds, although it looks like they have to process them by hand. The Hotel Loftleiðir has a full refund policy if you cancel 24 hours before arrival, but their website is wonky so I had to write to them by email at icehotels@icehotels.is.
Today, I ventured into #dbix-class inquiring about some performance problems I was having. I wasn’t complaining about the speed of DBIC, I was looking for ways to trim out work that I was doing that I could avoid doing. The script I was running (file parser + insert into DB) was taking a little more than an hour to run. I was musing whether to drop DBIC, parallelize the job or just deal with the slowness when** ribasushi** (Peter Rabbitson) came to the rescue. After sharing with him a copy of NYTProf’s output, he quickly identified some hot-spots in SQL::Abstract that could be worked on. Soon enough, Caelum(Rafael Kitover) chipped in and we had improvements (some XS code wasn’t being used) in Class::Accessor::Grouped coming. Within an hour I was upgrading CAG, SQLA, DBIC and installing Class::XSAccessors and profiling the code again.
Total improvement: time spent inside CAG dropped by 57% and 44% in SQLA
Total time elapsed: ~2 hours.
If this is not a sign of what makes the perl community great, I don’t know what is.
The code is not flying any any means, but the total runtime was reduced by 34%, which is not bad for an evening’s work.
Yesterday we had another Tel Aviv Free and Open Source Software meeting.
The meeting took place at a new venue provided by Amir. The venue was Shenkar engineering and design school in Ramat Gan (which is like an extension of Tel Aviv - so it's cool :)
A lot of people came to the meeting, and it was very nice to see so many new faces. This time we had a review of "Programming Pearls" which Shlomi Fish gave, followed by a lecture on Source Code Management systems (also called Version Control Systems) given by me.
It was a refreshing experience to speak of something that all programmers had in common and although I thought we're going to have tackles of "Git vs. Subversion vs. whatever", we didn't. We had interesting discussions on programming paradigms, policies and programming conventions and how SCMs can help or impede them.
Apparently a movie about Ada Lovelace is in the works. Zooey Deschanel, whom many of you will remember very fondly as Trillain in the Hitchhiker's Guide to the Galaxy, is said to have agreed to play Ada. A brilliant choice.
Ada is one of the most important people in the history of Western thought. And perhaps for that very reason, she is a lightning rod for denialism like perhaps no other woman thinker. I once heard a panel of three experts on BBC unanimously diminish her into a Babbage hanger-on. To do this, these experts had to ignore the distinction between a big calculator and a computer and forget the one between software and hardware. This they were able to do by gossiping about opium and race tracks.
For years people have been saying that Perl is dead or is dying. I've even said it, although not with the same implied meaning.
Today, with the power vested in me by myself, I hereby declare that we are now in the Second Age of Perl; and it has nothing to do with Perl 6!
It's not that I don't like Perl 6 / Rakudo. I actually love it, but I don't make my living from it. Perl 5 is what brings home the bacon, and my guess is that it will be that way for years to come.
Let’s be honest. Perl 5, Python, Ruby, they’re almost the same. There are some differences, but when your compare them with C, Java, Haskell or some such they suddenly feel rather superficial. They suitable or unsuitable for pretty much the same tasks, occupying a niche that Perl pioneered: that of a high manipulexity and whipuptitude.
They each operate at the same abstraction level. Even if a language is lacking a feature that the others have, it’s easily implemented using other constructs. There are plenty of valid reasons to prefer one over the other (taste, library availability, programmer availability), but they all offer the same power. Perl 6 is going to change that.
Perl 6, like Perl 5, Ruby and Python steals a lot from other languages. As you may expect, it steals too many things to mention from Perl 5. It steals chained comparisons from Python, objects from Smalltalk (in particular Squeak’s traits should be mentioned). It thankfully steals nothing from PHP.
Last week on stackoverflow I came across an interesting challenge. Since my new module threads::lite seems to have stabilized enough for such a task I decided to to port the erlang submission to it (while using some helper routines from the perl submission). The porting was a fairly straightforward process that resulted in a pleasantly readable program (specially when compared to the other entry).
Then I ran it. It ran almost 6 times as slow as the other perl program!
Reason enough to profile it and see what was going on. Renodino's comment proved to be quite accurate: Storable and locking seemed to be the main culprits.
To tackle the first issue I added a simple but effective feature: if a message contains only simple elements (no references or undefined values), it is packed instead of frozen.
the latest version of perl was released 4 days ago. It was interesting to see how it was reported on various channels.
Some were sort-of comparing it to Perl 6. Others wrote that it does not have major changes just a few bug fixes. Some wrote that The Perl Foundation announces it, others were stressing the release of ActivePerl 5.12 by ActiveState.
In any case I'd be interested to collect the news coverage about the release. So if you saw any other articles - either in English or in any other language - please post it on the wiki page of The Perl Foundation or just leave the links here as a comment and I'll copy them over to the wiki.
It takes the database connection details from the app config file, and provides a database keyword which will return you a connected database handle (taking care of ensuring that the DB connection is still alive, etc).
So, usage can be as simple as:
my $books = database->selectall_arrayref(
'select * from books where author = ?',
{ Slice => {}}, $author
);
(Calling database() simply returns a DBI database handle, so you can obviously do anything you can do with DBI).
Also, at the moment, if a database connection could not be established for any reason, database() will just return undef, so you will need to handle errors appropriately. After considering whether it's wise, I may tweak it to die, so that Dancer will handle the failure with a pretty 500 error for you (in which case, I'll make it possible to disable that via the config).
It's been pointed out to me that many programmers have issues with my blog because I'm writing about allomorphism, exceptions as flow control and other topics that are, frankly, not something a beginner programmer is going to warm to. I think that's a fair point and I'm going to try to start including information aimed at those new to Perl and those new to programming.
I'll start with subroutines. Specifically, an old, horrible example.
One of the first things a Perl programmer will notice when learning about Data::Dumper is: how weird and "inside out" the OO interface is. This is, I think, another unfortunate accident in the Perl history, as Data::Dumper, being the first of such modules, gets into the core in early Perl 5 and remains popular up until this day. But the interface and default settings apparently annoy a lot of people so much that alternatives and wrappers like Data::Dump, Data::Dumper::Again, Data::Dumper::Concise, among others, sprung up to life.
A loose analogy would be CVS which was popular for (too long) a time, and following it the explosion of alternative version control systems. Eventually after this phase a winner will emerge or dominate. In the version control system case it appears to be git. And in the Perl case I think it will be a builtin perl() method/function, like in Perl 6. Probably in 5.14? 5.16? 5.18? Don't you think it's about time Perl can "natively" dump its own structures in Perl, just like Python, Ruby, PHP, etc have been able to for a long time?
(Btw, lest anyone thinks otherwise: I do love DD. It has lots of options and has served its purpose well over the years.)
I am about to upload a new Alien:: distribution that downloads, builds, and installs a very, very large library. The installation of this Alien:: distribution occupies about 240MB on my laptop and compile times are huge even on my fast computer.
Is there a way to flag a distribution as unsuitable for CPAN testers? I'd rather not abuse the volunteer infrastructure by having them compile a library over night.
Over the weekend of the QA Hackathon, which by all accounts was another great success (and I think David, Ricardo aand I all wish we could have been there too), various work on CPAN Testers 2.0 was underway. With the submission to the Metabase and the feed from the Metabase into the cpanstats database being two very distinct parts of the eco-system, it has made work on both parts a lot easier as it only requires one interface between them. While much of the interface has been evolving, it has for the most part been fairly straightforward. However, unfortunately while testing the interface, I noticed that several reports had been posted with no text report. Seeing as this is the part that authors really need to see, it means that we now have to discard those reports. In addition, David also found a problem with how S3 names objects, which was causing a problem for storing facts within the Metabase.
