Planet YAPC

Week 10 of Web.pm -- Genshi, Grampa and some docs (2009.07.03 16:19)

2009-07-03T21:19:10Z

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.

Bids for YAPC::EU::2010 - Pisa and Kiev!

2009-07-03T13:56:00-05:00

Organizing a conference is hard, let's go shopping! For the first time I'm officially helping, not just for the Italian Perl Workshop this year, but possibly for YAPC::EU::2010 too. I've been working with the perl.it guys on the proposal to host the European Perl Conference 2010 in Pisa. We ...

Reboot

2009-07-03T11:13:00-05:00

Last Monday, I and 6 or 7 others were laid off from OpenSourcery. I'd just given my first talk at YAPC, and I wasn't really expecting to find out that I didn't have a job anymore. Whoops! If anyone wants to hire an experienced Perl programmer, take a look at my resume. I'm going to try to fill most ...

Perl 6 Design Minutes for 27 May 2009 (2009.07.02 18:03)

2009-07-02T23:03:51Z

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 othershave some changes to check into the spec when I'm happy with themthinking about the primitives we use to define use breaks down into load and importthinking of establishing compile-time keywords for both conceptsintended so that I can import from anything acting like a module -- an inlined role, for exampleotherwise trying to keep up with the flow of IRC Allison: working on the Parrot bookchanged its focus to a small, 100-page PIR book from a monolithic Parrot bookthe intent is to get something out for YAPC and OSCONwill send out a draft for reviewwill merge my changes into the repo later this week Patrick: released Rakudo #17 last weekwas easy again875 more tests since #16, so we pass 68% of the spectest suitefinished implementing the root_new opcode in Parrotcleans up a lot of the PMCProxy issues from moving Rakudo to its own HLLgained half of the speed we lost from the migrationwe'll get more back as we update more places that need itNQP never expected anything like thatI have to rework some it and PCThaven't quite figured out how to do thatrefactoring use and import in Rakudothe current implementation doesn't workwill hopefully match with what Larry's putting in the specit seems like the logical way to do thingsupdated Rakudo's ROADMAP in docs/ROADMAP gives us an idea of dependencies and next tasksmay also help people understand what blocks features they want Jerry: the bonding period has ended for GSoCtime for students to start codingeveryone on the Perl 6 and Parrot projects is ready c: fixed some memory leaks in Parrot and Rakudothere are still some in Rakudo, but the web examples should be able to live longerdid more profilingthink NFG is important for Parrot in the near termhave some documentation to writehave 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 mewhat'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 decideam 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 thatthe 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 sliceyou wouldn't want to write that Patrick: what in the arg list distinguishes the use of the semicolon versus the commainside of an argument list we have to recognize a variety of syntactic thingscomma, semicolon, colon, array or hash sigil, named parametersseems like captures need more information than just positionalthey need to store metadata about positional argumentsI like the syntactic stuff showing up in the argument listbut 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 parensthe comma implies...that might be more consistent binding for a top-level list Patrick: I half expected that answerI 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 semicolonan array in there means Capture of Capture of Capturewe were about to refactor List and Array in Rakudo anywaythe 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 thatthat makes things a lot cleanerinfix comma and infix semis now just create arglists Larry: or Listsif you define List as "something that has out of band metadata" Patrick: any more decisions that you can make about that will help our implementationI probably won't get around to that this week Larry: we make syntactic distinctionswe know that this is an arg listwe treat pairs as named argumentswe don't do that if we know it's not an argument listit stays positionalthat's the only distinction between an arg list and a Listpurely 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

What Haskell did to my brain | slides from YAPC::NA 2009

2009-07-02T19:38:00Z

"Warming up to Modular Testing" slides available (2009.07.01 15:50)

2009-07-01T20:50:16Z

For those of you who attended my talk "Warming up to Modular Testing with Test::Class" at YAPC::NA in June, my slides are online:
http://www.slideshare.net/bradoaks/

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

Untitled

2009-07-01T15:00:00-05:00

Today's [Person I Wish I'd Known About As A Girl] : http://en.wikipedia.org/wiki/Emily_Roebling Otherwise, bummed to miss Concertino, but YAPC was mostly fabulous. Even the downsides made me pissed enough to go kick some [thing that needs kicking]. Am home and inspired to crank out the code ...

Autodie 2.00 released (2009.07.01 0:45)

2009-07-01T05:45:12Z

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. ;)

Rakudo day: operators in setting and lots of RT bugfixes (2009.06.30 23:08)

2009-07-01T04:08:20Z

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.

Pair Programming with a Customer. EXTREME.

2009-06-30T18:53:00-05:00

The week before YAPC was terrible. First my AC went out. That’s a drag in Texas. Because the AC was out, my apartment got really hot, I couldn’t sleep, and then the mantle fell off the wall. That was crazy. Then I found out that I purchased a plane ticket to Raleigh, NC for a family reunion ...

Playing with Tektronix emulation for vector graphics! (2009.06.30 13:44)

2009-06-30T18:44:02Z

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

YAPC::EU::2009 Newsletter #7 - Stats, sponsors, newbies, etc (2009.06.30 9:47)

