blogs.perl.org

For any gEdit users out there: A while ago I've written a perlTidy plugin for this editor.
It's written in Python. I know, I know. But it was either that or C...

For those of you interested, check it out at GitHub

This is a small list of stuff I learned at YAPC::EU 2010 in Pisa.

Since my last couple of posts, things have been done:

• Complete revamping of call logic
• Finished objects for basic C Types (int, double etc.)
• A fairly sound cast() function for Ctypes
• Array objects

Crap... when you list it like that, sounds pretty dire, don't it?

Don't beat me up just yet though. I'll definitely get Pointers done in the next 48 hours. Not sure how tricky Structs and Unions will be but they'll definitely be done by the deadline too. Anyway, instead of wasting more time worrying I want to talk a bit more about my favourite topic...

Type object API revisited

In a few days, I'll be giving a talk on roles at DevTank. The audience will be developers (and business people) from many different language backgrounds. I've tried assessing state of the art for roles/traits in other languages, but am falling short. I just don't know other languages/cultures well enough.

I might add that I was disappointed to learn that Scala's traits are just mixins. I wonder how they came up with that name. Surely it wasn't just misunderstanding Smalltalk traits?

Update: As preparation for the talk, I've written a short language-agnostic introduction to traits/roles. I put that on my personal blog instead of this one as I don't want people to see the blog URL and dismiss it as just a "Perl" thing.

This year's YAPC::EU in Pisa was nothing short of amazing. While I am not sure if it will outdo my experiences in 2008 and 2009, it was everything I've come to expect of YAPCs.

While the flight was delayed, the hotel room had air conditioning (that's a + compared to Lisbon... ) and we went for some nice food in a restaurant near the river.

On the first day we walked a couple of meters to get to the YAPC buses (seriously, what a great arrangement) and met osfameron and some other attendees. We were at the hotel in 10 minutes and I just remember meeting a lot of people and attending talks, of which the keynote talk was the most surreal.
By the time we went to the evening dinner I felt like I'd been there for a week already.

Yes, the title is provocative. That's my idea. Now that I captured your attention, let me explain what's going on. I have a project, Quiki, that is requiring Perl 5.10. This because I use the given/when construct.

Meanwhile we received a bug report from Adam Kennedy asking to back port the project to Perl 5.8.8 because there are some Linux distributions that still use it. Note, I am not against this request from Adam. I totally understand it, and I am willing to help, back porting Quiki. But this makes me think. If Perl 5.10 is dated from December 2007, and we can't use its features yet, when will we be able to use Perl 5.12 features, or the new planned Perl 5.14 features?

Probably this means that we, as Linux users, should heavily complain for old releases. I suspect Adam was using CentOS. Probably we should make all CentOS Perl users fill in bug reports, and foruns, complaining of the old version of Perl that is shipping.

My slides from my talk at YAPC::EU 2010, "ElasticSearch - You know, for search", are now available here:

http://clintongormley.github.com/ElasticSearch.pm/ElasticSearch_YAPC-EU_2010/

So last month saw the big announcement that we have now enabled CPAN Testers 2.0, and we have started to see a shift of testers over to the new HTTP submission system. However, there are still a number who are submitting high volumes that we shall now start pestering to move over. Although the regular testers are fairly easy to help setup their smokers to use the new system, it's the infrequent testers that are going to a little trickier to catch.

CPANdeps and cpXXXan will be down for a few hours from around 2015 UTC on Sun 29 2010 until the morning of Sun 30 2010. This is for a datacentre move.

Following on from a conversation at the Pisa-London.pm Social last night about vim syntax highlighting useful words in perl files like TODO and how it might also be useful to highlight other useful words, like HACK and BODGE, I decided to have a go.

I knew the initial solution would be fairly simple - hack /usr/share/vim/vim72/syntax/perl.vim.

That seemed to easy, so I investigated a $HOME/.vim/ solution.

Initially I copied the existing perl.vim into my local directory:

cp /usr/share/vim/vim72/syntax/perl.vim $HOME/.vim/syntax/

edited the perlTodo line to include the new tokens.

I opened my test file and it worked!

Going Further

I’ve had a long-standing urge to handle tokens followed by an evil colon. I prefer:

# TODO: something shiny

over

# TODO something shiny

To me it looks nicer when it isn’t highlighted.

While working on the database abstraction layer for one of my toy projects, I came to a sudden realization. Why bother? I know SQL. I think in SQL. I thoroughly enjoy the relational model and DBI does pretty much everything I need. I can tie myself to one database system, since it's just a toy project. Sure, there are some repetitive bits that I don't want to repeat all throughout the codebase, but I can abstract those away once and for all. It sounds like an enormous reduction of friction. Am I missing something?

• The Perl6 in the real world talk, by Moritz Lenz had, at much, two or three slides or Perl. These 20 minutes reminded me of physics classes. Not much detail was given to the module internals.The presentation ended up with a good question from the audience: why Perl 6? with the answer, "because I like it", and because of the Perl 6 introspection mechanisms needed to calculate the dependencies. After talking in IRC with Moritz he shown me the abstract of his talk, which made me rewrite this entry. If I wasn't lazy and I've read the talk abstract, I might chose another track, or at least, do not complain so much.
• Lech Baczynski shown some common error on Perl programming, like precedence problems. While not an excellent presentation, as most of the errors where too basic, it helped Perl programmers to remind some of the details on Perl parsing, operators and functions.
• While present at 'Searching Perl Workloads‎' talk, I was distracted with some code in my laptop. Therefore, no comments. Sorry.
• Finally, on the Lightning Talks, second session, I would like to stress Andrew Shitov talk on There Is More Than Way To Empty It (an array) that was very cool.

jared recently took considered - if mischievous - aim at the Modern Perl crusade:

http://curiousprogrammer.wordpress.com/2010/07/29/does-your-perl-suck-if-you-dont-use-moose

A recent post from chromatic was the inspiration:

http://www.modernperlbooks.com/mt/2010/07/a-checklist-for-writing-maintainable-perl.html

I'd go further.

No amount of automation, source control, testing, Moose or peer consensus will help unless you understand the problem at hand. And the pure fact is your understanding will change the more you work on the problem. Worrying about maintainability will widen your concept of your problem and make it more difficult to solve. Perhaps this is justified (what little empirical evidence there is suggests that re-usable code takes 3x as long to develop as code that is not consciously designed to be re-usable - see "Facts And Fallacies of Software Engineering" by Robert Glass) but even if it is exactly what can you assume about the future needs and skills of any others who pick your code up?

After we reached the hotel yesterday at 10PM, we met up with Shmuel Fomberg from Israel.pm who was in the lobby. He provided us with a lot of information (we missed the get-together that day), maps and explanations with the locations of various places (hotel, leaning tower, where the Friends and Family meeting the next day is, etc.) and even offered some food. One awesome guy!

We tried to find a place open nearby but in the dark, near a stretch of main road, it all looks like places to get mugged/gang-raped. We decided to stay in where I could practice my lecture one more time before tomorrow. Considering how nervous I was, it was a good idea! After practicing the lecture one last time, I noticed that my battery is almost done so I reached for my power supply and found the socket here is incompatible. Panic ensued.

As I was sitting in Jonathan Worthington's talk about Perl 6 signatures this morning, it struck me how easy it was to read the code he was showing. The intent was always very clear, it was short and to the point, and just made sense.

But then I looked closer, and there were a lot of sigils, *, := and so on, and I could not see myself writing this. Now the fact that I have never actually written any Perl 6 might explain that ;--) I will see what the learning curve is when I start using Perl 6 for good.

