March 2014 Archives

The Grants Committee is pleased to announce the voting results of the March round.

The following grant is approved and funded:

The following grant is approved but not funded as specified in 3.4 of the Rules of Operation. This will be reconsidered in the next round according to 1.2 of the rules.

The following grant applications were rejected:

Tom Hukins has been assigned as a Grant Manager for the funded grant.

We would like to express gratitude for those who took time to give feedback on these proposals.

As a reminder, we will again call for grant proposals on May 1st.

Enroll your Amazon account in Amazon Smile, and The Perl Foundation will receive a donation of 0.5% of all qualifying purchases you make at
Yet Another Society

Jeffrey Ryan Thalhammer reported:

This past May, The Perl Foundation awarded a grant to fund development of a couple features in Pinto. Pinto is a robust tool for curating a private repository of CPAN modules, so you can build your application with the right modules every time. This is my fifth progress report on that work.

Pinto 0.0995 was just shipped to CPAN and it includes a merge command. At the moment, it is only capable of doing a fast-forward merge (that is, when the target stack hasn't changed since you last forked or merged it).

I still plan to support other types of merges, but I actually think fast-forward merging will cover the vast majority of scenarios. Most of the time, stacks are short-lived. You make a copy, upgrade some packages, and then build your app. If your tests fail, you probably throw the new stack away and stay with your current packages. If your tests pass, then you immediately merge the new stack back into the original.

This release also contains reset and revert commands that are similar (but not identical) to the same commands you find in git. All the new commands are experimental, so the interface and behavior are subject to change.

So I'm not calling the grant work "done" just yet. Once these new commands have been battle-tested a bit, then we'll see where things stand.

Dave Mitchell writes:

I spent about half my time last month continuing to work on fixing and refactoring the Perl_re_intuit_start() function, which is the main run-time optimisation facility in the regex engine.

My work so far was merged back into blead on 8th February; I've since done some more work which hasn't been pushed yet.

I also fixed a regression in maint-5.18 regarding whether a variable is seen in a regex that has a hash char class and an embedded newline, like


A side-effect of working on that led me to waste about 5 hours trying to get maint-5.18 to pass under clang/address-sanitiser. The failures appeared random, and bisecting showed that they were "fixed" in blead by a commit that should have made no difference; but cherry-picking that commit made the problem go away. It was also sensitive to re-compiles: touch, but don't change perl.h, and recompile, and the problem changed or went away. Eventually I decided it was probably a weird clang issue, and abandoned the effort.

The rest of my time was spent on a few miscellaneous issues, plus ploughing through my p5p mailbox.


5:10 RT #119125 /[#]/ and codeblocks in maint
35:14 RT#120692 Slow global pattern match with input from utf8
1:37 [perl #121230] process group kill on Win32 broken in 5.17.2
0:46 [perl #121336] valgrind errors in Perl_hv_iternext_flags
5:00 clang/asan weirdness on maint
1:00 fix locale.t spurious warning output
23:39 process p5p mailbox

72:26 Total (HH::MM)

4.0 weeks
72.4 total hours
18.1 average hours per week

As of 2014/02/28: since the beginning of the grant:

19.7 weeks
335.6 total hours
17.0 average hours per week

There are 64 hours left on the grant.

The Grants Committee got four grant proposals for this round. Before the Committee members vote, we would like to solicit feedback from the Perl community on these proposals.

Review the proposals below and please comment on each page. They are listed in the order in which they were received.

We have received the following grant application. Please leave feedback in the comments field by March 22nd, 2014.

Automated generation of DWIM Perl

  • Name:

    Gabor Szabo

  • Email:


  • Amount Requested:



DWIM Perl is a "batteries included" Perl distribution for Microsoft Windows and for Linux. On Windows it is based on Strawberry Perl, on Linux it is compiled from the source released by the Perl 5 Porters. Both versions include a few hundred additional modules from CPAN.

The grant will enable me to further work on it, and specifically to finish automating the release of new versions.

Benefits to the Perl Community

DWIM Perl can make it much easier and faster for beginners to get started using Perl. It is useful both for people who would like to program in Perl, and for people who "just" want to run existing scripts or applications.

DWIM Perl makes it much easier and faster to set up a server running a Perl-based application. For example on a $5/month VPS. This reduces the advantage other languages might have in the area of deployment.

DWIM Perl can be the foundation of a "Perl Cloud", where people can develop on either a Windows or Linux based machine, and then easily deploy to a cheap VPS that has the same version of Perl with the same set of CPAN modules.

The grant will allow me to cerate a tool for automated releases and semi-automated upgrade of the parts. This will allow me (or anyone else) to easily create a new, up-to-date release of DWIM Perl.

It will also make it easy to create similar "batteries included" Perl distributions for the needs of companies, or open source projects using Perl.


  • A script that given a configuration file can build a DWIM Perl distribution for Linux and for Windows.
  • Configuration files ready to build DWIM Perl for Linux using 5.18.2, and for Windows using Strawberry
  • A new release of DWIM Perl for Windows based on Strawberry Perl using a scripted generation.
  • A new version of DWIM Perl for Linux based on 5.18.2
  • DWIM Perl for Linux based on 5.19.X.
  • Bug reports or even patches to modules that don't install cleanly.
  • All the source will be placed on GitHub.

The Windows version will be an installation process. The Linux version will be a tar.gz file to be unzipped.

Project Details

In order to get started using Perl with any reasonable modernity, people need to find and install hundreds of CPAN modules. This is an additional obstacle to getting started with Perl. Not only can it take hours to install all the required modules, there is always a chance that the current version of some of the modules on CPAN do not install cleanly. Several important CPAN modules require additional, non-perl packages. Locating and installing them can be additional issue.

Having a Perl distribution with "batteries included" means that newbies can download, install, and run. A lot less friction in getting started with Perl.

Each DWIM Perl distribution will include

The Windows version will also include wxPerl and Padre.

The Linux version will include Starman.


On Linux, there is already a relatively good script, located at, but there are several modules that require external dependencies, that are not included.

In the Windows version, Strawberry already includes these "problematic" modules so the main thing that is missing is the automation.

For both versions the handling of the stable CPAN snapshot is missing.

  • Research how the CPAN snapshot should be handled: Options that should be checked are: Carton, Pinto
  • Do a "market research" asking people for lists of prerequisites they have in their Perl-based applications. Both open source and closed-source applications. This will provide valuable input as to what needs to be included in DWIM Perl.
  • Create a new release of both versions using a simple script, and with one module in the CPAN snapshot.

    The Linux script will be based on

  • Add tests that can be run post installation to verify the problematic modules work. (Mostly the ones that require external libraries.)

  • Write script to update the sh-bang lines of the perl scripts after relocation. (This might be submitted to p5p as well.)
  • Include DBD::mysql in Linux.
  • Include DBD::Pg in Linux.
  • Include POE in Linux.
  • Include PAR::Packer in Linux.
  • Include XML::Parser in Linux.

There will be several intermediate DWIM Perl releases, marking the finish of each inch-stone.

Project Schedule

I can start immediately after the grant is accepted on March 31, 2014. I expect the project to be done within 2-3 months.

Completeness Criteria

Assuming the evaluator has access to the right operating system (MS Windows or Linux) she will be able to run the build script and create a new version of DWIM Perl with minimal manual intervention.


I have created the DWIM Perl project in 2011, originally as a vehicle to distribute Padre, the Perl IDE on Windows. Later the Linux version was added in order make it easy to deploy Perl-based applications on Linux-based servers.

I have been using Perl since 1995 and teaching it since 2000. I am the original author of Padre, the Perl IDE. I am also the maintainer of a number of modules on CPAN

In addition, I run the Perl Weekly newsletter and the Perl Maven site.

We have received the following grant application. Please leave feedback in the comments field by March 22nd, 2014.

Perl::Lint - Yet Another Static Analyzer for Perl5

  • Name:

    Taiki Kawakami (@moznion)

  • Email:


  • Amount Requested:



This project aims to create a fast and flexible static analyzer for Perl5 that has compatibility with Perl::Critic, with the goal to be light and fast enough to allow near real-time check of Perl source code while you code (e.g. hook it in your editor)

Why do I fork Perl::Critic?

Currently Perl::Critic uses PPI to analyze perl source code, which is relatively slow. The processing time can be greatly shortened by about 30 times the current value by replacing PPI with Compiler::Lexer and Compiler::Parser, which are new tools created by Masaaki Goshima who authored PerlMotion.

Using these modules are the main ingredients to the speed up, but in my previous attempts introduce these changes to Perl::Critic, it has proven difficult to do this without changing the current codebase significantly thereby causing significant trouble for the current user base. It would especially affect the already-existing plugins for Perl::Critic.

Rather than breaking existing functionality, I propose to build a new tool that is feature-wise compatible to Perl::Critic, but with much faster processing speed.

Benefits to the Perl Community

While Perl::Critic is an extremely useful tool, we have seen many colleagues avoiding its use because of its slowness. Improving the execution speed of Perl::Critic would lower the barrier to use in your day-to-day hacking activities, thus also leading to a better quality code, and improved development efficiency. With a fast enough Perl::Critic, one might even be able to embedded in an editor for seamless and continuous checking as you write.


The new module which is compatible with Perl::Critic. And this module is much faster than Perl::Critic because it uses Compiler::Lexer and Compiler::Parser instead of PPI.

Project Details

This project aims to create a MUCH faster version of Perl::Critic, using Compiler::Lexer and Compiler::Parser

Compiler::Lexer and Compiler::Parser are tokenizer and parser for Perl5 written in C++, which offers unparalleled speed compare to pure-perl competitors used in PPI. They are used in projects such as PerlMotion which transpiles Perl5 code to Objective-C.

A real life example replacing PPI with Compiler::Lexer can be found in Perl::MinimumVersion and Perl::MinimumVersion::Fast . The former is implemented using PPI, and the latter uses Compiler::Lexer. A simple benchmark shows that Perl::MinimumVersion::Fast is about 33 times faster than Perl::MinimumVersion ( Applying this to Perl::Critic, one can expect at least an order of magnitude faster processing.

Therefore goal of this project is to create this much faster replacement while still keeping compatibility with Perl::Critic.


  • Analyze functions of Perl::Critic (half to one day)

    Extract items that Perl::Critic currently checks

  • Implement tokenizer (two or three weeks)

    Parse source code written in perl and divide to tokens by Compiler::Lexer and Compiler::Parser.

  • Implement code analyzer (two or three weeks)

    Analyze and evaluate tokens by checking with inspection rules

  • Implement a system to define inspection rules (one or half week)

    Implement a system to define inspection rules on this phase, as well as a basic set of rules that are frequently used (mostly ported from original Perl::Critic rules)

Project Schedule

Period: within two months When can I start: May 2014

Completeness Criteria

Pass all of tests for Perl::Critic, benchmark against Perl::Critic, and release the module to CPAN.


I am a software engineer and graduate student (majoring in high-performance computing and software engineering) in Japan. I'm experienced in systems development for about five years, and I have worked with perl for about 2 years. I have contributed to a few open source projects (mostly involving perl) and have released a few CPAN modules. Please refer to the following web sites for details:

I am also a member of Compiler::Lexer development team, so I know the inner implementation of these modules which are crucial for this project. I believe I can apply those skills to this project.


While the original proposal was written by Taiki Kawakami, Daisuke Maki was responsible for editing this proposal's English.

We have received the following grant application. Please leave feedback in the comments field by March 22nd, 2014.

Project Title

RPerl Test Suite Upgrade & Module::Compile Integration

  • Name:

    Name of proposer.

    William N. Braswell, Jr.

  • Email:

    Where we can contact you!


  • Amount Requested:

    How much is your project worth?



A short description.

Whether we want to admit it to ourselves or not, Perl is quite slow at many kinds of tasks, as shown by the popular Alioth Shootout Benchmarks:

RPerl is a compiler which converts low-magic Perl 5 source code into the equivalent Inline::C and Inline::CPP code, which is then compiled and can be linked back into high-magic Perl 5 code in place of the original slow pre-compiled pure-Perl. In other words, RPerl can help the low-magic parts of your program run up to 200x faster, WITHOUT breaking backward compatibility with existing high-magic Perl 5 and XS.

The next step of my involvement in RPerl development is to upgrade the RPerl test suite and determine if we should integrate Ingy's Module::Compile code. The RPerl test suite currently supports data type testing, and needs to be upgraded to support compilation of full Perl modules. Ingy's Module::Compile code may prove useful for RPerl, this needs to be investigated further and then implemented if found to be appropriate.

Benefits to the Perl Community

Why should the Perl Community grant this project?

The Perl Community has already put their money where their mouth is to support RPerl:

Not to put too fine a point on it, but the fact is that slowness and high-magic are a significant part of the reason why Perl has been in decline for the past decade:

Only an extremist would argue that significant performance improvements will be anything but a benefit to the Perl Community.

People like Matt Trout and Reini Urban and Daniel Dragan and BrowserUk and Ingy dotNet have been very helpful to me in the design and details of RPerl. Overall, I've had net positive support from the Perl community as a whole.

Under the guidance of TPF and Mark Keating, RPerl has now been successfully accepted into the Google Summer of Code 2014:


Quantifiable results e.g. "Improve X modules in ways Y and Z", "Write 3 articles for X website".

1. One or more new .t test suite files, with appendent .pm and .pl files to be tested

2. Module::Compile integration, or equivalent

Project Details

A more detailed description.

[ RPerl Test Suite ]

The RPerl test suite currently consists of 7 enabled .t test files:

Currently, RPerl's most advanced automated test file is built to control our manually-compiled sorting algorithm test application:

We need to create one or more additional .t test files to control the soon-to-be-large number of automatically-compiled test applications. I've already started working out the test strategy in some of the files:

[ Module::Compile ]

The Module::Compile software created by Ingy dotNet may be useful for RPerl's automated compilation process.

Currently I plan to move much of the functionality from the bin/rperl front-end to the module:

As part of this move, I should be able to determine if RPerl will benefit from Module::Compile. At that time I will either integrate Module::Compile into the RPerl compilation process, or I will choose some alternative method of achieving roughly equivalent functionality.


If your grant is going to take longer than a week it's useful to break down your project into small chunks. This helps everybody track of progress, and lets you see if your project schedule is practical!

Try and think in "inch-stones" rather than "mile-stones". Breaking down your grant into many small goals makes it harder to overlook difficulties, and easier to see progress as you complete your grant.

[ RPerl Test Suite ]

09_compile_print.t 10_compile_math.t 11_compile_conditionals.t 12_compile_loops.t 13_compile_sort.t TAP::Harness

[ Module::Compile ]

Move Functionality From To Create RPerl::pmc_compile() Determine If Module::Compile Will Work Integrate Module::Compile Into, Or Equivalent

Project Schedule

How long will the project take? When can you begin work?

I estimate the project will take between 1 to 2 months.

RPerl development is on-going, I am available to start immediately.

Completeness Criteria

Describe how your grant can be evaluated. For instance, code will be merged in Perl tree, or a module will be released to CPAN with the specified features, etc.

Upon completion, RPerl v1.0 will be released on Github (CPAN will come a little later):


Who are you? What makes you the best person to work on this project?

I'm the President of

I'm a repeat Perl entrepreneur:

I'm the CEO of Auto-Parallel Technologies, a Perl development startup: (new website coming soon!)

I've got an honors degree in Computer Science & Mathematics from Texas Tech University.

I'm also an avid Boy Scout leader and cane juggler with Circus Texas. (Not related to Perl!)

I instigated the creation of the Perl 11 movement, along with my co-conspirators Ingy dot Net and Reini Urban.

We have received the following grant application. Please leave feedback in the comments field by March 22nd, 2014.

JERL (Alien::Jerl) Perl5 running in the JVM

  • Name

    Michael Shomsky

  • Email:


  • Amount Requested:

    How much is your project worth? $ ~3000 (US)

  • Note:

    The project is in maintenance mode and it's 2nd year. It's gotten this far on 4hrs/month from one developer who would like to see it in a state where the build-toolchain is documented further, additional tests in Java products to insure future integration, and complete work on the rest of the build.


JERL: Run perl in the JVM

Benefits to the Perl Community

Why should the Perl Community grant this project? The community is using this product and it adds to Perl5's capabilities. A more complete product is more helpful for the QA and dev community.


Current Deliverables may be found at

Expected Deliverables:

  • Java based testing to ensure VM still works with new builds
  • Stable Eclipse project as a build artifact
  • Updates to the VM wrapper
  • Documentation for the build environment
  • Documentation for the test environment
  • A more complete build of perl living within the JVM

Project Details

JERL's aim has been clear: include Perl in Java. The project at 4 person hours / month has been stable enough to maintain the existing product. However, it is not enough time to address build and test related issues without further funding. A few issues and enhancements have been outstanding for a while that cannot progress without further person hours or funding.

Milestones Overview

  • Enhanced Testing: 40-person hours
  • Commandline: 0-person hours (already done in Alien::Jerl)
  • Products: [eclipse project and java test integration]: 40-person hours (needed)
  • Formalize build environment and toolchain: 10-person hours
  • Finalize transition of build from microperl to full perl 2 weeks


  • Enhanced Testing: 40-person hours
    • Java Artifacts 40-person hours
      • Inchstone: Create build artifact for a sample java product
      • Inchstone: Create build artifact for an eclipse product
      • Inchstone: Create tests for VM integration as part of build
      • Inchstone: Create tests for Perl to detect and set Java
      • Inchstone: Modify tests to correct for windows environment
      • Inchstone: Modify tests to be language independent
  • Formalize build environment and toolchain: 10-person hours
    • Inchstone: Build and debug in clean/new ubuntu environment
      • Inchstone: Document environment setup during creation
    • Inchstone: Document build process in the form of text and wiki entries
    • Inchstone: If failures or complexities are encountered then document differences from PERL5
  • Full Perl5 Functionality:
    • Research meta-build 160-person hours
    • Inchstone: Re-research the perl5 build and how the build builds the build
    • Inchstone: Review how to run the built products from the VM to allow for the Perl5 build to continue even though some of the build will have to proceed in the VM
    • Inchstone: Document build process, identify pieces that migrate to VM

Project Schedule

  • How long will the project take?

    1 month for 1 developer effort

  • When can you begin work?

    Late March, Early April 2014

Completeness Criteria

  • Completeness Criteria:
    • Inchstone identified have measurable artifacts which include projects
    • Whitepaper / Howto Build


  • Who are you?

    My name is Michael Shomsky

  • What makes you the best person to work on this project?

    I want to see this work and have been nursing this project, from inception, since 2012. I'm delighted that there are people out there who use it.

Tony Cook writes:

Approximately 57 tickets were worked on, and 12 patches were applied.

Probably the most interesting issue this month was diagnosing the HP-UX bus error in during regexp compilation, I won't repeat the diagnosis here, but it can be found at:

with some on-point follow-ups from Nicholas Clark, Dave Mitchell and Yves Orton.

This month brings the total hours spent on my second grant to 265.07 hours, which exceeds the limits of the grant.

1.40#116925 review ticket, review perl docs and code, comment
1.61#119499 review the discussion
#119499 comment
1.72#119593 review, reproduce, find a bisectable test case,
bisect, open cpan ticket 92771, comment
1.23#120120 try to reproduce, comment
2.40#120374 testing, work on diagnosis
#120374 more diagnosis, find the change in behaviour, start a bisect, comment
0.87#120692 benchmark and comment
2.04#120936 cygwin shm.t failure - fix skip logic
#120936 cygwin taint.t failure
2.26#120939 review new patch and comment
#120939 try to reproduce leak
#120939 fix just the leak
0.23#121018 review and start a comment, but rjbs beats me to it
0.88#121028 rebase and extract closepid change only, retest,
apply to blead, comment, open 121159
0.37#121033 review, review PerlIO_openn(), comment
0.13#121039 resolve with comment
0.55#121047 review, test and apply to blead
1.28#121081 produce a test patch
#121081 apply patch and comment
1.57#121112 produce a patch
2.93#121119 research and comment
#121119 try PERL_DISABLE_PMC suggestion
#121119 summarise to ticket
#121119 review discussion and comment
0.32#121126 review and comment - bring back test.deparse
1.65#121134 review, research state variable ops, test, apply
to blead and comment
0.80#121151 reproduce, research standards, comment
0.18#121162 test BBC broken module against fix
0.25#121172 review, test and comment
0.33#121173 review, test and apply
0.52#121176 review, test, apply to blead and perldelta
0.25#121182 review discussion and comment briefly
1.90#121196 produce a test, a fix and a comment
#121196 rebase, review, retest and apply
0.30#121203 review and apply
1.52#121207 review, test and comment
#121207 retest, minor fix, apply and comment
0.22#121220 comment
3.17#121223 review and comment (also watchdog issue discussion in IRC)
#121223 read response, try to work up a supplementary patch
#121223 comment
#121223 minor fixes, apply to blead
1.48#121236 review, research and comment
HP-UX problem and #121236 IRC discussion
0.43#121240 comment, review, apply and comment some more
0.68#121257 reproduce and comment
0.58#121259 comment, start bisect
#121259 test sprout's patch
2.14#121269 review patch and linked discussion, review older changes
#121269 test UTF-16 BOM, comment
#121269 review discussion, review code, experiment and comment
0.32#121287 review and comment
0.40#121291 test -Dusedl build, check on Module::Load failure, comment
#121291 test, comment and close
0.28#121292 open ticket based on 121269 discussion
0.30#40565 review comments
0.85#40867 review comments, proposed patch and find2perl code, comment
1.85#77672 review smoke-me reports, rebase, re-test locally,
write regression test
#77672 more writing regression test, apply to blead,
perldelta, comment, resolve
1.43#81074 try to deliver an unhandled signal to the main thread
1.83check for cygwin build failure, reproduce failure, produce
and test a fix
1.85cygwin win32core.t failure
0.37cygwin win32core.t failure, produce a fix on cygwin and
start a win32 test run
0.73diagnose HP-UX failures
4.23HP-UX debugging, found the immediate issue
0.82I18N::Collate test failure cygwin - strange strxfrm results
0.32more win32core, find some related issues
0.12nuke perl5-security spam and encourage others to do the same
0.97p5p catch up
0.53post describing the HP-UX issue
0.35report an bug
0.17run/locale.t tests for khw
0.83some more HP-UX failure testing, discussion
0.55test khw's latest run/locale.t smoke-me
3.42try more diagnosis through debugger, work on setting up
bisect, start bisect, watch blead succeed and try an
0.97win32core.t - work up final commits, test on both cygwin
and win32, push to blead

61.68 hours total

Tony Cook has requested an extension of $20,000 for his Maintaining Perl 5 grant. This grant has been running successfully since July 2013. The requested extension would allow Tony to devote another 400 hours to the project. The funds for this extension would come from the Perl 5 Core Maintenance Fund.

Before we make a decision on this extension we would like to have a period of community consultation that will last for seven days. Please leave feedback in the comments or, if you prefer, email your comments to karen at

Project Name

Maintaining Perl 5


Tony Cook


Free up one of the Perl 5 core's contributors to work non-stop on making Perl 5 better.

Benefits to Perl 5 Core Maintenance

This grant provides the pumpking with a development resource to target as he or she wills, while still providing for more general bug fixes and other improvements to the perl core.


I propose to adopt the same model as Dave and Nicholas's successful ongoing grants.

Like their grants, there are intentionally no pre-defined deliverables for this project. I intend to devote around 400 hours (about 20 hours a week) over the next 20 weeks to work on improving the core, paid by the hour at the same below-commercial rate as Dave and Nicholas. Some weeks I may be able to more than 20 hours, if acceptable this will consume more hours and end the grant earlier.

Like them, I would post a weekly summary on the p5p mailing list detailing activity for the week, allowing the grant managers and active core developers to verify that the claimed hours tally with actual activity, and thus allow early flagging of any
concerns. Likewise, missing two weekly reports in a row without prior notice would be grounds for one of my grant managers to terminate this grant.

Exactly as Nicholas and Dave do, 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 summarising the whole month. The report would need to be signed off by one of the grant 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"), the grant managers would be allowed, at any time, to inform the board that in their opinion the project is failing, and that the TPF board may then, after allowing me to present my side of things, to decide 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").

I view this grant as a proof of concept - if it goes well for everyone involved, I expect to apply to extend it.

Project Details

I think that the work that I would do to improve Perl 5 would mostly fall into one of four main classes: code reviews, bug fixing, helping other contributors, and adding features - with bug fixes the most prominent and adding features the least.

In one major sense what I'm offering is different to Nicholas's or Dave's grant: the current pumpking would be able to assign tasks directly.

Ideally this would be done with some consultation with myself, so a large complex task involving parts of the core I'm unfamiliar with isn't assigned (or is assigned with reasonable expectations on time). Of course, if too many tasks are negotiated into non-existence, the grant can be terminated.

Some possible tasks, based on discussions over the last several months:

  • readpipe(@list)
  • core exception objects
  • a git hook to prevent changes in the left of a merge

Success metric: completion of tasks assigned.

Otherwise I'd work on:

  • Reviews of patches submitted to perlbug, possibly committing them
  • This will improve my core knowledge, and provide more timely feedback to non-committers using their time to help perl.

Metric: number and complexity of patches applied or commented on.

  • Fixing bugs I select from the perl5 Request Tracker queue.

While I wouldn't necessarily be working on the the harder bugs that Dave targets, this would help bring the total bug count down, and reduce the noise in the Request Tracker queue.

Metric: number and complexity of issues fixed.

  • Fixing systemic issues in perl, such as the mis-use of I32 and U32 in the perl core.

Metric: complexity of issue solved.

  • Contributing to discussion on the perl5-porters mailing list.

For the grant, I'm specifically not proposing to:

  • Be a release manager. This doesn't prevent me volunteering to act as a release manager, but that wouldn't be counted towards this grant.
  • Act as language designer - I don't feel that I'm good at this.

Project Schedule

I expect that I can deliver 400 hours of work in approximately 20 weeks.

I am available to start work on this project immediately.


I'm a freelance programmer living in Australia.

I've been irregularly contributing to perl since 2008 and a committer since 2010.

My contributions have varied from build system fixes, to UTF-8 handling, to portability fixes.

I've been programming in C for 25 years and in perl for 20.

Endorsed By

Ricardo Signes, Nicholas Clark, H.Merijn Brand

Amount Requested


Suggestions for Grant Manager

Ricardo Signes, Marcus Holland-Moritz

GooglersGive to TPF


The Perl Foundation is now listed as a cause on This means that employees of Google may now donate to The Perl Foundation through GooglersGive, their workplace giving program. When making contributions through benevity, please search for "Yet Another Society"

We appreciate all of the Google employees that nominated us, and we thank everybody for all of your support of The Perl Foundation. Through your support, we are ensuring the future of Perl for a long time to come.

I am pleased to announce that we will once again be taking part in the Outreach Program for Women.

The application period is now open for women looking for a summer internship working on a Perl related project. The internship will take place from May 19th to August 18th 2014. The internship pays a stipend of $5,500 and the intern is expected to work full-time on the project. The deadline for applications is the 19th March. Full details of the eligibility requirements and how to apply for an internship can be found on the program website.

If you are an intern interested in working with Perl please take a look at our ideas page and also the project ideas page for this year's Google Summer of Code. If you are already working on a Perl project and what to contribute to that we can help you find a suitable mentor.

Last summer was the first time that we took part in the program. We had one intern, Upasana Shukla, who worked with her mentor Shawn Moore on the Moose project. You can read about Upasana's experiences as an intern and Shawn's experiences as a mentor.

We are still looking for mentors and project ideas for the interns. If you are interested in the possibility of having an intern working on your project for the summer please contact karen [at]

I am pleased to announce that Ricardo Signes' grant application and David Golden's QA Hackathon Travel Grant application have been successful. I would like to thank everyone who provided feedback on these grants.

The grants were awarded from our Perl 5 Core Maintenance Fund. If you wish to contribute to this fund please go to our donation system or contact karen [a]

The QA Hackathon is a free of charge coding workshop for people involved in Quality Assurance, testing, packaging, CPAN, and other quality assurance projects. It is taking place in Lyon, France, from Thursday 13th March to Sunday 16th March 2014.

As announced previously, the Grants Committee calls for grant proposals every two months. This is the first round under the new rule.

If you have an idea for doing some Perl work that will benefit the Perl community, consider sending grant application. The application deadline is March 14th. We will publish the received applications, get community feedback and conclude the acceptance by March 31st.

There are several reasons for you to apply for a grant. 1) Your work will get visibility through TPF 2) You will be assigned a grant manager who will help you accomplish the goal 3) Cash will be paid upon grant completion.

To apply, please read how to submit a grant. Grants Committee Charter and Rules of Operation will also help you understand how the grant process works.

The grant amount is always a difficult topic. Try to be realistic; there is no simple rule but it will be best to determine your amount based on the past grants.

If you have further questions, please contact us at tpf-proposals at

About TPF

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

About this Archive

This page is an archive of entries from March 2014 listed from newest to oldest.

February 2014 is the previous archive.

April 2014 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