Plaggnet YAPC::EU

Happy Cat sez, "I gots a plan. Momz wantz booze, she getz booze. Fill teh bukkitz with waterz." And teh doodz fillded dem full.

He sed to teh doodz, "Teyk som waters to teh party dood." Tehy didz it. Teh party dood was liek, "Tihs iz teh booze! I lieks tihs booze! Where didz tihs come?" (Teh doodz who broughted teh booze knowd.) Teh party dood wentz to teh pplz gettin hitchded and sed, "WTF!? Most doodz gives teh gud booze first, and tehn crappy booze when pplz iz too drunk to care. But tihs booze pwns!"

Happy Cat didded this, teh first of hiz signz, in Cana inz Galilee, and revealded hiz Pwnage; and Happy Cat's doodz beleved in him. — John 2:7-11

Today I've had some fairly good progress with Hitomi, the XML templater. Using the draft grammar moritz++ helped me build, I created a class that takes an XML document and translates it to a stream of events. This makes about half of the tests that I ported from Genshi last time pass; the other half of that test file concern tag soup input — I think I'll punt that one for now, and go for the lower hanging fruit: the classes Template and MarkupTemplate. With those, it should be possible to actually, you know, do some templating.

I'm getting more and more familiar with the original Python code, and starting to have some significant respect for the Genshi code base. It's simply a very well-thought-out piece of software. I can see why people like it. The project doesn't seem terribly active, unfortunately, so sometimes questions from me and others go unanswered on the #python-genshi IRC channel.

