I have been most fortunate to have been able to visit Zurich every year since 2008, to teach classes at the ETH.
Zurich is one of my favorite cities in the world: there’s something undefinably “civilized” about it. It’s elegant, but vibrant, and yet strangely tranquil too. From the glorious lake-front to the sylvan Zurichberg, its natural beauties always draw me back. Not to mention the wonderful food.
And yet, the reason I keep returning to Zurich is not any of those undeniable attractions. It’s the people I meet and work with there. Smart, serious, witty, genuine, and generous people. Developers, academics, and scientists, who are always a pleasure to teach…and a joy to learn from as well.
This year we’re going to try something a little different in Zurich. My previous visits have always been later in the year, but in 2012 we’re experimenting with a Spring schedule with four completely new classes.
For the past 2.5 months I mostly worked on converting my old Sub::Spec::* modules to the new Perinci::*. Sub::Spec is a mix of specification, convention, and tools to let you decorate functions with documentation as well as everything else, but most commonly argument specification and feature description. This decoration can in turn be used to do various things, from generating POD, to validating arguments, to shell completion.
The reason I picked a new name for the modules is because I want to decorate other code entities too, like variables and packages, thus the prefix "Sub::" is no longer apt. I also took advantage of this opportunity by introducing some backwards-incompatible changes like the change to schema of arguments specification. The specification is now separated more formally into Rinci (a la PSGI vs Plack) where the Perl implementation is called Perinci, short for "Perl Rinci". I envision Pyrinci, Rubinci, and Phinci seeing the light of day someday, though that would most likely be due to the effort of others.
David Mertens will give a talk at YAPC::NA 2012 described as:
Perl is awesome as processing text, but did you know that Perl can handle high performance computing, too? With the Perl Data Language, Perl can process large data at C speeds while using idiomatic Perl.
The Perl Data Language describes itself as “giving standard Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing.” What does this mean? In this talk, I will give an introduction to PDL from a Perl programmer’s perspective. I will cover basic PDL operations from creation and access to standard manipulations and will explaing basic plotting. Some of the more advanced topics will include slicing arbitrary chunks of data and, if time allows, writing code that interfaces with PDL’s processing engine.
[From the YAPC::NA Blog.]
And so to the final part of my notes from the 2012 QA Hackathon.
CPAN Testers Report Status
After asking several times, Andreas thought he finally understood what the dates mean on the Status page for the CPAN Testers Reports. He started watching and making page requests to see whether his requests were actioned. On Day 3 he pointed out that the date went backwards! Once he'd shown me, I understand now why the first date is confusing. And for anyone else who has been confused by it, you can blame Amazon. SimpleDB sucks. It's why the Metabase is moving to another NoSQL DB.
Some time ago I was invited to write a Perl article to Software Developers Journal. It is (as far as I could gather) a magazine based on Poland. Their website is at http://en.sdjournal.org/. It is a paid magazine, so to read it you should buy the magazine.
Although the magazine doesn’t have good procedures for publication (there isn’t a review phase where the authors can check if everything is fine) we think (yes, I co-authored the article with Nuno “smash” Carvalho) that the article is interesting. Probably with some English errors written by us, and probably with some others introduces by the editors. And yes, it is not our fault that they write Pearl instead of Perl… oh shame…
We are working the permission to post the article in the web. Probably we can in some time. For now, buy the magazine.
If you plan on driving in to YAPC::NA 2012 each day, or are staying in the dorm rooms and driving to Madison, then you’ll need a place to park. All other lodging besides the dorm rooms has parking available, you simply have to ask for it.
If you need parking, then you need to fill out this PDF form and submit it back to University Parking no later than May 15th.
[From the YAPC::NA Blog.]
This email slipped through Gmail's spam filter just now:
My name is Grace, i saw your profile at (www.cpan.org) today and became interested in you, i will also like to know you more, and i want you to send an email to my email address so i can give you my pictures for you to know whom i am. Here is my email address (firstname.lastname@example.org) I believe we can move from here. I am waiting for your reply in my mail. Remember the distance or color does not matter but love matters allot in life.
I don't know whether I should be sad or glad. Glad for the fact that cpan.org is considered popular enough to be worthy to be phished, or sad that no sites go unphished these days?
Since updating to the latest XCode on OS X Lion, we've been unable to build or use mod_perl 2 on our development machines. If we ignore the test failures and make install anyhow, we get this error message when trying to start Apache:
Cannot load /opt/local/apache2/modules/mod_perl.so into server: dlopen(/opt/local/apache2/modules/mod_perl.so, 10): Symbol not found: _modperl_handler_anon_add
One of our developers discovered this morning that llvm/clang on OS X defaults to C99, but mod_perl expects the 89 "standard". As a result of this thread, we compiled mod_perl in the following manner:
perl Makefile.PL MP_APXS=/path/to/apache/bin/apxs MP_CCOPTS=-std=gnu89
And voila, we have a working mod_perl 2 on Lion.
Come to find out, while researching this blog post, the macports people have already run into this:
Hope this saves you the grief it caused us.