blogs.perl.org

This year the YAPC Surveys have had a few updates. Every attendee now gets an email beforehand containing their personal keycode, so they can prepare the bookmarks before they get to the conference. The announcements are now part of the administration on the site, so I don't have to run everything manually, and can send repeat announcements to users who confirm late, even during the conference.

This year, for the first time, and thanks to a suggestion from Curtis Jewell, the Lightning Talks are all now available for feedback by attendees.

The survey will be open for 4 weeks, and now I have the tools in place, I'm hoping to have the results out before YAPC::Europe. Likewise, I aim to get the talk evaluations to speakers by then too.

Now that the CPAN Testers work is now in monitor mode, I can now pay more attention to packaging up the survey code and releasing it all. I've had interest from various people to use it, and it will be good to get some further use out of the code than just YAPCs. Mind you if any Workshops that use Act would like me to integrate the surveys with your event, please let me know and I'll set up and instance for you.

In a recent interview I did with SourceForge, I got to plug all the really great development that's been going on in the second age of Perl.

I think it's nice when we as Perl devs are able to spread the word out to audiences outside the Perl community. Hence the reason I share this link. I'd like to see more of this from other Perl devs.

Truth == Simplicity?

In other posts, I talked about improvements to Jay Earley's parsing algorithm -- some from Joop Leo, some from Aycock and Horspool, some of mine . Here I'd like to talk about Jay Earley's original algorithm. A common belief of great scientists is that, if an idea is basic and true, it is in essence also simple, and therefore it must have a simple explanation.

Finding the simple explanation might be far from simple. But a simple explanation there ought to be. I like to look for those simple explanations. Writing my mathematical novel, The God Proof, confirmed me in this habit. Whenever I am studying something, and it seems important and true, I look for the simple explanation.

Dotted Rules

The idea behind Earley's algorithm is that you can parse by building a table of rules and where you are in those rules. "Where" means two things: location in the rule relative to the rule's symbols, and location relative to the parse's input stream.

In a Perl script typically a shebang line is something like:

#!/usr/bin/perl

this works great if you want to use a wide, system based, Perl for your scripts. But what if you have several different installations of Perl and want to run the same script using different Perl versions without having to change the shebang line. Well, one possible and straightforward solution is to change it to something like:

#!/usr/bin/env perl

and then push the version you want to use to your $PATH environment variable. This can even be easily done based on the user. For example, you can have a user named 'perl_5.10' and for that user have:

PATH=/usr/local/perl_5.10/bin:$PATH

now, this user runs scripts (with the env version of the shebang line) using Perl 5.10.

I've done a little more with Perl and web design, but I've encountered a problem that has left me a bit perplexed. There's something PHP does that I'm sure Perl CAN do, but I'm just not sure how. That said, I'm not a huge fan of PHP, and to be quite honest the only function I've utilized has been include(), which is what I need to replicate. As you know, being able to standardize a page layout (header, body, footer) with separate pages makes things much easier to update. Instead of correcting/adding a navigation link to twenty pages, you only make one change! However, using PHP within a Perl script (without the aid of the PHP or PHP::Include modules - my host doesn't have 'em installed) doesn't work as the browser doesn't get the chance to parse/execute the PHP.

Made the drive to Columbus uneventfully.

Got checked into Morrison Towers and the conference.

Took a nap. Went to the Arrival Dinner at BW3's. Met Murry at the dinner and John on the walk back to the dorms. Had a drink at Eddie George's.

Drove to Port Columbus International Airport to pick up chromatic and Jon Swartz.

Surfed the web.

Wrote this.

Now setting an alarm and going to bed.

hooray I will give my first training course at YAPC. As every quarter, i written another wxperl article for $foo which will get part of the teaching material as well as my code examples for the wxperl workshop last year. i really need to prepare better for such incidences.

horray my first article for heise got published. it was about the german perl workshop some days ago, $foo got an entire different version of that, which gets into print today

hooray my money talk was well recieved and helped me to get some interesting contacts.