Still, it looks to me like the necessary complexity of code is pushed into a compact and for me quite overwhelming syntax. Which is probably as good a place as any to put it.

It's still quite striking though that Perl 6 might turn out to be a language that is easier to read than to write. Some might say that this makes it the exact opposite of Perl 5!

Recently there were cries in the office of:

oh noes! $thingy, which we rely on but don’t control, no longer has a hard-coded, specific record upon which we rely for one of our application tests

Miraculously I had a free slot in my calendar, donned my cape, took off my horn-rimmed glasses and wore my underpant outside my jeans:

I’ll have a look at that for you guys!

Buried Deeply … Somewhere

It turns out that our test was distanced from the problematic remote call by at least one intermediate “helper” module:

our_test.t:

# ...
use Test::OurApp::Data;

# ...
my $thing = Test::OurApp::Data
    ->get_thingy_from_xml( $file );

Test/OurApp/Data.pm:

My second morning at YAPC::EU::2010 wasn't very productive. I went to one presentation, and got sick during the coffee break (something wrong with the breakfast, I would say). I went to the bedroom to rest, and got back during the afternoon.

The only talk I've watched was Graphic visualization - there is a life after GD and GD::Graph‎. Uwe was kind of nervous as it was his first English talk. That was easy to notice, as he even did not remember correctly the slide order. That's the speakers life.

Regarding content, he talked mostly on four technologies: GD and GD::Graph, Chart::Clicker, GraphViz and SVG. While he shown some examples of what can be done with each one of these modules I missed some kind of conclusion. A table associating objectives with the tools available for that task would be enough (as the presented modules are not equivalent).

This statement is on my Ohloh page for ClamTk:

"Across all Perl projects on Ohloh, 28% of all source code lines are comments. For ClamTk, this figure is only 14%.

This lack of comments puts ClamTk among the lowest one-third of all Perl projects on Ohloh."

Now when I first saw that, the figure was probably 8%. Ohloh has since shamed me into obsessively adding more. I'm somewhat embarrased about the low number of comments - especially after developing this for 6+ years - but the 28% figure stuns me. In a good way, of course. As an amateur, it's probably just my lack of experience and limited exposure to other code bases.

Here is an example of what a module can look like. In this case it only has a simple method that greets the user:

class Greeter;

method greet($name = 'world') {
   say "hello $name";
}

Now to use the module we can write something like:

BEGIN { @*INC.push('Greeter/lib') }

use Greeter;
my $x = Greeter.new;
$x.greet('rakudo');

The only tricky part is actually the push in the BEGIN block, to add your lib directory. Of course running this is as simple as:

$ ./perl6 greeter.p6 
hello rakudo

I need to do two things:

• Think of a better name than Test::Class::Profile
• Write it

The problem: running several thousand tests in one Test::Class process can swallow up a lot of information. I want to instrument Test::Class to optionally capture that information to assist debugging/management of your test suite. I need to write code which will:

• Tell you what classes ran and in which order
• How long did each class take to run
• How long does each test control method take to run
• Overhead on test methods from test control methods

The last one is rather interesting. Consider a test class with a setup method which takes 8 seconds to run. If it has 10 test methods, than that's an extra 80 seconds of overhead you've added. If you can get the setup method to run in 4 seconds, you can save 40 seconds on the test class. Do this with just a few test classes and you're talking about serious performance savings.

What other information would you want in something like this? How should the information be recorded/presented?