2009-06-30T14:47:44Z

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

#7 Newsletter: Current stats, Further Sponsors, Send-a-Newbie Updates

2009-06-30T12:39:00Z

In this issue: current stats - more than 230 registered atendees further sponsors - welcome, ShadowCat send-a-newbie updates - results should be available shortly More in the Wiki.

YAPC|10 in Pittsburgh

2009-06-29T23:43:00-05:00

Doug's First YAPC (Yet Another Perl Conference) proves to be an informative and fun experience with only a slight hint of debauchery.

CHI - Universal caching for Perl - YAPC 2009

2009-06-29T22:48:40Z

From anon-78616.

looking for CPANTS (co-) maintainers (2009.06.29 15:02)

2009-06-29T20:02:37Z

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)

YAPC::NA 2009 - Slides Posted

2009-06-29T19:26:40Z

So YAPC::NA is over. I’ve mostly recovered from the Moose Flu that seems to have circulated around at it. I’ve posted my slides for both XML::Toolkit and the EPO-EC talks. The first went “okay”, while I’d been doing a lot of work with ...

YAPB

2009-06-29T09:53:00-05:00

... offensive pissing me off "How to stop being a n00b" talk EVAR at YAPC and while I like the guy who gave it, and will not ream him out publicly (I gave him what-for in his survey response) I am now convinced that a talk on helping n00bs is something only someone who can remember being a n00b can do. I ...

YAPC::Europe - Lisbon, 3rd-5th August 2009

2009-06-29T08:28:00-05:00

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...

YAPC::Europe - Lisbon, 3rd-5th August 2009

2009-06-29T13:28:00Z

YAPC::EU timetable is brutal. It tells you the audience size for ...

2009-06-29T11:36:00Z

YAPC::EU timetable is brutal. It tells you the audience size for each talk. For one of mine, it's 3 ppl, including myself http://ur1.ca/6gc6.

We're looking for YAPC::Asia Tokyo 2009 sponsors!

2009-06-29T04:29:00Z

We're currently looking for sponsors for YAPC::Asia Tokyo 2009. YAPC::Asia is the world's largest YAPC, where Perl's most brilliant minds will converge from all over the world. This is your opportunity to increase visibility amongst these talents! Minimum suggested sponsorship fee starts at 50,000 yen. Please email info@perlassociation.org for more details.

Warming up to Modular Testing (YAPC::NA::2009)

2009-06-29T12:26:00+09:00

Warming up to Modular Testing (YAPC::NA::2009) Loading...Flash Player 9 (or above) is needed to view presentations.

sartak: Reflections on YAPC::NA 2009

2009-06-29T03:13:00Z

This year, YAPC::NA is running surveys on talks and courses, so I expect I'll learn more ways that the class could be improved. If you attended the class, please do not worry about offending Dave or me if you disliked something. ...

tmoertel: Shanks Blackwell: the first recipe inspired by #yapc ...

2009-06-29T03:12:25Z

Shanks Blackwell: the first recipe inspired by #yapc? http://www.flickr.com/photos/tmoertel/3669667768/in/photostream/

Wiki - PresentationSlides - YAPC|10 - Pittsburgh - June 22-24, 2009

2009-06-29T03:10:00Z

Wiki - PresentationSlides - YAPC|10 - Pittsburgh - June 22-24, 2009...

YAPC ...

2009-06-28T20:16:00-05:00

http://www.flickr.com/photos/85201403@N00/3664390382/in/set-72157620475426891/>/a> Myself, Awwaiid, and Beppu. Beppu is in the green shirt just to my right. Awwaiid is on the far left of the photo in the white shirt. None of us knew we were being photographed. YAPC... my talk went very well ...

Convo with YAPC2010 organizer: it's all about Sun, Oracle (2009.06.28 13:37)

2009-06-28T18:37:52Z

*** 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)

Perl in the Time of Social Networks delivered in Pittsburgh, PA

2009-06-27T21:01:00-05:00

I attended YAPC|10 during this past week. The overall experience was quite particular, with ups and downs, but after all I made it back in one piece. I rode a Greyhound bus on my crusade of saving a few bucks. I always had issues with buses, when I was a child I used to go from Celaya to Mexico ...

YAPC aftermath: perl5 4lyfe

2009-06-28T10:42:00+09:00

YAPC aftermath: perl5 4lyfe. Well, YAPC::NA was awesome as always. ... YAPC aftermath: perl5 4lyfe. Well, YAPC::NA was awesome as always.

Cool new-to-me stuff from the past few whiles

2009-06-27T15:14:00-05:00

... It's got plenty of features for the geek crowd, and is designed with collaboration in mind. I'm still getting used to it, but I've already moved my to-do list over with great rejoicing. Thanks to mikegrb for attending YAPC and telling me about this. GitHub (github.com): I am not a programmer. Well ...

tmoertel: The finish line! My #yapc host duties are now complete ...

2009-06-27T01:05:08Z

The finish line! My #yapc host duties are now complete. Twas a blast, but also a marathon: long days and little sleep. Now: martini time!