Thanks again to the organizers, presenters and attendees. I had a great time and am already looking forward to next year.
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.
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
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
For RT #66928
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
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
Greetings, and welcome to the seventh YAPC::EU::2009 newsletter.
In this issue:
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:
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:
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
In this issue:
More in the Wiki.
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)
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.
*** 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)