During the German Perl Workshop I met my friend Mark Overmeer who asked me who financed my trips to the various events promoting Perl. I got lucky that in every place friends gave me free accommodation. The Perl Foundation, and YEF covered the
cost of the conference swag so I only had to pay the flights out of my pocket.

Then I checked and actually I paid 3,446 USD for the 4 trips.

It would be quite a lot of money to spend on my hobby but I see it also as an investment.
It is part of the scheme to get Perl used more and if my grant request at The Perl Foundation gets approved then my work will bring in enough money to TPF to cover my expenses and get compensation for the time I spend working on this.

Still Mark offered to help telling me that the SPPN (Stichting Perl Promotie Nederland aka. Foundation for the Promotion of Perl in the Netherlands) has some money and they might be able to help me cover some of my expenses.

So I sent them a detailed list of flights and expenses and within a few hours I got an approval from their board to get 500 Euro helping to cover my costs.

That's awesome. Thank you very much Dutch Perl Mongers!

I officially submitted a talk to YAPC::EU (at the appropriate time, of course) this August.

This will be my first YAPC and I'm very excited. I haven't purchased the tickets yet and it's a bit troubling that I have to make all the arrangements before knowing whether the talk is accepted, since I don't know what to ask $work to sponsor - I hope I won't miss out on room vacancy or flights.

My girlfriend (ferret) will probably be accompanying me. Considering last time we went abroad we stayed in a squat and went to protests/shows/squats, I hope she'll enjoy the tour in Pisa.

