February 2010 Archives

The call for papers for YAPC::NA 2010 has been officially announced. This year's theme will be "Modern Perl".

With a planned four parallel tracks each day, there are ample open slots for talks, so be sure to submit yours today.

YAPC::NA 2010 Update

The YAPC::NA 2010 website has been up for a while, but it is now officially integrated with Act. Be sure to visit soon, create an account if you don't already have one, and start getting ready for the conference.

Remember that the conference is June 21st through 23rd 2010 at Ohio State University. Registration will be $100 ($90 early-bird), which day-passes available.

David Mitchell has submitted a grant proposal, which if accepted would make use of a portion of the funding generously provided to TPF by Booking.com.

Before the Board votes on this proposal we would like to get feedback and endorsements from the Perl community. Please leave feedback in the comments or send email with your comments to karen at perlfoundation.org.

Grant Title: Fixing perl5 core bugs

Name: David Mitchell

Amount Requested: $25,000


Recently, booking.com donated $50K for the "further development and
maintenance of the Perl programming language". I would like part of that
money to to be used to fund me for approximately six months to devote 50%
of my time fixing "hard" core perl5 bugs.

Benefits to the Perl Community

There are currently approximately 1200 open and 300 new bug reports in the
perl5 bug queue. Although some of these are of the "5.003_08 does not
build on platform X" variety, many are current: for example, almost 500 of
them were created after the release of 5.10.0. As the perl core has become
more and more gnarly, and the pool of experienced but active core hackers
has declined, these bugs are just piling up and not getting fixed,
especially the hard ones. With this funding, I would would be able to
devote serious time and effort to making a dent in this queue.

Note that unlike many large open source projects, perl has no paid
developers devoted to bug fixing.


Unusually for a TPF grant, there are not clear-cut deliverables for this
project. I intend to devote 500 hours of my time over the next six months
fixing perl core bugs. The net result will be a list of bug numbers that
have been diagnosed, and (hopefully) fixed. Because it's impossible to
predict in advance how difficult a bug is going to be to diagnose and fix
(or indeed whether it is even fixable), I can't commit in advance to a
fixed list of bugs that I will fix over the course of the grant. Nor is it
realistic to have a bounty per fixed bug; I would end up not getting
rewarded for time spent on difficult bugs, and conversely I would have a
strong incentive to cherry-pick easy bugs, defeating the purpose of the

Therefore, monitoring of my progress will become important (see below).

Project Details

I think this has been fully covered above.


Note that due to the length and scale of this project, it is suggested
that there be two project managers, who can spread the monitoring load
between them as they see fit.

Since this project is heavily based on hours worked and the monitoring
thereof, I would post a weekly summary on the p5p mailing list which
details, for each bug worked on that week, how many hours were spent on
diagnosis and fixes, plus any bug status changes. This frequent feedback
would allow the grant managers and active core developers (who will be
aware of any recent commits and other activity of mine) to observe whether
my claimed hours bear any relation to actual activity and results, and
thus allow early flagging of any concerns.

Missing two weekly reports in a row without prior notice would be grounds
for terminating the project.

Once per calendar month I would claim an amount equal to $50 x hours worked.
I would issue a report similar to the weekly ones, but summarizing the
whole month. The report would need to be signed off by one of the
project managers before I get paid. Note that this means I am paid
entirely in arrears.

At the time of my final claim, I would also produce a report summarising
the activity across the whole project period.

Also, (the "nuclear option"), I suggest that either of the project managers
be allowed, at any time, to inform the board that in their opinion the
project is failing badly, and that the TPF board may then, after allowing
me to present my side of things, to vote whether to terminate the project
at that point (i.e. to not pay me for any hours worked after I was first
informed that a manager had "raised the alarm").

To ensure that at there are at least some visible results for the hours
spent, I would be required have closed at least one bug per 20 hours
before being able to claim money for those hours. (I would hope to close
more bugs than that, but by setting a low baseline, I'm not tying my
hands, while still allowing TPF to have something visible for publicity
purposes during the interim.)

Project Schedule

I am available to start work on this project immediately.

The project is expected to take six months. I am self-employed, which
allows me a good deal of flexibility. By promising approximately 50% of my
time, this gives me the ability to continue with my existing commitments
to other clients, while deferring seeking new clients. As such, the weekly
hours I devote to perl are likely to be highly variable, but hopefully
averaging out to about 20 hours per week. If for some reason I find that I
have spent less than 500 hours at the end of the six months, then I will
continue the project until until the 500 hours been spent, with the
proviso that that the TPF board are free to terminate the project at any
time after the six months. Conversely, if I manage to devote more than 20
hours per week, then my monthly payments will be accordingly larger, and
the project will terminate early (once the 500 hours are spent).

Note that it is currently my intention that the after six months I will
apply for a further $25K extension, although there is no obligation for me
to do so, nor for TPF to approve it.


I'm a freelance UNIX sysadmin and programmer living in the UK. I have been
using perl since 1993, and have been fixing core perl 5 bugs since 2001.
I have had commit rights since 2003 and I was pumpking for the 5.10.1 perl

In short, I am one of only a handful of active people who understand large
parts of the perl internals and who can thus fix "hard" bugs.

2010Q1 Grant Proposals

For this quarter TPF has three grant proposals that were not funded in 2009Q3 round and that will be discussed and voted again in this round, and four new grant proposals:

