blogs.perl.org

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

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.

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.

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?

本文为个人翻译，仅作参考之用，一切以原文为准。

原文链接： Announce: Rakudo Star - a useful, usable, "early adopter" distribution of Perl 6

作者：pmichaud

我谨代表Rakudo以及Perl 6开发团队高兴地向各位宣布Rakudo Star ── 一个可用、实用Perl 6早期发行版已于2010年7月发布。该发行版的tar源码包可以从 http://github.com/rakudo/star/downloads 下载。

Rakudo Star 着重打造Perl 6的一个尝鲜版本。我们知道它仍然包含缺陷，也慢于其应有的速度,且未实现Perl 6语言标准中的部分高级特性，但是 Rakudo Perl 6 之现状恰说明或为其开发应用程序或将其作为一门新型编程语言来探究的可行性(和乐趣)。一系列的"Star"发行版将力使Perl 6更加接近程序员，扩展Perl 6代码基础，以及赢得最终用户对Perl 6语言本身及其Rakudo实现的额外反馈。

在Perl6的世界里，我们将语言("Perl 6")和语言的特定实现(例如"Rakudo Perl")加以区分，"Rakudo Star"发行版由Rakudo Perl 6编译器的#31发行版[1]，Parrot虚拟机2.6.0版[2]，各式模块，文档，以及其他从Perl 6社区收集起来的资源所共同构成。我们拟将Rakudo Star按月发布，同时也将不时地发布反映重大变更及缺陷修复的特别版本。

本Rakudo Star发行版所含部分Perl 6新酷特性：

• Perl 6语法（"grammar"）和正则表达式（"regexes"）
• 正式参数列表和签名（"signatures"）
• 元操作符
• 进阶类型（"gradual typing"）
• 强大的对象模型，包括角色（"roles"）和对象（"objects"）
• 惰性列表求值（"lazy list evaluation"）
• 多重分派（"multiple dispatch"）
• 智能匹配
• 边界（"junctions"）和自动线程化（"autothreading"）
• 操作符重载（目前所支持的形式有限）
• 内省（"introspection"）
• 柯里化（"currying"）
• 丰富的内置操作符、函数和类型
• 互动的"读取-求值-打印"循环（"read-evaluation-print loop, REPL"）
• 代码点（"codepoint"）级的Unicode支持
• 可恢复异常（"resumable exceptions"）

本Rakudo Star发行版无法正确处理部分Perl 6关键特性，将在后续版本中修正。这样我们便不会将Rakudo Star作为"Perl 6.0.0"或"1.0"版。上述特性包括：

• 嵌套包定义
• 二进制对象，原生类型，pack和unpack
• 指定类型的数组
• 宏
• state 变量
• 线程和并发
• 非代码点级别的Unicode字符串
• 前、后约束，以及其他phasers
• REPL中readline对Unicode输入的支持
• 正则表达式字符范围<[...]>中的反斜杠转义
• 非阻塞I/O
• Synopsis 9的大部分
• perl6doc和POD工具