We have received the following Perl 5 grant application from Ricardo Signes.

Before the Board votes on this proposal we would like to have a period of community consultation. Please leave feedback in the comments or if you prefer send email with your comments to karen at perlfoundation.org.

Name

Ricardo Signes

Project Title

Perl QA Hackathon 2012
Amount Requested: $900

Synopsis

This grant will be used to pay for travel for Ricardo Signes to and from the Perl QA Hackathon held in Paris in Q1 2012.

Benefits to Perl 5

I have attended three of the four Perl QA Hackathons (Oslo, Birmingham, Amsterdam) and have, at each of them, been able to contribute several solid work days of very productive work to the infrastructure behind the CPAN and related tools. Specifically, I was one of the chief implementors of the new CPAN Testers platform (Metabase) and built the Fake CPAN system for testing CPAN tools, and several reusable software libraries that are used to power both Metabase and Fake CPAN.

In 2012, I hope to continue some work performed with David Golden in 2011, refactoring PAUSE and adding more regression tests to it. PAUSE is the system which processes contributor uploads to the CPAN, manages CPAN contributor identity, and builds the CPAN indexes used by CPAN clients to locate libraries for installation.

In previous years, I also spent a significant amount of time working with other attendees on their contributions, and plan to do the same this year. This is one of the several reasons that attendance in person is incomparably superior to "virtual attendance."

Deliverable Elements

The QA Hackathon does not have a set agenda, so promising specific work product from it up front seems unwise. I have detailed, above, the sort of work that I am almost certain to do, however. Further, I will provide a public, written report of my activities at the Hackathon.

Any software that I produce will be released under the Perl 5 standard license terms.

Applicant Biography

I have been building software in Perl professionally for about twelve years. I am a frequent contributor of original software to the CPAN and a frequent contributor to, or maintainer of, other popular CPAN libraries. I am also a contributor to the core Perl 5 project, and its current project lead.

I have been the recipient of TPF grants twice before, both of which were completed promptly and successfully.

Dave Mitchell writes:

As per my grant conditions, here is a report for the December period.

Spent it continuing my overhaul of the re_eval mechanism. This month I finished off fixing literal code blocks within patterns; that is to say, in all places where a code block appears literally within a quoted-regex context in perl source, that code block will only be compiled
once, at the same time as the surrounding perl code, and then passed round as necessary rather than being recompiled.

The main things left to do are to fix non-literal code blocks, e.g.

$code = '(?{...})';
use re 'eval';
/abc$code/;

and make the code blocks be invoked in such a way that things like die,
return and caller() will work.

Over the last month I have averaged 8 hours per week.

As of 2011/12/31: since the beginning of the grant:

94.9 weeks
1052.4 total hours
11.1 average hours per week

There are now 248 hours left on the grant.

Report for period 2011/12/01 to 2011/12/31 inclusive

Summary

Effort (HH::MM):

0:00 diagnosing bugs
37:00 fixing bugs
0:00 reviewing other people's bug fixes
0:00 reviewing ticket histories
0:00 review the ticket queue (triage)
-----
37:00 Total

Numbers of tickets closed:

0 tickets closed that have been worked on
0 tickets closed related to bugs that have been fixed
0 tickets closed that were reviewed but not worked on (triage)
-----
0 Total

Short Detail