Is Hitomi a good name? jnthn++ pointed out today that it sounded very similar to "hit on me", and I find myself constantly writing either "Hitmo" or "Himoti". Then again, I kinda like that it means (or so I've read) "doubly beautiful", and I don't have a better suggestion at the moment.

Another thing that has been going on in the past week is that viklund++ said, almost in passing, that it'd be nice to have an XPath engine for Match objects. I thought it was a great idea, and incubated the project "Grampa" (short for "grammar paths") on github. I've since made some good progress on it, and it's already slightly useful. Not to mention that I've learned a few new things about XPath and EBNF that I didn't know before. pmichaud++ helped me with some questions on the latter.

How does that tie into Web.pm? Well, it turns out that at least two of the subprojects of Web.pm would benefit from XPath searches: Hitomi, and Happle (our Hpricot clone). This suggests that Grampa should really be a Match front-end to an XPath query back-end, so that the back-end can then be reused in other projects. I've been implementing Grampa with this in mind.

Finally, since it's nearing the end of my original part of the grant, I've taken a fresh look at doc/PLAN and refined it a little. No major course corrections were needed, which feels comforting. I'll probably write some more about the status of the subprojects in next week's blog post.

Another thing I plan to do in the coming week is start on my Web.pm talk for YAPC::EU. I thought I'd write the talk in Perl 6 Pod, and then do various conversions to end up with a PDF. Since most of the toolchain for doing that doesn't exist yet, I thought I'd better start now. 哈哈

I wish to thank The Perl Foundation for sponsoring the Web.pm effort.

Posted by masak on perl6 at Fri, 03 Jul 2009 21:19:10 -0000 | Permalink

Posted at Fri, 03 Jul 2009 19:56:00 +0100 | Permalink

The Perl 6 design team met by phone on 27 May 2009. Larry, Allison, Patrick, Jerry, and chromatic attended.

Larry:

• changed the time function to return a Rat
• thinking about the traits that have been bothering Jonathan and others
• have some changes to check into the spec when I'm happy with them
• thinking about the primitives we use to define use
• breaks down into load and import
• thinking of establishing compile-time keywords for both concepts
• intended so that I can import from anything acting like a module -- an inlined role, for example
• otherwise trying to keep up with the flow of IRC

Allison:

• working on the Parrot book
• changed its focus to a small, 100-page PIR book from a monolithic Parrot book
• the intent is to get something out for YAPC and OSCON
• will send out a draft for review
• will merge my changes into the repo later this week

Patrick:

• released Rakudo #17 last week
• was easy again
• 875 more tests since #16, so we pass 68% of the spectest suite
• finished implementing the root_new opcode in Parrot
• cleans up a lot of the PMCProxy issues from moving Rakudo to its own HLL
• gained half of the speed we lost from the migration
• we'll get more back as we update more places that need it
• NQP never expected anything like that
• I have to rework some it and PCT
• haven't quite figured out how to do that
• refactoring use and import in Rakudo
• the current implementation doesn't work
• will hopefully match with what Larry's putting in the spec
• it seems like the logical way to do things
• updated Rakudo's ROADMAP in docs/ROADMAP
• gives us an idea of dependencies and next tasks
• may also help people understand what blocks features they want

Jerry:

• the bonding period has ended for GSoC
• time for students to start coding
• everyone on the Perl 6 and Parrot projects is ready

c:

• fixed some memory leaks in Parrot and Rakudo
• there are still some in Rakudo, but the web examples should be able to live longer
• did more profiling
• think NFG is important for Parrot in the near term
• have some documentation to write
• have been editing the Parrot book

Patrick:

• how's the command line for Rakudo coming?

Jerry:

• I expect to get back to that

Patrick:

• the "parens build captures" decision surprised me
• what's the rationale?
• I really liked "parens mean grouping"
• maybe I haven't reconfigured my worldview yet, but it feels messy

Larry:

• when used in an argument list, it has the same effect as a capture

Patrick:

• it even works when they're used as a term

Larry:

• they still mean that you have to look at what you're binding to and decide
• am I binding this to a scalar or to an array?
• (1, 2, 3) bound to an array...

Patrick:

• I'm going to have to think about that
• the zip operator in slice context....
• is this three or one positional arguments? zip($a,$b,$c)
• how many positional arguments are in this case? zip($a,$b,$c;$d)

Larry:

• one slice
• you wouldn't want to write that

Patrick:

• what in the arg list distinguishes the use of the semicolon versus the comma
• inside of an argument list we have to recognize a variety of syntactic things
• comma, semicolon, colon, array or hash sigil, named parameters
• seems like captures need more information than just positional
• they need to store metadata about positional arguments
• I like the syntactic stuff showing up in the argument list
• but I don't want to handle them in three different ways

Larry:

• I'll have to think about that

Patrick:

• haven't figured out how to deal with slice context either

Larry:

• might say that the presence of a semicolon implies the presence of other parens
• the comma implies...
• that might be more consistent binding for a top-level list

Patrick:

• I half expected that answer
• I can see the semicolon as just a lower precedence grouping operator

Larry:

• otherwise you have a semicolon that's just not there in every other argument list

Patrick:

• assuming that, the other commas form an argument list through the infix semicolon
• an array in there means Capture of Capture of Capture
• we were about to refactor List and Array in Rakudo anyway
• the question is "Do we really have a List type now?"
• Rakudo assumes that

Larry:

• if we can unify args list with List, that's probably healthy

Patrick:

• I'd really like that
• that makes things a lot cleaner
• infix comma and infix semis now just create arglists

Larry:

• or Lists
• if you define List as "something that has out of band metadata"

Patrick:

• any more decisions that you can make about that will help our implementation
• I probably won't get around to that this week

Larry:

• we make syntactic distinctions
• we know that this is an arg list
• we treat pairs as named arguments
• we don't do that if we know it's not an argument list
• it stays positional
• that's the only distinction between an arg list and a List
• purely syntactic

Patrick:

• to summarize
• zip($a, $b, $c) has three positional arguments
• zip($a, $b, $c; $d) has two, the first of which is itself a list/capture

Posted by chromatic on journal at Thu, 02 Jul 2009 23:03:51 -0000 | Permalink

Thanks again to the organizers, presenters and attendees. I had a great time and am already looking forward to next year.

Posted by bradoaks on journal at Wed, 01 Jul 2009 20:50:16 -0000 | Permalink

Autodie 2.00 released
This weekend the long awaited autodie 2.00 for Perl was released to the CPAN, which was almost immediately replaced by 2.02, which fixes some oopsed tests and which adds a couple more features to give us a really sweet experience. This blog entry assumes you're using 2.02.

Observant viewers will notice that the major version number has changed. I've taken the great leap from 1.999 to 2.00. Clearly, something is different, and you might be wondering what.

Well, autodie 2.0 now supports a hinting interface for user-defined subroutines. Put simply, if you have a user-defined subroutine that does something funny to signify failure, you can now tell autodie about that. Once it knows, it can Do The Right Thing when checking your subroutine. You can even put the hints into the same file as those subs, and if someone is using autodie 2.00, it will find the hints and use them.

This may not sound very exciting, but it is. It means that a lot of really ugly error-checking code, both on the CPAN and the DarkPAN, can go away. Lexically. Still not convinced this will change your life? Let's look a little more closely; trust me, you'll like it.

Let's pretend you're working on a piece of legacy code. For some reason, the people who wrote this code decided the best way to signal errors is by returning the list (undef, "Error message"). I don't know why, but I've seen this anti-pattern emerge independently in three 100k+ line projects I've been involved in.

sub some_sub {
    if ( not batteries_full() ) {
        return ( undef, "insufficient energy" );
    }

    if ( not coin_inserted() ) {
        return ( undef, "insufficient credit" );
    }

    my @results = some_calculation();

    return @results;
}

If you want to check to see if some_sub() returns an error, you need to capture its return values, look at the first one to see if it's undefined, and if it's not, use the second one as your error. At least, that's what you're supposed to do.

What actually happens is most developers decide that's way too hard, and don't bother checking for errors. Then one day, the batteries on your doomsday-asteroid-destroying-satellite go flat, nobody notices, and through an ironic twist of fate you're left as the last known human survivor, and there are zombie hordes and walking killer plants outside.

So, how can autodie help us? Well, before version 2.00, it couldn't. But now, with autodie::hints, it can! We can give autodie hints about how the return values are checked. They look like this:

use autodie::hints;

autodie::hints->set_hints_for(
    'Some::Package::some_sub' => {
        scalar => sub { 1 },
        list   => sub { @_ == 2 and not defined $_[0] },
    },
);

Our hints here are simple subroutines. If they return true, our subroutine has failed. If they return false, it's executed successfully. Notice that our scalar hint always returns true. That's because we consider any call of our subroutine in scalar context to be a mistake. It's returning a list of values, and you should be checking that list.

Once we've set our hints, we can then use autodie to automatically check if we're successful:

use Some::Module qw(some_sub);

sub target_asteroid {

    use autodie qw( ! some_sub );

    # autodie has lexical scope, so only calls to some_sub inside
    # the target_asteroid subroutine are affected.

    my @results = some_sub();     # Succeeds or dies
}

sub target_ufo {
    my @results = some_sub();

    # autodie is out of lexical scope, so we have to manually
    # process @results here.
}

If you're wondering what that exclamation mark means, it means "insist on hints", and is a new piece of syntax with autodie 2.00. If for any reason autodie can't find the hints for some_sub, our code won't compile. That's a very good thing, and avoids us having a false sense of security if we use autodie on an unhinted sub.

However the error messages from autodie aren't really that useful. They're going to be things like "Can't some_sub() at space_defense.pl line 53". There's a noticable lack of explanation as to why some_sub() failed.

Luckily, since the way early versions of autodie, we've been able to register message handlers. And with the new features in autodie 2.02, we can produce very rich messages. Let's see how!

use autodie::exception;

autodie::exception->register(
    'Some::Module::some_sub' => sub {
        my ($error) = @_;

        if ($error->context eq "scalar") {
             return "some_sub() can't be called in a scalar context";
        }

        # $error->return gives a list of everything our failed sub
        # returned.  We know this particular sub puts the error
        # message the second argument (index 1).

        my $error_msg = $error->return->[1];

        return "some_sub() failed: $error_msg";
    }
);

Now, whenever some_sub() fails, it'll print a genuinely useful message, like "some_sub() failed: Insufficient energy at space_defense.pl line 53". Yes, autodie automatically adds the file and line number for you. Nice!

But wait, there's more! We don't want to see this sort of code floating around in your programs. You may be dealing with other people's modules that you can't modify, so we can't hide all this configuration in there. So, we can write our own pragma that contains all this info. Here's the full code for a theoretical my::autodie pragma, and is the exact same code used by the t/blog_hints.t file in autodie's test suite.

package my::autodie;
use strict;
use warnings;

use base qw(autodie);
use autodie::exception;
use autodie::hints;

autodie::hints->set_hints_for(
    'Some::Module::some_sub' => {
        scalar => sub { 1 },
        list   => sub { @_ == 2 and not defined $_[0] }
    },
);

autodie::exception->register(
    'Some::Module::some_sub' => sub {
        my ($E) = @_;

        if ($E->context eq "scalar") {
            return "some_sub() can't be called in scalar context";
        }

        my $error = $E->return->[1];

        return "some_sub() failed: $error";
    }
);

1;

It works exactly the same as regular autodie, except it also knows how to handle some_sub(), and display good looking error messages. Here's how we'd use it:

use Some::Module qw(some_sub);
use my::autodie qw( ! some_sub );

my @results = some_sub();  # Succeeds or dies with a useful error!

There's a lot more you can do with autodie, and if you want to learn more, I'd suggest coming to my talk at OSCON or YAPC::EU, where I'll be covering all this and more, with a distinctive Star Trek twist. ;)

Posted by pjf on journal at Wed, 01 Jul 2009 05:45:12 -0000 | Permalink

At the beginning of June the Vienna.pm organization generously committed to funding me for 1-day-per-week of Rakudo effort, but because of the Rakudo release, Parrot Virtual Machine Workshop, YAPC::NA, and a short vacation, today is the first day that I had available to really dedicate to the task. In fact, to catch things up a bit I plan to do another Rakudo day tomorrow or Thursday.

Here's what I accomplished for today's Vienna.pm-funded Rakudo day.

The biggest task I tackled for the Rakudo day was to be able to write operators in the setting (Perl 6) instead of PIR (RT #66826). In fact, I had actually done most of this last week during the YAPC::NA hackathon day, but interruptions then and a few annoying Parrot bugs kept me from marking the task as completely accomplished then. What this means is that we can now begin defining operators directly in Perl 6 code (perhaps with some inlined PIR), which moritz++ has already been exercising for infix:<...>, infix:<eqv>, and a few other operators. Over the next few weeks I expect we'll move even more operators out of PIR and into the setting.

The rest of today's Rakudo day was spent reviewing and cleaning up the RT queue; it had grown to over 400 tickets but by the end of the day Jonathan and I have shrunk it back down to 387. I think we collectively closed about 16 tickets today, and I responded with requests for clarification or updates on several more. Here are some of the highlights:

RT #66060 noted a problem that the .uc method would fail on some strings where .lc worked. I tracked this down to a Parrot issue in its handling of Unicode strings when ICU wasn't present, and refactored the code to be a bit more robust there.

RT #66640 noted that the minmax operator wasn't implemented, so after some discussion about what it should do I added it to the setting (using the operator features mentioned above).

In RT #66624, the exception message coming back from not finding a substring within a string was particularly misleading; I adjusted .substr to provide a more useful error message.

For RT #66928 .WHAT would not work on some subs like &infix:<+>; this was because some of the builtin operators are still using Parrot's MultiSub PMC instead of the Perl6MultiSub PMC, and those didn't have a mapping to the type object. Eventually all of the operators will become Perl6MultiSub; in the meantime I set Parrot MultiSub PMCs to map to the Multi() type objects in the same manner that other Parrot PMC classes are mapped to Perl 6 types.

RT #66818 noted a problem with unwanted flattening of %*VM in a for statement; this was because the contents of %*VM were incorrectly bound to the Hash directly instead of going through a non-flattening reference (Perl6Scalar). Eventually I expect %*VM to be initialized in the setting, though, which will provide a more robust and direct solution to this problem.

In RT #66840 it was discovered that precedence errors in the ternary operator would cause Rakudo to issue an error message and exit completely, instead of throwing a catchable exception. I tracked this down to PGE's OPTable handling of the ternary operator, it was actually using "exit" when the error occurred (probably because it came from before Parrot's exception model was firmly in place). This was changed to throw an exception instead; the actual exception message needs a bit of work but I expect that will come from the much larger PGE refactoring that will be done as part of the Hague grant.

Lastly, today I spent a good bit of time discussing Rakudo and Parrot build/install issues with Allison, and I think we have basic agreement on the changes we'll be making in order to get those working. Hopefully we can get all of that done in time for the July release.

So, that's my first Vienna.pm Rakudo day -- lots of little pestering bug fixes, and a key bit of infrastructure to fully enable writing the builtin operators in Perl 6. Later this week I plan to do a long-needed refactor of container handling in Rakudo, and maybe to get a more complete implementation of BEGIN blocks (which we massively cheat on at the moment).

Thanks again to Vienna.pm for sponsoring this work.

Pm

Posted by pmichaud on perl6 at Wed, 01 Jul 2009 04:08:20 -0000 | Permalink

This is one of those, hmm, seems possible, wonder why no one has done it things.

The stock xterm that comes with X has emulation built in for the old Tektronix 4014 graphics terminal in addition to DEC220 emulation.

The Tektronix 4014 is a Vectrex like thing where lines are drawn directly onto the screen rather than being broken up into pixels and the entire surface of the display scanned. It also used a "storage tube" strategy where the beam detects what's already lit and re-energizes it, apparently mixing scanning with direct vector drawing. But that's beside the point of this. I've actually seen some of these beasts at UVA's Unix lab. The interesting bit is they draw vector graphics, xterm emulates them, and this works over bloody telnet.

http://vt100.net/tektronix/4014-um/4014-um.pdf is the best resource I could find -- the original manual. Other example programs sucked. But even that manual was tricky.

print unpack "u", q{M&UL_,SAH&PP=?U]O7QUW7W=;'7];;UL=>U=_4QU_4V]3'7M7<U,=?TMO1QU_22V]/'7-'<T\=?T-O 0QUO0V]`};

... my new JAPH. Requires a real xterm (probably) without GNU screen in the way. That was the 3rd thing I wrote.

$|=1;print chr(27),"[?38h",chr(29);while(1){print chr(32+rand 32),chr(96+rand 32),chr(32+rand 32),chr(64+rand 32);}

... demo program, shortened for Twitter. That was the 2nd thing I wrote.

use strict;
use warnings;
use IO::Handle;
STDOUT->autoflush(1);
print chr(27), "[?38h"; sleep 1;  # TEK mode from vt-whatever mode; this is an xterm/DEC escape sequence, not a TEK one
print chr(27), chr(12); sleep 1;  # clear screen
 
print chr(13+16);  # 13 plus some offset relating to shift+ctrl to get into graphics mode
 
while(1) {
    print chr(32 + int rand 32), chr(96 + int rand 32), # the 5 high bits of Y+32, 5 low bits of Y + 96
          chr(32 + int rand 32), chr(64 + int rand 32); # the 5 high bits of X+32, 5 low bits of X+64
    sleep 1;
}

The first program in its final form, which is just a long version of the above.

The manual explained that to get into Tek graphics mode, push shift+control+M with the thing in loopback mode. I have no idea what ASCII code a Tektronix terminal sends when you do that so that was a little useless and originally I misread the table as just being a control-M. Through trial and error, I established it as being ord("^M")+16. Some control codes are escape (chr(27)) plus another character; others are just a control character. Tektronix terminals also have a character mode which itself has many options including up to 133 char display. I haven't played with any of that yet except that it operates as a dumb terminal with an addressable cursor (movable cursor) when its not in graphics mode, and text and graphics can be mixed.

The while loop needs explanation. To draw lines, four characters of certain ranges are sent. The X and Y high bits

Send the Y high byte (ASCII value of 32-63 encoding the top 5 bits), the Y low byte (96-127 encoding the low 5 bits), the X high byte (32-63, again), then the X low byte (64-95). I guess when it sees that X low byte, it actually draws the line. It's possible to skip sending the high bits and only send the low bits in which case the high bits just stay zero. The JAPH program does that.

There's no "okay, this is a line draw!" code or escape sequence between the line data; the line data just goes in place of ASCII and gets interpreted as points. That three different character ranges are used to specify four different points is a bit tricky. The X-high and Y-high ranges are one and the same and the value gets set twice. X-low and Y-low are different ranges though.

When sending coordinates like this, it always draws a line from the last coordinate unless you just switched to graphics mode with a chr(29). Of course you can switch into graphics mode while in graphics mode, so to reposition the beam and start drawing a new, unattached line, send chr(29) and then the four bytes encoding the coordinates. Also, the coordinates are relative the top right of the screen. Try to figure that one out. While the X and Y values can encode up to 1024 positions, the Y resolution is only 768 (hey, completely standard resolution!) so it's possible to draw off of the top of the screen (cuz, you know, the coordinates are backwards and upsidedown).

Output and input do not happen at the same time, but there's an additional mode where the cursor becomes a crosshair and mouse clicks are sent with the mouse location are sent and can be polled. The real 4014 didn't have a mouse but instead had two knobs, not unlike an Etch-o-sketch. The text mode is of course an input mode.

What's next? Hmm, do the sinus scroller I meant to do for YAPC for presentation software? XTank clone that runs over telnet? First person 3D GUI for the MUD with wireframe orcs and elves?

-scott

Posted by scrottie on journal at Tue, 30 Jun 2009 18:44:02 -0000 | Permalink

Greetings, and welcome to the seventh YAPC::EU::2009 newsletter.

In this issue:

• current stats
• further sponsors
• send-a-newbie updates
• other things we're working on

Current Stats

We're now at 230 confirmed attendees.

Several people have registered to the different training courses (there are still some seats left) and the partner program currently has a group of 9 people (not counting the guides), and several inquiries from other interested people (yes, you can still register for the partner program).

It's going to be an amazing conference.

Further sponsors

To the ranks of Booking.com, logicLAB, SAPO, Eurotux, log, Caixa Mágica, Best Practical, FCUL, Active State, TAP, O'Reilly, Apress, Onyx Neon Press, $foo magazine, The Perl Review and o3 magazine, the following now also get on board:

• Shadowcat Systems - Not only is Shadowcat sponsoring YAPC::EU, they're also providing a free 1 day workshop in collaboration with EPO the day right after YAPC.

Send-a-newbie updates

All the candidates were asked to answer a set of questions in order to help the jury select the lucky ones who will be attending this YAPC::EU.

The answers were given and the jury is now working their way through them. We can tell you that some of the replies were really impressive.

The selected candidates should be announced pretty soon.

Send-a-Newbie is currently at 1,745 euros. You can still help.

What we're working on

We're working on several things. Here are some headlines:

• conference dinner - this year's conference dinner will be sponsored by Booking.com; we're taking care of the arrangements.
• coffee breaks - we're also working on these ones.
• conference proceedings - a number of speakers have written articles for the conference proceedings and we're now working on them.
• conference tshirts - we're working closely with a clothing company to make the conference tshirts.
• auction - this year we'll have two separate auctions: the silent one, with all the books, t-shirts and other cool things, and the live auction, with all the crazy stuff.
• several other things.

That's all for this newsletter, but you can count on further updates pretty soon.

Feel free to contact us at organizers@yapceurope2009.org for anything

conference related.

See you at the next newsletter,

the organizers

Posted by cog on journal at Tue, 30 Jun 2009 14:47:44 -0000 | Permalink

Posted at Tue, 30 Jun 2009 14:45:00 -0000 | Permalink

Posted at Tue, 30 Jun 2009 14:00:00 -0000 | Permalink

Posted at Tue, 30 Jun 2009 07:20:00 -0000 | Permalink

After another year of doing basically nothing with CPANTS, I think it is finally time to look for somebody to take over maintainership. I don't see any tuits to emerge in the next 3 months (thanks to two big, cool, all-perl jobs) to fix all the bugs that become more an more apparent, as CPANTS data is used by more and more third parties. Plus there are lots of interesting new projects (mostly Metabase) that could and should be considered.

As a first step, I moved the repo from google code (and svn) to github for easier collaboration. But to really move CPANTS forward, the switch to git is by far not enough...

So if you're interested in taking a very close look at the ugly parts of CPAN, or want to tweak the algorithm of the CPANTS game to make you finally show up on top, drop me a line and I'll either add you as co-maint (or even as full maintainer, if somebody wants to take over completely (which I'd prefer)).

I guess that we can keep the site hosted on the Vienna.pm server, unless somebody wants to move the site to their own machine. I could also give an inofficial short/long intro/tutorial at YAPC::Europe to help the new maintainers find their way round the code.

CPANTS consists of three components, two of which (M:C:Analyse & M:C:Site) are rather easy to understand, while M:C:ProcessCPAN is a bit more complex. It has no real tests and takes ages for a complete run - so it's quite a pain in the ass to fix bugs and implement new features (hm, bad advertising...).

So if you're interested in taking over (parts) of CPANTS, please comment below and/or drop me a line (domm AT cpan.org)

Posted by domm on journal at Mon, 29 Jun 2009 20:02:37 -0000 | Permalink

The YAPC::Europe conference will take place in Lisbon from the 3rd to the 5th August 2009. A fine array of speakers are scheduled for 4 tracks over the three days, with a sizeable handful of O'Reilly authors on the bill: Dave Cross, brian d foy, Damian Conway and, of course, Larry Wall.

If three days isn't enough for you, there are training courses before and after you can attend.

On the Thursday and Friday after the conference, Damian Conway, brian d foy and Mark Keating are hosting courses on New Features of Perl/Perl Best Practices, Mastering Perl and EPO Workshop, respectively.

And Dave Cross is running a two-day Introduction to Perl course for the two days prior to the conference. Newbies can start the weekend with no understanding of Perl and exit on Sunday evening with enough knowledge to enjoy the rest of the conference.

Indeed, Dave's course isn't the only conference feature to caters for Perl Rookies. Says Dave:

Send a Newbie.
"Another interesting experiment this year is Edmund von der Burg's 'Send-a-Newbie' programme. Edmund was concerned that there are usually very few young people at YAPC, so he decided to do something about it. People can donate money and Edmund (with a committee of trusted advisors) will allocate that money as grants which can be used by young people to pay to get to the conference. See http://www.send-a-newbie.com/ for more details."

What is this?
We want to cover the costs for young Perl programmers to attend the 2009 European conference in Portugal, funded by donations from individuals in the Perl community. Attending YAPC::EU is a great way to get to know others in the Perl community and we don't want anyone to be excluded.

On top of that, O'Reilly's very own Josette Garcia will be attending the conference, which is enough to make any event complete.

Posted at Mon, 29 Jun 2009 14:28:00 +0100 | Permalink

Posted at Mon, 29 Jun 2009 11:36:00 -0000 | Permalink

Posted at Mon, 29 Jun 2009 07:16:12 -0400 | Permalink

*** Candybar (~u38625503@s133948615.onlinehome.us) has joined channel #yapc
<Candybar> Hi... I hear some folks are chatting about YAPC::NA::2010 in Columbus
*** karen (~karen@pool-71-162-10-245.pitbpa.fios.verizon.net) has joined channel #yapc
<cwest> that did happen
> I think after chatting about it, they said "yes".
> isn't that another steel town though?
> do we really need two steel towns, back to back?
<rjbs> Yes.
<rjbs> Bethlehem 2011
<Yaakov> Candybar: Howdy!
<Yaakov> Candybar: People are excited about Columbus, as is usual after a successful YAPC the next YAPC is anticipated.
> hrm, maybe if I take passage as a crewmember on a steam ship I could afford YAPC::EU...
*** lando (~orlando@S0106001c10086ef3.vc.shawcable.net) has joined channel #yapc
<Yaakov> scrottie0: Stow away, its the cheapest.
<duaneb> as a first time attender of YAPC this year I'm looking forward to next years
<Yaakov> duaneb: Excellent.
<Candybar> I have already contacted the Bio Perl people
<Candybar> and they are very excited
<Yaakov> duaneb: Candybar is the crazy person^W^Worganizer.
<Candybar> here is our plan
<Candybar> two main threads
<Candybar> and a "misc" thread
<Candybar> bio perl thread
<Candybar> corporate perl thread
<Yaakov> Don't use threads!  fork()!
<Candybar> and misc things that kinda match
*** stash (~Adium@S0106001c100a7a61.vc.shawcable.net) has joined channel #yapc
<Candybar> I have already contacted the OpenSource club at OSU
> I was talking to the SNOBOL guys after this go.  Myself and someone else have both done SNOBOL talks now.  It would be interesting to
+see them come out and even give a short talk themselves.
> 20 minutes is a wonderful thing.
> or, more broadly, I think it would be good for the Perl community to be exposed to more related topics if they can be presented by
+experts.  not every talk has to be a Perl tech talk.
<Candybar> the OpenSource club has already reserved the architecture building
<Candybar> for free
<purl> for free are they mad?
> shoot, go recruit someone to give a robotics talk.
> is there an I2C module for Perl?
<Candybar> my "Corporate Perl" is along the lines of how perl is used in big business
> sorry, I'm stuck on that "misc" track you mentioned.
<Candybar> I am talking to Oracle to see if I can get them involved and as a sponser
> oraperl, w00t!
<Candybar> dude I still got 4.036 clients man
<Candybar> they use oraperl 7.3.2 clients
*** Signoff: karen (Quit: karen)
<Candybar> ok YAPC is a year away and the misc track will probibly become somthing else
<Candybar> it all depends on what talks get submitted
> I missed the last DEFCON but there are always network security tools that get written in Perl... think about looking over that
+schedule and asking a few of those speakers to come out and give their talk again.
*** khaos (~karen@pool-71-162-10-245.pitbpa.fios.verizon.net) has joined channel #yapc
*** Mode change "+o khaos" on channel #yapc by BinGOs
> YAPC is a wonderful thing but something isn't sitting right with me.  well, there's always something not sitting right with me.  and
+in this case, I think YAPC needs broaded horizons.  it's becoming too much of an echo chamber.
> and becoming too isolated.
> I should not be an example of someone doing something neat with Perl.  other people doing far more interesting things should be.
<khaos> Well at a YAPC around 50% of the attendees won't have been to one before
<Candybar> scrottie0: I would agree
<khaos> I'll have to wait for the survey responses to see what the stats are like for this one - but there were a lot of first time
+people there
<Candybar> but isn't that really what lighting talks are... people showing off cool things that end up being a talk later on
<khaos> Lightening talks are supposed to be that
> well, I wasn't refering to my lightning talk.
> but yes, lightning talks should be that.
> and various other things.  I was referring to the Vegas talk.
<khaos> but in the past few years they are become entertainment
<Candybar> ok here is what we have ...
<Candybar> we have a lot of corporations that need to see that perl is still used in business
> dunno.  I say we get Rocky Horror and pants the newbies.
<Candybar> we have a lot of students that use perl in the OSU biology department
*** Signoff: stash (Quit: Leaving.)
<Candybar> so that is two big hitters
*** stash (~Adium@S0106001c100a7a61.vc.shawcable.net) has joined channel #yapc
<Candybar> so that is two big hitters
*** stash (~Adium@S0106001c100a7a61.vc.shawcable.net) has joined channel #yapc
> and you have attendees that want to be excited about Perl.  but maintaining huge piles of legacy code ain't that.
> actually I almost put in a talk for maintaining huge piles of legacy code... which seems to be the defining characteristic of Perl in
+a large company.
> "How to Scale Your Big Ball of Mud Even Larger" or something like that.
<Candybar> **Wave** I get to maintain a big old warm pile of stinky "legacy code"
<Candybar> my unofficial title is "Perl Janitor"
> virtually everywhere.  it's not that companies have something against perl itself... they've come to hate the codebases, specifically
+the difficulty in extending them, that are written in Perl
<Candybar> I get to help clean up everyone piles of warm "code"
> they can't separate "rewrite" from "switch to <other language>" in their head.  no one wants a rewrite, but everyone wants to switch
+to Java|Ruby|Python|whatever
<Candybar> Ok so I know that Oracle uses perl.  I know Veritas uses perl.  I know that SUN (now Oracle) uses perl
<Candybar> and I have sales contacts in each one that I am working
> well, don't just worry about catering to your sponsors -- cater to your audiance.
<Yaakov> Candybar: I expect great things in Columbus.
> in fact, the way you're presenting this to me now, I'm nervous about the whole thing.
> I don't mind in principle of YAPC gets commercialized up a bit one go but if the content isn't geared towards me or anyone I know, I
+lack incentive to go.
<Candybar> the Columbus.PM bid was all about "involving" corporations in perl
<Yaakov> scrottie0: Another selling point!
<Candybar> the TPF decided that this was the direction that they wanted to try and go
<khaos> the theme for YAPC::EU this year is "Corporate Perl"
<khaos> and their program looks fine to me - as it is a good mix of things
> again, you've said a lot about what you're doing for your sponsors but not a thing about what you're doing for the attendees.  is this
+a free conference, like InteropNetworld?
<Candybar> I am not planning on "selling" perl out to anyone
<Yaakov> Candybar: I was thinking "Enterprise Perl" is a good way to go.
<Yaakov> scrottie0: Don't make Candybar cry you bastard.
<Yaakov> scrottie0: He's working one side at a time.
<Candybar> Sorry my 18 month old just threw her cheerios at me...  Back for a sec...
<Yaakov> Heh.
<Yaakov> She is also afraid you are selling out!
<purl> okay, Yaakov.
<Candybar> The message that I get all of the time from my Corporation is that perl is dead and java is the word
<Candybar> yet
<Candybar> they continue to purchase vendor applications written in perl
<Yaakov> Perl is the hidden hero.
<Candybar> they continue to use perl but "hide" it
<Candybar> exactly
> what corporations think matters.  what corporations can offer YAPC matters.  but I want to hear it out of your flapping pie hole
+feeder appendages that the people going to this and paying money to do so matter too.
<Yaakov> scrottie0: We are waiting for you to leave before revealing thesexy details of the attendee "special benefits".
<Candybar> here is what I don't want to do
<Candybar> I don't want to have T-Shirts that have Oracle or SUN spread all over them
> I don't care about that.
> the shirts already have sponsors on them.
<Candybar> I don't want to rename YAPC to Oracle World
> Java Mongers.  been there, done that.
<rGeoffrey> yippie, shirts that can be worn without extra advertising
> I hope youporn sponspors YAPC.
<Candybar> why not... lets ask em
<dngor> Has Mexico put in a bid for 2012?
<Yaakov> dngor: Amnesiac is an USAian now!
> Candybar, that's all tangent to what I was asking about -- yet again, do any of your plans revolve around bringing interesting content
+to the attendees?  or is this just Oracle's and Sun's job?
<rGeoffrey> 2012 should be extra special as we will never beyond the winter solstice that year
> your reasons listed for the two tracks you talked about had to do with the sponsor's wishes, not the betterment of the attendees.
> I wouldn't suppose that that's your only motive but you're not helping me dispel that myth either.
<Candybar> ok so I support over 300 perl programmers in my little corporation
<Candybar> I know tht this sounds crazy but I am their perl dude
<Candybar> I am planning this YAPC to cater to the corporation perl programmers in Columbus to get them excited about using perl more
<Candybar> the tracks are not set in stone but you might find the Bio Perl then more interesting
> okay, that's something.  but it still sounds to me a bit like a career fair, not a technical gathering.
<Candybar> actually it will be a career fair in a way
<Yaakov> People need jobs, a lot.
<Candybar> because I am working with the OSU office of student affairs
<Yaakov> It is currently very relevant.
<Candybar> and I want a perl class taught to seniors
<Candybar> with the understanding that right after graduation that they can attend and talk to recruiters
<Yaakov> yay!
<Yaakov> Candybar: Idea: One of the forks can be a "Practical Perl" fork.
<Candybar> that is interesting
<Yaakov> Enterprise Perl, Bio Perl, Practical Perl
<Candybar> because I already have a committment from my friend Mr Conway to come
> okay, so my Vegas talk shouldn't be an example of someone doing something exciting with Perl; doing maitenance with 299 other Perl
+programmers should be.
<Candybar> ok my kids are now screaming at me louder then scrottie0
<Candybar> I will be back sometime...
> give them icescream and a triple lattes and Mickey's for me.
<Candybar> take care and keep track of your thoughts
*** Signoff: Candybar (Quit: Leaving)

Posted by scrottie on journal at Sun, 28 Jun 2009 18:37:52 -0000 | Permalink

Posted at Sun, 28 Jun 2009 02:01:00 -0000 | Permalink

Posted at Fri, 26 Jun 2009 16:02:00 +0100 | Permalink

Posted at Fri, 26 Jun 2009 10:14:00 -0000 | Permalink

Posted by Sébastien Aperghis-Tramoni at Thu, 25 Jun 2009 20:01:38 -0000 | Permalink

Posted by Paul Fenwick at Thu, 25 Jun 2009 19:44:52 -0000 | Permalink

Posted by Alex Muntada at Thu, 25 Jun 2009 19:44:52 -0000 | Permalink

Posted by mpeters on journal at Thu, 25 Jun 2009 16:44:59 -0000 | Permalink

Somehow on a three day trip, I managed to do two double days. I'm not sure how that's physically possible.

Due to logistics, I didn't eat for 24 hours the first day. I had a light snack for breakfast, hopped on the plane, landed, met Beppu at the airport, hopped the 28X, walked to the hotel, took a cab to the arrival dinner, found we missed dinner (that's okay, we didn't pay, only wanted beer), had beer, stumbled upon a group of people including mst, drank until late... talk about drinking on an empty stomach.

I gave two talks. The second undid the good karma from the first. I'm a malcontent. I always want better. Sorry. But just because I'm a malcontent doesn't mean I'm an ingrate. Despite griping about which of my lightning talks they picked, I'm grateful for the chance to talk and for all the festivities provided for my amusement. Talks everyone! Awesome job! Yeah, the badges need to be double sided and have the nicks on them and coffee first thing in the morning is a really good idea because the little cafe upstairs cannot cope with hundreds of nerds in withdrawl who don't want to be up that time anyway, but I'm still impressed and grateful.

We had hand built rubber band powered airplanes launched into the main stadium. We saw traveling salesman solved in SQL and SQL do the Mandelbrot set. What else... I'm really sad I missed the SNOBOL talk.

Beppu and Awwaiid both talked. Beppu gave a lightning talk trying to introduce people to Coro and Squatting in 5 minutes. Awwaiid gave two talks, one on pop-up debugging back-door for CGI scripts that lets you inspect and change state and do a REPL and view the stack and then another on his HtmlUnit bindings.

The logic of Iron Man didn't convince me, but mst's sheer enthusiasm did. So I need to repost a hopefully less wearily written version of this elsewhere.

Like I grumped about, and like I've blogged about in the past, Perl programmers are obsessed with mucking about in Perl rather than *doing* things with Perl. I'm all for building tools to scale up your development and Perl is a fantastic language for that, but we have to, at some point, do something we these tools we've built -- something beyond just demo them. PHP spends very little time tooling up and goes straight for the kill with good results. I'm not saying it takes an idea tack on it, just that our lopsidedness here is revealing.

Posted by scrottie on journal at Thu, 25 Jun 2009 08:29:37 -0000 | Permalink

It is confirmed that YAPC::Asia will be on Sep 10-11, 2009 in Tokyo, Japan. (http://conferences.yapcasia.org/ya2009/)

We(PerlChina) are considering to host the beijing Perl Workshop on Sep 19 or 20(Sat or Sun) If there are enough interests from Y::A attendees.

Think about the Great Wall, Fobidden city and awesome Authentic Chinese food, If not Perl. :)

So If you are going to Y::A and also would like to visit china and attend the beijing perl workshop, reply this or email me qiang at perlchina dot org.

Posted by Qiang on journal at Wed, 24 Jun 2009 06:48:04 -0000 | Permalink

Posted at Tue, 23 Jun 2009 23:37:00 -0000 | Permalink

Posted at Sun, 21 Jun 2009 16:19:00 +0100 | Permalink

Putting the finishing touches on my YAPC::EU 2009 paper and at the last moment, decided to run a code snippet since I was trying to compare it to Ruby mixins:

package PracticalJoke;
use Moose;
with 'Bomb'   => { exclude => 'explode' },
     'Spouse' => { exclude => 'fuse' };

I should have written excludes and not exclude. That's a very easy mistake to make, but given that people might want to run my examples, it's embarrassing :)

Posted by Ovid on journal at Sun, 21 Jun 2009 13:17:18 -0000 | Permalink

Posted at Sun, 21 Jun 2009 03:45:00 +0900 | Permalink

Posted at Sat, 20 Jun 2009 15:48:00 -0000 | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by chromatic | Permalink

Posted by John Napiorkowski | Permalink

Posted by admin | Permalink

Posted by Bureau News | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by Renée Bäcker | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by waltman | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by pageman | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by Andy Lester | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by cass | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by Alias | Permalink

Posted by Renée Bäcker | Permalink

Posted by unknown | Permalink

Posted by Renée Bäcker | Permalink

Posted by David Moreno | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by pageman | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by pedro figueiredo | Permalink

Posted by unknown | Permalink

Posted by ruiseabra | Permalink

Posted by unknown | Permalink

Posted by gms | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by Ovid | Permalink

Posted by unknown | Permalink

Posted by Gábor Szabó | Permalink

Posted by pageman | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by hoanatwho | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by can.axis | Permalink

Posted by Cory Doctorow | Permalink

Posted by Alias | Permalink

Posted by unknown | Permalink

Posted by admin | Permalink

Posted by Mary Rotman | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by unknown | Permalink

Posted by Lech | Permalink