My talk is on When Perl Met Android and involves the work being done to run Perl on Android using the ASE project (in which I'm in charge of Perl now.) Hopefully the talk will be interesting enough to get accepted (I opted for a 50 minute long talk.)

2 years into my informatics studies and after a lot of java and absolutely no scripting, I'm wondering if I should stay with perl at all.
Here in Switzerland perl jobs are rare. I mean perl jobs, not "further desired skills: perl / bash".
And telecommuting jobs are mostly not that interesting because I live in a quite expensive country.
Most jobs I've looked at so far are maintenance jobs for legacy systems.
Hmpf.

Thanks to Stuttgart.pm I presented the initial results from the Perl Survey at German Perl Workshop last week. Unfortunately due to a combination of jet-lag (after a 36 hour journey) and stupidity, I didn't record the talk.

There appears to be some very good news in that people use and are enthusiastic about new versions of perl, and the cutting edge perl modules like Moose, Catalyst, DBIx::Class and so on.

Most of the analysis and graphs were done with R, a little Perl, and unfortunately for the CPAN and programming languages questions I had to result to a mix of Perl and manual munging with a spreadsheet.

The survey has generated a very large amount of information, and now that I've got an initial cut of the data analysis, I'll be writing a formal report, and investigating any interesting patterns I find on the way.

All the data is available github. The presentation slides are available from here (sorry about the small font size in some of the legends).

I had this nice 13 hours flight from Israel to Atlanta, GA and now I am at
the airport waiting for my connection to Columbus, OH. Quite last minute
but I have now two talks to give at the conference.

Actually we arrived 30 minutes early but the doors could not be opened
as the custom officers were not in their place yet. Go figure.

Anyway I found a nice spot where I could see the sun rising. It was
very nice but I should rather focus on my talks.

(Re)Packaging CPAN modules by downstream distributions

One of them is about packaging CPAN modules for the various downstream
distributions. It is mostly a bunch of whining on how little is being packaged
with some explanation why does that happen. I'll try to provide some ideas on how we
might break out from the vicious cycle of a chicken and egg problem but I
won't go into how to package CPAN modules for Debian, Fedora or FreeBSD.
Especially as I don't know that stuff.

PPI, perly.y and Marpa

Recently I've been combining the two main approaches to parsing Perl. One of these is the PPI module. The other is the parser in the actual Perl distribution. This is usually what is meant when someone speaks simply of "the Perl parser". That can be confusing in this context, so I will call the parser in the distribution, the Traditional Perl Parser (TPP).

I used the grammar in the TPP (it's in perly.y). But I threw out TPP's lexer (toke.c). I replaced toke.c with PPI::Tokenizer, rewrote TPP's bison grammar to use Marpa and put the two together.

To my surprise, mating the PPI::Tokenizer and perly.y has proved almost easy. PPI preserves whitespace and the TPP does not, so I had to throw whitespace away. PPI combines some tokens that TPP separates. (Notably PPI often combines sigils with other things. The TPP never does.) Also, there was the slightly more complicated issue of the ghostly semicolons, which I'll deal with in a bit.

I am currently reading through "Effective Perl Programming". Another fine book that I wish my coworkers would read. (And another fine book they are not going to read). The authors not only want you to write effectively, they want you to write concise code that is easy to read for anyone with a bit of Perl experience. For example, there is a piece of advice in there that says "Avoid excessive punctuation": "[...] Excessive puctuation makes programs less readale [...]" Exactly!

But why is code less readable when it's full of parenthesis, e.g.? I think the answer is simply that the puctuation lowers the signal-to-noise ratio. When reading code, you are looking for the signals, the statements that actually do something, the meat, the beef. A corollary of this is that a bit of whitespace here and there will increase your code's signal-to-noise ratio because it will make the beef stand out.

Here's a stupid little example:

I used to always scrape little bits of HTML properly, but I rarely bother anymore. I wrote this little bit of code today because I didn't find something on CPAN to do it. That is, nothing that didn't require authentication like Net::Twitter:

when (m[//twitter\.com/(?<user>[^/]+)/status/(?<id>\d+)]) {
    require LWP::Simple;
    LWP::Simple->import;
    my $user = $+{user};
    if (my $content = get($ARGV[0])) {
        my ($when) = $content =~ m[<span class="published timestamp"[^>]+>(.*?)</span>];
        my ($twat) = $content =~ m[<meta content="(?<tweet>.*?)" name="description" />];
        if ($when and $twat) {
            say "Twat by $user $when: $twat";

It prints the full contents of a tweet to IRC given a URL, here's the full program.

Ubic is a toolkit for describing services on Linux in perl. It's been implemented in-house at Yandex as a better way to run daemons than writing ugly SysV-style /etc/init.d scripts, and i've put it on github and CPAN recently.

So... any feedback? :)

PS: Several Ubic::Service::* modules are not in public domain yet - i'll have to do some cleanup first, hopefully in next week or two.

After Kieren Diments talk in schorndorf I held a spontaneous lightning talk about the state of the project called Perl 6. The slides wouldn't tell you much, since i pushed them together in 1 hour while listening to others. But i had to do it, since lot of people in the audience I talked with had no clear knowledge and some even said things on stage, that were hardly bearable. Get me right. i can listen to any opinion. No problem if someone says perl 6 sucks goats dick because that implementation will never do because... or that idea is ludicrous because it wil brake ..... but when people say things that simply arent true or if they dont even try to use their brain and don't bring spoken information in the context of the speaking person, I get a bit aggressiv.

I use git for my own projects, and the day-by-day stuff does not involve much messing with remote repositories. Anyway, it's a fantastic tool to keep track of the code and avoid losing anything.

getting started (installation apart!)

In the directory for the new project, just init:

  git init
  Initialized empty Git repository in ...

At this point, there's nothing tracked, so after editing some files you can add whatever you want to track, either by filename or by directory name. The fastest thing to do is probably:

  git add .

Note that at this point nothing has actually been put inside the tracking system - you'll have to commit your change:

  git commit

Today is the last day for proposals for YAPC::EU::2010. I have already the travel tickets, I have already a room in the Hotel. Now, I need to make something to lower my costs in Pisa, for example, to have an accepted talk, and get free entry.

To maximize my chances I proposed two talks, in very different perspectives of Perl:

The problem is that I have various .sql files containing database creation statements like:

DROP TABLE IF EXISTS foo;
CREATE TABLE foo ...
...
...;

It would be wonderful to execute these sql files using DBI’s do method, but do can only execute one statement at a time. Ok, simple enough, just split the file on semicolon, right? Well, often you have stored routines that change the delimiter, mid-statement.