Please take some time to comment on these proposals. TPF Grants Committee is very interested in community feedback on these projects relevance. Please be polite.

perl core memory improvements


Jim Cromie


[hidden email]

Amount Requested:

How much is your project worth? $3000


Memory allocation enhancements in core (sv.c).

Perl's variable namespace model is very flexible, users can:

 - create vars, in any package, or in my scope, by naming them;
 - give them complex values: my $foo = [ 1, { a => 2}, 3 ];
 - share/assign/shallow-copy them: $main::bar = $foo;
 - crosslink or self ref them: $a[2] = [$a[2], $a[1]];
 - other hairy stuff

This user data is all built on-demand from an inventory of sv-parts which is kept on the interpreter's freelists (sv_root, PL_body_roots). These are refilled periodically by S_more_bodies, which gets-an-arena, slices it into sv-parts, and threads them onto the freelist.

This can result in user data spread across memory like a spiderweb in a corner; its hard to clean the corner without destroying the web. IOW, it makes memory reclaim "hard", and probably ineffective. As a result I think, perl core has never really seen the need/benefit to bother reclaiming arenas.

One important workload however could benefit; Storable::freeze() uses a ptr-table to track SVs that it has %seen, but its PTEs hang off the interpreter until process termination. For a long-running process, this is clearly suboptimal.

Enhancing Perl 6 Pattern Matching with Ideas from Snobol4 and Other Sources


Morris M. Siegel, Ph.D.


[hidden email]

Amount Requested:

$3000 (negotiable)

The substance of my proposed alternative pattern-matching specification has already been essentially worked out as a self-funded research project, as it were. I felt this project was of such importance that it was worthwhile giving myself a sort of sabbatical to develop it. It has taken rather longer than I originally anticipated, and my personal funds have dropped to an uncomfortably low level. I can no longer afford to keep concentrating my efforts on this project on an unfunded basis.

My grant request is intended to retroactively fund some of my past development, and as well to enable me to continue focusing my efforts on the project. (The main task remaining is to write it up carefully and precisely, but there are some aspects that still need to be thought out.) Without a grant I would have to relegate the project to my limited spare time, and by the time it would be done it could well be too late for serious consideration.

I selected the figure of $3000 since I understand it is the upper range of typical Perl Foundation grants. I think the merits of the project, plus its time requirement (past and future), would justify a larger sum if the money is available. In addition, a larger sum would enable me to spend more time on fleshing out those ideas that still need to be thought out.

Improve Dist::Zilla's Tests, Documentation, and Structure


Ricardo Signes


[ hidden email ]

Amount Requested:



Dist::Zilla is a tool that helps Perl programmers build distributions for the CPAN. It eliminates boilerplate, handles packaging, interfaces with changelogs and version control, improves prerequisite management, and generally makes it easier to be a CPAN author. This grant will fund work to make it easier for new users to adopt Dist::Zilla and for Dist::Zilla itself to be more easily extended, maintained, and understood.

CPAN reviews


Alexandr Ciornii ('chorny' on IRC and PAUSE).


[hidden email] (backup) [hidden email]

Amount Requested:



Many CPAN modules have good documentation, many have bad documentation. But there is no such thing as enough documentation. There are many good reviews, examples, descriptions outside CPAN. I propose to collect them and cataloguize.

I want to make a site with links to reviews of CPAN modules. In general this site should be community-moderated, community-edited and allow users adding links to do minimal work first and enhance later, i.e. use this site as a bookmarking service.

Perl Compiler

Name: Reini urban
Email: [hidden email]
Duration: Until March 2011
Amount Requested: € $1000 (just for motivation)


Fix most of the remaining perl compiler, i.e. B::C, B::CC, B::Bytecode bugs.

Improve documentation a bit.

Maintain the planned compiler.perl.org site.

NOTE: perl.org Request Tracker was down for about a week (hardware problems). As this happened in the last days of the call for grants period we are extending it till the end of the week (day 5).

The Perl Foundation is looking at giving some grants ranging from $500 to $3000 in February/March 2010.

In the past, we've supported Adam Kennedy's PPI, Strawberry Perl and Perl on a Stick, Nicholas Clark's work on Perl internals, Jouke Visser's pVoice, Chris Dolan on Perl::Critic and many others (just check http://www.perlfoundation.org/grants for more references).

You don't have to have a large, complex, or lengthy project. You don't even have to be a Perl master or guru. If you have a good idea and the means and ability to accomplish it, we want to hear from you!

Do you have something that could benefit the Perl community but just need that little extra help? Submit a grant proposal by January 31.

As a general rule, a properly formatted grant proposal is more likely to be approved if it meets the following criteria

  • It has widespread benefit to the Perl community or a large segment of it.
  • We have reasons to believe that you can accomplish your goals.
  • We can afford it (please, respect the limits or your proposal should be rejected immediately).

To submit a proposal see the guidelines at http://www.perlfoundation.org/how_to_write_a_proposal and TPF rules of operation at http://www.perlfoundation.org/rules_of_operation. Then send your proposal to [email protected] Note that proposals should be properly formatted accordingly with our POD template.

On February 1st, proposals will be made available publicly (on this blog) for public discussion, as it happened in the previous round. So, please make it clear in your proposal if it should not be public.

Note that accepted but not funded proposals in the previous round do not need to be re-submitted.

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

About this Archive

This page is an archive of entries from February 2010 listed from newest to oldest.

January 2010 is the previous archive.

March 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2