37:00 [perl #34161] METABUG - (?{...}) and (??{...}) regexp issues

Nicholas Clark writes:

The start of December was mostly spent unpicking and simplifying how embed.h is included in perl.h. embed.h is one of the core's generated headers, containing C pre-processor directives to simplify use of the C API functions, by wrapping them such that the programmer doesn't need to deal with the implementation details of ithreads.

Over the years, embed.h has come to be included by perl.h in 4 different places depending on which OS perl is being built on. The confusion started 13 years ago when a second #include "embed.h" was added later in perl.h to support the now long defunct "PERL_OBJECT" system. This later migrated to be used for all Win32 builds. Subsequently VMS and Symbian gained special-cased includes of their own in perl.h, as like Win32 they defined HAVE_INTERP_INTERN, which needed to be done before embed.h was included.

The silly part is that it turns out that there was no reason why the include of embed.h had to be early on any OS. So it's possible to simplify perl.h by taking the Win32-only #include embed.h near the end, and removing the conditional code, so that all operating systems use it.

I also eliminated code from a2p to support using Perl's malloc, which was "temporarily" commented out 13 years ago, pending a proper fix. The lack of bug reports suggest that no-one has missed this. I worked with Craig Berry to simplify vmsish.h, which contained support code for a2p on VMS that isn't actually necessary.

Related to investigating both, I spotted that conditional code for NO_EMBED could be removed from sdbm.h. The functionality of NO_EMBED was removed 13 years ago, and most every other reference purged in 2003.

There is probably quite a bit more conditional compilation code that could be removed from sdbm.h. However, I'm not sure that it's worth it, as the cost of verifying that one has done it without error is likely to be much greater than the benefit that it brings. There's a lot more low hanging fruit elsewhere, plenty more than we have people to harvest it.

The "highlight" of the month was installman, the script that make install uses to locate documentation and install it as man pages. Initially it was something I could work on offline whilst travelling by train to London to meet Jesse (and others) for Dim Sum. Except that it turned out to be a lot more messy than it first seemed.

installman is responsible for finding Pod documentation in .pm and .pod files, passing the Pod to Pod::Man to generate manpages, and then installing the manpages in the correct location. There are exceptions - we don't install documentation for certain modules, we don't install certain modules (so we shouldn't install their documentation), and we should skip test modules. Half of this overlaps with what pod/buildtoc does. However, the code was completely different, with partially inconsistent exception lists, exceptions that are no longer needed, etc.

installman and buildtoc now share as much code as possible, with the installation exception rules in one place, and all dual life Pods now install in man1/

While the code still fresh in my mind, I also refactored the common Pod installation to eliminate pod.lst. This was the master Pod data file, added in 2003 by commit 416302502f485afa as part of a refactoring to reduce the amount of manual work needed to maintain Pod-related rules in various files, and to reduce errors and inconsistencies between them. It turned out that pod.lst contained quite a lot of data which were only needed to generate the table of contents in pod/perl.pod, and that there wasn't that much extra in pod.lst that wasn't in pod/perl.pod. Hence the two were near duplicates of each other, and simplification should be possible. By careful use of =begin, =end and =for Pod directives in pod/perl.pod is has been possible to readably encode the extra data into the source of pod/perl.pod without affecting the rendering and thus eliminate pod.lst. This both simplifies the distribution, and the tasks the release manager needs to perform each month.

In the process of doing this, I discovered that the changes that permitted dual-life Pods to move from pod/ to their owner distributions in dist/ and cpan/ had introduced another regression post v5.15.0 - the Pod files were now installed as if they were modules, into lib/, instead of the correct location with all the other core Pod files. In theory, this was a simple change to the installperl script to get it to use the code common to installman, buildtoc and a couple of other helper scripts. In practice, it turned out to be more complex, as there was another organic mess that needed simplification.

Key to this was changing the invocation of File::Find::find() that processes lib/ to run with 'no_chdir'. This allows that code to call other routines that use pathnames relative to the top of the build tree to access files, and as a side effect eliminates the localised package variable $::depth which was used to maintain a faked path prefix for display purposes to counter the effects of the directory change.

There is still a considerable amount of sanity refactoring that could be done on installperl. In particular, the code that processes lib/ has accumulated a lot of exception rules, at least some of which are now redundant and should be removed. This is left as an exercise to any reader who enjoys the mental challenge of figuring out the history of code from the "blame" log: http://perl5.git.perl.org/perl.git/blame/HEAD:/installperl

A more detailed breakdown summarised from the weekly reports. In these:

16 hex digits refer to commits in http://perl5.git.perl.org/perl.git
RT #... is a bug in https://rt.perl.org/rt3/
CPAN #... is a bug in https://rt.cpan.org/Public/
BBC is "bleadperl breaks CPAN" - Andreas König's test reports for CPAN modules

114.50 hours total

Its that time of the year, again. The Perl Foundation is looking at giving some grants ranging from $500 to $2000 in February 2012.

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 until the end of January.

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 GC current rules of operation at http://www.perlfoundation.org/rules_of_operation. Then send your proposal to tpf-proposals@perl-foundation.org. Note that should be properly formatted accordingly with our POD template.

Proposals will be made available publicly (on this blog) for public discussion, as it happened in the previous rounds. So, please make it clear in your proposal if it should not be public, and why.

Dear Community,

After the voting process, the grants committee rejected all grant proposals. One of them (translation of Perl documentation) was rejected by not compliance with the GC rules, and the other were rejected by a vote of the committee.

A new round of grant proposals will open next week.

Dear Community,

In the last two months we had a call for grant proposals. We got four proposals that are now available for discussion. Please follow the links below, read each proposal, and comment about the relevance of the grant, and if you think TPF should sponsor that work.

• #103612: Still - perl-controlled alcohol distillation system by Steve Eirium
• #104490.1: raidlax - raid5-style redundancy above the filesystem by Steve Eirium
• #104490.2: recogniser - responsible applications of entropy by Steve Eirium
• #105120: Turkish Localization of the 5.14.1 Perl Documentation by Allyson Whitney-Caputo

Steve Eirium <[hidden email]>

DISCUSSION

In a world of bank bailouts and wikipedia's cries for funding, one thing rises above the swamp of crap: making alcohol. Clearly one of the best things to be doing on the surface of a planet, it is only natural that some fusion would erupt on the interface with perl. Operating a reflux still is a fumey experience of careful timing. To avoid dying or going blind, one must cut the condensate hose from one jug to another at the appropriate column temperatures to avoid thesurrounding methanol. The process is mostly lying around in the sun, however.

However, the process is mostly operating valves, checking the temperature probe, and moving a hose from one bottle to another. This is all so simple, in a world of 12v solenoids that could be operated as fans right off a motherboard, why not have a junky computer full of perl in your brewery?

First step: get the perl. I propose I will write software to operate a reflux still, self-containing the whole process from fermentation to huge-bottle-of-ethanol. It will be highly flexible, as are systems of alcohol production, so that eg. merely monitoring the temperature and sounding an alarm when the cut is to be made, or just pumping around mash automatically, is possible.

Benefits to the Perl Community are having out there the softer half of an alcohol making robot, a fairly real thing anyone would think is cool.